Recently I was troubleshooting an environment where Windows 10 upgrades didn't came in. I did check if hotfixes were installed, which was the situation indeed.
-KB3095113: Update to enable WSUS support for Windows 10 feature upgrades (Server 2012 and 2012R2)
-KB3127032: Windows 10 upgrades are not downloaded in System Center Configuration Manager (CM1511 only)
I decided to remove the Upgrade checkbox, too put it on at later time. Then a new pop-up was displayed: Additionally, to service Windows 10 Version 1607 and later, you must install and configure KB3159706 using the guidance. Oops, I missed that one! Installed it a the WSUS/SUP and other Site server(s) and did have a look at additional steps too. This because of the following post on Microsoft TechNet: WSUS Breaks after KB3159706, released 5/5/2016
It mentions: Manual steps required to complete the installation of this update:
1. Install the hotfix and restart the WSUS/SUP server!
2. Open an elevated Command Prompt window, and run "C:\Program Files\Update Services\Tools\wsusutil.exe postinstall /servicing" (case sensitive)
3. Select HTTP Activation under .NET Framework 4.5 Features in the Server Manager Add Roles and Features wizard.
4. Restart the WSUS service.
I skipped steps mentioned on "If SSL is enabled on the WSUS server" at first try, but they seems to be needed too!
1.Open an elevated Command Prompt window, and assign ownership of the Web.Config file to the administrators group
-takeown /f web.config /a
-icacls "C:\Program Files\Update Services\WebServices\ClientWebService\Web.config" /grant administrators:f
2. Make the following changes in the file > add the lines displayed in bold, don't make the mistake (as me) to replace those lines!
3. Add the multipleSiteBindingsEnabled="true" attribute to the bottom of the Web.Config file
4. Restart the WSUS service.
Start a Software Update sync in ConfigMgr and watch wsyncmgr.log and WCM.log closely. Everything should be fine now!
Didn't see Windows 10 Servicing working yet, but hope too see it in near future. On Microsoft Ignite there was no session or demo about it too, given the fact that it may be working.
Will be continued in a next blogpost :-)
Recently (May 27, 2016) for ConfigMgr Current Branch (1602) is released, also known as KB3155482. It fixes multiple issues on both ConfigMgr and Microsoft Intune. It cannot be downloaded, but will be available in the ConfigMgr console instead.
Here's a list of issues that are fixed:
-Remote Control (1x)
-Site Systems (1x)
-Microsoft Intune and mobile device management (5x)
As you can see it fixes mostly Intune (MDM) parts. When not using Intune, just wait for build 1606 coming soon.
This hotfix is available for installation in the Updates and Servicing node of the ConfigMgr console. If the service connection point is in offline mode, you have to re-import the update so that it is listed in the ConfigMgr console.
For more information on the update have a look here:
Microsoft Support
Hopefully the ConfigMgr certificate issue is solved now too!
During deployment in ConfigMgr, you can install the ConfigMgr Client Cumulative Update immediately. There are multiple posts found where the PATCH= parameter is used. The Cumulative Update needs to be in a package or reference image (included for installation) for this. I see lots of times the PATCH= parameter is skipped, for different reasons. Let's have a look at another way to install the Cumulative Update. This one is not hard at all. It just works :-)
Just create ClientPatch folders in both ConfigMgr Client locations:
-Program Files\Microsoft Configuration Manager\Client\x64
-Program Files\Microsoft Configuration Manager\Client\i386
and copy the appropriate architecture (x64 and/or i386) from your hotfix to one of this folders. Do not forget to update your ConfigMgr Client Package to be sure using the Files with the Hotfixes.
That's it! No PATCH= parameter needed at all. It did work on my first try (CU4), so very easy to use if you ask me :-)
When using Client Push Installation it will be helpfull either. No need to apply the CU client update afterwards. It will be detected automatically:
-Detected 1 client patch files. Will apply them after client installation.
-Adding file 'configmgr2012ac-r2-kb3026739-x64.msp' to BITS job, saving as 'C:\Windows\ccmsetup\configmgr2012ac-r2-kb3026739-x64.msp'.
-C:\Windows\ccmsetup\configmgr2012ac-r2-kb3026739-x64.msp is Microsoft trusted.
-File C:\Windows\ccmsetup\configmgr2012ac-r2-kb3026739-x64.msp installation succeeded.
-Params to send FSP message '5.0.7958.1501 Deployment [DP]
Why this is a hidden/undocumented feature suprised me.
Can't be easier if you ask me :-)
Source: SCCMfaq.ch
Source: Systems Management and Automation
Update 6-7:
@jarwidmark - That method works for some, breaks for some, but either way, it is totally unsupported by Microsoft.
@rsjulsen - This method has totally worked for me :) But ofc.. Totally unsupported.. and totally, totally awsome :)
Update 24-8:
With Cumulative Update 1 for ConfigMgr 2012 R2 SP1 and 2012 SP2 this isn't needed anymore. Source: Automatically updating the Configuration Manager client
Last month a new ConfigMgr hotfix became available, specific for Mobile Device Management devices in Microsoft Intune. This hotfix greatly reduces the time that's required to execute a successful retire or wipe of an MDM device by using a notification to "push" these tasks. Without this hotfix, retire and wipe operations could require 24 hours to run successfully, because they relied on a "pull" mechanism of this frequency. This happens with me on installations also, where retirement could require 24 hours of even more!
After you apply this hotfix, retire and wipe operations are pushed to the following MDM device types: iOS, Android, Windows 8.1
These operations now run on the device in a matter of seconds, assuming the device is reachable by Microsoft Intune. The device must have an active data connection for Intune to communicate with it. Just great that this ConfigMgr Hotfix speeds up retire and wipe operations to seconds!
Note: If a device is not reachable by Intune when a retire or wipe operation is requested, the operation will run the next time that the device comes online and connects with the Intune service. This could require up to 24 hours.
To apply this hotfix, you must have Cumulative Update 3 for ConfigMgr 2012 R2 installed.
Download hotfix: Microsoft Support
Yesterday a new ConfigMgr 2012 R2 Policy Hotfix is released. This because Per-computer task sequence variables that are defined for imported computers are filtered out of client policies. This prevents the variables from being read during task sequence execution. This problem does not affect per-computer variables that are defined for existing clients.
This update applies only to Primary sites.
Important Per-computer task sequence variables have to be recreated if they were created after System Center 2012 R2 Configuration Manager was installed but before this update is applied.
You can download the Hotfix here: Microsoft Support
A few days ago a new ConfigMgr 2012 R2 OSD Hotfix is released. This because many customers couldn't PXE boot anymore. Have a look at these forums for more information about the issue:
Microsoft Technet, Windows Noob & MyITForum
This update resolves the following issues:
Issue 1
After you enable the PXE Service Point role on an instance of a specific distribution point, or you select the Deploy this boot image from the PXE-enabled distribution point property of a boot image, the Windows Deployment Service (WDS) stops running. Additionally, entries that resemble the following are logged in the Windows Application log:
Faulting application name: svchost.exe_WDSServer, version: 6.3.9600.16384, time stamp: 0x5215dfe3
Faulting module name: MSVCR100.dll, version: 10.0.40219.1, time stamp: 0x4d5f034a
Exception code: 0xc0000005
Fault offset: 0x000000000005f61a
Faulting process id: 0xae4
Faulting application start time: 0x01cec5d767184634
Faulting application path: C:\Windows\system32\svchost.exe
Faulting module path: C:\Program Files\Microsoft Configuration Manager\bin\x64\MSVCR100.dll
Note This problem affects only distribution points that are installed on site servers.
Issue 2
When operating system image files are downloaded to Configuration Manager 2012 R2 clients, you may find that the download takes longer than it did in previous versions of Configuration Manager 2012 clients. You may see this behavior when the target client is running Windows PE or a full Windows operating system.
You can download the Hotfix here: Microsoft Support
With ConfigMgr advanced driver management is possible for all kind of devices. Best practice for this is creating driver packages for all different devices, and put them in the Task Sequence used for deployment. With WMI queries you can decide then which driver package will be used on different types of devices.
For more information about that see my other blog: Driver management in ConfigMgr 2007 http://henkhoogendoorn.blogspot.com/2010/10/driver-management-in-configmgr-2007.html
Now drivers are seperated in different driver packages, but what to do with the Drivers folder where all single drivers are placed? For all drivers imported there can be folders created, for dividing different drivers and hardware. Also specific Categories can be created for recognizing drivers and hardware by model. Do the following for that:
As you can see I've imported HP8000 drivers, which has been assigned to a new category. Press Next for importing this drivers in the ConfigMgr database.
All drivers are successfully imported in the ConfigMgr database. Now do it again for a new type device or model.
Now I've imported HP8100 drivers, which has also been assigned to a new category. Press Next again for importing this drivers in the ConfigMgr database.
This time (all) drivers will fail to import in the ConfigMgr database. Why is that? This because drivers can be already existing in the database. Default in ConfigMgr 2007 there can be only 1 instance per driver in the database!
But.. There is a hotfix available for solving that! (kb2213600)
http://support.microsoft.com/kb/2213600
With this hotfix drivers can be multiple times imported in different folders. So I install this hotfix in my environment, and do the same thing as before.
This time all drivers are indeed successfully imported in the ConfigMgr database. Let's have a moment now to look in the ConfigMgr console.
In the ConfigMgr console drivers are seperated now by device and hardware model. This way everyone can see to which device the drivers belongs!
When creating driver packages now, it's easy to see that the structure for driver management is the same in both Drivers and Driver packages. This way advanced driver management is created in the ConfigMgr console!
Once last thing: when deleting older drivers in the ConfigMgr console, this drivers will also be deleted from older folders from different models. To prevent this create an OLD folder, and move the old driver folders (model) beneath the OLD folder.
Also a collegue of mine (Stephan Wibier) has found that when a txt file exist in the driver source folder, this will not happen. Drivers that are the same for different models will then not deleted. This text file must exist in all folders and sub-folders then, for all drivers that are imported. This txt file has named in this example HP8000.txt for the HP8000 driver folders, and HP8100.txt for the HP8100 driver folders.
Hope you learned a lot this way about advanced driver management in ConfigMgr 2007!
Follow us on Twitter:
Henk Hoogendoorn (PQR) @henkhoogendoorn
Stephan Wibier (PQR) @stephanwibier
When installing Configuration Manager 2007 with the Release 3 (R3) update, there must be a Client Hotfix installed first. This hotfix (KB977384) will create a package and program for you, which is handy for updating existing clients. Download location: http://support.microsoft.com/kb/977384
When advertising this client hotfix to systems only it will works fine, but when adding this client hotfix to a Task Sequence for deploying multiple applications it goes wrong. The Task Sequence will simply fails after installing the client hotfix, and installation will stop working.
In the SMSTS.log there will be the following errors seen:
- The sms client service is not running
- Install Software failed, hr=0x80040215
- Failed to run the action: Install <software package>
- Unknown error (Error: 80040215; Source: Unknown)
This because of the following issue:
When installing the client hotfix, it will shutdown the existing ConfigMgr client and WMI. After installation of the new client hotfix, it doesn't look like the ConfigMgr client or WMI service are restarting. Without these essential parts, installation will not working again. This is the reason why the Task Sequence will fail.
Update: Best practice from Microsoft is to not use the hotfix as single step in the task sequence. Just put it in the default "Setup windows and ConfigMgr" step. In the Installation properties box, type the following: PATCH="%_SMSTSMDataPath%\OSD\<var><Package_ID></var>\i386\hotfix\KB977384\SCCM2007AC-SP2-KB977384-x86-enu.msp"
Then installation will continue working.
