Answers to the eight top questions to ensure a smooth, successful switch.

The features in Exchange 2010 are compelling enough for IT decision-makers to already set in motion their plans to adopt it. Requirements for those implementations depend, of course, on where you're coming from. Exchange 2007 shops are only one hop away, while those running IBM's Lotus Domino/Notes will have to consider a few more hops. All in all, the move is possible with a little help.

Here are the answers to the eight key migration questions that most IT shops will face:

1. If I'm working with Lotus Domino and want to move to Exchange 2010, what do I need to do?

First off, this is a case of migration as opposed to transitioning. Migration doesn't allow for the configuration settings to smoothly transition over as they would if you were moving from Exchange 2003 or 2007 Exchange to 2010. However, according to Henrik Walther, an Exchange Certified Master and MVP for Exchange, you could use an Exchange 2007 Server and the Microsoft Transporter Suite (a free set of migration tools for Lotus Domino) to first migrate to Exchange 2007 and then transition to 2010. The reason you can't use Transporter Suite to go directly from Domino to Exchange 2010 is that Microsoft didn't update the tool for Exchange 2010. The company says it will help third-party software developers create tools to do so.

2. Can I simply upgrade an Exchange 2007 organization to 2010 by upgrading my server in-place?

Unfortunately, no. You will need to install an Exchange 2010 server into your Exchange 2007 organisation first and then move things over. Does this mean you have to buy additional hardware? Not necessarily. If you have a virtualized environment and Exchange 2007 (which is a 64-bit app) in place, you might be able to simple install another VM with Exchange 2010 integrated into the 2007 organization. After a period of coexistence to move items over, you can drop your Exchange 2007 servers.

3. If I drop my Exchange 2007 servers, will I lose WebDAV support for Mac Entourage clients?

Entourage, which is Microsoft's Mac OS X client for Exchange, can connect to the Exchange environment using the WebDAV protocol or the POP and IMAP protocols. WebDAV provides more capabilities than POP and IMAP, which provide just basic send/receive functions; commonly, WebDAV gives Mac users access to most of Exchange's capabilities.

But Microsoft is dropping WebDAV in Exchange 2010, replacing it with Exchange Web Services (EWS), which it says will support more Exchange capabilities than WebDAV (Entourage's inferior capabilities compared to Outlook is a frequent complaint of Mac users). So you'll have to move your Mac users to the EWS-capable version of Entourage, which Microsoft recently made available for download, or switch to the forthcoming Outlook for Mac client that Microsoft says will replace Entourage next year.

You have two other options to maintain access to Exchange functionality if you're not ready to go the EWS or Mac Outlook routes: One, if your Macs run the new Snow Leopard OS, you can use the included Apple Mail client instead. Two, you can keep an Exchange 2007 server in the mix for WebDAV connectivity since Exchange 2007 and Exchange 2010 can coexist peacefully.

4. Can I have Exchange 2008 coexist with Exchange 2000 or 2003, then complete the transition to Exchange 2010 later?

Exchange 2000? No. Exchange 2003? Yes. For Exchange 2003 and 2010 to coexist, you have to change your organization to native mode on an Exchange 2003 server. What does that mean? Well, mixed-mode Exchange typically means you have Exchange 5.5 or Exchange 2000 servers intermingling with your Exchange 2003 organisation, but it is time to drop those legacy servers and become all-Exchange 2003 shop. You'll also have to switch to native mode in your Exchange 2003 servers. Only then you can begin implementing your Exchange 2010 servers for coexistence and transition.

5. What should I have in place within my Exchange 2003/2007 environment before I implement Exchange 2010?

At the bare minimum, your Exchange 2003 and 2007 servers should be running Service Pack 2. At least one Global Catalog server in each site should be running Windows Server 2003 SP2. ActiveDirectory must be in the Windows Server 2003 forest functionality mode while transitioning.

6. In what order should I deploy Exchange 2010 roles?

Installing a single Exchange 2010 server with all four major roles (the Client Access role, the Hub Transport role, the Unified Messaging Server role, and the Mailbox Server role) within the domain resolves the issue completely, no installation order necessary. However, some organisations will want to go with a more staggered approach to deployment. In that case, the order is Client Access first, then Hub Transport, then Unified Messaging Server (if applicable), and finally Mailbox Server.

There's a reason for this order: major changes in how each server role works compared to Exchange 2007. In Exchange 2010, the Client Access and Hub Transport roles are needed for the Mailbox Server role to even function, and the Exchange 2010 Mailbox Server role cannot use any other transport server besides an Exchange 2010 Hub Transport server. You will need to put at least those three roles in place, move the mailboxes over, and then (if desired) decommission those legacy roles in your organisation. Thus, you will install these server roles in parallel with your existing servers.

A solid piece of advice from the Microsoft Exchange team: If you are dealing with a multiple-site transition, start with one ActiveDirectory site at a time, beginning with your Internet-facing sites. Additionally, you should switch your host names from Exchange 2003/2007 to your new Exchange 2010 servers. Those Exchange 2010 servers will know how to handle the requests for the older versions, but the older versions will not know how to work with Exchange 2010. You will also need to provide for a legacy host name so that Exchange 2010 knows how to work with the legacy systems.

Once you have the entire structure in place, you come to the most exciting process: moving mailboxes!

7. What is an online mailbox move?

In previous transition scenarios with Exchange, moving a mailbox would temporarily take the mailbox offline, rendering it inaccessible and potentially locking users out of email for a long time. With Exchange 2010, new cmdlets (do not use the old Move-Mailbox cmdlet!) will move the mailbox without disconnecting the client, but note that users running Outlook 2003/2007 will have to restart Outlook once their mailboxes are moved.

Note:  With Exchange 2007 we used the Move-Mailbox cmdlet but in 2010 we use the Get-MoveRequest cmdlet.  In addition, it is good to note that moving mailboxes from 2003 to 2010 will not be online, those are still offline moves.

8. How should we handle the use of certificates in our Exchange environment?

The Microsoft Exchange team recommends some best practices for Exchange 2010. For example, you should use one certificate for an entire ActiveDirectory site; ideally, the same certificate can be applied to reverse proxies like ISA. The fewer certificates you have, the easier the management.

The new Subject Alternative Name (SAN) certificates allow for multiple host names within the certificate. Another important point is to create as few host names as possible -- even as little as three: one for AutoDiscover, one for Outlook Web Acess/OutlookAnywhere, and a legacy host name for coexistence.

Getting to a smooth move

The move to Exchange 2010 will no doubt be exciting, but it doesn't have to be a nightmare. Best practices and advanced planning should make for a smooth move of mailboxes and configuration settings. Obviously you might consider a third-party tool to assist in some cases (I'm a huge fan of Quest software for these types of moves), and you may want to have a consultant or team of consultants guide you through the process.

What are your plans with Exchange 2010? Are you ready to roll out and move forward? What is your method of deployment for your environment?

Follow J. Peter Bruzzese on Twitter at