So I had another problem, and one I know I’m not alone in…
I’ve got clients that are failing, won’t install, have corrupt wmi repositories, and obviously I can’t deploy a repair solution to them so what do we do?
Well like most people in an enterprise environment (or smaller I’m sure) we maintain a logon script, and considering that this script will run come hail or high water it is clearly the best possible automated resolution point possible.
There have been some really great log on health check scripts written by a lot of great people in the MyITForum community, and having used two of the more popular ones I’ve decided there are some great things in both of them, but in one case more than what I need; and the other just short of my needs.
So what do we do? Simple, write our own; which you can download from a link at the bottom of this post.
So lets first look at what it takes to run this script:
CmLogonFrameWork.wsf + config.xml
At run time you can configure 4 override settings:
- /log:”c:\windows”
This will write the logfile to the windows directory.
- /config:”somefilesomewhere.xml”
This will load the specific config file you need, useful if you have multiple configurations for multiple machine/user types.
- /events
This will force the script to write events to the event log regardless of how it’s defined in the config.xml
- /debug
This will force the script to error verbosely, which will become useful if you are going to extend the code and need to see the error output.
So what does the script do? Well I’ve put my horrible Visio skills to work to give you the obfuscated flowchart that might very well make you want to claw your face off (included in the script download). However I’ll give you a quick overview of the intended functionality to save you from all the head scratching and the “what was this guy smoking” statements you might have as you read it.
It’s best to think about this script in 5 blocks:
- Initialization
- System Check
- SCCM Check
- SCCM Configuration
- Close Out
Initialization:
This block is fairly straight forward. We gather arguments, enforce a cscript execution (for cleanliness more than anything), generate our first log entry, load the configuration file, and write a LastRun entry to HKLM\Software\SccmHealth for tracking of changes and repair mechanisms later.
The only potential repair function during this phase would be to the XMLDom (and all the script will attempt to do is register the component). If OS version checks fail, or the XML file cannot be read then the script will close with an error in the log.
System Check:
The system check is also fairly straight forward. We first check the admin account if one is configured, we check the admin shares, we check the list of services defined in the config, and finally we verify that the root/cimv2 is accessible in WMI.
Repairs that would occur in this phase are the enabling of admin shares via service and registry values. Services are configured per the config file if they are not presently in that state. And finally if it’s enabled, an attempted wmi rebuild would be performed if wmi fails its check (there are two distinct repair types determined by the version of windows).
SCCM Check:
Now things get a bit more confusing, but I’ll keep it high level since I have a bit of an election system in the script on what repair method is the best option.
Check the CM namespace in WMI, then the service, then the executable, and finally the setup files. If all 4 fail or 3 of 4 then a standard installation will occur. If only the namespace fails then a reinstallation is attempted provided that option is allowed, if not then a wmi repair is attempted if it is allowed. There are other checks that manipulate the outcome such as your configuration options obviously and when the last repair date was attempted on the asset.
SCCM Configuration:
This section is very straightforward.
Check the Site code, and check the cache size, if they don’t match the config, we change them to match.
Close Out:
As our final phase we load any additional scripts identified in the config file, generate our System Check, SCCM Check, and SCCM Configuration check report card. If remote logging is enabled we write the final output there as well, and finally we deconstruct our objects and terminate the script with or without errors depending on the outcome of course.
Tips for Extending:
The two custom objects being used here in this script are cls_Logging and cls_Dict which are instantiated as Logging and Config respectively.
A list of these classes and how they work can be found here (logging) and here (config).
I’ve also included a test.vbs that extends the script to give you an idea of some of very basic examples of extended functionality. I would recommend you avoid adding anything to the primary script, but instead extend it all as a separate script and have it performed at the end of the script, unless of course it’s an entirely new object that you wish to build into this tool then by all means have at it.
If you have any questions, suggestions, or if you find bugs please comment so I can answer them or repair them, thanks.
Download: