If you want a really good client health check tool (scripts) then look no further, Dan Thomson has created the below after many years of working on it and developing,
cheers
niall
Project Description
There are many pitfalls with maintaining ConfigMgr managed systems so they install the client software and can continuously report to the hierarchy. This project provides a scripted solution that detects many issues and automates their repair.
The downloads locations:
* The scripts are on the Source Code page
* The Documentation is on the Documentation page and included in the source
Introduction
Poor system health…many have felt the pain and some are blissfully ignorant. Others however, are benefiting from a well run change management process and aren’t too poorly affected. Unfortunately, without a proper running operating environment, the Configuration Manager (ConfigMgr) client will face certain doom. This includes, at minimum, the inability to install itself on designated systems, a failure to discover its site assignment and receive policies, a lack of being able to report inventory or heartbeats, and not being able to process software and patch deployments. Where does that leave the intrepid administrator?
ConfigMgr has some in-built features that aid in identifying systems with issues. These mainly come in the form of reports. There also exist some third party add-ons and community scripts of various forms and thoroughness that attempt to identify and automate the correction of known issues. The community scripts are generally deployed by means of a Group Policy Object (GPO) computer startup script.
The Problem
As mentioned previously, the ConfigMgr client will have various issues if the hierarchy and the client system are not properly configured. Various other issues exist even when the ConfigMgr client is working properly. These include stale items remaining in the client cache, reported inventory being lost in transmission to the client’s assigned server, and so on. With the Health Check Tool, we are going to focus on the health of the client system and the ConfigMgr client itself. We want to make sure the client system is properly configured with its services; its environment (%Path%, %Temp%, and %Tmp% variables); its ability to install the ConfigMgr client; and for the ConfigMgr client to get policies, run inventory, and install software and patches.
Some of the issues can also be compounded by poor change management and unskilled administrators. Keeping up with client health is a daunting objective without an automated means to identify, report, and repair problems.
The Solution
Even though my environment now has one of the third party add-ons with a limited deployment base, there was a time when such a tool was not available. A co-worker and I were forced to create a solution by gathering the available community scripts and tailoring them into something that met our initial needs. That was a few years ago. Since then, I have been keeping up with the development and am now offering the solution to the community in hopes others can benefit as much as I do.
The solution being offered is an automated two step process (a third step is on its way in the near future). The automation for these steps comes via:
1. The Health Check Tool.cmd –a command script
2. The Health Check Tool.wsf –a Windows Script Host script
When these scripts run, they will record their activities to the %WinDir%\Temp\Health Check Tool.log file. Additionally, there is some tracking information written to the registry at the location specified by the RegistryStorePath option. This includes:
1. The name of the system the tool last ran on. This is useful if the client system turns into an image master or is renamed. If a change is noticed, the Health Check Tool will do a review of the EndPointQueues to determine if there might be a problem with the ConfigMgr client saving policies to WMI in future policy downloads.
2. The last date and time the Health Check Tool ran.
3. The last error codes that correspond to any detected known issues.
4. The last repairs that were conducted to fix known issues.
I opted to use this multi step process so I could overcome various hurdles. Some of these are:
1. Some systems are not able to run certain scripts because the Windows Script Host is broken for some reason.
2. Running the health checks too soon after startup could produce inaccurate results and will most likely interfere with the startup of the system and the ConfigMgr client.
3. The scheduled task allows the health checks to be run on a normal schedule without requiring the client system to be restarted.
We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.
If you want a really good client health check tool (scripts) then look no further, Dan Thomson has created the below after many years of working on it and developing,
cheers
niall
Project Description
There are many pitfalls with maintaining ConfigMgr managed systems so they install the client software and can continuously report to the hierarchy. This project provides a scripted solution that detects many issues and automates their repair.
The downloads locations:
* The scripts are on the Source Code page
* The Documentation is on the Documentation page and included in the source
Introduction
Poor system health…many have felt the pain and some are blissfully ignorant. Others however, are benefiting from a well run change management process and aren’t too poorly affected. Unfortunately, without a proper running operating environment, the Configuration Manager (ConfigMgr) client will face certain doom. This includes, at minimum, the inability to install itself on designated systems, a failure to discover its site assignment and receive policies, a lack of being able to report inventory or heartbeats, and not being able to process software and patch deployments. Where does that leave the intrepid administrator?
ConfigMgr has some in-built features that aid in identifying systems with issues. These mainly come in the form of reports. There also exist some third party add-ons and community scripts of various forms and thoroughness that attempt to identify and automate the correction of known issues. The community scripts are generally deployed by means of a Group Policy Object (GPO) computer startup script.
The Problem
As mentioned previously, the ConfigMgr client will have various issues if the hierarchy and the client system are not properly configured. Various other issues exist even when the ConfigMgr client is working properly. These include stale items remaining in the client cache, reported inventory being lost in transmission to the client’s assigned server, and so on. With the Health Check Tool, we are going to focus on the health of the client system and the ConfigMgr client itself. We want to make sure the client system is properly configured with its services; its environment (%Path%, %Temp%, and %Tmp% variables); its ability to install the ConfigMgr client; and for the ConfigMgr client to get policies, run inventory, and install software and patches.
Some of the issues can also be compounded by poor change management and unskilled administrators. Keeping up with client health is a daunting objective without an automated means to identify, report, and repair problems.
The Solution
Even though my environment now has one of the third party add-ons with a limited deployment base, there was a time when such a tool was not available. A co-worker and I were forced to create a solution by gathering the available community scripts and tailoring them into something that met our initial needs. That was a few years ago. Since then, I have been keeping up with the development and am now offering the solution to the community in hopes others can benefit as much as I do.
The solution being offered is an automated two step process (a third step is on its way in the near future). The automation for these steps comes via:
1. The Health Check Tool.cmd –a command script
2. The Health Check Tool.wsf –a Windows Script Host script
When these scripts run, they will record their activities to the %WinDir%\Temp\Health Check Tool.log file. Additionally, there is some tracking information written to the registry at the location specified by the RegistryStorePath option. This includes:
1. The name of the system the tool last ran on. This is useful if the client system turns into an image master or is renamed. If a change is noticed, the Health Check Tool will do a review of the EndPointQueues to determine if there might be a problem with the ConfigMgr client saving policies to WMI in future policy downloads.
2. The last date and time the Health Check Tool ran.
3. The last error codes that correspond to any detected known issues.
4. The last repairs that were conducted to fix known issues.
I opted to use this multi step process so I could overcome various hurdles. Some of these are:
1. Some systems are not able to run certain scripts because the Windows Script Host is broken for some reason.
2. Running the health checks too soon after startup could produce inaccurate results and will most likely interfere with the startup of the system and the ConfigMgr client.
3. The scheduled task allows the health checks to be run on a normal schedule without requiring the client system to be restarted.
download > http://configmgrclienthtc.codeplex.com/
Share this post
Link to post
Share on other sites