Zum Inhalt springen

PowerShell

HyperV: Lade-Fehler im Firmware-Tab

Heute hatte ich den Fall, dass eine HyperV-VM nicht mehr starten wollte. Ich bin dann drauf gekommen, dass in deren Einstellungen in dem Unterpunkt „Firmware“ das Laden dieser Einstellungen nicht möglich war.
Fehler: „There was an error loading the data for this setting.“

Ich hab dann einen Zeitlang das Internet befragt und bin auf allerlei Lösungsansätze gestossen, wovon ich euch nun die beiden PowerShell-Befehle zeigen möchte, mit denen ich das Problem lösen könnte. Dieser Artikel hat mich in die richtige Richtung gestupst.

Die beiden PowerShell-Befehle lauten:

(Get-VM <VMNAME>|Get-VMFirmware).BootOrder

Wobei dieser erste Befehl ja nur die Bootreihenfolge anzeigt und somit nicht ganz so wichtig ist. Aber der nachfolgende Befehl bringt dann die Lösung:

Get-VM <VMNAME>|Get-VMFirmware|ForEach {Set-VMFirmware -BootOrder ($_.Bootorder | ? {$_.BootType -ne 'File'}) $_}

Windows 10 und SMB1 / SMBv1 – Stand: August 2020 bzw. Windows10 Vers. 2004

Vorgeschichte:
Neulich hatte ich das Problem, dass ein relativ aktueller Windows10-Client nicht mehr auf das Netzlaufwerk einen älteren Server zugreifen konnte, auf dem noch (aus sentimentalen Gründen) noch eine alte Anwendung läuft. Auf besagten Server läuft Microsoft Server 2003, was schon mal einen Hinweis gibt, aus welcher Zeit(epoche) die angedeutete Software stammt. 😉

Symptome:
Eigentlich ist das schnell erklärt. Der User klickt auf besagtes Netzlaufwerk, der Windows Explorer fängt an zu „grineln“ und nach 1-2 Minuten kommt eine Fehlermeldung, dass auf das Laufwerk nicht zugegriffen werden kann.

Fehlersuche:
Zuerst dachte ich an „seltsame Zugriffsrechte“. Aber meine Recherche hat keinen Fehler ergeben. Dann hatte ich „Netzwerkproblem“ als Ursache als Idee – was ich aber bald verwerfen konnte, weil die anderen Netzlaufwerke ja alle gingen. Schlussendlich habe ich mal den 2003er-Server rebootet, weil ich den Verdacht hatte, dass sich der vielleicht „aufgehängt“ hatte. Alles ohne Erfolgt.

Lösung:
Dann hatte ich den Einfall, dass ich schon mal ein Problem mit einem Mac hatte, der auf auf eine Freigabe von einem Windows7-PC zugreifen wollten und nicht konnte. Damals lag das Problem beim SMB-Protokoll und das da eine Version „out of Date“ war.
Also hab ich in der Richtung weiter geforscht. Ich bin dann über einen Post von mir gestolpert, in dem ich im September 2019 bereits erklärt habe, wie man SMBv1 unter Windows10 aktiviert:

Aber Windows 10 hat sich weiter entwickelt und der oben beschriebene Weg funktionierte leider nicht mehr. 🙁
Aber ich habe einen neuen Weg gefunden und dieser funktioniert über die PowerShell (Merken: TShirt mit „Powerschäl“ entwerfen!). Es gibt für die PS einen Befehl, mit dem man die SMBv1 Unterstützung wieder aktivieren kann:
(PowerShell als ADMIN ausführen!)

Enable-WindowsOptionalFeature -Online -FeatureName smb1protocol 

Ich bin auf folgenden Seite darauf gekommen:

Nach dem Ausführen des Befehls (als Admin) braucht der PC noch einen Neustart und im Anschluss könnte ich auf das Share des alten 2003er Server wieder zugreifen. So weit, so gut.
Aber es hat natürlich auch einen Grund, warum in den aktuellen Windows10-Versionen SMB1 nicht mehr aktiviert/installiert ist. SMBv1 ist nicht mehr sicher! Aber in manchen Fällen braucht man es halt noch, so wie in meinem Fall.

Es gibt von Microsoft eine sehr schöne Seite, auf der eigentlich alles wissenswerte steht.

Dort sehen auch ein paar interessante Informationen, die ich hier nochmal gesondert hervorheben möchte:

In Windows 10 Fall Creators Update und Windows Server, Version 1709 (RS3) und höheren Versionen, wird das Netzwerkprotokoll Server Message Block Version 1 (SMBv1) nicht mehr standardmäßig installiert.

Quelle: https://docs.microsoft.com/de-de/windows-server/storage/file-server/troubleshoot/smbv1-not-installed-by-default-in-windows

Bedeutet also, dass seit dem Windows 10 Update 1709 (und höher) SMBv1 nicht mehr installiert ist und somit auch nicht mehr funktionieren sollte. Das wäre ja ungefähr im September 2017 gewesen! Warum der PC dann noch solang funktioniert hat, ist mir ein Rätsel.

Microsoft hat das SMBv1-Protokoll in 2014 öffentlich als veraltet eingestuft.

Quelle: https://docs.microsoft.com/de-de/windows-server/storage/file-server/troubleshoot/smbv1-not-installed-by-default-in-windows

Aha. Seit bereits 2014 ist SMB Version 1 ganz offiziell veraltet. Hat aber dann doch noch ein paar Jahre gedauert, bis sie es „abgeknipst“ haben. Und noch so als Site-Fact: Auf einem Windows Server 2012 R1 (W2K12R2) ist SMB noch aktiv und funktioniert.

Windows 10 Home und Windows 10 pro enthalten nach einer Neuinstallation weiterhin standardmäßig den SMBv1-Client. Wenn der SMBv1-Client nicht 15 Tage lang verwendet wird (mit Ausnahme des Computers, der ausgeschaltet wird), wird er automatisch deinstalliert.

Quelle: https://docs.microsoft.com/de-de/windows-server/storage/file-server/troubleshoot/smbv1-not-installed-by-default-in-windows

Auch ein interessanter Vorgehen. Window 10 komplett neu installiert, dann installiert Microsoft den SMBv1 Client per default mit. Wird er denn 15 Tage nicht genutzt, so erfolgt automatisiert dessen Deinstallation. Damit möchte MS wohl verhindert, dass User, die dieses Protokoll noch benötigen vor den Kopf gestossen werden. Aber wohlgemerkt nur bei einer Neuinstallation. Macht man hingegen brav die Windows-Updates, so „verschwindet“ plötzlich die SMBv1 Funktionalität. Es gibt aber einen Lichtblick…

Wenn ein Administrator SMBv1 erneut installiert, werden keine weiteren Versuche unternommen, ihn zu deinstallieren.

Quelle: https://docs.microsoft.com/de-de/windows-server/storage/file-server/troubleshoot/smbv1-not-installed-by-default-in-windows

Würde also bedeutet, wenn ich als Windows-Admin SMBv1 über die Powershell nach installierte, dann dürfte das Windows10 nicht mehr versuchen diesen veralteten SMB-Client zu entfernen. Da bin ich ja mal gespannt. 😉
Aktuell ist es noch zu früh, dass ich darüber eine Aussage treffen kann, da ich erst den Zeitraum von 15 Tagen verstreichen lassen muss. Aber ich habe so das Gefühl, dass es keine 2 Wochen dauert, bis die Netzwerkverbindung zu dem Microsoft Server 2003 wieder nicht mehr geht.

Nachtrag vom 17. August 2020:
Wie in den Kommentaren bereits angedeutet, gibt es bei den Windows-Features den Punkt „Unterstützung für die SMB 1.0/CIFS-Dateifreigabe“ und dort den Unterpunkt „SMB 1.0/CIFS automatisch entfernen“. Es soll angeblich reichen, wenn man diesen Unterpunkt abhakt und die SMB1-Verbindung soll damit dauerhaft funktionieren. Leider war dies bei meinem Test nicht der Fall. ;-(