Shaun Cassells at MyITForum.com

SMS 2003 and ConfigMgr 2007, PowerShell, Scripting, Finance, Fitness and Fun

SMS 2003 Client Health Startup Script v4.18

Script updated:  http://myitforum.com/cs2/blogs/scassells/archive/2009/04/14/sms-2003-client-health-startup-script-v4-19.aspx 

 

Below is a listing of features in a reworked version of Dudeworks (Thanks Rob and Brian), 1E, et al. (see bottom for longer list) start up scripts.  I recently became aware of Chris Stauffers Client Health Checker v1.2.   My script focuses on workstation health, Chris’ focuses on SMS health.  It is my hope in 2009 to combine these two if it seems intelligent to do.  Hopefully we can have this all together in early 2009.  Be great to present and then for everyone to tear apart at MMS... anything is possible. 

Reminder: this is not finalized.  It takes a community. Please feel free to post updates in the forums.

Overview

Workstation Client Health maintenance is a continuous process that must be maintained.  The following document gives an overview on how to fix several common workstation issues. 

CliFix GPO startup script

In an effort to reduce the amount of common workstation issues I have developed a script to check and change the following common issues.  This script is to be run via GPO startup scripts.  This requires the script to work as the system account and have intranet connectivity.  Both are accomplished by running as a GPO. Script Requirements
  1. Script must be in a location where the computers system account has access.  Usually on your domain controller ex. \\FQDNDomain\sysvol\ FQDNDomain\
  2. sc.exe must be present for full successful run. 
    1. Either in the run path
    2. system32
    3. system32\DLLCache
    4. Note: there are multiple versions floating around in the average environment
  3. regsvr32.exe needs to be present
  4. %systemroot%\system32 needs to be in system path
 

Script Settings

All, unless I missed some, sections of the script can be turned on and off in the top of the script.  Please review the script as some features will fail without modification.

Please Review the following CONFIG SETTINGS Variables:

  • SMSVersion
  • ConfigMgrVersion
  • WKS_ASSIGNSITECODE
  • WKS_CacheSize
  • WKS_LocalAdminGroup
  • WKS_admACCT
  • RegPath
  • strWebAddress
  • StrCCRServer
  • strCCRSiteCode
  • CCMSetUP

What the Script Does

  1. Checks to make sure the script has not run in X many hours. 
    1. Example if X = 12 the script will not run again until at least 12 hours after the last occurrence. 
    2. This will prevent a slow down on multiple reboots.
  2. Sets DCOM permissions to be correct for SMS / SCCM configuration
  3. Checks to make sure System Path has the 3 required windows paths enabled. (does NOT use WMI or require a restart to change values)
    1. C:\windows
    2. C:\windows\sysetm32
    3. C:\windows\system32\wbem
    4. Also removes %systemroot% from path replacing it with correct full path value
    5. If one of the 3 paths is missing, it will parse the full path removing duplicates and adding a,b,or c to the beginning of the path statement leaving all else unchanged.
  4. Check to see if sc.exe exists in the run from directory and if not in the system32 directory
  5. Checks to see if this script is run on a workstation or server.  If a server kills the script
  6. Checks to make sure the correct local admin group is present (value is set in header of script)
  7. Checks WMI service to see if it is set to auto and running.  If not executes sc.exe to start the service.
  8. Attempts to connect to WMI object
  9. If the WMI object connect fails
    1. Attempt to do a repair (if no previous status is present in the registry and approved via script switches)
    2. Attempt to do a rebuild (if ‘repair’ status is present in the registry and approved via script switches)
    3. If both the above have failed then do nothing and report major error
  10. Checks to see if Admin$ is present, if not forces existence via WMI
  11. Checks to see if msxml3.dll is registered, if not forces existence via WSH
  12. Checks to see if Qmgr.dll and qmgrprxy.dll are registered, if not forces existence via WSH
  13. Checks to see if OLEAut32.dll is registered, if not forces existence via WSH
  14. Checks to make sure the following services are set to appropriate Status and Mode
    1. RPC
    2. WMI
    3. Firewall/ICS
    4. Server Service
    5. Remote Registry
    6. BITS
    7. Windows Update Services
    8. Terminal Services
    9. Windows Installer
    10. Note: You may want to review the settings for your environment on each of these services.  All of the above services are set to default and either Manual or Automatic.
  15. Check the SMS version
  16. Checks the CCMExec service
  17. If SMS is not correct version can be forced to do an install
    1. Needs Review
  18. If the all of the above test passed without issue you have a healthy workstation.  The following two checks are for SMS.
    1. Check log file last update time.  If the PolicyEvaluator.log file has not been modified in past 14 days do a repair of the client.
    2. Check client assignment.  If no assignment set new site code based on AD boundaries in which the client is present.
      1. Note: Some people may want to disable this as it relies on AD
  19. If any fixes above had to be preformed
    1. Check the advanced client state.  Which client policies have enabled.
    2. Check the cache size
    3. Send a Client Configuration Request (CCR) to have client installed
    4. Run CCMSetup from the install share on the server.
 Note during this script several forms of reporting, logging, and information submitting have been preformed.  The standard methods of reporting are: 
  • Event log
  • Log file in the %temp% directory for the account used to run
    • GPO = C:\windows\temp
  • Reporting to a website that submits client status to a SQL table.
    • Future WebPost on how to do this 
Other verbose methods include:·        Two levels of command line reportingo       Log to Command lineo       Verbose to command line·        network share copy 

Future Additions:

Area's that need improvement

References:

·         MyITForum Forum: http://www.myitforum.com/forums/tm.asp?m=107044 ·         1E: www.1e.com ·         Chris Stauffers soon to be reviewed: http://myitforum.com/cs2/blogs/cstauffer/archive/2008/06/13/client-health-check-script-and-scheduled-task-version-1-1-release.aspx ·         Brian Mason: Original Author of CliFix ·         Rob Olson: Original Author of CliFix at www.dudeworks.com ·         Greg Ramsey: http://myitforum.com/cs2/blogs/gramsey/ ·         Steve Pruitt: http://myitforum.com/cs2/blogs/spruitt/ ·         And the MSSMS list http://www.myitforum.com

 

 

Script v4.18: REMOVED.  v4.19

http://myitforum.com/cs2/blogs/scassells/archive/2009/04/14/sms-2003-client-health-startup-script-v4-19.aspx

 

hopefully it will be up on  www.dudeworks.com soon

Comments

Heffe said:

Thank you for sharing your script.  I appreciate the work that has gone into it.  In our environment, this script seems reports an error on some workstations that are working correctly.  I believe I found the problem so I would like to make a suggestion for your next revision.

In the SCFileExist subroutine you check for the SC.EXE file in various locations on the client.  The ELSE statements increment the clientstate, despite the fact that SC.EXE was successfully found.  Would you consider removing lines 1591 and 1597 (the two lines that increment the count)?  Maybe I'm not understanding why those lines are there, but I think the script would run better without them.  In my opinion, the clientstate should only be incremented in the final case where SC.EXE is not found.

# February 26, 2009 7:36 PM

scassells said:

Morning Heffe.  Their are multiple versions of sc.exe in the average environment.  I cannot guarantee the functionality of each.  Hence why it checks to see if sc.exe exists in the run from path of the script.   If you do not want to put sc.exe in the run path, then yep remove the lines at 1591 and 1597.  I am waffling between leaving this as an error or not... at this time I am leaning towards removing.   Which do you recommend now that you know why it is there.

Best

# February 27, 2009 9:33 AM

Heffe said:

I would remove them, but that's just my opinion.  You're already logging the location of SC.EXE so we can go back and check the version if it doesn't work as expected.  I've used SC.EXE from the command line for years and have never had any serious issues with any of the versions.  Did you find a version that didn't work as expected?

The problem with incrementing the clientstate variable is that later in the script you might attempt to run CCMSetup.exe to reinstall the client if clientstate is greater than zero.  That means you would be running CCMSetup on a workstation whose only problem is that SC.EXE is in the path but not in the same directory the script was launched from.

# February 27, 2009 11:48 AM

scassells said:

Okay, can do.

As for finding varaition in sc.exe, I did not, but then again I do not have time to look.

# March 2, 2009 9:17 AM

MeenEnta said:

In the script you have this line

WKS_admACCT = "putyourshere" 'SpecIfy SMS Admin account (group)

I'm not sure what to put there, is it my logon "username" as I am the administrator or something else?

Thx Shaun.

Also my other email is gkamenjati@valleywater.org

# March 4, 2009 5:23 PM

scassells said:

Hi MeenEnta

  Good question.  In our environment we have removed local admin rights away from users.  Because of this we add in a Domain Group to allow a specific set of people to have access to the machine as administrators.  

If this is not something you need in your environment make sure do_CHK_LOCALADMIN is set to FALSE.

Best

# March 4, 2009 7:54 PM

kingskawn said:

Hi,

Thanks for this script but can you tell us how to make it SCCM compatible because in the title it says that it's working on sms2003 and under it says that for sccm there must be some modifications. What are these?

Thanks

# April 11, 2009 11:42 AM