Exchange Server 2007 is looming on the horizon. Beta versions are already in customers' hands, and Microsoft is on track to deliver the final version in early to mid 2007. As the software matures and we get more time to play with the new architecture and features, you should be reviewing your current deployment to determine what steps you need to take to prepare for a migration. This migration might not take place anytime soon—perhaps you feel it's best to first let the bugs shake out of any new Microsoft product release. However, even if you wait until the first Exchange 2007 service pack, you'll be upgrading in late 2007 or early 2008.
Perhaps you're still saying to yourself, "I've got plenty of time!" However, given the fundamental nature of some of the changes in Exchange 2007—for example, the move to an exclusive 64-bit platform (x64 only; Exchange 2007 won't support IA64)— starting your planning process as soon as possible is a good idea. And to begin planning, you need to concentrate on several key concerns, including mapping out your migration project, understanding the ramifications of 64-bit Exchange, streamlining your routing topology, and preparing for Windows PowerShell.
Seeking Perfection
As you set out to review your infrastructure, realize that no one has a perfect
Exchange 2003 or Exchange 2000 deployment—or for that matter, a perfect
Windows Server 2003 deployment. It's difficult to define "perfect" in this context
because best practices change as software evolves, new tools become available
for tuning your implementation, and commercial requirements and pressures vary
from company to company. Many argue that Microsoft's view of a perfect Exchange
2003 deployment is biased toward the company's own internal deployment. Not
many people will ever attempt to deploy the kind of huge Exchange mailbox clusters
that Microsoft runs in its Redmond datacenter. Not many companies have the combined
resources of the Windows and Exchange development teams to call upon if things
go wrong in the cluster. Everyone has a different definition of perfection,
so I suggest you don't even aspire to it. Instead, learn as much as you can
from what others have learned in other companies, then create your own best
practices within the context of your own company.
You also need to consider that Microsoft has made it much easier to analyze and tune deployments through the introduction of tools such as the Exchange Server Best Practices Analyzer (ExBPA). You can use ExBPA to compare information from one or more of your servers with data that Microsoft considers to represent best practice. Running ExBPA is a good first step to start your deployment review because ExBPA can identify obvious flaws that you need to address to improve the stability of your infrastructure. However, remember that you know more about your Exchange servers than any automated tool can discover, so be sure to treat ExBPA's recommendations as advice rather than absolute instructions.
For updates to the rule set that ExBPA uses, keep an eye on the Microsoft Exchange Analyzers site. (To learn how to get there, see the Learning Path.) Microsoft will be releasing new versions to help customers prepare for Exchange 2007. ExBPA always offers the option to update the rule set that it depends on to analyze systems, so you can expect an updated ExBPA to locate any obvious problems that you need to solve before you can move to Exchange 2007.
Thinking About Migration
After you're sure your current Exchange deployment is on a firm foundation,
you can start thinking about what you need to do to move to Exchange 2007. You
can break your Exchange 2007 migration project into four stages: discover, analyze,
decide, and execute.
Discover. How many servers are you using for Exchange and for supporting the Exchange ecosystem (e.g., antispam, antivirus, backup servers, DHCP, Global Catalog—GC, WINS)? Where are the servers located, and how many mailboxes are supported? Do you have specific reasons (e.g., network availability) for placing servers in particular locations? Are you running any products that Exchange 2007 won't support, initially or ever?
Analyze. Considering the changes in the Exchange 2007 architecture and the 64-bit version of Windows, what changes do you need to make to improve or simplify your infrastructure? For example, can you consolidate to a smaller set of servers? You should also review the major areas of functionality that Microsoft is addressing in Exchange 2007 and decide whether these areas are important to you. For example, Exchange 2007 boasts better and more integrated mail-hygiene capabilities, so how will this improvement affect your existing antispam and antivirus protection?
Decide. Lay out the plan to introduce Exchange 2007 to the organization. Know how you'll bring new servers in, what servers they'll replace, what servers will remain and be repurposed, what applications need to be upgraded (and to what version), and when the work will be done. For example, Microsoft will release a new Outlook 2007 client that will be the premier Exchange 2007 client. You'll want to review the Microsoft Office 2007 suite and consider the costs of upgrading.
Execute. The most important advice I can give you is to not focus just on Exchange. Focus on the big picture, which includes all the moving parts that you need to coordinate for a successful migration, including server and storage hardware, training, third-party software, support staff, operational procedures, and clients (including handheld devices).
Breaking things down into modular steps is a good way to approach any complex project. However, to really attack the problem, you need to understand some details about the changes in Exchange 2007, so let's take a look at the most important changes that Microsoft is making in this release.
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.
Getting Used to the Shell
PowerShell previously code-named Monad is a powerful command-line and scripting interface that provides a single way to automate management operations on the Windows platform. Microsoft has taken the opportunity to clean up the horrible mess of APIs (not all of which are fully documented or even publicly documented) that it has used in previous versions of Exchange to perform management activities. For example, on Exchange 2003 and Exchange 2000 servers, you had to use a mixture of APIs to automate management operations. In an Exchange 2007 environment, you drop all the old APIs and use a set of PowerShell cmdlets. (Pronounced command-lets, cmdlets are prepackaged commands for performing specific functions, such as creating a new mailbox.) In fact, Microsoft built the Exchange 2007 management framework, including the new version of the Exchange System Manager console (called the Exchange 2007 Management Console), from PowerShell cmdlets.
You don't have to wait for Exchange 2007 to learn PowerShell: It's available for Windows 2003 today. You might not be able to manage Exchange servers, but you'll be able to learn the language and learn how to create scripts that get real work done. When you install Exchange 2007 on a server, the installation procedure adds all the new Power-Shell verbs to work with Exchange and you can then upgrade your knowledge to work with Exchange. For more information about PowerShell, see the Learning Path.
Preparing on Other Fronts
Apart from the software products that obviously support Exchange, such as antivirus packages, there are new versions of other products that you might need to take into account as you plan your Exchange 2007 deployment. For example, Microsoft is about to release Office 2007, which includes a new version of Outlook. You need to test Outlook 2007 to justify the upgrade and deployment costs. The feature I like best about Outlook 2007 is the client's ability to use an Exchange-provided Web service called AutoDiscovery to consult AD to find out which server a user's mailbox is located on—thereby reducing the potential for error when users set up Outlook.
Many companies consider Microsoft SharePoint Portal Server as the natural replacement for Exchange public folders, which Microsoft plans to phase out in the next major release of Exchange following Exchange 2007—perhaps three or four years from now. One forward-thinking pointer is that the Exchange 2007 Management Console offers no way to manage public folders; you have to manage them through PowerShell or with an Exchange 2003 server. So now is the time to figure out your replacement strategy for public folders. A new SharePoint version is on the horizon, so should you incorporate this release and an upgrade for SQL Server, which provides the database for Share-Point, into your overall server upgrade and refresh plan? Perhaps you've deployed Live Communication Server—something else to consider.
My point is that the Exchange ecosystem is more than just the products that are immediately associated with messaging. To ensure that all the necessary moving parts mesh together, you need to take a holistic approach to your Exchange 2007 upgrade project.
Training
Even if have 10 years Exchange experience, you'll find that Exchange 2007 has a significant learning curve. The introduction of PowerShell and its power scripting capabilities brings a lot to the table, but so does tuning the 64-bit platform, ensuring that routing works well across your Windows sites, learning how best to coexist with legacy Exchange servers, coordinating upgrades in large organizations, and so on. I recommend signing up for the Exchange 2007 beta and deploying it on some servers, just to play with some of the new features, such as the scheduling assistant (a feature that should have been in Exchange a long time ago). For information about obtaining the beta release, see the Learning Path.
Even if you devote some time to playing with the Exchange 2007 beta, some training will be necessary, so be sure to sign up for some classes or attend some conferences to upgrade your knowledge, learn about best practice, and share your experience with other administrators.
Just Do It
Since 1996, Microsoft has released new versions of Exchange every few years, so dealing with an upgrade isn't a new challenge. Every upgrade has its quirks. The major changes in Exchange 2007 are its move to the 64-bit platform, the change to the routing subsystem, and a new scripting and management automation capability. The new Unified Messaging (UM) capability might also be an attractive selling point, as I discuss in the sidebar, "Talking with Exchange UM." As long as you're prepared for the upgrade, Exchange 2007 will be a straightforward installation—and now is a great time to start.