cj_berlin

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.