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.

Das globale Adressbuch

Auch das Globale Adressbuch ist nichts anderes als einen LDAP-Anfrage ohne Filterkriterium. Exchange 2000 liefert dann alle Mailempfänger im gesamten Forrest.

Dem globalen Adressbuch kommt eine besondere Rolle zu. Diese Einträge sind zugleich die Einträge, anhand denen Exchange 2000 seine Nachrichten routet. Und diese Adressliste sollte in einer gemischten Umgebung mit Exchange 5.5 die gleiche Anzahl an Elementen enthalten. Dies ist recht einfach mit dem Exchange 5.5 Administrator auf dem SRS-Server zu prüfen.

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:

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:

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

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.

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 "ShowinAB", welches durch die Exchange Schema-Erweiterung mit einem Index versehen ist.

Dieses Verständnis ist in mehrfacher Hinsicht relevant:

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.

Ich habe ein Programm CheckAddresslist, welches solche Inkonsistenzen aufspürt. Es ist aber noch nicht fehlerfrei und wird zu gegebene Zeit nachgereicht.

Weitere Links

Keywords: OAB Adressbuch Adresslisten GAL