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.
- Q822940 - How to Manage Address Lists When You Host Virtual
Organizations
http://support.Microsoft.com/?id=822940 - Microsoft Seite für Hoster
http://www.microsoft.com/serviceproviders/solutions/hostedmessaging.mspx - Beschreibung von Amit Zinman mit Bildern
http://www.msexchange.org/tutorials/Shared-Hosting-Exchange-2003-Part2.html
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
- GAL
- Adress book Polices
- Segregation 2007
- Segregation2007 Checkliste
- Exchange Hosting
- Q250455 XADM: How to Change Display Names of Active Directory Users
- Q300427 How to Change Active Directory Display Names
- Q277717 Change Display Names of Active Directory Users with ADSI Script
- Q319213 How To use Address Lists to Organize Recipients in Exchange 2003
- Q812218 XCCC: "The Search Could Not Be Completed" Error Message When You Search für Addresses
- OABInteg
- Tools DumpAddresslist
- Tools DumpOrt
- Exchange Offline Adressbuch anlegen
- Tools um die GAL in Kontakte zu verwandelt
http://www.slipstick.com/exs/portagal.htm