Windows Backup und das erste Mal

Willkommen zu einem neuen Beitrag über Windows Backup. Was passiert den genau beim Backup und was kann, besonders wenn dieses erstmals ausgeführt wird, schief gehen.

Ein wenig Backup Anatomie

Windows Backup arbeitet nach einem Prinzip das als “Inkremental forever” beschrieben werden kann.Nach dem ersten erfolgreichen Backup werden immer nur die Veränderungen zwischen den einzelnen Backups gesichert. Das hat prinzipiell den Vorteil, dass wenn einmal alle Dateien gesichert wurden (auch wenn es viele sind) nur noch wenige Veränderungen ins Backup aufgenommen werden und damit die weiteren Sicherungen schnell fertig sind.

Herausforderungen

Wird Windows Backup das erste Mal ausgeführt, steht abhängig von der Konfiguration, möglicher Weise eine Vollsicherung des Servers an und das kann dauern und von den Einstellungen des Backup-Tasks sabotiert werden. Die Zeit, welche für ein Backup benötigt wird hängt im Wesentlichen von den Faktoren Performance, Größe und Anzahl der zu sichernden Dateien ab.

Einstellungen für Windows Backup

Damit Windows Backup ungestört seine initiale Sicherung des Servers fertigstellen kann, gibt es zwei Möglichkeiten.

  1. Einstellungen des Backup Tasks
  2. Menge der zu sichernden Dateien

Einstellungen des Backup Tasks

Wie schon in diesem Beitrag beschrieben, bergen die Einstellungen des Backup Tasks einige Unsicherheiten welche ein erstes und erfolgreiches Backup schwierig machen können. Die einfachste Möglichkeit hier ist, dem Backup die notwendige Zeit (auch wenn es mehrere Tage sind) für die Vollsicherung ein zu räumen. Dabei sind die folgenden Einstellungen sinnvoll.

  • Stop the task if it runs longer than … = deaktivieren
  • If the task is already running, then the following rule applies = Do not start a new instance

image

Damit geben wir dem Backup die Möglichkeit, so lange zu laufen bis die erste Sicherung erfolgt ist und vermeiden zusätzliche Windows Backup Failed Meldungen im Backup selbst.

Nach erfolgreicher erster Sicherung, kann die Einstellung wieder aktiviert werden.

  • Stop the task if it runs longer than [3 days] = aktiv

Menge der zu sichernden Dateien

Als weiterer und nicht nur alternativer Ansatzpunkt kann eine Reduktion der zu sichernden Menge an Daten während des ersten Backups sein. Dazu werden einfach nicht alle Laufwerke ausgewählt sondern nur das Systemlaufwerk und zum Beispiel ein Datenvolume, hier F:

image

Ist die Sicherung damit erfolgreich zu ihrem Abschluss gekommen, kann für den nächsten Zyklus das Laufwerk D: hinzugefügt werden, bis alle Laufwerke in der Sicherung enthalten sind.

Eine weiter Option, an Stelle von ganzen Laufwerken mit der Inklusion von einzelnen Verzeichnissen zu arbeiten ist nur dann sinnvoll, wenn KEINE Deduplizierung auf den Volume stattfindet.

image

Diese kleine Warnung wird gerne überlesen und es kommt damit zu sehr langen Laufzeiten des Backups und einer Reihe von anderen Problemen.

Enjoy it, b!

Windows Backup (schlägt fehl)

Es gibt einige Gründe wieso Windows Backup nicht richtig funktionieren kann. Mit diesem Beitrag möchte ich eine Kleinserie beginnen und eine Reihe von Problemen in Windows Backup analysieren und falls vorhanden, eine Lösung beschreiben.

Doch erstmal an dieser Stelle, hallo und ein gutes Neues Jahr 2020 – dazu wünsche ich Euch allen viel Gesundheit und möglichst wenig Stress mit Euren laufenden IT-Systemen.

Windows Backup Failed

Der Start der Serie ist ein gelegentlicher Fehler, dass Windows Backup fehlgeschlagen ist. Wie das folgende Bild zeigt, läuft Windows Backup manchmal und dann wieder nicht.image

Der Grund dafür ist relativ einfach und liegt in der Konfiguration des Tasks welcher von Windows Backup selbst angelegt wird.

Die Lösung für fehlgeschlagene Backups (Failed)

Ich habe festgestellt, dass zwei Backup-Jobs nur in seltenen Fällen parallel laufen können. Auf keinen Fall klappt das, wenn die gleichen Laufwerke und Dateien gesichert werden sollen. Genau das wird aber vom Backup Task nicht berücksichtigt und kommt es dann zu einer Überschneidung beider Backup Jobs geht die Sache daneben.

image

Der Job war erst um 21:21 Uhr fertig und der fehlgeschlagene wurde wie eingestellt um 21:00 Uhr gestartet. Die folgende Einstellung sorgt für die oben gezeigte Meldung.

If the task is already running, then the following applies = Run a new instance in parallel

image

Obwohl das vorherige Backup noch nicht fertig ist, wird hier einfach der nächste Job gestartet und das geht mit der Fehlermeldung oben schief. Die Lösung für dieses Problem ist eine Änderung auf die folgend GRÜN markierte Einstellung.

If the task is already running, then the following applies = Do not start a new instance

image

Nun wird gewartet (maximal drei Tage), bis Windows Backup fertig ist. Nach drei Tagen wird dieser Task ebenfalls beendet und ein neuer kann seine Arbeit aufnehmen. Aber auch diese Einstellung sollte für ein initiales Backup überdacht werden. Mehr dazu in einem der nächsten Blogs.

Weitere Blogs

Weitere Beiträge zu dem Thema werden die folgenden Bereiche behandeln:

  • Das erste Mal
  • Performance
  • Anzahl der Dateien

Stay tuned Smile

Enjoy it, b!

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!

Windows Server 2012 R2 “Signing out”

Immer mal wieder habe ich bei einem Windows Server 2012 R2 das Problem, dass dieser Ewigkeiten mit einer Abmeldung beschäftigt ist und dieser Prozess zu hängen scheint.

image

Ein ähnliches Problem wird in diesem Blog beschrieben und auch dafür eine Lösung geboten, ich habe mir aber wie folgt beholfen.

  1. Öffnen einer Session mittels PsExec auf den betroffenen Server
  2. Abfrage der Sessions mit query session
  3. Logoff der Session über die ID

Die im Blog empfohlenen Fixes waren oder sind ja auf dem Windows Server noch nicht installiert.

# Aufbau einer Session mit PsExec
psexec \\server cmd.exe

# Abfrage der aktiven Sessions (hier die ID heraussuchen)
query session

# Abmelden der Session, logoff ID
logoff 3

Das sieht dann wie folgt aus.

image

Enjoy it, b!