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 .You just need to add the Exchange organization from the target forest AD to the EMC first.
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.