Skip to main content

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).

Comments

Popular posts from this blog

using preloadpkgonsite.exe to stage compressed copies to child site distribution points

UPDATE: john marcum sent me a kind email to let me know about a problem he ran into with preloadpkgonsite.exe in the new SCCM Toolkit V2 where under certain conditions, packages will not uncompress.  if you are using the v2 toolkit, PLEASE read this blog post before proceeding.   here’s a scenario that came up on the mssms@lists.myitforum.com mailing list. when confronted with a situation of large packages and wan links, it’s generally best to get the data to the other location without going over the wire. in this case, 75gb. :/ the “how” you get the files there is really not the most important thing to worry about. once they’re there and moved to the appropriate location, preloadpkgonsite.exe is required to install the compressed source files. once done, a status message goes back to the parent server which should stop the upstream server from copying the package source files over the wan to the child site. anyway, if it’s a relatively small amount of packages, you can

How to Identify Applications Using Your Domain Controller

Problem Everyone has been through it. We've all had to retire or replace a domain controller at some point in our checkered collective experiences. While AD provides very intelligent high availability, some applications are just plain dumb. They do not observe site awareness or participate in locating a domain controller. All they want is the name or IP of one domain controller which gets hardcoded in a configuration file somewhere, deeply embedded in some file folder or setting that you are never going to find. How do you look at a DC and decide which applications might be doing it? Packet trace? Logs? Shut it down and wait for screaming? It seems very tedious and nearly impossible. Potential Solution Obviously I wouldn't even bother posting this if I hadn't run across something interesting. :) I ran across something in draftcalled Domain Controller Isolation. Since it's in draft, I don't know that it's published yet. HOWEVER, the concept is based off

sccm: content hash fails to match

back in 2008, I wrote up a little thing about how distribution manager fails to send a package to a distribution point . even though a lot of what I wrote that for was the failure of packages to get delivered to child sites, the result was pretty much the same. when the client tries to run the advertisement with an old package, the result was a failure because of content mismatch. I went through an ordeal recently capturing these exact kinds of failures and corrected quite a number of problems with these packages. the resulting blog post is my effort to capture how these problems were resolved. if nothing else, it's a basic checklist of things you can use.   DETECTION status messages take a look at your status messages. this has to be the easiest way to determine where these problems exist. unfortunately, it requires that a client is already experiencing problems. there are client logs you can examine as well such as cas, but I wasn't even sure I was going to have enough m