Paul Thomsen at myITforum.com

Summary: my recent posting on "defining client health" was inspired by various conversations I've seen or had recently along the lines of 'how successful are you?' Rod Trent has posted a couple of surveys to that effect that really help to visuallize the points made in those discussions. For me, they lead to thoughts on client health (of course ;-)

Rod's results so far are:

Those polls (with the latest results) can be found at the following URLs. If you haven't entered your success rate, I encourage you to do so.

http://www.myitforum.com/absolutepm/polls/smssoftwarepoll.asp

http://www.myitforum.com/absolutepm/polls/sccmsoftwarerates.asp

The poll results raise some obvious questions:

• how big are the sample sets? (how many people have entered their data) - small sample sets have a larger risk of being unrepresentative
• what kind of organizations do they work for? (big, small, new, experienced, etc.) - this typically impacts how much time they can afford to spend to clarify details, and how many complexities they face
• did everyone filter out offline clients, obsolete clients, etc? (which obviously can't receive software distributions)
• how long do they allow for the success rates to be achieved (or do they factor time into the calculation)? There are good reason why success rates are low in the short run and better in the long run
• what do they mean by "success rate"? (I suspect there's a few different definitions - including or excluding package issues, offline clients, operational issues, etc.)
• are they satisfied with their sucess rates? - is 95% always bad?

Those are pretty serious variables for any data set, so it's hard to draw conclusions. But the results are reasonably consistent (the polls were done in different months), and given the percentage fractions, size of the myITforum community, and typical poll return rates, I suspect we're seeing the results from dozens of organizations. So it's not unfair to draw some conclusions.

My conclusions:

• a fairly high fraction of administrators aren't satisfied with their software distribution success rates - maybe one half
• my assumption is that half of those below 97% success are unhappy with their succes rates, and we can see two thirds are below 97%
• some of those with 97% or a little better are also unhappy
• that's based on the assumption that IT administrators and managers generally like success rates like 99%, 99.9%, or even 99.99%. 98% might be understandable. Below 98% would often be frustrating. Of course they're often comparing apples to oranges (data center server uptimes to user computer software distributions, for example). But IT people believe the world is very deterministic and quantifiable
• client health, in the broadest sense, is a factor for some people - maybe one quarter
• my assumption is that some of the half have well defined metrics, have investigated the issues, and come to the conclusion that it's often client-side problems

 But there are some conclusions we can't make (though we might like to):

• are bigger organizations more sensitive to client health issues than smaller ones are?
• is anyone willing to invest in their client health strategy (and thus their software distribution success rates)?
• is the current software distribution and client health guidance (documentation, reports, etc.) sufficient for people's needs? (i.e. are they satisfied with their understanding of the success rates they're seeing?)

That's where your comments come in. Anecodotal evidence isn't the best, but if we hear more or less the same story over and over, conclusions can be made. So make some noise! Clarify the story.

p.s. I don't have any data for products other than SMS or ConfigMgr, but I don't see any reason why other systems wouldn't see similar success rates. The problem is not that SMS and ConfigMgr are hard, but rather that computer management is hard. It's the nature of the beast.

Summary: "client health" is the art of accounting for all your computers. Further, it includes maximizing the success of your computer management services by fixing any health-impacting problems you find.

You don't have to run a computer management system for long before you become aware of "client health" issues. You might not call them that. At first they'll just be questions, and you may wonder if you're doing something wrong. People may question your competence. But a little investigation will indicate that most of the time there are good reasons for the issues. So then it becomes a challenge of defining what "good" looks like for your organization.

Your first exposure to client health might be when you distribute a key piece of software to all your clients (say 10,000 of them). You check back a few hours later and several thousand have run the advertisement (assuming you trusted it enough to send it to everyone all at once). A day later, two thirds of the clients are upgraded. A week later 90% are upgraded. As times goes on you get very few more clients. So what happened to the rest? Initial invesitgations confirm you set everything up correctly and your servers are working properly. You've entered the client health zone...

Similar issues will become apparent when you do patching (software updates). Or check a report for inventory details. Any computer management activity will show that getting 100.0% accountability is challenging.

Eventually you investigate the missing clients, find issues, fix those that need fixing, learn how to divide clients into the various health states, and institutionalize the whole process as a client health strategy.

Someone will soon ask "why does my computer mgmt system need a client health strategy?" There are plenty of other kinds of clients, after all. You don't have an e-mail client health strategy (as for Outlook). You don't have a web browser client health strategy (as for IE). You don't have a client health strategy for your line-of-business applications. But the difference is that those systems are very interactive with the users. When they don't work, the user knows it. If possible, the user will fix it. If not, they'll call the helpdesk and get it fixed.

In some cases users will rely on the computer mgmt system to receive software. But generally they'll use the same software for a long time, so they might not notice that a computer mgmt client is broken. Or some diligent users might notice that they haven't received new patches after a Patch Tuesday. But generally it's going to be up to us as administrators to proactively manage client health.

So that's what I call "client health". Other postings in this blog dive into various details, and there's plenty more to say about it. But the first question is: do you agree? Do you call this "client health"? Is there more or less to it than I suggest?

Summary: understanding the problems client health management reveals is crucial, but there are other disciplines that are also essential to fully managing client health.

In a recent blog posting I presented my 'buckets of buckets' perspective of client health management. The basic idea is that the more you drill into computer management client activity and client health numbers, the more you need to know. Each bucket of clients can usually be subdivided into several buckets. And on it goes.

I hope that 'buckets of buckets' concepts help, but it's important to remember that there's still more to client health management. I picture the other related disciplines as:

(click on the image for a full-scale, high clarity version)

The orange clouds could be considered client deployment disciplines, rather than client health disciplines. But client health is done in the context of the clients you have or should have, and the people that require excellent client health probably don't care whether the issues are deployment or health related. Further, duplicate boundaries (a typical boundary management problem) can cause content location problems just as much as they cause site assignment problems, and that would adversely affect key client activities.

And as discussed before, computer health (AKA desktop health) isn't client health, but the two share so much that I advocate keeping them together.

So I view the related disciplines as:

• reporting - collecting data that accurately assesses your client health state and reporting it in a meaningful form
• remediation strategies & tools - how you're going to fix the problems you find
• investigations - diving into the details (often looking at individual clients) to confirm the numbers, understand the root causes, and verify the best solutions
• guidance - understanding the art of client health management, and explaining it to your internal customers
• tool monitoring and maintenance - keeping the whole solution running smoothly

The possibly related disciplines are:

• deployment management - getting the computer management clients on all the computers they should be on
• exception management - limiting computer mgmt client deployment from any computers that require exceptions, and tracking those numbers
• asset management - understanding the computers that are coming into and being decomissioned from your organization, and possibly their movements
• boundary management - managing the relationship between clients and servers, possibly including reassignment of clients
• computer (desktop) health - issues that affect the computer as a whole can also effect client health, and benefit from the same infrastructure for reporting and remediation

Do you agree? Am I missing anything?

p.s. To some degree I'm repeating what I said in a post a little more than a month ago, but I'm trying to find a better way to articulate those concepts.

Summary: capacity planning is an important part of computer management. Even computer management systems must be capacity planned. How do you know when it's time to add a server?

Well, if you're coming to work and find 9 construction cranes working on new buildings for your company, that's a good clue:

Ok, I'm really stretching to make this topic relevant to my blog. But I haven't seen the usual generic Microsoft blogs talk about this, and I think it's quite cool, so I hope you'll forgive a little tangent.

Construction cranes have always impressed me as a great sign of economic activity. Even of human optimism. You know things are progressing in the right direction when someone feels a need and the confidence to build a building. So it's especially exciting to find that every day when I ride to work I need to count the cranes - I'm often pleasantly surprised to find there's a new one. Bring on those users and their clients!

p.s.1 In the picture you'll only count 8 cranes, but there is one more to the far left, out of the picture but on the same site. And I suspect Microsoft has cranes working on its behalf in other parts of the world, but these ones are in my building's 'backyard'.

p.s.2. Actually, we have yet to determine whether our current sites will not readily take on the additional clients these new buildings will bring. There's about 5 buildings coming online here, and a typical building has about 500 users. At the usual user-to-computer ratios, that's about 6,250 new clients. That doesn't require a new site, or even an MP, but a DP or two might be warrented.

Actually, I was going no matter what, but I get to be a speaker, which is a huge honour.

Rod reports that the first (main) round of session details have been released. From the list, I see I get to do two sessions, as follows. I'm especially excited about the client health presentation. I've recently talked about client health management a lot in this blog, but that's a very disjointed conversation - in the presentation I expect to really pull the story together.

My second session is a traditional 'how Microsoft IT does it' session. There's a lot of people involved, so it's especially humbling to present that story, and it's always a popular topic. That will also lead to blog topics.

On a personal note: those of you that have known me for awhile will know that this is my 11th year of attending this conference, including 11 years of presenting at it (yes, I can prove it (even though "MMS" itself has only existed for about 6 years)). But I'm the first to recognize that doesn't guarantee I'll get to do a presentation the next year. I don't pretend to be the most eloquent presenter around. The people who make the selections (or have an impact on the selections) frequently change, so past goodness (if there is any) doesn't count for much. As a result, I spend several months each year anxiously awaiting the release of the list of sessions. So I'm very pleased when I get to see my name on it. I'm very thankful. Most importantly, I truly look forward to seeing you there - together at MMS we'll continue to advance the art of computer management!

Update: I'm also honoured to be be one of the 'experts' on the Panel of Experts session this year. That's this one: