Hyper-V 18560, Triple Fault

Es gibt Probleme, die erwischen einen auf dem falschen Fuß. Während der Einführung und Konfiguration von Synology Active Backup for Business musste ich feststellen, dass eine wichtige VM noch auf einem Windows Server 2012 R2 Hyper-V Host lief. Das tat sie seit Jahren sehr zuverlässig und vfel damit in die Kategorie “never touch a running system …”

Synology Active Backup for Business benötigt aber mindestens die Hyper-V Version 6 der VM oder besser und damit einen Hyper-V Host der mindestens mit Windows Server 2016 oder höher läuft. Damit war notgedrungen eine Neuinstallation des Servers notwendig, da ich in diesem Fall auf den kostenlosen Microsoft Hyper-V Server 2019 zurückgreifen wollte.

Vor dem Upgrade dachte ich mir das bestimmt ein Updates des BIOS sinnvoll wäre, das auf dem Server verwendete war von 2014 und Supermicro hat für dieses Board nochmals 2021 ein neues BIOS bereitgestellt. Damit also zuerst den Microsoft Hyper-V Server 2019 installiert und gleich im Anschluss das BIOS aktualisiert. Für den Server war das eine so große Neuerung, dass er mir den konfigurierten SET weggeworfen hat und den Ethernet-Adapter 2 als Nummer 3 präsentierte. Kein Thema, ließ sich alles fixen.

Der Import der einzigen darauf verbliebenen VM (die zwar Generation 2, aber mit Version 5.0 lief) funktionierte funktionierte ebenfalls ohne Probleme, aber der Start wollte nicht gelingen und nach ca. 2min befand sich die VM wieder im ausgeschalteten Zustand.

Zuerst hatte ich das BIOS im Verdacht, aber eine neu eingerichtete VM mal schnell mit OpenSuse installiert, funktionierte ohne Probleme und auch die Hyper-V Replika zu dem anderen Windows Server 2019 Hyper-V Host lief ohne Probleme. Was also tun?

Ein Blick in das Eventlog offenbarte die beiden folgenden Events.

Critical 03/18/2022 20:13:12 Hyper-V-Worker 18604 None
'mt-app-1' has encountered a fatal error but a memory dump could not be generated. Error 0x2. If the problem persists, contact
Product Support for the guest operating system. (Virtual machine ID 0FDEE7BD-2627-4EC8-BE76-5EDF093B447B)
Critical 03/18/2022 20:13:12 Hyper-V-Worker 18560 None
'mt-app-1' was reset because an unrecoverable error occurred on a virtual processor that caused a triple fault. If the problem persists,
contact Product Support. (Virtual machine ID 0FDEE7BD-2627-4EC8-BE76-5EDF093B447A)

Der Fehler wurde zwar schon 2019 mit dem Update KB4497934 behoben, dass hatte aber noch nicht den Weg auf den neu installierten Hyper-V Host gefunden und damit musste ich auf den Workaround zur  Änderung des MAC Address Ranges greifen, was mit einem Aufruf in PowerShell recht einfach funktioniert.

Die folgende Abbildung zeigt den alten Adress-Bereich.

image

Für die Änderung muss man wissen wie eine MAC-Adresse überhaupt aufgebaut ist. Die ersten drei Oktette, also 11-22-33 oder in diesem Fall 00-15-5D sind dem jeweiligem Hardware-Hersteller zugeordnet, hier also Microsoft. Wenn nun der Bereich geändert werden soll, ist es am einfachsten das 4te Oktett zu inkrementieren.

# Anzeigen des aktuellen MAC-Adress Pools auf dem Hyper-V Host
Get-VMHost | Select ComputerName, MacAddressMinimum, MacAddressMaximum | ft
# Konfiguration eines neuen MAC-Adress Bereichs auf dem Hyper-V Host, das 4te Oktett wurde von 23 auf 24 geändert
Set-VMHost -MacAddressMinimum 00155D24AE00 -MacAddressMaximum 00155D24AEFF

Danach habe ich der VM den Netzwerk-Adapter entfernt und im Anschluss gleich wieder reinkonfiguriert. Danach startete mein Sorgenkind ohne Probleme.

Enjoy it, b!

Fix der SysVol-Replikation (DFS-R)

Neulich stand ich vor dem Problem, dass nach dem Einspielen von neuen Windows 10 ADMX-Dateien diese nicht zwischen den Domain Controllern (DCs) repliziert wurden.

Einen ersten Hinweis gab dazu das DFS Replication Event-Log, mit dem Event 4012.

image

Der Vorschlag direkt im Text ist, den DC der nicht an der Replikation teil nimmt aus der Replication Group zu entfernen und wieder hinzuzufügen ist ehrlichgesagt Bullshit, dass ist bei der SysVol Relikation mit DSF-R nicht möglich. Vielmehr muss man eine authoritative synchronization für das mit DFS-R replizierte SysVol durchführen.

Um trotzdem einen Blick auf die SysVol Replication Group werfen zu können, installiere ich gerne auf allen DCs oder in größeren Umgebungen auf Management Servern die DFS Management Tools aus dem Windows RSAT.

image

Mit PowerShell ist das ebenfalls möglich und kann für viele DCs automatisiert werden.

# Hinzufügen der RSAT DFS-Management Tools
Add-WindowsFeature -Name RSAT-DFS-Mgmt-Con

So, wie funktioniert nun die authoritative synchronization des SysVol?

Authoritative SysVol Replikation

Start von ADSIEDIT (über die Suchfunktion auf dem DC) oder das Startmenü, dort liegt das Tool unter Windows Administrative Tools / ADSI Edit.

image

In diesem Fall war die Ausgangslage wie folgt

  • slabad01.vmlabs.local (DC = OK)
  • slabad02.vmlabs.local (Replikation schlägt fehl)

Der slabad01 sollte also die Autorität für die SysVol Replikation werden und obwohl die Replikation ohnehin nicht mehr funktioniert, muss davor auf allen DCs die DFS Replication beendet und auf Manual gestellt werden.

image

image

Nachdem ADSI Edit (mit administrativen Rechten) gestartet wurde, bleiben die Standard-Einstellungen wie sie sind.

image

Nach dem Klick auf OK, steht uns ein Klick-Marathon bevor. Die KB von Microsoft referenziert hier wie folgt:

CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=,OU=Domain Controllers,DC=msDFSR-Enabled=FALSE

Das ist zwar korrekt stellt aber die genau umgekehrte Reihenfolge dar wie der eigentliche Weg ist. Dazu folgen wir dem nächsten Bild.

image

In den SYSVOL Subscription Properties setzen wir nun die beiden folgenden Werte:

msDFSR-Enabled=FALSE
msDFSR-options=1

Das nächste Bild zeigt beide Einstellungen.

image

Für alle anderen DC (bei mir ist es nur ein weiterer) muss ebenfalls msDFSR-Enabled=FALSE gesetzt werden.

msDFSR-Enabled=FALSE

Nun wird auf dem DC von dem die Replikation (Authoritative) aus erfolgen soll, die DFS Replikation wieder gestartet und auf Automatic gesetzt.

image

Nun findet sich im Event-Log der DFS Replication die ID 4114, diese indiziert das die Replikation dieses DC nicht aktiv ist (haben wir ja auch mit msDFSR-Enabled=FALSE deaktiviert).

Hoffentlich habt ihr ADSI Edit offen gelassen, nun wird nämlich der Wert für msDFSR-Enabled=TRUE gesetzt und eine Replikation mit DFSRDIAG POLLAD erzwungen.

DFSRDIAG POLLAD

image

Nun finden sich im Event-Log der DFS Replication die ID 4602, die besagt das auf diesem DC das SysVol wieder erfolgreich repliziert wird.

image

Für alle anderen DCs wird nun zuerst der Dienst für die die DFS Replication auf Automatic gesetzt und gestartet. Sobald der Event 4114 im DFS Replication Event-Log aufgetaucht ist, muss mit ADSI Edit für die restlichen DCs msDFSR-Enabled=FALSE wieder auf msDFSR-Enabled=TRUE gesetzt werden.

Im Anschluss muss auch auf jedem anderen DC ein DFSRDIAG POLLAD ausgeführt werden.

Dazu kann man einfach mal nachschauen ob im SysVol die fehlenden Richtlinien ankommen.image

Das Ereignis mit er ID 4604 meldet dann, dass die Replikation mit den anderen DCs eingesetzt hat und damit wäre auch das Problem gelöst.

Zusammenfassung

Zuerst wird auf dem DC der die autoritative Rolle einnehmen soll, die SysVol Replication wieder in Gang gebracht (er repliziert dann mit sich selbst) und im Anschluss die restlichen DCs mit eingebunden.

Enjoy it, b!

Bluetooth-Maus hängt unter Windows

Wenn unter Windows (egal ob Version 10 oder 11) immer mal wieder die Bluetooth-Maus hängt und das zum Beispiel besonders gerne in RDP-Sitzungen macht, kann das mit einer Einstellung im Intel® Wireless Bluetooth® Gerät (Device) zusammen hängen.image

In den Eigenschaften dieses Devices, muss die Option Allow the computer to turn off this device to save power im Power Management deaktiviert werden.

image

Damit sind die Hänger verschwunden und die Maus läuft ohne Probleme.

Enjoy it, b!

Mit dem Windows 11 Update KB5009566 keine L2TP VPN Verbindungen mehr möglich

Im Moment bin ich über das folgende Problem gestolpert. Nach der Installation von KB5009566 unter Windows 11 schlägt der Aufbau einer VPN-Verbindung mit L2TP fehl.

"The L2TP connection attempt failed because the security layer encountered a 
processing error during initial negotiations with the remote computer"

Eine Deinstallation des Updates bringt die verlorene Funktionalität zurück, diese kann über die Eingabeaufforderung (als Admin, also elevated / mit erhöhten Rechten) mit dem folgenden Befehl durchgeführt werden.

# Deinstallieren von KB5009566
wusa /uninstall /kb:5009566

Mal schauen, wann und wie Microsoft hier reagiert und hoffentlich nachbessert.

Update: Unter Windows 10 ist es wohl das Update KB5009543.

Enjoy it, b!

SBE: Howto fix Client Computer Backup

Die Annahme, dass das Laufwerk mit den Client Computer Backups auf dem SBE (Windows Server 2012R2 oder 2016 mit der Small Business Essentials Role) nicht wichtig ist, hat sich in meinem letzten Support-Fall als nicht korrekt herausgestellt.

Die Geschichte hat natürlich einen Anfang. Wird eine hinreichend große Anzahl von Clients (PCs im SBE Netzwerk) gesichert, kann das Laufwerk das den Sicherungsordner Client Computer Backup bereitstellt schon mal auf 1TB anwachsen. Der Kunde (oder dessen Administrator) dachte nun, dass er einigen Platz sparen kann, wenn er das Laufwerk nicht sichert und auch nicht in die Hyper-V Replikation aufnimmt. Durch einen Defekt der Server-Hardware musste auf einen anderen Hyper-V Host umgeschaltet werden und der SBE “erwachte” aus der Replika ohne die Client Computer Backups, beziehungsweise ohne das passende Laufwerk.

Gleiches kann natürlich auch passieren, wenn das Laufwerk versehentlich gelöscht wird oder auf einem anderen Wege kaputt geht.

Die Ausgangssituation

Vollständiger Verlust der Client Computer Backups mit samt des bereitstellenden Laufwerks. Damit werden die Clients nicht mehr gesichert und der SBE zeigt eine Reihe von Fehlermeldungen im Dashboard und auch in der Ereignisanzeige.

image

Nun stellt sich die Frage, wie diese Funktionalität wieder hergestellt werden kann und ob sich das überhaupt reparieren lässt?

Die Wiederherstellung der Client Computer Backup Funktionalität

Damit das nochmals klar wird, es geht hier nicht darum die Backups selbst wiederherzustellen, sondern die Funktionalität des SBE damit dieser wieder Backups der Clients anfertigen kann.

In einem ersten Schritt wird dem SBE wieder ein passendes Laufwerk bereitgestellt. Das geschieht in virtuellen Umgebungen durch Anhängen einer neuen VHD oder auf einem physikalischen Server durch Einbau einer neuen Platte.

Das neue Laufwerk erscheint unter dem Laufwerksbuchstaben I und wird mit NTFS formatiert. Nun dachte ich, dass es ausreichen würde die Funktion Repair backups / Repair now zu verwenden und der Rest passiert dazu im Hintergrund, dass war aber eine falsche Annahme. Es ist nämlich so, dass die Clients durch die Installation des Client Connectors in die Datenbank des Client Computer Backups eingetragen werden. Die existiert aber nicht mehr und muss darum neu angelegt und danach noch die Client Computer zugeordnet werden.

image

Ein Repair now … meldet zwar Erfolg, aber funktionieren tut hinterher das Client Computer Backup nicht.

Eine Reparatur erfolgt mit den folgenden Schritten:

Bereitstellen eines hinreichend großen Laufwerks, das einen Bezeichner besitzt und mit NTFS formatiert ist.

# Stopping Windows Server Essentials Computer Backup
Stop-Service -Name WseComputerBackupSvc -Force
# Create missing directories
New-Item -Type Directory -Path 'I:\ServerFolders\Client Computer Backups\'
# Starting Windows Server Essentials Computer Backup
Start-Service -Name WseComputerBackupSvc

image

Eigentlich legt der Windows Server Essentials Computer Backup Service beim Start, falls noch nicht vorhanden, seine Datenbank an. Ich habe aber schon gesehen, dass das nicht passiert ist. Darum lohnt sich nochmals das Ausführen der Reparatur (Repair now …)

image

Nun sollten die drei folgenden Dateien im Verzeichnis vorhanden sein.

image

  • Commit.dat
  • ConsistencyInfo.cc
  • DatabaseInfo.dat

Seitens des Servers ist nun alles eingerichtet, nun müssen wir noch die Clients zurückbringen.

Das habe ich bisher nur über eine De-Installation und Neu-Installation des Client Connectors hinbekommen. Zwischen den beiden Schritten, ist kein Neustart notwendig. Einfach den Connector deinstallieren und im Anschluss sofort wieder installieren und fertig.

image

Danach läuft das Backup wieder ohne Probleme.

image

Die drei oben genannten Dateien nehme ich darum auch in die Datensicherung auf.

image

Damit spart man sich zumindest die Arbeitsschritte auf dem Server.

Enjoy it, b!

Windows 11 | Stop Code PAGE_FAULT_IN_NONPAGED_AREA (50)

Heute Morgen hat sich mein Arbeitspferd, ein Lenovo P1, mit einem BSOD (Blue Screen of Death) verabschiedend.

Der STOP-Code lautete PAGE_FAULT_IN_NONPAGED_AREA und deutete gefühlt auf ein Treiber Problem hin. Da Windows den Memory-Dump (MEMORY.DMP) sauber geschrieben hat, war mein erster Weg sich die Sache einmal mit WinDBG (den Windows Debugger) anzuschauen.

image

WinDBG identifiziert hier schnell den Nvidia-Treiber als Verursacher.

nvlddmkm.sys

image

Und auch der Stack zeigt den Treiber, kurz vor der Exception. Diesen (also den Stack) liest man übrigens von unten nach oben.

image

Das Problem konnte ich durch ein Update des Nvidia-Treibers lösen. Installiert war die folgende Version.

image

Die Nvidia Homepage bietet dagegen schon einen neueren WHQL zertifizierten Treiber an.

image

Nach dem Update zeigt auch der Geräte Manager eine neuere Version an.

image

Vielen Dank für das Vorbeischauen.

!analyze –b Smile

Fix: Windows 10 und 11 Update und der Essentials Connector

Info: Bitte die Update Historie unten lesen, ursprünglich wurde das Script für Windows 10 Version 1903 entwickelt und seitdem immer wieder getestet und aktualisiert. Für alle die nicht lesen wollen, die aktuelle Version des Scripts befindet sich hier. Darüber hinaus funktioniert dieser Workaround ebenfalls mit Windows 11, wenn man ein Windows 10 System über das ISO aktualisiert.

For the english version, please follow this Link.

Zumindest aus Sicht des Windows Server Essentials Connector ist jedes Update von Windows 10 spannend. Die seit gestern offiziell verfügbaren Version 1903 für Windows 10 versäumt es beim Upgrade, die für die Ausführung des Windows Server Essentials Connectors notwendigen Dienste (Services) zu migrieren. Die sind nach dem Update nicht mehr vorhanden.WSE-1903

Damit ist der Windows 10 Client nicht mehr in der Lage sich am Windows Server Essentials an zu melden um seinen Status zu kommunizieren oder eine Sicherung durch zu führen. Im Dashboard des Server erscheint der Client Offline.

image

Damit das wieder klappt, müssen die Services hergestellt werden. Das geht am einfachsten durch das folgende Script, welches die Services in Form von REG-Dateien in die Registry importiert. Im Anschluss, nach einem Neustart funktioniert der Connector ohne Probleme.

image

Das Script und die dazu notwendigen REG-Dateien sind in der ZIP Datei als Download verfügbar. Für eventuelle Schäden lehne ich jegliche Haftung ab.

  • Die Ausführung des Scripts muss in einer PowerShell-Session als Administrator erfolgen
  • Script und REG-Dateien müssen zwingend im gleichen Verzeichnis liegen
  • Das Script prüft ob es sich um den Version 1903 oder höher handelt. Nur dann werden die REG-Dateien in die lokale Registry des Windows 10 Clients eingetragen

Möglicher Weise können Probleme mit der PowerShell Execution-Policy auftreten, dazu wende ich den folgenden Workaround an.

Get-Content -Path .\Fix-WSeLaunchpad-1903.ps1 | PowerShell.exe -NoProfile -

image


Update 30.05.2019

Inzwischen ist es mir gelungen, dass Microsoft dieses Problem als Bug (Fehler) betrachtet und an einem Fix arbeitet. Wie schnell damit zu rechnen ist, kann ich nicht sagen melde mich aber wenn ich weiteres weiß.

Update 15.07.2019

Das Script, und damit der Workaround funktionieren mit dem WSE 2016 und dem WSE 2012R2, dass mag im Blog nicht richtig rüber gekommen sein. Für die anderen Versionen (WSE 2011 und 2012) müsste man die Registry-Einträge des Connectors vergleichen.

Update 21.07.2019

Ich hatte nun die Gelegenheit Windows 10 Clients an einem SBE 2012 (ohne R2) um zu stellen und muss gestehen, dass das Script hier definitiv nicht funktioniert. Der Clientconnector dort verwendet wohl andere Einträge in der Registry als unter Windows Server 2012R2/2016.

Update 18.11.2019

Mit dem Update auf Windows 10 1909 gibt es keine Probleme, dass liegt an der von Microsoft geänderten Bereitstellung. Dazu werden vornehmlich nur Features freigeschaltet, die schon in früheren Versionen vorhanden waren.

Update 11.12.2019

Wird ein ISO mit Windows 10 1909 für einen Upgrade, zum Beispiel von Windows 7 auf Windows 10 verwendet. Schlägt der Bug wieder zu und das bisherige Script funktioniert leider nicht. Darum habe ich eine kleine Änderung durchgeführt und eine Version erstellt (steht nun auch in der History), die mit 1903 und neuer funktioniert.

Update 15.05.2020

Auch mit Windows 10 2004 tritt dieses Problem auf und kann über das Script behoben werden. Ich habe an diesem eine Reihe kleinerer Korrekturen durchgeführt und hier zum Download bereitgestellt.

Update 23.10.2020

Seit dem letzten Jahr, oder denken wir in Updates, seit Windows 10 Version 1909, liefert Microsoft das Herbstupdate als normales Windows Update aus, dass Features die im Verlauf der letzten Monate durch Updates (in 2004) installiert wurden aktiviert. Damit funktioniert das Update auf diesem Weg ohne Probleme und das Script ist nicht notwendig. Erfolgt aber ein Upgrade, zum Beispiel der Version 1909, durch das Windows 10 20H2 ISO, kann das Script im Anschluss den Connector reparieren.

Update 05.06.2021

Mit dem Windows 10 21H1 Update funktioniert das Script in der aktuellen Version ohne Änderungen. Wird das Update über den WSUS oder Windows Update installiert, dann funktioniert der Windows Essentials Connector ohne Probleme und das Script ist nicht notwendig. Erfolgt das Update hingegen über eine ISO Datei, die es als Download bei Microsoft gibt, kann der Essential Connector im Anschuss über das Script repariert werden.

Update 05.10.2021

Heute wurde Windows 11 released und ich habe gleich das Update probiert. Klappt mit den gleichen Problemen wie auch schon unter Windows 10. Genau genommen ist Windows 11 auch nur Windows 10 Build 22000 …

image

Das Script funktioniert auch hier ohne Probleme, ich habe aber die Ausgaben und Meldungen an das neue Windows angepasst.

Enjoy it,b!

Windows Update Error 0x80080005

Im Verlauf der letzten Update-Installation, hatte ich einige (drei) Windows Server 2016 die entweder die Updates nicht herunterladen oder sie im Anschluss nicht installieren wollten.

Die Installation blieb dabei bei einem Prozentwert (häufig 9 und 3%) stehen, oder der Download dauerte Stunden!

Ein manueller Versuch die Updates zu installieren endete mit einem 0x80080005 und der Windows Troubleshooter war ebenfalls nicht in der Lage einen von ihm erkannten Fehler im Windows Update zu beheben. Vielleicht habe ich mit 3 Stunden auch nicht lange genug gewartet, aber letztendlich musste eine funktionierende Lösung her.

Das Problem welches hier zu Grunde liegt, ist eine Korruption der Datenbank von Windows Update. Eine mögliche Lösung ist, dass man diese oder genauer gesagt den Ordner in dem diese liegt löscht. Damit geht aber die Option verloren, alte Updates zu entfernen.

Grundlagen

Die Lösung an sich ist recht einfach, den im Betriebssystem müssen lediglich zwei Ordner gelöscht werden:

# Löschen des Ordners SoftwareDistribution
%WINDIR%\SoftwareDistribution
# Löschen des Ordners Catroot2
%WINDIR%\System32\catroot2

Allerding sind die Ordner/Dateien von einer Reihe von Diensten im Zugriff und diese müssen zuerst einmal beendet werden. Darüber hinaus sind diese Dienste (Services) so konfiguriert, dass sie nicht immer laufen, sondern bei Bedarf getriggert werden. Ein simples net stop würde die laufenden Dienste beenden, was aber nicht sonderlich elegant ist.

net stop wuauserv
net stop cryptSvc
net stop bits
net stop msiserver

Code / Script

Mit PowerShell lässt sich das auf elegantere Weise lösen, allerdings wollte ich die Prüfung ob noch Dateien im SoftwareDistribution-Verzeichnis geöffnet sind nicht zu komplex gestalten. Darum habe ich handle.exe von Sysinternals als externes Programm verwendet.

Das Script kann über diesen Link heruntergeladen werden.

image

Code [Line 14 – 19]
Im Array $Services (Line 5) werden die zu stoppenden Dienste definiert und im Anschluss erfolgt eine Abfrage ob diese auch wirklich am laufen “Running” sind und nur dann werden sie auch gestoppt.

Code [Line 22]
Handle.exe (optional kann auch handle64.exe hier verwendet werden) liefert die Information zurück, ob eine Datei (die DataStore.ebd) noch geöffnet ist. Damit hat möglicher Weise das Beenden von einem der Dienste nicht funktioniert.

Code [Line 25 – 29]
Für den Fall, dass hier noch einer der Dienste die DataStore.ebd geöffnet hat, wird dessen Prozess über Stop-Process beendet. Spätestens jetzt wurde damit die Grundlage geschaffen das Windows System im Anschluss neu zu starten.

Code [Line 32 – 33]

Die beiden Verzeichnisse SoftwareDistribution und CatRoot2 sollten sich nun ohne Probleme löschen lassen.

Code [Line 36]

Nach einem erfolgtem Neustart werden die Verzeichnisse SoftwareDistribution und CatRoot2 vom Windows Update Dienst wieder angelegt und auch die darin notwendigen Dateien neu erstellt.

Darum können wir auf den Start der Dienste verzichten, sondern überlassen diese Aufgabe dem Neustart des Betriebssystems. Ein Aufruf von Update zeigte dann auch alle notwendigen Updates an und konnte auch diese Installieren.

image

Enjoy it, b!

LANCOM – Dead Peer Connection Timeout

Nach einem Abbruch einer VPN-Verbindung eines Windows Clients, konnten mit einem LANCOM Router keine VPN-Verbindungen mehr aufgebaut werden. Um eine Lösung für dieses Problem zu finden, war ich mit dem Hersteller mehrere Wochen in Kontakt. Starten möchte ich aber mit dem Setup der Umgebung.

Ausgangsituation

LANCOM 1781VA Router mit mehreren VPN-Verbindungen. Zwei davon sind permanente VPN-Tunnels zu Partnern und Standorten, dazu existiert für 5 Clients die Möglichkeit sich über VPN in das Firmennetzwerk einzuwählen.

Die folgende Abbildung zeigt aktuell drei Verbindungen mit den folgenden Funktionen.

image

  • HI-VPN stellt eine von Router ausgehende Verbindung zu einem Partner-Netzwerk dar
  • LC-1781VAW ist die eingehende Verbindung einer Zweigstelle
  • XX-NBK-<?>-VPN die Einwahl der Mitarbeiter aus dem Homeoffice durch den LANCOM Advanced VPN Client

Problem

Wurde von einem der Mitarbeiter im Homeoffice die Verbindung nicht ordentlich getrennt, sondern das Notebook nur in den Sleepmodus gesetzt. Dann zeigte nach ungefähr 2min das VPN auf dem LANCOM 1781VA Router einen Fehler mit einem “Dead Peer Connection Timeout”.

Keine der vorhandenen VPN-Verbindungen (sowohl Partner als auch Zweigstelle) konnte danach aufgebaut werden.

Beheben ließ sich dieses Problem nur, durch einen Neustart des Routers. Dieser funktionierte dann wieder problemlos, bis der nächste Mitarbeiter das Notebook schlafen legte.

Lösung

Der Verursacher des Problems war,  das sowohl im IDS und im DoS die Option Lock target port aktiviert war. Anscheinend erkennt der LANCOM Router den Abbruch der Verbindung als IDS/DoS und sperrt daraufhin die Ports welche für das VPN notwendig sind.

image

image

Nachdem die Option Lock target port deaktiviert wurde, läuft der Router wieder ohne Probleme wie ein Schweizer-Uhrwerk.

Enjoy it, b!

Windows SBE remotewebaccess.com Update schlägt fehlt

Mit dem Beginn dieser Woche (KW11/2021) waren einige meiner auf Windows Server 2012R2 basierenden Small Business Essential Server nicht mehr in der Lage ihre für den Anywhere-Access notwendige Sub-Domain unter remotewebaccess.com zu aktualisieren. Genau genommen betrifft das Problem alle SBE, aber manche haben eine statische IP-Adresse und was sich nicht ändert, muss man auch nicht aktualisieren. Die Problem-Kandidaten waren also Kunden (Telekom- und 1&1 ) die täglich eine neue dynamische IPv4-Adresse vom Provider bekommen.
image

Damit klappte natürlich auch der Zugang auf https://sbe.remotewebaccess.com/remote nicht mehr. Da hinter dem Zugang über remotewebaccess.com ein Zertifikat steckt, hat auch ein Zugang über “nur” die IP nicht gut funktioniert.

Das Fehlerbild war dubios, bis ich die Idee hatte das möglicher Weise der auf dem SBE laufende Update Client ein Problem mit der Verschlüsselung haben könnte. Stichwort TLS 1.0, TLS 1.1 Deaktivierung durch Microsoft.

Wenn man einen Blick auf die Release Documentation for Windows Server Essentials wirft, findet man zum eine Aktualisierung von 10.03.2021 …

image

… und dazu den folgenden Absatz.

image

Auch der Windows Server Essentials soll TLS 1.2 nutzen, Nach diesem Absatz dachte ich, OK – das ist es nicht, der Windows Server 2012R2 und neuer verwenden automatisch TLS.

image

Diese Aussage trifft zwar auf den Windows Server selbst zu, aber für das .Net Framework war dennoch ein wenig Nacharbeit notwendig und damit war ich auch auf die Lösung des Problems gestoßen.

Für beide auf dem Server installierten .Net Versionen (v2.0.50727 und v4.0.30319) mussten die folgenden Einträge in die Registry zusätzlich eingetragen werden.

# 64-bit OS
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v2.0.50727]
"SystemDefaultTlsVersions" = dword:00000001
"SchUseStrongCrypto" = dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]
"SystemDefaultTlsVersions" = dword:00000001
"SchUseStrongCrypto" = dword:00000001
# 32-bit Applications running on 64-bit OS
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v2.0.50727]
"SystemDefaultTlsVersions" = dword:00000001
"SchUseStrongCrypto" = dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319]
"SystemDefaultTlsVersions" = dword:00000001
"SchUseStrongCrypto" = dword:00000001

Mit PowerShell geht das sehr einfach die Befehle müssen als Administrator in PowerShell (elevated Session) ausgeführt werden.

# PowerShell
New-ItemProperty -Path "HKLM:\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v2.0.50727" -Name "SystemDefaultTlsVersions" -Value 1 -PropertyType DWORD -Force
New-ItemProperty -Path "HKLM:\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v2.0.50727" -Name "SchUseStrongCrypto" -Value 1 -PropertyType DWORD -Force
New-ItemProperty -Path "HKLM:\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319" -Name "SystemDefaultTlsVersions" -Value 1 -PropertyType DWORD -Force
New-ItemProperty -Path "HKLM:\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319" -Name "SchUseStrongCrypto" -Value 1 -PropertyType DWORD -Force

New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\.NETFramework\v2.0.50727" -Name "SystemDefaultTlsVersions" -Value 1 -PropertyType DWORD -Force
New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\.NETFramework\v2.0.50727" -Name "SchUseStrongCrypto" -Value 1 -PropertyType DWORD -Force
New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319" -Name "SystemDefaultTlsVersions" -Value 1 -PropertyType DWORD -Force
New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319" -Name "SchUseStrongCrypto" -Value 1 -PropertyType DWORD -Force

Danach noch den Server neu starten (Restart-Computer).

Update 20.03.2021
Für den Windows Server 2012 (OHNE R2) sind neben den oben beschriebenen Einträgen noch die folgenden Keys in der Registry zu setzen

# PowerShell
New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp" -Name "DefaultSecureProtocols" -Value '0xAA0' -PropertyType DWORD -Force
New-ItemProperty -Path "HKLM:\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp" -Name "DefaultSecureProtocols" -Value '0xAA0' -PropertyType DWORD -Force

Microsoft bietet hier auch ein eigene Lösung an um den Fix zu installieren. Dazu gibt es weitere Infos hier.

Update 22.03.2021
Das Problem tritt natürlich auch auf dem Windows Server 2016 SBE auf, und kann mit den gleichen Einträgen in der Registry wie für Windows Server 2012R2 behoben werden.

image

Die Abbildung oben zeigt den Fehler des Update-Mechanismus auch im Windows Eventlog unter Microsoft-Windows-ServerEssentials/Admin.

Enjoy it, b!