When Microsoft created Exchange Server 2007, one of the biggest changes that they made was the creation of server roles. The concept of roles existed in Exchange server 2003, it was very limited. In Exchange server 2007, there are five different roles which serve five very specific purposes.
Because these roles are so different from one another, the tasks that an Exchange Server performs, and the code that is installed is entirely dictated by the role that the server is configured to perform. That being the case, it is necessary to completely reevaluate your backup strategy. The backup techniques and procedures that Exchange admins have used for so long are not always the best option in an Exchange Server 2007 environment. In this article, I will discuss some backup strategies for each of the various Exchange 2007 server roles.
Like its predecessors, Exchange Server 2007 stores user’s mailboxes in a jet database (now called an extensible storage engine database). For all practical purposes, backing up a mailbox server in Exchange Server 2007 is really no different than backing up an Exchange 2003 server. That being the case, I want to focus the majority of my discussion on the other server roles.
As I’m sure you probably know, a hub transport server’s primary job is to route messages within the Exchange Server organization. At first glance, it would appear that it would be appropriate to use the same backup technique for a hub transport server as you would use for a mailbox server. After all, a hub transport server contains all of the message queues, and then Exchange Server 2007, the queues are based on a jet database that is very similar to the ones used by mailbox servers.
In spite of this though, Microsoft actually recommends that you do not backup hub transport servers in the traditional manner. This is primarily because of the transient nature of the messaging queues. Suppose for a moment that you made a backup of the hub transport server, and 15 minutes later the server failed catastrophically. It wouldn’t really do you any good to restore the database used by the message queues, because all of the messages that were in the queues at the time that the backup was made would have already been delivered.
Not only is it not necessary to backup the message queues, you really don’t have to worry about backing up the server’s configuration either. The vast majority of the configuration information is stored in Active Directory. If you find yourself having to rebuild a hub transport server, you can simply run Setup with the /Mode:RecoverServer switch. This command will use information contained in the Active Directory to rebuild the server. You can read more about this command at Microsoft Technet.
Although it’s transport servers are designed to be isolated from the rest of your Exchange Server organization, they are architecturally very similar to hub transport servers. In fact, it’s transport servers use queues that are based on the extensible storage engine just like hub transport servers do. Like hub transport servers, it is impractical to try to back up these queues.
Assuming that you are running a default configuration, you may not even need to worry about backing up an edge transport server. After all, Microsoft automatically updates the ant spam information over the Internet.
There are two cases though that weren’t backing up an edge transport server. One such situation would be cases in which you want to retain your message tracking and protocol logs. If you need to back up these logs, you can perform a simple file level backup. Incidentally, the same thing goes for hub transport servers.
The other situation that would warrant backing up an edge transport server is that you would want to create a backup if you were using custom filtering settings. If you are using custom filtering settings, you’ll have to use a predefined script to export those settings to an XML file. You can then back that XML file up using a normal file level backup. Should you ever need to restore the settings, you simply import the XML file using another predefined script. In case you’re wondering, these scripts are called ExportEdgeConfig.ps1 and ImportEdgeConfig.ps1. Both of these scripts are located in the \Program Files\Microsoft\Exchange Server\Scripts folder.
Backing up and restoring client access servers can be pretty tricky. Like a hub transport server, you can rebuild a client access server by entering the SETUP /MODE:RecoverServer command.
The problem is that entering this command returns the client access server to a default state. Even if you have created non-default virtual directories, those directories will be wiped out after using this command. Unfortunately, entering this command and then restoring a backup isn’t really an option because doing so will cause the IIS Metabase to be out of sync with the Active Directory. As such, Microsoft recommends that you make a log of all of the custom changes that you apply to your server. You can use the Setup command to rebuild the server, and then manually reapply your customizations.
If you decide to perform a traditional backup, then you must design the backup to include system state data.
As I’m sure you probably know, unified messaging servers allow you to store voice mail and faxes in Exchange Server mailboxes. Assuming that your unified messaging server is running a default configuration, you don’t have to worry about backing it up. All of the essential configuration data is stored in the Active Directory, and you can easily rebuild a unified messaging server by using the SETUP /MODE:RecoverServer command.
There is one exception to this rule though. If you have configured your unified messaging server to use custom voice prompts, then you will need to perform a file level backup to ensure that those voice prompts are backed up. In case you’re wondering, voice prompts are stored in the \Program Files\Microsoft\Exchange Server\Unified Messaging\Prompts folder.
As you can see, the majority of the configuration data used by Exchange Server 2007 is stored in the Active Directory. While this makes it easy, or even unnecessary to back up some of your Exchange Servers it becomes absolutely critical to make sure that you get good backups of the active Directory database.