Since time draws ever closer to the season of the witch, allow me to start out with an excerpt from a timeless techie classic, the poem titled, “The Ramen.” I know not from whom it came but kudos to them:
Once upon a workshift weary, I was searching, bleak and bleary,
Searching for forgotten files lost inside our data store —
As I sat there, not by choosing, fighting sleep and badly losing,
I considered trying snoozing — snoozing on my office floor.
“Not a bad idea,” I grumbled, ‘”snoozing on my office floor —
I can’t take this anymore.”
Thus it is submitted for your approval: A lonely Systems Administrator in a data center on a dark and stormy night. As the hours wage war on his battered psyche he wields one of the most dangerous weapons known to the business world: System Center Configuration Manager. SCCM is the modern Excalibur of the IT world and such is extremely powerful in the right hands. It is noted with some consternation, however, that this modern day weapon is not as discriminating to its owner as was the sword of myth. Many administrators over time have wreaked havoc in enterprises with simple pressing of a button or click of the mouse. Let us walk together for a spell along that cold, rain-slicked precipice of darkness and see the horror that was wrought by some of our predecessors, and how to avoid their fate.
In SCCM 2007 they are called Advertisements. In SCCM 2012 they are called Deployments. Whatever name they are given they are one of the most precious jewels of Configuration Manager, allowing us administrators to distribute software and updates to Collections of our choosing, but what happens when we choose…..poorly? This is the first tortured soul of a System Administrator:
He who advertised to the “All Systems” Collection:
There are times when you want to send something out to all systems, but those times are few and far in between. Microsoft recommends never advertising to that collection. The preferred solution is to create an appropriate collection such as All Desktops or All Windows 7 machines (You do have Windows 7 deployed right? You only have this much time left). Here are some simple steps to get started:
In SCCM 2012 under Assets and Compliance right click on Device Collections and Select Create Device Collection. Input the General Information, but BEWARE of the Limiting Collection! If you put in a default collection then any security you grant that collection is pretty much null and void. Setting a Limiting Collection to a default collection gives anyone with permissions to the created collection access to all collection. Go ahead and reread that last statement a few times then click Next.
Click on Add Rule and select Query Rule (Always use Query Rules as a best practice). Give the query a name and click Edit Query Statement. Under the Criteria Tab click on the starburst and click on Select to choose System Resource with the attribute Operating System Name and Version. The Operator should be chosen as “is like” and the Value desired is %Workstation 6%. You can then Click OK twice and put a check in Use Incremental Updates for this Collection Next twice and Close.
The next stop on our tour of damned shows us that the road to hell is truly paved with good intentions. This tortured soul tried to help out his fell System Admins by giving them access to SCCM without constraints and ended up sharing the fate of Julius Caesar:
He who hath given unfettered access to those undeserving:
SCCM 2012’s arguably most powerful feature is Role Based Security. This allows SCCM administrators to grant others access to only the objects that they need. Mark my words that entire books will be written about this subject so that no one else accidentally reimages a machine in the wrong collection, for example. By creating a new Security Role and properly configuring Security Scopes: you may deflect the dagger ever drawing towards your back.
Our next soul was also well intentioned, but by their folly brought entire enterprises to their knees garnering the wrong type of attention by executives. No demon has the wrath equaling that of a Vice President has after explaining to a C level executive why the entire organization is down and production dollars are lost. We name this lost soul:
He who hath distributed large files over the WAN during business hours:
This was of particular concern in SCCM 2007 when no throttling was in place and your Operating System Deployment person decided to send that new WIM file out to ALL of the distribution points at 9:00 A.M. In those dark days you could only achieve throttling by creating a Secondary Site. In SCCM 2012, we now have not only the ability to set bandwidth throttling at the Distribution Point level, but also at the client level using BITS:
In the SCCM 2012 console go to Administration and click on Client Settings. Right Click Default Client Settings (or whichever policy you prefer) and select Properties. Background Intelligent Transfer should already be selected and on the right pane you can turn on the bandwidth settings and select options appropriate for your organization.
I think we shall conclude our little Danse Macabre here as the hour grows late and moon is full. Although we have only visited three tortured souls this night, rest assured that there is more in our other rings. Why, we even have a few open spots should you fall along the wrong side of the precipice, but I’m sure all of your systems are fully secure and as a SCCM administrator you follow all best practices. Pay no attention shambling and groans that you hear in the background. Those aren’t zombies they’re just unemployed SCCM Administrators who didn’t heed the warnings.
