What does your baseline client activity curve look like?

The way your clients behave and how you would like them to behave are not necessarily the same thing. That isn’t always bad, but if you understand how they behave and can explain that, then you (and your stakeholders) can be reasonably confident that everything is under control. If not, then it’s time to do some investigation and possibly make some adjustments.

For example, the following two graphs are how two populations of clients report ConfigMgr heartbeat discovery:


You’ll notice the graphs are quite different. Part of the reason is that the first population has clients reporting heartbeat every day, and thus most clients report within a day, a good number more in two days, and the rest progressively over time. This would be reasonable for a client-base that is supposed to report heartbeat daily and is mostly powered up in the office each day (online to the ConfigMgr servers) with a small fraction of machines being mobile or being rebuilt over time. If that’s expected behavior, then all is well in this environment.

The second population has a small fraction of clients reporting in during the first two days, a quiet period (presumably a weekend), and then linearly more clients reporting heartbeat until day 7. From there the ‘laggards’ report in similarly to the first population, but at a slightly steeper rate. In this case the heartbeat discovery rate is set to 7 days, so that curve makes sense.

Both populations look to be reasonably healthy, in that a very high fraction of the clients report in within their expected heartbeat discovery cycles. When the heartbeat rate is set to daily then that conclusion can be reached more quickly, and any future disturbances in this curve would be caught more quickly. So it is advisable to use a frequent heartbeat cycle if possible (if servers and network allow it).

How can you produce a baseline client activity curve for your clients? The following SQL will do it for you:

declare @olddate datetime, @NullVal datetime, @today datetime
set @today=GETDATE()
set @olddate=DATEADD(day,-7, @today)
set @NullVal = CONVERT(datetime,'1/1/1980')

select datediff(DAY, AgentTime, @today) 'DaysAgo', count(DISTINCT Name0) 'Clients' into #temp1
from v_R_System sys full join (select ResourceId, MAX(AgentTime) as AgentTime from v_AgentDiscoveries where agentname<>'SMS Discovery Data Manager' AND agentname not like '%!_AD!_System%' ESCAPE '!'group by ResourceId) disc on disc.resourceid=sys.resourceid where client0=1 and obsolete0=0
group by datediff(DAY, AgentTime, @today)

-- thanks to http://www.sqlteam.com/article/calculating-running-totals for the basis of this part:
SELECT a.DaysAgo, SUM(b.Clients) 'Total Clients', a.Clients ' Daily Clients'
FROM #temp1 a CROSS JOIN #temp1 b WHERE (b.DaysAgo <= a.DaysAgo)
GROUP BY a.DaysAgo,a.Clients ORDER BY a.DaysAgo,a.Clients

Plug the results into Excel and produce the graph from there. Now you understand your clients better!

p.s. This kind of analysis gets really interesting when you compare key client service activities (such as patch installation, inventory reporting, software distribution status, etc.) vs. these baseline curves.  If any of those deviate significantly from the baseline, then there’s probably something wrong with those subsystems. The queries for that analysis are not very different from those above.

Published Wednesday, June 29, 2011 9:55 PM by pthomsen


No Comments