With the end of the year just around the corner, we tend to strategize for the upcoming year. This time of year, I’ve gotten into the habit of looking at Microsoft product support dates to see which products might be leaving the “supported world” in the upcoming year. If you’re unfamiliar, Microsoft breaks down their support model into “Mainstream” (free) support and “Extended” (paid) support. This is oversimplified of course, but in general, we want to be on mainstream support and on recent versions of software for all the latest security and feature benefits. For example, the latest version of System Center Service Manager (SCSM) provides you an Exchange Connector that can talk to M365, as well as improved SQL connectivity/performance. The latest version of System Center Operations Manager (SCOM) gets you improved Azure monitoring. The list goes on!
What’s Falling Out of Support?
I dug into the current versions of System Center (SC), Windows Server, and SQL Server to see what products are falling out of support soon. System Center 2010 just recently went out of Extended support (10/13/2020), and here is the breakdown for the more recent versions:
|System Center 2012 / 2012 R2||7/11/2017||7/12/2022|
|System Center 2016**||1/11/2022||1/11/2027|
|System Center 2019**||4/9/2024||4/9/2029|
|Windows Server 2012||10/9/2018||10/10/2023|
|Windows Server 2016||1/11/2022||1/12/2027|
|Windows Server 2019||1/9/2024||1/9/2029|
|SQL Server 2014||7/9/2019||7/9/2024|
|SQL Server 2017||10/11/2022||10/12/2027|
|SQL Server 2019||1/7/2025||1/8/2030|
*More info on Microsoft product lifecycle dates can be found here
**Excludes Configuration Manager (SCCM), as SCCM moved to a quarterly release cycle in 2016
There are a few key takeaways here. First, SC/Windows Server 2012’s time should be winding down this upcoming year. They have been off Mainstream support for some time now and have a little over a year remaining of Extended support. The second takeaway is that even SC/Windows Server 2016 is surprisingly getting up there in age. While they don’t leave Mainstream support anytime in 2021, they leave very early in 2022. If you’re happy with Extended support, there’s still plenty of time for 2016. Personally, I like to be on the latest and greatest, and 2019 looks to be in a great spot for the next several years.
From an SQL perspective, there tends to be an extra one-year buffer. It’s well worth nothing that Microsoft added SQL 2019 support for SCSM 2019 in October of this year, as long as you are on Cumulative Update 8. This means it’s now possible to move SCSM to SQL 2019, although since Mainstream support is so late in 2022, it’s less urgent.
Planning For Upgrades
If you find yourself staring at a 2012 or 2016 SC instance, it’s probably time to start planning your path to 2019. If staying in Mainstream support is the goal, you will want to update all SC components, and ideally OS/SQL too. Initially, this might seem like a daunting task with a lot of questions. The first of which are: What is the proper upgrade of a single System Center component, and what is the proper upgrade order for all of System Center? Microsoft sets the upgrade order as follows:
- Service Manager
- Data Protection Manager
- Operations Manager
- Configuration Manager
- Virtual Machine Manager
As the starting point, System Center Orchestrator (SCOrch) is a fairly simple system to upgrade or migrate. Our typical approach is to spin up a new environment with the latest OS/SQL and install/configure the latest SCOrch. Once that is complete, you can export runbooks from the old environment, and import runbooks to the new environment. Test and validate your runbooks are functional, then decommission your older instance.
Compared to SCOrch, SCSM poses a few more challenges and questions. Which application servers need to be upgraded first? What do we need to validate post-upgrade? Will our customizations still work? What is our roll-back plan? How much down-time will we have? Our environment is a mess now, should we clean things up first? Can we clean things up? Whew! While a number of questions may come to mind, let’s talk about a less stress-inducing way of answering all of them, getting to the latest and greatest SCSM, and a way we can take control of a messy environment: Cireson’s Lifecycle Management App (LMA). So, what exactly does it do?
Cireson’s Lifecycle Management App Can Help Clean House
My favorite way to explain what the Lifecycle Management App does is with an analogy. Let’s think of your environment like a house:
- Windows server is your plot of land
- SQL is the foundation and infrastructure
- SCSM is the house itself
- The amenities in your SCSM house are things like your Incident Classification values or your Service Catalog
As any homeowner knows, houses— and everything that come with them— need to be upkept and repaired from time to time. Let’s say your plot of land has a sinkhole on it, the foundation need repairs, you need a new roof, and the amenities of the house are cluttered and need reorganization. Whew, that’s a lot of stuff! Independently, it can surely be addressed, but does pile up and can be disruptive to fix. Surely it would be simpler to move.
So, let’s talk about moving instead. When it comes to moving, you have the opportunity to clean, organize, and pack up the things you care about... and disregard the rest! How much or little of this you do is up to you. In this analogy’s case, we’re moving and taking almost everything with us, except the house. We start by figuring out which amenities need to be moved and which can be thrown out. In our SCSM environment, this would be our lists, management packs, work items, etc. Rather than pack everything up one by one and doing the moving ourselves, we can hire a moving company to do all of the heavy lifting for us.
Imagine the Lifecycle Management App as our moving company. With our new house already built, we just need to tell the movers our new address and they’ll do the work for us. The end result is a brand-new house that has all of our amenities organized to our liking. With everything well organized and the new land and infrastructure intact, we feel good about staying in the new house for quite a while.
Hopefully that gets the general idea across, but in case you want to geek out over the technical details, the general technical steps go like this:
- Spin up Windows Server 2019 VMs for the application and database servers, in line with Microsoft’s recommendations. Maybe even consider adapting a more modern infrastructure in Azure or with Server Core.
- Install SCSM 2019 in the new environment, with the database located in the new SQL 2019 instance.
- Configure core items in the new SCSM environment, such as connectors, user roles, and cleaning up out-of-box sample data. Strategize and create these with best practices, avoiding any mistakes from the original environment.
- If using Cireson apps, install the 2019 versions of these apps, the latest Cireson Service Manager Portal, and copy any CustomSpace content.
- Run LMA to move items to the new environment and validate after each. Order is:
- Management packs*
- Clean up what you don’t need in the new environment, without risking data loss
- This is an opportunity to fix issues with naming conventions, remove extensions you no longer need, retire older content, etc.
- Configuration Items*
- Work Items*
- Management packs*
- On go-live day, migrate your work and configuration item deltas since step 5, point your Portal’s DNS to your new server, and you’re live! This step can be done in as little as 5 minutes downtime, and in many cases, without your users even realizing.
*All the above is done in the background, while folks still use your old environment
This approach keeps downtime and risk as minimal as possible, allows your staff to work on their typical schedule instead of cramming this all into a long weekend, and leaves you with a much cleaner environment. You can even take this a step further and use the tool to start cloning Dev and QA environments based on your new Prod environment.
No matter what method of updating you choose, be mindful of Microsoft’s support dates and plan the upgrade of each System Center component in advance—it’s a much less daunting task product-by-product. If you’re still unsure or want to talk any of this over, we’d love to chat– just reach out to us at firstname.lastname@example.org.