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.
- 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.
- sms collections refresh once a day. this means that client may not fall into the right collection on the same day, same hour, etc.
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.
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)
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).