DR Failover for Skype for Business Standard Edition

The article takes you through step by step of carrying out both health check and invoking disaster recovery (DR) a standard edition environment. The diagram below shows the layout of the environment where the DR was carried out on:

Before proceeding to test DR you need to make sure the appropriate registrar information is available/configured in the environment otherwise you will get the following error during Pool Failover process:

Please check that the pool <Prod_S4B> is healthy as conditions such as high CPU, low available memory
 or any disabled services can delay (or in some cases result in unsuccessful) fail over operations.
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help (default is “Y”):
Get-CsRegistrarConfiguration -Identity ‘service:Registrar:<Prod_S4B>’
WARNING: Cannot find “RegistrarConfiguration” “Registrar:<Prod_S4B>” because it does not exist.
Get-CsRegistrarConfiguration -Identity ‘service:Registrar:<DR_S4B>’
Invoke-CsPoolFailOver : Microsoft.Rtc.Management.Hadr.ManagementCOMException: Version check failed. This cmdlet works
only on servers running Lync Server 2013 or later.
   at Microsoft.Rtc.Management.Hadr.InvokePoolFailOverCmdlet.Action()
At line:1 char:1
+ Invoke-CsPoolFailOver -PoolFqdn <DR_S4B>
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidResult: (:) [Invoke-CsPoolFailOver], ManagementCOMException
    + FullyQualifiedErrorId : Microsoft.Rtc.Management.Hadr.InvokePoolFailOverCmdlet
WARNING: Invoke-CsPoolFailOver encountered errors. Consult the log file for a detailed analysis, and ensure all errors
(2) and warnings (0) are addressed before continuing.
WARNING: Detailed results can be found at
“C:\Users\<admin>\AppData\Local\Temp\2\Invoke-CsPoolFailOver-6fd7e68f-01a8-412d-90b4-76326cbc4d66.html”.
Invoke-CsPoolFailOver : Microsoft.Rtc.Management.Hadr.ManagementCOMException: Version check failed. This cmdlet works
only on servers running Lync Server 2013 or later.
   at Microsoft.Rtc.Management.Hadr.InvokePoolFailOverCmdlet.Action()
At line:1 char:1
+ Invoke-CsPoolFailOver -PoolFqdn <DR_S4B>
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidResult: (:) [Invoke-CsPoolFailOver], ManagementCOMException
    + FullyQualifiedErrorId : Microsoft.Rtc.Management.Hadr.InvokePoolFailOverCmdlet

First run the following command in Skype Management Shell:

PS C:\Get-CsRegistrarConfigurtion

Output of the above command is:

If incase you do not have the additional service level registrar’s pointing to the Frontend’s please run the following command:

PS C:\New-CsRegistrarConfiguration -Identity service:Registrar:frontendname.domain.com -EnableDHCPServer $true -PoolState $true

Note: Please replace “frontendname.domain.com” with your own server FQDN. Run the command for each standard edition server.

Once the above is done, rerun the command:

PS C:\Get-CsRegistrarConfiguration

To ensure the service level information has been loaded correctly.

Now check to make sure there are no issues with the backup state of the environment. In order to do this run the following command:

PS C:\Get-CsBackupServiceStatus -PoolFqdn “primaryfe.testdomain.com.au”

Output of the above command is:

To expand to see the BackupModules you can run the command as:

PS C:\Get-CsBackupServiceStatus -PoolFqdn “primaryfe.testdomain.com.au”  | Select BackupModules | fl

Looking closer at Figure 3.1 you will note the line: CentralMgmt.CMSMaster: [FinalState,NotInitialized]}

Matching this to Figure 3, this actually references to:

The reason why the CentralMgmt.CMSMaster “OverallImportStatus” is “NotInitialized” as there can only be one CMS Master. In this instance the primaryfe.testdomain.com.au is the CMS Master.

The table below shows the meaning of the various status output:

When you run the same commands against the secondary frontend:

PS C:\Get-CsBackupServiceStatus -PoolFqdn “secondaryfe.testdomain.com.au”

Output should be as follows:

To expand to see the BackupModules you can run the command as:

Looking closer at Figure 4.1 you will note the line: CentralMgmt.CMSMaster: [NotInitialized,NormalState]}

Matching this to Figure 4, this actually references to:

The reason why the CentralMgmt.CMSMaster “OverallExportStatus” is “NotInitialized” as there can only be one CMS Master. In this instance the secondaryfe.testdomain.com.au is not the CMS Master.

Note: There is no reason to check the Pool Fabric State as this is not an Enterprise Pool containing multiple frontend’s.

To test “Central Management Store (CMS)” run the following command:

On the Primary server:

PS C:\Test-CsDatabase -CentralManagementDatabase

Output should look like:

Run the following command from the Secondary Server:

PS C:\Test-CsDatabase -CentralManagementDatabase

Output of the above command is as follows:

Please also test all database connectivity’s both to all locally running SQL Services and between frontend servers:

Testing local databases run the following command:

PS C:\Test-CsDatabase -LocalService

Testing database across servers:

From Primary Server run the following command to the opposing server:

PS C:\Test-CsDatabase -ConfiguredDatabases -SqlServerFqdn “secondaryfe.testdomain.com.au”

The reason to do this is to ensure that the primary server can connect to the secondary server’s SQL database prior to initiating failover or putting the environment into production. Run the same command from the Secondary Server to the Primary Server. The command you run from the Secondary server is as follows:

PS C:\Test-CsDatabase -ConfiguredDatabases -SqlServerFqdn  “primaryfe.testdomain.com.au” 

Check the proposed state of the CMS failover by running the following command:

PS C:\Invoke-CsManagementServerFailover -WhatIf

Note: If this is a true DR situation most of the above health checks will fail as the query cannot communicate with the CMS Master server.

Once the health checks are done, run the invoke command to failover the CMS to the secondary server:

PS C:\Invoke-CsManagementServerFailover -BackSQLServerFqdn “Secondary Frontend Server” -BackupSQLInstanceName RTC

Check that the failover has been successful by running:

PS C:\Get-CsManagementStoreReplicationStatus -CentralManagementStoreStatus

Note: If the “ActiveMasterFqdn” is not populated, do not worry allow it takes a few mins to update. While this is happening you can launch the Topology Builder and verify that it has failed over.

On the main deployment page select “Skype for Business Server” and on the right hand pane under “Central Management Server” you should see a green tick next to the secondary frontend, example below:

As per “Figure 1” you will see that in this deployment there is only a single edge pool which is the next hop for the primary frontend server. In this deployment the servers are separate into their respective sites, primary being Site 1 and secondary being Site 2.

As such you cannot use Topology builder to failover edge services to the secondary frontend as the edge pool is physically configured under Site 1. The services will have to be failed over using PowerShell as below:

PS C:\Set-CsEdgeServer -Identity “Edgepool Fqdn” -Registrar Registrar:Secondary Frontend Fqdn

Once the command completes, publish the topology by running the following command:

PS C:\Enable-CsTopology

Once this completes you can now failover the pool for users and services by running the following command on the secondary server:

PS C:\Invoke-CsPoolFailOver -PoolFqdn “Secondary frontend server”

You have now successfully failed over the environment to the Secondary Frontend.