Jump to content

NorbertFe

Expert Member
  • Gesamte Inhalte

    43.066
  • Registriert seit

  • Letzter Besuch

24 Benutzer folgen diesem Benutzer

Alle Follower einsehen

Profile Fields

  • Member Title
    Expert Member

Letzte Besucher des Profils

29.503 Profilaufrufe

Fortschritt von NorbertFe

Grand Master

Grand Master (14/14)

  • 15 Jahre dabei!
  • Immens engagiert Rare
  • Engagiert
  • Erste Antwort
  • Erster eigener Beitrag

Neueste Abzeichen

2,2k

Reputation in der Community

355

Beste Lösungen

  1. Naja irgendwie logisch, dass das so nicht unbedingt toll funktioniert. Stehen die Namen im Zertifikat? Falls nein, dann mal die Hosts korrekt setzen. Was steht denn im Zertifikat für ein Name? Die müssen ja wohl unterschiedlich sein, sonst gäbe es keine Probleme. Deine scp sind unterschiedlich, wie du ja schreibst. Sollte man nicht unbedingt tun.
  2. Warum? Dann kannst du sie ja auch gleich löschen, denn dann siehst du, ob du evtl. noch was vergessen hast ;) Fahr ihn doch mal runter. Geht dann auch noch alles? Dann sind wohl die Virtual Directories noch nicht sauber konfiguriert bzw. der ClientaccessService im SCP. Gib mal ein get-clientaccessservice | fl *uri* Dann haben einige offenbar falsche Settings und finden ihr Postfach nicht. Nichts, was man nicht beheben kann, aber ich würds halt vorher sauber ziehen. Nach welcher Anleitung bist du vorgegangen? Bye Norbert
  3. Betrifft übrigens nicht nur SMTP Domains, sondern bspw. auch die Neueinrichtung von Entra ID Connect. Das dauert aktuell wenigstens 4-6h bevor die Synchronisation sauber abgeschlossen werden kann.
  4. Ist es so schwer, sich das mal beim Hersteller anzuschauen? https://learn.microsoft.com/en-us/powershell/module/exchange/set-organizationconfig?view=exchange-ps#-ewsenabled
  5. Was soll der denn da ausrichten? Oder hast von ihm die O365 Lizenzen?
  6. Ja, warte einfach mal 5-6h. Scheint seit kurzem etwas langsamer zu gehen in der ms Cloud. ;)
  7. Wie lange hast du bis jetzt gewartet?
  8. Kann durchaus sein. Ich hab’s nirgends benutzt. War halt irgendwann mal schulungsbestandteil. ;)
  9. Nein, das stimmt so nicht. Bis irgendwann 2024 war das eine Funktion, die es in Exchange Online gab (DLP Transport Rules). Wurde lange vorher an- bzw. abgekündigt, man kann also maximal den Vorwurf machen, dass man den Empfehlungen zum Löschen nicht gefolgt ist. ;) https://techcommunity.microsoft.com/blog/exchange/exchange-online-etrs-to-stop-supporting-dlp-policies/3886713 https://techcommunity.microsoft.com/blog/exchange/exchange-online-mail-flow-rules-to-stop-supporting-dlp-related-rules-conditions-/3959870
  10. Hilft dir evtl. nur bedingt, aber ich würde einfach ein Ticket bei MS eröffnen für den Kram.
  11. Ich vermute, es geht um Exchange Online? Falls ja, dann hast du vermutlich gelesen, dass es die in ExO nicht mehr gibt und man das im neuen PurView Portal bearbeiten=löschen kann. Ich hab grad keine DLP Richtlinien mehr irgendwo im Einsatz um zu sehen, was da in der Praxis mit passiert, aber man wird ja zum neuen Portal geleitet: https://purview.microsoft.com/datalossprevention Bin mir grad nicht sicher, ob da in der E3 (die wir haben) extra Lizenzen notwendig sind, aber ich komm zumindest ins Portal rein.
  12. Das ist meine letzte Antwort hier im Thread. Ich habe dir oben geschrieben, dass Exchange kein Sender Based Routing beherrscht. Es also ohne Hilfsmittel nur anhand der EMPFÄNGERDOMAIN oder anhand der Priorität möglich einen Sendeconnector zu wählen. Wenn ihr also 4 Sendeconnectoren verwendet, dann hab ihr dafür entweder einen guten Grund, oder eine unnötige Konfiguration. Kann ich ja schlecht einschätzen. Fakt ist aber, dass man dir eine Antwort schreibt und du daraufhin eine irrelevante Aussage kommt, die ja 1. genau null zusätzliche Info enthält noch 2. auf meine eigentliche Aussage eingeht. Insofern wenns für euch funktioniert ist gut, für mich ist hier jetzt Ende. Bye Norbert
  13. Da Exchange kein Sender based routing kann, ist das entweder immer derselbe senconnector aufgrund von * oder in der Priorität an der richtigen Stelle. Jedenfalls gibts da keinen für mich erkennbaren Zusammenhang von leerem oder nicht leerem Absender.
  14. Steht doch alles schon oben. Leerer Sender heißt, es ist kein Return-Path (AKA Envelope Sender) drin und somit kann auf einen OOF auch kein Bounce erfolgen. Und leer bedeudet leer. NICHTS, Empty, Leer, Nada also auch keine Domain. Hier zum Nachlesen: https://datatracker.ietf.org/doc/html/rfc2298 bye Norbert
  15. Die ist LEER. was soll er denn da finden? Es soll auf einen OOF keinen Bounce geben. Aus gutem Grund. Exchange verhält sich hier vollkommen RFC-konform. Ja es gibt Tools, die diese Konformität dann kaputtmachen, damit der Absender Ruhe gibt. Für mich kein sinnvoller Lösungsweg.
×
×
  • Neu erstellen...