NorbertFe

So gesehen stimmt dann deine Pauschalisierung natürlich :)

Tjo, was soll man dazu sagen ;) Generell sollten Pauschalisierungen vermieden werden. ;) Aktuell gibts schließlich immer noch die Exchange Edge Rolle ;)

In deinem Sendconnector, was steht da im Feld HELO String? Taucht dieser Name auch in deinem TLS Zertifikat für SMTP auf? Da sollte nicht nichts drin stehen, wenn dein Host nicht zufälligerweise intern wie extern identisch heißen sollte (was sehr unwahrscheinlich ist).

Schau mal ins Logfile des Sendeconnectors. Da sollten ja ggf. einige Infos drin stehen. In der Queue sollten die Mails auch eine Weile mit Fehlermeldung stehen. Es kann sein, dass dich diese Empfänger einfach blocken, weil deine IP (mit der du ja erst seit kurzem direkt sendest) auf irgendwelchen Blocklists usw. stehen. Im Zweifel musst du den Empfänger-Admin anrufen und fragen, was sein Problem ist. ;)

Immer wenn ich diese Probleme lese, muss ich dran denken, dass ich das im How To noch mit einpflegen will (seit Jahren), damit nach einer Verschiebung des PDC-e die Announceflags des bisherigen PDC-e wieder korrigiert werden. Es bleibt aber weiterhin die Frage, warum dein PDC-e nicht mit allen anderen FSMO auf einem DC liegt. :p

Naja, du musst nicht das Grundprinzip eines Proxys erklären, sondern nur klären, dass du eben einen proxy meinst und nicht evtl. ein zwischengeschaltetes SMTP Relay. Spontan würde ich genau an diesem proxy ansetzen, denn der macht irgendwas, was bei interner Kommunikation eben nicht so läuft. ;)

Du kannst jetzt noch zig mal "über den Proxy" schreiben, ich stell dann halt jedes Mal dieselbe Frage:

Ich denke er ist extern per SMTP erreichbar? was denn nu? SMTP Proxy? Wie muss man sich das vorstellen?

Ist ja auf jeden Fall eine SMTP Fehlermeldung. Insofern tippe ich mal auf ein Problem am Exchange. gibts denn evtl. Fehlermeldungen im Eventlog? Wenn genau dieser connector intern antwortet, dann wäre ich bei Nobby und würde mal schauen, was ggf. alles firewall- und Routingtechnisch dazwischenfunken kann.

Klingt nach backpressure. Wieviel Platz ist denn auf der Platte, auf der die Mail queue liegt?

Hat er die "Probleme" auch irgendwie erläutert? Ich seh da jetzt nur begrenzt Probleme, aber es kann ja sein, dass ich nicht über diese Probleme bisher gestolpert bin. Nö, warum sollte es? solange der user eine entsprechende Lizenz zugewiesen hat, oder man das Postfach in eine shared mailbox umwandelt ist da gar nix "Geschichte", wenn man das Konto deaktiviert.

Am besten sogar 2 Tage vorher. Auch wenns verdächtig wirkt. ;)

Richtig, aber irgendwann muss man sich dann bei bestimmten Kunden ersetzen lassen. So von wegen: keinerlei Bewegung trotz jahrelangem Tropfens ;)

https://legacy.support.exclaimer.com/hc/en-gb/articles/360026121771-How-to-configure-an-auto-response-for-an-alias-address ;)

Wirst du wohl auf den korrekten Header abstellen müssen und nicht nur auf den Empfänger.

Wenn sich CU14 installieren läßt, sehe ich keinen Grund es nicht zu tun. Hat ja keinen wirklichen Zusammenhang mit dem von dir beschriebenen Thema der Download Domains. Die Lücke gibts ja schon ein paar Jahre. ;)

Meist erreichen solche Konstrukte hinterher das Gegenteil davon. ;)

Und wenn man bei set lange genug wartet? Wohin ist denn die Powershell auf Server 2 verbunden? zum lokalen Server, oder gibts da evtl. schon Probleme?

Hmm, merkwürdig. Dann musst du wohl erstmal ins Eventlog schauen, ob man irgendwas sinnvolles findet.

Also ein get-owavirtualdirectory auf dem zweiten Server bringt ein ergebnis, aber ein Set bringt einen Fehler?

Dann stimmt wohl was mit dem zweiten Server nicht. ;) kannst du den mal booten?

Starte das doch mal direkt auf dem zweiten Exchange. Die Fehlermeldung erscheint mir ansonsten recht eindeutig.

Was hier vor einigen Seiten ja mal vorgeschlagen wurde ;)

Na das geht beim Edge aber genauso. ;)

Auch das steht natürlich in der sehr ausführlichen Extended Protection Anleitung. ;)