Versuch mit https://mail.firma.de.... geht auf beiden nicht, wobei ich keine Ahnung ab, wo mich der LB da hinschickt, im dümmsten Fall bin ich 2 Mal am selben Knoten.
dies kannst du ja schnell gegenprüfen von einem Client mit angepasster Host Datei. Oder du nimmst den jeweiligen Realserver auf dem Kemp offline.
Die Host Variante hat aber den Vorteil, dass diese Änderungen nur dich betreffen und nicht alle User.
Autodiscover zeigte ja bereits auf die neue Umgebung, korrekt?
Ja, sonst gäbe es ja keine Koexistenz. Alle Clientverbindungen sind auf dem neuen virtuellen Service auf dem Kemp terminiert, der die beiden Hosts hinten dran hat.
Hosts Datei ist ne Idee, versuch ich gleich mal...
Habs von dem DC aus getestet: Host1 geht nicht, Host2 geht nicht.
Konto auf dem alten DAG: geht von beiden.
puh... die High Ports zwischen den Exchange Knoten und DC's zwischen dem RZ und Netz des Kunden? Mir gehen die Ideen so langsam aus. Irgendein Wan Optimizer (Riverbed o.ä.) hängt da auch nicht zufällig mit drin? Die "optimieren gerne mal den Traffic zu doll.
ggf dann noch mit Fiddler/Wireshark püfen, wer bei einem 403 Aufruf mit involviert ist (welcher DC).
Ggf den DC für die DAG Knoten "festzurren" auf den, der im RZ steht.
Der DC passt. Das sollte eigentlich der Standort im AD regeln.
Fiddler hab ich mir mal angeschaut, kann ich nix wirklich sehen, aber ich kenn das Programm auch nicht wirklich.
TCPDumps würde ich lieber nen Netzi machen lassen, aber irgendwann wird uns nix anderes übrigbleiben.
hast du denn die Option, einen weiteren (Single) EX2016 Server auszurollen, welcher nicht im RZ steht? Dann kannst du eins der Postfächer dorthin migrieren und prüfen, ob's am Standort liegt.
Ist mit Kanonen auf Spatzen, ich weiß. Ausser Debugging des (SSL) Traffics oder Ticket bei M$ würde mir da nicht mehr viel einfallen, ist ja eh alles Ferndiagnose. Vielleicht weiß NorbertFE mehr.
Gruß,
Ralf
Nein, leider keine Idee, ich nutze die Funktion allerdings auch nicht. Ticket bei MS halte ich für wenig zielführend bei dem Problem. Es sei denn, man steht auf "Viele Logfiles" und viel "indisches Englisch". :)
Nein, leider keine Idee, ich nutze die Funktion allerdings auch nicht. Ticket bei MS halte ich für wenig zielführend bei dem Problem. Es sei denn, man steht auf "Viele Logfiles" und viel "indisches Englisch". :)
leider wahr... für eine schnelle Lösung braucht man schon Minimum ein Premier Support Case, sonst kann das auch mal Monate dauern.
Wir sind SPLA Partner und ich habe es noch nicht geschafft mich auf den Support Seiten von MS dahingehend vorzuarbeiten, dass ich überhaupt mal einen Supportcase eröffnen könnte...
aber wenn es "nur" an der bsp Möglichkeit scheitert, AR für die Benutzer zu ändern, wäre es ja fast günstiger, dies mit einem Drittanbietertool zu tun (bsp CodeTwo Exchange Rules/Pro o.ä.)
Hallo,
wir hatten das Problem auch. Nachdem wir eben den Mai 2022 SU für 2016 CU22 mit nachgelagerten PrepareAllDomains installiert haben, war der Fehler nun weg.
Viele Grüße
Stefan Ulbrich
wir hatten das Problem auch. Nachdem wir eben den Mai 2022 SU für 2016 CU22 mit nachgelagerten PrepareAllDomains installiert haben, war der Fehler nun weg.
guter Hinweis. /PrepareDomain + /preparealldomains zieht unter anderem einiges an fehlenden/korrupten Berechtigungen grade.
Musste ich beim aktuellen CU12 für EX2019 auch auf dem PDC machen, da sonst in unserer Umgebung die Installation "gebockt" hat.
Gruß,
Ralf