Je peux vous parler de la façon dont nous gérons les migrations de boîtes aux lettres interforêts de notre environnement 2003 vers notre nouvel environnement 2010. Ce processus fonctionne raisonnablement bien, à l'exception d'un problème connu : les boîtes aux lettres cross-forest ont parfois besoin de quelques heures pour être reconnues par Exchange 2010 (ou vous pouvez redémarrer l'Information Store pour qu'elles soient reconnues immédiatement).
Voici le processus que nous utilisons. Il existe d'autres moyens de le faire, mais celui-ci fonctionne pour nous dans un environnement de production et nous le faisons presque quotidiennement.
Conditions préalables
- Vous devez avoir une confiance de domaine entre l'ancien domaine et le nouveau domaine.
- Vous avez besoin d'un utilisateur disposant de privilèges administratifs sur l'ancien domaine, ou d'une personne capable de gérer la boîte aux lettres à déplacer.
Processus
- Préparer la forêt cible avec soit le powershell de microsoft script (je n'ai pas pu localiser un lien pour vous) ou utiliser la méthode que nous utilisons, le PrepareForestMove.vbs script de Michel de Rooij ( http://eightwone.com/2010/02/11/cross-forest-mailbox-move-2/ )
- Une fois que la sortie confirme que les fonctionnalités de la boîte aux lettres sont déplacées (devrait ressembler à output.log ci-dessous), lancez powershell.
- Définissez votre ancien identifiant d'administrateur de la forêt/gestionnaire de boîtes aux lettres dans une variable ($foo = Get-Credential).
- Exécutez ce qui suit :
New-MoveRequest -RemoteLegacy -Identity "foo@contoso.com" -RemoteGlobalCatalog "GC.contoso.com" -TargetDeliveryDomain "New.Forest.Domain.Com" -RemoteCredential $foo -verbose
Où
-
foo@contoso.com est une adresse électronique attribuée à la boîte aux lettres actuellement dans l'ancien système.
-
GC.contoso.com est un catalogue global dans l'ancien domaine. Il doit s'agir d'un catalogue global ! Vérifiez-le deux fois, car l'erreur n'est pas immédiatement apparente si le serveur n'est pas un GC.
-
nouveau.forest.domain.com est le nouveau domaine de livraison de la nouvelle forêt. Cela permet de configurer un transitaire dans le réseau d'échange de l'ancienne forêt qui redirige les e-mails de l'ancienne boîte aux lettres vers la nouvelle boîte aux lettres du nouveau domaine.
Informations complémentaires
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
J'inclurais bien la sortie "attendue" du verbe "New-MoveRequest", mais je n'ai pas de boîte aux lettres à déplacer en ce moment pour la montrer. Il suffit de dire que si vous voyez beaucoup de spam jaune sans aucune entrée rouge, tout devrait bien se passer.
Vous pouvez également vérifier l'état de la demande de déplacement pendant son traitement en utilisant Get-MoveRequestStatistics -Identity username
Oh, un élément supplémentaire : Si, lorsque vous tentez d'utiliser la nouvelle boîte aux lettres, vous obtenez un "Impossible d'ouvrir le magasin de messages", il s'agit du "problème connu" auquel j'ai fait référence ci-dessus. Si vous avez une configuration de Groupe d'Accès aux Bases de Données, nous avons constaté que le transfert du DAG vers un serveur secondaire résout généralement ce problème sans réinitialisation du magasin d'informations, bien que dans certains cas, vous devez faire un cycle de tous les magasins d'informations ! Microsoft espère que ce problème sera corrigé dans le SP2 (il n'était apparemment pas assez important pour le SP1).
Bonne chance, et j'espère que cela vous aidera !
