Since the release of System Center 2012 R2 there have been (to date) 3 Cumulative Updates which if you wish to keep your clients upto date will need deploying into your ConfigMgr hierarchy.

During the OSD Process the most common place you will see this is below:

This can sometimes be problematic and prone to issues however there is another way…………

Note * The below has not had an official stamp off from Microsoft so please test and use at your own risk however this has worked since 2007 and I have not experienced any known issues.

After completing the installation of the CU on your site Server you will have the hotfix files placed in the following area:

\\[Site Server\SMS_[Site Code]\hotfix\[Hotfix KB]

Within the directory will be the packages you have decided to install.

If you drill into the ‘Client\[Platform]’ directory you will find the .MSP file in this case CU3 for ConfigMgr 2012 R2

Launch a new explorer Window to where the package for you ConfigMgr Client is (Default = \\[Site Server]\SMS_[SMS Site Code]\Client

Within this directory are the x64 and i386 folders respectivly.

For the example, drill into the i386 Folder and create a ‘ClientPatch’ Folder in this directory:

Now copy the MSP into this directory

Repeat this for the x64 directory ensuring you copy the right MSP into the right folder!

Simply update the package for your ConfigMgr Client Agent and your good to go 🙂

Note* – It may be worth performing the last action out of hours as it may interupt a newly initiated build process!

Microsoft have now released CU3 for ConfigMgr 2012 R2 and further details can be found from the following link

http://support.microsoft.com/kb/2994331/

The key update is the option for a workaround to the MP rotation cycle via a registry value

With the ease at which ConfigMgr 2012 makes slipstreaming updates into an Image, that is both faster and negates the need for a technician VM it is hard going back to 2007 when updates are required to layer on top of a core WIM.

Since Microsoft did not release SP2 of Windows 7, anyone who has tried to keep a pure gold vanilla build (essentially a Win 7 CD) and layer updates on top would have hit the max 87 updates threshold for the step in the Task Sequence a long time ago so you need to be creative with how you reach your end goal.

One Option I have used when on client site with a GOLD WIM full of apps etc and no build and capture insight and miles out of compliance with updates is the method below:

1) Create a Software Update Package with all the updates you would like to inject into the WIM.

2) Once the updates have been downloaded copy the entire contents of the package down onto a technician PC. The updates will look something like the below:

3) With these on your reference machine, inside each of these folders are .cab files for the updates. I extracted these into 2 folders x86 & x64 and then removed the other folders.
Example below:

I then proceeded to create a folder structure including the WIM I wanted to mount and inject along with the update directories as shown below (as you can seem the client has created a VERY LARGE core WIM!):

With all this in place you can then use the below Powershell script to add in all of your updates.

*Note – Save the file as a .ps1 with your other items for cleanliness!
**Note – Items highlighted will depend on your environment so ensure you adjust as necessary

***CODE START***
$UpdatesPath = “C:\WIM\Patches\x86\*”
$MountPath = “C:\WIM\Mount”
$WimFile = “C:\WIM\Win7office2010 BaseBuild.wim”
DISM /Mount-Wim /WimFile:$WimFile /index:2 /Mountdir:$MountPath
$UpdateArray = Get-Item $UpdatesPath
ForEach ($Updates in $UpdateArray)
{
DISM /image:$MountPath /Add-Package /Packagepath:$Updates
Start-Sleep –s 10
}
Write-Host “Updates Applied to WIM”
DISM /Unmount-Wim /Mountdir:$MountPath /commit
DISM /Cleanup-Wim
***CODE END***

Run this from an elevated powershell Window and you should see it cycle through the updates:

The progress can also be monitored from the DISM Log – C:\Windows\Logs\DISM\Dism.log

Every seen this before?????

Fairly common issue when you have an unsuspecting GPO in your environment taking some precendence over ConfigMgr. Well what if you dont have one????

Working on a piece of work for a client who had around 3% of their clients reporting as ‘Compliance Unknown’ and this error was reported in WUAHandler.log

After ruling out anything to do with ConfigMgr and a Group Policy applying it turned out that there was a ‘jammed’ GPO policy on the end client which was resolved by deleting the following file:

C:\Windows\System32\GroupPolicy\Machine\Registry.pol

As this was a machine setting after this was cleared and the machine restarted to force a policy update from a DC, the next time a Software Update Scan was initiated the Software update cycle began and on the Software Evaluation cycle the updates began to install!