In our small environment, we combine the Hub/Transport, Mailbox and UM roles onto a single server. This is the last post in a series focusing on the transition to Exchange 2010 from Exchange 2007. This post will cover the installation of the HT, MB and UM roles.

Installing Hub/Transport, Mailbox and UM Roles

1. Install Prerequisites

On servers that will host the Hub Transport or Mailbox server role, install the Microsoft Filter Pack. For details, see 2007 Office System Converter: Microsoft Filter Pack

Add-WindowsFeature NET-Framework,RSAT-ADDS,Web-Server,Web-Basic-Auth,Web-Windows-Auth,Web-Metabase,Web-Net-Ext,Web-Lgcy-Mgmt-Console,WAS-Process-Model,RSAT-Web-Server,Desktop-Experience –Restart

2. Launch Setup

3. Enter the product key

Hub/Transport Transition

4. We will now configure the Hub/Transport configuration. Since we added Exchange 2010 into an existing 2007 organization, we can simply add the Exchange 2010 H/T Server to the existing Send Connector.

The receive connector is set at the Server Configuration level, I will modify the default receive connector and enable protocol logging for the inevitable debugging that will follow when troubleshooting mail flow issues. I will also increase the default message size to a more realistic size, ex: 40mb (this is fine for smaller organizations).

The only other setting I change is to enable anonymous users. We can do this because we have a hosted spam filter and our firewall restricts access to just that service’s IP address range. Otherwise, allowing anonymous access on a server that is directly connected to the internet is not advisable.

It is now time to modify the firewall to redirect inbound email to the new Exchange 2010 H/T role.  Setup both SNAT and DNAT (source and destination NAT) so that the outbound IP address matches the same IP as the inbound IP. This helps eliminate problems that happen when outside spam filters perform reverse lookups against your IP and MX Record (or even SenderID). If you’re not careful here, you can end up on a blacklist.

After performing this step, remove the Exchange 2007 H/T server from the Send Connector so that their outbound email is forced through the Exchange 2010 server, thus taking advantage of the change to the NAT rule.

Move the Offline Address Book to the new Exchange 2007 mailbox server using the wizard in the Exchange Management Console to perform this procedure.
1. In the Console tree, navigate to Organization Configuration > Mailbox.
2. In the Result pane, click the Offline Address Book tab, and then select the OAB for which you want to move generation to a new server.
3. In the Actions pane, click Properties. On the Distribution tab, select the Enable Web-based distribution and the Enable public folder distribution check boxes and then click OK.

Note: If you skip the step of Enabling the Web-based distribution, clients will get error 0x8004010F during a send/receive operation . See this post for more information.

4. In the Actions pane, click Move.
5. On the Move Offline Address Book page, click Browse to select the server to which you want to move the OAB generation process, and then click OK.
6. Click Move to move the OAB generation process to the selected server.
7. On the Completion page, verify that the operation completed successfully. Click Finish to close the Move Offline Address Book wizard.

At this point it is useful to create a mailbox on the Exchange 2010 server so that you can test mail flow into and from the organization. Examine the message headers from your free web-based email service so that you can validate the proper masquerading of the outbound IP address.

Create Mailbox Databases

One of the changes in Exchange 2010 is the concept of storage groups has gone away. This change decouples databases from servers to enable automatic failover via the new Database Availability Group (DAG) feature (a topic for a future blog series) and therefore this requires that Databases be created at the Organizational level.

Microsoft has increased the maximum database size limit from 200GB in Exchange 2007 to 2TB in Exchange 2010. It is still recommended to separate databases into manageable buckets so that database restores can fit within your SLA, but if databases are replicated in a DAG group, then you may be able to avoid backups altogether and with BIG database sizes! In our organization, I created mailbox databases in four buckets, and assign users to them based on their first name:

However, if you have the Standard Edition of Exchange, you will only be able to mount five databases. If you attempt to mount more than five databases, you will get an error message:TooManyMountedDatabases

And you may find that you are unable to delete the default Mailbox database. See this blog article that describes moving the ‘arbitration mailboxes’ out of the default database so that it can be deleted.

Another strategy to use to take advantage of DAG is to create databases based on which users require high availability. For example, if a very large organization did not want to pay for the bandwidth required to replicate thousands of users, but only wanted the executives to have their mailboxes replicated, you could create an ‘Executive’ mailbox store, and then selectively add this database to a DAG store and only replicate it and not the other mailbox databases. The only requirement in this design is that database names must be unique across servers.

One tip I have for you is to avoid immediately trying to mount the database after creating it. It seems that Exchange is not really ready for it, you need to give it a minute and then manually mount it otherwise you will get an error message.

Unified Messaging Transition

5. This is by far the trickiest part of a transition to 2010, other than CAS of course. Since we already had an Exchange 2007 UM in our environment, we had to decide between a full upgrade or a partial upgrade. And since we had already decided to have co-existence of the two systems for a period of time where mailboxes will reside in both the 2007 and 2010 environments, then full upgrade of UM is eliminated from being an option (but it is the preferred between the two for simplicity reasons). For a full treatment of these two upgrade scenarios, I highly advise you to become intimately familiar with this TechNet article.

The first step is to assign a computer certificate issued by the internal PKI to the UM Service using the built-in Certificate Wizard.

This should be done with a non self-signed certificate, with the result looking as follows:

If you were performing a full upgrade of UM (using the TechNet terminology from the URL above) then you would simply modify the UM server and add it to the existing dial plan. And then once the last mailbox has been moved, run Set-UMDialPlan -identity MyUMDialPlan -LegacyPromptPublishingPoint $null and uninstall all 2007 UM servers.

Moving back to our co-existence reality, the next thing to do is to change the Startup mode to TLS.

Restart the UM Service.

At this point you need to create additional dial plans and UM hunt groups with new pilot numbers.

You can also add a phone number to use for Outlook Voice Access (Just enter a subscriber access number). You’ll later tie this into OCS using a command-line utility described below.

Then, on the OCS side, you need to modify the Front End Properties and add the Exchange 2010 Server to the Host Authorization tab.

On the OCS server you will need to run the OcsUMUtil.exe (found in c:\program files\common files\microsoft office communications server 2007 r2\support on the OCS front-end server).

You need to create a location profile that matches the Exchange 2010 dialplan exactly in FQDN format and then associate an AutoAttendant.

Then, after mailboxes are migrated to Exchange 2010, you will have to disable UM, and then enable them for UM again so that they can be connected to the new Exchange 2010 dial plan (performs a PIN reset). This can be automated in powershell.  For example, when the mailbox move has completed, you can disable the old UM mailbox with one stroke:

Get-MoveRequest | where {$_.Status -eq “Completed”} | Disable-UMMailbox

The good news is the greetings do not have to be re-recorded. This step is necessary for users to get the benefit of the voice to text transcription.

You should now be able to leave a voicemail on an Exchange 2010 UM-enabled mailbox and see the voice to text transcription (aka Voice Mail Preview):

Mailbox Moves

Now that H/T, UM and the Mailbox databases have been created, you can now move over a pilot group of users. Mailbox moves in Exchange 2010 can now be performed online with zero impact to the user, and can therefore be performed during business hours.

The Move-Mailbox cmdlet in Exchange 2007 has been replaced with MoveMailbox.ps1 which is located in C:\Program Files\Microsoft\Exchange Server\V14\Scripts. This allows for moves to be performed in the background instead of foreground tasks. Mailbox moves now show up in a Move Request container. See Understanding Move Requests for more info.

If you were trying to delete a mailbox database in Exchange 2010, you have to clear all move requests first.

When I attempted to move my own mailbox, I received an error “Insufficient access rights to perform
the operation.” I had to go into Active Directory and allow inheritable permissions as follows:

1. Make sure you can see the Advanced Options by clicking View –> Advanced Options
2. Find the user account for a mailbox that will not move
3. Right Click the User account and click Properties -> go to the Security Tab
4. Click Advanced and then check the box next to Include inheritable permissions from this objects parents.
5. Go back to the Exchange Management Console and try to move the mailbox again. You will get an error that states that there is already a move request.
6. Copy the code under the section on how to remove the move request.
7. Paste this code into the Exchange Management Shell and click Yes to All (A) when it asks you if you are sure.
8. Move the mailbox. This time it should work

In my testing, it took about 11 minutes to move a 1GB mailbox.

Microsoft recommends that you back up the source mailbox server before you try to move any mailboxes. Additionally, perform a full online Exchange backup of the destination server after the mailbox moves are complete. Also, consider backing up messages to .pst files; this will allow for quick recovery if individual mailboxes cannot be moved successfully.
For every gigabyte of data that you move, an additional gigabyte of transaction logs is generated at the source and target server. Verify that you have sufficient free space on your transaction log drives. If you do not have sufficient free space on your transaction log drive for transaction log file generation, you could temporarily turn on circular logging. If you have turned on circular logging during the mailbox move, make sure that you turn circular logging off when the mailbox move is completed. If you leave circular logging turned on, you cannot restore up to the point of failure if the database has to be restored from a backup

If the user has Outlook open during the move, that is fine, but they’ll get prompted to restart Outlook when the move completes.

Removing Exchange 2007

After all mailboxes have been moved from 2007 to 2010, you can dismount and remove the databases from the Exchange 2007 mailbox server. If you have public folders, you will need to either replicate those or remove them before you can uninstall Exchange. If you have any distribution lists that were hardcoded with an Exchange 2007 server as the Expansion server, you’ll need to resolve that as well. Lastly, if you have any legacy routing group connectors from a previous migration from Exchange 2003, you’ll need to remove the routing group connector before you can uninstall Exchange 2007.

What’s Next?

I will cover automated mailbox migrations with powershell in a future blog post. In a future series of posts, I will cover backing up Exchange 2010, and monitoring Exchange with System Center Operations Manager 2010. For example, it is interesting to note that if you have servers in a DAG group, Microsoft suggests that it may not be necessary to backup those servers any more, but instead turn on circular logging and let the DAG group provide the backup capability.

I appreciated Scott Feltmann’s perspective on this too:

“A database availability group (DAG) is the base component of the high availability and site resilience framework that is built into Exchange 2010. A DAG is a group of up to 16 Mailbox servers that host a set of databases and provide automatic database-level recovery from failures that affect individual servers or databases.   System administrators can leverage multiple mailbox servers and replicate a mailbox database to a maximum of 16 mailbox servers, as 16 servers is the maximum number of servers in a DAG.  In the event of an issue on one of the mailbox servers an Administrator can move a user’s mailbox to another database in the DAG.  This process is seamless and requires about 30 seconds.  

During the transferring of the user’s mailbox to another server in the DAG the users experience no outage! Now, enough with the explanation, in Exchange 2010 Microsoft has suggested a maximum database size of 2TB! 

The explanation:  With the significant core improvements made to Exchange 2010, the maximum recommended mailbox database size has increased from 200 GB in Exchange 2007 to 2 TB in Exchange 2010”

Here is a nice list of the other new features in Exchange 2010.