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

Ok, alles gute Argumente. Habe aber gerade gelesen dass ich für Server 2025 Workgroup Cluster Zertifikate brauche... Keine CA, wird schwierig. Wenn mir da unser Rechenzentrum nicht gnädigerweise Zertifikate ausstellt wird das nix. Mal schauen. Gibt ja jetzt genug für und wieder, muss nur noch sehen welche "Probleme" ich lösen kann und mit welchen Einschränkungen ich leben kann/will. Auf jeden Fall schon mal danke für die Beteiligung!

Na ja, kein LAPS zum Beispiel. Logisch. Wieder das leidige Thema des regelmäßigen Passwort änderns auf lokalen Admin-Konten. Und logischerweise auch kein protected Users Gruppe, die ich bei meinen administrativen Konten verwende. Aber ist wie immer, einen Tod muss man sterben Werde mir das ganze nochmal in Ruhe anschauen und testen sobald die Hardware da ist.

Hmm. Habe mir gerade mal ein Video von Manfred Helber und Carsten Rachfahl zu dem Thema angeschaut... Hat ja schon den ein oder anderen Nachteil in Sachen Bedienung, u.a. wohl auch keine Remote-Verwaltung mit dem WAC... Klingt jetzt erstmal nicht so wie das was man gerne hätte

Ok, danke erstmal für die zahlreichen Antworten Ich fasse mal zusammen: - mehrere Hosts gleichzeitig Schreiben/Lesen auf einem Nicht-SMB Storage geht nur mit Cluster - zwei Hosts sind ausreichend um einen Cluster zu erstellen - Cluster ohne AD ist möglich, will man aber eigentlich nicht... - Hyper-V Hosts im AD sind Tier 0 und daher entsprechend abzusichern - @NorbertFe: Wenn da nicht Broadcom wäre, hätte ich ESXI hier sicher noch lange im Einsatz Nützt aber nix, VMware muss raus, von Proxmox bin ich (noch) nicht überzeugt. Also Hyper-V.

Ok, ich müsste auf dem SAN dann also zwei LUNS anlegen und jeweils eine LUN mit einem Host verbinden? Dann kann ich aber die VM nicht einfach auf nem anderen Host registrieren wenn ich das richtig verstehe. Nicht so schön, war in vSphere besser gelöst. Da kann ich eine LUN mehreren Hosts zuweisen ohne dass es Probleme gibt. Wäre dann wohl doch der Cluster das Mittel der Wahl... Welche Einschränkungen ohne AD wären das?

Na ja, habe nur 2 Hosts. Bei VMware waren für einen Cluster mindestens 3 Hosts vonnöten... Gibt's bestimmte Voraussetzungen für einen Cluster ohne AD? Ich möchte die Hosts ungern in's Produktions-AD aufnehmen und ein eigenes AD für zwei Hosts macht ja auch wenig Sinn...

Hallo liebe Kollegen, bei uns steht bald die Migration von VMware zu Hyper-V an. Unsere VMware-Umgebung besteht aus zwei Nicht-Cluster-Hosts, die auf ein gemeinsames SAN zugreifen. Ohne VMotion etc, aber mit der Möglichkeit die VM's auf dem jeweils anderen Host bei Bedarf zu registrieren. Ja, SAN ist Single-Point-Of-Failure, ist aber so akzeptiert. Jetzt ist die Frage: Kann ich das auch in Hyper-V so konfigurieren, dass sich zwei Standalone-HyperV-Hosts sich ein SAN teilen? Muss da noch etwas konfiguriert werden damit sich die beiden Hosts am SAN nicht "in die Quere kommen"?

Bei unserer Größenordnung wird der Anwalt vermutlich teurer als die Ersparnis... Dann lieber Finger weg

Hat jemand schon mal etwas mit der Firma Vendosoft zu tun gehabt? Ich habe hier ein Angebot über "gebrauchte" Lizenzen Office 2024 LTSC, 60 € günstiger als aus dem Rahmenvertrag unseres Rechenzentrums... Das ganze mit Ordentliche Rechnung und Lieferschein Vernichtungserklärung Erklärung zum Nutzungsrecht Datenträger (Microsoft Produkte) Installationsmedium & Product Key (Digital: Download-Link + Key) Bestätigung der Lieferkette durch die Wirtschaftsprüferkanzlei Brune Timmer Schlüter Part mbB (ab 3.500,00 € Netto-Einkaufswert) Lieber Finger weg oder realistisches, legales Angebot? Bin da immer eher skeptisch...

Sieht bisher gut aus, seit setzen der GPO auf oberster Ebene ist Ruhe