Outlook und GC (Globaler Katalog)

Exchange 5.5 hat seinen eigenen Verzeichnisdienst (DIR.EDB) den alle bisherigen Versionen von Outlook und der früher Exchange Client befragt hatten. Die MAPI-Client nutzten dazu einfach RPC. Zwar bot Exchange seine Adressbuchdienste auch per LDAP an, aber diese Option wurde nur selten genutzt. Erst durch den Einsatz fremder Clients (Unix etc.) und natürlich dem Active Directory Connector wurde der LDAP-Zugriff wichtiger.

Exchange 2000/2003 hingegen hat keinen eigenen Verzeichnisdienst mehr und nutzt das Active Directory. Damit stellt sich die Frage, wie die verschiedenen Versionen von Outlook damit zurecht kommen. Bei der ersten Verbindung kann Outlook ja noch nicht wissen, ob der im Profil angegebene Exchange Server schon 2000 oder neuer ist oder Exchange 5.5 und älter genutzt werden. Was passiert hierbei ?

Outlook startet, löst den Servernamen auf und verbindet sich auf den Portmapper (Port 135/TCP) um vom Server den eigentlichen Port zu erfahren, auf dem der Exchange Verzeichnisdienst lauscht. Das ist bei allen Versionen gleich. Nur wenn Outlook 2003 über RPC oder HTTP kommuniziert kommt ein anderes Verfahren zum Tragen.

Exchange und Adressbuchdienste

Aber am Exchange Server scheiden sich dann die verschiedenen Versionen. Exchange 5.5 bedient alle Clients aus seiner lokalen DIR.EDB-Datenbank bzw. verweist Outlook an den Postfachserver des Benutzers. Der Exchange 2000/2003 Server erkennt an Hand der mit übermittelten Versionsnummer die Leistung des Clients und verhält sich dann sehr unterschiedlich. Exchange 2000/2003 kennt dazu drei Varianten:

Der Dreh und Angelpunkt ist das Name Service Provider Interface (NSPI), welches früher vom Exchange DS bereit gestellt wurde und seit Exchange 2000/2003 durch die Domaincontroller bereit gestellt werden.

  • DSProxy
    Anfragen von Outlook werden vom Exchange Server stellvertretend an den GC gestellt. Die Antwort vom GC landet wieder bei Exchange, welcher die Antwort an den Client weiter gibt.
  • NSPI Referral
    Exchange erkennt, dass Outlook selbst die GC fragen kann und sendet an Outlook einen Verweis mit den GCs. Leider kann der Exchange nicht wissen, wo der Client steht und sendet die aus Sicht des Exchange Servers nächsten GC an den Client. Ein eventuell näher am Client stehenden GC (z.B.: bei einer zentralisierten Exchange Installation) bleibt ungenutzt.
  • GC Direkt
    Outlook 2000 und höher greifen nach der ersten Verbindung direkt auf die NSPI-Schnittstelle auf dem Domain Controller zu.

Verhalten im Fehlerfall

Outlook Version Erste Verbindung Normale Verbindung GC Aktualisierung Dynamisches Failover

97

NSPI

RFR

Exchange wird immer gefragt (DSPROXY)

Exchange übernimmt den Failover

2000/98

NSPI

RFR

JA, bei Nichterreichen des GC beim Start mit Fehlermeldung

Nein, Outlook Neustart erforderlich

2000 SP2

NSPI

RFR

JA, bei jedem Start wird der GC neu ermittelt

Nein, Outlook Neustart erforderlich

2002
2003
2007
2010
2013

NSPI

RFR

JA, beim Start
JA, bei Nichterreichen des GC
JA, bei Reconnect

Ja, innerhalb 30 Sekunden ohne Neustart

Die einzelnen Outlook Versionen verhalten sich unterschiedlich:

  • Outlook 97
    Da zu der Zeit die Entwickler von Outlook 97 noch nicht wussten, wie Exchange 2000/2003 funktioniert, fragt Outlook immer den Exchange Server, als wenn es ein Exchange 5.5 Server wäre. Exchange 2000 seinerseits fungiert als Proxy, d.h. der Exchange Server stellt die Anfrage an einen verfügbaren GC und gibt die Antwort an Outlook zurück, so wie auch ein Exchange 5.5 Server geantwortet hätte. (Stichwort "NSPI Proxy")
  • Outlook 98/2000... ...fragt beim Zugriff auf das Adressbuch den Exchange Server, aber Exchange sendet Outlook ein so genanntes "Referral" (Verweis) auf den aktuellen "Global Catalog". Ab diesem Zeitpunkt fragt nun Outlook 2000 diesen Global Catalog direkt und genau hier entsteht unser Problem. Leider "merkt" sicht Outlook bis zum SP1 den GC "für immer im Profil". Wird der G deinstalliert,
  • Outlook 2000 SP2
    Dieser Fix ändert das Verhalten von Outlook derart, dass es beim Start nicht mehr in der Registry den GC ausliest, sondern immer den Exchange Server anfragt. Zusätzlich kann der Administrator einen bestimmten GC in der Registry vorgeben, was ich aber nicht für sinnvoll halte. Sollte kein GC erreichbar sein, dann bekommt der Anwender mittlerweile eine verständliche Fehlermeldung.
  • Outlook 2002
    Das prinzipielle Verhalten ist wie bei Outlook 2000 SP2. Zusätzlich kann der Administrator aber eine Option "Closest GC" angeben (siehe KB319206), so dass Outlook angewiesen wird, anhand der Active Directory Standorte einen günstigen GC zu finden.
  • Outlook 2003
    Verhalten wie bei Outlook 2002 mit Ausnahme bei der Nutzung von RPC over HTTP

Hier sehen Sie den Eintrag des zuletzt genutzten GC in einem MAPI-Profil.


Registrykey mit dem GC-Eintrag

Seit Outlook 2000 SP2 und höher kann der Administrator einen bestimmten GC auf dem Client vorschreiben.

Auch auf dem Exchange Server kann der Admninistrator auf die automatische Erkennung von Exchange verzichten und explizit Server für die Funktion NSPI und RFR in der Registrierung vorgeben. In bestimmten Umgebungen (z.B. Firewalls) können oder sollen die neuen Clients die GCs nicht erreichen. Dann kann über eine "1" in "NoRFRService" die RFR Funktion deaktiviert werden. Auch neue Clients fragen dann immer den Exchange Server, der als Proxy die Daten bereitstellt. Die Werte finden sich unter:

HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet\Services\MSExchangeSA\Parameters\
NSPITargetServer:Reg_SZ
RFRTargetServer: Reg_SZ
NoRFRService: DWORD

Weitere Links