UC Talks https://docs.microsoft.com/archive/blogs/uctalks/feed.xml Wed, 17 Apr 2019 03:47:09 GMT en-US hourly 1 Moving the CMS – Make it part of your upgrade action plan – Part 2 https://docs.microsoft.com/archive/blogs/uctalks/moving-the-cms-make-it-part-of-your-upgrade-action-plan-part-2 Mon, 09 May 2016 22:18:00 GMT https://blogs.technet.microsoft.com/uctalks/?p=255 Install CMS on a Paired Pool Pool Pairing was introduced in Lync 2013 to provide a Disaster Recovery (DR) solution which got around some of the limitations and complexities of using a stretched pool within Lync 2010. The DR uses the backup service to replicate data between the Pools which are paired. The CMS can also take advantage of this technology and even more so leverage a mirror within the DR site for HA in the remote Data Centre (DC). The process is pretty much the same as installing within the primary DC (see Part 1) with a few added checks. To install the CMS on the Paired Pool, complete the following. Check the backup service status between the Paired Pools, they should show as
  • Get-CsBackupServiceStatus -PoolFqdn {Pool FQDN} (CMS is hosted on this pool)
  • Get-CsBackupServiceStatus -PoolFqdn {Pool FQDN}
3 Note: For the Pool rea-sfb-se02… you would see OverallImportStatus in Error state because the XDS and LIS database are not yet available on that Pool. You may also see Event id 4082 on that Pools servers. You should check that the SQL Server you are loading the CMS onto is the Principal for all the databases and its associated SQL Server contains all the Mirrors. Assuming all is correct at this stage, do one final check that replication is good using the Get-CsManagementStoreReplicationStatus cmdlet, if responses are TRUE then you can install the CMS. 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. Install CMS on a Paired Pool Mirror Again similar to what we did on the first Pool we can also add SQL Mirroring within the DR site for HA within the DR site. This is the same process, but using the SQL Server Mirror within the DR site. Just as with the first site mirroring you need to set-up and specify a file share. 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. Once this is set-up you can run the following cmdlet. Install-CsMirrorDatabase -DatabaseType Centralmgmt -FileShare \\{server FQDN}\MirrorBackup -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 in the DR site 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. Once complete you can check the mirror state using the Get-CsDatabaseMirrorState -PoolFqdn {Pool FQDN in the DR site}. You will have to run Setup on all FE’s in the backup Pool within the DR site. Once complete you should also make sure the Master Replicator and File Transfer Agents Services are started on all Front-Ends within the DR site and if not start them. For final checks use the Get-CsBackupServiceStatus -PoolFqdn {Pool FQDN} on both the Primary and Backup Pools. You can also make a final check on replications after some time using the Get-CsManagementStoreReplicationStatus cmdlet. This should return TRUE for all Servers.  “Real World” On a recent customer visit I went through this with my customer and hit the following interesting issue. The scenario was that the customer was moving from Lync 2013 to SfB 2015. Part of the process was to also move the OS version to Windows 2012 to 2012 R2 and the SQL version from SQL Server 2012 to 2014, so we completed a side-by-side upgrade. The Lync 2013 Pool we were moving the CMs from and the SfB 2015 Pool which was the destination were both mirrored. The move of the CMS was completed successfully between Pools, but we hit a problem when trying to mirror the CMS once it had been moved to SfB 2015. 4 When we had run the Install-CsMirrorDatabase cmdlet for some reason the Witness which was used in the Lync 2013 deployment was showing. This was the reason it was failing because the Witness was SQL 2012 whereas the two new SQL Servers were SQL 2014. When we looked within topology builder the SQL Server Store had two references associated with it. The new database store and the old Witness from Lync 2013, even though when looking in the topology there was nothing referencing the old Witness Server within the new Pool environment. 5 The fix actually turned out to be quite easy, we simply had to click on the dropdown within the topology builder where the new Witness was choosing something else and then choose the Witness again, the re-publish. At this point the Server did want to try and mirror again, but failed due to mirroring being in place already for databases apart from the CMS. The actually text file advising what was to be completed next after publishing was mis-leading it asked us to run the Uninstall-CsMirrowDatabase for the database when actually what we needed to do was to run Install-CsMirrorDatabase for the CMS management database (as detailed above). Once we had run the above command again the correct Witness was picked up and the CMS was mirrored correctly. When we tried the same procedure on the DR site, simply publishing the topology was enough to mirror the CMS on the SQL Servers within the DR site. I am not sure why this was the case perhaps it was because the CMS was actually active on the primary site. However, looking within the topology show both Pools (Primary and Backup) within the CMS section with the primary being active. 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. 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. Part 1 deals with moving the CMS within a single Pool or non-DR Pool architecture.]]> Moving the CMS – Make it part of your upgrade action plan – Part 1 https://docs.microsoft.com/archive/blogs/uctalks/moving-the-cms-make-it-part-of-your-upgrade-action-plan-part-1 Mon, 09 May 2016 21:45:45 GMT https://blogs.technet.microsoft.com/uctalks/?p=226 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.]]>