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.
Previous
