Jump to content

Exchange-Online Migration - manche Clients machen keinen Redirect im Autodiscover


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

Guten Morgen,

 

woran könnte es liegen, dass manche Clients (W2K12R2 RDP-Hosts mit Office 2016) sich nicht per Autodiscover zu Exchange-Online verbinden?

 

  • Postfach ist migriert
  • Batch ist abgeschlossen
  • Outlook neu gestartet

 

Der Client verbindet sich weiterhin mit dem lokalen Exchange.

 

Folgender Key war bisher gesetzt, wurde jetzt aber entfernt.

HKEY_CURRENT_USER\SOFTWARE\Policies\Microsoft\office\16.0\outlook\autodiscover DWORD: ExcludeExplicitO365Endpoint

 

Folgender Key soll man lt MS setzen, bringt aber auch nichts.

https://docs.microsoft.com/en-US/outlook/troubleshoot/profiles-and-accounts/cannot-connect-web-service-not-working-migrated-to-office-365

HKEY_CURRENT_USER\Software\Microsoft\Office\<x.0>\Outlook\Autodiscover DWORD: ExcludeLastKnownGoodUrl

 

Im lokalen DNS zeigt autodiscover.domain.de noch auf den lokalen Exchange. Aber manche Clients (vorwiegend W10 mit O365) machen den redirect.

 

Habt Ihr einen Tipp?

 

Grüße

Link zu diesem Kommentar

Hi,

 

deaktiviere aus GPS: Disable AutoDiscover (gpsearch.azurewebsites.net) mal alles außer:

  • Exclude HTTP redirect
  • Exclude explicit o365 endpoint
  • Disable autodiscover v2 service

Zusätzlich ggfs. noch GPS: Disable GuessSmart in Outlook. (gpsearch.azurewebsites.net).

 

Bei Windows Server 2012 R2 könnte das Problem auch noch am evtl. nicht aktivierten TLS 1.2 liegen.

 

Gruß

Jan

Link zu diesem Kommentar

Hilft leider nicht.

 

Die Registry-Keys für TLS 1.2 habe ich gesetzt. Die wollte auf dem Exchange auch der HCW haben:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft.NETFramework\v2.0.50727] "SystemDefaultTlsVersions" = dword:00000001 "SchUseStrongCrypto" = dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft.NETFramework\v4.0.30319] "SystemDefaultTlsVersions" = dword:00000001 "SchUseStrongCrypto" = dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft.NETFramework\v2.0.50727] "SystemDefaultTlsVersions" = dword:00000001 "SchUseStrongCrypto" = dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft.NETFramework\v4.0.30319] "SystemDefaultTlsVersions" = dword:00000001 "SchUseStrongCrypto" = dword:00000001

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client] "DisabledByDefault"=dword:00000000 "Enabled"=dword:00000001

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server] "DisabledByDefault"=dword:00000000 "Enabled"=dword:00000001

 

Es scheint ein Office 2016 mit Windows 2012 R2 Problem zu sein :hmmm:.

 

Wenn ich das Autodiscover.xml direkt aufrufe, erscheit zuerst eine Passwortabfrage und dann das xml mit Error 600

<Response>
<Error Time="11:21:20.2318216" Id="1596708203">
<ErrorCode>600</ErrorCode>
<Message>Ungültige Anforderung</Message>
<DebugData/>
</Error>
</Response>
</Autodiscover>
 
Intern zeigt Autodiscover noch immer per Split-DNS auf den lokalen Exchange.
 
 
 
Link zu diesem Kommentar

Damit das funktioniert hat, mussten ein paar Dinge gemacht werden. Nichts konnte ausgelassen werden. Alles ist notwendig. Evtl. hilft es auch jemandem anderen.

 

  • Sophos blockiert standardmäßig Autodiscover extern. Die URLs von hier https://support.sophos.com/support/s/article/KB-000038173?language=en_US helfen nicht. Man muss autodiscover.firma.com und autodiscover.firma.mail.onmicrosoft.com in die Exceptions aufnehmen. Es ist unklar warum Sophos das blockiert.
  • ExcludeHttpRedirect auf 0 (war 1), ExcludeLastKnownGoodURL auf 1, ExcludeExplicitO365Endpoint auf 0. Unklar wo die Keys, außer ExcludeExplicitO365Endpoint, herkommen. Wurden nicht absichtlich gesetzt.
  • HKEY_CURRENT_USER\Software\Microsoft\Office\x.0\Outlook\AutoDiscover gab es einen Unterschlüssel RedirectServers mit zwei Einträgen. Diesen löschen, wird beim Start von Outlook dann mit 6 anderen Einträgen neu generiert. Mit den zwei vorhandenen Schlüssel funktioniert es nicht.
  • Split-DNS für Autodiscover entfernen. Die Profile bleiben auch so erhalten und die OST wird nicht neu generiert.
  • MFA muss für die Zeit der Profiländerung deaktiviert werden. MFA funktioniert nur mit Office365 nicht mit 2016
  • Zusammen mit SSO muss der Nutzer dann nichts machen, außer Outlook starten.
  • In manchen Profilen bleibt der Microsoft Anmeldedialog (OAuth?) auf und der Vorgang bleibt stehen. Dann muss darin auf „anderen Usernamen“ geklickt werden und die Email-Adresse eingegeben werden. Dann nämlich will sich Outlook mit dem @firma.local zu O365 verbinden.

 

Windows 10/11 mit Office 365 macht keinerlei Probleme, das funktioniert einfach, auch wenn die Sophos Autodiscover blockiert. Windows 10 mit Office 2016 braucht die gleichen Streicheleinheiten.

 

Die Registry-Keys für TLS 1.2 waren auf dem Exchange (W2K12R2) für den HCW nötig. Aber auf einem RDP Host nicht, bzw. ändern nichts. Schaden aber auch nicht, so wie es scheint.

 

Grüße

 

Link zu diesem Kommentar
  • 4 Monate später...
Am 4.8.2022 um 22:38 schrieb wznutzer:

Damit das funktioniert hat, mussten ein paar Dinge gemacht werden. Nichts konnte ausgelassen werden. Alles ist notwendig. Evtl. hilft es auch jemandem anderen.

 

  • Sophos blockiert standardmäßig Autodiscover extern. Die URLs von hier https://support.sophos.com/support/s/article/KB-000038173?language=en_US helfen nicht. Man muss autodiscover.firma.com und autodiscover.firma.mail.onmicrosoft.com in die Exceptions aufnehmen. Es ist unklar warum Sophos das blockiert.
  • ExcludeHttpRedirect auf 0 (war 1), ExcludeLastKnownGoodURL auf 1, ExcludeExplicitO365Endpoint auf 0. Unklar wo die Keys, außer ExcludeExplicitO365Endpoint, herkommen. Wurden nicht absichtlich gesetzt.
  • HKEY_CURRENT_USER\Software\Microsoft\Office\x.0\Outlook\AutoDiscover gab es einen Unterschlüssel RedirectServers mit zwei Einträgen. Diesen löschen, wird beim Start von Outlook dann mit 6 anderen Einträgen neu generiert. Mit den zwei vorhandenen Schlüssel funktioniert es nicht.
  • Split-DNS für Autodiscover entfernen. Die Profile bleiben auch so erhalten und die OST wird nicht neu generiert.
  • MFA muss für die Zeit der Profiländerung deaktiviert werden. MFA funktioniert nur mit Office365 nicht mit 2016
  • Zusammen mit SSO muss der Nutzer dann nichts machen, außer Outlook starten.
  • In manchen Profilen bleibt der Microsoft Anmeldedialog (OAuth?) auf und der Vorgang bleibt stehen. Dann muss darin auf „anderen Usernamen“ geklickt werden und die Email-Adresse eingegeben werden. Dann nämlich will sich Outlook mit dem @firma.local zu O365 verbinden.

 

Windows 10/11 mit Office 365 macht keinerlei Probleme, das funktioniert einfach, auch wenn die Sophos Autodiscover blockiert. Windows 10 mit Office 2016 braucht die gleichen Streicheleinheiten.

 

Die Registry-Keys für TLS 1.2 waren auf dem Exchange (W2K12R2) für den HCW nötig. Aber auf einem RDP Host nicht, bzw. ändern nichts. Schaden aber auch nicht, so wie es scheint.

 

Grüße

 

danke, sehr hilfreich deine Erkenntnisse

 

bearbeitet von Dirk-HH-83
Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...