SQL Server Magazine

Microsoft Exchange Server 2007 SP1 introduces a wealth of new functionality that will interest messaging system architects and administrators. Microsoft has previously differentiated between service pack releases, intended to address bugs and other minor flaws, and feature pack releases, which add significant new functionality to the base product. That definition certainly indicates that Exchange 2007 SP1 is as much a feature pack release as a service pack. Let’s take a look at the enhancements coming in SP1 and see what they might mean for your organization.

Standby Continuous Replication
Chief among the new features in SP1 is standby continuous replication (SCR). Microsoft introduced local continuous replication (LCR) and cluster continuous replication (CCR) with Exchange 2007. LCR, as its name suggests, replicates database transactions to another local disk on the same Exchange 2007 server. LCR is useful if you lose a database or the drive that hosts a database because another copy is available that’s been kept up to date by using LCR’s log shipping and replay technology, but LCR is limited because it replicates data only within the same Exchange server. In contrast, CCR provides replication of database transaction data between two nodes in a cluster. This technology is focused on high-availability and failover scenarios and obviously requires the use of Exchange clusters.

Enter SCR. This solution arguably falls somewhere between the functionality of LCR and CCR. LCR focuses more on the notion of data copying than data protection and high availability. With SCR, you can replicate database log files to another Exchange 2007 server anywhere in your Exchange organization, provided it’s in the same Active Directory (AD) domain, though it need not be in the same AD site. Therefore, SCR lets you replicate mailbox databases to locations that might be geographically remote from your source Exchange server.

SCR gives you more flexibility than LCR because the replication is off-node and more flexibility than CCR because you aren’t limited to a single Exchange cluster to host the source and target nodes of the replication. If you lose the source server with SCR, you still have a copy of the data elsewhere on your network; you can either rebuild the server and copy the data back or use the replicated mailbox data on another server and rehome affected users. You can also combine SCR with LCR or CCR technologies. A source server can have LCR enabled as well as SCR to a remote location; similarly, a source server can be a cluster member either with or without CCR enabled.

Unlike LCR and CCR, SCR lets you replicate data for a given storage group to multiple locations. So, for that really important database, you can have replicated copies of the transaction logs in several locations. Similarly, an SCR target can have multiple sources—you can designate a single Exchange server in a remote location to be the SCR target for many different source servers. Just like LCR and CCR, you can use SCR only on storage groups that contain a single database, but you can have multiple storage groups replicated using SCR. SCR requires that both the source and target servers are running SP1 and also that an SCR target can’t be running LCR. SCR doesn’t provide any automated way of failing over databases if a problem occurs on the source server. You’ll have to construct the operational procedures appropriate to how you deploy SCR within your organization.

CCR Improvements
In Exchange 2007 RTM, all transaction log copying for CCR takes place over the public network in the cluster, which can cause communication problems. For example, when the passive node comes back online after being unavailable, you can get bottlenecking due to CCR replication contending with normal client traffic. Also, if the public network fails, a failover can take place without all transaction log data being replicated, despite the data being available.

With SP1, administrators can create mixed networks to take care of log shipping. For example, you can use the internal cluster network (which usually carries just the cluster heartbeat traffic) to ship logs between servers and so avoid contention with client traffic. SP1 also brings general performance improvements for clusters, including reduction in I/O for CCR and improved clustered Mailbox server transition when using CCR.

Exchange 2007 Meets Windows Server 2008
Although Exchange 2007 RTM isn’t supported on Windows Server 2008 (previously codenamed Longhorn), SP1 is designed specifically to work with Server 2008. SP1 exploits Server 2008’s improved clustering support, enhancing Exchange 2007’s overall clustering capability.

Without SP1, Exchange 2007 clusters are supported only on Windows Server 2003 and can’t span multiple IP subnets. Add SP1 and Server 2008, and the IP subnet limitation is removed—Exchange clusters can now be geographically dispersed across separate IP subnets. This capability simplifies the creation and management of infrastructures for wide-area Exchange clustering: virtual LAN technology between remote data centers, for example, is no longer required.

This new functionality brings with it new challenges. If a Mailbox server in a wide-area cluster fails over to a node in a different IP subnet, the IP address of the Mailbox server will change even though the DNS name of the server stays the same. SP1 uses routable protocols for clusters, as opposed to the broadcaststyle protocols of pre-SP1 clusters. Therefore, clients must be able to connect to the remote failover node using DNS because the failover process dynamically updates the DNS entry for the clustered Mailbox host. For this reason, Microsoft recommends using a short Time to Live (TTL) value for clustered Mailbox DNS records. Administrators also need to pay attention to the local DNS cache on client computers; to ensure that DNS resolution takes place using valid data after a failover, you can run the Ipconfig command with the /flushdns switch on client computers. You might be able to implement this procedure with a logon script, or perhaps a desktop icon to execute the command would be appropriate.

Implementing SP1 on Server 2008 also provides messaging architects and administrators an opportunity to brush up on their IPv6 skills: IPv6 native networks are supported with Exchange 2007 SP1. However, this is a tricky area because DHCP IPv6 isn’t supported on Server 2008; only static addresses are supported. SP1 includes several new setup options for /NewCMS and /RecoverCMS relating to clustered Mailbox server configurations in both IPv4 and IPv6 environments.

OWA Gets Back What It Lost—and More
Outlook Web Access (OWA) for Exchange 2007 was completely rewritten from the version for Exchange 2003. Unfortunately, not all of the OWA 2003 features were ported to OWA 2007, due largely to time constraints. Some of these previous OWA features are returned in SP1 and some new features have been added as well.

OWA Light has been enhanced with activity monitoring so that the session isn’t timed out if, for example, it takes a long time to enter a message. Also, when messages are being composed, they’re automatically saved in the Drafts folder if the session times out because of inactivity. This is a welcome improvement for avid OWA Light users. The experience for OWA Premium users is improved as well. Users can now create and edit Personal Distribution Lists, create and edit server-side rules, and access the Recover Deleted Items feature. Users will be happy to see that access to Public Folders from the OWA Premium client is back. OWA Premium’s WebReady Document Viewing now supports Office 2007 so that these files can be viewed in HTML format. OWA Premium also adds a monthly calendar view (previously it had only daily and weekly views) and support for Secure MIME (S/MIME) for receiving and sending of signed or encrypted email.

Exchange Transport Improvements
SP1 has a range of different transport improvements that cut across core transport functionality as well as specific improvements for the Edge Transport and Hub Transport server roles. Core transport functionality has been improved specifically in the back pressure feature. This feature helps you monitor key resources such as free space on drives that hold message queue databases and transaction logs, the number of uncommitted message queue database transactions in memory, and memory utilization by EdgeTransport.exe and other system processes. With back pressure, if system resources become too heavily utilized, Exchange stops accepting new messages to prevent the server’s resources from becoming completely exhausted. The net result is that the overall stability and reliability of the Exchange system is improved. The disk space requirements for back pressure have been refined from 4GB in Exchange 2007 RTM down to 500MB in SP1. SP1 also adds additional options for configuring other transport feature settings.

Continue to the next page

   Prev. page   [1] 2     next page