Tech
Safeguard your Exchange 2003 front-end servers
Most of the disaster recovery (DR) discussion that focuses on Microsoft Exchange servers looks directly at the servers which contain the databases. This means protecting the servers that hold mailbox and public folder data, which is vital for the proper resurrection of your Exchange infrastructure.
Most of the disaster recovery (DR) discussion that focuses on Microsoft Exchange servers looks directly at the servers which contain the databases. This means protecting the servers that hold mailbox and public folder data, which is vital for the proper resurrection of your Exchange infrastructure. However, an often overlooked issue is how to protect front-end Exchange servers that exist in midsize to enterprise-class organizations. These servers function with a wide number of potential roles, but the two most popular are those we'll address here: Outlook Web Access (OWA) servers and SMTP relay systems.
Protecting front-end server functions
SMTP relay servers act as targets for external SMTP servers sending outside mail to your company servers. They also act as bridgehead servers to the outside world, ferrying all communication from within the organization to its destinations.
OWA is a Web-based client that allows users outside your corporate LAN to access their e-mail without using Outlook client software installed on their local computers. They can use any computer with a Web browser to access their e-mail from anywhere they happen to be, and with as much security as you would like to afford them. To be clear, any Exchange server can perform these tasks. A front-end server, however, is a specifically-installed Exchange server that--generally speaking--doesn't actually host any mailbox or public folder data but connects to those servers that do.
Capture a system snapshot for bare-metal restores
To protect these servers, you will have to follow slightly different paths than you will for servers that contain Exchange databases. First off, there's no real data to protect. You could protect the incoming and outgoing mail streams if you wished, but in most cases, you'll find that this data only stays on the server for a matter of minutes at most. Instead, you need to protect the functions these servers fulfill.
An appropriate backup method for these servers is capturing a system snapshot for a bare-metal restore to repaired and/or new hardware systems in the event of a server loss. Tools included with Windows can capture system state, but do not perform a bare-metal restore. Instead, you'll have to re-install Windows, then restore the system state.
Third-party tools from backup software manufacturers can offer the ability to restore directly to a clean system with no Windows OS on it yet. Once reinstalled, you may need to perform some re-configuration of the Exchange systems, or even perform a DR installation of Exchange (using a command-line switch) that can re-configure the system while it puts the Exchange files back into place. Depending on which recovery tools you use for the server itself, you may not have to perform these steps at all, so keep that in mind and speak with your backup software vendor.
Redundancy and load balancing
You can also protect these systems by creating redundancy. A second server at the same site can be configured to either share the load for incoming and outgoing connections, or be set up so it's ready to stand in for the primary server in the event of a failure. Load-balancing can be configured by dynamically sending connections to one server or the other depending on equal allocation or--with some additional load-balancing hardware and/or software--based on the load on the servers at the time of the new connection coming in.
While a load-balancing solution can be extended to a second site, the expense of both the server technology and infrastructure makes it beyond the budgetary reach of most organizations. However, failover to another site can be accomplished by controlling DNS and other networking systems, instead of trying to load-balance across sites.
By using combinations of these technologies, you can effectively protect your front-end Exchange servers just as well as you protect your Exchange database servers. This can allow you to create solutions that protect the security of the enterprise, while not compromising user connectivity or protection to do it.
Protecting front-end server functions
SMTP relay servers act as targets for external SMTP servers sending outside mail to your company servers. They also act as bridgehead servers to the outside world, ferrying all communication from within the organization to its destinations.
OWA is a Web-based client that allows users outside your corporate LAN to access their e-mail without using Outlook client software installed on their local computers. They can use any computer with a Web browser to access their e-mail from anywhere they happen to be, and with as much security as you would like to afford them. To be clear, any Exchange server can perform these tasks. A front-end server, however, is a specifically-installed Exchange server that--generally speaking--doesn't actually host any mailbox or public folder data but connects to those servers that do.
Capture a system snapshot for bare-metal restores
To protect these servers, you will have to follow slightly different paths than you will for servers that contain Exchange databases. First off, there's no real data to protect. You could protect the incoming and outgoing mail streams if you wished, but in most cases, you'll find that this data only stays on the server for a matter of minutes at most. Instead, you need to protect the functions these servers fulfill.
An appropriate backup method for these servers is capturing a system snapshot for a bare-metal restore to repaired and/or new hardware systems in the event of a server loss. Tools included with Windows can capture system state, but do not perform a bare-metal restore. Instead, you'll have to re-install Windows, then restore the system state.
Third-party tools from backup software manufacturers can offer the ability to restore directly to a clean system with no Windows OS on it yet. Once reinstalled, you may need to perform some re-configuration of the Exchange systems, or even perform a DR installation of Exchange (using a command-line switch) that can re-configure the system while it puts the Exchange files back into place. Depending on which recovery tools you use for the server itself, you may not have to perform these steps at all, so keep that in mind and speak with your backup software vendor.
Redundancy and load balancing
You can also protect these systems by creating redundancy. A second server at the same site can be configured to either share the load for incoming and outgoing connections, or be set up so it's ready to stand in for the primary server in the event of a failure. Load-balancing can be configured by dynamically sending connections to one server or the other depending on equal allocation or--with some additional load-balancing hardware and/or software--based on the load on the servers at the time of the new connection coming in.
While a load-balancing solution can be extended to a second site, the expense of both the server technology and infrastructure makes it beyond the budgetary reach of most organizations. However, failover to another site can be accomplished by controlling DNS and other networking systems, instead of trying to load-balance across sites.
By using combinations of these technologies, you can effectively protect your front-end Exchange servers just as well as you protect your Exchange database servers. This can allow you to create solutions that protect the security of the enterprise, while not compromising user connectivity or protection to do it.