Marco31

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...

Habe gerade das Problem und die Lösung gefunden. Im MSFT-Video zur Einrichtung des Workgroup-Clusters wird in der besagten GPO der Hostname als FQDN eingegeben, das scheint aber entweder falsch oder nicht ausreichend zu sein. Ich habe jetzt einfach den Hostnamen ohne Suffix eingegeben und schon funktioniert es! Ich habe auf beiden Nodes einen gleichlautenden User mit lokalen Adminrechten und gleichem PW angelegt.

Hallo Leute, soweit läuft der Cluster, Test-VM lässt sich auch verschieben und auch Livemigration funktioniert. Ich habe nur das Problem, dass eine Fehlermeldung kommt wenn ich versuche, im Clustermanager eine VM auf einem anderen Konten zu verwalten. Es kommt eine WinRM Fehlermeldung: Fehler beim Vorgang auf Computer "Hyperv02": Der WinRM-Client kann die Anforderung nicht verarbeiten. Wenn das Authentifizierungsschema nicht Kerberos ist oder der Clientcomputer nicht Mitglied einer Domäne ist, muss der HTTPS-Datentransport verwendet werden, oder der Zielcomputer muss der TrustedHosts-Konfigurationseinstellung hinzugefügt werden. Verwenden Sie "winrm.cmd", um TrustedHosts zu konfigurieren. Beachten Sie, dass Computer in der TrustedHosts-Liste möglicherweise nicht authentifiziert sind. Weitere Informationen hierzu erhalten Sie, indem Sie den folgenden Befehl ausführen: "winrm help config".. Habe aber die Hosts jeweils über GPO (Computerkonfiguration\Administrative Vorlagen\Windows-Komponenten\Windows-Remoteverwaltung\WinRM-Client\Vertrauenswürdige Hosts) eingetragen. Was ja auch die Fehlermeldung empfiehlt... Jemand eine Idee warum es trotzdem nicht funktioniert? Oder bin ich da am Holzweg?

Wird es denn Probleme geben wenn ich es so lasse wie jetzt? Bis jetzt läuft es soweit.

Danke Norbert, scheint so zu funktionieren. Seit der Änderung keine Fehler mehr

Hallo Leute, ich habe mit 2x Windows Server 2025 in einer Workgroup einen Failover-Cluster erstellt. Soweit läuft auch alles bisher. Die Hyper-V-Server hängen im gleichen Subnet wie die Domäne, habe beide Knoten per statischem Eintrag im DNS der Domäne registriert. Ansonsten habe ich die Einrichtung laut MSFT-Video durchgeführt, mit Einträgen der Hosts und des Clusters in der LMHosts. Nur wird mir für den zweiten Knoten alle 15 Minuten folgender Fehler geloggt: Protokollname: System Quelle: Microsoft-Windows-FailoverClustering Datum: 12.09.2025 08:23:08 Ereignis-ID: 1196 Aufgabenkategorie:Network Name Resource Ebene: Fehler Schlüsselwörter: Benutzer: SYSTEM Computer: Hyperv02.domain.local Beschreibung: Die Cluster-Netzwerknamensressource "Clustername" konnte mindestens einen dazugehörigen DNS-Namen nicht registrieren. Ursache: Im Sicherheitspaket sind keine Anmeldeinformationen verfügbar. . Stellen Sie sicher, dass die Netzwerkadapter, die mit den abhängigen IP-Adressressourcen verknüpft sind, für den Zugriff auf mindestens einen verfügbaren DNS-Server konfiguriert wurden. Ereignis-XML: <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"> <System> <Provider Name="Microsoft-Windows-FailoverClustering" Guid="{baf908ea-3421-4ca9-9b84-6689b8c6f85f}" /> <EventID>1196</EventID> <Version>0</Version> <Level>2</Level> <Task>19</Task> <Opcode>0</Opcode> <Keywords>0x8000000000000000</Keywords> <TimeCreated SystemTime="2025-09-12T06:23:08.1203823Z" /> <EventRecordID>10041</EventRecordID> <Correlation ActivityID="{ae6af8d4-d0db-4319-a11e-a88babc13e29}" /> <Execution ProcessID="12424" ThreadID="12056" /> <Channel>System</Channel> <Computer>Hyperv02.domain.local</Computer> <Security UserID="S-1-5-18" /> </System> <EventData> <Data Name="ResourceName">Clustername</Data> <Data Name="StatusString">Im Sicherheitspaket sind keine Anmeldeinformationen verfügbar. </Data> </EventData> </Event> Es soll also der Clustername im DNS zu registriert oder aktualisiert werden, was dann nicht funktioniert... Wenn ich im DNS einen statischen Eintrag für den Clusternamen eintrage löst es das Problem auch nicht. Jemand eine Idee wie ich dieses Problem lösen kann?

DAS nenne ich mal nen guten Tip, danke!

Da hast du ohne Frage Recht, ich kann nur sagen dass es vom RZ so eingerichtet wurde Die werden ihre Gründe haben.

Hmm. Ok. Genau für das habe ich ja bereits von meinem RZ (LDAPS wegen Exchange-Anbindung), Root-CA des RZ in den vertrauenswürdigen Stammzertifizierungsstellen sowie Zertifikate für die DC's jeweils in "Eigene Zertifikate". Ich bin aber ehrlich gesagt gerade zu b***d zu verstehen, wie mir das bei Mitgliedsservern oder dem Workgroup-Cluster weiterhelfen kann...?