Migrating Away from an SCCM CAS (Part 1)

Hi, my name is Chris, and my ConfigMgr environment has a CAS.

This will be one of my few multi-part blog posts, mostly because it’s going to take a me a lot of time and a lot of testing to do things right. Once the series is complete, hopefully you’ll have an understanding on how I moved an environment to one that doesn’t require a CAS.

You cannot just remove the CAS from an environment, and there is no (supported) way to decouple a primary from a CAS. In fact, I’m not aware of any unsupported way either, but I haven’t looked too deep.

The Environment

I’m currently managing an environment with roughly 14,000 endpoints. These vary from Windows 7 through Windows 10, and Windows Server 2008 through Windows Server 2016, with everything in-between. I do not manage non-Windows devices in SCCM.

There are three core servers, which are the CAS and two primary management points. Alongside these I have one system running the Flexera AppPortal application, and just north of 20 distribution points, geographically distributed across the world.

Why do I have a CAS? Why don’t I want one?

I have a CAS, in short, because as an early adopter of SCCM 2012, migrating from 2007, no one told me not to continue to use one. While every PFE will probably tell you now that 99% of enterprises don’t require a CAS, that advice wasn’t available back in the early days.

I don’t want a CAS for a variety of reasons:

  1. It complicates administration and troubleshooting.
  2. It ensures I have a yearly call with Microsoft when SQL Replication breaks and I can’t fix it on my own.
  3. It means that changes I make are delayed before reaching the client due to CAS->Primary replication, making troubleshooting a slow and painful experience.

What’s Migrating, What’s Staying Behind

While I’m only now getting around to writing this all down, I’ve actually be actively working on the plan for about a month now. I’ve gone through a few trial migrations, so I have a good feeling for how things are going to move over.

What I do plan on moving over to the new primary site is:

  • Applications & Application Deployments
  • Boundaries and Boundary Groups
  • Software Metering Rules
  • Collections
  • Configuration Items, Baselines, Baseline Deployments, and Global Conditions
  • Operating System Upgrade Packages, Deployment Images, Deployment Drivers, Driver Packages, and Boot Images*
  • Software Distribution Packages & Deployments
  • Task Sequences & Task Sequence Deployments

(* For Boot Images, I don’t migrate over the default boot images because they’ll conflict with the ones that come out-of-the-box in my new environment)

What you’ll notice missing from the above list are:

  • Everything Software Update related. I tried, and failed, too many times at migrating these. If WSUS in the new environment isn’t always completely up to date, you end up with a bunch of failures; if you have patches that are too old in the existing environment that they don’t show up in fresh WSUS, you’re riddled with failures.
  • Queries. Mainly because they’re not included in the built-in migration tool. I could probably script something to move them over, but as I look through them, most of them are old, written by people who are no longer here to use them, and were just used for testing what would eventually end up as a collection query.

That’s all for now – in my next post, I’ll talk about the test environment I’ve setup in order to stage my migration and we’ll start getting into the nuts and bolts of my plan.


Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.