This section covers what is new and what is
different with Exchange 2007, not from a product function and feature
basis, but rather how certain
changes in Exchange 2007 impact the migration process to Exchange 2007.
This includes things such as the support for only 64-bit hardware,
changes in the Exchange database structure, routing groups and
administrative groups, elimination of the use of link states, and the
removal of support for specific Exchange 2000 and Exchange 2003
components.
Exchange Server 2007 on x64-bit
One
of the first things most organizations become aware of about Exchange
2007 is that it only supports x64-bit hardware running the Windows
Server 2003 x64-bit edition operating system. At the bottom line, this means that, during a migration from Exchange
2000 or Exchange 2003 to Exchange 2007, in-place upgrades are not
supported, and that, in many cases new hardware is required for the
migration to Exchange 2007.
Most
organizations migrating to Exchange 2007 have found that the migration
process between servers is relatively simple, so there hasn’t been any
major concerns migrating from Exchange 2000 and Exchange 2003 to
Exchange 2007 from one server to another. And because 64-bit Exchange
2007 is significantly more reliable and has better performance and
scalability benefits, the requirement to forego in-place upgrades has
been far outweighed by the enhancements 64-bit has brought to Exchange
2007.
Back to Just the EDB Database (STM Is Gone)
Another
thing you will notice in a migration from Exchange 2003 to Exchange
2007 is that the STM database disappears. Not to worry, Exchange 2007
no longer has an STM database. Microsoft has gone back to a sole EDB
database for Exchange and has incorporated the benefits that the
streaming STM database brought to Exchange 2003 into the new Exchange
2007 EDB format. Because the EDB database is new and improved, you
cannot mount an Exchange 2000 or 2003 database on Exchange 2007, and
during the migration process if you find that there is no STM database
on your server, don’t worry that you have lost any data during the
migration process.
No Routing Groups in Exchange Server 2007
Exchange
2007 has also brought about the elimination of the concept of a routing
group in Exchange. Routing groups were used in Exchange 2000 and
Exchange 2003 to allow Exchange administrators to create groups of
servers that communicated with each other and to identify common routes
in which the servers in a group communicated with servers in another
group. Exchange 2007 now uses Active Directory Sites and Services to
identify subnets, where servers on the same subnet are, by default,
part of the same routing communication group, but not as a formal group
that requires specific administration or management. If an Exchange
server is moved to a different subnet, the Exchange server acknowledges
a new subnet from Active Directory Sites and Services, and associates
itself with the servers on the same subnet if they exist.
The
Hub Transport server role replaces the old Exchange 2000 and Exchange
2003 bridgehead server, and the Hub Transport server knows which
Exchange servers it is servicing by the identification of the subnets
that the Hub Transport server is configured to service. It’s much
easier to just set a table of servers and how they communicate with one
another than to create specific groups and then move the servers within
a group or between groups to meet the needs of the organization.
The
elimination of the routing group requires that a temporary routing
group connector be configured between Exchange 2007 and the old
Exchange 2000 or 2003 environment. During the installation of Exchange
2007 as it is joined to an Exchange 2000 or Exchange 2003 organization,
the installation process prompts for the name of the Exchange 2000 or
2003 server from which the new Exchange 2007 server will route its
messages to and from. The purpose of this special routing group
connector is to ensure proper mail flow between
Exchange 2007 and the older Exchange 2000 or 2003 environment. This
routing group connector shows up as “Exchange Routing Group
(DWBGZMFD01QNBJR).”
Note
Some
have asked how Microsoft came about naming the temporary routing group
connector with DWBGZMFD01QNBJR attached to the connector name. If you
advance each letter in that routing group by one letter (D becomes an
E, W becomes an X, B becomes a C, and so on), DWBGZMFD01QNBJR becomes
EXCHANGE12ROCKS.
No Administrative Groups in Exchange Server 2007
In
addition to having routing groups removed in Exchange 2007, Microsoft
has also removed administrative groups from Exchange 2007. As part of
the administrative model in Exchange 2000 and 2003, the concept of
having administrative groups was to have resources placed in the
administrative groups for easier administration and management. This
allowed certain Exchange administrators to manage the associated
resources in their group. Rather than creating a special administrative
role with resources associated with the administrative group, Exchange
2007 has done away with the administrative group and just has
administration associated with user accounts or groups, and not as a
special group to create, manage, and administer.
Just
as with the elimination of the Exchange routing group needing a
temporary routing group connector for Exchange 2000 and Exchange 2003
backward compatibility, you will find a temporary administrative group
created with the designation “Exchange Administrative Group
(FYDIBOHF23SPDLT).” For those with the magic decoder ring that advanced
each letter in the routing group connector name to come up with
EXCHANGE12ROCKS, subtract a letter for each letter in the name of the
administrative group to come up with the same name.
No Link State Updates Required in Exchange Server 2007
Because
Exchange 2007 no longer requires routing group connectors other than to
communicate between Exchange 2007 and earlier Exchange 2000 or 2003
servers, the link state update process needs to be suppressed during
the coexistence of Exchange 2007 with earlier versions of Exchange.
Link state updates were needed in Exchange 2000 and Exchange 2003 to
establish a rerouting process if a routing group connector was down and
messages needed to be rerouted in the Exchange organization.
Exchange
2007 uses Active Directory Sites and Services site links and site link
bridge information to determine the best routing communications of
messages, and it leverages Active Directory (AD) to determine the best
way to reroute messages should a link be unavailable.
During
the migration process to Exchange 2007, because the temporary routing
group connector will be established as part of the installation process
of an Exchange 2007 server, a Registry hack needs to be performed on
EVERY Exchange 2000 and Exchange 2003
server prior to migrating to Exchange 2007 to suppress link state
updates. This prevents Exchange 2000 or 2003 servers from marking the
connectors as being down, and forces Exchange 2000 and Exchange 2003
servers to use least-cost routing in the calculation of alternate
routes in message communications.
Elimination of the Recipient Update Service (RUS) in Exchange Server 2007
Exchange
2007 also eliminated the Recipient Update Service (RUS), which requires
a temporary workaround in a coexistence environment. The RUS was the
function that took a user account created in Active Directory Users and
Computers and completed the provisioning process by autogenerating the
user’s email objects such as the user’s email address. Many Exchange
2000 and 2003 administrators never understood why after creating a user
in Active Directory that many times the user’s email address wasn’t
created and sometimes it would be created. It was because Active
Directory Users and Computers was not the tool that generated the
address information—the RUS created it. Depending on how busy the RUS
was on a system, it could take a while for the email address
information to show up for a newly created user.
In
Exchange 2007, email recipients are now fully provisioned at the time a
user is created in the Exchange Management Console or from the Exchange
Management Shell. During the coexistence of an Exchange 2007 and
Exchange 2000 or 2003 environment, the RUS still needs to be created
and present for each domain that has Exchange servers and users;
however, you must use the Exchange System Manager from Exchange
2000/2003 to provision the RUS because the provisioning service cannot
be configured from within the Exchange Management Console or Exchange
Management Shell tools of Exchange 2007.
Note
Although
the Recipient Update Service (RUS) needs to be created from the
Exchange System Manager utility (found in Exchange 2000/2003) for each
domain that an Exchange server or user resides, you cannot make an
Exchange 2007 server the RUS. RUS will only work on an Exchange 2000 or
2003 server system. If you create the RUS on an Exchange 2007 system,
RUS will stop working altogether for the domain in which RUS on the
Exchange 2007 server was created. As a rule of thumb, RUS is already
configured and working in the existing Exchange 2000 or 2003
environment. During the migration to Exchange 2007, keep the RUS
server(s) in each domain operating and only remove those servers in
each domain as the cleanup process to go to a native Exchange 2007
environment.
Managing a Coexisting Environment
During
the coexistence between Exchange 2000 or 2003 and Exchange 2007, an
administrator needs to be mindful which administration tool to use for
which function. This is a confusing task because many functions that no
longer exist in Exchange 2007 require the administrator to go back to
the Exchange System Manager tool in Exchange 2000 or 2003 to perform tasks. This is why the shorter the coexistence between Exchange 2000 or 2003 and Exchange 2007, the better.
The
following list discusses some of the administrative tasks that need
consideration for environments where Exchange 2000, 2003, and 2007 are
coexisting:
Exchange 2007
mailboxes must be managed with the Exchange Management Console found in
Exchange 2007. Many objects in Exchange 2007 are not exposed in
Exchange 2003, and if mailboxes are created in Exchange 2003 for an
Exchange 2007 user, certain objects will not be provisioned.
Mailboxes
on Exchange 2003 must be created using the Exchange System Manager
found in Exchange 2003. Just as the Exchange System Manager doesn’t
fully support Exchange 2007 object creation, the creation of Exchange
2003 mailboxes needs the RUS process to fully provision an Exchange
2003 mailbox from the Exchange System Manager tool.
The
Exchange Management Console will successfully manage an Exchange 2003
mailbox. So, as long as the mailbox has been created with the Exchange
System Manager tool, thereafter the mailbox can be managed or
administered from either tool.
Moving
mailboxes between Exchange 2003 and 2007 (either way) must be done with
the Exchange Management Console tool. Do not use the Exchange System
Manager tool to move mailboxes to or from Exchange 2007 because certain
components are not in the Exchange System Manager tool to successfully
complete the mailbox move process.
No Support for Certain Exchange 2000 Server Components
Several
components in Exchange 2000 are no longer supported in Exchange 2007.
Most of these components weren’t supported in a native Exchange 2003
environment either, and an organization needs to take this into
consideration when migrating to Exchange 2007. The following Exchange
2000 components are no longer supported in Exchange 2007:
Key Management Service (KMS)
Microsoft Mobile Information Service
Exchange Instant Messaging Service
Exchange Chat Service
Exchange 2000 Conferencing Service
MS-Mail Connector
cc:Mail Connector
These
services do not exist in Exchange 2007 and an organization requiring
functionality of these services needs to keep Exchange 2000 servers in
the organization long enough to retain the service or replace the
service with an Exchange 2007–supported equivalent service.
For
services such as the MS-Mail Connector and cc:Mail Connector, those
services can run for a while on an Exchange 2000 server even if all of
the users’ mailboxes have been migrated to Exchange 2007. However,
services keyed to user mailboxes, such as the Exchange 2000
Conferencing Service, Chat, Instant Messaging, Mobile Information
Service, or Key Management Service, will cease to work for each user as
their mailboxes are migrated to Exchange 2007.
The following are current services that are not supported by Microsoft Exchange 2007:
Key Management Service (KMS)— Use Active Directory autoenrollment of certificates and issue certificates to users for encrypted email communications.
Microsoft Mobile Information Service—
Exchange 2003 and Exchange 2007 support mobile devices directly within
the Exchange environment and no longer require the separate Microsoft
Mobile Information Service to support mobile users.
Exchange Instant Messaging Service—
Instant messaging moved to Microsoft Live Communications Server 2003
and 2005 with Exchange 2003, and is now Office Communications Server
2007 that is compatible with Exchange 2007.
Exchange Chat Service— Chat has also been integrated into Office Communications Server 2007.
Exchange 2000 Conferencing Service— Conferencing is also a core component of Office Communications Server 2007.
MS-Mail Connector— There is no equivalent support for a connector to MS-Mail in Exchange 2007.
cc:Mail Connector— There is no equivalent support for a connector to cc:Mail in Exchange 2007.
No Support for Certain Exchange Server 2003 Components
Those
migrating from Exchange 2003 to Exchange 2007 will notice that the
Novell GroupWise Connector is no longer supported in Exchange 2007. If
the organization requires continued support of Exchange-to-GroupWise
connectivity, the organization should keep at least one Exchange 2003
server in the organization running the Novell GroupWise Connector for
Exchange. This will keep mail flow and synchronization operating
between the environments.
