Moving Central Management Store in Disaster Recovery scenario

 

If your CMS pool is unavailable and cannot be recovered in short time or at all, you’ll have to move Central Management Store to another pool to be able to make any changes in the topology. However, you’ll also have to move all other services hosted on failed pool (Conference Directory, Users, Dial-in Access Numbers, Response Groups, etc.)

Prerequisites for successful CMS move:

- Backup of CsConfiguration

- Backup of CsLisConfiguration

- Backup of RGS configuration

- Backup of user data (dbimpexp)

 

To move these services follow the steps below:

A. From a user account that is a member of the RTCUniversalServerAdmins group, log on to any Front-end server in a pool to which CMS is going to be moved and open Lync Server Management Shell

 

B. Run the following cmdlet to install the CMS database on a target (new) pool back-end server

Install-CSDatabase -CentralManagementDatabase -SqlServerFqdn be02.contoso.com -SqlInstanceName rtc

Note: use sql server and instance names relevant to your environment

C. Run the following Management Shell cmdlet to move Central Management Store

Move-CsManagementServer -ConfigurationFileName "C:\CsConfiguration.zip" -LisConfigurationFileName "C:\CsLisConfiguration.zip" –Force

Note: use filenames relevant to your environment

Note: Move-CsManagementServer also updates the SCP to point to the new Central Management Store location.

 

D. Run Enable-CsTopology

E. Move Conference Directory associated with failed pool to other frontend pool by running the following Management Shell cmdlets:

Get-CsConferenceDirectory | where {$_.ServiceID -match “UserServer: FQDN_of_failed_pool”> | Move-CsConferenceDirectory -TargetPool <targetPoolFQDN> -Force

F. Move users from pool01 to target pool using either Control Panel or following Management Shell cmdlet:

Get-CsUser | where {$_.registrarpool –match “FQDN_of_old_pool”} | Move-CsUser –target “FQDN_of_new_pool” –Force

Note: Force move user will just move user accounts but will not move data associated with users (such as conferences). You’ll need to have this information exported previously (using dbimpexp on a regular basis) to be able to restore also user associated data.

 

G. If Simple URLs were pointing to the “old” pool, make sure to change DNS entries to point to the new pool (make sure that Meet and Dialin FQDNs are present in SAN of pool’s certificate).

H. Move RGS configuration to the new pool. Follow instructions in the procedure Restoring Response Group Settings, but make sure to import settings to the new pool.

Note: you will need to have RGS Config information exported on a regular basis (at least after every change) so you can import RGS configuration to another pool.

I. If there are Dial-In Access numbers hosted by the old pool, those should be migrated to the new pool using the following syntax:

Move-CsApplicationEndpoint -Identity <SIP URI of the access number to be moved> -TargetApplicationPool <FQDN of the pool to which the access number is moving> -Force

J. Import exported resources (users, contacts, conference directories) to a new pool using Dbimpexp tool:

- Make sure User Replicator has finished full sync. An event is logged upon completion (30024). You can trigger full sync with Update-CsUserDatabase cmdlet

- Run Dbimpexp.exe from the support folder where Communications Server is installed, using the following syntax:

For Standard Edition Server:

dbimpexp.exe /import /hrxmlfile:"c:\SavedUserData.xml" /restype:all

For an Enterprise pool:

dbimpexp.exe /import /hrxmlfile:"c:\SavedUserData.xml" /sqlserver:<sql server host name> /restype:all

 

Optional: If failed CMS pool also held a CAC PDP role, move this role to a new CMS pool using Topology Builder

---