Time to finally transfer my notes from three 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:

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:

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.