You won't be too surprised to hear that there are a lot of differences between Exchange Server 2003 and Exchange Server 2010. The most important are:
Exchange Server 2010 is available only in a 64-bit version.
Exchange Server 2010 does not use Administrative Groups for delegation of control.
Exchange Server 2010 does not use Routing Groups for routing messages.
Exchange Server 2010 does not use Link State Routing for updating the routing table.
Exchange Server 2010 does not use the Recipient Update Service for setting Exchange properties on recipient objects.
This is a much more extensive
list than the differences with Exchange Server 2007, and the
differences themselves are also more significant. Just to make sure
everyone is on the same proverbial page as I go through this, I'll lay
down a little background information on each of these legacy systems
(e.g. Administrative Groups) before I explain what's changed.
1 64-bit support
Exchange Server 2010 is
only available in a 64-bit version, as the Exchange Product Group at
Microsoft is taking full advantage of the hardware advances since
Exchange Server 2007 was released. The current 32-bit (X86) platform was
developed in the mid-eighties, and has a 4 GB memory limit. In those
days, 4 GB of memory was beyond everyone's imagination. Today, 4 GB of
memory is commonly installed in a laptop.
As the successor of the
32-bit platform, one of the clear advantages of 64-bit is a theoretical
memory limit of 2^64 bytes, or 16 PB (Petabytes). Windows obviously
cannot address this amount of memory at this time, but the current
memory limit of Windows Server 2008 R2 Enterprise is 2 TB (Terabytes).
Naturally, current processors just cannot address anything like that
much physical memory, but Moore's law and the inexorable march of
technological progress mean that this limit will keep being pushed back
in the future.
Whilst 4 GB of memory might be
enough for a laptop or workstation, for large server applications like
Exchange server, a mere 4 GB of memory is a huge limitation. A fact
which can be clearly illustrated in Exchange Server 2003, when having
more than 2,000 mailboxes on one Exchange server will result in a severe
disk I/O penalty, which typically results in an expensive storage
solution.
There are special
techniques for addressing more than 4 GB of memory on the 32-bit
platform, like Physical Address Extensions (PAE), which you can read
more about here:
HTTP://TINYURL.COM/32BITPAE
However, Exchange Server 2003
does not use this technique, and so is stuck with the 4 GB memory limit
(and you can read more about that here: HTTP://TINYURL.COM/2003LIMIT).
Given that Exchange server 2010 is 64-bit only, this automatically
implies that an in-place upgrade of Exchange Server 2003 server to
Exchange Server 2010 is impossible. A new Exchange Server 2010 server in
a 2003 environment always needs to be installed on separate hardware.
I'll mention briefly now that the same is true for Exchange Server 2007;
although it is also a 64-bit application, Microsoft does not support an
in-place upgrade due to technical complexity in both products.
2 Administrative Groups are no longer used for delegation of control
Exchange Server 2003 uses
Administrative Groups for delegation of control, allowing you to create
multiple Administrative Groups and delegate control of them to different
administrators. For example, a large multinational company could create
multiple Administrative Groups, one for each country, and each country
could have its own Exchange administration department, responsible for
maintaining their local Exchange servers. This could be achieved by
delegating control of the appropriate Administrative Group to specific
Universal Security Groups, which these Exchange administrators are, in
turn, assigned to. This sounds pretty complicated, and after seeing such
a scenario in real life, I can assure you that it is
complicated. And besides being complicated, it is prone to error and
I've seen it bring a world-wide deployment to its knees. It's a good
thing Microsoft is not continuing this path!
Exchange Server 2010 does not use Administrative Groups any more. During installation of the first Exchange Server 2010 server, a new Administrative Group will be created in Active Directory, called "Exchange Administrative Group (FYDIBOHF23SPDLT)."
All subsequent servers will be installed in this Administrative Group.
Delegation of control in Exchange Server 2010 is achieved by
implementing a Role Based Access (RBAC) model.
3 Routing Groups are no longer used for routing messages
For routing messages
between different locations, Exchange Server 2003 uses a concept called
Routing Groups. A Routing Group can be identified as a location with a
high bandwidth and low latency network, such as an office with a 100
Mbps internal network where all Exchange Server 2003 servers have full
access to each other all the time. When multiple locations are present,
each has their own Routing Group, and each Routing Group is connected
with each other using "slow links." These Routing Groups in an Exchange
organization are connected using Routing Group Connectors, and so
Routing Groups are very similar to Sites in Active Directory. Active
Directory sites have already existed since Windows 2000 Active
Directory, but Exchange Server 2003 just didn't use them and relied on
their own mechanism. And to be honest, this really didn't make sense.
Instead of Routing
Groups, Exchange Server 2010 now uses Active Directory sites to route
messages to Exchange servers in other locations. To connect Exchange
Server 2010 with an Exchange Server 2003 environment in the same Active
Directory forest (and thus the same Exchange organization), a special
Routing Group, called "Exchange Routing Group (DWBGZMFD01QNBJR)"
will be created during the installation of the first Exchange Server
2010 server. A special Interop Routing Group Connector will also be
created during the setup of that initial server, in order to route
messages between Exchange Server 2003 and Exchange Server 2010.
It's also worth bearing in
mind that since Exchange Server 2010 uses Active Directory sites for
routing SMTP messages, every site that contains an Exchange Server 2010
Mailbox Server role will also need an Exchange Server 2010 Hub Transport
Server role to be installed.
4 Link State Routing is no longer used for updating the routing table
To keep routing information up to date in Exchange Server 2003, a process called Link State
is used. When a connector in Exchange Server 2003 changes its state,
the Routing Table used by the Routing Group connectors is updated, and
this Routing Table is sent immediately to other Exchange servers in the
same Routing Group. When an Exchange Server 2003 server initiates an
SMTP connection to a similar server in another Routing Group, the
Routing Tables on both servers are compared and, if needed, the newer
version of the Routing Table is sent to the other server.
This works fine as long as
the Routing Table is not very large, but there are known cases, with
over 75 Routing Groups and hundreds of Routing Group Connectors, where
the Routing Table was between 750KB and 1MB in size. It might not sound
like much, but when a Routing Table is being exchanged frequently, this
will have a noticeable negative impact on the network traffic across the
WAN.
NOTE
More
information regarding message routing in Exchange Server 2003 can be
found in the "Exchange Server Transport and Routing Guide" which is on
the Microsoft TechNet site: HTTP://TINYURL.COM/ROUTINGGUIDE. When
you want to take a closer look at the routing table in your own
Exchange Server 2003 environment, you can download the WinRoute tool
from the Microsoft website: HTTP://TINYURL.COM/WINROUTE.
Exchange Server 2010 has
replaced this whole system with Active Directory Site Links (as
explained above) and thus leverages Active Directory information to
determine an alternate route when a specific link is no longer
available. Before installing the first Exchange Server 2010 server into
an existing Exchange Server 2003 environment, Link State Updates need to be suppressed to avoid routing conflicts between the Exchange versions.
5 Recipient Update Service versus Email Address Policies
The Recipient Update Service
(RUS) in Exchange Server 2003 is the service that is responsible for
updating the Exchange specific properties of Exchange recipients in
Active Directory. When a user is created with Active Directory Users and
Computers, the RUS will pick up the user account and "stamp" it with
Exchange specific attributes, such as the homeserver, homeMTA, homeMDB
and email addresses. It can take some time for a user to be fully
provisioned and available, especially on busy servers. The Service is
part of the System Attendant, and only one instance is running in each
Active Directory domain.
Exchange Server 2010 does not
use the Recipient Update Service anymore, but uses Email Address
Policies instead. When a mailbox-enabled user is created, an Email
Address Policy is applied immediately, and the mailbox is therefore
available instantly, though of course the user object needs to be
replicated between all Domain Controllers in your environment to be
fully available at all locations. In a coexistence scenario, the
Recipient Update Service and the accompanying Recipient Policies can
only be managed from the Exchange Server 2003 System Manager, and the
Exchange Server 2010 Address List Policies can only be managed from the
Exchange Management Console or the Exchange Management Shell. The only
time a Recipient Policy is accessed using the Exchange Management Shell
is when upgrading the Recipient Policy to an Email Address Policy.
