Windows CA: Zertifikatsregistrierungs-Webdienst lässt sich nah Migration nicht installieren (Configuration Failed 0x80070057 (WIN32: 87))

Wenn man eine Windows CA erfolgreich migriert hat (Backup+Restore), kommt beim Versuch den CertSvc-Webdienst via ServerManger zu installieren die folgende Fehlermeldung:

Webregistrierung der Zertifizierungsstelle: Konfiguration fehlgeschlagen.
Die Einrichtung der Active Directory-Zertifikatdienste ist mit folgendem Fehler fehlgeschlagen: Der Parameter ist falsch. 0x80070057 (WIN32: 87)

Das passiert nach einer Migration und auch nur mit dem Webdienst – den man korrekterweise erst nach der CA „dazuinstalliert“. Natürlich ist das ein bekannter und bisher (Windows Server 2003-2022) ungepatchter Bug.

Lösung

Das Problem besteht darin, dass der Wert von SetupStatus in der Registry unter HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration noch den Wert „hat“Web ist installiert“ hat. Wenn das der Fall ist, scheitert der Windows ServerManager.

Der Hexadezimalwert 6003 sagt „ist schon installiert“
Der Hexadezimalwert 6001 sgat „ist frei“

Man ändere also mal eben den Wert von SetupStatus der Registrierung auf 6001 und dann läuft die Installation des „Zertifikatsregistrierungs-Webdienstes“ durch.

Update

Ich habe soeben herausgefunden, das das sogar an der Kommandozeile vie certutil möglich ist:

certutil -setreg config\setupstatus 0x6001

Es wird noch besser, es gibt sogar eine named procedure in certutil dazu, die ebenfalls genau das selbe tut:

certutil -setreg config\setupstatus - SETUP_CLIENT_FLAG

Exchange EventID 1006 (MSExchangeDiagnostics) „Event Dispatchers Catching Up“

Auf Exchange Servern seit 2010 wird gerne mal dieses Ereignis alle paar Minuten in das Anwendungsprotokoll geschrieben:

The performance counter '\\EXCHANGESERVER\MSExchange Assistants - Per Database(msexchangemailboxassistants-DATABASE)\Quarantined Assistant Count Total' sustained a value of '6.015,00', for the '10' minute(s) interval starting at '10.10.2020 12:00:00'. Threshold breached since '10.10.2020 21:12'. None Trigger Name:AssistantsQuarantinedTrigger. Instance:msexchangemailboxassistants-DATABASE

Oder auch mit etwas längerem Intervall:

The performance counter ‚\\EXCHANGESERVER\MSExchange Assistants – Per Database(msexchangemailboxassistants-DATABASE)\Event Dispatchers Catching Up‘ sustained a value of ‚2.730,00‘, for the ’30‘ minute(s) interval starting at ‚10.10.2020 19:39:00‘. Threshold breached since ‚10.10.2020 20:10‘. None Trigger Name:EventDispatchersCatchupQueueTrigger. Instance:msexchangemailboxassistants-DATABASE

Lösung

Das ist ein Fehler, den es in vielen Setup auch schon unter Exchange 2013 gab (Exchange 2016 hat das genauso). Es gibt für beide einen Workaround um die nervigen Fehler-Einträge loszuwerden.

Im Verzeichnis Microsoft\Exchange\Vxxx\BIN (Powershell: $exinstall\bin) findet sich die Datei Microsoft.Exchange.Diagnostics.Service.exe mit der zugehörigen *.config Datei:

Microsoft.Exchange.Diagnostics.Service.exe.config

Diese „als Admin“ bearbeiten. Darin muss nur ein Trigger auf „false“ geändert werden, und zwar diese Zeile:

<add Name="Microsoft.Exchange.Diagnostics.Service.ExchangeJobs.Triggers.EventDispatchersCatchupQueueTrigger" Assembly="Microsoft.Exchange.Diagnostics.Service.ExchangeJobs.dll" Enabled="True" Role="Mailbox" />

in diese:

<add Name="Microsoft.Exchange.Diagnostics.Service.ExchangeJobs.Triggers.EventDispatchersCatchupQueueTrigger" Assembly="Microsoft.Exchange.Diagnostics.Service.ExchangeJobs.dll" Enabled="False" Role="Mailbox" />

Das ist in der Regel so um die Zeile 1440 herum. Danach startet man den MSExchangeDiagnostics Dienst neu und ist die Meldung los.

sc restart MSExchangeDiagnostics

Windows 10/11 und Windows Server „Automatische Reparatur“ vollständig abschalten

Windows 10/11 und Windows Server meinen es eigentlich gut, wenn Sie nach jeweils zwei „unerwarteten Neustarts“ (z.B. Strom aus) in die „Automatische Reparaturumgebung“ booten, anstatt das eigentlich Betriebssystem zu starten. Die Automatische Reparatur kann man zwir überspringen, aber nur wenn man eine Taste drücke.

Im Prinzip eine nette Idee, denn bei plötzlichen Stromausfällen könnte ja das Dateisystem beschädigt worden sein.

Manchmal braucht man aber ein System, das IMMER bootet. Beispielsweise für POS-Geräte die nur Informationen anzeigen sollen oder Geräte die gar keine Tastatur angeschlossen haben. Solche Geräte werden gerne öfter mal „hart“ ohne „herunterfahren“ ausgeschaltet und starten dann nicht mehr alleine.

Lösung

Um den freundlichen „Automatic Repair“ Assistenten vollständig loszuwerden, sind mehrere Schritte notwendig. Alles natürlich an der Administrator („Als Admin“) CMD Kommandozeile.

1. Die WinRE Umgebung komplett abschalten

reagentc /disable

2. Ruhezustand („Fastboot“) grundsätzlich abschalten

powercfg -h off

3. Die Recovery-Umgebung im Windows Bootlaufwerk abschalten
{current} ist dabei die Windows-Installation um die es geht. Eine Liste aller Installationen gibt bcdedit aus.

bcdedit /set {current} recoveryenabled no

4. Alle Startfehler beim booten ignorieren (auch das „dirty“ flag von NTFS)

bcdedit /set {current} bootstatuspolicy IgnoreAllFailures

Ab jetzt startet die Reparaturumgebung wirklich nicht mehr und man benötigt einen bootfähigen USB-Stick um das System im ernstfall zu prüfen.

Schnell große Dateien an der Windows Kommandozeile erstellen

Manchmal braucht mal „auf die Schnelle“ eine Testdatei. Sei es um Fileserver zu testen, Netzwerkverbindungen auszulasten oder ein Dateisystem zu stressen.

Der schnellste bekannte Weg große Dateien zu erstellen ist mit dem Tool fsutil. Das geht an der CMD-Shell und natürlich auch in der PowerShell.

Lösung

fsutil file createnew <DATEINAME> <GROESSE>

Die Größe wird dabei in bytes angegeben.

Beispiele

fsutil file createnew 01MB-TESTDATEI.TEST 1048576

fsutil file createnew 01GB-TESTDATEI.TEST 1073741824

fsutil file createnew 05GB-TESTDATEI.TEST 5368709120

fsutil file createnew 10GB-TESTDATEI.TEST 10737418240

Falls man Probleme hat MB/MiB, KB/KiB und so weiter auseinanderzuhalten, es gibt da ein wundervolles XKCD das einiges erklärt 🙂

Microsoft Word öffnet eine Datei nicht: „Fehler beim Öffnen der Datei in Word Versuchen Sie Folgendes: …“

In letzter Zeit gab es ein paar Anfragen, das Word „plötzlich“ Datein nicht mehr freiwillig öffnen will. Das passiert hauptsächlich bei sehr großen Dateien mit komplexen Inhalten. Naja, Word ist halt eine Textverarbeitung und keine DTP-Publishingsoftware …

Beim Doppleklick errscheint die Fehlermeldung

Fehler beim Öffnen der Datei in Word
Versuchen Sie Folgendes:

* Überprüfen Sie die Dateiberechtigungen für das Dokument oder Laufwerk
* Stellen Sie sicher, dass genügend Arbeitsspeicher oder Speicherplatz vorhanden ist
* Öffnen Sie die Datei mit dem Wiederherstellen-Textkonverter (Dateiname)

… und die Datei wird nicht geöffenet. Es passiert einfach gar nichts.

Lösung

Solche Dokumente lassen sich meist problemlos in Word Online öffnen. Das zerhackt zwar das Layout, aber rettet immerhin die Texte.

Besser ist es, das Dokument im „reparieren“ Modus von Word zu öffnen. Im Schlimmsten Fall verliert man eine Formatierung oder einen Absatz, aber in der Regel bleibt das Dokument praktisch vollständig erhalten.

Das geht innerhalb von Word mit Datei>Öffnen>Datei, dann die Datei wählen und NICHT öffnen, sondern auf sondern den kleinen Pfeil daneben klicken wo man dann „Öffnen und Reparieren“ auswählen kann.

Word repariert dann fiese Fehler und listet auch auf, was alles repariert wurde.

In dem Fenster kann man tehoretisch auch mit „Gehe zu“ direkt zu den Fehlern hinspringen, aber das klappt nicht immer. Meisten springt die Eingabe ganz an Ende des Dokuments. Jetzt kann man die Inhalte einfach in ein neues Dokuemnt übernehmen und wieder „sauber“ speichern.