BitLocker-Schutz für das Systemlaufwerk anhalten, Computer neustarten und den BitLocker-Schutz wieder fortsetzen
Aktueller Stand:
Hallo miteinander,
ab und zu passiert es mal, dass der BitLocker nach einem System-Neustart nicht nur wie gewöhnlich
1. den TMP-Schlüssel
2. den Wiederherstellungsschlüssel von einem USB-Stick und
3. und die PIN
abfragt, sondern verlangt danach stur nach dem Wiederherstellungskennwort (das aus 8 Blöcken zu je 6 Zahlen besteht)! Jeder Anwender, der BitLocker bereits verwendet, weiss wohl, wie umständlich es ist so ein extrem langes Kennwort von 48 Zahlen einzugeben. Insbesondere ist so ein Fall während einer Reise unangenehm.
Warum BitLocker ab und zu das lange Kennwort abfragt, hängt vor allem damit zusammen, dass ein Teil des gesamten Systems gestern, vorgestern oder wann auch immer wieder durch irgendwelchen Prozeduren aktualisiert worden war, was im heutigen Alltag fast nicht vermeidbar ist.
Aus meiner Sicht ist es nicht logisch, dass BitLocker im Falle einer Integritätsverletzung selbst dann nach dem Wiederherstellungskennwort verlangt, wenn der Anwender „gezielt“ ein System-Neustart durchführt, weil die System-Integrität in keiner Weise schlechter geworden ist, als vor dem Neustart. Der Schutz ist vor allem gegen Manipulationen vor dem Start des OSs gedacht (bei einem gezielten Neustart durch Anwender, darf aus meiner Sicht von diesem Schutzmechanismus kurzzeitig verzichtet werden).
Für diejenigen, welche den BitLocker-Schutz benutzen und ebenso nach einem Neustart ab und zu überraschend das BitLocker-Wiederherstellungskennwort eingeben müssen, können ab nun das nachfolgende Batch-Skript benutzen, um einen etwas speziellen Neustart wie folgt durchzuführen:
Den BitLocker-Schutz für das Systemlaufwerk anhalten, den Computer neustarten und den BitLocker-Schutz wieder fortsetzen
Das nachfolgende Skript z. B. als „Computer neustarten (BitLocker für das Systemlaufwerk anhalten und nach Neustart fortsetzen)“ mit der Erweiterung .bat bzw. .cmd speichern.
Verbesserungsvorschläge sind wie immer gerne willkommen und werden hier gerne umgesetzt.
Viel Erfolg
Gruß
evinben
BitLocker-Version: Windows 7
Eingesetzte Schlüsselschutzvorrichtungen für das Systemlaufwerk:
Eingesetzte Schlüsselschutzvorrichtungen für das Systemlaufwerk:
- TPM und PIN und Startschlüssel (die Startschlüssel-Datei ist auf einem USB-Stick abgelegt)
- Numerisches Kennwort
Hallo miteinander,
ab und zu passiert es mal, dass der BitLocker nach einem System-Neustart nicht nur wie gewöhnlich
1. den TMP-Schlüssel
2. den Wiederherstellungsschlüssel von einem USB-Stick und
3. und die PIN
abfragt, sondern verlangt danach stur nach dem Wiederherstellungskennwort (das aus 8 Blöcken zu je 6 Zahlen besteht)! Jeder Anwender, der BitLocker bereits verwendet, weiss wohl, wie umständlich es ist so ein extrem langes Kennwort von 48 Zahlen einzugeben. Insbesondere ist so ein Fall während einer Reise unangenehm.
Warum BitLocker ab und zu das lange Kennwort abfragt, hängt vor allem damit zusammen, dass ein Teil des gesamten Systems gestern, vorgestern oder wann auch immer wieder durch irgendwelchen Prozeduren aktualisiert worden war, was im heutigen Alltag fast nicht vermeidbar ist.
Aus meiner Sicht ist es nicht logisch, dass BitLocker im Falle einer Integritätsverletzung selbst dann nach dem Wiederherstellungskennwort verlangt, wenn der Anwender „gezielt“ ein System-Neustart durchführt, weil die System-Integrität in keiner Weise schlechter geworden ist, als vor dem Neustart. Der Schutz ist vor allem gegen Manipulationen vor dem Start des OSs gedacht (bei einem gezielten Neustart durch Anwender, darf aus meiner Sicht von diesem Schutzmechanismus kurzzeitig verzichtet werden).
Für diejenigen, welche den BitLocker-Schutz benutzen und ebenso nach einem Neustart ab und zu überraschend das BitLocker-Wiederherstellungskennwort eingeben müssen, können ab nun das nachfolgende Batch-Skript benutzen, um einen etwas speziellen Neustart wie folgt durchzuführen:
Den BitLocker-Schutz für das Systemlaufwerk anhalten, den Computer neustarten und den BitLocker-Schutz wieder fortsetzen
Das nachfolgende Skript z. B. als „Computer neustarten (BitLocker für das Systemlaufwerk anhalten und nach Neustart fortsetzen)“ mit der Erweiterung .bat bzw. .cmd speichern.
Verbesserungsvorschläge sind wie immer gerne willkommen und werden hier gerne umgesetzt.
Viel Erfolg
Gruß
evinben
:BitLocker-Schutz für das Systemlaufwerk anhalten, Computer neustarten und den BitLocker-Schutz wieder fortsetzen
:Getestet unter Windows 7 Ultimate, 32-Bit
@echo off
@prompt -$G
chcp 1252 >nul
:PushD %~dp0
echo.
:=================================
:RunAs Administrator
:=================================
set Arguments=%*
:Wenn mind. ein Argument übergeben worden ist, dann die Anführungszeichen verdoppeln.
if defined Arguments set "Arguments=%Arguments:"=""%"
:echo %Arguments%
:--------------------------------------
:Check for permissions
>nul 2>&1 "%SYSTEMROOT%\system32\cacls.exe" "%SYSTEMROOT%\system32\config\system" && goto :gotAdmin
echo Administrator-Rechte anfordern...
:Write the name from the user witch have first executet the file (prior the UAC request)
>"%temp%\getadmin.vbs" echo 'ExecutedUnderContexFromUser: %UserName%
:Argumente in VB-Script mit 2x doppelten Anführungszeichen umrahmen: ""Ar1"" ""Arg2"" ...
>>"%temp%\getadmin.vbs" echo CreateObject("Shell.Application").ShellExecute "%ComSpec%"," /c "" ""%~f0"" %Arguments% "" ",,"runas",1
"%temp%\getadmin.vbs"
exit /b
:gotAdmin
:--------------------------------------
:Den Benutzer anzeigen, unter dessen Kontext diese Batch-Datei zuerst ausgeführt worden ist:
for /f "tokens=2* delims=: " %%d in ('findstr "ExecutedUnderContexFromUser" "%temp%\getadmin.vbs"') do set ExecutedUnderContexFromUser=%%d
:echo Ausgeführt zuerst vom Benutzer: %ExecutedUnderContexFromUser%
if exist "%temp%\getadmin.vbs" del "%temp%\getadmin.vbs"
:=================================
:Execute code
:=================================
:BitLocker-Schutz-Status für das Laufwerk abfragen
:(bei der Statusabfrage gibt der Parameter {-protectionaserrorlevel | -p} den Errorlevel 0, wenn
:das Volume geschützt ist, und andersrum den Errorlevel -1 zurück).
manage-bde -status %SystemDrive% -protectionaserrorlevel>nul
if not %Errorlevel%==0 (
cls
echo.
echo ###############################################################################
echo # WARNUNG: #
echo # Der Bit-Locker-Schutz ist auf dem Laufwerk %SystemDrive% nicht aktiv. #
echo # Der geplante Schutz wird nach einem Neustart nicht automatisch fortgesetzt! #
echo ###############################################################################
pause >nul
goto :eof
)
:BitLocker für das Systemlaufwerk anhalten.
manage-bde -protectors -disable %SystemDrive%
:BitLocker-Schutz für das Systemlaufwerk fortsetzen
set TaskName=Bitlocker-Schutz für das Systemlaufwerk fortsetzen
set ScriptPath=%SystemDrive%\Windows\Temp\%TaskName%.bat
:temporäres Skript erstellen, welches nach Neustart ausgeführt werden soll
echo @echo off>"%ScriptPath%"
echo echo BitLocker-Schutz für das Systemlaufwerk wird wieder fortgesetzt>>"%ScriptPath%"
echo chcp 1252 ^>nul>>"%ScriptPath%"
echo manage-bde -protectors -enable %SystemDrive%>>"%ScriptPath%"
:BitLocker-Status aktualisieren (Entfernt die alte Warnung von BitLocker im Infobereich - auf der Taskleiste rechts. Wenn der BitLocker-Schutz
:das nächste Mal via GUI angehalten oder fortgesetzt wird, wird der aktuelle Status weiterhin problemlos angezeigt.)
echo taskkill.exe /IM fvenotify.exe>>"%ScriptPath%"
echo start "" fvenotify.exe>>"%ScriptPath%"
echo del "%ScriptPath%">>"%ScriptPath%"
:In der Registry eintragen, dass das Skript beim Anmelden (durch einen beliebiegen Anwender) automatisch ausgeführt werden muss
:Das "!"-Zeichen im Namen des Wertes sorgt hierfür, dass der Wert erst nur dann aus dem Registry-Schlüssel gelöscht wird,
:wenn sein Befehl vollständig ausgeführt ist.
reg add "HKLM\Software\Microsoft\Windows\CurrentVersion\RunOnce" /v "!%TaskName%" /t REG_SZ /d "\"%ScriptPath%\"" /f
:Computer herunterfahren und neustarten (/t 0 = sofortiges Herunterfahren)
shutdown /r /t 0 /d p:0:0 /c "Der Computer wird neugestartet"
echo.
echo Fals der Computer-Neustart aus irgendwelchen Gründen doch nicht erfolgen wird, dann wird der BitLocker-Schutz für das Systemlaufwerk in 60 Sekunden wieder fortgesetzt.
timeout /t 60
manage-bde -protectors -enable %SystemDrive%
timeout /t 3 >nul
:pause >nul
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 228441
Url: https://administrator.de/contentid/228441
Ausgedruckt am: 24.11.2024 um 12:11 Uhr
21 Kommentare
Neuester Kommentar
Moin,
was mir aufgefallen ist, was bei dir möglicherweise zu Problemen führen könnte, wenn das Laufwerk gar nicht verschlüsselt ist.
Meine Lösung zu dem Problem war folgende:
Ja, ich habe selbst so einen Script schonmal geschrieben, da ich BIOS Settings ändern musste (Bootreihenfolge).
Ich glaube aber, dass du das selbe Problem hast, wie wir damals: Schau mal nach deiner Bootreihenfolge, ich nehme an, du hast einen PXE-Boot oder DVD-Laufwerk vorgeschaltet? Das führte bei uns Laut MS zu diesem Fehler, deswegen schrieb ich einen ähnlichen Script.
Ich frage mich nur, wie du denn Script präventiv einsetzen willst, wenn du einen Reboot machen musst. Denn der Bitlocker schaut eigentlich mithilfe von TPM nach Änderungen an der Hardware und BIOS Settings und schlägt daraufhin mit dem Recovery-Key Alarm, aber sonst ist da eher weniger los. Ich kann bisher sagen, das 1-2 Anrufe wegen Recovery-Keys im Monat bei 1200 Usern normal sind. Und selbst dann, reicht meist ein Kaltstart um das Gerät zur Vernunft zu bringen. Sonst hat man eher einen Indikator für einen Hardwaredefekt, wenn er wirklich anschlägt und keine Ruhe gibt.
Gruß
Chris
was mir aufgefallen ist, was bei dir möglicherweise zu Problemen führen könnte, wenn das Laufwerk gar nicht verschlüsselt ist.
Meine Lösung zu dem Problem war folgende:
manage-bde.exe -status > bitlocker_pxe.log
find /I " Protection Status: Protection On" "bitlocker_pxe.log"
If %errorlevel% EQU 0 goto :bde_stop
Ja, ich habe selbst so einen Script schonmal geschrieben, da ich BIOS Settings ändern musste (Bootreihenfolge).
Ich glaube aber, dass du das selbe Problem hast, wie wir damals: Schau mal nach deiner Bootreihenfolge, ich nehme an, du hast einen PXE-Boot oder DVD-Laufwerk vorgeschaltet? Das führte bei uns Laut MS zu diesem Fehler, deswegen schrieb ich einen ähnlichen Script.
Ich frage mich nur, wie du denn Script präventiv einsetzen willst, wenn du einen Reboot machen musst. Denn der Bitlocker schaut eigentlich mithilfe von TPM nach Änderungen an der Hardware und BIOS Settings und schlägt daraufhin mit dem Recovery-Key Alarm, aber sonst ist da eher weniger los. Ich kann bisher sagen, das 1-2 Anrufe wegen Recovery-Keys im Monat bei 1200 Usern normal sind. Und selbst dann, reicht meist ein Kaltstart um das Gerät zur Vernunft zu bringen. Sonst hat man eher einen Indikator für einen Hardwaredefekt, wenn er wirklich anschlägt und keine Ruhe gibt.
Gruß
Chris
Moin,
er meint, dass dein echo in die Batchdatei einen Fehler hervorruft (, weil "BitLocker-Schutz" kein Befehl ist), eigentlich müsste es wie folgt lauten:
Das ist alles, schließlich soll das ja ausgegeben werden.
Gruß
Chris
er meint, dass dein echo in die Batchdatei einen Fehler hervorruft (, weil "BitLocker-Schutz" kein Befehl ist), eigentlich müsste es wie folgt lauten:
echo echo BitLocker-Schutz für das Systemlaufwerk wird wieder fortgesetzt>>"%ScriptPath%"
Das ist alles, schließlich soll das ja ausgegeben werden.
Gruß
Chris
Moin,
so wie ich das hier gerade sehe, wird sich da nicht so viel tun, denn wie gesagt, bei uns war es einfach der PXE Boot. Wir haben dann ausschließlich die Boot-Reihenfolge verändert also die interne HDD an erste Stelle gelegt und das Problem war weg. Da das aber bei dir schon der Fall ist, wird sich da nicht all zu viel verbessern. Naja, die Hoffnung stirb zuletzt
Gruß
Chris
so wie ich das hier gerade sehe, wird sich da nicht so viel tun, denn wie gesagt, bei uns war es einfach der PXE Boot. Wir haben dann ausschließlich die Boot-Reihenfolge verändert also die interne HDD an erste Stelle gelegt und das Problem war weg. Da das aber bei dir schon der Fall ist, wird sich da nicht all zu viel verbessern. Naja, die Hoffnung stirb zuletzt
Gruß
Chris
Moin,
ich habe mal nachgeschaut (Leider bei W8.1) du könntest folgende .exe-Datei abschießen um die falsche Info zu vermeiden:
"C:\Windows\System32\fvenotify.exe"
Also im Prinzip:
Damit kommt zumindest auf W8 keine falsche Info mehr, unter W7 müsstest du es Prüfen, habe gerade kein Testsystem da.
Gruß
Chris
ich habe mal nachgeschaut (Leider bei W8.1) du könntest folgende .exe-Datei abschießen um die falsche Info zu vermeiden:
"C:\Windows\System32\fvenotify.exe"
Also im Prinzip:
taskkill.exe /IM fvenotify.exe
Damit kommt zumindest auf W8 keine falsche Info mehr, unter W7 müsstest du es Prüfen, habe gerade kein Testsystem da.
Gruß
Chris
Moin,
also wofür er dieses Script direkt einsetzt, naja, da bin ich mir auch noch nicht ganz sicher, scheinbar hat er da ein kleines Problem beim Neustarten (Warum auch immer).
Ich persönlich habe ja, wie weiter oben bereits erwähnt, mal ein ähnliches Script geschrieben, bei mir ging es darum, die BIOS Settings bei knapp 100 Notebook händisch zu korrigieren, nachdem sie verschlüsselt waren. Da macht solch ein Script durchaus Sinn.
Gruß
Chris
also wofür er dieses Script direkt einsetzt, naja, da bin ich mir auch noch nicht ganz sicher, scheinbar hat er da ein kleines Problem beim Neustarten (Warum auch immer).
Ich persönlich habe ja, wie weiter oben bereits erwähnt, mal ein ähnliches Script geschrieben, bei mir ging es darum, die BIOS Settings bei knapp 100 Notebook händisch zu korrigieren, nachdem sie verschlüsselt waren. Da macht solch ein Script durchaus Sinn.
Gruß
Chris
Probiere deinen Vorschlag zuerst selber aus
Das habe ich, es gelang. Wäre interessant zu wissen, was bei Dir passiert.Lies doch mal http://technet.microsoft.com/en-us/library/dn383583.aspx und schau, was das ständig bei Dir auslösen könnte. Ich habe mit einigen BL-Systemen gearbeitet (Vista/7/8/8.1) und solche Erfahrungen nicht gemacht.
Keine großen Begründungen nötig, habe schon verstanden, dass Du meinst, es regelmäßig zu brauchen. War nur ein Hinweis dahingehend, dass Windows-Updates es nicht sein "dürften" und dass sie es bei mir auch nie waren. Die einzigen Male bei mir waren begründet durch Bios-Änderungen.
Dass es bei Dir dazu kommt, könnte auf Hardware-Probleme hindeuten, ich wäre deshalb sehr interessiert an der Ursache, anstatt ein Skript zur Hand zu nehmen.
Dass es bei Dir dazu kommt, könnte auf Hardware-Probleme hindeuten, ich wäre deshalb sehr interessiert an der Ursache, anstatt ein Skript zur Hand zu nehmen.