cj_berlin

Yup, Imprivata macht das ganze richtig managebar - für einen mehr oder weniger angemessenen Preis, versteht sich

Wenn Du auf NLA verzichten kannst, kannst Du die Anmeldung direkt am Anmeldebildschirm des Terminalservers durchführen. Das geht mit mstsc, musst halt die .RDP Datei ein wenig pimpen. Die beste Lösung für sowas sind Smartcards. Gesteckt --> Anmeldung, gezogen --> Abmeldung

Also zumindest kannst Du dich dann schon mal an die Agilität der dynamischen Gruppen in Entra ID gewöhnen, solltest Du diese mal benötigen

-RecipientFilter "(PrimarySmtpAddress -like '*@vg1.de')" oder so ähnlich

Ja, aber ob die KI dann auch das Richtige daraus lernt... <duckundweg>

Es gibt viele gute Ansätze hier, beim Threat Modelling für die Windows Firewall sollte eins jedoch nicht außer Acht gelassen werden: Die Konfiguration, ob sie lokal vorgenommen wurde oder aus GPOs kommt, steht im Klartext in der Registry. Somit kann die Angreiferin, wenn sie dort Lesezugriff hat, bereits genau wissen, was konfiguriert wurde. Das verrät ihr unter Umständen Dinge, die sie sonst nur mit Mühe und viel Noise herausgefunden hätte, wenn überhaupt. Will damit sagen: weniger kann manchmal mehr sein.

Ist es eine Aufforderung oder eine Feststellung?

Moin, ich würde es durchaus als geplanten Task laufen lassen, den Task jedoch als SYSTEM einplanen und nicht an Zeit, sondern an die Event Id 6273 binden. Dann kannst Du dich austoben - email verschicken, Textdatei schreiben, was auch immer.

Moin, obwohl Du mit Active Directory lange vertraut bist, können wir uns bitte darauf einigen, dass es "das" AD und nicht "die" AD ist? Mir konnte bisher noch niemand zusammenhängend erklären, wie man da auf das Femininum kommt... Aber was die Original-Frage angeht, ein Drucker-Admin wird nicht immer - und sollte heutzutage nie! - die Rechte haben, *irgendwelche* Objekte im AD anzulegen. Es ist auch ein super Angriffsvektor, wenn die Leute es gewohnt sind, Drucker aus dem Verzeichnis zu mappen...

Wo werden diese Zahlen angezeigt? In Windows oder im BIOS? 448 ist ja genau ein Riegel weniger (es könnte einer schlecht sitzen, kaputt sein, oder ein Slot im BIOS deaktiviert sein), 511 kann ein Rundungsfehler sein, wenn Windows gemeint ist (dann im BIOS gucken, und falls da 512 steht, ist alles gut). Was sagt msinfo32 dazu?

Und obwohl die Zahl von 86400000 ausreichend hoch sein sollte , ist meine Sorge, dass wir da irgendein Übersprechen des Default-Verhaltens und GPO haben. Finde die Policy, die das steuert (s.o.), setze einen vernünftigen Wert (1000 oder so) und schau, obs besser wird.

1 bedeutet Group Policy

Moin @_Lars_, kannst Du mal bitte die Ausgabe von Get-WMIObject Win32_TSSessionSetting -Namespace "Root\CIMv2\TerminalServices" posten?

Ich kann bestätigen, dass bei zwei frisch installierten 24H2-Maschinen das Verhalten genau so ist. Hab's jetzt in den MVP-Kanal geschickt, mal sehen, was rausfällt.

Tru dat. Ich kenne die Ausgabe von Deinem Skript nicht auswendig, dachte, das käme vielleicht von netstat - aber da wäre LISTENING ja groß geschrieben...

Sorry wenn das schon beantwortet wurde... aber ist die Regel auch für das Profil aktiv, welches die Zielmaschine auch tatsächlich erkannt hat? Die Regel gibt's ja für Domäne und Privat getrennt, zumindest sehe ich das auf einer frischen Maschine so...

Moin, ich dachte, das wäre weggepatcht worden, aber versucht mal, RC4 auf Domain Controller-Ebene wieder zuzulassen, zumindest bis alle Maschinen ihr Kennwort gerollt haben.

das war auch meine Vermutung - impliziert aber eine andere Interpretation von "günstig", als für die meisten Kunden üblich, die nur einen 2-Node-Cluster haben

Moin, das darunterliegende Protokoll - iSCSI., FC, SAS - hat nichts damit zu tun, wie zuverlässig das ganze funktioniert. Das Besondere an iSCSI *könnte* sein, dass Windows nur die ersten 10(?) Buchstaben des Maschinennamen für die IQN-Generierung verwendet. Wenn die Nodes also "HYPERVSERVER01" und "HYPERVSERVER02" heißen, ist es für das SAN derselbe IQN. Da kann es zu Fehlern kommen. Daher sollte man die IQNs kontrollieren und bei Bedarf anpassen, bevor man das ans SAN anschließt oder die LUNs für dieses Pärchen freizont. Die Cluster-Vorprüfung sagt Dir das übrigens, weil die SCSI-Reservierung nicht übertragen werden kann.

Das mit den LUNs erklärt sich wie folgt: Windows kennt zwei Filesysteme: NTFS und CSVFS (cluster shared volume filesystem). Ein NTFS-Volume darf nur einen Master haben, daher wird der erste Host, der die LUN mounten, das Filesystem sehen können. CSVFS ist aufgebohrtes NTFS, das um die Möglichkeit ergänzt wurde, dass mehrere Windows-Server auf das gleiche Volume gleichzeitig zugreifen. Voraussetzung dafür ist, dass sie in einem Cluster sind. Alternative wäre SMB3. Wenn Dein SAN auch NAS kann, und dieses SMB3 kann, könntest Du die VMs in einer SMB3-Freigabe platzieren. Dann können auch ohne Cluster mehrere Hosts auf den gleichen Datenbestand zugreifen. Hyper-V im AD sehe ich ähnlich wie @NorbertFe - die Tatsache, dass Domain Controller dort laufen, macht die Hyper-V- und Storage-Infrastruktur zu Tier 0, unabhängig von der Domänenmitgliedschaft. Wird das auf der ganzen Strecke respektiert, kann man das durchaus so fahren. Ist aber mit ESXi nicht anders. P.S. Und ja, ich weiß, dass Windows noch ReFS und FAT kann

Was spricht gegen einen Custer? Geht inzwischen sogar ohne AD.

Hallo zusammen, das August-Update für Windows Server 2025 behebt das Problem. Happy patching!

yup, funktioniert.

Moin, das mit DC und Terminalserver, das war mal. Dass man das nicht machen sollte, ist eine separate Diskussion, aber technisch hat Essentials schon immer darauf gesetzt. Die Fehlermeldung ist doch sehr eindeutig: Ein ausstehender Neustart blockiert das Hinzufügen eines neuen Features. Das konnte Dir auch mit 2016 passieren.

Ich weiß nicht. PF sind ja so ein bisschen wie File Shares. Der "moderne Weg" scheint zu sein, jeder speichert Zeugs bei sich und "teilt" es mit anderen. In einer Cloud-Welt, wo jeder Zugriff durch Purview gejagt wird, mag das funktionieren, aber sonst?