NorbertFe

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:

OK, soweit mir bekannt gabs bisher immer nur offizielle Aussagen zur Nichtmöglichkeit und im Allgemeinen gibts vermutlich weltweit nicht mehr soooo viele die einen guten Draht zum PS haben. ;) Mir persönlich würden jetzt auch nicht soviele Stellen einfallen an denen einem die Umbenennung auf die Füße fallen kann, aber versuchen möchte ich es trotzdem nicht unbedingt allein. :)

Sehr wahrscheinlich. Kannst du doch ganz einfach rausfinden. Entweder mal temporär auf NAT Veröffentlichung umstellen und testen oder in der WAF das Filters Strength Level mal runtersetzen (und ggf. auch mal ins erweiterte WAF Logging - nur per CLI schauen). Bye Norbert

Hättest du das gleich geschrieben, hätte man dir die Antwort sofort geben können, da müller/muller halt leider identisch fürs AD ist. Hilft im Nachhinein aber leider auch nicht mehr, denn die Lokalisierung der Default Gruppen ist im Nachhinein zumindest nicht supported. Möglich soll sie wohl sein, aber dann hätte die Gruppe der "Unternehmenssschlüsseladministratoren" auch nicht mehr diesen schönen Schreibfehler ;)

https://www.frankysweb.de/windows-server-2025-falsches-netzwerkprofil-auf-domain-controller/