In the event of a failure of an entire site, such as might be caused by a natural disaster, all servers in the internal network and perimeter network must be restored. This can be done using one of the following methods:

This section focuses on the second method. A secondary site is used as an interim solution until the primary site can be restored. For details about setting up and maintaining the secondary site, see Setting Up a Secondary Site. To use a secondary site to provide support, in the event of an outage of the primary site, use the procedures and guidelines in this section to complete the following steps:

  1. Bring the secondary site online.

  2. Restore the primary site and bring it back online.

The following procedures describe site restoration for an Enterprise pool. To restore a site for a Standard Edition server deployment, you can use the same procedure steps, modifying them as appropriate (such as using the IP address of the Standard Edition server, instead of the virtual IP address of the load balancer).

Note:
The backup and restoration of Active Directory Domain Services (AD DS) is beyond the scope of this document. These procedures assume that Active Directory Domain Services is set up with the appropriate configuration to support the secondary site in the same domain as the primary site and that Active Directory Domain Services remains available and functional, in the event of the loss of the primary site.

Bringing the Secondary Site Online

In the event of failure of service at the primary site, bring the secondary site online by performing the steps in the following procedure.

To bring the secondary site online

  1. Restore the backup of the RTC database of the primary site to the RTC database of the pool in the secondary site.

  2. Modify the _sipinternaltls and _sip_tcp DNS records to point to the pool FQDN of the secondary site. (If you use a load balancer, modify the DNS records of the pool in the secondary site to use the same virtual IP address that is configured on the load balancer in the original site.)

  3. Configure the Front End Servers in the new pool that you create for the secondary site, as specified in the deployment plan, and then verify the setup. This can include verifying specific configurations, such as the following:

    • Front End Servers within a pool behind a load balancer must be capable of routing to each other. This path of communication cannot include a NAT device. Any such device will prevent successful interpool communication over RPC.

    • Front End Servers behind a load balancer must have access to the Active Directory environment.

    • Front End Servers must have static IP addresses that can be used to configure them for use with the load balancer. In addition, these IP addresses must have DNS registrations (that is, Front End Server FQDNs).

    • Administration computers must be able to route through the load balancer to the pool FQDN, as well as the Front End Server FQDN of every Front End Server in the pool(s) to be managed. In addition, the path of communication to the Front End Servers to be managed cannot include a NAT device. (This restriction is enforced by the use of the RPC protocol by DCOM.)

  4. Use the Office Communications Server 2007 R2 snap-in to move all users to the new pool by using the Force Useroption.

  5. Test connectivity by logging on to Office Communicator from a client computer. Depending on the configuration and situation, you may need to modify configurations to do this. For instance, if the virtual IP address and pool FQDN change, it may be necessary to modify the client configuration unless auto-logon is enabled. It may also be necessary to use the ipconfig /flushdnscommand.

Restoring the Primary Site and Bringing It Back Online

This information describes how to bring the primary site back online after server loss at the primary site. If the failure of service at the original site was a temporary condition, such as a power outage, that did not damage the servers, you do not need to do anything except turn the servers back on. Before you start this procedure, use the appropriate procedures in Setting Up Server Platformsto set up the required servers.

When the primary site is ready to return to service, bring it back online.

Note:
The process covered in this section assumes that Active Directory Domain Services is intact.

For details about decommissioning servers and pools and rebuilding them, as well as restoring Active Directory data, see Decommissioning Standard Edition Servers and Enterprise Poolsin the Administering Office Communications Server 2007 R2 documentation.

To restore the primary site, after setting up server platforms

  1. Back up the RTC database from the secondary site, and then store it at a location that is accessible from the primary site.

  2. Log on to the Front End Server in the primary site, and then use the Office Communications Server 2007 R2 snap-in to deactivate each server role (as appropriate to your configuration) individually.

    Important:
    Use the log file to verify successful deactivation of each server role (and all deactivation tasks for that server role) before you deactivate the next server role.

    Deactivate the server roles in the following sequence:

    • Microsoft Office Communications Server 2007 R2, Audio/Video Conferencing service

    • Microsoft Office Communications Server 2007 R2, Web Conferencing service

    • Microsoft Office Communications Server 2007 R2, Web Components service

    • Microsoft Office Communications Server 2007 R2, Front End service

  3. Expand the pool, right-click Users, and then click Delete usersto remove SIP-enabled users from the pool (after verifying the availability of the database backup in the secondary site pool).

  4. Use the Remove Pool Wizard to remove the original pool and corresponding files of the primary site. Use the Forceoption, but do not use the Keep Existing Databasesoption.

    Important:
    Use the log file to verify successful removal of the pool and all removal tasks before proceeding to the next step.

  5. Do one of the following:

    • In Windows Server 2003, open Add or Remove Programs.

    • In Windows Server 2008 or Windows Vista, open Programs and Features.

  6. Remove each of the server roles (as appropriate to your configuration) in the following sequence.

    • Microsoft Office Communications Server 2007 R2, Administrative Tools

    • Microsoft Office Communications Server 2007 R2, Core Components

    • Microsoft Office Communications Server 2007 R2, Audio/Video Conferencing Server

    • Microsoft Office Communications Server 2007 R2, Standard Edition Server or Microsoft Office Communications Server 2007, Enterprise Edition Server

    • Microsoft Office Communications Server 2007 R2, Web Conferencing Server

    • Microsoft Office Communications Server 2007 R2, Web Components Server

  7. Delete share folders that have been created during pool and server creation for meeting content, meeting metadata, and the address book file store.

  8. Use the Office Communications Server 2007 R2 Deployment Wizard to set up all required server roles.

  9. Create a new pool that has the same pool name as the original primary site, by using the default Remove Existing Databasesoption.

  10. Restore the RTC database backup from the secondary site to the same instance of SQL Server that is used by the original pool of the primary site (specifying the appropriate instance name if the default was not used originally).

  11. When both pools (for the primary site and the secondary site) are online, use the Office Communications Server 2007 R2 snap-in to move all the users from the secondary site pool to the primary site pool. Do not use the Forceoption.

  12. On the load balancer, disable the Front End Servers associated with the pool in the secondary site, and then configure the Front End Servers in the primary site pool as specified in the deployment plan.

  13. Modify DNS records to point back to the original primary site pool.

  14. Log on to Office Communicator, and then verify connectivity to the primary site and functionality of IM, contact groups, and contact lists. Depending on the configuration and situation, you may need to modify configurations to do this. For instance, if the virtual IP address and pool FQDN change, it may be necessary to modify the client configuration unless auto-logon is enabled. It may also be necessary to use the ipconfig /flushdnscommand.