562 Networks

Since Exchange 2010 is similar if not almost identical to Exchange 2007 in terms of server roles (CAS, Hub Transport, Mailbox, Edge), if you implemented Exchange 2007 in a manner that suits the needs of your organization, then your transition to Exchange 2010 will be pretty straight forward. Effectively, you would add Exchange 2010 server roles to mirror the Exchange 2007 server roles you have today (ie: if you have 2 CAS/2007 servers today, you’d likely build up 2 CAS/2010 servers in the Exchange 2010 environment, etc).

The sequence for a migration from Exchange 2007 to Exchange 2010 is as follows:

Upgrade all Exchange Servers to Exchange Server 2007 Service Pack 2.
Bring the AD forest and domains to Windows Server 2003 Functional (or higher) levels.
Upgrade at least one Global Catalog domain controller in each AD Site that will house Exchange Server to Windows Server 2003 SP2 or greater.
Prepare a Windows Server 2008 (RTM or R2) x64 edition server for the first Exchange 2010 server.
Install the AD LDIFDE tools on the new Exchange 2010 server (to upgrade the schema).
Install any necessary prerequisites (WWW for CAS server role).
Run setup on the Exchange 2010 server, upgrade the schema, and prepare the forest and domains. (Setup runs all in one step or separate at the command line.)
Install CAS server role servers and configure per 2010 design. Validate function-ality.
Transfer OWA, ActiveSync, and Outlook Anywhere traffic to new CAS servers.
Install Hub Transport role and configure per 2010 design.
Transfer inbound and outbound mail traffic to the 2010 HT servers.
Install Mailbox servers and configure Databases (DAG if needed).
Create public folder replicas on Exchange 2010 servers using AddReplicatoPFRe-cursive.ps1or Exchange 2010 Public Folder tool.
Move mailboxes to Exchange 2010 using Move Mailbox Wizard or Powershell.
Rehome the Offline Address Book (OAB) generation server to Exchange Server 2010.
Transfer all Public Folder Replicas to Exchange Server 2010 Public folder store(s).
Delete Public and Private Information Stores from Exchange 2007 server(s).
Uninstall all Exchange 2007 servers.
One of the areas of change that you’ll make with your transition to Exchange 2010 that is different than in your Exchange 2007 implementation is the high availability and disaster recovery functions of your Mailbox server role. Because the concepts of Single Copy Clusters, Cluster Continous Replication (CCR), and Standby Continous Replicaton (SCR) no longer exist in Exchange 2010, you’ll be transitioning your mailboxes off of Exchange 2007 that has these functions to Exchange 2010 that users Database Availability Groups (DAGs). Of course if you are just migrating to a single Exchange 2010 Mailbox server with no high availability or disaster recovery, then you will just have mailbox databases that you’ll be moving your mailboxes to. However for organizations implementing high availability and disaster recovery, the DAGs provide replication of mail (of up 16 copies) from server to server. When you setup your Exchange 2010 Mailbox servers to prepare them for the transition of mailboxes, setup your DAG replication and test your failover and failback of Exchange 2010 Mailbox servers, and then move your mailboxes to the DAG(s).

Another area of change between Exchange 2007 and Exchange 2010 is that ALL client connections go through the CAS server(s). Unlike Exchange 2007 and prior where OWA connections went through the CAS server but Outlook (2003/2007) connections actually communicated directly over MAPI to the backend Mailbox servers. However with Exchange 2010, client systems no longer communicate directly to the backend Mailbox servers. Instead, the client MAPI connections hit the CAS server(s) that then communicate with the Mailbox servers on the backend. So just like in the shift to Hub Transport servers in Exchange 2007 where all mail routes through the Hub Transport servers (incoming mail, outgoing mail, user to user mail between servers, and even user to user mail between users on the same server), with Exchange 2010, all clients go through the CAS server(s). As such, the CAS servers take on more of a performance load and need to be beefed up a little. Our recommendations for CAS to Mailbox in Exchange 2007 was 1 CAS servers for every 2 Mailbox servers. For Exchange 2010, our recommendation is now 3 CAS servers for every 4 Mailbox servers. Most organizations have at least 2 CAS servers in their environment for redundancy, and because you can virtualize the CAS role plus have 2000, 3000, even 5000 mailboxes on a single Mailbox server, we typically find this 3:4 CAS:MBX ratio hasn’t been a showstopper for organizations in terms of a design change.

Also important to note is that all 2007 server roles (CAS, Hub Transport, Mailbox) in Exchange 2007 need to remain until all users are migrated to Exchange 2010. Exchange 2010 CAS, Hub Transport, and Mailbox servers are not backwards compatible with Exchange 2007, so in order for a user to access Outlook Web Access on Exchange 2007, they need to still hit the Exchange 2007 CAS servers to access their mailbox on the Exchange 2007 Mailbox server. After their mailbox is migrated to Exchange 2010, then the user will hit the Exchange 2010 CAS server and access their mailbox on the Exchange 2010 Mailbox server. Because Exchange 2010 has a proxy service on the CAS server, your external URL for OWA can point to the Exchange 2010 CAS server and if the user’s mailbox is still on Exchange 2007, the CAS/2010 server will automatically redirect the client connection to the CAS/2007 server for OWA.

Lastly, after moving mailboxes off of Exchange 2007 to Exchange 2010, leave the Exchange 2007 infrastructure in place for a couple (2) weeks. By leaving the old Exchange 2007 server(s) in place, when an Outlook client tries to connect to the old Exchange 2007 server for its mail, the old Exchange 2007 server will notify the Outlook client software that the user’s mail has been moved to the Exchange 2010 server and will automatically update the user’s Outlook profile with the new destination server information. Thereafter, when the Outlook client is launched, Outlook will access the user’s mailbox on the new Exchange 2010 server. By leaving the old Exchange 2007 infrastructure in place for a couple weeks, pretty much all of your users will launch Outlook to have the profile automatically changed thus requiring no client system intervention during the migration process. The only users you will likely need to manually reset their Outlook profile are users who are on extended leave and had not accessed their Outlook mail during the 2 week time that you had the Exchange 2007 environment still in place.

Hopefully these steps are helping in providing you guidance in your migration from Exchange 2007 to Exchange 2010. I cover the migration process in much more detail (including specific steps and step by step processes for cutting over CAS, Hub Transport, and Mailbox server roles) in my book “Exchange 2010 Unleashed” from Sams Publishing. The book was written from 2-yrs of early adopter experience working with Exchange 2010 and will hopefully provide more detailed guidance on the migration process from Exchange 2007 to Exchange 2010.

I’ve been ask to blog information about the new Hub Transport “Shadow Redundancy” process that provides fault tolerance to the routing of mail through Hub Transport servers, as well as I’ve been asked to blog about the new Exchange 2010 Unified Messaging (voicemail), so I’ll put together my thoughts on those areas upcoming…

If you make any Exchange services available over the Internet, you need to set up an Exchange server in the DMZ. For example, if your Exchange server accepts inbound SMTP mail from the Internet, you must provide an SMTP connection to your Exchange server. Also, many companies place front-end Outlook Web Access (OWA) servers in the DMZ to let users access their mailboxes over a secure HTTP connection. If your organization requires news feeds (through Network News Transfer Protocol—NNTP), you might need an NNTP presence in your DMZ. Other services that might require an Exchange service in the DMZ include Instant Messaging (IM) services, conferencing services, and custom applications.

When you need to locate an Exchange server in the DMZ, you have several options for protecting the server. If you have a firewall in place, you might be able to locate the firewall proxy connections to your Exchange server inside the firewall so that the server isn’t directly exposed to the Internet. This approach is common for services such as SMTP. When you don’t have a proxy firewall, you need to set up some ACLs on the router that handles traffic to and from the Internet. Typically, the configuration on your Internet perimeter will have multiple zones that lead to a multitiered architecture. In such cases, you must limit inbound traffic to your Exchange servers to the specific services you want the servers to accept (e.g., SMTP, HTTP). Likewise, you must let only specified services travel to the Internet from your Exchange servers.

If you use standard management tools to administer and manage Exchange servers in the DMZ, you might need to implement special configurations. For example, when you locate OWA servers in the DMZ, you need to open TCP ports 80 (HTTP), 443 (Single Sockets Layer—SSL—port for HTTP), 389 (Lightweight Directory Access Protocol—LDAP), and 3268 (Global Catalog—GC) because OWA uses these ports to serve clients. However, to manage the OWA server from inside the firewall, you also need to open certain remote procedure call (RPC) ports. Management tools such as Exchange System Manager (ESM) won’t work unless you configure these ports and services to pass through the firewall.