Windows Recovery Partition löschen und neu erstellen

Vor etwas mehr als 8 Jahren habe ich einen Blog über das Löschen der Windows Recovery Partition geschrieben. Hey, mehr als 8 Jahre in der IT ist eine halbe Ewigkeit, vielleicht sogar mehr. Damals ging es darum, ein Problem mit dem Client-Backup des Windows Small Business Essential Server zu lösen.

Wichtig:
Die Partitionsnummern können abweichen. Achtet deshalb unbedingt darauf, dass die ermittelte Nummer verwendet und das Skript nicht nach dem Prinzip „Fire and Forget“ ausgeführt wird. Dafür ist es nämlich nicht gedacht, sondern dient lediglich als Sammlung der verwendeten Befehle.

Unten gibt es dann auch das Update wenn die Winre.wim fehlen sollte, der eigentliche Beitrag ist ja aus dem Juni 2024.

Das Problem

Heute mit Windows 11 und dem Server 2022 ist die Recovery Partition immer noch ein Thema. Meistens, wenn die Systempartition erweitert werden muss, befindet sich die Windows Recovery Partition am Ende der Festplatte.

Genau genommen sprechen wir vom Windows Recovery Environment (Windows RE), zu dem auch die Windows Recovery Partition gehört.

Die folgende Abbildung zeigt die Recovery Partition auf einem Windows Server 2022.

image

Wird die Disk nun erweitert (auf 196GB), dann sieht das wie folgt aus.

image

Natürlich gibt es eine Reihe von 3rd-Party-Tools, die hier helfen können, und einige davon sind sogar OpenSource, andere wiederum laufen in den kostenlosen Versionen nicht auf den Servern und müssen (und sollten) für den kommerziellen Einsatz bezahlt werden.

Wenn noch eine größere Anzahl von Servern oder (z.B. VMs) erweitert werden muss, ist die Unterstützung von PowerShell oder Kommandozeile (cmd.exe) hilfreich.

Die Vorgehensweise (Ablauf)

Die Erweiterung wird mit den folgenden Schritten durchgeführt.

  1. Deaktivieren von Windows RE
  2. Löschen der Windows Recovery Partition
  3. Erweitern der Systempartition (bis zum Maximum abzüglich 524MB)
  4. Erstellen der neuen Recovery Partition im freien Bereich (524MB) mit NTFS als Dateisystem und ohne Laufwerksbuchstaben
  5. Anpassen der Attribute der neuen Windows Recovery Partition
    – Partition Type = de94bba4-06d1-4d40-a16a-bfd50179d6ac
    – Partition Attribute = 0X8000000000000001
  6. Aktivieren von Windows RE

Achtung, bei MBR-Disks (die ich nicht mehr verwenden würde), lautet der Partition-Type anders, nämlich 27 und nicht de94bba4-06d1-4d40-a16a-bfd50179d6ac.

Die Schritte im Einzelnen

Vor dem ersten Schritt ist es sinnvoll, sich einen Überblick über den Zustand von Windows RE zu verschaffen und dann im Anschluss Windows RE zu deaktivieren.

image

Die grün umrandete Informationen zu Disk und Partition kann über die beiden PowerShell-Befehle Get-Disk und Get-Partition verifiziert werden.

image

Im Gegensatz zu meinem Blog zu beginn, habe ich inzwischen eine Möglichkeit gefunden, die Recovery-Partition mit PowerShell zu löschen.

image

Im Diskmanagement ist danach die Recovery Partition nicht mehr vorhanden.

image

Nun wird die Systempartition (Laufwerk C) auf die maximale Größe, abzüglich des Platzes für die Recovery Partition erweitert.

image

Was im Diskmanagement anschließend wie folgend aussieht. Wir sehen das Laufwerk C mit 195GB und 524MB freiem Platz für die Windows RE Partition.

image

Ok, jetzt die Frage Smile warum wird die Windows RE Partition mit 524MB angelegt, wenn sie doch vor dem Löschen 523MB hatte?

Grob geschätzt habe ich das bestimmt einige hundert Mal gemacht, ein einziges Mal hat Windows RE danach mit einer 523MB großen Partition nicht mehr funktioniert. Eine wirklich gute Analyse konnte ich aus Zeitgründen nicht durchführen. Der Workaround, der funktionierte, war eine Partition mit 524MB statt der ursprünglichen 523MB.

Nun geht es um den Wiederaufbau von Windows RE.

Der verbleibende Platz auf der Disk 0 (524MB) wird nun der neuen Windows RE Partition zugewiesen, darüber hinaus mit NTFS formatiert und kein Laufwerksbuchstabe verwendet.

image

Jetzt müssen wir noch die ID der Windows RE Partition und das GPT-Attribut ändern. Das ist auch der einzige Punkt, wo PowerShell keine Möglichkeit bietet.

Partition Type = de94bba4-06d1-4d40-a16a-bfd50179d6ac
Partition Attribute = 0X8000000000000001

Falls jemand von Euch eine bessere Lösung hat, bitte in die Kommentare schreiben – Danke!

image

Beide Einstellungen können mit diskpart.exe überprüft werden.

image

Sieht gut aus, würde ich sagen.

Fehlt nur noch die Aktivierung von Windows RE, vorher sollte man aber prüfen, ob Winre.wim im Verzeichnis C:\Windows\System32\recovery vorhanden ist.

image

Da Winre.wim eine versteckte Datei ist, wurde der Befehl Get-ChildItem mit der Option -Attributes h ausgeführt. Der Befehl reagentc /enable kopiert dann die Datei auf die Windows RE Partition (was ein paar Sekunden dauert).

Update 08.10.2025 – die Winre.wim fehlt …

Durchaus möglich ist, dass die Windows RE-Datei (Winre.wim) fehlt und damit reagentc das Image nicht auf die neue Recovery-Partition kopieren kann.

image

In diesem Fall empfiehlt sich die folgende Vorgehensweise.

  1. Bereitstellen einer ISO-Datei des entsprechenden Betriebssystems
    – Kopieren der ISO-Datei auf den Server
    – Ein Doppelklick mit dem Windows Explorer mounted das ISO
  2. Erstellen eines Verzeichnisses um die install.wim zu mounten
  3. Mounten der install.wim Datei nach $winDir
  4. Wechsel in das Recovery-Verzeichnis der gemounteten install.wim
  5. Kopieren der Winre.wim nach C:\Windows\System32\Recovery
  6. Aktivierung von Windows RE
  7. Unmount der install.wim

Auch hier die Schritte im Detail

Nach dem Doppelklick mit dem Windows Explorer ist das Windows Server 2022 Image auf Laufwerk G vorhanden.

image

Erstellen eines Verzeichnisses um die install.wim zu mounten und bereitstellen dieser mit dism.exe

image

Wechsel in das Recovery-Verzeichnis der gemounteten install.wim und kopieren der Winre.wim nach C:\Windows\System32\Recovery

image

Jetzt muss noch die Recovery Partition aktiviert (reagentc /enable kopiert die Winre.wim) und die install.wim wieder entfernt werden.

image

So, jetzt aber.

Natürlich gibt es alle Befehle als PowerShell-Datei zum Download.

Enjoy it und happy Recovery, b!

WSUS Reporting auf dem Windows Server 2012R2

Für Windows Server 2012R2 gilt “Oldie but Goldie” und ich muss gestehen, dass ich davon noch einige in Betrieb habe. Die meisten davon als SBE (Windows Server mit der Small Business Essentials Rolle) und damit auch als WSUS tätig.

Hat man nun den WSUS am Laufen, will man bestimmt auch den einen oder anderen Report generieren. Dazu sind eine Reihe Schritte notwendig, die ich im Folgenden erläutern werde.

Ohne konfiguriertes Reporting erscheint die folgende Fehlermeldung (Klick mit der rechten Maustaste auf einen Computer / Status Report), die man durchaus als irreführend bezeichnen kann.

image

Versucht man den Link zu öffnen, erhält man ein freundliches “We’re sorry …”

image

Es geht aber letztendlich doch Smile

Voraussetzungen

Der WSUS muss laufen, dass ist klar und sinnvoller Weise mit der WID (Windows Internal Database) da inzwischen die SUSDB gerne mal die 10GB Grenze knackt und damit der SQL Server Express nicht mehr damit umgehen kann.

  • Installierter und funktionsfähiger WSUS mit WSUS Management MMC
  • SQL Server System CLR Type
  • Microsoft Report Viewer Runtime 2008

Darüber hinaus brauchen wir das .Net Framework 3.5, das entweder über den Servermanager oder PowerShell installiert werden kann.

image

# Anzeige ob das .Net Framework installiert ist oder nicht
Get-WindowsFeature -Name NET-Framework-Core
# Installation des .Net Framework
Install-WindowsFeature Net-Framework-Core -source \\network\share\sxs

Zusätzlich ist die SQL Server System CLR Type notwendig, die es unter dem folgenden Link zum Download gibt

http://go.microsoft.com/fwlink/?LinkID=239644&clcid=0x407

oder hier ausgewählt werden kann:

https://www.microsoft.com/en-us/download/details.aspx?id=56041

Wichtig ist, dass man die richtige SQLSysClrTypes.msi erwischt. Jene die bei mir funktioniert hat war die unten, mit einer Größe von ca. 2,4MB.

image

image

Nachdem Download wird die Runtime mit einem Doppelklick installiert. Jetzt fehlt nur noch die Microsoft Report Viewer Runtime 2008. Hier der Link, direkt bei Microsoft:

https://www.microsoft.com/en-us/download/confirmation.aspx?id=3203

Auch hier, einfach mit einem Doppelklick installieren und fertig ist das Reporting.

image

Damit haben wir ein funktionierendes Reporting des WSUS auf dem Windows Server 2012R2.

image

Enjoy it, b!

Windows Server Essentials Computer Backup Service funktioniert nicht (mehr)

In der Release Documentation for Windows Server Essentials vom 10.03.2021 kündigt Microsoft Pläne an TLS 1.0 und 1.1 zu deaktivieren und TLS 1.2 für den Windows Server Essentials als zukünftigen Standard für eine Absicherung der Kommunikation vorzusehen.

image

Ein Überlesen dieser Information und damit das Versäumnis TLS 1.2 zu aktivieren hatte ja schon im März zu dem Blog über den nicht mehr funktionierenden Zugriff mittels <domain>.remotewebaccess.com geführt.

Nun bin ich auf einem SBE über einen nicht mehr funktionierenden Windows Server Essentials Backup Service gestolpert und dessen Abhängigkeit zu TLS 1.1.

Durch den Startup Type = Automatic sollte der Dienst mit einem Neustart des Servers gestartet werden. Was zwar passierte, aber nach ein paar Minuten war der Dienst nicht mehr aktiv.

image

Ich fasse hier mal die Symptome zusammen:

    • Der Windows Server Essentials Backup Service startet und stoppet im Anschluss wieder
    • Im Eventlog unter Application and Services Logs / Microsoft / Windows / ServerEssentials / Admin haben wir diese Fehlermeldung:Event 270, ServerEssentials
      API name GetTlsServerCredentials


image

Der Fehler sieht danach aus, dass der Service sich nicht Authentifizieren kann.

Weder Microsoft selbst, noch die Suchmaschine(n) meiner Wahl lieferten einen wirklich guten Hinweis auf die API GetTlsServerCredentials. Damit dachte ich mir, ich versuche mal IISCrypto von NARTAC Software um mir die aktuelle Konfiguration anzeigen zu lassen.

image

Auf diesem Server war lediglich Schannel TLS 1.2 (Server / Client Protocols) aktiviert. Ein Vergleich mit einem anderen SBE zeigte aber, dass dieser zusätzlich TLS 1.2, 1.1 und 1.0 aktiviert hatte und auf diesem Server lief der Windows Server Essentials Computer Backup Service.

image

Nach der Aktivierung von TLS 1.1 (und TLS 1.0, siehe Update unten), sowohl Server als auch Clientseitig (Server Protocols / Client Protocols) und einem damit notwendigen Neustart lief auch der Windows Server Essentials Computer Backup Service auf diesem SBE wieder.

image

Es existiert also eine Abhängigkeit zu TLS für den Windows Server Essentials Computer Backup Service. Eine Dokumentation dazu konnte ich nirgendwo finden und diese gewonnene Erkenntnis ist auf einen “educated guess” zurück zu führen, hat aber das Problem gelöst. Alle anderen Services auf dem SBE laufen übrigens mit der TLS 1.2 Einstellung problemlos, nur für den Windows Server Essentials Computer Backup Service ist noch TLS 1.1/1.0 notwendig.

Update 25.06.2021:
Nachvollziehen konnte ich dieses Verhalten sowohl mit Windows Server 2016 als auch mit Windows Server 2012R2, allerdings mit einen Unterschied. Während auf einem Windows Server 2016 der Windows Server Essentials Computer Backup Service mit TLS 1.1 wieder funktioniert hat, benötigte es unter Windows Server 2012R2 TLS 1.0.

Interessant ist, dass mit TLS 1.1 unter Windows Server 2012R2 der Service deutlich länger lief, bevor er mit dem Fehler oben (Event ID 270) sich beendet hat.

Update 29.06.2021:
Mit TLS 1.1 und 1.2 läuft auf dem Windows Server 2016 der Windows Server Essentials Computer Backup Service, aber die Clients verweigern das Backup. Welches nach Aktivierung von TLS 1.0 ebenfalls wieder funktioniert hat.

Zusammenfassend kann ich heute folgendes sagen:

  • Windows Server 2016 und 2012R2 = TLS 1.0, 1.1 und 1.2

Wenn ich nochmals zu neueren Erkenntnisses komme, gibt es dazu wieder ein Update.

Enjoy it, b!

SYSVOL-Migration von FRS auf DFSR

Microsoft empfiehlt schon seit langer Zeit die Replikation des SYSVOL von FRS (File Replication Service) auf DFSR (Distributed File Service Replication) umzustellen. Um genau zu sein, kam diese Empfehlung mit Windows Server 2003R2 🙂 .  Das ist auch sinnvoll, da DFSR stabiler arbeitet und FRS mit dem Windows Server 1709 nicht mehr unterstützt wird.

Ich habe dann eine Reihe meiner Small Business Domains durchgeschaut und noch eine gefunden in dieser FRS zur Replikation verwendet wird. Das ist immer dann der Fall, wenn von sehr alten Versionen (hier ein Windows Server 2000 basiertes Active Directory) immer wieder auf neue Versionen migriert wurde. Die Historie in dieser Domain ist:

  • Windows Server 2000
  • Windows Server 2003
  • Windows Server 2008
  • Windows Server 2012R2

In Domains mit nur einem Domain Controller (DC), wie das bei dem Small Business Server oder Small Business Essentiales üblich ist, kommt es in der Regel zu fast keinen Problemen mit der Replikation. Denn es gibt nur einen DC, das bedeutet aber nicht das hier keine Replikation stattfindet, sondern dass der Server in der Regel sich selbst immer erreichen kann.

FRS oder DFSR?

Wie stellt man überhaupt fest, ob innerhalb des Active Directory (AD) mit FRS oder DFSR repliziert wird? Das kann über mehrere Möglichkeiten herausgefunden werden.

Im Ereignis-Protokoll auf einem (in einer SBS/SBE Domain auf dem einem) DC sind aktuelle Einträge vorhanden.

image

Im DFS Management wird KEINE Gruppe angzeigt, wie im folgenden Bild zu sehen ist. Darunter das Domain System Volume wenn auf DFSR umgestellt wurde.

FRS (File Replication Service)

image

DFSR (Distributed File System Replication)

image

Voraussetzungen

Damit eine Migration ohne Probleme läuft, sollten ein paar Bedingungen im Vorfeld erfüllt sein.

FRS muss fehlerfrei arbeiten, dass kann man gleich prüfen wenn man einen Blick in das Ereignisprotokoll des FRS wirft

Bei mehreren DC, erstelle ich eine Datei im NETLOGON-Verzeichnis und schaue ob diese auf den anderen DCs zeitnah auftaucht.

C:\Temp> echo "Test" > \Windows\SYSVOL\domain\scripts\test.txt

Zusätzlich muss die Domain im Domain-Mode mindestens auf Windows Server 2008 laufen.

image

Das kann mit PowerShell und Get-ADDomain geprüft werden.

# Den Befehl als Administraor in einer PowerShell-Sitzung ausführen
(Get-ADDomain).DomainMode
Windows2012R2Domain

Nun können wir die Migration starten.

Migration von FRS auf DFSR

Bevor die Migration gestartet wird mache ich, wenn nur ein einziger DC vorhanden und dieser virtualisiert ist, einen SnapShot. Darüber hinaus ist ein aktuelles Backup obligatorisch.

image

Bei einem Snapshot (oder Checkpoint) ist es wichtig, dass falls dieser in Anspruch genommen wird, alle Daten die seit dem Checkpoint erstellt wurden verloren gehen. Darum ist eine Migration des SYSVOL etwas fürs Wochenende.

Die Migration selbst erfolgt mit dem Tool dfsrmig.exe das in einer, als Administrator gestarteten CMD- oder PowerShell-Sitzung auf dem DC ausgeführt wird, der die PDC-Emulator Rolle besitzt. Bei nur einem Server / DC ist die Rollenverteilung klar, ansonsten kann diese wie folgt mit PowerShell geprüft werden.

# Den Befehl als Administrator in einer PowerShell-Sitzung ausführen
(Get-ADDomain).PDCEmulator
mt-sbs-1.DOMAIN.local

Wird nur Get-ADDomain verwendet, findet man den PDC-Emulator hier.

image

Die Migration selbst verläuft in vier Stufen mit dem folgenden Status von 0 … 3, die Informatik beginnt halt gerne bei 0 Smile

Status Start 0

Mit dfsrmig /setGlobalState 0 werden die Domain Controller auf Start gesetzt und die Migration kann beginnen.

# Den Befehl als Administrator in einer PowerShell-Sitzung ausführen
dfsrmig /setGlobalState 0

Die Meldung Invalid state change requested, rührt daher das auf diesem DC der Befehl schon im Vorfeld abgesetzt wurde und dieser sich schon im Status Start befindet.

image

Kontrollieren, ob alle DC sich final im Status Start befinden kann und sollte man mit dfsrmig /GetMigrationState.

# Den Befehl als Administrator in einer PowerShell-Sitzung ausführen
dfsrmig /GetMigrationState

image

Bei mehreren DCs kann das schon seine Zeit dauern, letzte Woche habe ich bei zwei Servern ca. 10min gewartet bis dieser Status erreicht war. Hier ist ein wenig Geduld angebracht.

Status Prepared (Vorbereitet) 1

Mit dfsrmig /setGlobalState 1 wird nun im nächsten Schritt der DC in den Status Prepared versetzt und mit dfsrmig /GetMigrationState kann der Status wiederholt abgefragt werden.

# Den Befehl als Administrator in einer PowerShell-Sitzung ausführen
dfsrmig /setGlobalState 1

Wie im folgenden Bild zu sehen ist, benötigt auch ein einzelner DC seine Zeit. Dazu einfach einen Kaffee holen und mit dfsrmig /GetMigrationState den Status abfragen.

image

Status Redirected (Umgeleitet) 2

Mit dfsrmig /setGlobalState 2 wird nun die Phase 2 eingeleitet und alle DC in den Status Redirected gesetzt, was ebenfalls seine Zeit dauern kann.

# Den Befehl als Administrator in einer PowerShell-Sitzung ausführen
dfsrmig /setGlobalState 2

Natürlich liefert dfsrmig /GetMigrationState den aktuellen Zustand.

image

Damit ist die Phase 2 beendet und wir können uns der Phase 3 zuwenden und die Migration damit abschließen.

Status Eliminated (Entfernt) 3

Mit dfsrmig /setGlobalState 3 wird nun die Phase 3 und damit der Abschluss der Migration eingeleitet und alle DCs in den Status Eliminated gesetzt.

# Den Befehl als Administrator in einer PowerShell-Sitzung ausführen
dfsrmig /setGlobalState 3

Wie schon vorher liefert dfsrmig /GetMigrationState den Zustand und Status der Migration, im folgenden Bild waren wir nach gut 2min fertig.

image

So nun sind wir fertig, alle vier Schritte / Phasen sind durch.

Wie kontrollieren wir nun, ob alles sauber läuft?

Vertrauen ist gut, Kontrolle ist besser

Im DFS Management wird nun das Domain System Volume angezeigt und man kann es auch als Replikationsgruppe hinzufügen.

image

Dort sehen wir auch den migrierten SYSVOL-Ordner.

image

Zusätzlich verabschiedet sich der FRS mit einem “letzten” Eintrag im Ereignisprotokoll.

image

Im DFS Replication Ereignisprotokoll finden wir ebenfalls einen Eintrag, dass nun mit DFSR repliziert wird.

image

Bei mehr als einem Domain Controller, erstelle ich immer eine Datei im NETLOGON-Verzeichnis und schaue ob diese repliziert wird. Das Verzeichnis heißt ja nun auch nicht mehr SYSVOL, sondern SYSVOL_DFSR.

image

Wird nun ein weiterer DC hinzugefügt, dann verwendet dieser wie vor das Verzeichnis SYSVOL.

image

Die beiden ersten Server wurden „migriert” und der letzte in der Liste (blau umrandet) wurde nach der Migration hinzugefügt.

Enjoy it, b!

GPO Error "Resource $(string id="Win7Only)‘

Die Fehlermeldung lautet wie folgt und erscheint bei der Anzeige der Settings / Einstellungen einer GPO.

Error "Resource $(string id="Win7Only)' referenced in attribute displayName could not be found" when opening gpedit.msc in Windows

Im GPO-Management wird der Fehler wie folgt angezeigt.

image

Microsoft selbst, kennt den Fehler auch und liefert in diesem KB-Artikel die Lösung, bzw. einen Workaround wie man den Fehler beheben kann.

https://support.microsoft.com/en-us/help/4292332/error-when-you-open-gpedit-msc-in-windows

Der Fehler ist bei mir aufgetreten, nachdem ich eine auf Windows Server 2012 R2 laufende Domain für Windows Hello vorbereiten wollte, dazu gehört auch das Aktualisieren der ADMX-Dateien.

Da ich schon die aktuellen ADMX-Dateien eingespielt hatte, hier geht es zu den Windows 10 ADMX-Dateien für Version 2004, blieb mir nur die Möglichkeit die ADML-Datei zu editieren. Das kann man entweder mit Notepad oder mit Notepad++ machen.

Dazu habe ich die folgenden Schritte durchgeführt.

Erstellen eines Backups für die SearchOCR.adml Datei im folgenden Ordner:

C:\Windows\SYSVOL\domain\Policies\PolicyDefinitions\en-US

Das geht am einfachsten in einer Eingabeaufforderung oder in PowerShell mit xcopy, wobei beide Sitzungen mit erweiterten Adminrechten gestartet werden müssen.

C:\Windows\SYSVOL\domain\Policies\PolicyDefinitions\en-US
# Wechsel in der Verzeichnis mit den PolicyDefinitions der jeweiligen Sprache
C:\Windows\SYSVOL\domain\Policies\PolicyDefinitions\en-US
# Sichern der alten Datei mit dem Namen searchocr.adml durch xcopy
xcopy searchocr.adml \temp

Dann wird mit dem Editor eine Leerzeile in Zeile 26 eingefügt, und in diese leere Zeile der folgende String kopiert.

# Einfügen des folgenden Strings in Zeile 26"
Microsoft Windows 7 or later

Im Editor sieht das dann wie folgt aus.

image

Danach ist die Fehlermeldung verschwunden und die GPO-Einstellungen werden korrekt angezeigt.

Enjoy it, b!

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!

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!

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!

Windows Task Scheduler 2147942667

Der Windows Task Scheduler versteht bei der Konfiguration seiner Aktionen (Action) keinen Spaß, dass Quotieren eines Pfades mit Anführungszeichen führt beim Versuch der Ausführung zu einem Fehler 2147942667. Das der Task Scheduler mit Anführungszeichen so seine Probleme hat, ist eigentlich ein altes Problem.

Hier das Problem im Detail, das in meinem Fall auf einem Windows Server 2012R2 aufgetreten ist.

"C:\Program Files\Scripts"

image

Hier dazu den Lösung, also das Weglassen der Anführungszeichen.

C:\Program Files\Scripts

image

Damit läuft dann auch der Task ohne Probleme.

Enjoy it, b!

Installation von KB3000850 auf Windows Server 2012 R2 schlägt fehl …

Alle die meinen Blog verfolgen, wissen – der WSUS und ich haben ein schwieriges Verhältnis … zumindest wollte mir dieser partout nicht der Update Windows8.1-KB3014442-x64.msu zur Installation anbieten, welches neben Windows8.1-KB3016437-x64.msu und dem Windows8.1-KB3003057-x64 die Voraussetzung für Windows8.1-KB3000850-x64 darstellt.

Die Vorgehensweise ist eigentlich immer die gleiche, zu erst auf der Microsoft Webseite nach dem Update suchen, welches fehl schlägt. Dann werden hier manchmal weitere Updates im gleichen Download mit angeboten. Hier einfach alle Updates runter laden und probieren welche sich installieren lassen. Bei mir waren alle drauf, mit Ausnahme von KB3014442-x64.msu und der scheint die Grundlage für Windows8.1-KB3000850-x64.msu zu sein.

image

Danach hat es problemlos funktioniert Smile

 

Enjoy it, b!