ugg.li Schnelle Hilfe für schnelle Admins
Nicht immer schön, aber effektiv. Schnelle Hilfe für schnelle Admins.
Das Microsoft Windows Server 2012 R2 seit dem 10. Oktober diesen Jahres wirklich am Support-Ende angekommen ist, ist nicht neu. ESU natürlich ausgenommen, die Installationsbasis ist ja immer noch relativ groß.
Neu ist, zumindest für uns, aber die eindringliche „Sicherheitsempfehlung“ im Defender-Portal, das Betriebssystem schlicht zu deinstallieren 😂
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.
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.
Ich habe soeben herausgefunden, das das sogar an der Kommandozeile vie certutil möglich ist:
certutil -setreg config\setupstatus 0x6001Es 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
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.
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 /disable2. Ruhezustand („Fastboot“) grundsätzlich abschalten
powercfg -h off3. 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 no4. Alle Startfehler beim booten ignorieren (auch das „dirty“ flag von NTFS)
bcdedit /set {current} bootstatuspolicy IgnoreAllFailuresAb jetzt startet die Reparaturumgebung wirklich nicht mehr und man benötigt einen bootfähigen USB-Stick um das System im ernstfall zu prüfen.
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.
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 🙂
Zertifikate sind eigentlich vom Ablaufverständnis her einfach – aus privatem Teil und öffentlichem Teil kann man ein PFX erzeugen, das sich für dem schnellen Import in Windows-Server eignet. Der Weg über einen bestehenden PK ist deutlich einfacher und schneller als ein neues CSR mit neuem PK und ein neuer Signierungsvorgang.
(Wenn möglich sollte aber natürlich ein neuer Key bevorzugt werden.)
openssl pkcs12 -in EXAMPLE.pfx -nocerts -out EXAMPLE.keyNach der Kennworteingabe für die Extraktion und der Kennworteingabe für die verschlüsselte Ablage des Keys liegt die EXAMPLE.key Datei vor.
openssl.exe pkcs12 -export -out EXAMPLE-NEU.pfx -inkey EXAMPLE-PRIVATE-KEY.key -in EXAMPLE-CERTIFICATE.cerWenn die CA mehrere Intermediate Zertifikate und/oder ihre eigene Root-CA Zertifikate als eigene Dateien mitliefert, kann man diese mit mehreren -in Parametern in das PFX auch gleich mit einpacken (die Kette sollte in der richtigen Reihenfolge, angefangen mit dem Root-CA-Zertifikat angegeben werden):
openssl.exe pkcs12 -export -out EXAMPLE-NEU.pfx -inkey EXAMPLE-PRIVATE-KEY.key -in EXAMPLE-RootCA.cer -in EXAMPLE-CA.crt -in EXAMPLE-CERTIFICATE.crtAlternativ kann auch eine CA-Kette in einer Datei mit dem Parameter -certfile verwendet werden:
openssl.exe pkcs12 -export -out EXAMPLE-NEU.pfx -inkey EXAMPLE-PRIVATE-KEY.key -in EXAMPLE-CERTIFICATE.crt -certfile CA-CHAIN.cer