NorbertFe

Möglich. Antworte doch mal auf die Frage: Was genau soll diese Regel tun?

Ich versteh dein Konstrukt immer noch nicht. Vielleicht weil ich schwer von Kapee bin, aber wenn deine Regel aus 1. als Match "multipart/signed" nimmt und du gleichzeitig in 2. du dieser Rule sagst, dass ExceptIfMessage Signed ist, dann matcht die nie diese Regel. Mal davon abgesehen, dass "signed, encrypted" zumindest lt. dem Exchange 2010 Artikel so nicht funktioniert, aber das mag in ExO natürlich inzwischen funktionieren. Was kommt denn dann als Prio3 und prio 4 bei dir?

Nochmal zum Verständnis. Du willst alle eingehenden Nachrichten "außer digital signierte" mit einem Betreff versehen, richtig? New-TransportRule -Name "Signierte E-Mails in Klars***rift" -HeaderMatchesMessageHeader "Content-Type" -HeaderMatchesPatterns "multipart/signed" -SetHeaderName "X-Processed" -SetHeaderValue "True" Wenn ich das richtig lese, dann zielt das doch darauf ab, Mails mit dem Header multipart/signed zu identifizieren, richtig? Und im nächsten Schritt schließt du sie von der Verarbeitung wieder aus. Set-TransportRule -Identity "Signierte E-Mails in Klars***rift" -ExceptIfMessageTypeMatches "Signed" Wäre für mich jetzt nicht verwunderlich, dass eben signierte Nachrichten dann von der Regel (vermutlich mit Priority 3 oder später) verarbeitet werden. Evtl. hilft das: https://thoughtsofanidlemind.com/2011/05/12/excluding-disclaimers-for-encrypted-or-signed-messages/

Welche Regel ist denn mit Priority 1 da?

Indem du signierte Mails nicht auf dem Transportweg veränderst. Ist doch ganz einfach. :) Die Wahrscheinlichkeit, dass du externe signierte Mails bekommst _und_ diese Spam oder Phishing sind, ist derzeit relativ gering. Alternativ brauchst du irgendwas, was die digitale Signatur dann "abschneidet", dann kann der User aber nicht mehr erkennen, dass die Mail mal signiert war. Ich bin aber auch kein Freund von diesen "Betreffänderungen". Denn das liest spätestens nach 2 Wochen eh kein User mehr und klickt trotzdem drauf. Es wäre vermutlich besser lesbar für alle, wenn du statt dieser großen weißen Screenshots einfach mal die Transport Regeln per Powershell ausgeben würdest (und hier per Code Tag einfügst). Dann sieht man nämlich ggf. auch die Abarbeitungsreihenfolge.

Ja, da ich bei fast allen davon ausgehe, dass es single domain forests sind... ;) Aber ok dein Hinweis ist korrekt.

Nein. Vor allem kann man ja zig UPN-Suffixes pro Domain anlegen und nutzen. Ich würde es JETZT noch ändern, denn an dein Konstrukt erinnerst du dich vermutlich in 2 Wochen schon nicht mehr.

Und wozu braucht man das? Wärs nicht einfacher nur username@domain.de zu nehmen?

Aber bitte die Lizenzthematik berücksichtigen. ;)

Bandbreite interessiert doch niemanden (jedenfalls niemanden der nicht damit zu tun hat.) ;)

Datenverlust bzw. Integritätsverlust der Daten ist in deinem Szenario (kopieren) aber höher. Wenn das egal oder unerheblich sein sollte, könnte man darüber nachdenken. Allerdings ist das installieren eines hyper-v Hosts eine Sache von nicht mal 1h, ich sehe also das Problem nicht, welches du lösen willst. ;)

Sie sollten, aber sie müssen nicht.

Naja es würde schon reichen, wenn all die Optimierungen und Handstände die man machen muss mal mit ins default Setup geflossen wären.

Trotzdem Mist. Andererseits hat sich wsus technisch ja sowieso seit 2012 nix mehr getan, oder?

Man könnte sich ja nochmal sein Konstrukt vor Augen führen (wir definieren Gruppen die Zugriff haben sollen) und dann nochmal überlegen, ob andere Gruppen Zugriff haben "müssen". ;) Doch auch das kann man testen.

Warum nur heißt die Test-Struktur Test-Struktur? Damit du dir genau diese Frage selbst beantworten kannst. Wir können dir diese Frage hier nicht beantworten.

Und übersiehst die Hinweise, die dir hier im Forum gegeben werden. Regele das NICHT per Explorer, sondern nimm dir ein entsprechendes Tool, was erstens schneller und weniger Klickarbeit braucht und sogar einen Undo Knopf hat. Du machst es dir echt unnötig schwer, nur weil du "es so willst und musst". Bitte, jeder wie er will. Bye Norbert

Na dann berichte doch mal in ca. 12 Monaten. Dann wissen wir und IHR, was aus dem Projekt geworden ist und ob es gelebt wird oder einfach nur da ist. ;)

zumindest keine praktikable.

Wieso? Die bekommen sie dafür, dass du lizenzrechtlich auf der sauberen Seite stehst. ;) Du darfst natürlich auch jegliche Alternative nutzen, wenn dir oder deinem Kunden das besser gefällt.

Nein der darf problemlos auch auf Windows 2019 und ab CU15 auch auf Windows 2025 installiert werden. Allerdings ist die Laufzeit halt nur noch etwas mehr als 1 Jahr. Also Exchange jetzt ohne SA zu erwerben ist Geldverbrennung. Jetzt kurz vor Exchange SE aber auch schon egal. :)

Für Exchange 2019 soweit ich weiß noch nicht, oder wo liest du das raus?

Du brauchst entweder Lizenzmobilität = SA oder die doppelte Anzahl an Lizenzen (einmal die laufenden Instanzen plus die Cold Standby Lizenzen). War jetzt nicht so schwer aus dem Thread herauszulesen, oder?

Wieso ist das besonders interessant? Das ist der Grund, warum dir hier mehrfach SA empfohlen wurde. Wenn du die Lizenzen schon hast kannst du damit gar nichts anfangen, denn SA muss zusammen erworben werden und darf dann nicht ablaufen. Und ja du brauchst für jede Lizenz eine eigene SA. Und da du ja den Lizenzexpress Link oben schon gefunden hast, findest du da bestimmt auch die Preise für SA (pro Produktlizenz). Warum? Weil Microsoft Geld haben will?

logisch, wenns regex ist. ;)