SMS Client Health Startup Scripts, and multiple domain maintenance.

The downside of multiple domains, is that I have to maintain multiple scripts for SMS Client Health Check.

Until today.

I used the sThisDomain variable I created for the Check_Domain function I wrote, and did this:

Select Case sThisDomain
    Case "CONTOSO"
        WKS_admACCT = "CONTOSO\Workstations Admins"
        StrCCRServer = "CON23"
        strCCRSiteCode = "P20"
        GoodLogPath ="\\CENTLOG\CONTOSO\SMSHealthCheck\Good"
        BadLogPath ="\\CENTLOG\CONTOSO\SMSHealthCheck\Bad"
    Case "TOLERDO"   
        WKS_admACCT = "TOLERDO\Admin WKS"
        StrCCRServer = "TOOL11"
        strCCRSiteCode = "P76"
        GoodLogPath ="\\CENTLOG\TOLERDO\SMSHealthCheck\Good"
        BadLogPath ="\\CENTLOG\TOLERDO\SMSHealthCheck\Bad"
    Case Else
        COLLECTMSG "Unknown_Domain","ERROR","The domain '" + sThisDomain + "' is not configured for in SMS check script"
        StrERRType = StrERRType & "UNKNOWN_Domain_"
End select

As you can see, just changing the value of sThisDomain, I am now able to have the one script working in another domain (such as  TOLERDO).  and the script now allows me to quickly add another domain by just adding another Case block in.

SMS Client Health Startup Script, and logging

sms2003_150x70The pilot of the SMS Client Health Startup Script has gone reasonably well.  So far the script has found about 30 broken PCs.

But the logging has been a bit hit and miss.  We write to a central log server, and we’re been getting quite a few “Path not found” errors.

Now, I think it’s either one of two things.

  1. The DNS server lying to me, and/or
  2. The section of the code which does the central log file creation.

For the lying DNS server, I’ve added a Ping of the central log server, so I’m hoping that’ll help.

Now the section of the SMS Client Health Script which checks that the log directory existed, was doing this:
If objFSO.FolderExists(LogPath) Then
Set objFolder = objFSO.GetFolder(LogPath)
Set objFolder = objFSO.CreateFolder(LogPath)
End If

"Set objFolder = objFSO.GetFolder(LogPath)" – WTF???

The script is trying to get a folder listing of ALL the log files that the central log server has.  I don’t understand why.  The code doesn’t do anything with the information.  Unless it’s some perverted way of checking that the log directory is online.

My guess is that the GetFolder call is timing out, and causing the later log file write call to fail.

So, I replaced the offending code with:
If Not objFSO.FolderExists(LogPath) Then
COLLECTMSG "Set_LOGFOLDER","ERROR","GoodLogPath not found " & err & " " & err.description
End If

We’ll see how it goes over the next week.

Resetting the Permission Required flag for SMS Remote Control.

sms2003_150x70We have a VBscript job that SMS 2003 runs weekly on all our client computers.

Amongst other things, it sets the Permission Required flag for SMS Remote Control.
In other words, it’s the "Permission Required for someone to remotely control my computer, from elsewhere".  Normally this is a good idea.

Permission Required.

After hours, one of my co-workers needed to remote control a users computer, and the user wasn’t there.

My quick solution?*

Edit the vbscript to change the flag, then remotely run the script.

Problem solved.

* Remote Registry access was broken.  And WMI was not healthy.
  (the registry key is: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\Client\Client Components\Remote Control\Permission Required .

So you want to upgrade your SMS 2003 Server to SP3

sms2003_150x70 These are the following minimum steps you need to follow:
Pre-install tasks (preflight)
Verify SMS 2003 SP3 requirements (SQL & Windows Server OS versions/SP)

Using the SMS Deployment Readiness Wizard:

Backup SMS SQL Database
Restore SMS SQL Database with new DB name
Run SMS Deployment Readiness Wizard
Review SMSSetup.log
Verify that SMS is running correctly (pre-SP3 install)
Review MPcontrol.log file has no errors
Verify SMS client is reporting correctly
Test client discover
On SMS Server, verify client is reporting
Service Pack 3 install and verify
Backup existing SMS MOF file
Run SP3 install
Reinstate original MOF file
Verify that SMS is running correctly (pre-SP3 install)
Review MPcontrol.log file has no errors
Verify SMS client is reporting correctly
Test client discover
On SMS Server, verify client is reporting
Review SMS log files
Review SMSSetup.log
Review mpsetup.log to ensure completion
Review mpcontrol.log to ensure a) completion and b) http 200 messages being received.
Review SMSSiteComp.log
Review Hman.log (if applicable)
Review Inboxmgr.log
Verify SMS Reporting Point is still working (Central Server only)
Post install hotfixes
Apply Hotfix KB971225 (Windows 2008 & Vista detection)
Apply Hotfix KB941214 (Updated Client.MSI)
Apply Hotfix KB974014 (Windows 7 and Windows Server 2008 R2 support)
Reboot server
SMS Client on Server install
Install client.msi on server
Verify sms client on server
Post SP3 install tasks
Check version in SMS Console / Site heirachy is now SP3
Update OSD Feature pack
Reboot server
Bookmark and Share

Semi-regular web-link clearance – July 2010

Suggested reading from the Microsoft Directory Services team.
Lots of good entry level reading here to help you brush up your Active Directory skills.

Troubleshooting, Known Issues and General Resources
When you’re troubleshooting a problem with Systems Management Server or Configuration Manager 2007, chances are you’re not the first person to encounter your particular issue. With that in mind, the first thing you’ll want to do is a quick search of our Knowledge Base, our blog sites and our forums to see if anyone has already posted the resolution: …

Data collection for Configuration Manager 2007 and SMS 2003
Log files you should collect before you raise a Microsoft support call, for SMS 2003 and SCCM 2007.
”For System Center Configuration Manager 2007 (ConfigMgr 2007) and Systems Management Server 2003 (SMS 2003), the first thing you’ll probably want to do in preparation for your callback is gather up any relevant information and log files so that you’ll have them handy when you speak with a Support Engineer. The exact data we’ll want to review can vary significantly depending on the issue so for the sake of this document we’ll err on the side of gathering too much data rather than too little.”

Use A Ram Disk To Reduce Writes On Solid State Drives

Bookmark and Share

SMS Client Health Startup Script and Cross Domain logons.

PowerShell logoI’m in the process of piloting the DudeWorks/1E/Shaun Cassells SMS SCCM Client Health script.  I’ve set it up so it runs in the user’s logon script.  But there’s a bug with that.

  • User FRED is the CONTOSO domain
  • User FRED logons onto a computer which is part of the TOLERDO domain.
  • SMS Client Health script tries to repair the TOLERDO domain computer
    (not a good thing).

The fix?
Update the script to check to see if the user is logging onto a computer in their own domain.  The scripts changes were:

  1. CONFIG Settings section
    Added sThisDomain="CONTOSO"
  2. In the START section, just after the Create Log file call
    ' Check Domain to ensure a CONTOSO user isn't logging onto a TOLERDO PC.
  3. And finally, added this subroutine:
    Sub Sub_Check_Domain
         If InStr(objSysInfo.ComputerName, LCase(sThisDomain)) = 0 Then
    COLLECTMSG "Sub_Check_Domain","","A " + sThisDomain + " user has logged onto a non " + sThisDomain + " PC"

            COLLECTMSG "Sub_Check_Domain","","objSysInfo.ComputerName is set to: " + objSysInfo.ComputerName
             CLIENTSTATE = 99
             StrERRType = StrERRType & "WRONG_Domain_"
             COLLECTMSG "Sub_Check_Domain","","PC is in domain:" + sThisDomain
        End If
    End Sub

Bookmark and Share

Detecting broken or not installed SMS/SCCM clients.

You take all your computer accounts in Active Directory, filter out the old records (I use a cut-off of 30 days), and then compare it to your SMS or SCCM database.
(I showed you how to export the LastLogin date from Active Directory here).

An aside:
I love Active Directory, as you can use it as an “Authoritative Source”.  If the computer is not in Active Directory then it won’t be able to use AD resources, such as the corporate intranet or email or network printing; if your sysadmin is particularly clever.

You’re going to have 3 cases where computers aren’t reporting into SMS/SCCM, but are in Active Directory.

1. SMS/SCCM client is not installed
This is the easy to detect.  You can see it in the Active Directory but it’s not in your SMS/SCCM database.  Simple fix, install the SMS/SCCM client.

2. SMS/SCCM client is installed but has never reported.
Investigate and resolve the issue.  If there are lots of clients not reporting, it might be a site boundary issue.

3. SMS/SCCM client is installed but has stopped reporting.
The client has become broken.  When I last had this problem, it was WMI based and I wrote a custom script to repair it.  With mixed results.

The way I tell if a client has stopped reporting?
I subtract the SMS last contact date from the Active Directory LastLogin date.  If the difference is greater than 14 days, it’s likely the SMS client has a problem.

You could fix these broken clients manually, but a better way would be to have something in your users logon script.  Which runs at user logon and just detects and fixes common SMS/SCCM problems.  Which someone has already done.  You can find it here:
SMS 2003 Client Health Startup Script v4.19


  • 30 days?  Well people go on holidays for 4 weeks, and their computer may be turned off…
  • Corey Hynes suggested at TechEd 2005 that you should automate repeative tasks with scripts.  He was right you know.
    Microsoft Systems Management Server 2003
    Microsoft System Center Configuration Manager 2007

Bookmark and Share

Adding computers directly to SMS collections

I don’t do this often enough to remember it, so here’s a quick guide for me (and anyone else out there still using SMS 2003).

SMS Directly adding PC to collection

  1. Start the Administrator Console, and browse to the collection you want to add the computer to.
  2. Right-click the collection and select Properties.
  3. Select Membership Rules, and then click the Computer icon.
    The “Create Direct Membership Rule Wizard” will appear.
  4. Set the “Resource class” as System Resource.
  5. Set the “Attribute name” as Netbios Name.
  6. Enter the computer name, of the computer you want to add.
  7. Click Next.
  8. You’ll be asked for a Collection the computer is in.
    I usually select All Windows <operating system> computers.
  9. Click Finish
    (and the computer will be added to the collection).

Bookmark and Share

WMI has stopped working on some remote computers.

And I don’t know why.  My strong guess is that it is related to one of the 10+ recent Microsoft security patches I’ve deployed to the fleet.  (I’m looking at you .Net Framework 2.0)

The fix so far? Rebuild WMI and repair the SMS client.

I do this by:

  • copying wmirebuild.bat and runrepair.vbs to the target computer.
    the purpose of runrepair.vbs is to HIDE the running of wmirebuild.bat, so the end user doesn’t see it.
  • remotely run runrepair.vbs via a PSEXEC command.

Yes, it’s a bit kludgey.  It’s a fast fix.

Dim objFSO,objNet,objShell,drive_status
Dim objWMIService, objProcess, colProcess, strComputer, strProcessKill
Dim sWbemPath,sSystemRoot

On Error Resume Next

Set objFSO = CreateObject("Scripting.FileSystemObject")
Set objShell = CreateObject("WScript.Shell")

sSystemRoot = objShell.ExpandEnvironmentStrings("%systemroot%")

'check that system32 directory exists.

If Not objFSO.FolderExists(sSystemRoot) Then
End If

If Not objFSO.FileExists("c:\temp\wmirebuild.bat") Then
objShell.Run "c:\temp\wmirebuild.bat", 0, True
End If

Set objShell = Nothing
Set objFSO = Nothing


net stop ccmexec
net stop VMAuthdService
net stop winmgmt
cd %systemroot%\system32\wbem
rem rd /S /Q repository

regsvr32 /s %systemroot%\system32\scecli.dll
regsvr32 /s %systemroot%\system32\userenv.dll

mofcomp cimwin32.mof
mofcomp cimwin32.mfl
mofcomp rsop.mof
mofcomp rsop.mfl

for /f %%s in ('dir /b /s *.dll') do regsvr32 /s %%s
for /f %%s in ('dir /b *.mof') do mofcomp %%s
for /f %%s in ('dir /b *.mfl') do mofcomp %%s

net start winmgmt
net start VMAuthdService
net start ccmexec

echo done >>c:\temp\done.txt

Then kick it all off with
psexec \\COMPNAME -s c:\winnt\system32\cscript.exe //B c:\temp\runrepair.vbs

Update: the wmirebuild.bat script I found here: How Do I Rebuild A Corrupt WMI Repository?

The next post in this series is, “Grumble grumble – revisiting the WMI fix”.

Bookmark and Share

Check the health of your SMS 2003 & 2007 servers

I run a PowerShell script which checks the health of my 20 SMS 2003 servers.

Sure, I could install Microsoft Operations Manager (Microsoft MOM).  But there is the cost for the physical server, and Microsoft licensing to be considered.

So, instead I make do with the PowerShell script.  It’s saved me from having several server problems becoming noticeable to the customers.  (the latest example is here)

It’s crude, but it checks each of the SMS servers for:

  1. the server is alive, aka “pingable”.
  2. it’s CPU utilisation is <= 20%, and that no individual processor is running at greater than 20%.
  3. that the assorted SMS directories (inbox, Offersum etc.) are being processed.
    If a directory has greater than x files, this may be an problem.
    Curiously enough, Microsoft suggests a 10,000 file threshold.  I set it at 200 files.
  4. enough disk space exists on the SMS package shares.

Future plans?

  1. Write each check out to a log, for availability reporting.
  2. Check for “older than x days” files in the SMS directories.
  3. Make it’s output pretty, most likely via WPF.

You can download the script, and the sample server list file here.

Bookmark and Share