Move the Lync Central Management Store with a clear recovery boundary

The Central Management Store is part of Lync’s configuration infrastructure. My original June 2012 article outlined a move from an existing location to another Front End or SQL destination. A clearer procedure needs to distinguish a reachable source from an unavailable one.

Prepare before the move

Establish the source, destination, topology and SQL-instance details. In the management shell for the relevant deployment, create and verify configuration exports in an existing protected backup folder:

Export-CsConfiguration -FileName 'C:\LyncBackup\Configuration.zip'
Export-CsLisConfiguration -FileName 'C:\LyncBackup\LIS.zip'

Use a destination prepared for the actual topology. For a Standard Edition target, the original workflow included the local Prepare Standard Edition server setup step. Database creation must use the destination’s real FQDN, instance and approved file locations.

Treat the planned move as a controlled change

The historical sequence uses Install-CsDatabase -CentralManagementDatabase, topology enablement and Move-CsManagementServer. These are separate steps with prerequisites, not a script to paste without checking the deployment.

Microsoft’s cmdlet reference describes a live move initiated locally from the destination pool, after the target store and required services have been prepared. Follow the version-specific procedure and complete the local setup work reported by the command.

# Planned move: run only after destination preparation
# in the appropriate local management shell.
Move-CsManagementServer

Keep disaster recovery separate

When the original management server is inaccessible, the recovery procedure differs. The original post showed backup-file parameters with -Force. That is not the default continuation of a healthy live move.

The reference explains that force changes how the unavailable source is handled and carries a potential data-loss risk. Select the documented recovery procedure for the actual failure rather than adding force to bypass an unexplained error.

Verify the destination and replication

Review the move output and finish any required setup on the identified servers. Check configuration access and use the replication-status cmdlet as part of validation:

Get-CsManagementStoreReplicationStatus

Investigate replicas that are not up to date and retain the change records. A successful command result is one checkpoint; the operating objective is a usable management configuration and healthy distribution to the intended servers.

Read this as a historical operating guide

The original examples used lab FQDNs and default SQL paths. This revision replaces those environment-specific commands with the decision sequence and verified command names. The source post remains available for historical comparison.