This is a sampling of the most common situations I run into with customer engagements. I haven’t followed-up my older “what I learned this week” articles, so this is sort of catch-up.
The following is intended for an immature audience. Mature people will likely fall asleep before completing this, and may require physical or electrical stimulation to regain consciousness. I am not mature, so I may fall asleep before you do.
1 – Software and Update Deployments with Maintenance Windows and Overrides
- You can deploy Applications and Packages to Device Collections and User Collections
- The Deployment itself has properties (attributes) assigned to stipulate the behavior (schedule, target, restrictions, exceptions, etc.)
- User and Device Collections can have Maintenance Windows assigned, which provide guard rails for drunken, passed-out, deployments
- Deployments can be assigned to respect or ignore Maintenance Windows, like a politician at a press conference
- Machines which end up in multiple collections with maintenance windows can easily become unpredictable
- Machines that end up in multiple non-contiguous maintenance windows can become a reason to drink
- People who place machines into multiple collections with unique maintenance windows may end up duct taped to a urinal at a bus station
- It’s easy to forget Maintenance Windows, or how they overlap and pile up on devices which end up in multiple collections
- Use maintenance windows sparingly
- Plan all of your maintenance window needs before you apply the first one
- Consider naming Collections to indicate maintenance window involvement (as well as the window itself: example = “Crappy Machines – MW – Fridays 5p-11p”)
- Consider custom Device Client Settings for roaming devices, versus stationary devices
2 – Operating System Deployments and PXE Panic
- You can target PXE deployments of OSD Task Sequences to Collections
- You can restrict the Deployments to recognize only existing ConfigMgr Clients, or “unknown” Computers (never been on your network or AD or ConfigMgr), or allow anything (both known and unknown)
- Targeting PXE OSD deployments to both known and unknown can be risky
- It is actually not easy to accidentally image production machines via PXE using SCCM OSD
- In order to “accidentally” re-image existing/known computers, you’d have to:
- Target the wrong Collection(s) with a…
- Zero-Touch (ZTI) task sequence, and…
- Select the wrong availability, such as allowing ConfigMgr clients, and…
- Set the Deployment purpose option to “Required”, and…
- Not have a PXE password enabled, and…
- Have the devices boot configuration set to boot from the Network first, and…
- Not know what you’re doing
- Not ask for help when you realize you don’t know what you’re doing
- Getting ready to quit your job out of anger at your employer
- Be careful with Deployment targeting
- Clearly name your Task Sequences so your worst technicians can still understand which ones to select
- Restrict access to Deploying Task Sequences (and anything else) if you work within a large team (tip: roles and scopes are your friend)
- Consider using a central or regional workbench process, with a local PXE responder (DP, etc.) on the same subnet, isolated from the production network on a common switch. The network team doesn’t need to be bothered
- Use a controlled password on your PXE responder (DP, etc.)
- Slip Xanax into the coffee pot near the network team (just kidding, don’t do that)
3 – Collection Limiting and Refresh Scheduling
- Collections with Query Rules are “limited” to being a subset of a parent Collection, called (queue the dramatic music) a “limiting collection”
- A limiting Collection restricts the scope from which the dependent Collection can see resources to consider as members. If the limiting Collection doesn’t contain a resource, the dependent Collection won’t be able to add it as a member
- A Query-Rule Collection will only refresh membership results as often as its limiting Collection. In other words, if the limiting Collection refreshes every 7 days, the dependent Collection can be set to 1 day, but will only update when the limiting Collection hits its 7 day cycle
- Query-rule Membership Collections with very short refresh cycles may impact site server performance, and may cause ripple effects which can further impact performance
- Avoid using a lot of incremental updates for collections.
- Be careful with Direct-rule Membership Collections and assigning refresh schedules
- Pay attention to Limiting Collections and their membership rules and refresh schedules.
- Consider tuning query rule collection refresh schedules during and after major changes to the environment only. For example, during OS migrations/upgrades, reduce the interval to get faster reporting updates, but after the bulk of activity dies down, increase the interval back to reasonable values
- If you’re not a DBA or DBD, go talk to one and ask for advice on query optimization techniques. They may look at you like an Ebola patient when you show them WQL, but free doughnuts or Empanadas, and coffee should calm them down again
4 – Accounts and Security
- ConfigMgr uses several security (user-type) accounts for various features. Each account is used in a unique and different way, for a unique purpose. Some are mandatory, and some are optional:
- Site Installation and Initial Configuration (Windows, SQL Server, AD)
- Client Push Installation (Workstations, Servers, Domain Controllers, Classified/Sensitive systems, etc.)
- Network Access / Software Distribution and OSD
- Domain-Join / OSD
- Build and Capture / OSD
- Remote Tools / Client Settings
- Roles / Accounts / Administration
- Discovery Methods / Administration
- Cloud Services / Administration
- Each account has unique access/privilege needs
- Accounts which are used by multiple (unrelated) systems often add risk of unexpected interruption by other users (password changes, account lock-outs, etc.)
- You can often control team access from application-level groups, or via AD security groups. Trying to manage it both ways often leads to unwanted results.
- Avoid using SCCM-related accounts for multiple purposes, even within SCCM
- Aim for dedicated, purpose-driven accounts, exclusive to what they’re intended for
- Grant each account only the bare minimum permissions it needs
- Choose a consistent manner by which to manage team access to tools and features
- NEVER share the use of a ConfigMgr service account with an unrelated system or process
- NEVER use a person’s own login account for a service account
- Avoid using a person’s own login account for building site systems
- Document everything, and track changes always
5 – Device Imaging, Naming and Provisioning
- If you don’t provide an explicit name for each device during imaging, the default name will suck
- Sucky device names make for a sucky day at work
- You can assign a unique device name to a bare metal imaging process using a variety of means within ConfigMgr:
- Collection Variables
- UDI form input, or tools like UI++
- Custom (script) form input
- Semi-Automated using external systems / third-party tools or custom development
- Completely Automated using internal data
- You can spend hours, days, even weeks on the perfect naming process
- There is no 200 level. Don’t listen to that other guy
- Strive for fully-automated, zero-input processes
- Watch out for forgetting Collection Variables while trying to implement other options at the same time
- Count the time you spend on device naming (if you’re not already fully-automated) and assign a dollar figure to that, tally it up weekly, monthly and annually. Then see if it saves you more than that somewhere else, and by how much. I bet it’s not saving you anything at all (dollar-wise)
6 – Guard Dogs and Anti-Malware Fences
- Anti-Virus / Anti-Malware is intended to protect your computer from malicious code
- Most AV/AM products are general in nature, rather than specifically-tuned for every other product you may have installed.
- Some products step on common parts of a computer which cause AV/AM products to react as if it is malware.
- System Center Configuration steps on a lot of those parts.
- Most AV/AM products do not know what Configuration Manager is.
- Many Windows 10 migration projects are derailed or delayed by AV/AM interference
- The less consistent your AV/AM environment, the greater the interference risk and scale of impact to migration projects
- One of the most common interference issues is having unsupported (outdated) AV/AM client versions installed on machines
- Another common problem are rogue AV tools installed inconsistently throughout the environment
- Most AV/AM products like McAfee, Symantec, Sophos, provide administrator consoles for managing their own environments.
- Most AV/AM admin consoles are in front of dedicated AV admins
- Most AV/AM admins have some sort of favorite food or drink. Leverage that.
- Make sure all AV/AM clients are on a consistent, and Windows 10 supported, version. Refer to vendor docs like McAfee, Symantec and Sophos or whatever you use, for more details.
- Grant exclusions for ConfigMgr client footprints, such as files/folders, registry paths, services, processes, etc.
- Don’t forget the firewall exceptions
- Don’t forget the exclusions for the ConfigMgr site servers too
- Don’t forget food bribery works wonders on cross-team collaboration
7 – Failing to Keep Up
- Many customers are still on ConfigMgr 2007, 2012, 2012 R2, as well as Windows Server 2003, 2008, 2008 R2, and SQL 2008, 2012
- Many customers are still on Windows 7, Office 2010 or 2013
- Many customers have moved up to ConfigMgr Current Branch, but are still behind on site updates/upgrades.
- Many customers upgraded in-place but didn’t spend time on the underlying infrastructure (Windows Server OS, SQL Server, physical and virtual resource allocations, etc.)
- Current levels are Windows Server 2016, SQL Server 2017, SCCM 1802, ADK 1803, MDT 8450, and Windows 10 1803
- Many sites haven’t been diligent on keeping 3rd party apps updated consistently
- Many customers haven’t kept their AV and disk encryption installs consistently up to date
- Focus on bringing all of your platforms up to date
- Consider a new stack and clean cut-over if possible
- Double-check your licensing and resource constraints (VM hosts, storage, etc.)
- Update or replace peripheral processes, like backups, monitoring, etc.
- Consider third-party tools to augment things like patching, backups, automation, etc.
Did I miss anything? Let me know in the comments below.