8
Exchange 2019 - keine public folders nach Migration
Mahlzeit,
wir haben unsere Exchange Migration nach sehr vielen sehr intensiven Tests gestartet und leider finden einen die Probleme dann doch wieder... nur das wir jetzt live sind und das ganz gerne endlich fertig hätten.
exchangealt Exchange 2013 on premise
exchangeneu Exchange 2019 on premise
Client Outlook 2013 auf Windows 2012 R2 als RD-Session Host
DNS
mail.domain.de
autodiscover.domain.de
zeigt alles mittlerweile auf exchangeneu. Outlook-Profile wurden im Nachgang bei den Benutzern neu eingerichtet (vorher hat sich Outlook aufgehängt).
in Outlook:
Die Benutzer können Outlook starten, unabhängig davon ob sich ihr Postfach auf exchangealt oder exchangeneu befindet. E-Mail läuft so weit, allerdings sieht kein Benutzer in Outlook die öffentlichen Ordner. Wir haben das entsprechende Postfach für die öffentlichen Ordner zwischenzeitlich auf exchangeneu migriert, das hat nichts geändert. Auch ein neu angelegter Test-Benutzer sieht keine öffentlichen Ordner in Outlook.
in OWA:
OWA läuft für Benutzer auf dem exchangealt auch nur gegen eine URL vom exchangealt, hier eingeloggt sehen sie aber auch die öffentlichen Ordner in der DB von exchangeneu. Alte Benutzer, die bereits migriert wurden, können OWA mit exchangeneu bzw. mail.domain.de machen und auch hier sind die öffentlichen Ordner da.
Es ist nicht ganz klar ob das bei einem der vielen Tests schon mal funktioniert hat, beim letzten Test von dem ich noch virtuelle Maschinen habe gab es das Problem wohl auch nur ist das nicht aufgefallen.
Im Internet scheint es das Problem des öfteren mal zu geben aber meist in Verbindung mit Exchange 365.
wir haben unsere Exchange Migration nach sehr vielen sehr intensiven Tests gestartet und leider finden einen die Probleme dann doch wieder... nur das wir jetzt live sind und das ganz gerne endlich fertig hätten.
exchangealt Exchange 2013 on premise
exchangeneu Exchange 2019 on premise
Client Outlook 2013 auf Windows 2012 R2 als RD-Session Host
DNS
mail.domain.de
autodiscover.domain.de
zeigt alles mittlerweile auf exchangeneu. Outlook-Profile wurden im Nachgang bei den Benutzern neu eingerichtet (vorher hat sich Outlook aufgehängt).
in Outlook:
Die Benutzer können Outlook starten, unabhängig davon ob sich ihr Postfach auf exchangealt oder exchangeneu befindet. E-Mail läuft so weit, allerdings sieht kein Benutzer in Outlook die öffentlichen Ordner. Wir haben das entsprechende Postfach für die öffentlichen Ordner zwischenzeitlich auf exchangeneu migriert, das hat nichts geändert. Auch ein neu angelegter Test-Benutzer sieht keine öffentlichen Ordner in Outlook.
in OWA:
OWA läuft für Benutzer auf dem exchangealt auch nur gegen eine URL vom exchangealt, hier eingeloggt sehen sie aber auch die öffentlichen Ordner in der DB von exchangeneu. Alte Benutzer, die bereits migriert wurden, können OWA mit exchangeneu bzw. mail.domain.de machen und auch hier sind die öffentlichen Ordner da.
Es ist nicht ganz klar ob das bei einem der vielen Tests schon mal funktioniert hat, beim letzten Test von dem ich noch virtuelle Maschinen habe gab es das Problem wohl auch nur ist das nicht aufgefallen.
Im Internet scheint es das Problem des öfteren mal zu geben aber meist in Verbindung mit Exchange 365.
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 7289487437
Url: https://administrator.de/contentid/7289487437
Printed on: April 28, 2024 at 01:04 o'clock
8 Comments
Latest comment
Moin...
DNS
mail.domain.de
autodiscover.domain.de
zeigt alles mittlerweile auf exchangeneu. Outlook-Profile wurden im Nachgang bei den Benutzern neu eingerichtet (vorher hat sich Outlook aufgehängt).
dns zeigt wo Hin?
in Outlook:
Die Benutzer können Outlook starten, unabhängig davon ob sich ihr Postfach auf exchangealt oder exchangeneu befindet. E-Mail läuft so weit, allerdings sieht kein Benutzer in Outlook die öffentlichen Ordner. Wir haben das entsprechende Postfach für die öffentlichen Ordner zwischenzeitlich auf exchangeneu migriert, das hat nichts geändert. Auch ein neu angelegter Test-Benutzer sieht keine öffentlichen Ordner in Outlook.
in OWA:
OWA läuft für Benutzer auf dem exchangealt auch nur gegen eine URL vom exchangealt, hier eingeloggt sehen sie aber auch die öffentlichen Ordner in der DB von exchangeneu. Alte Benutzer, die bereits migriert wurden, können OWA mit exchangeneu bzw. mail.domain.de machen und auch hier sind die öffentlichen Ordner da.
Es ist nicht ganz klar ob das bei einem der vielen Tests schon mal funktioniert hat, beim letzten Test von dem ich noch virtuelle Maschinen habe gab es das Problem wohl auch nur ist das nicht aufgefallen.
Im Internet scheint es das Problem des öfteren mal zu geben aber meist in Verbindung mit Exchange 365.
zu 99% ein Autodiscover-Problem, das habe ich mit office2013 öfter.
Lösung:
http://support.microsoft.com/kb/2788136
https://www.behnsen.net/exchange-2013-oeffentliche-ordner-werden-in-outl ...
das sollte so helfen...
Frank
Zitat von @ukulele-7:
Mahlzeit,
wir haben unsere Exchange Migration nach sehr vielen sehr intensiven Tests gestartet und leider finden einen die Probleme dann doch wieder... nur das wir jetzt live sind und das ganz gerne endlich fertig hätten.
exchangealt Exchange 2013 on premise
exchangeneu Exchange 2019 on premise
Client Outlook 2013 auf Windows 2012 R2 als RD-Session Host
hm...Mahlzeit,
wir haben unsere Exchange Migration nach sehr vielen sehr intensiven Tests gestartet und leider finden einen die Probleme dann doch wieder... nur das wir jetzt live sind und das ganz gerne endlich fertig hätten.
exchangealt Exchange 2013 on premise
exchangeneu Exchange 2019 on premise
Client Outlook 2013 auf Windows 2012 R2 als RD-Session Host
DNS
mail.domain.de
autodiscover.domain.de
zeigt alles mittlerweile auf exchangeneu. Outlook-Profile wurden im Nachgang bei den Benutzern neu eingerichtet (vorher hat sich Outlook aufgehängt).
in Outlook:
Die Benutzer können Outlook starten, unabhängig davon ob sich ihr Postfach auf exchangealt oder exchangeneu befindet. E-Mail läuft so weit, allerdings sieht kein Benutzer in Outlook die öffentlichen Ordner. Wir haben das entsprechende Postfach für die öffentlichen Ordner zwischenzeitlich auf exchangeneu migriert, das hat nichts geändert. Auch ein neu angelegter Test-Benutzer sieht keine öffentlichen Ordner in Outlook.
in OWA:
OWA läuft für Benutzer auf dem exchangealt auch nur gegen eine URL vom exchangealt, hier eingeloggt sehen sie aber auch die öffentlichen Ordner in der DB von exchangeneu. Alte Benutzer, die bereits migriert wurden, können OWA mit exchangeneu bzw. mail.domain.de machen und auch hier sind die öffentlichen Ordner da.
Es ist nicht ganz klar ob das bei einem der vielen Tests schon mal funktioniert hat, beim letzten Test von dem ich noch virtuelle Maschinen habe gab es das Problem wohl auch nur ist das nicht aufgefallen.
Im Internet scheint es das Problem des öfteren mal zu geben aber meist in Verbindung mit Exchange 365.
Lösung:
http://support.microsoft.com/kb/2788136
https://www.behnsen.net/exchange-2013-oeffentliche-ordner-werden-in-outl ...
das sollte so helfen...
Frank
Ergänzung:
Ein Problem habe ich vergessen zu erwähnen: Outlook versucht bei der Profileinrichtung und später im Betrieb auf "etwas" zuzugreifen, möglicherweise die öffentlichen Ordner. Es erscheint ein Anmeldefenster, Anmeldung funktioniert nicht dann erscheint es wieder. Klickt man es weg läuft alles andere erstmal.
Der Abwesenheitsassistent in Outlook funktioniert auch nicht.
@Frank:
Die Seite habe ich auch schon gefunden, das aber erstmal abgetan weil die Domain sich nicht geändert hat. Allerdings ist das natürlich nicht ganz richtig, als wir uns erstmalig ein Zertifikat für Exchange zugelegt haben hat sich in der ganzen Umgebung die "SMTP-Domain" von intern.domain.de auf domain.de geändert. Zum Zeitpunkt der Ersteinrichtung der public folders war es also intern.domain.de und das wird DNS-seitig gar nicht aufgelöst mit autodiscover.intern.domain.de , eventuell liegt hier irgendwo die Ursache.
Ich habe jetzt noch eine andere Spur: Die URL
https://autodiscover.domain.de/autodiscover/autodiscover.xml
müsste mir doch eigentlich eine XML anzeigen, tut sie aber nicht (weder auf exchangealt noch exchangeneu). Es kommt auch hier ein Anmeldedialog an dem sich kein Benutzer oder Admin anmelden kann. Es könnte auch noch ein Authentifizierungsproblem geben...
Ein Problem habe ich vergessen zu erwähnen: Outlook versucht bei der Profileinrichtung und später im Betrieb auf "etwas" zuzugreifen, möglicherweise die öffentlichen Ordner. Es erscheint ein Anmeldefenster, Anmeldung funktioniert nicht dann erscheint es wieder. Klickt man es weg läuft alles andere erstmal.
Der Abwesenheitsassistent in Outlook funktioniert auch nicht.
@Frank:
Die Seite habe ich auch schon gefunden, das aber erstmal abgetan weil die Domain sich nicht geändert hat. Allerdings ist das natürlich nicht ganz richtig, als wir uns erstmalig ein Zertifikat für Exchange zugelegt haben hat sich in der ganzen Umgebung die "SMTP-Domain" von intern.domain.de auf domain.de geändert. Zum Zeitpunkt der Ersteinrichtung der public folders war es also intern.domain.de und das wird DNS-seitig gar nicht aufgelöst mit autodiscover.intern.domain.de , eventuell liegt hier irgendwo die Ursache.
Ich habe jetzt noch eine andere Spur: Die URL
https://autodiscover.domain.de/autodiscover/autodiscover.xml
müsste mir doch eigentlich eine XML anzeigen, tut sie aber nicht (weder auf exchangealt noch exchangeneu). Es kommt auch hier ein Anmeldedialog an dem sich kein Benutzer oder Admin anmelden kann. Es könnte auch noch ein Authentifizierungsproblem geben...
Outlook 2019 geht gar nicht.
Der exchangealt lief mal als AD split permission, dabei kam es zu Problemen die Microsoft dann nach Tagen gefixt hat, irgendwie. exchangealt wurde von mir vor der ganzen Umstellung bewusst mit Setup wieder auf nicht split permissons zurück geführt. In der Testumgebung lief dann alles, da kam keine Authentifizierungs-Aufforderung.
Vielleicht sind public folders nur ein Symptom.
Der exchangealt lief mal als AD split permission, dabei kam es zu Problemen die Microsoft dann nach Tagen gefixt hat, irgendwie. exchangealt wurde von mir vor der ganzen Umstellung bewusst mit Setup wieder auf nicht split permissons zurück geführt. In der Testumgebung lief dann alles, da kam keine Authentifizierungs-Aufforderung.
Vielleicht sind public folders nur ein Symptom.
Eventuell kann mir jemand mal sagen was beim Aufruf von
1)
Get-ClientAccessServer | fl AutodiscoverServiceInternalUri
kommt und was beim Aufruf von
2)
https://autodiscover.domain.de/autodiscover/autodiscover.xml
im Browser kommt.
Bei mir kommt
1)
AutoDiscoverServiceInteralUri : https://autodiscover.domain.de/Autodiscover/Autodiscover.xml
AutoDiscoverServiceInteralUri : https://autodiscover.domain.de/Autodiscover/Autodiscover.xml
(wirklich 2x, vermutlich einmal von exchangealt und exchangeneu)
2)
Authentifizierungsmaske
1)
Get-ClientAccessServer | fl AutodiscoverServiceInternalUri
kommt und was beim Aufruf von
2)
https://autodiscover.domain.de/autodiscover/autodiscover.xml
im Browser kommt.
Bei mir kommt
1)
AutoDiscoverServiceInteralUri : https://autodiscover.domain.de/Autodiscover/Autodiscover.xml
AutoDiscoverServiceInteralUri : https://autodiscover.domain.de/Autodiscover/Autodiscover.xml
(wirklich 2x, vermutlich einmal von exchangealt und exchangeneu)
2)
Authentifizierungsmaske
Zitat von @ukulele-7:
Ergänzung:
Ein Problem habe ich vergessen zu erwähnen: Outlook versucht bei der Profileinrichtung und später im Betrieb auf "etwas" zuzugreifen, möglicherweise die öffentlichen Ordner. Es erscheint ein Anmeldefenster, Anmeldung funktioniert nicht dann erscheint es wieder. Klickt man es weg läuft alles andere erstmal.
Der Abwesenheitsassistent in Outlook funktioniert auch nicht.
ich bleibe beim autodiscover Problem Ergänzung:
Ein Problem habe ich vergessen zu erwähnen: Outlook versucht bei der Profileinrichtung und später im Betrieb auf "etwas" zuzugreifen, möglicherweise die öffentlichen Ordner. Es erscheint ein Anmeldefenster, Anmeldung funktioniert nicht dann erscheint es wieder. Klickt man es weg läuft alles andere erstmal.
Der Abwesenheitsassistent in Outlook funktioniert auch nicht.
@Frank:
Die Seite habe ich auch schon gefunden, das aber erstmal abgetan weil die Domain sich nicht geändert hat. Allerdings ist das natürlich nicht ganz richtig, als wir uns erstmalig ein Zertifikat für Exchange zugelegt haben hat sich in der ganzen Umgebung die "SMTP-Domain" von intern.domain.de auf domain.de geändert. Zum Zeitpunkt der Ersteinrichtung der public folders war es also intern.domain.de und das wird DNS-seitig gar nicht aufgelöst mit autodiscover.intern.domain.de , eventuell liegt hier irgendwo die Ursache.
Ich habe jetzt noch eine andere Spur: Die URL
https://autodiscover.domain.de/autodiscover/autodiscover.xml
ErrorCode>600</ErrorCode>müsste mir doch eigentlich eine XML anzeigen, tut sie aber nicht (weder auf exchangealt noch exchangeneu). Es kommt auch hier ein Anmeldedialog an dem sich kein Benutzer oder Admin anmelden kann. Es könnte auch noch ein Authentifizierungsproblem geben...
Moin...
kommt und was beim Aufruf von
2)
https://autodiscover.domain.de/autodiscover/autodiscover.xml
im Browser kommt.
Bei mir kommt
1)
AutoDiscoverServiceInteralUri : https://autodiscover.domain.de/Autodiscover/Autodiscover.xml
AutoDiscoverServiceInteralUri : https://autodiscover.domain.de/Autodiscover/Autodiscover.xml
(wirklich 2x, vermutlich einmal von exchangealt und exchangeneu)
ist ja auch richtig!
2)
Authentifizierungsmaske
Frank
Zitat von @ukulele-7:
Eventuell kann mir jemand mal sagen was beim Aufruf von
1)
Get-ClientAccessServer | fl AutodiscoverServiceInternalUri
Eventuell kann mir jemand mal sagen was beim Aufruf von
1)
Get-ClientAccessServer | fl AutodiscoverServiceInternalUri
WARNUNG: Das Cmdlet "Get-ClientAccessServer" wird in einer künftigen Version von Exchange entfernt. Verwenden Sie
stattdessen das Cmdlet "Get-ClientAccessService". Wenn in Skripts das Cmdlet "Get-ClientAccessServer" verwendet wird,
aktualisieren Sie die Skripts, sodass sie das Cmdlet "Get-ClientAccessService" verwenden. Weitere Informationen finden
Sie unter "http://go.microsoft.com/fwlink/p/?LinkId=254711".
AutoDiscoverServiceInternalUri : https://autodiscover.test.de/Autodiscover/Autodiscover.xml
AutoDiscoverServiceInternalUri : https://autodiscover.test.de/Autodiscover/Autodiscover.xmlkommt und was beim Aufruf von
2)
https://autodiscover.domain.de/autodiscover/autodiscover.xml
im Browser kommt.
Bei mir kommt
1)
AutoDiscoverServiceInteralUri : https://autodiscover.domain.de/Autodiscover/Autodiscover.xml
AutoDiscoverServiceInteralUri : https://autodiscover.domain.de/Autodiscover/Autodiscover.xml
(wirklich 2x, vermutlich einmal von exchangealt und exchangeneu)
2)
Authentifizierungsmaske
Frank
Zitat von @ukulele-7:
Ergänzung:
Ein Problem habe ich vergessen zu erwähnen: Outlook versucht bei der Profileinrichtung und später im Betrieb auf "etwas" zuzugreifen, möglicherweise die öffentlichen Ordner. Es erscheint ein Anmeldefenster, Anmeldung funktioniert nicht dann erscheint es wieder. Klickt man es weg läuft alles andere erstmal.
Der Abwesenheitsassistent in Outlook funktioniert auch nicht.
@Frank:
Die Seite habe ich auch schon gefunden, das aber erstmal abgetan weil die Domain sich nicht geändert hat. Allerdings ist das natürlich nicht ganz richtig, als wir uns erstmalig ein Zertifikat für Exchange zugelegt haben hat sich in der ganzen Umgebung die "SMTP-Domain" von intern.domain.de auf domain.de geändert. Zum Zeitpunkt der Ersteinrichtung der public folders war es also intern.domain.de und das wird DNS-seitig gar nicht aufgelöst mit autodiscover.intern.domain.de , eventuell liegt hier irgendwo die Ursache.
da liegt wohl der Hase im Pfeffer... erstele doch mal nen dns record autodiscover.intern.domain.de zum Test!Ergänzung:
Ein Problem habe ich vergessen zu erwähnen: Outlook versucht bei der Profileinrichtung und später im Betrieb auf "etwas" zuzugreifen, möglicherweise die öffentlichen Ordner. Es erscheint ein Anmeldefenster, Anmeldung funktioniert nicht dann erscheint es wieder. Klickt man es weg läuft alles andere erstmal.
Der Abwesenheitsassistent in Outlook funktioniert auch nicht.
@Frank:
Die Seite habe ich auch schon gefunden, das aber erstmal abgetan weil die Domain sich nicht geändert hat. Allerdings ist das natürlich nicht ganz richtig, als wir uns erstmalig ein Zertifikat für Exchange zugelegt haben hat sich in der ganzen Umgebung die "SMTP-Domain" von intern.domain.de auf domain.de geändert. Zum Zeitpunkt der Ersteinrichtung der public folders war es also intern.domain.de und das wird DNS-seitig gar nicht aufgelöst mit autodiscover.intern.domain.de , eventuell liegt hier irgendwo die Ursache.
ich weiß echt nicht, warum ihr immer interne und externe url unterschiedlich macht...
Ich habe jetzt noch eine andere Spur: Die URL
https://autodiscover.domain.de/autodiscover/autodiscover.xml
müsste mir doch eigentlich eine XML anzeigen, tut sie aber nicht (weder auf exchangealt noch exchangeneu). Es kommt auch hier ein Anmeldedialog an dem sich kein Benutzer oder Admin anmelden kann. Es könnte auch noch ein Authentifizierungsproblem geben...
Frank
1Zitat von @Vision2015:
da liegt wohl der Hase im Pfeffer... erstele doch mal nen dns record autodiscover.intern.domain.de zum Test!
ich weiß echt nicht, warum ihr immer interne und externe url unterschiedlich macht...
Also früher war das so (als der exchangealt an den Start ging und die public folder mailbox somit erzeugt wurde). Seit nunmehr mindestens 5 Jahren ist extern wie intern immer mail.domain.de bzw. autodiscover.domain.de für als Exchange Server Adresse eingerichtet.da liegt wohl der Hase im Pfeffer... erstele doch mal nen dns record autodiscover.intern.domain.de zum Test!
ich weiß echt nicht, warum ihr immer interne und externe url unterschiedlich macht...
Zur Sicherheit habe ich jetzt autodiscover.intern.domain.de ergänzt. Im Anschluss hat sich aber das Verhalten erstmal nicht wirklich geändert, zumindest nicht sofort nach flushdns und mit neuem E-Mail Konto.
DNS sieht intern wie folgt aus:
mail.domain.de
autodiscover.domain.de
(öffentliche Domain in unserem Besitz, wurde erst später frei und nutze ich für alles technische um es kurz zu halten)
mail.intern.domain.de
autodiscover.intern.domain.de
exchangeneu.intern.domain.de
(Windows Domain)
mail.mail-domain.de
autodiscover.mail-domain.de
(E-Mail-Adressen, Webseite)
=> zeigt alles auf IPv4 von exchangeneu
Im Anschluss habe ich weiter gesucht nach Dingen die Outlook beeinflussen. Weil ich auch alte und neue OUs vorbereitet habe und sich mein eigenes normales Benutzerkonto anders als andere normale Benutzerkonten verhält habe ich allerhand probiert, testweise ein neue Windows Profil angelegt etc. Autodisover meint jetzt keinen Exchange Server mehr zu kennen:
Um meiner Verwirrung Herr zu werden habe ich Internet Explorer/Windows und Edge Proxy-Einstellungen deaktiviert und nun bekomme ich eine neue Sicherheitswarnung für autodiscover.mail-domain.de !
Was auch logisch ist weil das ist nicht das autodiscover was ich benutzen möchte und was im Zertifikat steht das wäre autodiscover.domain.de aber da meine E-Mail Adresse eben @mail-domain.de ist kann ich ihn da im Moment nicht von abbringen.
Ich gehe mal schlafen...
