Skype operation guide

Failover

Here we discuss failover strategies for each tier in the MindLink stack, in terms of complete failure of an entire pool in an active/passive DR configuration.

Skype for Business

Scenario: The next-hop Skype for Business frontend pool becomes unavailable.

- Administrative actions:

    - Reconfigure the MindLink Server to use another pool as the next-hop pool.
    - If using manual configuration of the named next-hop pool, this requires setting the name of the failover pool and restarting the MindLink service.
    - If using auto-provisioning:

        - Mobile/Anywhere/SharePoint  the SfB DNS auto-discovery records should be changed to point to the failover pool. The MindLink service does not require a restart.
        - API  The new next-hop pool should be changed in the published SfB topology. The topology changes will be replicated to the MindLink server. The MindLink service does not require a restart.




- Anywhere/SharePoint/Mobile user experience:

    - The user will be notified that their session has ended and instructed to re-log on.
    - On re-logging on, a SfB session will be established on another node in the frontend pool.


- API behaviour:

    - The agent and channels will become inactive.
    - The agent will attempt to automatically reconnect and eventually become active and re-activate its channels.

Scenario: The users home Skype for Business frontend pool becomes unavailable.

- Administrative actions:

    - None. When homed users are moved to their failover pool the MindLink Server will be redirected to the new log on pool by the next-hop pool.


- Anywhere/SharePoint/Mobile user experience:

    - The user will be notified that their session has ended and instructed to re-log on.
    - On re-logging on, a SfB session will be established on another node in the frontend pool.


- API behaviour:

    - The agent and channels will become inactive.
    - The agent will attempt to automatically reconnect and eventually become active and re-activate its channels.

Scenario: The SfB Persistent Chat Pool becomes unavailable:

SfB persistent chat supports a stretched-pool configuration for DR. As such, recovery of services in at least one site should be the administrative priority.

If the persistent chat pool fails, users will be notified of session disconnection and unable to log on until services are restored.

Database Layer (Mobile)

Scenario: The database layer becomes unavailable.

- Administrative actions:

    - Configure the MindLink Server to connect to a new database via the Management Center.
    - Restart the MindLink Server.


- Failover process:

    - The MindLink Server periodically monitors the connectivity to and health of the database layer.
    - When a MindLink Server node identifies that it has not been able to connect to the database layer for a period of time, it will remove itself from the pool.
    - It will terminate all user sessions and refuse future log ons.


- User experience:

    - Logged on users will have their session removed and will be informed that they need to re-log on.
    - Once the database has been reconfigured and services restarted, users will be able to re-log on.