sms: installing itmu updates out-of-band

i was on a field visit recently and came across an interesting dilemma.  the administrators i worked with indicated that the turnaround time on a newly imaged machine would be somewhere in the neighborhood of 48 hours.  this was something that i couldn't get my mind to engage.  if the image process itself took an hour or so, throw in a few minutes to unpack it, set it up, connect it, pop the disc in and run it, etc... why was it taking 48 hours or longer?

well, it seemed that our antiquated imaging process caused delays of up to 48 hours before a newly imaged machine would receive all the required security updates. rather than using something like going to windows update, the administrators chose to let the process work through on its own.  looking into this, our problems were created by a couple of things that could easily be addressed.

1. sms client installation script is only available as a machine startup gpo. this requires the machine to be rebooted twice. it had to receive the policy (naturally) and then execute it.
2. sms collections refresh once a day. this means that client may not fall into the right collection on the same day, same hour, etc.

there are no real issues with bullet #1. it's the way things work. the client has to receive the policy first. in order to apply it though, it has to reboot. :/ that kind of sucks and slows things way down. ad discovery (and subsequent installation) happens nightly, which means, if a machine is imaged that morning, it won't get the client until that evening if it just sits there.  in this particular case, logon scripts aren't used so that's ruled out.  as i mentioned before, the admins just let it sit there... so clearly it was the overnight discovery and installation that catches the machine.

bullet #2 is interesting. if you increase your schedule cycle for the particular collection, that'll definitely speed things up. still, there's a balance you have to meet to make sure you're not running sql statements over and over just to make sure new machines coming up get things immediately. the really unfortunate part about this is that you have to wait for bullet #1 to occur first. :)  so let's say the machine was imaged at 8am, it receives the client at 1am, the collection refreshes at 6pm, and the client is done... somewhere around 7pm.  so, the theory of 48 hours seems about accurate.

there's lots of ways to get around this problem. you could speed up collection schedules and put the client into the image. you could create local policies that mirror advertisements and compile them on the client locally. for fun, i wanted to see how this was being done by other folks. i received some great input from the myitforum mailing list and ended up going with this idea from greg smith called "installing itmu updates on demand". this is great work. basically, greg created a script to run through a patch installation cycle, without calling patchinstall.exe.

there were some things in the script that just didn't work for my environment so i created another script to run prior to it. it handles the following things:

• from a list of package ids, it extracts the actual smspkgx$ locations.
• installs windows update agent, if required.
• installs sms client, if required.
• runs scanwrapper.
• installs any required patches.

the sms client installation does a bit of goofiness with how it downloads the .msi and runs everything in the background. in order to make sure the script didn't launch anything prior to the installation being complete, i put a loop in to check for the smssoftwaredistribution component. that did the trick...

all of the heavy lifting was in the installdsuwupdates.vbs script that i mentioned before (by greg smith). this is just my little wrapper that makes things work a little better for me. :) if you want to use my method, you'll need to update the following values in sms_update.vbs:

• sSMSServer - your server name
• sWUA = package id for windows update agent
• sITMU = package id for ITMU patches
• sSCAN = package id for ITMU scanner (scanwrapper)

after that, you should be good to go. one thing to note, in the installdsuwupdates.vbs file, there is a line that looks like this: szXML = szBase & "PatchAuthorize.xml". you can change the .xml filename to whatever you use in your organization. for instance, we have a cumulative update with a different name to install everything. great one to use for patching up one-off like this.

have fun! you can get the files here. it contains my script and an updated installdsuwupdates.vbs script (to handle a few things i'm sending to it).