NorbertFe

Nein und das ist auch gut so. Ein OOF wird per Empty Sender gesendet (vom Exchange). Da ist also keine kryptische interne Domain enthalten. ;) Sicher, dass es um OOF und nicht um NDR oder DSN geht? Das wäre dann die external postmasteraddress in der Transportconfig.

Geh mal davon aus, dass der OWA korrekt ist und du im Outlook möglicherweise den Cachemode aktiv hast. Was passiert, wenn du ein neues Outlook Profil erstellst. Was siehst du dann?

Naja geht halt „noch“. 2019 ist ja auch betroffen.

Bis Ende des Supportzeitraums von Office 2016 und aktuell gepatcht ja. edit sagt: stimmt nicht. Ms hat den Support im Oktober 2023 für Services beendet: https://learn.microsoft.com/en-us/deployoffice/endofsupport/microsoft-365-services-connectivity ich vermute es wird funktionieren, aber ohne Support.

Wohin zeigt der scp? Den solltest du ggf. Am Client testweise ausschließen oder im Exchange per set-clientaccessservice leeren.

Hier zum Nachlesen ;) Auch wenns jetzt eh egal ist: https://www.handelsblatt.com/unternehmen/handel-konsumgueter/ebay-ebay-kleinanzeigen-heisst-kuenftig-anders/29115742.html

Ebay hat afaik Kleinanzeigen verkauft mit der Bedingung für x Jahre noch Ebay Kleinanzeigen als Namen zuzulassen. Das ist vor einiger Zeit abgelaufen, deswegen jetzt nur noch Kleinanzeigen.

Diesmal?!

Ich hab schon länger keinen neuen Exchange mehr unattended installiert. Aber Kollege hat gestern Exchange 2019 CU14 neben Exchange 2016 per GUI installiert und da ging das direkt weiter, wenn man das Feedback deaktiviert hat.

alternativ: Neuinstall before pfusching ;)

Nein der scp kann auch direkt auf owa.domain.tld zeigen. Wozu sollte er auf autodiscover zeigen müssen?

Du beschreibst grad das gefühl, nachdem ich mein neues Auto gestern in Empfang genommen habe:

Weißt du, warum es hier die codeblock Formatierung im Forum gibt? ;)

Moin, das sollte ja der „lizenzberater“ dann auch irgendwie belegen können, diese Aussage. bye norbert

Die wäre üblicherweise zu bevorzugen, wenn man eine IP für den http Redirect nutzen kann. Sprich meine Priorität wäre umgekehrt zu deiner Liste (von unten nach oben).

270€ wären mir auch zuviel wenn es um Exchange Domains ginge. ;)

definiert aber auch jeder anders. Bei mir wäre da spätestens bei 3 Schluss. ;) Hab aber Kunden die hatten da 10-20 drin. ;)

Eigentlich ist es nicht eleganter und hilft halt nur bei Windows Outlook. Alle anderen Clients kennen den SRV Lookup im Autodiscover nicht.

Das kommt darauf an, ob dein Exchange Server die Mails direkt aus dem Internet annimmt, oder ob du ein Relay davor hast, von welchem der Exchange die Mails zugestellt bekommt. Im ersteren Fall musst du den Default Connector dann erstmal auf die internen IP Kreise eindampfen, damit die 0.0.0.0 an deinen neuen Connector gebunden werden kann. Im zweiteren Fall legst du einfach einen neunen Connector an und definierst nur das Mailgateway als erlaubte Remote IP Address. Bye Norbert

Da geht es um den Default Frontend Connector. Dessen EHLO String kannst du nur anpassen, wenn du ihn "umkonfigurierst". Aus diesen Grund solltest du NICHT den Default Frontend Connector benutzen, sondern einen eigenen mit den richtigen notwendigen Einstellungen. Denn der Default Frontend Connector nutzt im Default den Hostnamen des Exchangeservers, damit er sich mit anderen Exchange Servern seiner Organisation sicher "unterhalten" kann.

Da ich die Fehler nicht auswendig kenne und selbst recherchieren müßte, wäre es schon von Vorteil, wenn du die komplette Fehlermeldung hier als Code reinkopieren könntest. Aber ich vermute mal, dass das Zertifikat entweder den im EHLO eingetragenen Namen eben nicht enthält (Tippfehler), oder nicht an den SMTP Service gebunden wurde. Bye Norbert

Ich vermute, du erwartest das, was ich dir oben schon erklärt habe, hier nicht geben zu können: Da ich deine grundsätzliche Konfiguration nicht kenne, wird das etwas schwierig, sowas im Forum als Schritt für Schritt Anleitung hinzuschreiben. Insofern habe ich dir die Werkzeuge an die Hand gegeben, dich mit diesem Problem auseinanderzusetzen: TlsAuthLevel : TlsCertificateName : TlsDomain : UseExternalDNSServersEnabled : False Konfiguriere das mal korrekt (mit validen Zertifikatsdaten) und auf der Gegenseite in Exchange Online mit Zertifikatsvalidierung und schau ob sich was ändert. Wenn du das selbst nicht machen kannst oder willst, wäre es jetzt an der Zeit sich an (s)einen Dienstleister für diese Themen zu wenden um zu schauen, ob das Problem gelöst werden kann. Ich kann dir nicht sagen, ob es dafür eine "vernünftige" Lösung gibt, aber ich gehe stark davon aus. Bye Norbert PS: Da hilft auch kein Siezen. Und wenn du immer nur deine Einzeiler hier postest, ohne mal mitzuarbeiten (zumindest ist das mein Eindruck), dann wird die Hilfe hier auch nicht sonderlich wirksam sein.

Ja, diese Vermutung wurde aber jetzt auch bereits von mir geäußert inklusive dem Vorschlag, den Sendeconnector mal zu bearbeiten. Ansonsten drehen wir uns hier im Kreis.

Ich dachte ich hätte mit den entsprechenden Links in die Hinweise auf die mögliche Lösung deines Problems gegeben. Du wirst also testen müssen, ob die Konfiguration des Sendeconnectors zum Ziel führt. Da ich deine grundsätzliche Konfiguration nicht kenne, wird das etwas schwierig, sowas im Forum als Schritt für Schritt Anleitung hinzuschreiben. Vor allem, weil du ja bspw. die erste meiner Frage noch nicht mal beanwortet hast: Es geht also um OOF Nachrichten die von On-Prem Postfächern an ExO Postfächer gesendet werden oder auch an externe Empfänger gehen? Je nach der Konfiguration und des gewünschten/konfigurierten Mailflows kann es also evtl. unterschiedliche (oder keine sinnvolle) Lösung geben.

Ohne es genau zu wissen oder belegen zu können, bezweifle ich, dass du dieses Attribut ändern kannst, denn es wird mit hoher Wahrscheinlichkeit (siehe die Einleitung) ein constructed attribute sein oder eben read only. Und wenn man "when created" änderbar wäre, dann wär der Zweck dieses Attributes irgendwie hinfällig, oder?