5. Repairing Exchange
The
Exchange 2013 setup program does not support a repair mode; you cannot
run Setup in a repair mode to have it scan a server for any missing
files, registry keys, Active Directory objects, or other elements that
might be affecting the ability of the server to run properly. If a
server is not functioning correctly and nothing you do seems to make
any difference (and no help is gained by searching the Internet), you
might be forced to uninstall all the roles from the server to remove
Exchange and then reinstall the server from the beginning. This is not
so bad; experience with broken software demonstrates that a “flatten
and rebuild” approach usually delivers a more robust solution than
attempting to repair individual flaws that might be hiding other
problems that only appear after you repair the apparent problem.
An
alternative approach is to wait for Microsoft to provide a fix in a
cumulative update and install it as an upgrade to a more recent build.
This will usually fix any problems caused by a missing component, if
only because a build-to-build upgrade includes code that will create
objects such as a missing registry key or permission that it detects as
the server is upgraded.
6. Recovering a failed server
If you’re unfortunate enough to suffer a catastrophic hardware
failure that renders a computer completely unusable, you can recover
the configuration for the server from Active Directory to rebuild
Exchange. To do this, you must first provide new hardware that runs the
same operating system as the failed server and has the same drive
letters available for the databases that the server supports. The new
server should be as powerful as the failed computer in terms of its
ability to support user load. Because new hardware usually has improved
performance, it shouldn’t be a problem to replace the failed computer
with new hardware, but replacing it with older hardware might be
problematic if the configuration of that computer isn’t as capable and
is therefore less likely to support the same load.
After the new hardware is installed, you must do the following:
Reset the Active Directory computer account for the failed server.
Install
and configure Windows with the prerequisite roles and features,
including any hotfixes Exchange requires; the setup program cannot
install any required software when it runs in recovery mode.
Ensure
that network connectivity works properly and that the new computer is
configured with the correct IP addresses and other settings.
Join the replacement computer to the domain hosting Exchange with the same name as the failed server.
Authenticate the Windows server license.
You
can then run Setup.com with the /m:recoverserver command. In this mode,
the installation procedure reads the details of the server
configuration from Active Directory and reconstructs an exact replica
of the failed server. Exchange keeps details of the software versions
installed on a computer in the system registry, and the setup program
will only recover a server to the same version of Exchange that was
installed on it before it failed. You cannot recover and upgrade at the
same time; for instance, it’s not possible to recover a failed Exchange
2013 server by using an Exchange 2013 SP1 software kit, so be sure you
keep a share or DVD with the version of Exchange that you’ve actually
installed.
After the recovery is complete, all the server roles
defined in Active Directory will be operational on the replacement
server. In the case of a failed mailbox server, you must still restore
databases to their location on disk. The up-to-date database and
transaction logs might be accessible from the disks the failed server
used. If not, you’ll have to recover from backup and replay whatever
transaction logs are available to bring the databases as up to date as
possible. Some data loss is inevitable in this case. In the case of CAS
servers, you might also have to restore configuration files that are
not included in Active Directory. For example, if you update the
Mailbox Replication Service (MRS) configuration file on mailbox servers
for some reason, you will have to:
Copy
the updated configuration file from another mailbox server (if
available) in the organization. All configuration updates should be
applied consistently across the organization.
Recover the configuration file from another backup.
Manually
apply the update again. This assumes that you have details of the edits
that should be applied to the configuration file, which underlines the
need for careful documentation of these types of changes.
Special
steps are required for failed servers that are members of a DAG. The
installation procedure won’t allow you to run /m:recoverserver if it
detects that the server is a member of a DAG. To proceed, you must
remove database copies and then evict the failed server from the DAG
before you can run the steps described earlier. After the server is
restored to full health, you can bring it back into the DAG and create
new database copies.
Remember
that the operation you’ve just performed is a recovery of Exchange
based on information in Active Directory. Any information or
configuration setting that is stored outside Active Directory, such as
customizations made to configuration files, must be restored separately.
