SCOM 2007 R2 CU#7 & SCOM 2012 R2 RTM: Does It Work?

2013-10-17 Update:
I have just downloaded the RTM version of SCOM 2012 R2. And tested this scenario with the SCOM 2012 R2 MMA. And yes, this works as well. I have updated the blog posting accordingly.

Yesterday evening I had an interesting discussion with fellow MVP and friend, Cameron Fuller. He asked me whether a Microsoft Monitoring Agent (MMA) will work on a server which was formerly covered by a SCOM 2007 R2 Management Group, resulting in a multi-homed MMA reporting to a SCOM 2007 R2 MG and to the SCOM 2012 R2 RTM MG.

Since a single picture clarifies a lot, the above described scenario looks like this:

And the question is: DOES it work? So it was time to test this scenario. Even more because tomorrow SC 2012 R2 will be released to the public and many companies are still on SCOM 2007 R2 level.

For this I built myself to single-server-MGs. This kind of MG is only viable for quick test runs for this kind of scenarios and nothing more. So never ever run such a MG in a production environment or test environment. I always break these MGs down after the scenario is tested. So no activation of the software is required.

My test lab
For this particular scenario I had built myself these three servers. These are the FQDNs and their related functionality:

1. 2007R2.sc.local
   This server runs SQL Server 2005 x64 ENU Enterprise edition SP4 with SCOM 2007 R2 CU#7 Root Management Server, without Reporting installed. Guest OS: Windows Server 2008 R2 SP1 ENU, Standard edition. This is a single-server-MG for SCOM 2007 R2 CU#7.
2. SCOMAgent.sc.local
   This server will be monitored by the SCOM 2007 R2 MG in the beginning. Later on this SCOM 2007 R2 Agent will be replaced by MMA and – hopefully – become multi-homed, reporting to the SCOM 2007 R2 MG and the SCOM 2012 R2 MG. Guest OS: Windows Server 2008 R2 SP1 ENU, Standard edition.
3. 2012R2.sc.local
   This server runs SQL Server 2012 SP1 x64 ENU Standard edition with SCOM 2012 R2 RC Management Server, with Reporting installed. Guest OS: Windows Server 2012 R2 RTM, Standard edition. This is a single-server-MG for SCOM 2012 R2 RC.

The test scenarios
There are multiple test scenarios, where the first two are basic and no-brainers. Scenarios 3 and 4 will more be exiting .

1. Test Scenario 01: The SCOM 2007 R2 CU#7 MG monitors the Windows server SCOMAgent.sc.local
   First of all, I will start monitoring the server SCOMAgent with the SCOM 2007 R2 CU#7 Agent. Now this is a no-brainer and works as expected:
   
   
   
2. Test Scenario 02: The SCOM 2012 R2 RC MG monitors the Windows server SCOMAgent.sc.local
   Basically this is a no-brainer as well. The SCOM 2012 R2 RC MG will discover this server and the SCOM 2007 R2 CU#7 based Agent. Now it will replace it with the MMA which will report to the SCOM 2012 R2 RC MG:
   
   
   
3. Test Scenario 03: The MMA will become multi-homed and report to BOTH SCOM MGs
   This scenario will happen automatically. MMA will know there was an old SCOM Agent (the SCOM 2007 R2 CU#7 Agent) reporting to another SCOM MG. So the MMA will multi-home itself and start reporting to both MGs: the SCOM 2007 R2 CU#7 MG and the SCOM 2012 R2 RC MG.
   
   Question here is whether the SCOM 2007 R2 CU#7 based MG will accept the communication from the MMA. Without a doubt the MMA works perfectly with the SCOM 2012 R2 RTM MG as seen with Test Scenario 02.
   
   Let’s take a look at the configuration of the MMA on the server SCOMAgent.sc.local itself:
   
   This looks promising since the MMA has indeed multi-homed itself. As expected, it reports to two MGs. One of those MGs is SCOM 2007 R2 CU#7 based and the other SCOM 2012 R2 RC based.
   
   How about the SCOM event log on the same server? Best test here is to stop MMA, flush the cache (remove the HealthState folder), empty the SCOM event log and start MMA again. That way we have a nice clean crisp start situation, forcing the MMA to recollect all MPs from BOTH MGs. So whenever the SCOM 2007 R2 CU#7 MG refuses to communicate with the MMA, we’ll know it.
   
   Good signs:
   This is looking GOOD! EventID 21023 tells us that the MMA is requesting new configuration from the Management Group. And in this case the MMA logs EventID 21023 for BOTH MGs:
   
   The SCOM 2007 R2 CU#7 MG:
   
   
   The SCOM 2012 R2 RTM MG (as expected):
   
   
   Afterwards many other important EventIDs will be logged. But the most important one is EventID 1210 telling us the new configuration of the MMA became active. Basically this EventID shows the MG has accepted the MMA.
   
   The SCOM 2007 R2 CU#7 MG:
   
   The SCOM 2012 R2 RC MG (as expected):
   
   
   Let’s check the SCOM 2007 R2 CU#7 Console:
   
   
   The SCOM 2012 R2 RC Console:
   
   
   Another test: I have built myself in SCOM 2007 R2 a Service Monitor based on the MP Template. This service monitor checks the health of the Hyper-V Guest Shutdown Service running on the SCOMAgent.sc.local server and the SCOM 2007 RMS as well. And the MMA executes this Monitor properly:
   
   
   
   Test Scenario 4: Will the standalone RTM MMA work as well with SCOM 2007 R2?
   This can be tested since the RTM version of MMA is already available for download. So let’s download it and install it on the SCOMAgent.sc.local server and see what happens.
   
   After the installation of the standalone version of the MMA, it’s still communicating with both MGs:
   
   
   Let’s run the same check again: Stop MMA, flush it, empty the SCOM even log and start the MMA again in order to see what happens.
   
   Okay, EventID 21023 for both MGs is logged. That’s a good start . And YES! EventID 1210 for BOTH MGs is logged as well!
   The SCOM 2007 R2 CU#7 MG:
   
   
   The SCOM 2012 R2 RTM MG:
   
   
   And YES, the MMA which is available as a separate download is of a newer version compared to the MMA provided by SCOM 2012 R2 RC. And as it turns out, the version of the standalone MMA is exactly the same as the MMA version used by the RTM version of SCOM 2012 R2.
   
   The SCOM 2007 R2 CU#7 Console:
   
   
   The SCOM 2012 R2 RC Console:
   

Conclusion
The MMA (up to version 7.1.10184.0 which is part of SCOM 2012 R2 RTM) works perfectly with SCOM 2007 R2 CU#7 based MGs.

This is really good news since it opens the path for many organizations still running SCOM 2007 R2 CU#7 and wanting to migrate to SCOM 2012 R2 RTM.

And NO. There is NOT a single upgrade path available from SCOM 2007 R2 CU#7 to SCOM 2012 R2 RTM. It will still involve (too?) many steps:

1. SCOM 2007 R2 CU#7 > SCOM 2012 RTM
2. SCOM 2012 RTM > SCOM 2012 SP1
3. SCOM 2012 SP1 > SCOM 2012 R2 RTM.

Multi-homed Migration Scenario
HOWEVER. As it seems now, the MMA communicates fine with a SCOM 2007 R2 MG. So this opens the way to a whole different approach with rolling out SCOM 2012 R2 RTM. Instead of going through the pains of a multi staged in-place upgrade from SCOM 2007 R2 to SCOM 2012 R2 RTM, you instead opt for the option of a Multi-homed Migration scenario.

In this scenario a whole new SCOM 2012 R2 RTM MG is built. The MMAs are pushed out to all monitored Windows Servers. In case there is a SCOM 2007 R2 CU#7 Agent on it, the MMA will replace it and become multi-homed. We know now, that the MMA (up to version 7.1.10184.0) works well with SCOM 2007 R2 CU#7 based MGs.

There are multiple advantages here:

1. No down time of monitoring;
2. A phased migration project;
3. No burdens of the past are put into the new SCOM 2012 R2 RTM MG;
4. Lessons learned can be implemented from day one in the new SCOM MG;
5. MPs containing overrides can be transferred to the new MG as well, even overrides targeted at Server objects since the multi-homed MMA will inject the same GUIDs.

Some challenges – related to transferring MPs with overrides - are:

1. Overrides targeted at certain Objects instead of a Group;
2. Overrides targeted at Groups with explicit members;
3. Overrides targeted at non-Windows Computer objects.

When you want to know more about the Multi-homed migration, read this posting of my fellow MVP buddy (and friend), Cameron Fuller.