in

myITforum.com

Matt Broadstock at myITforum

Scripting away in Margaritaville

Having fun getting SMS client issues worked out

Well, now that Tim Mintner is a bigshot and Microsoft (how's Davenport treatin' ya) and Brian Tucker is in South Carolina sitting on a beach drinking beers and playing his guitar, I get to be SMS-guy for a week. It's a nice change of pace from the AD and scripting work that I spend most of my time on.

So, for the past few days I have been working pretty much non-stop on trying to make sure all of our clients are on the ITMU version. We had a few hundred clients that had problems upgrading to the latest client. And, of course, rather than there just being one cause, there seems to be a lot of different reasons.

So far, we've run into the following:

80+ machines - Registry permissions at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\Client\Client Components\Remote Control\User Settings were screwed up. This was caused by a package that was setting registry permissions at HKLM\Software and pushing them down to every subkey.

50+ machines - More registry perm issues - This time a different package was resetting the permissions at HKEY_CLASSES_ROOT\TypeLib with "Domain Users - Full Control". The client wasn't able to upgrade/repair because the System account didn't have permissions.

50+ systems - A router issue at one of the sites is preventing them from contacting our load balanced Management Points. They can access any other server but not just those two servers. Still working on this one.

A handful of systems - The SMS Agent Host was just stopped.

I hammer this point home to our packagers all the time: You cannot take the easy way out when setting either NTFS or registry permissions. We've been bit time and time again with packages doing things they weren't supposed to do: vbs get broken, .Net framework gets broken, VBA stops working in MS Office, etc. Overall they are doing a pretty good job but all it takes is one bad package to screw up a lot of workstations. And they can be a real pain to fix after-the-fact too.

Anyway, if anyone cares, here's the query we used to track which clients haven't been updated:

select SMS_R_System.ResourceID,SMS_R_System.ResourceType,SMS_R_System.Name,SMS_R_System.SMSUniqueIdentifier,SMS_R_System.ResourceDomainORWorkgroup,SMS_R_System.Client from SMS_R_System where ClientVersion not in ( "2.50.3174.1152" ) and OperatingSystemNameandVersion like "%Workstation 5.1%"

I then created a subcollection that was limited to that collection with the following query:

select SMS_R_System.ResourceID,SMS_R_System.ResourceType,SMS_R_System.Name,SMS_R_System.SMSUniqueIdentifier,SMS_R_System.ResourceDomainORWorkgroup,SMS_R_System.Client from SMS_R_System where Active = 1 and Client = 1 and ResourceDomainORWorkgroup = "DS"

This was so I was only looking at systems on the domain (not our legacy clients) that are indeed active.

Published Sep 21 2005, 12:49 PM by mbroadstock
Filed under:

Comments

No Comments
Copyright - www.myITforum.com, Inc. - 2007 All Rights reserved.
Powered by Community Server (Commercial Edition), by Telligent Systems