Monday, October 3, 2016

Resources & Tips About Upgrading To SCOM 2016


Spoiler Alert:
This posting isn’t about my personal upgrade experiences. That posting will come later. For now this posting is more about the available resources and tips for an upgrade to SCOM 2016.


Can I upgrade from SCOM 2012 RTM/SP1 to SCOM 2016? No you can’t…
Like always, Microsoft only support upgrade path N-1. Meaning, N is the ‘latest & greatest’ which is SCOM 2016 RTM. And N-1 is the most previous version, being SCOM 2012 R2.

At this moment of writing it’s unsure which UR level is required. However, to be on the safe side of things I would prefer to be at least on UR #9 level here.

I know, UR #11 is out for some time now (there is no UR #10 for SCOM 2012 R2), but unlike UR#9, I am still not sure whether UR #11 is issue free. Therefore my personal choice to be on UR #9 level before upgrading to SCOM 2016.

Again, this is my personal choice and approach, until now Microsoft hasn’t made any official statements here.

So when you run an older SCOM 2012 version, like SP1 or even RTM(?!), there is NO direct upgrade path to SCOM 2016! So upgrade to SCOM 2012 R2 first (only possible when running SCOM 2012 SP1, read the N-1 bit of this posting Smile), and then move on to SCOM 2016. However, in situations like these, it’s better to roll out a new SCOM 2016 environment.

Official documentation
Gladly there is official Microsoft documentation on TechNet all about upgrading to SCOM 2016, to be found here. Even though it’s based on TP5, it won’t change that much when System Center 2016 goes GA.

So far the TechNet documentation seems to be pretty complete. Like any other upgrades PREPARATION is key! So follow the official guide lines setout by your company. Make backups! Be sure there is always a way back. Otherwise it’s you on the way out and your next question will be whether the customer wants french fries with their order…

Soon I’ll start upgrading some test environments of myself and share those experiences on my blog.

Some advice
Here are some tips in order to make the upgrade to SCOM 2016 a smooth ride:

Tip #01: Only Upgrade When You’re 100% Sure You CAN Upgrade… 
Ony upgrade SCOM 2012 R2 (UR #9) when you’re sure ALL the moving parts of your SCOM 2012 R2 environment (server OS, SQL and so on) match the SCOM 2016 requirements. Until now only the requirements for System Center 2016 Technical Preview can be found. This will change soon I guess.

Tip #02: Don’t Forget The Pre-Upgrade Tasks
READ and EXECUTE the Pre-Upgrade Tasks. This will save your day (and job…). I’ve seen too many failed uprgades because the people didn’t follow up on that! Which is a shame, because it makes your life so much easier.

Tip #03: Be Patient Or You Might Kill SCOM
Always – when upgrading to the latest version of SCOM – start with ONE SCOM Management Server only! Never ever start the initial upgrade on multiple SCOM MS servers. Why? Because when the first SCOM MS server is upgraded, the related SCOM databases are ‘touched’ as well. As a result multiple SQL scripts are running in order to upgrade those SCOM databases to SCOM 2016. When finished, a flag will be set on those databases, so those scripts won’t run twice. However, when you run the initial upgrade from multiple SCOM MS servers, that flag isn’t set, resulting in the upgrade scripts running multiple times, resulting in a BROKEN SCOM environment. So be PATIENT, and upgrade your enviroment PER SCOM MS sever, even when the first one already upgraded successfully.

Tip #04: Alongside Migration Scenario Can Save You A Lot Of Time/Pain
If there are multiple components not supported by SCOM 2016 (like the underlying server OS for the SCOM Management/Gateway Servers or the SQL server instances used by SCOM), it’s sometimes better to start new and using the Alongside Migration Scenario.

In this type of migration, you build yourself a new SCOM 2016 Management Group and update all existing SCOM Agents (on 2012x level) to SCOM 2016. This will multi-home the SCOM Agents, which will report now to the current SCOM MG – based on SCOM 2012x – and to the new one running SCOM 2016.

As a result the SCOM 2016 Agents will inherit the same GUID, making the import of the Override MPs from the SCOM 2012x to the new SCOM 2016 MG, far more easier. Of course, you have to provision new SCOM Gateway Servers since they can only report to ONE SCOM MG at the time, not more.

But still, you go from a monitoring situation – based on SCOM 2012x – to a monitored situation using SCOM 2016. So there won’t be many ‘black outs’ monitoring wise. No big bangs, but a gradual move to SCOM 2016 instead.

Tip #05: Test It!
Never ever upgrade your production environment like there is no tomorrow. Be patient. First upgrade a test environment and ascertain yourself all is still okay.

Tip #06: Don’t Forget 3rd Parties & Other SC 2012x Components!
Also think about 3rd party software like Derdack Enterprise Alert, SquaredUp, Savision and so on.

Also when SCOM is part of the whole/partial System Center stack, make sure you upgrade the SC components in the right order:
image
As you can see, there is a typo here. My guess is that item #1 should be SCSCM Smile. However, per environment the dependencies can be different. So TALK with all the people and departments involved. Esspecially when SCOM is hooked up to SCSM, it might involve a lot of customized MPs.

Also when there is a dependency with SCVMM, make sure you know what you’re stepping into.

Recap
Only in small and isolated SCOM 2012 R2 UR #x environments, the upgrade might be a small step. Howeverm many times SCOM is bigger AND not an island but hooked up to many other platforms and products. So be carefull in situations like these, prepare yourself thoroughly and only upgrade when you’re sure all the affected products/services officially support SCOM 2016 as well.

10 comments:

Vinay said...

Hi,

I have SCCM SCOM and SCVMM installed. Do I need to upgrade SCCM and SCVMM to 2016 first and thn I should go with the SCOM?

Marnix Wolf said...

Hi Vinay. Follow this article, header Upgrade Sequence: https://technet.microsoft.com/en-us/system-center-docs/get-started/upgrade-to-system-center-2016

Mina said...

Hi,

Currently I am running SCOM 2012 Sp1 and want to migrate to SCOM 2016 , this is the first article I found talking about alongside migration.
I don't want to upgrade to 2012 R2 and then 2016
I have new servers for SCOM 2016.
but now the trick is how to move the current data from 2012 Sp1 on the old servers to 2016 on the new servers.
assuming I completed SCOM 2016 deployment on the new servers, how can I move the data ?
absolutely I can't backup the operations manager DB from 2012 Sp1 and restore it in 2016 because the DB structure is different, so what are the options here ?

Marnix Wolf said...

Hi Mina.

There is no way to 'move current data from SCOM 2012 SP1 into SCOM 2016'. The Along Side migration scenario is meant in such a way that you go from monitored by SCOM 2012 SP1 to being monitored by SCOM 2016, by making the SCOM 2016 Agent multi-homed so it reports to both SCOM MGs.

This scenario isn't meant at all to move data from one SCOM MG to another. I've never done that since it will lead directly to an unsupported SCOM configuration, which happens when you modify the SCOM SQL DBs in any manner.

The only way to 'move' data is to upgrade from SCOM 2012 SP1 to SCOM 2012 R2 to SCOM 2016. However, I strongly advise against such a scenario as well, even though this upgrade path is fully supported by SCOM.

Too many times I've seen SCOM MGs go down when running multiple upgrades. One upgrade, from N-1 (where N is the most current version, SCOM 2016) to N. Meaning from SCOM 2012 R2 to SCOM 2016. BUT only when the SCOM 2012 R2 environment is a fresh install and not the result of a previous upgrade like SCOM 2012 SP1 to SCOM 2012 R2.

In the latter case the outcome is like Russian Roulette. As such the along side scenario was born, also driven by a fellow MVP Cameron Fuller who bumped into the same issues as I did.

So my advise to you is to roll out a brand new SCOM 2016 environment, run the along side scenario as discussed, migrate the custom MPs from SCOM 2012 R2 to SCOM 2016 *(be careful with the Override MPs since some are meant ONLY for the SCOM 2012 R2 MG, like the Secure Reference MP, containing ALL run as accounts, also the ones SCOM uses for Action Account, SDK and so on...).

Also what you can do is to phase out the SCOM 2012 R2 MG when the SCOM 2016 has taken over the monitoring and reporting functionality fully. And even when phased out, just keep it running for the reports as long as required. After that, break it down and remove it.

These are just my two cents but would be my advise in any official customer engagement.

Cheers,
Marnix

Mina said...

Hi Marnix

I believe this scenario is the best since the upgrade operations always encounter a lot of unexpected failures as you mentioned.
but after I complete the Along side migration, all the agents will be multi homed , how can I remove the old Management group from the agents before breaking the 2012 environment ?

Thanks,
Mina Hanna

Marnix Wolf said...

Hi Mina.

Good decision and a good question. The removal of the old SCOM MG from the Agents is quite easy actually, even more when the SCOM Agents were originally deployed from the SCOM Console of the old MG. It doesn't even matter when those Agents are upgraded to SCOM 2016 Agents since they're backwards compatible with SCOM 2012x. The old SCOM MG will treat them as remotely manageable, which is nice.

Simply from the SCOM Console of the old MG, give the SCOM Agents an uninstall. What will happen is that the SCOM Agent will 'know' it reports to another SCOM MG as well. Instead of remove itself, it will remove the entries of the SCOM MG which sent it the uninstall command.

As a result the SCOM Agent which was previously multi-homed (reporting to two SCOM MGs instead of 1), the SCOM Agent becomes 'single homed', reporting to the new SCOM 2016 MG only.

Test it first with a few agents and you'll see it works like a charm.

When the SCOM Agent is manually installed you need to perform two steps in this order:
01: Remove SCOM Agent from the system manually. Of course you can use a cmd line for it, check this out: https://blogs.technet.microsoft.com/jonathanalmquist/2009/12/30/agents-remove-configured-management-group-or-uninstall-agent-using-command-line/
02: When the SCOM Agent is removed from the system, DELETE it from SCOM (Uninstall won't do the trick).

All the best with it Mina.

Cheers,
Marnix

SCOMMER said...

Hi there,

Reading the above comments seem to suggest that multi-homing is the best method, i agree.

Marnix, have you tested this with multi-homing agent between SCOM 2012 SP1 management group and a new 2016 Management group? I want to migrate from 2012 SP1 to 2016.
Thanks

Marnix Wolf said...

Hi SCOMMER.

I haven't. But simply test it by installing a SCOM 2016 UR#2 Agent on a Windows server currently being managed by your SCOM 2012 SP1 MG. My guess is it will work. When it does, you know it will also work with your new SCOM 2016 UR#2 MG.

Cheers,
Marnix

Unknown said...

Hi Scommer,

have you done a test with a 2012SP1 Agent and SCOM2016 System?
If yes, please let us know the result :).

Thanks in advance,

Julian

Marnix Wolf said...

Hi Fra Jules.

No I haven't. But to be frank, I expect it to work because the SCOM 2012 SP1 Agent isn't that much different compared to a SCOM 2012 R2 Agent.

Cheers,
Marnix