Outlook und GC

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

Understanding and Troubleshooting Directory Access
http://www.Microsoft.com/downloads/details.aspx?FamilyID=c976433f-f979-4745-b7a6-9d8446ef6409&DisplayLang=en
How to analyse Client Traffic
http://www.Microsoft.com/exchange/techinfo/administration/2000/ClientNT.asp
256976 How MAPI clients access Active Directory
272290 OL2000: Outlook Performs Load Balancing with Global Catalog Servers
317209 XADM: How to Identify Your Global Catalog Server Using Outlook
319206 OL2002: How to Specify the Closest or Specific GC Server
823719 Exchange 2000 MAPI address book provider cannot connect to a different global catalog server if the current global catalog server is unavailable
314980 How to configure Active Directory diagnostic event logging in Windows Server 2003 and in Windows 2000 Server
949469 NSPI connections from Microsoft Outlook to a Windows Server 2008-based domain controller may fail with an error code: "MAPI_E_LOGON_FAILED"

Keywords:

Outlook AD GC GAL