Executive Summary:
The release of Microsoft Exchange Server 2007 Service Pack 1 (SP1) introduces new functionality and improvements that will interest Exchange Server administrators and messaging system architects. Exchange 2007 SP1 introduces a new feature called standby continuous replication (SCR) that can replicate mailbox databases to geographically remote locations. This Exchange Server update is also supported on Windows Server 2008, and includes improvements to unified messaging (UM), Outlook Web Access (OWA), message transport, public folder management, and many other features.
|
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
Previous
Register
