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

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.

Die Obergrenze von maximal 25 Benutzern und 50 Devices kann allerdings nicht durch CALs erweitert werden.

Es besteht aber die Möglichkeit Windows Server 2012 R2 Essentials in einen Windows Server 2012 R2 Standard umzuwandeln. Dort stehen mit der Essentials Experience Rolle die Funktionalitäten von Essentials zur Verfügung. D.h. es muss nach dem Umwandeln nicht auf die Vorteile von Essentials verzichtet werden. Skalierbar ist Windows Server 2012 R2 Standard mit Essentials Experience Rolle auf bis zu 100 Benutzer und bis zu 200 Devices. Zu beachten ist allerdings, dass die Integrierten Nutzungsrechte von Windows Server 2012 R2 Essentials nicht in CALs umgewandelt werden – das bedeutet Sie benötigen für alle Benutzer (auch für die ersten 25) Windows Server 2012 CALs.

Zunächst benötigen Sie die Windows Server 2012 R2 Standard Lizenz inkl. Product Key sowie die benötigte Anzahl der Windows Server 2012 CALs um mit der Umwandlung zu starten.

Das Umwandeln von Windows Server 2012 R2 Essentials in Windows Server 2012 R2 Standard mit Essentials Experience Rolle erfolgt mit folgenden einfachen Schritten:

Sie können zunächst im Server Manager Prüfen ob tatsächlich Windows Server 2012 R2 Essentials installiert ist:

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

Über die Eingabe von DISM /online /Get-CurrentEdition können Sie auch hier die aktuell installierte Windows Version abfragen:

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

Das eigentliche Umwandeln von Windows Server 2012 R2 Essentials in Windows Server 2012 R2 mit Essentials Experience Rolle erfolgt durch Eingabe von: DISM /online /Set-Edition:ServerStandard /ProductKey:XXXXX-XXXXX-XXXXX-XXXXX-XXXXX /AcceptEula
Als ProductKey muss der Produktschlüssel der zuvor erworbenen Windows Server 2012 R2 Standard Lizenz eingegeben werden – wobei dies auch der Schlüssel einer OEM Version sein kann.

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:

Das Essentials Dashboard ist nach der Migration inkl. der Office 365 Integration weiterhin vollständig nutzbar. Es können jetzt bis zu 100 Benutzer und bis zu 200 Devices hinzugefügt werden. Achten Sie darauf, dass für jeden Benutzer eine Windows Server 2012 CAL erforderlich ist (es können natürlich auch Device CALs genutzt werden).

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:

„Unerwarteter Fehler. Wenden Sie sich an die für das Netzwerk zuständige Person, um das Problem zu beheben.“

Dieser Fehler wird angezeigt, weil der Client Connection Assistent unter Windows Server 2012 R2 Essentials nur für die folgenden Systeme ausgelegt ist:

• Windows 7 Service Pack 1 (SP1)
• Windows 8
• Windows 8.1
• Mac OS X 10.6 -10.8

Im Oktober 2015 soll ein Update für Windows Server 2012 R2 Essentials erscheinen welches die Unterstützung für Windows 10 hinzufügt.

Bis dieses Update verfügbar ist muss ein entsprechendes Update Paket auf den Windows 10 Client heruntergeladen werden der zur Essentials Umgebung hinzugefügt werden soll. Der Download findet sich unter:
http://www.microsoft.com/en-us/download/details.aspx?id=40285

Relevant sind die beiden Dateien:
Windows10.0-KB2790621-x64.msu
und
Windows10.0-KB2790621-x86.msu

Je nachdem ob es sich um ein 32Bit oder ein 64Bit System handelt muss das entsprechende Update Paket über einen Doppelklick installiert werden.

Die Sicherheitswarnung mit einem Klick auf „Öffnen“ bestätigen:

Anschließend durch einen Klick auf „Ja“ das Update Paket installieren:

Nach erfolgreicher Installation des Update Paketes wird das Installations-Fenster durch einen Klick auf „Schließen“ geschlossen:

Der Konfigurationsassistent für Windows Server Essentials muss manuell aus dem Startmenü des Windows 10 Clients aufgerufen werden (man geht also nicht über die Connection Website):

Die Sicherheitswarnung wird mit einem Klick auf „Ja“ bestätigt:

Der Konfigurationsassistent sollte den Essentials Server im Netzwerk automatisch finden (in meinem Fall „ESS-SRV01″):

Sollte der Server nicht automatisch gefunden werden kann die Serveradresse auch manuell eingegeben werden. Ich würde in diesem Fall allerdings empfehlen zunächst die Netzwerk- und IP Konfiguration zu überprüfen – sehr häufig liegt der Fehler dort, wenn der Server nicht automatisch gefunden wird.

Der Konfigurationsassistent selbst arbeitet unter Windows 10 wie bekannt. Zunächst sind Name und Kennwort eines Netzwerkbenutzers erforderlich:

,

Wenn ein administrativer Benutzer verwendet wurd wird eine Warnung angezeigt – über einen Klick auf „Nein“ kann allerdings auch der Administrative Benutzer für das Hinzufügen genutzt werden.

Anschließend wird der Computer durch einen Klick auf „Neu starten“ neu gestartet:

Nach dem Neustart kann gewählt werden, ob der Computer nur für den Benutzer selbst oder auch für weitere Benutzer eingerichtet wird:

Die Computerbeschreibung ist optional:

Auch die Sicherungseinstellungen für den Client werden im Assistenten festgelegt:

Abschließend wird der Computer konfiguriert:

Durch einen Klick auf „Fertig stellen“ wird der Assistent abgeschlossen:

Nun kann sich der Benutzer erstmalig an dem Windows 10 Client im Essentials Netzwerk anmelden:

Es gibt unter Windows 10 auch das gewohnte Launchpad:

Und im Essentials Dashboard wird der Client natürlich korrekt angezeigt, inkl. der Statusinformationen:

In Netzwerken mit Windows Home Server 2011, Windows Small Business Server 2011 Essentials und Windows Server 2012 Essentials (nicht R2) sind für Windows 10 Clients keine weiteren Aktionen erforderlich.

Viel Erfolg beim Einsatz von Windows 10 in Windows Server 2012 R2 Essentials Netzwerken!

Zunächst müssen die Einstellungen der VM geöffnet werden. Dort kann im Bereich „SCSI Controller“ ein neues virtuelles DVD Laufwerk hinzugefügt werden:

Jetzt kann unter dem Eintrag „DVD Drive“ ein iso-Image ausgewählt werden:

Durch einen Klick auf „OK“ werden die Einstellungen angewendet und die VM kann auf das gemountete iso-Image zugreifen und, sofern es sich um ein bootfähiges Image handelt, auch von diesem gebootet werden.