Scheduled Exchange Server outages
Many people think of a server outage as something unexpected. Sometimes, however, it's necessary to take an Exchange Server down for maintenance. In a cluster continuous replication (CCR) environment, it's possible to take a mailbox server offline with only a minor interruption to the users.
The basic philosophy behind this technique is that, in a CCR environment, you technically have two different mailbox servers with identical copies of a storage group. If you need to take the active server down for maintenance, it's possible to direct Exchange to use the server with the passive copy of the information store as the active mailbox server.
You can perform this procedure using either the Exchange Management Console (EMC) or the Exchange Management Shell (EMS). Using the EMS can be quicker and easier than clicking through the EMC. To move the clustered mailbox server using the EMS, enter the following command:
Move-ClusteredMailboxServer Identity:<clustered mailbox server name> -TargetMachine<passive node name> -MoveComment:<comment>
In this command, you must provide the name of your clustered mailbox server, the name of the server that is acting as the passive node and a comment regarding why the passive node is being designated as the active node. If you prefer to perform the procedure using the Exchange Management Console, this Microsoft TechNet article on how to move a clustered mailbox server in a CCR environment can help.
Unplanned Exchange Server outages
How the passive node behaves when the active node experiences an unscheduled Exchange Server failure varies depending upon how CCR is configured and the nature of the failure. When the passive node detects that a failure has occurred on the active node, it first attempts to copy any remaining log files from the active node. This might sound strange in a failure situation, but sometimes it works.
For example, if the active node fails because one of the Exchange-related services stops, Windows would still be functional and the passive node should be able to connect to the failed server and copy any log files. Assuming that the copy process is successful, the passive node will consider itself to be in a lossless state. Once the passive node verifies that no data has been lost, it will mount the information store within the protected storage group.
Things work differently if the passive node cannot copy the log files from the active node. If the log file copy process fails, then Exchange looks to see how the AutoDatabaseMountDial setting is configured. There are three potential settings.
The first possible setting is lossless, which means that no log files are lost.
The Exchange Server can also be set to use good availability, which allows a loss of up to three log files (3 MB). Assuming that replication was functioning normally prior to the failure and that log files are being copied as soon as they are closed, then the good availability setting should provide automatic recovery with very little data loss.
The third setting is best availability. The best availability setting, which is also the default setting, allows up to six log files to be lost. This setting has pros and cons.
The best availability setting does provide automatic recovery in high-latency environments. This means that even if the replication processes aren't completely up to date, automatic recovery can still occur. However, with the best availability setting, there is a chance that the passive node might not contain all of the data that the active node contains. When the failed server comes back online, database divergence can become an issue. In this case, you must perform a full reseed of the failed server's database to correct the problem.
About the author: Brien M. Posey, MCSE, is a five-time recipient of Microsoft's Most Valuable Professional award for his work with Exchange Server, Windows Server, Internet Information Services (IIS), and File Systems and Storage. Brien has served as CIO for a nationwide chain of hospitals and was once responsible for the Department of Information Management at Fort Knox. As a freelance technical writer, Brien has written for Microsoft, TechTarget, CNET, ZDNet, MSD2D, Relevant Technologies and other technology companies. You can visit Brien's personal website at www.brienposey.com.
Do you have comments on this tip? Let us know.
Please let others know how useful this tip was via the rating scale below. Do you know a helpful Exchange Server, Microsoft Outlook or SharePoint tip, timesaver or workaround? Email the editors to talk about writing for SearchExchange.com.