Failover steps for a disaster recovery event

  1. Stop services at the primary site. If possible, stop the services on all servers at the primary site.
  2. Failover all third-party services, such as:
    • Microsoft Active Directory
    • Microsoft Exchange
    • Skype for Business
    • Microsoft SharePoint
  3. Failover the databases:
    • BlackBerry UEM database
    • BEMS-Core1 database (BEMS-Mail cluster (Push Notifications) database)
    • BEMS-Core2 database (BEMS-Presence cluster database)
    • BEMS-Core3 and Connect databases (BEMS-Connect cluster databases)
    • BEMS-Core4 and Docs databases (BEMS-Docs cluster databases)
  4. At the disaster recovery site, reconfigure the database access for the services to connect to the appropriate databases.
    • If the databases are using Always On Availability Groups for their disaster recovery configuration, then no action is required.
    • For configurations that do not use Always On Availability Groups, reconfigure the UEM Core database access by using the UEM Configuration Tool on each server to update the db.properties file.
  5. Start services at the disaster recovery site.
    Start the UEM Core, BlackBerry Connectivity Node, and BlackBerry Proxy services first, then the BEMS services. You may need to enable the startup mode if it is disabled.
  6. Reconfigure the BEMS databases in the BEMS dashboard. Restart the BEMS services.
  7. Verify that the BlackBerry Presence and BlackBerry Connect services are stopped before you change the settings.
  8. For the BlackBerry Presence and BlackBerry Connect clusters, reconfigure the Skype for Business front-end pool configuration. Restart the applicable services.
  9. For the BlackBerry Connect cluster, BEMS-Connect Service Configuration, reconfigure the BlackBerry Proxy startup server to point to the BlackBerry Proxy server at the disaster recovery site. Restart the applicable services.
  10. Reconfigure the network FQDN endpoints.
    Reconfigure the first FQDN (for example, cluster1.external.org.com) to point to an endpoint at the secondary site that has no BlackBerry Proxy servers attached. This is generally done through a Global Traffic Manager or equivalent and enables fast fail for attempted connections to the original primary site.
  11. Optionally, swap the primary and secondary servers.
    If the outage will be long-term, use the BlackBerry UEM console to swap the primary and secondary priorities for all App servers.
    Leave the BlackBerry Proxy configuration unchanged.
  12. To failback, follow steps 1 through 9, reversing the primary and disaster recovery sites.