Innovative Technology Weblog

Having spend a whole night up to do my first inter-org Exchange 2003 to Exchange 2007 mailbox migration and publishing the new OWA, SMTP and POP3 endpoints, I feel obligated to share this epic story with our readers. After much exploring, digging through the (now deemed priceless) Exchange 2007 TAP e-mail archives and fighting great battles with the PowerShell bosses, I must say I feel a Wii bit proud of my accomplishments… and a little too hooked on Zelda I suppose.

Although I can’t clearly recall exactly what all happened that night, I now I started somewhere around 22:30 and finished around 06:30 in the morning. Now don’t think I had many mailboxes to move; nope, when I finally got the move-mailbox command going, all 12 of my mailboxes moved without a hitch. Oh and before any of you think that any of this is Microsoft’s fault, it’s not. Every problem I came across was either due to my own faults or it was standard (read: more secure) behavior and just needed the correct PowerShell command to change it to my own (read: less secure) requirements. Finding those correct PowerShell commands took most of the time though, so here is my main message to you: make sure you get plenty of hands-on experience with the Exchange 2007 Management Shell ’cause you are going to need it!

So I had already installed Exchange 2007 on 2 servers:
- One internal server with the Mailbox, Hub Transport, Client Access and Unified Messaging roles on it
- One internet-facing server with the Edge Transport role on it

The Exchange 2007 organization is installed into its own forest, because I wanted to be able to build everything from scratch next to my live (Exchange 2003) environment and move the whole thing over when all was working well, keeping downtime to a minimum. Boy, my VMware Server had a tough time in those weeks I built the new environment, having to support up to 12 virtual machines at peak moments…

Now to keep user problems as low as possible, I chose to use the latest ADMT with the Password Export Service to copy over the user accounts including their passwords. Next I setup the EdgeSync subscription in Exchange to connect my Edge server to my main internal Exchange server. This is a pretty straightforward process and is well described on the Exchange Management Console. You basically go to your Edge server, start the Exchange Management Shell and enter the command:

New-EdgeSubscription -file:”c:\NewSubscriptionExport.xml”

This creates a xml file which you now have to manually move to your internal Exchange server and import it using either the Management Shell or the Management Console, I chose the Management Console. It then creates the EdgeSync subscription and connectors. With this your Exchange environment can now basically route mail to the internet and accept mail from the internet for the e-mail domains that the Exchange Organisation knows about. And here comes your next task: your internal e-mail domain is probably not the e-mail domain you use for internet mail, so you need to add another “Accepted Domain” to your Exchange config. This is pretty easy to do with the Exchange Management Console, but to push this change directly to the Edge server, you must go open up the Exchange Management Shell on the internal Exchange server and enter the command:

Start-EdgeSynchronization

After this command completes you can check if the Edge server received the changes correctly by entering to following EMS command (on the Edge server):

Get-AcceptedDomain

Now that that was done, I wanted to move over my mailboxes and knowing this would be an inter-organization mailbox move I looked for the Mail Migration Wizard in the start menu…..it’s not there. So I searched the Exchange Management Console for move-mailbox kind of options, but the only one you will find only supports intra-org mailbox moves… Oh boy. So I went back to my trusty TAP mail archive and searched for inter-org and found one Exchange TAP tip (no 167) mail about inter-org mailbox migration (but a good one!). The article was quite lengthy and ultimately resulted in the following Exchange Management Shell commands:

$s = get-credential

$t = get-credential

Get-mailbox -DomainController ‘forestAdc1.extest.com’ -Credential $s -database ‘SourceServer1\SourceDB1′ | move-mailbox -TargetDatabase ‘TargetServer1\TargetDB1′ -SourceForestGlobalCatalog ‘forestA.extest.com’ -GlobalCatalog ‘forestB.extest.com’ -DomainController ‘forestBdc1.extest.com’ -NTAccountOU ‘OU=UsersOU, DC=forestB, DC=extest, DC=com’ -SourceForestCredential $s -TargetForestCredential $t

The get-credential commands bring up a user control that allows you to enter the credentials needed for the source forest (stored in $s) and the target forest (stored in $t). These objects are then re-used in the following larger-than-life command that should enumerate all the source mailboxes in the source database on the source server and move them over to the target database on the Exchange 2007 server. Needless to say this requires some practice to do well… One more problem was that I wanted to migrate everything but the mailbox of the Administrator account, so… how do you specify that? Well, you have to insert a ‘where’ statement in between the get-mailbox and move-mailbox commands. The resulting command is:

Get-mailbox -DomainController ‘forestAdc1.extest.com’ -Credential $s -database ‘SourceServer1\SourceDB1′ | where {$_.Alias -ne “Administrator”} | move-mailbox -TargetDatabase ‘TargetServer1\TargetDB1′ -SourceForestGlobalCatalog ‘forestA.extest.com’ -GlobalCatalog ‘forestB.extest.com’ -DomainController ‘forestBdc1.extest.com’ -NTAccountOU ‘OU=UsersOU, DC=forestB, DC=extest, DC=com’ -SourceForestCredential $s -TargetForestCredential $t

However, every time I tried to migrate the mailbox I got a “The object could not be found” error message. After much searching, I found that I had not migrated the sIDHistory from the user accounts in the ADMT migration… whoops. Fortunately this was easily fixed by deleting the users in the new forest and migrating the users once more with ADMT, this time enabling the sIDHistory option. I then also found that you can skip some options of the move-mailbox command because they are often not required for the command to work. I got the mailbox migration running with the following command:

Get-mailbox -DomainController ‘forestAdc1.extest.com’ -Credential $s -database ‘SourceServer1\SourceDB1′ | where {$_.Alias -ne “Administrator”} | move-mailbox -TargetDatabase ‘TargetServer1\TargetDB1′ -SourceForestCredential $s -TargetForestCredential $t

During the migration, the PowerShell tries to graphically represent the migration progress, using old Norton Commander-like progress bars. It’s quite nostalgic really…

After the mail migration, I needed to enable POP3 and allow external users to send outbound SMTP mail via the Edge Transport server. How that story went, I’ll save for another part…

 

This entry was posted on Friday, January 5th, 2007 at 4:56 pm and is filed under General. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.