NilsK

Moin, Wird vermutlich nicht helfen, aber du könntest es mal mit der Super-Kompatibilität "CompatibilityForOlderOperatingSystemsEnabled" versuchen: https://learn.microsoft.com/en-us/powershell/module/hyper-v/set-vmprocessor?view=windowsserver2025-ps EDIT: Um das kurz einzuordnen: Der beschriebene Fehler wird genau das sein, nämlich ein Fehler. Das mit der erweiterten Kompatibilität wäre jetzt eher als Test zu verstehen, wie weit sich der Fehler auswirkt. Und falls es mit der Einstellung dann doch ginge, wäre das ja auch was. Gruß, Nils

Moin, Am Ende würde es mit Internet Connection Sharing gehen, was ja nichts anderes als Routing ist. Dass es nicht geht, liegt an "eurer IT". Bevor das jetzt als Empfehlung verstanden wird: so ein Konstrukt (ICS im Host-OS) wäre eine Notlösung und ist für eine professionelle Server-Umgebung nicht zu empfehlen. Ihr werdet mit eurer IT zusammenarbeiten müssen, um eine funktionierende Lösung zu finden. Gruß, Nils

Moin, Alle VMs sollen über das VPN nach außen kommunizieren, ohne dass sie das VPN selbst aufbauen müssen? Dann brauchen sie einen Router, der dafür sorgt. Die Netzwerkverbindung des Hosts hat mit den Netzwerken der VMs nichts zu tun. Auch wenn Hyper-V scheinbar "unterhalb" von Windows Server läuft, ist das Gegenteil der Fall: die Verwaltungsinstanz von Hyper-V ist technisch betrachtet nur eine VM wie alle anderen auch. Deren Netzwerktraffic ist also von den Netzwerken der anderen VMs getrennt. Ein VPN im Host-OS steht nur diesem Host-OS zur Verfügung. Gruß, Nils

Moin, vielleicht sollten wir erst mal etwas sortieren. VMware gibt es immer noch. Es ist nur von einer anderen Firma gekauft worden und kostet in den meisten Szenarien eine Ecke mehr als vorher. Den "kostenlosen" ESXi gibt es auch wieder, allerdings nur für Testzwecke. Hyper-V gibt es ebenfalls immer noch, und es war schon immer eine Rolle in Windows Server. Es ist aber trotzdem ein "Bare-Metal"-Virtualisierer, keine Desktop-Software wie VirtualBox oder so. Du kannst also bei VMware bleiben oder auf Hyper-V umsteigen. In einem Fall kannst du dein Know-how weiter nutzen, im anderen minimierst du die Lizenzkosten, weil du mehr als die Windows-Serverlizenzen nicht brauchst. Nicht verstanden habe ich, wie viele Server du jetzt umziehen willst. Einen oder vier? Gruß, Nils

Moin, Echt, nur weil du das schöner findest, machst du so einen Hermann? Gut, dass ich nicht dein Chef bin ... 😉 Sorry, das musste erst mal raus. Wenn die Dinge so liegen, würde ich einen neuen DC mit dem neuen Namen installieren und danach den alten rausnehmen. Geht noch schneller, noch einfacher und mit noch weniger Risiko. Und wenn ich dein Chef wäre, würde ich sagen, verschwende mit sowas nicht Zeit und Geld. Gruß, Nils

Moin, großartig! Gruß, Nils

Moin, also, wenn wir bei Vorträgen sind - vor langer Zeit habe ich mal einen Vortrag zu JEA gehalten, der ziemlich genau die oben genannten Anforderungen abdeckte. Ich weiß nicht mehr, ob der aufgezeichnet worden ist; es war auf einer der "CLoud & Datacenter"-Konferenzen. Und ich würde behaupten, dass das Beispiel auch in dem Rheinwerk-Buch behandelt wird ... ... ja, wird es, und zwar in Kapitel 3.7.8 - das habe ich seinerzeit geschrieben. Also, wenn es wirklich nur diese Anforderungen sind, dann kann das eine Alternative zu einem kommerziellen Tool sein. Gruß, Nils

Moin, zu der Scripting-Aufgabe für die Übersicht werfe ich mal mein seit vielen Jahren fertiges Script in den Ring. [Get-HyperVInventory: New Download Source is Here | faq-o-matic.net] https://www.faq-o-matic.net/2020/12/23/get-hypervinventory-new-download-source-is-here/ Gruß, Nils

Moin, na, dann nimm das doch. Gruß, Nils

Moin, wenn es nur drei Clients sind, kann man sich den Zauber mit dem zusätzlichen DC vielleicht auch sparen. Einfach auf dem neuen Server ein neues AD installieren, die Daten kopieren, die Anwendung installieren. Die drei Clients dann eben neu aufnehmen. Falls dort Daten in den Profilen der früheren Anmeldekonten gespeichert sind, kommt man da mit Adminrechten lokal ran und kann die in die neuen Profile verschieben. Ob das grundsätzlich funktioniert, weiß man in ca. 2 Stunden. Die Chance ist groß. Falls doch nicht, dann gilt der Weg von Evgenij im Groben. Gruß, Nils

Moin, fragen wir mal anders: Was ist denn da die Anforderung? Gruß, Nils

Moin, der war gut. Gruß, Nils PS. AD-Attribute und "klar" ... wo kommen wir denn da hin?

Moin, naja, nicht ganz. Oder je nachdem habt ihr auch beide Recht. Eine VHDX-Datei wird normalerweise mit dynamischer Größe angelegt, sie ist dann nur so groß wie der tatsächlich belegte Platz. Die Größe der Partition ist dabei egal. Man kann so eine Datei aber auch mit fester Größe anlegen, dann ist sie so groß wie definiert. (Auch dies dann aber unabhängig von der Partitionsgröße, nur ist die ja meist so groß wie das Volume.) Das ging so auch schon mit VHD-Dateien, aber das nur am Rande. Gruß, Nils

Moin, ich meinte, ob einer eurer Domänencontroller unter 2025 läuft. Da gab es bis zum Sommer Probleme mit gesperrten Konten. Gruß, Nils

Moin, habt ihr Domänencontroller unter Windows Server 2025? Wenn ja, sind die auf dem aktuellsten Patchlevel? Gibt es darüber hinaus im Netzwerk Anmeldeprobleme oder Zugriffsprobleme auf Windows-Ressourcen? Hat sich an dem Aufbau des Clusters oder eines der Hosts kürzlich etwas geändert? Ist z.B. einer der Hosts aus einem Backup wiederhergestellt worden? Gruß, Nils

Moin, Ich finde, wir sollten das hier beenden. Das können wir nicht verantworten, was hier geschieht. Es geht nicht nur um einen Rechner, der vielleicht beeinträchtigt wird, sondern es geht um ein Risiko, das von diesem dann ausgehen wird. Nur meine 2 Cents. Gruß, Nils

Moin, jahrelang passiert nix mit Active Directory, und danach machen sie es dann gleich mehrmals kaputt. Großes Kino. Gruß, Nils

Moin, das wird sich anhand der Beschreibung nicht beantworten lassen. Und ich wage vorauszusagen, dass du hier auch niemanden finden wird, der für diesen Fall eine Diagnose abgibt, unabhängig von der Informationsmenge. Gruß, Nils

Moin, nein, kenne ich eben nicht, siehe oben. Ich kenne aber ein paar andere Seltsamkeiten, und an eine davon musste ich hier denken. Die war es aber anscheinend nicht. Gruß, Nils

Moin, hast du dem Gerätemanager gesagt, dass er auch wirklich nachsehen soll? [Migration von Hyper-V VMs zu anderem Hypervisor (V2V) – Wichtige Nacharbeit! | faq-o-matic.net] https://www.faq-o-matic.net/2016/07/06/migration-von-hyper-v-vms-zu-anderem-hypervisor-v2v-wichtige-nacharbeit/ Der Artikel hat einen anderen Schwerpunkt, aber das Verfahren ist dort beschrieben. Gruß, Nils

Moin, ich stolpere da auch. Nach meiner Kenntnis zieht Windows die Metrik nur dann zu Rate, wenn es mehrere ansonsten gleichwertige Routen gibt - in dem Fall also, wenn es mehr als eine Verbindung mit einem Gateway gibt. Nur zur Sicherheit, weil Windows auch sonst an der Stelle ein paar unangenehme Angewohnheiten hat: Gibt es in dem Rechner evtl. noch "Reste" ehemaliger Adapter, in denen dem 10.x/24-Netzwerk mal ein Gateway zugeordnet war? Sichtbar wäre das u.a. über den Gerätemanager, wenn man ihn ausdrücklich (per CMD) dazu anweist, auch ausgeblendete Geräte anzuzeigen. Gruß, Nils

Moin, als ich mich das letzte Mal mit F1 befasst habe, war es nur gültig für Geräte mit kleinen Bildschirmen und sehr eingeschränkten Nutzungsszenarien. Ich nehme an, dass das immer noch der Dreh ist. Daher dürfte die Kombi, die du dir ausgedacht hast, gar nicht anwendbar sein. Gruß, Nils

Moin, Entweder beides ohne Anführungszeichen oder beides mit. IF "%ordner%"=="menue" oder IF %ordner%==menue Siehe https://ss64.com/nt/if.html Batch ist schon sehr weit weg von Programmiersprachen. Gruß, Nils

Moin, ich wollte nicht in Abrede stellen, dass deine Gründe valide sind. Und als ich meinte, du musst die angehen - erstens weißt du das ja, und zweitens ist auch klar, dass das nicht so einfach in deiner Macht liegt. Davon solltest du dich aber nicht hindern lassen, den Teil, den du kontrollieren kannst, für dich sinnvoll zu bauen. Das eine tun, ohne das andere zu lassen. Ich rate dabei aber, nicht zu viel auf einmal zu wollen. Sonst wirst du nie fertig, und du baust dir deine eigene Überforderung. IT-Sicherheit kann man immer noch mal besser machen, aber genau das ist der Punkt: Es ist ein Prozess. Mach Dinge Schritt für Schritt. Viele Risiken, die es grundsätzlich gibt, sind in einer konkreten Situation gar nicht relevant oder recht unwahrscheinlich, die muss man dann auch nicht im ersten Schritt ausschalten. Nein, würde man nicht. Das sind unterschiedliche Netze. Die Hosts haben ein eigenes Betriebssystem und einen eigenen Netzwerkstack, der mit denen der VMs nichts zu tun hat. Da das in Hyper-V leider nicht besonders übersichtlich gebaut ist und da auch viele Internet-Quellen das nicht gut darstellen, hab ich das mal selbst beschrieben. Das ist im Detail zwar nicht mehr ganz aktuell, die Grundzüge sind aber noch dieselben. [Hyper-V und Netzwerke | faq-o-matic.net] https://www.faq-o-matic.net/2012/04/23/hyper-v-und-netzwerke/ Gruß, Nils

Moin, wenn du schon auf der Ebene nachdenkst und argumentierst - was sinnvoll ist -, dann solltest du in Betracht ziehen, einen separaten Infrastruktur-Forest für deine Host-Umgebung einzurichten. Dort hast du dann die Vorteile der Domänenverwaltung und kannst die Domäne getrennt von deiner Produktionsdomäne absichern. Sollte es dort dann ein Problem geben, ist der andere Forest nicht automatisch mit korrumpiert. Ich stimme aber auch Jan zu - das Niveau, das du erreichen willst, ist mit den "Gründen", die du nebulös anführst, nicht vereinbar. An die wirst du auch ran müssen. Gruß, Nils