Introduction

Dans cet article, nous allons aborder le processus de migration d’une organisation Exchange 2013 vers une autre.
Contrairement à une migration classique entre version entre des serveurs Exchange au sein d’une même organisation Active Directory, la migration inter forêt requiert des étapes préliminaires supplémentaires comme la migration du compte AD associé à la boîte aux lettres.

Théorie

Afin d’illustrer au mieux les étapes de migrations, nous allons prendre un cas concret d’une architecture Exchange 2013. Cet exemple illustre la migration des comptes de la société TripleZ vers l’architecture de la société ITnYOU.

Au sein de cet article, nous nous focaliserons sur la migration du compte [email protected] (UPN).

Une migration inter forêt se base sur une relation d’approbation entre deux forêts Active Directory. Cela permet entre autre aux utilisateurs migrés de conserver un accès dans leur ancienne forêt grâce à l’attribut AD : « SIDHistory ».

Afin de conserver les attributs AD de l’environnement source, il est possible d’utiliser l’outil Microsoft gratuit ADMTv3.2.
Ce type de migration permet la migration des données d’une BAL via la commande de déplacement « New-MoveRequest ». Cependant, avant d’initialiser cette cmdlet, il convient de vérifier l’état des prérequis ci-dessous.

Prérequis

Plusieurs prérequis sont nécessaires au bon déroulement d’une migration Exchange inter-forêt:

• Une infrastructure AD saine (source & cible)

  Valider grâce aux outils dcdiag, repadmin, console d’évènement Windows, console AD etc.

• Création d'une relation d'approbation AD inter forêt bidirectionnelle

  Cet article part du principe que la relation d’approbation est en place et fonctionnelle. A noter qu’un futur article traitera de son implémentation complète.

• Activation du point de terminaison du proxy MRS sur les serveurs d’accès clients source

  Get-WebServicesVirtualDirectory | Set-WebServicesVirtualDirectory -Identity “EWS (Default Web Site)” -MRSProxyEnabled $true

• Importation le certificat Root de l’organisation source dans l’environnement cible

  Dans notre exemple, vérifier en naviguant vers : https://trcas01.triplez.lan/EWS/mrsproxy.svc (aucun avertissement ne doit apparaître)

Notez aussi que les ports présents sur le schéma doivent être ouverts dans les deux sens pour que le déplacement s’effectue correctement

Pratique

Notez qu’il convient d’effectuer la mise à jour des serveurs Exchange 2013 en CU6 afin d’éviter des problèmes liés à l’étape 3 consistant au déplacement de la boîte aux lettres.

Etape 1: Migration du compte AD via ADMT

Une fois la relation d’approbation fonctionnelle, il est possible de migrer le compte AD d’un utilisateur de TripleZ vers ITnyou. Il ne s’agit pas ici de détailler le fonctionnement et toutes les possibilités offerte par l’outil Microsoft ADMTv3.2 mais seulement quelques points important permettant de comprendre l’essentiel de son utilisation.

Il convient donc de prendre en compte les points suivant :

Une fois ces étapes terminées avec succès, il est aisé de migrer des comptes via le logiciel ADMT. Veuillez noter qu’ADMT ne désactive pas le compte dans l’environnement source par défaut. A ce stade l’utilisateur initialement de l’organisation TripleZ dispose d’un compte dans l’organisation ITnyou et peut ouvrir une session dans le domaine itnyou.lan.

Une fois que le compte a été correctement migré dans l’AD cible ITnYou, vous pouvez passer à l’étape de préparation Exchange permettant de migrer les attributs « msExchange » et la création de contact de redirection.

Les étapes 2 et 3 s’effectuent à partir d’un serveur Exchange de l’environnement cible (méthode pull). De plus, les contrôleurs de domaine utilisés pour les déplacement sont des catalogues globaux.

Etape 2 : Préparation au déplacement d’une BAL

La préparation au déplacement d’une BAL dans une migration inter-forêt consiste en l’exécution d’un script fourni dans les binaires d’Exchange. Il permet de migrer des attributs Exchange ainsi que les différentes adresses référencées initialement sur le compte (SMTP, X500).

Cela permet donc entre autre aux utilisateurs de pouvoir utiliser la fonctionnalité « Répondre » sur des messages antérieurs à la migration à partir du client Outlook et donc de fluidifier le changement d’organisation.

• Avant de préparer le compte de l’utilisateur, il s’avère utile d’activer le compte [email protected] en tant qu’utilisateur de messagerie aussi appelé « Mail Enabled User » :

Enable-MailUser -Identity [email protected] -ExternalEmailAddress [email protected]

• Etant donné que le compte a été déjà migré avec ADMT, il convient d’utiliser les commutateurs « uselocalobject » et « overwritelocalobject » afin d’effectuer une fusion des attributs avec le compte existant.

Ouvrez une console PowerShell Exchange et exécutez les lignes suivantes :

Une fois l’exécution terminée, il est important de repérer la ligne surligné ici en rouge :

A ce stade, le compte user1 est un compte AD avec une adresse de messagerie pointant vers le domaine triplez.com. Le déplacement de la BAL peut désormais s’effectuer.

Etape 3 : Déplacement d’une BAL

Le déplacement de la BAL de user1 du domaine triplez.com vers le domaine itnyou.com s’effectue grâce à la cmdlet New-MoveRequest :

New-MoveRequest -Identity [email protected] -Remote -TargetDatabase DBCIBLE01 -RemoteGlobalCatalog TRAD01.triplez.lan -RemoteCredential $RemoteCredentials -RemoteHostName TRCAS01.triplez.lan -TargetDeliveryDomain

Le commutateur « Remote » permet de signifier à Exchange qu’il s’agit d’une migration inter-forêt et de version d’Exchange identique. Pour des versions différentes on aurait utilisé « RemoteLegacy ». Notez qu’il est aussi possible d’utiliser le switch « MRSServer » pour spécifier un serveur MRS pour la migration.

Pour l’ensemble des paramètres disponible, je vous renvoie directement sur la TechNet : http://technet.microsoft.com/fr-fr/library/dd351123%28v=exchg.150%29.aspx

Vous pouvez vérifier l’état d’avancement de vos déplacements à l’aide de la commande suivante :

Une fois le déplacement terminé, l’utilisateur initialement présent dans la forêt source se transforme en utilisateur de messagerie avec pour adresse externe [email protected]ou.com.

En conclusion

On a pu voir qu’une fois la relation d’approbation AD en place, il suffit de suivre scrupuleusement les étapes pour parvenir à migrer la BAL d’un utilisateur en ligne. Il est bien sur possible d’automatiser toutes les étapes ci-dessus à l’aide de scripts Powershell.

Cet article traite donc des différents points et actions à prendre en compte pour réaliser une migration inter-forêt entre deux organisations Exchange 2013. Cependant, il ne fait pas référence aux éléments permettant de réaliser une coexistence riche comme il pourrait y en avoir dans le cadre d’une migration classique.