Exchange Hybrid und Teams mit multiplen SMTP-Domains

Wie man den On-Premise Exchange in den Hybrid-Modus versetzt und so eine Kalenderintegration mit Microsoft Teams schafft, habe ich bereits in diesem Artikel beschrieben: Exchange On-Premise und Teams Kalender. Bei Unternehmen, die nur eine SMTP-Domain verwenden, sollten mit diesem Artikel alle notwendigen Schritte abgedeckt sein. Doch wie sieht es mit Organisationen aus, die mehrere Accepted Domains verwenden? Wie funktioniert hier der Autodiscover-Request? Doch fangen wir von vorne an und besprechen kurz, wie der Autodiscover in einer hybriden Umgebung überhaupt funktioniert.

 

Exchange Hybrid und der Autodiscover

Funktionsweise

Dass alle lokalen AD-Benutzer mit der Cloud synchronisiert und die SMTP-Domains auch im O365 Portal eingetragen worden sind, gehört hierbei natürlich zur Grundvoraussetzung. Doch warum ist das so? Möchte Microsoft Teams auf den Kalender zugreifen, so führt Teams einen REST API Call auf die Exchange Online Umgebung aus. Exchange Online muss hierbei über die Information verfügen, ob es sich um ein O365 oder On-Premise Postfach handelt. Wird das angesprochene Postfach von einem On-Premise Exchange gehostet, so wird die Anfrage an eben diesen weitergeleitet. Das kann aber nur funktionieren, wenn zuvor das HCW Deployment korrekt ausgeführt wurde.

 

Loggt sich nun ein Nutzer in Microsoft Teams ein und ruft den Kalender auf, so wird ein Autodiscover-Request an folgende Adresse geschickt:

https://outlook.office365.com/autodiscover/autodiscover.json?Email=test01@schweigerstechblog.de&Protocol=EWS&RedirectCount=5

Da Exchange Online weiß, dass es sich um ein On-Premise Postfach handelt, wird die Anfrage an die Autodiscover-Domain des On-Premise Exchanges weitergeleitet:

https://autodiscover.schweigerstechblog.de/autodiscover/autodiscover.json?Email=test01%40schweigerstechblog.de&Protocol=EWS&RedirectCount=6

Die Autodiscover-URL bildet sich immer aus „autodiscover.SMTPDomain.tld„, also wie in diesem Fall „autodiscover.schweigerstechblog.de„.

 

Es ist daher notwendig, dass folgende Voraussetzungen erfüllt sind:

  • Exchange Online muss wissen, wo das Postfach gehostet wird.
  • Unter der Domain „autodiscover.SMTPDomain.tldmuss der Exchange antworten und ein gültiges SSL Zertifikat vorweisen können.

 

Problematik

Wir wissen nun, dass Office365 den Autodiscover-Request von Teams an die On-Premise Domain weiterleitet. Und genau hier kann auch ein Problem entstehen: Auch wenn Organisationen teilweise mehrere SMTP-Domains besitzen, so ist der Exchange meist nur unter der Hauptdomain „autodiscover.primaryDomain.tld“ erreichbar. Hat nun ein Postfach als PrimarySMTPAddress die „benutzername@secondDomain.tld“ konfiguriert, so würde Office365 die Autodiscover-Anfrage an die „autodiscover.secondDomain.tld“ senden. Da hierfür am Exchange weder ein Zertifikat, noch ein DNS-Record existiert, läuft die Anfrage dementsprechend ins Leere. Die Kalenderinformationen können also nicht abgerufen werden.

 

Lösung

Nun gibt es mehrere Ansätze, dieses Problem zu lösen.

  • Variante 1: Der alte und mittlerweile nicht mehr empfohlene Ansatz wäre es, alle Domains auf den Exchange verweisen zu lassen. Dadurch wird allerdings auch ein SAN Zertifikat benötigt, welches alle Domains abdeckt. Da das den Wartungsaufwand und auch die Kosten erhöht, empfiehlt es sich, Variante 2 abzubilden.
  • Variante 2: Office365 mittels SRV-Records die korrekte Autodiscover-Domain zeigen.
  • Variante 3: Seit Exchange 2013 (bzw. Exchange 2010 SP3 RU1) gibt es das „Autodiscover Domain“ Feature. Dieses Feature erlaubt es uns, eine Autodiscover-Domain unter mehreren SMTP-Domains auszuwählen. Alle Autodiscover-Anfragen werden seitens Office365 zentralisiert auf die von uns definierte Autodiscover-Domain geleitet.

 

Variante 2 – SRV-Records

Outlook kennt insgesamt 5 Methoden, wie er zu einer erfolgreichen Autodiscover-XML kommen kann. Eine genaue Auflistung aller könnt ihr bereits hier nach lesen. Office365 erlaubt für die Autodiscover-Weiterleitung in Microsoft Teams allerdings nur Methode 5: den SRV-Record.

Dieser besagt, dass für jede sekundäre Domain ein SRV-Record in der DNS-Zone gesetzt werden muss, welcher auf die Haupt-Domain verweist. Da die Integration eines SRV-Records bei jedem Anbieter etwas anders ausschaut, nehme ich als Referenz das DNS-Portal von Ionos (ehemals 1&1):

Nach dem Setzen muss folgender Eintrag mittels DNS abfragbar sein „_autodiscover._tcp.seconddomain.com“ und auf „autodiscover.schweigerstechblog.de“ verweisen. Beim Aufruf der „autodiscover.schweigerstechblog.de“ muss der Exchange mit einem validen Zertifikat antworten.

 

Variante 3 – Exchange Hybrid Autodiscover Domain

ACHTUNG: Diese Methode scheint laut Microsoft Support nicht mehr zu funktionieren. Ein offizielles Statement dazu gibt es allerdings nicht.

Glücklicherweise lässt sich das besagte Feature sehr einfach über den Hybrid Configuration Wizard konfigurieren. Unter dem Punkt „Hybrid Domains“ können alle Domains angehakt werden, welche in die Hybrid-Konfiguration aufgenommen werden sollen. Wichtig ist dabei, den Wert „True“ in der Spalte „Auto Discover (Optional)“ nur bei jener primären Domain zu setzen, unter der auch euer Exchange erreichbar ist.

Kontrollieren lässt sich die Konfiguration auch am Exchange mit folgendem Befehl:

[PS] C:\Windows\system32>Get-HybridConfiguration | fl Domains

Domains : {schweigerstechblog.de, autod:schweigerstechblog.de, secondDomain.tld, thridDomain.tld}

Die Autodiscover-Domain wird hierbei mit dem Prefix „autod“ angezeigt. Bis die Konfiguration seitens Office365 übernommen worden ist, kann es teilweise mehrere Tage dauern. Hier ist also etwas Geduld gefragt.

 

Weitere hilfreiche Artikel zu diesem Thema:

Das könnte Dich auch interessieren …

Abonnieren
Benachrichtige mich bei
guest
0 Comments
Inline Feedbacks
View all comments
0
Hinterlass' doch deine Meinung zu diesem Artikelx
()
x