Exchange 2010 Address Book Policies (ABP)

Für diese Funktion ist Exchange 2010 SP2 erforderlich. Siehe E2010 SP2

Wer bislang schon Segregation 2007 z.B.: anhand der Segregation2007 Checkliste eingerichtet hat, wird sich die Migration dieser Umgebung anschauen wollen. Beachten Sie auch den Vergleich auf Exchange Hosting

Achtung:
Verwechseln sie nicht "Hosting" mit "Segregation". Segregation ist kein Hosting, sondern der Betrieb einer Exchange Organisation für den Eigenbetrieb mit einer Filterung der Adressliste. Hosting ist der Betrieb mehrerer virtueller Exchange Organisationen in einem Forest. Siehe auch Exchange Hosting.

Etwa im Frühjahr 2010 hat auch Microsoft gemerkt, dass es zwischen dem Exchange Betrieb "on Premise" mit einer großen globalen Adressliste und dem Betrieb mit dem "/Hosting"-Switch für viele virtuelle Firmen eine Lücke gibt.

Ein riesiger Vorteil von Exchange in größeren Umgebungen ist die Nutzung des Active Directory für die Verwaltung der Empfänger aber auch der Konfiguration. Damit macht es fast keinen Unterschied, ob ihre Exchange Umgebung nun aus einem oder vielen verteilten Servern besteht. Alle wissen das gleiche und können alles sehen. Auch die Anwender können in der globalen Adressliste einfach suchen und finden.

Genau das ist aber in noch größeren Firmen dann wieder ein Problem, wenn nicht jeder darf von allen gesehen werden oder der Betrieb einer gemeinsamen Umgebung für mehrere Fachbereiche oder Firmenteile erlaubt es nicht, diese auch logisch voneinander abzuschotten. Bislang lautet die Lösung bei Exchange 2010 also immer: "Mit gehangen Mit gefangen" oder Sie haben für jede Firme eine eigene Exchange Organisation aufgebaut oder eben mit "/hosting" gearbeitet. Aber genau der "/Hosting"-Betriebsmode hat doch umfangreiche Einschränkungen, z.B. kein Unified Messaging, keine Public Folder und andere (Siehe Exchange Hosting).

Mit Address Book Polices wird eine ähnliche Funktion wie von Segregation 2007 bekannt mit Exchange 2010 bereit gestellt, die aber technisch komplett anders umgesetzt ist weil auch Exchange 2010 im Vergleich zu Exchange 2007 anders funktioniert. Daher sind auch alle Anleitungen von Exchange 2007 nicht auf Exchange 2010 anwendbar.

Die Funktion von ABP wurde von Greg Taylor auf der TechEd 2011 in Orlando erstmals öffentlich vorgestellt.

TechEd 2011: EXL326 What's New in Microsoft Exchange Server 2010 SP2: Featuring GAL Segmentation
http://channel9.msdn.com/Events/TechEd/NorthAmerica/2011/EXL326
Powerpoint: http://media.ch9.ms/teched/na/2011/ppt/EXL326.pptx
Video: http://media.ch9.ms/teched/na/2011/wmv/EXL326.wmv
Video: http://media.ch9.ms/teched/na/2011/wmv-hq/EXL326-HD.wmv

Einsatzbereiche

Auch wen ABPs primäre der Nachfolger der Exchange 2007 Segregation sind und bestimmten Personenkreisen "ihre" individuelle GAL" zugewiesen werden kann, so geht der Einsatzbereich weit über das "Hosting" hinaus. Hier ein paar Denkansätze

Sie sehen also, dass es nicht nur "Hosting" ist. Beachten Sie da aber auch die Einschränkungen bzgl. LDAP.

Wichtige Einschränkungen

Ehe sie nun jubelnd durch die Flure stürmen sollten sie kurz innehalten und genau prüfen, was ABP ist und vor allem was es nicht ist:

Adressbuchrichtlinien wirken sich nur auf die Sichtbarkeit von Adresslisten und der Mitglieder beim Zugriff über den Exchange Adressbuchdienst (MSExchangeAB) und Exchange Web Services (EWS) aus

Aber der Betrieb einer "MultiTenant" Umgebung kennt noch weitere Dinge. Office 365 ist z.B. "eine Exchange Installation" aber mit mehreren "Tenant"-Services. Office365 nutzt angeblich weder ABPs noch "/hosting", sondern eine ganz eigene Basis. Wenn eine Umgebung aussehen sollte, als wenn es mehrere unabhängige Exchange Organisationen wären, dann gelten bezüglich der Adressbuchrichtlinien einige Besonderheiten.

Und es gibt noch ein paar andere kleinere Hürden und Abhängigkeiten, die ich aber nicht alle hier aufzählen kann. Den Aufbau einer "Hosted Umgebung" mit Exchange bedeutet mehr als nur etwas "Setup" aufzurufen.

Funktion

Der große Unterschied zu Exchange 2007 ist, dass die Richtlinie mit den Adresslisten an ein Postfach explizit "zugewiesen" wird. In Exchange 2007 konnte ein Anwender theoretisch alle Adresslisten erreichen, wenn diese nicht über ACLs explizit gelöscht oder erlaubt wurden. Exchange kennt mehrere Adresslisttypen, die bei den Richtlinien berücksichtig werden müssen.

Sie können problemlos mehrere Adresslisten pro Typ definieren, z.B. für jede Firma eine eigene Gruppe von Adresslisten. Der Inhalt der Adressliste wird über Filter definiert. Es kann durchaus sein, dass ein Element in mehreren Adresslisten erscheint

Achtung:
Prüfen sie vorab, welche Felder sie für die Filterung nach Adresslisten nutzen wollen. Das Feld "Company" erscheint auf den ersten Blick geeignet, aber ein Verteiler hat keine "Company". Am elegantesten ist die Nutzung der "Custom Attributes", die Exchange schon seit der ersten Version bereit stellt.

Planung

Ohne Planung geht es nicht und das gilt umso mehr, wenn Sie mehrere Adresslisten und Firmen miteinander auf der gleichen Plattform betreiben wollen. Relativ einfach ist die Planung, wenn es überhaupt keine Überlappung von Personenkreisen gibt, z.B. bei einer Bereitstellung von Messaging-Diensten für mehrere voneinander unabhängigen und daher abgetrennten Firmen. Anders sieht es aus, wenn es sehr wohl Überlappungen gibt, z.B. weil mehrere Firmen die gleiche Geschäftsführung haben oder z.B. in einer Bildungseinrichtung die Schüler der Jahrgangsstufen sich nicht gegenseitig sehen dürfen. aber die Lehrer natürlich schon alle Schüler sehen müssen. In Universitäten ist es nicht unüblich, dass alle Postfächer auf Exchange laufen aber unterschiedliche Sichtbarkeitskreise bestehen. Microsoft hat dazu sehr viele nette Bilder und Animationen als Powerpoint veröffentlicht (Siehe auch http://channel9.msdn.com/Events/TechEd/NorthAmerica/2011/EXL326 bezüglich Powerpoint und Video), so dass ich es hier auf der Bereitstellung von Exchange für getrennte Firmen belassen will. Hierbei gibt es für jede Firma die gewünschten Adresslisten, eine Raumadressliste, eine GAL und ein OAB.

Firma Firma Firma2
Adresslisten AL-Firmenname1-Mitarbeiter
AL-Firmenname1-Verteiler
AL-Firmenname1-Vertrieb
AL-Firmenname1-Marketing
AL-Firmenname1-Technik		 AL-Firmenname2-Mitarbeiter
AL-Firmenname2-Verteiler
AL-Firmenname2-Vertrieb
Globale Adressliste GAL-Firmenname1 GAL-Firmenname2
Raumadressliste AL-Firmenname1-Räume AL-Firmenname2-Räume
Offline Addressbuch OAB-Firmenname1 OAB-Firmenname2
Adressbuch Policy ABP-Firmenname1 ABP-Firmenname2

Es ist nicht zwingend, dass alle Firmen die gleichen Adresslisten haben. Über ein passendes Namenskonzept ist aber sicher zu stellen, dass die Namen der Listen organisationsweit eindeutig sind.

Ein Benutzer hat dann immer genau eine Adressbuchrichtlinien. Der CAS-Server prüft dann den Benutzer beim Zugriff, ermittelt die Adressbücher anhand der Richtlinie und setzt diese um.

Da diese Prozesse essentiell für die Abtrennung sind und Menschen bei Routinetätigkeiten leicht etwas übersehen, ist es ratsam diese Einstellungen sowohl beim Anlegen und Entfernen einer Firma als auch beim Einrichten neuer Postfächer möglichst zu automatisieren. Ein Provisioning spart ihnen Zeit und Fehler und letztlich kann der Kunde es sogar "selbst" machen, was ihm den Eindruck einer 24h-Bereitschaft gibt und den Anbieter wieder Kosten spart.

Die Zuweisung wird dann üblicherweise per Powershell erfolgen.

Einrichtung

Die Konfiguration der ABPs hat es sogar bis in die GUI geschafft. Legen Sie wie gewohnt erst mal die vier verschiedenen Adresslisten an:

# GAL mit Company als Filter anlegen
New-GlobalAddressList gal-firma1 `
    -ConditionalCompany Firma1 `
    -IncludedRecipients Allrecipients

# GAL basierend auf einer OU anlegen
New-GlobalAddressList gal-firma1 `
    -RecipientContainer ou=firma1,ou=kunden,dc=provider,dc=tld
    -IncludedRecipients Allrecipients

New-AddressList al-firma1 `
    -ConditionalCompany Firma1 `
    -IncludedRecipients Allrecipients
New-AddressList al-firma1 `
    -RecipientContainer ou=firma1,ou=kunden,dc=provider,dc=tld
    -IncludedRecipients Allrecipients

Nachdem Sie diese Elemente angelegt haben, können Sie diese ebenfalls über die GUI zu einer Adressbookpolicy zusammenstellen.

Im darauffolgenden Fenster sind die Adresslisten zu spezifizieren

Oder als Powershell

new-AddressBookPolicy -Name 'ABP Firma1'
`   -GlobalAddressList '\gal-firma1' `
    -OfflineAddressBook '\Default Offline Address Book' `
    -RoomList '\al-firma1' `
    -AddressLists '\al-firma1'

Auf den Benutzer selbst kann immer genau eine Richtlinie zugewiesen werden. Die Zuweisung kann nicht pro OU, Datenbank oder andere Übermengen erfolgen sondern nur auf den Benutzer selbst (Vergleichbar zu Throttling und ActiveSync Polices). Die ABP kann schon beim Anlegen des Benutzers über die GUI zugewiesen werden:

Der entsprechende Parameter beim New-Mailbox ist selbsterklärend

Enable-Mailbox -Identity 'E2010.local/msxfaq/newUser' `
    -Alias 'NewUser' `
    -AddressBookPolicy 'ABP Firma1'

Auch nachträglich ist eine Pflege über die GUI möglich

Auch hier ist die Powershell in der Regel die bessere Wahl, besonders wenn es um "Massenänderungen" geht

Set-Mailbox user1 `
    -AddressBookPolicy "abp firma1"


# Anwendung der Einstellung auf alle Empfänger einer OU
Get-Mailbox -OrganizationalUnit firma1 | 
    Set-Mailbox -AddressBookPolicy "abp firma1"

Bitte beachten Sie
Die Filterung der Ansichten erfolgt nur, wenn der Client über den Exchange 2001 SP2 CAS-Server auf Exchange zugreift. Sie müssen daher zuverlässig verhindern, dass Client an Exchange vorbei per LDAP direkt die Domaincontroller befragen. Bei einem "echten" Hoster wird dies der Regelfall sein, denn wer würde schon seine DCs auf dem Internet per 389/TCP erreichbar machen. Beim Einsatz innerhalb von Firmen ist dies entsprechend umzusetzen.

Praktischer Einsatz für Firmen über Abteilung

ABPs sind nicht primär für den "Hosting" Betrieb, da sie zwar die "Sichtbarkeit" in den Adresslisten beschränken aber die Kommunikation zwischen den verschiedenen Firmen nicht unterbricht (Stichwort intern/externe Out of Office Meldungen. Zugriff auf Frei/Belegt-Zeiten etc.). Für Firmen selbst aber ist ABP schon genial, denn je größer eine Firma ist, desto länger die die Adresslisten. Hier können z.B. nach Landesgesellschaften oder Abteilungen eigene zusätzliche Adresslisten erstellt werden. Sie haben dann noch die Wahl ob jede dieser Teileinheiten eine eigene GAL (gefiltert) bekommt oder die globale GAL beibehalten wird.

Dieses Beispiel nutz das Feld "Department". Das ist leider ein "String" und wenn Sie der der Stammdatenpflege nicht sauber arbeiten ist so eine Feld vielleicht nicht die beste Datenquelle. Denkbar ist auch eines der ExtensionAttributes. Wer eher an ein "Hosting" denkt, wird pro Kunde vielleicht eine OU definiert haben. Dann ist diese ein besseres Kriterium.

Das Anlegen der "Abteilungs-Adresslisten" lässt sich per Powershell sehr schnell einrichten:

$departmentlist = Get-Recipient  `
                      -resultsize unlimited `
                      -Filter {department -ne $null} | group department -NoElement

Foreach ($department in $departmentlist) {
   $depname = [string] $Department.name
    write-host "Processing:$Depname"
    if ((get-addresslist $Depname) -eq $null){
        write-host "Create Addresslist $Depname"
        new-addresslist -name $Depname  -ConditionalDepartment $Depname -IncludedRecipients AllRecipients
    }
}

Analog dazu können Sie die "departmentlist" natürlich auch dazu nutzen, die ABPs anzulegen und bei den Benutzern auch gleich zuzuweisen. Wer das Skript dann einfach regelmäßig startet, hat schon das "kleine Provisioning" fertig. Host werden natürlich das Provisioning schon beim "Anlegen" der Firma und des Users machen und nicht im nachhinein.

Präsentation auf dem Client

Weiter oben habe ich schon beschrieben, was nicht geht oder welche "Lücken" dieses System hat, so hilft vielleicht auch eine "Positiv-Liste" weiter, welche Funktionen durch ABP abgedeckt werden

Sie sehen schon, das die Einführung von ABPs nicht alle Problemfälle perfekt abdeckt. Besonders wenn es "Überlappungen" der Empfänger gibt, was seit Exchange 2010 nun wieder mögich ist (In Exchange 2007 sollte man das unbedingt vermeiden), so erscheinen dann die anderen Effekte.

Migration von Ex2007 Segregation

Unter Exchange 2007 gab es keinen "/hosting"-Schalter. Statt dessen wurde die Segregation 2007 eingesetzt. Damit stellt sich die Frage, wie eine Umgebung von dieser Konfiguration auf die neue Exchange 2010 Lösung mit Address book policies umgestellt werden kann.

Nach Abschluss der Migration werden natürlich alle Exchange 2007 Spuren und Berechtigungen entfernt sein, weil Exchange 2010 natürlich komplett anders die Berechtigungen (Stichwort RBAC) verwaltet. Für die Übergangszeit muss es also Exchange 2010 möglich sein, wie gewohnt zu arbeiten und trotzdem darf das Prinzip von Exchange 2007 Segregation nicht durchbrochen werden, damit die Anwender nicht zu viel sehen. Aber von den verschiedenen Wegen gibt es nur zwei offiziell unterstützte Migrationspfade:

Der Weg von der Exchange 2007 Segmentierung mit ACLs auf den Adresslisten zu Exchange 2010 SP2 ABPs ist ebenso möglich wie die Migration bisheriger Umgebungen vom HMC-Framework auf Exchange 2010 mit "/hosting". Eine Migration von allen Versuchen mit Exchange 2010 die gleiche Separierung zu erreichen sind nicht unterstützt. Hier könnte der Weg nur heißen, wieder temporär zurück auf Exchange 2007 oder gleich auf Exchange 2010 ohne Separierung zu gehen und dann ganz ganz schnell zu migrieren. Oder dann doch eine neue Exchange Organisation aufbauen und "Cross-Org" migrieren.

Technisch dürfte die Migration wie folgt ablaufen.

Ich bin nicht sicher, ob diese Einschränkung wirklich erforderlich ist. Theoretisch könnte man vorab den Exchange Konten explizit Rechte auf die Adresslisten geben und so das Setup durchlaufen lassen. Hier warte ich auf die finalen Migraionsleitfäden.

Maßgleich für jede Migration sollten aber die finalen Exchange Migrationsdokumente sein, welche aber heute (24. Okt 2011) noch nicht public sind.

Weitere Links

Keywords:Segregation ABP Addressbookpolicies