NorbertFe

Du brauchst doch nur bei deiner external rule die signed Mails ausnehmen. Aber probier’s halt.

vor einer Stunde schrieb Assassin:

Oder hat das vieleicht doch noch weitreichendere Folgen wenn man die gruppe entfernt?

Stellt man sich diese Frage nicht bevor man sie entfernt? ;) An deiner Stelle würde ich es jetzt einfach abwarten. Sehr wahrscheinlich ist es aber nicht kritisch.

Du definierst eine Regel (Prio 2) , welche auf Multipart/Signed abzielt und exludierst dann in der selben Regel, signed Nachrichten . Und dann wunderst du dich, dass auf diese (ausgeschlossenen Nachrichten) die Prio 3 Regeln angewandt werden. Und zusätzlich müsstest du dann in Prio 3 natürlich die in Prio 2 bearbeiteten Mails ausschließen, damit sie eben nicht dort verarbeitet werden. Evtl. bin ich ja zu blond, um das zu verstehen. 

Deswegen fragen wir dich ja nicht. 

vor 4 Stunden schrieb BRIX:

Vielleicht kann ich es auch nur schlecht beschreiben.

 

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?

vor 5 Minuten schrieb BRIX:

Wie bekomme ich das hin, das dennoch Signierte Mails "normal" also nicht als Anhang angezeigt werden.

 

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.

vor 6 Minuten schrieb cj_berlin:

Pro Forest  

 

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

vor 23 Minuten schrieb msdtp:

Müsste ich dann nicht die lokale Domain umbenennen?

 

Nein. Vor allem kann man ja zig UPN-Suffixes pro Domain anlegen und nutzen.

vor 20 Minuten schrieb msdtp:

Ok, beim nächsten mal....

Ich würde es JETZT noch ändern, denn an dein Konstrukt erinnerst du dich vermutlich in 2 Wochen schon nicht mehr.

vor 25 Minuten schrieb msdtp:

username@domain.local; für die lokale Anmeldung
Username@domain.de; für die online Anmeldung

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.) ;)

vor 13 Minuten schrieb spooner:

Was haltet ihr davon?

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. ;)

vor 1 Stunde schrieb Nobbyaushb:

nach meinem Wissensstand müssen alle Member die gleichen Physischen CPU mit der gleichen Anzahl Cores und Taktfrequenz und Hauptspeicher haben

 

Sie sollten, aber sie müssen nicht. 

vor 7 Stunden schrieb Sunny61:

Richtig. Vermisst Du etwas?

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?

vor 4 Minuten schrieb imebro:

Ich könnte natürlich jetzt noch weitere Gruppen hinzufügen (z.B. "Authentifizierte Benutzer", die Standardgruppe "Benutzer" etc.), aber ob das sein MUSS, weiß ich dann auch noch nicht.

 

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". ;)

vor 5 Minuten schrieb imebro:

Das kann ich so ja auch nicht wirklich testen.

 

Doch auch das kann man testen.

vor 17 Minuten schrieb imebro:

Ich meinte, ob ggf. noch ZUSÄTZLICHE Gruppen aufgenommen werden MÜSSEN in meine Test-Struktur?

 

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.

vor 30 Minuten schrieb imebro:

Vorab hatte ich die Vererbung deaktiviert, im nächsten Fenster die 2. Option (Link) gewählt und dann die Admin- u. MA-Gruppe über "Prinzipal auswählen" hinzugefügt.

 

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

vor 8 Minuten schrieb imebro:

FÜR UNS!! praktikabel sein

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. ;)

vor 1 Stunde schrieb magheinz:

Es gibt keine Möglichkeit auf einer Ebene den Leuten Zugang zum Ordner zu geben um darin zu arbeiten und gleichzeitig zu verhindern, dass sie diesen Ordner löschen

zumindest keine praktikable. 

vor 2 Minuten schrieb magicpeter:

für nix....

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.

vor 1 Minute schrieb Nobbyaushb:

Exchange 2019 bitte nur beachten, der dieser nach dem derzeitigen Stand nur auf Server 2022 installiert werden darf

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.

vor 2 Minuten schrieb lizenzdoc:

Alles nicht so einfach ...

Jetzt kurz vor Exchange SE aber auch schon egal. :)