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:
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.
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
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
Reset the server’s computer account in Active Directory.
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.
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
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
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:
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.
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>"
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:
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.
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>"
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.
