Autodiscover 365

Wie müssen Sie Exchange Autodiscover konfigurieren, wenn Sie Hybrid nutzen aber quasi alle Empfänger mittlerweile in der Cloud sind?. Den lokalen Exchange Server dürfen Sie ja dennoch nicht deinstallieren.

Server Autodiscover EX->EXO

Ehe ich auf die Autodiscover-Auflösung eines Outlook Clients beim Hybrid Mode eingehen will, möchte ich erst einmal die Autodiscover-Funktion von Exchange Online zu Exchange On-Premises beschreiben. Auch die Exchange Server müssen miteinander kommunizieren um z.B. Frei/Belegt-Zeiten zu erhalten oder auch anderen Cloud-Diensten auf Exchange On-Premises Zugriffe zu erlauben.

Im Hybrid-Mode "gehört" ihre SMTP-Domäne natürlich dem lokalen Server und entsprechend muss Autodiscover lokal eingestellt werden.

In die Gegenrichtung hat Microsoft es sich einfach gemacht. Autodiscover von einem lokalen Exchange Server zu Exchange Online findet quasi nur für die SMTP-Domäne "%tenantname%.mail.onmicrosoft.com" statt, welche als Weiterleitungsadresse bei den lokalen Anwendern eingetragen ist.

Zudem kann Microsoft ein Exchange natürlich auchc eintragen, dass outlook.office365.com eine vertrauenswürdige URL für alle Clients und Server ist. Selbst wenn also "autodiscover.<ihredomain>" auf Office 365 verweist, gibt es keine Zertifikatswarnung.

Server Autodiscover EXO->EX

Umgekehrt ist es aber erst einmal aufwändig, wenn Sie viele Domains betreiben und nicht für jede Domäne einen Namen im SAN-Zertifikat haben. Aber hier hat Microsoft mittlerweile auch mitgedacht, dass Sie für ihren Tenant mehrere SMTP-Domänen unter einer primären Domäne zusammenfassen können.

With older hybrid servers—that is, hybrid servers running Exchange 2010—you need to create an Autodiscover record in DNS for all SMTP domains. Also, the SAN certificate has to include all used autodiscover DNS records in the SAN list.
Exchange Q & A: Handling hybrid environments
https://docs.microsoft.com/en-us/previous-versions/technet-magazine/dn249970(v=msdn.10)

Aber seit Exchange 2013 ist dies nicht mehr der Fall:

When it comes to the Autodiscover domain feature, this happened with the release of Exchange 2010 SP3 RU1. Yes, when applying RU1, you can use the Autodiscover domain feature in an Exchange 2010-based hybrid configuration. To set the Autodiscover domain, use the following command:
Exchange Q & A: Handling hybrid environments
https://docs.microsoft.com/en-us/previous-versions/technet-magazine/dn249970(v=msdn.10)

Damit dies funktioniert, sind folgende Schritte erforderlich:

  • HCW für die primäre SMTP-Domäne starten
    Damit sollte Hybrid eingerichtet und für diese Domäne funktionstüchtig sein
  • Konfiguration der Zusatzdomains
    Nutzen sie dazu die Exchange On-Premises PowerShell auf dem Hybridserver und passen Sie folgenden Befehl an ihre Domänen an um die Einstellungen lokal zu hinterlegen
Set-HybridConfiguration `
   -domains msxfaq.de, msxfaq.com, uclabor.de, autod:primarydomain.tld
  • HCW erneut starten
    Um die lokalen Einstellungen nun in die Cloud zu übertragen, nutzen Sie einfach noch einmal den HCW
  • Kontrolle mit get-hybridconfiguration
    Kontrollieren sie noch einmal, ob die Einstellungen noch vorhanden sind. Die zusätzlichen Domänen sollten nun auch im Autodiscover-Eintrag erscheinen

Die Änderungen können dennoch mehrere Stunden (bis zu 24h) benötigen, bis alle Exchange Online Server das Update auch anwenden. Die Einstellungen werden vom HCW dann aber in der Cloud hinterlegt und sind wie folgt auslesbar

Get-OrganizationRelationship | fl *target*

TargetApplicationUri : FYDIBOHF25SPDLT.uclabor.de
TargetSharingEpr :
TargetOwaURL :
TargetAutodiscoverEpr : https://autodiscover.uclabor.de/autodiscover/autodiscover.svc/WSSecurity

Die können die Einstellungen in der Cloud natürlich auch manuell vornehmen, z.B. mit:

Set-OrganizationRelationship `
   -Identity "EXO to OnPrem `
   -TargetSharingEpr https://hybrid.uclabor.de/EWS/Exchange.asmx/WSSecurity `
   -TargetOwaURL https://owa.uclabor.de/owa `
   -TargetAutodiscoverEpr $null

Damit teilen Sie der Exchange Online Instanz nach, dass die Anfragen nicht über "autodiscover"-Anfragen aufgelöst werden sollen, sondern den explizit angegebenen Server ansprechen.

Client Autodiscover und Hybrid

Autodiscover ist für die Funktion von Exchange Clients unerlässlich. Über Autodiscover finden Clients wie Outlook aber auch Skype for Business, EWS-Tools aber auch Exchange selbst den richtigen Exchange Server. Auf der Seite Exchange - Autodiscover habe ich die umfangreichen Wege von Autodiscover beschrieben und bislang sind folgende Aussagen wichtig:

Before we move on, be clear that we are discussing Exchange hybrid and in this deployment model Autodiscover must point to the On-Premises Exchange infrastructure.
Quelle: Office 365 Exchange Hybrid Deployments Busting The Autodiscover Myth - https://blogs.technet.microsoft.com/rmilne/2016/07/14/office-365-exchange-hybrid-deployments-busting-the-autodiscover-myth/

Auch in einem zweiten Post ist die Aussage eindeutig.

Note that in a hybrid configuration the external Autodiscover namespace must point back to the On-Premises Exchange infrastructure and not to Office 365.  This is a common configuration issue as the Office 365 portal complains about missing DNS records
Office 365 Autodiscover Lookup Process  https://blogs.technet.microsoft.com/rmilne/2015/04/29/office-365-autodiscover-lookup-process/

Wenn Sie aber nun mehr und mehr Postfächer nach Office 365 verschieben und am Ende nur noch eine Rumpfinstallation von Exchange On-Premises verbleibt, dann kommt sicher der Wunsch auf, diese Abhängigkeit zu beseitigen. Warum sollten Clients weiterhin zuerst auf den lokalen Exchange Server zugreifen, der dann über die TargetAddress den Client zu Office 365 umlenkt. Wäre es dann nicht langsam an der Zeit den Autodiscover-Eintrag direkt auf die Cloud zeigen zu lassen? Das ist sogar möglich, wie Microsoft selbst dokumentiert:

Assuming that you have already moved all of the mailboxes to Exchange Online, you can point the MX and Autodiscover DNS records to Exchange Online, instead of to On-Premises.
Quelle: How and when to decommission your On-Premises Exchange servers in a hybrid deployment https://docs.microsoft.com/en-us/exchange/decommission-On-Premises-exchange#why-you-may-not-want-to-decommission-exchange-servers-from-On-Premises

Dieser Artikel unterscheidet aber zwei Szenarien:

  1. Szenario 1: Abschalten von DirSync
    Hier kann Exchange lokal komplett entfernt werden, da ohne DirSync eine Verwaltung in der Cloud möglich ist
  2. Szenario 2: DirSync bleibt aktiv
    Hier muss zumindest ein Exchange Server als "Provisioning"-Server verbleiben.

Aber auch beim Szenario 2 ist es erlaubt die Autodiscover-Einträge zu Office 365 zu lenken, wenn lokal keine Postfächer mehr vorhanden sind.

Sie müssen aber sicher sein, dass es keine Empfänger mehr On-Premises gibt, da Office 365 anscheinend die Zugriffe der Anwender nicht auf den lokalen Exchange Server umleitet. Kann er ja auch nicht, da es keinen eigenen DNS-Namensraum dafür gibt. Exchange Online routet die Mails ja über die normale SMTP-Domäne zurück und nicht über eine "onprem.firma.tld"-Domäne, wie es in die Gegenrichtung eine %tenantname%.mail.onmicrosoft.com gibt.

Microsoft warnt auch explizit davor

If you were to even start the process by pointing the Autodiscover Records to Exchange Online, you would immediately break some features like hybrid public folder access.
Quelle: How and when to decommission your On-Premises Exchange servers in a hybrid deployment https://docs.microsoft.com/en-us/exchange/decommission-On-Premises-exchange#why-you-may-not-want-to-decommission-exchange-servers-from-On-Premises

Outlook 2016 C2R und Autodiscover

Auf der anderen hat Microsoft mit Outlook 2016 Click to Run schon ein etwas anderes Verhalten an den Tag gelegt. Outlook 2016C2R und neuer verlassen sich nicht mehr auf eine funktionierende Auflösung von Autodiscover nach dem klassischen Weg, sondern probieren immer auch Office 365 als möglichen Exchange Service. Das Verhalten hat Microsoft auch publiziert:

Outlook uses a set of heuristics to determine whether the provided user account comes from Office 365. If Outlook determines confidently that you are an O365 user, an attempt is made to retrieve the Autodiscover payload from the known O365 endpoints (typically https://autodiscover-s.outlook.com/autodiscover/autodiscover.xml or https://autodiscover-s.partner.outlook.cn/autodiscover/autodiscover.xml).
Quelle: Outlook 2016 implementation of Autodiscover https://support.microsoft.com/en-ca/help/3211279/outlook-2016-implementation-of-autodiscover

Das Verhalten kann über die Konfiguration des Werts "ExcludeExplicitO365Endpoint" wieder verändert werden.

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\16.0\Outlook\AutoDiscover]
"ExcludeExplicitO365Endpoint"=dword:00000001

Outlook ist also nicht mehr 100% davon abhängig, dass Autodiscover tatsächlich On-Premises noch funktioniert.

Interessanterweise erfolgt die Abfrage in der Cloud noch vor dem lokalen SCP-Lookup und allen anderen Anfragen

Die Reihenfolge ist:

  1. Lokaler Cache
    Nicht übersteuerbar
  2. Lokale XML-Datei per GPO
    Durch Parameter "PreferLocalXML" steuerbar
  3. Lokale "Lasts Know Good"-Konfiguration im Cache
    Durch Parameter "ExcludeLastKnownGoodURL" übersteuerbar
  4. Office 365 Autodiscover
    Durch Parameter "ExcludeExplicitO365Endpoint" übersteuerbar
  5. SCP-Lookup.
    Erst hier kommt dann die LDAP-Abfrage. Sie ist durch den Parameter "ExcludeScpLookup" übersteuerbar
  6. Root-Domäne <maildomain>
    Durch Parameter "ExcludeHttpsRootDomain" übersteuerbar
  7. Autodisover-Url   autodiscover.<maildomain>
    Durch Parameter "ExcludeHttpsAutoDiscoverDomain" übersteuerbar
  8. Lokale Daten
  9. Redirect URL
    Durch Parameter "ExcludeHttpRedirect" übersteuerbar
  10. SRV-record "_autodiscover._tcp.
    Kurz vor Schluss wird noch ein SRV-Record im DNS abgefragt.
  11. Office 365 Failsafe
    Durch Parameter "ExcludeExplicitO365Endpoint" übersteuerbar

Dieser Ablauf unterscheidet sich deutlich von dem bisherigen Ablauf auf Autodiscover - Grundlagen

Umleitung mit Notes

Nun gibt es ja durchaus einige andere Umgebungen, in denen der lokale Exchange Server noch nie Postfächer gehabt hat und auch nie bekommen wird. Ich denke da an die Projekte, bei denen Postfächer z.B. ,von einem lokalen Lotus Notes Server direkt nach Office 365 migriert werden. Es passiert natürlich, dass Postfächer hier sowohl in der Cloud in Exchange Online als auch On-Premises in Notes liegen. Wenn Sie dann eine 3rd Party Software wie den "Quest Coexistence Manager" oder "CMT for Binary Tree" nutzen, dann wäre es schon interessant, die Postfächer im alten System aus Exchange Online hinsichtlich "Free/Busy" auflösbar zu machen.

Ich habe daher einfach mal einen Tenant aufgesetzt, bei dem "Autodiscover" in die Cloud geht und es dort einen Mail-Kontakt gibt, der auf einen anderen SMTP-Namensraus verweist.

Der Autodiscover-Eintrag geht hier auf Office 365

C:\>nslookup autodiscover.uclabor.de
Server:  fritz.box
Address:  192.168.178.1

Nicht autorisierende Antwort:
Name:    autod.ms-acdc.office.com
Addresses:  2603:1026:203::8
          2603:1026:208:1::8
          2603:1026:208:8b::8
          2603:1026:203:4f::8
          40.101.124.216
          52.97.170.72
          40.101.88.184
          40.101.88.8
Aliases:  autodiscover.uclabor.de
          autodiscover.outlook.com
          autod.ha.office365.com

Weiterhin gibt es einen Mail Contact, der Mails auf "notesuser@notes.uclabor.de" verweist. Den habe ich natürlich "On-Premises" angelegt und durch AADConnect synchronisieren lassen:

Nach einigen Minuten gab es dann auch in Office 365 einen Benutzer ohne Exchange Online Lizenz aber mit einer Weiterleitungsadresse:

PS C:\> Get-MsolUser -UserPrincipalName notesuser@uclabor.de | fl *dir*,proxy*

DirSyncProvisioningErrors : {}
IndirectLicenseErrors     : {}
LastDirSyncTime           : 10.03.2019 00:27:23
ProxyAddresses            : {smtp:notesuser@fcarius.onmicrosoft.com, smtp:notesuser@uclabor.de,
                            SMTP:notesuser@notes.uclabor.de}

PS C:\> Get-MailUser "Notes User" | fl userprin*,prim*,ExternalEmailAddress,emailadd*

UserPrincipalName : notesuser@uclabor.de
PrimarySmtpAddress : notesuser@notes.uclabor.de
ExternalEmailAddress : SMTP:notesuser@notes.uclabor.de
EmailAddresses : {smtp:notesuser@uclabor.de, smtp:notesuser@fcarius.onmicrosoft.com, X500:/o=First
Organization/ou=Exchange Administrative Group
(FYDIBOHF23SPDLT)/cn=Recipients/cn=xxx-Notes,
SMTP:notesuser@notes.uclabor.de}
EmailAddressPolicyEnabled : False

Der Benutzer in der Cloud ist soweit in Ordnung und ich habe einen Autodiscover-Test machen können:

  • Outlook
    Auf jeden Versuch von der Cloud eine Antwort zu bekommtn hat Exchange Online mit einem 401 statt einen Redirect geantwortet.
  • EWS (Failed)
    Auch der Versuch per EWS eine Autodiscover-Anfragen zu erhalten ist gescheitert
Trying to call Autodiscover for notesuser@uclabor.de on https://autodiscover.uclabor.de/autodiscover/autodiscover.xml
failed: WebException (Die Verbindung mit dem Remoteserver kann nicht hergestellt werden.)
Trying to get Autodiscover redirection URL from http://autodiscover.uclabor.de/autodiscover/autodiscover.xml.
Redirection URL found: 'https://autodiscover-s.outlook.com/autodiscover/autodiscover.xml
Trying to call Autodiscover for notesuser@uclabor.de on https://autodiscover-s.outlook.com/autodiscover/autodiscover.xml
failed: WebException (Der Remoteserver hat einen Fehler zurückgegeben: (401) Nicht autorisiert.)

Ich halte fest, dass Exchange Online zumindest am 10 März 2019 keine Umleitung anhand der TargetAdresse eines Benutzers Benutzers unterstützt. Es gibt daher keinen Weg für einen Dienst irgendwie einen lokalen Autodiscover-Service zu finden. Auch für 3rd Party Migrationen bedeutet dies, dass der "Autodiscover.<maildomain>"-Eintrag samt Zertifikaten immer auf einen On-Premises Exchange Server verweisen muss.

Autodiscover V2

Bislang wurde immer gesagt, dass "Autodiscover.<maildomain>" zwingend auf die lokale Umgebung verweisen muss damit der Client erst den Server fragt und dann ggfls. zu Office 365 umgeleitet wird. Das stimmt aber nur für den "klassischen Autodiscover"-Weg. Microsoft hat aber vor einiger Zeit eine "Version 2" veröffentlicht.

Entsprechend kompatible Clients nutzen andere Abfragen. Die scheinen zu funktionieren.

Invoke-RestMethod -Uri 'http://autodiscover.outlook.com/autodiscover/autodiscover.json?Email=notesuser@uclabor.de&Protocol=EWS'
Invoke-RestMethod : Der Remotename konnte nicht aufgelöst werden: 'autodiscover.notes.uclabor.de'

Hier bekommt der Client eine HTTPS-Umleitung auf einen "Autodiscover"-Eintrag mit der TargetDomain im DNS-Namen.

Wenn die Weiterleitug auf einenn gültigen Autodiscover-Eintrag verweist, dann bekommt der Client auch eine korrekte Antwort.

Invoke-RestMethod -Uri ‘http://autodiscover.outlook.com/autodiscover/autodiscover.json?Email=onprem@uslabor.de&Protocol=EWS’
Protocol Url
-------------- ---
EWS EWS      https://owa.uclabor.de/EWS/Exchange.asmx

Anscheinend ist es für Office 365 mit Autodiscover V2 überhaupt kein Problem auf Ziele zurück zu verweisen, die nicht in der Cloud sind.

Weitere Links