myITforum.com : SMS Client Health Script

OK, I'm throwing down a challenge! I think that the best and only way anyone should ever push and maintain the SMS client is via a startup script. Every rule has an exception, so find me in the forums and tell me why this can't always be done.

Rob Olson & I wrote this thing about two years ago. Over time we added to it as we found common files which a script could fix. Net result? 8,000 systems which refused to install the SMS client are now all healthy and patching fine and reporting inventory day after day. How long would it have taken us to fix those one by one? We'd still be working on them even if we had an amry of techs to help us.

Why this script over other methods?

Running AD System Discovery out of the box means you can pick up dead machines in AD and never push to them. Same thing for network discovery only it's noisier to the network.

A startup script run from a GPO means that real, live machines are finding SMS which seems to make more sense than having SMS look. And since SMS relies on AD for things like finding an SLP or MP or site assignment, then it only makes sense to rely on that infrastructure to enforce a GPO. (Because if that isn't working, SMS wouldn't either). And rather than just finding machines and trying a push, this script will keep those clients healthy (in SMS terms anyway). We recommend placing it in a startup script so you don't slow your users at logon. It also runs under local system this way. Local system has permissions where your server might not; another reason this is far better than a push from an SMS server.

So how's it work?

If you have SMS installed and automatic updates installed, it'll just exit. But if not, it rolls up is sleeves and goes to work.

It starts looking for anything which could prevent an install of the client or prevent SMS from patching a system (wuausrv and BITS); is admin$ disabled, has msxml3.dll has lost its registration, has ccmexec has been disabled, etc. The script is pretty well commented so you can decide to turn any one piece of it off. But where it finds something wrong, it fixes it and that is why this is better that a generic discovery mechanism. Should a user disable SMS, or BITS, or should the XML parser become unregistered, this will fix it.

It won't work out of the box. You'll have to edit a few lines to specify your servers and user groups.

You may want to specify that your SMS admin techs have local admin on the clients and if you go to line 89, you can specify such an account. You can specify cache sizes, a server to send CCR's to, and the location to run ccmsetup on the fly (this is recommended over the CCR method and is default here). You can add logging too. This version now writes to the local event log but like the last version can copy the script's log to a server you name (good or bad or both - good means the script found nothing wrong, bad means it had to do something). If you chose this option, grant DOMAIN\DOMAIN COMPUTERS write permissions (NFTS) to that share since the script runs under local system.

If you enable logging for bad clients to park their scripts on a share, you can see what's getting fixed. You can also monitor to see who is running this every day (meaning the script failed to fix something and keeps trying every day). Can that be automated? Rob did that part all on his own. He wrote a web based backend to this which you could run too to monitor that share and show you who keeps failing. He's published that part on his DudeWorks site for free. You can also subscribe there and get updates if we change this script.

You can set the GPO to run on just one OU to test or roll out the client to and as you build confidence, you can move it up and perhaps link it to the root (even we're not there yet). We have dozens of OU's linking to the one GPO. As various business units move off other management systems, they ask how to get SMS. We tell them to link their OU to our GPO and when they reboot, they'll get the client. Simple. Actually this goes without saying, but it's a good way for you to test the script and GPO before sending it to others; put some test machines in an OU and link the GPO to it. When you're satisfied, start rolling.

What will we do differently in the next version that you could do right now? Kill the Windows Updates and BITS checks and have the GPO enforce them directly. We did not do that because with a base of 130K machines, you want to tread as easily as you can. What if we broke something else we didn't know about? Well it's been a couple years now and we feel good about the GPO and its value, so we'll make that change the next go around. We might also incorporate WMDIAGv2 instead of playing the WMI repair\rebuild game.

UPDATE: Shaun Cassells took this script and gave it a fresh work over with a few more fixes to boot. Check out the details here. Great work Shaun!

12308CLIFIX_Public.zip
Uploaded latest version to myITforum on 1/28/2008. As always, Dudeworks should have the latest public version too.

Download


		myITforum.com ©2010 \| Legal \| Privacy