ConfigMgrFu

My experience as a technology implementer and user: triumphs, discoveries, and expletives.

News

Ichthus
Configuration Manager Unleashed
Microsoft Most Valuable Professional
Follow Me on Twitter
CatapultSystems
web counter

Blog Roll

Persistent Posts

ConfigMgr Client Hotfix Versioning

imageTime to finally transfer my notes from two big yellow stickies to a blog post.

Basically, while trying to do a build & capture of Windows 7 SP1 recently, I was trying to apply every available (to my knowledge) client hotfix to the ConfigMgr agent. I was using Michael Murgolo’s hotfix script to automatically populate the PATCH property, but was running into all kinds of issues and so dug in to figure out what was going wrong. Note that the issues outlines below are not just present in task sequences but will also manifest if installing hotfixes in other ways also.

Problem #1

The first problem was that the script was relying on the default sort order of the Files property of the Folder object from the FileSystemObject automation object. This means that hotfixes with larger numbers but more digits would sort before hotfixes with smaller number but fewer digits because it was sorting them in normal alphabetic order instead of the desired numerical order; e.g., KB2516517 comes before KB982203 in a normal alpha sort even though 982203 is less than 251617. The presumption here is that hotfixes described in KB articles with larger numbers should always contain later code than those with smaller numbers (as we’ll see in a moment, this isn’t always true though).

To solve this issue, I modified Michael’s script to sort the KBs according to numerical order. Others have also run into this including Mattias Benninge who also modified the script and added a couple of useful features to boot; he posted his version earlier today.

Problem #2

As I stated above though, the sort order only addresses part of the problem. The other problem is the presumption I stated above which (as it turns out) does not hold true in all case because even after using my version of the script I was still getting errors.

Thus, I set forth to figure out what hotfixes install what components. The first place I started was the KB articles themselves which resulted in the following table of update files:

KB

DLL

File Version

977176

smsswd.exe

.2108

977384

Multiple

Multiple

978754

osdcore.dll

.2115

979199

invdatastore.dll

.2120

982203

lsinterface.dll

.2132

2276865

tscore.dll

.2152

2278119

srvwinmgr.dll

.2154

2309968

updatesagent.dll
updatesdeployment.dl

.2176
.2158

2509007

Updateshandler.dll

.2188

2516517

lsinterface.dll

.2177

2536089

AssetAdvisor.dll
VAppCollector.exe

.2184
.2184

Not a whole lot of help there except to confirm that some of the updates do replace the same file.

So, the next step was manually installing each hotfix with verbose logging enabled. In the verbose logs, the specific components and version numbers were listed which revealed a whole lot more as depicted in the following table:

KB

Component

Version

977176

SMSTaskSequence

.2108

977384

CCMFramework
SMSSoftwareDistribution
SMSPowerManagement

.2155
.2154
.2157

978754

SMSOSDeployment

.2115

979199

SMSInventory

.2120

982203

CCMFramework .2132

2276865

SMSTaskSequence

.2152

2278119

SMSSoftwareDistribution

.2154

2309968

SMSSoftwareUpdate

.2176

2509007

SMSSoftwareUpdate

.2188

2516517

CCMFramework
SMSSoftwareDistribution
SMSPowerManagement

.2177
.2160
.2157

2536089

SMSInventory

.2184

Conclusions

There are so many things to draw from these two tables I’m not sure where to begin.

  1. Using the SMSClientVersion is in no way sufficient to judge whether a hotfix is installed. I know I haven’t even mentioned  this property before, but I have seen folks using this property to create queries to determine if a hotfix is installed on their clients or not. Based on the log files, SMSClientVersion is always set to the highest component version installed and thus is only indicative of a single hotfix being installed. Instead you should use the method I outlined previously with the values from the second table above. Even that method has potential problems though because of #3 below.
  2. 982203 does indeed appear to be superseded by 2516517 because they both replace the same file (lsinterface.dll) and increment the CCMFramework component version.
  3. Updating a components version number does not imply supersedance; e.g., 977176 and 2276865 both update the SMSTaskSequence component version but one updates smsswd.exe and the other updates tscore.dll. However, if you try to install 977176 after 2276865 on a client it will fail.
  4. 982203 updates CCMFramework to .2132 but 977384 updates CCMFramework to .2155 so you can’t install 982203 after 977384 however, 977384 doesn’t update lsinterface.dll so it doesn’t actually supersede 982203. (982203 is for NAP though so I don’t this is a very popular hotfix at all and there is a possible workaround to it by just unbinding IPv6 on the fix-up servers).

I’m sure there are other conclusions to draw, but those were the most obvious and relevant to me.

Another side issue I saw during my initial testing was that if I tried to install all of the hotfixes during a task sequence on a VM with 512MB (it might have even been 768, I don’t remember) of memory, the TS would die during the client installation. Once I bumped the RAM up to 1GB, everything went smoothly.

Recommendations

Don’t install every client hotfix just for fun.

Because the client gets reinstalled during deployment TSes anyway, the only hotfix really needed during a build and capture is 2509007 although I can see also putting 977384 in there because it is a bigger and more impactful hotfix.

Use Michael's script if you are only installing a couple of hotfixes during the TS and don’t see any conflicts based on the info above.

Use Matt’s script if you are installing more than a few hotfixes and will have a conflict (because of the sort order) based on the above info.

If you need 982203, you may have to hardcode the PATCH property to ensure the proper order or modify one of the two scripts to get the desired order. Alternatively, use 2516517 as it appears to supersede 982203.

One issue that I see with both scripts is that simply installing a hotfix on the site server, creating the hotfix package, and updating your client install package will immediately cause the hotfix to be part of any of your task sequences. This could be dangerous or bad for a variety of reasons. Be aware of this. The best work-around to this is to create a separate package that contains the hotfixes you want to deploy and the script. Both scripts look in certain sub-directories so make sure the package has the proper structure. Then, reference this package in the TS instead of the client install package.

Test, test, test.

Comments

No Comments