NilsK

Moin, für dein Einsatzgebiet sind Hyper-V und VMware praktisch ebenbürtig (mit dem Unterschied, dass Hyper-V funktional nicht beschränkt ist). Wenn dir die Vertrautheit mit dem vorhandenen System die Lizenzkosten für die neue Version wert ist, dann nimm die. Willst du das Geld sparen, dann kannst du umsteigen, musst dich dann aber eben etwas ins System einfinden und natürlich die VMs konvertieren (was den Kostenvorteil relativiert). Gruß, Nils

Moin, wenn du das ohnehin für die Zeit der V2V-Migration machen willst, dann koppel doch einfach die vNIC ab. Dadurch änderst du nichts innerhalb der VM und hast gleichzeitig dafür gesorgt, dass die Quell-VM nach dem Vorgang offline bleibt. Gruß, Nils

Moin, gerade in solchen Konstellationen gibt es -zig mögliche Bremsen, die Hardware ist nur selten tatsächlich das Problem. Weit häufiger sind es fehlende Indizes oder schlechte Abfragen. Gern auch Sperrkonflikte: User B kann nicht weitermachen, weil User A einen Dialog offen hat, der eine Tabelle exklusiv sperrt. Lauter so Dinge. Wenn die Platten oder die Hardware wirklich zu langsam wären, sollte man das auch ohne großen Aufwand im Performance Monitor (oder sogar im Resource Monitor) sehen. Gibt es dort keine Hinweise der Art, dann muss sich der Hersteller von seinem hohen Ross herunterbewegen und in die Analyse einsteigen. Gruß, Nils

Moin, ja, seit geraumer Zeit werden DNS-Zonen in einer eigenen Partition gespeichert. Die bei dir noch in der Domänenpartition vorhandenen Zonen dürften älteren Datums sein. Wenn du in ADSI Edit den Eintrag "rootDSE" verbindest und in dessen Eigenschaften schaust, siehst du unter namingContexts die vorhandenen AD-Partitionen. Die kannst du dann wiederum in ADSI Edit öffnen, um die Zonen und deren DNs ausfindig zu machen. Gruß, Nils

Moin, aus dem oben zitierten Satz hatte ich gefolgert, dass es um eine kostenpflichtige Variante geht. Gruß, Nils

Moin, gut. Für einen Umstieg auf moderne Software bei gleicher VM-Zahl brauchst du also: die Core-Lizenzen für Windows Server 2016 Standard, zwei "Sets" (dafür musst du wissen, wieviele CPUs und Cores die Hardware hat und gibst das in den Kalkulator ein, den ich oben verlinkt habe) 10 CALs WS 2016 10 RDS-CALs WS 2016 10 Office-Lizenzen in der passenden Edition, die für RDS freigegeben ist Statt die VMware-Lizenz zu erneuern, könntest du auf Hyper-V umsteigen, dann hast du keine weiteren Kosten für die Virtualisierung. Gruß, Nils

Moin, das ist eine Microsoft-Seite. "Direkter" wird man das ohne einen konkreten Lizenzberatungsfall kaum bekommen, denke ich. Gruß, Nils

Moin, hm? Nein. Die Cores müssen immer voll lizenziert werden, es müssen immer 2 CPUs lizenziert werden, und das Minimum von 2*8 Cores ist ja überschritten. 20 Core-Lizenzen in dem Szenario mit 4 VMs. Sagt dein Rechner das nicht auch? Ich find ihn grad nicht. :D ich widerrufe einen Teil meiner Argumentation und verweise einfach auf diesen Rechner: https://www.windows-server-kompetenz-club.de/de/lizenzkonfigurator Demnach wären es bei einem Server mit 1 CPU und 10 Cores und 4 VMs 32 zu lizenzierende Cores (also 16 Core-Lizenzen). Derselbe Server mit Dual-COU müsste 40 Cores lizenzieren (also meine 20 Core-Lizenzen). Ach, soll sich doch der Vertrieb drum kümmern. :D Gruß, Nils

Moin, welche Frage jetzt genau? Ein 10-Core-Server muss 10 Cores pro CPU lizenziert haben, also 10 Core-Lizenzen, um "einmal" mit Standard lizenziert zu sein (jede Core-Lizenz deckt zwei Cores ab - da immer zwei CPUs lizenziert werden müssen, muss man also 20 Cores lizenzieren, selbst wenn es nur eine 10-Core-CPU ist). Single-CPU-Server ergeben aus Lizenzsicht keinen Sinn für Windows. Für vier VMs braucht man zwei Standard-Lizenz-Sets, also 20 Core-Lizenzen. Unübersichtlich, aber aus meiner Sicht nicht wirklich unklar. Oder überseh ich was? Gruß, Nils EDIT: So nicht ganz richtig, siehe #8 in diesem Thread.

Moin, von einer anderen Seite betrachtet, hat sich eigentlich nicht viel geändert: Die Standard-Lizenz erlaubt es weiterhin, zwei Windows-Server-VMs derselben Version oder ihrer Vorgänger zu betreiben Will man mehr als zwei VMs haben, dann muss man dem Host mehrere Standard-Lizenzen zuweisen: Pro 2 WS-VMs eine Lizenz Die Lizenz ist immer dem Host zugewiesen, nie der VM Man kann Lizenzen verschiedener Versionen nicht auf demselben Host mischen Für deine vier VMs musst du dem Host also zwei Standard-Lizenzen (bzw. besser: Lizenz-Sets) zuweisen. Was sich geändert hat, ist "nur" die Core-Lizenzierung. Pro CPU musst du mindestens acht Cores lizenzieren (auch wenn sie weniger Cores hat), und pro Server mindestens zwei CPUs (auch wenn nur eine drinsteckt). Das sind dann die 16 Core-Lizenzen als Minimum, die Norbert ansprach. Sollte der neue Host 8-Core-CPUs haben, dann sind die Core-Lizenzen auch nicht teurer als die bisherige CPU-Lizenzierung. Bei aktuelleren CPUs mit mehr Cores zahlst du etwas mehr, weil alle Cores lizenziert werden müssen (in deinem Fall "zweimal" wegen der beiden erforderlichen Standard-Lizenzen). Die RDS-Lizenzen und die CALs kommen separat und müssen zu der eingesetzten Server-Version passen. Die CALs für die "höchste" eingesetzte Version (Beispiel: drei 2008-Server und ein 2016-Server erfordern 2016-CALs für alle User/Devices). DIe RDS-CALs für die Version, mit der der RDS-Server läuft (hast du also einen 2008-R2-RDS und vorhandene 2008-RDS-CALs, dann kannst du die weiternutzen). Die RDS-CALs brauchst du pro User, der "irgendwann" zugreift, nicht nur für die gleichzeitigen. Ein aktuelles Office ergibt schon Sinn. So viele Lizenzen, wie User das Office nutzen (können). Gruß, Nils

Moin, dann würde ich das mit einem Startup-Skript lösen, das einmalig lokal läuft (indem es etwa prüft, ob die Objekte schon vorhanden sind). Ist immer sicherer, als sich auf das Funktionieren des Netzwerks oder einer bestimmten Session-Technik zu verlassen. Gruß, Nils

Moin, warum löst du das nicht über Gruppenrichtlinien? Dafür gibt es die Funktion "Eingeschränkte Gruppen". Gruß, Nils

Moin, Und savecred nur beim ersten Aufruf, nicht jedes Mal. Also einmal manuell, im Batch dann ohne den Schalter. Gruß, Nils

Moin, was sagt denn ipconfig /all zu der Karte? Sind evtl. mehrere IP-Adressen darauf gebunden? Als nächstes versuchte ich, die vNIC zu entfernen. Dann VM hochfahren, prüfen, ob die Karte auch im Gerätemanager mit ausgeblendeten Geräten weg ist. Dann VM herunterfahren, neue vNIC hinzufügen. Hochfahren, einrichten. Möglich, dass sie dann funktioniert wie gewünscht. Gruß, Nils

Moin, vielleicht kannst du dir ein Batch bauen, das mit runas und dem Schalter /savecred das per Kommandozeile übergebene Programm (wäre dann sowas wie %1) startet. Dann musst du beim ersten Mal das Kennwort eingeben, danach aber nicht mehr. Das Batch bindest du dann unter SendTo ein, dann taucht es im Kontextmenü auf. Sicherheitstechnisch bedenklich, aber könnte funktionieren. Gruß, Nils

Moin, du schreibst, dass es früher "auf Physik" funktioniert hätte. Ist die VM per P2V entstanden? Falls ja, könnte es sein, dass die Konfig der ehemals physischen Netzwerkadapter dir dort mit reinspukt. In dem Fall per Device Manager mit "show nonpresent devices" die Reste entfernen. Eigentlich müsste das Setup nämlich funktionieren, da hast du Recht. Gruß, Nils

Moin, das kommt drauf an, was du mit "das" meinst und was da zu handhaben ist. Solange man nur in den Ruhezustand und zurück wechselt, läuft die Usersession ja weiter, da gibt es dann ja keinen Bedarf, Skripte auszuführen. Gruß, Nils

Moin, Dann ist iSCSI die bessere Option. Das Problem dürfte jetzt darin bestehen, dass beide Karten SMB machen. Gruß, Nils

Moin, wie greifst du auf das NAS zu? Per SMB oder per iSCSI? Wozu dient das Konstrukt? Greift nur die eine VM auf das NAS zu oder auch andere Geräte? Gruß, Nils

Moin, naja, dazu muss man ja erst mal durchsteigen, wie die Logik denn nun ist. Für einen Nicht-Insider ist das mittlerweile nicht mehr ganz einfach. Zumal die neue Handhabung mit den erstmals wegfallenden Elementen ja nun auch kaum noch nachzuvollziehen ist. In sofern kann ich die Nachfragen schon verstehen. Trotzdem ist es richtig, dass man ab einem gewissen Punkt die Dinge ausprobieren sollte, weil sie sich in einem Forum nur schlecht erklären lassen. Also: Testlab einrichten (ein DC als VM, je Client-Version eine VM, die wichtigsten Aspekte nachbilden - immer in einem Lab, nie in Produktion) und testen. Gruß, Nils

Moin, dann suchst du ja genau keinen MOC-Kurs. Wie die anderen schon sagten: Such dir einen Schulungsanbieter oder ein Systemhaus und besprich mit denen, was du willst. Das wird dann auf ein Angebot nach Tagessätzen hinauslaufen. Wenn der Anbieter gut ist, kann er mit dir im Vorfeld auch schon besprechen, welche Idee sinnvoll ist und welche weniger (mehrere Domänen etwa macht man heute nicht mehr, mehrere Standorte sind im Lab sehr aufwändig, Troubleshooting ist sehr relativ ... usw.). Dabei kann es helfen, wenn man sich vorher über das Ziel der Maßnahme ausführliche Gedanken macht, sonst artet sowas manchmal in "betreutes Herumspielen" aus. Gruß, Nils

Moin, um es mal etwas ausdrücklicher zu beantworten: Da du "nur" die ADMX für die Systeme benötigst, die du tatsächlich einsetzt, solltest du die Vorlagen auch von diesen Systemen nehmen und nicht separat herunterladen. Leider hatte es in der jüngeren Vergangenheit mehrfach veraltete Downloads bei Microsoft gegeben, die dann zu Anzeigefehlern bei der Administration führten. Offensichtlich fehlt hier die Qualitätskontrolle. Da ja aber jedes Windows-System die zur Version passenden Vorlagen mitbringt, ist es der bessere Weg, diese zu nehmen. Bei Windows 10 muss man, wie Norbert schon sagt, leider etwas genauer hinsehen, weil die laufenden Änderungen dort auch Einstellungsmöglichkeiten entfernen. Auch dort gilt aber, dass die mit dem OS (bzw. ggf. mit Updates) ausgelieferten, also quasi "installierten" Versionen vorzuziehen sind. Die Funktion der Richtlinien selbst wird durch die Vorlagen nicht verändert, sondern nur die Administrierbarkeit. Gruß, Nils

Moin, ja, das siehst du richtig. https://support.microsoft.com/en-us/help/231287/loopback-processing-of-group-policy Und das wurde dir in #7 ausdrücklich und bereits in #2 implizit gesagt. Aber gut, dass es jetzt gefunden ist. Gruß, Nils

Moin, bei solchen Mandantenlösungen rate ich dazu, ausreichend zu analysieren und zu planen. Da das AD von selbst nicht mandantenfähig ist (in dem Sinne, dass die Mandanten tatsächlich voneinander getrennt sind, also Kunde A nichts von Kunde B wissen darf), bedeutet das erheblichen Aufwand oder völlig andere Lösungen. Mit Standardwerkzeugen kommt man da fast nie weiter. Gruß, Nils

Moin, wir können weiter munter irgendwelche Stichworte in den Raum werfen. Ob die dann mit den Anforderungen des TO, mit den juristischen Rahmenbedingungen, die für ihn tatsächlich gelten, oder mit seinem Business irgendwas zu tun haben - oder ob sie überhaupt irgendwie auf irgendwas zutreffen, ist mittlerweile offenbar egal. Genausogut könnten wir jetzt auch aufwerfen, dass E-Mail grundsätzlich kein besonders geeignetes Kommunikationsmedium ist. Oder dass es nachts kälter ist als draußen ... Macht ruhig weiter, ich bin dann raus. Gruß, Nils