So the company I work for is always on the bleeding edge of new SCCM technology, we are in every TAP etc. As such my most recent challenge was the task of deploying the SCCM R3 Beta Client hotfix - KB977384.
Feeling flush with the success of my Adobe patching efforts I thought why not use SCUP and deploy the hotfix as an update. Now there have been a couple of posts suggesting that you approach the hotfix deployment by using the more traditional software distribution methods - You can find them here:
http://blogs.msdn.com/b/shitanshu/archive/2010/05/04/part-1-configuration-manager-r3-beta-deployment-in-microsoft-it.aspx
http://scug.be/blogs/sccm/archive/2010/05/14/sccm-2007-r3-beta-refresh-installation-howto.aspx
http://fabien-lange.blogspot.com/2010/04/be-green-with-sccm-2007-r3-power.html
And a teammate of mine was pretty certain that an attempt to deploy using SCUP/SUM/WSUS would result in a spectacular failure. His reasoning was that in order to apply the hotfix the ccm service must be stopped and restarted.
But I felt pretty feisty and since I knew windows update agent actually does most of the heavy lifting during a software update deployment I was confident this deployment method would succeed.
Which it did and I was awarded a Thor for my efforts :) There was a little bit of complaining in the windowsupdate.log as the Windows Update Agent tried to report back to SCCM Client on its status but as soon as the SCCM client service restarted everything was fine.
So its pretty easy to create this update in SCUP. The hotfix comes in msp flavor which is the most preferred (IMHO) type of update binary. The logic for applicability is built into the msp - Its not going to apply if its not applicable. In this case the update will only apply to SCCM Client Agents at SP2 (4.00.6487.2000).
So here's how I did it:
NOTE: A word about Classifications - DON'T use the Classification type of hotfix. This is the only classification type which will not be visible in SCCM.
First lets keep things tidy shall we - Add a vendor and call it Microsoft Custom Updates. Then create a product called System Center Configuration Manager.
Now you can create your update
Update information - I've highlighted the areas you'll need to complete in the screenshot below - Use a classification type of Updates (see note above). I'm trying to spare you some of my pain.
Extended properties - I used the KB article ID for both Bulletin ID (screenshot above) and for the Article ID as well - This just makes is easier to view and sort once the update makes it into SCCM - Also you'll need the more info URL - I used once of the links from blog posts above as MS has not officially published the KB yet as R3 is still in Beta. Your company may want you to use an internal Help Desk page or something else - Its your choice. Impact is not really all that important. Reboot behavior doesnt really do anything either but as best practice I generally select never reboots - your deployment properties as well as the return codes for your binary will drive the reboot behavior.
Prerequisite Rules - KISS (Keep it Simple Stupid) - Remember these are high level rules which will instruct windows updates to even bother scanning the system for this update. Leave the fancy detection logic to the applicability rule. In the example below I used the Basic Rule for processor architecture and included both x86 and x64 - The SCCM Client Agent is still only 32bit but I do want this applied to both 32bit and 64bit systems.
Select package - Here comes the fun part and the main reason I prefer msp installer types over other installer types
Notice when you create a brand new update you have Applicability Rules and Installed rules listed in the left frame - Now take a close look at my screenshot examples above - yep that's right - If your msp is properly engineered you don't have to worry about defining either one of those rules for your update - See why I like msp's.......
OK So back to our package selection - You'll need to select the installer type and provide locations - I've provided a recommended command line parameters you may want to pass along as well - Just a quick note here the GUI is limited to 100 characters BUT you can pass longer command line parameters is required - Look for a future blog post on the how-to for that (that's a teaser folks.....).
Command Line: REINSTALL=ALL REINSTALLMODE=mous FSP=yourfsp.fqdn.com SMSSLP=yourslp.fqdn.com
I was a bit surprised about adding the FSP to the command line but this is an extract from the first blog post on deploying R3-Beta -
Note: Based on implementation experience, ensure that FSP command line is appended to the installation parameters of R3 hotfix deployments and SLP name as missing FSP parameter in command line would remove existing FSP entries from the clients.
Alrighty then!
Click through the remaining wizard windows and your DONE!!!!!
Then its simply a matter of PUBLISHING - SYNCHRONIZING - DOWNLOADING & finally DEPLOYING :)
BTW - You don't need to be all that fancy about your target collection when deploying either - If the client is not SCCM SP2 the update will scan as not applicable.
This should be a workable approach for any RTM code that's forthcoming as well but Ill post a follow-up once that code is released. And you should be able to leverage this for other hotfixes you might feel the need to deploy as well.