Day Four: SMS success!

Maybe SMS success is an oxymoron. My current measure of success is not breaking the existing infrastructure. Deploying a package is just extra icing on the cake.

One thing I forgot to mention is that just before we left on Friday we did create a test collection with two test machines. Then we created the test advertisement and crossed our fingers.

Monday was a holiday for us. So today was our first chance to see if the patch deployed. I came in, checked my test machine and there was our custom made post patch reboot message. Firing up the SMS console revealed that the packages ran successfully (not that I expected anything less).

The best way (that I’ve found) to figure out if your packages ran on a test group is to open up the console, expand the Site Database>System Status>Advertisement Status. Select the advertisement you’re interested in checking. Then in the right pane you can see the how many clients received the package, how many started it, success, failures, etc. If you want to get really detailed you can right click on your site>show messages>all. I usually only need to look at the last day or two but you can go back further if you need to. The description column will report back every action that was taken and the results of that action. I think it’s better then any of the reports I’ve found.

Since it was the first day of the week, it was time for the meetings to start. First meeting: Discuss the implementation of SMS in one of our classrooms. The Sys admin for the classrooms manages 5 classrooms of 16 machines each. They are firewalled off from the rest of the company, but holes can be opened up for specific needs. He’s still using ghost to re-image the machines before every class. The problem is, he has 16 different images and some of them fall behind in patch levels. The old admin started a project to get SMS implemented in these classrooms. After hunting around for a few days we found the servers. He setup a child site and a separate machine for dp. We figured the child site is inside our internal firewall and the dp is on the classroom side of the firewall. At this point we assume the correct ports have been opened, guess we’ll find out. A little bit of discussion and we determine that he can automatically run the sms client install after ghosting. Now things get interesting. How do we schedule advertisements such that, the machines are kept up-to-date but no patching takes place while a class is in session. It occurs to me that if he can run a command line automatically after patching then we have a patch solution in place already, currently in use by our new computer deployment team. They use a combination of a WSUS (Windows Server Update Services) Server and a script that updates the Automatic Updates client, forces all the settings, connects to the WSUS server, updates, reboots, logins and continues until the machine is patched.

WSUS? Isn’t that SMS blasphemy? Well hold on before you crucify me. Remember all we are really interested in, is patching classroom machines that get re-imaged several times a week. The software is already installed on the images and we are not patching non-Microsoft products. Plus this solves the scheduling problem, since the patching takes place automatically, immediately after imaging. It’s the right tool for this job.

The idea is well received by the other admins. In the end we agree that SMS is still important to implement, we want the reporting and we see the benefit of creating software packages for the future, and one day we may switch him from Ghost to OSD. Plus it buys us time for him to get the images updated with the client.

Meeting Two will have to wait until my next post.