NilsK

Moin, schau dir Branch Cache an. Das ist genau für dein Szenario gemacht. Wenn es doch DFS sein soll: Ja, da brauchst du AD-Standorte, aber ein RODC ist nicht nötig. Lass den weg, der erzeugt nur Umstände. Die Standortinformationen erhält der Client auch vom Remote-DC, sofern die Standorte und Subnets richtig gepflegt sind. Gruß, Nils

Moin, die XBox-Dienste stehen auf Manuell. Der Maps Broker ist zwar automatisch, beendet sich aber bei Inaktivität selbst. Der Gewinn der Maßnahmen dürfte sich nahe Null befinden. Optimierungen macht man fallbezogen, nicht pauschal. Gruß, Nils

Moin, für dein Szenario könnte Branch Cache interessanter sein - wenn denn an Standort B wirklich nur gelesen werden soll. (Mir fallen kaum Szenarien ein, in denen das Sinn ergeben könnte.) Der Sinn des RODC erschließt sich mir gerade nicht. Gruß, Nils

Moin, mag ja sein, aber Veeam braucht nun mal das API. Das ist doch hier jetzt auch eine Scheindiskussion, hinter der sich am Ende persönliche Vorlieben verbergen. Wer VMware einsetzen will, muss halt die Lizenzkosten dafür einrechnen. Ob das ein relevanter Punkt ist, ergibt sich nur aus der Gesamtbetrachtung. Und bei so einer kann eben durchaus rauskommen, dass VMware das Geld wert ist. Ist doch gut. Gruß, Nils

Moin, In dem Fall eben das fehlende API fürs Backup ... Gruß, Nils

Moin, da wäre jetzt relevant, worin denn der Bedarf besteht bzw. welches Problem daraus entsteht. Aus meinem Wirkungsbereich kenne ich keine Probleme, weswegen es gar nicht "gehandhabt" wird. Gruß, Nils

Moin, dass das Volumen sich beim Umstieg von einem System auf ein anderes verändert, ist nicht überraschend. Andere Formate, andere Optimierungen usw. lassen eine Größenprognose bei solchen Migrationen nur sehr grob zu. Von dem Anwachsen beim Verschieben von Exchange 2010 nach 2016 in dem Umfang war mir jetzt nichts aktiv bekannt. Beim Umstieg von älteren Versionen lag sowas u.a. am wegfallenden Single-Instancing. Ich würde in beiden Fällen aber nicht von Fehlern ausgehen, soweit es keine anderen Indikatoren dafür gibt. Gruß, Nils

Moin, ja, da hast du natürlich Recht. Das war ursprünglich auch mein Gedanke - die VMs müssen sowieso neu, da ist die Plattform dann egal. Hatte ich nur eben aus dem Blick verloren. :D Gruß, Nils

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