This is a follow-up to the post about renaming a domain with Exchange 2007, which you actually can’t do as it turns out, so this became a migration to a new forest.
I was mostly working on the mailbox migration, so this post only covers Exchange 2007 to 2007 cross-forest migration.
ADMT was used to migrate the user accounts. The only really important thing to note here is that you must migrate the SIDs otherwise the mailbox owner will not be recognised by move-mailbox.
I had various errors, which I have listed below, but eventually managed to get the migration working with the following script.
$s = get-credential
$t = get-credential
Get-Content "mailbox.txt" | Get-Mailbox -DomainController oldDC.oldDomain.local -Credential $s | move-mailbox -TargetDatabase "CN=Mailbox Database,CN=First Storage Group,CN=Information Store,CN=newExchServer,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=First Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=newDomain,DC=local" -SourceForestGlobalCatalog oldDC.oldDomain.local -GlobalCatalog newDC.newDomain.local -DomainController newDC.newDomain.local -SourceMailboxCleanupOptions none -SourceForestCredential $s -TargetForestCredential $t -Confirm:$false
The mailbox.txt file contains a list of UPNs, one per line.
Hint: To find your mail database FQDN use ADSIEdit to bind to the Configuration partition in the destination AD.
1. “Failed to reconnect to Active Directory.”
-> This post helped me get the script right and eradicate this error: http://forums.msexchange.org/m_1800493015/tm.htm
2. “MapiExceptionNetworkError: Unable to make admin interface connection to server.”
-> Don’t use administrator. Create a dedicated migration account in both forests and give it the following permissions:
- Exchange Recipient Administrator in both forests,
- Exchange Server Administrator on all source and destination servers,
- Local admin on all source and destination servers,
- Domain Admins both forests (I didn’t expect to have to do this – but see the next error).
3. “Error occurred in the step: Updating attributes. Access denied.”
-> This was fixed by adding the Domain Admins membership in both domains. I then also found I had to restart the Exchange Management Shell.
4. “Failed to set basic mailbox information, will retry in 60 seconds”.
-> If you wait the 60 secs it should then work. This happens because the destination mailbox does not yet exist. For a workaround, create all the destination mailboxes using enable-mailbox and then add the -AllowMerge option to the script above.
5. “Error occurred in the step:Approving object. No matched target NT account is found.”
-> This will happen if you have neglected to migrate the SIDs with ADMT, or if you created new accounts in the destination domain.
For some reason I got this error with all the resource mailbox accounts, despite SID migration having been used. As we weren’t worried about profiles or passwords I ended up deleting the accounts from the destination domain, and then modifying the script above to include the -NTAccountOU option. This allowed move-mailbox to create new accounts and migrate the mailboxes.
6. Not really an error but IT TOOK A BLOODY LONG TIME! We were really unprepared by how slow it was. As the servers were on a dedicated server VLAN with 100 MBit cards we thought it would be pretty fast – but it took over 12 hours to move 50GB. There are probably other factors here – such as the source server being a VM – but still!
7. And in a similar vein: watch the transaction logs on the destination server. I thought I was all prepared for this one and started the day with a Full backup when the server was empty, to follow with incrementals at intervals throughout the day. But at some point I overwrote the existing backup rather than appending, and from that point Exchange helpfully hung on to its trillions of logs. I then had to wait a couple of hours for a full backup to complete so that I could finish migrating the last few mailboxes – Ugh!
8. Distribution Lists: ADMT migrated the groups and their members, but the mail alias went missing along the way. I had to export all the aliases using get-distributiongroup in the old domain, and then update the groups using enable-distributiongroup in the new domain.
9. Outlook 2003 had to be manually reconfigured to connect to the new server. It should be possible to script this in the login script, and there are various vbscripts out there on the internet, but the guys who were doing this part said they couldn’t get it to work, so in the end they did them all manually as the users arrived on Monday morning.
10. While all the mailbox delegations were imported (even for those resource mailboxes which I had to recreate) we noticed that the delegates appeared with a question mark over the icon in Exchange Management Console – however the delegations seemed to be working fine. I couldn’t find anything about this question mark icon. Our best guess was that it was connected to the SID migration and SID history – essentially that the delegation was made with a historical SID.
I’m not going to go into this in any great detail, mostly because I don’t understand it all that well, and don’t particularly want to.
We had to install a new CA server into the new domain, which meant a whole lot of other certs being recreated and reinstalled. That was a variously hair-tearing experience, depending on the application.
For Exchange it wasn’t too hard. I created a new Web Server cert and changed the default one using remove-exchangecertificate, import-exchangecertificate and enable-exchangecertificate. There’s a nice walkthrough here.
It was also necessary to import a couple of certs into the Local Computer store on the ISA 2006 server:
- The root cert from the new CA had to be imported into Trusted Root Authorites, and
- The new Exchange server cert had to be imported into Personal.
After that it was just a matter of changing the OWA and ActiveSync configurations to reference the new Exchange server.