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 "OnPremise" 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

  • Firmentrennung beim Hosting
    Das ist der primäre Einsatz von ABP, bzw. der Fall, auf den alle Anbieter lange gewartet haben. Wer bislang auf Exchange 2007 mehrere Kunden "separiert" betreibt, konnte dies mit Exchange 2010 RTM gar nicht umsetzen und mit Exchange 2010 SP1 erst über den "/hosting"-Schalter mit den bekannten Einschränkungen betreiben. Exchange 2010 ABP erlaubt es nun in einer normalen Exchange Umgebung den einzelnen Einheiten (z.B. Firmen, Kunden, Teilbereiche) eine eigene Adresslisten zu geben
  • Sichtbarkeit begrenzen
    Interessant ist die Funktion auch für den internen Einsatz. Stellen Sie sich vor, ihre Firma nutzt eine GAL und pflegt auch das Feld "Manager". Nun kann eigentlich jeder Mitarbeiter eine Person suchen und sich über den Manager nach oben und über Verteiler wieder weiter hangeln. Mit wenige Code könnte so ein komplettes Organigramm erstellt werden. Es kann daher auch interessant sein, für bestimmte Anwender, die ein Postfach haben (z.B. Consultants, Azubis etc.) einen per ABP beschränkten Zugriff auf Exchange Adressbücher einzurichten. Genauso könnten z.B.: Testkonten und besondere Verteiler vor der Masse "verborgen" werden, ohne das Objekt gleich komplett als "Hide from Addressbook" zu kennzeichnen.
  • Nutzen erhöhen
    In der GAL sind in der Regel alle Exchange Empfänger. Gerade für Vertrieb und andere Personen wäre es aber wünschenswert, z.B. auch die Kontaktadressen aller Kunden über die GAL zu erhalten. Mit Exchange ist das ganz einfach: Sie lesen die Kontakte aus der ERP-Anwendung aus und importieren diese als Kontakte im Active Directory (z.B. mit MiniSync oder CSV2Contact). Dumm nur dass, diese Kontakte nun durch alle Personen gesehen werden und deren OAB aufbläht. Das können Sie mit ABPs derart lösen, dass der Vertrieb eben eine GAL bekommt, in der alle Firmenmitarbeiter abzüglich Testkonten zuzüglich Kontakte enthalten sind. Alle anderen Mitarbeiter bekommen eine GAL, in der die ERP-Kontakte nicht enthalten sind.

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.

  • Mailrouting
    Mails von einem "Kunden" zum anderen "Kunden" verlassen technisch nicht die Organisation. Sie sind also nicht "External", so dass diese nicht konvertiert werden. Auch die Umsetzung von Funktionen auf einem Gateway (Disclaimer, Verschlüsselung, Archiv, Spamschutz) können maximal auf Ebene des Transportagenten oder über Transportregeln umgesetzt werden.
  • Ressourcen-Throttling
    Da alle Clients z.B. die gleiche CAS-Server nutzen, werden auch hier alle Kunden "gleich" behandelt. Eine Priorisierung ist nicht möglich.
  • Internal/External/OOF
    Auch mit getrennten Adresslisten sind alle Empfänger weiterhin in "einer" Organisation. Regeln, die z.B. Abwesenheitsassistenten betreffen und nach "intern" und "extern" unterscheiden, werden erst mal nicht angewandt. Hier können intelligente Transportagenten helfen, die aber noch nicht Bestandteil von Exchange sind.
  • Verfügbarkeit
    Frei/Belegt-Zeiten sind ein weiteres Thema. Per Default kann jeder ja die "Belegt-Zeiten" abfragen. Selbst wenn die anderen Empfänger nicht in der GAL erreichbar sind kann ein fixer Anwender seinen eigenen LegacyExchangeDN in Erfahrung bringen und über Raten und direkte Eingabe diese Daten von anderen Personen abrufen.
  • Nur für Exchange 2010 Mailboxen
    ABP ist Bestandteil des Ex2010 SP2 CAS-Rolle, gegen die sich Outlook und andere Dienste verbinden. Nur beim Zugriff über diese Wege und für diese Version werden die ABPs angewendet.
  • LDAP (z.B. Mac)
    Dienste, die weder ExchangeAB noch EWS nutzen, sondern direkt per LDAP den DC erreichen können, werden nicht gefiltert, d.h. diese Clients würden alle Empfänger sehen. Es gibt keine ACLs auf OUs oder Adresslisten. Es darf daher nicht möglich sein, das Active Directory direkt zu erreichen. Mac Entourage und Outlook Mac nutzen Autodiscover und erhalten so aber den Namen eines DCs und umgehen ABP. Nur wenn der DC nicht erreichbar ist, nutzen sie EWS.
  • Exchange auf DC nicht erlaubt
    Dann ersetzt nämlich das Active Directory die NSPI-Funktion von Exchange, die dann aber nicht die Address Book Policies berücksichtigt. Das sollte aber nur in Testfeldern zu Verwirrung führen, da ABP für größere Firmen ist, die sicher nicht Exchange auf DCs installieren.
  • Sharepoint und Lync
    Diese Produkte, die im gleichen Forest installiert sein können, nutzen andere Wege, um die Sichtbarkeit zu steuern. Diese müssen parallel aufgebaut und konfiguriert werden.
  • 3rd Party Produkte
    Das gilt natürlich auch für alle anderen Drittprodukte, die auf Servern installiert und von Anwendern bedient werden können (z.B. Provisioning, Faxserververwaltung o.ä.) die eigene Wege zur Filterung anbieten. Aber auch Dienste, die ein generisches Dienstkonto, z.B. Blackberry nutzen, umgehen unter umständen die ABPs
  • Management von Gruppen
    Über das Exchange Control Panel können Sie Anwendern erlauben, z.B. Gruppen und deren Mitglieder als "Self-Service" zu verwalten. Leider ignoriert das "Get-Group"-Commandlet die APBs, so dass die diese Verwaltung abschalten müssen, wenn Verteiler in mehreren Adressbook Polices aufgeführt werden.
  • RemoteDomains und OOF
    Über Remote Domains kann ein Admin normalerweise steuern, welche Informationen externe Domänen erhalten (z.B. OOF, Formatierung etc.). Diese Einstellungen wirken nicht zwischen Firmen auf der gleichen Hosting Umgebung und vor allem sind die Einstellungen nicht pro Firma individuell zu steuern.
  • NDR und Postmaster
    Leider ist es mit Exchange nicht möglich die Unzustellbarkeiten anhand der ursprünglichen Zieldomäne mit dem "postmaster@zieldomäne" zu beantworten. Insofern kann ein externer Sender doch erkennen, bei welchem Dienstleister der Empfänger seine Postfächer hosted.
  • OrgForms
    Ich kenne keinen Provider, der Formulare anbietet, weil alle "Kunden" ihre Formulare im gleichen Public Ordner ablegen müssten. Etwas anderes wäre es, wenn der Hoster z.B. einen zentralen Faxserver mit passendem Formular anbietet. Kundenspezifische Formulare werden aber eher nicht realisiert.

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.

  • Addresslist
    Davon kann es sehr viele geben und Sie können sicherlich die Adresslisten für "Alle Postfächer", "Alle Kontakte", "Aller Verteiler" etc. Dies sind weiter nutzbar aber natürlich wird man pro "Einheit" nur eine Teil sichtbar machen wollen.
  • Global Address List
    Üblicherweise gibt es die nur "einmal". Aber wer mehrere unabhängige Einheiten betreibt, wird natürlich jeder Einheit "ihre" eigene GAL zuweisen, die dann nur eine gefilterte Ansicht enthält.
  • Offline Address List
    Damit Outlook im Cached-Mode oder Offline eine Adressliste hat, sollten Sie für jede Einheit natürlich auch eine eigene GAL als "Offline-Version" bereit stellen.
  • Room Address List
    Eine "besondere" Adressliste, die speziell bei der Terminplanung in Outlook nützlich ist, wenn hier die Besprechungsräume aufgeführt werden.

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:

  • Globale Adressliste
    Achten Sie darauf, dass das Konto selbst auch in dieser GAL enthalten ist.
    Die GAL können Sie leider noch nicht per GUI erstellen, z.B. mit

# 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

  • Adresslisten
    Sofern bedarf besteht, können Sie weitere Adresslisten angeben. Das geht per GUI aber bei vielen Firmen ist die PowerShell eleganter. Sie müssen aber mindstens eine Adressliste und eine Raumadressliste anlegen
New-AddressList al-firma1 `
    -ConditionalCompany Firma1 `
    -IncludedRecipients Allrecipients
New-AddressList al-firma1 `
    -RecipientContainer ou=firma1,ou=kunden,dc=provider,dc=tld
    -IncludedRecipients Allrecipients
  • Offline Adressbuch
    Idealerweise basierend auf der passend angelegten Adresslisten. Bitte geben sie NICHT die "Default GAL" mit an.
  • Raumliste
    Sie können den Anwendern auch noch eine Raumliste mitgeben, damit Sie gleich gefiltert die Besprechungsräume sehen.

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

  • Auswahl von Adresslisten im Picker
    In Outlook können Sie im Adressbuch die Adresslisten auswählen. Hier sehen Sie dann nur noch die Adressen in ihrer Policy
  • Auflösen von Adressen
    Wer in Outlook eine Adresse nicht vollständig eingibt, dem schlägt Outlook eine Adresse vor oder bietet einen Dialog zur Auswahl an.
  • Räume in Besprechungen addieren
    Auch hier sehen Sie natürlich nur "ihre" Raumliste
  • Suche in der GAL
    Hier wird nicht mehr die globale sondern eben nur die eine GAL genutzt, die in der Richtlinie hinterlegt ist. Hier ist wichtig, dass der Benutzer selbst natürlich auch in der GAL sichtbar sein muss.
  • Suche mit "Voice Access"
    Über die Exchange UM-Rolle ist es heute schon möglich, per Sprache im Adressbuch nach dem Ansprechpartner zu suchen. Auch hier muss über die ABP gefiltert werden.
  • Adressbuchsuche über Mobilgeräte (ActiveSync)
    Auch über das ActiveSync-Protokoll ist eine Suche in der GAL, bzw. nach Einführung der ABPs nur in der zugewiesenen GAL  möglich. Hier ist zu prüfen, ob andere Produkte (z.B. Blackberry, Goodlink, etc.) den Exchange CAS-Server nutzen. Selbst wenn Sie dies tun ist es immer noch ein unterschied, ob ein generisches Dienstkonto auf alle Postfächer zugreift. Meines Wissens nach nutzt z.B. Blackberry immer noch nicht "Kerberos Delegation" um im Auftrag des Anwender zu arbeiten. Andere Produkte könnten per LDAP sogar an dem Exchange 2010 SP2 CAS vorbei gehen
  • Ansicht von Mitgliedern in Verteilerlisten
    Das ist besonders knifflig, weil Benutzer ja in Verteilen Mitglied sein könnten, die sie selbst nicht sehen und umgekehrt in einem Verteiler Mitglieder sein könnten, die der Anwender über das normale Adressbuch nicht sieht. Exchange filtert dieser raus. ABP filterst diese Einträge, damit ein Anwender sich so nicht "durch hangeln" kann. Das führt natürlich auch dazu, dass Sie vielleicht eine Mail an einen Verteiler senden und es viel mehr Empfänger gibt.
  • Mailtipps
    Wobei eigentlich die "Mailtipps" sie vorab informieren sollten. Da aber auch Mailtipps sich an ABP orientiert, könnte es dennoch sein, das Sie eine Mail an einen "kleinen" Verteiler senden, die dann aber später doch geblockt werden könnte.

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öglich 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.

  • Exchange 2010 Setup mit PrepareSchema, PrepareAD und PrepareDomain bzw. PrepareAllDomains
    Damit werden Schema erweitert aber vor allem die neuen Sicherheitsgruppen für RBAC angelegt und natürlich die Berechtigungen auf die verschiedenen Container vergeben.
  • Downtime einplanen
    Damit das Exchange Setup funktioniert, muss es die "Default GAL" lesen können. In verschiedenen Quellen steht, dass dazu die Rechte wieder kurz zurück gesetzt werden müssten. Das ist natürlich nur ohne aktive Clients möglich, welche ansonsten ja zumindest kurzfristig "alles" sehen könnten.

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.

  • ABP analog einrichten
    In Exchange 2007 haben sie in der Regel eine Sicherheitsgruppe pro Benutzerkreis angelegt, welche dann auf die Adresslisten zugreifen durften. Da diese Funktion später die ABPs übernehmen, sollten Sie analog entsprechende ABPs einrichten, die die gleichen Adresslisten enthalten und später den Anwendern zugewiesen werden können
  • User migrieren, ABP anwenden
    Die Nutzdaten der Anwender werden über eine "normale" Migration verschoben. Nach Abschluss der Migration müssen Sie aber umgehend noch zwei weitere Einstellungen durchführen: Zum einen muss die nun gültige ABP zugewiesen werden., damit der Exchange 2010 SP2-CAS-Server die Adressen korrekt filtert. Sie sollten aber auch die Änderungen rückgängig machen, die für die Segregation 2007 gesetzt wurden. Hier ist das Feld "msExchQueryBaseDN" maßgeblich, welche wieder "leer" sein sollte.
  • Optional: Benutzer aus der Gruppe entfernen
    Nachdem der Anwender nicht mehr auf Exchange 2007 arbeitet, können Sie ihn aus den Gruppen entfernen, die ihm bislang unter Exchange 2007 den Zugriff auf die Adresslisten gewährt haben. Exchange 2010 berücksichtigt diese nicht mehr. Sollten Sie die Gruppe aber für andere Dienste noch benötigen (Dateisharing, Sharepoint, etc.), dann sollten Sie den Benutzer natürlich nicht entfernen. Bitte löschen Sie die Gruppe jetzt noch nicht !
  • ACLs auf den ALs wieder zurück setzen.
    Ehe Sie die Gruppe löschen, sollten Sie die bei der Einrichtung der Segregation 2007 vorgenommenen Änderungen an ACLs wieder rückgängig machen. Noch "sehen" sie ja den Klarnamen der Gruppe und nicht mehr nur eine verwaiste SID.

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