Please let others know how useful this tip is via the rating scale at the end of it. Do you have a useful Exchange or Outlook tip, timesaver or workaround to share? Submit it to our tip contest and you could win a prize.
After a restore operation completes, Exchange looks for transaction logs that might still exist on the server. If transaction logs exist, they are played back in an effort to make the restored database more current. Then, the update sequence numbers (USNs) of objects within the database are compared to the USNs on other servers. If other servers have more current USNs than the restored database, the database is updated to reflect changes indicated by the most current USNs. The end result is that the restored database is nearly identical to how it was at the time of the crash.
The technology behind the recovery procedure is amazing and I commend Microsoft for doing a great job developing it. Even so, there are situations in which Exchange's recovery method can work against you.
The recovery procedure I just described assumes that the server crashed. Sometimes that just isn't the case though. For example, if you have an inexperienced administrator who accidentally deletes a thousand mailboxes, you will probably find yourself restoring a backup -- but it won't be because the server crashed.
Imagine that you created a backup last night. This morning your inexperienced administrator accidentally deleted a thousand mailboxes. You can restore last night's backup, but there's a problem: The deletion action has a higher USN than the USNs on the backup tape. Therefore, when you restore the backup, yes, the mailboxes will be restored -- but they will soon be deleted -- because that's what Exchange thinks it needs to do in order to make the backup current.
To get around this problem, Microsoft has a tool called AUTHREST.EXE. This tool allows you to perform an authoritative restore of an Exchange database. It works by modifying the USNs on the restored database to make them higher than the highest USNs on any of your other Exchange servers. That way, the backfilling process won't overwrite anything on the server, and you can restore those thousand mailboxes without fearing that they'll disappear soon after.
Obviously, the AUTHREST.EXE tool is a handy tool to have around. But there are caveats. AUTHREST.EXE updates all of the USNs on a server. This means that even if intentional changes have been made since the time of the last backup, those changes will be undone by AUTHREST.EXE.
So how to you know when you should and should not use AUTHREST.EXE? In the example situation I described, in which a thousand accounts were deleted, I would use the AUTHREST.EXE tool without hesitation -- especially if I had a very recent backup. However, if your most recent backup is several days old, or if you only have a few mailboxes to recover, you are usually a lot better off using a different recovery method.
In those situations, I recommend using Exchange 2003's Recovery Storage Group feature. With it, you can restore your backup to a recovery storage group rather than overwriting the current database. You can then move deleted mailboxes from the recovery storage group to the information store. There's a little bit more to the procedure than that, but that's the general idea of how it works. If you need more specific instructions, check out my recent article on recovery storage groups.
About the author: Brien M. Posey, MCSE, is a Microsoft Most Valuable Professional for his work with Windows 2000 Server and IIS. Brien has served as CIO for a nationwide chain of hospitals and was once in charge of IT security for Fort Knox. As a freelance technical writer he has written for Microsoft, TechTarget, CNET, ZDNet, MSD2D, Relevant Technologies and other technology companies. You can visit Brien's personal Web site at http://www.brienposey.com.
Do you have comments on this tip? Let us know.
