There are three approaches which can be used for deployment or migration of Operations Manager. These are:
- Fresh installation: Used for a new installation of Operations Manager 2012 or when the existing Operations Manager 2007 R2 environment is either non-viable or unused.
- In-place upgrade: Used to upgrade an existing OpsMgr 2007 R2 environment to OpsMgr 2012. This approach requires that the management server are on Windows Server 2008 R2 or higher and that the database is on SQL Server 2008 R2 or higher. This approach should work but we have seen that when it fails it fails in a way that the environment needs to be restored back to a backup. The benefits to an in-place upgrade are retention of the existing data in the data warehouse, and potentially a shortened coexistence timeframe since the the migration is completed when the upgrade is completed.
- Multi-homed migration: This approach installs a new OpsMgr 2012 environment, upgrades agents to OpsMgr 2012 and the agents report to both the original OpsMgr 2007 R2 environment and the OpsMgr 2012 environment. This works well for environments where there can be no down time to monitoring and where a longer co-existence period is acceptable. By moving sealed management packs between the environments, most of the overrides which were created can be moved to the OpsMgr 2012 environment.
Issue: The problem I have seen in the past however is with overrides which were created to a server instead of a group. If the override is created to a server it’s stored to the guid of the server. In one of my client sites we found that when the server is multi-homed, a new guid is assigned to the server in the OpsMgr 2012 environment. So attempts to migrate these management pack configures to the new OpsMgr 2012 environment fail.
Blog Post Goal: The goal of this blog post was to investigate the multi-homed migration to determine if custom management packs which reference specific server(s) could be migrated between the management groups in a multi-homed configuration. If this was not possible the goal was to develop a conversion process to take existing override management packs which include overrides targeted to specific servers and to convert those management packs to the new environment and convert the guid for the server in the new environment.
Steps to create the test environment:
To create this test lab, I installed an OpsMgr 2007 R2 all-in-one environment and added a Windows Server 2008 R2 box called Agent01. I deployed an OpsMgr 2007 R2 agent to the Agent01 server.
Below shows the Agent01 server monitored by OpsMgr 2007 R2 management group “Group1” shown below:
Next I installed an OpsMgr 2012 environment for a management group called “Group 2” as shown below;
And I performed a multi-homed upgrade of the agent by pushing the 2012 agent from the OpsMgr 2012 server. The result is shown below where Agent01 is now reporting to both management groups and has the new Operations Manager Agent control panel feature.
And is now monitored as healthy in both environments, with the updated Goup2 management pack shown below:
Question: Do overrides created to a specific server migrate successfully in a multi-homed configuration?
To test this question I created an override targeted to the Agent01 server in the Operations Manager 2007 R2 environment: (Total CPU Utilization Percentage)
By creating an override for a specific object of class.
And chose Agent01 as the object to override.
For this example I set it to a CPU threshold of 2 or higher and a queue of 0 or higher to increase the frequency of this monitor triggering. I then stored this in the “overrides management pack”.
I also decreased the interval seconds to 60 and the number of samples down to 1.
On Agent01, I created a quick script to increase the CPU utilization on Agent01 and watched for the alert to trigger successfully:
Which generated an alert in OpsMgr 2007 R2 as shown below: (note the queue length of 2 and the cpu value of 30% which indicates that the override worked in the OpsMgr 2007 R2 environment)
If we export this override management pack (overrides management pack) we see the following XML:
<?xml version="1.0" encoding="utf-8"?><ManagementPack ContentReadable="true" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<Manifest>
<Identity>
<ID>Overrides.Management.Pack</ID>
<Version>1.0.0.0</Version>
</Identity>
<Name>Overrides Management Pack</Name>
<References>
<Reference Alias="SystemCenter">
<ID>Microsoft.SystemCenter.Library</ID>
<Version>6.1.7221.81</Version>
<PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
</Reference>
<Reference Alias="Windows">
<ID>Microsoft.Windows.Library</ID>
<Version>6.1.7221.0</Version>
<PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
</Reference>
<Reference Alias="Windows1">
<ID>Microsoft.Windows.Server.2008.Monitoring</ID>
<Version>6.0.6972.0</Version>
<PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
</Reference>
</References>
</Manifest>
<Monitoring>
<Overrides>
<MonitorConfigurationOverride ID="OverrideForMonitorMicrosoftWindowsServer2008OperatingSystemTotalCPUUtilizationForContextMicrosoftWindowsOperatingSystemce2ad40d6a19416ea29b836e1d631b69" Context="Windows!Microsoft.Windows.OperatingSystem" ContextInstance="2af913ae-04b6-18d3-1355-a9ec8829afe8" Enforced="false" Monitor="Windows1!Microsoft.Windows.Server.2008.OperatingSystem.TotalCPUUtilization" Parameter="CPUPercentageThreshold">
<Value>2</Value>
</MonitorConfigurationOverride>
<MonitorConfigurationOverride ID="OverrideForMonitorMicrosoftWindowsServer2008OperatingSystemTotalCPUUtilizationForContextMicrosoftWindowsOperatingSystem5a878ec47311418eb8ea41e8324332bc" Context="Windows!Microsoft.Windows.OperatingSystem" ContextInstance="2af913ae-04b6-18d3-1355-a9ec8829afe8" Enforced="false" Monitor="Windows1!Microsoft.Windows.Server.2008.OperatingSystem.TotalCPUUtilization" Parameter="CPUQueueLengthThreshold">
<Value>0</Value>
</MonitorConfigurationOverride>
<MonitorConfigurationOverride ID="OverrideForMonitorMicrosoftWindowsServer2008OperatingSystemTotalCPUUtilizationForContextMicrosoftWindowsOperatingSystem1ead19ccf8c04ffd898f680a56de7e68" Context="Windows!Microsoft.Windows.OperatingSystem" ContextInstance="2af913ae-04b6-18d3-1355-a9ec8829afe8" Enforced="false" Monitor="Windows1!Microsoft.Windows.Server.2008.OperatingSystem.TotalCPUUtilization" Parameter="IntervalSeconds">
<Value>60</Value>
</MonitorConfigurationOverride>
<MonitorConfigurationOverride ID="OverrideForMonitorMicrosoftWindowsServer2008OperatingSystemTotalCPUUtilizationForContextMicrosoftWindowsOperatingSystem555fc1d5d4d8497591629dcb1211dbde" Context="Windows!Microsoft.Windows.OperatingSystem" ContextInstance="2af913ae-04b6-18d3-1355-a9ec8829afe8" Enforced="false" Monitor="Windows1!Microsoft.Windows.Server.2008.OperatingSystem.TotalCPUUtilization" Parameter="NumSamples">
<Value>1</Value>
</MonitorConfigurationOverride>
</Overrides>
</Monitoring>
<Presentation>
<Folders>
<Folder ID="Folder_575d178e7351464ebdc1c2e11bff0c03" Accessibility="Public" ParentFolder="SystemCenter!Microsoft.SystemCenter.Monitoring.ViewFolder.Root" />
</Folders>
</Presentation>
<LanguagePacks>
<LanguagePack ID="ENU" IsDefault="false">
<DisplayStrings>
<DisplayString ElementID="Overrides.Management.Pack">
<Name>Overrides Management Pack</Name>
</DisplayString>
<DisplayString ElementID="Folder_575d178e7351464ebdc1c2e11bff0c03">
<Name>Overrides Management Pack</Name>
</DisplayString>
</DisplayStrings>
</LanguagePack>
</LanguagePacks>
</ManagementPack>
Note the bolded areas above: ContextInstance="2af913ae-04b6-18d3-1355-a9ec8829afe8".
A check of this in the BaseManagedEntityEd as shown below indicates that the object is related to Agent01 in the OpsMgr 2007 R2 environment:
/****** Script for SelectTopNRows command from SSMS ******/
SELECT TOP 1000 [BaseManagedEntityId]
,[BaseManagedEntityInternalId]
,[BaseManagedTypeId]
,[FullName]
,[Path]
,[Name]
,[DisplayName]
,[TopLevelHostEntityId]
,[IsManaged]
,[IsDeleted]
,[LastModified]
,[OverrideTimestamp]
FROM [OperationsManager].[dbo].[BaseManagedEntity]
where BaseManagedEntityId = ‘2af913ae-04b6-18d3-1355-a9ec8829afe8’
A select from the database reveals that this GUID is related to the Agent01 system on the Operations Manager 2007 R2 environment:
BaseManagedEntityId BaseManagedEntityInternalId BaseManagedTypeId FullName Path Name DisplayName TopLevelHostEntityId IsManaged IsDeleted LastModified OverrideTimestamp
2AF913AE-04B6-18D3-1355-A9EC8829AFE8 100 66DD9B43-3DC1-3831-95D4-1B03B0A6EA13 Microsoft.Windows.OperatingSystem:AGENT01.Odyssey.com AGENT01.Odyssey.com NULL Microsoft Windows Server 2008 R2 Enterprise 0BC0EDDE-6E07-00C9-EE22-21DE3C9F8B54 1 0 2013-02-09 20:26:37.067 2013-02-09 20:21:33.023
The same select from the database reveals that this GUID is related to the Agent01 system on the Operations Manager 2012 environment:
BaseManagedEntityId BaseManagedEntityInternalId BaseManagedTypeId FullName Path Name DisplayName TopLevelHostEntityId IsDeleted LastModified OverrideTimestamp TimeAdded LastModifiedBy
2AF913AE-04B6-18D3-1355-A9EC8829AFE8 223 66DD9B43-3DC1-3831-95D4-1B03B0A6EA13 Microsoft.Windows.OperatingSystem:AGENT01.Odyssey.com AGENT01.Odyssey.com NULL Microsoft Windows Server 2008 R2 Enterprise 0BC0EDDE-6E07-00C9-EE22-21DE3C9F8B54 0 2013-02-10 18:35:09.443 2013-02-09 21:48:03.950 2013-02-09 21:48:03.9515669 NULL
This indicates that the GUID referenced in the XML is retained and is valid in both the OpsMgr 2007 R2 environment and in the Opsmgr 2012 environment.
After the Windows Operating System was monitored I moved the override management pack from the OpsMgr 2007 R2 environment to the 2012 environment: (by copying over the exported management pack and importing it through the Administration pane in the OpsMgr 2012 environment).
The overrides pane seems to indicate that the override did make it over (cpu overrides on 2012 below):
CPU overrides for OpsMgr 2007 R2 are below for comparison:
The override management pack works without alteration in the OpsMgr 2012 environment as shown below:
And the OpsMgr 2007 R2 environment continues to function as well:
Answer: Multi-homed migration works for an overrides created which are specific to a server when the management packs are moved into the new management group in a multi-homed migration.
Question: What about groups? If we create a group with an explicit member does it move to the new management group correctly and do overrides applied to that group move correctly?
Next I created a new group with a new management pack called “overrides management pack2” and statically defined the Agent01 system to the group.
The group name was Test Group1 and the membership in the OpsMgr 2007 R2 environment is shown below:
Next I moved the management pack to the OpsMgr 2012 management group and validated that the group and membership transferred correctly:
To test this I created an override to the Test Group1 shown above and changed the “Available Megabytes of Memory” monitor in the OpsMgr 2007 R2 environment, exported the overrides management pack and moved it to the OpsMgr 2012 environment. OpsMgr 2007 R2 for this configuration is shown below:
OpsMgr 2012 for the same configuration is shown below:
Answer: Overrides applied to groups and moved from one management group to another in a multi-homed migration function as expected.
Question: What about functionality created by management pack templates, will those migrate correctly between the management groups?
Answer: In a client environment we also tested porting management packs which included templates such as the tcp port and monitoring for services. This functionality transferred between the two environments and worked as expected.
There are additional questions related to migrations where overrides are targeted at non-Windows Computer objects (such as IIS sites, application pools and more) and whether those will also migrate correctly in a multihomed configuration but I did not get the time required to run those tests for the purposes of this blog post. If you get a chance to try this or what happens when you multihome a manually installed agent I would really appreciate any results that you have with those tests!
Summary:
- The multi-homed migration approach to migrating Operations Manager 2007 R2 to Operations Manager 2012 appears to allow any override configurations to move successfully from the original 2007 R2 management group to the new 2012 management group when the management packs from the OpsMgr 2007 R2 environment are added to the OpsMgr 2012 environment.
- This applies to function even for server specific overrides which I had seen fail at a previous client engagement.
- The ability to effectively move overrides from one management group to another in a multi-homed migration successfully means that the only existing requirement I can see which would require an upgrade is for client environments which require the data warehouse data to be maintained in the same data warehouse versus maintaining the original OpsMgr 2007 R2 environment.