Migration 101 - LegacyExchangeDN

Articolo
02/05/2009

Wasa LDN ?

Le LegacyExchangeDN est le plus vieil et le seul identifiant unique d’un « destinataire » (recipient) Exchange dans une organisation Exchange. Comme son nom l’indique, il s’agit du DistinguishedName (nom complet X500) de l’objet mailbox dans l’annuaire Exchange 5.5.

Il se trouve aussi dans Active Directory (attribut LegacyExchangeDN) renseigné sur les objets visibles dans la liste d’adresse globale (« GAL ») :

· Contacts

· groupes

· Mail-Enabled Users (MEA)

· Boites aux lettres

Le puriste notera que toute une série d’autres objets exchange ont aussi un LDN (public folders, connecteurs …)

Il s’agit d’une adresse au format X500 qui contient :

· Le nom de l’organisation

· Le nom du site 5.5 ou de du groupe administratif

· Une chaine identifiant l’objet (souvent l’alias de messagerie)

Ou le trouve-t-on ?

Toutes les APIs MAPI utilisent extensivement ce legacyExchangeDN pour résoudre un nom (« check name »), soumettre un message …

De plus ce LegacyExchangeDN est celui qui est stocké dans chaque message (propriétés PR_SENDER_EMAIL_ADDRESS, et PR_EMAIL_ADDRESS pour les fans de MFCMAPI) ;

Je le prouve avec ce message que m’a justement envoyé le sieur Robain susnommé me demandant de relire la présente:

On trouve aussi ce LDN dans le « fameux » fichier .NK2 (%AppData%\Microsoft\Outlook\<profilname>.NK2)

Vous savez celui qui contient les derniers correspondants et qu’il est conseillé de « vider » quand on migre un profil utilisateur :

Un petit script powershell pour le mettre en évidence :

PS C:\Users\gb> gc "C:\Users\gb\AppData\Roaming\Microsoft\Outlook\Outlook.NK2" -Encoding unicode | % { if ($_ -imatch "o=[\w\d ,;/=]*") {$Matches[0]}}

Ce qui donne :

O=MICROSOFT/OU=NORTHAMERICA/CN=RECIPIENTS/CN=MLAXXX

O=MICROSOFT/OU=EUrope/cn=Recipients/cn=39xxxx

o=microsoft/ou=europe/cn=Recipients/cn=56xxx

O=MICROSOFT/OU=Northamerica/cn=Recipients/cn=scottxxx

O=MICROSOFT/OU=NORTHAMERICA/CN=RECIPIENTS/CN=53xxxx

O=MICROSOFT/OU=EXCHANGE ADMINISTRATIVE GROUP (FYDIBOHF23SPDLT)/CN=RECIPIENTS/CN=Ivrobain

.. .

Quiz : pourquoi le legDN d’ivan, est-il différent des autres legDN dans mon fichier .NK2 ? (répondez en commentaires J )

Enfin et mauvaise nouvelle on retrouve aussi le LegacyExchangeDN dans la fiche contact d’une personne appartenant à l’organisation (que ce soit un contact ou une mailbox) et sauvegardée dans mes contacts (devinez qui ? ):

Pour toutes ces raisons, il est essentiel de prendre garde au LDN lors de migrations inter-organisations pour prévenir les avis de non remise le lendemain de la migration d’une boite aux lettres … de V.I.P. … car pour résumer si Exchange ne trouve pas dans l’AD celui que votre Outlook a mis dans le message… NDR.

Je passe donc la plume à Ivan,

Guillaume

Migration et LegacyExchangeDN

Lorsque je me suis intéressé au LegacyExchangeDN (LDN), j’ai lu/posé des questions autour de moi et les réponses que j’ai obtenues m’ont fait comprendre que beaucoup de personnes avaient des raisonnements empiriques, et ne comprenaient pas les raisons techniques qui poussent à migrer cet attribut. Aussi, nous avons mené des tests, et le présent article va tenter d’éclaircir tout ça.

Ce qu’il faut savoir avant de commencer

Au ResolveP2 près, (voir plus loin) si je reçois un mail d’une personne située dans une autre organisation Exchange que la mienne, c’est l’adresse SMTP de l’expéditeur qui sera marquée dans le champ émetteur du mail

Si je reçois un mail d’une personne de la même organisation Exchange que moi (un collègue de travail m’envoie un mail par exemple), c’est le LDN de la boîte aux lettres de l’émetteur qui apparaît dans le champ émetteur du mail.

Pour les mails venant d’une autre organisation, si le ResolveP2 est actif (« résoudre la messagerie anonyme » sous Exchange 2003, ou mode d’authentification « sécurisé de l’extérieur » dans Exchange 2007), alors il y a 2 cas de figure :

a. Il y a un contact, dans l’organisation cible, qui représente la personne émettrice. Dans ce cas, le mail reçu aura pour émetteur une adresse de type X500 correspondant au LDN du contact représentant l’émetteur

b. Aucun contact ne représente l’émetteur dans l’organisation. Dans ce cas, le mail arrive dans la boîte aux lettres et le champ « émetteur » de ce mail est l’adresse SMTP de l’émetteur.

Conclusion : dans ma boîte aux lettres, les mails peuvent avoir dans le champ « émetteur » soit une adresse SMTP, soit une adresse X500. Il sera possible de répondre à tous les mails (que j’ai émis ou reçus) ayant pour émetteur une adresse SMTP (pourvu que les routes/connecteurs idoines soient en place évidemment). Dans le cas de mails ayant, dans le champ « émetteur », une adresse de type X500/LDN, ça se complique…

Maintenant parlons migration

Lors d’une migration, on a typiquement :

· Des boîtes aux lettres dans la source, qui sont remplacées par des contacts.

· Des contacts dans la cible, qui sont remplacés par des boîtes aux lettres.

Prenons un exemple :

· Mon organisation Contoso migre ses boîtes aux lettres dans l’organisation Exchange Fabrikam.

· Il y a 10 000 personnes dans Contoso et je suis la 5000^ème personne à migrer.

· Lorsque je suis migré, je me retrouve avec les 5000 premiers migrés dans Fabrikam et il me reste 5000 collègues dans Contoso.

· Au moment de la migration de ma boîte aux lettres:

o un contact qui me représente a été créé dans Contoso, afin que j’apparaisse toujours dans la liste d’adresses globale (GAL) de mes collègues de Contoso d’une part, et que les mails qu’ils m’écrivent soient transférés dans ma nouvelle boîte aux lettres Fabrikam.

o Un contact a été supprimé dans Fabrikam pour laisser la place à ma nouvelle boîte aux lettres.

1^er cas de NDR (Non-Delivery Report) : Que se passe-t-il si une personne encore dans Contoso répond à un mail que je lui avais envoyé avant d’être migré ?

Comme au moment où je lui ai écrit nous étions dans la même organisation, le champ « émetteur » du mail est une adresse de type X500 correspondant au LDN de mon ancienne boîte aux lettres dans Contoso.

Par conséquent, lorsque mon collègue répondra à mon ancien mail, sa réponse sera à destination du LDN de mon ancienne boîte Contoso. Or cette boîte n’existe plus (elle a été remplacée par un contact). Mon collègue recevra alors un rapport de non remise (NDR).

La solution consiste donc à injecter, dans l’attribut ProxyAddresses du contact qui remplace mon ancienne BAL, une adresse de type X500 correspondant au LDN de mon ancienne BAL Contoso.

2^ème cas de NDR : Le ResolveP2 est actif dans Fabrikam. Des collègues dans Fabrikam répondent à un mail que j’avais envoyé lorsque ma BAL était dans Contoso.

J’envoie depuis ma BAL Contoso un mail à des personnes déjà migrées dans Fabrikam. Le ResolveP2 est actif, et un contact me représente. Le champ émetteur du mail reçu contient une adresse de Type X500 correspondant au LDN du contact qui me représente dans Fabrikam.

Lorsque j’ai migré, mon contact Fabrikam est remplacé par ma nouvelle BAL.

Lorsque mes collègues Fabrikam répondent à mes vieux mails, ils répondent à une adresse X500 correspondant au LDN d’un contact qui n’existe plus (il a été remplacé par ma BAL). Ils reçoivent un NDR.

La solution consiste donc à injecter dans l’attribut ProxyAddresses de la nouvelle BAL Fabrikam, le LDN du contact qui la représentait avant la migration.

Evidemment, un doublon d’adresse étant interdit, le contact doit VRAIMENT avoir été détruit pour qu’un message arrive à destination.

Références:

How to set X500 proxy addresses for Exchange Server 2003 recipients and for Exchange 2000 Server recipients: https://support.microsoft.com/kb/313324
Outil de mise à jour du profil Exchange: https://support.microsoft.com/kb/873214/fr

Conclusion

La migration des legacyExchangeDN vers les proxyaddresses de la cible est devenu une fonction standard de tous les outils de migration ou de synchronisation d’annuaires (Quest, IIFP …), en revanche la traduction des données de la boites aux lettres (contacts) ou local au profil (.NK2) est une fonction que tous les outils n’implémentent pas. Nous vous invitons à bien faire attention à ces aspects lors de vos futures migrations.

N’hésitez pas à faire appel à MCS, à votre PFE, ou à votre TAM pour ces questions, ou posez des questions dans le thread.

Ivan Robain

Condividi tramite