Logo
PREGNANCY
Windows XP
Windows Vista
Windows 7
Windows Azure
Windows Server
Windows Phone
 
 
Windows Server

Exchange Server 2010 : Recovering Exchange Roles (part 1)

6/4/2011 6:40:55 PM
Exchange Server 2010 configuration data is stored in Active Directory (except for servers with the Edge Transport server role), and you can fully restore some server roles, such as Hub Transport server, by running Exchange Setup in the Recoverserver mode using the following command:
Setup /m:Recoverserver

With other roles, such as Mailbox server, this command restores the Exchange configuration, but you need to recover critical Exchange data from backup. This lesson looks at the various Exchange server roles and how you should plan to recover each role.

1. Creating a Disaster Recovery Plan Based on Exchange Roles

Before considering the recovery of Exchange server roles, it is important to remember that certain types of hardware failure do not require a server recovery process. If, for example, a server’s processor, motherboard, or power supply fails, recovery often requires only the replacement the failed components and a server reboot. It might be necessary to go through the Windows Product Activation process again because of the hardware changes and to install new hardware device drivers, but in general you need to go through the server recovery process only when all the data on your storage devices has been lost or is irretrievably corrupted.

The Exchange Server 2010 Setup routine, includes a Recoverserver mode that is used for recovering a server or moving a server to new hardware while maintaining the same server name. When you run Setup in this mode, it reads configuration data from Active Directory for a server with the same name as the server from which you are running Setup. Note that the Recoverserver mode does not migrate locally stored custom settings or databases, only settings stored in Active Directory.

You can use a basic set of recovery steps for all server roles, except for Edge Transport server. Edge Transport servers are stand-alone and are not part of a domain. They therefore do not have configuration data associated with a computer account.

Before you run Setup in Recoverserver mode to recover a server role to a replacement computer (or to the same computer with its system hard disk reformatted), you need to take the following steps:

  • Reset the Active Directory computer account This allows you to join a replacement computer to the domain. Take care not to delete the failed server’s computer account because this would result in the loss of all Exchange configuration data stored with the computer account. Resetting the account enables you to join the replacement server to the domain but does not delete configuration data.

  • Install the operating system You need to install Windows Server 2008 SP2 (64-bit) or Windows Server 2008 R2 on the replacement server specifying exactly the same volume and operating system configuration as you used in the server you are recovering. The operating system you install must be exactly the same as the operating system that was installed on the failed server.

  • Specify the replacement server name The replacement server must be assigned precisely the same name as that of the failed server.

  • Configure the replacement server to host the relevant Exchange Server 2010 server role or roles You need to install specific roles, role services, prerequisite components, and features on the replacement server prior to attempting to deploy specific Exchange server roles.

  • Join the replacement server to the domain

When you have gone through the preliminary steps listed, you run Exchange Setup in Recoverserver mode, as described previously in this lesson. This extracts the configuration data that is associated with the failed server’s Active Directory computer account and applies that data as part of the recovery process.


2. Recovering a Hub Transport Server

Typically, you can restore a server running the Hub Transport server role almost completely by running Exchange Setup in Recoverserver mode. Hub Transport servers store all essential configuration data in Active Directory in addition to some limited configuration data stored in the registry. You can back up the registry by performing a System State data backup and if necessary restore it with a System State data restore.

The only items that will not be restored by using Recoverserver mode on a Hub Transport server are message queues stored in database files and any message tracking, protocol, and connectivity logs you enabled on the failed server. Queues store messages currently being processed, and because of their transient nature, they use circular logging and are not backed up. Logs are used primarily for historical reference and troubleshooting.

Queues and logs are typically not essential to restoring Hub Transport server functionality. If, however, you want to recover a particularly important message, you can mount the message queue databases, located in the C:\Program Files\Microsoft\Exchange Server\TransportRoles\data\Queue directory on an alternate Hub Transport server, assuming of course that this data was not lost when the server failed. In general, however, it is easier to look for a copy of a sent message in a user’s Outbox or ask the sender to retransmit it.

3. Recovering a Client Access Server

You can restore a failed server running the Client Access server role to its initial default state by running Exchange Setup in Recoverserver mode. Any changes you have made to Hypertext Transfer Protocol (HTTP) virtual servers running on the Client Access server are, however, not restored because changes to these virtual servers are stored in Internet Information Server (IIS) configuration data.

Restoring the IIS configuration data from backup to recover the custom settings can generate errors on the Client Access server if the IIS configuration data and the recovered Active Directory settings are not exactly in synchronization. This procedure is not therefore recommended.

Client Access servers store some configuration data in the registry that you can restore if you have backed up System State data. However, this configuration data is limited.

Many organizations do not apply customizations to their Client Access servers, in which case running Exchange Setup in Recoverserver mode restores the server role. If, however, your organization does customize a Client Access server, you need to take the following precautions to enable you to recover the server role in the vent of failure:

  • Keep a log of all customizations that you make to the original Client Access server This information is required for server role recovery because some configuration settings are not associated with the computer account in Active Directory.

  • Take a note of the server’s volume configuration The recovery process requires that the recovered server’s volume configuration matches that of the failed server.

  • Ensure you have a valid Secure Sockets Layer (SSL) certificate You can reapply for an SSL certificate from an enterprise certification authority (CA) server in your domain through the Internet Information Services (IIS) console. If, however, you obtained the server’s SSL certificate from a trusted third-party authority, you should store a copy of this certificate somewhere secure. Many organizations keep purchased certificates in a safe after they have been installed.

  • Keep a record of your custom virtual directories If a Client Access server uses custom virtual directories to, for example, publish custom offline address books, you need to re-create these manually when the server is recovered.

  • Apply customization changes after you have performed the recovery process Otherwise, it is possible that these configuration changes will be overwritten by that process.

If a significant amount of customization has occurred you may find it easier to run Exchange Setup and restore your Client Access server by building a new server with a new name. However, if, as is more typical, little or no customization has been carried out, you can restore the failed server with the same name by running Exchange Setup in Recoverserver mode. If you choose the second alternative, you then need to apply the same customizations that you had on the failed server by re-creating additional websites and virtual directories as necessary. You restart IIS to apply the setting changes.


4. Recovering a Mailbox Server

You cannot fully restore the Mailbox Server role by running the Exchange Setup program in Recoverserver mode but must, in addition, restore the Mailbox server from a backup that includes the necessary Exchange data and the System State data. Mailbox servers store Exchange mailbox and public folder database files together with Exchange transaction log files specific to each database. You need to back up these files with an Exchange-aware backup application, such as Windows Server Backup.

If available replicas exist, you can rebuild replicated public folder data through the normal replication process. Mailbox servers also store full-text indexing information specific to each mailbox database, but you do not back up or restore full-text indexes because you need instead to rebuild them. Other types of Exchange databases on Mailbox servers include free/busy information and the offline address book. This information is rebuilt through automated maintenance and then replicated.

To recover the Mailbox server role, you first use Exchange Setup in Recoverserver mode to extract the original Mailbox server’s configuration data from Active Directory. The volume configuration of the replacement server must be exactly the same as that of the failed server. Mailbox servers are particularly sensitive to any configuration differences, and you need to document the exact configuration of the server’s storage devices and volumes. If this configuration is not precisely reproduced, you are likely to encounter problems when attempting to restore mailbox and storage group data.


Note:

Exchange Server 2007 uses cluster continuous replication (CCR) or a single copy cluster configuration to provide failover protection and high availability for Mailbox servers. If you need to recover a clustered Mailbox server in Exchange Server 2007, you re-create the failed cluster node and then run Exchange Setup with the RecoverCMS switch to install the passive Mailbox server role on the computer. However, Exchange Server 2010 uses DAGs and mailbox database copies to implement the same functionality. If you see an answer in the examination that features CCR or the RecoverCMS switch, that answer is likely to be wrong.


5. Recovering a Member Server in a DAG

If a member of a DAG fails and you want to replace it, you need to remove any database copies that were held on the failed server from the DAG. You also remove the configuration of the failed server from the DAG. You then reset the failed server’s computer account and use Exchange Setup in Recoverserver mode to perform the server recovery operation in the same way as you do for any failed Mailbox server.

The original Exchange files and services are then installed on the server, and the roles and settings that were stored in Active Directory are applied to the server. You add the recovered server to the DAG and reconfigure the mailbox database copies. The step-by-step procedure to recover a failed DAG member server is as follows:

  1. Retrieve any replay lag or truncation lag settings for any mailbox database copies that exist on the failed server by entering an EMS command based on the Get-MailboxDatabase cmdlet:

    Get-MailboxDatabase Research | FL *lag*

    Figure 1 shows the output of this command. Note that in this case, both the replay lag and the truncation lag times are zero.

    Figure 1. Listing the replay lag and truncation lag for a mailbox database copy


  2. Remove any mailbox database copies that exist on the failed server by entering an EMS command based on the Remove-MailboxDatabaseCopy cmdlet:

    Remove-MailboxDatabaseCopy Research\VAN-EX1

  3. Remove the failed server’s configuration from the DAG by entering an EMS command based on the Remove-DatabaseAvailabilityGroupServer cmdlet:

    Remove-DatabaseAvailabilityGroupServer -Identity Research -MailboxServer VAN-EX1


  4. Reset the server’s computer account in Active Directory.

  5. Install exactly the same operating system on the replacement server that was installed in the failed server. Ensure that the computer names are also identical.

  6. Insert the original Exchange Server 2010 setup media into the replacement server. Open a Command Prompt window, access the volume that holds the setup media, and enter the following command:

    Setup /m:Recoverserver

  7. When the Setup recovery process is complete, add the recovered server to the DAG by entering an EMS command based on the Add-DatabaseAvailabilityGroupServer cmdlet:

    Add-DatabaseAvailabilityGroupServer -Identity MyDAG -MailboxServer VAN-EX1

  8. Reconfigure mailbox database copies by entering one or more EMS commands based on the Add-MailboxDatabaseCopy cmdlet. If any of the database copies being added previously had replay lag or truncation lag times greater than zero, you can use the ReplayLagTime and TruncationLagTime parameters of this cmdlet to reconfigure those settings:

    Add-MailboxDatabaseCopy -Identity Research -MailboxServer VAN-EX1

    Add-MailboxDatabaseCopy -Identity Marketing -MailboxServer VAN-EX1 -ReplayLagTime
    2.00:00:00

    Add-MailboxDatabaseCopy -Identity Sales -MailboxServer VAN-EX1 -ReplayLagTime
    2.00:00:00 -TruncationLagTime 1.00:00:00


6. Recovering a Unified Messaging Server

Like the Hub Transport server role, the Unified Messaging server role stores its essential configuration data in Active Directory and some limited configuration data in the registry. You can restore a Unified Messaging server to its initial default state by running the Exchange Setup program in Recoverserver mode. If necessary, you can restore registry settings from a System State data backup.

Queues and logs are not essential to restoring Unified Messaging server functionality. You can mount message queues on a new server if you can recover them from a failed server. You can also restore custom audio files used for prompts automatically through replication if you have other Unified Messaging servers in the organization.

7. Recovering an Edge Transport Server

The Edge Transport server role is installed on a stand-alone server. Edge Transport servers store configuration data, queues, replicated data from Active Directory, and any logs, such as message tracking, protocol, and connectivity logs, that have been enabled. These servers also store some configuration data in the registry.

Replicated data from Active Directory is stored in Active Directory Application Mode. Queues store messages that are being processed, and logs are used primarily for historical reference and troubleshooting. Replicated data, queues, and logs are not essential to restoring Edge Transport server functionality. Replicated data can be resynchronized as necessary, and both queues and logs are created automatically as necessary.

If you have applied custom settings to an Edge Transport server (for example, for content filtering), you can create a backup of the configuration through cloning.

7.1. Cloning Edge Transport Server Configurations

Edge Transport server settings are configured by information from the web (for example, anti-spam updates) or are replicated from Active Directory through the EdgeSync process. If you have not modified or customized these settings, you do not need to back up Edge Transport server data. In this case, you can fully recover edge transport services by setting up a new Edge Transport server. If, however, you modify or customize settings, you need to clone the configuration to capture your changes.

Two scripts exist in the C:\Program Files\Microsoft\Exchange Server\Scripts directory on an Edge Transport server. When you run the ExportEdgeConfig.ps1 script, Exchange exports all user-configured settings and stores the data in an extensible markup language (XML) file. When you copy this XML file (or a backup of the XML file) to a new Edge Transport server and run the ImportEdgeConfig.ps1 script, Exchange imports the user-configured settings saved in the in the XML file.

7.2. Creating the Configuration XML File

The step-by-step procedure to create the configuration XML file is as follows:

  1. Copy the ExportEdgeConfig.ps1 script from the C:\Program Files\Microsoft\Exchange Server\Scripts directory to the root folder of your user profile on the source Edge Transport server.

  2. Export the server configuration data by using the ExportEdgeConfig.ps1 script on the source server. To do this, you enter an EMS command with the following syntax:

    ./ExportEdgeConfig -CloneConfigData:"<path of the XML file to be created>"

  3. The confirmation message “Edge configuration data is exported successfully to: <path of the XML file to be created>” appears. Copy the XML file to the target server.

7.3. Creating an XML Answer File and Importing Configuration Settings

The ImportEdgeConfig.ps1 script checks the XML file to see whether the server-specific settings are valid for the target Edge Transport server. If any settings need to be modified, the script writes the invalid settings to an XML answer file that you can use to modify the target server information in the XML configuration file. During the import configuration step, the script imports the user-configured settings and data stored in the XML file. The step-by-step procedure to validate a configuration file and create an answer file is as follows:

  1. Copy the ImportEdgeConfig.ps1 script from the C:\Program Files\Microsoft\Exchange Server\Scripts directory to the root folder of your user profile on the target Edge Transport server.

  2. Validate the configuration file and create an answer file that enables you to modify any settings that are listed as invalid on the target server by using the ImportEdgeConfig.ps1 script. To do this, enter an EMS command with the following syntax:

    ./ImportEdgeConfig -CloneConfigData:"<path of the XML file you have copied from
    the source server>" -IsImport $false -CloneConfigAnswer:"<path of the XML answer
    file used to configure server-specific settings>"


  3. The confirmation message “Answer file is successfully created” appears. Open the answer file and modify any settings that are invalid for the target server. If no modifications are required, the answer file will have no entries. Save your changes.

When you have created an answer file and made any required modifications, you then import the configuration settings in the XML file you copied from the source server, modified by the settings in the answer file. To do this, enter an EMS command with the following syntax:

./ImportEdgeConfig -CloneConfigData:"<path of the XML file you have copied from the
source server>" -IsImport $true -CloneConfigAnswer:"<path of the XML answer file used to
configure server-specific settings>"

The confirmation message “Importing Edge configuration information succeeded” appears.
Other -----------------
- Windows Server 2008 : Planning for Terminal Services and Application Virtualization - Terminal Services Roles (part 3)
- Windows Server 2008 : Planning for Terminal Services and Application Virtualization - Terminal Services Roles (part 2)
- Windows Server 2008 : Planning for Terminal Services and Application Virtualization - Terminal Services Roles (part 1)
- Exchange Server 2010 : Backup and Recover Exchange Data (part 4) - Recovering Single Items & Using Exchange Native Data Protection
- Exchange Server 2010 : Backup and Recover Exchange Data (part 3) - Database Portability & Recovering a Mailbox within the Deleted Mailbox Retention Period
- Exchange Server 2010 : Backup and Recover Exchange Data (part 2) - Creating an Exchange Server Disaster Recovery Plan
- Exchange Server 2010 : Backup and Recover Exchange Data (part 1) - Using Windows Server Backup
- Planning for Forestwide and Domainwide Upgrades with Server 2008 : Planning for Upgrades in an Existing Forest
- Planning for Forestwide and Domainwide Upgrades with Server 2008 : Cross-forest Authentication
- Exchange Server 2010 : High Availability for Other Exchange Roles (part 2) - Practice: DAGs and Public Folder Replication
- Exchange Server 2010 : High Availability for Other Exchange Roles (part 1)
- Exchange Server 2010 : Highly Available Public Folders
- Exchange Server 2010 : Managing Database Availability Groups (part 2) - Mailbox Database Copies
- Exchange Server 2010 : Managing Database Availability Groups (part 1)
- Planning for Forestwide and Domainwide Upgrades with Server 2008 : Migrating Computer Accounts
- Planning for Forestwide and Domainwide Upgrades with Server 2008 : Migrating User Accounts
- SharePoint 2010 Disaster Recovery for End Users : Versioning
- SharePoint 2010 Disaster Recovery for End Users : Recycle Bins
- Planning for Forestwide and Domainwide Upgrades with Server 2008
- Windows Server 2008 : Planning for Network Access
 
 
Most view of day
- Nginx HTTP Server : Basic Nginx Configuration - Testing your server
- BizTalk Server 2006 : Starting a New BizTalk Project - BizTalk Assembly Naming and Versioning
- Windows Phone 8 : Working with the Windows Phone Software (part 6) - Removing Multimedia Content - Removing Music from Your Phone
- SQL Server 2012 : XML and the Relational Database - Shredding XML Using OPENXML
- Microsoft Word 2010 : Adding Graphics to Your Documents - Drawing Shapes in Word (part 1) - Drawing an AutoShape
- Windows Phone 8 : Configuring Basic Device Settings - Date and Time (part 1) - Setting the Date and Time
- Microsoft Access 2010 : Using Reports to Print Information - Printing a Report
- Using the Windows 7 Libraries : USING THE EXPLORER BROWSER CONTROL (part 2)
- Workflow in Dynamics AX 2009 : Workflow Life Cycle (part 1) - State Model
- Sharing Your Computer with Others : Display User Accounts
Top 10
- Configuring and Troubleshooting IPv6 in Windows Vista (part 4) - Troubleshooting IPv6 Connectivity
- Configuring and Troubleshooting IPv6 in Windows Vista (part 3) - Configuring IPv6 in Windows Vista Using Netsh , Other IPv6 Configuration Tasks
- Configuring and Troubleshooting IPv6 in Windows Vista (part 2) - Configuring IPv6 in Windows Vista Using the User Interface
- Configuring and Troubleshooting IPv6 in Windows Vista (part 1) - Displaying IPv6 Address Settings
- Deploying IPv6 : IPv6 Enhancements in Windows Vista
- Games and Windows 7 : Games for Windows - LIVE (part 2) - Accessing Games for Windows - LIVE from within Compatible Games
- Games and Windows 7 : Games for Windows - LIVE (part 1) - Using the Games for Windows - LIVE Marketplace
- Sharepoint 2013 : Client-side Programming - Working with the REST API (part 3)
- Sharepoint 2013 : Client-side Programming - Working with the REST API (part 2) - Working with the REST API in JavaScript
- Sharepoint 2013 : Client-side Programming - Working with the REST API (part 1) - Understanding REST fundamentals
 
 
Windows XP
Windows Vista
Windows 7
Windows Azure
Windows Server
Windows Phone
2015 Camaro