cj_berlin

"die es im Idealfall nicht gibt" ist das Stichwort. Ein Securty-Konzept, das von dem Idealfall ausgeht, ist nicht sehr nachhaltig Hafnium und Log4j lassen grüßen.

Wenn Pass-the-Hash in der Umgebung möglich ist, vielleicht lieber nicht darüber nachdenken. Diese Guidance, der sich inzwischen auch NIST angeschlossen hat, scheint nur eine Welt zu kennen, wo ein potentieller Angreifer vor einer Maske sitzt und da Passwörter im Klartext eingibt... Da würde ich sogar mitgehen

Moin, "geht nicht" ist keine Fehlermeldung von Windows. Welche bekommst Du denn?

...und, natürlich, wer schon vor Jahren das Feature ausgerollt hat, dessen Name mir nicht einfällt (wenn nicht bereits im Request ein passendes Client-Zertifikat enthalten ist, gar nicht antworten), kann sich jetzt entspannt auf die Schulter klopfen

Moin, wenn die Idee ist, die Umgebung nach dem Kauf weiter zu benutzen, würde ich allerdings - das habe ich jetzt nicht gesagt - eher mit nicht aktivierten Prod-Installationen arbeiten statt mit Eval, denn Eval musst Du nach dem Kauf explizit konvertieren, und das gelingt zwar immer öfter, aber halt nicht immer

Hallo zusammen, mir ist neulich durch Zufall aufgefallen, dass mein Server 2025 Hyper-V Host (die Hardware ist von ca. 2019, 2x XEON E5) bei allen VMs die CPU-Auslastung mit konstant 0% anzeigt. Mein anderer Server 2025 Hyper-V Host (relativ frischer i7-Prozessor) zeigt Werte, die in etwa den Erwartungen entsprechen. Heute meinen privaten Rechner (i7-Notebook von 2019) auf 24H2 upgedatet, selbes Bild - egal, wieviel die VMs zu tun haben, auf dem Host ist die CPU-Last bei 0%. Hyper-V PowerShell-cmdlets zeigen das gleiche Verhalten. Kann das jemand bestätigen? Stimmt mein Eindruck, dass das Phänomen sich bei älteren CPUs zeigt? Oder habt ihr andere Erfahrungen? Danke und einen schönen Sonntag allen!

Server 2025 könnte SMB über QUIC auf verschiedenen Ports per Share... Muss der Client aber auch erst mal können. Ansonsten kannst Du dir vielleicht Dynamic Access Control anschauen, das ist aber ein Rabbit Hole, wenn man damit anfängt.

Das ist wo man sich dann hinfassen darf, wenn das ganze nicht performt.

Naja, ein "NAS" ist ja nicht zwingend eine kleine Syno. Ich habe sehr gute Erfahrungen mit Hyper-V und SQL auf SMB3-Freigaben, sowohl von Windows als auch von einer "enterprise grade third party" bereitgestellt.

Ja, so würde es gehen, aber ich würd's trotzdem nicht machen In Ruhe ein Cluster bilden und Failover testen können ist Gold wert.

Moin, um den zweiten Teil der Frage zu beantworten: Downtime musst Du schon einplanen. Besonders wenn - und das ist meistens zu bevorzugen - der Shared Storage tatsächlich als Block und nicht als File betrieben wird. Denn dann werden die LUNs als Cluster Shared Volumes betrieben, und die gibt es erst, wenn das Cluster gebildet wurde. SMB-Storage von einem Feld- und Wiesen-NAS würde ich persönlich nicht riskieren wollen, funktioniert aber, wenn das NAS einen SMB3-Dialekt spricht.

Moin, erstens, bei all seinen Verdiensten für die PowerShell-Community, ist nicht alles, was Adam Bertram sich überlegt hat, als "best practice" zu bezeichnen. Zweitens, es gibt sehr viele Entwickler, die zu PowerShell nicht von CMD/VBS/bash, sondern von C++/C#/etc. gekommen sind, wo starke Typdefinitionen vorgeschrieben sind. Diese Leute versuchen, das Bekannte auch in PowerShell durchzusetzen, meistens mit mäßigem Erfolg, weil PowerShell sich strikt weigert, ein "strongly typed language" zu werden. WENN Deine Funktion immer denselben Typ zurückgibt, kann es IntelliSense verbessern, wie Du auch bemerkt hast, wenn Du diesen auch in der Definition der Funktion angibst. Wer funktionale Programmierung lange und in großem Stil betrieben hat, wird vermutlich zustimmen, dass es an sich eine sehr gute Idee ist, wenn jede Funktion immer den gleichen Ergebnistyp zurückgibt. Das schreibt auch Uncle Bob irgendwo in "Clean Code", wenn ich mich recht erinnere. Nur ist es in Skriptsprachen in der Regel eher hinderlich, solche Restriktionen aufzuerlegen. Aber wenn Dein Skript- oder Moduldesign das hergibt, gibt es Dir ein zusätzliches Quentchen Sicherheit, wenn Du weißt, was Du von welcher Funktion zurück bekommst.

Wenn Du Windows Server-Workloads fährst, musst Du diese Lizenzen betrachten. Sollte es sich um so viele VMs handeln, dass Datacenter-Lizenzen bereits wirtschaftlicher sind als eine Anhäufung von Standard, kostet Dich das Windows-Cluster selbst mit S2D an Software nichts (zusätzlich). Wenn das oben aufgeführte NAS als Shared Storage für das Proxmox-Cluster fungieren soll, hast Du zwar Hochverfügbarkeit im Compute geschaffen, aber nicht im Storage. Das kannst Du mit einem Windows-Cluster auch genau so abbilden, selbst mit Standard-Lizenzen (die Du für die VMs eh brauchst). Kostet also an Software wieder nichts (zusätzlich).

Moin, auf dem DC listen diese Widgets, und auch NET USER, und auch Get-LocalUser, die Domain User auf. Das bedeutet nicht, dass sie auf dem DC ein Userprofil haben oder sich dort anmelden dürften. Insofern hast Du security-technisch vermutlich kein Problem, oder zumindest ist es nicht dadurch ersichtlich, dass diese User auf der Liste auftauchen. Mach GPRESULT /H auf dem DC und such nach der Einstellung "Diese Systemsteuerungssymbole einblenden" oder so ähnlich. Findest Du sie, dann wird daneben stehen, aus welcher Policy sie kommt.

OK, das sind zwei Fragen. 1. sind die User wirklich lokal oder sind das Domain-User? Falls es Domain-User sind, hast Du kein Problem. 2. warum ist das Control Panel-Widget aufrufbar? Da ist scheinbar wirklich eine Policy, die für DCs nicht gedacht war, auf diese angewendet worden. GPRESULT liefert Dir den Namen der Policy. Falls die User *wirklich* nicht Domain User sind, müsste man das troubleshooten.