Marco31

Habe einen kleinen Hyper-V Workgroup Cluster, 2 Hosts 2025. Als Storage ein SAN als shared Storage. Läuft seit ca nem dreiviertel Jahr ohne Probleme. Livemigration läuft super 😉

Oh Mann, das waren noch Zeiten 👍😂 Nächtelang Maniac Mansion und Pirates! (Sorry für Off Topic)

Was glaube ich den wenigsten bekannt ist, in verwalteten Umgebungen ohne Windows Update läuft da gar nichts automatisch wenn ich das ganze richtig Verstehe... Microsoft entscheidet wohl anhand von Telemetriedaten, ob und wann Maschinen den Updateprozess für die Zertifikate anstoßen. Hat man die Telemetriedaten blockiert (vielleicht reicht auch Beschränkung) wird da vermutlich nix passieren... Die Windows Updates bringen wohl nur die notwendigen Daten mit, installieren aber NICHT die Zertifikate. Daher muss mal wohl selbst tätig werden und die entsprechenden GPO's konfigurieren und dann überwachen, ob die Zertifikatsupdates durchlaufen. Hyper-V-VM's sollen da angeblich auch Probleme machen, hatte da ein paar Sachen gefunden bei Google, habe aber da noch nicht angegriffen da ich mich erstmal den Clients gewidmet hatte und noch eine Möglichkeit suche, das ganze vernünftig zu überwachen. Hier ein ganz guter Artikel zum Thema: Update der UEFI-Zertifikate für Secure Boot: Microsoft bringt 3 neue Gruppenrichtlinien | WindowsPro Und hier ein paar Skripte: GitHub - cjee21/Check-UEFISecureBootVariables: PowerShell scripts to check the UEFI KEK, DB and DBX Secure Boot variables as well as scripts for other Secure Boot related items. (ob man da fremde Skripte benutzen möchte bleibt jedem selbst überlassen ) Wundert mich dass man so wenig drüber liest, könnte sein dass da die nächste "plötzliche" Katastrophe zurollt

Darf ich fragen wie du das über Docusnap auswertest? Hört sich nach ner guten Idee an😉

Das ist der Druckdialog, nicht die Druckwarteschlange... Trotzdem danke für den guten Tipp

Hallo Leute, ich hatte jetzt schon mehrfach das Problem, dass unter Windows 11 Dokumente nicht gedruckt werden und in der Druckwarteschlange stehen. Gehe ich aber in die Druckwarteschlange (die "tolle" neue App), wird da rein gar nichts angezeigt... Die Druckaufträge sind aber definitiv da, beim Neustart des Clients werden diese sofort gedruckt... Kennt jemand das Problem, gibt es eine Möglichkeit die "alte" Druckwarteschlange zu nutzen?

Für Admins wohl eher keine gute Idee... Habe das nur für die User Accounts geblockt...

ABE funktioniert dafür absolut perfekt!

Da gebe ich dir ja absolut recht, aber wie soll man sowas lösen? Ich habe zum Thema "Rechenzentrum" schon Dinge mitbekommen, die darf man niemandem erzählen... Zumindest mich hat die Geschichte mit Südwestfalen-IT kein bisschen erstaunt, es wundert mich eher dass da nicht noch mehr kam in letzter Zeit. Wenn ich den Admin Approval Mode für den Built-In Admin aktivieren würde, wäre Veeam ja nicht mehr in der Lage sich am Hyper-V-Host anzumelden. Wie gesagt, Veeam außerhalb Domäne = entweder Built-In Admin oder UAC deaktivieren. Ist b***d, aber laut Veeam nicht zu ändern. Scheint auf jeden Fall zu funktionieren, habe mal ne Deny-All Inbound am Hyper-V-Host für eine Client-IP erstellt. Zugriff war vom entsprechenden Client auf den Hyper-V-Host nicht mehr möglich. Aber warum sollte ich das ganze auf den restlichen System umgekehrt auch implementieren? Wer erfolgreich am Hyper-V-Host ist kann ohne Probleme auf alle Server-VM's zugreifen, da hilft die Firewallregel nichts. Die einzigen Server bei denen das Sinn machen würde wären doch höchstens der Veeam Server und der physische DC? Oder habe ich da einen Denkfehler?

Klingt schon mal nach ner Idee... Also auf den Hyper-V-Hosts Deny für alle IP-Adressen der Hosts und Clients, abgesehen vom Backup-Server und dem Backup-Proxy... Aber würde ich damit dann nicht nur das Management-Netz der Hyper-V-Hosts beschränken, sondern auch das VM-Netz? Das wäre natürlich dann ziemlich b***d Wäre natürlich auch recht Wartungsintensiv in Sachen neue Hosts/Clients, je nach IP Range.

Die "Gründe" sind einfach; wir hängen an einem Rechenzentrum das die Firewall und das damit verbundene Routing kontrolliert. Da komme ich nicht dran. Leider reicht auch mein Know-How nicht aus, um z.B. einfach mal noch ne zweite Firewall "davor" zu setzen im Produktivnetz. Und Hilfe darf man da leider nicht erwarten, da ist Personal dünn gesät und gutes erst recht... Ich muss also erstmal mit dem klar kommen was ich habe und was ich beeinflussen kann.

Ja, da liegst du schon richtig. Es war auf jeden Fall der Gedanke, die Sicherheit damit etwas zu verbessern. Leider sind da halt dann die oben genannten Dinge, die das ganze dann wieder ins Gegenteil verdrehen... Ich hätte kein Problem mit zurück auf Anfang, dafür habe ich das ganze ja erstmal eher als Test aufgesetzt. Zurzeit habe ich ehrlich gesagt eher nicht die Einschätzung, dass der Hyper-V-Cluster in der Workgroup unter den oben genannten Voraussetzungen eine große Verbesserung der Sicherheit darstellt im Gegensatz zur Domänenmitgliedschaft.

Hallo Leute, ich schon wieder, sorry dass ich hier das Forum gerade mit meine Fragen bombardiere Aber ich muss hier Entscheidungen treffen mit denen ich dann vermutlich einige Jahre leben muss, daher ist jede Hilfe wertvoll. In dem Thread hier (https://www.mcseboard.de/topic/231670-frage-2-hyper-v-hosts-an-einem-san/) waren ja schon einige Stimmen pro und contra Hyper-V-Cluster in der Workgroup zu lesen. Leider hat sich jetzt durch Veeam B&R ein weiteres unschönes Problem ergeben; um einen Hyper-V-Workgroup-Cluster zu sichern, muss man auf den Hyper-V-Hosts entweder die Remote-UAC ausschalten oder für die Verbindung von Veeam zum Cluster DEN Administrator-Account auf den Hyper-V-Hosts nutzen. Eigentlich mal wieder zwei Dinge die man NICHT tun sollte... Jetzt stellt sich für mich die Frage welche Kröte ich schlucke; die oben genannten Fakten des Workgroup-Clusters oder packe ich den Cluster in meine Domain, wo ich alle Admin-Konten in den Protected Users habe (bis auf den einen, dessen PW liegt im Tresor), aber auch alle anderen Nachteile der Domänenmitgliedschaft habe; und eben auch die Vorteile der Verwaltbarkeit. Leider ist Netzwerksegmentierung und damit ein Management-VLAN aus Gründen (noch) nicht möglich, daher ist das derzeit keine Option die die Sicherheit erhöhen würde. Ich erwarte hier natürlich nicht "die Lösung" des Problems, letztendlich muss ich das ja selbst entscheiden. Ich würde aber gerne mal verschiedene Meinungen dazu hören, schadet ja nie...

Ok, das wäre dann durchaus eine Erklärung... Nächstes mal bin ich (hoffentlich) schlauer

In einer idealen Welt würde die Doku des Herstellers auch das gleiche Ergebnis zeigen wie das Video des Herstellers Spätestens wenn man dann beides sich zu Gemüte geführt hat darf man raten was richtig ist oder testen was funktioniert Microsoft ist schon toll...