SCCM 2007 – General client troubleshooting tips

I will preface this section with an admission that this is *not* client-specific, or even specifically related to Configuration Manager. It is as it says “General”, so technically it still applies. These are some of my personal “standard procedures” that I follow. These tips have never failed me, so I hope they are helpful to you as well:

Contents

Standard guidelines
Standard procedures
What SCCM 2012 changes
Final thoughts

Author
Recent Posts

David Stein

David is an author and consultant, working for Endurance IT Services in Virginia Beach, Virginia, specializing in Microsoft enterprise systems and Business Process Automation.

Standard guidelines

1. Know your environment! If you are trying to deploy something as complex, pervasive and challenging as Configuration Manager into an unknown, murky environment, then you are only asking for trouble. I know it’s not always possible to walk into a situation with complete command and control over the circumstances, but if you are being expected to solve a problem that begins with a bad implementation (beyond your control or purview), then you might want to consider another job.

2. Look for patterns. Approach every incident by gathering enough facts to identify the scope of the problem. In the years I’ve been working in IT (roughly thirty), this has helped point to the root cause of a problem much more quickly and reliably than any other approach. Some example questions to ask:

Does the problem affect ONE user, or ALL users?
Are the affected computers in the same subnet, or sharing a common switch or router?
Are the affected users or computers in common AD groups?
Do the computers share a common (and unique) software application?
Do they share a common hardware driver?

There are many more questions like these, but the general idea is to find a common thread that might lead to solving a bigger problem. If you focus solely on diagnosing and repairing just one computer you might miss the real problem entirely.
A case in point: One of my customers reported that eight of their computers just stopped reporting into the MP and were no longer getting advertisements. After working through the above checklist, it turned out they were the same hardware model and received the same driver update at the same time. Once we isolated that, we were able to roll-back the driver update and obtain a newer, corrected version from the vendor to resolve the problem.

In yet another case, a network engineer modified a DHCP scope that knocked a group of computers out of the Configuration Manager Site because the new subnet was not part of any Site Boundaries.

3. Inspect the logs. If an obvious pattern doesn’t emerge, the next places to look are the logs. Windows Event logs and Configuration Manager log files. In fact, the colleagues who know me well would concur that my first question to a technician who approaches me with a difficult issue is “what do the logs show?” If I get that confused look, or a response that indicates they haven’t bothered checking the logs, I tell them to go back and do their homework.

4. Know when to get help. Everyone in the IT field today feels increased pressure to “keep up” and become a master of at least a handful of products and technologies they deal with. That doesn’t mean you have to, or even should, try to solve every problem alone. If you’re not an expert at some particular aspect of the issue you are trying to diagnose, don’t waste time during a critical situation trying to become the master of it if you can reach out for help. If you don’t have the luxury of a team that you can depend on for assistance, that’s one thing. But if you work within a team that possesses skills that can help you solve a problem in less time than trying to tackle it by yourself, do yourself and your customers a favor and ask your teammates for assistance.

Generally speaking, and I know this is very general, most customers who find themselves in a situation where they have grown to a scale that encourages them to pursue something like Configuration Manager, are already running desktops and laptops which are on supported hardware. The most common issues tend to be software-related, but this is obviously a generalized statement. If you find that either (A) you do not know for sure what your environment can support, or (B) you know it has some deficiencies: Address those issues first, before even considering something like Configuration Manager. And if you’re told you don’t have that choice, well, you always have a choice to move on. As one of my customers likes to say: “If you don’t have time to do it right the first time, how will you have time to go back and fix it?”

Standard procedures

Aside from the “General Tips” above, here’s a fairly simple and consistent recipe for troubleshooting problematic client agents:

Verify network connectivity
1. TCP/IP stack
2. Name resolution (DNS, WINS)
3. DHCP environment
4. Firewall settings
5. Router and Switch settings
Verify client agent installation
1. Version
2. Actions (Control Panel applet)
3. Web Reports
4. Client Logs
5. Site Server Status Reports and Site Server Logs
Verify client agent settings and policy updates
1. a. Client Logs
2. b. Web Reports
3. c. Site Server Status Reports
Verify Site Server Operations
1. Site Status Reports and Alerts
2. Web Reports
3. Site Server Logs

As always, one more place to look is the Microsoft TechNet Library. In particular, there are two high-level pages which provide an index for helping you resolve problems with Configuration Manager 2007 using methods which are officially “supported”:

The first link above provides additional links to troubleshooting procedures, while the second link provides links to workflows (flow charts) that walk you through sequential processes for each general type of technical issue related to Configuration Manager 2007.

What SCCM 2012 changes

Configuration Manager 2012 brings a huge improvement to Client health management. For starters, it installs additional tools and services on each client to self-monitor and self-repair the client when something starts going bad. This alone removes a huge portion of the headaches that 2007 clients can create for an administrator. Just a few of the well-known issues that 2012 remedies include WMI stack issues, service faults, faulty or corrupted dependency components, client updates, and so forth.

Microsoft has published quite a bit of information about these improvements, which I strongly recommend to any Configuration Manager site administrator.

Final thoughts

I realize that by focusing on client problems, that it may paint a bleak picture of the product itself. That’s really unfair and it isn’t my intention either. I could compile a list of problems for any software product, and in many cases: a much larger list. That doesn’t mean that you are likely to encounter those problems, or that they are even critical “show-stoppers” for a successful project implementation. Just as discussing possible diseases does not mean that the human body is a faulty product; problems can develop when things aren’t managed properly.

Configuration Manager is a very powerful and very capable product, and it only gets more powerful and more capable with each new release and each new update. As such, it demands a high degree of careful planning, thorough testing, and precise implementation if you expect to achieve a successful and well-performing result. But once implemented, as with any pervasive infrastructure management system, it requires meticulous oversight and care in order to keep in optimal condition. I hope this article helps you find and solve client issues in your environment so you can get your Configuration Manager sites functioning at their optimal level.