Installing Exchange 2003/2007 in an Exchange 2010 Environment

Question: Is it possible to install Exchange 2003 or 2007 in a pure Exchange 2010 organization?

 Answer: If this is an Exchange 2010 greenfield environment (an Exchange organization that consists only of Exchange 2010 servers and never had previous versions of Exchange deployed), the answer is no. If you have transitioned from Exchange 2007 to Exchange 2010 and the last Exchange 2007 server has already been decommissioned, the answer is again no. You will not be able to install Exchange 2007 at a later time in this organization because it’s now considered a pure Exchange 2010 organization.

If you plan to transition from Exchange 2003 to Exchange 2010 and you have already prepared the Active Directory forest using Exchange 2010 setup, again  you can’t  install an Exchange 2007 server in the organization. You will, by the way, get a warning that mentions this when installing the first Exchange 2010 in a pure Exchange 2003 organization (see Figure 1).

Figure 1 Setup warns that you can’t install Exchange 2007 in the organization after preparing it using Exchange 2010 Setup.

So if you think you’ll need an Exchange 2007 server at some point, you should keep an Exchange 2007 server in the organization after transitioning from Exchange 2007 to Exchange 2010. Or, if you are transitioning from Exchange 2003 to Exchange 2010, you should deploy an Exchange 2007 server in the organization before you prepare the AD forest using Exchange 2010 setup.

Question: We currently use Exchange 2007 as the messaging system in our enterprise environment. We have just upgraded all our client machines from Windows XP to Windows 7, and we’re having problems installing the Exchange 2007 (SP2) Management tools on the new Windows 7 clients. Anything special we need to be aware of when installing the Exchange 2007 Management tools on Windows 7?

Answer: Because Exchange Server 2007 was developed before Windows 7, the Exchange 2007 Management tools are not supported on Windows 7. The Exchange product group chose to focus their efforts on Exchange 2010, which of course does support Windows 7. 

Unfortunately, software development is always subject to budget and resource constraints, and these imposed some restrictions when the Exchange product group had to decide about providing support for installing the Exchange Management tools on Windows 7. An important consideration was the fact that approximately 65% of all customers who use Exchange are still on Exchange 2003, and now that Exchange 2010 has been released to manufacturing, most customers will skip Exchange 2007 and go directly to Exchange 2010.

The solution is to install Exchange 2007 Service Pack 3 on the Windows 7 clients. Yes, you heard that right. Based on customer feedback, the Exchange Product group has decided to release Exchange 2007 SP3 in the second half of 2010, which will add support for installing Exchange 2007 Management tools on Windows 7 clients and Exchange 2007 on Windows Server 2008 R2 servers. You can read more about the plans to release Exchange 2007 SP3 here:http://msexchangeteam.com/archive/2009/11/30/453327.aspx.

Question: As preparation for a planned Exchange 2007 to Exchange 2010 migration, I’ve set up a lab environment with two separate Active Directory forests. The source AD forest contains an Exchange 2007 organization and the target AD forest contains an Exchange 2010 organization.

I seem to recall that when I performed an Exchange 2003 to Exchange 2007 cross-forest migration, the target organization didn’t necessarily require that the Active Directory user accounts had already been migrated to the target AD forest.

After trying to move some Exchange 2007 mailboxes cross-forest to an Exchange 2010 organization, it seems that the cross-forest mailbox moves with Exchange 2010 behave differently from the Exchange 2007 equivalent.

Can you explain how to move mailboxes cross-forest when the target is an Exchange 2010 organization?

Answer: You’re correct that cross-forest mailbox moves in Exchange 2010 don’t work as they did with Exchange 2007.

As you indicate, the Exchange 2007 Move-Mailbox cmdlet didn’t necessarily require the AD accounts to be migrated to the target AD forest prior to moving the associated mailbox. The Exchange 2007 Move-Mailbox cmdlet would check for any AD accounts in the target AD forest that matched any of the proxy addresses (SMTP addresses), source ObjectSID (masterAccountSID, objectSID and sidHistory), or legacyExchangeDN (x500 address stamped on user object). If a match was found, the matched AD account in the target AD forest would be mail-enabled. If a match was not found, the Move-Mailbox cmdlet would create a disabled mailbox-enabled AD user account.

With Exchange 2010, things have changed. First, the Move-Mailbox cmdlet is no longer used. This cmdlet has been replaced with the brand-new New-Move Request cmdlet, which, by the way, brings several nice improvements with it. Furthermore, when doing cross-forest mailbox moves using the New-Move Request cmdlet, Exchange 2010 expects to find a valid mailuser and tries to match the source account to a target account using the msExchMailboxGUID. Unlike Exchange 2007, it will not try to match a target account using the abovementioned attributes. This means that before you can do cross-forest moves with Exchange 2010, you need to provision the target AD forest with mail users.

By the way, unlike with Exchange 2007, you can now do cross-forest mailbox moves using the Exchange 2010 Exchange Manage Console (see Figure 2). You just need to add the Exchange organization from the target forest AD to the EMC first.

Figure 2 The Exchange 2010 New Remote Move Request Window

You can create mail users in the target Exchange 2010 organization using the PrepareMoveRequest.ps1 script described in this section on Microsoft TechNet or by using either Identity Lifecycle Management (ILM) 2007 FP1 (with latest hotfix that will enable Exchange 2010 provisioning for ILM 2007 FP1) or using Forefront Identity Management (FIM 2010), which is currently available in a release candidate 1 and will RTM later in Q1 2010.

Question: Our organization currently has Exchange 2007 deployed. We have a high availability solution consisting of 4 Exchange 2007 servers—two servers that have the Hub Transport and Client Access server roles installed and two servers that are acting as mailbox server cluster nodes in a continuous replication cluster (CCR) cluster. The Exchange 2007 servers on which the HT and CAS server roles are installed have been configured in a Windows NLB in order to load balance and provide automatic failover for incoming client and SMTP connections. This solution works very well, but now that Exchange 2010 has been released, we want to move to this latest Exchange server version. Not only are there several new features we want to utilize, but we have also heard that we can reduce the number of Exchange servers to two without losing the HA functionality we have now.

Are there special considerations we need to be aware of before moving to an Exchange 2010 HA solution consisting of just two servers?

Answer: Yes, in order to build a highly available Exchange 2007 messaging solution with automatic failover and without any single points of failure at either the hardware or storage level, you needed a total of four machines: two servers with the Exchange 2007 Client Access and Hub Transport server roles installed and two acting as cluster nodes in a cluster continuous replication-based cluster (CCR).

The Hub Transport has built-in load balancing and fail-over for intra-site communication, and you could make it redundant using DNS round-robin mechanisms. But since the CAS role doesn’t include any load-balancing functionality, you typically also had to configure these two machines as nodes in a Windows network load balancing (WNLB) cluster in order to provide load balancing and automatic fail-over for incoming connections from clients and servers on the Internet and other external networks.

The two machines acting as cluster nodes in the CCR cluster would have the active and passive Mailbox server roles installed respectively, so that the clustered mailbox server (CMS) could switchover or failover to either node. Finally, you would dedicate one of the front-end servers as the file-share witness (third vote) in the CCR cluster.

As you probably know CCR (and SCC, LCR and SCR for that matter) has been cut from Exchange 2010. Instead, Exchange 2010 introduces a new feature called Database Availability Groups (DAGs). This feature uses the same synchronization technology as CCR and SCR combined, but it has so many new features and so much more functionality that it is significantly better than CCR and SCR. An interesting aspect of Exchange 2010 is that it’s supported to have other Exchange 2010 roles (Hub Transport, Client Access and even Unified Messaging) installed on the same server on which you have a Mailbox server role that has been added to a DAG. This means you no longer need to dedicate two machines as front-end servers for the Hub Transport and Client Access Server roles. You simply install all required Exchange 2010 roles on the two machines and voilà, you have a fully redundant Exchange 2010-based messaging solution. Well, almost. Yes, it did sound too good to be true, didn’t it?

You see, since DAGs make use of the Windows Failover Clustering (WFC) component to an extent (primarily heartbeat and the cluster database), you can’t configure the two servers as nodes in a Windows NLB since it’s unsupported to use both WFC and WNLB on the same server. This has been unsupported since Windows NT 4.0 and is due to potential hardware sharing conflicts between the Cluster service and WNLB. Read more in KB article: http://support.microsoft.com/default.aspx?kbid=235305.

This means that you must use an external load balancing/fail-over device such as a hardware-based load balancer. Also note this balancer should be redundant, so you need a minimum of two devices.

Though you still make use of WFC and though DAG is an Enterprise Edition feature, you don’t actually need the Exchange 2010 Enterprise Edition to utilize DAG. Unlike with Exchange 2007 CCR, DAG is also included with the standard edition of Exchange 2010. But bear in mind that you are limited to a total of five databases (including active and passive database copies) in this scenario.

 Since you install the CAS and HT roles on the same machine that has the Mailbox server role and is a DAG member server, you can spare two machines and two Windows 2008 and Exchange 2010 standard edition licenses. If you don’t already have an external load balancer in your environment, you can either use a virtual load balancer appliance or buy a hardware-based load balancer. Of course, you need a server that acts as the witness server as well, but although it’s a best-practice recommendation, this doesn’t necessarily need to be an Exchange server. It could be any Windows 2003/2008 file server in your environment.