Outlook Offline Adressbuch (OAB) - Hinter den Kulissen

Wer Outlook im Cached Mode oder gar Offline betreibt, hat auf dem lokalen PC nicht nur eine OST-Datei mit einer Kopie des Postfachs und optional den öffentlichen Ordnern Favoriten, sondern auch eine Kopie des Adressbuchs der Firma. Outlook lädt dazu beim ersten Start eine vollständige Kopie eines vom Server bereit gestellten Adressbuchs herunter und in der Folge immer nur noch die Änderungen . Nur wenn Outlook länger als 30 Tage "offline" war oder die Anzahl der Änderungen mehr als 10% ausmachen, startet Outlook wieder einen kompletten Download.

Generierung

Damit der Client überhaupt ein OAB herunter laden kann, muss der Server diese Information natürlich erst einmal bereit stellen. Das Verfahren ist seit Exchange 5.5 (?) nahezu unverändert. Ein Hintergrundprozess erstellt per Default gegen 05:00 uhr Ortszeit ein Update und legt dieses zum Download bereit. Dazu kommen je nach Exchange Version unterschiedliche Orte zum Einsatz:

Ort Outlook Version Exchange 5.5 2000/2003 2007/2010

MAPI:Public Folder V1

nur alte Dos/Windows Clients mit Exchange 4.0/5.0

nein

nein

nein

MAPI:Public Folder V2

Alle "non unicode-Clients" Outlook 2007/2010

Ja

Ja

Optional

MAPI:Public Folder V3

Alle "Unicode-Clients" Outlook 2003

Ja

Ja

Optional

MAPI:Public Folder V4

Outlook 2003 ab SP2
Outlook 2007
Outlook 2010

Nein

Ja

Optional

http://server/OAB

Outlook 2007/2010

Nein

Nein

Default

Die weiteren Details sind auf den Seiten E2K7:OABGen und Exchange Offline Adressbuch anlegen beschrieben.

In Office 365 können Sie den Zeitpunkt der Generierung meines Wissens nach nicht bestimmen.
Offline address books in Exchange Online (https://technet.microsoft.com/en-us/library/mt763296(v=exchg.150).aspx)

Download per Public Folder (Alle Outlook Versionen)

Outlook 97 bis Outlook 2010 unterstützen weiterhin den Download von Offline Adresslisten per MAPI aus den öffentlichen Ordnern. Dieser Weg ist in der Regel problemlos und kann nur daran scheitern, dass der Server kein Adressbuch bereit stellt oder der Client kein Replikat des Ordners erreichen kann. Hierzu gibt es aber aber ausreichend Quellen im Internet und aufgrund der schnellen Abnahme von Exchange 2003 und älter und Outlook 2003 zugunsten von Exchange 2007 und neuer und Outlook 2008 beschäftigt sich diese Seite nur mit dem Download per HTTP

OAB Download mit Outlook 2007/2010

Outlook2007/2010 und Exchange 2007/2010 laden das Offline Adressbuch vom Server nicht mehr MAPI sondern über HTTP des IIS und BITS. Outlook 2007 stellt also auf dem Client in den BITS-Dienst den Auftrag ein, er möge doch bitte das Offline Adressbuch herunter laden. Und wenn dies nicht funktioniert, dann findet der Anwender eben einen ziemlich nichtssagende Fehlermeldung in seinem Ordner "Synchronisierungsprobleme":

Wenn Sie aber nun wissen, dass der Download nicht von Outlook selbst sondern über BITS erfolgt, dann sollten Sie in einer DOS-Box einfach mal BITSADMIN verwenden. (oder zukünftig die passenden PowerShell Befehle). Hier sehen Sie genau den Job und auch die Fehlermeldung dazu.

Selbst wenn der Download, wie bei uns, per HTTP erfolgt. Hier das ganze noch mal als Text, damit auch Google und andere Suchmaschinen diese Seite finden können.

C:\>bitsadmin /list /verbose

BITSADMIN version 3.0 [ 7.5.7600 ]
BITS administration utility.
(C) Copyright 2000-2006 Microsoft Corp.

BITSAdmin is deprecated and is not guaranteed to be available in future versions of Windows.
Administrative tools für the BITS service are now provided by BITS PowerShell cmdlets.

GUID: {14F18F96-E68B-4BF5-B680-67533D8EA94B} DISPLAY: 'Microsoft Outlook Offline Address Book'
TYPE: DOWNLOAD STATE: TRANSIENT_ERROR OWNER: MSXFAQ\fcarius
PRIORITY: NORMAL FILES: 0 / 1 BYTES: 0 / 25073
CREATION TIME: 09.04.2010 16:19:17 MODIFICATION TIME: 09.04.2010 16:19:45
COMPLETION TIME: uNKNOWN ACL FLAGS:
NOTIFY INTERFACE: uNREGISTERED NOTIFICATION FLAGS: 3
RETRY DELAY: 600 NO PROGRESS TIMEOUT: 1209600 ERROR COUNT: 5
PROXY USAGE: PRECONFIG PROXY LIST: NULL PROXY BYPASS LIST: NULL
ERROR FILE:    https://owa.netatwork.de/OAB/d7348a69-9919-4f90-9d85-c15536c228ee/oab.xml -> C:\\AppData\Local\Microsoft
\Outlook\oab17.xml
ERROR CODE:    0x801901f4 - HTTP-Status 500: Der Server kann die Anforderung aufgrund eines unbekannten Fehlers nicht erfüllen.
ERROR CONTEXT: 0x00000005 - Fehler beim Verarbeiten der Remotedatei.
DESCRIPTION: Microsoft Outlook Offline Address Book Directory
JOB FILES:
        0 / 25073 WORKING https://owa.netatwork.de/OAB/d7348a69-9919-4f90-9d85-c15536c228ee/oab.xml -> C:\\AppData\Loca
l\Microsoft\Outlook\oab17.xml
NOTIFICATION COMMAND LINE: none
owner MIC integrity level: MEDIUM
owner elevated ?           false

Peercaching flags
         Enable download from peers      :false
         Enable serving to peers         :false

CUSTOM HEADERS: NULL

Listed 1 job(s).

C:\>

Hier ist also zu sehen, dass der Server mit einem 500er Fehler antwortet.

Troubleshooting

Am einfachsten ist es nun erst mal, die angefragte URL in einem Browser einzugeben und zu sehen, ob sie dann die Datei bekommen, nachdem ich mich natürlich erst mal authentifiziert hatte

In meinem Fall war das aber kein Problem. Also kann es nur an einer besonderen Art des "Request" liegen, mit der BITS hier die Anfrage stellt. Im Hintergrund macht der IIS seine Arbeit. Also hier ein Blick ins Log geworfen. (gekürzt).

POST /Autodiscover/Autodiscover.xml - 443 - 192.168.100.20 Microsoft+Office/12.0 401 0 0 0
POST /Autodiscover/Autodiscover.xml - 443 MSXFAQ\fcarius 192.168.100.20 Microsoft+Office/12.0 200 0 0 31
HEAD /OAB/d7348a69-9919-4f90-9d85-c15536c228ee/oab.xml - 443 - 192.168.100.12 Microsoft+BITS/7.5 401 2 5 124
HEAD /OAB/d7348a69-9919-4f90-9d85-c15536c228ee/oab.xml - 443 - 192.168.100.12 Microsoft+BITS/7.5 401 2 5 171

Ok, hier kommen also erst Autodiscover und dann zwei anonyme Anfragen an, aber keine 500er Rückmeldung, die mein Client vermeldet.

Also galt meine Aufmerksamkeit dann dem ISA-Server, welche in meinem Fall die Anfragen einsammelt. Um das besser "debuggen" zu können habe ich eine eigene Web Veröffentlichungsregel erstellt, die OAB bereit gestellt hat.

 

Dann war die Anzeige im ISA-Status einfacher zu filtern.

Hier sieht man, dass die Anfragen anscheinend fehl schlagen. Etwas stöbern im Netz hat mehrere mögliche Gründe angegeben:

Nach dem das alles nichts gefruchtet hat und also Zugriffe, SSL-Zertifikate, Authentifizierung etc. alles ausgeschlossen war, war guter Rat teuer. Aber

Bösewicht Link Translation

Letztlich habe ich aber durch die Recherche doch noch eine Option gehabt, "OAB not downloading für external clients (http://forums.isaserver.org/m_2002068861/mpage_1/key_/tm.htm#2002069031)" führte mich dann auf die Spur, dass ein besonderes Feature des ISA-Servers hier mit einen Streich spielen könnte. Allerdings würde das nicht dazu passen, da auch der interne Download ohne ISA-Server bislang ebenfalls nicht funktioniert hat. Aber in dem Zusammenhang bin ich dann auf eine Fall in Verbindung mit RPC over HTTP gestoßen. Ich hatte hier nämlich eingestellt, dass ich für schnelle und langsame Verbindungen RPC/HTTP aktiviert hatte. 

In Verbindung mit Autodiscover kamen dabei gar nicht meine "Exchange RPC"-Einstellungen für interne Zugriffe zu tragen, sondern immer die "Exchange HTTP"-Einstellungen. Damit ist mein Client von Intern auch über die externe URL auf den Exchange Server gegangen. Nachdem ich die "Link Translation" auf der OAB-Regel deaktiviert habe, konnte mein Outlook dann auch endlich per BITS wieder sein Offline Adressbuch herunter laden.

Wobei auch hier die vergangenen Probleme und Versuche erst mal dazu geführt haben, dass in der BITS-Warteschlange noch einige Reste standen und erst ein Neustart von Outlook und ein manueller Download eines kompletten Adressbuchs den Knoten gelöst hat. Wobei das auch meiner ungeduld geschuldet war. Vielleicht hätte sich Outlook auch noch selbst gefangen.

Passende Lösung

Das ganze führt aber natürlich zu einer ganz neuen Betrachtung des Outlook Cached Mode, RPC over HTTP, E2K7:OABGen und Autodiscover. Vielleicht ist es doch passender, wenn man "schnelle Verbindungen" erst per TCP nutzt und damit "RPC Native" gegen Exchange CAS-Server einsetzt um damit auch die "InternalURL"-Einstellungen für die sonstigen Dienste zu nutzen und Outlook erst dann auf RPC over HTTP umschaltet, wenn der Server per TCP direkt nicht zu erreichen ist. Nebenbei ist das sicher auch eine interessante Basiskonfiguration für Direct Access, also das IPSec-VPN über IPV6, welches mit Windows 7 und Windows 2008 R2 verfügbar wird.

Alternativ könnte ein Split-DNS derart helfen, dass auch Zugriff auf die über "ExternalURL" spezifizierten Adressen aus dem internen LAN doch auf den internen Servern landen. Allerdings müssen diese dann natürlich auch in den Zertifikaten die externen Namen haben. Wenn zudem der externe Zugriff per ISA Authentifizierung vielleicht mit Tokens gesichert ist, dann kann es wieder stören, dass intern keine Anmeldemaske kommt ,sondern die integrierte Anmeldung den direkten Zugriff erlaubt.

Weitere Links