NilsK

Moin, du sagst ja, dass dir die Argumente gegen Pass-through Disks bekannt sind. Viel mehr gibt es dazu eigentlich auch nicht zu sagen. Rein technisch geht es, auch in Cluster-Konstrukten. Die Nachteile und Fehlermöglichkeiten sind aber so umfangreich, dass man das nicht machen will. Für Guest-Cluster nutzt man üblicherweise per iSCSI (oder seltener vFC) in die VMs eingebundene LUNs. Oder man setzt auf Shared-VHDX (2012/R2) bzw. VHD Sets - von denen liest man aber leider auch oft, dass sie nicht so zuverlässig sind, wie man das braucht. Wie ist denn das Storage bei dem derzeitigen physischen Cluster angebunden? Wenn es eine LUN aus dem Storage ist, kann man die vielleicht sogar so lassen, wie sie ist, um sie an die VMs durchzureichen. Gruß, Nils

Moin, dann sag das doch gleich. Leider ist es in Foren üblich, nur eine Detailfrage zu stellen, statt zu sagen, worum es geht. Das behindert die Sache unnötig - der Thread hätte schon viel schneller eine Antwort liefern können. Also: Natürlich geht das, es ist in solchen Szenarien sogar durchaus üblich. Du kannst einen DNS Secondary einrichten, der sich die DNS-Daten (und nur diese) von einem DC/DNS holt. Solange es sich um einen Nur-Lese-Zugriff handelt, ist das auch ein gangbarer Weg. Ob sich damit allerdings die Anforderungen erfüllen lassen, lässt sich aufgrund der eher unscharfen Äußerungen dazu nicht ablesen. Der beschriebene Secondary würde alle DNS-Einträge enthalten und abfragbar machen, da können durchaus personenbeziehbare Daten dabei sein (z.B. Namen von PCs, die zu bestimmten Mitarbeitern gehören - etwa "PC-MEYER"). Hier wäre also ggf. ein Blick auf die genauen Anforderungen und die Details der Umgebung relevant. Gruß, Nils

Moin, das kommt darauf an, wie das Storage die Disk bzw. LUN bereitstellt. Theoretisch könnte man die LUN im Storage als Cluster-LUN definieren und dann an zwei Hosts anbinden, um sie von dort aus als Pass-through in VMs weiterzuleiten. Voraussetzung ist dann allerdings, dass die VMs den Zugriff so koordinieren, dass keine gleichzeitigen Schreibzugriffe nötig sind - was in der Praxis bedeutet, dass die VMs einen Cluster bilden müssen (sofern wir von Windows sprechen). In dem Fall wäre es aber nicht sinnvoll, mit Pass-through zu arbeiten - wenn es eine Cluster-LUN im Storage gibt, sollte man die stattdessen über iSCSI oder vFC direkt an die VMs anbinden, statt den (fehlerträchtigen) Umweg über die Hosts zu gehen. Mit lokalen Disks dürfte das überhaupt nicht mögllich sein. Geht es nur um einen Host und lokale Disks, dann bedeutet das Zuweisen einer Pass-through Disk, dass diese exklusiv der betreffenden VM zur Verfügung steht. Jetzt wäre natürlich wichtig zu wissen, was denn die dahinterstehende Anforderung ist ... Gruß, Nils

Moin, vielleicht können wir hier ja einfach mal das Missverständnis aufklären. Die lokalen Peer-to-Peer-Updates sind für Netzwerke gedacht, in denen es keinen WSUS gibt. Kleine Netze oder z.B. kleine Außenstellen. Da spart man Traffic und eben den Aufwand eines WSUS. Wenn ein WSUS vorhanden und gut angebunden ist, ergeben die Peer-to-Peer-Updates keinen Sinn. Gruß, Nils

Moin, das verstehe ich durchaus. Aber dafür ist die verfügbare Bandbreite sehr wahrscheinlich zu knapp, um wirklich ein zuverlässiges Verfahren dieser Art aufzubauen. Es bringt ja auch nichts, wenn wegen der Einschränkungen ständig manuell nachgebessert werden muss und man sich im Fall des Falles nicht darauf verlassen kann. Daher würde ich, wenn ich verantwortlich wäre, die Idee nicht weiter verfolgen, jedenfalls nicht, wenn die Änderung der Rahmenbedingungen keine Option ist. Gruß, Nils

Moin, und die 20 Mbit sind übrig? Oder hat der Kunde die evtl. deshalb, weil er sie bereits braucht, z.B. für "Internet"? Nee, da wird kein Schuh draus. Für was für ein Desaster plant ihr denn, dass es ein anderer Standort sein soll? Und wenn das eintritt, können die Leute in der Zentrale dann wirklich noch arbeiten? Was macht der Kunde, wenn kein Ausfall vorliegt, sondern ein logischer Fehler, der Original und Replikat beschädigt? Falls in dem Fall das Recovery vom Backup reicht, warum nicht in anderen Fällen? ... so die Richtung ... Gruß, Nils

Moin, und was genau sagt er auf den Hinweis, dass selbst mit einem Kennwort auf dem Dateiserver ohne die Sperrung des Desktops jeder auf die lokalen Daten seines Rechners zugreifen kann? Sollte es sich hier um den einzigen User weltweit handeln, der nur auf dem Dateiserver arbeitet und keine Daten lokal hält? Gruß, Nils

Moin, der Beschreibung nach sollte Get-WinEvent in der PowerShell auch mit den Dateien klarkommen. Vielleicht geht's damit. Gruß, Nils

Moin, vermutlich an 23 Druckern, zu denen eine Netzwerkverbindung hergestellt werden muss. Klingt nicht unbedingt nach Wunschdesign. Trotzdem gibt es ja offenbar Netzwerkprobleme, jedenfalls deuten deine Logs darauf hin. Das verstärkt das Problem mindestens, anscheinend sorgt es aber auch direkt für Fehler. Gruß, Nils

Moin, dann hab ich ja noch Glück gehabt, dass du mir das gesagt hast, kein Kunde. Gruß, Nils

Moin, Alter, muss sich denn alles ändern? Dafür bin ich mittlerweile zu alt. Also, du hast natürlich auch hier Recht. Offenbar gibt es Windows 10 Enterprise auch ohne SA. Ich bin mir ziemlich sicher, dass früher die Enterprise-Fassung eine SA vorausgesetzt hat. Anscheinend ist das nicht mehr so. Damit ist meine obige Aussage jetzt unvollständig und Zahnis Ergänzung notwendig. Das VDA-Recht hängt an der SA. Wenn man eine Umgebung plant, sollte man mit einem kundigen Berater immer prüfen, ob das konkrete Szenario wirklich abgedeckt ist - bei dem macOS-Szenario bin ich mir gerade nicht mehr so sicher, ob das wirklich drin wäre. Gruß, Nils

Moin, ja, nimm die 015 raus. Das braucht man nicht, und es führt im Zweifel nur zu Problemen - so etwa in deinem Szenario. Gruß, Nils

Moin, hm, ja, stimmt. Bei 2008 war es 1+1 (Host und 1 VM). das ist korrekt, aber Enterprise setzt ohnehin SA voraus. Ohne SA gibt es nur Professional. Nimmt man zu Professional die SA hinzu, hat man Enterprise. Das VDA-Zugriffsrecht ist ein SA-Feature, insofern hast du natürlich Recht. Gruß, Nils

Moin, ich glaube, du hast diese Optionen nicht richtig verstanden. Abgesehen davon, ist ein lokaler Admin eben lokaler Admin. Maßnahmen wie die genannten können evtl. in einem Gesamtkonzept eine Rolle spielen, aber es gibt kein kleines, überschaubares Set von Einstellungen, das Sicherheit "herstellt". Solange nicht klar ist, was denn erreicht werden soll und vor welchen konkreten Gefahren du dich schützen willst, kann man keine passende Lösung entwerfen. Wobei je nach Anforderung eine Lösung durchaus ein größeres Projekt zur Entwicklung erfordern kann. Allgemeine Anregungen findest du im Web zuhauf. Wenn dann konkrete Fragen bestehen, können wir die gern diskutieren. Gruß, Nils

Moin, mit der einen Lizenz ist der Host lizenziert (solanger er nur Host ist) und zwei Windows-Server-VMs. Das ist seit Windows Server 2008 so. https://www.youtube.com/watch?v=6tH3QGSRP00 Gruß, Nils

Moin, lol. Du sprichst wahr. Wenn man mehr darüber wüsste, wie denn die Umstellung geplant ist und wie groß das Netz ist, könnte man mehr Sinnvolles dazu sagen. Vorausgesetzt, das Routing zwischen beiden Netzbereichen ist sichergestellt, dann sollten sich Aufwand und Risiko in Grenzen halten. Du könntest dann DC1 ins neue Netz stellen und DC2 zunächst im alten Netz belassen. Die weiteren Server und die Clients stellst du sukzessive um. Gegen Ende kommt DC2 dann auch ins neue Netz. Parallel mehrere IP-Adressen für die DCs würde ich eher nicht machen. Mit Routing ist das auch nicht nötig. Also im Wesentlichen bei DC1 die neue IP-Adresse eintragen, Anmeldedienste neu starten und nach ein paar Minuten prüfen, ob die DNS-Einträge sich aktualisiert haben. Falls nein, manuell korrigieren. Später dasselbe Spiel mit DC2. Ich sehe da eigentlich kein ernsthaftes Problem. Gruß, Nils

Moin, du brauchst 1 Lizenz Windows Server 2016 Standard, 1 Lizenz Windows 10 Enterprise (für die Client-VM) und pro Client 1 2016-CAL (egal welches OS). Enterprise deshalb, weil dort m.W. die Lizenz auch den Zugriff auf die Client-VM enthält. Du lizenzierst bei Server-VMs immer den Host, nie die VMs. Die Standard-Lizenz umfasst 2 VMs mit Windows Server. Gruß, Nils

Moin, ja, im Wesentlichen musst du sicherstellen, dass alle Clients alle Namen richtig auflösen können. In der Koexistenzphase bedeutet das ohnehin alle Namen aus der alten und der neuen Domäne. Ob man das per Forwarding macht, per Stub-Zone, per Secondary oder wie auch immer, ist aus der Sicht nebensächlich. Natürlich müssen auch die IP-Grundinformationen stimmen, das Gateway etwa. Dann ist es während der Migration egal, welchen DNS-Server die Clients fragen, das könnte durchaus der "alte" sein. Irgendwann ändert man das im DHCP und gut. Mit "Sonderlocken" meinte ich sowas wie WINS-Server, Domänennamen oder so, halt die (wenigen) Sachen, die man Windows per DHCP so mitgeben kann. Das müsste man dann rausnehmen, falls es bisher vorhanden war. Alles Weitere kann man nur beurteilen, wenn man sich genau mit der Umgebung beschäftigt. Das kann gar nichts sein oder eine ganze Menge ... Gruß, Nils

Moin, dann klingt das nach Routingproblem. Das würde auch die Logmeldungen erklären. Gruß, Nils

Moin, auf deinem Screenshot von dem Client ist ein aktives VPN zu sehen, parallel zur LAN-Verbindung. Solche Konstrukte führen regelmäßig zu dem von dir beobachteten Problem. Gruß, Nils

Moin, ja, das ist richtig. Das Thema wird auch schon eine Weile in der Microsoft Product Group diskutiert, aber die bekannten Fälle scheinen im Detail so unterschiedlich zu sein, dass es dort nicht vorangeht. Daher wäre ein Supportcall weiterhin empfehlenswert - vielleicht löst der das Problem, aber wenn nicht, dann ist das wenigstens ein zusätzlicher offizieller Problemhinweis an den Hersteller. Gruß, Nils

Moin, ich tippe mal auf das VPN, das dem Client da in die Quere kommt. Gruß, Nils

Moin, man testet nicht in einer Produktionsumgebung. Auch nicht auf "unkritischen" Servern. Punkt. Die Veeam-Checkpoints funktionieren aber? Das wäre schon mal gut. Trotzdem oder gerade deswegen: Supportcall. (Falls ich es noch nicht empfahl.) Gruß, Nils

Moin, ja, DHCP kann ein Grund für eine Trennung sein. Die muss dann aber physisch sein (eigenes Netz, mindestens eigenes VLAN), ein separater IP-Kreis reicht dann nicht. (Ich sehe gerade, dass DHCP schon in der Eröffnung erwähnt wurde, das hatte ich erst übersehen.) Ein zwingender Grund ist das allerdings auch nicht. Durch passendes Design bekommt man auch das hin, solange man per DHCP keine Sonderlocken verteilt. Gruß, Nils

Moin, naja ... das würde ich differenziert sehen. Solange es sich um eine kleine bis mittelgroße Umgebung handelt und "selbes IP-Netz" einfach nur das IP-Segment bezeichnet, sehe ich überhaupt kein Problem. Etwas Sorgfalt muss natürlich sein, aber sonst interessiert sich das AD nicht besonders für andere Systeme im selben Subnet. In einer größeren Umgebung mag das etwas anders aussehen, aber da sehe ich auch nur operative Gründe für eine Subnet-Trennung, keine technischen. DNS und alle anderen Infrastrukturdienste kann und muss man natürlich sorgfältig planen, einrichten und betreiben. Aber das gilt für getrennte Subnets genauso wie für ein gemeinsames. Besonders die DNS-Auflösung muss während der Koexistenz ja auch domänenübergreifend funktionieren, das ist in der Praxis eher der Knackpunkt. Da man bei einer Domänenmigration für eine funktionierende Netzwerkkommunikation sorgen muss, kann eine zusätzliche IP- und VLAN-Aufteilung erheblichen Zusatzaufwand bedeuten, das würde ich schon gegeneinander abwägen. Gruß, Nils