Gérer un système de messagerie est déjà assez compliqué en soit. Créer des adresses de messageries, des autorisations, des calendriers des contacts, les dossiers Publics. Migrer de domaine et vous vous rendrez compte que finalement » Avant c’était simple ! « .
Dans cet article, je vous expose quelques paramètres à conserver lors de la migration ( cache NK2, contact et liste de distribution etc …).
J’expliquerai aussi simplement la méthode utilisé pour communiquer entre les 2 serveurs exchanges.
Rappel :
Je dispose en plus d’une gestion multi-compte, je gère donc des adresses (pour l’exemple) en :
- essai.com
- nantes.biz
- vite.bzh
En réalité j’en gère beaucoup plus mais pour l’exemple ça sera déjà pas mal !
Table des matières :
1) Routage des mails,
Default Policy depuis 2003 :
Via la console Gestionnaire système Exchange dans Destinataires puis Stratégie de destinataires éditez la Default policy.
Puis je vais modifié chaque adresse et décocher l’option « L’organisation Exchange est responsable de la remise de tous les messages à cette adresse« .
Désormais lorsque un mail destiné à @vite.bzh et non hébergé pas mon serveur 2003 celui-ci sera expédié via mon connecteur que je vais vous montrer de suite !
Connecteurs 2003 :
Toujours dans la console Gestionnaire système Exchange dans Groupe d’administration puis Premier groupe d’administration > Groupe de routage > Connecteurs, créez un connecteur nominatif.
Dans l’onglet Espace d’adressage ajouter les adresses à rediriger.
Dans l’onglet Général, entrer l’adresse [IP] entre crochet du serveur de destination.
Default Policy depuis 2010 :
Dans la console, coté 2010, se déplacer dans Microsoft Exchange On-Premises > Organization Configuration puis Hub Transport.
Dans l’onglet Accepted Domains entrer les domaines que ce serveur va gérer.
Connecteurs 2010 :
Au même endroit, dans l’onglet Send connectors créer un « New Send Connector » , dans l’onglet Address Space ajouter tout les adresses gérer.
Dans l’onglet Network entrer [IP] du serveur exchange 2003
Voila les 2 connecteurs sont configuré, les 2 serveurs exchanges sont capable de communiquer ensemble.
2) Souci post migration
Export des utilisateurs en tant que contact
Toujours dans un souci de communication, lorsque vous migrez un utilisateur vers un autre serveur de messagerie vous devez créer un contact.
Le contact est obligatoire, pour les raisons suivantes :
- Permet de gérer le cache NK2 (voir ci dessous).
- Obligatoire afin de conserver une global adresse liste à jour, car oui la GAL n’est pas partagé entre les 2 domaines.
Afin de peupler la Global adresse list coté 2010, j’ai réalisé un export via CVDE ou ldifde en épurant un maximum d’attribut.:
- cn,diplayName, distinguishedName, mail,mailnickname,name, ObjectClass
J’ai ensuite changé l’attribut ObjectClass de user à contact. et ai réinjecté le tout sur mon serveur Exchange 2010.
Cache NK2
Lorsque que vous écrivez un mail, celui-ci est conservé dans votre cache NK2 (stocké en local dans le profil de l’utilisateur). C’est pourquoi, lorsqu’un utilisateur migre d’un domaine de messagerie à l’autre sa boite n’a pas du tout le même alias vers sa BAL mais ça, le cache NK2 n’en sait rien.
Pour rappel, afin de peupler la global adresse liste des deux domaines, je créer un contact dans le domaine qui n’héberge pas la boite. Lors de la migration je remplace la bal par un contact. Lors de la création du contact l’alias généré ne correspond pas à l’emplacement réél de la bal.
Donc, pour que les utilisateurs du domaine source puissent continuer à utiliser leur cache NK2 copié la variable LegacyexchangeDN avant migration et réinjecter l’attribut dans le contact après migration.
De plus, quand vous migrez le cache NK2 de vos utilisateurs , vous devez opèrer une manipulation supplémentaires. Utiliser l’outils NK2edit et transformer toutes les adresses en smtp.
Action > Convert EX to SMTP.
FIX DACLS
Lors du Move Request, vous subissez une erreur à XX% avec un statut Move failed.
Pas de panique en genèral ceci est du à un soucis d’ACL mal appliqué dans la BALS. Pour cela, il existe un outil magique qui à solutionné un grand nombre d’erreur PFDAVAdmin
Ouvrer la boite et faite un clic droit puis « Fix folder DACLs » indiqué que vous souhaiter le réaliser sur la sous arborescence.
Source : http://runebelune.blogspot.fr/
Réponse aux Anciens Mails
Un collaborateur vient de migrer, cependant celui-ci ne peux répondre aux anciens mail pre-migration. Pire sur les appareils Apple, à la place de l’émetteur on voit clairement l’attribut LegacyexchangeDN .
Ceci vient du faites que vos contacts coté 2010 n’ont pas de lien avec l’ancienne boites coté 2003, je vous rappel que le contact en lui même existe juste pour remplir la GAL. L’astuce est simple en réalité, vous devez ajouter un connecteur X500 avec l »attribut LegacyexchangeDN. Ainsi la liaison entre l’ancien mail et l’ancienne bal ce fera automatiquement donc plus aucun souci de ce coté la.
Microsoft Exchange On-Premises > Recipient Configuration > Mail Contact
Editez les propriétés du contact puis dans l’onglet E-Mail Addresses faites Add > Custom Addresse
Dans le champs E-mail type : X500
E-mail address : LegacyexchangeDN
La solution ici source
Pas de mail après migration.
Vous envoyez des mails à votre collaborateur fraîchement migré, mais ils ne les reçoit pas. Pas de message d’erreur ou un message vous expliquant que l’adresse n’est pas correct ([email protected]).
Ceci vient du faite que vous avez fait une boulette, vous avez effectué successivement les 2 requettes de mouvement de boites ./Prepare-move puis le move-mailbox et ensuites vous avez passé votre admt. Errrrrrrrreur !
Vous inquiètez pas cela ce répare rapidement, Celui-ci a ajouté dans le champs targetaddress de votre utilisateur son adresse de messagerie, ce champs doit-être vide. Sur l’annuaire AD de votre nouveau domaine dans l’attribute editor vider le champs « targetAddress » par <not set>. Quelques minutes après les mails seront reçut !
Dans tous les cas bon courage, je compléterais si j’ai d’autre souci !
Liste d’article sur le sujet :
- Migration de domaine – Le Plan [Part1]
- Étapes 1 : Gestion des DNS et relations d’approbation transitives
- Étapes 2 : Migration des Unités d’Organisation et des GPO
- Étapes 3 : Migration de domaine – ADMT 3.2
- Migration de domaine – Password Export Server
- Migration de domaine – Migration des Groupes
- Migrations des Users et des BALS Première Partie
- Migrations des Users et des Bals Secondes Partie
- Migration de domaine – Migration d’un Ordinateur
- Gestion des petits soucis dût à la migration
merci infiniment pour cet effort, je vais faire la migration a vous traces souhaitez moi bonne chance