I’ve got a SCOM2016 management group of 6 management servers, 2 gateways and need some advice please.
I’m trying to work out the easiest way to upgrade to SCOM2019 without having to rebuild loads of custom monitoring, or redo dashboards etc. This is complicated by the face that the management servers are running Server 2012 R2 - out of interest, I know it’s not supported, but will SCOM2019 run on Server2012?
My initial plan was to stand up new Server 2019 VMs, add them into the Management Group, rehome the agents, retire the server 2012 Management Servers and then upgrade to SCOM2019. This ought to work, however all my *NIX agents are manually installed. Am I going to have to manually sign certs and install the agent on these to point at the new Management Servers?
I’d be very grateful for any advice from anyone who’s been down this road before!
Fortunately I recently replaced my SCOM SQL backend to SQL2019 on Server 2019, so that’s a big chunk of work done.
Side-by-Side
Let’s start with your most recent reply about doing a side-by-side. When objects are migrated, most times, they get a brand new GUID. That means if you have references in your management packs to specific objects, then those relationships would be lost. So, a side-by-side might be problematic for you. I guess this approach would depend on how many EAs you have and how complicated are they? It’s entirely realistic to do a side-by-side migration, but it’s tedious.
Add new 2019 Management Servers to your existing Management Group
As for your SCOM 2016 management group running on Server 2012 R2 (I’m assuming R2 because it scares me if you’re running 2012).
I “believe” you could:
Stand up a couple of new 2019 VMs.
Add them to your 2016 SCOM management group (as 2016 Management Servers).
Phase-out your 2016 management servers (that are running on server 2012R2).
Once complete, upgrade your management group to SCOM 2019.
Upgrading to 2019
Keep in mind that when you upgrade your 2016 SCOM management group to 2019 SCOM, you will not be able to monitor Windows 2012 or Windows 2012 R2.
Linux Agents
The bane of Linux management is the certificates. When you install new management servers, you will need to create a certificate mesh. You can do a lot of that work from within SCOM and maintain monitoring. It’s annoying and time-consuming, but definitely possible. When you phase out the 2016 management servers that exist on Windows 2012, you will need to remove their certificate. In other words, get familiar with the process because you are going to be this a lot.
Here are some links to some blog posts that should help:
From what you’ve presented, there is no reason not to do an in-place upgrade. I have done so starting from SCOM 2012 on Windows 2008 R2 over to SCOM 2019 on Windows 2019. Even upgrading SQL version, OS of SQL, migrated to Always-On, all while keeping the same MG, so yes, what you’re facing is quite possible.
I would upgrade the OS first to the latest supported of the SCOM version you’re running, then upgrade the SCOM version and if needed you can go back and forth between both. I will assume you’re running everything on VMs so you can adjust resources as needed.
< rant >Side note, I am always, err amazed, at the “expert” recommendations to do Side-by-Side upgrades as they seem to forget that real-world, the gazillion of custom overrides (this server has override A, but server next to it has override B), the specialized MPs, the purchased MPs linked to an MG, the Unix agents, the loss of historical data, etc… Add to that, you’ll have a moving target while you do the ~6 months to prep as the “old” MG will need to be maintained (overrides and stuff) < /rant >
I rest my case, your honor…