Autodiscover testen
Wenn Autodiscover für ihre Umgebung so "essentiell" ist, dann sollten Sie die Funktion auch überwachen. Aber auch als Überprüfung nach einer Installation oder Konfigurationsänderung ist so ein Werkzeug wichtig. Diese Seite stellt die verschiedenen Tools vor.
Microsoft Remote Connectivity Analyzer
Für Anwender und Administratoren, die die Funktion von Extern prüfen wollen, bietet sich der "Microsoft Remote Connectivity Analyzer " an. Sie geben einfach ihre Mailadresse und Anmeldedaten an und der Service prüft, ob und wie er mit AutoDiscover dazu ein Postfach finden kann. Die Ausgaben sind in der Regel gut zu lesen.
Beachten Sie aber, dass Sie ihre gültigen Anmeldedaten verwenden. Wer hier sensibel ist, sollte ein eigenes Testkonto anlegen oder nach dem Check sein Kennwort ändern.
-
Webseite zum externen Test der Exchange Anbindung und
DNS Einträge
https://www.testexchangeconnectivity.com/
Outlook GUI
Wenn Sie Outlook gestartet haben und neben der Uhr das "Outlook"-Icon sehen, können Sie mit "CTRL + Rechte Maustaste" hier den Punkt "E-Mail-AutoKonfiguration testen..."
Im nächsten Dialog sehen Sie dann schon, ob Outlook die Mailadresse richtig ermittelt. Für Exchange würde ich die Checkbox bei "GuessSmart" entfernen, damit POP3/IMAP4 Aliasse nicht genutzt werden.
Ich habe hier absichtlich die "example.com" genutzt, da hierfür kein "Autodiscover" verfügbar ist und daher alle Teilschritte durchlaufen werden. Auf der Karteikarte "Log" sehen sehen Sie die Schritte in der chronologischen Reihenfolge. Beachten Sie hier, dass am Ende zusätzlich noch ein Test gegen "autodiscover-s.outlook.com" gemacht wird, der so in der originalen Autodiscover-Konfiguration nicht beschrieben ist.
Interessant ist aber das Verhalten neuerer Outlook-Versionen, die nun auch noch am Anfang eine Abfrage zu Exchange Online voranstellen:
Damit stellt Outlook sicher, dass ein Exchange Online Postfach immer funktioniert, selbst wenn im Hybrid-Betrieb die lokale Autodiscover-Funktion gestört ist oder der Kunde den CNAME bei "autodiscover.<meinedomain.tld> vergessen hat. Das lässt sich auch im Fiddler überprüfen:
Die Mailadresse versteckt sich bei den Zugriffen auf autodisover.xml in der Payload des HTTP-POST.
Auch im HTTP-Header sehen Sie die X-AnchorMailbox
Outlook Tracing
Wenn Sie Outlook anweisen, einen Trace zu schreiben, dann legt Outlook mittlerweile "lesbare" Logs an. Die Einstellung kann auch der Gruppenrichtlinie aktiviert werden:
In der Folge schreibt Outlook je nach Version umfangreiche Protokolldateien an verschiedene Stellen.
%temp%\olkdisc.log Outlook 2010 Autodiscover Log %temp%\OlkAS folder %temp%\OlkCalLogs folder %temp%\Outlook Logging\*.*
- How to enable global and advanced logging for Microsoft Outlook
https://support.microsoft.com/en-us/topic/how-to-enable-global-and-advanced-logging-for-microsoft-outlook-15c74560-2aaa-befd-c256-7c8823b1aefa
Test mit Outlook COM-Objekt
Wenn Sie auf einem PC mit Outlook arbeiten, können Sie auch hier einen guten Test per GUI ausführen. Siehe dazu auch MSXFAQ.DE:Autodiscover:Outlook. Per GUI kann das auch ein Mitarbeiter im Helpdesk analysieren.
Wenn Outlook konfiguriert und aktiv ist, dann können Sie sogar per PowerShell die komplette XML abfragen:
(New-Object -ComObject Outlook.Application).session.autodiscoverxml
Test-OutlookWebServices
Exchange selbst liefert einige "Test-Comandlets" mit aus, die primär die "WebServices" prüfen, zu denen aber eine funktionierende Autodiscover-Abfrage erforderlich ist. Daher kann dieses Commandlet zumindest von intern auch genutzt werden, um die Funktion von Autodiscover zu verifizieren.
Test-OutlookWebServices -identity user1@msxfaq.de –MailboxCredential (Get-Credential)
Sie müssen natürlich eine Mailadresse ihrer Mailbox und die Anmeldedaten des Benutzers eingeben.
- Test-OutlookWebServices
https://technet.microsoft.com/en-us/library/bb124509(v=exchg.141).aspx - Test and Verify Autodiscover
https://technet.microsoft.com/en-us/library/cc539050.aspx
Autodiscover per EWS
Es ist ja nicht nur Outlook oder ein Mobil-Client, der per Autodiscover einen Weg sucht. Auch der Zugriff auf die verschiedenen Exchange WebServices (OAB, EWS, etc.) erfordert eine Auflösung per AutoDiscover. Wer hier die EWS Managed-API von Microsoft installiert hat, kann sehr schnell und einfach eine Autodiscover-Anfragen starten.
Schauen Sie sich z.B.: den Code in meinem Test-EWS-Skript an.
# Binde die Managed DLL ein und instanziere ein Objekt [void][Reflection.Assembly]::LoadFile("C:\Program Files\Microsoft\Exchange\Web Services\2.2\Microsoft.Exchange.WebServices.dll") $service = new-object Microsoft.Exchange.WebServices.Data.ExchangeService # definiere die Anmeldung mit expliziten Daten $service.UseDefaultCredentials = $false $service.Credentials = New-Object System.Net.NetworkCredential("cloudusa1@uclabor.de", "Password", "") #Setze weitere Flags für Traceing und SCP $service.TraceEnabled = $true $service.EnableScpLookup = $true # Starte Autodiscover und erlaube Redirect $service.AutodiscoverURL("cloudusa1@uclabor.de",{$true}) # Zeige die Anzahl der Mails in der Inbox $inbox = [Microsoft.Exchange.WebServices.Data.Folder]::Bind($service,[Microsoft.Exchange.WebServices.Data.WellKnownFolderName]::Inbox) write-host "Number or unread Messages : " $inbox.UnreadCount
Durch das Aktivieren des "Trace" können Sie per STDOUT genau sehen, welche Anfragen die DLL absendet.
- Test-EWS
- EWS
- Implementing an Autodiscover Client in Microsoft Exchange
http://msdn.microsoft.com/en-us/library/ee332364(EXCHG.140).aspx - Making use of Autodiscovery in VBS and PowerShell Scripts
http://gsexdev.blogspot.com/2008/01/making-use-of-autodiscovery-in-vbs-and.html - Exchange Managed API autodiscover with
Powershell
http://www.infinitec.de/post/2011/07/22/Exchange-Managed-API-autodiscover-with-Powershell.aspx
Autodiscover Trace mit EWS - primäres Postfach
Mit aktiviertem Trace und dem SCP-Lookup, welcher normal nicht aktiv ist, zeigt der Trace die Funktion von Autodiscover.
PS C:\> $service.AutodiscoverURL("cloudusa1@uclabor.de",{$true}) <Trace Tag="AutodiscoverConfiguration" Tid="6" Time="2017-02-01 20:28:35Z"> Starting SCP lookup for domainName='uclabor.de', root path='' </Trace> <Trace Tag="AutodiscoverConfiguration" Tid="6" Time="2017-02-01 20:28:44Z"> LDAP call failed, exception: System.Runtime.InteropServices.COMException (0x8007054B): Die angegebene Domäne ist nicht vorhanden, od er es konnte keine Verbindung hergestellt werden. bei System.DirectoryServices.DirectoryEntry.Bind(Boolean throwIfFail) bei System.DirectoryServices.DirectoryEntry.Bind() bei System.DirectoryServices.DirectoryEntry.get_AdsObject() bei System.DirectoryServices.PropertyValueCollection.PopulateList() bei System.DirectoryServices.PropertyValueCollection..ctor(DirectoryEntry entry, String propertyName) bei System.DirectoryServices.PropertyCollection.get_Item(String propertyName) bei Microsoft.Exchange.WebServices.Autodiscover.DirectoryHelper.GetScpUrlList(String domainName, String ldapPath, Int32& maxH ops) bei Microsoft.Exchange.WebServices.Autodiscover.DirectoryHelper.GetAutodiscoverScpUrlsForDomain(String domainName) </Trace>
Der Lookup per SCP ist aus dem Internet natürlich fehlgeschlagen. Also versucht EWS nun die beiden Zugriff auf https://uclabor.de und https://autodiscover.uclabor.de
<Trace Tag="AutodiscoverConfiguration" Tid="6" Time="2017-02-01 20:28:45Z"> Determining which endpoints are enabled for host uclabor.de </Trace> <Trace Tag="AutodiscoverConfiguration" Tid="6" Time="2017-02-01 20:28:45Z"> Request error: Die Anfrage wurde abgebrochen: Es konnte kein geschützter SSL/TLS-Kanal erstellt werden.. </Trace> <Trace Tag="AutodiscoverConfiguration" Tid="6" Time="2017-02-01 20:28:45Z"> No Autodiscover endpoints are available for host uclabor.de </Trace> <Trace Tag="AutodiscoverConfiguration" Tid="6" Time="2017-02-01 20:28:45Z"> Determining which endpoints are enabled for host autodiscover.uclabor.de </Trace> <Trace Tag="AutodiscoverConfiguration" Tid="6" Time="2017-02-01 20:28:59Z"> Request error: Die Verbindung mit dem Remoteserver kann nicht hergestellt werden. </Trace> <Trace Tag="AutodiscoverConfiguration" Tid="6" Time="2017-02-01 20:28:59Z"> No Autodiscover endpoints are available for host autodiscover.uclabor.de </Trace>
Aber auch diese beiden Zugriffe sind per HTTP fehlgeschlagen. Dann versucht EWS den Zugriff ohne SSL um einen Redirect zu erhalten
<Trace Tag="AutodiscoverConfiguration" Tid="6" Time="2017-02-01 20:28:59Z"> Trying to get Autodiscover redirection URL from http://autodiscover.uclabor.de/autodiscover/autodiscover.xml. </Trace> <Trace Tag="AutodiscoverConfiguration" Tid="6" Time="2017-02-01 20:28:59Z"> Redirection URL found: 'https://autodiscover-s.outlook.com/autodiscover/autodiscover.xml' </Trace> <Trace Tag="AutodiscoverConfiguration" Tid="6" Time="2017-02-01 20:28:59Z"> Determining which endpoints are enabled for host autodiscover-s.outlook.com </Trace> <Trace Tag="AutodiscoverConfiguration" Tid="6" Time="2017-02-01 20:29:00Z"> Request error: Der Remoteserver hat einen Fehler zurückgegeben: (401) Nicht autorisiert. </Trace> <Trace Tag="AutodiscoverConfiguration" Tid="6" Time="2017-02-01 20:29:00Z"> Host returned enabled endpoint flags: Legacy, Soap, WsSecurity, WSSecuritySymmetricKey, WSSecurityX509Cert, OAuth </Trace>
Der Redirect hat funktioniert. Nun kann der Client einen POST senden. Ich nutze die EWS Managed API und damit ist klar, dass dieser Client natürlich auch die EWS-URL interessiert. Diese wird gezielt angefragt.
<Trace Tag="AutodiscoverRequestHttpHeaders" Tid="6" Time="2017-02-01 20:29:00Z"> POST /autodiscover/autodiscover.svc HTTP/1.1 Content-Type: text/xml; charset=utf-8 Accept: text/xml User-Agent: ExchangeServicesClient/15.00.0913.015 </Trace> <Trace Tag="AutodiscoverRequest" Tid="6" Time="2017-02-01 20:29:00Z" Version="15.00.0913.015"> <?xml version="1.0" encoding="utf-8"?> <soap:Envelope xmlns:a="http://schemas.microsoft.com/exchange/2010/Autodiscover" xmlns:wsa="http://www.w3.org/2005/08/addressing" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Header> <a:RequestedServerVersion>Exchange2013_SP1</a:RequestedServerVersion> <wsa:Action>http://schemas.microsoft.com/exchange/2010/Autodiscover/Autodiscover/GetUserSettings</wsa:Action> <wsa:To>https://autodiscover-s.outlook.com/autodiscover/autodiscover.svc</wsa:To> </soap:Header> <soap:Body> <a:GetUserSettingsRequestMessage xmlns:a="http://schemas.microsoft.com/exchange/2010/Autodiscover"> <a:Request> <a:Users> <a:User> <a:Mailbox>cloudusa1@uclabor.de</a:Mailbox> </a:User> </a:Users> <a:RequestedSettings> <a:Setting>InternalEwsUrl</a:Setting> <a:Setting>ExternalEwsUrl</a:Setting> </a:RequestedSettings> </a:Request> </a:GetUserSettingsRequestMessage> </soap:Body> </soap:Envelope> </Trace>
Als Antwort bekommt der Client einen 200 OK mit einem ziemlich umfangreichem Cookie. Ich habe die Authentication-Informationen natürlich entfernt
<Trace Tag="AutodiscoverResponseHttpHeaders" Tid="6" Time="2017-02-01 20:29:02Z"> HTTP/1.1 200 OK Transfer-Encoding: chunked request-id: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx X-CalculatedBETarget: cy1pr20mb0631.namprd20.prod.outlook.com X-DiagInfo: CY1PR20MB0631 X-BEServer: CY1PR20MB0631 Cache-Control: private Content-Type: text/xml; charset=utf-8 Set-Cookie: EXOBasicAuth=compactTicket=t%3dxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx&key=cloudusa1%40uclabor.de+microsoft.exchange.autodiscover+77.20.11.223+&signature xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx&puid=100300009A804B4C&expireTime=636216065 400000000&membername=cloudusa1%40uclabor.de&flags=False&UserType=ManagedBusiness; expires=Thu, 02-Feb-2017 04:29:00 GMT; path=/autodiscover; secure; HttpOnly,X-BackEndCookie2=cloudusa1@uclabor.de=xxxxxx=; expires=Fri, 03-Mar-2017 20:29:00 GMT; path=/aut odiscover; secure; HttpOnly,X-BackEndCookie=cloudusa1@uclabor.de=xxxxxxx; expires=Fri, 03-Mar-2017 20:29:00 GMT; path=/autodiscover; secure; HttpOnly Server: Microsoft-IIS/8.5 X-AspNet-Version: 4.0.30319 X-Powered-By: ASP.NET X-FEServer: VI1PR07CA0115 Date: Wed, 01 Feb 2017 20:29:00 GMT </Trace>
Sie sehen her aber anhand der Servernamen, dass dieses Postfach wohl in Nordamerika liegen muss. Da ich nur nach der EWS-URL gefragt habe, bekomme ich auch nur diese Antwort. Daher ist die Antwort "überschaubar"
<Trace Tag="AutodiscoverResponse" Tid="6" Time="2017-02-01 20:29:02Z" Version="15.00.0913.015"> <s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" xmlns:a="http://www.w3.org/2005/08/addressing"> <s:Header> <a:Action s:mustUnderstand="1">http://schemas.microsoft.com/exchange/2010/Autodiscover/Autodiscover/GetUserSettingsResponse</a:Action> <h:ServerVersionInfo xmlns:h="http://schemas.microsoft.com/exchange/2010/Autodiscover" xmlns:i="http://www.w3.org/2001/XMLSchema-instance"> <h:MajorVersion>15</h:MajorVersion> <h:MinorVersion>1</h:MinorVersion> <h:MajorBuildNumber>888</h:MajorBuildNumber> <h:MinorBuildNumber>17</h:MinorBuildNumber> <h:Version>Exchange2015</h:Version> </h:ServerVersionInfo> </s:Header> <s:Body> <GetUserSettingsResponseMessage xmlns="http://schemas.microsoft.com/exchange/2010/Autodiscover"> <Response xmlns:i="http://www.w3.org/2001/XMLSchema-instance"> <ErrorCode>NoError</ErrorCode> <ErrorMessage /> <UserResponses> <UserResponse> <ErrorCode>NoError</ErrorCode> <ErrorMessage>No error.</ErrorMessage> <RedirectTarget i:nil="true" /> <UserSettingErrors> <UserSettingError> <ErrorCode>SettingIsNotAvailable</ErrorCode> <ErrorMessage>User setting 'InternalEwsUrl' is not available. </ErrorMessage> <SettingName>InternalEwsUrl</SettingName> </UserSettingError> </UserSettingErrors> <UserSettings> <UserSetting i:type="StringSetting"> <Name>ExternalEwsUrl</Name> <Value>https://outlook.office365.com/EWS/Exchange.asmx</Value> </UserSetting> </UserSettings> </UserResponse> </UserResponses> </Response> </GetUserSettingsResponseMessage> </s:Body> </s:Envelope> </Trace>
Hätte ich die Abfrage mit Outlook gemacht, dann wären hier sehr viel mehr Informationen zu sehen, z.B. die verschiedenen Zugänge zum Postfach, die OAB-Download-URLs, die Zugänge zu Unified Messaging, OOF-Einstellungen und andere.
Wenn ich z.B. eine falsche Mailadresse übergebe, dann ist auch dies in der XML-Struktur beschrieben.
HTTP/1.1 200 OK request-id: 2b7105a2-906c-488e-8f59-f79436e4d894 X-CalculatedBETarget: cy1pr20mb0631.namprd20.prod.outlook.com X-DiagInfo: CY1PR20MB0631 X-BEServer: CY1PR20MB0631 Cache-Control: private Content-Type: text/xml; charset=utf-8 Set-Cookie: X-BackEndCookie2=cloudusa1@uclabor.de=uxxxxx; expires=Fri, 03-Mar-2017 20:34:10 GMT; path=/autodiscover; secure; HttpOn ly,X-BackEndCookie=cloudusa1@uclabor.de=xxxxx; expires=Fri, 03-Mar-2017 20:34:10 GMT; path=/autodiscover; secure; HttpOnly Server: Microsoft-IIS/8.5 X-AspNet-Version: 4.0.30319 X-Powered-By: ASP.NET X-FEServer: DB6PR0802CA0040 Date: Wed, 01 Feb 2017 20:34:09 GMT Content-Length: 360 </Trace> <Trace Tag="AutodiscoverResponse" Tid="6" Time="2017-02-01 20:34:11Z" Version="15.00.0913.015"> <?xml version="1.0" encoding="utf-8"?> <Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006"> <Response> <Error Time="20:34:09.8115253" Id="153269344"> <ErrorCode>500</ErrorCode> <Message>The email address can't be found.</Message> <DebugData /> </Error> </Response> </Autodiscover> </Trace> Ausnahme beim Aufrufen von "AutodiscoverUrl" mit 2 Argument(en): "The Autodiscover service returned an error." In Zeile:1 Zeichen:1 + $service.AutodiscoverURL("unvalidmail@uclabor.de",{$true}) + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : NotSpecified: (:) [], MethodInvocationException + FullyQualifiedErrorId : AutodiscoverRemoteException