Exchange 2010 - Planning and Coexistence
Given my current employment, I’ve got the time to devote to studying Exchange 2010. To hone my skills, I plan posting my notes on this beloved blog to encourage the masses to migrate to Exchange 2010 and hire me to do it.
Currently, Exchange 2010 is in the Release Candidate phase of development. This means it is one step before the Release (Ready?) to Market (RTM) or gold standard. Thus it is very similar to what you will see on Exchange 2010 when it hits production but there may be slight difference. It can be downloaded for evaluation from the Microsoft web site. In addition, the technical writing squirrels are catching up on the documentation to post to the Technet site too. There will be differences in what is posted now compared to what was and what will be concerning this version. This should be a little warning since what I write is predominately based on what I find on the Technet site.
Planning to implement Exchange 2010 is similar to Exchange 2007 (Ex2k7). This release was a departure from the previous Exchange releases in the architecture by implementing multiple roles an Exchange server could be assigned. Previous versions had two, the front end and back end options, for server roles. The front end managed the client web access and the inbound/outbound internet SMTP traffic. Exchange 2010 offers the same roles as Ex2k7: mailbox (MB), hub transport (HT), client access services (CAS), edge transport (ET) and unified messaging (UM). So the decision of where and how to implement these roles needs to be considered in the planning stage.
The biggest difference between 2007 and 2010 is the mailbox (MB) role’s high availability feature. Gone away are 2007’s Single Copy Cluster (SCC) and Local Continuous Copy Replication (LCR). The 2010’s new fandango for handling this provides a database replication to other Exchange servers where the database is highly available across multiple servers. We’ll get into this in more detail in later blogs. The up shot to planning is certain restrictions with 2007 are removed when placing roles. In a medium organization which wanted high availability for each role of mail service would need at least four servers, two clustered mailbox servers and two network load balanced CAS/HT servers. The clustered mailbox prevented additional roles being installed on it. We should now be able to knock this down to two since HT and CAS can be installed on the equivalent clustered mailbox server. The clustering technology has changed significantly with Windows Server 2008 so it is not dependent on shared storage; the Exchange 2010 capability makes clustering hardly server dependent.
Given the needed brevity of blogs, I won’t detail the decision points on role placement in this discussion. You can check out the Technet site and msexchange.org concerning Ex2k7 architecture if you would like more info on it. In addition, the majority of Exchange deployments include just single servers with third party implementations for anti-spam or unified communications. I believe we should concentrate on the majority to limit the discussion.
Another key similarity with Exchange 2007 is the lack of in-place upgrade capability. Overall, the in-place upgrade is not a recommended method of migration for email systems. The possiblity of breaking your working email server by running the setup.exe utility doesn’t emote a “warm and fuzzy” feeling especially when it is a business critical system. The upgrade restriction is primarily due to the 64 bit architecture and the requirement of Windows Server 2008 for the hosted operating system. Without the in-place upgrade, all customers will need to consider coexistence scenarios.
Here are the highlights on planning Exchange 2010 coexistence implementations:
- Exchange 2010 is supported with Ex2k3 SP2 and Ex2k7 SP2. Ex2k is not supported. This needs to be upgraded to Ex2k3 before you can get busy.
- Ex2k3 native mode is the minimum accepted configuration for the Exchange organization.
- Active Directory can be supported by Windows Server 2003 SP1 or higher. The Schema and GCs can be Windows Server 2003 servers.
- The Active Directory forest and domain function levels must be Windows Server 2003 or higher.
- Exchange isn’t supported on domain controllers. The exception is Small Business Server implementations and this is actually a different operating system from Windows Server 2008.
I expect the majority of customers considering Exchange 2010 will have Ex2k3 existing implementations. They have developed a pretty stable environment with Ex2k3 but see the benefits of the 64 bit processing performance. They may also be very interested in the high availability/site resilience solution since it has drastically reduced the price tag of it. Those who have implemented Ex2k7 may not have much impetus to upgrade unless they have Microsoft Software Assurance. I expect the economy will suppress even this move to limit the cost in man hours.
Since the architecture is similar to Ex2k7, the migration path is similar also. First, a CAS role is integrated into the organization. Legacy OWA requests will be redirected by the Exchange 2010 CAS role to this server. Thus the Exchange 2010 CAS will replace the Ex2k3 Front end server for Internet based OWA traffic. (When I refer to OWA, I also am including ActiveSync, Outlook Anywhere, POP3 and IMAP4) Second, the implementation of the Hub Transport role will replace the other component of the front end server by receiving the Internet based SMTP traffic. Finally, the mailbox servers are implemented and mailboxes are gradually moved from the Ex2k3 backend servers. A typical install which includes the CAS, HT and MB roles all in one server is acceptable in migration but you will concentrate on the configuring each role in the same order.
This is how Microsoft lays out the upgrade path which is how I’ll perform the migration in the lab:
1. Upgrade to proper SP level.
2. Install the Ex2010 with the follow role order CAS, HT, UM and MB
3. Configure legacy host name for the FE server. This allows users to continue have access to the Ex2k3 FE going through the Ex2010 server. The Ex2010 server will redirect traffic to this name "seamlessly."
4. Redirect internet bound incoming traffic to CAS and HT roles by reassigning the external name. This will result in the FE servers becoming secondary.
5. Move mailboxes to Ex2010.
The “legacy host name” step renames the FE server and reassigns its name to the Ex2010 server. For example, your company’s FE name is mail.domain.com. This will be changed to “legacy.domain.com” and the CAS server will get the mail.domain.com. SSL and forms based authentication is required on the Ex2k3 server for this to work.
I’ll stop here to keep your eyes from glazing over. Next time, we’ll walk through the preparation of an Exchange 2k3 environment.
Currently, Exchange 2010 is in the Release Candidate phase of development. This means it is one step before the Release (Ready?) to Market (RTM) or gold standard. Thus it is very similar to what you will see on Exchange 2010 when it hits production but there may be slight difference. It can be downloaded for evaluation from the Microsoft web site. In addition, the technical writing squirrels are catching up on the documentation to post to the Technet site too. There will be differences in what is posted now compared to what was and what will be concerning this version. This should be a little warning since what I write is predominately based on what I find on the Technet site.
Planning to implement Exchange 2010 is similar to Exchange 2007 (Ex2k7). This release was a departure from the previous Exchange releases in the architecture by implementing multiple roles an Exchange server could be assigned. Previous versions had two, the front end and back end options, for server roles. The front end managed the client web access and the inbound/outbound internet SMTP traffic. Exchange 2010 offers the same roles as Ex2k7: mailbox (MB), hub transport (HT), client access services (CAS), edge transport (ET) and unified messaging (UM). So the decision of where and how to implement these roles needs to be considered in the planning stage.
The biggest difference between 2007 and 2010 is the mailbox (MB) role’s high availability feature. Gone away are 2007’s Single Copy Cluster (SCC) and Local Continuous Copy Replication (LCR). The 2010’s new fandango for handling this provides a database replication to other Exchange servers where the database is highly available across multiple servers. We’ll get into this in more detail in later blogs. The up shot to planning is certain restrictions with 2007 are removed when placing roles. In a medium organization which wanted high availability for each role of mail service would need at least four servers, two clustered mailbox servers and two network load balanced CAS/HT servers. The clustered mailbox prevented additional roles being installed on it. We should now be able to knock this down to two since HT and CAS can be installed on the equivalent clustered mailbox server. The clustering technology has changed significantly with Windows Server 2008 so it is not dependent on shared storage; the Exchange 2010 capability makes clustering hardly server dependent.
Given the needed brevity of blogs, I won’t detail the decision points on role placement in this discussion. You can check out the Technet site and msexchange.org concerning Ex2k7 architecture if you would like more info on it. In addition, the majority of Exchange deployments include just single servers with third party implementations for anti-spam or unified communications. I believe we should concentrate on the majority to limit the discussion.
Another key similarity with Exchange 2007 is the lack of in-place upgrade capability. Overall, the in-place upgrade is not a recommended method of migration for email systems. The possiblity of breaking your working email server by running the setup.exe utility doesn’t emote a “warm and fuzzy” feeling especially when it is a business critical system. The upgrade restriction is primarily due to the 64 bit architecture and the requirement of Windows Server 2008 for the hosted operating system. Without the in-place upgrade, all customers will need to consider coexistence scenarios.
Here are the highlights on planning Exchange 2010 coexistence implementations:
- Exchange 2010 is supported with Ex2k3 SP2 and Ex2k7 SP2. Ex2k is not supported. This needs to be upgraded to Ex2k3 before you can get busy.
- Ex2k3 native mode is the minimum accepted configuration for the Exchange organization.
- Active Directory can be supported by Windows Server 2003 SP1 or higher. The Schema and GCs can be Windows Server 2003 servers.
- The Active Directory forest and domain function levels must be Windows Server 2003 or higher.
- Exchange isn’t supported on domain controllers. The exception is Small Business Server implementations and this is actually a different operating system from Windows Server 2008.
I expect the majority of customers considering Exchange 2010 will have Ex2k3 existing implementations. They have developed a pretty stable environment with Ex2k3 but see the benefits of the 64 bit processing performance. They may also be very interested in the high availability/site resilience solution since it has drastically reduced the price tag of it. Those who have implemented Ex2k7 may not have much impetus to upgrade unless they have Microsoft Software Assurance. I expect the economy will suppress even this move to limit the cost in man hours.
Since the architecture is similar to Ex2k7, the migration path is similar also. First, a CAS role is integrated into the organization. Legacy OWA requests will be redirected by the Exchange 2010 CAS role to this server. Thus the Exchange 2010 CAS will replace the Ex2k3 Front end server for Internet based OWA traffic. (When I refer to OWA, I also am including ActiveSync, Outlook Anywhere, POP3 and IMAP4) Second, the implementation of the Hub Transport role will replace the other component of the front end server by receiving the Internet based SMTP traffic. Finally, the mailbox servers are implemented and mailboxes are gradually moved from the Ex2k3 backend servers. A typical install which includes the CAS, HT and MB roles all in one server is acceptable in migration but you will concentrate on the configuring each role in the same order.
This is how Microsoft lays out the upgrade path which is how I’ll perform the migration in the lab:
1. Upgrade to proper SP level.
2. Install the Ex2010 with the follow role order CAS, HT, UM and MB
3. Configure legacy host name for the FE server. This allows users to continue have access to the Ex2k3 FE going through the Ex2010 server. The Ex2010 server will redirect traffic to this name "seamlessly."
4. Redirect internet bound incoming traffic to CAS and HT roles by reassigning the external name. This will result in the FE servers becoming secondary.
5. Move mailboxes to Ex2010.
The “legacy host name” step renames the FE server and reassigns its name to the Ex2010 server. For example, your company’s FE name is mail.domain.com. This will be changed to “legacy.domain.com” and the CAS server will get the mail.domain.com. SSL and forms based authentication is required on the Ex2k3 server for this to work.
I’ll stop here to keep your eyes from glazing over. Next time, we’ll walk through the preparation of an Exchange 2k3 environment.
Comments
This will redirect to exchange 2003 seamlessly only if Forms based auth is turned on in exchange owa. If your exchange 2003 owa is published by ISA, then this will not work, as FBA would need to be turned off.