NorbertFe

https://www.faq-o-matic.net/2011/02/07/bilder-im-active-directory/ da sieht man mal, wie viel software inzwischen eingestellt wurde. ;) kaum noch ein Link aus meinem Artikel funktioniert. der hier geht aber definitiv noch: https://www.codetwo.de/freeware/active-directory-photos/

Ja mit Powershell und einer entsprechenden Schleife. Oder mit einem entsprechenden Tool.

Ohne den gpresult Report wird das vermutlich schwierig, hier weiterzuhelfen.

Ja, aber die gelten dann für die jeweiligen gpp und nicht für Scripts im gpo.

Im Zweifel mal nachschauen, wo die "Public Folder Database 1154646891" noch im AD steht. Sie muss ja noch an irgendwelchen Objekten hängen. Wird man mit adsiedit sicherlich finden können. Alternativ mal ein LDIF vom gesamten AD ziehen und mit dem Editor durchsuchen. Irgendwo muss der Kram ja auftauchen.

Warum dann migrieren? :) Aber muss wohl jeder selbst merken.

Ich würde kurzfristig „jetzt“ weggehen. ;) wenn du die jetzt migrieren hast du sie auch in 5 Jahren noch.

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

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.

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?