Microsoft hat jetzt dokumentiert, welche Gruppenrichtlinien-Einstellungen nur in der Enterprise Edition (und in der Education Edition) von Windows 10 anwendbar sind. Dies gilt ab Version 1607.

Für andere Editionen lassen sich die Einstellungen zwar setzen, sie wirken dort aber nicht.

[Group Policies that apply only to Windows 10 Enterprise and Education Editions (Windows 10)]
https://technet.microsoft.com/en-us/itpro/windows/manage/group-policies-for-enterprise-and-education-editions

Windows 10 unterstützt den Anwender nach Kräften dabei, die passende App für einen Datentyp zu finden.

In einigen Webforen finden sich Hinweise, dass ein Upgrade auf Windows 10, Version 1607 (“Anniversary Update”) bei aktivierter Bitlocker-Verschlüsselung manchmal Probleme macht. In solchen Fällen verläuft das eigentliche Upgrade wohl problemlos, doch ab dem ersten “echten” Reboot beschwert sich Windows über Probleme, auf den TPM-Chip zuzugreifen.

Dies tritt offenbar nur unter bestimmten Umständen auf, die momentan noch nicht bekannt sind. Eine Zuordnung zu bestimmter Hardware scheint derzeit nicht möglich zu sein. Der Fehler tritt nur in wenigen Fällen auf (bei meinem Rechner beispielsweise nicht).

Laut einem Eintrag in einem TechNet-Forum hat Microsoft allerdings das Problem durch die Analyse von Logdateien der Forenteilnehmer bereits identifiziert und arbeitet an einer Lösung. Bis dahin sollten Anwender von Bitlocker besondere Vorsicht beim Upgrade walten lassen und wichtige Daten vorher sichern.

[Windows 10 14393 (1607) Enterprise – Issues with TPM]
https://social.technet.microsoft.com/Forums/windows/en-US/d6530d19-6ca6-4697-bf81-6d7c08492bdb/windows-10-14393-1607-enterprise-issues-with-tpm?forum=win10itprogeneral#99a2f162-c7e3-494d-a402-863349388c79

Vor wenigen Tagen wiesen wir auf ein Upgrade-Problem für Windows 10, Version 1607, hin. Dort gibt es in bestimmten Konstellationen Schwierigkeiten mit der Bitlocker-Laufwerksverschlüsselung.

Ein aktueller Beitrag im TechNet-Forum gibt nun an, dass die Ursache des Problems bei Hyper-V liegt. Durch die neue Technik “DeviceGuard” gerät Windows aus dem Tritt, wenn Hyper-V auf einem Bitlocker-verschlüsselten Rechner aktiv ist und das Upgrade auf Version 1607 stattfindet. Einen Fix kündigt Microsoft für den 23. August 2016 an.

Einstweilen gibt es folgende Alternativen für Workarounds:

• Hyper-V vor dem Upgrade abschalten und erst nach dem Installieren des Updates vom 23. August wieder aktivieren.
• Vor dem Upgrade einen Registry-Key für DeviceGuard löschen (dann kann Hyper-V an oder aus sein)
• Bitlocker vor dem Upgrade abschalten und erst nach dem Fix vom 23. August wieder einschalten

Hier der Originalbeitrag von Microsoft:

[Windows 10 14393 (1607) Enterprise – Issues with TPM]
https://social.technet.microsoft.com/Forums/windows/en-US/d6530d19-6ca6-4697-bf81-6d7c08492bdb/windows-10-14393-1607-enterprise-issues-with-tpm?forum=win10itprogeneral#9422a326-b653-4b24-96c2-6fab882ed65f

Für die Fachzeitschrift “IT-Administrator” werde ich im Herbst eine Reihe von Trainings zu Hyper-V in Windows Server 2016 durchführen. Die eintägigen Veranstaltungen konzentrieren sich auf die Neuerungen für Hyper-V in der nächsten Windows-Server-Version, die Ende September erscheinen soll. Natürlich stelle ich Hyper-V auch insgesamt vor, sodass die Trainings auch für Interessierte geeignet sind, die mit Hyper-V bisher weniger zu tun hatten.

Die Schulungen sind als interaktiver Vortrag mit vielen Praxisdemos konzipiert, wir haben viel Raum für Fragen und Diskussion.

Hier geht es zu den Details, den Terminen und zur Anmeldung:

[IT-Administrator Workshops: Hyper-V unter Windows Server 2016]
https://www.it-administrator.de/trainings/210433.html

Wer seinen Admin-Rechner auf die Version 1607 von Windows 10 aktualisiert hat, muss die RSAT (Remote Server Administration Tools) neu installieren. Die Versionen, die in vorherigen Windows-10-Builds funktionierten, sind nicht mehr kompatibel.

Aktuell ist die Fassung aus dem TP5 von Windows Server 2016 die richtige:

[Download Remoteserver-Verwaltungstools für Windows 10 from Official Microsoft Download Center]
https://www.microsoft.com/de-de/download/details.aspx?id=45520&751be11f-ede8-5a0c-058c-2ee190a24fa6=True&fa43d42b-25b5-4a42-fe9b-1634f450f5ee=True#

Nach der Installation des Pakets sind die Tools automatisch aktiv. Es ist nicht mehr nötig, sie einzeln einzuschalten.

Wir haben kürzlich recht intensiv über ein Problem in Version 1607 von Windows 10 berichtet, das die Bitlocker-Verschlüsselung ins Straucheln brachte. Die Ursache war eine Unverträglichkeit mit der gleichzeitig aktivierten Virtualisierung per Hyper-V.

Wie angekündigt, hat Microsoft am 23. August 2016 ein Update veröffentlicht, das das Problem beheben soll. Die Zeit reichte natürlich noch nicht aus, um den Fix auf Herz und Nieren zu prüfen, doch erste Foren-Kommentare deuten darauf hin, dass das Problem nun gelöst ist.

Das Update kann man hier herunterladen (Misstrauen ist ob der nicht vorhandenen Beschreibung zwar verständlich, aber es soll sich um den richtigen Fix handeln):

[Servicing stack update for Windows 10 Version 1607: August 23, 2016]
https://support.microsoft.com/en-us/kb/3176936

Dieser Artikel erschien zuerst auf Timos Blog.

Um die Informationssicherheit zu gewährleisten, rate ich jedem dringend, insbesondere bei mobilen Geräte wie Notebooks/Laptops und Tablets (aber nicht begrenzt darauf), die Nutzung vollständiger Festplattenverschlüsselung zu erwägen. Das Verschlüsseln des permanenten Speichers (ganz gleich, ob Festplatte mit bewegelichen Teilen oder auf Flash-Speicher basierende SSD) stellt einen wichtigen Baustein für die Datensicherheit dar, hat aber auch seine Schattenseite: Die zur Verschlüsselung und Entschlüsselung benötigten Berechnungen erhöhen die Systemauslastung.

BitLocker ist in den beiden für professionelle Nutzung vorgesehenen Versionen von Windows 10 enthalten: Windows 10 Pro und Windows 10 Enterprise.

Nachdem ich neugierig war, welchen Einfluss die Verschlüsselung mittels BitLocker auf die Leistung der Festplatte hat, führte ich ein paar Tests durch. Das verwendete System ist ausgestattet mit einer i7-6700HQ CPU und 8 GiB RAM. Der Test berücksichtigt zwei verschiedene Speichermedien: eine „herkömmliche“ Festplatte mit rotierenden Scheiben sowie eine SSD.

Bitte beachtet, dass dieser Test absolut nicht wissenschaftlichen Kriterien genügt und die Ergebnisse abweichen können und werden.

Testergebnisse: SSD-Laufwerk

Testergebnisse: Festplatte

Der Test wurde mittels CrystalDiskMark 5.1.2 durchgeführt.

Die Leistung für wahlfreies Lesen/Schreiben wurde in meinem Fall durch die Verschlüsselung im Schnitt um circa 16% verringert bei der SSD und ungefähr den gleichen Wert bei der HDD, mit Ausnahme des wahlfreien Schreibens. Die Ursache hierfür ist mir unklar.

Aus diesen Benchmark-Ergebnissen lässt sich ein nennenswerter Leistungsverlust des reinen Datendurchsatzes ableiten. Vermutlich wird man diesen bei besonders IO-intensiven Aufgaben bemerken können.

Allerdings empfehle ich, sich nicht von diesen Werten abschrecken zu lassen. Das beruhigende Gefühl, schützenswerte Daten recht gut geschützt zu wissen, entschädigt für die Festplatten-Leistungseinbuße, die sicherlich in vielen realen Anwendungsfällen nicht die größte Rolle spielt. Dennoch solltet ihr eure Tests auf euren eigenen Systemen durchführen, falls die Festplatten-Leistung in eurer Umgebung als kritischer Faktor anzusehen ist – wenngleich ihr dann vermutlich ohnehin ein anderweitiges Speichersystem wie ein SAN mit verschlüsselten Platten/SSDs nutzen wollt.

Abschließend möchte ich darauf hinweisen, dass der BitLocker-Wiederherstellungschlüssel unbedingt an einem oder mehreren sicheren Orten verwahrt werden sollte.

Für das Hyper-V-Training, das ich am 28. September 2016 in Dortmund für die Zeitschrift “IT-Administrator” halte, sind noch Teilnehmerplätze erhältlich. Bei den beiden anderen Terminen in Hamburg und Dietzenbach (bei Frankfurt) wird es jetzt langsam eng.

Wer noch Interesse hat oder wer sich gleich anmelden möchte, findet alles Wichtige hier:

[IT-Administrator Workshops]
https://www.it-administrator.de/trainings/210433.html

Am ersten Tag der Konferenz Ignite 2016 hat Microsoft am 26. September den neuen Windows Server 2016 vorgestellt und freigegeben. Das Produkt gilt damit als veröffentlicht und erhältlich.

Doch Vorsicht: Der Download, der parallel zur Konferenz freigegeben wurde, umfasst nur die Eval-Version, die auf 180 Tage Laufzeit begrenzt ist. Das “echte” Produkt, das sich für produktiven Betrieb eignet, wird erst “Mitte Oktober” verfügbar sein. Dann steht es Volumenlizenzkunden zum Download zur Verfügung. Ebenso ist erst dann damit zu rechnen, dass die finale Fassung im MSDN bereitsteht.

Die offizielle Ankündigung:

[Announcing the launch of Windows Server 2016 – Hybrid Cloud]
https://blogs.technet.microsoft.com/hybridcloud/2016/09/26/announcing-the-launch-of-windows-server-2016/

Bereits im Juli hat Microsoft ein Datenblatt zur Lizenzierung des neuen Windows Server 2016 veröffentlicht. Dieses ist kein rechtsverbindliches Dokument und ersetzt nicht den Lizenzvertrag, sondern es gibt einen allgemeinen Überblick über die Eigenheiten und das Neue in der Lizenzierung.

Ein paar wichtige Punkte daraus:

• Die Standard Edition und die Datacenter Edition unterscheiden sich in ihren Funktionen. Nur mit Datacenter gibt es:
• Storage Replica und Storage Spaces Direct
• Shielded Virtual Machines
• den vollständigen virtuellen Netzwerkstack
• Die Installations-Option “Nano Server” erfordert eine aktive Software Assurance.
• Nano-Server folgen dem Update-Modell “Current Branch for Business”, müssen also regelmäßig aktualisiert (bzw. neu erzeugt) werden.
• Windows Server Containers sind nicht separat zu lizenzieren. Hyper-V Container hingegen “belegen” eine VM-Lizenz.
• Auch weiter gilt das CAL-Modell: Neben der eigentlichen Serverlizenz benötigt man für alle zugreifenden User oder Geräte jeweils eine CAL.
• Die Standard Edition und die Datacenter Edition werden künftig nach Cores lizenziert (nicht mehr nach CPUs).
• Das Minimum sind dabei 16 Cores (für die der Lizenzpreis in etwa dem bisherigen Preis von Windows Server 2012 R2 für zwei CPUs entspricht).
• Weitere Cores kann man in Zweierpaketen lizenzieren, wobei pro CPU mindestens 8 Cores zu lizenzieren sind.
• Kunden mit aktiver Software Assurance für ihre Server-Lizenzen können während der aktiven Vertragslaufzeit kostenlos auf Windows Server 2016 umsteigen. Erst bei der nächsten Verlängerung des Vertrags wird dieser auf die Core-Lizenzierung umgestellt (und damit dann evtl. teurer).

Windows Server 2016 wird im Oktober 2016 in Microsofts Preislisten erscheinen und dann zügig die einzige Version sein, die man neu erwerben kann.

Link zum Download des Datenblatts (Stand Juli 2016):
http://download.microsoft.com/download/7/2/9/7290EA05-DC56-4BED-9400-138C5701F174/WS2016LicensingDatasheet.pdf

Link zu Lizenz-FAQs (Mai 2016):
http://download.microsoft.com/download/7/2/9/7290EA05-DC56-4BED-9400-138C5701F174/WSSC2016LicensingFAQ.pdf

Seit Windows Server 2012 R2 zeigt der Hyper-V-Manager für jede VM eine “Version” an. Dies ist dort ausgesprochen langweilig, denn es steht immer “5.0” in dem Feld. Aussagekräftig wird die Version erst mit Windows Server 2016.

Schon seit der ersten Hyper-V-Ausgabe tragen VMs intern Versionsnummern. Hierüber identifiziert der Host, welche Konfigurationsdaten für eine VM vorhanden sind. Bislang war diese Version faktisch an Hyper-V auf dem Host gekoppelt, denn jede Host-Version konnte nur genau eine VM-Konfigurationsversion nutzen. Übertrug man eine VM von einem “älteren” auf einen “neueren” Host – per Export und Import oder von Windows Server 2012 nach Windows Server 2012 R2 auch per Shared-Nothing Live Migration – dann konvertierte der Host die VM-Version stillschweigend. Damit war die VM nur mit diesem neueren Hyper-V-System kompatibel. Auf den “älteren” Host ließ sie sich dann nicht zurück übertragen.

Mit Windows Server 2016 gibt es nun (endlich) die Funktion “Cluster Rolling Upgrades” für Hyper-V-Cluster. Damit kann man einen bestehenden Cluster von Windows Server 2012 R2 aus Schritt für Schritt auf die neue Windows-Version bringen, indem man einzelne Hosts nacheinander mit Windows Server 2016 installiert und sie dann in den bestehenden Cluster wieder aufnimmt. Solange dieser Prozess noch nicht für alle Hosts abgeschlossen ist, läuft der Cluster im Mischbetrieb von 2012 R2 und 2016.

Während dieser Aktualisierungsphase kann man bestehende VMs frei zwischen den verschiedenen Hosts hin- und herschieben, denn Hyper-V in Windows Server 2016 konvertiert die VM-Konfigurationsversionen nicht mehr automatisch. Eine VM, die von einem 2012-R2-Host stammt, behält so ihre Version 5.0, bis man sie manuell aktualisiert. Erst dann kann sie nicht mehr auf einem älteren Host laufen.

In Windows Server 2016 kann man neue VMs auch gezielt mit einer älteren Konfigurationsversion erzeugen. Dies geschieht über den Schalter -version im PowerShell-Cmdlet New-VM. So lassen sich auch neu angelegte VMs in einem Misch-Cluster frei verschieben.

Bislang hatte Microsoft nicht ausdrücklich dokumentiert, welche Eigenschaften zu bestimmten VM-Versionen gehören. Da es in der Preview-Phase von Windows Server 2016 gleich mehrere neue VM-Konfigurationsversionen gab (6.0, 6.1, 6.2, 7.0, 7.1 und 8.0 – die Versionen vor 6.2 sind aber nicht mehr vorhanden), hat der Hersteller nun eine Übersicht veröffentlicht, welche Version für welche Funktion notwendig ist. Diese findet sich hier:

[Upgrade virtual machine version in Hyper-V on Windows 10 or Windows Server 2016]
https://technet.microsoft.com/en-us/windows-server-docs/compute/hyper-v/deploy/upgrade-virtual-machine-version-in-hyper-v-on-windows-or-windows-server

Interessanterweise gibt das Cmdlet Get-VMHostSupportedVersion auch zwei Versionen mit den Nummern 254.0 und 255.0 zurück, die als “Vorabversion” und “Experimentell” gekennzeichnet sind. Erzeugt man eine VM mit einer dieser Versionen, so warnt Hyper-V:

Das Skript Check-WindowsSecurityBasics.vbs prüft automatisiert einige grundlegende Sicherheitseinstellungen einer Windows-Installation:

• Den Virenscanner (nur bei Clients)
• Den Update-Status
• Den Status der Windows-Firewall
• Die Mitglieder der lokalen Administratoren

Es kann daher als Grundlage für weitere Untersuchungen dienen und erspart einiges Klicken und manuelles Notieren. Da es in VBScript geschrieben ist, sollte es auch mit älteren Windows-Versionen funktionieren und benötigt keine PowerShell.

Die Überprüfung des Virenscanners läuft über das Windows Security Center, das nur auf Clients (ab Windows 7) vorhanden ist. Auf Servern gibt dieser Test also kein Eregbnis.

Den Update-Status prüft das Skript über das Windows-Update-API. Zur Einschätzung der Update-Versorgung versucht das Skript dabei auch zu ermitteln, wie viele Updates für ein frisch installiertes System verfügbar wären. Bei einer Installation, die schon länger läuft, können durchaus mehr Updates vorhanden sein, als für eine Neuinstallation anstünden: Das liegt daran, dass manche Updates bereits durch andere ersetzt wurden.

Diese Prüfung braucht oft eine ganze Weile. Falls es besonders lange dauert, kann das daran liegen, dass der Component Store in Unordnung geraten ist. Der folgende Blog-Artikel beschreibt, wie man ihn reparieren kann:

[Fixing Component Store Corruption in Windows 8 and Windows Server 2012 – TechNet Blogs]
https://blogs.technet.microsoft.com/joscon/2012/09/26/fixing-component-store-corruption-in-windows-8-and-windows-server-2012/

Das Skript arbeitet auf der Kommandozeile, es ist daher mit cscript in einem CMD-Fenster aufzurufen, nicht per Doppelklick. Die Ausgabe leitet man am besten in eine Datei um:

cscript //nologo C:\Pfad\Check-WindowsSecurityBasics.vbs > C:\Pfad\Ergebnis.txt

Mit einigen Schaltern kann man das Verhalten des Skripts steuern:

• /mode:csv – schaltet auf CSV-Ausgabe um, dann kann man das Ergebnis z.B. mit Excel auswerten. Das ist praktisch, wenn man die Ergebnisse mehrerer Rechner gemeinsam analysiert.
• /headers:yes – gibt im CSV-Betrieb die Spaltenüberschriften mit aus. Sammelt man die Ergebnisse mehrerer Rechner in einer Datei (z.B. in einer Server-Dateifreigabe), so kann man beim ersten Rechner die Überschriften mit ausgeben, auf den folgenden dann nicht.
• /updatesearch:no – überspringt den Windows-Update-Check.
• /verbose:no – lässt die ausführlichen Angaben weg.
• /help oder /? – zeigt die Syntaxhilfe an.

Das Skript sollte ohne Administratorrechte ausführbar sein.

Didier Van Hoye hat in einem Artikel beschrieben, warum das Verkleinern von VHDX-Dateien in Hyper-V manchmal nicht funktioniert, woran das liegt und was man dann tun kann.

[You cannot shrink a VHDX file because you cannot shrink the volume on the virtual disk – Working Hard In IT]
https://blog.workinghardinit.work/2016/08/09/you-cannot-shrink-a-vhdx-file-because-you-cannot-shrink-the-volume-on-the-virtual-disk/

Nach der Freigabe von Windows Server 2016 hat Microsoft nun auch neue Remote Server Administration Tools für Windows 10 bereitgestellt.

[Download Remoteserver-Verwaltungstools für Windows 10 from Official Microsoft Download Center]
https://www.microsoft.com/de-DE/download/details.aspx?id=45520

In einem sehr lesenswerten Artikel hat Eric Siron die Funktion “Dynamic Memory” von Hyper-V beschrieben und einige Hinweise zum Umgang damit gegeben.

[Hyper-V Dynamic Memory – An Illustrated Guide]
http://www.altaro.com/hyper-v/hyper-v-dynamic-memory-explanation-and-recommendations-2/

Die Netzwerkoptionen in Hyper-V gehören zu den Komponenten, die am häufigsten missverstanden werden. Das liegt nicht an der eigentlichen Technik, sondern an der Einbindung in die grafische Verwaltungsoberfläche. Hier hat Microsoft seit vielen Jahren leider die Gelegenheit versäumt, ein übersichtliches Werkzeug bereitzustellen.

Der Hyper-V-Experte Eric Siron hat in einem Blog-Artikel die Technik und die Zusammenhänge sehr gut dargestellt:

[What is the Hyper-V Virtual Switch and how does it work?]
http://www.altaro.com/hyper-v/the-hyper-v-virtual-switch-explained-part-1/

Windows Server 2016 ist jetzt seit einigen Wochen verfügbar, und Kunden prüfen, wann und wie sie das neue System einsetzen können. Besonders für Hyper-V-Umgebungen stellt sich da die Frage, wie man vorhandene VMs auf die neue Version migriert.

Zwar trommelt Microsoft laut für das “Cluster Rolling Upgrade”, bei dem man mit wenig Aufwand und ohne Downtime auf die Version 2016 kommt. Aber: Das geht nur, wenn die betreffenden VMs bisher auf einem Cluster unter Windows Server 2012 R2 laufen. Wer eine ältere Version oder keinen Cluster hat, kommt damit nicht weiter.

Hier eine Übersicht über die möglichen Methoden.

In-place Upgrade

Grundsätzlich unterstützt Microsoft das direkte Upgrade eines laufenden Hyper-V-Hosts auf Windows Server 2016. Voraussetzung: Der Quell-Host läuft mit Windows Server 2012 oder 2012 R2.

Wer Hyper-V unter Windows Server 2008 oder 2008 R2 einsetzt, kann diese Methode nicht nutzen. Allenfalls wäre hier ein doppeltes In-place Upgrade möglich: Erst von 2008/R2 auf 2012/R2 und von dort auf 2016. Dadurch verdoppeln sich aber die Risiken und die Ausfallzeit.

Diese Methode sollte man nur einsetzen, wenn das Quell-Betriebssystem “sauber” läuft und keine weitere Software installiert ist. Außerdem sollte man natürlich prüfen, ob alle nötigen Treiber für Windows Server 2016 vorhanden sind.

Während des Upgrades stehen die VMs nicht zur Verfügung, es ist also eine Downtime nötig.

Cluster Rolling Upgrade

Diese Methode ist nutzbar, wenn die VMs auf einem Failover-Cluster unter Windows Server 2012 R2 laufen. Windows Server 2012 (ohne R2) reicht nicht.

Prinzipiell räumt man hierbei einen Clusterknoten frei, indem man alle VMs auf andere Knoten verschiebt. Dann installiert man diesen Server neu und nimmt ihn wieder in den Cluster auf – oder man ersetzt ihn durch einen neuen Server. Ab da kann man VMs von einem der 2012-R2-Hosts auf den 2016-Host verschieben. So geht es dann weiter, bis alle Knoten ausgetauscht bzw. aktualisiert sind. Am Ende stellt man die VM-Versionen auf den neuesten Stand um (derzeit 8.0).

Prinzipiell kann man die vorhandenen Knoten auch freiräumen und dann per In-place Upgrade aktualisieren, aber das bringt nur wenige Vorteile. Zudem gibt es derzeit Probleme bei dieser Variante des Verfahrens, man sollte also noch die nötigen Updates abwarten. Eine saubere Neuinstallation ist also vorzuziehen.

Diese Methode erfordert keine Downtime für die Anwender.

Cluster-Migrationsassistent

Der Cluster-Migrationsassistent unterstützt bei der VM-Migration von Windows Server 2012 oder 2012 R2 nach Windows Server 2016. Interessant ist er aber nur für 2012, denn von 2012 R2 kann man besser per Cluster Rolling Upgrade kommen.

Hierbei baut man parallel zu dem bestehenden 2012-Cluster einen neuen 2016-Cluster auf. Dort führt man dann den Assistenten aus (“Clusterrollen kopieren”). Dieser übernimmt die Konfigurationen der VMs, lässt diese aber sonst unangetastet. Im nächsten Schritt fährt man alle VMs und den 2012-Cluster herunter, koppelt das Storage ab und verbindet es mit den Knoten des 2016-Clusters. Dort kann man die VMs dann starten.

Die Methode erfordert eine (kurze) Downtime.

Shared-Nothing Live Migration

Von Hosts unter Windows Server 2012 oder 2012 R2 kann man laufende Maschinen direkt auf einen Host unter Windows Server 2016 migrieren. Das funktioniert auch mit Clustern.

Die Shared-Nothing Live Migration migriert sowohl die VMs selbst als auch die virtuellen Festplatten. Ein gemeinsames Storage zwischen beiden Versionen ist nicht nötig. Da alle VMs weiter laufen, dürfte dies die beste Methode sein, wenn man von 2012 oder 2012 R2 kommt.

Dieses Verfahren erfordert keine Downtime.

Migration mit Hyper-V Replica

Hat man Windows Server 2012 oder 2012 R2, dann kann man auch per Replica nach Windows Server 2016 migrieren.

Man richtet dazu unter 2012 oder 2012 R2 die Replikation für die betreffenden VMs ein und gibt den 2016-Host als Ziel an. Sind die VMs vollständig repliziert, dann führt man ein “Geplantes Failover” aus. Dieses scheitert im letzten Schritt, denn Hyper-V kann die Replikationsrichtung nicht umkehren. Das macht aber nichts, denn die eigentliche Umschaltung ist dann vorbereitet und alle Änderungen sind übertragen. Nun schaltet man die Quell-VMs ab und die Ziel-VMs ein. Am Ende entfernt man auf beiden Seiten die Replikation.

Diese Methode erfordert eine (kurze) Downtime für die VMs.

VMs kopieren und importieren

Hyper-V unter Windows Server 2016 kann VMs von allen seinen Vorgängern importieren. Dazu beendet man die Quell-VM und kopiert sie vollständig auf den neuen Host (VM-Konfiguration und virtuelle Festplatten). Dort ruft man die Import-Funktion auf und nutzt (idealerweise) die Option “direkt registrieren”. Sofort danach kann man die VM starten.

Diese Methode erfordert eine (kurze) Downtime für die VMs.

Host-Festplatten umkoppeln und VMs importieren

Dieses Verfahren ist eine Variante des “normalen” Imports. Es funktioniert ebenfalls mit VMs von allen Hyper-V-Versionen.

Man fährt die Quell-VMs und den “alten” Host herunter. Nun baut man die Festplatte(n) aus und verbindet sie mit dem neuen Host. Sofern es sich um LUNs aus dem SAN handelt, ändert man nur die Zugriffskonfiguration. Auf dem Quell-Host führt man dann ebenfalls einen Import aus, wieder mit der Option “registrieren”. Bei Bedarf kann man auf dem 2016-Host die VMs dann auf das endgültige Storage (live) verschieben.

Wichtig: Hier arbeitet man mit den Original-VMs und erzeugt keine Kopie! Ein Backup ist also unerlässlich.

Diese Methode erfordert eine (kurze) Downtime für die VMs.

VM-Backup und -Restore

Windows Server 2016 kann die Windows-Server-Backups seiner Vorgänger lesen und wiederherstellen. Diese Methode eignet sich also unabhängig von der Quell-Version.

Man sichert die VMs mit Windows Server Backup auf eine Freigabe oder ein Wechselmedium. Auf dem 2016-Host stellt man die VMs dann wieder her. Als kleine Hürde erweisen sich die Namen der VMs, die Windows Server Backup leider nicht korrekt ausliest. Hier hilft ein kleines PowerShell-Skript.

Diese Methode erfordert eine Downtime für die VMs.

Backup und Restore in der VM

Natürlich kann man auch “innerhalb” der VM ein Backup erzeugen und dieses in einer neuen VM auf dem Zielhost wiederherstellen. Damit ist man völlig unabhängig von den Host-Versionen. Der Aufwand ist aber relativ hoch.

Diese Methode erfordert eine Downtime für die VMs.

Überblick: Was eignet sich wann?

Die folgende Tabelle listet auf, von welcher Hyper-V-Version aus sich mit welcher Methode VMs nach Windows Server 2016 bringen lassen. Die Spalte “Downtime” gibt an, ob durch die Methode eine Downtime für die Anwender entsteht.

Microsoft bietet seinen Kunden jetzt eine Option, den Herstellersupport für bestimmte Serverprodukte auf insgesamt 16 Jahre zu verlängern. Das neue Programm “Premium Assurance” lässt sich kostenpflichtig für Windows Server und SQL Server hinzubuchen.

Bisher gewährt Microsoft einen definierten Supportzeitraum für seine professionellen Produkte, der sich in die zwei Phasen “Mainstream Support” (fünf Jahre nach Erscheinen) und “Extended Support” (weitere fünf Jahre) aufteilt. Wer für seine Lizenzen das Upgrade-Abo “Software Assurance” abgeschlossen hat, kann für bestehende Installationen jetzt eine dritte Supportphase von sechs Jahren hinzukaufen. Die ersten Produktversionen, für die dies möglich ist, sind Windows Server 2008 und SQL Server 2008.

Näheres dazu findet sich hier:

[Introducing Windows Server Premium Assurance and SQL Server Premium Assurance | Hybrid Cloud Blog]
https://blogs.technet.microsoft.com/hybridcloud/2016/12/08/introducing-windows-server-premium-assurance-and-sql-server-premium-assurance/

Windows 10 und Windows Server 2016 enthalten eine Konfigurationsänderung, die es Angreifern erschwert, neue Ziele in einem Netzwerk ausfindig zu machen und zu erreichen. Dazu ändern sie das Verhalten des SAMR-Protokolls, das es seit frühen Windows-NT-Versionen gibt.

Bislang war es jedem authentifizierten Benutzer möglich, alle Benutzerkonten eines Computers oder der Domäne aufzulisten. Das ermöglicht eine Reihe weitergehender Angriffe (ein Beispiel gibt es bei uns mit einem simplen DOS-Angriff auf eine Domäne). Dabei umgeht die hier diskutierte Methode das Active Directory und das Kerberos-Protokoll, indem es mit der alten SAM-Logik von Windows NT arbeitet.

Seit Windows 10, Version 1607, und der Release-Version von Windows Server 2016 hat sich hier die Zugriffslogik geändert, indem die Remote-Abfrage nur noch für Administratoren erlaubt ist. Ein PowerShell-Skript in der TechNet Gallery erlaubt eine granularere Steuerung:

[TechNet SAMRi10 – Hardening SAM Remote Access in Windows 10/Server 2016]
https://gallery.technet.microsoft.com/SAMRi10-Hardening-Remote-48d94b5b