I can speak to how we handle our cross-forest mailbox migrations from our 2003 environment into our new 2010 environment. This process works reasonably well, except for a known issue that cross-forest mailboxes sometimes need a few hours to be recognized by Exchange 2010 (Or, you can restart the Information Store to get them up immediately)
Here's the process we use. There are alternate ways to make it happen, but this works for us in a production environment and we do this almost daily.
Prerequisites
- You must have a domain trust between the old domain and new domain.
- You need a user with administrative privileges on the old domain, or someone capable of managing the mailbox being moved.
Process
- Prepare the target forest with either microsoft's powershell script (could not locate a link for you) or use the method we use, the PrepareForestMove.vbs script by Michel de Rooij (http://eightwone.com/2010/02/11/cross-forest-mailbox-move-2/)
- Once the output confirms that the mailbox features are moved (Should look like below output.log), fire up powershell.
- Define your old forest admin/mailbox manager credential into a variable, ($foo = Get-Credential)
- Execute the following:
New-MoveRequest -RemoteLegacy -Identity "foo@contoso.com" -RemoteGlobalCatalog "GC.contoso.com" -TargetDeliveryDomain "New.Forest.Domain.Com" -RemoteCredential $foo -verbose
Where
- foo@contoso.com is an e-mail address
assigned to the mailbox currently in
the old system old.
- GC.contoso.com is a global catalog in the old domain. It must be a global catalog! double check this, as it is not immediately apparent by the error if the server is not a GC.
- new.forest.domain.com is the new delivery domain of the new forest. What this does is setup a forwarder in the old forest's exchange network that reroutes e-mail from the old mailbox to the new one at the new domain.
Additional info
output.log for PrepareForestMove looks similar to this:
[14:36] Start
[14:36] Reading names from users.txt
[14:36] doe.100: Syncing Exchange Attributes from doe.100
[14:36] Setting mail to John.Doe@contoso.com #8
[14:36] Setting mailNickname to doe.100 #8
[14:36] Setting msExchMailboxGuid to (B25A79608ABA6F4FA36E6C0AF3CB69BE) #8209
[14:36] Setting targetaddress to John.Doe@contoso.com #8
[14:36] Setting proxyAddresses to multi-value [smtp:John.Doe@old.contoso.com, smtp:doe.100@local, smtp:doe.100@contoso.com, SMTP:John.Doe@contoso.com, X400:c=us;a= ;p=contoso;o=Exchange;s=Doe;g=John;] #8204
[14:36] Adding X500:/o=contoso/ou=First Administrative Group/cn=Recipients/cn=doe.100 to proxyAddresses
[14:36] John.Doe@contoso.com
[14:36] Adding smtp:John.Doe@nlsa.contoso.com to proxyAddresses
[14:36] Setting msExchRecipientDisplayType to -2147483642 #3
[14:36] Setting msExchRecipientTypeDetails to 128 #2
[14:36] Setting legacyExchangeDN to /o=CTS/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=John Doe #8
[14:36] Finished
I would include the "expected" output of the New-MoveRequest verbose, but I don't have a mailbox to move at the moment to show. Suffice it to say, if you see lots of yellow spam without any red entries, things should be rocking and rolling just fine.
You can also check the status of the moverequest as it's processing by using Get-MoveRequestStatistics -Identity username
Oh, an additional item: If when you attempt to use the new mailbox you get an "Unable to open message store", this is the "known issue" I referred to above. If you have a Database Access Group setup, we've found that failing over the DAG to a secondary server usually clears this up without an info store reset, though in some cases you need to cycle all of the info stores! Microsoft hopefully will fix this in SP2 (apparently wasn't important enough for SP1)
Good luck, and I hope this helps!
Best Answer
Here is the technet doc with instructions on how to create a new child domain. It's for 2003, but is applicable to later OS versions as well (not that you mentioned what OS the new DC will be).
However, simply creating a new domain is the easy part, it's what you do after the setup that's the tricky part, and without knowing why you're creating a new child domain, it not going to be possible to advise you further, or even determine whether a new child domain is even a good idea to begin with.