Zum Abschluss des Hybrid Configuration Wizard (HCW) wurde mir folgende Warnungs-Meldung angezeigt:
HCW8064 - Der Assistent für Hybridkonfiguration wurde abgeschlossen, er konnte den OAuth-Anteil der Hybridkonfiguration aber nicht ausführen. Wenn Sie Features benötigen, die OAuth voraussetzen, können Sie versuchen den Assistenten für Hybridkonfiguration erneut auszuführen oder OAuth mithilfe dieser manuellen Schritte manuell konfigurieren.
Der Link “Weitere Informationen” verweist auf https://support.microsoft.com/en-us/help/3089172/hcw-has-completed-but-was-not-able-to-perform-the-oauth-portion-of-you. Wenn man schaut, wofür OAuth verwendet, wird dieser Artikel referenziert. Dort ist zu lesen, OAuth für Cross-Premises eDiscovery Suchen benötigt wird. Da diese erwähnten Funktionen in dem Projekt nicht relevant waren, habe ich das erstmal ignoriert. Eine erneute Ausführung des HCW hat übrigens auch kein OAuth einrichten können. Manchmal kann aber das erneute Ausführen des HCW solche Probleme tatsächlich beheben - einfach ausprobieren!
OAuth kann allerdings auch für die Authentifizierung für den Cross-Premise Austausch von Free/Busy Informationen genutzt werden. Der verlinkte OAuth-Artikel erwähnt allerdings ausschließlich eDiscovery - das ist auch die Sektion der Dokumentation in der sich der Artikel befindet. Weitere OAuth-Szenarien werden hier nicht erläutert. Im Artikel zur Konfiguration von OAuth für Exchange Hybrid wird Free/Busy auch nicht erwähnt.
Kein Free/Busy möglich
Nachdem die ersten Test-User zu Exchange Online migriert wurden, hat sich gezeigt, dass der Cross-Premise Abruf von Free/Busy Informationen nicht funktioniert. Zur Erläuterung von Hybrid Free/Busy gibt es hier zwei sehr gute Artikel im Exchange Team Blog:
- Demystifying Hybrid Free/Busy: what are the moving parts?
- Demystifying Hybrid Free/Busy: Finding errors and troubleshooting
Intra-Organization Connector (IOC)
Sowohl On-Premise als auch in Exchange Online kann geprüft werden, ob ein Intra-Organization Connector (für Hybrid OAuth notwendig) verwendet wird. Da die Konfiguration per HCW fehlgeschlagen ist, sollte keine funktionierende IOC Konfiguration hinterlegt sein.
| |
Das Attribut “Enabled” steht auf “False”, demnach wird kein OAuth verwendet. Also wie erwartet.
Organization Relationship (ORG REL)
Als nächstes sollte geprüft werden, ob ein Organization Relationship vorhanden ist.
| |
In meinem Fall, wurde ein Organization Relationship zurückgegeben. Es wird also DAUTH verwendet.
DAUTH Überprüfung
Ich habe hier tatsächlich nur an der Oberfläche gekratzt. Nach einigem Troubleshooting hat sich gezeigt, dass die Authentifizierung per DAUTH in diesem Fall tatsächlich nicht funktioniert. Ich habe zum Überprüfen in Outlook on the Web (OWA) versucht eine Cross-Premise Verfügbarkeit abzurufen. In der Browser-Entwicklerkonsole (per “F12” aufrufbar) kann dann unter “Network” nach “GetUserAvailabilityInternal” gefiltert werden.
Die relevanten Informationen die ich dort finden konnte:
Error 0x80048800
wst:FailedAuthentication
AADSTS901124: Application ‘fydibohf25spdlt.example.com’ does not exist.
Die Details zum Free/Busy Troubleshooting sind auch im Exchange Team Blog: Demystifying Hybrid Free/Busy: Finding errors and troubleshooting zu finden. Da die nicht existente Application und der Code “AADSTS901124” anscheinend kein Standard-Szenario ist, wollte ich eigentlich schon ein Ticket bei Microsoft eröffnen. Da aber OAuth ohnehin die moderne und empfohlene Authentifizierungsmethode ist, kann man aber auch ersteinmal dafür Troubleshooting betreiben.
OAuth manuell einrichten
Grundsätzlich wird die manuelle Einrichtung von OAuth im Artikel Configure OAuth authentication between Exchange and Exchange Online organizations beschrieben. Ich wiederhole das jetzt nicht hier alles. Was bei mir allerdings noch anders war:
Exchange Server Auth Certificate abgelaufen und erneuert
Im Abschnitt “Step 3: Export the on-premises authorization certificate” wird beschrieben, wie das Microsoft Exchange Server Auth Certificate exportiert werden kann. Im nächsten Schritt würde es dann in Exchange Online importiert werden. Da das Exchange 2013 System beim Kunden bereits seit über 5 Jahren im Betrieb ist, wurde das Zertifikat bereits einmal ausgetauscht. Da Hybrid und OAuth hier noch nie verwendet wurden, wurde das neue Zertifikat auch nie für die Authentifizierung hinterlegt.
Auf msxfaq.de gibt es einen guten Artikel zu Exchange OAuth. Dort wird unter anderem beschrieben, wie per powershell Set-AuthConfig das neue Zertifikat hinterlegt werden kann:
| |
Anschließend ist noch ein iisreset notwendig.
Intra-Organization Connector konfigurieren
Anschließend konnte ich der Dokumentation entsprechend weiter verfahren (Step 3, 4 und 5). Step 6 und 7 waren nicht mehr zutreffend. Die IOC mussten nicht mehr angelegt werden, sondern mussten nur noch per Get-IntraOrganizationConnector | Set-IntraOrganizationConnector -Enabled $true aktiviert werden. Step 8 spielte keine Rolle, da keine pre-Exchange 2013 SP1 Server in der Umgebung vorhanden waren.
Tests
Anschließend konnte ich folgende Tests erfolgreich durchführen:
OAuth Test per PowerShell
In On-Premise Exchange Management Shell ausführen:
| |
In Exchange Online PowerShell ausführen:
| |
Abruf von Free/Busy Zeiten (Cross-Premise)
Tatsächlich konnten jetzt Cross-Premise die Free/Busy Zeiten abgerufen werden - in beide Richtungen. Hier ein exemplarischer Screenshot, der die Abfrage von einem Exchange Online Postfach zu einem Exchange On-Premise Postfach zeigt.
Weiterführende Links
- Demystifying Hybrid Free/Busy: what are the moving parts? (Exchange Team Blog)
- Demystifying Hybrid Free/Busy: Finding errors and troubleshooting (Exchange Team Blog)
- Configure OAuth authentication between Exchange and Exchange Online organizations (docs.microsoft.com)
- Exchange OAuth Artikel (msxfaq.de)