Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Use the following procedures if a single Front-End pool is failed and needs to be failed over, or the pool that experienced the disaster is back online and you need to restore your deployment to regular working status. Learn how to fail over and fail back the Microsoft Edge pool used for Skype for Business federation or XMPP federation, or change the Microsoft Edge pool associated with a Front-End pool.
- Fail over a Front End pool
- Fail back a pool
- Fail over the Edge pool used for Skype for Business Server federation
- Fail over the Edge pool used for XMPP federation in Skype for Business Server
- Fail back the Edge pool used for Skype for Business Server federation or XMPP federation
- Change the Edge pool associated with a Front End pool
Fail over a Front-End pool
Datacenter1 contains Pool1, and Pool1 has failed. You're failing over to Pool2 located in Datacenter2.
Most of the work for the pool failover involves failing over the Central Management store, if it's required. The Central Management store must be functional when the pool’s users are failed over.
If a Front-End pool fails, but the Edge pool at that site is still running, you must know whether the Edge pool uses the failed pool as a next hop pool. If it does, you must change the Edge pool to use a different Front-End pool before failing over the failed Front-End pool. How you change the next hop setting depends on whether the Edge will use a pool at the same site as the Edge pool, or a different site.
To set an Edge pool to use a next hop pool at the same site
Open Topology Builder, right-click the Edge pool that needs to be changed, and select Edit Properties.
Select Next Hop. From the Next hop pool: list, select the pool that will now serve as the next hop pool.
Select OK, and then publish the changes.
To set an Edge pool to use a next hop pool at a different site
Open a Skype for Business Server Management Shell window and type the following cmdlet:
Set-CsEdgeServer -Identity EdgeServer:<Edge Server pool FQDN> -Registrar Registrar:<NextHopPoolFQDN>
To fail over a pool in a disaster
Find the host pool for the Central Management Server by typing the following cmdlet on a Front-End server in Pool 2:
Invoke-CsManagementServerFailover -Whatif
The results of this cmdlet show which pool currently hosts the Central Management Server. In the rest of this procedure, this pool is known as CMS_Pool.
Use Topology Builder to find the version of Skype for Business Server running on the CMS_Pool. If it's running Skype for Business Server, use the following cmdlet to find the backup pool of Pool 1.
Get-CsPoolBackupRelationship -PoolFQDN <CMS_Pool FQDN>
Let Backup_Pool be the backup pool.
Check the status of the Central Management store with the following cmdlet:
Get-CsManagementStoreReplicationStatus -CentralManagementStoreStatus
This cmdlet should show that both ActiveMasterFQDN and ActiveFileTransferAgents are pointing to the FQDN of CMS_Pool. If they're empty, the Central Management Server isn't available and you must fail it over.
If the Central Management store isn't available or if the Central Management store was running on Pool1 (that is, the pool that has failed), you must fail over the Central Management Server before failing over the pool. If you need to fail over the Central Management Server that was hosted on a pool running Skype for Business Server, use the cmdlet in step 5 of this procedure. If you don't need to fail over the Central Management Server, skip to step 7 of this procedure.
To fail over the Central Management store on a pool running Skype for Business Server, do the following:
First, check, which Back-End Server in Backup_Pool runs the principal instance of the Central Management store by typing the following:
Get-CsDatabaseMirrorState -DatabaseType Centralmgmt -PoolFqdn <Backup_Pool Fqdn>
If the primary Back-End Server in Backup_Pool is the principal, type:
Invoke-CSManagementServerFailover -BackupSQLServerFqdn <Backup_Pool Primary BackEnd Server FQDN> -BackupSQLInstanceName <Backup_Pool Primary SQL Instance Name>
If the mirror Back-End Server in Backup_Pool is the principal, type:
Invoke-CSManagementServerFailover -MirrorSQLServerFqdn <Backup_Pool Mirror BackEnd Server FQDN> -MirrorSQLInstanceName <Backup_Pool Mirror SQL Instance Name>
Validate that the Central Management Server failover is complete. Type the following command:
Get-CsManagementStoreReplicationStatus -CentralManagementStoreStatus
Check that both ActiveMasterFQDN and ActiveFileTransferAgents are pointing to the FQDN of Backup_Pool.
Finally, check the replica status for all Front-End Servers by typing the following:
Get-CsManagementStoreReplicationStatus
Check that all replicas have a value of True.
Skip to step 7 in this procedure.
Install the Central Management store on the Back End Server of Backup_Pool.
First, run the following command:
Install-CsDatabase -CentralManagementDatabase -Clean -SqlServerFqdn <Backup_Pool Back End Server FQDN> -SqlInstanceName rtc
Run the next command on one of the Front End Servers of Backup_Pool to force the move of the Central Management store:
Move-CsManagementServer -ConfigurationFileName c:\CsConfigurationFile.zip -LisConfigurationFileName c:\CsLisConfigurationFile.zip -Force
Validate the move is complete:
Get-CsManagementStoreReplicationStatus -CentralManagementStoreStatus
Check that both ActiveMasterFQDN and ActiveFileTransferAgents are pointing to the FQDN of Backup_Pool.
Check the replica status for all Front End Servers by typing the following:
Get-CsManagementStoreReplicationStatus
Check that all replicas have a value of True.
Install the Central Management Server service on the rest of the Front End Servers in Backup_Pool. To do so, run the following command on all the Front End Servers, except the one you used when forcing the Central Management store move earlier in this procedure:
Bootstrapper /Setup
Fail over the users from Pool1 to Pool2 by running the following cmdlet in a Skype for Business Server Management Shell window:
Invoke-CsPoolFailover -PoolFQDN <Pool1 FQDN> -DisasterMode -Verbose
Because the steps taken in the previous parts of this procedure to check the Central Management store status aren't universal, there's still a chance this cmdlet fails because the Central Management store isn't yet fully failed over. In this case, you must fix the Central Management store based on the error messages that you see, and then run this cmdlet again.
If you see the following error message, then you need to change the Microsoft Edge pool at this site to use a different pool as its next hop before failing over the pool. For details, see the procedures at the beginning of this article.
Invoke-CsPoolFailOver : This Front-end pool "pool1.contoso.com" is specified in topology as the next hop for the Edge server. Failing over this pool may cause External access/Federation/Split-domain/XMPP features to stop working. Please use Topology Builder to change the Edge internal next hop setting to point to a different Front-end pool, before you proceed.
Fail back a pool
After the pool that experienced the disaster is back online (that is, Pool1 in this example), take the following steps to restore your deployment to regular working status.
The failback process takes several minutes to complete. For reference, it's expected to take up to 60 minutes for a pool of 20,000 users.
Fail back the users who were originally homed in Pool1 and are failed over to Pool2 by typing the following cmdlet:
Invoke-CsPoolFailback -PoolFQDN <Pool1 FQDN> -Verbose
No other steps are necessary. If you failed over the Central Management Server, you can leave it in Pool2.
Fail over the Edge pool used for Skype for Business Server federation
If the Edge pool where you have Skype for Business Server federation configured goes down, you must change federation to use a different Microsoft Edge pool for federation to work.
On a Front End server, open Topology Builder. Expand Edge pools, and then right-click the Edge server or Edge server pool that is currently configured for Federation. Select Edit properties.
In Edit Properties under General, clear Enable federation for this Edge pool (Port 5061). Select OK.
Expand Edge pools, and then right-click the Microsoft Edge server or Edge server pool that you now want to use for Federation. Select Edit properties.
In Edit Properties under General, select Enable federation for this Edge pool (Port 5061). Select OK.
Select Action, select Topology, select Publish. When prompted on Publish the topology, select Next. When the Publish is finished, select Finish.
On the Microsoft Edge server, open the Skype for Business Server Deployment wizard. Select Install or Update Skype for Business Server System, and then select Setup or Remove Skype for Business Server Components. Select Run Again.
Select Next. The summary screen shows actions as they're executed. Once the deployment is done, select View Log to view available log files. Select Finish to complete the deployment.
If the site containing the failed Edge pool contains Front End Servers that are still running, you must update the Web Conferencing Service and A/V Conferencing Service on these Front-End pools to use an Edge pool in a remote site that is still running.
Fail over the Edge pool used for XMPP federation in Skype for Business Server
In your organization, there's one Edge pool designated as the pool to use for XMPP federation. If this pool goes down, you must fail over XMPP federation to use a different Edge pool before XMPP federation can work again.
When you first install Edge pools and enable XMPP Federation, you can simplify the disaster recovery process by setting up external DNS SRV records for all of your Edge pools for XMPP federation, instead of just one. Each of these SRV records must have a different priority set. All XMPP federation traffic goes through the pool with the SRV record with the highest priority.
In the following procedure, EdgePool1 is the pool, which originally hosted XMPP federation, and EdgePool2 is the pool, which will now host XMPP federation.
To fail over the Edge pool used for XMPP federation
If you don’t already have another Edge pool deployed (besides the one that is currently down), deploy that pool.
On each Edge Server in the new Edge pool, which will now host XMPP federation (EdgePool2), run the following cmdlet:
Stop-CsWindowsService
Run the following cmdlet to repoint the XMPP federation route to EdgePool2:
Set-CsSite Site2 -XmppExternalFederationRoute EdgeServer2.contoso.com
In this example, Site2 is the site containing the Edge pool, which will now host the XMPP federation route, and EdgeServer2.contoso.com is the FQDN of an Microsoft Edge Server in that pool.
On the external DNS server, change the DNS A record for XMPP federation to point to EdgeServer2.contoso.com.
If you don't already have a DNS SRV record for XMPP federation, which resolves to the Microsoft Edge pool, which will now host XMPP federation, you must add it, as in the following example. This SRV record must have a port value of 5269.
_xmpp-server._tcp.contoso.com
Verify that the Edge pool, which will now host XMPP federation has port 5269 open externally.
Start the services on all Edge Servers in the Edge pool, which will now host XMPP federation:
Start-CsWindowsService
Fail back the Edge pool used for Skype for Business Server federation or XMPP federation
After a failed Edge pool that used to host federation has been brought back online, use this procedure to fail back the Skype for Business Server federation route and/or the XMPP federation route to again use this restored Edge pool.
On the Edge pool that is now available again, start the Edge Services.
If you want to fail back the Skype for Business Server federation route to use the restored Edge Server, do the following:
On a Front End server, open Topology Builder. Expand Edge pools, then right-click the Edge server or Edge server pool that is currently configured for Federation. Select Edit properties.
In Edit Properties under General, clear Enable federation for this Edge pool (Port 5061). Select OK.
Expand Edge pools, then right-click the original Edge server or Edge server pool that you again want to use for Federation. Select Edit properties.
In Edit Properties under General, select Enable federation for this Edge pool (Port 5061). Select OK.
Select Action, select Topology, select Publish. When prompted on Publish the topology, select Next. When the Publish is finished, select Finish.
On the Edge server, open the Skype for Business Server Deployment wizard. Select Install or Update Skype for Business Server System, then select Setup or Remove Skype for Business Server Components. Select Run Again.
Select Next. The summary screen shows actions as they're executed. Once the deployment is done, select View Log to view available log files. Select Finish to complete the deployment.
If you want to fail back the XMPP federation route to use the restored Microsoft Edge Server, do the following:
Run the following cmdlet to repoint the XMPP federation route to the Edge pool, which will now host XMPP federation (in this example, EdgeServer1):
Set-CsSite Site1 -XmppExternalFederationRoute EdgeServer1.contoso.com
In this example, Site1 is the site containing the Edge pool which will now host the XMPP federation route, and EdgeServer1.contoso.com is the FQDN of an Edge Server in that pool.
If you don't already have a DNS SRV record for XMPP federation, which resolves to the Edge pool, which will now host XMPP federation, you must add it, as in the following example. This SRV record must have a port value of 5269.
_xmpp-server._tcp.contoso.com
On the external DNS server, change the DNS A record for XMPP federation to point to EdgeServer2.contoso.com.
Verify that the Edge pool which will now host XMPP federation has port 5269 open externally.
If the Front End pools remained to run in the site containing the Edge pool that failed and is restored, you should update the Web Conferencing Service and A/V Conferencing Service on these Front End pools to again use the Edge pools at their local site.
If the Front End pool at the same site as the failed Edge pool also failed, you can now use Invoke–CsPoolFailback to fail back the Front End pool.
Change the Edge pool associated with a Front End pool
If an Edge pool goes down but the Front End pool at the same site is still running, you will need to set the Front End pool to use an Edge pool at a different site until the failed Edge pool is restored.
In Topology Builder, navigate to the name of the Front End pool you need to change.
Right-click the pool, and then select Edit Properties.
In the Associations section, under Associate Edge Pool (for media components), use the drop down box to select the Edge pool you want to associate this Front End pool with.
Select OK.