Post by David on Aug 13, 2012 22:20:07 GMT 5.5
Upgrade from Exchange 2007 to Exchange 2010
Exchange Server 2007
Our example company, called Inframan, has approximately 500 employees. Most of them are located on the internal network, but there are also quite a number of employees who access the Exchange 2007 environment from the Internet. On the internal network, a mix of Outlook 2003 as well as Outlook 2007 is being used, and remote workers have a laptop with Outlook 2007, and a mix of mobile devices using ActiveSync to keep in sync with the Exchange Server 2007 environment. Being a typical customer, Inframan also uses Public Folders, not only for free/busy information and to download the Offline Address Book, but also for storing company wide documents, digital invoices, etc.
From a message hygiene perspective, an Exchange Server 2007 Edge Transport Server is used between the Internet and the internal network. The Edge Transport Server has anti-spam enabled; Real-time Block Lists (RBL) are used in conjunction with Content Filtering to minimize the amount of spam coming in from the Internet, and a Threat Management Gateway (TMG) was recently installed. All clients now connect to the TMG Server and from the TMG Server, and client requests are forwarded to the Client Access Server.
The externally accessible fully qualified domain names (FQDN) that are in use at Inframan are webmail.inframan.nl and autodiscover.inframan.nl. These FQDN’s are used internally as well, but to prevent internal Outlook 2007 client to be rerouted to the TMG server a “split DNS” is used. Factoring in this internet-facing security, the external IP address for webmail is the external address of the TMG server, while the internal IP address for webmail is the IP address of the Exchange 2007 Client Access Server. To achieve this, a DNS zone is created on the internal DNS server for ‘inframan.nl’, where the internal Address (“A”) records are stored.
All external IP addresses for inframan.nl must be stored in the internal DNS zone. If you forget to, for example, include the Address record of the external webserver, then internal clients cannot resolve its IP address, and accessing the site via an internet browser will fail!
This setup has been working successfully for a couple of years now, but since Inframan needs to upgrade their hardware, it was decided to upgrade to Exchange Server 2010 SP1 at the same time.
Exchange Server 2007 – 2010 coexistence
it’s worth noting here that Exchange Server 2007 and Exchange Server 2010 can coexist in one Active Directory, but there are a couple of caveats in such a scenario:
•An in-place upgrade is not supported, so you cannot install Exchange Server 2010 SP1 on top of any of the existing Exchange Server 2007 servers;
•The Internet-facing Active Directory site has to be upgraded first. In the Inframan scenario this is not important since there’s only one site, but you have to be mindful of this fact;
•Exchange Server 2007 CAS & HUB servers will not work against an Exchange Server 2010 Mailbox Server;
•Likewise, Exchange Server 2010 CAS & HUB servers will not work against an Exchange Server 2007 Mailbox Server.
The implications are this are fairly clear; Inframan needs to install a new Exchange Server 2010 Mailbox Server and a new combined Exchange Server 2010 CAS and HUB Server into the existing Exchange Server 2007 environment.
However, the Exchange Server 2007 Edge Transport Server can work against an Exchange Server 2010 Hub Transport Server, and can be replaced by an Exchange 2010 Edge Transport Server after the installation of the Exchange Server 2010 Hub Transport Server.
The upgrade path
The upgrade path for the Inframan scenario is as follows:
1.Upgrade the Active Directory Schema;
2.Upgrade the Active Directory Forest Configuration;
3.Upgrade the Active Directory Domain(s) Configuration;
4.Install the combined Exchange 2010 CAS/HUB Servers;
5.Install the new Exchange 2010 Mailbox Server;Move the access methods from Exchange 2007 CAS to Exchange 2010 CAS;
6.Change the message flow from the Internet to the Exchange 2010 Hub Server;
7.Move all resources from Exchange 2007 to Exchange 2010;
8.Install the Exchange 2010 Edge Transport Server;
9.Decommission Exchange Server 2007 from the Exchange organization.
Of course, before you try and upgrade, you need to make sure you have all of the prerequisites in place for Exchange 2010 SP1 with respect to Active Directory, which are:
•The Schema Master has to be Windows Server 2003 SP2 or later;
•The Global Catalog Servers need to be Windows Server 2003 SP2 or later;
•Active Directory needs to be running in at least “Windows Server 2003 Native mode” and it needs to be in at least “Windows 2003 Forest Functional Level”.
Microsoft has a Supportability Matrix where you can quickly check all requirements for Exchange Server 2010, which can be found on the Microsoft TechNet site:. As far as Exchange 2007 is concerned, it needs to be on at least an Exchange Server 2007 Service Pack 2 level. Assuming you’ve got all the prerequisites in place, let’s take a look at the steps of the upgrade.
Active Directory Upgrades
Changing the Active Directory Schema isn’t that different than in the Exchange 2003 to Exchange 2010 upgrade path, so I won’t go into detail about that. It’s just a matter of running the setup.com /PrepareSchema command to achieve this.
However, bear in mind that when you change the Active Directory configuration in step 2 of the upgrade, you’re actually changing quite a lot. The Exchange 2010 configuration is stored in the same Administrative Group as the Exchange 2007 configuration, called Administrative Group (FYDIBOHF23SPDLT), but quite a lot of things have changed under the hood. When you dive into the Configuration Partition using tools like LDP or ADSIEdit, you’ll notice many changes And, because of these changes, the Exchange 2007 Administration Tools will not or cannot see the Exchange Server 2010 Server objects
So, you’ll need both the Exchange 2007 and Exchange 2010 versions of the Administration Tools to manage a coexistence scenario with Exchange Server 2007 and Exchange Server 2010, and thankfully both versions of the Administration Tools can coexist on the same Management Server or Management Workstation. Background aside, you can accomplish the changing of the Active Directory Forest Configuration using the setup.com /PrepareAD command.
Next, when running the setup.com /PrepareDomain (or /PrepareAllDomains if you want to change all of the domains with Exchange Server objects in one command), the Active Directory Domain is finally prepared for Exchange Server 2010.
Of course, there’s no actual need to change the Active Directory manually as outlined above. You can also start the graphical setup program (setup.exe on the installation media) and just install the first server, which automatically invokes the Active Directory changes, assuming you have sufficient permissions of course
Installing the Servers
After the Active Directory is updated, it’s time to install the actual Windows servers that will host the Exchange Server 2010 Server Roles. Personally, I always recommend using Windows Server 2008 R2. It is, quite simply, a better product than Windows Server 2008 SP2, and is also more efficient, especially within the network stack. Speaking of efficiency, you also don’t need to install the 85 hotfixes required when installing Windows Server 2008 SP2.
So, we are going jump ahead to after the installation of Windows Server 2008 R2 is complete, and the following prerequisites are now required before installing the first Exchange Server 2010 Server role:
•.NET Framework 3.5.1;
•Office 2010 Filter Pack (needed for attachment filtering);
•Hotfixes KB982867, KB979744, KB983440 and KB977020.
Internet Information Server is part of the prerequisite software as well, but this feature will be installed as part of the actual Exchange Server role installation, so it’s not really worth mentioning here. Additionally, over time, the last bullet won’t be a manual step anymore, as the Windows Server 2008 R2 Server will eventually be automatically updated using Windows Update (or your own patch management solution in the future, of course).
When the fresh server is fully updated, it’s time to install the Exchange Server 2010 SP1 Client Access Server and Hub Transport Server roles.
1.Logon to the freshly installed and updated Windows 2008 R2 server as an Enterprise Administrator, and navigate to the installation media. Start the graphical setup application, setup.exe
2.Follow the installation wizard (download the additional language packs if needed), but do not select the Typical Setup option (which will install the Client Access, Hub Transport and Mailbox Server role on the same server). Instead, select the Custom Setup, which will allow you to select exactly which Server Roles you want to install.
3.In the Server Role Selection Window, select the Client Access Role and the Hub Transport Role, and right under the file path you have to check the Automatically install Windows Roles and Features required for Exchange Server option. If you do this, then the additional necessary Server Roles (like Internet Information Server) will be automatically installed.
4.The next step is to enter the external domain name which, in our example, is webmail.inframan.nl. This FQDN is used in all ExternalURL properties on objects like the OWA Virtual Directory, ECP Virtual Directory, Exchange Web Services Virtual Directory, etc.
Click Next to continue the wizard;
5.If all goes well you’ll reach the readiness checks, which should complete successfully. If something goes wrong, then the setup application will tell you exactly what is wrong and what to do to correct the issue(s):
This is obviously a drastic error message
This error message is quite obviously Stating that the Active Directory and Windows Server prerequisites are fine, but the Inframan environment is still running an older version of Exchange Server 2007. When there are minor issues, there’s the option to correct them on the fly, although personally I’m not a great fan of doing this. In any case, every now and then updates will not be processed correctly, or the server needs to be rebooted, but the setup application unfortunately doesn’t notice this. If you continue regardless, you can end up with all kinds of strange issues when the setup is finished (if it finishes at all). So, the Inframan Exchange 2007 servers need to be upgraded first, at least to Exchange Server 2007 SP2. When this is finished, the Exchange Server 2010 SP1 setup program can be started again;
6.When the issues are resolved, the server is rebooted and the Exchange 2010 SP1 setup program is started again. Just like in the previous steps, follow the wizard and install the combined Hub Transport and Client Access Server. If requested reboot the server;
7.When these server roles are installed, the Exchange Server 2010 SP1 Mailbox Server can follow. The requirements for this machine are the same as the first server we installed, so we just need to ensure the prerequisites described at the start of this Server Installation section are applied. Once that’s been done, just logon to this new server as an Enterprise Administrator, navigate to the installation media and start the (graphical) setup program.
8.Follow the wizard as before, but this time select a typical setup, and in the Server Role Selection window, select only the Mailbox Server role. Just like in Figure 3, check the Automatically install Windows Roles and Features required for Exchange Server checkbox to have the prerequisites automatically installed.
9.Follow the rest of the wizard and install the Exchange Server 2010 SP1 Mailbox Server Role. If possible, install the latest Update Rollup Fix for Exchange Server 2010 SP1 on both servers
After preparing the two new Exchange 2010 servers, it is time to think about moving resources from Exchange 2007 to Exchange 2010. The following steps need to be performed:
1.Change the message flow from Exchange 2007 to Exchange 2010;
2.Change the external client access from Exchange 2007 to Exchange 2010;
3.Configure the Exchange 2010 Mailbox Server and configure the Public Folder replication;
4.Move mailboxes from Exchange 2007 to Exchange 2010;
5.Move other resources to Exchange 2010;
6.Decommission the old Exchange 2007 servers.
There’s no real need to follow the first three steps in this specific order; it is also possible to, for example, configure the Exchange 2010 Mailbox Server and setup Public Folder replication first. It’s really up to you to choose what to do first.
Changing Message Flow
After installing both servers, the environment now has two Exchange Server 2007 servers and two Exchange Server 2010 servers, with all message flow and all client access is still going through the Exchange Server 2007 HUB server. If messages need to go from an Exchange 2007 Mailbox to an Exchange 2010 Mailbox, they are picked up by the 2007 HUB Server, sent to the 2010 HUB Server using SMTP, and from there delivered into the Exchange 2010 Mailbox.
When messages are delivered from the Internet, through the 2007 Edge server, and destined for an Exchange 2010 Mailbox, they are also delivered to the 2007 HUB Server, sent to the 2010 HUB server using SMTP, and then delivered to the appropriate Exchange 2010 Mailbox.
So, we have to figure out a way to change the message routing and the client access methods with as little downtime as possible.
Thankfully, changing the message flow is relatively straightforward, as an Exchange 2010 Hub Server can cooperate with an Exchange 2007 SP2 or SP3 Edge Transport Server. To accomplish this, the existing Edge Synchronization (between the Exchange 2007 Edge Server and Exchange 2007 Hub Server) needs to be removed, and a new Edge Synchronization between the Exchange 2007 Edge and Exchange 2010 Hub Server needs to be created.
Later on, a new Exchange 2010 Edge Server can be installed in the DMZ, and an Edge Synchronization between that Exchange 2010 Edge Server and the Exchange 2010 Hub Server can be created. When this is accomplished, the mail flow from the firewall can be redirectedto the new Exchange 2010 Edge Server, and the old Exchange 2007 Edge Server can be removed. I’ll get back to this particular subject in my last article on upgrading Exchange Server 2007 to Exchange Server 2010.
To create a new Edge Subscription between the Exchange 2007 Edge Server and the Exchange 2010 Hub Transport Server, follow these steps:
1.Logon to the Exchange 2007 Edge Server and an administrator, open the Exchange Management Shell, and enter the following command:
2.Copy the New-Edge.XML file to the local disk of the Exchange 2010 Hub Transport Server;
3.On the Exchange 2010 Hub Transport Server, open the Exchange Management Console, navigate to the Organization Configuration, select Hub Transport and select the Edge Subscription tab;
4.Delete the existing Edge Synchronization between the Exchange 2007 Hub and Exchange 2007 Edge Transport Server;
5.New Edge Subscription
6.In the New Edge Subscription wizard, enter the Active Directory site which the Edge Subscription has to use, and select the New-Edge.XML file that was created in step 1 And, finally, click New. The Edge Subscription is now created, but it is not yet active;
7.Open an Exchange Management Shell and enter the following command:
8.The synchronization process is started, and all SMTP transport is now sent between the Exchange 2007 Edge Transport Server and the Exchange 2010 Hub Transport Server.
For the normal SMTP message flow, only port 25 needs to be opened on both firewalls. For the synchronization to take place from the internal Exchange 2010 Hub Transport Server to the DMZ Exchange 2007 Edge Transport Server, port 50636 needs to be opened, but only from the inside out -There’s no need to open this port from the DMZ back to the internal network.
This can easily be checked by examining the header information of a new message. It should read something like:
This sample SMTP message was delivered at the Exchange 2007 Edge Transport Server (2007Edge.inframan.nl), sent to the Exchange 2010 Hub Transport Server (2010CASHUB.infra.local) and then to the Exchange 2007 Hub Transport Server (2007cashub.infra.local). From there it is delivered into a mailbox.
Changing the External Client Access
Before the external client access can be changed we need to dive into some of the Client Access Server internals. For starters, be aware that the Exchange 2010 Client Access Server cannot work directly with the Exchange 2007 Mailbox Server role. This is especially true for the Outlook Web App; when a client, for example Internet Explorer, enters the Exchange 2010 Client Access Server and needs to access an Exchange 2007 mailbox, the client is silently redirected to the Exchange 2007 Client Access Server!
The problem this creates is that both the Exchange 2007 CAS and the Exchange 2010 CAS server cannot use the same FQDN, i.e. webmail.inframan.nl. Therefore, when changing the client access, the ‘old’ Exchange 2007 Client Access Server must now be accessible using an FQDN like legacy.inframan.nl.
If you’ve done this correctly, then when clients access the Exchange 2010 CAS Server using webmail.inframan.nl/owa, and their mailbox is still on Exchange Server 2007, they are silently redirected to legacy.inframan.nl/owa, which is actually the Exchange 2007 CAS Server. This therefore means that the current publishing rules on the TMG Server need to be changed as well for this upgrade to work:
--------------------------------------------------------------------------------
1.The Unified Communications certificate has to include the legacy.inframan.nl FQDN. Instead of using a new Unified Communications Certificate it is also possible to use a wildcard certificate, which is fully supported in Exchange Server 2010.
2.The webmail.inframan.nl publishing rule needs to be changed to point to the new Exchange 2010 Client Access Server;
3.The legacy.inframan.nl FQDN needs to be created, and it has to point to the Exchange 2007 Client Access Server;
4.The autodiscover.inframan.nl publishing rule needs to be changed, and it has to be pointing to the Exchange 2010 Client Access Server.
In a coexistence scenario there are three Fully Qualified Domain Names (FQDN):
•Webmail.inframan.nl – this points to the external-facing Client Access Server, which is used for all services (OWA, ActiveSync, Outlook Anywhere etc.). This is the current Exchange 2007 CAS Server, but will soon be changed to the new Exchange 2010 CAS Server;
•Autodiscover.inframan.nl – this points to the external-facing Exchange 2007 CAS Server and, after the change, it will point to the new Exchange 2010 CAS Server. Outlook 2007 (and higher) clients are able to retrieve autodiscover information, even when their mailbox is still on Exchange 2007;
•Legacy.inframan.nl – this points to the old Exchange 2007 CAS Server after the switch to the Exchange 2010 CAS Server. It is used for when OWA clients are redirected to the Exchange 2007 CAS server because the user’s mailbox is still on Exchange 2007.
Just to make sure we’re all absolutely clear on this, the webmail.inframan.nl FQDN will give access to the Exchange 2010 Client Access Server while the legacy.inframan.nl FQDN will give access to the old Exchange 2007 Client Access Server. Outlook Web Access for mailboxes still on Exchange Server 2007 will be redirected to the legacy FQDN.
To prepare for the upcoming changes, we have to follow these steps, which we’ll cover in more detail in a moment:
•Request a new SSL Certificate for the Exchange 2010 Client Access Server;
•Create a new rule on the TMG Server called “Legacy Inframan”, and publish OWA for Exchange 2007 using this publishing rule;
•Enable Outlook Anywhere on the Exchange 2010 Client Access Server;
•Move the Offline Address Book (OAB) and enable web-based distribution;
•Disable Outlook Anywhere on your Exchange 2007 Client Access Server;
•Reconfigure external DNS, and update the Publishing Rules on TMG.
An SSL certificate on the Client Access Server should contain the Common Name webmail.inframan.n’ and the autodiscover.inframan.nl hostname in its Subject Alternatives Name field. The easiest thing to do at this stage is to use only one SSL certificate, using the legacy.inframan.nl hostname as well:
1.Logon to the Exchange 2010 Client Access Server and open the Exchange Management Console. Navigate to the Server Configuration and, in the navigation pane (the left pane), select Client Access. In the actions pane (the right pane), select Request New Certificate;
2.Follow the New Certificate Wizard to create a new certificate request, using the three hostnames I mentioned earlier.
3.A new request file is created, and should be submitted to the Certificate Authority. I always recommend one of the supported certificate vendors (check Microsoft knowledge base article KB929395 for this), but an internal Windows 2008 CA can be used as well;
4.After the certificate is returned from the CA, save the certificate file on the local disk of the Exchange 2010 Client Access Server, and finish the certificate wizard;
5.When you’re finished, use the Enable Exchange Services option in the actions pane. In the inframan scenario, only the IIS service is used by the new certificate.
in Exchange Server 2010, usage of a wildcard SSL certificate is also fully supported. When the certificate is configured and working on the Exchange 2010 Client Access Server, the certificate is exported to a file on the local hard disk. This is a different file from the one we created in step 4 above; this is a backup file of the Exchange certificate. It is then imported to the Exchange 2007 Client Access Server and the TMG Server (which, if you recall, the company has upgraded to from an ISA Server, as mentioned in part 1). As mentioned earlier, one SSL certificate can be used on all servers. You should also bear in mind that, while changing the certificate on the Exchange 2007 Client Access Server and the TMG server is a small update, it will cause a small outage in the messaging service.
The next step is creating a new rule to publish Exchange 2007 OWA using the legacy.inframan.nl hostname, b ut this shouldn’t be too difficult, so I won’t go into detail. However, I will go into detail regarding How to enable Outlook Anywhere on the Exchange 2010 Client Access Server:
1.Logon to the Exchange 2010 Client Access Server and open the Exchange Management Console. Navigate to Server Configuration and select the Exchange 2010 Client Access Server;
2.In the Actions Pane, click on Enable Outlook Anywhere. The wizard to enable Outlook Anywhere will start, and you should enter the external hostname (i.e. webmail.inframan.nl)here. Select the appropriate authentication mechanism, which in this example will be Basic Authentication.
3.Click on Enable to continue the wizard, and a warning message will be displayed saying Outlook Anywhere will be enabled in approximately 15 minutes. Click on Finish to end the wizard.
While the Exchange Management Console is still open, we can get started with moving the Offline Address Book and enabling web-based distribution on the Exchange 2010 Client Access Server:
4.Navigate to the Organization Configuration and click on Mailbox. In the results pane, select the Offline Address Book tab;
5.Right–click on the Default Offline Address Book and select Move, using the Browse button to select the Exchange 2010 Mailbox Server. Click on Move again to continue. A warning message is displayed, informing you that the files are copied to the new target server, at which point you can click on Finish to end the wizard.
6.Right-click on the Default Offline Address Book again; select the property sheet, and then select the Distribution tab, where the 2007 Client Access Server is still listed. Remove the old server, and then click Add to add the Exchange 2010 Client Access Server as a distribution point. Finally, click on OK to apply the changes and close the wizard.
The Offline Address Book is only generated once a day, by default at 4:00 am. So, when you are creating new mailboxes, you have to be careful as they might not show up in this OAB until the next day! On the other hand, the Client Access Server polls the Mailbox Server for updates on the OAB once every 480 minutes (8 hours). Be aware of these issues when troubleshooting OAB issues.
Next, we need to disable Outlook Anywhere on the Exchange 2007 Server:
1.Logon to the Exchange 2007 Client Access Server, navigate to the Server Configuration, and select Client Access Server. Select the 2007CASHUB Server and, in the Actions Pane, select Disable Outlook Anywhere;
2.Follow the wizard to disable Outlook Anywhere;
3.It is also possible to use the Exchange Management Shell to complete this action by entering the following command:
At this stage, the Exchange 2007 Client Access Server needs to be reconfigured, so that legacy mailboxes on Exchange 2007 are still connected to the appropriate URL during the coexistence phase. To do this, logon to the Exchange 2007 Client Access Server, open the Exchange Management Shell, and enter the following commands:
The last step is to reconfigure the TMG web publishing rules for OWA, Autodiscover and ActiveSync, so that they all point to the new Exchange 2010 Client Access Server, and also to add the legacy host name to the external DNS, and point it to the external interface of the TMG Server. An important step here is to change the web listener, as it needs to provide the single sign-on mechanism that enables the seamless redirection from the Exchange 2010 Client Access Server to the Exchange 2007 Client Access Server.
Right now we have the following scenario:
•When a browser goes to the Exchange 2010 Client Access Server using webmail.inframan.nl/owa to open an OWA session, the client is redirected to the Exchange 2007 Client Access Server for as long as the mailbox is still on the Exchange 2007 Mailbox Server. The legacy.inframan.nl/owa URL is used for redirection;
•When an Outlook Anywhere client connects to the Exchange 2010 Client Access Server, this server connects to the Exchange 2007 Mailbox Server to retrieve the mailbox data. The RPC protocol is used for this;
•Autodiscover information and the Offline Address Book are downloaded by Outlook 2007 and Outlook 2010 clients from the Exchange 2010 Client Access Server;
•An ActiveSync client connects to the Exchange 2010 Client Access Server, and this server retrieves the mailbox data from the Exchange 2007 Mailbox Server using the RPC protocol.
The Remote Connectivity Analyzer (RCA) can be used to test the Exchange configuration, and can be found on www.testexchangeconnectivity.com.
If all goes well, then the Outlook Anywhere clients will never notice that something has changed, nor will the Windows Mobile clients. Only OWA clients will be redirected from the webmail.inframan.nl URL to the legacy.inframan.nl URL, and this is clearly visible when using OWA after the redirection:
Configuring the Exchange 2010 Mailbox Server
After installing the Exchange 2010 Mailbox Server, there’s some configuration that needs to be done. The first step is to change the default location of the Mailbox Database from the standard location (C:\Program Files\Microsoft\Exchange Server\v14\Mailbox )to a separate disk, which is not difficult.
Since Inframan is using Public Folders, a new Public Folder Database needs to be created on the Exchange 2010 Mailbox Server:
1.Logon to the Exchange 2010 Mailbox Server as an administrator and open the Exchange Management Console. Navigate to Organization Configuration and select the Database Management Tab;
2.In the Actions Pane, click on New Public Folder Database... and follow the wizard. Enter a new name for the Public Folder Database and select a server. Note that you can only choose an Exchange 2010 Mailbox Server role, even if we are in a coexistence scenario. This is because it is not possible to manage an Exchange 2007 object from an Exchange 2010 Management Console (or Shell);
3.Select a location where the Public Folder database and its accompanying log files will be stored. By default, the C:\Program Files\Microsoft\Exchange Server\v14\Mailbox directory is selected, but it’s a best practice to use another disk. Enter the new location and click New to create the Public Folder database and mount it.
4.Now we need to configure the mailbox database on Exchange Server 2010 to use the newly created Public Folder database. To do so, select the mailbox database and open its properties. In the properties window, select the Client Settings tab. Select the 2010 Public Folder Database (the default is the 2007 Public Folder database) and select the default Offline Address Book.
Since all Public Folder information is still stored in the Public Folders, we have to setup replication between both Public Folder databases, both for the system folders (i.e., for free/busy information and the Offline Address Book) as well as the regular user folders;
1.Logon to the Exchange Server 2007 Mailbox Server role, open the Exchange Management Console and, in the Tools section, open the Public Folder Management tool;
2.To add the Exchange 2010 Public Folder database to the list of replicas, select a public folder’s properties and select the Replication tab. Add the Public Folder Database on the Exchange 2010 Server and click OK. Repeat this for all System Folders that are available on the Exchange 2007 Server (i.e. Free/Busy and Offline Address Book folders).
3.The user Public Folders then need to be replicated to the Exchange 2010 Public Folder database as well. It is possible to manually configure all Public Folders with a new replication partner, but it’s better to use PowerShell scripts that Microsoft delivers with Exchange Server 2010. Open the Exchange Management Shell and navigate to the Scripts directory by entering the CD $ExScripts command, and execute the following script:
4.This will add the Exchange 2010 public folder database as a replication partner on all public folders that are beneath the root folder. Public Folder replication is not the fastest mechanism in Exchange Server so, depending on the number of Public Folders and the size of the database, it can several hours (or, indeed, days) to complete.
When the Public Folder statistics are checked after the replication has started running, it will be obvious that there’s data in the Public Folders on the Exchange Server 2010 Mailbox Server:
At this point, we still have a combined Exchange 2007 / Exchange 2010 environment, although the SMTP mail flow is now going through the Exchange 2010 Hub Transport Server, and all clients connect to the Exchange Server 2010 Client Access Server. However, since all mailboxes are still on Exchange Server 2007, the requests are either redirected to the Exchange 2007 Client Access Server (for OWA), or the Exchange 2010 Client Access Server is talking directly to the Exchange 2007 Mailbox Server.
Moving Mailboxes
As you are presumably aware, Exchange 2007 resources are managed from the Exchange 2007 management tools, i.e. the Exchange Management Console and the Management Shell. Exchange 2010 resources, on the other hand, are managed from the Exchange 2010 management tools, and you cannot manage Exchange 2007 resources from the Exchange 2010 management tools, or vice versa. The good thing is that if you are fortunate enough to have a management server, you can install the management tools of both versions on the same machine, and thereby save yourself some trouble.
To move mailboxes from Exchange 2007 to Exchange 2010, you have to initiate the move from the Exchange 2010 Management Shell or Management Console.
•Logon to the Exchange 2010 Server and open the Exchange Management Console.
•Navigate to the recipient configuration and click Mailbox. In the results pane, a list of mailboxes appear, and if there are a large number of mailboxes, then you can create a filter on the view. For example, you can view only the mailboxes in a particular mailbox database.
•In the results pane, select a mailbox, right-click on it, and select New Local Move Request…
•A wizard appears, pre-loaded with the mailbox you just selected. In the Target mailbox database field, select the Exchange 2010 Mailbox Database and click Next to continue;
•The next step is to specify what Exchange has to do when corrupt messages are found in the source (Exchange 2007) mailbox. It can skip the mailbox, which is the default, causing Exchange will stop moving the mailbox. You can also skip just the corrupted messages, but then you have to enter the maximum number of messages to skip. I usually leave this with its default setting, so when corrupted messages are found, the move process is skipped for that particular mailbox. Click Next to continue;
•A summary is shown and, when all is well, you can click New to actually start the Move Request. After 10 to 20 seconds, the move request is created and submitted, and the wizard is finished. The actual moving of mailbox data still has to start, as it is only the move request that has been initiated (the actual move will take place in the background). To view the status of the move request, select Move Request under recipient configuration in the Exchange Management Console. You can right-click on the move request to see its properties:
•When the mailbox is moved to Exchange 2010 while you (or rather, the user whose mailbox you just moved) have Outlook open, a message is shown when the actual move has finished saying the Outlook client has to be restarted:
•Restart Outlook for the changes to take effect and to continue working. To check if the Outlook client really connects to Exchange 2010, you can right-click on the Outlook icon in the system tray (in the bottom right of the screen) and select Connection Status;
•The client now connects to the Exchange 2010 Client Access Server, and from there to the Exchange 2010 Mailbox Server. Since Public Folder replication was setup earlier, the data is now retrieved from the Exchange 2010 Public Folder;
•Repeat steps 3 to 6 for all mailboxes still on Exchange 2007;
•When all mailboxes are successfully moved to Exchange Server 2010, the move requests need to be removed as well. In the Exchange Management Shell, under Recipient Configuration and Move Request, select all the move requests and click on Clear Move Request. Now all of the mailboxes are on Exchange Server 2010.
Moving other resources
the Offline Address Book generation server was already moved to the Exchange 2010 Mailbox Server. Given that Address Lists, E-mail Address Policies, Accepted Domains etc are more or less the same in Exchange Server 2010, these do not need any attention at this point.
However, you do have to take care of Transport Rules and Journaling Rules. Normally, these are exported from Exchange 2007 and imported into Exchange 2010 when you install the Hub Transport Server role, but there are circumstances where you have to do this manually. To migrate Transport Rules from Exchange 2007, logon to the Exchange 2007 Hub Transport Server, open an Exchange Management Shell and enter the following command:
Copy the resulting file to the Exchange 2010 Hub Transport Server, open an Exchange Management Shell and enter the following command:
When you open the Exchange 2010 Management Console, the Transport Rules will now be visible and functional on the Exchange 2010 Hub Transport Servers:
At this stage, you have essentially migrated your entire message environment from Exchange Server 2007 to Exchange Server 2010, so it’s time to look at decommissioning the old environment.
Removing Exchange Server 2007
To start with, since all Public Folders are replicated from Exchange Server 2007 to Exchange Server 2010, it’s time to decommission the Exchange 2007 Public Folder Database. You cannot just delete this Public Folder database since it still contains a replica of this data, and the Exchange 2007 Mailbox Database still has a referral to the Exchange 2007 Public Folder database. To remove the replica, there’s a script in the $exscripts directory on the Mailbox Server:
•Logon to the Exchange 2007 Mailbox Server and open the Exchange Management Console. Navigate to the Server Configuration and select Mailbox Server. In the results pane, select the Mailbox Database on the Exchange 2007 Server and open its properties. In the Client Settings tab, change the default Public Folder database referral to the Exchange 2010 Public Folder database referral.
•Next, logon to the Exchange 2010 Mailbox Server, open the Exchange Management Shell, and change to the scripts directory by entering the CD $exscripts command.
•Enter the following command to start the script which will move all replicas from Exchange 2007 to Exchange 2010:
The script will be finished in approximately 20 seconds, but it will only change the replication settings on the Public Folder databases. The actual Public Folder replication will take place when the script has finished, and this replication can take quite some time, depending on the amount of data in the Public Folders of course. I usually leave it running overnight and continue the next morning when everything has replicated out, but there are known scenario’s where replication took about 48 hours to complete.
•Running the MoveAllReplicas.ps1 script from the Exchange Server 2010 server actually touches the 2007 Public Folder database. Therefore, the Public Folder database cannot be removed anymore from within the Exchange Server 2007 Management Console; this process now fails with a "future version of Exchange" error message:
•To remove the Public Folder database from the Exchange 2007 server, logon to the Exchange 2010 Server, open the Management Shell and enter the following command:
This will check the Public Folder Database for any Public Folder replicas and, if none are found (which should be the case of course since we removed this in step 2), the Public Folder database will be dismounted and removed:
•Now, when you check the Exchange 2007 Management Console, you’ll see that the Public Folder database has been removed;
•Remove the Exchange 2007 Mailbox Database as well.
Now that the Mailbox Database and the Public Folder Database are removed, the Exchange 2007 Mailbox Server can be removed. On the Exchange 2007 Mailbox Server, open the Control Panel and open the Applications option. In the results list, select the Exchange 2007 Server and select Uninstall. The setup application starts in "maintenance mode", and you can just follow the wizard to uninstall Exchange Server 2007.
Before removing the Exchange 2007 Client Access and Hub Transport Server roles, make sure that no other clients are accessing the Client Access Server (naturally, they shouldn’t be, since we already removed the Exchange 2007 Mailbox Server. However, if clients do access the Exchange 2007 Client Access Server, it will result in an error message) or the Hub Transport Server (which can happen in scenario’s with applications that use SMTP relaying).
Once you’re sure that no clients are trying to access them, the Exchange 2007 Client Access Server and Hub Transport Server can be removed as well. Logon to these servers and open the Control Panel. Just like the Exchange 2007 Mailbox Server, select the Exchange 2007 Server option from the applications menu, and click Uninstall. The setup application will start in "maintenance mode" again, and you can follow the wizard to uninstall Exchange 2007 from these servers.
The only step left is to remove the "legacy publishing rule" from the Forefront TGM Server.
As a side note, it might be a good idea to install a recovery Active Directory and Exchange 2007 in your lab environment. In our sample environment, there’s a couple of years worth of backup database. When you need to restore one of these backups, for legal purposes for example, then it’s a good idea to have an up-and-running Exchange 2007 environment you can use to restore these old backups.
Edge Transport Server
The last server role that needs to be replaced (although this can be done earlier in the process, but preferably after the Exchange 2010 Hub Transport Servers are installed) is the Exchange 2010 Edge Transport Server.
The prerequisites for an Edge Transport Server are almost the same as a Hub Transport Server, except that it’s not normally a member of the (internal) domain. Also, you have to set a Fully Qualified Domain Name on the Edge Transport server before installing it.
Once all prerequisite software has been installed (Windows Server 2008 SP2 X64 or Windows Server 2008 R2, .NET Framework 3.5 SP1, PowerShell 2.0, Active Directory Lightweight Directory Services.), you can install Exchange 2010. Just like a regular Exchange 2010 Server, you can have the prerequisite software automatically install during the Exchange 2010 setup, but I prefer to do it myself in advance. This way, I have full control over the prerequisite installation and control the necessary reboots.
•On the new Exchange 2010 Edge Transport Server (to be), logon as an administrator and navigate to the installation media. Start the graphical setup application, setup.exe;
•Follow the wizard until you reach the Server Role Selection window, where you should select the Edge Transport Role. Note that as soon as you select this role, the other server roles are greyed out. You cannot combine the Edge Transport Server with any other server role;
•Check the Automatically install Windows Server roles and features required for Exchange Server check box, which will install server roles and features needed for Exchange Server. Click Next to continue;
•Follow the wizard and do the prerequisite check. If something is missing, it is reported here, and you can correct them. If needed, reboot the server and continue the wizard to install the Edge Transport Server role.
When the Edge Transport Server role has been installed, the server needs to be rebooted as well (or possibly again, depending on how much trouble you had installing the prerequisites). After rebooting, configure the Edge Transport Server anti-spam functionality as desired.
•When the server is fully operational, open an Exchange Management Shell and enter the following command:
•A new subscription file is created, which you need to copy to the Exchange 2010 Hub Transport Server;
•Logon to the Exchange 2010 Hub Transport Server and open the Exchange Management Console. Navigate to the Organization Configuration and select Hub Transport. Select the Edge Subscription tab and remove the current Edge Subscription (with the Exchange 2007 Edge Transport Server). This will mean you don’t have any inbound or outbound SMTP services!
•In the Actions Pane, click New Edge Subscription and follow the wizard. Bind the Edge Subscription to the Active Directory site you’re using (the Default-First-Site-Name in a default configuration), and select the Edge2010.xml file we created earlier;
•When the Edge Subscription is created, open the Exchange Management Shell and enter the following command:
•The Edge Synchronization will now start. All you have to do now is reconfigure the SMTP mail flow from the external firewall to the Exchange 2010 Edge Transport Server and you’re back in business.
You can now safely remove the Exchange 2007 Edge Transport Server.
Decommission PST files
A typical migration scenario would be a transition from Exchange 2007 to Exchange 2010 (although the same it true of course a transition from Exchange 2003 to Exchange 2010), followed by decommissioning PST files. In the past, Exchange used to have relatively small mailboxes, and users would store data in PST files, which are always difficult from a SysAdmin’s perspective:
•PST files are stored on a local workstation, and are therefore not backed up;
•PST files are stored on a laptops, which can be easily stolen (security breach);
•PST files are stored on a network share, which is slow and not supported.
Exchange Server 2010 now offers the Personal Archive, and in SP1 it is possible to locate the Personal Archive on a different Mailbox database, even on a different Mailbox Server from the users’ primary mailboxes
how to deal with importing PST files in mailboxes or in the Personal Archive. The only downside of this process is that it’s command line only, which can be difficult for a Windows SysAdmin more used to GUIs.
Suppose we have an Exchange administrator (ExAdmin) and, after he implemented Exchange Server 2010 SP1 (including the Personal Archives), he is now responsible for importing the PST files into the Mailboxes and Archives.
However, when the ExAdmin initially opens the Exchange Management Shell and enters the appropriate cmdlet (New-MailboxImportRequest) an error message is generated:
By default, no one has the required permission to perform these actions, and therefore the cmdlets are not available; to enable the mailbox import functionality, the “Mailbox Import Export” role needs to be assigned to the ExAdmin user. ExAdmin needs to Logon as the administrator (in this case, the user that first installed Exchange Server 2010, or anyone else who has been given the Organization Administrator privilege) and execute the following command:
The ExAdmin user now has the appropriate permission, and can execute the cmdlets after he closes and re-opens the Exchange Management Shell. That’s all it takes...
The cmdlet to import PST files into the mailboxes is New-MailboxImportRequest. It takes a number of parameters, but the most important ones are, of course, the mailbox and the path to the file share where the PST file is located. The request does not accept a local directory, so you have to use a file share, but there’s a snag here: when creating the file share, you have to grant the security group “Exchange Trusted Subsystem” read/write permissions on that file share. A nice feature to see in this cmdle is the –IsArchive parameter, which is responsible for importing a PST file into the user’s Personal Archive. However, note that to use the Personal Archive, you’ll need an Enterprise Client Access License (eCAL).
So, to import a PST file into Johan’s mailbox, you have to enter the following command:
You should be aware This command is not available in the Exchange Management Console in Exchange Server 2010 SP1 - only in the Exchange Management Shell.
Performing the actual import of the data into the mailbox is a process which runs on the Client Access Server, as explained earlier when I mentioned the Mailbox Replication Service. So, after entering the import cmdlet, it is therefore possible to close the Exchange Management Shell and log off from the server or management workstation which has the management tools installed.
To monitor the status of the import request, you can use the Get-MailboxImportRequest and the Get-MailboxImportRequestStatistics cmdlets when needed, combined with a selection of parameters, such as the demonstrated in the command below:
It is also possible to enter multiple requests at the same time, or close to each other. The requests will be queued, and when the Client Access Server picks up a request it will then process them sequentially.
Now let’s demonstrate how to monitor the progress of an import action. First of all, to import a PST file into the user Johan’s Personal Archive directly soon after starting the previous import into his primary mailbox), you can use the following command:
Now, when you enter the previous command for monitoring the import status, you’ll see two entries. In this example, the actual primary mailbox is already finished (100%) and the Archive import is still running:
Now that we’ve got the basics, I’ll mention that it’s possible to exclude certain folders during the import using the –ExcludeFolders parameter, and it is also possible to use a –SourceRootFolder parameter to define what data to import from within the source PST; everything outside of the targeted –SourceRootFolder will not be imported. Similarly, the –TargetRootFolder specifies the location in the mailbox where the import will store its data, for example in a \RecoveryFolder location in the mailbox.
Interestingly, it is also possible to perform bulk import of PST files. Suppose there are a number of PST files in the file share we’ve used earlier; it is now possible to request a list of those PST files, and pipe this output into the New-MailboxImportRequest:
The mailbox which is to be targeted, is identified from the file name of the PST file; so student-1.pst will be automatically imported into the mailbox named “student-1”. When importing multiple PST files in the same batch, you’ll notice that only one or two imports are active at the same time; other requests have the status “Queued” and are only processed when previous imports are finished.
One of the issues top bear in mind is to not overload the Client Access Server and the Mailbox Server during a PST import, which is why the import process is throttled. The good thing is that this throttling is fully configurable; so you can, for example, really stress your Mailbox Servers and Client Access Servers when you’re performing bulk imports on a Saturday or Sunday. The configuration for this is stored in a config file called MSExchangeMailboxReplication.exe.config, which is stored (by default) in the directory C:\Program Files\Microsoft\Exchange Server\V14\Bin on the Client Access Server; when you open it with Notepad, you’ll find some “MaxActiveMoves” parameters which you can edit (which you can see in the image below). Please note that this file exists on every Client Access Server, which means that you’ll need to adjust across all CAS machines if you have a large Exchange organization & are doing a bulk import / export.
As you can probably guess, increase the number of moves per target MDB and your Import Request will process more than just two PST files at a time
Red Gate now offers the PST Importer, which is a handy graphical tool for importing PST files directly into a mailbox or a mailbox’ Personal Archive.
The PST importer is a 32-bit application, but it can of course run on an X64 Exchange Server. The only thing is that it uses some Outlook DLLs, so your best option is to run it on a management workstation (X64) that has Outlook installed. Using this tool, you can either import the PST files immediately, or you can schedule the import to run off business hours.
There’s one (design) issue that you need to bear in mind in general when dealing with PST files. When designing your Exchange 2010 environment, especially the storage needed for the Mailbox Databases, please take into account the amount of PST data you’re likely to be managing. I am constantly impressed by the number of TB’s currently in use by PST files, and if you don’t design and provision properly, you’ll run out of disk space before your migration has finished!
Exchange Server 2007
Our example company, called Inframan, has approximately 500 employees. Most of them are located on the internal network, but there are also quite a number of employees who access the Exchange 2007 environment from the Internet. On the internal network, a mix of Outlook 2003 as well as Outlook 2007 is being used, and remote workers have a laptop with Outlook 2007, and a mix of mobile devices using ActiveSync to keep in sync with the Exchange Server 2007 environment. Being a typical customer, Inframan also uses Public Folders, not only for free/busy information and to download the Offline Address Book, but also for storing company wide documents, digital invoices, etc.
From a message hygiene perspective, an Exchange Server 2007 Edge Transport Server is used between the Internet and the internal network. The Edge Transport Server has anti-spam enabled; Real-time Block Lists (RBL) are used in conjunction with Content Filtering to minimize the amount of spam coming in from the Internet, and a Threat Management Gateway (TMG) was recently installed. All clients now connect to the TMG Server and from the TMG Server, and client requests are forwarded to the Client Access Server.
The externally accessible fully qualified domain names (FQDN) that are in use at Inframan are webmail.inframan.nl and autodiscover.inframan.nl. These FQDN’s are used internally as well, but to prevent internal Outlook 2007 client to be rerouted to the TMG server a “split DNS” is used. Factoring in this internet-facing security, the external IP address for webmail is the external address of the TMG server, while the internal IP address for webmail is the IP address of the Exchange 2007 Client Access Server. To achieve this, a DNS zone is created on the internal DNS server for ‘inframan.nl’, where the internal Address (“A”) records are stored.
All external IP addresses for inframan.nl must be stored in the internal DNS zone. If you forget to, for example, include the Address record of the external webserver, then internal clients cannot resolve its IP address, and accessing the site via an internet browser will fail!
This setup has been working successfully for a couple of years now, but since Inframan needs to upgrade their hardware, it was decided to upgrade to Exchange Server 2010 SP1 at the same time.
Exchange Server 2007 – 2010 coexistence
it’s worth noting here that Exchange Server 2007 and Exchange Server 2010 can coexist in one Active Directory, but there are a couple of caveats in such a scenario:
•An in-place upgrade is not supported, so you cannot install Exchange Server 2010 SP1 on top of any of the existing Exchange Server 2007 servers;
•The Internet-facing Active Directory site has to be upgraded first. In the Inframan scenario this is not important since there’s only one site, but you have to be mindful of this fact;
•Exchange Server 2007 CAS & HUB servers will not work against an Exchange Server 2010 Mailbox Server;
•Likewise, Exchange Server 2010 CAS & HUB servers will not work against an Exchange Server 2007 Mailbox Server.
The implications are this are fairly clear; Inframan needs to install a new Exchange Server 2010 Mailbox Server and a new combined Exchange Server 2010 CAS and HUB Server into the existing Exchange Server 2007 environment.
However, the Exchange Server 2007 Edge Transport Server can work against an Exchange Server 2010 Hub Transport Server, and can be replaced by an Exchange 2010 Edge Transport Server after the installation of the Exchange Server 2010 Hub Transport Server.
The upgrade path
The upgrade path for the Inframan scenario is as follows:
1.Upgrade the Active Directory Schema;
2.Upgrade the Active Directory Forest Configuration;
3.Upgrade the Active Directory Domain(s) Configuration;
4.Install the combined Exchange 2010 CAS/HUB Servers;
5.Install the new Exchange 2010 Mailbox Server;Move the access methods from Exchange 2007 CAS to Exchange 2010 CAS;
6.Change the message flow from the Internet to the Exchange 2010 Hub Server;
7.Move all resources from Exchange 2007 to Exchange 2010;
8.Install the Exchange 2010 Edge Transport Server;
9.Decommission Exchange Server 2007 from the Exchange organization.
Of course, before you try and upgrade, you need to make sure you have all of the prerequisites in place for Exchange 2010 SP1 with respect to Active Directory, which are:
•The Schema Master has to be Windows Server 2003 SP2 or later;
•The Global Catalog Servers need to be Windows Server 2003 SP2 or later;
•Active Directory needs to be running in at least “Windows Server 2003 Native mode” and it needs to be in at least “Windows 2003 Forest Functional Level”.
Microsoft has a Supportability Matrix where you can quickly check all requirements for Exchange Server 2010, which can be found on the Microsoft TechNet site:. As far as Exchange 2007 is concerned, it needs to be on at least an Exchange Server 2007 Service Pack 2 level. Assuming you’ve got all the prerequisites in place, let’s take a look at the steps of the upgrade.
Active Directory Upgrades
Changing the Active Directory Schema isn’t that different than in the Exchange 2003 to Exchange 2010 upgrade path, so I won’t go into detail about that. It’s just a matter of running the setup.com /PrepareSchema command to achieve this.
However, bear in mind that when you change the Active Directory configuration in step 2 of the upgrade, you’re actually changing quite a lot. The Exchange 2010 configuration is stored in the same Administrative Group as the Exchange 2007 configuration, called Administrative Group (FYDIBOHF23SPDLT), but quite a lot of things have changed under the hood. When you dive into the Configuration Partition using tools like LDP or ADSIEdit, you’ll notice many changes And, because of these changes, the Exchange 2007 Administration Tools will not or cannot see the Exchange Server 2010 Server objects
So, you’ll need both the Exchange 2007 and Exchange 2010 versions of the Administration Tools to manage a coexistence scenario with Exchange Server 2007 and Exchange Server 2010, and thankfully both versions of the Administration Tools can coexist on the same Management Server or Management Workstation. Background aside, you can accomplish the changing of the Active Directory Forest Configuration using the setup.com /PrepareAD command.
Next, when running the setup.com /PrepareDomain (or /PrepareAllDomains if you want to change all of the domains with Exchange Server objects in one command), the Active Directory Domain is finally prepared for Exchange Server 2010.
Of course, there’s no actual need to change the Active Directory manually as outlined above. You can also start the graphical setup program (setup.exe on the installation media) and just install the first server, which automatically invokes the Active Directory changes, assuming you have sufficient permissions of course
Installing the Servers
After the Active Directory is updated, it’s time to install the actual Windows servers that will host the Exchange Server 2010 Server Roles. Personally, I always recommend using Windows Server 2008 R2. It is, quite simply, a better product than Windows Server 2008 SP2, and is also more efficient, especially within the network stack. Speaking of efficiency, you also don’t need to install the 85 hotfixes required when installing Windows Server 2008 SP2.
So, we are going jump ahead to after the installation of Windows Server 2008 R2 is complete, and the following prerequisites are now required before installing the first Exchange Server 2010 Server role:
•.NET Framework 3.5.1;
•Office 2010 Filter Pack (needed for attachment filtering);
•Hotfixes KB982867, KB979744, KB983440 and KB977020.
Internet Information Server is part of the prerequisite software as well, but this feature will be installed as part of the actual Exchange Server role installation, so it’s not really worth mentioning here. Additionally, over time, the last bullet won’t be a manual step anymore, as the Windows Server 2008 R2 Server will eventually be automatically updated using Windows Update (or your own patch management solution in the future, of course).
When the fresh server is fully updated, it’s time to install the Exchange Server 2010 SP1 Client Access Server and Hub Transport Server roles.
1.Logon to the freshly installed and updated Windows 2008 R2 server as an Enterprise Administrator, and navigate to the installation media. Start the graphical setup application, setup.exe
2.Follow the installation wizard (download the additional language packs if needed), but do not select the Typical Setup option (which will install the Client Access, Hub Transport and Mailbox Server role on the same server). Instead, select the Custom Setup, which will allow you to select exactly which Server Roles you want to install.
3.In the Server Role Selection Window, select the Client Access Role and the Hub Transport Role, and right under the file path you have to check the Automatically install Windows Roles and Features required for Exchange Server option. If you do this, then the additional necessary Server Roles (like Internet Information Server) will be automatically installed.
4.The next step is to enter the external domain name which, in our example, is webmail.inframan.nl. This FQDN is used in all ExternalURL properties on objects like the OWA Virtual Directory, ECP Virtual Directory, Exchange Web Services Virtual Directory, etc.
Click Next to continue the wizard;
5.If all goes well you’ll reach the readiness checks, which should complete successfully. If something goes wrong, then the setup application will tell you exactly what is wrong and what to do to correct the issue(s):
This is obviously a drastic error message
This error message is quite obviously Stating that the Active Directory and Windows Server prerequisites are fine, but the Inframan environment is still running an older version of Exchange Server 2007. When there are minor issues, there’s the option to correct them on the fly, although personally I’m not a great fan of doing this. In any case, every now and then updates will not be processed correctly, or the server needs to be rebooted, but the setup application unfortunately doesn’t notice this. If you continue regardless, you can end up with all kinds of strange issues when the setup is finished (if it finishes at all). So, the Inframan Exchange 2007 servers need to be upgraded first, at least to Exchange Server 2007 SP2. When this is finished, the Exchange Server 2010 SP1 setup program can be started again;
6.When the issues are resolved, the server is rebooted and the Exchange 2010 SP1 setup program is started again. Just like in the previous steps, follow the wizard and install the combined Hub Transport and Client Access Server. If requested reboot the server;
7.When these server roles are installed, the Exchange Server 2010 SP1 Mailbox Server can follow. The requirements for this machine are the same as the first server we installed, so we just need to ensure the prerequisites described at the start of this Server Installation section are applied. Once that’s been done, just logon to this new server as an Enterprise Administrator, navigate to the installation media and start the (graphical) setup program.
8.Follow the wizard as before, but this time select a typical setup, and in the Server Role Selection window, select only the Mailbox Server role. Just like in Figure 3, check the Automatically install Windows Roles and Features required for Exchange Server checkbox to have the prerequisites automatically installed.
9.Follow the rest of the wizard and install the Exchange Server 2010 SP1 Mailbox Server Role. If possible, install the latest Update Rollup Fix for Exchange Server 2010 SP1 on both servers
After preparing the two new Exchange 2010 servers, it is time to think about moving resources from Exchange 2007 to Exchange 2010. The following steps need to be performed:
1.Change the message flow from Exchange 2007 to Exchange 2010;
2.Change the external client access from Exchange 2007 to Exchange 2010;
3.Configure the Exchange 2010 Mailbox Server and configure the Public Folder replication;
4.Move mailboxes from Exchange 2007 to Exchange 2010;
5.Move other resources to Exchange 2010;
6.Decommission the old Exchange 2007 servers.
There’s no real need to follow the first three steps in this specific order; it is also possible to, for example, configure the Exchange 2010 Mailbox Server and setup Public Folder replication first. It’s really up to you to choose what to do first.
Changing Message Flow
After installing both servers, the environment now has two Exchange Server 2007 servers and two Exchange Server 2010 servers, with all message flow and all client access is still going through the Exchange Server 2007 HUB server. If messages need to go from an Exchange 2007 Mailbox to an Exchange 2010 Mailbox, they are picked up by the 2007 HUB Server, sent to the 2010 HUB Server using SMTP, and from there delivered into the Exchange 2010 Mailbox.
When messages are delivered from the Internet, through the 2007 Edge server, and destined for an Exchange 2010 Mailbox, they are also delivered to the 2007 HUB Server, sent to the 2010 HUB server using SMTP, and then delivered to the appropriate Exchange 2010 Mailbox.
So, we have to figure out a way to change the message routing and the client access methods with as little downtime as possible.
Thankfully, changing the message flow is relatively straightforward, as an Exchange 2010 Hub Server can cooperate with an Exchange 2007 SP2 or SP3 Edge Transport Server. To accomplish this, the existing Edge Synchronization (between the Exchange 2007 Edge Server and Exchange 2007 Hub Server) needs to be removed, and a new Edge Synchronization between the Exchange 2007 Edge and Exchange 2010 Hub Server needs to be created.
Later on, a new Exchange 2010 Edge Server can be installed in the DMZ, and an Edge Synchronization between that Exchange 2010 Edge Server and the Exchange 2010 Hub Server can be created. When this is accomplished, the mail flow from the firewall can be redirectedto the new Exchange 2010 Edge Server, and the old Exchange 2007 Edge Server can be removed. I’ll get back to this particular subject in my last article on upgrading Exchange Server 2007 to Exchange Server 2010.
To create a new Edge Subscription between the Exchange 2007 Edge Server and the Exchange 2010 Hub Transport Server, follow these steps:
1.Logon to the Exchange 2007 Edge Server and an administrator, open the Exchange Management Shell, and enter the following command:
New-EdgeSubscription –FileName C:\New-Edge.XML
2.Copy the New-Edge.XML file to the local disk of the Exchange 2010 Hub Transport Server;
3.On the Exchange 2010 Hub Transport Server, open the Exchange Management Console, navigate to the Organization Configuration, select Hub Transport and select the Edge Subscription tab;
4.Delete the existing Edge Synchronization between the Exchange 2007 Hub and Exchange 2007 Edge Transport Server;
5.New Edge Subscription
6.In the New Edge Subscription wizard, enter the Active Directory site which the Edge Subscription has to use, and select the New-Edge.XML file that was created in step 1 And, finally, click New. The Edge Subscription is now created, but it is not yet active;
7.Open an Exchange Management Shell and enter the following command:
Start-EdgeSynchronization
8.The synchronization process is started, and all SMTP transport is now sent between the Exchange 2007 Edge Transport Server and the Exchange 2010 Hub Transport Server.
For the normal SMTP message flow, only port 25 needs to be opened on both firewalls. For the synchronization to take place from the internal Exchange 2010 Hub Transport Server to the DMZ Exchange 2007 Edge Transport Server, port 50636 needs to be opened, but only from the inside out -There’s no need to open this port from the DMZ back to the internal network.
This can easily be checked by examining the header information of a new message. It should read something like:
Received: from 2010CASHUB.infra.local (192.168.0.237) by
2007cashub.infra.local (192.168.0.232) with Microsoft SMTP Server (TLS) id
8.2.254.0; Sat, 6 Nov 2010 13:01:59 +0100
Received: from 2007edge.inframan.nl (192.168.0.234) by 2010CASHUB.infra.local
(192.168.0.237) with Microsoft SMTP Server (TLS) id 14.1.255.0; Sat, 6 Nov
2010 13:01:51 +0100
2007cashub.infra.local (192.168.0.232) with Microsoft SMTP Server (TLS) id
8.2.254.0; Sat, 6 Nov 2010 13:01:59 +0100
Received: from 2007edge.inframan.nl (192.168.0.234) by 2010CASHUB.infra.local
(192.168.0.237) with Microsoft SMTP Server (TLS) id 14.1.255.0; Sat, 6 Nov
2010 13:01:51 +0100
This sample SMTP message was delivered at the Exchange 2007 Edge Transport Server (2007Edge.inframan.nl), sent to the Exchange 2010 Hub Transport Server (2010CASHUB.infra.local) and then to the Exchange 2007 Hub Transport Server (2007cashub.infra.local). From there it is delivered into a mailbox.
Changing the External Client Access
Before the external client access can be changed we need to dive into some of the Client Access Server internals. For starters, be aware that the Exchange 2010 Client Access Server cannot work directly with the Exchange 2007 Mailbox Server role. This is especially true for the Outlook Web App; when a client, for example Internet Explorer, enters the Exchange 2010 Client Access Server and needs to access an Exchange 2007 mailbox, the client is silently redirected to the Exchange 2007 Client Access Server!
The problem this creates is that both the Exchange 2007 CAS and the Exchange 2010 CAS server cannot use the same FQDN, i.e. webmail.inframan.nl. Therefore, when changing the client access, the ‘old’ Exchange 2007 Client Access Server must now be accessible using an FQDN like legacy.inframan.nl.
If you’ve done this correctly, then when clients access the Exchange 2010 CAS Server using webmail.inframan.nl/owa, and their mailbox is still on Exchange Server 2007, they are silently redirected to legacy.inframan.nl/owa, which is actually the Exchange 2007 CAS Server. This therefore means that the current publishing rules on the TMG Server need to be changed as well for this upgrade to work:
--------------------------------------------------------------------------------
1.The Unified Communications certificate has to include the legacy.inframan.nl FQDN. Instead of using a new Unified Communications Certificate it is also possible to use a wildcard certificate, which is fully supported in Exchange Server 2010.
2.The webmail.inframan.nl publishing rule needs to be changed to point to the new Exchange 2010 Client Access Server;
3.The legacy.inframan.nl FQDN needs to be created, and it has to point to the Exchange 2007 Client Access Server;
4.The autodiscover.inframan.nl publishing rule needs to be changed, and it has to be pointing to the Exchange 2010 Client Access Server.
In a coexistence scenario there are three Fully Qualified Domain Names (FQDN):
•Webmail.inframan.nl – this points to the external-facing Client Access Server, which is used for all services (OWA, ActiveSync, Outlook Anywhere etc.). This is the current Exchange 2007 CAS Server, but will soon be changed to the new Exchange 2010 CAS Server;
•Autodiscover.inframan.nl – this points to the external-facing Exchange 2007 CAS Server and, after the change, it will point to the new Exchange 2010 CAS Server. Outlook 2007 (and higher) clients are able to retrieve autodiscover information, even when their mailbox is still on Exchange 2007;
•Legacy.inframan.nl – this points to the old Exchange 2007 CAS Server after the switch to the Exchange 2010 CAS Server. It is used for when OWA clients are redirected to the Exchange 2007 CAS server because the user’s mailbox is still on Exchange 2007.
Just to make sure we’re all absolutely clear on this, the webmail.inframan.nl FQDN will give access to the Exchange 2010 Client Access Server while the legacy.inframan.nl FQDN will give access to the old Exchange 2007 Client Access Server. Outlook Web Access for mailboxes still on Exchange Server 2007 will be redirected to the legacy FQDN.
To prepare for the upcoming changes, we have to follow these steps, which we’ll cover in more detail in a moment:
•Request a new SSL Certificate for the Exchange 2010 Client Access Server;
•Create a new rule on the TMG Server called “Legacy Inframan”, and publish OWA for Exchange 2007 using this publishing rule;
•Enable Outlook Anywhere on the Exchange 2010 Client Access Server;
•Move the Offline Address Book (OAB) and enable web-based distribution;
•Disable Outlook Anywhere on your Exchange 2007 Client Access Server;
•Reconfigure external DNS, and update the Publishing Rules on TMG.
An SSL certificate on the Client Access Server should contain the Common Name webmail.inframan.n’ and the autodiscover.inframan.nl hostname in its Subject Alternatives Name field. The easiest thing to do at this stage is to use only one SSL certificate, using the legacy.inframan.nl hostname as well:
1.Logon to the Exchange 2010 Client Access Server and open the Exchange Management Console. Navigate to the Server Configuration and, in the navigation pane (the left pane), select Client Access. In the actions pane (the right pane), select Request New Certificate;
2.Follow the New Certificate Wizard to create a new certificate request, using the three hostnames I mentioned earlier.
3.A new request file is created, and should be submitted to the Certificate Authority. I always recommend one of the supported certificate vendors (check Microsoft knowledge base article KB929395 for this), but an internal Windows 2008 CA can be used as well;
4.After the certificate is returned from the CA, save the certificate file on the local disk of the Exchange 2010 Client Access Server, and finish the certificate wizard;
5.When you’re finished, use the Enable Exchange Services option in the actions pane. In the inframan scenario, only the IIS service is used by the new certificate.
in Exchange Server 2010, usage of a wildcard SSL certificate is also fully supported. When the certificate is configured and working on the Exchange 2010 Client Access Server, the certificate is exported to a file on the local hard disk. This is a different file from the one we created in step 4 above; this is a backup file of the Exchange certificate. It is then imported to the Exchange 2007 Client Access Server and the TMG Server (which, if you recall, the company has upgraded to from an ISA Server, as mentioned in part 1). As mentioned earlier, one SSL certificate can be used on all servers. You should also bear in mind that, while changing the certificate on the Exchange 2007 Client Access Server and the TMG server is a small update, it will cause a small outage in the messaging service.
The next step is creating a new rule to publish Exchange 2007 OWA using the legacy.inframan.nl hostname, b ut this shouldn’t be too difficult, so I won’t go into detail. However, I will go into detail regarding How to enable Outlook Anywhere on the Exchange 2010 Client Access Server:
1.Logon to the Exchange 2010 Client Access Server and open the Exchange Management Console. Navigate to Server Configuration and select the Exchange 2010 Client Access Server;
2.In the Actions Pane, click on Enable Outlook Anywhere. The wizard to enable Outlook Anywhere will start, and you should enter the external hostname (i.e. webmail.inframan.nl)here. Select the appropriate authentication mechanism, which in this example will be Basic Authentication.
3.Click on Enable to continue the wizard, and a warning message will be displayed saying Outlook Anywhere will be enabled in approximately 15 minutes. Click on Finish to end the wizard.
While the Exchange Management Console is still open, we can get started with moving the Offline Address Book and enabling web-based distribution on the Exchange 2010 Client Access Server:
4.Navigate to the Organization Configuration and click on Mailbox. In the results pane, select the Offline Address Book tab;
5.Right–click on the Default Offline Address Book and select Move, using the Browse button to select the Exchange 2010 Mailbox Server. Click on Move again to continue. A warning message is displayed, informing you that the files are copied to the new target server, at which point you can click on Finish to end the wizard.
6.Right-click on the Default Offline Address Book again; select the property sheet, and then select the Distribution tab, where the 2007 Client Access Server is still listed. Remove the old server, and then click Add to add the Exchange 2010 Client Access Server as a distribution point. Finally, click on OK to apply the changes and close the wizard.
The Offline Address Book is only generated once a day, by default at 4:00 am. So, when you are creating new mailboxes, you have to be careful as they might not show up in this OAB until the next day! On the other hand, the Client Access Server polls the Mailbox Server for updates on the OAB once every 480 minutes (8 hours). Be aware of these issues when troubleshooting OAB issues.
Next, we need to disable Outlook Anywhere on the Exchange 2007 Server:
1.Logon to the Exchange 2007 Client Access Server, navigate to the Server Configuration, and select Client Access Server. Select the 2007CASHUB Server and, in the Actions Pane, select Disable Outlook Anywhere;
2.Follow the wizard to disable Outlook Anywhere;
3.It is also possible to use the Exchange Management Shell to complete this action by entering the following command:
Disable-OutlookAnywhere –Server 2007CASHUB
At this stage, the Exchange 2007 Client Access Server needs to be reconfigured, so that legacy mailboxes on Exchange 2007 are still connected to the appropriate URL during the coexistence phase. To do this, logon to the Exchange 2007 Client Access Server, open the Exchange Management Shell, and enter the following commands:
Set-OWAVirtualDirectory –Id 2007CASHUB\OWA*
-ExternalURL legacy.inframan.nl/owa
Set-OABVirtualDirectory –Id 2007CASHUB\OAB*
-ExternalURL legacy.inframan.nl/OAB
Set-UMVirtualDirectory –Id 2007CASHUB\Unified*
-ExternalURL legacy.inframan.nl/UnifiedMessaging/Service.asmx
Set-WebServicesVirtualDirectory –Id 2007CASHUB\EWS* -ExternalURL legacy.inframan.nl/ews/exchange.asmx
Set-ActiveSyncVirtualDirectory –Id 2007CASHUB\Microsoft* -ExternalURL legacy.inframan.nl/Microsoft-Server-ActiveSync
-ExternalURL legacy.inframan.nl/owa
Set-OABVirtualDirectory –Id 2007CASHUB\OAB*
-ExternalURL legacy.inframan.nl/OAB
Set-UMVirtualDirectory –Id 2007CASHUB\Unified*
-ExternalURL legacy.inframan.nl/UnifiedMessaging/Service.asmx
Set-WebServicesVirtualDirectory –Id 2007CASHUB\EWS* -ExternalURL legacy.inframan.nl/ews/exchange.asmx
Set-ActiveSyncVirtualDirectory –Id 2007CASHUB\Microsoft* -ExternalURL legacy.inframan.nl/Microsoft-Server-ActiveSync
The last step is to reconfigure the TMG web publishing rules for OWA, Autodiscover and ActiveSync, so that they all point to the new Exchange 2010 Client Access Server, and also to add the legacy host name to the external DNS, and point it to the external interface of the TMG Server. An important step here is to change the web listener, as it needs to provide the single sign-on mechanism that enables the seamless redirection from the Exchange 2010 Client Access Server to the Exchange 2007 Client Access Server.
Right now we have the following scenario:
•When a browser goes to the Exchange 2010 Client Access Server using webmail.inframan.nl/owa to open an OWA session, the client is redirected to the Exchange 2007 Client Access Server for as long as the mailbox is still on the Exchange 2007 Mailbox Server. The legacy.inframan.nl/owa URL is used for redirection;
•When an Outlook Anywhere client connects to the Exchange 2010 Client Access Server, this server connects to the Exchange 2007 Mailbox Server to retrieve the mailbox data. The RPC protocol is used for this;
•Autodiscover information and the Offline Address Book are downloaded by Outlook 2007 and Outlook 2010 clients from the Exchange 2010 Client Access Server;
•An ActiveSync client connects to the Exchange 2010 Client Access Server, and this server retrieves the mailbox data from the Exchange 2007 Mailbox Server using the RPC protocol.
The Remote Connectivity Analyzer (RCA) can be used to test the Exchange configuration, and can be found on www.testexchangeconnectivity.com.
If all goes well, then the Outlook Anywhere clients will never notice that something has changed, nor will the Windows Mobile clients. Only OWA clients will be redirected from the webmail.inframan.nl URL to the legacy.inframan.nl URL, and this is clearly visible when using OWA after the redirection:
Configuring the Exchange 2010 Mailbox Server
After installing the Exchange 2010 Mailbox Server, there’s some configuration that needs to be done. The first step is to change the default location of the Mailbox Database from the standard location (C:\Program Files\Microsoft\Exchange Server\v14\Mailbox )to a separate disk, which is not difficult.
Since Inframan is using Public Folders, a new Public Folder Database needs to be created on the Exchange 2010 Mailbox Server:
1.Logon to the Exchange 2010 Mailbox Server as an administrator and open the Exchange Management Console. Navigate to Organization Configuration and select the Database Management Tab;
2.In the Actions Pane, click on New Public Folder Database... and follow the wizard. Enter a new name for the Public Folder Database and select a server. Note that you can only choose an Exchange 2010 Mailbox Server role, even if we are in a coexistence scenario. This is because it is not possible to manage an Exchange 2007 object from an Exchange 2010 Management Console (or Shell);
3.Select a location where the Public Folder database and its accompanying log files will be stored. By default, the C:\Program Files\Microsoft\Exchange Server\v14\Mailbox directory is selected, but it’s a best practice to use another disk. Enter the new location and click New to create the Public Folder database and mount it.
4.Now we need to configure the mailbox database on Exchange Server 2010 to use the newly created Public Folder database. To do so, select the mailbox database and open its properties. In the properties window, select the Client Settings tab. Select the 2010 Public Folder Database (the default is the 2007 Public Folder database) and select the default Offline Address Book.
Since all Public Folder information is still stored in the Public Folders, we have to setup replication between both Public Folder databases, both for the system folders (i.e., for free/busy information and the Offline Address Book) as well as the regular user folders;
1.Logon to the Exchange Server 2007 Mailbox Server role, open the Exchange Management Console and, in the Tools section, open the Public Folder Management tool;
2.To add the Exchange 2010 Public Folder database to the list of replicas, select a public folder’s properties and select the Replication tab. Add the Public Folder Database on the Exchange 2010 Server and click OK. Repeat this for all System Folders that are available on the Exchange 2007 Server (i.e. Free/Busy and Offline Address Book folders).
3.The user Public Folders then need to be replicated to the Exchange 2010 Public Folder database as well. It is possible to manually configure all Public Folders with a new replication partner, but it’s better to use PowerShell scripts that Microsoft delivers with Exchange Server 2010. Open the Exchange Management Shell and navigate to the Scripts directory by entering the CD $ExScripts command, and execute the following script:
AddReplicaToPFRecursive.ps1 -Server 2007MBX -TopPublicFolder "\"
-ServerToAdd 2010MBX
-ServerToAdd 2010MBX
4.This will add the Exchange 2010 public folder database as a replication partner on all public folders that are beneath the root folder. Public Folder replication is not the fastest mechanism in Exchange Server so, depending on the number of Public Folders and the size of the database, it can several hours (or, indeed, days) to complete.
When the Public Folder statistics are checked after the replication has started running, it will be obvious that there’s data in the Public Folders on the Exchange Server 2010 Mailbox Server:
At this point, we still have a combined Exchange 2007 / Exchange 2010 environment, although the SMTP mail flow is now going through the Exchange 2010 Hub Transport Server, and all clients connect to the Exchange Server 2010 Client Access Server. However, since all mailboxes are still on Exchange Server 2007, the requests are either redirected to the Exchange 2007 Client Access Server (for OWA), or the Exchange 2010 Client Access Server is talking directly to the Exchange 2007 Mailbox Server.
Moving Mailboxes
As you are presumably aware, Exchange 2007 resources are managed from the Exchange 2007 management tools, i.e. the Exchange Management Console and the Management Shell. Exchange 2010 resources, on the other hand, are managed from the Exchange 2010 management tools, and you cannot manage Exchange 2007 resources from the Exchange 2010 management tools, or vice versa. The good thing is that if you are fortunate enough to have a management server, you can install the management tools of both versions on the same machine, and thereby save yourself some trouble.
To move mailboxes from Exchange 2007 to Exchange 2010, you have to initiate the move from the Exchange 2010 Management Shell or Management Console.
•Logon to the Exchange 2010 Server and open the Exchange Management Console.
•Navigate to the recipient configuration and click Mailbox. In the results pane, a list of mailboxes appear, and if there are a large number of mailboxes, then you can create a filter on the view. For example, you can view only the mailboxes in a particular mailbox database.
•In the results pane, select a mailbox, right-click on it, and select New Local Move Request…
•A wizard appears, pre-loaded with the mailbox you just selected. In the Target mailbox database field, select the Exchange 2010 Mailbox Database and click Next to continue;
•The next step is to specify what Exchange has to do when corrupt messages are found in the source (Exchange 2007) mailbox. It can skip the mailbox, which is the default, causing Exchange will stop moving the mailbox. You can also skip just the corrupted messages, but then you have to enter the maximum number of messages to skip. I usually leave this with its default setting, so when corrupted messages are found, the move process is skipped for that particular mailbox. Click Next to continue;
•A summary is shown and, when all is well, you can click New to actually start the Move Request. After 10 to 20 seconds, the move request is created and submitted, and the wizard is finished. The actual moving of mailbox data still has to start, as it is only the move request that has been initiated (the actual move will take place in the background). To view the status of the move request, select Move Request under recipient configuration in the Exchange Management Console. You can right-click on the move request to see its properties:
•When the mailbox is moved to Exchange 2010 while you (or rather, the user whose mailbox you just moved) have Outlook open, a message is shown when the actual move has finished saying the Outlook client has to be restarted:
•Restart Outlook for the changes to take effect and to continue working. To check if the Outlook client really connects to Exchange 2010, you can right-click on the Outlook icon in the system tray (in the bottom right of the screen) and select Connection Status;
•The client now connects to the Exchange 2010 Client Access Server, and from there to the Exchange 2010 Mailbox Server. Since Public Folder replication was setup earlier, the data is now retrieved from the Exchange 2010 Public Folder;
•Repeat steps 3 to 6 for all mailboxes still on Exchange 2007;
•When all mailboxes are successfully moved to Exchange Server 2010, the move requests need to be removed as well. In the Exchange Management Shell, under Recipient Configuration and Move Request, select all the move requests and click on Clear Move Request. Now all of the mailboxes are on Exchange Server 2010.
Moving other resources
the Offline Address Book generation server was already moved to the Exchange 2010 Mailbox Server. Given that Address Lists, E-mail Address Policies, Accepted Domains etc are more or less the same in Exchange Server 2010, these do not need any attention at this point.
However, you do have to take care of Transport Rules and Journaling Rules. Normally, these are exported from Exchange 2007 and imported into Exchange 2010 when you install the Hub Transport Server role, but there are circumstances where you have to do this manually. To migrate Transport Rules from Exchange 2007, logon to the Exchange 2007 Hub Transport Server, open an Exchange Management Shell and enter the following command:
Export-TransportRuleCollection -FileName C:\Export_Transport_Rules.xml
Copy the resulting file to the Exchange 2010 Hub Transport Server, open an Exchange Management Shell and enter the following command:
[Byte[]]$Data = Get-Content -Path " C:\Export_Transport_Rules.xml " -Encoding Byte -ReadCount 0
Import-TransportRuleCollection -FileData $Data
Import-TransportRuleCollection -FileData $Data
When you open the Exchange 2010 Management Console, the Transport Rules will now be visible and functional on the Exchange 2010 Hub Transport Servers:
At this stage, you have essentially migrated your entire message environment from Exchange Server 2007 to Exchange Server 2010, so it’s time to look at decommissioning the old environment.
Removing Exchange Server 2007
To start with, since all Public Folders are replicated from Exchange Server 2007 to Exchange Server 2010, it’s time to decommission the Exchange 2007 Public Folder Database. You cannot just delete this Public Folder database since it still contains a replica of this data, and the Exchange 2007 Mailbox Database still has a referral to the Exchange 2007 Public Folder database. To remove the replica, there’s a script in the $exscripts directory on the Mailbox Server:
•Logon to the Exchange 2007 Mailbox Server and open the Exchange Management Console. Navigate to the Server Configuration and select Mailbox Server. In the results pane, select the Mailbox Database on the Exchange 2007 Server and open its properties. In the Client Settings tab, change the default Public Folder database referral to the Exchange 2010 Public Folder database referral.
•Next, logon to the Exchange 2010 Mailbox Server, open the Exchange Management Shell, and change to the scripts directory by entering the CD $exscripts command.
•Enter the following command to start the script which will move all replicas from Exchange 2007 to Exchange 2010:
.\MoveAllReplicas.ps1 -Server 2007MBX -NewServer 2010MBX
The script will be finished in approximately 20 seconds, but it will only change the replication settings on the Public Folder databases. The actual Public Folder replication will take place when the script has finished, and this replication can take quite some time, depending on the amount of data in the Public Folders of course. I usually leave it running overnight and continue the next morning when everything has replicated out, but there are known scenario’s where replication took about 48 hours to complete.
•Running the MoveAllReplicas.ps1 script from the Exchange Server 2010 server actually touches the 2007 Public Folder database. Therefore, the Public Folder database cannot be removed anymore from within the Exchange Server 2007 Management Console; this process now fails with a "future version of Exchange" error message:
•To remove the Public Folder database from the Exchange 2007 server, logon to the Exchange 2010 Server, open the Management Shell and enter the following command:
Get-PublicFolderDatabase -Identity "Public Folder Database" | Remove-PublicFolderDatabase
This will check the Public Folder Database for any Public Folder replicas and, if none are found (which should be the case of course since we removed this in step 2), the Public Folder database will be dismounted and removed:
•Now, when you check the Exchange 2007 Management Console, you’ll see that the Public Folder database has been removed;
•Remove the Exchange 2007 Mailbox Database as well.
Now that the Mailbox Database and the Public Folder Database are removed, the Exchange 2007 Mailbox Server can be removed. On the Exchange 2007 Mailbox Server, open the Control Panel and open the Applications option. In the results list, select the Exchange 2007 Server and select Uninstall. The setup application starts in "maintenance mode", and you can just follow the wizard to uninstall Exchange Server 2007.
Before removing the Exchange 2007 Client Access and Hub Transport Server roles, make sure that no other clients are accessing the Client Access Server (naturally, they shouldn’t be, since we already removed the Exchange 2007 Mailbox Server. However, if clients do access the Exchange 2007 Client Access Server, it will result in an error message) or the Hub Transport Server (which can happen in scenario’s with applications that use SMTP relaying).
Once you’re sure that no clients are trying to access them, the Exchange 2007 Client Access Server and Hub Transport Server can be removed as well. Logon to these servers and open the Control Panel. Just like the Exchange 2007 Mailbox Server, select the Exchange 2007 Server option from the applications menu, and click Uninstall. The setup application will start in "maintenance mode" again, and you can follow the wizard to uninstall Exchange 2007 from these servers.
The only step left is to remove the "legacy publishing rule" from the Forefront TGM Server.
As a side note, it might be a good idea to install a recovery Active Directory and Exchange 2007 in your lab environment. In our sample environment, there’s a couple of years worth of backup database. When you need to restore one of these backups, for legal purposes for example, then it’s a good idea to have an up-and-running Exchange 2007 environment you can use to restore these old backups.
Edge Transport Server
The last server role that needs to be replaced (although this can be done earlier in the process, but preferably after the Exchange 2010 Hub Transport Servers are installed) is the Exchange 2010 Edge Transport Server.
The prerequisites for an Edge Transport Server are almost the same as a Hub Transport Server, except that it’s not normally a member of the (internal) domain. Also, you have to set a Fully Qualified Domain Name on the Edge Transport server before installing it.
Once all prerequisite software has been installed (Windows Server 2008 SP2 X64 or Windows Server 2008 R2, .NET Framework 3.5 SP1, PowerShell 2.0, Active Directory Lightweight Directory Services.), you can install Exchange 2010. Just like a regular Exchange 2010 Server, you can have the prerequisite software automatically install during the Exchange 2010 setup, but I prefer to do it myself in advance. This way, I have full control over the prerequisite installation and control the necessary reboots.
•On the new Exchange 2010 Edge Transport Server (to be), logon as an administrator and navigate to the installation media. Start the graphical setup application, setup.exe;
•Follow the wizard until you reach the Server Role Selection window, where you should select the Edge Transport Role. Note that as soon as you select this role, the other server roles are greyed out. You cannot combine the Edge Transport Server with any other server role;
•Check the Automatically install Windows Server roles and features required for Exchange Server check box, which will install server roles and features needed for Exchange Server. Click Next to continue;
•Follow the wizard and do the prerequisite check. If something is missing, it is reported here, and you can correct them. If needed, reboot the server and continue the wizard to install the Edge Transport Server role.
When the Edge Transport Server role has been installed, the server needs to be rebooted as well (or possibly again, depending on how much trouble you had installing the prerequisites). After rebooting, configure the Edge Transport Server anti-spam functionality as desired.
•When the server is fully operational, open an Exchange Management Shell and enter the following command:
New-EdgeSubscription -FileName C:\Edge2010.xml
•A new subscription file is created, which you need to copy to the Exchange 2010 Hub Transport Server;
•Logon to the Exchange 2010 Hub Transport Server and open the Exchange Management Console. Navigate to the Organization Configuration and select Hub Transport. Select the Edge Subscription tab and remove the current Edge Subscription (with the Exchange 2007 Edge Transport Server). This will mean you don’t have any inbound or outbound SMTP services!
•In the Actions Pane, click New Edge Subscription and follow the wizard. Bind the Edge Subscription to the Active Directory site you’re using (the Default-First-Site-Name in a default configuration), and select the Edge2010.xml file we created earlier;
•When the Edge Subscription is created, open the Exchange Management Shell and enter the following command:
Start-EdgeSynchronization
•The Edge Synchronization will now start. All you have to do now is reconfigure the SMTP mail flow from the external firewall to the Exchange 2010 Edge Transport Server and you’re back in business.
You can now safely remove the Exchange 2007 Edge Transport Server.
Decommission PST files
A typical migration scenario would be a transition from Exchange 2007 to Exchange 2010 (although the same it true of course a transition from Exchange 2003 to Exchange 2010), followed by decommissioning PST files. In the past, Exchange used to have relatively small mailboxes, and users would store data in PST files, which are always difficult from a SysAdmin’s perspective:
•PST files are stored on a local workstation, and are therefore not backed up;
•PST files are stored on a laptops, which can be easily stolen (security breach);
•PST files are stored on a network share, which is slow and not supported.
Exchange Server 2010 now offers the Personal Archive, and in SP1 it is possible to locate the Personal Archive on a different Mailbox database, even on a different Mailbox Server from the users’ primary mailboxes
how to deal with importing PST files in mailboxes or in the Personal Archive. The only downside of this process is that it’s command line only, which can be difficult for a Windows SysAdmin more used to GUIs.
Suppose we have an Exchange administrator (ExAdmin) and, after he implemented Exchange Server 2010 SP1 (including the Personal Archives), he is now responsible for importing the PST files into the Mailboxes and Archives.
However, when the ExAdmin initially opens the Exchange Management Shell and enters the appropriate cmdlet (New-MailboxImportRequest) an error message is generated:
By default, no one has the required permission to perform these actions, and therefore the cmdlets are not available; to enable the mailbox import functionality, the “Mailbox Import Export” role needs to be assigned to the ExAdmin user. ExAdmin needs to Logon as the administrator (in this case, the user that first installed Exchange Server 2010, or anyone else who has been given the Organization Administrator privilege) and execute the following command:
New-ManagementRoleAssignment –Role “Mailbox Import Export” –User ExAdmin
The ExAdmin user now has the appropriate permission, and can execute the cmdlets after he closes and re-opens the Exchange Management Shell. That’s all it takes...
The cmdlet to import PST files into the mailboxes is New-MailboxImportRequest. It takes a number of parameters, but the most important ones are, of course, the mailbox and the path to the file share where the PST file is located. The request does not accept a local directory, so you have to use a file share, but there’s a snag here: when creating the file share, you have to grant the security group “Exchange Trusted Subsystem” read/write permissions on that file share. A nice feature to see in this cmdle is the –IsArchive parameter, which is responsible for importing a PST file into the user’s Personal Archive. However, note that to use the Personal Archive, you’ll need an Enterprise Client Access License (eCAL).
So, to import a PST file into Johan’s mailbox, you have to enter the following command:
New-MailboxImportRequest –Mailbox Johan –FilePath \\2010AD02\PST-Files\johan.pst
You should be aware This command is not available in the Exchange Management Console in Exchange Server 2010 SP1 - only in the Exchange Management Shell.
Performing the actual import of the data into the mailbox is a process which runs on the Client Access Server, as explained earlier when I mentioned the Mailbox Replication Service. So, after entering the import cmdlet, it is therefore possible to close the Exchange Management Shell and log off from the server or management workstation which has the management tools installed.
To monitor the status of the import request, you can use the Get-MailboxImportRequest and the Get-MailboxImportRequestStatistics cmdlets when needed, combined with a selection of parameters, such as the demonstrated in the command below:
Get-MailboxImportRequest | Get-MailboxImportRequestStatistics | `
ft TargetAlias,Percent*,BytesTransferred*
ft TargetAlias,Percent*,BytesTransferred*
It is also possible to enter multiple requests at the same time, or close to each other. The requests will be queued, and when the Client Access Server picks up a request it will then process them sequentially.
Now let’s demonstrate how to monitor the progress of an import action. First of all, to import a PST file into the user Johan’s Personal Archive directly soon after starting the previous import into his primary mailbox), you can use the following command:
New-MailboxImportRequest –Mailbox Johan –FilePath \\2010AD02\PST-Files\johan-archive.pst `
-IsArchive
-IsArchive
Now, when you enter the previous command for monitoring the import status, you’ll see two entries. In this example, the actual primary mailbox is already finished (100%) and the Archive import is still running:
Now that we’ve got the basics, I’ll mention that it’s possible to exclude certain folders during the import using the –ExcludeFolders parameter, and it is also possible to use a –SourceRootFolder parameter to define what data to import from within the source PST; everything outside of the targeted –SourceRootFolder will not be imported. Similarly, the –TargetRootFolder specifies the location in the mailbox where the import will store its data, for example in a \RecoveryFolder location in the mailbox.
Interestingly, it is also possible to perform bulk import of PST files. Suppose there are a number of PST files in the file share we’ve used earlier; it is now possible to request a list of those PST files, and pipe this output into the New-MailboxImportRequest:
Dir \\2010ad02\PST-Files\*.pst | %{
New-MailboxImportRequest –Name ImportOfPst –BatchName ImportPstFiles `
–Mailbox $_.BaseName –FilePath $_.FullName
}
New-MailboxImportRequest –Name ImportOfPst –BatchName ImportPstFiles `
–Mailbox $_.BaseName –FilePath $_.FullName
}
The mailbox which is to be targeted, is identified from the file name of the PST file; so student-1.pst will be automatically imported into the mailbox named “student-1”. When importing multiple PST files in the same batch, you’ll notice that only one or two imports are active at the same time; other requests have the status “Queued” and are only processed when previous imports are finished.
One of the issues top bear in mind is to not overload the Client Access Server and the Mailbox Server during a PST import, which is why the import process is throttled. The good thing is that this throttling is fully configurable; so you can, for example, really stress your Mailbox Servers and Client Access Servers when you’re performing bulk imports on a Saturday or Sunday. The configuration for this is stored in a config file called MSExchangeMailboxReplication.exe.config, which is stored (by default) in the directory C:\Program Files\Microsoft\Exchange Server\V14\Bin on the Client Access Server; when you open it with Notepad, you’ll find some “MaxActiveMoves” parameters which you can edit (which you can see in the image below). Please note that this file exists on every Client Access Server, which means that you’ll need to adjust across all CAS machines if you have a large Exchange organization & are doing a bulk import / export.
As you can probably guess, increase the number of moves per target MDB and your Import Request will process more than just two PST files at a time
Red Gate now offers the PST Importer, which is a handy graphical tool for importing PST files directly into a mailbox or a mailbox’ Personal Archive.
The PST importer is a 32-bit application, but it can of course run on an X64 Exchange Server. The only thing is that it uses some Outlook DLLs, so your best option is to run it on a management workstation (X64) that has Outlook installed. Using this tool, you can either import the PST files immediately, or you can schedule the import to run off business hours.
There’s one (design) issue that you need to bear in mind in general when dealing with PST files. When designing your Exchange 2010 environment, especially the storage needed for the Mailbox Databases, please take into account the amount of PST data you’re likely to be managing. I am constantly impressed by the number of TB’s currently in use by PST files, and if you don’t design and provision properly, you’ll run out of disk space before your migration has finished!