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.
Those of us that have been in the ConfigMgr (SCCM/SMS) business for a while have had the joy (and challenge) of learning the new versions as they’re developed and then released. There are many approaches to that learning curve, and I’m a fan of all of them. You can learn top-down, meaning you review the marketing and product documentation that highlights the differences and then focus on whatever details are relevant to you. You can experiment with the new version, seeing how it works, what’s changed, and what’s challenging - that’s a middle ground approach to me. And then there’s the bottom-up approach of looking at the technical changes and trying to understand why they were made and how you can use them.
For some reason I actually like the latter approach most of all. By seeing the technical implementation details I can understand what’s really changed. A good example is log files, both client-side and server-side. If a new log is introduced and it has some substance, then that must be an important component, and it must add some important functionality. The high-level details give us the context of that importance, but the low-level details give us the clues to make it work well.
As I’ve mentioned in the past, the first moment at which I fell in love with ConfigMgr was looking at the database. That’s hard to explain, but I still maintain that ConfigMgr is a data-centric system and thus the database is very important. When I’m learning a new version of ConfigMgr, I start by focusing on the database changes.
An easy approach to looking at database changes is to fire up SQL Server Management Studio, connect to your new ConfigMgr database, expand the Views node, and look for changes. With up to 1,000 views that’s problematic, though you can ease the process by ignoring the collection views, inventory views, and ‘secondary views’ (those that seem to be intermediate views). But that all depends on your memory of the previous version’s database schema and what’s important, so it’s easy to miss fun new views.
Another alternative is to query for the differences. Those queries (assuming you’re doing them from the database server with the previous version) would be:
-- lost views
SELECT * from sysobjects where type='V'
and name not like 'v_CM_RES_COLL_%' and name not like '_RES_COLL_%' and name not like 'v_HS_%'
and name not in
(SELECT name from [new_version_server.new_version_database].dbo.sysobjects where type='V'
and name not like 'v_CM_RES_COLL_%' and name not like '_RES_COLL_%' and name not like 'v_HS_%')
order by name
-- new views
SELECT * from [new_version_server.new_version_database].dbo.sysobjects where type='V'
and name not like 'v_CM_RES_COLL_%' and name not like '_RES_COLL_%' and name not like 'v_HS_%'
and name not in
(SELECT name from sysobjects where type='V'
and name not like 'v_CM_RES_COLL_%' and name not like '_RES_COLL_%' and name not like 'v_HS_%')
order by name
You’ll notice the queries ignore the collection and hardware inventory history views. Collections are a constant and I’d rather compare hardware inventory changes by looking at the SMS_def.mof changes.
The lost views will likely be a manageable number but the list of new views could be quite numerous, depending on how big the version differences are between the versions you’re comparing. Service packs are likely to introduce few changes, major versions will introduce a lot, and minor versions will be somewhere in between.
If there are a lot of changes then you’ll want to do variations on the above queries, filtering out groups of views as you understand them. Views do often have naming conventions that group related views to each other and so if you understand the significance of the group then you can eliminate them from your list of views to study.
Admittedly, interpreting what a new view adds can be tricky. The name of the views and the columns will give clues. Doing queries against the view when it’s got some data will help further. To a large degree you just have to follow your instincts and focus on those that seem most interesting. And this is just one way to learn the new version, so don’t spend too much time focusing on this technique.
Finally, you might ask what can be seen by using this technique to compare ConfigMgr 2007 with ConfigMgr 2012. My suggestion is that it’s too early to jump to conclusions. ConfigMgr 2012 will change as time goes on (otherwise it would be released already). Exciting view changes are blog posts for future dates.
p.s. I focus on views here, as opposed to tables, because views are what we have always been encouraged to use as ConfigMgr customers. Generally that works, but sometimes there are interesting table additions that don’t get reflected in views. For that reason you may want to also look at tables, but that’s an easy extension of the above concepts.
Throughout my career I’ve been amazed by the diversity of the environments that you and I work in or serve. People sometimes ask why computer management is often so complex, but to me the answer is simply that there’s no one-size-fits-all solution. That’s part of what makes this field so much fun!
Furthermore, each of the variables is a scale, with different organizations falling at different points in each dimension. In no particular order:
- size by count of clients - 100 clients to 300,000+ clients
- size by number of server sites - 1 site to 18,0000 sites
- size by number of locations – often much more than the number of server sites
- size by the size of individual sites or locations - 2 clients to 10,000 clients at an individual site or location
- 'stability' of clients - all users at designated, fixed machines to many users swapping many machines and often on the road at many locations (possibly connecting by various means). Rebuilding machines or having multiple clients per user can further complicate this variable
- features used - such as inventory collection, operating system deployment, software distribution, patching, remote control, software metering, and configuration management
- sophistication of feature use - out of the box defaults to highly customized inventories, extensive reporting, numerous and fancy packages, etc.
- network complexity - no links or all good links, to a mish-mash of link types, including complex scenarios such as satellite links
- administration and engineering organization – one unit, centralized and working well together, to many units, decentralized and centralized, not working well together
- business organization (stakeholders) – centralized to many business units with widely varying goals, philosophies and needs
- security - out of the box, generic to highly locked down with third party tools and complete paranoia
- domain/forest models - one domain to multi-master domain model, or multi-domain model
- administration and engineering sophistication - barely know what they're doing to gurus with programming skills ready to change or fix anything
- management support – “don’t screw up”, to “I trust you, and if the users give you a hard time – why don’t they take computer management seriously?”
- sensitivity to problems / risk tolerance - go with the flow to it must work first time, every time, forever
- history - starting clean, or heavily invested in a competitor, to heavily invested in ConfigMgr
- vendors - pure Microsoft shop to mix of Microsoft, Linux, 3rd parties, etc.
- hardware – all one kind of high-end PCs/laptops to a mish mash of low end to high end PC's from various vendors plus Apple. Devices further complicate this story
- operating systems – mostly XP or Win7 to a sprinkling of everything ever offered
- budget - money is not an object to do it all for free (or get the vendor to pay for it)
- management wisdom - total wisdom to hasn't got a clue
- time frame - take the time it needs to “you've got until Friday”
- experience doing projects
- job security – cover my ass and hope for the best, to let’s make it happen and I can handle the risks
What other variables would you add?