Menu Close

Recovering a SCOM management server


It should be a rare occurrence to completely lose a SCOM Management server.  Normally you would restore from a backup, or recover a VM snapshot in order to quickly recover a lost/damaged/corrupted SCOM MS.

However, in the case this does happen, you have options.

The biggest challenge in recovering a SCOM Management Server, is dealing with the RunAs account passwords.  There is a registry entry used to decrypt these, and this is generated when the first management server is installed.  This is normally copied to new management servers as they are added after the first MS in a management group.

What the /Recover command line switch does – is tell Setup this is a DR provisioning, and to behave a little differently.  It will look to see if ANY other Management Servers in the management group are still online.  If they are, Setup will contact them, and copy the registry entries needed to deal with RunAs account decryption.  However, if ALL management servers have been lost, then it will re-generate a new decryption key, but this results in you having to re-enter your existing RunAs account passwords in SCOM once the recovery action is complete.


Another challenge, is at the time of this writing, there is no documentation on the SCOM command line parameters for SCOM 2016, and the SCOM 2012 command line reference example is missing some data.

Here is a working command line for a recovery:

Setup.exe /silent /AcceptEndUserLicenseAgreement /recover /InstallPath:"D:\Program Files\Microsoft System Center 2016\Operations Manager" /ManagementGroupName:MGNAME / /DatabaseName:OperationsManager / /DWDatabaseName:OperationsManagerDW /ActionAccountUser:DOMAIN\omaa /ActionAccountPassword:password /DASAccountUser:DOMAIN\omdas /DASAccountPassword:password /DatareaderUser:DOMAIN\omdr /DatareaderPassword:password /DataWriterUser:DOMAIN\omdw /DataWriterPassword:password /EnableErrorReporting:Never /SendCEIPReports:0 /UseMicrosoftUpdate:0


The key areas to focus on with your custom data are:

  • InstallPath
  • ManagementGroupName
  • SqlServerInstance
  • DWSqlServerInstance
  • ActionAccountUser
  • ActionAccountPassword
  • DASAccountUser
  • DASAccountPassword
  • DatareaderUser
  • DatareaderPassword
  • DataWriterUser
  • DataWriterPassword


As with new SCOM deployments – you will need to have elevated rights to install SCOM components:

  • SCOM Administrator rights
  • Local Administrator rights on the Management server OS
  • Local Administrator rights on all other Management Servers (required for remote registry connection)
  • System Administrator rights in SQL hosting the databases


  1. Alex IRIZARRY

    I am not running it correctly. Preparing to have a standby server in the secondary datacenter but wanted to see how long it would take to run the /recover command on the standby server.

    • Kevin Holman

      I am not a fan of standby Management servers in a remote datacenter…. unless this is a DR scenario where the management server is not installed or part of the management group yet, and is just a VM ready to be installed in the case of DR. I am a fan of replicating the Management Server VM’s in a primary datacenter to a DR datacenter, which allows the fastest possible outage recovery with the least configuration.

  2. Sem Craeghs

    After running this on the first management server , i receive on every management server: “OpsMgr has no configuration for management group [managementgroupname] and is requesting new configuration from the Configuration Service.” and no client is reporting anymore…

Leave a Reply

Your email address will not be published. Required fields are marked *