Migration Inter-foret Exchange 2013 vers Exchange 2013
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 user1@triplez.lan (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 :
Implémenter ADMT
- Installation du logiciel ADMT sur un contrôleur de domaine du domaine cible ITnyou
https://connect.microsoft.com/site1164/program8540
- Création de la clé de chiffrement dans le domaine cible
ADMT Key /Option:Create /SourceDomain:triplez.lan /KeyFile:C:FMPFileMigPass.pes /KeyPassword:pwd2015
- Création d’un compte de migration
- Dans le domaine source, rajouter un compte Administrateur dans BUILTIN (du domaine cible)
- Installation du logiciel PES 3.1 (même lien qu’ADMTv3.2) dans un contrôleur de domaine du domaine source TripleZ afin de permettre la migration des comptes en conservant le mot de passe :
- En tant qu’administrateur en ligne de commande : msiexec –i pwdmig.msi
- Entrez les identifiants de la forêt cible
- Une fois ces étapes effectuées, redémarrer le contrôleur de domaine
- Une fois le serveur en ligne, démarrez le service « Password Export Service »
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 user1@triplez.lan en tant qu’utilisateur de messagerie aussi appelé « Mail Enabled User » :
Enable-MailUser -Identity user1@itnyou.lan -ExternalEmailAddress user1@triplez.com
- 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 :
#Entrez successivement les identifiants d’un compte admin dans l’environnement source puis cible
$RemoteCredentials = Get-Credential
$LocalCredentials = Get-Credential
.Prepare-MoveRequest.ps1 -Identity user1@triplez.com -RemoteForestDomainController trad01.triplez.lan -RemoteForestCredential $RemoteCredentials -LocalForestDomainController itad01.itnyou.lan -LocalForestCredential $LocalCredentials -uselocalobject –overwritelocalobject
Une fois l’exécution terminée, il est important de repérer la ligne surligné ici en rouge :
VERBOSE: Local ad account with dupplicate proxy addresses found: CN=user1,OU=Import,DC=itnyou,DC=la
VERBOSE: Merging Mailbox properties to local MailUser
VERBOSE: Setting msExchMailboxGUID to abc24a96-5n54-4l2f-b8i7-f1aec452abe1
Preparation for user1@triplez.com done. Local recipient info Merged.
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 user1@triplez.com -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 :
#Vérifier l’état d’avancement des déplacements de BAL: Get-MoveRequest | Get-MoveRequestStatistics
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 user1@itnyou.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.