But if you did not like all the rest of have done at least once, then here is how you can remove the dependencies. But first please backup you management packs.

1. Download and install Microsoft’s XML Notepad
2. Export the Default management pack to any folder you like. This will export it into an XML file. Back this file up before making changes to it.
3. Open the XML file in XML Notepad
4. Expand the management pack in the left window to \\managmentPack\Manifest\References 

1. Look in each sub-folder named Reference for the Management pack that you are trying to remove. Once you find it Delete the Reference folder.
2. Import the Default XML file back into the console.
3. Try to delete the management pack again.

Symptom 1: During the pre-requisite check you receive notification that ASP.net is not started but the service is running.

Symptom 2: During setup you receive the “srs server validation” error  

To fix this

• Of course confirm that ASP is installed. If it is then do the following.
• Open the command prompt go to

C:\windows\Microsoft.NET\Framework\v2.0.50727

• Run the following command

aspnet_regiis /i

After I implementing Microsoft’s System Center Operation’s Manager 2007 (SCOM) into our environment I wanted to test the disaster recovery process. Our design is using an RMS and one MS. The test was meant to be simple and I of course didn’t think to create another test environment for this. *what an idiot*

To prove that the steps provided by Microsoft worked I unplugged the RMS and prompted the MS server. Hey this worked like a charm. It was the next step that really got ugly, the next step of course was when I brought the RMS back on-line. Because that is the goal in the end right. To restore the original server. Somewhere I missed a step. And before you know it I was rebuilding the entire environment. I was fairly sure that I hadn’t really missed anything. But I screw up so often who really knows for sure? I then created that test environment that ignored the first time and tried it again. Hey what do you know I had the same results. Then for the third test I opened up a Microsoft support call and had them help me do it right, and again the same results. The Microsoft support tech confessed to me that in there training they only test the promotion . They didn’t actually try to go back to the original solid state.

After a couple of days he for-wards me an internal email from Microsoft that talks about the process and how to avoid this issue.

Read on to see the risk assessment and the detailed steps of how to demote and promote

Risk assessment of promotion

The Root management server (RMS) is the primary SCOM server that is responsible for sending alerts out to a pager. It is also the server that needs to be running in order to access the alerts window within SCOM.

If the RMS fails, the Management Server (MS) will continue to accept the alerts from the agents (client servers that are being monitored). However, the MS will only collect alerts. It will not provide access to the Console to view alerts, nor will it send alerts to pager or email. The result of this is that all alerting will stop until there is a RMS in the environment again.

Options

In our environment, we have three options to handle the RMS to MS fail-over.

1. Don’t promote the MS server. Fix the RMS and bring it back on-line.

During the outage of the RMS server there will be no indication of other service failures in the environment. We would be relying on the business to notify us through the Service Desk.

1. Promote the MS to RMS

Benefit: This will provide Alerting and console access.

I have documented and tested the promotion and demotion of RMS servers in our environment. If the steps are followed exact then there should not be an issue.

However, if the procedure is not followed exactly it would mean a complete loss of the SCOM environment. The database may need to be rebuilt and the agents would need to be redeployed to all servers. The SCOM servers would need to be rebuilt from scratch.

The following note is from an internal Microsoft memo that was provided to us during Microsoft support call. This is not included in the official MS documentation. There is the risk that an analyst that responds to this type of incident might consult the official documentation and not complete the fail-over properly.

NOTE: You do NOT want the previous RMS to still be an RMS when it comes back up or becomes reachable again (network back up), as both RMS’s will compete for the DB’s attention, which is not a healthy state. If you do get in this state (old RMS not demoted, back in contact with DB), the correct fix is to demote that old/previous RMS first, as indicated above.

Do not try to demote the new RMS, as you will end up with no RMS indicated in the DB, and would likely have no way to recover the Management Group. If you want to set the previous RMS back to the current RMS, demote it first, then re-promote it, which will then automatically demote the existing RMS.

The promotion should be used only as the last resort and only in the case where there is no other way to restore the original RMS.

1. Upgrade the SCOM environment to a Cluster. (The best option but the most costly)

Clustered SCOM environment would ascertain stability of the SCOM environment and eliminate its single point of failure. It would also eliminate the need for the shaky promoting procedure described in item 2.

How to demote the Root Management Server so that you can promote it again later.

The following 3 steps need to happen to promote the Management server.

1. Backup the key on the current RMS to a file share using SecureStorageBackup tool

2. import the key to the MS to be promoted to RMS from the file share

3. Run the management server config tool on the new RMS to promote it

1. Backup the key on the current RMS to a file share

To run the SecureStorageBackup.exe Tool

On the current Root Management Server

a. Copy

SecureStorageBackup.exe and ManagementServerConfigTool.exe from

\ Ops_SP1Rc1\SupportTools.

To

C:\Program Files\System Center Operations Manager 2007

b. Open a command line and navigate to

C:\Program Files\System Center Operations Manager 2007

c. Run the following command:

SecureStorageBackup Backup “Network Path\SCOM_Key_backup\SCOMKEY.bin”

This key must be available to the machine you want to promote.

d. Provide a password

to secure the key and retype the password. The password must be eight characters long. Once the key is exported, you will see a success message.

2. Import Key to the current MS

On the Management Server you want to promote to become the Root Management Server

a. Copy SecureStorageBackup.exe and ManagementServerConfigTool.exe from

Ops_SP1Rc1\SupportTools.

To

C:\Program Files\System Center Operations Manager 2007

b. Open a command line and navigate to

C:\Program Files\System Center Operations Manager 2007

c. Run the following command:

SecureStorageBackup Restore “Network Parch\SCOM_Key_backup\SCOMKEY.bin”

d. Provide password used to access the key and retype the password again. Once the key is exported, you see a success message.

3. On the Management Server you want to promote to become the Root Management Server

a. Copy SecureStorageBackup.exe and ManagementServerConfigTool.exe from

\Ops_SP1Rc1\SupportTools.

To

C:\Program Files\System Center Operations Manager 2007

b. Open a command line and navigate to

C:\Program Files\System Center Operations Manager 2007

c. Run the following command:

ManagementServerConfigTool.exe PromoteRMS

If the Current RMS is currently on-line and reachable you are done. This will automatically update and demote the RMS to a MS. If not it is critical to complete ALL the following steps.

d. Go to the promoted Root Management Server, open the services and stop the Ops HealthService.

a. Go to the installation directory (default: %ProgramFiles%\System Center Operations Manager 2007) and delete the Health Service State folder.

e. Start the MOM Health Service.

f. When you open the Operations Console the first time, specify the name of the new Root Management Server to connect to.

4. Demote the Original RMS server when it is back on-line. This needs to be done before it can be promoted back to RMS.

a. Copy SecureStorageBackup.exe and ManagementServerConfigTool.exe from

\ Ops_SP1Rc1\SupportTools.

To

C:\Program Files\System Center Operations Manager 2007

b. Open a command line and navigate to

C:\Program Files\System Center Operations Manager 2007

c. Run the following command:

ManagementServerConfigTool.exe UpdateDemotedRMS

After the Original RMS is back online you will need to promote it again

5. On the Management Server you want to promote to become the Root Management Server

a. Copy SecureStorageBackup.exe and ManagementServerConfigTool.exe from

\ Ops_SP1Rc1\SupportTools.

To

C:\Program Files\System Center Operations Manager 2007

b. Open a command line and navigate to

C:\Program Files\System Center Operations Manager 2007

c. Run the following command:

ManagementServerConfigTool.exe PromoteRMS

Final Steps

Go to the promoted Root Management Server, open the services and stop the Ops HealthService.

1. Go to the installation directory (default: %ProgramFiles%\System Center Operations Manager 2007) and delete the Health Service State folder.
2. Start the MOM Health Service.
3. When you open the Operations Console the first time, specify the name of the new Root  Management Server to connect to.

If the Current RMS is currently on-line and reachable you are done. This will automatically update and demote the RMS to a MS.

Resolution is to fix WMI. And here is exactly how I did it.

Well almost exactly. You will need to send me an email for the files required to do this.

On effected server

1. copy mom_tracing.mof to any location on the server. I used c:\downloads

 2. open the command prompt and navigate to c:\downloads and
run the following command without the quotes.

 ”mofcomp mom_tracing.mof”

 This will most likely lead to an error looking for the EventTrace class in WMI which the mom_tracing.mof is dependent upon. (This can be verified by running wbemtest connecting to Root\WMI and doing a recursive Enum of the classes and looking for EventTrace as a class, if necessary).

To fix the error proceed to step 3

3. Copy the contents of the mof folder (email me for this folder) to c:\%SystemDirectory%\system32\wbem
4. Open command prompt and navigate to c:\%SystemDirectory%\system32\wbem
Run the following command without the quotes.

“For /f %s in (‘dir /b *.mof *.mfl’) do mofcomp %s”

Restart WMI services.

Install SCOM agent from file://scomserver/agent/i386

And that’s it. The entire process should take less then a few minutes.

Brad Hearn

Enterprise Server Analyst

http://bradstechblog.com/

The OpsMgr Connector could not connect to MSOMHSvc\rms01.local

haha, I have.

Using a domain account is not supported and will not allow you to start the service. But it will register a second servicePrincipalName to the domain account. If this happens the agents will no longer be able to communicate with the server. Or at least until the duplicate servicePrincipalName is removed.

I found this out during the test phase when I changed the service login account during trouble shooting the health service. (The original problem with the health service was that it would keep failing and stopping. The resolution was never found, and that was with an open Microsoft call. We reinstalled the server and that resolved it. However the servicePrincipalName was still messed up in active directory.)

The following is what I have documented and used to fix this.

Here is a clipping from another post (http://www2.wolzak.com/index.php?option=com_frontpage&Itemid=1) on this that I found.

To generate a list of accounts that the SPNs are registered to, run the following command at the command prompt.

1. From the domain controller, open a command prompt and then type the following string: ldifde -f domain.txt
2. Open the text file in Notepad and then search for the SPN that is reported in the event log. ServiceClass/host.domain.com (in this case look for MSOMHSvc/rms01.local)
3. Note the user accounts under which the SPN is located and the organizational unit the accounts reside in….the userPrincipalName should be located directly above the servicePrincipalName registration as in the example below.
userPrincipalName: useraccount@domain.com
servicePrincipalName: ServiceClass/host.domain.com

Use one of the following options to delete the account SPN registrations from the accounts that should not contain registrations to ServiceClass/host.domain.com. (i.e. Typically any accounts containing an SPN registration for SeriviceClass/host.domain.com that services are not explicitly starting with). Make sure you know which credentials you want to keep (in this case the system account or the domain administrator) and see to it that the service is running with the credentials you want to use. Delete the other one.

Using ADSIEdit

1. Add ADSIEdit to the MMC and bind to the domain using the Domain well known naming context.
2. Navigate to each user account you previously documented as having a duplicate SPN registration and right click the account and select properties.
3. Scroll through the list of attributes until you see servicePrincipalName, double click servicePrincipalName and remove the duplicate SPN registration and click on OK and exit ADSIEdit.

Using SetSPN

1. From the command prompt type the following command and hit enter.setspn -D ServiceClass/host.domain.com:Port AccountName

Make sure to test before performing this operation in a production environment.

Brad Hearn

Enterprise Server Analyst

http://bradstechblog.com/