Gestion des petits soucis dût à la migration [Part10]

By | 23 avril 2014

messagerieGé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 :

ForetJe 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 !

 

            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.

Zexchange01

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 !

Zexchange02Connecteurs 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.

Zexchange03Dans l’onglet Général, entrer l’adresse [IP] entre crochet du serveur de destination.

Zexchange04C’est tout coté 2003.

Default Policy depuis 2010 :

Dans la console, coté 2010, se déplacer dans Microsoft Exchange On-Premises > Organization Configuration puis Hub Transport.

Zexchange05Dans 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.

Zexchange06

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.

user04De 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.

PVFADMIN

 

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 

X500

 

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 !

targetAddress

Dans tous les cas bon courage, je compléterais si j’ai d’autre souci  !

Liste d’article sur le sujet :

 

  1. Migration de domaine – Le Plan [Part1]
  2. Étapes 1 : Gestion des DNS et relations d’approbation transitives
  3. Étapes 2 : Migration des Unités d’Organisation et des GPO
  4. Étapes 3 : Migration de domaine – ADMT 3.2 
  5. Migration de domaine – Password Export Server
  6. Migration de domaine – Migration des Groupes
  7. Migrations des Users et des BALS Première Partie
  8. Migrations des Users et des Bals Secondes Partie
  9. Migration de domaine – Migration d’un Ordinateur
  10. Gestion des petits soucis dût à la migration 

One thought on “Gestion des petits soucis dût à la migration [Part10]

  1. tariq

    merci infiniment pour cet effort, je vais faire la migration a vous traces souhaitez moi bonne chance

    Reply

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *