Windows und der Secure-Channel

Einer meiner Windows 10 PC hatte das Problem, dass ich auf eine Reihe von Ordnern im Netzwerk nicht zugreifen konnte. Hauptsächlich waren es umgeleitet Ordner aus dem Benutzerprofil. Ich leite gerne die Eigenen Dateien / Documents auf den Server um.

Das Problem war, dass der Secure-Channel zum Server nicht mehr sauber funktionierte. Wie so oft lag die Lösung in PowerShell vergraben, und das sage ich weil man einfach wissen muss das es mit diesem Befehl so einfach geht.

Test-ComputerSecureChannel liefert True oder False zurück, je nachdem wie der Zustand der Verbindung zwischen dem PC und der Domain (Domain-Controller) ist.

Im Fall von False, lohnt sich die Verwendung des Parameters –Verbose um genauere Informationen zu erhalten.

Test-ComputerSecureChannel -Verbose
VERBOSE: Performing the operation "Test-ComputerSecureChannel" on target "ws1"
False
VERBOSE: The secure channel between the local computer and the domain sbsland.local is broken.

Eine Reparatur erfolgt dann unter der Verwendung eines Domänen-Administrators.

Test-ComputerSecureChannel -Repair -Credential (Get-Credential)

Darüber hinaus lässt sich über den Parameter –Server auch die Verbindung zu weiteren PCs oder Servern in der Domäne prüfen.

Test-ComputerSecureChannel -Server sbs.sbsland.local -Verbose
VERBOSE: Performing the operation "Test-ComputerSecureChannel" on target "ws1"
False
VERBOSE: The secure channel between the local computer and the domain sbsland.local is in good condition.

image

Enjoy it, b!

Ändern des DNS-Servers mit Netsh

Mit netsh.exe lassen sich eine Vielzahl von Änderungen durchführen. Nicht nur die IP kann von DHCP auf statisch geändert, sondern auch der/die DNS Server entsprechend neu konfiguriert werden.

:: Start von netsh
netsh

:: Anzeige der aktuellen Konfiguration
interface ip show config

Dann muss das entsprechende Interface heraus gesucht werden.image

Hier wäre des Adapter „Ethernet”

:: Setzen des neuen DNS auf 10.0.50.21
interface ip set dns Ethernet static 10.0.50.21

Danach kann man nochmals nachschauen, ob die Änderung passt.

:: Anzeige der aktuellen Konfiguration
interface ip show config

Enjoy it, b!

Microsoft SQL Server Login Probleme

Auf einem SQL Server 2012 Express (der eigentlich nur die Datenbank für den WSUS) bereit stellt, kam es zu dem Problem das ich mich nicht mehr über das SQL Server Management Studio anmelden konnte, oder das zwar die Anmeldung klappte aber der Zugriff auf die WSUS Datenbank (SUSDB) mit fehlenden Rechten verweigert wurde. Den SA konnte ich dazu auch nicht mehr aktivieren, obwohl ich Domain-Admin war.

Die Ursache des Problems

Das Problem lag darin, das während des Setups der Benutzer als Administrator zum SQL-Server hinzugefügt wurde. Irgendwann, wurde aber genau dieser Administrator gelöscht und wieder neu angelegt. Damit war der Zugriff auf den SQL Server nicht mehr möglich.

image

How to fix this

Die Lösung ist, wenn man sie kennt, relativ einfach. In einem ersten Schritt müssen wir herausfinden wie die Instanz des SQL Servers heißt. Das geht am einfachsten mit net start, im Anschluss wird die Instanz mit net stop gestoppt. Am einfachsten ist es alle Schritte in einer PowerShell oder Command Line mit erhöhten Rechten aus zu führen. Die Abfrage an sich geht zwar auch ohne, aber zum Stopp sind diese Rechte notwendig.

net start
...
SQL Server (MSSQLSERVER)
...

Stopp der SQL Server Instanz.

net stop "SQL Server (MSSQLSERVER)"

Der ganze Ablauf sieht dann wie folgt aus.

image

Sollte bei der Abfrage der SQL Server Agent auftauchen, so muss dieser ebenfalls gestoppt und deaktiviert werden! Wie hier, im Bild oben zu sehen ist, war das aber nicht notwendig.

Nun wird die SQL Server Instanz mit dem optionalen Schalter /m im Single-User Mode gestartet. Nun kann lediglich EIN einziger Benutzer die Verbindung zur Datenbank aufbauen (was auch die Grund ist den Agenten zu stoppen, startet dieser nämlich wieder zusammen mit dem SQL Server, dann ist die eine Verbindung belegt). Der Start im Singe-User Mode ermöglicht einem Mitglied der lokalen Administratoren die Verbindung als SYSADMIN auf zu bauen, damit haben wir die notwendigen Rechte um unser Problem zu fixen.

Der Start der SQL Server Instanz funktioniert analog zum Stopp, nur das dazu der Parameter /m verwendet wird.

net start "SQL Server (MSSQLSERVER)" /m

image

Nachdem die SQL Server Instanz erfolgreich gestartet wurde, kann eine Verbindung mit dem SQL Server Management Studio hergestellt werden und da wir mit SYSADMIN Rechten unterwegs sind, das Problem mit dem Login korrigiert werden.

Das SQL Server Management Studio starte ich in diesem Fall ebenfalls mit erhöhten Rechten (rechte Maustaste, …).

Nun wird unter Security/Logins der Benutzer (DOMAIN\USER) aus dem AD hinzugefügt und mit den folgenden Server Rollen ausgestattet:

  • public (Default)
  • sysadmin

image

Zusätzlich habe ich auch den SA mit einem schweren Passwort versehen und aktiviert.

Nach dem beenden des SQL Server Management Studios, muss die SQL Server Instanz gestoppt und wieder normal gestartet werden.

net stop "SQL Server (MSSQLSERVER)"
...
net start "SQL Server (MSSQLSERVER)"

image

Nach dem Neustart fehlte lediglich die Zuweisung des wieder angelegten Benutzers als DBO zur Datenbank. Der nun folgende Befehl wird im SQL Server Management Studio ausgeführt und ordnet den Benutzer zu.

ALTER AUTHORIZATION ON DATABASE::SUSDB TO [DOMAIN\USER];

image

Nun ist der volle Zugriff auf die SUSDB wieder vorhanden und ich kann sie endlich kleiner machen.

Enjoy it, b!

Hyper-V: Scheduled Checkpoint

Wenn Hyper-V (in diesem Fall war es die Version 2016), also Microsoft Hyper-V Server 2016 mit einem Checkpoint hängt, dann ist das Problem meistens der Hyper-V Virtual Machine Management Service.

Sichtbar wird das Problem durch folgende Anzeige im Hyper-V Management.

image

und Alternativ zum Status Deleting Checkpoint – Scheduled kann auch der Status Creating Checkpoint – Scheduled erscheinen, obwohl im Hyper-V Management keine Checkpoints angezeigt werden.

Die Lösung für das Problem ist ein Neustart des Hyper-V Virtual Machine Management Service, eventuell laufende VMs sind davon nicht betroffen und damit kann die Maßnahme ohne Downtime während des Betriebs durchgeführt werden.

:: cmd.exe/net.exe
net stop "Hyper-V Virtual Machine Management" && net start "Hyper-V Virtual Machine Management"
# PowerShell
Restart-Service -Name "Hyper-V Virtual Machine Management" -Verbose

Nach einem Neustart des Service ist alles wieder in Ordnung und die Meldung irgendwelcher Scheduled Checkpoints ist verschwunden.

image

Enjoy it, b!

Event 4121, Data Deduplication

Auf einem Windows Server 2012R2 ließ sich die Konfiguration für die Deduplizierung der Volumes nicht mehr starten, ebenfalls zeigte der Servermanager keine Informationen über deren Zustand an. Im Eventlog (Application and Services/Microsoft/Windows//Deduplication/Operational) waren viele Einträge mit dem Event 4121 zu sehen.

image

Alle Einträge mit dem Event 4121 deuteten auf eine korruptes XML-Datei im Laufwerk D: hin:

D:\System Volume Information\Dedup\Settings\dedupConfig.02.xml

Zumindest ich habe im Web keinen wirklich guten Vorschlag zur Lösung des Problems gefunden. Maßnahmen wir die Deinstallation der Deduplizierung, brachten ebenso wenig Erfolg wie ein Chkdsk auf dem Volume.

Das Problem habe ich nach einigem Überlegen wie folgt gelöst.

Analyse der dedupConfig.02.xml

Dazu habe ich die XML-Datei nach C:\Temp kopiert, da aber auf die Datei nur der SYSTEM Account Zugriff hat musste ich dazu eine cmd.exe mit PSEXEC starten.

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

Damit konnte ich die XML-Datei sehen und auch kopieren.

dir "D:\System Volume Information\Dedup\Settings\dedupConfig.02.xml" /ah

xcopy /h  "D:\System Volume Information\Dedup\Settings\dedupConfig.02.xml" C:\Temp

Im Verzeichnis C:\Temp habe ich erst einmal alle Attribute entfernt und versucht die Datei mit NotePad++ zu öffnen,

attrib -s -h -a dedupConfig.02.xml

Die Datei ließ sich mit keinem Editor öffnen, bzw. in einer sinnvollen Form lesen. Die Idee, wie das Ganze nun in den Griff zu bekommen sei, war von einem anderen Server (und hier ebenfalls von Laufwerk D die XML zu kopieren.

Dazu war der Ablauf wie folgt.

  1. Kopieren der neuen dedupConfig.02.xml nach C:\Temp (auf dem Quellsystem ist dazu ebenfalls eine cmd.exe unter dem SYSTEM Account notwendig, also wieder PSEXEC verwenden
  2. Setzen des Data Deduplication Service auf deaktiviert (im Service-Manager)
  3. Kopieren der Datei nach D:\System …
  4. Setzen des Data Deduplication Service auf manuell und starten des Deduplication Settings Wizards im Servermanager – Fertig!

image

Danach war wieder eine Konfiguration der Einstellungen möglich und es wurde sofort wieder der korrekte Status der Deduplizierung angezeigt.

Enjoy it, b!

Rücksetzen des lokalen Administrators

Im Blog vom 15.05.2019 (Death man walking) hatte ich die Deaktivierung des lokalen Administrators empfohlen. Vergisst man nun einen alternativen Administrator an zu legen oder hat dessen Passwort beziehungsweise des lokalen Admins vergessen, kann der Zugriff auf das System nur noch über einen Umweg erfolgen.

Was wollen wir eigentlich machen?

Um den Administrator durch die Hintertür zu öffnen, verschaffen wir uns über eine Sitzung der CMD.EXE Zugriff, welche unter dem Local System Account des Betriebssystems läuft und über den Anmeldebildschirm (LogonUI.exe) gestartet wird.

Der Anmeldebildschirm (LogonUi.exe) bietet nämlich die Möglichkeit ein Hilfsprogramm, den Utility-Manager (Utilman.exe) über ein Icon zu starten.

image

Ersetzt man nun die Utilman.exe durch die CMD.EXE, öffnet sich anstatt des Utility-Managers die Eingabeaufforderung. Doch was ist dafür notwendig?

Hilfsmittel und Voraussetzungen

Als Hilfsmittel verwenden wir ein Windows 10 Installationsmedium, dass entweder von einer DVD, USB-Stick oder im Falle einer VM also ISO zum Start des Rechners / Systems verwendet wird.

Die Info, wie wir an ein Windows 10 ISO kommen habe ich in diesem Blog beschrieben.

Dazu muss unter Umständen im BIOS des Rechners die Startreihenfolge geändert werden, so das vom Windows 10 Installationsmedium gestartet werden kann. Einige Motherboards und Notebooks erlauben hier auch durch Drücken einer Taste, dass Startmedium aus zu wählen. Im Falle einer VM unter Hyper-V sieht das dann wie folgt aus.

clip_image004

Der Ablauf

Nach einem erfolgreichen Start erscheint auf dem Bildschirm der folgende Dialog, an dem wir lediglich das passende Layout für die Tastatur auswählen (man muss sich das Leben nicht immer schwerer machen, als es ist).

clip_image006

Nach einem Klick auf Next / Weiter öffnen wir im folgenden Dialog mit SHIFT+F10 eine Eingabeaufforderung. Es soll ja gar keine Installation erfolgen, sondern wir benötigen Zugriff auf das Experten-GUI (die Eingabeaufforderung, CMD.EXE) Smile

clip_image008

Typischer Weise liegt das Betriebssystem auf Laufwerk C, insofern keine vorhandenen USB-Sticks, externe Festplatten oder andere Geräte es auf einen anderen Bezeichner verschoben haben. Dann gilt es einfach danach zu suchen.

Das Ersetzen der Utilman.exe erfolgt mit den nun folgenden Schritten:

  1. Wechsel in das Laufwerk C: nach \Windows\System32
  2. Umbenennen von Utilman.exe nach Utilman.bak
  3. Kopieren der CMD.EXE nach Utilman.exe
  4. Rechner neu starten (und davor noch das Installationsmedium entfernen), dass kann auch mit shutdown /r erfolgen.

Die Abbildung unten zeigt zusammenfassend alle Schritte.

image

Nach dem erfolgten Neustart, erscheint bei einem Klick auf das Ease of Access Symbol rechts unten die Eingabeaufforderung. Von der wir schon aus dem Titel des Fensters sehen können das es sich um die als Utilman.exe umbenannte CMD.EXE handelt.

clip_image012

Die Eingabeaufforderung läuft wiederum unter dem Local System Account und hat damit das Recht den lokalen Administrator zu bearbeiten.

image

Falls der Administrator deaktiviert ist, kann dennoch das Passwort gesetzt und anschließend dieser aktiviert werden.

net user administrator 1n$Höllen?Schwieriges!Passw0rd
net user administrator /active:yes

Das sieht dann nochmals wie folgt aus …

clip_image014

Zum Schluss gilt es dann nochmals die Sache mit der umbenannten Utilman.exe wieder auf zu räumen.

Aufräumen

Nach erfolgter Anmeldung, als Administrator in das Verzeichnis C:\Windows\System32 wechseln und dort die Utilman.bak nach Utilman.exe kopieren oder umbenennen.

copy /b /v utilman.bak utilman.exe

Wichtig für das Umbenennen ist, dass Windows dazu neu gestartet wird. Da die Utilman.exe sonst im Zugriff ist.

Enjoy it, b!

Das Windows Server Essentials Dashboard lässt sich nicht öffnen

Für einen neu angelegten Administrator war es nicht möglich das Dashboard des Windows Server Essentials 2016 zu öffnen. Der Versuch wurde mit der folgenden Fehlermeldung quittiert. Das folgende Bild zeigt die Meldung unter 2016 …

image

… oder wie im nächsten Bild zu sehen ist, die des Windows Server Essentials 2012R2.

image

Für die Fehleranalyse von Essentials spezifischen Funktionen sind die Logfiles im folgenden Verzeichnis ein guter Startpunkt:

C:\ProgramData\Microsoft\Windows Server\Logs

Dort befinden sich eine Reihe von Dashboard*.log Dateien, welche Informationen zur Ausführung des Dashboards gespeichert haben.

---------------------------------------------------------
[5016] 190312.115710.7435: General: Initializing...C:\Windows\system32\Essentials\Dashboard.exe
[5016] 190312.115711.4899: General: Failed to open ADTestHook registry key.
[5016] 190312.115711.4899: General: Failed to open ADTestHook registry key.
[6880] 190312.115711.6419: General: Color branding started
[6880] 190312.115711.6419: General: Processing Microsoft default SKU branding colors XML
[6880] 190312.115711.8369: General: Branding colors XML parsing started
[6880] 190312.115711.8659: General: Branding colors XML parsing ended
[6880] 190312.115711.8659: General: Looking for OEM branding colors XML
[6880] 190312.115711.8669: General: No OEM informations available
[6880] 190312.115711.8669: General: Color branding complete
[5016] 190312.115712.3499: General: Failed to open ADTestHook registry key.
[5016] 190312.115712.3499: General: Failed to open ADTestHook registry key.
[5016] 190312.115712.5779: General: Failed to open ADTestHook registry key.
[5016] 190312.115712.5779: General: Failed to open ADTestHook registry key.
[5016] 190312.115720.1563: Dashboard.Forms: Dashboard: Non domain admin cannot access dashboard.
---------------------------------------------------------

Besonders interessant fand ich die letzte Zeile mit dem Hinweis:

Non domain admin cannot access dashboard … der angelegte Admin war aber ein Domain Admin, sonst würde das auch keinen Sinn ergeben. Da die Mitgliedschaft über Gruppen geregelt wird, habe ich einen funktionierenden Domain Admin mit dem neuen Benutzer vergleichen und keinen Unterschied in den vorhandenen Gruppen feststellen können, bis ich im AD Objekt des Benutzers auf die Primäre Benutzergruppe (Primary group) gestoßen bin. Diese war bei dem funktionierendem Admin Domain Users und nicht Domain Admins wie bei dem Benutzer wo der Start des Dashboard fehlgeschlagen ist.

Eine Änderung von Domain Admins auf Domain Users, hat das Problem gelöst.

image

Das Dashboard konnte wieder geladen werden.

Enjoy it, b!