Windows Server 2016 Datacenter bietet mit dem Feature Automatic Virtual Machine Activation (AVMA) eine Funktion welche die Aktivierung von virtuellen Windows Server 2016 und Windows Server 2012 R2 Systemen automatisiert, wenn diese auf einem Hyper-V Host mit Windows Server 2016 Datacenter ausgeführt werden – auch wenn die jeweilige VM keine Netzwerkverbindung hat.

Das Feature AVMA wurde bereits mit Windows Server 2012 R2 Datacenter eingeführt – zu meinem zugehörigen Blog Artikel gelangen Sie über folgenden Link:
http://www.manfredhelber.de/automatic-virtual-machine-activation-avma/

Voraussetzungen um AVMA nutzen zu können:

1. Sie müssen Hyper-V nutzen – nur bei Nutzung von Hyper-V steht AVMA zur Verfügung
2. Der Parent muss mit Windows Server 2016 Datacenter oder Windows Server 2012 R2 Datacenter installiert sein
3. Der Parent muss aktiviert sein
4. In den Childs (VMs) muss eine der folgenden Windows Server Editionen installiert sein: Windows Server 2016 Standard, Windows Server 2016 Datacenter, Windows Server 2016 Essentials, Windows Server 2012 R2 Standard, Windows Server 2012 R2 Datacenter oder Windows Server 2012 R2 Essentials
5. In den VMs müssen bei der Windows Installation die AVMA Keys verwendet werden.

Ein entsprechender Hyper-V Host könnte wie folgt aussehen:

Ältere Gastbetriebssysteme sind aus technischer Sicht möglich, allerdings kann für VMs mit Betriebssystemen vor Windows Server 2012 R2 kein AVMA genutzt werden.

In meinem Beispiel wurde Windows Server 2016 Datacenter als Parent System installiert und aktiviert:

Bei der Installation des Parent Systems wurde der mit Windows Server 2016 Datacenter erworbene Product Key für die Installation verwendet.

Wenn auf diesem Hyper-V Host eine virtuelle Maschine mit Windows Server 2016 oder Windows Server 2012 R2 installiert wird ist darauf zu achten, dass als Product Key nicht der Product Key des Parent Systems sondern einer der AVMA Product Keys eingegeben wird.

Die AVMA Keys sind im TechNet unter folgendem Link zu finden: https://technet.microsoft.com/en-us/library/dn303421(v=ws.11).aspx und lauten:

Für VMs mit Windows Server 2012 R2 als Betriebssystem:
Datacenter: Y4TGP-NPTV9-HTC2H-7MGQ3-DV4TW
Standard: DBGBW-NPF86-BJVTX-K3WKJ-MTB6V
Essentials: K2XGM-NMBT3-2R6Q8-WF2FK-P36R2

Für VMs mit Windows Server 2016 als Betriebssystem:
Datacenter: TMJ3Y-NTRTM-FJYXT-T22BY-CWG3J
Standard: C3RCX-M6NRP-6CXC9-TW2F2-4RHYD
Essentials: B4YNW-62DX9-W8V6M-82649-MHBKQ

Im folgenden Screenshot wird bei der Installation einer VM mit Windows Server 2012 R2 der AVMA Key für Windows Server 2012 R2 Standard genutzt:

Als Ergebnis werden im folgenden Setup Schritt die beiden Installationsvarianten für Windows Server 2012 R2 Standard angeboten:

Nach Abschluss der Windows Server 2012 R2 Installation ist das Gast-Betriebssystem automatisch aktiviert – wie im Screenshot zu sehen benötigt die VM dazu keine aktive Netzwerkverbindung:

Die AVMA Aktivierung wird im Gastbetriebssystem im Application-Log unter der Event ID 12309 aufgezeichnet:

Am Parent-System finden sich die erfolgten AVMA Aktivierungen im Application-Log unter der Event ID 12310:

Durch Aufruf von slmgr /dli im Gastbetriebssystem lassen sich detaillierte Informationen zur Windows Lizenz abrufen:

Im Screenshot ist der Name des AVMA Hosts zu sehen. Außerdem ist zu sehen, dass die AVMA Aktivierung für 7 Tage gültig ist. D.h. die AVMA Aktivierung wird alle 7 Tage vom AVMA Host bestätigt.

Analog funktioniert dies natürlich mit VMs mit Windows Server 2016 als Gastbetriebssystem:

Als Ergebnis werden im folgenden Setup Schritt die beiden Installationsvarianten für Windows Server 2016 Standard angeboten:

Nach Abschluss der Windows Server 2016 Installation in der VM ist das Gast-Betriebssystem automatisch aktiviert – wie im Screenshot zu sehen benötigt die VM dazu keine aktive Netzwerkverbindung:

Die AVMA Aktivierung wird auch bei Windows Server 2016 VMs im Gastbetriebssystem im Application-Log unter der Event ID 12309 aufgezeichnet:

Auch am Parent-System finden Sie diese AVMA Aktivierung im Application-Log unter der Event ID 12310:

Auch bei Windows Server 2016 VMs lassen sich durch Aufruf von slmgr /dli im Gastbetriebssystem detaillierte Informationen zur Windows Lizenz abrufen:

Im Screenshot ist der Name des AVMA Hosts zu sehen. Außerdem ist zu sehen, dass die AVMA Aktivierung für 7 Tage gültig ist. D.h. die AVMA Aktivierung wird alle 7 Tage vom AVMA Host bestätigt.

Wurde bei der Installation des Windows Server 2016 oder Windows Server 2012 R2 Gastbetriebssystems in der VM kein AVMA Key eingeben (z.B. weil eine Eval. Version installiert wurde) so lässt sich dieser nachträglich durch Eingabe des folgenden Befehles im Gastbetriebssystem integrieren:
slmgr.vbs /ipk AVMAKEY

Viel Erfolg bei der Nutzung von Windows Server 2016 und AVMA.

Falls Sie sich intensiver zum Thema Hyper-V informieren möchten schauen Sie doch einmal in unserem Workshop-Bereich vorbei:
http://www.manfredhelber.de/kurse/

In der Technical Preview Phase war dies zunächst nur mit mindestens 4 Servern unterstützt:

Konfigurationen mit 4 bis 16 Knoten sind weiterhin möglich und eignen sich besonders für Umgebungen in denen großer Wert auf mehrfache Redundanz gelegt wird.

Seit Windows Server 2016 Technical Preview 5 ist auch eine Konfiguration von Storage Spaces Direct mit nur 3 Servern möglich:

Es darf hier immer noch zum Ausfall eines Knotens und einer weiteren Disk kommen ohne dass es zu einem Datenverlust kommt.

Die große Neuerung wurde jetzt im Rahmen der Microsoft Ignite bekannt gegeben: in der RTM Version von Windows Server 2016 sind Storage Spaces Direct Konfigurationen mit nur zwei Knoten möglich:

Dies ist natürlich besonders für kleinere Umgebungen interessant. Es ist kein weiteres zentrales Storage System erforderlich, allerdings muss ein Cluster Zeuge als Fileshare-Zeuge oder als Cloud-Zeuge konfiguriert werden. Die beiden Server müssen Netzwerktechnisch über mindestens 2x 10 GBit angebunden werden – RDMA ist nicht zwingend erforderlich, wird allerdings empfohlen. In der 2-Knoten Konfiguration darf immer noch ein Knoten komplett ausfallen ohne, dass es zu einem Datenverlust kommt. Es darf dann allerdings in dem verbleibenden Server keine weitere Disk ausfallen. Ein späterer Scale-Out mit zusätzlichen Servern bei zusätzlichem Bedarf an Speicherkapazität oder Rechenleistung ist problemlos möglich.

Zu beachten ist auch, dass Storage Spaces Direct nur in der Datacenter Edition von Windows Server 2016 enthalten ist. Durch die Nutzung der Datacenter Edition auf allen Hosts ergeben sich daraus in diesem Hyper-converged Szenario mit Windows Server 2016 und Storage Spaces Direct allerdings auch unlimitierte virtuelle Nutzungsrechte für Windows Server auf den beteiligten Knoten.

https://www.microsoft.com/de-de/evalcenter/evaluate-windows-server-2016

Auch das aktualisierte und kostenfreie eBook „Introducing Windows Server 2016″ ist bereits zum Download verfügbar:

https://blogs.msdn.microsoft.com/microsoft_press/2016/09/26/free-ebook-introducing-windows-server-2016/

Die Bits&Bytes sind zwar RTM, der GA Termin wird allerdings erst Mitte Oktober sein.

Viel Spaß beim Lesen und beim Testen der vielen neuen Features.

Detaillierte Informationen zur Lizenzierung von Windows Server 2016 erhalten Sie im Microsoft Licensing Datasheet in englischer Sprache:
http://download.microsoft.com/download/7/2/9/7290EA05-DC56-4BED-9400-138C5701F174/WS2016LicensingDatasheet.pdf
und im Windows Server Kompetenz Club zusammengefasst in deutscher Sprache:
https://kompetenzclub.blob.core.windows.net/kompetenzclub/2pager%20Lizenzierung%20WS2016.pdf

Hilfreich um Ihren Lizenzbedarf zu ermitteln ist auch der Windows Server 2016 Lizenz Konfigurator im Windows Server Kompetenz Club:
http://www.windows-server-kompetenz-club.de/de/lizenzkonfigurator

Sehr häufig wird die Frage nach dem Thema hyper-threading gestellt. Betrachten wir exemplarisch folgenden physischen Server:

Dieser physische Server hat 2 Sockel, 20 Kerne und durch hyper-threading 40 logische Prozessoren. Für die Lizenzierung von Windows Server 2016 sind die physischen Kerne und die Sockel zu betrachten und nicht die logischen Prozessoren. Das bedeutet für den exemplarisch betrachteten Server aus dem Screenshot müssen 20 Kerne für Windows Server 2016 lizenziert werden. Siehe hierzu auch Punkt 11 im Windows Server 2016 licensing FAQ Dokument unter folgendem Link: http://download.microsoft.com/download/7/2/9/7290EA05-DC56-4BED-9400-138C5701F174/WSSC2016LicensingFAQ.pdf

Durch die zunehmende Kerndichte der aktuellen CPUs könnte es durchaus interessant sein höherwertige CPUs in den Serversystemen zu planen und nicht benötigte Kerne zunächst zu deaktivieren. Viele aktuelle Serversysteme lassen dies im BIOS zu:

Wenn wie im obigen Screenshot dargestellt die Anzahl der Kerne je Prozessor auf z.B. 8 eingestellt sind werden nach Start von Windows Server 2016 nur noch 16 Kerne angezeigt und es können natürlich auch nur noch diese 16 Kerne genutzt werden:

Laut dem Lizenz FAQ Dokument zu Windows Server 2016 müssen in diesem Fall nur noch 16 Kerne für diesen physischen Server lizenziert werden.
„Physical cores that are disabled for use by an operating system do not need to be licensed.“
Siehe hierzu auch Punkt 12 im Windows Server 2016 licensing FAQ Dokument unter folgendem Link: http://download.microsoft.com/download/7/2/9/7290EA05-DC56-4BED-9400-138C5701F174/WSSC2016LicensingFAQ.pdf

Wichtig ist allerdings zu beachten, dass immer mindestens 16 Kerne je physischem Server lizenziert werden müssen. Wenn in dem obigen Beispiel die Anzahl der Kerne je CPU z.B. auf 4 eingestellt wird müssen trotzdem 16 Kerne lizenziert werden.

Sollten zu einem späteren Zeitpunkt Kerne im BIOS zusätzlich aktiviert werden um mehr Leistung zu erhalten ist unbedingt darauf zu achten, dass diese zusätzlichen Kerne lizenziert werden müssen sobald der physische Server mehr als 16 aktive Kerne hat.

https://www.microsoft.com/de-de/evalcenter/evaluate-windows-server-technical-preview

Voraussetzung zum Einsatz der Optionen zur Volumenaktivierung ist die Lizenzenzierung der zu aktivierenden Systeme über einen Volumenlizenzvertrag (bitte beachten Sie, dass es Windows Client Systeme im Rahmen der Volumenlizenzierung nur als Upgrade Versionen gibt, d.h. Sie benötigen auf dem jeweiligen System immer eine upgradeberechtigte Basislizenz – typischerweise die jeweilige Windows OEM Clientlizenz) oder über entsprechende OEM Lizenzen + Software Assurance (SA) wodurch diese gleichwertig mit der Volumenlizenz werden. Nicht nur Windows Clientbetriebssysteme und Microsoft Office können über die Optionen zur Volumenaktivierung aktiviert werden, sondern auch Windows Server Systeme.

Die im nachfolgenden beschriebenen Optionen zur Volumenaktivierung dürfen nicht mit der Automatic Virtual Machine Activation (AVMA) verwechselt werden – AVMA ist mit jeder Windows Server 2012 R2 Datacenter Lizenzform (auch OEM) möglich und wurde von mir in folgendem Blog Artikel beschrieben: http://blog.mhblog.de/?p=162

Microsoft bietet drei Mechanismen zur Volumenaktivierung von volumenlizenzierten Windows Systemen im Netzwerk:

• Multiple Activation Key (MAK)
• Key Management Service (KMS)
• Active Directory-Aktivierung

Multiple Activation Key (MAK)

Bei der Nutzung von MAK wird an den Clients der MAK Schlüssel eingetragen und die Clients werden direkt und einmalig gegenüber dem Microsoft Aktivierungsdienst aktiviert. Ideal ist die Nutzung von MAK Schlüsseln für volumenlizenzierte Umgebungen mit weniger als 25 Windows Clients und weniger als 5 Windows Servern – dies ist die Schwelle ab welcher der Key Management Service die Aktivierung übernehmen könnte. MAK Schlüssel können allerdings auch in größeren Umgebungen eingesetzt werden – neben dem MAK Schlüssel ist keine zusätzliche Infrastruktur erforderlich. Das Microsoft Volume Activation Management Tool kann optional zur Unterstützung bei der MAK Aktivierung genutzt werden.
Detaillierte Informationen zur Nutzung der MAK-Aktivierung finden sich unter folgendem TechNet Link: https://technet.microsoft.com/de-de/library/dn502526.aspx

Key Management Service (KMS)

Zum Thema Key Management Service erreichen mich die meisten Anfragen. Es sollte zunächst geklärt werden, ob dies tatsächlich die beste Option in Ihrem Szenario ist (siehe MAK und Active Directory-Aktivierung). Der Key Management Service kann in Umgebungen genutzt werden in denen Volumenlizenzierte Clients über einen zentralen KMS Host im Netzwerk aktiviert werden sollen (mindestens 25 Windows Clients bzw. mindestens 5 Windows Server sind erforderlich, damit KMS mit der Aktivierung des jeweiligen Produktes startet). Die Clients werden dabei regelmäßig (alle 180 Tage) gegenüber dem zentralen KMS Host und nicht einmalig gegenüber dem Microsoft Aktivierungsservern aktiviert. Bei der Installation der Clients wird dabei ein generischer Product Key verwendet – die Liste der Client Keys für KMS findet sich unter folgendem Link: https://technet.microsoft.com/de-de/library/jj612867.aspx

Zur Konfiguration eines Hosts der KMS für das Netzwerk bereitstellt ist ein KMS Host Key erforderlich. Diesen KMS Host Key finden Sie im Microsoft Volume Licensing Service Center (VLSC) unter „Downloads and Keys“. Zu beachten ist dabei, dass der KMS Host Key nicht unter dem jeweiligen Clientbetriebssystem zu finden ist, sondern unter dem Windows Betriebssystem welches als KMS Host dienen soll – der KMS Host muss nicht zwingendermaßen ein Windows Server System sein wie die Tabelle unter folgendem Link zeigt: https://technet.microsoft.com/en-us/library/dn502537.aspx

So könnte z.B. ein Windows 10 Client welcher als KMS Host konfiguriert wird die Aktivierung für folgende Produkte bereitstellen:
Windows 10 Enterprise

• Windows 10 Education
• Windows 10 Pro
• Windows 8.1 Enterprise
• Windows 8.1 Pro
• Windows 8 Professional
• Windows 8 Enterprise
• Windows 7 Professional
• Windows 7 Enterprise

Wenn Windows Server 2012 R2 als KMS Host genutzt werden soll wird mindestens eine Windows Server 2012 R2 Standard Volumenlizenz oder Windows Server 2012 R2 Standard OEM Lizenz + Software Assurance benötigt, da, wie bereits erwähnt, der KMS Host Key im VLSC unter dem Windows Betriebssystem welches als KMS Host dienen soll zu finden ist. Eine Ausführliche Anleitung zur Konfiguration eines KMS Hosts finden Sie im TechNet unter: https://technet.microsoft.com/library/ff793407.aspx

Bitte beachten Sie, dass zur Aktivierung von Windows 10 durch einen Windows 8, Windows 8.1, Windows Server 2012 oder Windows Server 2012 R2 basierenden KMS Host folgendes Update am KMS Host installiert werden muss: https://support.microsoft.com/en-us/kb/3058168 – beachten Sie bitte außerdem, dass anschließend auf dem KMS Host der aktualisierte Windows Server 2012 R2 + Windows 10 KMS Key eingespielt werden muss. Es wird häufig der Fehler gemacht den Windows 10 KMS Host Key zu nutzen, dieser ist allerdings nur nutzbar, wenn der KMS Host auch tatsächlich Windows 10 ist. Den aktualisierte Windows Server 2012 R2 + Windows 10 KMS Key finden Sie im VLSC nicht unter „Downloads and Keys“ sondern im Bereich „License“ -> „Relationship Summary“ auf der Seite die anschließend geladen wird können Sie im Bereich „Product Keys“ den Schlüssel für „Windows Srv 2012R2 DataCtr/Std KMS for Windows 10″ finden. Mehr dazu auch unter: https://support.microsoft.com/en-us/kb/3086418

Detaillierte Informationen zur Bereitstellung der KMS-Aktivierung finden sich unter folgendem TechNet Link: https://technet.microsoft.com/de-de/library/dn502531.aspx

Active Directory-Aktivierung

Die Active Directory-Aktivierung wurde mit Windows Server 2012 eingeführt und vereinfacht die Aktivierung neuerer Volumenlizenzierter Systeme. Die Active Directory-Aktivierung kann eingesetzt werden, wenn das Active Directory Schema mindestens auf die Version Windows Server 2012 aktualisiert wurde und wenn die zu aktivierenden Systeme mindestens Windows 8 oder Windows Server 2012 ausführen. Active Directory-Aktivierung und KMS können gemeinsam im Netzwerk genutzt werden.

Detaillierte Informationen zur Bereitstellung der Active Directory-Aktivierung finden sich unter folgendem TechNet Link: https://technet.microsoft.com/de-de/library/dn502534.aspx

Zusätzlich gibt es eine sehr gute Anleitung im TechNet zum Aufbau einer Testumgebung für KMS und Active Directory Aktivierung: https://technet.microsoft.com/de-de/library/hh831794.aspx

Mich erreichen regelmäßig Anfragen zur technischen Umsetzung, denn nach der Installation von Windows Server 2012 R2 Essentials auf einem physischen Server sind immer die zusätzlichen Rollen und Features für die Essentials Funktionalitäten installiert. Außerdem wird bei jeder Anmeldung am Essentials Server der Assistent zur Konfiguration der Essentials Umgebung gestartet bis die Konfiguration erfolgreich abgeschlossen wurde. Wenn der Windows Server 2012 R2 Essentials virtuell betrieben werden soll wäre es allerdings erforderlich die physische Installation (den Parent) nur mit der Hyper-V Rolle zu installieren um dann in einer dort angelegten VM Windows Server 2012 R2 Essentials mit den vollständigen Essentials Funktionen zu installieren und zu konfigurieren.

Folgendes Vorgehen ist erforderlich.

Zunächst wird auf dem physischen Server Windows Server 2012 R2 Essentials installiert. Nach der Installation wird wie gewohnt ein Kennwort für den Administrator festgelegt und der Administrator meldet sich am Server an.

Der Assistent für die Windows Server Essentials Konfiguration wird automatisch gestartet. Durch einen Klick auf „Abbrechen“ und eine anschließende Bestätigung mit „Ja“ wird dieser beendet.

Anschließend muss ein PowerShell Fenster mit administrativen Berechtigungen geöffnet werden. Durch die Eingabe von
dism /online /disable-feature:Microsoft-Windows-ServerEssentials-ServerSetup

werden die Essentials Features deaktiviert:

Anschließend kann die Verknüpfung für das Essentials Dashboard auf dem Desktop gelöscht werden:

Zusätzlich empfiehlt es sich die Verknüpfung zum Essentials Dashboard in der Taskleiste zu löschen:

Im nächsten Schritt werden die Rollen und Features die nicht benötigt werden und auf dem Hyper-V Host (Parent) nicht installiert sein dürfen entfernt. Im Server Manager wird dazu unter „Verwalten“ die Option „Rollen und Features entfernen gewählt“:

In dem Assistenten zum Entfernen von Rollen und Features werden die ersten Schritte mit einem Klick auf „Weiter“ bestätigt bis der Schritt zum Entfernen der Serverrollen erscheint. Dort müssen alle installierten Rollen außer der „Speicherdienste“ entfernt werden:

Nach einem Klick auf „Weiter“ erscheint der Schritt zum Entfernen der nicht benötigten Features:

Es müssen dort alle Features außer: .NET Framework 4.5, Tools und Infrastruktur für die grafische Verwaltung, Grafische Shell für Server, Windows PowerShell 4.0, Windows PowerShell ISE, Windows Server Sicherung, WoW64-Unterstützung und Unterstützung für die SMB 1.0/CIFS-Dateifreigabe entfernt werden. Die drei vorherigen Screenshots zeigen die korrekte Auswahl.

Die nächsten beiden Schritte werden mit „Weiter“ bestätigt – die nicht erforderlichen Rollen und Features werden nun entfernt:

Nachdem die Rollen und Features erfolgreich entfernt wurden muss der Server nach einem Klick auf „Schließen“ neu gestartet werden.

Nach einer erneuten Anmeldung als Administrator an dem neu gestarteten Server fällt auf, dass der Essentials Konfigurationsassistent nicht mehr automatsch startet. Im Server Manager ist zu sehen, dass die installierte Edition weiterhin Windows Server 2012 R2 Essentials ist:

Nun bietet es sich an den Computernamen anzupassen, das Netzwerk zu konfigurieren und alle aktuellen Updates am Server zu installieren.

Anschließend kann über den Server Manager die Hyper-V Rolle installiert werden. Nach erfolgreicher Konfiguration von Hyper-V können entsprechende virtuelle Switche sowie die VM in der Windows Server 2012 R2 Essentials installiert werden soll angelegt werden.

Achtung: Die Windows Server 2012 R2 Essentials Lizenz inkludiert nur die Nutzungsrechte für den Parent mit Hyper-V (es dürfen außer Hyper-V keine weiteren Rollen auf dem Parent installiert werden) und eine VM mit Windows Server 2012 R2 Essentials! Es sind keine weiteren VM Nutzungsrechte enthalten. Um weiter VMs mit Windows Server betreiben zu dürfen muss dem Host mindestens eine zusätzliche Windows Server 2012 R2 Standard Lizenz zugeordnet werden. Der Host kann wie in dem folgenden Artikel beschrieben anschließend in einen Windows Server 2012 R2 Standard umgewandelt werden: http://blog.mhblog.de/?p=339

Wenn das Gastbetriebssystem in der zu konvertierenden VM allerdings die Voraussetzungen für einen Generation 2 VM erfüllt:

kann in vielen Fällen das Convert-VMGeneration Script von John Howard (Senior Program Manager im Hyper-V Team bei Microsoft) helfen. Das Script ist unter folgendem Link zu finden:

https://code.msdn.microsoft.com/ConvertVMGeneration

Wichtig ist zu erwähnen, dass es weder von Microsoft, noch von John Howard einen Support für dieses Script gibt, d.h. Sie sollten für eine ausreichende Sicherung Ihrer VMs und Ihrer gesamten Umgebung sorgen bevor Sie mit der Konvertierung starten.

Zunächst muss die zu konvertierende VM gestartet werden. Dort muss in einer administrativen Eingabeaufforderung über das Kommando:

reagentc /disable

die Recovery Agent Konsole daktiviert werden:

Anschließend muss das Gastbetriebssystem in der VM heruntergefahren werden.

Auf dem Hyper-V Host muss nun ein ein PowerShell Fenster mit administrativen Rechten gestartet werden.

Dort wird über die Eingabe von:

Set-ExecutionPolicy –ExecutionPolicy unrestricted

die Execution Policy angepasst:

Anschließend kann über die folgende Eingabe der Konvertierungsvorgang gestartet werden:

.\convert-vmgeneration.ps1 -VMName „WS2012R2Gen1″ -Path W:\VMs

In meinem Beispiel wird die VM mit dem Namen „WS2012R2Gen1″ konvertiert und die Generation 2 VM soll unter „W:\VMs“ abgelegt werden:

Das Script erstellt eine neue Generation 2 VM welche die Einstellungen der ursprünglichen Generation 1 VM übernimmt. Für die neue Generation 2 VM wird auch eine neue virtuelle Festplatte erstellt. Um die Daten von der virtuellen Festplatte der Generation 1 VM auf die virtuelle Festplatte der Generation 2 VM zu übertragen werden beide virtuellen Festplatten am Host gemountet:

Prüfen Sie wie im Output des Konvertierungsscripts angegeben die gemounteten Festplatten am Host-System:

In meinem Beispiel wird die Disk 3 komplett überschrieben – deshalb bitte manuell über z.B. die Datenträgerverwaltung prüfen ob das so korrekt ist.

Nachdem mit „Y“ bestätigt wurde arbeitet das Script weiter. Je nach Datenmenge und Storage Durchsatz dauert es nun einige Zeit bis die Konvertierung abgeschlossen ist.

Nach Abschluss des Vorgangs gibt es eine neue virtuelle Maschine vom Typ Generation 2 – in meinem Beispiel „WS2012R2Gen1 (Generation 2):

Die ursprüngliche Generation 1 VM bleibt erhalten, sollte allerdings nachdem die Generation 2 VM erfolgreich getestet wurde gelöscht werden.

Starten Sie nun die durch die Konvertierung entstandene Generation 2 VM und melden Sie sich an. Öffnen Sie in der VM Konsole eine Eingabeaufforderung und führen Sie folgendes Kommando aus:

reagentc /enable

https://technet.microsoft.com/de-de/evalcenter/bb291020.aspx

Ein erster Überblick über Neuerungen in Windows Server 2016 TP4 findet sich in folgendem TechNet Artikel:

https://technet.microsoft.com/library/dn765472.aspx

Aus lizenztechnischer Sicht sieht es also so aus, dass es eigentlich nicht um die Anzahl der Accounts geht, sondern um reale Personen die im Essentials Netzwerk arbeiten. Jedem Individuum muss ein User Account im Windows Server 2012 R2 Essentials zugewiesen werden. Das bedeutet Windows Server 2012 R2 Essentials ist für Netzwerk mit maximal 25 IT Benutzern geeignet. Technisch ist das allerdings so, dass Windows Server 2012 R2 Essentials die Accounts wertet die in dem Essentials Dashboard angezeigt werden.

Die Lösung ist, die nicht benötigten Accounts im Essentials Dashboard auszublenden. Hierfür gibt es die Gruppe „WseInvisibleToDashboard“ im Active Directory – diese finden Sie in Active Directory Benutzer und Computer im Container Users:

Alle Mitglieder dieser Gruppe werden nicht im Essentials Dashboard angezeigt und zählen auch nicht mehr zum User Limit:

Nach Hinzufügen der Accounts und einem Klick auf OK verschwinden die User aus dem Essentials Dashboard:

Obwohl der Exchange Server weiterhin in der Umgebung integriert ist:

Wenn der Administrator neben dem Account „Administrator“ auch noch einen individuellen User Account in der Essentials Umgebung nutzt darf auch der Account „Administrator“ ausgeblendet werden.