A quick write up on something which you might encounter when trying to move mailboxes across forests. Often, operators don’t always have full access permissions in both environments and rely on provided accounts or delegated permissions to execute the move.

Suppose you’re in the target environment and are asked to migrate mailboxes cross-forest from a previous version of Exchange to Exchange 2010. One of the first steps would be to run the Prepare-MoveRequest.ps1 script to prepare the target object and populate it with Exchange-related attributes from the source environment.

You then come at a point in such a migration, after running Active Directory Migration Tool – ADMT and perhaps some additional tweaks, when you need to actually move the user’s mailbox. So, you enter for example:

$cred= Get-Credentials
New-MoveRequest –Identity UserX –RemoteLegacy –TargetDatabase DB1 -RemoteGlobalCatalog SourceDC –RemoteCredential $cred –TargetDeliveryDomain maildomain.com

Mailbox move request are being queued but for some mailboxes you may encounter the following error message: “Database xxxxx-xxxx-xxxx-xxxx-xxxxx doesn’t exist”. That error message may get you worrying, but let’s investigate.

We’re in the target environment and the source environment is running a legacy version of Exchange so setting up a remote PowerShell session and using Get-MailboxDatabase <GUID> is not an option. All roads lead to Rome when querying Active Directory, but in this case let’s load up our trusty LDP to look up that GUID; it should map to a database in the source environment.

In LDP, use Connection > Connect and enter the name of a remote domain controller, like the one specified as RemoteGlobalCatalog, in our example RemoteDC. Then, use Bind providing the credentials you used with RemoteCredential.

Next, select View > Tree and use <GUID=xxxxx-xxxx-xxxx-xxxx-xxxxx> as BaseDN (replace those x’s with the GUID reported by the failing New-MoveRequest and make sure you include those less and greater than symbols).

Now, normally the database object with that GUID and its properties will be returned. If not, something is probably wrong with the permissions on the mailbox, directly or indirectly. Depending on whether you’re able to migrate other users from the same database, server up to the organization, you can rule out if it’s a per-mailbox issue, database permission issue etc.

This proves that as always, preparation is everything. Therefor, prior to migration be sure to check or correct effective permissions on mailboxes to prevent any surprises in that area when you’re actually migrating.

Note that the permission ACLs on a mailbox needs to be in a so-called non-canonical order. To fix this, you may find the FixMailboxSD utility helpful. More information on the importance of canonical ordering of mailbox permissions in Exchange here.