Why I Think SCCM Will Probably Not Survive

At TechEd 2014, I had talks with several folks about DSC versus SCCM’s configuration auditing functionality. My feeling at the time was that SCCM could easily become the tooling we need atop the DSC technology, and that Microsoft could more or less transparently migrate the SCCM auditing capability to use DSC.

They still could, but I’ve changed my mind after thinking about the bigger picture. I’m presently thinking that, long-term, SCCM as it is today doesn’t have a distant future.

There are a lot of reasons why I feel this is true, but the most compelling is probably the simplest: Microsoft could never offer “SCCM Online,” because the SCCM architecture just wouldn’t do it. That said, Microsoft does have an “SCCM Online” called InTune, which works well for them. Granted, it’s missing some of the key pieces of SCCM, but those can be added – and in “cloud candence,” that wouldn’t necessarily take long. InTune already provides the Mobile Device Management capabilities attributed to SCCM. While it might need to be supplemented with on-premises elements to reach better SCCM parity, I don’t think SCCM per se is going to fit Microsoft’s current vision.

Another problem is that SCCM is a hulking, monotlithic architectured product that just doesn’t fit in well with what the rest of MS is doing, server-wise. That’s a fuzzy statement, but it reinforces my gut feeling that MS is looking elsewhere to solve the need.

And then I look at the foundational technologies MS is releasing. DSC obviously solves part of what SCCM does, although at the moment it lacks management tooling. OneGet, coming in Windows Management Framework 5, could enable DSC to be a much more powerful software deployment tool by taking some of the heavy infrastructure out of software deployment. InTune is already geared to do things like inventorying and app deployment, and it could well take on that role for laptops in large enterprises, too – perhaps supplemented by local package repositories, to manage bandwidth better, but without the overhead of a current Distribution Point.

One area, which I discussed a lot with a fellow in my class last week, is that InTune doesn’t do bupkis for OS deployment, which is a big deal. WDS is a more-or-less-purely PXE approach to OS deployment, which isn’t always what organizations need. But from a technological perspective, OS deployment is actually an easy beast to tackle – witness the number of times Microsoft has done so. What’s hard is to come up with the right feature and workflow mix. SCCM works really well for some folks (in terms of OSD); less so for others, so there may be room for change.

InTune technologies would obviously need more scale, too, to push large companies off SCCM, but I think right now that scale is more a Microsoft product decision and less a technical limitation. InTune doesn’t presently support servers, but again, I feel that’s a product decision more than a technical limitation. Product decisions can be changed literally over a weekend – I’m not sure there are a bunch of insurmountable technical hurdles to making InTune “the answer.” And it would certainly fit Microsoft’s direction of sticking everything in the cloud and renting it to you.

Now, I think this is all pretty far off, and regardless what Microsoft does there are organizations with massive SCCM investments who will take forever to move to something else. Which is fine, if it suits their needs. But in a forward-looking way, I’m not entirely sure I’d make a massive new investment in SCCM. At the least, I’d certainly think hard about other ways Microsoft might be pointing. There’s certainly time to let the pieces on the board move around a bit more – InTune isn’t currently positioned to devastate SCCM, for example, and we’ll have a few of its product cycles to see if it does start moving that direction.

Microsoft has always had an awkward relationship with config management, so whatever happens, it’ll be interesting to see if they really nail it.

And of course I could be completely off-base :). As I said, it’ll be interesting to see. Right now MS is clearly at an odd crossroads with CM.

10 thoughts on “Why I Think SCCM Will Probably Not Survive

  1. Peter Egerton

    Nice write up. I’ve heard this a lot recently especially following Wallys departure. However the number of customers that have seen red when I’ve chatted about this is not far from 100%. I probably agree that this is what MS will try to do but I suspect they may underestimate the backlash.

    1. Don Jones

      Oh, I don’t think they’re underestimating. I think they’re terrified. I think the reason we’re not seeing an official story from them is that they’re trying to put one together that won’t tick off the multiverse. They could do a lot to make a transition easier, but it’d take a lot of engineering.

  2. Adam Bertram (@adbertram)

    You have some good points and we’ll never know what MS is thinking but I’d like to share another point of view from a different angle. I work with ConfigMgr all day, every day and have primarily been doing so for over 4 years now. A few points:

    1. I agree, like everything these days, MS is trying to take more and more services to the cloud. With the introduction of InTune, Active Directory in the cloud and cloud-based distribution points some of ConfigMgr’s features are available in the cloud. However, as you mentioned, OSD is not available and I honestly can’t see how it could be. WIM images are 10, 20, 30GB+ in size. Unless Internet bandwidth gets really cheap and really fast sometime soon I don’t know how that’s going to work. Perhaps they could have some kind of management service in the cloud to send commands to on-premise distribution points like you mentioned but you never know. The bandwidth concern also goes for software distribution. Office 2013 is 2-3GB and our technicians are deploying that a few dozens times a day. I just can’t see how to scale that over the tubes.

    2. I liked your thought about integrating DSC into ConfigMgr. I like DSC and the thought behind it. Honestly, ConfigMgr’s Compliance Settings really do leave something to be desired. They are really only a different way of reporting on the state of an application or OS settings. I’d love to see something like DSC incorporated into ConfigMgr. It makes sense since ConfigMgr already compiles and applies MOFs anyway for inventorying purposes.

    3. Comparing OneGet to ConfigMgr’s software distribution model is a joke. That’s like comparing apples and oranges. The software distribution model is not only getting the bits installed onto a client, the client also automagically figures out where it is, what’s the best place to get said bits from, the best time to download the bits not including sending up each client’s status up to a database so an admin can report on just about any piece of process. I’m not saying MAAAAAYBE one day OneGet will see some of this but it’s going to be a looooong way off.

    I’ve heard the “SCCM is dying” talk before and I do see a few indicators that the winds are changing (Intune, cloud DPs, cloud AD, MMS going away) however I just can’t see a time when it would completely go away. Granted, I could be completely full of shit in my statement because I haven’t lifted my head out of the ConfigMgr trees for some time now. I’m not tied to a certain tool so if it does go away I’ll always have my precious Powershell skills to fall back on. 🙂

    1. Don Jones

      Well, since this is basically just a thought experiment at this point, let’s think about it.

      Windows Update already tells us how MS does software distribution of large objects. They control things from the cloud and download the master copy to your local repository; you distribute from there. That local “repo” wouldn’t need to be any more complicated than a file or web server.

      In terms of OneGet… I think you’re comparing an early preview release to a mature, decade-old product. Obviously OneGet doesn’t do what SCCM software distribution does. But I think you also misunderstand what OneGet is and where it might be headed.

      In this blue-sky concept I’m thinking of, DSC tells nodes WHAT to install. DSC also controls the list of available repositories – which might include cloud- and local-based repositories, that’d likely be up to you.

      OneGet’s job is to find the right repo, walk the package dependencies, and perform the installation.

      The “find the right repo” is where the intelligence that you mentioned needs to come into play. Funny thing is, all the complex intelligence in the existing SCCM client has largely been done in much simpler ways elsewhere. If a repo is just a web server (which they basically are), then doing things like load-balancing, creating geo-affinity, and so on – we already know how to do those things. The “intelligence,” if you will, comes not from the client but from the cloud itself. It’s like when you visit a website and they use Akamai or AWS to deliver assets like graphics. Your “client” doesn’t know poo about where to go, but the cloud gets you to a geo-proximal distribution point. Following that logic, OneGet itself doesn’t need to be too intelligent… which is perfect.

      In other words, imagine that the OneGet client hits a “repo” server (and it’s really worth looking at how that architecture works, it’s fascinating), but it’s in the cloud (or on-prem, sure). That repo actually redirects the client to the real bits, using geo information, time of day, client type, all that. Rather than downloading the “rules” to the client, you keep them centralized in the cloud. This happens on the Internet every day already. For giant files, you just make sure the cloud knows where your local repos are, so clients don’t have to drag 30GB across the WAN. You could literally set this up today, if you wanted to.

      DSC already supports sending back client status – and the system it uses to do so is pretty extensible (by MS) to support a lot more data going upstream. So whatever OneGet reports for the installation can feed back up the chain. Again, the report-back is just a web service talking to a database, so it’s easy to scale out… to cloud proportions.

      But… no, today, the pieces aren’t in place. But if you look at what pieces ARE in place, it seems pretty clear that they could create an SCCM-like set of capabilities, albeit with more of the intelligence in the cloud, and less intelligence required of the client. Which is perfect when you want to support a broader range of clients, since you don’t have to write as “thick” a client agent for multiple platforms.

      Again… this is all years off, I’m sure. And it might not even be what eventually goes down. I just think it’s valuable to look at what’s happening and kind of figure out what might be a good investment direction, personally. And don’t underestimate how many of the pieces VERY NEARLY are in place.

      Frankly, the biggest hurdle won’t be the technology. It’ll be transitioning customers without them rioting. But then again, the size and number of companies jumping from Exchange on-prem to O365 has stunned me, so it’s possible enough customers will ride along to make it a fait accompli.

  3. @davejdyer


    This is an incredibly compelling line of thought. I too have had my head down focused on getting the most out of CM for a few years now with the mindset that it will be the foundation of our deployment and reporting structure for many years to come.

    I’ve had DSC on my mind for some time now and OneGet since I saw the WMF 5 release news, but other projects keep jumping in front of my desire to get familiar with them. I agree that it’s hard to forecast how this will shake out in the end, but I think all of Don’s points are very valid. If nothing else, this will certainly server as motivation to re-prioritize some of my study and training focus.

    Thank you.

  4. Adam Bertram (@adbertram)

    I agree with you in regards to Windows Update. There’s even an option now in ConfigMgr when pushing updates to go out to Microsoft to grab the updates. However, I would hesitate on saying updates are “large objects”. I’ve never seen an update larger than maybe a few hundred meg at the absolute biggest. When you’re talking Office 2013, AutoCAD or another large software package that’s in the multi-gigabytes that’s a different story. Granted, those aren’t extremely frequent.

    I understand the premise of OneGet and I understand that it’s all new and shiny at this point vs. the old fart SCCM that can show that OneGet whipper-snapper a thing or two. Only time will tell if or when the OneGet tech overtakes ConfigMgr’s software distribution model. They both gets the bits on the machine at the end of the day.

    Re: “DSC tells nodes WHAT to install” I really like DSC and I think the tech is extremely cool. However, to get stuff done it still has to execute some kind of script although at a different point rather than just running a Powershell script against a machine. Ultimately, what’s the difference between creating a DSC script via Powershell, pushing that script to a machine, getting compiled and then checking compliance every 15 minutes vs simply creating a Powershell script, deploying with SCCM and telling it to run every 15 minutes. To me, the end result is exactly the same. If the end result is the same then it’s all about how easy it is to get there and how easy it is to manage it.

    I do like package dependencies. I don’t have much experience with OneGet but I do with RPMs. In ConfigMgr, I’m forced to manually build those dependencies in the new App Model. However, I probably would never push a package built my some no-name person on the Internet somewhere to any PC in an enterprise environment. Granted, it’d be nice to see the dependencies and allow me to verify all the code prior to deployment.

    SCCM is an enormous beast with a lot of tentacles. The OneGet/DSC discussion we’re having now is only a small piece of what makes up SCCM. Intune does exist although honestly I have near 0 experience with it. From what you mention, I’m assuming that will do all the traditional software/hardware inventorying and reporting but let’s say it also has features like software metering, asset intelligence (software license management) and even a NAC/NAP product like SCCM does now. Sure, it’s feasible to replace SCCM with these products today although it’d probably take 5+ applications to mimic the same result. Why would I choose to use all these desperate products when I have everything I need in 1; SCCM?

    1. Don Jones

      Don’t take this as “new and shiny” vs “old fart;” that’s dismissive and missed the point of the observation (notably, I’m not saying this is an argument).

      My point with Windows Update is that it’s absolutely possible for a cloud service to tell a client WHERE to get its installer bits, and for those bits to live on a local repository. You took the analogy a bit too literally. There’s nothing stopping you, for example, from standing up one or more local repos, and simply telling a cloud service where they live. That’s no different, in fact, than how SCCM works today, it’s just the “site server” would be in the cloud.

      You’ve also missed some subtleties in how DSC differs from a “normal” script. One major difference is idempotence, meaning the effect of running a DSC config 10 times is no different than running it 1 time. Yes, you could absolutely write your own script that first tested to see if anythign needed to be done, and didn’t do anything if nothing was required. You would have engineered yourself your own DSC – and spent a lot of time doing it, when you could have just consumed what’s (now) built in. By the same argument, you could also invent your own SCCM agent, your own GPO technology, and anything else. If your point is “in the end, SCCM and DSC achieve the same thing with regard to configuration instructions, or could do so,” sure, they do. I think you may have missed my opening argument in the article: If SCCM goes away, it will not be for a lack of functionality. It is because it isn’t cloud-scale, and doesn’t work in a cloud-hosted environment. Whether that is good or bad isn’t really my point; my point is merely that it IS.

      I’m also not trying to make an argument that DSC, OneGet, etc, are MORE FUNCTIONAL than SCCM. Again, that misses the point of my observation. I am not arguing that they are BETTER than SCCM – again, misses the point. I am in no way even suggesting that SCCM is BAD or in NEED of being retired. Your reply exhibits a certain amount of defensiveness on behalf of SCCM, and it’s unwarranted – I’m not attacking SCCM.

      I’m observing that SCCM is poorly suited to the direction Microsoft appears to be taking. Given that observation, does Microsoft appear to be in the process of backfilling SCCM functionality in other places, in more cloud-scale ways? Yes, they do. No combination of DSC, OneGet, InTune, etc. can replace SCCM ***TODAY***. I’m not interested in today; I’m interested in what’s coming.

      Let me emphasize that. You said, “Sure, it’s feasible to replace SCCM with these products today,” but that wasn’t my point at all. I don’t believe it is feasible. TODAY.

      Instead, I see Microsoft BEGINNING to line up the functional replacements for SCCM’s existing features. Those first steps, combined with SCCM’s non-cloud-focus, is what makes me think Microsoft is indeed walking down a path to replace SCCM. Could they do it today? Of course not. Do they seem to be aligning their troops in that direction? They do.

      Take OneGet – something that isn’t even released yet. Will OneGet v1 replace what SCCM does? Absolutely not. No way, no how. But it establishes – as a CORE COMPONENT OF THE OPERATING SYSTEM – a foundational replacement. Combine that with other existing technologies and approaches, and you can see where it – in those combinations – COULD do so one day. And that’s what “watching the industry” and “predicting directions” is all about.

      The first automobile drew derision from people who owned horse-drawn carriages. Now those carriages are tourist attractions. It took time, and refinement, but it happened. That was the point of my article, here – I’m seeing what seems to be the beginning. It’s going to take a few cycles for it all to come together, but it seems as if Microsoft is implementing the pieces that will eventually come together to obviate SCCM.

  5. Adam Bertram (@adbertram)

    Ah, I understand what you’re getting at now.

    I agree 100% on Windows Update. You’re right. It would not be a big problem for a client to simply hit a cloud server versa an on-prem site server to tell the client connect to on-prem DP to get your stuff.

    Full disclosure: I also commented on your “don’t reinvent the wheel” comment a couple weeks ago on your Facebook page. I, admittingly, tend to write my own stuff a lot of the time when I could get an off-the-shelf product to do it. I like knowing what I’m using and how it’ll exactly behave. With that in mind, I agree with you in regards to DSC, that tech WILL make it easier to maintain state. Maybe by the time MS releases DSC Wave 5,678 they’ll have all the resources we need and writing a script won’t be necessary anymore.

    I suspect my obvious, unintended defensiveness has to do with what Peter Egerton mentioned above about the backlash. I tried my damnedest to never be close-minded about anything but when you’ve been in the bowels of a product for so long as others that he’s probably referring to you feel a sort of camaraderie aka fanboy status. Speaking of…don’t EVER talk bad about my Macbook/iPhone/iPad from me or we’ll fight. 🙂

    At the end of the day, we’re on the same page. You’d have to be stupid to not see Microsoft’s push to the cloud. I’m surprised it took the configuration management guys this long to begin assembling the cloud troops. Us ConfigMgr admins though will hold down the fort! If we get sieged, I’ll roll with the punches like any good IT pro should do and attempt to subdue my sobbing.

  6. Trey McGlaun

    This is a very interesting discussion.

    What do you guys think about how products like 1E Nomad and Adaptiva OneSite could change the way media is delivered from the cloud? Microsoft already has Branch Caching features. It would seem that it could work in a similar fashion for large application and OSD payloads.

Comments are closed