共用方式為

Moving the CMS – Make it part of your upgrade action plan – Part 1

  • 發行項

What is the CMS?

The Central Manager Store (CMS) is a repository which stores the master copy of the information relating to your topology. It is held on the Central Management Server which is generally the first server which you install within your topology. These blog post articles (Part 1 and Part 2) are not meant to explain what the CMS is, in fact if you are not sure what the CMS actually is then perhaps you should not be moving it at all. There is a very good article written by my colleague Jens Trier Rasmussen which explains it perfectly here. The post is written for Lync 2010, the first of our products where the CMS first appeared, but it is also valuable information relating to both Lync 2013 and Skype for Business 2015 (SfB 2015).

Scenario

The following information can be used whether you are doing a side-by-side upgrade from Lync 2010 to Lync 2013 or a side-by-side upgrade from Lync 2013 to SfB 2015, the tasks are very much the same. What this does not take into account is the new in-place upgrade option which we brought in with SfB 2015 which is in fact the recommended method to upgrade from Lync 2013 to SfB 2015. Of course you may not be completing an upgrade at all and may simply be decommissioning a Pool which holds the CMS, these tasks also apply to this scenario too.

The tasks cover the following scenarios, you may complete as few or as many of the tasks as you need depending on your topology and what you are looking to achieve:

  1. Move the CMS from one Pool to another (Part 1)
  2. Mirror the CMS on the new Pool for HA purposes (Part 1)
  3. Using Paired Pools to protect the CMS for DR purposes (Part 2)

I have also added some “real life” detail which I have experienced at a customer site recently when running through these tasks.

Planning to move the CMS

Moving the CMS is fairly straight forward assuming you have completed the appropriate planning and checks. On occasions there may be something unforeseen which happens which is why it is imperative that you plan the move, after all the CMS is the key component of the overall topology.

You should consider the following when moving the CMS:

  • Note which Pool you are moving it from
  • Note which Pool you are moving it to
  • Note the versions of SQL in both Pools
  • Always backup the CMS including the XDS and LIS databases both on the source and destination Pools especially if they are different versions
  • Always check CMS replication both before you move it the CMS and periodically throughout the process to make sure everything is up to date
  • Note if you are using mirroring or always-on
  • Note if you are using a Witness if you are
  • Note if you have a DR Pool (Paired-Pool) associated with the Pool you are moving it to (Part 2)

Steps to move the CMS

The following steps can be used alone or in combination to Move, Mirror for HA purposes and/or Install the CMS on a Paired-Pool/Mirror for DR purposes. You should be logged-in to one of the Front-Ends of the Pool you are moving to as a member of the RTCUniversalServerAdmins group or ideally as CSAdministrator.

Backup the CMS:

Before completing any kind of activity on the CMS which has the potential to be destructive it is advisable to back up the CMS which can be used should the need arise. The CMS contains two specific databases, XDS and LIS. XDS is the main database of the system and part of central management store which maintains the topology information, polices, configuration etc. and replicates a read only copy to every subsequent Lync or SfB server. LIS stands for Location Information Service and maintains the location information service data, however this is still considered part of the overall CMS.

To back up the XDS and LIS databases, you can use the following commands. It is recommended that you completed this prior and post move especially if you are moving the CMS to an updated version.

Export-CsConfiguration –filename c:\ {path}\cmsconfig.zip

Export-CsLISconfiguration –filename c:\ {path}\lis.zip

{path} is optional.

Move the CMS to a new Pool:

The CMS is created within SQL or SQL Express (if it is a Standard Edition) when the topology is first published, this is usually on the first Pool created within the topology or if multiple Pools exist it can be specified within the topology document. A pointer (Service Connection Point or SCP) is then provided within Active Directory in order to find which Server the CMS resides on, so it can be downloaded, changed and replicated from the master as necessary.

If the Pool which the CMS currently resides on is to be decommissioned or the solution is being upgraded the CMS has to be moved. Prior to moving the CMS, the database framework or skeleton has to be created on the Pool destined to own the CMS once it is moved.

Install-CsDatabase –CentralManagementDatabase –SQLServerFQDN {SQL Server FQDN} –DatabasePaths “E:\”, “D:\”

The SQL Server FQDN can be an SQL Server back-end or a Standard Edition Server. If a specific SQL Instance is required, this can be specified with the –SQLInstanceName switch. The –DatabasePaths switch is used to place the files, for example in the above command log files will be created on E:\ and databases on D:\ where possible and performance factors allow. Once the command has completed you should check on disk and within SQL Management Studio, the files and databases are shown.

You should now run the following command on the Front-End (FE) used for the move.

Enable-CsTopology and correct any errors

It is very important that any errors are corrected prior to moving the CMS otherwise the move is likely to fail and you are unlikely to be able to access the CMS. If all has completed without errors, then you need to check replication prior to moving the CMS. Use the following command.

Get-CsManagementStoreReplicationStatus 1

If all Servers are set to TRUE, then it means the read-only copy of the CMS on each Server is up to date. It is recommended in a mirrored configuration where you are moving the CMS to a Pool with an SQL mirrored back-end, you check within SQL Management Studio that the SQL Server you are moving to, holds all the principals of all the databases. Once these checks are successful, then you are ready to move the CMS.

To move the CMS type Move-CsManagementServer, this command

2

Read the information carefully and if you are comfortable to move the CMS type A. Once complete you may need to start / re-start both the Master Replica and File Transfer Agent services on the Front-End used for the move.

To add or remove the Master Replica and File Transfer Agent Service from each Front End in both the source and destination Pools you will need to Run setup on all the old Lync 2013 FE’s and the new SfB 2015 FE’s for example if it is an upgrade and you have moved the CMS from Lync 2013 to SfB 2015.

You should Re-boot all of the Front-Ends in turn whilst checking replication is TRUE using the Get-CsManagementStoreReplicationStatus cmdlett between re-boots on the destination Pool, this is required because of a group membership change to access Central Management Server database.

Once all Front-Ends have been rebooted and replication is true, you can use the following to check for success

  • Get-CsManagementConnection (should show destination Pool)
  • Get-CsService –CentralManagement (should show destination Pool)
  • Get-CsDatabaseMirrorState –PoolFQDN {Pool FQDN} (check the mirror state)

To make sure replication is continuing use the Get-CsManagementStoreReplicationStatus after some time and validate replication is completed and appears as TRUE.

Implement Mirroring or Re-mirror the CMS on the new Pool

It is important within any organisation that provision of high availability (HA) within a site where customers want it, is implemented. This is true of any of the Lync 2013/SfB 2015 databases, but especially the CMS considering its importance. My experience so far is with SQL Mirroring of the CMS, although SQL Always-On is supported for SfB 2015 the following refers to SQL Mirroring.

Just as it is true when mirroring databases using Topology Builder that you need to specify a file share, the same is true when using the cmdlet. You should set-up a file share to be used as a “one off shot” for backing up and restoring the databases. This can be set-up providing everyone with full access and ripped down once the mirroring of the CMS is complete.

You should also check within SQL Management Studio that the primary SQL Server is Principal for all of the databases, the CMS and LIS databases will also reside on this Server.

To install a mirrored copy of the CMS for HA purposes run the following. This cmdlet is run on the same Front-End that you used to move the CMS, the file share is the one you have set-up previously and the SQL Server FQDN is the primary (Principal SQL Server).

Install-CsMirrorDatabase –DatabaseType CentralMgmt -FileShare " \\{server FQDN}\DbBackup" -SqlServerFqdn “{SQL Server FQDN}”

Note: the –databasepaths switch is not used with the Install-CsMirrorDatabase comdlet, but you should make sure that both the Principal and Mirror SQL Servers have the exact drive structure. The databases and logs will be created on the same LUNs and within the same directories taken from the Principal.

High Level Steps (for completeness the information contains Part 1 and Part 2 steps)

  1. Backup CMS
    1. Export-CsConfiguration –filename c:\{path}\cmsconfig.zip
    2. Export-CsLISconfiguration –filename c:\{path}\lis.zip
  2. Create CMS database on the SQL Server you are moving to
    1. Install-CsDatabase –CentralManagementDatabase –SQLServerFQDN {SQL Server FQDN} –DatabasePaths “E:\”, “D:\”
    2. Check Db’s and log files are created in both SQL and the disk
    3. Enable-CsTopology and correct any errors
  3. Check replication and make sure all replicas are “True” and up to date
    1. Get-CsManagementStoreReplicationStatus
  4. Move CMS
    1. Check the SQL Server we are moving the CMS to is the principal for all current databases
    2. Move-CsManagementServer and check details are correct then type A
    3. You may need to start / re-start both the Master Replica and File Transfer Agent services on the Front-End used for the move
    4. Run setup on all the old Lync 2013 FE’s and the new SfB 2015 FE’s, (this should be run again if the Master Replica and File Transfer Agent services still appear on the Lync 2013 Servers or do not appear on the SfB 2015 Servers)
    5. Re-boot all SfB 2015 Front End’s one at a time in turn checking replication before each one is re-booted
  5. Check replication and the move
    1. Get-CsManagementStoreReplicationStatus
    2. Get-CsManagementConnection
    3. Get-CsService –CentralManagement
    4. Get-CsManagementStoreReplicationStatus after sometime and validate replication is completed and appears as True
  6. Install CMS on Mirror database of the SQL in the SfB Pool you are moving to (if required)
    1. Install-CsMirrorDatabase –DatabaseType CentralMgmt -FileShare "\\{Server FQDN}\{share}" -SqlServerFqdn {“SQL Server FQDN}"}
  7. Install CMS on Paired Pool of the Pool you are moving to (if required)
    1. Get-CsBackupServiceStatus -PoolFqdn {Pool FQDN} (you moved the CMS to this pool)
    2. Get-CsBackupServiceStatus -PoolFqdn {Pool FQDN}
    3. Check Principal and Mirror SQL servers
    4. Install-CsDatabase -CentralManagementDatabase -SQLServerFQDN {SQL FQDN} –DatabasePaths “E:\”, “D:\”
  8. Install CMS on Paired Pool Mirror in the remote paired site
    1. Install-CsMirrorDatabase -DatabaseType Centralmgmt -FileShare \\{server FQDN}\{mirrorshare} -SqlServerFqdn {Primary SQL Server FQDN}
    2. Get-CsDatabaseMirrorState -PoolFqdn {Pool FQDN}
    3. Run setup on all Front End’s in the backup Pool
    4. Start the Master Replicator and File Transfer Agents services if not started
    5. Get-CsBackupServiceStatus -PoolFqdn {Primary Pool FQDN}
    6. Get-CsBackupServiceStatus -PoolFqdn {Paired Pool FQDN}

I hope this actually has been useful for people, if you have any comments or believe the process can be more streamlined then please comment to let me know. Part 2 deals with the CMS within a DR Pool architecture.

Author: Dave Murphy

Contributors: Tushar Pathak

I would like to thank Tushar for his valuable input into this procedure and support of the process. Tushar is a Support Escalation Engineer (SEE) working out of India.