NorbertFe

Das dürfte wohl auf so ziemlich jedes SMTP Relay zutreffen, es sei denn es ist ein open relay. ;) Das hilft wie ich oben schrieb aber nur bedingt, wenn nicht auch noch der Displayname berücksichtigt wird. Warum man dafür dann allerdings zwei Interfaces benötigt, erschließt sich mir nicht unbedingt, denn das ginge ja auch mit nur einem. Mails ohne From Header kann man zwar blocken, aber dann muss man sich nur bedingt wundern, wenn Dinge wie OOF nicht funktionieren. ;) Ich denke du weißt worauf ich hinaus wollte mit meiner vorherigen Antwort. Bye Norbert

Das "sollte" so sein, aber da Outlook ja den Displaynamen so schön prominent darstellt und die Mailadresse in grau auf hellgrau ist das sowieso in vielen Fällen egal, es gibt im Antispam auch keine 100%. Dieses "extern" habe ich nur bei unserem Personal- und Bewerbungspostfach aktiv. Die Leute die damit arbeiten, wissen aber auch genau, dass sie vorher fragen und nicht hinterher, da diese beiden Postfächer eben speziell nur dafür da sind. Wenn ich das global setzen würde, wäre das in meinen Augen auch nur "Gewohnheit". Das führt zu nix, außer falscher Sicherheit der Nutzer.

Was passiert mit internen Mails die nicht aus Outlook heraus initiiert werden?

Eben. Am Ende sag doch einfach, du brauchtest jemanden dem du dein Leid mitteilen wolltest ;) Eine Lösung wirds hier vermutlich nicht wirklich geben.

Würde ich auch nicht, wenn das Ding schon 24/7 seit x Monaten läuft ;)

Witzbold. Wenn alles verschlüsselt wurde und du sicherstellen kannst, dass deine Sicherung irgendwas starten kann, kann man natürlich mit einer 2 Wochen alten VM auch wieder an den Start gehen. Wo genau wär da jetzt das Problem? ;) Das kann man sogar "testen". Ansonsten eben... Metadatacleanup und schauen, dass du wenigstens zwei DCs recht schnell an den Start bekommst, und dann kommen deine Maschinen. ;)

Es geht doch nicht nur um Server, die du als "Printserver" nutzt, sondern um jedes Windows, was grundsätzlich Treiber untergeschoben bekommen kann (zur Not eben per lokaler Rechteerweiterung. Also, grundsätzlich ist es eine gute Idee, den Printservice tatsächlich auf Servern zu deaktivieren, solange dort nicht gedruckt wird (Printserver, Faxserver, Terminalserver). Bei denen sollte man dann schauen, ob 1. ein Fix irgendwann zur Verfügung steht, aber auch ggf. prüfen, ob man die NTFS Rechte bis auf weiteres einschränkt, denn das scheint tatsächlich aktuell die "sicherste" Variante zu sein. Bye Norbert PS: Falls ich da oben irgendwo Fehler im GEdankengang habe, dann bitte korrigieren. Doch, wenn man die "richtigen" Printdriver verwendet.

Aha, du meinst also, dass ein Backup ne gute Idee ist? Dann hast du recht. Dazu musst du nicht mal wissen was alles geändert wurde, solange du sicherstellen kannst, dass Backup ist konsistent. ;) der Rest ist dann Sache eines vernünftigen recoveryprozesses. Und da ist das ad zwar ein wichtiger, aber nicht der einzige Schritt ist. ;)

Die Lücke besteht auf jedem Windows PC. ;) Pfft Hacker. Das problem dürften wohl fast immer automatismen sein, die durch Nutzer ausgeführt werden. Und selbst wenn das erstmal „nur“ zur Übernahme eines PCs führt (was ich für wahrscheinlicher halte).

Ja, ist zwar auch auszuhebeln aber ein wenig sicherer. Vor allem wird man das alles testen müssen, damit man beim ersten Problem nicht die Lücke wieder aufreißen muss.

Tja dann hast du ein Dilemma. Vielleicht fürs Treiber deployment entweder einen anderen Weg finden oder zumindest auf die printserver einschränken.

Und das hindert dich ggf. selbst mal unter https://docs.microsoft.com/en-us/powershell/module/exchange/set-calendarprocessing?view=exchange-ps nachzuschauen? ;)

Ist das so schwer, sich mal die Eigenschaften anzuschauen? Wie wärs mit get-calenderprocessing "deinRaum" | fl Da gibts dann so Dinge wie "DeleteComments" und man staune: The DeleteComments parameter specifies whether to remove or keep any text in the message body of incoming meeting requests. Valid values are:

So wie beim TO? ;)

Das ist ja dann auch keine automatische Weiterleitung. Wär ja schlimm, wenn das nicht ginge. ;)

Genau, gibts da nicht was von $Cloud?

Wer druckt denn schon auf Terminalserver. ;)

Meine auch. ;) Aber da muss ich zum Glück nicht hin.

Wie wärs mit dem Test auf einem betroffenen Server? Dann sieht man, obs damit zusammenhängt.

Würde mich mal interessieren, wie denn die Point and Print Policy in 4. reinspielt. Denn laut Artikel gilt ja "The RestrictDriverInstallationToAdministrators registry setting resides under the PointAndPrint registry location but is specific to protections for CVE-2021-34527 but is not related to point and print behavior." Was heißt denn "not related"? :) Also üblicherweise wurde bisher ja folgende Richtlinie gesetzt: https://www.faq-o-matic.net/2009/10/08/drucken-unter-windows-7-in-der-domne/ Damit war es dann "Nicht Admins" auf den PCs möglich Treiber zu erhalten, die auf dem Printserver (oder ggf. auch woanders?) bereitstanden. Eigentlich ja ein gewünschtes Verhalten. Wenn ich jetzt "RestrictDriverInstallationToAdministrators" wäre interessant, ob das Auswirkungen auf das bisherige Verhalten am PC hat. Ich vermute nein. Bei all den ganzen Artikeln (hier, Heise, MS, usw. usf.) sieht man leider immer nur die Hälfte hab ich den Eindruck, weil niemand genau weiß, warum und wieso das bisher so gelöst wurde bzw. warum es auf einmal anders sein muss. :) Hatte ich ja bereits oben verlinkt. Aber das ist im Zweifel ja nur die Holzhammermethode für "wenige" Printserver, bei denen man im Zweifel "manuell" für das Treiberupdate sorgen kann. Wenn man das jetzt bei 1000 PCs ausrollen würde (ginge ja problemlos per GPO), dann hätte man spätestens dann ein Problem, wenn ein neues Druckermodell mit neuem Treiber kommt und steht da. :) So zumindest mein aktuelles Verständnis.

Stimmt. aber ich hab letztes Jahr ein Kabel hintergelegt (Glück, wenn man nur ca. 30m bis dahin hat ;)).

Interessant. Also fassen wir zusammen: 1. Dienst überall deaktivieren, wo er nicht benötigt wird 2. remotezugriffe auf den Spoiler überall per gpo deaktivieren wo er nicht benötigt wird 3. Update Juli installieren 4. restrict admins für die treiberinstallation für alle. was bleibt danach noch offen, außer aufs nächste Update warten und wie hoch ist dann die Hürde, wenn man das obige alles umgesetzt hat. Bye norbert

Wurde ja mehr oder weniger abgeschafft. Die Dinger können maximal noch usb nic. ;) ich hab noch die erste Generation vom Fire-tv (ohne Stick), da gabs einfach nen Ethernet Anschluss. ansonsten sehe ich das ähnlich, aber leider haben die wenigsten ne strukturierte Verkabelung in der Wohnung. ;)

Spart halt Strom ;) Alternativ könnte man ja auch einfach sagen, erst Fire-TV anschalten und dann erst das ipad ;)

Keine Sorge, aber das führt zu weit und bringt außer Frust ja nix. Ich glaub, das ist gerade bei Senioren oftmals eher ein "Angst haben" vor der Technik gepaart mit "ich höre nicht zu, weil ich dann einfach dich frage" :/