The next release of Microsoft’s kick-ass System Center Configuration Manager product line was rumored to be labeled “2016”. Meanwhile, it continues hopping along officially named “vNext” during the technical preview period. The latest rumor going around is that it’s official name will be sans version. As in, “System Center Configuration Manager” and that’s it. That may work for marketing material, but customers are never going to adopt that in practice, at least not anytime soon.
Customers are still going to give it a name, because they have to. Think about it: how else are we supposed to discuss a site migration? “I’m upgrading from SCCM 2012 R2 to SCCM” ?? I don’t think so. Being human, we like surnames on things to help distinguis them from the crowd. In this case, the crowd is all the other versions of the same product. We may call it “2016” or “vNext” or something, but we shall call it something with a declarative version.
Ok. Enough of that dribble. On to the main point.
As much as I love the product, there are some things that have irked me with regards to SCCM since 2003, and some which were added in 2007 and again in 2012. This is personal, and given that I’m not a “guru” or MVP recipient, my opinion is essentially worthless, but still, I drank some coffee and spent days in my home lab on 2012 R2 SP1 CU1 (takes a long breath before continuing…) and with vNext Preview 3.
I submitted some of these back in the beta program for 2012 but it was too late in the release cycle for it to be taken seriously. I figured “okay, maybe in 2015 or whatever.” and I didn’t get into the early round of vNext this time so I blame myself on this. Anyhow, it’s a blog post.
Obviously, this is all subjective and open for disagreement, so with that said, here goes…
- Ditch the client console. I’ve built more than my share of web consoles for SCCM and it’s not that difficult. The advantages outweigh the drawbacks by 100:1. Intune is already there, so all other excuses are moot. Some benefits include easier upgrades, single-point access control, and platform agnostics. Then again, the PowerShell cmdlet module would need to be shared from the MP or somewhere central. But given that this isn’t likely to happen before Intune and SCCM are merged in a blender…
- The vNext console is pretty much the same as 2012 R2. It violates quite a few of the “best practices” guidelines that Microsoft and many open source development vendors push. Among them:
- Drag and Drop support (think about moving collections into folders). Having to right-click and select “Move” is so 1980’s.
- Resizeable dialogs (think about “Add Resource” to collections)
- Adaptive Defaults (think about each time you add a device to a collection and it keeps defaulting to “User Collections”
- In-Place Expansion (when clicking “Show Members” on a collection it opens in the “Devices” tree, rather than under the starting location beneath “Device Collections”)
- Applications AND Packages – please combine the two into a new hybrid. It’s confusing even for those of us who are used to them. Try having a conversation, and it goes like this “You need to deploy the application.” (response) “You mean an Application application or a Package application?” and “Deploy with a Deployment or an Advertisement?” Answer: “Just lock your machine and go find a nearby bar“. *smh*
- Ribbons and Stacks and Tabs – Please, pick one. This is like stuffing Microsoft Office 2000 and 2013 into the same blender. Basically, it amounts to wasted real estate. If the sidebar panel is to remain, at least drop the stacks and go with tabs, to be consistent with your web browsers and Office products (Excel puts them along the bottom, but so what?)
- Non-Contiguous Workflows – The process for deploying an application is still awkward. You create the Application, and the related things (detection methods, requirements, etc.), then a Collection, and then a Deployment. Two of these are in one section (“Application Management”) and the other in a different section (“Assets and Compliance”). Why not a single-flow “wizard” to create the Application and its attributes, then the Collection (or select an existing) and then specify a Deployment? I’m not suggesting this be the ONLY way, but just as an alternative.
- Incorporate the Right-Click Tools
- Incorporate the RBA Viewer
- Default Global Conditions – should include a few more “out of the box”, such as Internet Explorer versions, Office versions, and .NET Framework versions. I am aware that it’s not difficult to add these, but they’re so commonly used that they should built-in.
- Organization – Shouldn’t “Site Configuration” be more closely related to “Hierarchy Configuration”? Why not group “Deployments” and “Distribution Status” under “Application Management” in the Monitoring section, like you do in Software Library? For that matter, “Assets and Compliance” might be better split into two groups, for things like “Endpoint Protection”, “Software Metering” and “User State Migration”. The bundled section is kind of weird. Maybe I’m not drinking the right kool aid.
- Site Boundaries – oh boy. I’d LOVE to see a built-in feature that analyzes boundary groups for overlap when they involve site system references. I know it can be done with PowerShell (even VBScript) but in the console it could be helpful.
- AD Site Links – And speaking of Site Boundaries, it’s not much of a stretch to poke at AD and pull Site Links attributes. This can be leveraged for a variety of uses, such as analyzing costs and schedules for comparing with Site Boundaries and Distribution Points. Even if it just popped up a message saying something like, “hey, that’s a really slow link, and you have X devices on the other end, you might want a DP over there.” Pie-in-the-sky, maybe, but that’s a “why not?” thinking pattern I was heavily influenced by my esteemed colleague Brad Hamilton.
- The Installer – Okay, this needs it’s own section:
- HTA base form – why? PowerShell PowerShell PowerShell is all we hear. Yet, the ConfigMgr installer is still VBScript/HTA. Isn’t it time to at least build a Visual Studio form?
- Pre-Requisites – Why not offer checkboxes to go ahead and create the “System Management” container, extend the Schema, and delegate the appropriate permissions. That’s about a dozen lines of PowerShell.
- Pre-Requisites Cont’d – Why not offer checkboxes to take care of SQL Server (select or install), ADK, WSUS, WDS, BITS, RDC, and options for MDT and pull the latest updates for each along the way? Again, some of the other enterprise products use this approach, but SCCM seems to always leave that up to the installer. I know that sounds whiny, but it just seems “clunky” to me and it’s already 2015.
I’m sure some of you are sneering at this and thinking “who is this guy?” and “what an idiot!”. Fair enough. Some of these are fringe complaints and I could go on earning a paycheck dealing with them as they are forever. But sometimes I find people get used to things and accept them as “optimal” when they’re really not. Regardless of how negative this article may seem, I’m still a die-hard fan of ConfigMgr. Like I said at the very beginning, it’s “kick-ass” and has earned it’s place in enterprise computing environments.
Are my comments valid or am I full of shit? I’d appreciate your thoughts on this as well, so please post comments if you would.