Cumulative Updates to Config Manager and Your Clients

When Microsoft release a major upgrade or release to Config Manager 2012, the rollout of the client update is fairly straightforward. Major releases et al result in a change to the base site wide client version. if you’re lucky enough to have a bit of a free rein, and enforce client installation via the Software Update Based approach:

su_based

Cha Ching… tick the boxes and your published version matches the available version. Time for a tea break.

I love this approach. Any non-managed domain PCs that have lax support staff not installing the client get it rammed hard via the Windows Update interface.

However, this won’t work for a cumulative update (CU). Even if you install the CU, the available version in the above window will not reflect the minor update.

A harsh mistress, no less.

A harsh mistress, no less.

Very, very irritating.

So how to deploy the client? Well the minor versions do generally come with packages that get parachuted into your Software Library. You can then deploy these, but let’s face it, it’s always messy having to patch post deployment.

True, you use the MSI property to specify the UNC location of the patch MSP file, and then hit your site with a client push. However if you have an environment that is blessed with a flakey network and/or DNS, sometimes the client install will inexplicably fail due to its inability to resolve the UNC path.

Of course the FSP reins supreme here, as you can catch those install failures… you did configure a FSP, yeah? xD

Anyway, I poo poo’d that approach too. Then I recalled the notion of adding a folder called clientpatch, to the client source. This is admittedly an unsupported method of deploying the CU, but that was down to complications with Config Manager 2007.

We created the folder under the x86 client architecture as a test, as most PCs are running a x64 OS so any problems would be extremely minimal. The result? The client install process subsequently took the “slipstreamed” CU as part of the install.

Just make sure you use the correct .MSP xD

Just make sure you use the correct .MSP xD

The client source folder is generally located in the Config Manager install folder, as per the above screenshot. You will most likely need to create the clientpatch folder yourself under the relevant architecture folder.

Don’t forget to redistribute your Config Manager package, or the change(s) you have made with the ClientPatch folder won’t have any affect!

I tried a client push on a small group of PCs, and:

Dance off, Bro. IT'S ON.

Dance off, Bro. IT’S ON.

The highlighted lines clearly show the detection, and intent to install the CU3 at the point of client delivery. No messing about waiting for subsequent application deployments to bring the client minor version up.

I have subsequently tested the Software Update Based Client Install, and this too slipstreamed in the CU3 update.

Just bear in mind that this is most likely to be publicly frowned upon by Microsoft. Caveat emptor and all that šŸ˜‰

Advertisements

4 thoughts on “Cumulative Updates to Config Manager and Your Clients

  1. Pingback: Upgrading to Config Manager R2 CU4 | Confessions of a Config Manager Engineer

  2. Pingback: SCCM 2012 R2 CU5 | Confessions of a Config Manager Engineer

  3. Pingback: Automatic Client Upgrade | Confessions of a Config Manager Engineer

  4. Pingback: Config Manager 2012 SP2 CU1 et al | Confessions of a Config Manager Engineer

Flame on xD

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s