This short article is intended to list the most common causes of problems with the Outlook connection to Exchange during migration. Connection problems often occur after a mailbox has been moved to a newer Exchange version. Outlook then often displays one of the following messages:
The Microsoft Exchange administrator has made a change that requires Outlook to be restarted.
This message can appear every time Outlook is started, a connection to the mailbox is then no longer possible:
The action cannot be completed. No connection to Microsoft Exchange is available. Outlook must be in the online module or connected to complete this process
This message appears when setting up new profiles; it is not possible to set up the profile:
Or simply this message from Outlook 2019:
Something didn't work out.
I would like to collect the most common causes in this article, I would be happy to receive further causes / problems by e-mail or as a comment and will then update this article.
Autodiscover and DNS
After the new Exchange servers have been installed and configured, the DNS entries for Autodiscover must point to the new Exchange servers. This often causes problems if a mailbox is moved to new Exchange servers but the Autodiscover DNS entries still point to the old servers. Here is an example that can occur when migrating from Exchange 2010 to Exchange 2016 (but also with other versions):
In this case, the HOST-A record autodiscover.frankysweblab.de points to the IP 192.168.200.14, which is the IP of the Exchange Server EX1 (red). In this case, EX2 is the Exchange Server with the newer version (blue):
The DNS entry for Autodiscover must therefore point to the new Exchange Server:
The same applies to the SRV records (if they exist):
SRV records must also point to the Exchange server with the newer version. In this example, the IP for HOST-A autodisocver.frankysweblab.de has been changed to 192.168.200.15 (IP of new Exchange Server) and the SRV record has been changed to the host autodiscover.frankysweblab.de. Autodiscover thus refers to the Exchange version to which the migration is to take place:
The external DNS entries also need to be considered here.
Outlook 2010 and MAPIoverHTTP
Outlook 2010 is still in use in many companies. With Exchange 2013, the MAPIoverHTTP protocol which replaces RPCoverHTTP. Even if RPCoverHTTP is still supported, there are usually problems with Outlook 2010 when MAPIoverHTTP is activated.
Outlook 2010 only supports MAPIoverHTTP with an update (KB2965295), this update requires Service Pack 2 for Office 2010. In order for MAPIoverHTTP to work with Outlook 2010, Service Pack 2 for Office and KB2965295 must be installed.
Here are the corresponding download links:
The updates should therefore be installed before moving the mailboxes so that Outlook 2010 can establish a connection to Exchange 2013/2016 with MAPIoverHTTP activated.
No special updates are required for Outlook 2013 and higher, but these should of course also be up to date.
Autodiscover redirects
Another problem is the autodiscover redirects of the Exchange server, which can also lead to connection problems with Outlook:
After the mailbox move is completed, Exchange Server 2013 or 2016 continues to proxy the autodiscover request to Exchange Server 2010. Exchange Server 2010 responds with a 302 redirect back to Exchange Server 2013 or 2016 (depending on the upgrade).
This problem is described in the following Microsoft article:
However, manually restarting the application pool is usually not a solution, especially if many mailboxes are moved over a longer period of time. A restart interval for the application pool can help here. A restart interval for the "MSExchangeAutodiscoverAppPool" can be defined in the IIS Manager:
With a restart interval of 5 minutes, a mailbox only remains disconnected for a maximum of 5 minutes and the application pool does not have to be restarted manually:
Once all mailboxes have been moved, this setting can be reversed.
Exchange URLs
Incorrectly configured URLs for the virtual directories in the Exchange server can also cause connection problems with Outlook. For example, typing errors in the URLs can lead to incorrect name triggering and thus disrupt the connection from Outlook to Exchange.
The configuration of the virtual directories is described here:
The host names in the URLs must be resolvable accordingly via DNS. The virtual directories can also be managed in the EAC:
The host name for Outlook Anywhere can be found here:
However, the URL for Autodiscover can only be managed via the Exchange Management Shell:
Get-ClientAccessService | fl name,autodiscover* Set-ClientAccessService -Identity EXCHANGE -AutoDiscoverServiceInternalUri "https://autodiscover.frankysweb.de/Autodiscover/Autodiscover.xml"
The URL can be adapted accordingly with the "Set-ClientAccessService" command.
Fehlermeldung „Die Aktion kann nicht abgeschlossen werden.“ kam bei uns bei der Migration von Exchange 2013 auf 2019 bei 6 von ca. 40 Clients. Alle hatten Office 2016 im Einsatz. Outlook war nicht mehr benutzbar. Der jeweilige User konnte sich an einem anderen PC mit Office 2016 anmelden und hatte dort keine Probleme. Sämtliche Lösungsansätze halfen nichts.
Mit der Umstellung von Office 2016 auf 2019 hat sich das Problem für diese User dann erledigt.
Hallo zusammen,
ich habe einen sehr interessanten Fall, der bereits mit dem Exchange 2016 existiert.
Wird der Exchange 2016 aus diversen Gründen wie Updates etc. neu gestartet und es ist ein Outlook offen, so wird das lokale Profil zerstört. Outlook quittiert den Start dann mit
„Fehler beim Anmelden. Überprüfen Sie die Netzwerkverbindung sowie den Server- und Postfachnamen. Der Microsoft Exchange-Informationsdienst Ihres Profils enthält nicht alle erforderlichen Informationen. Überprüfen Sie Ihr Profil.“
Abhilfe schafft nur, Profil löschen und neu anlegen.
Nun haben wir eine neue Maschine mit dem Exchange 2019 aufgesetzt und die Postfächer migriert. Dort besteht das Problem weiterhin. Wird der Exchange rebootet, ist das Profil im Outlook (2016/2019) kaputt.
Die Hoffnung, mit der Neuinstallation und der neueren Version das Problem zu beheben, hat sich leider nicht erfüllt.
Abweichend von der Standardkonfiguration habe ich schon den Exchange Cache Mode im Outlook deaktiviert, aber auch dies ergab keine Verbessung.
Google hat mir nicht weiter geholfen und ich hoffe hier, den entscheidenden Tipp zu bekommen.
Viele Grüße
Marco
Hallo an alle,
Wir migrieren gerade Postfächer von Exchange 2016 zu Exchange 2019.
Probleme haben wir bisher nur bei Outlook für Mac, manche der Clients benötigen eine lange Zeit (über 4 Stunden und mehrere Neustarts der Rechner) um sich endlich mit dem migrierten Postfach zu verbinden. Anderen Mac Clients genügt ein simpler Neustart vom Outlook selbst.
Dabei ist die Version von Mac oder vom Mac für Outlook nicht ausschlaggebend. Die DNS Einträge sind korrekt gesetzt und die Virtuellen Verzeichnisse sind ebenfalls korrekt.
Kennt jemand das Problem und vor allem kennt jemand die Lösung dafür?
Viele Grüße
Katrin
Hallo Franky,
ich habe 2x SRV2016 (DC) und 2x Exchange 2016 (DAG). Das funktioniert auch alles soweit. DNS haut hin, ich kann von einem Client (W10) ein Postfach per OWA öffnen und Mails versenden und Empfangen. Aber wenn ich das Outlook 2016 starte um das Postfach einzurichten, bekomme ich die Meldung das der Server nicht erreichbar ist. Wie gesagt, DNS haut hin. Autodiscover funktioniert auch. Ich denke das der Outlook Client ein Problem hat. Habe auch schon mehre Registrie Einträge ausprobiert, leider ohne Erfolg. Habt ihr noch eine Idee?
Gruß Marko
Hallo Marko,
ich habe hier gerade das selbe Problem. Wie habt ihr das damals gelöst?
Viele Grüße
Bernd
Hallo Frank,
Ich hatte gerade eine Eingebung. Da über den SBS die eigenen Dateien und AppData per Gruppenrichtlinien verschoben wurden und ich die Freigaben vom SBS entfernt hatte, konnten keine neuen Outlook-Profile angelegt werden. Ich hatte zwar die Gruppenrichtlinien am neuen DC entsprechend der neuen Gegebenheiten angepasst, aber diese wurden aus noch unerfindlichem Grund nicht übernommen. Werde ich noch untersuchen müssen. Jetzt habe ich erst mal die alten Freigaben wieder aktiviert und siehe da jetzt klappt es auch mit Outlook. somit hat sich der obige Post erledigt.
Gruß Dietmar
Hallo Frank,
bisher haben mir Deine Anleitungen gut weiter geholfen. Vielen Dank dafür.
Aber jetzt bin ich fast am Verzweifeln. Ich habe nach Deiner Anleitung Exchange von 2010 (auf SBS) nach 2019 migriert. Soweit hat mehr oder weniger alles funktioniert. Clients können via OWA auf Ihre Postfächer zureifen sowie Mails senden und empfangen. Einzig autodiscover mit Outlook fiunktioniert nicht. im DNS ist meines erachtens alles richtig eingetragen. Ich kann den Exchangeserver und autodiscover auflösen. Die Webseiten werden erreicht. Wenn ich die Autodiscover-Webseitenadresse im Browser eingebe bekomme ich auch eine xml-Datei angezeigt. Wenn ich bei den Clients ein neues Outlookprofil anlege kommt, dass keine Verbindung zum Exchange hergestellt werden kann. Bestehende Profile werden auch nicht entsprechend aktualisiert. Wenn ich den Exchangeserver bei der Profilerstellung manuell eingebe wird er trotzdem nicht gefunden, egal ob FQDN oder sonstigen auflösbaren Namen. Exchange 2019 auf Server 2019, AD auf Server 2012r2, Clients W7 und W10 mit Office 2013 sowie RDP-Server 2012 R2 mit Office 2016. Firewalls sind ausgeschalten. Ich habe schon alle möglichen (auch Deine) Lösungsansätze probiert. Aber jetzt gehen mir die Ideen aus. Vielleicht kann mir jemand auf die Sprünge helfen.
Vielen Dank im Voraus
Gruß Dietmar
Hallo Frank,
habe kürzlich die Migration von Exchange 2016 auf 2019 soweit abgeschlossen. Habe nach deiner Anleitung gearbeitet, wirklich ein super und hilfreiches Tutorial.
Jetzt bin ich an dem Punkt angelangt den alten Exch2016 zu deinstallieren, was ich mich aber noch nicht recht getraut habe. Statt dessen habe ich ihn einfach erstmal abgeschaltet. Nun taucht aber das Problem auf dass sich Outlook manchmal verbindet, manchmal nicht. (Neues Profil angelegt). Mit der Funktion „Email-Autokonfoguration testen“ konnte ich erkennen das ab und an noch der alte Server als MapiHttpPostfachspeicher angezeigt wird. Auch versucht er beim öffnen freigegebener Kalender bei manchen noch mit dem alten Server zu verbinden.
Habe ich hier noch ne Einstellung vergessen/übersehen oder muss der alte Exch2016 erst komplett deinstalliert werden?
Danke schon mal für eure Hilfe, vlt. hat jemand gerade einen Tipp parat?
Gruß Fabian
Hi Frank,
deine Seite ist einfach der Hammer. Tausend Dank. Konkret hatte ich das Problem mit dem MSExchangeAutodiscoverAppPool. Nach dem manuellen/automatisierten Neustart verbinden sich die Clients.
War auf einer Exchange-Schulung (auch mit Schwerpunkt Migration), aber das habe ich dort nicht mitgenommen.
Vielen lieben Dank!
Gruß
Alex
Hallo Frank,
vielen Dank für die Rückmeldung. Mittlerweile bin ich auch darauf gestoßen, das Stichwort lautet ms.exch.setupreadiness.NoE15ServerWarning bzw. bei der Vorbereitung des AD-Schemas:
https://docs.microsoft.com/de-de/Exchange/plan-and-deploy/deployment-ref/ms-exch-setupreadiness-noe15serverwarning?view=exchserver-2019
Beste Grüße,
Jan
Hallo,
kann man in eine Umgebung, in der bisher nur ein Exchange 2019 installiert ist, nachträglich zusätzlich einen Exchange 2013 oder 2016 installieren? Der Exchange 2019 ist der erste Exchange, der je in dieser Dömäne installiert wurde. Oder hat die Installation des Exchange 2019 irgendwelche Attribute auf einen Stand gesetzt, die die nachträgliche Installation früherer Versionen verhindert?
Hintergrund: Die zusätzliche Installation einer älteren Version wird ggf. für die Kompatibilität zu einigen PCs benötgt, die noch Outlook 2010 haben.
Beste Grüße,
Jan
Hallo Jan,
in einer Exchange 2019 Organisation lässt sich keine ältere Exchange Version mehr installieren. Outlook 2010 läuft aber auch mit Exchange 2019. Es wird zwar nicht unterstützt, aber es läuft aktuell noch. Wie lange dies so bleibt ist allerdings ungewiss.
Gruß,
Frank
Hallo Frank,
Danke für deinen Artikel, der einzige der so auf meinen Suchtreffer passte.
Ich habe selbiges Problem mit Outlook 2016 und Exchange 2013, aber nur bei einem von 700 Postfächern, das sich nicht mehr verbinden will. Alle werte und Einträge sind unverändert, aber seit ca. 2 Wochen lässt sich dieses Postfach mit einem neuem Profil nicht mehr einbinden.
Wo kann ich da ansetzen?
Beste Grüße
Micha Rombach
Hallo Michael,
bist du in der Sache weitergekommen?
Habe den ähnlichen Fall, dass ich 2 User nicht mit dem neuen Exchange verbinden kann, Credentials sind ok, aber beim Auflösen des Exchange Namens kann er ihn nicht finden. NS-Lookup sagt aber alles in Ordnung, Autodiscover & Co funktioniert bei den restlichen 70 Usern einwandfrei. Das Problem ist benutzerbezogen, anderer Rechner&Outlookversion landen beim selben Punkt, ein neues Outlookprofil für diese 2 User lassen sich nicht einrichten.
Bei uns ist mir allerdings der Ex2013 weggebrochen und ich musste ihn manuell aus der Domäne entfernen und durch einen neuen Ex2016 ersetzen. Von daher kann es hier ja noch zusätzliche Faktoren geben…
Gruß,
Thomas
Bin selbst fündig geworden…wir haben jedem Postfach die IMAP und POP Funktionalität deaktiviert.
Bei den betroffenen 2 Personen sind wir in den Zeilen verrutscht und haben die 2 falschen Optionen deaktiviert. In diesem Fall die MAPI Schnittstelle, damit konnte Outlook natürlich keine Verbindung aufbauen…
MAPI aktivert und die User konnten mit einem neuen Outlookprofil versorgt werden!
Gruß,
Thomas
Hi Frank,
vielen lieben Dank für Deinen tollen Artikel. Der Abschnitt „Autodiscover Redirects“ hat mir gestern den Tag gerettet!
Viele Grüsse
Flo
Hallo Frank,
wir haben Probleme mit Outlook 2019 und mit Vollzugriff eingebunden Postfächer.
Postfächer sind bei mehreren Benutzern mit Vollzugriff eingerichtet.
exchange 2016/exchange 2019 und outlook 2019, am server ist vollzugriff recht vergeben, Postfächer sind im Outlook
vorhanden, syncronisieren jedoch nicht korrekt.
Immer wieder ist das Postfach getrennt, dann wieder verbunden, es kommt auch ab und an eine Meldung:
Auf diese Ordner usw. kann nicht zugegriffen werden, der Administrator hat ein Limit konfiguriert oder so ähnlich.
Gibt es hier bekannte Probleme mit Outlook 2019?
LG
Sascha
Hallo Sascha,
wir haben nach einer Migration von Exchange 2010 auf 2016 das gleiche Problem.
Sobald ein Benutzer freigegebene Postfächer oder Kalender zugeordnet bekommt, treten die von Dir genannten Probleme auf. (die Outlookversion ist egal – getestet mit 2010,2013 und O365) Erkennbar im Verbindungsstatus treten viele requests und fails bei den einzelnen Verbindungen auf. Der Reconnect dauert teilweise recht lang. Unser Systemhaus hat keine Idee mehr…
Konntet Ihr das Problem lösen?
Nehme ich die freigegebenen Postfächer aus dem Benutzerprofil, so arbeitet Outlook ohne Probleme.
Grüße
Thomas
Lösung bei uns: Die Domänenbeschränkung im IIS (für den ECP-Zugriff) durfte nicht angeschaltet sein! Ohne eine solche Beschränkung lief alles gut.
Ich hatte das AppPool Thema schon vor Jahren dokumentiert, liest aber wohl keiner? Link: https://support.microsoft.com/en-us/help/3097392/outlook-logon-fails-after-mailbox-moves-from-exchange-2010-to-exchange
Der Autodiscover Cache im AppPool hat mittlerweile einen Timeout von einer Stunde.
Danke, habe ewig gesucht.
Hi Frank,
danke für den tollen Artikel! Ich war so frei und habe deinen Artikel mit meinem, ähnlich gelagerten Blog verlinkt.
Beste Grüße
Alex
https://blog.ollischer.com/microsoft-exchange-2016-migration-outlook-keeps-prompting-the-microsoft-exchange-administrator-has-made-a-change-that-requires-you-quit-and-restart-outlook
Hi Frank!
Was Kevin Schley schreibt, hatten wir auch häufig. War nur beim ersten Mal ein Problem, da wir natürlich unrund geworden sind, wie alles verschoben und richtig gestellt war und trotzdem noch nicht möglich war, mit 2016 zu arbeiten. Nach 30 Min nachdem der Batch verschoben wurde, hat dann alles funktioniert.
Danke auch Frank für den tollen Artikel.
Eine Frage habe ich dazu, weil ich lese, dass der SRV Eintrag auch umgeändert gehört: Falls ein SRV-Eintrag war mit dem alten, gehörts auf neue, verstanden. Wenn aber keiner da war und es sind die Domains
.Domain.de
owa.domain.de
autodiscover.domain.de
im Zertifikat enthalten, benötigt man keinen SRV-Eintrag.
Bisher hat ein SRV-Eintrag im Outlook nur dazu geführt, dass eine zusätzliche Meldung aufgeschienen ist, ob man der URL für die Autokonfiguration trauen soll oder sowas (mit einer Checkbox, dass die nicht mehr kommt). Aber solche Meldungen verwirren. Die gibts auch noch mit Outlook2016.
Somit meine Frage: SRV-Eintrag nur wenn einer war und nicht dennoch zusätzlich?
Möchte die Outlook-Fenster eigentlich vermeiden.
liebe Grüße aus Wien!
Hallo Mr Buabe,
wenn es bisher keinen SRV Eintrag gegeben hat, musst du ihn nicht extra anlegen. Dies ist meist auch nur für zusätzliche Domains nötig, die keinen HOST-A Eintrag besitzen und somit auch nicht als SAN auf dem Zertifikat stehen. In der Standardeinstellung fragt Outlook nach, ob die Umleitung via SRV Eintrag zugelassen werden soll. Dies ist aber eine einmalige Meldung und lässt sich auch in der Registry abschalten.
Gruß,
Frank
Hi zusammen,
Ich hatte dieses verhalten ebenfalls bereits bei diversen Exchange Migrationen.
Outlook kann keine Verbindung mehr mit dem migrierten Postfach herstellen. (DNS etc. sind alle korrekt eingerichtet)
Die Lösung in bisher jedem Fall war, nach Abschluss des Migrations Batch einfach zu warten.
Nach ca. 20 bis max 60 min kann sich Outlook wieder ganz normal verbinden.
Dieses verhalten konnte ich jetzt bei ca. 4x Exchange Migrationen 2010 -> 2016 beobachten.
Zukünftige Postfach Finalisierungen werden bei uns seither immer nach der Regulären Arbeitszeit des Kunden ausgeführt.
Einer eine Idee woran das liegt und was da genau passiert?
Grüße
Das gleiche Aktuell bei uns. Ich werde das morgen mal mit dem AppPool Neustart Intervall testen
Hallo Frank,
hat hier jemand meine Gedanken gelesen… :-)
Wir beginnen gerade die Postfächer von unserem Ex2010 auf das neue Ex2016 DAG zu ziehen. Und genau mit diesen Problem kämpfe ich gerade. Manche Postfächer brauchen ewig bis sie sich wieder per Outlook verbinden können.
Dann teste ich morgen gleich mal den AppPool Neustart und checken SRV Eintrag.
Danke
Andreas
Beim script hat sich in Zeile zwei ein copy-paste Teufel eingeschlichen.
Da steht:
Set-ClientAccessService -Identity EXCHANGE -AutoDiscoverServiceInternalUri „<a href="https://autodisc…
und so weiter. Der Teil gehört weg.
Toll wenn einem Webtools mit ihren Automatismen so schön in den Fuß schießen.
Toll hier hier hat mir das webtool ebenfall „geholfen“:
Der korrekte Satz lautet (hier mit Spaces damit es nicht werinterpretiert wird):
Der Teil mit dem weblink, also von bis muss weg.
Ich hasse diese weblink interpretationshelfer…
Hallo Joachim,
danke für den Hinweis, ich habe es korrigiert.
Gruß,
Frank