Windows 10 und Server Release Informationen

Wo wir gerade im vorhergehenden Artikel bei Office 365 Buildnummern waren (https://newyear2006.wordpress.com/2020/03/02/office-365-buildnummern-und-versionen/), hier noch passend offizielle Release Informationen zu Windows 10 und Windows Server: https://docs.microsoft.com/en-us/windows/release-information/. Dazu gibt es noch ein Message Center mit offiziellen Verlautbarungen: https://docs.microsoft.com/en-us/windows/release-information/windows-message-center.

Zum einzelnen Release findet man noch weitere Infos zu Problemen für z. B. 1903: https://docs.microsoft.com/en-us/windows/release-information/status-windows-10-1903, oder für 1909: https://docs.microsoft.com/en-us/windows/release-information/status-windows-10-1909.

WLAN bzw. Wireless unter Windows Server 2016 aktivieren, Meldung “Ein Dienstinstallationsabschnitt dieser INF-Datei ist ungültig.” beheben

Die Windowsserver können auch an WLAN-Netze angebunden werden. Dazu ist allerdings etwas mehr Aufwand nötig. GUI-Menschen haben vielleicht schon mal bei einem Windows Server die Meldung “Ein Dienstinstallationsabschnitt dieser INF-Datei ist ungültig.”, wenn man im Gerätemanager Treiber aktualisiert, gesehen. Dies ist z. B. auf die standardmäßig nicht verfügbare Wireless Unterstützung zurückzuführen.

WirelessNetworking Feature aktivieren bzw. prüfen
Zunächst benötigt man das WirelessNetworking Feature. Man kann dies mittels Powershell so abfragen:

Get-WindowsOptionalFeature -Online| where featurename -match wireless

FeatureName : WirelessNetworking
State       : Disabled

Wenn Disabled gemeldet wird, dann muss das Feature zuerst einmal installiert werden:

Enable-WindowsOptionalFeature -Online -featurename WirelessNetworking

Meistens ist danach ein Neustart des Rechners notwendig.

Restart-Computer

WLAN Dienst aktivieren
Damit nun mit WLAN gearbeitet werden kann, muss auch der WLAN Dienst geprüft werden:

Get-Service WLanSvc

Status   Name               DisplayName
——   —-               ———–
Stopped  WlanSvc            Automatische WLAN-Konfiguration

Sollte hier Stopped stehen, muss er mit

Start-Service WLanSvc

gestartet werden. Sollte der Dienst gar nicht aufgelistet werden, dann ist oben bei der Featureinstallation was schief gelaufen oder der Rechner wurde noch nicht neu gestartet.

WLAN Treiber laden
Damit man tatsächlich mit dem WLAN arbeiten kann, sollte man nun noch im Gerätemanager prüfen, ob man noch einen Treiber für das WLAN laden muss.

Gängige Intel-WLAN-Treiber findet man hier https://downloadcenter.intel.com/de/download/ unter dem Stichwort ProSetWireless.

Treiber von Windows 10 erhalten
Wenn es mal keine Treiber direkt für den Windows Server 2016 geben sollte, dann kann man doch meist die Treiber von Windows 10 verwenden. Hier wird das Verfahren anhand einer LAN-Karte dargestellt: https://newyear2006.wordpress.com/2017/03/07/treiber-von-windows-10-im-windows-server-2016-installieren-wenn-es-keine-offiziellen-treiber-gibt-am-beispiel-einer-intel-netzwerkkarte/.

Würde man dieses Verfahren auf z. B. auf eine aktuelle Intel WLAN-Karte anwenden, dann wären die Hardware-ID VEN_8086&DEV_24F3 und die Datei NETwtw04.INF im Spiel, welche geändert werden müsste.

Falls man Probleme haben sollte die Wireless-Treiber zu entpacken, ohne sie zu installieren, dann muss man wissen, dass die Treiberinstallation mittels den WIX-Toolset erstellt wurden. Zum Entpacken benötigt man Dark.exe für Bundle WIX : https://github.com/wixtoolset/issues/issues/3645/. Die Angabe von /Layout führte bei der bisherigen Version leider nicht zum Entpacken.

Warum schaltet sich dieser verdammte DHCP-Dienst am Windows Server ständig ab? Was hat das mit IPv6 zu tun?

Irgendwie stand ich gerade auf dem Schlauch und hab mich mit einem Problem länger als nötig beschäftigt um am Ende festzustellen, die Lösung ist logisch und ganz einfach. Es ging los, dass bei einem Kunden der Speedport gegen eine Fritzbox ausgetauscht werden sollte.

Zu Beginn war alles ganz einfach, Internetverbindung war schnell da. Aber dann gab es Probleme im Netz mit den Client-Rechnern nach einem Neustart. Dazu muss man wissen, dass bei der Fritzbox der IPv4-DHCP ausgeschaltet wurde. Egal wie oft man nun am Windows Server den DHCP-Server neu gestartet hat, er funktionierte immer kurz und war dann wieder ausgeschaltet. Sowas kennt man wenn ein zweiter DHCP-Server im Netz ist. Also nochmal auf der Fritzbox versichert, dass der Ipv4-DHCP ausgeschaltet war. Am Ende war nur noch der Server mit dem Client mit der Fritzbox verbunden. Klappte aber immer noch nicht!

Wo schaut man nach, wenn man solche Probleme hat? Richtig, in der Ereignisanzeige. Also kurz nach den DHCP-Server Logs geschaut:

Get-WinEvent -ListLog *dhcp*|select logname

LogName
——-
Microsoft-Windows-Dhcp-Client/Admin
Microsoft-Windows-Dhcp-Client/Operational
Microsoft-Windows-Dhcp-Server/FilterNotifications
Microsoft-Windows-Dhcp-Server/Operational
Microsoft-Windows-DhcpNap/Admin
Microsoft-Windows-DhcpNap/Operational
Microsoft-Windows-Dhcpv6-Client/Admin
Microsoft-Windows-Dhcpv6-Client/Operational

Ah alles klar:

Get-WinEvent -LogName Microsoft-Windows-Dhcp-Server/Operational -MaxEvents 10

TimeCreated                   ProviderName                                             Id Message
———–                   ————                                             — ——-
17.12.2015 12:52:43           Microsoft-Windows-DHCP-Server                           106 Die Rese
17.12.2015 12:52:43           Microsoft-Windows-DHCP-Server                           107 Die Rese
17.12.2015 12:49:25           Microsoft-Windows-DHCP-Server                           106 Die Rese
17.12.2015 12:48:23           Microsoft-Windows-DHCP-Server                           107 Die Rese
25.11.2015 09:12:51           Microsoft-Windows-DHCP-Server                           106 Die Rese
25.11.2015 09:12:24           Microsoft-Windows-DHCP-Server                           107 Die Rese
21.05.2014 14:25:11           Microsoft-Windows-DHCP-Server                           106 Die Rese

Wie 2015? Ich hab aktuell Problem und nicht 2015! Hä? Was geht hier. Auf jeden Fall ist es wie immer man sucht überall aber nicht an der richtigen Stelle!!!!

Irgendwann dachte ich, dass kann nicht sein und klar es war so. Denn man sollte ja auch wegen DHCP-Server Meldungen nicht bei Microsoft-Windows-DHCP-Server schauen sondern unter SYSTEM!!!! Ich könnte so kotzen…

Also mittels

Get-WinEvent -LogName system -MaxEvents 20

TimeCreated                   ProviderName                                             Id Message
———–                   ————                                             — ——-
05.12.2016 14:52:32           Service Control Manager                                7040 Der Starttyp des Diensts "…
05.12.2016 14:50:02           Microsoft-Windows-GroupPolicy                          1500 Die Gruppenrichtlinieneins…
05.12.2016 14:50:01           Microsoft-Windows-GroupPolicy                          1500 Die Gruppenrichtlinieneins…
05.12.2016 14:49:56           Service Control Manager                                7036 Dienst "Windows Modules In…
05.12.2016 14:49:25           Microsoft-Windows-DHCP-Server                          1043 Es wurde festgestellt, das…
05.12.2016 14:49:05           Service Control Manager                                7036 Dienst "DHCP-Server" befin…
05.12.2016 14:49:01           Microsoft-Windows-DHCP-Server                          1056 Der DHCP-Dienst wird auf e…
05.12.2016 14:45:31           Service Control Manager                                7036 Dienst "DHCP-Server" befin…
05.12.2016 14:45:31           Microsoft-Windows-DHCP-Server                          1054 Der DHCP/BINL-Dienst auf d…
05.12.2016 14:45:31           Microsoft-Windows-DHCP-Server                          1053 Der DHCP/BINL-Dienst hat e…
05.12.2016 14:45:19           Service Control Manager                                7036 Dienst "DHCP-Server" befin…
05.12.2016 14:45:15           Microsoft-Windows-DHCP-Server                          1056 Der DHCP-Dienst wird auf e…
05.12.2016 14:45:03           Microsoft-Windows-GroupPolicy                          1500 Die Gruppenrichtlinieneins…

geschaut und hier tauchen dann auch die üblichen Verdächtigen DHCP/BINL-Meldungen auf! Wenn man nun genauer nachschaut, wird es auch offensichtlich:

Get-WinEvent -LogName system -MaxEvents 20| where {$_.id -eq 1053}| ft message -Wrap

Message
——-
Der DHCP/BINL-Dienst hat einen anderen Server mit der IP-Adresse fe80::3a10:d5ff:fe89:bb02 in diesem Netzwerk ermittelt
, der zu der folgenden Domäne gehört: .

Also wo liegt nun das Problem? Warum hab ich oben immer geschrieben, dass ich den IPv4DHCP ausgeschaltet habe? Na klar, weil die Fritzbox auch noch einen IPv6DHCP hat und dieser munter weiter aktiv war. Und da im Netz nunmal unabhängig von IPv4 und IPv6 nur ein DHCP aktiv sein war, hat sich der Windows DHCP-Server immer schneller verabschiedet!

Also Lösung: Entweder IPv6 ganz abschalten oder den IPv6DHCP abschalten! Besser ist natürlich die zweite Variante.

Mal abgesehen davon, dass ich hätte schneller drauf kommen können. ist mir erst durch diese Geschichte wieder aufgefallen, wie inkonsistent die DHCP-Dienst-Sache unter Windowsservern ist. Einfach nur traurig…

Hardware direkt einer virtuellen Maschine im Hyper-V mittels Discrete Device Assignment zuordnen

Microsoft experimentiert viel mit dem Hyper-V und baut ihn in alle Richtungen aus. So gab es ganz zu Beginn von Windows 10 Powershell Cmdlets, welche es erlaubten physische Hardware direkt einer virtuellen Maschine zuzuordnen https://charbelnemnom.com/2015/02/whats-new-in-powershell-for-hyper-v-in-windows-server-technical-preview-hyperv-powershell-vnext/. Dazu gab es die Cmdlets:

Get-Command *assigna*

Name                            Version Source
—-                            ——- ——
Add-VMAssignableDevice          2.0.0.0 Hyper-V
Add-VMHostAssignableDevice      2.0.0.0 Hyper-V
Dismount-VMHostAssignableDevice 2.0.0.0 Hyper-V
Get-VMAssignableDevice          2.0.0.0 Hyper-V
Get-VMHostAssignableDevice      2.0.0.0 Hyper-V
Mount-VMHostAssignableDevice    2.0.0.0 Hyper-V
Remove-VMAssignableDevice       2.0.0.0 Hyper-V
Remove-VMHostAssignableDevice   2.0.0.0 Hyper-V

Allerdings verschwanden diese Cmdlets wieder zum Release von Windows 10, weshalb sie bei diesem Vergleich nicht auftauchten: https://newyear2006.wordpress.com/2015/07/30/umgang-mit-verschiedenen-versionen-von-powershellmodulen-und-ermittlung-von-unterschieden/.

Per Zufall stolperte ich aber über diesen Blogeintrag https://techstronghold.com/blogs/virtualization/pass-through-wired-or-wireless-wi-fi-nic-to-vm-using-hyper-v-discrete-device-assignment-dda-in-windows-server-2016, der komische Dinge vollführte. Tatsächlich hat Microsoft obige Cmdlets mit Release von v1511 bei Windows 10 wieder eingeführt! Wobei die Dokumentation, stand heute, also ein halbes Jahr nach Erscheinen von v1511, absolut erbärmlich ist. Z. B. besteht die Dokumentation von Add-VMAssignableDevice nur aus einem Template. Keine Erklärung nix.

Nun ist das Thema an sich auch recht komplex, aber man könnte ja zumindest ein paar Links für weitergehende Informationen hinterlegen. So muss man sich alles selber ergooglen.

Im Prinzip geht es um Discrete Device Assignment, kurz DDA, auch bekannt als PCI Passthrough. Dies erlaubt einer VM den direkten Zugriff auf Hardware.

Hier findet man einen Hintergrundartikel dazu: https://blogs.technet.microsoft.com/virtualization/2015/11/19/discrete-device-assignment-description-and-background/. Obwohl die Cmdlets unter Windows 10 verfügbar sind, scheint nur unter Windows Server 2016 die Unterstützung aktiviert zu sein! Dies wird in diesem Artikel geschrieben: https://blogs.technet.microsoft.com/virtualization/2015/11/20/discrete-device-assignment-machines-and-devices/.

Selbst wenn man mit dem Server 2016 unterwegs ist, muss die Hardware DDA unterstützen, ein Script welches die Hardware daraufhin überprüft, ist hier zu finden: https://github.com/Microsoft/Virtualization-Documentation/blob/master/hyperv-tools/DiscreteDeviceAssignment/SurveyDDA.ps1.