Ich hatte bei einem Kunden einen kuriosen Fall: Outlook 365 (also Outlook 2019) mit Exchange 2016. Alle Mailboxen wurden erst gerate von Exchange 2010 auf diesen Exchange migriert. Alle Benutzer konnten verbinden. Alle? Nein, ein einziger Benutzer konnte keine Verbindung herstellen.
Die Outlook-Verbindungsstatus (bei gedrückter Ctrl-Taste mit rechter Maustaste auf das Outlook-Tray-Symbol klicken > Verbindungsstatus) zeigte an, dass Outlook noch auf den alten Exchange-Server verbinden will. Wenn ich die Mailbox auf den alten Server zurückverschoben habe, klappte die Verbindung.
Sämtliche Recherchen zu autodiscover, SCP, etc. zeigten keine Fehler.
Schlussendlich entdeckte ich diesen Technet-Forum-Thread:
https://social.technet.microsoft.com/Forums/en-US/3eb2fdcc-6ca5-404e-89df-ee9ccd0fc7f1/resolved-exchange-2016-bug-outlook-not-connecting-to-exchange-after-mailbox-move-from-2010-to
Dieser beginnt im Januar 2016, und reicht bis zum Juli 2019!! Die Benutzer beklagen sich dort – zu recht – dass dieser Bug weiterhin besteht!
Ich konnte es kaum glauben, gab dem einfachen und schnell ausgeführten Lösungsansatz eine Chance:
Starte IIS auf dem Exchange
navigiere zu den AppPools und starte den AppPool «MSExchangeAutodiscoverAppPool» neu.
Voila – Outlook dieses eines Benutzers konnte sich wieder verbinden.
Hier die offizielle KB:
https://support.microsoft.com/en-us/help/3097392/outlook-logon-fails-after-mailbox-moves-from-exchange-2010-to-exchange
In der offiziellen KB wird ganz kurz darauf hingedeutet, wie das Problem verifiziert werden kann. Hier etwas ausführlicher:
Im Verzeichnis «C:\Program Files\Microsoft\Exchange Server\V15\Logging\HttpProxy\Autodiscover» wird pro Stunde ein Logfile abgelegt. In diesen Logfiles ist der falsche Aufruf sichtbar:
2019-07-30T09:37:34.670Z,56b631f7-80d0-4e75-bd01-6d574f1b7efe,15,1,1713,5,CDE3D74E-55AB-4DAE-AF9B-D136C3F50A6E,Autodiscover,autodiscover.DOMAIN.ch,/autodiscover/autodiscover.json,,,false,,DOMAIN.ch,Smtp~Vorname.Nachname@DOMAIN.ch,Microsoft Office/16.0 (Windows NT 6.2; MAPI 16.0.10730; Pro),10.62.10.130,EXCHANGE2016,404,404,,GET,Proxy,EXCHANGE2010.DOMAIN.local,14.03.0123.000,IntraForest,ExplicitLogon-SMTP,,,,0,105,,,0,4,,0,3;,3,,0,3,,0,14,0,,,,5,0,0,0,1,0,14,0,7,9,9,9,14,,?Email=Vorname.Nachname%40DOMAIN.ch&Protocol=Autodiscoverv1&RedirectCount=1,,BeginRequest=2019-07-30T09:37:34.655Z;CorrelationID=;ProxyState-Run=None;AccountForestGuard_DOMAIN.local=1;ServerLocatorRefresh=08ef57ef-6740-4956-bea2-5aed6d10195b;RefreshingCacheEntry=CacheEntry(BackEndServer EXCHANGE2010.DOMAIN.local ~1937997947|ResourceForest DOMAIN.local|FailoverSequenceNumber 0|LastRefreshTime 29.07.2019 10:56:58);DownLevelTargetRandomHashing=0/1;ClientAccessServer= EXCHANGE2010.DOMAIN.local ;ResolveCasLatency=0;FEAuth=BEVersion-1937997947;ProxyToDownLevel=True;RoutingEntry=DatabaseGuid:08ef57ef-6740-4956-bea2-5aed6d10195b%40DOMAIN.local%40DOMAIN.local Server: EXCHANGE2010.DOMAIN.local +1937997947@0;BeginGetResponse=2019-07-30T09:37:34.663Z;OnResponseReady=2019-07-30T09:37:34.668Z;EndGetResponse=2019-07-30T09:37:34.668Z;ProxyState-Complete=ProxyResponseData;SharedCacheGuard=0;EndRequest=2019-07-30T09:37:34.670Z;S:ServiceLatencyMetadata.AuthModuleLatency=0;I32:ATE.C[ADSERVER.DOMAIN.local]=1;F:ATE.AL[ADSERVER.DOMAIN.local]=0;I32:ADS.C[ADSERVER]=1;F:ADS.AL[ADSERVER]=1.8065,WebExceptionStatus=ProtocolError;ResponseStatusCode=404;WebException=System.Net.WebException: Der Remoteserver hat einen Fehler zurückgegeben: (404) Nicht gefunden. bei System.Net.HttpWebRequest.EndGetResponse(IAsyncResult asyncResult) bei Microsoft.Exchange.HttpProxy.ProxyRequestHandler.<>c__DisplayClass198_0.b__0();,,|RoutingDB:08ef57ef-6740-4956-bea2-5aed6d10195b,,,CafeV1