Tag Archives: Config Manager Client Upgrade

WSUS Boot-Strapper Error

Following a client upgrade, I did notice a niggle with one of Config Manager’s Components:

So fustrating at times... the error doesn't really tell what the real issue is.

So frustrating at times… the error doesn’t really tell what the real issue is.

A constant stream of:

WSUS Configuration Manager failed to publish client boot-strapper package

So basically something is wrong, but there were no details to give me a definitive direction. I delved into the logs, and headed straight for the WSUS logs. I opened the WCM.log, and although nothing was flagged in red, I did find some interesting text:

Continue reading


Config Manager 2012 SP2 CU1 et al

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


Another fine mess.

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″>

Continue reading

Automatic Client Upgrade

With the advent of 5.00.8239.1000, the site had a major build upgrade (as opposed to a minor build change a la hotfix) and yet another client update to rollout. Normally I would do a client push and slipstream in the client MSI using the clientpatch hack here.

Quite frankly, I was getting a bit tired of pushing the client over the course of a month 😀

So I decided to investigate something that had been bugging me for a while: Automatic Client Upgrade, and why the option was greyed out to enable it was greyed out.

I believe this is a new, as in new to Config Manager 2012, option. We still have the tradition client deployment options either as an automated Client Push or as a Software Update based installation:

Old skool Config Manager!

Old skool Config Manager!

Continue reading

SCCM 2012 R2 CU5

Short but sweet…

System Centre COnfiguration Manager 2012 R2 CU5 has been released, and it is rather delicious! For me personally, it allegedly addresses an issue I have ben seeing, and in fact, quite possibly made Microsoft aware of via TechNet and our Microsoft Support Partner. Specifically:

Software distribution fails when the client cache is full and virtual applications have been deployed.

Errors that resemble the following are recorded in the Cas.log file on the client:

  • IsCacheCopyNeeded returned ‘true’ by {content id}

Continue reading

Upgrading to Config Manager R2 CU4

We’ve been having a few oddities of late, especially with our DPs. I was starting to think some of this was down to the migration to HTTPS. I was loathe to consider it, as I am very much attached to the work that I did. Plus, I just think that HTTPS is cool.

Anyway, it suddenly dawned upon me that Cumulative Update 4 was available. I was not terribly keen to look at it, as I am still rolling out the CU3 client. However my jaw dropped when i saw the fix list on the Microsoft page. Basically, if you have applied CU3, then you’d be crackers not to apply CU4. It fixes a lot of stuff CU3 broke.

Continue reading

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:


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 😉