NorbertFe

Kann durchaus sein. Ich hab’s nirgends benutzt. War halt irgendwann mal schulungsbestandteil. ;)

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

Hilft dir evtl. nur bedingt, aber ich würde einfach ein Ticket bei MS eröffnen für den Kram.

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.

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

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.

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

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.

Na dann ist doch gut für euch.😆

Hängt halt vom Anforderungsprofil ab. Und bevor ich sowas pauschal umsetze, schaue ich mir evtl. eben erstmal die Konsequenzen an, die diese Konfiguration mit sich bringt.

Wer kommt denn auf die Idee 😆

Google mal Cached credentials. ;) Kann man konfigurieren, wieviel gespeichert werden. Probier’s doch in der Firma aus. Melde dich ab, zieh das lankabel ab oder Wireless aus. Indem man mindestens zwei zwischengespeicherte Anmeldungen erlaubt. Und nur diese zwei Accounts das Notebook nutzen und beide wenigstens einmal online angemeldet werden.

Soll der ram lieber ungenutzt rumliegen?

Da kommt er ja nicht hin wegen fehlender MFA Möglichkeit. ;)

Im Zweifel würd ich den "andere Dienstleister" anklingeln und nachfordern.

Nein ist es nicht. Aber der User sollte sich schon neu anmelden, damit die Gruppenmitgliedschaft zieht. ;)

https://learn.microsoft.com/en-us/powershell/module/exchange/set-organizationconfig?view=exchange-ps -PublicFolderShowClientControl https://learn.microsoft.com/de-de/powershell/module/exchange/set-casmailbox?view=exchange-ps -PublicFolderClientAccess Komisch, sonst wollen immer alle erinnert werden, wenn im Gruppenpostfach was ankommt ;) Weil es eben eine andere Zugriffsvariante ist.

Was kein Wunder wäre, wenn du tatsächlich den Offline Modus meinst. ;) Ich vermute aber, du meinst den Cache-Mode (ja, das ist tatsächlich ein Unterschied). Die Automapped Mailboxes einfach NICHT in den den Cachemode integrieren, sondern per Policy verhindern. Bye Norbert

Ich hab dir insgesamt 3 Hinweise gegeben. Wenn du natürlich nur den bequemsten umsetzt, wird es schwierig die Fehlerquelle zu finden und auszuschließen.

Gibt doch genügend NAS Systeme und denen man eine vm laufen lassen kann. Dann installier dir doch da ne Windows 2019 vm als dc. ;)

Hättest ja auch einfach noch ne 5. Schicht draufschmieren können. ;) Haben die vor dir ja auch alle gemacht.

Ist sie auch. Hat sie ja auch nicht. Aber deswegen bleibt deine Aussage eben falsch. Ist doch gut, wenn du jetzt eine andere besser für dich passende Lösung hast.

Erzähl mehr, was nicht mehr darüber funktioniert.

Und wenns jetzt Probleme gibt, dann liegt das vermutlich an den Extended Protection die auf Exchange 2019 seit CU14 per default aktiviert wird und bei 2016 eben nicht. Da sollte man es jetzt manuell aktivieren.

Das kann natürlich nur der Admin tun und dann könnte er es auch zur Not per GPO ausrollen. Alternativ wäre interessant, ob man das gleiche Ergebnis nicht auf Serverseite erzielen kann: