64-Bit Hardware
The big Exchange 2007 change is its move to a 64-bit software platform. Microsoft believes that moving Exchange to the 64-bit platform will deliver better scalability in terms of the number of mailboxes supported per server, better ability to deal with large mailboxes and messages, and a reduction in the demand for expensive I/O as Exchange caches more data in the expanded memory address space. The move will also address some virtual-memory fragmentation problems that Microsoft has experienced in large-scale Exchange 2003 deployments (particularly with clustered servers).
To make all this happen, you need to deploy Windows 2003 (preferably Release 2—R2) and Exchange 2007 on 64-bit hardware. You won't be able to upgrade an existing server running Windows 2003 and Exchange 2003 to the new platform, even if you run this software on a server equipped with a 64-bit capable CPU (e.g., the AMD Opteron, the Intel EMD64T). Microsoft won't support in-place upgrades because of the complexity of such operations, so you'll have to deploy new servers, install Exchange 2007, then use the Move Mailbox function to migrate users. The disadvantage of this approach is the need for new hardware, but if you align your Exchange 2007 migration with your server-hardware replacement cycle, you can minimize the cost impact. The good news is that Microsoft has significantly upgraded Exchange's Move Mailbox feature in Exchange 2007 to make it easier to move mailboxes between servers, including the ability to use PowerShell scripts to automate moves.
Because Exchange works inside an ecosystem that includes Exchange-supporting third-party software (e.g., antivirus and antispam products, backup software, products that analyze message-tracking logs, management frameworks such as HP Open-View), the move to a 64-bit platform involves more than Windows and Exchange. You need all this software to support Exchange 2007, so I recommend contacting your software suppliers to determine when they'll have upgraded products ready. For more information about the ramifications of 64-bit Exchange 2007, see the Learning Path.
Windows and Routing
Until now, Windows sites have essentially been a convenient collection point for workstations. From an Exchange perspective, you needed to be concerned only with the allocation of GC servers to sites that support Exchange servers. The Exchange 2007 transport subsystem drops the routing groups that Exchange 2003 and Exchange 2000 use and instead uses Windows sites as the basis for SMTP routing. A Windows site is defined as one or more IP subnets, so it makes sense to route SMTP messages across an IP network by using sites as the routing topology.
As a side effect, Exchange 2007 also drops the link-state routing update messages that Exchange 2003 and Exchange 2000 servers circulate among routing groups to keep the routing topology aware of network problems. Link-state updates seemed great when Microsoft introduced them in Exchange 2000. However, the first Exchange 2000 deployments occurred in reasonably stable corporate networks. No one really knew what could happen in an unstable hub-and-spoke network: Update messages flooded the network with information and compounded the problem that unstable links caused.
When you laid out sites within your Active Directory (AD) design, you probably didn't consider the possibility that Microsoft might decide to use sites as the basis for mail routing. It's also possible that you haven't reviewed your AD design since you first deployed Windows 2000, so now is a good time to break out the design documents and give your site layout a critical look. You also need to consider any evolution that has occurred in your network infrastructure since you implemented the original AD design—for example, new or higher-capacity links or a move from a hub-and-spoke network to a fully connected mesh. Obviously, you want to be sure that AD replication continues to work reliably, but you also want to ensure that sites connect in a way that lets messages flow between them efficiently. Only sites that host Exchange 2007 bridgehead servers will participate in email routing, and these sites will also host at least one GC server to help Exchange route messages to servers, validate email addresses, resolve query-based distribution groups, expand the content of distribution groups, and so on.
Although Exchange 2007 uses AD sites as the basis for its routing topology, there isn't a one-to-one mapping between sites and the topology. Only AD sites that have a bridgehead server participate in the routing topology, so that's an immediate point to consider while you review your existing Exchange 2003 routing topology. Look at the AD site layout and map it against the Exchange 2003 routing group structure to determine whether the two are comparable (or compatible). This review will let you determine whether any changes are necessary, such as whether an AD site needs to host a bridgehead server so that messages can flow through the site. You also need to be sure that all Exchange mailbox servers will have access to bridgehead servers to route their messages. During the same review, try simplifying the routing topology as much as possible: It's possible that an ineffective topology has evolved and hasn't been touched since you first designed your Exchange 2003 or Exchange 2000 topology.
Apart from changing the basis of the routing topology from routing groups to Windows sites, Microsoft has used the .NET Framework to rewrite the Exchange 2007 transport engine to make it simpler and let it process messages faster. A side effect of this change is that any transport event sinks that you developed for Exchange 2003 or Exchange 2000 will no longer work. For example, to comply with legislation, some financial companies developed code that prevented messages from passing from one part of the company to another. Because event sinks aren't a well-known aspect of coding, that code probably took considerable effort to develop. Microsoft promises that Exchange 2007 will be much easier to use as a development platform because it's based on the .NET Framework. As welcome as this evolution is, you'll still have to assess whether you need to redevelop your code to work with Exchange 2007.
