SYSVOL-Migration von FRS auf DFSR

Microsoft empfiehlt schon seit langer Zeit die Replikation des SYSVOL von FRS (File Replication Service) auf DFSR (Distributed File Service Replication) umzustellen. Um genau zu sein, kam diese Empfehlung mit Windows Server 2003R2 🙂 .  Das ist auch sinnvoll, da DFSR stabiler arbeitet und FRS mit dem Windows Server 1709 nicht mehr unterstützt wird.

Ich habe dann eine Reihe meiner Small Business Domains durchgeschaut und noch eine gefunden in dieser FRS zur Replikation verwendet wird. Das ist immer dann der Fall, wenn von sehr alten Versionen (hier ein Windows Server 2000 basiertes Active Directory) immer wieder auf neue Versionen migriert wurde. Die Historie in dieser Domain ist:

  • Windows Server 2000
  • Windows Server 2003
  • Windows Server 2008
  • Windows Server 2012R2

In Domains mit nur einem Domain Controller (DC), wie das bei dem Small Business Server oder Small Business Essentiales üblich ist, kommt es in der Regel zu fast keinen Problemen mit der Replikation. Denn es gibt nur einen DC, das bedeutet aber nicht das hier keine Replikation stattfindet, sondern dass der Server in der Regel sich selbst immer erreichen kann.

FRS oder DFSR?

Wie stellt man überhaupt fest, ob innerhalb des Active Directory (AD) mit FRS oder DFSR repliziert wird? Das kann über mehrere Möglichkeiten herausgefunden werden.

Im Ereignis-Protokoll auf einem (in einer SBS/SBE Domain auf dem einem) DC sind aktuelle Einträge vorhanden.

image

Im DFS Management wird KEINE Gruppe angzeigt, wie im folgenden Bild zu sehen ist. Darunter das Domain System Volume wenn auf DFSR umgestellt wurde.

FRS (File Replication Service)

image

DFSR (Distributed File System Replication)

image

Voraussetzungen

Damit eine Migration ohne Probleme läuft, sollten ein paar Bedingungen im Vorfeld erfüllt sein.

FRS muss fehlerfrei arbeiten, dass kann man gleich prüfen wenn man einen Blick in das Ereignisprotokoll des FRS wirft

Bei mehreren DC, erstelle ich eine Datei im NETLOGON-Verzeichnis und schaue ob diese auf den anderen DCs zeitnah auftaucht.

C:\Temp> echo "Test" > \Windows\SYSVOL\domain\scripts\test.txt

Zusätzlich muss die Domain im Domain-Mode mindestens auf Windows Server 2008 laufen.

image

Das kann mit PowerShell und Get-ADDomain geprüft werden.

# Den Befehl als Administraor in einer PowerShell-Sitzung ausführen
(Get-ADDomain).DomainMode
Windows2012R2Domain

Nun können wir die Migration starten.

Migration von FRS auf DFSR

Bevor die Migration gestartet wird mache ich, wenn nur ein einziger DC vorhanden und dieser virtualisiert ist, einen SnapShot. Darüber hinaus ist ein aktuelles Backup obligatorisch.

image

Bei einem Snapshot (oder Checkpoint) ist es wichtig, dass falls dieser in Anspruch genommen wird, alle Daten die seit dem Checkpoint erstellt wurden verloren gehen. Darum ist eine Migration des SYSVOL etwas fürs Wochenende.

Die Migration selbst erfolgt mit dem Tool dfsrmig.exe das in einer, als Administrator gestarteten CMD- oder PowerShell-Sitzung auf dem DC ausgeführt wird, der die PDC-Emulator Rolle besitzt. Bei nur einem Server / DC ist die Rollenverteilung klar, ansonsten kann diese wie folgt mit PowerShell geprüft werden.

# Den Befehl als Administrator in einer PowerShell-Sitzung ausführen
(Get-ADDomain).PDCEmulator
mt-sbs-1.DOMAIN.local

Wird nur Get-ADDomain verwendet, findet man den PDC-Emulator hier.

image

Die Migration selbst verläuft in vier Stufen mit dem folgenden Status von 0 … 3, die Informatik beginnt halt gerne bei 0 Smile

Status Start 0

Mit dfsrmig /setGlobalState 0 werden die Domain Controller auf Start gesetzt und die Migration kann beginnen.

# Den Befehl als Administrator in einer PowerShell-Sitzung ausführen
dfsrmig /setGlobalState 0

Die Meldung Invalid state change requested, rührt daher das auf diesem DC der Befehl schon im Vorfeld abgesetzt wurde und dieser sich schon im Status Start befindet.

image

Kontrollieren, ob alle DC sich final im Status Start befinden kann und sollte man mit dfsrmig /GetMigrationState.

# Den Befehl als Administrator in einer PowerShell-Sitzung ausführen
dfsrmig /GetMigrationState

image

Bei mehreren DCs kann das schon seine Zeit dauern, letzte Woche habe ich bei zwei Servern ca. 10min gewartet bis dieser Status erreicht war. Hier ist ein wenig Geduld angebracht.

Status Prepared (Vorbereitet) 1

Mit dfsrmig /setGlobalState 1 wird nun im nächsten Schritt der DC in den Status Prepared versetzt und mit dfsrmig /GetMigrationState kann der Status wiederholt abgefragt werden.

# Den Befehl als Administrator in einer PowerShell-Sitzung ausführen
dfsrmig /setGlobalState 1

Wie im folgenden Bild zu sehen ist, benötigt auch ein einzelner DC seine Zeit. Dazu einfach einen Kaffee holen und mit dfsrmig /GetMigrationState den Status abfragen.

image

Status Redirected (Umgeleitet) 2

Mit dfsrmig /setGlobalState 2 wird nun die Phase 2 eingeleitet und alle DC in den Status Redirected gesetzt, was ebenfalls seine Zeit dauern kann.

# Den Befehl als Administrator in einer PowerShell-Sitzung ausführen
dfsrmig /setGlobalState 2

Natürlich liefert dfsrmig /GetMigrationState den aktuellen Zustand.

image

Damit ist die Phase 2 beendet und wir können uns der Phase 3 zuwenden und die Migration damit abschließen.

Status Eliminated (Entfernt) 3

Mit dfsrmig /setGlobalState 3 wird nun die Phase 3 und damit der Abschluss der Migration eingeleitet und alle DCs in den Status Eliminated gesetzt.

# Den Befehl als Administrator in einer PowerShell-Sitzung ausführen
dfsrmig /setGlobalState 3

Wie schon vorher liefert dfsrmig /GetMigrationState den Zustand und Status der Migration, im folgenden Bild waren wir nach gut 2min fertig.

image

So nun sind wir fertig, alle vier Schritte / Phasen sind durch.

Wie kontrollieren wir nun, ob alles sauber läuft?

Vertrauen ist gut, Kontrolle ist besser

Im DFS Management wird nun das Domain System Volume angezeigt und man kann es auch als Replikationsgruppe hinzufügen.

image

Dort sehen wir auch den migrierten SYSVOL-Ordner.

image

Zusätzlich verabschiedet sich der FRS mit einem “letzten” Eintrag im Ereignisprotokoll.

image

Im DFS Replication Ereignisprotokoll finden wir ebenfalls einen Eintrag, dass nun mit DFSR repliziert wird.

image

Bei mehr als einem Domain Controller, erstelle ich immer eine Datei im NETLOGON-Verzeichnis und schaue ob diese repliziert wird. Das Verzeichnis heißt ja nun auch nicht mehr SYSVOL, sondern SYSVOL_DFSR.

image

Wird nun ein weiterer DC hinzugefügt, dann verwendet dieser wie vor das Verzeichnis SYSVOL.

image

Die beiden ersten Server wurden „migriert” und der letzte in der Liste (blau umrandet) wurde nach der Migration hinzugefügt.

Enjoy it, b!

WSUS zusammen mit der WID auf Laufwerk D

Fügt man den Windows Server Update Service (WSUS) auf einem Windows Server (2016 oder 2019) hinzu, dann werden weitere für die Rolle notwendigen Dienste und Funktionen hinzugefügt.

image

Darunter auch die Windows Internal Database (WID), als SQL-Server für die Bereitstellung der WSUS-Datenbank.

image

Die WID ist nur zur Verwendung von Windows eigenen Diensten, wie dem WSUS gedacht und nicht zur Bereitstellung von Datenbanken für externe Anwendungen.

Neben dieser Einschränkung hat die WID einen großen Vorteil: Im Gegensatz zur kostenlosen SQL Server Express Edition besitzt sie keine Begrenzung der maximalen Größe einer Datenbank auf 10GB (bis zum SQL Server 2008R2 war das Limit sogar nur 4GB).

Wird der WSUS über PowerShell hinzugefügt, erfolgt ebenfalls die Installation und Verwendung der WID.

image

Hier die Installation über PowerShell:

Install-WindowsFeature UpdateServices -Restart -IncludeManagementTools -Restart

Wird die WID mit dem WSUS verwendet, dann unterliegt dessen Datenbank, die SUSDB, nicht der 10GB Begrenzung wie das bei der Verwendung der SQL Server Express Edition der Fall ist.

Das ist ein Vorteil, da die SUSDB gerne mal die 10GB Grenze, vor allem wenn die Wartung vernachlässigt wird, übersteigt.

Der Haken an der Sache ist, dass die WID nach ihrer Installation auf dem Laufwerk C liegt und dort will ich sie nicht haben.

Umkonfigurieren der WID auf ein anderes Laufwerk

Die WID muss daher nicht auf Laufwerk C verbleiben, sondern kann auf ein anderes Laufwerk gelegt werden. Dazu sind die folgenden Tools und Schritte notwendig.

  • Nachdem der WSUS und damit die WID hinzugefügt wurde, aber noch bevor eine Konfiguration des WSUS erfolgt, sollte die WID auf ein passendes Laufwerk gelegt werden. Ich nehme dazu gerne Laufwerk D, dass ich in Form einer 256GB großen Platte bereitstelle
  • Damit die WID auf Laufwerk D verschoben werden kann, empfiehlt es sich das ohnehin für die Wartung der SUSDB hilfreiche SQL Server Management Studio zu installieren
  • Nicht notwendig, aber für mich immer praktisch ist Notepad++ oder Visual Studio Code als Editor auf dem Server

Damit die WID Laufwerk D: verwendet, sind die folgenden Schritte notwendig.

Start der Windows Internal Database über die Services oder PowerShell

image

image

# Starten der WID
Start-Service -Name 'MSSQL$MICROSOFT##WID'
# Ändern des StartupTypes auf Automatic (delayed)
Set-Service -Name 'MSSQL$MICROSOFT##WID' -StartupType Automatic

Nun ist es möglich, mit dem folgenden String eine Verbindung zur WID über das SQL Server Management Studio (SSMS) herzustellen.

np:\\.\pipe\MICROSOFT##WID\tsql\query

Das SSMS muss dazu mit administrativen Rechten (rechte Maustaste Run as Administrator) gestartet worden sein.

image

Der weitere Ablauf ergibt sich aus den folgenden Schritten.

  • Stoppen der WID, durch das SSMS, PowerShell oder auch den Services Manager
  • Anlegen des Data und Log Verzeichnisses auf Laufwerk D (als Administrator)

image

  • Verschieben des Inhalts von C:\Windows\wid\data und C:\Windows\wid\log nach Laufwerk D:

image

Verschieben von Data und Log auf Laufwerk D
move C:\Windows\wid\data\* 'D:\Microsoft SQL Server\WID\Data\'
move C:\Windows\wid\log\* 'D:\Microsoft SQL Server\WID\Log\'
  • Ändern der folgenden drei Einträge in der Registry, für die Lokation der master. mdf, master.ldf und error.log Dateien

image

  • Der neue Pfad geht auf Laufwerk D mit den Unterverzeichnissen

image

  • Danach folgt die Berechtigung des WID Service Accounts auf die Verzeichnisse auf Laufwerk D … der Einfachheit nehme ich hier immer das WID-Verzeichnis selbst.

image

NT SERVICE\MSSQL$MICROSOFT##WID 
  • Danach kann die WID gestartet werden und die Verbindung über das SSMS klappt auch ohne Probleme.

image

Die Installation des WSUS erfolgt über den Post-Configuration Task oder kann über den folgenden Aufruf erfolgen.

# wsusutil.exe liegt im Verzeichnis C:\Program Files\Update Services\Tools
.\wsusutil.exe postinstall SQL_INSTANCE_NAME="LOCALHOST" CONTENT_DIR=D:\WSUS

image

Enjoy it, b!

WinDbg, wie man in einem Dump den Computernamen findet

Vor einiger Zeit war ich damit beschäftigt einige Dumps zu analysieren um nach einem Fehler zu suchen. Dabei hätte mich brennend interessiert auf welchem Computer der Dump geschrieben wurde.

Bis zu Windows 10 war das auch nicht so schwer herauszubekommen, aber Microsoft hat hier etwas geändert. Nach einigem Suchen im Netz bin ich dann auf die folgende Lösung gestoßen, die nebenher noch die Domain/Workgroup, sowie das Betriebssystem ermittelt.

In WinDbg muss dazu der folgende Aufruf erfolgen:
r @$t0 = @@masm(mrxsmb!SmbCeContext); dx (nt!_UNICODE_STRING[4])(@$t0)

# r @$t0 = @@masm(mrxsmb!SmbCeContext); dx (nt!_UNICODE_STRING[4])(@$t0)

2: kd> r @$t0 = @@masm(mrxsmb!SmbCeContext); dx (nt!_UNICODE_STRING[4])(@$t0) (nt!_UNICODE_STRING[4])(@$t0) [Type: _UNICODE_STRING [4]] [0] : "Workgroup" [Type: _UNICODE_STRING] [1] : "NB-LP1-1" [Type: _UNICODE_STRING] [2] : "Windows 10 Enterprise 18363" [Type: _UNICODE_STRING] [3] : "Windows 10 Enterprise 6.3" [Type: _UNICODE_STRING]

[1] liefert dann den Computer auf dem der Dump erstellt wurde.

Enjoy it, b!

BlueScreen / Stopp, Windows 10 CSC reset

Nach dem Update auf Windows 10 Version 20H2, der Herbstversion 2020 hatte ich auf einer Reihe von Lenovo Notebooks und auf zwei Microsoft Surface Pro Tablets das Problem, dass sich im Verlauf der Anmeldung das Betriebssystem mit einem Bluescreen (BSOD, Stopp-Fehler) verabschiedete.

IMG-20201209-WA0000_ON1_Cloud

Für alle die hier nicht mehr weiterlesen wollen, könnte das Setzen des folgenden Parameters in der Registry von Windows 10 und ein damit verbundener Neustart das Problem beheben.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CSC\Parameters]
"FormatDatabase"=dword:00000001

Neustart nicht vergessen Smile

Alle Interessierten dürfen gerne den Rest des Beitrags lesen.

Fehlerbild(er)

Eine Reihe mir zugesandter Screenshots die von den Anwendern mit dem Smartphone erstellt wurden, zeigten ein diffuses Fehlerbild.

Unterschiedlich war dabei immer die Fehlerursache, dabei tauchten verschiedene Komponenten des Betriebssystems auf:

  • mrxsmb20.sys (7x), mountmgr.sys (1x) und auch der volume.sys (1x)
  • Lenovo L460, L470 und T14L
  • Surface Pro 4 und Surface Pro 7

Gleich waren auf allen Windows 10 Systemen die folgenden Parameter

  • Der BSOD tauchte immer während der Anmeldung auf
  • Windows 10 Version 20H2
  • kürzlich auf die Version 20H2 aktualisiert
  • Nach dem Update lief der Computer im Netzwerk (Firma) stabil!
  • Der Computer ist Mitglied einer Domäne, aber die Anmeldung erfolgte ohne Verbindung zum Domain Controller im HomeOffice
  • Konfiguriertes OneDrive for Business

Workarounds

Eine schnelle Lösung brachte die Verwendung eines lokalen Benutzers auf den Endgeräten. Der Computer war zwar nach wie vor Mitglied der Domäne, aber von Benutzer wurde im HomeOffice ein lokales Konto verwendet. Dieses hatte ich entweder im Vorfeld schon angelegt, konnte es über Teamviewer “nachrüsten” oder der Anwender war dazu selbst in der Lage.

Damit war ein Zugang per RDP auf den eigentlichen PC innerhalb der Firma möglich und der Druck erst einmal weg.

Darüber hinaus brachte das Zurücksetzen von Windows auf die vorherige Version bei allen Surface Geräten Abhilfe. Der BSOD war verschwunden! Ich muss aber gestehen, dass ich das auf den Lenovo Notebooks nicht in Betracht ziehen wollte.

Zusammenfassend konnte das Problem schnell mit den beiden folgenden Ansätzen gelöst werden.

  1. Verwenden eines lokalen Benutzers (den ich inzwischen generell immer anlege, zusätzlich zu einem lokalen Admin) und auch einrichte (Outlook, OneDrive, …)
  2. Rückkehr auf die vorherige Version von Windows 10

Zufrieden war ich aber mit beiden Lösungen nicht. Zum einen führen lokale Benutzerprofile dazu, dass irgendwann Daten darin verschwinden und nicht mehr auf dem Server gespeichert werden. Eine Rückkehr auf die vorherige Version von Windows kann nur temporär eine Lösung sein, das nächste Update kommt bestimmt. Also musste dafür eine ordentliche Lösung gefunden werden und kein Workaround. Durch die Workarounds konnten alle Anwender zunächst einmal arbeiten.

Die eigentliche Lösung

Durch das Auftauchen von Komponenten die mit dem Speicher (Festplatte) und Cache von Windows zu tun hatten, dachte ich zuerst an einen Defekt des Notebooks. Da der BSOD aber nach der Verwendung des lokalen Benutzer-Kontos nicht mehr auftrat, konnte ich diesen Verdacht beiseitelegen und außerdem hatte ich inzwischen das Problem auf mehreren Geräten.

Geblieben waren aber der mrxsmb20.sys und das der STOPP-Fehler der generell bei einer Anmeldung ohne Domain Controller erfolgte.

Das zeigte mir auch ein Blick in den memory.dmp (PROCESS_NAME: winlogon.exe ist der Anmelde-Prozess von Windows)image

Dazu bekommen wir gleich zu Beginn der Analyse den Hinweis, dass etwas beim Zugriff auf das Dateisystem schief gegangen ist, nämlich als eine RDR (ReDirection) stattgefunden hat.

image

Das ist der Fall, wenn ein Computer sich Offline anmeldet. Inzwischen konnte ich nachvollziehen, dass die Anmeldung direkt im Firmennetzwerk ohne Probleme funktioniert und lediglich im HomeOffice der BSOD auftritt.

Im ersten Screenshot des Debuggers ist zu sehen, dass es sich um einen ExceptionCode c0000005 handelt und der Zugriff auf den Offline Cache fehl schlägt. Der entsprechende Ordner dafür liegt im Windows Verzeichnis mit dem Namen CSC.

# Windows Client Side Cache Ordner (Offline Files)

%WINDIR%\CSC

Die Berechtigungen auf diesen sind einfach gehalten und mit SYSTEM:F überschaubar. Allerdings lassen sie sich nur im passenden Kontext überprüfen. Ich verwende dazu Psexec.exe von Sysinternals, welches mit dem Parameter –s im Systemkontext gestartet werden kann.

# Start von Psexec.exe unter Local System

C:\Temp> "\Program Files (x86)\Windows Sysinternals Tools\psexec.exe" -s cmd.exe

# Kontrolle der Berechtigungen

C:\Windows> cacls csc /t

image
Nachdem die Berechtigungen richtig angezeigt wurden, erinnerte ich mich an frühere Migrationen von Dateiservern wo im Anschluss der CSC Cache Probleme gemacht hat und zurück gesetzt werden musste. Korrekter Weise dessen Datenbank und ein Upgrade von Windows 10 auf eine höhere Version könnte hier durchaus ebenfalls zu Problemen oder Inkompatibilitäten führen.

Ein Rücksetzen des CSC ist über den folgenden Registry-Eintrag möglich. Natürlich verbunden mit einem notwendigen Neustart des Computers.

image

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CSC\Parameters]
"FormatDatabase"=dword:00000001

Damit war auch eine Anmeldung im HomeOffice möglich und damit die Lösung des Problem gefunden.

Alle nun folgenden Notebooks habe ich gleich im Anschluss nach dem Upgrade ebenfalls mit diesem Eintrag versehen und die CSC Datenbank gelöscht. Das Problem ist danach nicht mehr aufgetreten.

Enjoy it, b!

Windows 10 Upgrade schlägt fehl

Beim Upgrade von zwei Windows 10 PCs wurde ich von der folgenden Fehlermeldung überrascht.

image

Windows kann mithilfe von Setup nicht auf einem USB-Speicherstick installiert werden.

Windows war der Meinung, dass die interne Festplatte (eine SSD) ein USB-Stick wäre. Lösen lässt sich dieses Problem, indem in der Windows Registry der folgende Wert auf 0 gesetzt wird.

image

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control
PortableOperatingSystem = 0

Damit konnte Windows ohne Probleme auf die gerade aktuelle Version 20H2 aktualisiert werden.

Enjoy it, b!

GPO Error "Resource $(string id="Win7Only)‘

Die Fehlermeldung lautet wie folgt und erscheint bei der Anzeige der Settings / Einstellungen einer GPO.

Error "Resource $(string id="Win7Only)' referenced in attribute displayName could not be found" when opening gpedit.msc in Windows

Im GPO-Management wird der Fehler wie folgt angezeigt.

image

Microsoft selbst, kennt den Fehler auch und liefert in diesem KB-Artikel die Lösung, bzw. einen Workaround wie man den Fehler beheben kann.

https://support.microsoft.com/en-us/help/4292332/error-when-you-open-gpedit-msc-in-windows

Der Fehler ist bei mir aufgetreten, nachdem ich eine auf Windows Server 2012 R2 laufende Domain für Windows Hello vorbereiten wollte, dazu gehört auch das Aktualisieren der ADMX-Dateien.

Da ich schon die aktuellen ADMX-Dateien eingespielt hatte, hier geht es zu den Windows 10 ADMX-Dateien für Version 2004, blieb mir nur die Möglichkeit die ADML-Datei zu editieren. Das kann man entweder mit Notepad oder mit Notepad++ machen.

Dazu habe ich die folgenden Schritte durchgeführt.

Erstellen eines Backups für die SearchOCR.adml Datei im folgenden Ordner:

C:\Windows\SYSVOL\domain\Policies\PolicyDefinitions\en-US

Das geht am einfachsten in einer Eingabeaufforderung oder in PowerShell mit xcopy, wobei beide Sitzungen mit erweiterten Adminrechten gestartet werden müssen.

C:\Windows\SYSVOL\domain\Policies\PolicyDefinitions\en-US
# Wechsel in der Verzeichnis mit den PolicyDefinitions der jeweiligen Sprache
C:\Windows\SYSVOL\domain\Policies\PolicyDefinitions\en-US
# Sichern der alten Datei mit dem Namen searchocr.adml durch xcopy
xcopy searchocr.adml \temp

Dann wird mit dem Editor eine Leerzeile in Zeile 26 eingefügt, und in diese leere Zeile der folgende String kopiert.

# Einfügen des folgenden Strings in Zeile 26"
Microsoft Windows 7 or later

Im Editor sieht das dann wie folgt aus.

image

Danach ist die Fehlermeldung verschwunden und die GPO-Einstellungen werden korrekt angezeigt.

Enjoy it, b!

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!

Routing mit Linux in virtuellen Umgebungen

Vor 4 Jahren hatte ich einen Blog geschrieben, wie man einen Microsoft Hyper-V Server 2016 als Router “verwenden” kann.

Natürlich stellt man sich dabei die Frage, wieso man das tun sollte? Zum einen ist der Hyper-V Server von Microsoft kostenlos und hat als Mitglied der Windows Server Core Familie geringere Systemanforderungen.

Es gibt hier eine Alternative, dazu müssen wir aber die Windows-Welt verlassen und uns Linux anschauen. Ich selbst bin historisch mit SUSE Linux verbunden, daher habe ich für diese Lösung openSUSE Leap 15.2 verwendet.

Als Ausgangslage haben wir die gleichen Voraussetzungen wie im Blog damals, also gleiche Netzwerke, IP-Adressen und die FRITZ!box usw. Also einfach mal den Blog nochmals anschauen, dort ist auch die Konfiguration der FRITZ!box selbst beschrieben.

Ausgangslage

Hier eine kurze Zusammenfassung davon:

  • Server mit 3 Netzwerkkarten (172.16.16.253, 192.168.110.0 und 192.168.120.1)
  • Fritz!BOX für den Internet-Zugang
  • Netzwerk an der FRITZ!box ist 172.16.16.0/24, das Gateway ist immer die 1 (also die FRITZ!box selbst)

Konfiguration der Linux VM

Für die VM unter Hyper-V habe ich die folgenden Parameter verwendet:

  • Hyper-V Generation 2 VM mit deaktiviertem Secure Boot
  • 2 CPUs
  • Dynamischer Hauptspeicher mit 1GB Start und maximal 2GB, im Betrieb läuft die VM mit grob 800MB
  • 64GB Festplatte (wobei hier auch weniger ausreichend ist), da die VHDX aber dynamisch ist, stellen die 64GB kein Problem dar
  • Zum Start nur einen Netzwerk-Adapter, wobei im Verlauf der Konfiguration weitere hinzugefügt werden

Die folgende Abbildung zeigt eine Übersicht der VM.

image

Installation openSUSE Leap 15.2 in der VM

Für die Installation wird das ISO-Image gemounted und die VM gestartet.

image

Im nun folgenden Menü Installation auswählen und den Dingen seinen Lauf lassen.

image

Da die VM über den einen Adapter eine IP-Adresse vom DHCP-Server bekommen hat, ist das Linux Setup in der Lage ggf. notwendige Updates aus dem Netz zu laden. Nach knapp 2min erscheint die Auswahl zur Konfiguration der Tastatur und der Lizenzvereinbarung. Ich verwende gerne VMs in englischer Sprache (English US) dazu aber eine Tastatur mit den deutschen (QWERTZ) Layout.

image

Hier dann auf Next drücken. Im nun folgenden Menü können wir auf eine Aktivierung von Online Repositories für unseren Zweck verzichten, also No auswählen.

image

Da wir einen schlanken Server wollen, treffen wir die Auswahl Server bei der Abfrage der System Role. Damit  haben wir zwar keine Oberfläche, können aber auf YaST zurück greifen, der alle notwendigen Aufgaben für uns erledigen kann.

image

Weiter geht es mit Next mit dem Vorschlag der Partitionierung die wir so übernehmen können.

image

Hier ebenfalls mit Next die Installation fortsetzen. Als Zeitzone wähle ich Europe und Germany und drücke abermals den Next Button.

Der Benutzer der im nächsten Schritt angelegt wird, findet später seine Verwendung für alle Aufrufe mit sudo.

image

Mit der Übersicht der gewählten Parameter kann die Installation starten.

image

Die gut 800 Pakete mit knapp 2GB Gesamtgröße installiert das Setup relativ schnell, für einen Kaffee reicht es aber trotzdem Smile

Konfiguration der Netzwerk-Adapter

Nach dem Neustart kann das ISO von der VM entfernt werden und die Anmeldung erfolgen.

image

YaST wird danach mit dem sudo Befehl gestartet und alle weiteren Schritte erfolgen im YaST Control Center unter System / Network Settings.

image

Als erstes verpassen wir der Netzwerkkarte eine feste IP (172.16.16.253/24). Dazu wird mit Edit die Konfiguration bearbeitet. Innerhalb von YaST springt man mit der TAB-Taste zwischen den einzelnen Menüpunkten hin und her. Zusätzlich zur IP-Adresse setze ich auch gleich den Hostnamen.

image

Mit Next bekommen wir wieder die Übersicht über die gemachten Einstellungen.

image

In den Einstellungen System / Network Settings / Hostname / DNS trage ich nochmals einen statischen Hostnamen ein und dazu noch die beiden im Netzwerk vorhandenen DNS-Server.

Mit Quit wird YaST beendet und die VM heruntergefahren, was wieder mit einem sudo shutdown erfolgt. Das Herunterfahren der VM ist notwendig, da ich zwei weitere  Netzwerk-Adapter hinzufüge die mit den Netzen 192.168.110.0/24 und 192.168.120.0/24 konfiguriert werden.

image

Der Trick, nur einen der beiden neuen Netzwerk-Adapter zu verbinden funktioniert unter Linux leider nicht, beide werden als Not Connected dargestellt. Nach dem Start der VM sind beide Netzwerk-Adapter zusätzlich sichtbar und können konfiguriert werden.

image

Welcher nun der richtige Adapter ist, lässt sich über die MAC-Adresse herausfinden.

image

Der Adapter eth1 bekommt nun die IP-Adresse 192.168.110.1/24 und dient zukünftig als Gateway für dieses Subnetz.

image

Analog dazu Adapter eth2 mit der Konfiguration 192.168.120.1/24 hier die Zusammenfassung aller Netzwerk-Adapter.

image

Was fehlt nun eigentlich noch? Richtig, wir haben das Routing selbst nicht aktiviert und ein Gateway ist ebenfalls noch nicht konfiguriert. Das erfolgt in den nächsten beiden Schritten.

Gateway und Routing

Die bisher gemachten Konfigurationen kann man mit der Auswahl von Next einfach mal schreiben lassen und hat diese damit gesichert.

Danach sind wir wieder im YaST Control Center unter System / Network Settings unterwegs.

image

Dort wird unter Network Settings / Routing die Weiterleitung für IPv4 aktiviert (wer hier IPv6 benötigt, bitte zusätzliche diese Option auswählen).

image

Damit fehlt nur noch das Gateway und das ist im YaST in der Textversion nach meiner Meinung fies versteckt.

Der Dialog zur Konfiguration ist unter System / Network Settings / Routing und dann unter der Option Add zu finden.

image

Hier wird das Gateway 172.16.16.1 für den Adapter mit der IP-Adresse 172.16.16.253 konfiguriert und damit die Konfiguration abgeschlossen.

Wer will, kann die VM nochmals neustarten. Bei mir hat es ohne diesen geklappt und der Router war fast fertig, denn natürlich muss noch die Firewall konfiguriert werden, sonst geht bei der Einstellung default nur der Ping durch.

Konfiguration der Firewall

Die Firewall in openSUSE verwendet Zonen, die eine Sammlung von geöffneten Ports und Protokollen darstellen. Ich habe die Firewall auf trusted gesetzt, damit ist ein interner Datenverkehr ohne weiteren Einschränkungen möglich.

image

Dazu werden die Netzwerk-Adapter mittels YaST von der Zone default in die Zone trusted geändert.

image

Enjoy it, b!

Fix: Windows 10 Update and Small Business Essentials Connector

Informationen in deutscher Sprache sind unter dem folgenden Link verfügbar.

While this blog is held in german language, one article requires an addition written in english language.

For Windows 10, Microsoft provides every 6 months a major version update to add new features to it’s client operating system.

This update, if done by an ISO or with an update package from WSUS may break the Windows Server Small Business Essentials Connector by forgot to migrate the connector services registry keys.

Windows SBE services

While these five services are displayed in the services.msc they are, without corresponding registry keys, are no longer functional.

Additionally the Windows 10 client seems to offline from Windows SBE dashboard.

Windows 10 clients offline in dashboard

To get the connector back working, I’ve written a script adding the missing registry keys from a PowerShell session. The ZIP-file contains beside the PowerShell code the REG-files containing the missing keys.

To run the script, follow the steps described bellow:

  1. Download the script and extract the content to a dedicated directory
  2. Open a PowerShell session as Administrator and jump to the directory with the PowerShell-script and the REG-files. Note, script and REG-files must live in the same directory
  3. Execute the script by running the following line of PowerShell (to workaround PowerShell Execution-Policies) and don’t miss the “-“ at the end of the script.
# Workaround some obscure PowerShell Execution-policies 😉
# don't miss the "-" at the end of the line!
Get-Content -Path .\Fix-WSeLaunchpad-1903.ps1 | PowerShell.exe -NoProfile -

A successful execution looks, like the following picture shows.

Note: Don’t forget to reboot your Windows 10 client, to make the connector work again.

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!