Exchange Adressbücher und die GAL

Exchange 2000 bietet wie Exchange 5.5 für seine Anwender auch Adressbuchdienste. Eigentlich handelt es sich dabei um Ansichten, die aus LDAP-Anfragen zum Active Directory erzeugt werden.

Adressbuchansichten

Im Gegensatz zu Exchange 5.5 hat Exchange 2000 ja keinen eigenen Verzeichnisdienst mehr. Während Exchange 5.5. daher seine Benutzer in Empfängerkontainern pflegt und diese auch in Outlook entsprechend anzeigt, kennt Exchange 2000 dies nicht mehr.

Exchange 2000 kennt nur noch den aktuellen Forrest und die Benutzer darin. Dabei ist es völlig unerheblich, in welcher Domäne der Benutzer oder der Verteiler ist. Exchange 2000 liest einfach die GAL per LDAP im Moment des Zugriffs.

Statt den Empfängerkontainern und den starren Adressbuchansichten von Exchange 5.5 kann Exchange 2000 Adressbücher nach LDAP-Filterkriterien Ansichten generieren. Diese werden vom Administrator konfiguriert. Dies sieht dann was wir eine SQL-Abfrage aus.

Es ist also nicht mehr so wie bei Exchange 5.5, dass eine Ansicht "nach Ort" erstellt wird und ich erhalte je Ort ein Adressbuch und im schlimmsten Fall auch für alle Schreibweisen und Tippfehler ein Adressbuch, sondern ich erhalte das Ergebnis einer LDAP-Anfrage mit Filterkriterien als Liste. Sie sehen aber auch, wie wichtig es ist, ein Namenskonzept für das Ausfüllen der Benutzerinformationen im Active Directory zu haben.

Rechte

Auch wenn ich nun die schöne Welt der Adressbuchansichten und des globalen Adressbuchs aufgezählt habe, so gelten immer noch die Rechte im Active Directory, d.h. ein Anwender kann nur die Objekte sehen, auf die er auch Leserechte hat. Dies ist besonders in ASP-Umgebungen interessant, wenn mehrere Firmen auf einem Exchange Server arbeiten.

ich kann sowohl auf die Adressbuchansichten Rechte vergeben, so dass der Anwender die Ansicht überhaupt nicht sieht, aber auch in der Ergebnisliste einer Adressbuchansicht sind nur die Anwender gelistet, auf die der Anwender die Leserechte hat.

Aber achten Sie bei der Vergabe von Rechten auf Empfänger und Organisationseinheiten (OUs) darauf, dass zumindest die Exchange Server immer noch die Rechte behalten. Denn wenn der SMTP-Server den Benutzer im Adressbuch nicht mehr findet, dann kann er die Nachrichten auch nicht mehr zustellen. Das gleiche gilt auch für den Store. Wenn der Exchange Store einen Verteiler nicht mehr "finden" kann, dann hat dieser Verteiler auch keine Rechte

Offline Adressbücher

Denken wir wieder mal an die Benutzer, die mit Outlook "unterwegs" sind und ihre Daten gerne mitnehmen und natürlich auch ein Adressbuch unterwegs haben möchten. Schließlich enthält das Active Directory bei ordentlicher Pflege nicht nur die Anwender mit dem NT-Konto, sondern auch die Anschrift, Telefonnummern, Gruppenzugehörigkeit etc, die unterwegs nützlich sind.

Exchange 2000 kompiliert diese Adressbücher je nach Einstellung und legt sie in einem Systemorder (siehe öffentliche Ordner und Kontakte) ab. Diesen Inhalt können Sich dann Outlook Clients replizieren und unterwegs nutzen.

Auf dem Exchange 2000 Server muss ich natürlich einstellen, wie oft Exchange 2000 diese Adressliste kompiliert und welche Adressbücher überhaupt verfügbar gemacht werden.

Bitte beachten Sie zum Thema Offline Adressbuch auch die gesonderten Seiten:

Adresslistenkonzept

Ehe Sie nun aber übereilt Adresslisten anlegen, sollten Sie sich genau überlegen, was Sie damit bezwecken wollen. Die Mitarbeiter werden nämlich diese Adresslisten in ihrer Auswahl später sehen und da ist es schlecht, wenn Sie einige Wochen später schon wieder die Adresslisten umbenennen oder sogar löschen.

mögliche Ziele für Adresslisten könnten daher sein:

  • Geografische Filterung
    z.B. nach Ländern oder Kontinenten
  • Filterung nach Abteilungen
    Eine Liste enthält nur die Empfänger einer Abteilung
  • Filterung nach Empfängertyp
    z.B. eine Liste mit allen Besprechungsräumen oder Verteilern

Im Gegensatz zu Exchange 5.5 können Sie aber nicht sagen: "Bitte generiere eine Liste pro Wert in Feld x". Sie müssen schon jede Liste manuell anlegen. Wenn Sie daher 40 Abteilungslisten benötigen, dass bedeutet das 40 mal eine Adressliste anlegen. Die Sichtbarkeit von Adresslisten kann über Berechtigungen beschränkt werden. So können Sie z.B. mehrere Firmen virtuell auf einem Server betreiben. Allerdings müssen Sie dann auch die Sichtbarkeit der GAL einschränken.

Verwechseln Sie eine Adressliste nicht mit einem Verteiler ! Es ist keine Gruppe. Sie können aber natürlich eine Liste auswählen und dann alle Empfänger in ihren Brief als Adressaten übernehmen.

Für die Generierung von Adresslisten ist ein entsprechender LDAP-Filter erforderlich. Hierbei sollten Sie die beiden Einschränkungen beachten:

  • Kein Filter auf OU
    Sie können einen Adressbuchfilter erstellen, in dem Alle Personen einer OU enthalten sind. Ein Filter in der Art " DN enthält /OU=Vertrieb" ist nicht möglich. Sie müssen daher ein anderes echtes Feld nutzen, z.B.: die Abteilung.
  • Kein Filter auf Multi-Value Felder
    Es gibt mehrzeilige Felder im Active Directory wie z.B. die Mailadressen (ProxyAddresses). Auch hier gelten Einschränkungen bei der Nutzung dieser Felder.
  • UND-Verknüpfung
    Wenn Sie z.B. in einer Adressliste alle Mailboxen mit "Ort= Paderborn" und alle Verteiler enthalten sein sollen, dann haben Sie ein Problem, weil die einfache Eingabe einen Filter ergibt, in dem die Felder "UND-Verknüpft" werden. Nur haben Verteiler meist keinen Ort. Hier hilft dann die benutzerdefinierte Eingabe eines LDAP-Filter

Gut ist, das im Exchange System Manager der Filter sofort "geprüft" werden kann. mögliche Empfänger in einer Adressliste sind

  • Postfächer
  • Kontakte
  • Verteiler
  • öffentliche Ordner

Für die gewünschte Adressliste müssen Sie daher ein LDAP-Filter finden, der über alle Objekte hinweg konsistent ist. In der Regel haben Sie für besondere Zwecke die erweiterten Feld "extendsionAttribute1 -extendsionAttribute16" bewährt da diese meist nicht genutzt werden. Es gibt aber Ausnahmen. Einige Faxserver aber auch NTDSNoMatch und der ADC nutzen ein Feld. Mit einem einfachen Script kann so ein Feld auch aus der Position im AD (DistinguishedName bzw. OU-Pfad) gefüllt werden.

Alternativ kann aber auch ein Filter auf "MemberOf" durchgeführt werden und damit eine Sicherheitsgruppe als Kriterium genutzt werden. Das hat klare unterschiede

Kriterium AD-Feld
z.B. "l" = Ort
Sicherheitsgruppe
Member of
Pflege

Manuelle Eingabe. Kann aber auch per Script oder Import (z.B. aus Personalwesen) gepflegt werden

Manuelle Pflege oder durch Import bzw. kopieren

Tippfehler

Unterschiedliche Schreibweisen sind kritisch. Objekte mit anderer Schreibweise tauchen nicht in der List auf.

Kein Risiko. Aber Neue Objekte müssen in die Gruppe aufgenommen werden, sonst sind Sie ebenfalls nicht sichtbar

delegierte Rechte

Admin des Objekts kann die Felder ändern und damit die Sichtbarkeit in der jeweiligen Adressliste ändern

Admin der Gruppe kann die Mitglieder ändern und damit die Sichtbarkeit in der jeweiligen Adressliste ändern.

Mehrwertigkeit

Ein Feld kann nur einen Wert enthalten. für die Sichtbarkeit in mehreren Adresslisten sind unterschiedliche LDAP-Filter und Felder zu verwenden

Kein Problem, da ein Empfänger in mehreren Gruppen enthalten sein kann.

Nutzung als Verteiler

Ab Exchange 2003 als "Querybased Groups" getrennt zu pflegen und möglich. Aber erlaubt keine Vergabe von Berechtigungen.

Gruppe kann einfach "Mail aktiviert" werden. Sogar Berechtigungen auf Dateisysteme und öffentliche Ordner sind möglich.

Pflege der Felder Nicht alle Fehler sind bei allen Objekten pflegbar. So haben Verteiler und öffentliche Ordner zwar das Feld "l" aber in der MMC ist dies nicht zu pflegen.

Die Exchange Extension Attribute sind bei den Exchange Objekten durchgängig pflegbar.

Alle Exchange relevanten Objekte können Mitglied einer Gruppe sein.

Adresslisten umbenennen und verschieben

Sie können die Adresslisten im Exchange System Manager in einer Hierarchie einordnen. Allerdings wird dies in Outlook nicht so dargestellt, dass der Anwender dann Ordner auf uns zuklappen kann. Jede Änderung der Adressbuchlisten selbst, also verschieben, umbenennen etc, kann einige Zeit dauern. Zum einen weist Sie schon der Exchange System Manager darauf hin:

Aber selbst nach 12 Stunden ist noch nicht alles "aktuell", da gerade Outlook 2003 im Cached Mode primär seine offline Adressbücher nutzt und diese natürlich erst neu aufgebaut und herunter geladen werden müssen.

Adresslisten intern

Wenn Sie nun glauben, Sie pflegen bei einer Adressliste einfach nur einen LDAP-Filter und Outlook nutzt diesen einfach bei der Anzeige der Adressliste, dann irren Sie. Würden Outlook Client bei der Auswahl einer Adressliste den vom Administrator hinterlegten Filter gegen den DC ausführen, bestünde die Gefahr einer DC-Überlastung. Ein Administrator kann ja LDAP-Filter konfigurieren, die Felder ohne Index nutzen. Eine solche Suche würde lange dauern und viel Ressourcen fressen. Daher arbeite Exchange anders. Wann immer sie eine Adressliste anlegen oder ändern, wird bei den Anwendern, die in diese Adressliste fallen, das Feld "ShowInAB" aktualisiert.

Es hängt nun von der Exchange Version ab, welcher Prozess diese Einträge aktualisiert.

  • Exchange 2000/2003
    Der RUS ist dafür zuständig, geänderte Adresslisten zu erkennen, die Mitglieder auszuwerten und bei allen Benutzern das Feld entsprechend zu aktualisieren oder auch wieder zu entfernen
  • Exchange 2007/2010
    Hier machen dies gleiche die entsprechenden PowerShell Kommandos, die bei einer Änderung einer Adressliste durch die Empfänger laufen, z.B.

get-mailbox | set-mailbox -applymandantoryproperties

Eine manuelle Änderung an diesem Feld ist nicht ratsam !! Wenn Outlook dann eine Adressliste nutzt, dann nimmt er sich den DN der Adressliste und sucht danach im Feld "ShowinAddressBook", welches durch die Exchange Schema-Erweiterung mit einem Index versehen ist.

Dieses Verständnis ist in mehrfacher Hinsicht relevant:

  • Bereich "Hosting"
    Hier sieht ein Benutzer nur genau eine GAL-Adressliste. In der muss er auch Mitglied sein
  • MAPI-Probleme
    Sehr oft ist ein Benutzer "noch nicht" in der Adressliste sichtbar, obwohl er schon eine Mailadresse etc. hat. Dann kann es daran liegen
  • Inkonsistenzen und alte Anzeigen
    Probleme beim RUS oder Berechtigungen führen ebenfalls dazu, dass dieses Feld vielleicht nicht zeitnah aktualisiert wird und damit Benutzer noch nicht in der richtigen oder noch in der falschen Adressliste erscheinen-

Wenn also Benutzer sich nicht in Outlook (MAPI) anmelden können oder nicht in Adressbüchern erscheinen, dann kann es durchaus damit zusammen hängen.

LDAP und Exchange und "kein RUS"
Adresslisten werden über LDAP/OPATH-Filter definiert aber Exchange leitet davon das ShowInAddressbook ab. Wer an den Exchange Commandlets vorbei Feldinhalte ändert, die für Adresslisten verwendet werden, dann stimmt die Adressliste nicht mehr. Ein "Update-Recipient" oder eine Neugenerierung der Adressliste ist in dem Fall erforderlich.

Weitere Links