Supermicro X11SCH-F “other devices”

Nach der Installation von Windows Server 2019 wird für das Supermicro X11SCH-F Motherboard eine Reihe von unbekannten Geräten (other devices) angezeigt, für die kein Treiber installiert werden wurde.

image

Würden wir uns auf einem Windows Server ohne GUI (Desktop Experience) befinden, dann wäre DevManView von Nirsoft die erste Wahl um die korrekte Installation von Treibern und Geräten zu kontrollieren. Das Tool ist kostenfrei und gehört nach meiner Meinung auf jeden Windows Server Core, aber das nur nebenbei.

Die Lösung dieses Problems, habe ich in Teilen in diesem Blog beschreiben. Interessanter Weise hat aber die Installation des aktuellsten Intel Chipset INF Utility nicht alle Geräte korrekt mit Treibern versorgt.

image

Übrig geblieben sind zwei Geräte mit der Bezeichnung PCI Simple Communications Controller

image

Windows Update wollte für die beiden Geräte ebenfalls keine Treiber bereitstellen und so war etwas Recherche notwendig, um hier eine Lösung zu finden. Für mich interessant war, dass Supermicro ebenfalls auf seiner Webseite einen Intel Chipsatz Treiber anbietet, der nicht ganz der aktuellen Version von Intel entspricht, dass Problem aber behoben hat.

image

Dabei gab es aber noch ein kleineres Problem zu lösen. Wenn nun schon das aktuelle Intel Chipset INF Utility installiert wurde, bemerkt das der Installer infinst_autol.exe und bietet ein Downgrade an, was natürlich eine Option sein könnte. Eine Alternative ist aber, explizit mit einem rechten Mausklick und Update driver, den Pfad für den Treiber mit anzugeben.

image

Die Installation muss explizit für jedes Gerät erfolgen:

  1. Rechtklick und Auswahl von Update driver
  2. Auswahl von Browse my computer for driver software
  3. Über die Option Browse den Pfad zum Treiber für Windows 10-x64 angeben und den Treiber installieren

    C:\Users\Administrator\Downloads\Chipset_v10.1.17861.8101\DriverFiles\production\Windows10-x64

Beide Geräte wurden damit erfolgreich erkannt.

image

image

Da es sich um Treiber für die Intel Management Engine handelt, wäre möglicher Weise eine Suche nach einen passenden Treiberpaket dafür ebenfalls von Erfolg gekrönt gewesen. Letztendlich hat es aber so auch funktioniert.

Enjoy it, b!

NIC Teaming: Warning 16945 MsLbfoSysEvtProvider

Wird auf einem Windows Server (egal ob 2012R2, 2016 oder 2019) ein Lbfo-Team erstellt, schreibt das Betriebssystem nach einem Neustart die folgende Meldung (Warning) in das System-Eventlog.

image

Ein Blick auf alle vorhandenen MAC-Adressen zeigt, dass hier Adressen doppelt vergeben worden sind. Das erstellte Team (hier Team Ethernet 1) besitzt die gleiche MAC-Adresse wie einer der für das Team verwendeten Adapter.

image

Hier nochmals die MAC-Adressen.

  • TEAM Team Ethernet 1 = 0C-C4-7A-41-7B-47
  • NIC Ethernet = 0C-C4-7A-41-7B-47
  • Hyper-V Virtual Switch vEthernet (_ Network 172.16.32.0) = 0C-C4-7A-41-7B-47

Das Problem beheben wir damit, dass alle Adapter die eine gleiche Adresse haben abgeändert werden. Dabei ist es sinnvoll MAC-Adressen des Teams und des Hyper-V Virtual Switches zu ändern, anstatt die MAC der NIC zu überschreiben. Dort ist diese nämlich fest hinterlegt, im Team und im Hyper-V Switch jedoch nicht.

  • TEAM Team Ethernet 1 = 0C-C4-7A-41-7B-45

  • Hyper-V Virtual Switch vEthernet (_ Network 172.16.32.0) =
    0C-C4-7A-41-7B-48

Das kann man über die GUI erledigen, oder falls ein Windows Server Core vorliegt mit PowerShell.

# Ändern der MAC-Adresse des Teams "Team Ethernet 1"
Set-NetAdapter -Name "Team Ethernet 1" -MacAddress "0C-C4-7A-41-7B-45"
# Ändern der MAC-Adresse des Hyper-V Switches "vEthernet (_ Network 172.16.32.0)"
Set-NetAdapter -Name "vEthernet (_ Network 172.16.32.0)" -MacAddress "0C-C4-7A-41-7B-48"

Nach der Änderung sieht die Vergabe der MAC-Adressen wie folgt aus und die Warnung 16945 wird beim nächsten Neustart nicht mehr ins Eventlog geschrieben.

image

Update zum Windows Server 2019:

Auf einem Windows Server 2019 hatte ich folgendes Verhalten, dort wurden die MAC-Adressen im Wechsel verteilt. Der Hyper-V Switch kollidierte mit MAC-Adresse des der ersten NIC, das Team mit der MAC-Adresse der zweiten NIC.

image

Beheben lässt sich das Problem aber auf die gleiche Weise. Hier nochmals die MAC-Adressen.

  • TEAM Team Ethernet 1 = AC-1F-6B-F6-3E-C1
  • NIC Ethernet = AC-1F-6B-F6-3E-C1
  • Hyper-V Virtual Switch vEthernet (_ Network 172.16.32.0) = AC-1F-6B-F6-3E-C0
  • NIC Intel Ethernet I210 #2 = AC-1F-6B-F6-3E-C0

image

  • TEAM Team Ethernet 1 = AC-1F-6B-F6-3E-C3
  • NIC Ethernet = AC-1F-6B-F6-3E-C1
  • Hyper-V Virtual Switch vEthernet (_ Network 172.16.32.0) =
    AC-1F-6B-F6-3E-C2
  • NIC Intel Ethernet I210 #2 = AC-1F-6B-F6-3E-C0

Enjoy it, b!