Is SCCM overkill for medium-sized organizations?
Solution 1:
Background:
I have been the primary administrator/user of a SCCM 2012 SP1 implementation in our organization which is composed of about 500 workstations (Windows 7) and 120 servers (Windows Server 2008 R2). I am also early on in my career and primarily have a background in and a passion for networking and Linux so Windows endpoint management is something new and slightly distasteful to me. I only have experience with SCCM 2012 so I can't speak to the older versions. Our organization is at the bottom of the economy of scale curve and our (more or less) successful implementation of SCCM is largely due the fact we are far enough ahead of our requirements that we can be proactive, a lot of standard duties are handled by other groups (Active Directory, Email, Networking, Security).
The Price of Features: Complexity
SCCM 2012 has alot of moving parts and when they break they break for reasons that are not always immediately obvious or intuitive. SCCM 2012 kind of acts like an overseer, managing and leveraging a bunch of existing underlying technologies through a single framework. This is not simple and it occasionally breaks. To get an idea of how many different underlying pieces are involved go look at the number of logfiles, I think at a rough count there are something like ~240 logfiles. Again, it is hard (at least my perspective) to overstate the complexity of SCCM (or really any endpoint management system).
Managing Endpoints Like a Boss
You know what is really annoying? Walking (or RDPing) to each individual machine to perform the same task over and over again. That's boring and a waste of time. If you really commit to using this tool it can be an incredible force-multipler. Here's the features that let you do that:
- Software Updates - This is basically just WSUS on steroids. You get great reporting, granularity and compliance checking over the standard WSUS offerings. If you can do WSUS you can do Software Updates with SCCM.
- Compliance Settings - I was about really excited to see this feature coming from the land of things like Puppet. Configuration Items are composed of a Setting to evaluate and then a Compliance Rule which determines whether or not to remediate it. As example, we pushed an organization-wide Application that removed one compression utility and replaced it with another. This had the unfortunate consequence of not correctly setting the file association for ZIP files. One Registry Key based Configuration Item later we had set the file association across the entire fleet. You can assess a pretty wide degree of Settings - Registry Keys/Values, Active Directory queries, WQL and SQL queries, and PowerShell scripts. Think of Compliance Settings like a very flexible, granular version of GPOs with revision control (finally) and reporting. The downside is that for anything even slightly complex you will be writing scripts and we still don't escape the difficulty of doing configuration management of an API oriented management model.
- Applications - This is for deploying and managing 3rd party software. All of the logic is supposed to be contained in the "Application" - the detection logic (how do I know if $APPLICATION is installed), the requirement logic (does the client meet the prerequisites), in installation logic and the uninstallation logic. With properly built Applications this works really, really well for managing 3rd party software. The newer version is deployed, it automatically supersedes the older version, uninstalls it and then installs the newer version. As I mentioned above - we replaced one utility with another across our entire fleet overnight. You can take this model even further and use the "AppStore" functionality to let users install their own software that is outside of the base image.
You will want to manage things like Adobe Flash, Acrobat/Reader and Java JRE since they are so often the target of malware but do not attempt to do this yourself. Just buy a subscription service that provides them through SCUP. The installation process for these products is such a moving target that it seems like every version does things differently (see here, here, here and here). At best I find that I can turn out a new Application of something like the Java JRE or Flash in about five hours. If you do Reader, Acrobat, Flash, and Java JRE you can expect 20 hours worth of work a month at a minimum. That's almost entire week of a FTE for packaging - save those hours and effort for in house or specialty applications. (Why Adobe and Oracle go to such depths to make my life harder, I have no idea.) - Reporting / Software Metering - Just about everything in Windows is either in WMI or in the Registry. The Registry is easy to reach into with Configuration Items and just about everything in WMI gets sucked up in the Inventory Cycle. You can then use the builtin or custom Reports to turn this into nice fancy Manager-Approved (TM) information. As an example, we have a custom report that get us the Serial Number of all our workstations, we send it to our Dell rep and we get back a list of machines whose warranty expires that quarter. Neat.
I mentioned user-centric Application installation from an "AppStore" earlier - so if users are installing Acrobat on their own how do you manage licenses? You can run a report at true up time to see who has the software in question and then look at Software Metering which will tell you how often that particular piece of software is used on a particular workstation. We're using this to roll-up each department's licenses for Acrobat into a single agreement so we can get a better per-license cost and then for extra measure remove it from workstations where it is rarely used. - Operating System Deployment - This is basically MDT, WAIK and DISM. The value add that SCCM gets you is Task Sequences and Build and Capture. You essentially automate the process of building your reference machine. To refresh your base image, you update your Task Sequence and re-run it. This greatly reduces the time it takes to build a new base image.
Right-sizing - Or How I Became an SCCM Administrator
All that stuff sounds good huh? Here's the problem. It's not simple to do. Our tier-1 guy spent almost six weeks figuring out the Build and Capture for base images. It took me at least a month to get a laundry list of break/fix issues resolved. I still can't manage to build, test and deploy Java JRE before a new version is released. Our DBA had to write our custom reports since I couldn't figure out SSRS. I find that I write a lot of PowerShell scripts to glue certain things together or to perform some kind of "logic". I still can't write WQL queries for application logic. After six months of spending almost all day, every day with SCCM, I feel like I'm just beginning to start getting over the learning curve. Our tier-1 and tier-2 folks end up pushing the majority of SCCM issues (which are really endpoint/desktop support stuff) to me since they don't (yet!) have the skill set to resolve them. By skill set - I mean, things like familiarity with WMI/WQL, WSUS, ProcMon, Windows Installer, PowerShell, and the Registry. To do things like the ZIP association file Configuration Item fix, you need to know that kind of configuration data is stored in the Registry and where to find it. If you make SCCM your organization's tool for managing endpoints you need to be prepared for 1) a lot of desktop support stuff to be handled by people further up the support chain since it requires such a diverse skill set, 2) a brutal learning curve for your tier-1 staff, 3) resistance and a tendency for staff to do stuff the "old school manual way" because it is "so much easier".
Is SCCM a good fit for your organization? Here's some questions to consider.
- Are you in a reactive mode or a proactive mode?
- How diverse is your staff's job duties already? Do they just do endpoint management or are you doing everything?
- How deep and diverse is your staff's skill set?
- Is there a desire and willing-ness to among your staff to climb that learning curve?
- How diverse is your fleet and your end user's requirements?
- Is senior staff willing handle desktop support issues and mentor your tier-1 and tier-2 folks until they become more comfortable with SCCM?
- Will your management provide training (hint: If you have a Microsoft Premier contract, they have some great PFEs that can do on-site seminars).
- Is your management willing to run interference for you, while you spend a week or two figuring out something the "SCCM-way" instead of just doing it the "old school manual way"?
Solution 2:
I would not call 800+ computers "mid sized". I was successfully deploying the successor of SCCM in a bank with 850 employees. In your case it is a lot more likely nowt knowing your tools that will be the problem - somehow I have a problem imagining the team of 3 people in a school being the highly competent people that companies employ for a lot more money. The learning curve WILL be brutal for you.
But once you are over it, it will help a lot - the whole System Center suite. 800+ machines is WAY too big to run around to install stuff.
Solution 3:
Forget you're a school and look at your numbers critically. You have 800 computers and nearly 2000 users. That's not a small company and I wouldn't really say "midsize" either. Schools IT is often neglected, but the truth is you should be using good quality enterprise hardware and software.
And, indeed, that includes SCCM. It's hard for any of us to say what will definitely work in your environment, but you could certainly pick worse places to start.
Of course, this is all easier said than done, but trust me when I say I've nearly every 'level' of educational IT.
There's very little that's truly overkill for a network of this size - plenty that are too expensive, though!
Solution 4:
I'd use redo and backup, and wpkg, simple (with a bit of research and organization), and best of all it works. You can image a machine, and then WPKG will (surprise, surprise), install the software. That's the system we used to use with 2000+ machines, over multiple campuses, until we were taken over by another college. We use SCCM now. It's great in all respects except speed, reliability, simplicity, installing software, installing the os, reporting, and giving you accurate data. Apart from that, it's ok.