Es muy común que los administradores de Exchange no se involucren mucho con Outlook y viceversa, pero hay un atributo que realmente no podemos dejar pasar por alto, es el legacyExchangeDN.
La arquitectura original de Exchange utilizaba nombres distinguidos para cada objeto en el directorio, los cuales se forman con los nombres y ruta de los contenedores del objeto, esto era un poco rígido, lo cual llevaba a cierta complejidad y poca flexibilidad en su manejo. Por ejemplo, no se podía cambiar el nombre de un sitio en Exchange 5.5 o mover objetos entre contenedores, a menos que se eliminara el objeto para así obtener el nuevo nombre distinguido o distinguishedName.
Esto llevó a que los desarrolladores fueran más cautelosos al hacer la transición o integración de Exchange a Active Directory; este continúa utilizando nombres distinguidos pero no son el identificador primario, esta función la han tomado los GUIDs (Global Unique Identifier). El cual no varía sin importar la cantidad de modificaciones que se hagan al distinguishedName.
No obstante Exchange aún tiene partes de código que utilizan el distinguishedName para funcionar apropiadamente, razón por la cual surge una necesidad de un atributo que nos de esta compatibilidad, acá es cuando el legacyExchangeDN entra en juego.
Veamos a este atributo como "el nombre viejo" de un objeto en Exchange o bien como un identificador MAPI pues todo cliente MAPI pueden utilizar el legacyExchangeDN para hacer referencia a objetos.
De hecho usted puede responder correos usando una dirección en dicho formato ya que Active Directory responderá a la consulta ejecutada por el transport engine y resolverá la dirección apropiadamente, además este atributo está indexado para así agilizar los tiempos de respuesta.
Ahora bien, donde vemos el legacyExchangeDN en acción... pues cada vez que respondemos un correo y el destinatario está en la lista de direcciones de uso frecuente (Outlook Autocomplete o Automatic Name Resolution). Aunque normalmente lo único que vemos es la última parte de este, la cual casi siempre es igual al mailNickname peeero realmente es el legacyExchangeDN lo que esta ahí.
Por lo cual al migrar buzones entre organizaciones debemos recordar esto para no afectar el ruteo de correos, esto pues los clientes Outlook seguirán enviando correos a la dirección antigua, esto desde luego únicamente con destinatarios internos pues con los externos usa el ReturnPath que es una dirección SMTP.
Si usted es de esos incrédulos pues puede usar el MDB Viewer Utility (MDBVu32) para abrir su buzón de correo y mirar un mail enviado por un usuario interno, específicamente en la propiedad PR_SENDER_EMAIL_ADDRESS. Ahora si me cree? A bueno!
Y bien, si por alguna razón como la creación de una nueva Organización de Exchange o el movimiento de buzones entre organizaciones debemos modificar el legacyExchangeDN y deseamos preservar el ruteo pues tomando el legacyExchangeDN y agregándolo como una dirección X500 lo lograremos, algo como:
adfind -b DC=daemonroot,DC=com -f "(&(objectClass=user)(objectClass=person)(legacyExchangeDN=*)(!(objectClass=computer)))" legacyExchangeDN -adcsv admod proxyAddresses::X500:{{legacyExchangeDN}} -unsafeQué pasa si simplemente modificamos el legacyExchangeDN, pues vamos a tener NDRs por cada respuesta a un mail con el valor antiguo o por cada correo enviado a destinatarios que están el AutoComplete y pues al menos yo no quiero recibir todas esas quejas...
