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.

Update 13.08.2022 – Notes from the field

Hier ein Hinweis zum Thema Windows 11 Insider-Preview.sbsland-w11-insider-preview

Update 03.10.2022 – Windows 11 22H2

Ob man das Windows 11 22H2 Update nun als sinnvoll betrachtet oder nicht. Microsoft sieht es als die aktuellste Version von Windows 11 und bietet es darum neben dem WSUS auch zum direkten Download per ISO an. Führt man das Update durch, funktioniert der Essentials Connector nicht mehr, erhält aber durch das hier bereitgestellte Script seine Funktion zurück.

 

Enjoy it,b!

Fix: Windows 10 and 11 Update and Small Business Essentials Connector

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

While this blog is held in German, one article requires an addition written in English language.

For Windows 10 and 11, Microsoft provides every 6 months (since 2022 every year) a major version update to add new features to it’s client operating system.

This update, if done by an ISO or with a 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, no longer functional.

Additionally the Windows 10/11 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.

image

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

Update October 3th, 2022

To make it short, Windows 11 22H2 Update also breaks the connector but the script will fix it.

Enjoy it, b!

racknex UM-INT-001 | SBE Compute Unit

Langsam muss ich mir doch Gedanken über die Umbenennung dieses Blogs machen, eine Anregung war SBE = Small Business Environments, was mir persönlich sehr gut gefällt. Der SBS (Small Business Server) verliert mit jeder Migration bei meinen Kunden, für mich an Bedeutung und auch aus Sicht des Supports von Microsoft sind seine Jahre gezählt.

Zeit über neue Ansätze nachzudenken und wieder einen Artikel über meine Freunde in Österreich zu schreiben, hiermit beste Grüße an racknex und die erfolgreiche Verwendung der UM-INT-001 als Rackmount für meine SBE Compute Unit.

UM-INT-001

Credits und Copyright liegen bei racknex

“Für was brauchen wir den eigentlich noch die beiden Server?” Fragte mich ein Kunde, nachdem wir seine Datei- und Anmeldedienste (und alles andere, was ein Small Business Server Essentials 2012 R2 so macht) auf zwei Synology NAS Systeme migriert hatten. Sein Szenario sah zu diesem Punkt wie folgt aus:

  • VPN-Server
  • Anmeldedienste (Synology Directory Server) und DNS
  • Dateidienste (SMB/CIFS)
  • DHCP
  • Backup der Arbeitsplätze und virtuellen Maschinen (VMs)
  • Surveillance (für die Videokameras in der Werkstatt) sowie Cloud-Backup
  • Docker Container mit WSUS Offline Update

Das alles verbunden mit einem zweiten Synology NAS welches zusätzlich den Anmeldedienst aktiv absichert und ansonsten für die Replikation von Snapshots und die Sicherung des primären NAS zum Einsatz kommt.

Gut, natürlich wir haben ja immer noch die Server, die inzwischen nicht mehr viel zu tun haben. Dort laufen gerade mal drei VMs (virtuelle Maschinen), eine für das Management der Drucker, die zweite für das ziemlich schrottig programmierte Warenwirtschaftssystem sowie eine dritte mit einem virtuellen Desktop und Windows 11. Die Absicherung der VMs erfolgt zum einen durch das Active Backup von Synology und natürlich über eine Hyper-V Replikation. Aufgefallen sind die beiden Server vor allem, da sie einen besonders hohen Geräuschpegel verursachten, der besonders im Sommer ziemlich auf die Nerven ging.

Darum musste auch hier eine Alternative her und war durch einen Zufall schnell gefunden. Während der Suche nach Treibern auf der Intel Homepage bin ich auf einen Artikel gestoßen, dass Intel NUC Systeme (zumindest einige von ihnen) 24×7 betrieben werden können. Bei fast allen meiner Kunden laufen die PCs ohnehin 24×7 und das nicht nur 3 oder 4 Jahre, insofern hatte ich keine Probleme mit der Vorstellung das sowas auch mit einem Intel NUC möglich wäre und sogar, im Falle von Intel, unterstützt wird. Eine Analyse der auf den Servern vorgehaltenen Kapazitäten ergab, dass zwei Intel NUCs mit dem i5 der 11ten Generation sowie 32GB Hauptspeicher und einer 2TB NVMe ausreichen würden. Das Ganze hat Brutto keine 2.000 € gekostet und konnte mit dem Rackmount von racknex sauber in das Rack eingebaut werden.

UM-INT-001

Nach der Migration der VMs hatten wir (der Kunde und ich) zwei Aha-Erlebnisse.

  • Zum einen reduzierte sich die Temperatur im Serverraum um 5° und die Kühlung musste im Sommer nicht mehr aktiv sein
  • Der Intel NUC mit der NVMe war so schnell, dass die VMs bei einem Neustart des Intel NUCs sogar eine reconnect einer RDP-Session ermöglichten

Die Ausfallsicherheit wird nach wie vor durch die Hyper-V Replica und dem Microsoft Hyper-V Server 2019 sichergestellt und auch hier sichert Synology Active Backup die VMs.

Das Setup läuft nun seit 3 Monaten ohne Probleme, mit Crystaldiskinfo prüfe ich die NVMe Laufwerke und lasse mir einen Alert schicken, wenn sich gravierende Parameter ändern.

Damit stellen sich zum Schluss zwei Fragen.

  1. Wieso hast Du nicht den Synology Virtual Machine Manager und die beiden NAS Systeme verwendet?
  2. Brauchst Du jetzt keine “echten” Server mehr?

Zu 1. muss ich sagen, dass in diesem Fall zwei der drei VMs schon eine ordentliche Rechenleistung benötigen. Nichts mit High-End, aber mehr als üblicher Weise ein Atom oder Celeron-Prozessor von Intel liefern. Ein Setup analog zu den Intel NUCs auf den beiden Synology NAS Systemen hätte deren Kosten und vor allem auch deren Geräuschpegel deutlich nach oben geschraubt. Dazu stellen die Intel NUC Systeme eine einfach Exit-Strategie dar, sollte die Idee aus irgendeinem Grund nicht funktionieren, dann machen wir normale Arbeitsplätze draus und kaufen wieder “echte” Server.

Zu 2. Für genau diese Anforderung des Kunden reichen die Intel NUCs mit Hyper-V Replica definitiv aus, zumal wir ja auch eine ordentliche Datensicherung haben. Richtige und damit vor allem teure und laute Server werde ich nach wie vor verwenden, wenn die Option mit den Synology NAS Systemen und nur zwei bis drei kleineren VMs nicht besteht. Dann machen wir alles wie gehabt, erprobt und solide aber auch deutlich teurer und wärmer. Da wir aber im kommenden Winter nicht wissen, wie kalt es bei uns werden wird, kann der Kunde ja die alten Server als Heizung mitlaufen lassen Smile

Bis bald mal wieder und enjoy it, b!

Synology Directory Server | Passwort beim Zugriff auf ein Netzlaufwerk

image

An dieser Stelle möchte ich auf den vielleicht wichtigsten Artikel im Synology Knowledge Center hinweisen Smile

https://kb.synology.com/en-id/DSM/tutorial/domain_user_not_get_group_permission

Es geht hier um eine nicht korrekte Auswertung von Gruppenmitgliedschaften beim Zugriff auf ein Netzlaufwerk.

Technischer Hintergrund

Einem Benutzer in der Domain wird über ein Anmeldeskript (login.cmd) ein neues Netzlaufwerk verbunden. Die Vergabe der Berechtigungen dazu erfolgt relativ einfach indem der Benutzer Mitglied in einer dafür erstellen Gruppe in der Domain wird. Diese Gruppe hat wiederum entsprechende Berechtigungen auf dem Netzlaufwerk.

  • Sepp (Benutzer) – Mitglied in der Gruppe “_ SN Immobilien Users”
  • Die Gruppe “_ SN Immobilien Users” hat R/W-Zugriff auf den Share \\sn-nas-15\immo

Das Problem

Für das neue Netzlaufwerk, muss auf einmal im Fenster des Anmeldeskript ein Passwort angegeben werden, das funktionale Passwort von Sepp wird hier aber nicht akzeptiert. Es bleibt nur die Möglichkeit das Fenster zu schließen und damit die darauffolgenden Maßnahmen (weitere Laufwerke usw.) abzubrechen.

Das erwartete Verhalten wäre, dass Sepp durch seine Mitgliedschaft in der Gruppe “_ SN Immobilien Users” die entsprechenden Berechtigungen auf dem Netzlaufwerk besitzt. Durch seine neue Anmeldung, wird der Security-Token neu erstellt und die (neue) Gruppen-Mitgliedschaft fließt in diesen mit ein.

Die Lösung

Auf dem Synology NAS müssen die folgenden beiden Änderungen durchgeführt werden.image

https://kb.synology.com/en-id/DSM/tutorial/domain_user_not_get_group_permission

Der Windows Client muss wie folgt behandelt werden, wobei bei mir ein Neustart genügte.

image

Danach war das Netzlaufwerk über die passende Gruppenmitgliedschaft im Zugriff.

Update: Ein defektes Computerkonto, kann ebenfalls den Zugriff auf ein Laufwerk verhindern. Die Symptome sind dabei die gleichen, es wird ebenfalls nach einem Benutzer und Passwort gefragt und dieses nicht akzeptiert. Es genügt dann den PC aus der Domäne heraus- und wieder reinzunehmen.

Enjoy it, b!

Synology Directory Server | Hyper-V Replica schlägt fehl–Kerberos Fehler

Ich arbeite bei kleinen Projekten gerne mit dem Synology Directory Server als Ersatz für das Microsoft Active Directory (AD). Bei wenigen Benutzern lassen sich damit einige Kosten sparen. Gelegentlich besteht jedoch auch hier die Anforderung, eine virtuelle Maschine (VM) hochverfügbar bereitzustellen. Dafür habe ich bisher immer den Microsoft Hyper-V Server (2019) in Verbindung mit der Hyper-V Replica verwendet.

Das klassische Setup funktionierte bis zur Aktivierung der Hyper-V-Replikation problemlos:

  • Join der beiden Hyper-V-Hosts in die Domäne des Synology Directory Servers
  • Öffnen der Firewall auf den Hyper-V-Hosts, um über Port 80 oder 443 zu replizieren
  • Verwendung der Kerberos-Authentifizierung (HTTP) für die Replikation
  • Einrichten der Hyper-V Replica für eine oder zwei VMs

Allerdings wurde ich am Ende der Konfiguration mit folgender Fehlermeldung konfrontiert – und konnte zunächst nichts damit anfangen:

image

Ja klar, es gibt ein Problem mit Kerberos … aber warum?

Die Namensauflösung funktionierte, und auch die ServicePrincipalNames waren registriert.

image

Auch die Ports 80 und 443 waren über die Firewall geöffnet und antworteten wie erwartet.

Mein Verdacht fiel nach einiger Zeit auf den Synology Directory Server. Dieser stellt eine Domäne mit folgendem Functional Level bereit:

  • Domain Functional Level: Equal to Windows Server 2008 R2

Die Hyper-V Replica wurde mit Windows Server 2012 eingeführt – was aber nicht zwingend bedeutet, dass die Domäne ebenfalls auf diesem Level sein muss. Ich vermute jedoch, dass hier – möglicherweise in Verbindung mit der Tatsache, dass intern Samba 4.10 läuft – das Problem liegt.

Als Alternative wollte ich nun die Authentifizierung per Zertifikat verwenden.

image

Dabei bin ich über eine Reihe von Herausforderungen gestolpert, die sich aber letztendlich lösen ließen. Als Grundlage habe ich diese Anleitung verwendet, die aber nur mit kleineren Modifikationen funktionierte.

Ein wichtiger Unterschied ist auf jeden Fall, dass meine beiden Hyper-V Hosts in der Domain verbleiben sollen, also nicht in einer Workgroup betrieben werden.

  • Insgesamt werden n+1 (N = Anzahl der Hyper-V Hosts die an der Replikation teilnehmen) Zertifikate erstellt. Für jeden Hyper-V Host eines (das Server-Zertifikat) und das Root-Zertifikat. Bei zwei Hosts, haben wir damit drei Zertifikate
  • Während das Root-Zertifikat auf jedem der Hyper-V Hosts installiert wird, bekommt jeder Host ein eigenes Server-Zertifikat

Auf dem ersten Knoten wird eine PowerShell-Sitzung als Administrator gestartet und dazu die folgenden Variabel angelegt.

Dabei bin ich auf einige Herausforderungen gestoßen, die ich aber lösen konnte. Als Grundlage diente mir eine Anleitung, die jedoch nur mit kleineren Anpassungen funktionierte.

Ein wichtiger Unterschied: Meine beiden Hyper-V-Hosts sollen in der Domäne verbleiben und nicht in einer Workgroup betrieben werden.

  • Insgesamt werden n+1 Zertifikate benötigt (n = Anzahl der Hyper-V-Hosts, die an der Replikation teilnehmen). Für jeden Host ein Server-Zertifikat sowie ein Root-Zertifikat. Bei zwei Hosts ergibt das drei Zertifikate.
  • Das Root-Zertifikat wird auf jedem Hyper-V-Host installiert, jeder Host erhält zusätzlich ein eigenes Server-Zertifikat.

Auf dem ersten Host wird eine PowerShell-Sitzung als Administrator gestartet und die folgenden Variablen gesetzt:

image

Dann wird das Root-Zertifikat erstellt. Dafür habe ich die folgenden Änderungen vorgenommen (Zeile 26).

  • KeyUsage CertSign  in KeyUsage CertSign, CRLSign, DigitalSignature

In Zeile 27

  • KeyLength 2056 in KeyLength 4096

image

Der Server, auf dem das Root-Zertifikat wurde, muss diesem ebenfalls vertrauen. Darum wird das Zertifikat von Personal nach Trusted Root Certification Authorities kopiert.

image

Nun werden auf demselben Knoten sowohl das Root-Zertifikat exportiert als auch die Server-Zertifikate erstellt.

image

Auch bei der Erstellung der Server-Zertifikaten habe ich Änderungen vorgenommen:

  • Hinzufügen eines weiteren Parameters (Zeile 64), wobei zuvor (Zeile 60) der FQDN erstellt wird:
    DnsName $fqdn, $name
  • KeyLength 4096

image

Auf allen Hyper-V Hosts muss nun die Prüfung der Zertifikate deaktiviert werden.

image

Nun werden die Zertifikate auf die anderen Knoten (hier nur einer) verteilt.

image

Tipp: Der “\” am Ende des Pfads erstellt das Verzeichnis automatisch.

Nun wird auf dem zweiten Knoten sowohl das Root- als auch der Server-Zertifikat importiert

image

Das sieht dann auf jedem Hyper-V Host wie folgt aus.

image

image

Damit sollte die Hyper-V Replikation eigentlich funktionieren – tat sie aber nicht. Zusätzlich zur certificate-based Authentification (HTTPS), musste ich auch noch die Verwendung von Kerberos (HTTP) aktivieren! Warum, kann ich nicht genau sagen und muss hier nochmals mit einem Netzwerk-Trace, der Sache auf den Grund gehen.

image

Mit dieser Konfiguration funktioniert nun die Hyper-V Replikation auch mit Hyper-V Hosts, die Mitglied in einer Samba-Domain und dem Synology Directory Server sind.

Enjoy it, b!

PowerShell Convert UNIX to DOS

Leider läuft Notepad++ auf Windows Server Core nicht mehr zuverlässig und so habe ich mich auf die Suche nach Alternativen gemacht und auch eine gefunden. Nun verwende ich seit geraumer Zeit Micro (a modern and intuitive terminal-based text editor).

Allerdings habe ich gelegentlich ein Problem mit der Darstellung und Verarbeitung von Dateien die unter UNIX / Linux abgespeichert wurden.

image

Damit diese problemlos bearbeitet werden können, konvertiere ich sie mit dem folgendem Einzeiler in PowerShell in das ASCII-Format.

Get-Content -Path .\vm-export-v029.ps1 | Out-File -Encoding ascii .\vm-export-v029.txt

Danach öffnet Micro die konvertierte Datei problemlos.

image

Enjoy it, b!

Drucker im Active Directory (AD)

Löscht man einen Drucker, der auch über das Active Directory (AD) gelistet war kann es vorkommen das dieser nach dem Löschen weiterhin angezeigt wird. Richtet sich dann ein Benutzer neue Drucker ein wird dieser, schon gelöschte und damit nicht mehr vorhandene Drucker, erneut angeboten.

image

Damit stellt sich die Frage, wo den der Drucker im Active Directory noch vorhanden ist und wie er entfernt werden kann.

Der Drucker ist über den Server im AD zu finden, auf dem er bereitgestellt wurde. Diese Information muss also noch vorhanden sein. Zur Anzeige aktiviert man Users, Contacts, Groups, and Computers as containers und findet damit unter dem Computer Objekt des Servers die von ihm bereitgestellten Drucker.

image

Das Drucker Objekt, kann dann mit einem Rechtsklick und Delete gelöscht werden.

image

image

Danach ist man den Drucker wirklich los.

Enjoy it, b!

Windows 11 | SYSTEM_THREAD_EXECPTION_NOT_HANDLED

So sollte ein Tag nicht beginnen.

IMG_20220630_063001_ON1_Cloud

Mein Lenovo P1 ist heute genau drei Jahre im Betrieb und ich kann in dieser Zeit auf insgesamt 10 BSODs (Stopp-Fehler) zurück blicken, dass waren einige mehr als ich mit meinen Microsoft Surface Book 2 (insgesamt vier) hatte. Nun könnte man von mangelnder Qualität bei Lenovo sprechen, was ich aber so nicht unterschreiben werde, denn alle der 10 Fehler hat mehr oder weniger mit der im Notebook verbauten Nvidia Grafikkarten zu tun.

Im Gegensatz zu früheren BSODs, wo eindeutig ein Nvidia-Treiber auf dem Stack zu sehen war, hat dieses Mal der DirectX Graphics MMS den BSOD verursacht und damit könnte der Fehler im Betriebssystem direkt zu suchen sein.

image

Der erste Blick in dem korrekt geschriebenen Dump mit dem Debugger ( !analyze –v) zeigte zumindest den Stop-Code (7E) und die lapidare Meldung, dass dieser Fehler wohl des Öfteren auftaucht. Auch der Treiber kann über den Dump zweifelsfrei dem Betriebssystem zugeordnet werden.

image

Trotzdem tat ich mich schwer, die eigentliche Ursache zu finden. Ein ganz guter Punkt zum suchen ist der folgende Link bei Microsoft, wo die Bug Check Code Reference zu sehen ist.

https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/bug-check-code-reference2

Von dort geht es weiter zum eigentlichen Code dem 7E, der in insgesamt drei Varianten hier beschrieben ist.

https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/bug-check-0x7e–system-thread-exception-not-handled

Ich hatte die Exception 0xC0000005, eine Zugriffsverletzung oder auch Access Denied

  • 0xC0000005: STATUS_ACCESS_VIOLATION indicates a memory access violation occurred

Letztendlich hat mich die Analyse nicht weitergebracht, aber immerhin den Hinweis darauf gegeben, dass ein Problem im Bereich der Grafiktreiber vorhanden sein könnte. Was mich wiederum zu einer holistischen Suche nach “dxgmms2.sys blue screen nvidia” verlasst hat und mir nicht wenige Einträge im NVIDIA Forum offenbarte.

Meine bisher abschließende Lösung ist damit, den NVIDIA Treiber zu aktualisieren.

image

Enjoy it, b!

Microsoft Surface Laptop Rubber Feed Replacement

Sollte bei einem Microsoft Surface Laptop 3 (oder auch 4) einer der Gummifüße abgehen, gibt es zwei Möglichkeiten das Problem zu beheben.

IMG_20220624_111150_ON1

DYI – Pattex tuts auch

Ist der Gummifuß noch vorhanden, kann man ihn mit Pattex oder Uhu wieder festkleben. Dazu habe ich das Loch und den Gummifuß mit Isopropropanol gereinigt. Den Pattex-Kleber sowohl auf den Rand des Lochs und auf den Gummifuß aufgetragen, trocken lassen und dann wieder verklebt.

Bisher hält dieser ohne Probleme. Zum Reparaturprozess noch ein paar Gedanken und Informationen.

  • Mit dem Isopropropanol bin ich beim Gummifuß sehr vorsichtig gewesen um ein Aushärten zu verhindern.
  • Die Wahl viel auf Pattex, bzw. Uhu da im Gegensatz zu Sekundenkleber dieser sich nicht in dem Bohrloch verteilt und ein Lösen der Schraube des Unterbodens verhindert und unmöglich macht. Der Pattex lässt sich hier relativ einfach wieder entfernen.

Neues “Food-Replacement” vom Hersteller

Ja, sowas gibt es. Bei Microsoft scheint das Problem wohl bekannt zu sein und der Hersteller bietet darum die Möglichkeit vier dieser Gummifüße nachzubestellen. Überraschend, für recht kleines Geld. Ich habe dafür 4 Euro bezahlt (alle 4 Füße zusammen). Ich schreibe überraschend aus dem Grund, da ich von Ersatzteilen aus dem Obstgarten andere Preise gewohnt bin oder man die reguläre Beschaffung generell verweigert.

Allerdings haben die Götter vor den Erfolg den Schweiß gesetzt und man muss wissen wie man an dieses Ersatzteil kommt.

Spätestens jetzt ist der Punkt gekommen, an dem man sein Surface Laptop bei Microsoft registrieren sollte. Ist das erfolgt, kann durch das Öffnen eines Support-Request die Bestellung ausgelöst werden. Aber auch hier ist auf die eine oder andere Kleinigkeit zu achten, die ich in den folgenden Schritten beschreiben werde.

  1. Registrierung des Surface Laptops unter dem folgendem Link https://account.microsoft.com/devices falls das schon geschehen ist, einfach den Link öffnen um von dort den Support-Request zu öffnen.

    image

    ddd

  2. Im nun folgenden Service-Dialog, die folgenden Optionen auswählen
    Kategorie = Accessory
    Problemtyp = Div
    Ausführliche Beschreibung des Problems | Rubber Feed replacement


    image

    Darauf erkennt der Dialog, dass neue Gummifüße notwendig sind, prüft die Adresse und bietet einem die passende Farbe zur Auswahl an

  3. Abhängig von der Farbe des Laptops, hier zwischen Black, Cobalt Blue, Platinum und Sandstone auswählen

    image

    und mit Weiter bestätigen.

  4. Zum Versand sind keine weiteren Maßnahmen erforderlich

    image

    und die Bezahlung erfolgt über die hinterlegte Kreditkarte. Ab jetzt ist der Prozess vollends selbst erklärend.

  5. Im Vorfeld ist es sinnvoll, zu prüfen ob die hinterlegte Kreditkarte noch gültig ist und hier ggf. die Daten zu aktualisieren
  6. Microsoft versendet im Anschluss eine Bestellbestätigung an die im Microsoft Konto hinterlegte Mail-Adresse

Final

Ich habe mir natürlich die Frage gestellt, wieso genau bei einem von insgesamt sechs mir bekannten Microsoft Surface Laptop Geräten der Gummifuß sich gelöst hat, aber nicht bei den anderen. Die Erklärung liegt in dem Arbeitsumfeld des Benutzers. Der Surface Device steht dort häufig auf einem Holz-, bzw. auf einem Labortisch und wird dort öfters verschoben. Die Füße haften dabei wohl relativ stark an den Tischplatten, was zu ihr Abnutzung und Ablösung führt.

Enjoy it, b!

Synology DS | Ausführen von WSUS Offline Update unter Docker

Auf dem Windows Small Business Essentials war bei mir immer der WSUS zur Aktualisierung der Server und Clients installiert. Das hat immer ganz gut funktioniert und ja ich gebe zu, es gab hier auf meinem Blog den einen oder anderen Artikel, der sich nicht immer positiv gegenüber dem WSUS gezeigt hat. Aber, letztendlich habe auch immer versucht eine Lösung zu meinem WSUS-Problem zu liefern.

Wird im Netzwerk, als Datenspeicher nur ein NAS, wie zum Beispiel eine Synology Diskstation (DS) verwendet, fehlt erst einmal die Möglichkeit einen WSUS zu betreiben und damit auch das zentrale Update der Server und Clients.
Schon seit langer Zeit habe ich zusätzlich zum WSUS für die Server gerne das WSUS Offline Update verwendet, welches wiederum als Community Edition (CE) auf GitLab verfügbar ist. Darüber hinaus existiert auf GitHub ein Docker Image, mit dem wiederum WSUS Offline Update in einem Docker Container ausgeführt werden kann.

Wie man so etwas angeht, soll dieser Beitrag beschreiben.

Voraussetzungen

  • Synology Disk Station mit der Unterstützung von Docker als Container Host
  • Das aus dem Synology Paket Zentrum installierte Docker-Paket

    image

  • Auf der Diskstation muss nun noch eine Freigabe erstellt werden, mit den folgenden Rechten und Eigenschaften

    image

    Ob man die Freigabe in der Netzwerkumgebung verstecken will oder nicht ist Geschmackssache, ich blende den Ordner immer aus, wenn die Installation der Updates exklusiv durch einen Admin oder automatisiert erfolgt und damit die Benutzer ihn nicht sehen sollen.
    Wird hingegen die Installation der Updates den Benutzern überlassen, dann sollte der Ordner eingeblendet werden.
    Darüber hinaus aktiviere ich die folgenden beiden Erweiterte Einstellungen

    image

    Dazu gebe ich der lokalen Gruppe users das Leserecht (Schreibgeschützt) und den Domain-Users ebenfalls.

    image

    Die Admins (lokal und Domain-Admins) haben ja per Default Lesen/Schreiben als Zugriffsrecht gesetzt.
    Dieser Ordner, also wsusoffline wird später in den Docker Container abgebildet.

Installation des Docker-Images

Nach der Installation von Docker, wird dieser gestartet, um das Image aus der Docker Registry herunterzuladen.

Dazu einfach ins Suchfeld R0gger (das ist der Entwickler des Images, 0 = Null) eingeben und Download klicken.

image

Wichtig ist hier die Auswahl der Community Edition (ce) um die aktuellste Version zu erhalten.

image

Die CE mit Auswählen bestätigen und der Download startet. Unter Image erscheint danach die 1, was den Download von einem Image signalisiert der nach ca. 250MB abgeschlossen ist.image

Konfiguration des Docker-Images

Durch einen Klick auf Starten wird das Docker-Image gestartet und dazu der Dialog zur Konfiguration aufgerufen.

Als Netzwerk verwenden wir die bridge und klicken auf Weiter.

image

Neben einem Automatischen Neustart, sind die Erweiterte Einstellungen interessant.

image

In den erweiterten Einstellungen werden die Laufzeit-Variablen für den Container festgelegt, Änderungen führe ich hier nur an den folgenden Variablen durch:

  • SYSTEM = w100-x64, w63-x64
  • OFFICE – löschen der Variabel, einfach aus dem Grund da alle meine Clients auf Microsoft365 laufen und die Updates aus der Cloud bekommen. Den Speicherplatz spare ich mir damit

image

Mit Speichern und Weiter, geht es dann weiter, wobei wir die Port-Einstellungen zu belassen wie sie sind und nur die Volume-Einstellungen konfigurieren müssen. Dort wird der Inhalt des Docker-Containers in die oben erstellte Freigabe wsusoffline gemounted.

image

  • wsusoffline = /wsus/wsusoffline

Mit dem Klick auf Weiter sind wir fertig und können den Container im Anschluss ausführen.

image

Running the Docker-Image

Damit kommen wir zum spannenden Teil, woher wissen wir eigentlich genau, ob wir alles richtig gemacht haben?

Läuft der Container, dann bietet uns die Option Details einen umfassenden Einblick was im Container vor sich geht.

image

Dort sind unter anderem der Ressourcen-Verbrauch, dass Mapping des Update-Ordners (wsusoffline) und die Laufzeitvariablen zu sehen.

image

Zwei weitere Punkte will ich hier nicht unerwähnt lassen. Zum einen habe ich mich schwergetan herauszufinden, wie den der Pfad lautet auf den der wsusoffline-Ordner gemapped werden soll?

Diesen habe ich in einer Terminal-Session ermittelt, dazu einfach unter Terminal eine Sitzung mit der Bash öffnen und nach dem Verzeichnis wsus im Root suchen.

image

Dort, also unter /wsus/wsusoffline werden die Updates gespeichert und dieser Ordner wiederum auf den wsusoffline-Ordner des NAS abgebildet, um den Zugriff über SMB zu ermöglichen.

Zuletzt habe ich noch mit einer Fehlermeldung gekämpft, und hierzu ein Paket (JSON-Processor) nachinstallieren müssen. Das geht ebenfalls in der Terminal-Session über die beiden folgenden Befehle.

# Installation des Pakets für die JSON-Interpretation
apt-get update
apt-get install jq

So, damit bin ich erstmal fertig und habe einen weiteren Schritt für eine alternative zum SBE beschrieben.

Enjoy it, b!