Since this week built-in mobile device management (MDM) is available for Office 365 commercial plans. With MDM for Office 365, you can manage access to Office 365 data across a diverse range of phones and tablets, including iOS, Android and Windows Phone devices, without the need for Microsoft Intune. The built-in MDM features are included at no additional cost in all Office 365 commercial plans, including Business, Enterprise, EDU and Government plans.
Office 365’s MDM capabilities work to keep your data safe in three ways:
-Conditional Access: Setup security policies to ensure that Office 365 corporate email and documents can be accessed only on phones and tablets that are managed by your company and are compliant.
-Device management: Manage security policies such as PIN lock and jailbreak detection to help prevent unauthorized users from accessing corporate email and data on a device when it is lost or stolen.
-Selective wipe: Remove Office 365 company data from an device while leaving personal data in place.
When looking at the Feature Comparison, there are big differences seen between Exchange ActiveSync, MDM for Office 365, Intune Standalone and Intune + ConfigMgr (Hybrid). This Feature Comparison can help to decide which solution offers the functionality needed.
When looking for protection beyond what’s included in Office 365, you can subscribe to Microsoft Intune, part of the Microsoft Enterprise Mobility Suite, and receive additional device and application management capabilities for phones, tablets and PCs. With Microsoft Intune actions such as cut, copy, paste and save as to applications can be restricted as well, keep corporate information even more secure.
Nice to see that Office 365 has MDM capabilities from now on!
Source: Office Blogs
In my daily work I'm doing ConfigMgr implementations a lot. Multiple features missing in ConfigMgr 2007 were implemented in the 2012 release, which is still an awesome product (if you ask me)! Let's have a look at the most wanted features requested by customers. Don't know for sure what the 'vnext' release will bring, but still want to mention them. When having more, just leave a comment.
1) Hash value error during deployment: When updating a single package during deployment, which is part of a OSD task sequence, it fails because of hash value. When having a large enterprise company, it's hard to explain this! Maybe OSD and packaging are different teams then. Or people are working 24 hours around the globe in a single ConfigMgr Site. Just offer both old and new hash for a few hours and don't let the task sequence fail because of this! A colleague mentions: When this is the case, ConfigMgr isn't an enterprise product, and I think he is right on this point. (Must check it again)
2) Continue task sequence after error: It's crazy that when a task sequence fails (which happens a lot during testing), you cannot restart the task sequence from the point it fails. One mistake and you can start all over again, or you must enable "continue on error" on every step or group. Why not ask a question if you want to continue OSD after all? Makes life a lot easier during imaging.
3) User Environment Management (UEM): When customers want UEM functionality, they must use Group Policy, Preferences, MS UE-V, RES Workspace Manager, Imideo Flex Profiles or AppSense. Why not building more of Group Policy and Profile management in ConfigMgr, so you have best of both worlds? Hope that this part is available in the 'vnext' release, because Windows 10 may be controlled with ConfigMgr completely! Source: Windows 10 enterprise management with System Center Configuration Manager and Intune
4) Application control after deployment: When customers using ZENworks Configuration Manager (ZCM), it's hard to sell the ConfigMgr product. This is not because of imaging, which is a very strong selling feature! It's because of UEM and application control, which is part of ZCM by default. No way you can deploy shortcuts and decide on which time an application becomes available and on which time it's removed. This feature is requested in education a lot, where exams must be available on specific times only. Hope this will be way better in the 'vnext' release, not only on Windows 10, but on applications also.
5) Show collection membership for systems: One of great features of Powershell Right Click Tools, which let you you see in which collections a system or user resides. Should be default functionality in ConfigMgr if you ask me. Why not adding more management tools by default on systems and collections?
6) Black screen when using remote control: Hide the screen from the end user, when typing in sensitive information. Can be a valuable feature, because other remote tools offers this functionality also. Instead of a black screen, a message like "work in progress, please wait" is a nice-to-have also.
7) Change Distribution point (DP) when not available: When you have multiple DP's in the same IP-range, and content is available on one DP only, ConfigMgr is waiting for content and fails afterwards. Content is randomly selected on DP's, so you don't know at forehand which DP is selected per package. When adding content during deployment on the other DP, it will still continue (lucky enough). Better would be, when ConfigMgr doesn't see the needed content on a DP, it will use another one automatically.
Update 15-4-2015:
8) Enforce installation or upgrade during logon/logoff: Software installation can take place when a user is logged on or logged off, but sometimes you want to update a critical component. Best thing to do is to enforce this during logon or logoff, like Group Policy, without the possibility to use the component on the system. This isn't possible at the moment, so companies which are in 24/7 business, have a challenge that way.
Hope that some of features mentioned here are build-in a next release, or added at a later time. Time will tell ;)
During deployment I'm using SCEP installation and update packages a lot. When using the script from Chris Nackers, new definitions can be downloaded automatically each day. Therefore a system is deployed with the latest SCEP update during deployment, and there's less security risk after deployment. Most of time SCEP installation, and antimalware/ antispyware (MPAM) updates goes fine, but Network Inspection System (NIS) updates goes wrong. Errors given are:
-Installation completed with exit code 0x80004005
-Installation failed with error (0x80004005)
-Install Software failed, hr=0x80004005. The operating system reported error 2147500037: Unspecified error
This because you're using the wrong version then. When looking on Microsoft Malware Protection Center, the following is mentioned:
1. Open your security software by double clicking on the icon in the system tray (you may need to click the arrow to see the icon) or, in Windows 8.1, search for Windows Defender:
2. Click the arrow next to Help and choose About:
3. Your software version number is displayed at the line labelled Antimalware Client Version
For version number 4.1.522.0 and above, you must download the Network Realtime Inspection definitions:
-For 32-bit versions of Windows, download 32-bit Network Realtime Inspection definitions
-For 64-bit versions of Windows, download 64-bit Network Realtime Inspection definitions
If you have a version number lower than 4.1.522.0, you must download the Network Inspection Service definitions:
-For 32-bit versions of Windows, download 32-bit Network Inspection Service definitions
-For 64-bit versions of Windows, download 64-bit Network Inspection Service definitions
So yes, there is a difference between Network Realtime Inspection (NRI) and Network Inspection Services (NIS) definitions.
Source: Malware Protection Center
More blogposts on this topic:
Install and update Endpoint Protection (SCEP) during a task sequence
During re-deployment on a HP EliteBook Revolve 810 G3 tablet, the following error message was shown: "An error occurred with the boot selection, verify media is present and retry". Because of that no WinPE is loaded at all, and deployment is not possible. Lucky me the solution was not that hard. Let's have a look at the solution:
Boot your laptop and press F10.
Select [System Configuration]
Select [Boot Options]
Scroll down to [SecureBoot Configutation]
Disable BIOS Secure Boot
Change BIOS Boot Mode to UEFI Hybrid or Legacy Mode
Save and exit
Now boot and press [F12] and PXEboot works
Hope it helps!
Source: HP EliteBook Revolve 810 Tablet - PXE Boot Failure
Update: An ever better solution is as follows:
-Change BIOS to UEFI Native and SecureBoot
-Remove options 060, 066 and 067 from DHCP settings
-Add IP-Helper which is pointing to the WDS and DHCP server
Besides of that the following information:
Try to get rid of DHCP options and use IPhelpers instead. Also make sure that you are using a boot images that matches the architecture of the OS to be deployed. (Torsten)
UEFI is a new beast that has issues with DHCP scope options. UEFI is *very* different than traditional BIOS. (Jason)
Source: UEFI PXE BOOT ERROR
Since November last year I'm using a Microsoft Surface Pro 3 as primary device for my daily work. I wrote multiple blogposts about my experience in November and December. For over 5 months I'm very happy with my choice, never had a doubt I made the wrong choice here. But still there are some minors left. Let's have a look at my experience so far. Pro's and Con's are taken from my post before.
Pro's (changes in bold)
-Fast (with i7 CPU, i5 performance don't know)
-Quiet (on battery always, on power not all the time)
-Battery (approx. 8/9 hours with Office and Internet open)
-12" display (sharp, resolution, pen support)
-Pen (great in presentations)
-Weight (1,1 kg with keyboard)
-New generation device, high wow factor!
-Windows 10 upgrade coming (waiting for RTM to upgrade)
-Kickstand (can be placed in all positions)
-It's both a notebook and tablet
Con's (changes in blue)
-Fan blowing (on power only, not all the time)
As mentioned in the links below, this is being caused by the Windows Installer Module and the Windows Installer Module Worker, which start in the background at random times and cause the CPU to work at higher speeds. This causes the heat and the fans to kick into overdrive. When stopping these processes in Task Manager, my Surface is as quiet as on battery in seconds! Hope that this issue is fixed when moving to Windows 10 in a few months. Otherwise a hardware replacement may be needed to resolve this.
-Out of sleep (when in sleep mode, it will wake up. for it seems because of the keyboard?)
Sometimes my device will go out-of-sleep, which is annoying because all open programs will be gone afterwards. Strange thing that no hibernation is used for this? For it seems the device stays on, till battery power is reached a critical state. After that the device turns down. Lucky me this happens around rarely and not always. Hope this issue is fixed also when moving to Windows 10.
-One USB port only (far too little to connect multiple devices!)
Last week I ordered a Microsoft Arc Touch Mouse Surface Edition, because of this. The mouse works really fine, and benefit of it is a free USB port which I have now. Again no doubt I made the wrong choice here, and it looks great next to my Surface!
-Keyboard function keys (sometimes Fn is needed, sometimes not, which is confusing)
Well, you will get used to it ;)
-There is no insert key on the keyboard (mentioned by @scambler)
Didn't miss it myself actually. What I am missing on modern devices is the lack of pause key, which is really handy during PXE boot. Just have a look HERE for a workaround on the insert key.
More information about the fan blowing:
Fix found for Microsoft's Surface 3 overheating issues
Excessively loud fan, constant overheating during idle and light tasks
Tools To Simulate CPU / Memory / Disk Load (for testing purpose)
More blogposts on this topic:
Microsoft Surface Pro 3 first experience
Microsoft Surface Pro 3 second experience
Last month I did a ConfigMgr upgrade from SP1 to R2, with Cumulative Update 4 afterwards. At first sight everything seems to be okay. After a few weeks however, customer was mentioning OSD was very slow at Driver package and ConfigMgr client stage installation. Default deployment before the R2 upgrade was around 45 minutes, but after R2 upgrade around 135 minutes! Lucky me I found the following post on Microsoft TechNet HERE and HERE.
It mentions:
It appears that MS support was able to find a solution for my environment.
Immediately after enabling the "allow clients to connect anonymously" setting on each distribution point the time it took for the MDT Toolkit package to download went from 30 minutes to around 20 seconds.
The support tech was unable to explain why this setting was required following the R2 upgrade in our environment. He verified that in his lab environment he did NOT have this setting configured on the DP and he saw no issue downloading the MDT toolkit package.
As much as I would like to have a root cause for this issue I'm just happy that my OSD process isnt taking 3 hours now!
At customer mentioned this was the solution also. Immediately after enabling the "Allow clients to connect anonymously" setting on each distribution point configured, deployment was done in 45 minutes again. Strange enough I did a lot of R2 installations, and a lot of SP1 to R2 upgrades also, but never had this issue before. Still happy with this easy to implement solution. Thanks again!
When deploying Windows 8.x with MDT or ConfigMgr, deployment may stop at the network selection screen. When press Connect in the selection screen, deployment will continue. Within this blogpost I show you how to skip network selection.
Within MDT:
The CustomSettings.ini (which can be found on Properties, Rules on the Deployment Share) needs to be changed as follows:
<OOBE>
<HideEULAPage>true</HideEULAPage>
<NetworkLocation>Work</NetworkLocation>
<ProtectYourPC>1</ProtectYourPC>
<HideLocalAccountScreen>true</HideLocalAccountScreen>
<HideOnlineAccountScreens>true</HideOnlineAccountScreens>
<HideWirelessSetupInOOBE>true</HideWirelessSetupInOOBE>
</OOBE>
Within ConfigMgr:
The unattend file (additional file which can be used in the Apply Operating System step) needs to be changed as follows:
<?xml version="1.0" encoding="utf-8"?>
<unattend xmlns="urn:schemas-microsoft-com:unattend"> <settings pass="oobeSystem">
<component name="Microsoft-Windows-Shell-Setup" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<OOBE>
<HideEULAPage>true</HideEULAPage>
<HideWirelessSetupInOOBE>true</HideWirelessSetupInOOBE>
<NetworkLocation>Work</NetworkLocation>
<HideOnlineAccountScreens>true</HideOnlineAccountScreens>
<HideOEMRegistrationScreen>true</HideOEMRegistrationScreen>
<HideLocalAccountScreen>true</HideLocalAccountScreen>
</OOBE>
<RegisteredOwner>Microsoft</RegisteredOwner>
</component>
</settings>
<cpi:offlineImage cpi:source="" xmlns:cpi="urn:schemas-microsoft-com:cpi" />
</unattend>
For x86 systems, change "amd64" in "x86" to get the job done.
Source locations:
Windows 8.1 deployment in MDT 2013
Windows 8.1 prompting for network (some lines missing)
When using the script from TechNet, the red lines are missing. Therefore an error message is displayed during mini-setup (about /unattend) and deployment stops on that point. Now way you can pass a deployment error during mini-setup, so just use the unattend file mentioned here. Hope it helps!
When deploying packages within a task sequence you can add multiple steps with a single package in every step. When deploying lots of packages, the task sequence will be very large. There is however an alternative, using "Install software packages according to dynamic variable list". That way you can use a single step for as many packages you want. Just configure the following steps:
-Create a collection and add Collection Variables on it. Name must be APP001, APP002, APP003 (for example) and so on. Value must be the package ID value and Program installation name (which is Install in my case). Add as many packages needed.
-In the task sequence add a "Install package" step and choose for "Install software packages according to dynamic variable list": APP (for example). Mark "If installation of a software package fails, continue installing other packages in the list" when needed.
-Just make sure that on every package used, "Allow this program to be installed from the install package task without being deployed" is checked. Otherwise a 80004005 error will follow during deployment.
(instead of APP you can use any name you want, as long as numbers are used. The name used in task sequence must be same.)
Deploy the task sequence on the created collection. All packages will get deployed in a sequence based on the numbering of the collection variables choosed. Just another way for installing packages ;)
In my case I'm installing multiple packages in a single step. Not a problem at all, and very easy to configure.
More blogposts on this topic:
Deploy multiple applications using Dynamic Variables in a Task Sequence
When doing deployment on modern ultrabooks or devices like Microsoft Surface, no ethernet adapter is build in. You must use external adapters by using USB connected to have the same behavior. When using multiple cables however, or using the same ethernet adapter for multiple devices, ConfigMgr is going crazy. When that happens it's good to know that SMBIOS GUID's can be used as well instead of using a MAC address. Let's have a read on that one.
The MAC address of a network interface is its unique identifier. Think of it as the serial number of that network interface. When switching network interfaces between devices, MAC addresses wil change also. Therefore we need a SMBIOS GUID. ConfigMgr 2012 uses SMBIOS to identify computers, and falls back to MAC addresses if SMBIOS information is not available. SMBIOS is the GUID that is stored in the Device’s BIOS or UEFI. It’s unique to the device and ConfigMgr uses it to recognize prestaged computers.
When importing systems in ConfigMgr, a computer name and MAC address or SMBIOS GUID must be filled in. MAC addresses can be found in command prompt when typing in "ipconfig /all". SMBIOS can be found in BIOS or by typing in "wmic csproduct get uuid". After re-deployment, where I switched network interfaces, the correct computer name was still used. So when using SMBIOS instead of MAC, it's allowed to switch network interfaces. Good news!
When importing of many new systems is needed, just ask your hardware vendor for a list of SMBIOS GUID's. That way it's easy to import them in ConfigMgr, and prevent MAC address isues. For example: SurfacePro3, 00:1E:8C:17:F0:E5, 3164B0C0-AB47-11DC-A63B-001E8C17F0E5 (for usage in a CSV file). The future is bright, ConfigMgr is still in lead on this one ;)
For more information, have a look on: Microsoft blogs
Last week I did some ConfigMgr client installation on DMZ workgroup servers. Installation of the client went fine, but they went on internet mode after that. There was no possibility to add them to a Site either. Looking in locationservices.log the following lines were showed:
-Failed to resolve 'SMS_SLP' from WINS
-Unable to find lookup MP(s) in Registry , AD, DNS and Wins
-LSIsSIteCompatible: Failed to get Site version from all directories.
-failed to get dp locations as the expected version from mp
The installation line used was as follows:
Ccmsetup.exe /mp:<FQDN> /logon SMSSITECODE=XXX FSP=<FQDN>
After a few installations I found the following website:
About Client Installation Properties in Configuration Manager 2012
It mentions:
/source:<Path> = Specifies the location from which to download installation files. You can use a local or UNC installation path. Files are downloaded by using the server message block (SMB) protocol.
/mp:<Computer> = Specifies the source management point for downloading installation files. Files are downloaded over an HTTP or HTTPS connection, depending on the management configuration for client connections. This download uses BITS throttling, if BITS throttling is configured. If the management point is configured for HTTPS client connections only, you must verify that the client computer has a valid PKI client certificate.
/logon = Specifies that the client installation should stop if any version of the Configuration Manager 2012 or SMS client is already installed.
SMSMP = Associates the Configuration Manager 2012 client with the specified management point. You can specify a fully qualified domain name as this property.
In the end I used the following installation line to install ConfigMgr 2012 Clients on DMZ workgroups servers successfully:
Ccmsetup.exe /source:<path> SMSSITECODE=XXX FSP=<FQDN> SMSMP=<FQDN>
Hope it helps!
Source:
Install SCCM 2012 Client on DMZ workgroup servers
Managing workgroup clients in Configuration Manager 2012
Today I did another ConfigMgr upgrade from SP1 to R2 with 3 remote Distribution points (DPs). Nothing to worry you will say. After the upgrade (which was 100% fine) the Primary server and 1 remote DP was working fine. Deployment could be done, everything okay. Nothing to see in Site and System status. The other 2 remote DP's however didn't want to PXE boot because of error "PXE-E53: No boot filename received". Last line in SMSPXE.log was ================= PXE Provider shutdown. =====================
I did a lot of things after that:
-Restart WDS services
-Update both boot images and checked properties
-Restart multiple Site servers
-Checked logfiles (On primary and Site servers)
-Checked DHCP scope options
-Checked local security
-Checked SMS Component Manager
-Checked firewall status
-Checked no antivirus in place
SMSPXE.log was showing me the following lines:
-RequestMPKeyInformation: Send() failed.
-Failed to get information for MP: http://FQDN. 80004005
-PXE::MP_InitializeTransport failed; 0x80004005
-PXE::MP_LookupDevice failed; 0x80004005
-RequestMPKeyInformation: Send() failed.
-Failed to get information for MP: http://FQDN. 80004005
-PXE::MP_InitializeTransport failed; 0x80004005
-PXE::MP_ReportStatus failed; 0x80004005
-PXE Provider failed to process message.
-Unspecified error (Error: 80004005; Source: Windows)
-98:4B:E1:7E:6D:89, 39C6D000-9BED-11E0-0000-984BE17E6D89: Not serviced.
-Cannot read the registry value of MACIgnoreListFile (00000000)
-MAC Ignore List Filename in registry is empty
Nothing didn't work here! When looking on MS TechNet they say you must reinstall WDS, PXE, DP all over again. Not exactly what I had in mind here. Long story short, after a few hours checking I rebooted the Primary Site server, restarted WDS services on both DPs again, and everything was working in a few minutes. First line in SMSPXE.log was now ================= PXE Provider loaded. =====================
Very happy with the (easy) solution, but very strange ConfigMgr didn't gave me an error. There's no mentioning of rebooting a Primary Site server after the upgrade also. Lessons learned: Reboot the Primary Site server and Site servers after an migration always.
Source:
Upgrade ConfigMgr 2012 SP1 to 2012 R2 Preview
Management Point PXE Boot Error 80004005 After SP1 Upgrade
SCCM 2012 R2 upgrade broken WDS/PXE
PXE-E53: No boot filename received
Microsoft has announced the first build of Windows 10 Technical Preview for Phones. I used Windows 8.1 Technical Preview several months on my device. After using my Samsung Ativ S for almost 2 years now, i'm still very happy with my choice. My next Phone will run Windows 10 for sure, no doubt about that. The reason that multiple favorite apps are missing, is no obstacle for me. Microsoft rocks!
When you want to run Windows 10 Technical Preview, just make sure to follow the next steps:
-Join the Windows Insider Program
-Register your device to receive builds as over the air updates
-Builds will come to you automatically as they are ready, after being validated by engineers at Microsoft and used on their own phones
-Use the built-in Windows Feedback app to send us problem reports and suggestions
-Updates will continue all the way up to the final build that goes out to all customers
-You can roll your phone back to the previous OS any time you’d like
If you’re a Windows Phone customer and love to try the latest stuff before anyone else, or a Developer or IT Pro who works with Windows Phones, joining the Windows Insider program and trying out this build may be right for you. You’ll be getting an insider’s view and getting builds that normally would have only been available to Microsoft engineers in the past. Same as on Windows 10 Technical Preview.
There are a lot of known issues mentioned already. Just have a look at them to see what to expect. Still great to have the opportunity to try the earliest publicly available preview for Windows 10 Technical Preview. Do you take the risk or not, that's the question.
Source: Blogging Windows
When creating a new report on the ConfigMgr server, the following error message is displayed: "The Report Builder click-once application does not exist on the report server. Ensure that the report builder application manifest exists on the server and try again." Point is Report Builder 3.0 must be installed first. In my situation I use a single ConfigMgr server and a remote SQL server with Reporting database. After installation however the error message displayed is still the same. What's going on here!?
Lucky me I found the following website: TechNet blogs
It mentions: On the computer running the ConfigMgr console, open the Windows Registry Editor. Browse to HKLM/ SOFTWARE/ Wow6432Node/ Microsoft/ ConfigMgr10/ AdminUI/ Reporting. Double-click the ReportBuilderApplicationManifestName value to edit the value data. Change ReportBuilder_2_0_0_0.application to ReportBuilder_3_0_0_0.application, and then click OK.
After that additional steps were needed also:
Use Notepad or any text editor to open the file: *Note Open Notepad as Administrator, otherwise you won’t be able to save the edits.
"C:\ Program Files (x86)\ Microsoft Configuration Manager\ AdminConsole\ bin\ Microsoft.ConfigurationManagement.exe.config"
Scroll down to the <ReportBuilderMapping> section.
In my case it originally contained
<ReportBuilderMapping>
<add key="11.0" value="ReportBuilder_3_0_0_0.application"/>
<add key="10.50" value="ReportBuilder_3_0_0_0.application" />
<add key="10.0" value="ReportBuilder_2_0_0_0.application"/>
<add key="DEFAULT" value="ReportBuilder_2_0_0_0.application"/>
</ReportBuilderMapping>
We want to replace the 2's in those last two lines with 3's, so it looks like this:
<ReportBuilderMapping>
<add key="11.0" value="ReportBuilder_3_0_0_0.application" />
<add key="10.50" value="ReportBuilder_3_0_0_0.application" />
<add key="10.0" value="ReportBuilder_3_0_0_0.application"/>
<add key="DEFAULT" value="ReportBuilder_3_0_0_0.application"/>
</ReportBuilderMapping>
After that it was finally possible to open the SQL Report Wizard.
Sometimes there are multiple Management points installed for high availability or communication reasons. With Distribution points you set boundary groups to decide with one to use. With Management points they will be randomly selected. This can be seen in ClientLocation and LocationServices logfiles. With Cumulative Update (CU) 3 however there's a possibility to set the Management point also. In this scenario you have MP1 and MP2, where MP1 is forced (for example). Let's have a look at the logfiles after applying the key:
Key: HKLM\SOFTWARE\Microsoft\CCM:AllowedMPs
Type: Reg_Multi_SZ
Value Data: <Management point>
ClientLocation.log
-Rotating assigned management point, new management point is: 'MP1'
-Assigned MP changed from 'MP2' to 'MP1'
This will be applied daily. (every 25 hours)
LocationServices.log
-The MP name retrieved is 'MP1'. MP 'MP1' is compatible
-The MP name retrieved is 'MP2'. MP 'MP2' is compatible
-Retrieved MP 'MP1' from Registry
-Attempting to retrieve lookup MP(s) from AD. Lookup Management Points from AD: 'MP1' and 'MP2'
-Not persisting assigned management point 'MP2' because it is not in the list of allowed MP's
-MP list is forced, ignoring MP 'MP2'
-Default Management Points from MP: 'MP1'
This can be handy when you want to enforce Management points for static systems. For roaming systems this is not recommended, because it will still be communicate with the Management point, even when on another location. Still great to see that Management point can be enforced, when no use of a Secondary site is made.
More information: MS TechNet Blog
This week I had a strange issue in Remote Tools. Everything was working fine on the ConfigMgr client, and Remote Tools for it seems also. But when starting the "Send Ctrl-Alt-Del Key" nothing was happening. Strange issue, never seen that before! The solution for this is not that hard, because other people has already found a solution for it. As far as I know a GPO is blocking this functionality.
Just create or edit a Group Policy, browse to Computer Configuration, Policies, Administrative Templates, Windows Components, Windows Logon Options. In there enable the setting "Disable or enable software Secure Attention Sequence" and configure it on "Services and Ease of Access applications". After a GPupdate you will see the "Send Ctrl-Alt-Del Key" is working (again)! Happy again :-)
Source: Microsoft TechNet
Today Cumulative Update (CU) 4 for ConfigMgr 2012 R2 is released. It fixes 27 issues and 4 additional changes are included. No need to install CU3 anymore when using this one.
Here's a list of issues that are fixed, there are quite a lot of them:
- Client (2 fixes)
- Software distribution and application management (6 fixes)
- Network Access Protection (1 fix)
- Operating system deploymenjt (2 fixes)
- Administrator Console (1 fix)
- Site servers and site systems (6 fixes)
- Mobile devices (5 fixes)
- Migration (1 fix)
- Reporting (2 fixes)
- Software updates (1 fix)
Additional changes that are included in this update:
- Windows PowerShell (lot of changes)
- Data replication (performance replications)
- Endpoint Protection (anti-malware platform update)
- Operating systems other than Windows (Mac OSX 10.10, Suse Linux Enterprise Server 12 (x64)
Just install it in your environment when experiencing problems described in this article. When not affected by these problems, Microsoft recommends to wait for the next service pack that contains this update. The version that is displayed in the About System Center Configuration Manager dialog box is 5.0.7958.1501.
This update replaces Cumulative Update 3 for System Center 2012 Configuration Manager R2
For more information or download the update have a look here: Microsoft Support
When System Center Endpoint Protection (SCEP) updates are not applying and the following errors are mentioned, Windows Update is not configured right. Let's first have a look at the errors:
WindowsUpdate.log
-CNetworkCostChangeHandler: RegisterForCostChangeNotifications: CoCreateInstance failed with error 80004002
-RegisterNetworkCostChangeNotification: Error 80004002
-Failed to get Network Cost info from NLM, assuming network is NOT metered, error = 0x80240037
-Network Cost is assumed to be not supported as something failed with trying to handls to wcmapi.dll
-CSerializationHelper: InitSerialize failed: 0x80070002
UpdatesDeployment.log
-Job error (0x87d00692) received for assignment
WUAHandler.log
-Failed to Add Update Source for WUAgent of type (2) and id {}. Error = 0x87d00692
Long story short, there was an unknown WSUS policy in-place! After changing few settings everything was working immediately.
Just make sure "Allow Automatic Updates immediate installation" is enabled, and "Specify intranet Microsoft update service location" is pointing to the ConfigMgr SUP server on port 8530/8531. Then you will be fine after all. Hope it helps!
Source: SCEP updates pushed out to clients through SCCM 2012
When installing the ConfigMgr client on Windows Server 2003 (R2) systems, there may be an error message in ccmsetup.log (Windows\ ccmsetup\ Logs folder). This because prerequisites are not in place to succesfully install the client.
-Failed to query BITS 2.5 interface with error 0x8004002
-This operating system does not contain the correct version of BITS. BITS 2.5 or later is required.
-CcmSetup failed with error code 0x80004002
Just install Background Intelligent Transfer Service (BITS) 2.5 for Windows Server 2003 (KB923845) to solve the issue. The hotfix can be found on the following location: Download Center
After that install the ConfigMgr client will be fine.
During a ConfigMgr 2007 distribution point migration IIS must be installed (if it isn't installed yet) and content can be converted. Because of IIS installation (which ConfigMgr will do for you, if you select this in the wizard) a restart may be triggered. In my case an unexpected restart was done on a Windows Server 2008 R2 system. This because of an "unknown" MSI installation. As far as I can see only the "Remote Differential Compression" (RDC) feature is installed and the "Microsoft Visual C++ 2010 x64 redistributable".
When distribution points are not "eligible for upgrade", which they were in my case, just make sure no other roles (eg PXE service point) then distribution point are installed. Just make sure there is enough available disk space also - need 100% free space in order to carry out conversion to ConfigMgr 2012 content library. When removing PXE service point, clean up disk space, and wait a while (or reboot the server), distribution points are finally eligible for upgrade.
Source: Microsoft TechNet
When looking in SMS_DP$\SMS\BIN\vcredist.log-MSI_vc_red.msi on the server the following lines are displayed:
MSI (s) (68:4C) [10:55:25:452]: Note: 1: 1707 MSI (s) (68:4C) [10:55:25:452]: Product: Microsoft Visual C++ 2010 x64 Redistributable - 10.0.40219 -- Installation completed successfully.
MSI (s) (68:4C) [10:55:25:452]: Windows Installer installed the product. Product Name: Microsoft Visual C++ 2010 x64 Redistributable - 10.0.40219. Product Version: 10.0.40219. Product Language: 0. Manufacturer: Microsoft Corporation. Installation success or error status: 0.
MSI (s) (68:4C) [10:55:25:452]: Value of RebootAction property is MSI (s) (68:4C) [10:55:25:452]: Windows Installer requires a system restart. Product Name: Microsoft Visual C++ 2010 x64 Redistributable - 10.0.40219. Product Version: 10.0.40219. Product Language: 0. Manufacturer: Microsoft Corporation. Type of System Restart: 2. Reason for Restart: 1.
MSI (s) (68:4C) [10:55:25:452]: Product: Microsoft Visual C++ 2010 x64 Redistributable - 10.0.40219. Restart required. The installation or update for the product required a restart for all changes to take effect. The restart was deferred to a later time.
MSI (s) (68:4C) [10:55:25:468]: Deferring clean up of packages/files, if any exist MSI (s) (68:4C) [10:55:25:468]: MainEngineThread is returning 3010 MSI (s) (68:34) [10:55:25:468]: RESTART MANAGER: Session closed.
MSI (s) (68:34) [10:55:25:468]: No System Restore sequence number for this installation.
When looking in Event Viewer the server is rebooted a second afterwards (on 10:55:26 exactly):
The process f:\06ce98a1da047515c72afeca1f47e3\Setup.exe (########) has initiated the restart of computer ######## on behalf of user ######## for the following reason: Other (Planned) Reason Code: 0x80000000 Shutdown Type: restart
So yes, "Microsoft Visual C++ 2010 x64 redistributable" did need a restart, and your server will be down for a few moments.
Furthermore Microsoft TechNet mentions that the ConfigMgr 2007 client must be removed on Branch distribution points only. During migration on a Standard distribution point however the following message is displayed "Failed to update binaries". After removing the ConfigMgr 2007 client, converting content was done successfully without any problem. When migrating packages is done, the following message is displayed: "Completed reassign distribution point". So next time, I will remove the ConfigMgr 2007 client on Standard distribution points before migration also.
Be aware that only packages which are migrated to ConfigMgr 2012 will be converted to the SCCMContentLib folder. Other old packages will still be left in the old package share folder and can be removed afterwards manually. Just make sure that packages migrated does not have the "Copy the content in this package to a package share on distribution points" have selected in properties. Otherwise they will be on your new ConfigMgr 2012 server in package share folder also. After that you will have new distribution points running!
Source: Microsoft TechNet
