Outlook 2016 kann kein Profil erstellen

Das Erstellen eines neuen Outlookprofiles und die Verbindung zum Exchange Server mit Outlook 2016 schlagen fehl:

Also: „Fehler beim Anmelden… Der Microsoft Exchange-Informationsdienst ihres Profils enthält nicht alle erforderlichen Information…“

Die Autodiscover Ermittlung funktioniert nicht.

Outlook sucht die Einstellungen in der Autodiscover.xml. Um diese zu finden, führt Outlook eine Reihe von Schritten durch, die beendet werden, wenn die Autodiscover-Daten ermittelt werden konnten (Beispiel für EMail-Adresse des Benutzers xyz@foo.de):

1. Ermittelung der Autodiscover URL im Active Directory
2. https://foo.de/autodiscover/autodiscover.xml
3. https://autodiscover.foo.de/autodiscover/autodiscover.xml
4. http://autodiscover.foo.de/autodiscover/autodiscover.xml
5. Abfrage des Service Ressource Records (SRV) im DNS, um den FQDN des Servers, der die autodiscover.xml bereitstellt zu ermitteln: _tcp.foo.de
6. Ermittlung der URL in der lokalen Registrierung des Clients

Aus der EMail-Adresse des Benutzers wird der Domainpart (foo.de) mit den Hostname autodiscover zum FQDN verbunden: autodiscover.foo.de.

Für die Schritte 2. bis 5. werden die DNS-Server durch den Client abgefragt. Bei ersten Schritt erfolgt eine Active Directory Suche. Der letzte Schritt geht über die lokale Registrierung  der Clients.

Sobald einer der Suchen zum Erfolg führt, wird die Suche abgebrochen und mit der ermittelten Autodiscover URL versucht die autodiscover.xml herunter zu laden. Dies erfolgt dann über https oder http.

Wenn der Benutzer und der Rechner im Active Directory angemeldet sind, erfolgt die Ermittlung der Autodiscover XML über Service Connection Points (SCP) im Active Directory. Dort findet Outlook die notwendigen Angaben (ServiceBindingInformation), um die Autodiscover.xml abzurufen. Jeder Exchange Server mit Clientaccess stellt einen solchen SCP bereit:

CN=Ex001,CN=Autodiscover,CN=Protocols,CN=EX001,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=foo,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=ad,dc=foo,dc=de

Dort steht im Attribut ServiceBindingInformation die URL für den Autodiscover. Mit einen kleinen Skript kann überprüft werden, ob der Client SCPs im Active Directory ermitteln kann:

   $ConfigurationNamingContext = ([ADSI]"LDAP://rootdse").configurationNamingContext.tostring()   $dn = "cn=Microsoft Exchange,cn=services,{0}" -f $configurationNamingContext       $searcher = new-object system.DirectoryServices.DirectorySearcher("LDAP://$DN")   $searcher.Searchroot = "LDAP://$DN"   $searcher.SearchScope = "Subtree"   $keyWord1 =   "77378F46-2C66-4aa9-A6A6-3E7A48B19596"   $keyWord2 = "67661d7F-8FC4-4fa7-BFAC-E1D7794C1F68"   $searcher.filter =   "(&(objectClass=serviceConnectionPoint)(|(keywords=$keyword1)(keywords=$KeyWord2)))"       $searcher.propertiestoload.add("name") | out-Null   $searcher.propertiestoload.add("servicebindinginformation") |   out-Null   $searcher.propertiestoload.add("keywords") | out-Null       $results = $searcher.findall()   foreach ($result in $results) {         $RetVal =   New-object -TypeName psObject -property @{                     Name   = $result.properties.name                     ServiceBindingInformation   = $result.properties.servicebindinginformation                     KeyWords   = $result.properties.keywords          }          write-output $retval       }   

$ConfigurationNamingContext = ([ADSI]”LDAP://rootdse“).configurationNamingContext.tostring() $dn = “cn=Microsoft Exchange,cn=services,{0}” -f $configurationNamingContext   $searcher = new-object system.DirectoryServices.DirectorySearcher(“LDAP://$DN”) $searcher.Searchroot = “LDAP://$DN” $searcher.SearchScope = “Subtree” $keyWord1 = “77378F46-2C66-4aa9-A6A6-3E7A48B19596” $keyWord2 = “67661d7F-8FC4-4fa7-BFAC-E1D7794C1F68” $searcher.filter = “(&(objectClass=serviceConnectionPoint)(|(keywords=$keyword1)(keywords=$KeyWord2)))”   $searcher.propertiestoload.add(“name”) | out-Null $searcher.propertiestoload.add(“servicebindinginformation”) | out-Null $searcher.propertiestoload.add(“keywords”) | out-Null   $results = $searcher.findall() foreach ($result in $results) {       $RetVal = New-object -TypeName psObject -property @{                   Name = $result.properties.name                   ServiceBindingInformation = $result.properties.servicebindinginformation                   KeyWords = $result.properties.keywords        }        write-output $retval   }

Außerdem kann noch es der Fall sein, dass auf den Rechner eine Umleitung an eine lokale Datei oder eine Umleitung der URLs in der Registry auf eine vorgegebene URL im Schlüssel HKCU\Software\Microsoft\Office\16.0\Outlook\Autodiscover\RedirectServers hinterlegt ist. Bei Outlook 2016 kommt eine Besonderheit hinzu: Als erster Schritt, um die Autodiscover Daten zu ermitteln, versucht Outlook die Autodiscover.XML unter der URL https://autodiscover-s.outlook.com/autodiscover/autodiscover.xml zu finden. Das ist insbesondere dann ein Problem, wenn der Benutzer sich mit seiner Firmenadresse an der IT-Administration vorbei in Office365 registriert hat.

Wir haben also folgende Reihenfolge bei der Ermittlung:

• https://autodiscover-s.outlook.com/autodiscover/autodiscover.xml
• Abfrage des SCP im Active Directory, falls der Rechner im AD
• https://foo.de/autodiscover/autodiscover.xml
• https://autodiscover.foo.de/autodiscover/autodiscover.xml
• http://autodiscover.foo.de/autodiscover/autodiscover.xml
• Abfrage SRV Eintrag im DNS: _autodiscover._tcp.foo.de
• Lokale Umleitung

Wenn in einem der Schritte eine Autodiscover.XML ermittelt werden kann, ist die Suche beendet und Outlook versucht die Autodiscover.XML herunterzuladen und auszuwerten.

Beim vorliegenden Problem hatte ich es mit einem Benutzer und Rechner im AD zu tun. Eine lokale Umleitung lag nicht vor und die Abfrage der URL https://autodiscover-s.outlook.com/autodiscover/autodiscover.xml war durch eine Gruppenrichtlinie, die den Registry Eintrag

HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\16.0\Outlook\AutoDiscover\ExcludeExplicitO365Endpoint (REGDWord) = 1

erstellt, ausgeschaltet. Zusätzlich habe ich zu Testzwecken alle anderen Ermittlungsmethoden außer der Ermittlung des SCP in Active Directory durch eine Gruppenrichtlinie  deaktiviert. Dazu gibt es in den ADMX-Dateien für Office eine Vorlage.  Das obige Skript lieferte die korrekten SCPs für die zwei Exchange Server.

Was am Ende fehlschlug war nicht der Zugriff auf den SCP, sondern mit den dort ermittelten Informationen konnte nicht auf die Autodiscover.XML zu gegriffen.

Meistens sind bei Verwendung eines Proxyservers fehlende Ausnahmen in den Proxyserver Einstellungen des Internet Explores die Ursache dafür. In vorliegenden Fall war dies nicht der Fall, da diese Einstellungen für die Proxyausnahmen korrekt durch Gruppenrichtlinien gesetzt wurden. Die FQDNs der Autodiscover URl waren in den Proxyeinstellungen der Internetexplorers korrekt angeben.

Allerdings fiel auf, dass die automatische Konfiguration für die Verbindungseinstellungen konfiguriert war:

Dieses Häkchen in den Verbindungseinstellungen hat sich als die Ursache für das Problem heraus gestellt. Nachdem „Einstellungen automatisch erkennen“ deaktiviert wurde, konnte das Outlookprofil erfolgreich erstellt werden.

Tagged with → autodiscover • Exchange • Outlook