New-MoveRequest fails with “Database .. doesn’t exist”

Exchange 2010 LogoA 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

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.

TargetAddress, ExternalEmailAddress and Set As External

In co-existence scenarios, the targetAddress attribute is leveraged to accomplish routing to different Exchange organizations by specifying the ‚Äúfinal destination‚ÄĚ e-mail address. The e-mail domain part of this address can be a non-accepted domain (i.e. other organization). This will enable organizations, when used in conjunction with mail-enabled users or contacts, to provision the (global) address list of their Exchange organization with mail-enabled objects of other organizations, also in a migration co-existence phase. Simply said:

  1. It can allow users in the local organization to select the object from the (global) address list and that object exists in other organizations;
  2. Exchange can route the message to its final destination using the specified targetAddress.

Reason for this blog is that I still see people putting e-mail address in the targetAddress property or the object by scripting against Active Directory (e.g. ADSI), even while they’re scripting using the Exchange Management Shell.

In the Exchange Management Shell, you can set the targetAddress by using the Set-MailContact or Set-MailUser in conjunction with the ExternalEmailAddress parameter, e.g.:

Set-MailContact  michel -ExternalEmailAddress

Setting this address is also possible using the Exchange Management Console, which may be more appropriate for testing purposes or a small number of changes (though I’d prefer the less-prone-to-error script any day):


When utilized in scripts, you can use PowerShell Piping Power (is that abbreviation already taken?) to process (CSV) files or use filtering to select the objects of which you want to configure the targetAddress, e.g.:

Get-MailContact -OrganizationalUnit “contoso.local/Division” -Filter {EmailAddresses -like *@contoso.local} -ResultSize unlimited | ForEach { Set-MailContact ‚ÄďExternalEmailAddress “$($_.Alias)@newcompany.local” }

Get-Content “users.txt” | Get-MailContact | ForEach{ Set-MailContact $_.Identity -ExternalEmailAddress “$($_.Alias)@newcompany.local”¬† }

This will configure all mail-enabled contacts in the Division OU with an @contoso.local e-mail address with a target address which consists of the current alias followed by @newcompany.local. The other example uses a text file with names to process contacts and set the targetAddress to the current value of “alias” followed by the external e-mail domain.

Needless to say, the connectors between contoso and newcompany¬† as well as the accepted domains should be properly configured to route those contoso.local and newcompany.local domains between those organizations. Of course, this also depends on whether you’re using internal or external domain names and if you want those messages to go through the public network or not.

Note that this is also how you can set configure the targetAddress of a local (DirSync’ed) mail-enabled contact with an Office 365 mailbox in a Hybrid setup, for example after moving the mailbox to Office 365. In such case you set the targetAddress to the service domain in a Hybrid Office 365 setup, e.g.

Cross-Forest Mailbox Move (2)

Note: This is part 2; part 1 can be found here.

After the post on experiences regarding Cross-Forest Mailbox Move, the problems with the “sample” Powershell script and the script created in good ol’ VB, I got lots of requests to publish the script. After thinking this over, I made it ready for publishing. That means stripping excessive code and changing domain names etc. to a more descriptive labels.

The script does require some explanation:

  • The script uses 1 input file (users.txt) and produces 1 output file (output.log) (included below);
  • The reason for sending output to screen (optional) as well as file is to be able to check it properly (e.g. using notepad) when running it for a set of users;
  • users.txt contains a single line with the source and target account names. This is the same file we used for ADMT imput. Reason for having a source as well as a new account name is that in the migration process account are renamed. ADMT can do this for you, but the script will need both the old and the new name name to connect to the objects and copy/set several attributes;
  • It’s VB, had been kept simple and didn’t went through a code beautifier. That means no full function headers, input/output descriptions or extensive error handling;
  • Modify the constants using information from your environment, e.g. source/target domain, servers, LegacyExchangeDN etc.
  • The script uses fixed servers. This is to make sure we’re talking to the same server(s) as ADMT and to prevent replication issues because of lag;
  • Use the script at your own risk. I cannot accept any responsibility for consequences when using this in your production environment;
  • Use it in a lab environment first; test, test, test!




'* Name     : PrepareForestMove
'* Created By      : Michel de Rooij
'* E-mail    :
'* Date            : 20100217
'* Version    : 0.22
'* Changes:
'* 0.21 Initial version
'* 0.22 Made changes to address single-value proxyAddress attributes

Option Explicit

Const strUserfile            = "users.txt"
Const strOutputFileName            = "output.log"
Const DEBUGOUTPUT            = 1

Const conSourceServer               = ""
Const conSourceDomain                = ""
Const contargetServer                = ""
Const conTargetDomain                = ""

Const conLegacyExchangeDN            = "/o=NEWEXORG/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn="
Const conTargetEmailDomain            = ""

' AD putex cmds

' FileSystem
Const ForWriting =2
Const ForReading =1


Dim oFSO, strFile, objFile, hOutputFileHandle, bProcessLine, strLine
Dim arrUsers, strUser, strCmd, strNewUser

Set oFSO = CreateObject("Scripting.FileSystemObject")
Set hOutputFileHandle= oFSO.OpenTextFile( strOutputFileName, ForWriting, True)


strFile= strUserFile

if NOT oFSO.fileExists( strFile) then
 die( "Input file "& strFile& " does not exist")
end if

debug("Reading names from "& strFile)
set objFile= oFSO.OpenTextFile( strFile, ForReading, True)

while not objFile.atEndOfStream

 bProcessLine= True
 strLine= objFile.readLine

 if isEmpty(strLine) then
 bProcessLine= False
 If left(strLine, 1)= ";" Then
 bProcessLine= False
 If inStr( strLine, ",") > 0 Then
 ' Line OK
 arrUsers= split( strLine, ",")
 strUser= arrUsers(0)
 strNewUser= arrUsers(1)

 If strUser= "SourceName" Then
 ' Input file header, skip        
 bProcessLine= False
 End If
 bProcessLine= False
 debug("** INFO: Skipping line "& strLine)
 End If    
 End If
 End If

 If bProcessLine Then

 debug(strNewUser& ": Syncing Exchange Attributes from "& struser)
 syncAttributes strUser, conSourceServer, conSourceDomain, strNewUser, conTargetServer, conTargetDomain

 End If



set hOutputFileHandle= Nothing
set objFile= Nothing
set oFSO= Nothing


' Purpose: output to screen when DEBUGOUTPUT is 1, always to file
Function debug(strMsg)
 hOutputFileHandle.write ("["& FormatDateTime(now(),4) & "] "& strMsg & chr(13)& chr(10))
 if DEBUGOUTPUT=1 then
 wscript.echo strMsg
 end if
End Function

' Purpose: terminate with message
Function die(strMsg)
 wscript.echo strMsg
 wscript.quit (1)
End Function

' displayString
' Returns string from varType item/elements
Function displayString( varObj)
 Dim tmp, item
 tmp= ""
 select case VarType( varObj)

 Case vbEmpty
 tmp= "(Empty)"
 Case vbNull
 tmp= "(Null)"
 Case vbInteger, vbLong, vbSingle, vbDouble, vbByte, vbDecimal, vbCurrency, vbDate, vbBoolean
 tmp= cStr( varObj)
 Case vbString
 tmp= varObj
 Case vbObject
 tmp= "(Object)"
 Case vbvariant
 tmp= "(Variant)"
 Case 8209
 tmp= "("& OctetToHexStr( varObj)& ")"
 Case vbArray, 8204
 For each item in varObj
 If tmp="" Then
 tmp= tmp+ item
 tmp= tmp+ ", "+item
 End If
 tmp= "["& tmp& "]"
 Case Else

 End Select

 displaystring= tmp& " #"& varType( varObj)

End Function

' OctetToHexStr
' Convert OctetString (byte array) to Hex string.
Function OctetToHexStr (arrbytOctet)
 Dim k
 OctetToHexStr = ""
 For k = 1 To Lenb (arrbytOctet)
 OctetToHexStr = OctetToHexStr & Right("0" & Hex(Ascb(Midb(arrbytOctet, k, 1))), 2)
End Function

' syncAttributes
' migrates attributes from source to target
Function syncAttributes (strUser, SourceServer, SourceDomain, strNewUser, TargetServer, TargetDomain)

 dim strDNSource, strDNTarget, objSource, objTarget, n, strMail
 strDNSource= getDN( struser, SourceServer, SourceDomain, "")
 strDNTarget= getDN( strNewuser, TargetServer, TargetDomain, "")
 If strDNSource<>"" AND strDNTarget <> "" Then
 set objSource= getObject( "LDAP://"& SourceServer& "/"& strDNSource)
 set objTarget= getObject( "LDAP://"& TargetServer& "/"& strDNTarget)

 copyAttribute "mail", objSource, objTarget, False
 copyAttribute "mailNickname", objSource, objTarget, False
 copyAttribute "msExchMailboxGuid", objSource, objTarget, False
 setAttribute "targetaddress", objSource.get( "mail"), objTarget
 copyAttribute "proxyAddresses", objSource, objTarget, True
 addAttribute "proxyAddresses", "X500:"& objSource.get( "LegacyExchangeDN"), objTarget

 strMail= objSource.get( "mail")
 n= instr( strMail, "@")
 debug( strMail)
 addAttribute "proxyAddresses", "smtp:"& left( strMail, n-1)& "@"& conTargetEMailDomain, objTarget

 setAttribute "msExchRecipientDisplayType", -2147483642, objTarget
 setAttribute "msExchRecipientTypeDetails", 128, objTarget
 setAttribute "legacyExchangeDN", conLegacyExchangeDN& objSource.get("cn"), objTarget


 debug("*** ERR: Cannot retrieve DNs for Source or Target")
 syncAttributes= False
 End If
End Function

' getDN
' Retrieves the DN for a user object
Function getDN( struser, strServer, strDomain, strOU)
 dim objConn, objCmd, strQuery, objRS, strAttr, strRDNLDAP, strDNSLDAP
 strDNSLDAP= DNSDomain2LDAPPath( strDomain)
 strAttr= "distinguishedName"
 set objConn= createObject( "ADODB.Connection")
 set objCmd= createObject( "ADODB.Command")
 objConn.Provider= "ADsDSOObject"
 objConn.Open "ADs provider"
 objCmd.ActiveConnection= objConn
 strQuery= "<LDAP://"& strServer
 If strServer <> "" Then
 strQuery= strQuery& "/"
 End If
 strQuery= strQuery& strRDNLDAP
 If strOU <> "" Then
 strQuery= strQuery& ","
 End If
 strQuery= strQuery& strDNSLDAP& ">"
 strQuery= strQuery+ ";(&(objectCategory=person)(objectClass=user)(SAMAccountName="& strUser&"));"& strAttr& ";subtree"
 objCmd.CommandText = strQuery
 on error resume next
 set objRS= objCmd.execute
 if err.number <> 0 Then
 debug( "*** ERR: Error "& err.number& " executing ["& strQuery& "]")
 getDN= ""
 on error goto 0
 Select Case objRS.recordCount
 Case 0
 debug( "*** ERR: User object "& struser& " not found")
 getDN= ""
 Case 1
 getDN= objRS.Fields( strAttr)
 'debug( getDN)
 Case Else
 debug("*** ERR: Ambigious user object "& struser)
 getDN= ""
 End Select
 End If
 set objRS= Nothing
 set objCmd= Nothing
 set objConn= Nothing
End Function

' DNSDomain2LDAPPath( str)
' Makes an LDAP notation for a DNS domain name
' e.g. corp.local => DC=corp,DC=local
Function DNSDomain2LDAPPath( str)
 Dim tmp1, tmp2, tmp3
 tmp1= split( str, ".")
 tmp2= ""
 For each tmp3 in tmp1
 If tmp2<>""  then
 tmp2= tmp2& ","
 End If
 tmp2= tmp2& "dc="& tmp3
 DNSDomain2LDAPPath= tmp2
End Function

' RDN2LDAPPath( str)
' Makes an LDAP notation for a Relative Distinguished Name
' e.g. Domain Accounts/3rd party => OU=3rd party,OU=Domain Accounts
Function RDN2LDAPPath( str)
 Dim tmp1, tmp2, tmp3
 tmp1= split( str, "/")
 tmp2= ""
 For each tmp3 in tmp1
 If tmp2<>"" then
 tmp2= ","& tmp2
 End If
 tmp2= "ou="& tmp3& tmp2
 RDN2LDAPPath= tmp2
End Function

' copyAttribute
' Copies attribute(s) to target
Function copyAttribute( strAttribute, objSource, objTarget, boolMulti)
dim boolUpdate, varItem
If isEmpty( objSource.get( strAttribute)) Then
  debug( strAttribute& " not set, clearing")
  objTarget.PutEx ADS_PROPERTY_CLEAR, strAttribute, 0
  varItem= objSource.get( strAttribute)
  If boolMulti Then
    if isArray( varItem) Then
      debug( "Setting "& strAttribute& " to multi-value "& displayString( varItem))
      objTarget.PutEx ADS_PROPERTY_UPDATE, strAttribute, varItem
      debug( "Setting "& strAttribute& " to single-value "& displayString( varItem))
      objTarget.PutEx ADS_PROPERTY_UPDATE, strAttribute, array( varItem)
    End If
    debug( "Setting "& strAttribute& " to "& displayString( varItem))
    objTarget.Put strAttribute, varItem
  End If
End If
on error goto 0
End Function

' setAttribute
' Sets attribute to target
Function setAttribute( strAttribute, strValue, objTarget)
 debug("Setting "& strAttribute& " to "& displayString(strValue))
 objTarget.Put strAttribute, strValue
End Function

' addAttribute
' Adds attribute to target
Function addAttribute( strAttribute, varAttribute, objTarget)
 dim boolUpdate, tmp
 boolUpdate= True
 If isEmpty( varAttribute) Then
 ' not set, skipping
 'on error resume next
 If isEmpty( objTarget.get( strAttribute)) Then
 boolUpdate= True
 If isArray( objTarget.get( strAttribute)) Then
 For each tmp in objTarget.get( strAttribute)
 If tmp = varAttribute Then
 boolUpdate= False
 End If
 boolUpdate= varAttribute= objTarget.get( strAttribute)
 End If
 End If
 on error goto 0
 If boolUpdate Then
 debug("Adding "& varAttribute& " to "& strAttribute)
 objTarget.PutEx ADS_PROPERTY_APPEND, strAttribute, array( varAttribute)
 debug( varAttribute& " already in "& strAttribute)
 End If
 End If
End Function

Output.log (sample)

[16:24] Start
[16:24] Reading names from users.txt
[16:24] jtest: Syncing Exchange Attributes from jtest
[16:24] Setting mail to #8
[16:24] Setting mailNickname to jtest #8
[16:24] Setting msExchMailboxGuid to (70C2360FB0330346A925172CA0473B9F) #8209
[16:24] Setting targetaddress to #8
[16:24] Setting proxyAddresses to [, X400:c=US;a= ;p=DemoOrg;o=Exchange;s=Old;g=Mr;] #8204
[16:24] Adding X500:/o=DemoOrg/ou=First Administrative Group/cn=Recipients/cn=jtest to proxyAddresses
[16:24] Adding to proxyAddresses
[16:24] Setting msExchRecipientDisplayType to -2147483642 #3
[16:24] Setting msExchRecipientTypeDetails to 128 #2
[16:24] Setting legacyExchangeDN to /o=NEWORG/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=Mr Old #8
[16:24] Finished

Cross-Forest Mailbox Move

Note: This is part 1; part 2 can be found here.

Currently I’m working with Johan Veldhuis on a project where we’ll be moving mailboxes from Exchange 2003 to Exchange 2010. Accounts and mailboxes will be migrated from forest to forest and to make things more interesting, the account migration is isolated from the mailbox migration. In other words, we start with a single forest after which we’ll create a account/resource forest setup from where we’ll consolidate things again. The account/resource forest setup is not completely by the book as the accounts in the resource forest won’t be disabled. This is because ActiveSync devices will be migrated at a later stage; this means they can use their existing authentication information.

Note: In the remainder of this article the following variables are used:

  • is the source forest with Exchange 2003;
  • is the new forest with Exchange 2010;
  • Jan Test is our to be migrated test user with User ID jtest;
  • is an e-mail domain for which Exchange 2003 is authoritative;
  • is an e-mail domain for which Exchange 2010 is authoritative.

The starting point of this blog is the situation where both forests and are up and running. There is a trust between and, ADMT and the Password Export Server are configured and running properly. This means we can successfully migrate user accounts from to the new forest; the user’s mailbox will remain on Exchange 2003 in

Here is where the first problem was encountered. The Active Directory schemas mismatch, so ADMT will only migrate a basic set of attributes. This means that although has Exchange attributes, these won’t be migrated. Also, to be able to use the mailbox properly from their account, we need to add mailbox permissions for the account. For this purpose we created a post-migration script which adds Full Mailbox Access and External Account permissions to the mailbox for the account. After that we have reached an intermediary state, with accounts in and resources (mailboxes) in; Users will log on using an account from the account forest and access their mailbox in the resource forest.

The next phase will be migrating Exchange 2003 mailboxes from to Exchange 2010 mailboxes in Microsoft provides a nice TechNet article (633491) on how to prepare mailboxes for cross-forest mailbox move requests. The article also links to a (sample) PowerShell script, part of ILM 2007 SP1, located here. The script, Prepare-MoveRequest.ps1, should prepare the target forest for mailbox move request. Unfortunately, we couldn’t get it working properly.

First, the script complained it couldn’t find the specified Identity in the target forest. This was odd; the account is present, it was created by ADMT. Diving into the code it looks for the identity in various attributes:

filterParm = “(& (objectClass=user)” +
”¬†¬† ( (| (mailnickname=$escapedIdentity)” +
”¬†¬†¬†¬†¬†¬†¬† (cn=$escapedIdentity)” +
”¬†¬†¬†¬†¬†¬†¬† (proxyAddresses=SMTP:$escapedIdentity)” +
”¬†¬†¬†¬†¬†¬†¬† (proxyAddresses=smtp:$escapedIdentity)” +
”¬†¬†¬†¬†¬†¬†¬† (proxyAddresses=X500:$escapedIdentity)” +
”¬†¬†¬†¬†¬†¬†¬† (proxyAddresses=x500:$escapedIdentity)” +
”¬†¬†¬†¬†¬†¬†¬† (objectGUID=$escapedIdentity)” +
”¬†¬†¬†¬†¬†¬†¬† (displayname=$escapedIdentity))))”

$srcObject = findADObject $srcdc $filterParm

No matter what we tried, no match. Odd. Also, the script contains code which creates objects when it determines it needs to and there’s no switch to turn this behaviour off. That switch would be nice, because the last thing we want is to end up with hundreds of mail-enabled user objects when there are already user account objects present. Since we had little time to debug and fix the script, we decided to prepare the target account in ourselves. I took a script from one of my earlier projects (VB), which I created for similar merger / split scenarios in the past, and checked it against the information in the TechNet article mentioned earlier. In the end we had a script which transforms users into mail-enabled users as follows:

  1. Copy the following atributes from the account in to the account in mail, mailNickname, msExchMailboxGuid, proxyAddresses;
  2. Adds the LegacyExchangeDN attribute from account as an X500 address to the account in;
  3. Sets msExchRecipientDisplayType to -2147483642;
  4. Sets msExchRecipientTypeDetails to 128;
  5. Sets targetAddress in to the value of mail attribute in the;
  6. Adds a constructed e-mail address (e-mail account + @ + new e-mail domain, e.g. to the proxyAddresses in;
  7. Sets legacyExchangeDN on the new account in to “/o=<ORG>/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=<CN>”, where <CN> is the cn of the account.

This is more or less the same as the Prepare-MoveRequest.ps1 should do, but this one worked like expected. Note that the last three actions are important for getting the move request to work. The targetAddress should be set properly, because new-moveRequest will set the target Address of the account to the primary SMTP address of the account. LegacyExchangeDN and the proxyAddress should be added because new-moveRequest uses these for lookup and matching (I assume, because we will also will specify the identity itself). The proxyAddress e-mail address for which Exchange 2010 in is authoritative will be promoted to primary SMTP e-mail address.

Now, after preparing the account and transforming it into a mail-enabled user, we can use new-moveRequest to transfer the mailbox from Exchange 2003 to Exchange 2010:

$cred = get-credential
new-moverequest -identity <userid> -RemoteLegacy -TargetDatabase “<Mailbox Database Name>” -RemoteGlobalCatalog -RemoteCredential $cred -TargetDeliveryDomain <>

An explanation:

  • We need to specify RemoteLegacy because the source forest isn’t Exchange 2010;
  • TargetDatabase identifies the target database;
  • Using RemoteGlobalCatalog we specify a GC from the remote forest;
  • With RemoteCredential, in combination with get-credential, is used to prompt for credentials and use them in the cmdlet;
  • TargetDeliveryDomain specifies the external e-mail domain that is used to set the targetAddress in the source forest, so normally this should be an e-mail domain for which the source forest isn’t and the target forest is authoritative.

Presto! This is what the objects look like after performing the new-moverequest:
cn=Jan Test
legacyExchangeDN=/o=<ORG>/ou=First Administrative Group/cn=Recipients/cn=jtest88083336
proxyAddresses=X500:/o=<ORG>/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=Jan Test;;;
X400:c=NL;a= ;p=<org>;o=Exchange;s=Test;g=Jan;;
cn=Jan Test
legacyExchangeDN=/o=<ORG>/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=Jan Test;
mailNickname=jtest‚Ä®;;X400:C=NL;A= ;P=<org>;O=Exchange;S=Test;G=Jan‚Ä®;‚Ä®;smtp:J.Test@target,com‚Ä®;X500:/o=<ORG>/ou=First Administrative Group/cn=Recipients/cn=jtest88083336

Notice that new-moveRequest adds a random number “88083336” to legacyExchangeDN in and to X500 in This is to promote the account for legacyExchangeDN usage and enables mailflow from the old to when replying on old e-mail.

Update: Also worth noting is we an additional challenge because the source domain name equaled their e-mail namespace, which they want to keep using during and after the migration. Therefor we had to introduce a bogus local namespace for which the Exchange 2003 becomes authoritative and 2010 is not. We can use recipient policies to stamp this address to mail-enabled objects and by creating a connector from Exchange 2010 to Exchange 2003 using this namespace, we can route e-mail from migrated users to non-migrated users.

I hope this information is useful. For more information on new-moveRequest for cross-forest moves, check here. When you have questions, post them in the comments below or send me an e-mail.