Client Activity History
Summary: client activity must be considered in the context of history - especially your organization's client activity history. That may be the only way to distinguish between behavioral issues and technical issues.
As I've often said, problematic computer management clients will give much the same symptoms in 3 circumstances: server-side issues (I usually lump environmental issues in here as well), client-side issues, and offline clients. That offline segment could be very large but is the hardest to measure (because clients don't reliably announce when they're going offline). Server-side issues are easier to find and quantify, but given the diversity of server-side issues, they're not easy to quantify either. So the issues we want to manage as client health managers (broken clients) are especially hard to quantify.
A question I was investigating today gives a good example. I was looking at client activity for the last few years for our biggest population (big populations are nice in that they are less subject to the trivial little issues that throw off small populations). There's lots of ways to look at client activity over time, which soon gets messy, but I tried to look at the most significant perspective - software distribution (which for SMS 2003 includes patch management). My graph is:
In a basic sense that may look like a boring, basically straight line - who cares? But there is plenty of meaning in it. It tells us how many of our clients have run any software distribution in the last 2 weeks as of each day. You can see that's been quite constant around 85% for pretty much all of the last 3+ years (1129 days) - that's good in it's own right; things don't change a lot over time, for any reason. If we send out an advertisement now it should hit 85% of our clients in the next two weeks, as they always have (the rest of the clients are offline or broken, with the great majority being offline). It's important to be able to say that because it might be non-intuitive but the history proves it. We can see the variances from that norm have been a little more dramatic over the last 200 days as compared with the previous 400 days, possibly because the population is smaller as we moved sites from this hierarchy over to a SCCM 2007 hierarchy or because a lot of effort has been put into the SCCM 2007 environment and thus less into the SMS 2003 environment during that time. And in our first year you can see we had our greatest variances - possibly because the population was even smaller back then but also because our organization was maturing as a computer management organization.
A similar analysis can be done using the history of particular site. It has 31,000 clients (big enough to be interesting, but not huge) and is SCCM 2007. I've only been collecting client activity data at the site level for half a year, so it doesn't go so far back.
You can see this site's client activity has been good in the last month, and not bad in the last 50 days. The last few days have been slightly off, due to a known management point issue (we dogfood a lot, so we will see such issues). What happened between days 75 and 120? Simple: Beta 2 - that's really why we dogfood - so you don't see such challenges. Prior to that its client activity was off and on, but it was a smaller site back then and those were even earlier dogfood builds. The first 21 days were SMS 2003, to serve as a baseline.
The main point of comparing a site vs. a hierarchy is that you'll see that any given site will vary more dramatically than a hierarchy. Partially that's statistics - small populations vary more than big populations. But it's also because any given site will have a more nuanced history.
The conclusion from this blog posting should be: don't just measure today's client activity, but also keep track of it so you can graph it. Then you can analyze the trends. Be sure to remember the relevant events, and allow for the rules of statictics. (I'll post some details on how to save and use data in a future posting, but in the meantime a spreadsheet will suffice)
p.s. My apologies for not blogging more recently. With summer temperatures finally hitting this part of the world I've been trying to find time to do things I remember enjoying other than computer management (including things other than dogfooding). That's easier said than done, but I'm trying...
Update: this post used to be titled "Client Health History", and in fact for years I did refer to the data described here as "client health" data. In a sense it is, but more specifically it indicates activity of healthy (or partially healthy) clients. It doesn't tell us anything about unhealthy clients (since they can't report activity). That's a distinction I've often had to tell people, but even better is to use precise terminology in the first place - it's much less confusing. So "activity" data is only a subset of "client health" data. There's other client health data, such as details about broken clients, that is not activity data.