Archiv der Kategorie: Troubleshooting

The file name is too long – Löschen langer Pfade mit der Windows API

Veröffentlicht am von
Antwort

Lange Dateinamen und Pfade sind unter Windows eigentlich kein Thema mehr. Dennoch tauchen sie wie ein schlechter Traum, immer wieder auf und stellen einen vor das Problem, wie kann ich diesen langen Dateinamen oder Pfad nun löschen?

:: der normale Ansatz mit rd und dem Verzeichnis
E:\Shares\Projekte-2018> rd 20-old /s /q

Lieferte wie zu erwarten das folgende Ergebnis, mit einer Menge von nicht gelöschten Verzeichnissen und Dateien.

image

“The file name is too long.”

In diesem Beitrag aus dem Jahr 2011 hatte ich schon mal ein Skript mit Robocopy vorgestellt, welches das Problem bei mir zumindest, immer lösen konnte. Allerdings gab es auch einen Kommentar, der die Funktion des Skriptes nicht bestätigen konnte, zumindest nicht für sein Problem mit NetBeans. Eine genaue Validierung des Problems blieb aber aus.

Nun, knapp 12 Jahre danach habe ich mir, aufgrund einer aktuellen Aufgabenstellung darüber wieder Gedanken gemacht und dazu die Windows API verwendet.

:: der Ansatz mit rd über die Windows API
rd \\?\e:\Shares\Projekte-2018\20-old /s /q

Was wiederum nicht funktioniert hat, und mit dem gleichen Ergebnis “The file name is too long.” endete.

Nun besteht seit Windows 10 Version 1607 (und damit auch für den Windows Server 2016) die Möglichkeit “Enable Long Paths” in der Registry oder per GPO zu aktivieren.

image

Maximum Path Length Limitation – Win32 apps | Microsoft Learn

Die Einstellung hatte ich per GPO und einem entsprechendem gpupdate schon auf den Servern bereitgestellt.

Den Artikel sollte man sorgfältig lesen, denn dort werden Dateiverwaltungsfunktionen aufgelistet, welche nach dem Setzen des Registrierungsschlüssel NICHT mehr der MAX_PATH-Einschränkung unterliegen. Was mich wiederum auf die Idee gebracht hat die Sache mit PowerShell und .Net (Directory Class) zu versuchen.

# PowerShell mit .Net Directory Class
[System.IO.Directory]::Delete("E:\Shares\Projekte-2018\20-old", $true)

Damit der Aufruf funktioniert, muss man zwei Dinge beachten.

  1. Der Verzeichnisname muss vollständig übergeben werden, also nicht 20-old sondern E:\Shares\Projekte-2018\20-old
  2. Die Verzeichnisse sind nicht leer und darum benötigen wir noch ein $true um diese ohne Nachfrage zu löschen

Und den dritten Punkt hätte ich beinahe vergessen, Geduld! Das Löschen von ~500GB hat mehrere Stunden gedauert und kam mit der folgenden Meldung zu einem Ende.image

Es war am Ende eine Datei, die das vollständige Löschen verhindert hat. Auf dieser waren, aus welchem Grund auch immer, die ACL verbogen. Also nochmals icacls, wie in diesem Beitrag beschrieben drüber laufen lassen und der erneute Aufruf von [System.IO …] konnte alle restlichen Artefakte entfernen.

So, eigentlich wollte ich nur ein Verzeichnis löschen …

Enjoy it, b!

SBE: Howto fix Client Computer Backup

Veröffentlicht am von
2

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 sich einiges an Platz sparen kann wenn er das Laufwerk nicht sichert und auch nicht in die Hyper-V Replikation mit aufnimmt. Durch einen Defekt der Server-Hardware musste auf einen anderen Hyper-V Host umgeschaltet werden und der SBE “erwachte” aus der Replika ohne sein 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 Client Computer 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.

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 zu verwenden und der Rest passiert dazu im Hintergrund, dass war aber eine falsche Annahme. Es ist nämlich so, dass die Client Computer durch die Installation des Client Connector in die Datenbank des Client Computer Backups eingetragen werden. Die existiert aber nicht mehr und muss darum neu angelegt werden 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 erfolgreiche 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 einer Reparatur.

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.

Update 15.03.2023:
Die Integration oder Wiederaufnahme der Clients in das Backup, ist ohne eine Re-Installation des Client Connector möglich.

Wie im Folgenden zu sehen ist, zeigt das Dashboard die Windows Clients im Zustand Unknown.

image

Nun muss das Launchpad des Client Connector auf dem Windows Computer gestartet und die Option Backup ausgewählt werden.

image

Der Backup status am Client erscheint dann wie folgt, aber es wurde ein Verbindung zum SBE hergestellt was zu einer Änderung des Status führt.

image

Das Herstellen der Verbindung über das Launchpad ist ein einfacher Reconnect, der den Backup status von Unknown auf Not set up ändert und im Anschluss die Konfiguration des Backups vom SBE aus ermöglicht.

image

Ab jetzt läuft das Backup wieder, kein Reboot und vor allem auch keine Neuinstallation (des Connectors) waren dafür notwendig.

Ursprünglicher Beitrag:
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 würde ich darum auch in die Datensicherung des SBE aufnehmen.

Enjoy it, b!

Windows 11 2022 Enterprise Edition | Zugriffsprobleme auf das NAS

Veröffentlicht am von
1

Info: Ganz unten, im Update vom 02.11.2022 ist die Lösung für das Problem beschrieben. Wen die Hintergründe des Problems nicht interessieren, einfach gleich nach unten scrollen.

Der ursprüngliche Blogbeitrag

Nach dem Update auf Windows 11 22H2 konnte ich mich nicht mehr auf meine NAS-Laufwerke (Synology) verbinden. Zum Beispiel lieferte die Anzeige des Temp-Verzeichnisses mit dem DIR-Befehl die Meldung zurück, dass der Benutzername nicht korrekt ist und das war auch bei der Anzeige des Home-Verzeichnisses der Fall.

C:\Temp> dir \\nasbp.home.local\temp
Der Benutzername oder das Kennwort ist falsch.

Obwohl die Credentials mit cmdkey im System gespeichert sind, habe ich es nochmals mit dem Parameter /u:home\bernd probiert und abermals den Hinweis bekommen, dass mein Passwort nicht korrekt wäre.

image

Zuerst hatte ich das Windows 11 22H2 Update generell verdächtigt, aber auf allen Systemen bis auf zwei funktionierte der Zugriff nach wie vor.

Um das hier vorne weg zu nehmen, funktioniert hat der Zugriff von der Professional Edition aus und lediglich Clients mit der Windows 11 22H2 Enterprise Edition hatten Zugriffsprobleme.

Die Umgebung

Die Daten liegen auf einem Synology NAS (DSM 7.1x). Ich verwende aber nicht die Benutzer-Verwaltung von Synology, sondern den Synology Directory Server (was nix anderes als Samba ist) um den Zugriff auf die Laufwerke (Shares / Freigaben) auf dem NAS zu regeln. Die Anmeldung erfolgt damit gegen eine Samba-Domain, die über den Synology Directory Server bereitgestellt wird. Neben einigen Windows Systemen die in der Domain Mitglied sind, gibt es eine Reihe von Geräten die ihre Heimat woanders haben und lediglich über Benutzer / Passwort (was wiederum im Synology Directory Server liegt und per cmdkey auf dem Gerät gespeichert ist) auf das NAS zugreifen.

Das Problem und ein erster Workaround

Die Symptome zeigen sich auf zwei Wegen.

  1. Die Ansicht vom Verzeichnissen per Dir und dem FQDN / UNC-Pfad funktioniert nicht mehr (siehe Bild oben), egal ob das in der Eingabeaufforderung (cmd), PowerShell oder im Windows Explorer probiert wird
  2. Ein net use wie zum Beispiel net use t: \\nasbp.home.local\temp schlägt mit einem Fehler 86 fehl

Was aber immer geht, ist die Verwendung der IP des NAS und nicht des FQDN, also \\92.168.178.11\temp und damit habe ich hier auch gleich den Workaround beschrieben. Natürlich ist der Workaround nicht schön, aber erst einmal besser als nichts.

Die Ursache – The good case –

Um der Sache in Stück weit auf den Grund zu gehen, habe ich mich entschlossen einen Trace im Netzwerk zu ziehen. Wireshark und netsh sind hier die Mittel der Wahl. Bevor man sich dem eigentlichen Problem zuwendet, ist es sinnvoll mit einem Trace einen funktionierenden Zugriff mitzuschneiden.

image

Der Trace zeigt alle Schritte die erfolgen müssen um erfolgreich den Inhalt von \\nasbp.home.local\temp mit dem Benutzer home\bernd angezeigt zu bekommen.

Wichtig hier ist das Paket 479, in dem die Anforderung für home\bernd an den Server gesendet wird und die Bestätigung über Paket 481.

image

Zu sehen ist dabei auch, dass Domain, Account und Hostname des Clients korrekt angezeigt und übertragen werden.

image

In Paket 488 sieht man dann auch die finale Anfrage nach \\nasbp.home.local\temp und die erfolgreiche Bestätigung in Palet 490.

Die erfolgreiche Kommunikation basiert vollständig auf NTLM und verwendet kein Kerberos. Als Client war Windows 11 22H2 Professional Edition im Einsatz.

Die Ursache – The bad case –

Schaut man sich dagegen einen Trace an, in dem die Verbindung nicht zustande kommt, passieren hier andere interessante Dinge. Dazu müssen wir aber ein wenig ausholen und nicht nur den SMB Verkehr betrachten, der ist nämlich ein “Oper” von Dingen die davor passiert sind.

Die DNS Abfragen sehen hier noch wie erwartet aus.

image

Der Client (dieses Mal die IP 192.168.178.141, fragt den Server / das NAS 192.168.178.11 und .21 nach dem A (IPv4) und dem AAAA (IPv6) Eintrag ab und bekommt auch die korrekten Werte geliefert. Auch SMB scheint noch am Anfang korrekt zu arbeiten.

image

In Paket 159 fragt der Client den Server nach dem zu verwendenden SMB Dialect an.

image

In Paket 161 antwortet der Server mit SMB2 *

image

Daraufhin versucht der Client in Paket 162 auf eine nochmals höhere Version zu gehen.

image

Wo der Server auch gerne mitgeht Smile (irgendwie ist das wie beim Reizen im Skat).

image

In Paket 165, wurde letztendlich der höchste der angebotenen Dialekte SMB 3.1.1 verhandelt und angenommen.

image

Jetzt schickt der Client in Paket 171 (KRB5) einen AS-REQ an den Server.

image

Hier eine Abbildung der unter etype angebotenen Verschlüsselungsarten (Paket 171).

image

Die Anfrage wird vom Server abgelehnt (Paket 173), da er eine PRE-Authentification fordert, dazu wird aber auch gleich die notwendige Verschlüsselungsart mitgeteilt.

image

Die Kommunikation endet immer mit einem Fehler, nachdem insgesamt 6 Pakete ausgetauscht wurden.

KRB Error: KRB5KRB_AP_ERR_BAD_INTEGRITY

image

Das passiert wiederum 4x und danach erscheint die Meldung, dass der Benutzer oder das Passwort nicht korrekt ist und das nur, wenn als Client Windows 11 22H2 Enterprise Edition verwendet wird.

Ein zweiter (schmutziger) Workaround

Ich selber bin kein Freund von IP-Adressen in dem Sinne, dass sie für Verbindungen zu anderen Systemen genutzt oder gar hart verdrahtet werden. Wieso gibt es denn eigentlich DNS und den will ich auch verwenden?!

Einen Fall-Back von Kerberos auf NTLM lässt sich damit erzwingen, dass wir seitens des SMB-Servers (dem NAS) die DES-Encryption erzwingen.

image

Das ist an sich keine schöne Sachen, da DES als “weak” gilt und nicht mehr verwendet werden sollte.

Wie in den Paketen 95 und 97 im folgenden Trace zu sehen ist, können sich Server und Client nicht auf DES einigen und es erfolgt ein Fall-Backup auf NTLM.

image

Damit zwingt man die Enterprise Edition zum gleichen Verhalten wie die Windows 11 22H2 Professional Edition.

Zum Schluss

Es stellt sich nun die Frage, wieso verhält sich die Enterprise Edition eigentlich so, während Windows 11 22H2 Professional gleich mit NTLM ins Rennen geht.

Eine mögliche und für mich die einzige Erklärung die ich gefunden habe ist, dass mit Windows 11 22H2 bei der Enterprise Edition der Windows Defender Credential Guard aktiviert wurde.

image

Ich bin gespannt, wie die Sache weiter geht und werde es Euch wissen lassen wenn neue Erkenntnisse vorliegen. Falls hier jemand weitere Infos hat, bitte in die Kommentare unten reinschreiben.

Update 02.11.2022

Das Problem scheint nur Synology NAS Systeme und den Directory Server zu betreffen, ansonsten ist es recht ruhig zu dem Thema im Internet. Zumal, wenn der Zugriff über eine IP-Adresse anstatt des FQDN erfolgt, es ohnehin nicht auftritt.

Nun hat Synology Anfang November ein Update für den SMB Service bereitgestellt, welches das folgende Problem löst.

“Fixed an issue where users could not joind their computers to Synology Directory Server after updating OS to Windows 11 22H2”

image

Seitdem ist das Problem bei mir nicht mehr aufgetreten. Nach der Installation des Updates auf dem NAS habe ich die DES encryption für den Account wieder rückgängig gemacht und alles läuft und funktioniert wieder wie gehabt.

Enjoy it, b!

Excel–Öffnen in geschützter Ansicht

Veröffentlicht am von
Antwort

Nach einer Migration des Servers in eine DFS-Struktur, meldete sich Excel (aber auch andere Office Programme) mit der Meldung das Dateien nur in der “geschützten Ansicht” geöffnet werden können.

image

Der Hinweis rührt daher, dass sich der Name des Servers, der die Dateien bereitstellt geändert hat und die Office Anwendungen diesen nicht mehr als vertrauenswürdig einstufen.

Während der bisherige Zugriff über \\server\freigabe seit Jahren problemlos funktioniert hat, kommt beim Zugriff über \\dfs-fqdn\dfs\freigabe die oben gezeigte Meldung.

Beheben lässt sich das Problem an mehreren Stellen, am einfachsten aber über eine GPO welche dfs-fqdn als vertrauenswürdig einstuft.

image

In die Site to Zone Assignment List kann man mehrere Werte, IP-Bereiche usw. eintragen. Denkbar wäre zusätzlich nur “finance” falls es jemanden gibt der mit \\finance\dfs\freigabe anstatt \\finance.local\dfs\freigabe arbeitet, was zwar nicht sinnvoll aber möglich ist.

Der Wert 1 definiert die Domain (finance.local) als (1) Intranet zone und damit als vertrauenswürdig ein.

image

Definiert habe ich den Wert sowohl in der Computer Configuration als auch in der User Configuration der Policies / Richtlinen.

Im Internet kursieren eine Reihe alternativer Workarounds, wie zum Beispiel das Aufweichen der Sicherheitseinstellungen in Excel / Office wie im folgendem Screenshot zu sehen ist.

image

Davon halte ich nichts, Life is dangerous … und da muss man nicht zusätzlich die Anzahl der Angriffsvektoren erhöhen.

Enjoy it, b!

Fix: Windows 10 und 11 Update und der Essentials Connector

Veröffentlicht am von
138

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

Veröffentlicht am von
3

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!

Synology Directory Server | Passwort beim Zugriff auf ein Netzlaufwerk

Veröffentlicht am von
Antwort

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!

PowerShell Convert UNIX to DOS

Veröffentlicht am von
Antwort

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!

Windows 11 | SYSTEM_THREAD_EXECPTION_NOT_HANDLED

Veröffentlicht am von
Antwort

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!

Hyper-V 18560, Triple Fault

Veröffentlicht am von
Antwort

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!