SMS Client Health can be at many times a daunting task. If you are a very small group managing the workstations it may become almost impossible to keep on top of clients that may have become unhealthy at some point.
This was true of our environment. As it grew from 60,000 to 90,000+, our team head count did not necessarily match that same growth and the Client Health Collections allowed us to automatically Identify Client Health issues and remediate them with as much automation as is possible. This SMS Client Health Structure is the design of Microsoft Premier Field Engineer Christopher Sugdinis and was implemented in our environment with great success. He has also implemented the similar customized processes for other Microsoft Premier Customers. Rodney Jackson has also presented Chris’s documentation on this topic at MMS 2006 and MMS 2007.
My intention here is to give a basic overview of the SMS Client Health collections structure as Chris has helped us to implement. I believe that this has helped us so much that I can not help but to share how valuable and cost efficient it has helped our team to be. I am sure it will benefit greatly anyone who implements even the basic levels presented here. I do also believe very strongly that anyone would benefit from being a Microsoft Premier Customer and though this documenting of it may steal some of their thunder, I believe that anyone whom brings in a Microsoft Premier Field Engineer with a specialty in SMS will be able to further enhance anyone's implementation of an SMS Client Health Collection Structure.
What is Client Health?
The SMS Client Health Collections structure that is documented here is simply a group of collections each based on the previous and progressively identifying possible pain points in an SMS client's health and or Functional milestones. You might think of it like one of those decorative water fountains with multiple levels. As each system comes in on the top of the water fountain, it gets either caught/filtered before it can go onto the next level in the fountain. Once the workstation is processed through all of the levels, it is confirmed as a "Health" 
workstation that meets the standards in place within the environment.
Why have an Client Health?
Most environments are Dynamic in nature. I call ours a "Breathing, living entity" because the systems always are changing. Examples that make them Dynamic and change the systems include;
-
Reimage workstation
-
Security patches
-
Computer account moved to different Domain as part of a migration
-
Software installed/uninstalled by SMS, User
-
SMS Client underlying dependencies
-
WMI version
-
WMI Damaged
-
WMI hotfix needed
-
XML version
-
WU Client
Additionally you may have some level of Configuration standards that you want to maintain. Some examples;
-
Operating System
-
Service Pack Levels
-
Hard Drive Free Space
-
Anti-Virus present
-
MOF Version applied
What can I do with a Health Structure?
Once you have established a base structure, you will find that as you identify pain problems that you will want to add additional checks into your health structure. As you do this, your structure will become larger. You will have to determine specifically for your environment what is to be done with these problem areas. For instance, you may need to just report to the field tech's the systems sitting in that area and instruct them on the resolution. Or you may be able to target that group of systems with SMS for remediation; it is up to you at that point how to remediate the areas.
What do I do with it once I have it?
With a health structure you have a couple of things you can do.
-
You may want to base all of your other collections on the ending healthy collection. That way you are not targeting systems that are broken, obsolete, or not complying with standards. As your systems are remediated, they will flow through the health collection structure. Then as your other collections update, they will become targets for your production advertisements. This assures that your only managing healthy workstations and only those specific systems that meet your client health requirements.
-
You may want to just use this for working through clients that are unhealthy and be able to identify key problems. Using these collections, you may also find that some sort of application is now breaking the SMS Client! In my case, we use it for both.
How does this help the SMS Administrator?
Previously the SMS administrator may have had to add complication to a collection query, like Client = 1, OS = Workstation, obsolete=0 and so on before even getting to the core of the desired adjustment. Each SMS administrator may not have known the entire core things needed and as a result may have been trying to advertise to system that are not healthy or no longer exist.
Now with all of that filtering being handled in the Health structure, the SMS Administrator can focus on the Project at hand while relying on the health structure assuring all of those basic checks have been handled.
What does it look like?
This is a small view of the beginning of our health structure, there are a great many that are not shown as we have added specific criteria to meet the needs of our diverse environment;
Is there anything to be concerned about implementing this?
Well as with everything done within SMS, there is an impact. How much there is will depend entirely on your configuration. By default, any collections you create are set to update during the time of day when the collection was created. Since most collections are created during business hours, you may already have many collections updating during peak business hours. Before implementing this process, all collection schedules that can be adjusted should have their collection schedules adjusted so that they update during off business hours. By reducing your existing colleval workload during the day, you can safely implement additional collections that will update quickly and efficiently.
Before you implement each of the collections, you should watch the collection evaluator log (colleval.log) to make sure that your existing collections, do not take an abnormal amount of time to complete. Also do this while creating the new Client Health related collections. This is or should be a regular part of the SMS Administrators process (making sure that excessive collection updates are not causing backlogs on the SMS Server) but it has to be said none the less. The underlying client health queries are very simple and run every 12 hours in our environment so we have found that when we did experience colleval issues, we could resolve the problem just by moving other preexisting collection schedules to off peak hours.
The Collection update cycle timing is critical.
Your timing of the collection updates should flow from the first collection through to the next. Leave a gap in-between them of at least 5 minutes or more, otherwise you will find them waiting for each other to complete thereby walking on top of each other and in some cases causing them to fail to update.
Don't get wild with the collection update frequency, once a day may be sufficient while you are working out the nuances of your environment. Other environments and configurations may be able to handle a more aggressive update cycle, it is something you as the SMS Administrator are going to have to watch and adjust to match your configuration and environment.
If you are at all concerned about implementing this in your environment, bringing in a Microsoft Premier Field Engineer with a specialty in SMS will be well worth its weight in gold.
OK, enough with the blah blah, how do I get started?
A couple of key points here;
-
This will be built by creating a series of 8 collections in this example.
-
This example is not intended to be a complete work, it will give you a starting point only. In our production environment we have over 75 individual collections in our SMS Client Health structure, so keep in mind that this is only a starting point for you.
-
This example will be assuming the criteria of;
-
Windows XP Workstations
-
Client installed
-
Client is not Obsolete
You will for this process need to start the SMS Console in a mode that will allow you to find the collection ID values easily. You can do this by editing the SMS Console shortcut adding "/SMS:NodeInfo=1" to the command. Example: E:\SMSADMIN\bin\i386\sms.msc /SMS:NodeInfo=1
Now open the Console in the special mode. After creating each collection, right click the collection and get properties. There will be a new tab called Node Information. Find the Store Name, that is the collection ID as shown below;
I am going to use COL00AXX here as example, you will need to modify to suit your situation. We usually put the CollectionID in the name for easily finding the collection ID later on and will be BOLDED to make it stand out.
For each category, there are 2 collections. Good/Bad, In Scope/Out of Scope, Healthy/Unhealthy. Each set is based on the previous set's Healthy collection results, that Healthy, In Scope entry will be Bolded.
Collection #1 (The In Scope side)
Collection #2
Collection #3 (The In Scope side)
Collection #4
Collection #5 (The Healthy side)
Collection #6
These last 2 are the end of the Health structure as a sort of summary of the health collections structure.
Collection #7 (The Healthy side)
Collection #8