Move a snap-shot of OpsManager to another domain

This blog post describes how a snap shot of  an existing virtual Operations Manager 2007 R2 installation can be brought online in another domain.

Why that?

With the upcoming version System Center Operations Manager 2012 you will need to test and document your upgrade path and it would be useful and recommended to do that in a separated environment. Reinstalling the whole thing would also be possible, but then you perhaps do not have the same settings or hotfixes installed. So our approach is to take a snap shot of our existing virtual OpsManager 2007 R2 servers and copy them to another domain, get the system up and running and then test the upgrade within this environment.

Environment Description

The virtual OpsManager 2007 R2 environment we would like to move has the following servers:

Root Management Server (RMS)
Management Server (MS)
SQL Server
Reporting Server (RS)

All servers are separated virtual machines with Windows 2008 64-bit. The SQL installation is still on SQL 2005.
We use AD integration, and have additionally to the standard Operations Manager accounts Run As accounts for special management packs like SQL, VMware, AD, etc.

The new environment will be a separated virtual environment with the same AD domain structure as in the old environment. You should have domain admin permissions or someone who has that to process all necessary steps in the new environment.

Process overview

  1. Create a local administrator account and remember the password
  2. Create a backup of the reporting service encryption key and store it on the reporting server. (
  3. Take a snap shot of the 4 servers and copy them over to the new environment. Start up the machines in the new environment
  4. Add the servers to a workgroup, reboot, add the servers back to the new AD domain.
  5. Create all necessary accounts and groups in AD
  6. Give accounts permissions and perform config changes

The last step is the most complicated one as you perhaps recognized yet. I will not talk through everything in detail, but I will focus on the last step and only add links to other blogs where information is already posted.


Step 5:

In our environment we have four Operations Manager action accounts (as it is recommended) and separated domain accounts for other functions like AD integration, Run As account for SQL, VMWare, AD MPs. So the accounts and groups we need in the new environment are as follows:

Server Action Account (short: SAA)
SDK and Config Account (short: SDK)
Data Reader Account (short: DRA)
Write Action Account (short: WAA)
AD Integration Account
SQL MP Run As Account (this account will also be used for running the SQL services!)
VMWare MP Account
AD MP Account

You perhaps have to create additional accounts, if you have other MPs you are using where Run As accounts are defined and which you would like to test in the new environment.

Additionally to the accounts you need the Operations Manager administrators group. Add the SDK and SAA user to this group. Don’t forget to add a user ID to that group which you use to logon to that new domain, so that you can later administer Operations Manager with that ID.

Step 6:

Kevin has a great blog post which describes what (Windows and SQL) permissions the OpsManager accounts need:
So give the accounts the necessary Windows permissions. I would also recommend to delete all old IDs from the old domain out of the windows groups and within secpol.msc. Also assign additional permissions through secpol.msc on the RMS to the DRA account:

Before we can start configuring the OpsManager side, we need to get the SQL databases running again.


Our SQL environment is running with a SQL service account which has no Windows administration permissions, it is a normal domain user. The services on the migrated machines still have the old account listed which does not exist in the new domain anymore. So we need to change this account and also give the new OpsManager accounts permissions to the databases.

This blog describes how you can define a new service account for the SQL services: It is written for SQL 2008 but also applies to SQL 2005.
In our environment the SQL service account also needs full control permissions to the %SQL installation%\MSSQL\Data folder. And do not forget to grant the account ‘Allow Logon Locally’ permissions through secpol.msc.
Start all SQL services and open up the SQL Server Management Studio with the SQL service account user to grant all necessary permissions for the OpsManager accounts to the OpsManager Databases (see again Kevins blog post): OperationsManager, OperationsManagerDW, ReportServer, ReportServerTempDB.

Now we have the prerequisits set to start with the changes within Operations Manager.

Operations Manager:

Check SPNs and set SPNs for the new SDK service account:

The Operations Manager administrator group has also been recreated so you need to assign that group back to Operations Manager. This blog describes how to do that:

Open up the Operations Manager console with your user ID and go to Administration: Run As Configuration: Accounts. Change the service accounts.

Logon to the RMS and enter the new SDK user for the System Center Data Access and the System Center Management Configuration services. Restart all System Center services on RMS and MS.

Go back to the Operations Manager console and delete out all old agents which are not existing in the new environment.

Check the Operations Manager event log on the RMS. One thing we recognized: We had a lot of data warehouse errors, which indicated that the service account had not enough permissions. But we set the correct permissions as Kevin wrote. So what was the problem?
It took a while, but finally we found it. There is a table entry in the OpsManager database which defines the Write action account. So this needs also be changed.
Logon to the SQL server, open up SQL Server Management Studio. Connect to the OperationsManager DW instance and run the following query:
SELECT WriterLoginName from dbo.ManagementGroup
UPDATE dbo.ManagementGroup
set WriterLoginName=’domain\waa user’
Restart the System Center Service on the RMS.

Now the main system should run without major problems.

What is still missing is AD integration and Reporting.

AD Integration:

For AD integration run momadadmin.exe for each domain where computer should be integrated: Then change the agent assignment rules as needed in the new environment.


That part is always a bit tricky. The SQL Server reporting services are running with the DRA service account in our environment. But that account has changed now. So the SQL Server reporting services service had problems to start. We changed the account in the service and also in the application pools in IIS (Advanced Settings:Identity).
But that still won’t let the service start. The error “RPC Server is not listening” really does not tell anything. But without a running instance the Reporting Service Configuration Tool cannot configure the service.
What was the solution? The rsreportserver.config file also has entries about the service user. So create a save copy of the file (stored here %Program Files%\Microsoft SQL Server\MSSQL.X\Reporting Services\ReportServer\). Delete out all user information and start the SQL Server Reporting services service.
Now you can run the Reporting Service Configuration Tool (with a user that has admin permissions in SQL and on the SQL/Reporting server) and specify the service account where needed. Also restore the old encryption key if needed. You will need to create a new backup of the encryption key when you enter the new user.
Go through all steps and check that they are successfull. Then you can try to open up http://localhost/reports.
Does it open up ? Ok, then you are finished!

So what is missing now?
Only the Run As accounts for the other management packs (SQL, VMWare, etc.). Check the permissions for those users (see MP documentation) and set them accordingly.

The error events should be gone now in the Operations Manager event logs and the system is prepared for the update to System Center Operations Manager 2012! 

This posting is provided “AS IS” with no warranties, and confers no rights.

Post a comment or leave a trackback: Trackback URL.


  • D  On August 23, 2012 at 10:00 am

    Our setup is a ops manager 2007 RMS server and another server hosting the database , it has had years of work getting packs customized.

    The domain is shared and the plan is to spilt it into 2 domains. To start from scratch would take years again of setting up packs. So I have been trying to get a clone of the 2 servers working in the new domain.

    What i have done so far is

    Cloned 1 DC in the new domain and cloned the 2 ops manager servers.

    On a segregated vSwitch cleaned up the domain controller and added the opsmanagers 2 servers to work group then joined the new domain.

    Then went through all the SQL permissions, ops manager permissions, registry , .xml files , created the ops manager groups and now when I run the ops manager console it starts up with no errors.

    Event viewer looks very clean – My isssue and it could be a non-runner is that I cant change or add the management server , it still gives the old server.domainname in the drop down in discovery and creating run as accounts.

    Is ther any hack that can be done to get the RMS display name and ops manager to accept its new domain version ?

    Any pointers woul be great

    • opsmgrtipps  On August 23, 2012 at 11:50 am

      There is no documented / supported way to move OpsManager to another domain or rename a management server. So I am sorry, but I do not have a solution for you. In your case I would recommend to really install a new management group in your new domain. If you have stored your overrides in separated management packs, then it should be no problem to move the customizations to the new management group also.

  • D  On August 27, 2012 at 10:30 am

    Hi , thanks for your reply , I dont suppose you can point me in the direction any documentation that I would need for getting the management packs over to the new domain. There will be full trust in place but this trust will be removed by the end of the project

    So The plan now is to build a fresh install of ops mgr in the new domain and somehow try and get the management packs exported and working in the now domain

  • D  On August 28, 2012 at 7:41 am

    Thanks very much for the link !

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s