Dan Thomson at myITforum.com

Managerial Effectiveness Self-Test #1

I was recently thinking about ways a manager could easily determine effectiveness.  The first thing that came to mind was:  Do you find yourself frequently being sought out to provide guidance to your sub-ordinates?  If not you might want to reflect on why not.

Posted Monday, August 16, 2010 9:24 AM by dthomson | with no comments

SMS/ConfigMgr Health Check Tool: Status Update 2

So where are things today with the Health Check Tool?  I have the tool running pretty well in my mixed SMS 2003/ConfigMgr environment.  We don't have any 64 bit systems to test on, so I'm going to get my home lab out of mothballs and do some testing against Server 2003, Server 2008, Vista, and Windows 7.  I know I said you'd see something mid-July, but good things come to those who are patient......

Posted Friday, August 13, 2010 4:05 PM by dthomson | with no comments

Code Editors

It would really be nice if one company could write a code editor that worked great.  Most that I've tried fall short in one way or other.....

Posted Friday, August 13, 2010 12:13 PM by dthomson | with no comments

SMS/ConfigMgr Health Check Tool: Reading Logs

I am not really a fan of having to parse logs to figure out if something is working right or not, but I have found that's a requirement when looking for error situations with CCMSetup and the Windows Update Agent.  I'm also parsing through the files in the EndPointQueues folder to determine if the client was included in an operating system image and there are system name mismatches which indicate why the client might not be receiving all policies.

Posted Friday, August 13, 2010 12:08 PM by dthomson | with no comments

myITforum roll call (Wash D.C. / Baltimore area)

Hey myITforum readers.  Who here is from the Washington D.C. / Baltimore, MD area?   It would be nice to have a get together this year.  Something like I tried a few years back.  Shoot me an email if you're interested. Maybe I should make this a myITforum poll.....

Posted Friday, August 13, 2010 11:52 AM by dthomson | with no comments

SMS/ConfigMgr Health Check Tool: Code bloat or what?

For giggles, I checked how many lines of code there are in all the files that comprise the Health Checker Tool I'm working on.  No wonder it's taking so long...there is nearly 15,000 lines of formatted code.  It seems I can never get myself to do things simple.  I still have yet to properly document the code.

I'm still finding some issues I need to work out, such as:

• Posting a CCR to a Configuration Manager Management Point via VB Script.  My code works fine on SMS 2003, and I thought it was fine on ConfigMgr, but the site server never sees the request and the code doesn't generate an error.
• Posting an MP List request to a Configuration Manager Management Point via VB Script.  Again, my code works fine on SMS 2003, but it isn't working on ConfigMgr and the code doesn't generate an error.
• My Windows Installer repair routine is quirky and needs some more attention.

Feel free to send me your tips!

Posted Friday, August 06, 2010 3:20 PM by dthomson | with no comments

SMS/ConfigMgr Health Check Tool: Status Update 1

So where are things today with the updated health check script that was mentioned a couple months back in the myITforum newsletter?  I have coded a three part process that is started as a GPO computer startup script.  A lot of the basic thoughts on checks and fixes came from the various tools already available from many community scripter's.  I have taken these basics and expanded so the tool fits well in my environment, which can be troublesome at times. These three operational parts of the health check tool are:

• A Health Check Tool.cmd script that is launched via the GPO. I had to start the health check process in this manner because I found a number of systems in my environment that had issues with the Windows Script Host and would fail to run the health check script directly.
• A Health Check Tool.exe executable that is coded using WISE Script Editor 7.6 SP3 (I'll see if I can back this out to use SMS Installer instead).
• A Health Check Tool.wsf script. The .wsf script references a number of utility scripts to help keep code additions and changes manageable (we're at or over 10,000 lines of formatted code).

How the Health Check Tool runs during system startup

Health Check Tool.cmd

The Health Check Tool.cmd script runs first via a GPO computer startup script and performs the following tasks:

• Copies the Health Check Tool.exe to the computer's hard drive in the %ProgramFiles%\SMS\Health Check Tool\ folder.
• Creates a Health Check Tool service that runs the Health Check Tool.exe
• Starts the Health Check Tool service.

Health Check Tool.exe

The Health Check Tool.exe executable runs when the Health Check Tool service is started by the Health Check Tool.cmd script.  This executable performs the following tasks:

• Verifies the tool is running as an administrator
• Deletes any scheduled tasks that are set to run the Health Check Tool.exe (see How the Health Check Tool runs every day)
• Checks to see if the Windows Script Host is ok. If not, a repair is run to attempt a fix.
• Extracts all .rtf, .wse, .wsf, .vbs, and .xml files to sub-folders under the %ProgramFiles%\SMS\Health Check Tool\ folder
• Starts the Health Check Tool.wsf script

Health Check Tool.wsf

The Health Check Tool.wsf script is typically started by the Health Check Tool.exe and performs the bulk of the system health checks.  This script performs the following tasks:

• Verifies there are no task sequences running. If yes, the script exits.
• Verifies core services are configured properly. If needed, various repairs are attempted.
• Verifies the Path, Tmp, and Temp environment variables are correctly populated and are the correct registry type. If needed, various repairs are attempted.
• Checks if the XML Parser is functioning. If needed, various repairs are attempted.
• Checks if WMI is running properly. If needed, various repairs are attempted.
• Checks if the Windows Update Agent is working properly. If needed, various repairs are attempted.
• Checks if BITS is working properly. If needed, various repairs are attempted.
• Checks if Windows Installer is working properly. If needed, various repairs are attempted.
• Checks if the administrative shares (Admin$, C$, IPC$) exist. If needed, various repairs are attempted.
• Verifies the local administrators group is populated with a specified domain group. If needed, various repairs are attempted.
• Checks the free disk space of the drive where the operating system is installed.
• Checks the free disk space of the drive where the SMS cache resides.
• Checks if the active network interface card (NIC) is configured properly.
• Searches Active Directory for the site code and site server that the system should be reporting to.
• Verifies the SMS or ConfigMgr client is installed and operational. If needed, various repairs are attempted. If it is not installed, various attempts are made to get it installed. I'll expound further on the scope of these checks in another blog post, but some of them are listed below.
• Checks some SMS client registry and file system security settings. If needed, various repairs are attempted.
• Checks to determine if the client software was improperly prepared and included in an operating system image. If yes, the SMS client is uninstalled and then installed (via CCR or direct install).
• Checks if the client is assigned to an SMS site. If not, various repairs are attempted.
• Checks if the client is assigned to the correct SMS site.
• Checks for some missing client logging registry entries. If needed, various repairs are attempted (usually by uninstalling the SMS client and reinstalling).
• Checks if the PolicyEvaluator.log file has been updated recently. If needed, various repairs are attempted.
• Checks if the client has Software Distribution enabled. If needed, various repairs are attempted.
• Checks if the client has the required default policies. If needed, various repairs are attempted.
• Checks if the client has any advertisements. If needed, various repairs are attempted.
• Checks if the client is running patch scans.
• Checks if the client can communicate with its Management Point (MP).
• Checks the client cache folder and cleans out any entries that are older versions, entries that are not referenced by an advertisement, entries that haven't been referenced in a specified number of days, and any entries that don't have a cache folder. Also, any cache folders that don't have a cache entry are deleted.
• Checks if a reboot is pending (using WUA and the PendingFileRenameOperations registry entry). If yes, a reboot is initiated if A) no user is logged on, B) no files are open, and C) no installs are running.
• Sends a error log to a central server for reporting.
• Writes various entries into the event log indicating health check starts, stops, and repairs.
• Many settings are currently defined in a .xml settings file. I'm thinking of also writing a GPO add-on for this at some point too so settings can be a bit more dynamic without having to edit a file that needs to get pushed out.

How the Health Check Tool runs repeatedly

When the health check tool runs, it has the capability to add itself to the system task scheduler list so that it can re-run every day without requiring the system to be restarted.  This allows a non-functioning system to make it through the various levels of repairs sooner and hopefully get back to functioning properly.

I have recieved a few correspondences where some folks have shared what they are currently doing for system health checks.  There's two though that said they would share what they had, but must have ....COUGH..... forgotten to send it over.

Feel free to send me an email if you want to share your ideas or try the beta version when it gets a bit further along in testing.

Posted Wednesday, August 04, 2010 9:55 PM by dthomson | with no comments