Hallo zusammen! Nachdem ich nun so ziemlich alles ausprobiert habe, was ich gefunden habe und auch ein wenig Abstand nicht geholfen hab, brauche ich doch mal die Kraft der Community.
Umgebung:
Exchange 2019 CU9 latest (Single-Server, ursprünglich mal ein SBS2008 über Exchange 2013 migriert, aber schon eine Weile her) auf einen S2019STD
Alle internen und externen Pfade auf eine FQDN mit Split DNS und Let's Encrypt Zertifikaten
Windows 10 und 7 Client mit Outlook 2013, vollständig gepatcht
Was geht:
Autodiscover über Outlook und testconnectivity
OWA komplett inkl. OOA und Public Folder
Outlook App auf IOS und Android, Mail App auf IOS
Outlook Autoconfigure und Download der Mailboxen
Was geht nicht:
Alle Outlook Clients zeigen nach dem Start und einem Update des Posteingangs sofort "Kennwort erforderlich" an. Es kommt aber kein Loginfenster für die Abfrage der Zugangsdaten. Es reicht ein Klick auf "Kennwort erforderlich" und dann ist Outlook wieder unregelmäßig lange verbunden. Gerade beim Ordnerwechsel oder Zugriff auf Public Folder kommt die Meldung wieder. Zugriffe auf Public Folder oder freigegebene Kalender funktionieren manchmal nicht wenn die Meldung in Outlook steht, aber sofort nachdem man sie wieder "weg" geklickt hat. Es gibt keine gespeicherten Anmeldedaten auf den Clients bzw. sind die während der Fehleranalyse gelöscht worden. Outlook verbindet per HTTPS mit NTLM. Cache oder Non-Cache-Modus machen keinen unterschied.
Outlook extern ist nicht in Verwendung und auch nicht getestet. OOA aus Outlook geht gar nicht.
Ausfälligkeiten:
Outlook kann das OAB nicht herunterladen, es kommt aber kein Fehler in Outlook. Der Zugriff per Browser auf die OAB-URL funktioniert. BITS zeigt einen Fehler an, greift aber auf die richtige URL zu:
"ERROR CODE: 0x80072efd - Die Serververbindung konnte nicht hergestellt werden"
Im IIS Log sehe ich Zugriffe von dem Testclient, aber keine auf /oab/. Im Exchange OABDownload-Log sehe ich Die Zugriffe aus dem Browser samt AuthenticationType, die BITS Anfragen aber nicht. Ich nehme an dass hier aber nur der erfolgreiche Download eines OAB protokolliert wird. Es ist aber generelles BITS Problem (z.B. durch den Chrome-Updater) und ich weiß auch nicht ob das nicht eine falsche Fährte ist.
In den erweiterten Kontoeinstellungen ist "Netzwerksicherheit bei der Anmeldung" ausgegraut und hat keinen Wert (bei einem autokonfigurierten Profil)
Zig Logeinträge im Exchange-Log "NotificationClient" a la "2021-06-03T21:03:51.800Z,XXXEXC19,ReceiveNotification,"S:CsmId=OData;S:Sts=UnknownError;S:L=0;S:Ex=Microsoft.Exchange.Rpc.RpcException: Error 0x6d9 (In der Endpunktzuordnung sind keine weiteren Endpunkte verfügbar) from ClientAsyncCallState.CheckCompletion: RpcAsyncCompleteCall \r\nEEInfo: ComputerName: \r\nEEInfo: ProcessID: 13956\r\nEEInfo: Generation Time: 03.06.2021 21:03:51\r\nEEInfo: Generating component: 2\r\nEEInfo: Status: 0x000006D9\r\nEEInfo: Detection location: 950\r\nEEInfo: Flags: 0\r\nEEInfo: NumberOfParameters: 0\r\n\r\n\r\n bei Microsoft.Exchange.Rpc.ClientAsyncCallState.CheckCompletion()\r\n bei Microsoft.Exchange.Rpc.NotificationsBroker.ClientAsyncCallState_GetNextNotification.End(String& notification)\r\n bei Microsoft.Exchange.Rpc.NotificationsBroker.NotificationsBrokerRpcClient.EndGetNextNotification(ICancelableAsyncResult asyncResult, String& notification)\r\n bei Microsoft.Exchange.Data.Notification.NotificationClient.<>c__DisplayClass36_0.<OnNotification>b__0(NotificationClientLogEvent logEvent)""
Der Mailversand aus dem Android-Mail Client funktioniert nicht (aber das ist vermutlich ein anderes Thema), die anderen Funktionen sind in Ordnung.
Was hab ich bereits geprüft:
Alles was mit Autodiscover zu tun hat (möchte ich aber trotzdem nicht ausschließen), VirtualDirectories neu angelegt, IIS Authentifications verändert, UpdateCAS und co., diverse Registry-Einträge und natürlich OAB neu angelegt und dessen Erstellung geprüft.
Wann ist es aufgetreten:
Naja, wie das manchmal so ist hab ich CU9, die drängenden KBs und Umstellung von einem internen SelfSigned Zertifikat auf Let's Encrypt und dabei die Homogenisierung der internal und externalURLs zügig hintereinander umgesetzt und dabei OWA im Auge behalten. Vorher gab es durch das Zertifikat eh noch Autodiscover-Probleme.
Ich sag schonmal danke für alle Ideen die ihr dazu habt.
<?xml version="1.0" encoding="utf-8"?>
<Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006">
<Response xmlns="http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a">
<User>
<DisplayName>User</DisplayName>
<LegacyDN>/o=First Organization/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=User</LegacyDN>
<AutoDiscoverSMTPAddress>User@XXX.de</AutoDiscoverSMTPAddress>
<DeploymentId>cdf99b8a-b0e8-41e8-ba27-9cd8f0faaa12</DeploymentId>
</User>
<Account>
<AccountType>email</AccountType>
<Action>settings</Action>
<MicrosoftOnline>False</MicrosoftOnline>
<ConsumerMailbox>False</ConsumerMailbox>
<Protocol Type="mapiHttp" Version="1">
<MailStore>
<InternalUrl> https://mail.XXX.de/mapi/emsmdb/?MailboxId=1a3e30fe-4e5b-4aaa-8a3c-2ef8e49fdcd3@XXX.de</InternalUrl>
<ExternalUrl> https://mail.XXX.de/mapi/emsmdb/?MailboxId=1a3e30fe-4e5b-4aaa-8a3c-2ef8e49fdcd3@XXX.de</ExternalUrl>
</MailStore>
<AddressBook>
<InternalUrl> https://mail.XXX.de/mapi/nspi/?MailboxId=1a3e30fe-4e5b-4aaa-8a3c-2ef8e49fdcd3@XXX.de</InternalUrl>
<ExternalUrl> https://mail.XXX.de/mapi/nspi/?MailboxId=1a3e30fe-4e5b-4aaa-8a3c-2ef8e49fdcd3@XXX.de</ExternalUrl>
</AddressBook>
</Protocol>
<Protocol>
<Type>WEB</Type>
<Internal>
<OWAUrl AuthenticationMethod="Basic, Fba"> https://mail.XXX.de/owa/</OWAUrl>
<Protocol>
<Type>EXCH</Type>
<ASUrl> https://mail.XXX.de/EWS/Exchange.asmx</ASUrl>
</Protocol>
</Internal>
<External>
<OWAUrl AuthenticationMethod="Fba"> https://mail.XXX.de/owa/</OWAUrl>
<Protocol>
<Type>EXPR</Type>
<ASUrl> https://mail.XXX.de/EWS/Exchange.asmx</ASUrl>
</Protocol>
</External>
</Protocol>
<Protocol>
<Type>EXHTTP</Type>
<Server>mail.XXX.de</Server>
<SSL>On</SSL>
<AuthPackage>Ntlm</AuthPackage>
<ASUrl> https://mail.XXX.de/EWS/Exchange.asmx</ASUrl>
<EwsUrl> https://mail.XXX.de/EWS/Exchange.asmx</EwsUrl>
<EmwsUrl> https://mail.XXX.de/EWS/Exchange.asmx</EmwsUrl>
<EcpUrl> https://mail.XXX.de/owa/</EcpUrl>
<EcpUrl-um>?path=/options/callanswering</EcpUrl-um>
<EcpUrl-aggr>?path=/options/connectedaccounts</EcpUrl-aggr>
<EcpUrl-mt>options/ecp/PersonalSettings/DeliveryReport.aspx?rfr=olk&exsvurl=1&IsOWA=<IsOWA>&MsgID=<MsgID>&Mbx=<Mbx>&realm=XXX.local</EcpUrl-mt>
<EcpUrl-ret>?path=/options/retentionpolicies</EcpUrl-ret>
<EcpUrl-sms>?path=/options/textmessaging</EcpUrl-sms>
<EcpUrl-publish>?path=/options/calendarpublishing/id/<FldID></EcpUrl-publish>
<EcpUrl-photo>?path=/options/myaccount/action/photo</EcpUrl-photo>
<EcpUrl-tm>options/ecp/?rfr=olk&ftr=TeamMailbox&exsvurl=1&realm=XXX.local</EcpUrl-tm>
<EcpUrl-tmCreating>options/ecp/?rfr=olk&ftr=TeamMailboxCreating&SPUrl=<SPUrl>&Title=<Title>&SPTMAppUrl=<SPTMAppUrl>&exsvurl=1&realm=XXX.local</EcpUrl-tmCreating>
<EcpUrl-tmEditing>options/ecp/?rfr=olk&ftr=TeamMailboxEditing&Id=<Id>&exsvurl=1&realm=XXX.local</EcpUrl-tmEditing>
<EcpUrl-extinstall>?path=/options/manageapps</EcpUrl-extinstall>
<OOFUrl> https://mail.XXX.de/EWS/Exchange.asmx</OOFUrl>
<UMUrl> https://mail.XXX.de/EWS/UM2007Legacy.asmx</UMUrl>
<OABUrl> https://mail.XXX.de/OAB/215aeab0-df5c-43e8-ad03-7f120d9924fa/</OABUrl>
<ServerExclusiveConnect>On</ServerExclusiveConnect>
</Protocol>
<Protocol>
<Type>EXHTTP</Type>
<Server>mail.XXX.de</Server>
<SSL>On</SSL>
<AuthPackage>Negotiate</AuthPackage>
<ASUrl> https://mail.XXX.de/EWS/Exchange.asmx</ASUrl>
<EwsUrl> https://mail.XXX.de/EWS/Exchange.asmx</EwsUrl>
<EmwsUrl> https://mail.XXX.de/EWS/Exchange.asmx</EmwsUrl>
<EcpUrl> https://mail.XXX.de/owa/</EcpUrl>
<EcpUrl-um>?path=/options/callanswering</EcpUrl-um>
<EcpUrl-aggr>?path=/options/connectedaccounts</EcpUrl-aggr>
<EcpUrl-mt>options/ecp/PersonalSettings/DeliveryReport.aspx?rfr=olk&exsvurl=1&IsOWA=<IsOWA>&MsgID=<MsgID>&Mbx=<Mbx>&realm=XXX.local</EcpUrl-mt>
<EcpUrl-ret>?path=/options/retentionpolicies</EcpUrl-ret>
<EcpUrl-sms>?path=/options/textmessaging</EcpUrl-sms>
<EcpUrl-publish>?path=/options/calendarpublishing/id/<FldID></EcpUrl-publish>
<EcpUrl-photo>?path=/options/myaccount/action/photo</EcpUrl-photo>
<EcpUrl-tm>options/ecp/?rfr=olk&ftr=TeamMailbox&exsvurl=1&realm=XXX.local</EcpUrl-tm>
<EcpUrl-tmCreating>options/ecp/?rfr=olk&ftr=TeamMailboxCreating&SPUrl=<SPUrl>&Title=<Title>&SPTMAppUrl=<SPTMAppUrl>&exsvurl=1&realm=XXX.local</EcpUrl-tmCreating>
<EcpUrl-tmEditing>options/ecp/?rfr=olk&ftr=TeamMailboxEditing&Id=<Id>&exsvurl=1&realm=XXX.local</EcpUrl-tmEditing>
<EcpUrl-extinstall>?path=/options/manageapps</EcpUrl-extinstall>
<OOFUrl> https://mail.XXX.de/EWS/Exchange.asmx</OOFUrl>
<UMUrl> https://mail.XXX.de/EWS/UM2007Legacy.asmx</UMUrl>
<OABUrl> https://mail.XXX.de/OAB/215aeab0-df5c-43e8-ad03-7f120d9924fa/</OABUrl>
<ServerExclusiveConnect>On</ServerExclusiveConnect>
</Protocol>
<PublicFolderInformation>
<SmtpAddress>PFMailbox1@XXX.local</SmtpAddress>
</PublicFolderInformation>
</Account>
</Response>
</Autodiscover>
Um dem Thema weiter auf den Grund zu gehen habe ich nun Fiddler auf einem Testsystem installiert. Tja, was soll ich sagen. Outlook funktioniert nun wie gewünscht und sogar inkl. OOA. Es muss also an sich ein Zertifikat/Auth Problem sein, da Fiddler sich ja dazwischenschaltet und diesen Prozess dadurch abändert.
Was weiter nicht funktioniert ist der OAB Download, hier kommt die Verbindung zustande (HTTP 200) und wird vom Exchange laut Fiddler abgebrochen:
fiddler.network.https> HTTPS handshake to mail.XXX.de (for #165) failed. System.IO.IOException Fehler bei Authentifizierung, da die Gegenseite den Transportstream geschlossen hat.
@fcnet Respekt, die beste Fehlerbeschreibung die ich je gelesen habe ?
Ist Office 2013 aktuell mit Service Packs? Ein Test wäre die Möglichkeit Office 2019 zu installieren.
Bzgl. OAB - evtl. helfen Dir diese Links weiter: MS Anleitung und Forumsbeitrag 1 / Forumsbeitrag 2
Danke, danke! Ich versuche mal ähnlich strukturiert weiter zu machen ?
OAB:
Nach einem Exchange-Server Neustart scheint das OAB zumindest in Etappen zu laden. Ich stelle das mal hinten an weil es ja auch mit den Kommunikationsproblemen zwischen Client und Exchange zu tun haben kann. Auf den Testclients auf denen das OAB nun geladen wurde ändert sich zumindest nichts am Verhalten von Outlook. Deine Anregungen checke ich trotzdem noch.
Outlook Versionen:
Outlook 2019 steht mir hier leider nicht zur Verfügung, 2016 habe ich mal installiert und es verhält sich beim vorhandenen Profil genauso wie das 2013er, inklusive dem Umstand, dass es wunderbar funktioniert sobald Fiddler sich zwischen hängt. Hier kann man aber statt "Kennwort erforderlich" auch mal "Verbindungsversuch" lesen. Es kommt dann auch der Tooltip das man das Kennwort neu eingeben muss. Auch bei einem neu angelegten lande ich beim gleichen Ergebnis. Hier kam eine Meldung bezüglich Konfigurationsumleitung der Public Mailbox:
"Konfigurieren von PFMailbox1@XXX.local-Serevreinstellungen für diese Webseite zulassen?" mit dem richtigen Autodiscover-Pfad. Das ist für Outlook 2013 über die Registry für mail.XXX.de per Autodiscover\RedirectServers unterdrückt. Outlook 2016 kann meine ich ja mehr protokollieren als 2013, leider finde ich in den Logs nichts wirklich hilfreiches, hab die aber auch nur über den normalen EventViewer geprüft.
Ein Outlook 2019 konnte ich nur mit einer externen Verbindung prüfen, was der Vollständigkeit halber ja eh noch ausstand. Alles einwandfrei.
Weitere Analyse:
Ich hab dann noch die Hinweise mit evt. "versteckten" Kennwortfenstern geprüft, aber ohne Erfolg. Da Fiddler das Verhalten durch seine Man-In-The-Middle Position verändert, hab ich versucht über WireShark weiter zu kommen und hab die Einträge in Exchange Logs nochmal durchwühlt und bin jetzt erstmal der Annahme, das etwas beim Zugriff auf das WebService Directory nicht funktioniert. Alle /mapi/ Logs sahen sauber aus und Zugriffe auf /EWS/Exchange.asmx scheinen immer unautorisiert zu bleiben und irgendwie mit dem "Kennwort erforderlich" zu korrelieren. Daher hab ich das WebServices VirtualDirectory neu erstellt.
Aktuelle Situation:
Nach der Neuerstellung ist nur die internalURL gesetzt, auf https://HOST.XXX.local. Daher hab ich Outlook (2ß16) direkt mal so getestet. Jetzt kommt natürlich eine Zertifikatsabfrage und zuerst hatte ich das Gefühl, dass sich der Verbindungszustand hält...aber dann... nein. Keine Änderung. Also die URLs wieder korrekt gesetzt und keine Verbesserung...
Hi,
Exchange 2019 setzt TLS 1.2 voraus. Ich würde vermuten, dass du bisher TLS 1.2 auf deinen Clients nicht aktiviert hast. Siehe dazu hier:
Gruß,
Frank
Guter Punkt. Das Fixup hatte ich zumindest schonmal laufen lassen, aber die Registry-Einträge danach nicht gegengeprüft. Prinzipiell dürfte dann aber doch gar keine Kommunikation zustande kommen, aber da weiß man ja nicht ob es für manche Requests dann evt. doch noch nen Fallback gibt. Der Exchange läuft als 2019er allerdings schon 1 Jahr. Zwischenzeitig sind die CUs bis CU9 drauf gekommen. TLS 1.2 war aber schon immer nötig oder evt. auch erst ab einem gewissen Update-Stand?
Musste ich noch schnell checken und hab im WireShark gesehen dass es TLSv1.2 Pakete sind und ein Browsertest auf https://browserleaks.com/ssl ergab dass TLSv1.2 und TLSv1.3 aktiv sind.
Ich gehe jetzt nochmal eine anderen Fährte nach. Da das Autodiscover mit dem 2019er anfangs nicht ordentlich funktionierte habe ich hier viel per GPO/Registry "unterstützt", was aber letztlich nicht richtig gut funktionierte, daher auch der Schritt zum öffentlichen Zertifikat und Split-DNS mit homogenen internal/external URLs. Also auf einem Testclient mal Outlook mit einem lokalen User eingerichtet wobei das Passwort dann gespeichert wurde und auch im Tresor liegt. Beim Start von Outlook kommt hier auch 1x "Kennwort erforderlich" und danach ist die Verbindung stabil. Beim Aufruf von OOA hängt Outlook leider, aber das prüfe ich auch gerne im Nachgang. Client raus aus der Domäne, rein, GPOs geblockt mit neuem User angemeldet und wieder das gleiche Problem...
Problem gelöst. Ich bin alle HealthChecks nochmal durchgegangen und hab beim OWA Proxy den 413 Request Entitiy Too Large entdeckt. Das hatte ich zwar alles schonmal gecheckt und gefixt, aber danach die Virtual Directories neu eingerichtet. Die Zugriffe aus der Domäne kommen im Vergleich zum lokalen User vermutlich mit Client Zertifikat und sprengen die erlaubte Anfragegröße. Also Clientzertifikate auf OWA und EWS ignoriert und nun scheints zu laufen. ?
Die Zugriffe aus der Domäne kommen im Vergleich zum lokalen User vermutlich mit Client Zertifikat und sprengen die erlaubte Anfragegröße.
Glückwunsch! Ich hatte ein ähnliches Probleme mit ActiveSync und User Zertifikaten (größere EMails mit Anhang wurden nicht versendet). In diesem Fall kannst Du auch den Parameter uploadReadAheadSize hoch setzen - MS Anleitung