Config Manager 2012 SP2 CU1 et al

So we upgraded to CU1 (KB3074857), and applied the following hofixes:

KB3082531
KB3084586
KB3089193

Another fine mess.

All looked ticketyboo, however when testing the client, I received the following error when attempting to uninstall the Config Manager client:

<![LOG[Failed to load mdmregistration.dll with error 0x8007007e]LOG]!><time=”14:49:36.523+00″ date=”11-03-2015″ component=”ccmsetup” context=”” type=”3″ thread=”5224″ file=”mdmreg.h:78″>

Now where did this come from?

Hmmm…

So I started doing some digging. I found that there was now a new folder called ClientUpdate, under the Config Manager directory. Inside here was the post CU1 hotfix KB3082531. It looks like Microsoft have dfecided to reintriduce the ClientPatch trick (blogged here), as part of the improvements to the Automatic Client Upgrade feature (blogged here).

This is documented… where?

However it just doesn’t seem to work right for us.

Now, to clarify, following the upgrade to R2 (or SP2, depending upon how you butter your bread), I dumped everything from the ClientPatch folder as it was now redundant. There is no leftover mess from allegedly non-supported techniques to be interfering here; /movealong.

I found that the clients were still rolling out as the R2 base version 5.0.8239.1000, and then the ACU was scheduling an upgrade to KB3074857 (CU1 v.1203), and scheduling ANOTHER upgrade to KB3082531 (Hotfix v.1211). When you then factor in a randomised timescale of around seven days a pop… well… ***ing **** doesn’t begin to even cover it.

So I slipped the CU1 update and the other clientside KB3082531 into the ClientPatch folder. As expected, a client push resulted in the client applying both update and hotfix in one seamless go. The client version correctly reported 5.0.8239.1211.

However then the Automatic Client Upgrade function decided to schedule an “upgrade” back to to 5.0.8239.1203; I manually triggered the scheduled task and the clean install was then dumped in a hail of errors. Derp.

I had my test client ping ponging all over the place. Needless to say, I’ve now disabled the Automatic Client Upgrade, and dumped the “new” ClientUpgrade folder.

The result? By falling back to an established deployment methodology, my test client is now working as expected… I just have to resort to doing a site wide push the old fashioned way. On an additional plus, the issues with scheduled Automatic Upgrades (blogged here) will no longer be clogging up my Fallback Status Point either.

Bleh… the old ways are sometimes the best ways.

So, bye bye Automatic Client Upgrade. It wasn’t particularly nice knowing you.