Öffentliche Ordner - Clientzugriff

Ein wichtiger Aspekt ist natürlich der Zugriff der Anwender auf die öffentlichen Ordner. Wie findet der Client den Weg zu einer Instanz des Ordners ?

Bislang wissen Sie, dass der Inhalt eines Ordners nicht auf allen Server der Organisation vorhanden sein muss, sondern vielleicht nur einige Server ein Replikat tragen. Trotzdem kennen alle Server in der Organisation mit einem öffentlichen Informationsspeicher alle Ordner. Dazu dient ein Systemordner namens "Hierarchy", der intern den Namen "1-1" trägt Dieser Ordner enthält die Information über alle anderen Order (Besitzer, Berechtigungen, Replikate, Grenzwerte etc.). Dies ist für das weitere Verständnis wichtig.

Der Client greift auf einen Ordner zu

Jeder Anwender mit einem Postfach hat einen "Homeserver" auf dem das Postfach liegt. Bei genau diesem Postfachspeicher ist bei Exchange 2000/2003 hinterlegt, welchen Öffentlichen Ordner Speicher dieser Benutzer als Standardspeicher benutzt. Bei Exchange 5.5 ist es immer der gleiche Server, auf dem das Postfach liegt.

Der Client spricht den Informationsspeicherdienst (STORE.EXE) dieser Datenbank an. Der STORE.EXE seinerseits schaut nun in seine Hierarchie nach, auf welchen Servern der Exchange Organisation ein Replikat der Inhalte zu finden ist. Übrigens kann jeder Server jetzt schon feststellen, ob Sie als Anwender überhaupt die Rechte dazu haben, den Ordner oder dessen Inhalte zu sehen.

Ausgehend von der Liste der Replikate passiert nun folgendes:

Beim Einsatz von Exchange 5.5 werden für die Ermittlung der Kosten jedoch nicht die Kosten der Connectoren heran gezogen, sondern die Kosten der konfigurierten Affinität. Alle anderen Dinge sind identisch.

Es kann aber passieren, dass mehrere Server die gleichen Kosten haben. Der Client wird nun aber nicht bei jeder Frage zu einem anderen Server verwiesen, sondern der Store verteilt die Anfragen der Clients auf die verschiedenen gleichwertigen Server aber sorgt dafür, dass ein Client immer den gleichen Server nutzt. Damit wird eine konsistente Ansicht der Ordner erreicht.

Affinität und Referral mit Exchange 2007/2010

Die Exchange Produktdokumentation beschreibt den Vorgang pro Produkt sehr schön
Understanding Public Folder Referrals
Exchange 2010 http://technet.microsoft.com/en-us/library/bb691235.aspx
Exchange 2007 http://technet.microsoft.com/en-us/library/bb691235(EXCHG.80).aspx

Exchange 2007/2010 können sich nicht mehr an den "Sites" von Exchange 5.5 und den Routinggruppen von Exchange 2000/2003 orientieren. Beides gibt es nicht mehr. Unter der Haube gibt es nur noch die eine große administrative Gruppe "Exchange Administrative Group (FYDIBOHF23SPDLT)" und Routinggruppe "Exchange Routing Group (DWBGZMFD01QNBJR)", von der Sie aber nichts mehr sehen.

Exchange 2007/2010 orientieren sich an den Standorten des Active Directory. Alle Server in der gleichen Site sind eigentlich erst mal "gleichberechtigt" und Server in anderen Sites werden erst entsprechend der Kosten dem Client gemeldet, wenn in der lokalen Site kein Server ein Replikat des angefragten Ordners hat.

Früher gab es bei den Routinggroup-Connectoren eine Checkbox, um eine Verbindung für Public Folder Referrals zu blockieren. Das gibt es so bei Exchange 2007/2010 nicht mehr. Aber über eine Hintertür ist diese Funktion noch noch vorhanden. Immer dann, wenn die Kosten eines AD-Sitelinks größer als 500 sind, schließt Exchange diesen Link bei der Ermittlung der Server für ein Referral aus.

Aber das trifft natürlich nicht auf die Server in einer Site zu. Das kann besonders bei größeren Migrationen von Nachteil sein, wenn ein neuer Server seine öffentlichen Ordner noch "auffüllt" und die Clients dennoch schon an den Server gelenkt werden.

Zuerst gibt es aber auch wie in früheren Versionen pro Postfachdatenbank die Einstellungen, welche PF-Datenbank der Default Speicher ist:

An diese Datenbank sollte sich der Client zuerst wenden, um dann beim Zugriff auf Ordner, die dort nicht als Replikat liegen, auf einen anderen Server verwiesen zu werden. Auf der PF-Datenbank selbst aber gibt es ebenfalls eine interessant Einstellung.

Hier kann man die Verweise dieser Datenbank zu anderen Servern manuell konfigurieren und damit die automatische Ermittlung anhand der Kosten von AD-Sitelinks überschreiben. Das geht natürlich auch per Powershell

Set-PublicFolderDatabase `
    -Identity 'ExServer1\PubFolders1'
    -CustomReferralServerList 'Server1:1','Server2:10','Server3:25'
    -UseCustomReferralServerList $True

Durch diesen Trick sollte es möglich sein, einen neu installierten Server mit einer Public Folder Datenbank, der noch nicht komplett repliziert ist, vom Zugriff durch Clients auszuschließen.

Mit dem Parameter CustomReferralServerList werden die Kosten für den Verweis auf Öffentliche Ordner für einzelne Server manuell angegeben. Kosten können eine beliebige positive Zahl annehmen. Nicht in der Liste enthaltene Server werden nicht in Verweise einbezogen. Wenn dieser Parameter festgelegt wird und sich keine Server in der Liste befinden, dann erfolgen keine Verweise auf Öffentliche Ordner.
Quelle: Set-PublicFolderDatabase http://technet.microsoft.com/de-de/library/aa997225.aspx

Referrals mit Exchange 2000/2003

Komplett anders sieht es bei Exchange 2000/2003 aus. Da alle Exchange Server hier per Design im gleichen Forest sind und sich damit alle vertrauen, kann ein Benutzer problemlos auf alle Server eine Verbindung aufbauen. In einem gut installieren Active Directory funktioniert auch die Namensauflösung und Verbindung.

Dies ist ein Grund, warum Exchange nicht mehr auf manuell konfigurierte Affinitäten angewiesen ist, sondern einfach die Kosten der Connectoren als Parameter für die Errechnung der nächsten Server heranziehen kann. Diese Funktion ist per Default "eingeschaltet" und sogar transitiv, d.h. auch Verbindungen von Standort1 über Standort2 nach Standort3 werden berücksichtig.

Wenn dies nicht gewünscht ist, dann kann der Administrator auf dem Connector explizit die Nutzung eines Connectors zur Berechnung der Referrals abschalten. Dies ist z.B.: sinnvoll, wenn der Connector eine Wählverbindung nutzt oder der Standort nicht ausreichend transparent verbunden ist und die Clients den entfernten Exchange Server nicht erreichen können.

Eine Besonderheit gibt es ab Exchange 2003. Hier können Sie abweichend auf dem jeweiligen Server selbst bestimmen, ob er anhand der Routinggruppen oder einer fest vorgegebenen Liste die Clients an andere Server verweist:

 

Affinität mit Exchange 5.5

Um die Kosten für den Zugriff auf einen anderen Server zu ermitteln, muss Exchange 2000 und Exchange 5.5 einen Weg zur Kostenermittlung kennen. Hier unterscheiden sich beide System grundlegend.

Exchange 5.x ermittelt die Kosten der Replikate per Default nur anhand der Server im gleichen Standort. Damit Replikate in anderen Standorten ebenfalls erreichbar werden, muss der Exchange Administrator diese anderen Standorte als "Ordner-Affinität" mit Kosten konfigurieren:

Diese Affinität wird auch nicht vererbt. Wenn der Administrator von Standort1 die Ordner von Standort2 als erreichbar definiert hat und der Administrator den Zugriff von Standort2 auf Standort3 erlaubt, so kann trotzdem kein Zugriff von Standort1 auf Standort3 erfolgen.

Weiterhin heißt eine funktionierende Affinität noch nicht, dass der Anwender wirklich auf den Server zugreifen kann. Der Client verbindet sich per RPC mit dem entfernten Server. Dazu muss gewährleistet sein, dass:

Die Einstellung in Exchange 5.5. ist die das Funktionieren von Affinitäten daher nicht die ausreichend.

Referral und Affinity im gemischten Modus

Eine Besonderheit gilt es im gemischten Modus zu betrachten. Exchange 5.5 nutzt seine eigenen konfigurierten Affinitäten. Exchange 2000/2003 nutzt das Flag im Connector um anhand dessen Kosten die Referrals zu ermitteln.

Auf einem Exchange 5.5 Connector gibt es zwar Kosten, aber im Exchange 5.5 Administrator keine Option, um Referrals zu steuern. Exchange 2000/2003 nutzt die Informationen der  Exchange 5.5 Connectoren per Default nicht. Sollte dies gewünscht sein, so muss der Exchange 2000/2003 Administrator diese explizit aktivieren. Dies geht nur über das Kontextmenü des Exchange 5.5 Connectors im Exchange 2000/2003 Systemmanager. Dort muss der Haken bei "Verweise auf Öffentliche Ordner nicht zulassen" vom entsprechenden Exchange 5.5 Connector entfernt werden.

Im Exchange 2000/2003 System Manager sind die Exchange 5.5 Connectoren aber Read-only, so dass die Einstellungen dort nicht direkt verändert werden können. Alle Dialogfelder sind dort deaktiviert:

Damit bleibt nur das Kontextmenü, um auch Exchange 5.5 Connectoren für Verweise von öffentlichen Ordnern in Exchange 2000/2003 tauglich zu machen.

Wird dies nicht gemacht, dann könnte das folgendes Szenario auftreten.

Wird nun ein Postfach von Server EX55-1 auf E3K-1 verschoben, so kann dieser Benutzer nicht mehr auf den ORDNER2 zugreifen, da dieser nicht im gleichen Standort liegt, Exchange 2003 per Default die Affinität von Exchange 5.5 ignoriert, und auf dem Connector immer noch das Flag "Disallow Public Folder Referral" gesetzt ist.

Affinity/Referrals mit WinRoute

Auch wenn es nicht einfach ist, die Funktion der REAPI zu analysieren und z.B. vom Server die Antworten und Ergebnisse der Abfrage zu erhalten, so können Sie mit WINROUTE zumindest die Basis prüfen anhand derer REAPI die Liste der Server ermittelt. REAPI nutzt dazu:

Mit WINROUTE müssen Sie sich dann jeden Connector zu den entfernten Servern anschauen und kontrollieren, ob die Verweise auf Öffentliche Ordner auf diesem Connector aktiviert oder deaktiviert sind.

Anhand dieser Liste können Sie dann ermitteln, welche Entscheidung REAPI fällen wird. Mit MFCMAPI können Sie am Client individuell ermitteln, welcher Server ihnen gerade die Infos liefert.

Zugriff per IMAP4

Neben dem Zugriff per NNTP können Sie auch mit IMAP4 auf öffentlichen Ordner zugreifen. Diese Funktion muss im virtuellen IMAP4-Server allerdings erst aktiviert werden

Zugriff per NNTP

Auch per NNTP kann ein Zugriff auf öffentliche Ordner ermöglicht werden. Die öffentlichen Ordner sind dann analog zu Newsgroups zu sehen. Natürlich ist eine Anmeldung erforderlich, um von Exchange als Anwender erkannt und zugelassen zu werden. Allerdings ist der Zugriff nicht sonderlich bequem, da damit nahezu alle Funktionen von Exchange (Formulare etc.) nicht zur Verfügung stehen. In Exchange 2003 ist der Zugriff per NNTP daher per Default nicht aktiv, d.h. der virtuelle NNTP-Server ist gestoppt.

Mails an öffentliche Ordner

Öffentliche Ordner können auch eine Mailadresse erhalten. Hierbei unterscheiden sich Exchange 5.x und Exchange 2000/2003:

Exchange 5.5

Damit kann jeder an diesen Ordner eine Mail senden. Die Mail wird immer an den beim Ordner angegebenen "Homeserver" zugestellt der diese in den Ordner als "Mail" ablegt. Erst dann werden die Mails auf eventuelle Replikate verteilt. Insofern ist es wichtig, dass der Homeserver nahe am SMTP-Connector liegt, damit die Mails schnell und effektiv abgelegt und verteilt werden.

Exchange 2000/2003

Eingehende Mails werden zuerst an einen nahe liegenden Public Folder Store gesendet, der eine Replikation der MAPI-TLH hat. Dieser Informationsspeicher nimmt die Mail an und stellt sie in den lokalen Ordner zu, wenn dieser vorhanden ist. Ansonsten leitet er die Mail an einen anderen Server weiter, der ein Replikat des öffentlichen Ordners hat. Dabei nutzt Exchange 2000/2003 aber eine ganz bestimmte Reihenfolge, um diesen Server zu bestimmen:

Dies ist wichtig für das Verständnis und der Verhinderung von Schleifen. Sorgen Sie dafür, dass replikate von Mail aktivierten Ordnern auch hier nahe am ersten Server sind, der Mails annimmt und zudem sollten die Replikate auf einem Exchange 2000/2003 Server liegen. Auch ein lokaler Exchange 5.5 Server in der gleichen Administrative Gruppe wird nicht genutzt !!!

Bei einer Migration mit gemischtem Betrieb von Exchange 5.5 und Exchange 2000/2003 sind auch alle Ordner immer Mail enabled. Sie müssen über ein Public Folder Connection Agreement beim Active Directory Connector sicherstellen, dass die Mailadressen auch im Active Directory hinterlegt werden.

Tags:Öffentliche_Ordner Clientzugriff Referral