#8: Be Ready to Recover
Most companies have a solid backup strategy in place and do a great job backing up Exchange server data. However, many companies' backup plans are designed to meet business and recovery requirements that are several years old (and thus outdated). Business requirements change over time, so if you're working on a design that refreshes (rather than launches) an Exchange organization, be sure to review the existing backup policies to ensure that they meet current business needs. Be sure to include restore times as a part of the decision. In most circumstances, the time needed to restore Exchange is more important than the time needed to back up Exchange.
Specify that test restores are to be performed as part of a regularly scheduled, proactive process. Backing up an Exchange server involves both software and hardware technology, one or both of which can fail from time to time. Performing regular test restores will provide a greater chance of a successful real-life restore and will ensure that administrators know how to restore Exchange data after a disaster.
Exchange 2000 introduced multiple SGs and databases; Exchange 2003 added the Recovery SG (RSG). These enhancements brought us more decision points in meeting Exchange recovery requirements. Multiple recovery points now exist within a single Exchange 2003 server that hosts mailboxes, and you must ensure that your backup methodology addresses each one. The most common recovery scenarios are
- restoring a single item or mailbox,
- restoring a single database,
- restoring multiple SGs and databases on one server,
- performing a Messaging Dial Tone recovery (typically for a corrupted database), and
- performing a total server recovery (i.e., bare metal recovery).
Which of these considerations will apply to your design will vary depending on the company's recovery requirements. What was considered a disaster for an Exchange Server 5.5 system is often a simple restore of a single database in Exchange 2003.
The new functionality of the RSG, along with disk-to-disk backups, has allowed some Exchange environments to implement a simplified backup-and-restore strategy that uses only NTBackup. Like other backup products, NTBackup can be used to back up an Exchange server by using a disk-to-disk then disk-to-tape process (the entire process is referred to as disk-disk-tape). This simplified implementation has many benefits:
- disk-to-disk backups can use less-expensive, slower disks as backup (or secondary) disks
- disk-to-tape lets you roll the offline backup to tape or other offline media at your convenience
- this implementation requires less-expensive hardware
- this implementation requires less software on Exchange servers
- this implementation requires a less-complicated environment to support and administer
- restores that use disk-to-disk backups can be completed remotely, without physically mounting a tape
Ultimately, service level agreements (SLAs) determine the appropriate backup strategy. With new and updated features in Exchange 2003, businesses have many configuration options available to meet their Exchange backup, restore, and disaster-recovery requirements while still allowing an easily supported Exchange environment. Evaluate these options carefully during the design process.
#9: Secure Internet Connectivity
With Exchange now qualifying as a mission-critical application for most companies, you need to give serious consideration to the implementation of Internet-facing services such as SMTP relay servers, antivirus servers, content filtering, and firewall options such as Microsoft Internet Security and Acceleration (ISA) Server 2004. As I mentioned earlier, placing antivirus, antispam, and content-filtering services in the perimeter network protects your Exchange infrastructure from unwanted traffic and adds a security barrier between the bad guys and your Exchange infrastructure. Administrators sometimes believe they've secured the Exchange environment simply by placing an SMTP relay server in the perimeter network or by forwarding ports 25, 80, and 443 through firewalls to the Exchange servers on the internal network. Not so.
The best protection I've found is the installation of an ISA Server solution in the perimeter network. It took me awhile to say "Microsoft" and "firewall" in the same breath, but I have to admit that Microsoft has done a great job designing ISA Server to protect the Exchange environment. ISA Server completely authenticates OWA users before letting them on the internal network, inspects every email before delivering it to Exchange, and provides another level of security for Remote Procedure Call (RPC) over HTTP, to name just a few features. These capabilities alone make ISA Server worth consideration.
#10: Take Advantage of ExBPA
No discussion of successful Exchange design would be complete without a mention of the Exchange Server Best Practices Analyzer Tool (ExBPA). Running ExBPA after the installation and configuration of an Exchange server usually finds configuration parameters that have been missed or that should be reviewed. Running the tool at different times can produce different recommendations. For example, running ExBPA when only a few mailboxes are on a new Exchange mailbox server will produce one set of recommendations; running the tool again after adding several hundred or thousand mailboxes will produce an updated set of recommendations that take the new load into consideration. ExBPA provides an easy-to-read report along with working links that provide quality verbose information. I recommend that your design specify a regularly scheduled run of this tool on all Exchange servers. You can download the most recent ExBPA version at http://www.microsoft.com/exchange/downloads/2003/exbpa.
The Benefits of Good Design
Every Exchange installation is different and requires a unique solution that's tailored to fit the company's business requirements. Those requirements will change over time, as will available hardware and software features. Common sense is still the best weapon in the fight against an overly complex Exchange environment. A key architectural question is, "What is the business benefit from the technical decision being implemented?" Asking that question at every step and remembering the four key architectural principles of simplicity, integration, cost, and efficiency will help ensure the success of any Exchange design.
Mark England (mark.d.england@hp .com) is a senior solutions architect in HP's Americas Messaging Team. His focus is on complex messaging architecture and design. Mark is a frequent speaker at industry events and is a contributor to Exchange & Outlook Administrator and Windows IT Pro.
End of Article
Prev. page
1
[2]
next page -->
