Exchange Server 2010 on x64-bit
One
of the first things most organizations become aware of about Exchange
Server 2010 is that it only supports x64-bit hardware running the
Windows Server 2008 x64-bit or Windows Server 2008 x64 R2 edition
operating system. Exchange Server 2007 was also 64-bit only, but
supported Windows Server 2003 as well. This means that, during a
transition from Exchange Server 2003 to Exchange Server 2010, in-place
upgrades are not supported, and that, in many cases, new hardware is
required for the transition to Exchange Server 2010.
Most organizations
transitioning to Exchange Server 2010 have found that the transition
process between servers is relatively simple, so there hasn’t been any
major concerns transitioning from Exchange Server 2003 to Exchange
Server 2010 from one server to another. And because 64-bit Exchange
Server 2010 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 Server 2010.
Back to Just the EDB Database (STM Is Gone)
Another thing you will
notice in a transition from Exchange Server 2003 to Exchange Server 2010
is that the STM database disappears. It originally was removed with
Exchange Server 2007, and the contents of the STM databases were folded
into the traditional EDB jet database. Because the EDB database is new
and improved, you cannot mount an Exchange Server 2003 database on
Exchange Server 2010; during the transition process, if you find that
there is no STM database on your server, don’t worry that you have lost
any data.
No Routing Groups in Exchange Server 2010
Exchange Server 2010 has
also brought about the elimination of the concept of a routing group in
Exchange Server. Routing groups were used in Exchange Server 2003 to
allow Exchange Server 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
Server 2010 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 Server 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 Server 2010 and the old Exchange Server 2003
environment. During the installation of Exchange Server 2010, as it is
joined to an Exchange Server
2003 organization, the installation process prompts for the name of the
Exchange Server 2003 server from which the new Exchange Server 2010
server will route its messages to and from. The purpose of this special
routing group connector is to ensure proper mail flow between Exchange
Server 2010 and the older Exchange Server 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.
The same concept applies for the new admin group created, which is named
FYDIBOHF23SPDLT. Microsoft chose this naming convention to avoid a
naming conflict with any potential Exchange Org worldwide.
No Administrative Groups in Exchange Server 2010
In addition to having
routing groups removed in Exchange Server 2010, Microsoft has also
removed administrative groups from Exchange Server 2010. As part of the
administrative model in Exchange Server 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 Server administrators to manage the associated resources in
their group. Rather than creating a special administrative role with
resources associated with the administrative group, Exchange Server 2010
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.
No Link State Updates Required in Exchange Server 2010
Because Exchange Server
2010 no longer requires routing group connectors other than to
communicate between Exchange Server 2010 and earlier Exchange Server
2003 servers, the link state update process needs to be suppressed
during the coexistence of Exchange Server 2010 with earlier versions of
Exchange Server. Link state updates were needed in Exchange Server 2003
to establish a rerouting process if a routing group connector was down
and messages needed to be rerouted in the Exchange Server organization.
Exchange Server
2010 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.
Elimination of the Recipient Update Service (RUS) in Exchange Server 2010
Exchange
Server 2010 also eliminated the Recipient Update Service (RUS) in
Exchange Server 2003. 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 Server 2003 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 Server
2010, 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 Server 2010 and
Exchange Server 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 Server 2003/2007
to provision the RUS because the provisioning service cannot be
configured from within the Exchange Management Console or Exchange
Management Shell tools of Exchange Server 2010.
Note
Although the
Recipient Update Service (RUS) needs to be created from the Exchange
System Manager utility (found in Exchange Server 2003) for each domain
in which an Exchange server or user resides, you cannot make an Exchange
Server 2010 server the RUS. RUS will only work on an Exchange Server
2003 server system. If you create the RUS on an Exchange Server 2010
system, RUS will stop working altogether for the domain in which RUS on
the Exchange Server 2010 server was created. As a rule of thumb, RUS is
already configured and working in the existing Exchange Server 2003
environment. During the transition to Exchange Server 2010, 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 Server
2010 environment.
Coexistence in a Mixed Exchange Server Environment
During the
coexistence between Exchange Server 2003 and Exchange Server 2010, 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 Server 2010 require the administrator to go
back to the Exchange System Manager tool in Exchange Server 2003 to
perform tasks. This is why the shorter the coexistence between Exchange
Server 2003 and Exchange Server 2010, the better.
The
following list discusses some of the administrative tasks that need
consideration for environments where Exchange Server 2003, 2007, and
2010 are coexisting:
Exchange Server
2010 mailboxes must be managed with the Exchange Management Console or
Exchange Management Shell found in Exchange Server 2010. Many objects in
Exchange Server 2010 are not exposed in Exchange System Manager, and if
mailboxes are created using Exchange System Manager for an Exchange
Server 2010 user, certain objects will not be provisioned.
Mailboxes
on Exchange Server 2003 must be created using the Exchange System
Manager found in Exchange Server 2003. Just as the Exchange System
Manager doesn’t fully support Exchange Server 2010 object creation, the
creation of Exchange Server 2003 mailboxes needs the RUS process to
fully provision an Exchange Server 2003 mailbox from the Exchange System
Manager tool.
The
Exchange Management Console will successfully manage an Exchange Server
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 Server 2003 and Exchange Server 2010 (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
Server 2010 because certain components are not in the Exchange System
Manager tool to successfully complete the mailbox move process.
No Support for Certain Exchange Server 2000 and 2003 Components
Several components
in Exchange Server 2000 and 2003 are no longer supported in Exchange
Server 2010. Most of these components weren’t supported in a native
Exchange 2003 environment either, and an organization needs to take this
into consideration when transitioning to Exchange Server 2010. The
following Exchange Server 2000 and 2003 components are no longer
supported in Exchange Server 2010:
Key Management Service (KMS)
Microsoft Mobile Information Service
Exchange Instant Messaging Service
Exchange Chat Service
Exchange Server 2003 Conferencing Service
MS-Mail Connector
cc:Mail Connector
These
services do not exist in Exchange Server 2010, and an organization
requiring functionality of these services needs to keep Exchange 2000 or
2003 Servers in the organization long enough to retain the service or
replace the service with an Exchange Server 2010–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 Server 2003, even if all the users’ mailboxes have
been transitioned to Exchange Server 2010. However, services keyed to
user mailboxes, such as the Exchange Server 2003 Conferencing Service,
Chat, Instant Messaging, Mobile Information Service, or Key Management
Service, will cease to work for each user as their mailboxes are
transitioned to Exchange Server 2010.
