Joking aside (for a few minutes anyway)…
The five (5) most common root causes for SCCM site issues that I’ve seen over the past year, working as a consultant.
- Site scale: (smallest) 500, (largest) 180,000
- Site types: CAS (5%), Primary alone (85%), Primary with Secondaries (5%), None (5%) aka “new install”
- Avg staffing: (IT dept) 12-24 (SCCM admin) 1
- Avg coffee consumption: 1 cup per 30 minutes
- Avg sleep: 5.2 hours
1 – Lack of planning before installing the environment
In the past year alone, I’ve run across almost a dozen sites which had a CAS and didn’t need one, or Secondary sites, and didn’t need them, and so on. Some didn’t have a FSP and could’ve used one. Some weren’t using the appropriate credentials for client installations, network access and so on. And lately, many seem to have pinned their plans on outdated platforms, such as Windows Server 2008 R2 or SQL Server 2012. At least keep them patched (e.g. SQL 2012 SP3 CU9)
2 – Lack of monitoring and following-up on warnings/errors
Of the last 24 customer engagements I’ve been involved with, roughly 60% do not keep a daily watch over site issues (sites, components, clients, content distribution, deployments, etc.). Of those that do monitor, about half ignore lingering warnings which impact site performance.
3 – Lack of cohesive management
This varies by scale/size of the organization (at least in my world). Often it’s a matter of job roles and organizational divisions. For example, DBA’s controlling the SQL Server environment without allowing SCCM admins any direct access (very bad). Or AD admins who drag their feet (or push back) on requests for schema extensions, keeping AD accounts “clean” and so on. Or Network Admins who fight back against using PXE, no matter what the rationale. In many cases, it rolls up to team managers who don’t work well together, so resolving conflicts and barriers is difficult, especially when the CTO or CIO prefer to avoid dealing with it. My advise: deal with it! The good of the company outweighs your stupid personal disagreements.
4 – Lack of keeping up on updates
Whether it’s the Windows Server, SQL Server, ADK, MDT or Configuration Manager itself, all of these require persistent support and oversight. Keep them patched. But more importantly, READ THE PATCH details first. Understand what’s being “fixed” or “modified” (or deprecated) as well as “known issues”. You can save yourself a shit-ton (that’s a scientific measurement, by the way) of headaches and support costs by not blindly installing without understanding. However, do not avoid patching simply because of fear and doubt. You work in IT, which means “change” is inevitable and continuous. It’s why the “soft” in “software” exists (trust me, Babbage wasn’t kidding around).
5 – Inefficient use of features
This one alone could be broken out into sub-categories actually, and now that I mentioned it, I will…
a – Ignoring features which are not fully understood (not doing research)
b – Continuing to use outdated methods (disk imaging, for one, like Acronis or Ghost)
c – Ignoring other System Center capabilities (SCOM, Orchestrator, etc.)
d – Not following “best practices” (excessive permissions on common accounts, incorrect client installation settings
e – Paying for 3rd-party products which SCCM (or other System Center) capabilities could provide (depends upon the individual requirements of course)
f – Ignoring 3rd-party products out of fear of the unknown (FUD)
g – Ignoring new features added with each build (current branch), such as Azure, OMS, UA, and mobile device features
h – [my peeve] Inefficient mapping of tools to processes. Such as ignoring Group Policy in favor of doing everything in SCCM or via scripts. Continuing to use familiar solutions even when newer and better (cheaper, faster, more efficient, more reliable) solutions are available.
i – Insufficient use of Internet search tools (Google, Bing, etc.)
Did I miss anything?