Configuration Manager Client Push include Cumulative Update

April 29, 2015

Hi everyone,

I’ve always been wondering how it’s possible to easily include the latest Cumulative Updates with for example the Configuration Manager client push from the console.

A colleague of mine came up with an elegant solution, in this post I’ll describe shortly how the Cumulative Update can be included in the client push mechanism.

The latest Cumulative Update (CU4 for Configuration Manager 2012 R2) can be downloaded here: 

After installing the CU on the Primary Site Server there is an extra folder created under the installation folder on the Configuration Manager site server, this folder is called hotfix and it contains some automatically created folders visible in the below screenshot


In this post I’ll be focusing on the Client folder which contains 2 subfolders, one for the i386 patch and one for the x64 patch.

I’ll start with the x64 patch, copy the msp file from the directory Client\x64.

Browse to the source of the client package that is used for client push. By default this is the path \\[FQDN Primary Site Server]\SMS_[SiteCode]\Client. There again you have 2 folders (i386 en x64). In the x64 folder create a folder named “ClientPatch” and copy the msp file into this folder.

For the i386 msp file repeat the previous steps and copy the other msp file to the “ClientPatch” folder in the i386 folder

The structure of the client package should look similar like this:


After the necessary files and folders are added make sure you update the package on the distribution points so the next time a client push is done the most recent files are used. All content located in the “ClientPatch” subfolders will be automatically installed.

The ccmsetup.log on the client should show extra info about the update being installed. Also an extra log is created, in this case called: “configmgr2012ac-r2-kb3026739-x64.msp”


In the future, when new CU’s are released simply follow the same procedure and replace the “old” msp-files with the “new” ones.

Extra benefit: When using the same package in your task sequences, the CU will also be applied automatically, without extra parameters. So after the task sequence has completed the client will be on the latest CU without having to update afterwards.

Hope this helps!

Best regards,




SCCM2012 Firewall issues

November 29, 2012

Today we share 2 things about communication between site systems in a 2012 site.

  1. SCCM Client push

In order to perform a succesfull client push there are a number of ports that need to be opened. See SCCM help file.

Now there are alternative methods like group policy or script installation that do not need RPC and SMB, but the ability to deploy and redeploy from the sccm console is very usefull.

Now I had some doubt about the RPC and SMB communication needed to be bi-directional or not. So I tested using the local Windows firewall.
No firewall restriction on server OSE, goal was to find out if traffic was bidirectional so all outbound communication from the client was blocked.

Performed Client Push. First part ok service started but error while trying to download Client sources.

So I added only HTTP communication to the firewall from client to Site Server.

And sucess Client deployment works.

So communication is one way from site server to Client. Only http ( TCP 80 ) is required from client to Site server for client push.

Update : in a production environment this has proven to be wrong rpc communication is bi-directional between site server and client.

  1. Rpc communication between site server and site components

By default communication between site server and site components ( SUP, SMP, DP ) uses RPC over dynamic ports. Now we have the option for setting the communication one way from site server to site component by using the option “Require the site server to initiate connections to this site system” but it might be usefull to limit the number of RPC ports being used.
Here’s how :
First in order to find out how may dynamic ports are in use now you can use rpcdump.exe ( part of 2003 resource kit tools ). On my system this was 152 ports.

Now let’s check the default range on our system using netsh.

Now the plan was to create a port range of 255 ( minimum allowed ) from 5001 to 5256.
Use the following command : netsh int ipv4 set dynamicport tcp start=5001 num= 255

Restart the server.
Verify result


update : in a production environment this has lead to not enough rpc ports available on the site server. Numerous issues occurred like loosing ad connectivity. After setting the rpc to default the issues no longer occurred.