Transitioning from Exchange 2000/2003 to Exchange Server 2007

[LEFT][CODE]http://www.msexchange.org/tutorials/Transitioning-Exchange-2000-2003-Exchange-Server-2007-Part1.html[/CODE]

[SIZE=3][B]PART-1[/B][/SIZE]

[B]Introduction [/B]

In this 3 part article series I’ll walk you through how to perform a transition from Exchange 2000/2003 to Exchange Server 2007. A transition is the process in which you perform an upgrade to Exchange 2007, that is you move data from any legacy Exchange servers in your Exchange organization to new Exchange 2007 Servers, after which you decommission the legacy Exchange servers. A transition should not be confused with a migration, because unlike a transition a migration is the process in which you move data from a non-Exchange messaging system (such as GroupWise, Lotus Notes or SendMail) to an Exchange organization, or move data from a legacy Exchange organization in an existing Active Directory Forest to an Exchange organization in a new Active Directory Forest.

It’s important to note that unlike previous versions of Exchange, in-place upgrades from Exchange 2000 or 2003 to Exchange Server 2007 aren’t supported, because, among other reasons, Exchange 2007 is 64-bit and therefore requires the x64-bit version of Windows Server 2003.
[B]Note:[/B]
Exchange Server 2007 also exists in a 32-bit version but this version is meant to be used for testing and evaluation purposes only, so unless we’re speaking management tasks, it’s only the 64-bit version of Exchange Server 2007 that’s supported in a production environment.
Although in-place upgrades to Exchange 2007 are unsupported, I can assure you that a transition from Exchange 2000 or 2003 to Exchange 2007 in the same Active Directory Forest is a straightforward process, as I’ll show you throughout this article series.


[B]Prerequisites[/B]

Before you even start thinking about deploying Exchange 2007 Servers in your existing environment, there are several requirements that must be fulfilled first.
You must make sure that the Exchange organization is set to [B]Native Mode (no pre-Exchange 2000 servers)[/B] as shown in [B]Figure 1.1[/B] below.
[IMG]http://www.msexchange.org/img/upl/image0011168870882828.jpg[/IMG]
[B]Figure 1.1:[/B] Exchange Organization set to Native Mode
Since any pre-Exchange 2000 servers that may exist in your Exchange organization must be decommissioned before you can switch to native mode, it means that any Exchange 5.5 Servers in your organization must be properly removed before you can perform this step. 'So does this mean that you cannot do a transition directly from Exchange 5.5 to Exchange 2007 in the same Active Directory Forest?' I hear some of you ask. Yes that is correct! Those, hopefully few, of you who still have an Exchange 5.5 organization who want to move to Exchange 2007 must first upgrade from Exchange 5.5 to 2000 or 2003 and then do the transition from Exchange 2000 or 2003 to Exchange 2007.
You must also make sure that any Exchange 2000 Servers in your Exchange organization run with Exchange 2000 Service Pack 3, and that any Exchange 2003 Servers have Service Pack 2 applied. In addition you should take note that if you plan to keep at least one Exchange 2000 or 2003 server in the Exchange organization, the following services are unsupported by Exchange Server 2007:

[LIST]
[LIST][*]Novell GroupWise connector (Exchange 2003 Service)[*]Microsoft Mobile Information Server (Exchange 2000 Service)[*]Instant Messaging service (Exchange 2000 Service)[*]Exchange Chat Service (Exchange 2000 Service)[*]Exchange 2000 Conferencing Server (Exchange 2000 Service)[*]Key Management Service (Exchange 2000 Service)[*]cc:Mail connector (Exchange 2000 Service)[*]MS Mail connector (Exchange 2000 Service)[/LIST][/LIST]
You must make sure that the Domain Controller that is the schema master in your Active Directory runs Windows Server 2003 with at least Service Pack 1 applied. This is also true for any Global Catalog servers in each Active Directory site in which you plan on deploying Exchange 2007. Actually I recommend you run Windows Server 2003 with at least Service Pack 1 applied on all Domain Controllers in the Active Directory Forest. This version supports Exchange 2007 service notifications, allows users to browse the address book in Microsoft Outlook Web Access and provides the ability to look up distribution list membership in a more efficient manner than in Windows 2000 Server.
[B]Note:[/B]
If you have any non-English Domain Controllers in your Active Directory, you should also apply the hotfix mentioned in [URL="http://support.microsoft.com/kb/919166"]MS KB article 919166[/URL] to those servers, as you otherwise can experience issues accessing the address book via OWA 2007.
Finally Exchange 2007 requires that the Active Directory functional level is set to Windows Server 2000 or Windows Server 2003 as shown in [B]Figure 1.2[/B] below.
[IMG]http://www.msexchange.org/img/upl/image0031168870882859.jpg[/IMG]
[B]Figure 1.2: [/B]Active Directory Domain Functional Level
If you’re unsure whether your Active Directory environment is ready for deploying the first Exchange 2007 Server, I recommend you run the latest version of the Exchange Best Practices Analyzer (ExBPA) to see if there’s anything you need to resolve before you continue.

The latest version of ExBPA version 2.7, which you can download at [URL="http://www.exbpa.com/"]www.exbpa.com[/URL], includes an Exchange 2007 Readiness Check option as shown in [B]Figure 1.3[/B].
[IMG]http://www.msexchange.org/img/upl/image0051168870882859.jpg[/IMG]
[B]Figure 1.3: [/B]Exchange 2007 Readiness Check Option in ExBPA
You may also have heard that you must suppress Link State updates on any Exchange 2000 or 2003 Servers when deploying an Exchange 2007 Server into a legacy Exchange organization. But this is only true if you’re planning on having more than one routing group connection established between Exchange 2000/2003 and Exchange 2007. For the purpose of this article series we’re deploying one Exchange 2007 Server into a legacy Exchange organization consisting of one Exchange 2003 Server, and therefore don’t need to suppress Link State updates. If you plan on establishing more than one routing group connector, see [URL="http://www.microsoft.com/technet/prodtechnol/exchange/e2k7help/1f0b9ca5-06ca-4848-a79b-7d92aba2c7dd.mspx"]this link[/URL] for instructions on how to suppress Link State updates.
[B]Preparing Active Directory [/B]

With all prerequisites fulfilled we can move on and prepare the Active Directory using the respective Exchange 2007 Setup.exe switches. Exchange 2007 Setup includes several switches; we’ll go through each of those related to preparing the Active Directory in this section.

[B]Important:[/B]
Each of the switches we go through below will be run automatically during the deployment of the first Exchange 2007 server in the Exchange legacy organization, so it’s not mandatory to run them before installing Exchange 2007, but depending on the size as well as topology of your environment, it may be wise to prepare the Active Directory first using these switches before you start the actual deployment process.
[B]Prepare Legacy Exchange Permissions[/B]

The first thing we need to do when deploying an Exchange 2007 into a legacy Exchange organization is to run [B][I]Setup.com /PrepareLegacyExchangePermissions.[/I][/B] This is in order to grant specific Exchange permissions in the Active directory domain(s) in which one or more Exchange 2000 or 2003 Servers exist, or where Exchange 2000 or 2003 DomainPrep has been executed. The reason why we must run the [B][I]Setup.com /PrepareLegacyExchangePermissions[/I][/B] is because the Exchange 2003 or Exchange 2000 Recipient Update Service otherwise won’t function correctly after the Active Directory schema has been updated with Exchange 2007 specific attributes.
[B]Note:[/B]
For a detailed explanation on why the [B][I]Setup.com /PrepareLegacyExchangePermissions [/I][/B]must be run in an Active Directory domain in which one or more Exchange 2000 or 2003 Servers exist, or where Exchange 2000 or 2003 DomainPrep has been executed, see [URL="http://www.microsoft.com/technet/prodtechnol/exchange/e2k7help/cb24ddb7-0659-4d9d-9057-52843f861ba8.mspx?mfr=true"]this section[/URL] in the Exchange 2007 Online Documentation.
In order to run [B][I]Setup.com /PrepareLegacyExchangePermissions[/I][/B], you must open a Command Prompt window and navigate to the directory, network share or DVD media containing your Exchange 2007 Setup files, then simply type [B][I]Setup.com /PrepareLegacyExchangePermissions[/I][/B] and hit [B]Enter[/B] as shown in [B]Figure 1.4[/B].
[IMG]http://www.msexchange.org/img/upl/image0061168871152203.jpg[/IMG]
[B]Figure 1.4:[/B] Running Setup.com with the /PrepareLegacyExchangePermissions Switch
[B]Note:
[/B]Some of you might be in a situation where you want to prepare the Active Directory domain before you install the x64-bit version of Windows Server 2003 on a server in the Active Directory Forest, and therefore cannot run [B][I]Setup.com /PrepareLegacyExchangePermissions[/I][/B] using the 64-bit version of Exchange 2007 as you don’t have any x64-bit Windows 2003 Servers deployed yet. But fear not, as it’s fully supported to use the 32-bit version of Exchange 2007 to prepare your production Active Directory environment. As I mentioned in the introduction, the 32-bit version of Exchange 2007 is fully supported in a production environment, when speaking management tasks, and preparing the Active Directory is considered a management task.
[B]Prepare Schema[/B]

The next command to run in order to prepare the environment is the [B][I]Setup.com /PrepareSchema[/I][/B], which will connect to the Domain Controller schema master and import LDAP files to update the schema with Exchange 2007 specific attributes. In order to do so, open a Command Prompt window and type [B][I]Setup.com /PrepareSchema [/I][/B]followed by hitting [B]Enter[/B] like we did with the previous switch. Setup will now update the schema as necessary as shown in [B]Figure 1.5[/B].
[IMG]http://www.msexchange.org/img/upl/image0071168871152218.jpg[/IMG]
[B]Figure 1.5:[/B] Running Setup.com with the PrepareSchema Switch
Like was the case with the previous command, this can be done using the 32-bit version of Exchange 2007.
[B]Prepare AD[/B]

The [B]Setup.com /PrepareAD[/B] command is used to configure global Exchange objects in Active Directory, create the Exchange Universal Security Groups (USGs) in the root domain as well as prepare the current domain. The global objects reside under the Exchange organization container. In addition, this command creates the Exchange 2007 Administrative Group which is named [B]Exchange Administrative Group (FYDIBOHF23SPDLT)[/B] as well as creates the Exchange 2007 Routing Group called [B]Exchange Routing Group (DWBGZMFD01QNBJR)[/B].

As some of you may be aware, Exchange 2007 doesn’t make use of Routing Groups and Administrative Groups like Exchange 2000 or 2003 did. Administrative Groups have been dropped completely and message routing in Exchange 2007 is based on Active Directory Sites. But in order for Exchange 2007 to co-exist with Exchange 2000 or 2003, Exchange must create the mentioned Administrative Group and Routing Group, which can only be viewed via an Exchange 2000 or 2003 System Manager or by using ADSIEdit as can be seen in [B]Figure 1.6[/B] and [B]1.7[/B] below.
[IMG]http://www.msexchange.org/img/upl/image0081168871152218.jpg[/IMG]
[B]Figure 1.6: [/B]Exchange 2007 Administrative and Routing Group in the Exchange 2003 System Manager
[IMG]http://www.msexchange.org/img/upl/image0091168871338984.jpg[/IMG]
[B]Figure 1.7:[/B] Exchange 2007 Administrative and Routing Groups in ADSIEdit
You can run the [B][I]Setup.com /PrepareAD[/I][/B] command before running [B][I]/PrepareLegacyExchangePermissions[/I][/B] and [B]/PrepareSchema[/B]. Doing so will run the [B][I]/PrepareLegacyExchangePermissions[/I][/B] and [B]/PrepareSchema [/B]commands automatically.


[B]Note:[/B]
Okay with all these boring switches it’s time for a little fun! Did you know that although coding a product such as Exchange 2007 is a lot of hard work, the Exchange Product Group always has time for a little humor? To prove it let us try to take the GUID of the above Administrative Group shown in [B]Figure 1.6[/B] and shift each letter upwards. Do the same for the GUID of the Exchange Routing Group shown in [B]Figure 1.7[/B] but do it downwards. Did you manage to see what it translates to?
In order to run this command, open a Command Prompt window and type [B]Setup.com /PrepareAD [/B]followed by [B]Enter[/B]. Setup will now configure the organization as necessary as shown in [B]Figure 1.8[/B].
[IMG]http://www.msexchange.org/img/upl/image0101168871338984.jpg[/IMG]
[B]Figure 1.8:[/B] Running Setup.com with the PrepareAD Switch
[B]PrepareDomain and PrepareAllDomains[/B]

It’s also possible to prepare a local domain or all domains in the Active Directory using the [B]Setup.com /PrepareDomain[/B] and [B]Setup.com /PrepareAllDomains[/B] respectively. These switches will set permissions on the Domain container for the Exchange Servers, Exchange Organization Administrators, Authenticated Users, and Exchange Mailbox Administrators, create the Microsoft Exchange System Objects container if it does not exist, and set permissions on this container for the Exchange Servers, Exchange Organization Administrators, and Authenticated Users and create a new domain global group in the current domain called Exchange Install Domain Servers. In addition it will add the Exchange Install Domain Servers group to the Exchange Servers USG in the root domain.
As with the commands we have already been through, these commands also need to be run from a Command Prompt window as shown in [B]Figure 1.9[/B].
[IMG]http://www.msexchange.org/img/upl/image0111168871339000.jpg[/IMG]
[B]Figure 1.9:[/B] Running Setup.com with the PrepareDomain Switch
This was all there was for part 1 in this 3 part article series covering a transition from Exchange 2000/2003 to Exchange 2007 in the same Active Directory Forest. In part 2 which will be published soon here on MSExchange.org, we’ll prepare the new server for Exchange 2007 and then do the actual Exchange 2007 installation.


[/LEFT]

[LEFT][CODE]http://www.msexchange.org/tutorials/Transitioning-Exchange-2000-2003-Exchange-Server-2007-Part2.html[/CODE]

[SIZE=3][B]PART-2[/B][/SIZE]

[B]Installing Exchange Server 2007[/B]

We have reached part 2 in this 3 part article series covering how you transition from an Exchange 2000/2003 to an Exchange 2007 Server deployed in the same Active Directory Forest. For the purpose of this article we will only install one Exchange 2007 Server, and we’ll do so by selecting a typical installation of Exchange 2007. Since a typical installation of Exchange Server 2007 installs the Mailbox, Hub Transport and Client Access Server roles on the respective server, we must make sure the following software and Windows components are installed on the server prior to launching Exchange 2007 Setup.
[B]Required Software[/B]


[LIST][*]Microsoft .NET Framework Version 2.0 (including [URL="http://go.microsoft.com/fwlink/?linkid=74465"]this update[/URL])[*]Microsoft Management Console (MMC) 3.0 (bear in mind MMC 3.0 is installed by default when using Windows Server 2003 R2)[*]Windows PowerShell V1.0 (can be found [URL="http://support.microsoft.com/?kbid=926139"]here[/URL] or on the Exchange 2007 DVD media)[/LIST]
[B]Required Windows Components[/B]

[B]Mailbox Server[/B]

[LIST][*]Enable network COM+ access[*]Internet Information Services[*]World Wide Web Service[/LIST]
When installing the Mailbox Server role, you also need to make sure you install the hotfixes mentioned in MS KB article [URL="http://support.microsoft.com/kb/904639"]904639[/URL] and [URL="http://support.microsoft.com/kb/918980"]918980[/URL].
[B]Client Access Server[/B]

[LIST][*]World Wide Web Service[*]Remote procedure call (RPC) over Hypertext Transfer Protocol (HTTP) Proxy Windows networking component (Required only if you are deploying clients that will use the Outlook Anywhere functionality, previously called RPC over HTTP)[*] ASP.NET v2.0[/LIST]
[B]Hub Transport Server[/B]
No additional Windows components are required by the Hub Transport server; however you must make sure that the SMTP and NNTP services are [B][U]NOT[/U][/B] installed.
[B]Note[/B]
Listing the hardware requirements for Exchange 2007 is outside the scope of this article's series. For information on hardware requirements see [URL="http://www.microsoft.com/technet/prodtechnol/exchange/e2k7help/cb24ddb7-0659-4d9d-9057-52843f861ba8.mspx?mfr=true"]this section[/URL] in the Exchange Server 2007 Online Documentation.
When ready navigate to the network share containing the Exchange 2007 Setup files, or insert the Exchange Server 2007 DVD media, then double-click on [B]Setup.exe[/B]. This will bring us to the Exchange 2007 splash screen shown in[B] Figure 2.1[/B]. Click [B]Step 4: Install Microsoft Exchange[/B].
[IMG]http://www.msexchange.org/img/upl/image0011170071347937.jpg[/IMG]
[B]Figure 2.1:[/B] Exchange 2007 Setup Splash Screen
Setup will copy the necessary files and soon after begin initializing. After initialization completes, you will be taken to the first step in the Installation Wizard, the [B]Introduction[/B] page where you should click [B]Next[/B].
You will now be presented with and need to accept the terms of the end-user license agreement (EULA). I know reading the License Agreement is not among the most exciting things in the world, but you should at least spend a couple of minutes skimming through it. When you have done so, select [B]I accept the terms in the license agreement[/B], and then click [B]Next[/B]. After clicking [B]Next[/B] you will be taken to the [B]Error Reporting[/B] page, where you should decide if you want to enable this feature or not. When you have done so click [B]Next[/B].
As you can see in [B]Figure 2.2[/B], now is the time to select the type of installation we want to perform, as we’re going to do a typical installation of Exchange Server 2007, select this option, then click [B]Next[/B].
[IMG]http://www.msexchange.org/img/upl/image0021170071347968.jpg[/IMG]
[B]Figure 2.2:[/B] Selecting a Typical Exchange Server Installation
In order to establish mail flow between the Exchange 2000/2003 and the Exchange 2007 routing groups, we now need to create a routing group connector ([B]Figure 2.3[/B]). To do so click [B]Browse[/B] then select the Exchange 2000 or 2003 bridgehead server to which you want to connect Exchange 2007, then click [B]Next[/B].
[IMG]http://www.msexchange.org/img/upl/image0031170071347984.jpg[/IMG]
[B]Figure 2.3: [/B]Specifying an Exchange 2000 or 2003 Routing Group
The Exchange 2007 Setup wizard will now go through a set of prerequisite checks in order to see whether Exchange is ready to be installed. If you have installed all the necessary software, Windows components and hotfixes, it should complete without any warnings or errors. If this is not the case you should review the issue and if possible click the Recommended Action link in order to see an explanation of or a resolution to the warning or error.
When all issues have been resolved click the Install button and let Exchange Setup copy the necessary Exchange files and install and configure each server role.


[B]Note:[/B]
If you didn’t run any of the setup preparation switches mentioned in part 1 of this 3 part article series, the Exchange 2007 Setup wizard will prepare the Active Directory before it begins installing the respective server roles.
When Setup has completed installing all the Server roles, click Finish ([B]Figure 2.4[/B]).
[IMG]http://www.msexchange.org/img/upl/image0041170071753468.jpg[/IMG]
[B]Figure 2.4:[/B] Exchange 2007 Setup Completed
[B]Finalizing Deployment[/B]

With the Exchange 2007 Server installation in place let’s launch the Exchange Management Console (EMC). Note that the first time the EMC is launched it will show you the Finalize Deployment tab under the Microsoft Exchange node as shown in [B]Figure 2.5[/B]. You should examine each of the deployment tasks listed here, and perform the ones that are relevant for your environment.
[IMG]http://www.msexchange.org/img/upl/image0061170071753468.jpg[/IMG]
[B]Figure 2.5:[/B] Finalize Deployment Tab in the Exchange Management Console
Since each deployment task is explained in a step by step fashion, I won’t go into details about each of them here.
[B]End-to-End Scenario Tasks[/B]

In addition to the Deployment Tasks we just covered, there’s also an End-to-End Scenario tab ([B]Figure 2.6[/B]), which provides a list of tasks that are optional for configuring features, but you should at least skim through each of them and see whether any of these tasks are relevant to your Exchange environment.
[IMG]http://www.msexchange.org/img/upl/image0081170071753468.jpg[/IMG]
[B]Figure 2.6:[/B] End-to-End Scenario Tab in the Exchange Management Console
Again, since each task under this tab is pretty much self-explanatory, covering each of them is outside the scope of this articles series.
[B]Global Settings[/B]

Global Settings that have been configured on an Exchange 2000 or 2003 Server will be transferred to the Exchange 2007 Server automatically, as these settings are stored and read from Active Directory. This means that recipient policies, Internet Message Formats, SMTP connectors and Exchange delegation permissions are applied to user mailboxes stored on Exchange 2007 as well. [B]Figure 2.7[/B] below shows you the Default Policy which was originally created on our Exchange 2003 Server.
[IMG]http://www.msexchange.org/img/upl/image0101170071920046.jpg[/IMG]
[B]Figure 2.7:[/B] Default Policy in the Exchange 2007 Management Console
Also note that when the Exchange 2007 Server has been deployed in the legacy Exchange organization, any of the organization-level settings should be managed using Exchange 2007 Management tools (EMC or EMS) during the co-existence period.
That was it for part 2 but you can look forward to part 3, which is the last article in this article series, which will be published in the near future. In part 3 we’ll replicate public folders, move mailboxes as well as a few other things before we finally decommission the Exchange 2003 server. See you then!

[/LEFT]

[LEFT][CODE]http://www.msexchange.org/tutorials/Transitioning-Exchange-2000-2003-Exchange-Server-2007-Part3.html[/CODE]

[SIZE=3][B]PART-3[/B][/SIZE]

[B]Replicating Public Folders[/B]

When deploying an Exchange 2007 Server with the Mailbox Server role installed into a legacy Exchange organization, Exchange Setup will create one Mailbox database and one Public Folder database on the respective server by default as can be seen in [B]Figure 3.1[/B] below.
[IMG]http://www.msexchange.org/img/upl/image0021170860922968.jpg[/IMG]
[B]Figure 3.1:[/B] Exchange 2007 Mailbox and Public Folder Database
The Public Folder database is created so that you can replicate any Public Folder data stored on your legacy Exchange servers to Exchange 2007. Even though you don’t use Public Folders to store data in your environment, there’s one other reason why you might want to keep the Public Folder database mounted on your Exchange 2007 Server. As some of you may already know, Exchange 2007 no longer uses a Public Folder (or more specifically a System Folder named SCHEDULE+ FREE BUSY in your Public Folder hierarchy) to store free/busy information for the mailbox users in the organization. Instead free/busy information is stored directly in each user’s mailbox, and retrieved using a new web-based service called the Availability service. The advantage of this new approach is that there no longer are any 15 minute delays when free/busy time for a user is updated. Instead the update will happen instantly. So why would I want to keep the Public Folder database on my Exchange 2007 server, if free/busy information is retrieved using this new method? Well if you still have legacy Outlook clients (that is Outlook 2003 and earlier versions) running in your organization, these clients still need to use Public Folder method to retrieve free/busy information, since only Outlook 2007 supports the new Availability service.

If you don’t use Public Folders to store data and only have Outlook 2007 clients deployed in your organization, you can safely remove the Public Folder database, as you don’t have anything to use it for in that case. This also means you can skip the following steps.
Okay let’s get going with setting up a replica for the Public Folders on our Exchange 2003 Server that should be replicated with the new Exchange 2007 Public Folder database. In order to do so we must use either the Exchange 2003 System Manager or the Exchange Management Shell (EMS). For the purpose of this example we’ll use the Exchange 2003 System Manager.


[B]Note[/B]
Managing Public Folders using the Exchange Management Console (EMC) is not possible in Exchange 2007 RTM, but will be integrated with Exchange 2007 Service Pack 1.
To add the Exchange 2007 Public Folder database to the replica list on the Exchange 2003 Server, open the Exchange 2003 System Manager, then expand Administrative Groups > First Administrative Group > Folders > Public Folders as shown in [B]Figure 3.2[/B].
[IMG]http://www.msexchange.org/img/upl/image0041170860922968.jpg[/IMG]
[B]Figure 3.2:[/B] Public Folders in the Exchange 2003 System Manager
Now open the property page of each public folder, then click the Replication tab and add the Exchange 2007 to the replica list as shown in [B]Figure 3.3[/B].
[IMG]http://www.msexchange.org/img/upl/image0051170860922968.jpg[/IMG]
[B]Figure 3.3:[/B] Public Folder Replication Tab
[B]Note[/B]
Exchange 2003 Service Pack 2 introduced a new Public Folder Settings Wizard which makes it a breeze to add servers to replica lists. So if you have a lot of Public Folders in your Public Folder tree, I highly recommend you use this wizard, which you can read more about in a [URL="http://www.msexchange.org/tutorials/Public-Folder-Improvements-Exchange-2003-Service-Pack-2.html"]previous article[/URL] of mine. If you have thousands of Public Folders, you might want to use the Public Folder replica scripts located in the Exchange Scripts folder (which can be found under C:\Program Files\Microsoft\Exchange Server).


Even though you still have legacy Outlook clients (Outlook 2003 and earlier) in your organization, you don’t need to set up a replica for the SCHEDULE+ FREE BUSY or the OFFLINE ADDRESS BOOK system folder. This will be done automatically when deploying an Exchange 2007 Server in a legacy Exchange organization.
When all Public Folders have been replicated to the Exchange 2007 Server, you should remove the old Exchange 2000 or 2003 Server(s) from the replica lists. When any Public folder data has been removed from the respective Public folder instances, you can dismount the old Public Folder stores (E2k3 SP2 won’t let you remove the Public Folder store until the data is gone and it won’t get removed while it’s dismounted). You should verify that your clients are still capable of seeing Public Folder data as well as free/busy information and accessing the offline address book before you delete it though. If this is not the case, I recommend you wait a little longer so that you’re sure the replication has occurred properly.

[B]Important:[/B]
Outlook Web Access (OWA) 2007 doesn’t include a GUI for accessing Public Folders, so in order to access Public Folders using Internet Explorer you must open a separate browser window and type [url]https://FQDN/public[/url]. It’s important you’re aware of this missing feature!
[B]Pointing Internet Clients to the Client Access Server[/B]

Now would be a good time to point any Internet clients that are OWA, EAS and RPC over HTTP (now called Outlook AnyWhere) in your organization to the Client Access Server running on the Exchange 2007 Server. If you’re using a firewall such as ISA server (which you do, right?), this change is done at your ISA Server firewall. If you for some reason don’t use an ISA Server in your DMZ, but perhaps a Check Point Firewall 1 or a wannabe firewall such as a Cisco PIX, you should do the redirection there. If you don’t have a firewall you should make the change on the external DNS server hosting your Internet domain.
[B]Note:[/B]
If your ISA Server is configured to pre-authenticate your OWA users, you must change the Authentication method for the OWA virtual directory under Server Configuration > Client Access in the EMC to basic authentication, since it’s configured to use forms-based authentication by default.


So will any users with a mailbox on my Exchange 2000 or 2003 Server still be able to use OWA, Exchange ActiveSync or Outlook AnyWhere (formerly known as RPC over HTTP) to access their mailbox? Yes this will work just fine since the Client Access Server is backward compatible and will redirect the clients to the respective legacy mailboxes on the Exchange 2000 or 2003 server.


[B]Note:
[/B]When you perform the above changes, your users will no longer be able to access their mailbox using Outlook Mobile Access (OMA), as OMA has been discontinued in Exchange 2007.
[B]Moving Legacy Mailboxes to Exchange 2007[/B]

Alright we have reached the part where we’re going to move our legacy mailboxes from Exchange 2000 or 2003 Server to Exchange 2007. Doing so is a straightforward process and can be done using either the Move Mailbox wizard in the Exchange Management Console (EMC) or the Move-Mailbox cmdlet in the Exchange Management Shell (EMS). For the purpose of this article series we’ll use the EMC. So if it’s not already open, launch the EMC, then expand the Recipient Configuration work center and click the Mailbox sub-node. Now highlight all the legacy mailboxes as shown in [B]Figure 3.4[/B], and then click the Move Mailbox task in the Action Pane.
[IMG]http://www.msexchange.org/img/upl/image0071170861087562.jpg[/IMG]
[B]Figure 3.4: [/B]Selecting Legacy Mailboxes in the Exchange Management Console
This will launch the Exchange 2007 Move Mailbox wizard, where you need to specify the destination server, storage group and mailbox database. Select the Exchange 2007 Server in the drop down box ([B]Figure 3.5[/B]), and then click Next.
[IMG]http://www.msexchange.org/img/upl/image0081170861087562.jpg[/IMG]
[B]Figure 3.5:[/B] Specifying the Exchange 2007 Server as the Destination Server
Now specify how you want to manage any corrupted messages found in a mailbox ([B]Figure 3.6[/B]), then click Next.
[IMG]http://www.msexchange.org/img/upl/image0091170861087578.jpg[/IMG]
[B]Figure 3.6:[/B] Specifying how corrupted messages in mailboxes should be managed
On the Move Schedule screen shown in [B]Figure 3.7[/B], select Immediately (unless you want the mailboxes to be moved automatically at a later time) and click Next.
[IMG]http://www.msexchange.org/img/upl/image0101170861227703.jpg[/IMG]
[B]Figure 3.7:[/B] Move Mailbox Scheduling Options
Finally click Move in order to start moving the legacy mailboxes to the Exchange 2007 Server ([B]Figure 3.8[/B]).
[IMG]http://www.msexchange.org/img/upl/image0111170861227703.jpg[/IMG]
[B]Figure 3.8:[/B] Move Mailboxes Summary Page
As is the case with the Move Mailbox wizard in Exchange 2003, the Exchange 2007 Move Mailbox wizard can move 4 mailboxes at a time, and only one instance of the wizard can run on a server.
When all the mailboxes have been moved to the Exchange 2007 Server click Finish in order to exit the Move Mailbox wizard, and then check that mail flow to/from the Internet to the mailboxes on the Exchange 2007 works as expected.
If you will be running in a co-existence environment for a period of time, it’s important to understand that mailboxes stored on an Exchange 2007 server must [B][U]not[/U][/B] be managed using the Active Directory Users and Computers (ADUC) MMC snap-in, but instead must be managed using the Exchange Management Console (EMC) or the Exchange Management Shell (EMS). However Exchange 2003 mailboxes can still be managed using ADUC.
[B]Note:[/B]
If you want to move the Mailboxes using the Exchange Management Shell (EMS), you do so using the Move-Mailbox cmdlet. Using the Move-Mailbox cmdlet gives you a set of advanced options, among which the most interesting one is the option of specifying the number of mailboxes to be moved at a time (as you read earlier the Move Mailbox wizard is limited to 4).
[B]Redirecting Inbound Mail to the Exchange 2007 Server[/B]

When all legacy mailboxes have been moved to the Exchange 2007 Server, we can point SMTP traffic (port 25/TCP) directly to the Exchange 2007 Server, so that inbound messages are routed directly to this server. It’s recommended to deploy an Edge Transport Server in your perimeter network (aka DMZ), and let this server route inbound messages to the Exchange 2007 server on your internal network. Instructions on how to deploy an Edge Transport server is outside the scope of this article series, but I’ll cover that topic in another article in the near future. If you don’t want to deploy an Edge Transport server, you should bear in mind that you need to change the Permission Groups settings on the [B]Default <server>[/B] receive connector under the Server Configuration work center node> Hub Transport sub-node in the EMC so [B]Anonymous users[/B] are allowed to connect to the Exchange 2007 Server as shown in [B]Figure 3.9[/B], otherwise you won’t be able to receive e-mail messages from other SMTP servers on the Internet.
[IMG]http://www.msexchange.org/img/upl/image0121170861227703.jpg[/IMG]
[B]Figure 3.9:[/B] Permission Groups Settings on the Default Receive Connector
In addition you should make sure that any Send Connectors under [B]Organization Configuration[/B] > [B]Hub Transport[/B] > [B]Send Connector[/B] tab are configured so that they can send outbound mail (either using a smart host or DNS MX) properly ([B]Figure 3.10[/B]).
[IMG]http://www.msexchange.org/img/upl/image0131170861399203.jpg[/IMG]
[B]Figure 3.10:[/B] Send Connector Settings
When the necessary changes have been made, we can delete the routing group connector which was set up to establish mail flow between the Exchange 2003 and 2007 Routing Groups. In order to do so you should expand Administrative Groups > First Administrative Group > Routing Groups > Connectors and right-click on the respective Routing Group Connector then select Delete in the context menu as shown in [B]Figure 3.11[/B].

[B]Note:
[/B]Officialy the correct way of deleting the routing group connectors is to use the Remove-RoutingGroupConnector cmdlet, but since Exchange 2003 version blocking doesn’t block deletes, you can also use the Exchange 2003 System Manager as well.
[IMG]http://www.msexchange.org/img/upl/image0151170861399203.jpg[/IMG]
[B]Figure 3.11:[/B] Deleting the Routing Groups Connector
Since the Routing Group connector won’t be deleted in both ends, you also need to delete it under the Exchange Administrative Group (FYDIBOHF23SPDLT) > Exchange Routing Group (DWBGZMFD01QNBJR) > Connectors.
[B]Decommissioning Exchange Legacy Servers[/B]

The final step is to decommission the Exchange 2000 or 2003 Server and we can consider the transition done. The Exchange 2003 server should be removed using the Exchange 2003 Setup program, which can be launched via Add or Remove Programs ([B]Figure 3.12[/B]).
[IMG]http://www.msexchange.org/img/upl/image0171170861399218.jpg[/IMG]
[B]Figure 3.12:[/B] Add or Remove Programs
But before you begin uninstalling the Exchange 2003 Server, we first need to assign the Recipient Update Service (RUS) to our Exchange 2007 Server. Not because RUS should be used (in fact Exchange 2007 no longer uses RUS), but because the Exchange 2003 Setup program won’t let us uninstall Exchange 2003, before RUS has been assigned to another server. In order to assign RUS to the Exchange 2007 Server, open the Exchange 2003 System Manager, then expand the Recipients node and select Recipient Update Services. Now open the property page both for Recipient Update Service (Enterprise Configuration) and Recipient Update Service (domain), then click the Browse button under the Exchange Server text box and specify the Exchange 2007 Server instead, then click OK twice and close the System Manager as shown in [B]Figure 3.13[/B].
[B]Note
[/B]It's important you don't delete the recipient policies in the Exchange 2003 System Manager, since Exchange 2007 uses them when provisioning users.
[IMG]http://www.msexchange.org/img/upl/image0191170861703937.jpg[/IMG]
[B]Figure 3.13:[/B] Assigning the Recipient Update Service to the Exchange 2007 Server
[B]Note:[/B]
Microsoft will release an Exchange 2003 hotfix, which will prevent one from reassigning the RUS to an Exchange 2007 server some time in the future. The reason being, this really is an invalid setting that should be blocked. Instead the recommendation will be to use ADSIedit to remove the enterprise RUS object.
Now we can continue uninstalling the server, so select Microsoft Exchange then click the Change/Remove button.
The Exchange 2000 or 2003 wizard will appear, click Next then select Remove in the Action dropdown box as shown in [B]Figure 3.14[/B]. Click Next.

[B]Note
[/B]If your organization relies heavily on Public Folders, you might want to leave the Exchange System Management Tools intact, as you can use them to administer Public folders on your Exchange 2007 server. Remember Exchange 2007 doesn't have a UI for Public Folder Management.
[IMG]http://www.msexchange.org/img/upl/image0201170861703937.jpg[/IMG]
[B]Figure 3.14: [/B]Exchange 2003 Installation Wizard Component Selection Page
On the Installation Summary page click Next and wait for the Exchange 2003 uninstallation process to complete ([B]Figure 3.15[/B]).


[B]Note[/B]
If the Exchange 2000 Setup files aren’t located on an accessible drive, network share, you will be prompted to insert the Exchange 2003 CD media during the uninstallation process.
[IMG]http://www.msexchange.org/img/upl/image0211170861703937.jpg[/IMG]
[B]Figure 3.15:[/B] Exchange 2003 Uninstallation Process
When the uninstallation process has completed click Finish to exit the Exchange 2003 Setup wizard ([B]Figure 3.16[/B]).
[IMG]http://www.msexchange.org/img/upl/image0221170861703937.jpg[/IMG]
[B]Figure 3.16:[/B] Exchange 2003 Successfully Uninstalled
Alright we’re done!
[B]Note[/B]
If the Exchange 2003 uninstallation for some reason fails, it may be necessary to remove the Exchange 2003 Server by deleting the Server object in the Exchange System Manager or even via ADSIEdit if this isn’t possible. But please don't delete the respective legacy (Exchange 2003) Administrative Group, as the user's legacyDNs still points there, even though their mailboxes are being moved in a native organization.
[B]Conclusion[/B]

Doing a transition from an Exchange 2000 or 2003 Server to an Exchange 2007 in the same Active Directory Forest is a straightforward process, and since Exchange 2007 co-exists just fine with legacy Exchange servers, you can do the transition at your own pace. Co-existence support is laudable as a transition process typically happens in several phases. This is especially true if you’re going to do a transition from multiple legacy Exchange Servers to multiple Exchange 2007 Servers.

I like the fact that the Exchange 2007 Setup wizard knows when Exchange 2007 is deployed in an existing legacy Exchange organization, and in this case prompts you to create a routing group connector so that mail flow is established between the legacy routing group and the Exchange 2007 routing group. It’s also nice to see that Exchange 2007 Setup, in this case, creates a Public Folder database and automatically adds the Exchange 2007 Server to the OFFLINE ADDRESS BOOK and SCHEDULE+ FREE BUSY system folders replica lists, so you only have to concentrate on replicating Public Folders.

Finally it’s a real pleasure working with the Exchange 2007 Move Mailbox wizard (or Move-Mailbox cmdlet) in order to move legacy mailboxes to an Exchange 2007 Mailbox Server, but I must admit, support for Public Folder management in the Exchange 2007 Management Console GUI is missed.


[/LEFT]