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
- Create a local administrator account and remember the password
- Create a backup of the reporting service encryption key and store it on the reporting server. (http://msdn.microsoft.com/en-us/library/ms400729(v=vs.80).aspx)
- Take a snap shot of the 4 servers and copy them over to the new environment. Start up the machines in the new environment
- Add the servers to a workgroup, reboot, add the servers back to the new AD domain.
- Create all necessary accounts and groups in AD
- 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.
Details
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: http://blogs.technet.com/b/kevinholman/archive/2008/04/15/opsmgr-security-account-rights-mapping-what-accounts-need-what-privileges.aspx.
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: http://thoughtsonopsmgr.blogspot.com/2011/08/eventid-26338-on-rms-system-center-data.html.
Before we can start configuring the OpsManager side, we need to get the SQL databases running again.
SQL:
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: http://technet.microsoft.com/en-us/library/ms345578.aspx. 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: http://blogs.technet.com/b/jonathanalmquist/archive/2008/08/14/operations-manager-2007-spn-s.aspx.
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: http://blogs.technet.com/b/operationsmgr/archive/2011/11/28/how-to-change-the-operations-manager-2007-admin-group-if-the-original-was-deleted-from-active-directory.aspx.
Open up the Operations Manager console with your user ID and go to Administration: Run As Configuration: Accounts. Change the service accounts. http://technet.microsoft.com/en-us/library/bb735419.aspx.
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.ManagementGroupUPDATE 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: http://www.infrontconsulting.com/AD_OpsMgr2007.pdf. Then change the agent assignment rules as needed in the new environment.
Reporting:
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.
SystemCenterTipps 