Migrating from SCOM R2 CU#5 to OM12. Part IV: Upgrade Tasks for Operations Manager

----------------------------------------------------------------------------------
Postings in the same series:
Part   I - The environment
Part  II - Prepare yourself
Part III – Pre Upgrade Tasks for Operations Manager
Part V  – Upgrade Tasks for Operations Manager, continued
Part VI – Wrapping Up  
----------------------------------------------------------------------------------

In the fourth posting of this series, I will describe in detail the actual upgrade process of the SCOM R2 CU#5 environment itself. The previous postings were all about preparing the environment in order for a smooth upgrade to OM12. As a matter of a fact, like many other migrations, the preparations take up most of the time. However, when the preparations are done as advised by Microsoft, without any shortcuts, changes are that the upgrade itself will run just fine. Be aware though that you still need to be careful and not to think lightly about it.

Still remember the environment I built for this series of blog postings? In order to refresh your memory, I’ll show it again:

Forest: SCOM2OM12.local

1. SCOM-DC01: AD Controller for forest SCOM2OM12 and Enterprise PKI;
2. SCOM-DB01: SQL Server with SSRS;
3. SCOM-MS01: RMS;
4. SCOM-MS02: MS.

Forest: NTE.local

1. NTE-DC01: AD Controller for forest NTE;
2. NTE-GW01: SCOM R2 Gateway Server;
3. NTE-SV01: Member Server.

In a simplified Visio drawing the environment looks like this:

Let’s start with the upgrade.

Upgrade Tasks for Operations Manager
When looking at the Distributed Upgrade (Simple) Process Flow Diagram, these are the step which we are going to make today:

Again, the diagram itself isn’t all you need. The documentation (online and as Word documents for download) is just as important, so use that as well.

It might sound boring – since I am repeating myself here – please know this: ‘…The starting point for an upgrade is having an Operations Manager 2007 R2 topology and ensuring that all hardware and software meets the supported configurations for System Center 2012 – Operations Manager…’.

In my case everything is prepped and ready to go! Let’s check the Console in order to see all is OK:

Wow! That’s NOT good! Or isn’t it? Remember we imported the Upgrade Helper Management Pack yesterday? So perhaps that’s in play here. Open per Windows Computer the Health Explorer in order to see what’s going on:

Phew! So this is by design, nothing wrong here. However, check every SCOM R2 Management server (RMS, MS and Gateway(s)) to be sure.

Another thing to reckon with is the OpsLogix Ping MP. A nice MP it is. However, it adds some functionality to the SCOM R2 Console by placing a DLL file in the same folder as where the SCOM R2 server/console is installed. When that DLL file is still in place when the server is upgraded to OM12, the Console WON’T start. So REMOVE that file (OpsLogix.IMP.Base.UI.dll).

Now everything is OK and we’re ready to rock!

Step A: Pre-Upgrade Tasks
We already covered that yesterday, so we can skip this step. Perhaps an additional check is needed but that’s about it. Time to move on.

Step B: Upgrade manually installed Agents
In this scenario all Agents are installed by using the Push method. So we can skip this step as well. Nice! We’re making progress here!

Step C: Secondary Management Server Upgrade
Since this is a distributed environment, we start by upgrading any secondary SCOM R2 Management Server. This DOESN’T mean the RMS nor ANY Gateway Server. In my test environment it means I have to upgrade the SCOM-MS02 server.

During this upgrade process the Management Server will become unavailable to all the servers, clients and network objects reporting to it. When the Agents are pushed out they will failover automatically. This won’t be the case for the monitored network objects however, nor when this server is also a Watcher Node for some or more synthetic transactions. So keep this in your mind and more important COMMUNICATE it with all the parties involved…

1. I insert the installation media of OM12, start it WITH ELEVATED PERMISSIONS and choose Install
   
   
   
2. That’s nice! Setup detects an upgrade path > Next
   
   
   
3. The Installation Location is automatically chosen > Next
   
   
   
4. Now a check for the requirements is started. In my case I get a warning about not having enough memory available. I simply ignore it since it’s a test environment only. In production environments however it’s advised to add more RAM! > Next
   
   
   
5. Now the account information has to be added. I strongly advise to use AD accounts and not LOCAL accounts! Add the required account information > Next
   
   
   
6. And the Upgrade is ready to start > Upgrade
   
   
   
7. This will take a while. Gladly the different stages of the upgrade process are neatly shown:
   
   
   
   
8. At some point in time you’ll get to see this message:
   
   Please note the checkbox for Launch Microsoft Update when the wizard closes. Yes, OM12 can be updated through the same mechanisms as your Windows Server. Be careful though since we all know what CU#3 and CU#4 did with restarting non-SCOM related services… But that’s just me.
   
   Click Close. And the secondary SCOM Management Server is successfully updated to OM12!
   
   
9. Let’s start the OM12 Console. Looking good:
   
   
   Ouch! What’s wrong?
   
   Nothing actually! Let me explain.
   
   The new OM12 expects the Data Access service to be running on the upgraded secondary Management Server. In OM12 there isn’t a RMS any more, remember? And yes, the new Data Access service is running but there is nothing to connect to since all the other components – like the Operational Database for instance – is still at SCOM R2 CU#5 level!
   
   
   So now you say, let’s connect the OM12 Console to the RMS than. Wrong again! Why? Well, the Data Access service, which is needed for any Console connection, is totally revamped in OM12. Therefore the OM12 Console won’t recognize the old Data Access service as such and the same error will be thrown.
   
   Therefore we go to the RMS and start the SCOM R2 Console on that server. And yes, it works. Let’s check the status of our upgrade:
   
   
   Yes! Step 1 of upgrading our SCOM environment went just fine! Time to move on to the next Step, upgrading the Gateway Server(s).

Step D: Gateway Server Upgrade
Now it’s time to upgrade the Gateway Server, in my case the NTE-GW01. Let’s start.

1. I insert the installation media of OM12, start it WITH ELEVATED PERMISSIONS and choose Gateway management server
   
   
   
2. The Gateway Server Upgrade Wizard program is started automatically. Nice! > Next
   
   
   
3. Phew! Not much information is needed here :) > Upgrade
   
   
   
4. Now the upgrade is running. This might take a while, depending on the server specs. And after a while this screen pops up:
   
   > Finish.
   
   
5. Let’s check the SCOM R2 Console:
   
   Yes! We’re doing great! Time to move on to the next step, let’s upgrade the Agents. All of them are pushed so the update can be done from the Console as well.

Step E: Pushed Agents Upgrade
This might sound very easy. And actually it is. But there are some caveats to reckon with, all documented in the Deployment Guide, page 154:

Sometimes, the Agents don’t appear in Pending Management. When that’s the case, and a reboot of the related Management Server or Gateway doesn’t work, the workaround is to start a Repair of those Agents through Administration > Device Management > Agent Managed.

Select a bunch of server which are managed by the same Management Server, right click and select Repair. Soon your Agents will be at OM12 RTM level, which is version 7.0.8560.0. In my case the Demo Devil paid me a visit and the Agents didn’t appear in Pending Management.

Another thing I have seen is that there is still a folder present on the upgraded secondary Management Server, like: C:\Program Files\System Center Operations Manager 2007. This folder still contains a subfolder called Agent Management, containing (per architecture) the AD Helper and .NET Helper objects. Simply rename that folder to C:\Program Files\System Center Operations Manager 2007_OLD for instance. Run the Repair again and you’re in good shape.

So I upgraded them using the workaround and soon all was just fine:

Now I had to upgrade my Xplat Agents. However, I don’t have them so that’s an easy one. Now it’s time to upgrade the RMS, the databases and SCOM Reporting. But that will be described in the next posting of this series. See you all next time!