Note: Wall of Screenshots – G3 Killer 😉
– Upgrade Setup
– Docs needed
– Prerequisites Check
– Upgrade Path Checklist
– Time to upgrade
– Post-Upgrade Tasks
– RMS Cluster Removal
– Reintegrating the RMS Nodes
This is pretty raw footage of my SCOM Upgrade Beta Lab. If you find any typos, you can keep them 😉
I won’t cover issues & fixes that much in this blog post, only the ones that affect setup. Operations Manager Log cleanup may be worth an additional blog post. I don’t have many of them though.
Database and Agent
SCOMTEST001 – 2008 R2 Standard with SQL 2008 R2 CU5
RMS Cluster SCOMTEST000 on SCOMTESTCluster
SCOMTEST002 – 2008 R2 Enterprise
SCOMTEST003 – 2008 R2 Enterprise
SCOMTEST004 – 2008 R2 Standard
No upgrade before reading the documentation, right?
My main source of information will be TechNet: http://technet.microsoft.com/en-us/library/hh205987.aspx
Also, which I did beforehand was studying the Upgrade guide of the Beta Documentation which you can find here.
Before checking 2012 Prerequisites
Not much point in upgrading a broken environment, therefore the first thing I’m gonna do is double-checking if all my roles function properly.
Check OpsMgr Logs, check Management Server Health Status, check Database.
Once this is fine I can proceed. It actually is, therefore I proceed 🙂
Second thing, let’s check Supported Configurations
Aside from some common parameters the most important things I noticed:
– Management Servers need to be 2008 R2 64-Bit
In my production environment this means that I have to upgrade most of my Management Servers to R2 first before upgrading.
This is not a big deal in itself as I won’t need any downtime.
– All Roles need to be at CU4 patch level
This however, is a bigger problem due to the issues with the CU4 setup, which would cause some services to restart.
In my LAB environment this isn’t a problem but I won’t run the CU4 update in production. CU5 beta is already available so it can’t take too long to get the RTM.
– .net 3.5 and 4.0
Many features of 2012 need .net 3.5 and 4.0. Since the agents themselves don’t seem to need that, it’s not a big deal.
Upgrade Path Checklist and finding the right Path
First things first, the official Pre-Upgrade Tasks – I did them by the book: http://technet.microsoft.com/en-us/library/hh205986.aspx
As I have mentioned already in Part 1 of this blog post, I’m gonna go with a Distributed Management Group with unsupported Configuration Upgrade.
The top level tasks suggest the following approach:
– Import the Upgrade Helper Management Pack
– Replace Secondary Management Servers
– Replace Gateways
– Secondary Management Server Upgrade
– Management Group Upgrade from RMS or, and in my case: Management Group Upgrade from Secondary Management Server
What about the Agent Upgrade?
Agent Upgrade decision
The first thing I notice here is that it doesn’t suggest upgrading the agents first, at least not that clearly. In the webcast about the Upgrade they said you should upgrade the agents first as R2 Agents won’t be able to communicate with 2012. Let’s quote TechNet here, which is not as clear:
The order in which you upgrade the agents depends on how they were deployed (manually installed or push-installed), and whether your root management server (RMS) meets the supported configuration requirements for Operations Manager 2012. You also must perform a number of pre-upgrade and post-upgrade tasks, and might perform some optional upgrade tasks.
While TechNet tells me the correct logical steps, it overcomplicates things by not telling me the following:
– R2 Agents can’t communicate with a 2012 Management/Gateway Server.
– R2 Gateway Servers can’t communicate with 2012 Management Servers
This was said in a recent webcast about the 2012 Upgrade!
In my case, I have manually installed Agents, so the logical steps are pretty clear.
However, if you have Push Install Agents, you can upgrade the Agents from a 2012 Management/Gateway Server. Therefore, if you have Push Agents, you might have downtime for them. (Maybe I’m gonna check that in my second Upgrade Test).
My Upgrade Path
– Upgrade Agent
– Backup Database (done)
– Backup and restore the Encryption Key on the Secondary Management Server (done)
– Upgrade Gateways (not present in Lab)
– Upgrade Management Server
– Upgrade Management Group from secondary Management Server
Time to Upgrade
– Upgrade Agent
– Backup Database (done)
– Backup and restore the Encryption Key on the Secondary Management Server (done – and I apparently did it wrong. It appears like the Restore doesn’t count if it was done on R2. I had to rerun it on 2012)
– Upgrade Gateways (not present in Lab)
– Upgrade Secondary Management Server
– Upgrade Management Group from Secondary Management Server
Upgrading the Agent
Read this documentation carefully as there are some implications that aren’t self-explanatory. Basically, if you have the Web or Operations Console installed, uninstall them first. I guess this doesn’t go for the Authoring Console as a new one is not available. To verify that, I’m gonna install it first just to see what happens. Authoring Resource Kit (and it doesn’t cause any problems).
Time to download Beta, which I already did. You can get it here.
Pretty redundant screenshots to be honest.
I know I’m picky here but the final page could be a bit more context based, it actually looks like it’s one and the same for Installation/Upgrade.
At least the Pending Management suggestions don’t make much sense.
Upgrading the Agent ain’t rocket science, but does it work?
Actually, I was gonna give it a Health State reset, but the setup already did that.
– Active Directory Integration works
– Connection to Management Server works
– Management Packs Load
– 1210 Event is here
And, I wanna see if the Management Server responsible for this Agent reports any problems.
No errors nor warnings. I’d say it works.
Another thing I’m really interested in is if the R2 Console works with 2012. Therefore I first check if the 2012 Console works with R2.
Upgrading the Secondary Management Server
First you need to download and install the SCOM2012BETA package. Default Folder is then C:\SCOM2012BETA
Upgrading the Management Group from Secondary Management Server
So, this is actually the interesting part for me as this will be the most critical step in my production environment as well.
Time to read the documentation: How to Upgrade a Management Group from a Secondary Management Server to Operations Manager 2012.
– “You should first upgrade other features, such as secondary management servers, agents, and gateways before running the final upgrade on the management group”
– “an account that is a member of the Operations Manager Administrators role for your Operations Manager 2007 R2 management group and a local administrator on the computer. You also need SQL Server Administrator rights on both the Operational database server and the data warehouse server.”
The Management Group Upgrade page comes with an important note regarding the RMS Removal.
And here it actually tells me that I should upgrade from a secondary MS in case I have a clustered RMS. Would be nice to have that mentioned in the documentation somewhere though.
Fix and restart setup.
Interesting point: I restored the Secure Keys on this server already but when it had the R2 MS installed.
Note: There is no new SecureStorageBackup tool, you have to use the one from R2.
Note: You have to copy the installation files of 2007 R2 from a Management Server that wasn’t upgraded yet to have all the necessary assemblies.
Configure Accounts. Next.
Check Installation Summary.
That was easy.
Aside from that, I did the Post-Upgrade Tasks by the book:
RMS Cluster Removal
Once the Management Group Upgrade is finished, the RMS Cluster is removed from the Management Group.
As pointed out in the documentation, you have to uninstall SCOM R2 from it.
And, I don’t need the cluster application anymore.
If you don’t need the whole cluster anymore, you can as well destroy the whole cluster.
In my case, the production Cluster also has a file share on it, therefore this is not an option for me.
Make sure you restart the Servers after uninstallation is finished.
Also delete the key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0
Uninstallation doesn’t delete the following value: HealthServiceVirtualHost
And 2012 Setup will assume it’s still a RMS cluster node.
Reintegrating the RMS Nodes
This is the same for all the RMS Nodes, you just have to install the Management Server Component.
The Management Server for this management group is clustered.
It’s actually not, as mentioned before the uninstall of R2 doesn’t remove the value HealthServiceVirtualHost from Key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0
Once you delete this key/value it works.
Fix and rerun.