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

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

http://blogs.technet.com/b/exchange/archive/2015/10/01/exchange-server-2016-forged-in-the-cloud-now-available-on-premises.aspx

Aus Sicht des Windows Server Betriebssystems sind die Anforderungen Seitens Exchange 2016 interessant. Eine Auflistung der Exchange 2016 Anforderungen finden Sie unter:

https://technet.microsoft.com/de-de/library/aa996719(v=exchg.160).aspx

Bitte beachten Sie: als Serverbetriebssystem für Exchange 2016 wird Windows Server 2012 R2 oder Windows Server 2012 benötigt – ältere Windows Server Betriebssysteme werden nicht unterstützt.

Informationen zur Konfiguration von Windows Server 2012 R2 für den Betrieb von Exchange 2016 finden Sie unter:

https://technet.microsoft.com/de-de/library/bb691354(v=exchg.160).aspx

Mit der Einführung von Exchange 2016 stellt sich auch die Frage nach den unterstützten Outlook Versionen. Exchange 2016 unterstützen die folgenden Versionen von Outlook:

•Outlook 2016
•Outlook 2013
•Outlook 2010 mit KB2965295
•Outlook für Mac 2016
•Outlook für Mac für Office 365
•Outlook für Mac 2011

Ältere Outlook Versionen werden nicht unterstützt. Diese sind auch die Versionen von Outlook die für Exchange online / Office 365 unterstützt werden.

Den Download für Exchange 2016 finden Sie unter folgendem Link:

http://www.microsoft.com/en-us/download/details.aspx?id=49161

Wichtig: die folgenden Schritte sind von Microsoft nicht supported und deshalb nur zu Testzwecken geeignet! Auch lassen sich natürlich die in dem virtuellen Hyper-V System angelegten VMs nicht starten, da der virtuelle Server in dem Hyper-V aktiviert wird keinen Zugriff auf die Virtualisierungsfeatures des physischen Prozessors hat. Ansonsten können aber die wichtigsten Hyper-V Funktionen getestet werden. Auch ein Hyper-V Cluster kann so zu Testzwecken aufgebaut werden.

Der Versuch die Hyper-V Rolle in einer unter Hyper-V betriebenen VM im Servermanager zu aktivieren schlägt mit folgender Fehlermeldung fehl:

Die Hyper-V Managementtools lassen sich allerdings in der Liste der Features erfolgreich auswählen und installieren:

Die Installation von Hyper-V muss über die Powershell erfolgen – geben Sie folgendes in einem PowerShell Fenster ein:

Enable-WindowsOptionalFeature –Online -FeatureName Microsoft-Hyper-V –All

Hyper-V wir nun in der VM aktiviert (der Hyper-V Manager wurde bereits wie zuvor beschrieben über den Server Manager installiert):

Abschließend ist ein Neustart des virtuellen Servers erforderlich:

Nach dem Neustart des virtuellen Windows Servers können dort über den Hyper-V Manager VMs angelegt werden:

Wie bereits eingangs erwähnt lassen sich diese VMs in der VM nicht starten. Bei dem Versuch dies doch zu tun erscheint die folgende Fehlermeldung:

In den Details ist dann folgendes nachzulesen:

Option 1 und Option 2 könnten zutreffend sein, wenn Hyper-V neu aktiviert wurde – Hyper-V lässt sich nämlich auch auf Systemen die nicht alle Voraussetzungen für den Einsatz von Hyper-V erfüllen aktivieren. In diesem Fall könnten natürlich keine VMs gestartet werden.

Die Ursachen die unter der 3. Option genannt sind könnten allerdings durchaus auch bei einem System auftreten auf dem Hyper-V zuvor problemlos lief. Es gibt mehrere mögliche Ursachen für diese Fehlermeldung:

Sie haben gerade den physischen Hyper-V Host über ein Bare Metal recovery wiederhergestellt (das funktioniert sehr gut mit den Boardmitteln von Windows Server Backup)
oder
Sie haben auf dem Hyper-V Host unter Windows eine Datenträgerspiegelung eingerichtet und der Server startet nach Ausfall der ersten physischen Platte neu
oder
Sie haben anderweitig bewusst oder unbewusst Änderungen an der Bootkonfiguration vorgenommen

Die Lösung des Problems ist dann sehr einfach – Sie benötigen eine Eingabeaufforderung in der Sie folgendes eingeben müssen:

bcdedit /set hypervisorlaunchtype auto

Nach einem Neustart des Hyper-V Hosts lassen sich dann auch alle VMs wieder starten.

Über die Eingabe von:

bcdedit /enum

lassen Sie übrigens die konfigurierten Booteinstellungen anzeigen – auch der Starttyp des Hypervisors:

Häufig entscheidet man sich während einer Evaluation den Windows Server genau so produktiv einsetzen zu wollen. Dazu muss der Server nicht neu installiert werden – nachdem eine Lizenz für Windows Server 2012 R2 Standard oder Datacenter erworben wurde kann die Evaluationsversion ohne Neuinstallation in eine nicht laufzeitbeschränkte Version umgewandelt werden. Dies ist auch möglich, wenn es sich bei der später erworbenen Lizenz um eine OEM Lizenz handelt.

Für das Umwandeln ist es allerdings nicht ausreichend einfach nur den Product Key einzugeben. Folgende Schritte sind erforderlich:

Der Server sollte eine Internetverbindung besitzen, damit die erforderliche Aktivierung automatisch erfolgen kann.

Öffnen Sie an dem Server der umgewandelt werden soll zunächst eine Eingabeaufforderung mit erhöhten Rechten.

Über die Eingabe von DISM /online /Get-CurrentEdition können Sie die aktuell installierte Evaluationsversion abfragen:

In diesem Beispiel wurde Windows Server 2012 R2 Standard als Evaluationsversion installiert (ServerStandardEval).

Über die Eingabe von DISM /online /Get-Targeteditions lassen sich die möglichen Zieleditionen ausgeben:

Zu beachten ist dabei, dass die Evaluationsversion von Windows Server Standard in die nicht laufzeitbeschränkten Versionen Windows Server Standard oder Windows Server Datacenter umgewandelt werden kann. Die Evaluationsversion von Windows Server Datacenter lässt sich nur in die nicht laufzeitbeschränkte Version von Windows Server Datacenter umwandeln.

Wenn also zu Beginn der Evaluation noch nicht ganz klar ist welche der beiden Editionen später eingesetzt werden soll ist man mit der Evaluationsversion von Windows Server Standard etwas flexibler.

Das eigentliche Umwandeln der Evaluationsversion in eine nicht laufzeitbeschränkte Version erfolgt durch Eingabe von: DISM /online /Set-Edition:ZIELEDITION /ProductKey:XXXXX-XXXXX-XXXXX-XXXXX-XXXXX /AcceptEula wobei ZIELEDITION durch eine der ermittelten Zieleditionen aus dem vorherigen Befehl zu ersetzen ist. Als ProductKey muss der Produktschlüssel der erworbenen Zieledition eingegeben werden – wobei dies auch der Schlüssel einer OEM Version sein kann.

Im folgenden Beispiel wird die Evaluationsversion von Windows Server 2012 R2 Standard in eine nicht laufzeitbeschränkte Version von Windows Server 2012 R2 Standard umgewandelt:

Der Server muss anschließend zweimal neu gestartet werden. Durch Eingabe von „Y“ erfolgen die beiden Neustarts automatisch.

Das Ergebnis kann z.B. durch die Eingabe von DISM /online /Get-CurrentEdition geprüft werden:

Alternativ können über slmgr /dli bzw. slmgr /dlv erweiterte Informationen zur Edition und Lizenz abgefragt werden.

Diese Schritte beziehen sich nur auf Windows Server Standard und Datacenter. Ein Server der mit einer Evaluationsversion installiert wurde und bereits als Domain Controller konfiguriert ist kann nicht umgewandelt werden.

Sie können die ISO Dateien aus dem TechNet Evaluation Center natürlich auch verwenden um virtuelle Maschinen zu installieren. Diese können anschließend durch die oben beschriebenen Schritte mit dem Lizenzschlüssel der dem Hyper-V Host zugewiesen wurde in nicht laufzeitbeschränkte virtuelle Windows Server umgewandelt werden. Dies ist sehr hilfreich, wenn aus technischen Gründen ein OEM Medium nicht für die Installation der virtuellen Windows Server genutzt werden kann.

Zunächst müssen Sie im Servermanager unter „Manage“ die Option „Add Roles and Features“ aufrufen:

Der erste Schritt des Assistenten wird über einen Klick auf „Next“ bestätigt:

Im nächsten Schritt bleibt die Option „Role-based or feature-based installation“ ausgewählt.

Wählen Sie in der Liste den Server aus für den die grafische Shell für den Server installiert werden soll. In meinem Szenario wird der lokale Server ausgewählt:

Es werden keine zusätzlichen Rollen benötigt:

In der Liste der Features gibt es den Bereich „User Interfaces and Infrastructure“. Da mein Server als „Windows Server Technical Preview 2 (with local admin tools)“ installiert wurde ist der Punkt „Graphical Management Tools and Infrastructure“ bereits ausgewählt und installiert. Über die Auswahl der Option „Server Graphical Shell“ wird das vollständige grafische Windows Interface inkl. Explorer und Internet Explorer installiert:

Bei zusätzlicher Auswahl der Option „Desktop Experience“ wird die vollständige Desktop Experience von Windows 10 am Server installiert – dies wird z.B. bei RDS Hosts benötigt:

Ich wähle für meinen Server nur die Option „Server Graphical Shell“ aus:

Im nächsten Schritt wird die Option „Restart the destination server automatically if required“ ausgewählt, da die ausgewählten Änderungen einen Neustart des Servers erfordern. Wurde diese Option nicht gewählt erfolgt kein automatischer Server Neustart. Da zu diesem Zeitpunkt allerdings die vollständige grafische Oberfläche noch fehlt muss der Neustart über die Eingabeaufforderung durchgeführt werden. Dies ist nach Installation der Features über die Eingabe von „shutdown -r“ in der Eingabeaufforderung möglich.

Nach einem Klick auf „Install“ werden die Features installiert und da die Option „Restart the destination server automatically if required“ gewählt wurde erfolgt anschließend ein automatischer Neustart des Servers:

Nach dem Neustart des Servers erfolgt die Anmeldung mit einem administrativen Benutzer:

Nach dem Login wird automatisch das Fenster für die Installationsprozess angezeigt – daraus lässt sich die erfolgreiche Installation der ausgewählten Features ablesen:

Nach einem Klick auf „Close“ steht jetzt nicht nur der Server Manager zur Verfügung:

Sondern auch der Windows Desktop mit dem neuen Startmenü:

Im Startmenü findet sich auch ein eigener Bereich für die administrativen Tools:

Für die Windows Server Technical Preview 2 gibt es somit vielfältige Möglichkeiten für die Konfiguration des Servers und des User Interface:

Über angepasstes Setup:
Nano Server
(das Vorgehen für die Installation der Windows Server Technical Preview 2 als Nano Server wird in einem späteren Artikel betrachtet)

Während des klassischen Setups:
Windows Server Technical Preview 2 -> Server Core
Windows Server Technical Preview 2 (with local admin tools)

Nach dem Setup:
Server Graphical Shell
Desktop Experience

Je nach Einsatzszenario des Servers lässt sich die Windows Server Technical Preview 2 (Windows Server 2016) noch besser an die jeweiligen Anforderungen anpassen.