LegacyExchangeDN und X.500

Was verbirgt sich hinter dem Feld "LegacyExchangeDN", welches sowohl in Exchange 5.5 als auch in Exchange 2000/2003 vorhanden ist. Zuerst sollten Sie dieses Feld nicht mit "msExchADCGlobalNames" verwechseln. Weitere Felder zu Benutzern im AD sind auf RDNCHANGE.VBS erläutert.

Diese Beschreibung geht sehr detailliert auf Systemeinstellungen ein, die im Normalfall nicht von einem Administrator oder Anwender verändert werden sollen. Sie sind hier zum besseren Verständnis der Hintergründe und Interna's von Exchange wiedergegeben. Es kann keine Garantie über die Vollständigkeit und Fehlerfreiheit gegeben werden. Manuelle Eingriffe sind meist nicht durch Microsoft unterstützt und können zu Datenverlusten und Funktionsstörungen führen, die schlimmstenfalls einen Neuaufbau ihrer gesamten Umgebung bedeuten können

LegacyExchangeDN unter Exchange 5.5

Unter Exchange 5.5 hat jedes Objekt einen eindeutigen "Objekt Distinguished Name" (Obj-Dist-Name), der eindeutig ist. Sie können dieses Feld mit der SID in einer Domäne vergleichen. Alle Berechtigungen auf öffentliche Ordner, Postfächer etc. wurden anhand dieses Feldes vergeben vergeben. Ein Feld "LegacyExchangeDN" gibt es in Exchange 5.5 allerdings nicht, sondern ist nur im Active Directory mit Exchange 2000/2003 zu finden.

Der Obj-Dist-Name unter Exchange 5.5 hatte immer die Form:

/O=orgname/ou=Standortname/cn=Recipients/cn=objektname

Dies bildet die logische Struktur im Exchange 5.5 Verzeichnis ab. Es ist gut zu sehen, dass auch der Empfängercontainer innerhalb der Site enthalten ist. Wenn Sie selbst den Feld für ein Objekt anzeigen wollen, dann nutzen Sie einfach den Exchange 5.5 Administrator im "RAW-Mode"  (Aufruf von "ADMIN.EXE /RAW"). Sie können dann zu jedem Objekte neben den normalen Eigenschaften auch die Basiseigenschaften anzeigen lassen.

Soweit ist das noch nichts besonders.

LegacyExchangeDN und Exchange 2000/2003

Lange Zeit hieß es, dass das Feld LegacyExchangeDN in Exchange 2000/2003 nicht mehr erforderlich sei, aber das was sicher vorschnell, so dass es auch mit Exchange 2000/2003 wichtig ist, die Bedeutung und Funktion dieser Variablen zu können. Denn sehr viele ältere  Programme, die bislang mit Exchange 5.x genutzt wurden, erwarten auch weiterhin bestimmte Informationen für die Funktion.

Das was bei Exchange 5.5 der "Obj-Dist-Name" war ist bei Exchange 2000/2003 der LegacyExchangeDN. Jedes Objekt, welches für Exchange aktiviert ist, bekommt durch den RUS einen passenden LegacyExchangeDN vergeben. Der RUS nutzt dazu die Informationen über die Organisation und die Administrative Gruppe, der z.B.: das Postfach zugeordnet ist.

d.h. immer wenn Sie einen Benutzer mit MMC für Active Directory Benutzer & Computer anlegen und diese für Exchange aktivieren, dann erstellt der RUS hierfür nicht nur die Mailadressen, sondern auch den LegacyExchangeDN. Der RUS nutzt dazu den "Given Name" des Objekts und die dazugehörige Organisation und administrative Gruppe. Wann immer Sie ein solches Objekt verändern, verschieben etc, wird der RUS erneut den ExchangeLegacyDN setzen. Das  Format ist identisch zum Obj-Dist-Name bei Exchange 5.5:

/O=orgname/ou=Standortname/cn=Recipients/cn=objektname

Wir können also festhalten, dass der Exchange 5.5 Obj-Dist-Name  im Active Directory dem LegacyExchangeDN entspricht.

Exchange Mixed Mode und ADC

Das  ist umso wichtiger zu wissen,  da auch der ADC diese Feld bei einem Anwender im Active Directory füllen kann. Wenn der ADC die Informationen über ein Exchange Objekt von Exchange 5.5 in das Active Directory übernimmt, dann wir der Inhalt von "Obj-Dist-Name" zum LegacyExchangeDN im Active Directory. Den Inhalt diese Felds kann am einfachsten mit ADSIEDIT eingesehen werden:

Diese Übernahme der Informationen ist später noch wichtig.

LegacyExchangeDN und ADCDisabledMailByADC

Manchmal  werden Sie aber Objekte finden, die nicht im Exchange Adressbuch sichtbar sind und das Feld "LegacyExchangeDN" enthält den sehr befremdlichen Wert "ADCDisabledMailByADC" oder "ADCDisabledMail". Wenn ein Objekt diesen Inhalt hat, dann wird es durch den RUS nicht  mehr weiter verarbeitet und bleibt unverändert. Damit stellt sich die Frage, woher dieser Eintrag kommt.

Bei der Replikation von Benutzern mit dem ADC zwischen Exchange 5.5 und dem Active Directory ist auch der Fall möglich, dass ein Postfach in Exchange 5.5 gelöscht wird. Nun liegt es an der Einstellung der Verbindungsvereinbarung, was der ADC daraus macht. Das Zielobjekt im Active Directory kann ein aktivierter (wurde aktiv genutzt) oder deaktivierter Benutzer (war ein Platzhalterkonto eventuell mit externem Benutzerkonto) sein und der ADC kann Löschbefehle durchführen oder nicht durchführen

  Disabled Account Enabled Account
Delete aktiv

Objekt wird im Active Directory gelöscht.

Objekt wird "Exchange Disabled"

Es bleibt vorhanden, aber hat keine Exchange Eigenschaften mehr.

Der ADC schreibt "ADCDisabledMailByADC" in den LegacyExchangeDN und lösche das Feld "MSExchADCGlobalnames"

Delete nicht aktiv Objekt bleibt erhalten!

Löschanweisung wird in LDF-Datei geschrieben.
Administrator muss selbst die Löschung durchführen.

Objekt wird aber "Exchange Disabled"
Der ADC schreibt "ADCDisabledMailByADC" in den LegacyExchangeDN und lösche das Feld "MSExchADCGlobalnames"
Objekt wird "Exchange Disabled"

Es bleibt vorhanden, aber hat keine Exchange Eigenschaften mehr.

Der ADC schreibt "ADCDisabledMailByADC" in den LegacyExchangeDN und lösche das Feld "MSExchADCGlobalnames"

Sie werden diesen Wert also nur finden, wenn die entsprechende Verbindungsvereinbarung auf die Betriebsart "Löschen" eingestellt ist.

Der RUS wird darauf hin dieses Konto nicht mehr berücksichtigen. Wenn Sie den Benutzer allerdings wieder mittels der MMC aktivieren, dann wird durch die MMC das Feld wieder gefüllt.

LegacyExchangeDN und Exchange 2000/2003 Empfängerrichtlinien

Beim gemischten Betrieb von Exchange 5.5 und Exchange 2000/2003 in einer Organisation finden Sie deutlich sichtbar die Exchange 5.5 Standortadressierung als Empfängerrichtlinie in ihrem Exchange 2000/2003 Administrator wieder. In den Eigenschaften sehen Sie den Erstes Auftreten in den Empfängerrichtlinien.

Diese Richtlinie kann weder gelöscht noch verändert werden und stellt sicher, dass sowohl Exchange 5.5 als auch Exchange 2000/2003 bei der Ermittlung der Mailadressen auf das gleiche Ergebnis kommen. Siehe auch Exchange 2000 - RUS und Empfängerrichtlinien). Damit ist aber auch klar, dass bei einem falschen LegacyExchangeDN nicht mehr die richtige Richtlinie greift.

Wer legt das Feld an ?

Zur schnelleren Übersicht hier noch mal die verschiedenen Prozesse, die das Feld anlegen:

  • MMC für Benutzer und Computer
    Wenn Sie mit der MMC einen Benutzer für Exchange "aktivieren", dann trägt die MMC neben dem Homeserver und der Postfachdatenbank auch den LegacyExchangeDN mit ein. Damit muss der RUS dann nur noch die Mailadressen und einige Rechte vergeben.
  • RUS
    Der Empfängeraktualisierungsdienst kann ebenfalls bei einem neuen Empfänger einen fehlenden Eintrag ergänzen. Dies ist besonders dann von Vorteil, wenn Benutzer per Script angelegt werden und Sie in ihrem Skript dieses Feld einfach vergessen oder nicht genau wissen, was Sie dort eintragen sollen.
  • ADC
    Bei der Replikation eines Kontos von Exchange 5.5 nach Exchange 2000/2003 wird der "Obj-Dist-Name" aus Exchange 5.5 zum LegacyExchangeDN im Active Directory.
  • Exchange 2007/2010 PowerShell Commandlets
    Seit Exchange 2007 gibt es keinen RUS mehr
  • Migrationstools
    Es gibt von verschiedenen Herstellern (z.B. Quest, BinaryTree etc.) Produkte zur Migration von Postfächern. Einige der Produkte enthalten einen "DirSync" und sind damit auch zuständig für das Anlegen von Kontakten etc. Es kann sein, dass diese Produkte dann ebenfalls dieses Feld pflegen (z.B. beim Zusammenführen von Objekten) oder die Aufgabe dem Exchange 2000/2003 RUS überlassen oder die PowerShell commandlets heran ziehen.

LegacyExchangeDN, Admingroups und Objekte verschieben.

Seit Exchange 5.5 SP4 und natürlich seit Exchange 2000 und neuer ist es möglich, Postfächer auch von einer Site in eine andere Site zu verschieben. Wird ein Postfach frisch angelegt, dann wird der LegacyExchangeDN der dazu gehörenden administrativen Gruppe als Basis für den LegacyExchangeDN des Exchange-Objekts genutzt.

  • Exchange im "Mixed Mode"
    Bei der Verschiebung eines Postfachs in eine andre administrative Gruppe wird der LegacyExchangeDN geändert. Der alte Wert wird als X500-Adresse in den Proxy Addresses mit addiert
  • Exchange im "Native Mode"
    Der LegacyExchangeDN wird hier nicht geändert. Bei Exchange 2007 ist ja jede Migration immer ein "Cross Admin Group" Migration.

LegacyExchangeDN in Outlook

Der LegacyExchangeDN zeigt sich z.B. auch in Outlook. Wenn Sie mehrere Empfänger mit dem gleichen Namen haben (z.B.: mehrere öffentliche Ordner gleichen Namens) dann muss der LegacyExchangeDN natürlich eindeutig sein. Exchange hängt dann einfach zufällige Nummern an. Mit dem Softerra LDAP kann das dann z.B. so aussehen.

Das ist im ersten Moment erst mal nicht kritisch, aber wenn Sie in Outlook z.B. eine Mail an diesen Empfänger adressieren und Outlook mögliche Empfänger vorschlägt, dann finden Sie hier den letzten Teil des LegacyExchangeDN wieder:

Da auch das von einigen Anwendern natürlich als "verwirrend" angesehen wird, stellt sich auch hier die Frage, wie dies "korrigiert" werden kann.

Wer nutzt den LegacyExchangeDN und kann ich das Feld manuell ändern ?

Es kann ja nun sein, dass Sie ihre Exchange Organisation immer mal wieder umstrukturieren, Benutzer von einem Standort in den anderen Standort wechseln. Dann stellt sich schnell die Frage, ob Sie den LegacyExchangeDN nicht einfach mit LDIFDE oder anderen Tools ändern können.

Als Administrator mit ausreichend Berechtigungen können Sie natürlich dieses Feld einfach ändern, allerdings werden die Effekte nicht immer von Vorteil sein, weil eben der LegacyExchangeDN anderweitig genutzt wird. So kann es passieren dass:

  • MAPI-Zugriffe fehlschlagen.
    z.B.: für Mailbox Backups
  • Das MAPI-Profil des Anwenders muss neu erstellt oder angepasst werden.
  • Stellvertreter
    Oft binden sich andere Personen ein Postfach als Stellvertreter ein und legen den "Link" in ihre Favoriten. Auch solche Links können dadurch ungültig werden und müssen neu erstellt werden.
  • Free/Busy-Zeiten
    Auch der Zugriff auf öffentliche Ordner und besonders die Frei Belegt Zeiten wird gestört werden, da auch hier der LegacyExchangeDN genutzt wird, d.h. wenn Sie jemanden einladen und dessen Belegung anzeigen wollen, dann nimmt Outlook den LegacyExchangeDN des Partners und sucht nach einem so bekannten Element in "Free/Busy".
    Siehe auch "894252 A user may be able to view the free-and-busy information of another user even though the other user belongs to separate company in Exchange 2000 or in Exchange 2003"
  • Adressbuchprobleme
    Da MAPI den LegacyExchangeDN statt  der SMTP-Adresse nutzt kann bei einer Änderung dieser Adresse eine inkonsistent für einige Zeit bestehen. So können andere Anwender die Adresse in privaten Verteilern oder Kontakte übernommen haben. Diese werden nicht aktualisiert und führen daher zu unzustellbaren Mails. Antworten anderer Benutzer auf frühere Nachrichten des umgestellten Anwenders funktionieren nicht mehr, da Outlook zur Adressierung intern den alten Wert verwendet und nicht die SMTP Adresse. Dies kann man umgehen, indem Sie ein X.500 Adresse beim dem Benutzer hinzu fügen, welche dann die genauer Schreibweise des früheren LegacyExchangeDN (Kleingeschrieben ohne Punkte etc.) enthält. Auch MailMig nutzt diesen Weg um migrierte Anwender weiterhin erreichbar zu machen
  • Verbindung zum Store
    Das Feld LegacyExchangeDN wird aber auch innerhalb von Exchange genutzt, um den Postfachspeicher mit dem Benutzer zu verbinden. Starten Sie einfach den Exchange System Manager und gehen Sie bis zu den Postfächern auf dem Server. Wenn Sie dann das Feld "Vollständiger Postfachname" hinzufügen, sehen Sie hier auch den LegacyExchangeDN.

    Wenn Sie den LegacyExchangeDN ändern, dann wird aber auch diese Anzeige aktualisiert. Die Verbindung zwischen einem Exchange Postfach und dem dazu gehörigen Objekt im AD wird über das Feld "msExchMailboxGuid" hergestellt.

Trotzdem ist es daher meist besser, den LegacyExchangeDN nicht zu ändern und die anderen Probleme zu lösen, z.B. in dem Sie einen migrierten Anwender manuell wieder in die Gruppen hinzu fügen, eventuell Berechtigungen auf Ordner ersetzen oder gleich auf "Verteiler" umstellen.

Auch Microsoft hat ein passendes Tool, um den LegacyExchangeDN zu ändern:

Microsoft Exchange Server LegacyDN utility
http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=19034

Beachten Sie dazu aber die Beschreibung

The Legacydn.exe tool enables you to change Exchange 2000 and 2003 organization names, change Exchange 2000 and 2003 administrative group names, change legacyExchangeDN values on critical system objects, and view legacyExchangeDN values. LegacyExchangeDN is an attribute of many Microsoft® Active Directory® directory service objects (such as mail-enabled users, mailbox-enabled users, public folders, and Exchange system configuration objects), that provides backward compatibility with Exchange 5.5.

One of common use of LegacyDN.exe is to use it to help you rename attributes as part of the process of recovering an Exchange database to a test server when Exchange data is not recoverable using other methods.

Important This tool is to be used in a test environment only. Do not use it to make changes in a production system because doing so will render all Exchange databases as unstartable.

Wenn Sie den LegacyExchangeDN wirklich ändern, dann sollten Sie den alten Wert als X500-Adresse mit in die ProxyAddresses aufnehmen.

LegacyExchangeDN und X.500

Vielleicht haben Sie sich schon mal gefragt, warum Benutzer in den Proxy Adressen auch X.500 Adressen haben. Das passiert immer dann, wenn man einen Benutzer von einer Exchange Site in eine andere Site verschiebt und im MixedMode ist oder wenn man man Benutzer korrekt in eine andere Exchange Organisation überträgt.

Der alte LegacyExchangeDN wird dann zusätzlich als X.500 Adresse addiert, damit Rückläufer etc. weiter zugestellt werden. Stellen Sie sich einfach vor, dass dies so ähnlich funktioniert wie die SID-History bei der Migration von Benutzern in eine andere Domäne.

Diese zusätzliche X.500 Adresse kann auch helfen, Probleme mit der NK2-Datei von Clients nach einer Migration zu entkräften. Wer eine Mail an eine Adresse aus dem lokalen Cache schreibt, kann eine unzustellbarkeit erhalten, wenn es den user noch gibt aber er einen anderen LegacyExchangeDN bekommen hat, z.B. weil der Empfänger irrtümlich gelöscht und neu angelegt oder neu Postfach-Aktiviert wurde.

Diagnostic information für administrators:
 
Generating server: srv01,msxfaq.local
 
IMCEAEX-_O=ORG_OU=DE_cn=Recipients_cn=test@explample.com
#550 5.1.1 RESOLVER.ADR.ExRecipNotFound; not found ##

In dem Fall kann man auch auch behelfen, indem der alte LegacyExchangeDN als X.500 Adresse addiert wird. Muss man das für viele Anwender machen, dann können Sie das per ADModify.NET oder per PowerShell machen:

Get-Mailbox | foreach {
   $_.EmailAddresses += [Microsoft.Exchange.Data.CustomProxyAddress]("X500:/o=Org/ou=DE/cn=Recipients/cn=$_.alias")
   $_|set-mailbox
}

LegacyExchangeDN im Betrieb

Wenn Sie nun glauben, dass der LegacyExchangeDN mit Exchange 2007 und Outlook2007 überflüssig geworden ist, dann irren Sie. Auch in dieser Umgebung ist dieses Feld weiterhin erforderlich. Ein Beispiel hierzu:

Wenn Sie in einem öffentlichen Ordner vom Typ "Kontakte" einen Verteiler anlegen, dann können Sie in diesen Verteiler verschiedene andere Empfänger aufnehmen. Dazu zählen natürlich auch Personen aus der GAL. Outlook speichert in der Verteilerliste nun aber nicht die SID, die SMTP-Adresse oder den distinguishedName des Active Directory Objekts, sondern den LegacyExchangeDN. Dies ist erst mal "nur" ein Outlook Problem aber soll reichen, warum sie auch heute noch ein Augenmerk auf dieses Feld haben sollten.

Durch einen Supportfall bei einem Kunden, bei dem kein LegacyExchangeDN mehr angelegt wurde (Fehler in den System Policies) wurde nun auch klar, dass selbst Exchange 2007 auf diesem Feld aufbauen. Was z.B. beim Fehlen eines LegacyExchangeDN nicht mehr geht ist:

  • Free/Busy-Zeiten
    In dem Fall wurden durch einen Connector die Benutzer eines GroupWise-Systems in Exchange als Kontakte angelegt und die Frei/Belegt-Zeiten in den SystemOrdner repliziert. Der Exchange 2007 Concierce konnte zu dieser "LegacyMailbox" aber leider keine Frei/Belegt-Zeiten abrufen.

    Im Eventlog sehen Sie dann auch eine entsprechende Meldung, z.B.
Event Type:     Error 
Event Source:   MSExchange Availability 
Event Category: Availability Service 
Event ID:       4003 
Description: 
Process 204[w3wp.exe:/LM/W3SVC/1/ROOT/EWS-1-12863200]: 
Microsoft.Exchange.InfoWorker.Common.Availability.PublicFolderRequest failed.
The exception returned is Microsoft.Exchange.InfoWorker.Common.Availability.PublicFolderRequestProcessingException:
The remote server returned an error: (404) Not Found.. 
The request information is http://srv01.msxfaq.net/public/?Cmd=freebusy&start=2009-04-05T12:00:00Z&end=2009-09-03T12:00:00Z&
interval=30&u=user.name@domainname.com.. The Availability service could not successfully retrieve Schedule+ free/busy data für one the legacy Exchange mailboxe "o=msxfaq,ou=First Admin Group, cn=user1
increase the diagnostic logging level of the MSExchange Availability service.
  • Ausgehende Mails eines Postfachs
    Wenn bei einem Postfach der LegacyExchangeDN fehlt, dann kann der Send-Connector wie früher bei Exchange 5.5 den Absender nicht "finden" und demnach auch nicht die Adresse richtig senden. Beim externen Empfänger kommt dann eine IMCEA-Adresse an, z.B.
  • Adressierbarkeit an Kontakte
    Legen Sie zum Test einmal einen externen Kontakt an und entfernen Sie dann den legacyExchangeDN. Eine Mail an den Kontakt wird mit einer unzustellbarkeit quittiert

    Auch hier ist ersichtlich, dass Outlook wohl kaum die SMTP-Adresse aus dem Adressbuch nimmt, sondern doch den internen LegacyExchangeDN adressiert und erst der Transport-Server dann das Objekt im Active Directory sucht und daraus die Zieladresse im SMTP-Format anzeigt
  • Verteiler ohne LegacyExchangeDN
    Das gleiche Problem erleiden Verteiler die ohne LegacyExchangeDN angelegt werden. Diese werden bei Outlook im Online-Modus im Adressbuch ebenfalls angezeigt aber eine Mail an den Verteiler führt auch zu einem NDR
  • Offline-Adressbuch
    Damit das eben nicht passiert, berücksichtigt der Exchange Server beim Erstellen eines Offline-Adressbuch nur Objekte mit einem LegacyExchangeDN. Wer Outlook also im Cached-Mode oder Offline betreibt, sieht diese Empfänger gar nicht mehr.
  • Adressbuch
    Der LegacyExchangeDN erscheint auch, wenn jemand eine Mail von einem ganz frisch angelegten Benutzer bekommt und der Empfänger den Sender im (Offline)-Adressbuch nachschlagen will. Dort kommt er auch erst nach einigen Stunden an.
  • Eigener Name beim Ausdruck
    Interessanterweise kann der LegacyExchangeDN auch beim Ausdrucken erscheinen. So gesehen bei Outlook 2013, wenn ein "neuer" Anwender eine Mail ausdrucken will, aber sein Konto ebenfalls noch nicht lokal im Offline Addressbuch vorliegt.

    Es hat den Anschein, dass Outlook anhand des LegacyExchangeDN im OfflineAddressbuch nach dem Benutzereintrag sucht um den Displaynamen zu erhalten. Ist der Name nicht auflösbar, dann zeigt Outlook in der Druckvorschau den LegacyExchangeDN an.

ähnliche Probleme haben Sie, wenn der LegacyExchangeDN zwar gesetzt ist, aber z.B. aufgrund unterbrochener Vererbung die Exchange Dienste das Objekt nicht komplett "sehen" können. Ich hatte bislang nur einen Fall, in dem der LegacyExchangeDN nicht gesetzt wurde. Mit folgenden Befehlen können Sie die Objekte kurz prüfen:

Get-mailcontact -resultsize unlimited | where {$_.LegacyExchangeDN -eq ""}
Get-mailuser -resultsize unlimited | where {$_.LegacyExchangeDN -eq ""}
Get-DistributionGroup -resultsize unlimited | where {$_.LegacyExchangeDN -eq ""}
Get-mailbox -resultsize unlimited | where {$_.LegacyExchangeDN -eq ""}

Normalerweise ist dies eine Aufgabe des RUS oder der PowerShell Commandlets. Allerdings orientieren diese sich an den Empfängerrichtlinien und an den Systemrichtlinien. Und wer hier im Feld "Purported Search" etwas ändert, kann in dieses Problem laufen. Die PowerShell Befehle erkennen einen fehlenden LegacyExchangeDN nur dann als Fehler, wenn die nachfolgenden Filter auch die Objekte einschließen. Hier ein partieller Export der korrekten Filtereinstellungen.

dn: CN=Mail Enable Recipient,CN=System Policies,CN=Net at Work GmbH,CN=Microsoft Exchange,
     CN=Services,CN=Configuration,DC=netatwork,DC=de
cn: Mail Enable Recipient
purportedSearch: 
 (|(&(objectCategory=person)(objectClass=user)(mailnickname=*)(targetAddress=*)
 )(&(objectCategory=person)(objectClass=contact)(mailnickname=*)(targetAddress=
 *))(&(objectCategory=group)(mailnickname=*))(&(objectCategory=publicFolder)(ma
 ilnickname=*)))

dn: CN=Mailbox Enable user,CN=System Policies,CN=Net at Work GmbH,CN=Microsoft Exchange,
    CN=Services,CN=Configuration,DC=netatwork,DC=de
cn: Mailbox Enable user
purportedSearch: 
 (&(objectCategory=person)(objectClass=user)(mailnickname=*)(homeMdb=*))

dn: CN=Hidden DL Membership,CN=System Policies,CN=Net at Work GmbH,CN=Microsoft Exchange,
    CN=Services,CN=Configuration,DC=netatwork,DC=de
cn: Hidden DL Membership
purportedSearch: (objectCategory=group)

Aktuell habe ich noch keinen Hinweis, welcher Prozess, welche Software oder wie auch immer das Feld "purportedSearch" des "Mail Enable Recipient"-Objekts derart geändert wurde, dass dort nicht mehr die zutreffenden Objekte gefunden wurden. Hilfreich war dabei auch der folgende Artikel in den Microsoft Foren

LegacyExchange, X500 und Autodiscover

Ein Supporfall in einer Exchange 2007/2010 Umgebung hat mir wieder mal gezeigt, dass auch hier LegacyExchangeDN und die X.500 Adresse durchaus eine Funktion haben. Warum auch immer wurde der LegacyExchangeDN eines Postfachs beim einem anderen Postfach als X.500 Adresse addiert.

Also Folge konnte der Anwender sich gar nicht mehr in Outlook anmelden. Exchange erfragte immer wieder Benutzername und Kennwort aber konnte die Verbindung zum Postfach nicht herstellen. Letztlich gab der folgende Eintrag im Eventlog den Hinweis.

Log Name:      Application
Source:        MSExchange Autodiscover
Event ID:      1
Task Category: Web
Level:         Error
Keywords:      Classic user:          N/A
Computer:      SRV1.msxfaw.com
Description: unhandled Exception "Multiple objects with legacy DN /o=ORG/ou=Exchange Administrative 
    Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=user1 were found."
Stack trace:    at Microsoft.Exchange.Data.Directory.Recipient.ADRecipientSession.
      FindByLegacyExchangeDN(String legacyExchangeDN)
   at Microsoft.Exchange.Autodiscover.Providers.Outlook.OutlookAutoDiscoverProvider.
      <>c__DisplayClass14.<GetADRecipientForRequestedUser>b__11()
   at Microsoft.Exchange.Autodiscover.RequestDetailsLogger.TrackLatency[TResult]
      (LogField logField, Func`1 method)
   at Microsoft.Exchange.Autodiscover.Providers.Outlook.OutlookAutoDiscoverProvider.
      GetADRecipientForRequestedUser(ADRecipientSession adRecipientSession, ADRecipient callerRecipient)

Allerdings war es nicht ausreichend, den LegacyExchangeDN aller Objekte zu durchsuchen, sondern eben auch noch die ProxyAddresses nach X500-Adresen. Kaum war der Konflikt beseitigt, konnte der Benutzer wieder arbeiten.

Interessant war allerdings, dass dieses Problem erst mit Exchange 2010 nach der Migration des Postfachs offensichtlich wurde. Solange das Postfach auf Exchange 2007 lagt, konnte der Anwender arbeiten. Exchange 2010 nutzt also entgegen vieler anderslautender Informationen weiterhin intensiv den LegacyExchangeDN und wertet nun sogar noch eine X.500-Adresse aus.

Weitere Links