Dieser kleine Artikel soll die häufigsten Ursachen für Probleme mit der Outlook Verbindung mit Exchange während der Migration auflisten. Häufig kommt es zu Verbindungsproblemen nachdem ein Postfach auf eine neuere Exchange Version verschoben wurde. Outlook bringt dann gerne eine der folgenden Meldungen:
Der Microsoft Exchange-Administrator hat eine Änderung durchgeführt, die einen Neustart von Outlook erfordert.
Diese Meldung kann hei jedem Outlook Start auftreten, eine Verbindung zum Postfach ist dann nicht mehr möglich:
Die Aktion kann nicht abgeschlossen werden. Es steht keine Verbindung mit Microsoft Exchange zur Verfügung. Outlook muss im Onlinemoduls oder verbunden sein, um diesen Vorgang abzuschließen
Diese Meldung tritt beim Einrichten neuer Profile auf, das Einrichten des Profils ist nicht möglich:
Oder auch einfach diese Meldung von Outlook 2019:
Da hat etwas nicht geklappt.
Ich würde in diesem Artikel gerne die häufigsten Ursachen sammeln, gerne nehme ich weitere Ursachen / Probleme per Mail oder als Kommentar entgegen und werde diesen Artikel dann aktualisieren.
Autodiscover und DNS
Nachdem die neuen Exchange Server installiert und konfiguriert wurden, müssen die DNS-Einträge für Autodiscover auf die neuen Exchange Server verweisen. Hier kommt es oft zu Problemen, wenn ein Postfach zu neuen Exchange Servern verschoben wird, die Autodiscover DNS Einträge aber noch auf die alten Server verweisen. Hier ein Beispiel, welches bei der Migration von Exchange 2010 zu Exchange 2016 auftreten kann (aber auch bei anderen Versionen):
In diesem Fall zeigt der HOST-A Record autodiscover.frankysweblab.de auf die IP 192.168.200.14, welches die IP des Exchange Servers EX1 ist (rot). In diesem Fall ist EX2 der Exchange Server mit der neueren Version (blau):
Der DNS-Eintrag für Autodiscover muss hier also auf den neuen Exchange Server verweisen:
Gleiches gilt auch für die SRV-Records (wenn existent):
Auch SRV-Records müssen auf den Exchange Server mit der neueren Version zeigen. In diesem Beispiel wurde also die IP für den HOST-A autodisocver.frankysweblab.de auf 192.168.200.15 (IP neuer Exchange Server) und der SRV-Record auf den Host autodiscover.frankysweblab.de geändert. Somit verweist Autodiscover auf die Exchange Version zu der migriert werden soll:
Hier gilt es auch an die externen DNS Einträge zu denken.
Outlook 2010 und MAPIoverHTTP
In vielen Unternehmen ist noch Outlook 2010 im Einsatz. Mit Exchange 2013 wurde das Protokoll MAPIoverHTTP eingeführt welches RPCoverHTTP ersetzt. Auch wenn RPCoverHTTP noch unterstützt wird, gibt es mit aktivierten MAPIoverHTTP meistens Probleme mit Outlook 2010.
Outlook 2010 unterstützt MAPIoverHTTP erst mit einem Update (KB2965295), dieses Update erfordert das Service Pack 2 für Office 2010. Damit MAPIoverHTTP mit Outlook 2010 funktioniert, muss also das Service Pack 2 für Office und das KB2965295 installiert sein.
Hier einmal die entsprechenden Download Links:
Die Updates sollten also vor dem Verschieben der Postfächer installiert werden, damit Outlook 2010 eine Verbindung zu Exchange 2013/2016 mit aktivierten MAPIoverHTTP herstellen kann.
Für Outlook 2013 und höher sind keine speziellen Updates nötig, jedoch sollten diese natürlich auch auf einem aktuellen Stand sein.
Autodiscover Redirects
Ein weiteres Problem sind die Autodiscover Redirects der Exchange Server, auch hier kann es zu Verbindungsproblemen mit Outlook kommen:
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).
Dieses Problem ist in dem folgenden Microsoft Artikel beschrieben:
Das manuelle Neustarten des Application Pools ist aber meist keine Lösung, gerade wenn viele Postfächer über einen längeren Zeitraum verschoben werden. Hier kann man sich mit einem Neustartintervall des Application Pools behelfen. Im IIS-Manager lässt sich ein Neustartintervall für den “MSExchangeAutodiscoverAppPool” festlegen:
Mit einem Neustart Intervall von 5 Minuten, bleibt ein Postfach also nur maximal 5 Minuten getrennt und es muss kein manueller Neustart des Application Pools durchgeführt werden:
Nachdem alle Postfächer verschoben wurden, kann diese Einstellung wieder rückgängig gemacht werden.
Exchange URLs
Auch falsch konfigurierte URLs für die virtuellen Verzeichnisse im des Exchange Servers können Verbindungsprobleme mit Outlook verursachen. Beispielsweise können Tippfehler in den URLs zu einer fehlerhaften Namensauslösung führen und damit die Verbindung von Outlook zu Exchange stören.
Die Konfiguration der virtuellen Verzeichnisse ist hier beschrieben:
Die Hostnamen in den URLs müssen via DNS entsprechend auflösbar sein. Die Virtuellen Verzeichnisse können auch in der EAC verwaltet werden:
Der Hostname für Outlook Anywhere findet sich hier:
Die URL für Autodiscover kann allerdings nur über die Exchange Management Shell verwaltet werden:
Get-ClientAccessService | fl name,autodiscover* Set-ClientAccessService -Identity EXCHANGE -AutoDiscoverServiceInternalUri "https://autodiscover.frankysweb.de/Autodiscover/Autodiscover.xml"
Mit dem Befehl “Set-ClientAccessService” lässt sich die URL entsprechend anpassen.
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