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.
Mailbox Server
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.
Hub Transport Server
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.
Edged Transport Servers
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.
Client Access Servers
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.
Unified Messaging Servers
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.
No comments:
Post a Comment