NorbertFe

Offenbar hast du es nicht getan, denn dann hättest du im adsiedit ja nicht im falschen Kontext gesucht (hatte sogar extra Verlinkungen _mit_ Bildern geliefert). Aber da ich dir ja zu unfreundlich bin, musst du eben warten, bis es dir jemand anderes nochmal schreibt. Viel Erfolg Norbert

Hab ich doch oben getan. Müßtest nur die Beiträge dir antwortender Forenmitglieder lesen. ;) Bye Norbert PS: "Optimal" kann man nicht steigern.

Offensichtlich? Für wen? Und wo hast du geschaut? Sind deine dcs dhcp Server?

Ja auf zwei 2022 dcs. Hab noch keine Probleme festgestellt (aber auch nicht danach gesucht).

Na steht der Server drin oder nicht?

War/ist Windows 2022 nicht davon betroffen? In der Liste stehen nur 2012R2, 2016 und 2019. Edit: Ich muss wohl erst die Tasse Kaffee austrinken. Sorry, habs gefunden.

Wie wärs wenn du den Rechtsbeistand fragst. ;) Dürfen wir hier nicht, aber ich hab mal gegooglet (ohne Anspruch auf irgendwas) https://www.computerweekly.com/de/ratgeber/Datenschutz-Rechtskonforme-Spam-Filterung (Zwar schon älter, aber ich bezweifle, dass sich da wirklich großes dran geändert hat) Für rechtlich verbindliche Aussagen siehe meinen ersten Satz. Wenn du sie also NICHT annimmst, dann hast du genau dieses Problem gar nicht erst. Und ja das ist ein Unterschied, ob ich eine Mail nicht annehme oder sie nach der Annahme dem eigentlichen Empfänger vorenthalte. Bye Norbert

Dann schau doch mal mit adsiedit nach. CN=NetServices,CN=Services,CN=Configuration,DC=domain,DC=tld Man kann die Autorisierung auch delegieren, so dass man dazu nicht Org-Admin sein muss. https://secureidentity.se/delegate-dhcp-admins-in-the-domain/ https://regularsysadmin.wordpress.com/2015/02/07/delegating-microsoft-dhcp-server-administration-completely/

Ja, das ist der Zweck eines Rejects. Eher unwahrscheinlich, da oft nicht den Sender Address (RFC5321.MailFrom) gefälscht wird (jedenfalls nicht _an_ dich, sondern von anderen), sondern die From (RFC5322.From und die steht innen und interessiert bei SPF null) und wenn, dann sollte euer System eben Backscatter erkennen können. ;) Man löscht keine Nachrichten ohne Benachrichtigung. Isso. Ich weiß, das will dein Chef nicht hören. Jeder wie er meint. Bye Norbert

Hardware? Ich kenn solche Phänomene aber auch unter Windows 10 schon. Meist hat ein Update des Docks geholfen.

Schlechte Idee. Reject wäre das Sinnvollste in dieser Situation. Tausch den Mist aus. Anders kann man das nicht mehr bezeichnen. Und wenn du nach deinem Smarthost was einfach löschst, dann bist DU verantwortlich. Der richtige Punkt für die Spamfilterung ist IMMER der erste annehmende Host für deine Domain. Wenn das dein Smarthost ist und der sowas nicht kann, dann wirds echt Zeit und alles andere brauchst du dir nicht ausdenken, denn das wird nur Quark.

Man müßte halt lesen, was einem geantwortet wird. Ohne SPF/DKIM und DMARC wirds garantiert nix und selbst mit denen gibts immer noch diverse Situationen, wo Fehler auftreten. Die sind dann aber eben auch seltener im normalen Mailverkehr

Das schaffst du nicht (allein) mit SPF. Ja. Siehe oben. Und an der Stelle solltest du als erstes ansetzen. Denn wenn du nicht weißt, wie und warum deine Mails irgendwo landen, ist das immer ein schlechter Start für Antispam Maßnahmen. SPF kann man dann immer noch leicht konfigurieren. Dein Problem hat aber wie schon erwähnt mit hoher Wahrscheinlichkeit gar nichts damit zu tun. Bye Norbert

Weil man dann nur ein bisschen Spam bekommt, oder wie? Gleich vorneweg: SPF hilft heutzutage nur noch bedingt. Auch Spammer können SPF. ;) Zu deinem Problem: Es wäre einfacher, wenn du das mal konkret skizzierst. OWA wäre ja direkt per https auf dem Exchange und da spielt der SPF Record keinerlei Rolle.

Schau mal, was du für Backup Software bekommst, die Proxmox nativ unterstützt und vergleich das mal mit Hyper-V oder ESX. Von den beiden letzteren gibts übrigens genauso kostenfreie Editionen die in deinem Fall vermutlich ausreichen und die genauso "sehr problemlos" laufen würden. ;)

Ich werte den ;) mal entsprechend. :p

Wenn ich das richtig sehe, aktiviert das wieder RC4 korrekt? Da bin ich bei solchen Quick'n'dirty Lösungen ja immer skeptisch, ob hinterher überall auch wieder auf 24 gesetzt wird. ;) Und dann sind sich alle sicher, dass sie immer gepatcht haben und vergessen die Q'n'D Aktion ausm November 2022. ;)

Dazu hatte ich ja neulich einen Thread aufgemacht, aber das war noch vor den November Updates. Ich hatte übrigens heute einen anderen "netten" Fehler mit CVE-2021-42287. Das hatten wir vor Monaten auf 2 gesetzt und gefühlt seit Oktober (das war ja angekündigt) liefen die GPOs auf den DCs nicht mehr alle. Aufgefallen ist das, weil per GPO auf dem PDC Emulator der falsche Zeitserver (auf Domain Root auf NT5DS) ankam, anstatt der entsprechende NTP Server. Policy auf nicht konfiguriert gesetzt Fehler weg Zeit wieder in Ordnung. :/ Nervt aktuell richtig, wenn ich auch an das aktuelle Problem mit DirectAccess denke. Bye Norbert

Wie hat sich das denn gezeigt? Fällt vermutlich in einer Kerberos-only Umgebung deutlich schneller auf als in einer wo NTLM als Fallback noch läuft, oder?

Ja.

Ja aber auch da für jedes einzeln und dann per Schleife. ;)

Wieso ob? Na klar kann man das machen. Obs hilft oder sinnvoll ist, sei mal dahingestellt. :)

Wirf es nochmal raus und importiere es komplett neu (per Exchange Powershell). Alternativ vermutlich sowieso egal. Was ergibt ein Test mit checktls.com? Alternativ 2: Setz das Zertifikat explizit in den Sende- und Empfangsconnector. Bye Norbert PS: Der Thumbprint ist nicht geheim. ;) Der steht im Zertifikat öffentlich zugänglich.

Hast du geklärt, dass das Zertifikat gültig ist? Hat der Exchange evtl. einen Proxy eingetragen? Welchen Fehler gabs denn? Zertifikat ungültig oder kein Zugriff auf die CRL. Viel mehr Möglichkeiten gibts nicht. Bye Norbert

Es geht um den exchange Patch, nicht um den für Windows. ;)