BitLocker の回復キーを AD にバックアップする .bat が、端末で手動実行すると成功するのに GPO の「コンピューター構成 ＞ スタートアップ スクリプト」で配布すると失敗する――。この差は、同じバッチでも実行アカウントやネットワーク到達性など“起動時特有の条件”がまったく違うことが原因です。現場で効いた切り分けと、確実に 1 回だけ実行させる回避策をまとめます。
現象：ローカル実行は成功、GPO スタートアップ スクリプトだと動かない
よくある相談が次のパターンです。
- 端末にログオンして管理者として .bat（
manage-bde利用）を実行すると、BitLocker の回復キーが AD（Active Directory）に正常に保存される。 - 同じ .bat を、GPO の「コンピューター側（スタートアップ スクリプト）」として配布すると、何も起きない／失敗する。
- 同じ GPO で配布している別の .bat は問題なく動くため、「この .bat だけ何が違うのか」が分からない。
さらにログを見ると 0x80070522（必要な特権がない） のようなエラーが出ていることがあり、手動実行と同じ前提で動いていない可能性が高い状況です。
結論：GPO のスタートアップ スクリプトは「手動実行」と実行条件が別物
最大のポイントは、GPO のスタートアップ スクリプトは「PC 起動のタイミング」「SYSTEM 権限」「ユーザープロファイル無し」「ネットワーク未確立の可能性」など、手動実行とは前提が大きく変わることです。まずは違いを整理すると、原因の見当が付きます。
| 観点 | 手動実行（管理者） | GPO スタートアップ スクリプト | 影響しやすい例 |
|---|---|---|---|
| 実行アカウント | ログオンユーザー（管理者昇格） | 多くの環境で LocalSystem（SYSTEM） | UAC、権限、アクセスできるネットワーク資源が変わる |
| 起動タイミング | OS 起動後・ネットワーク安定後 | OS 起動途中（ドメイン到達前の可能性） | AD へ保存する処理が “まだ到達できない” で失敗 |
| ユーザープロファイル | あり | 基本なし | %USERPROFILE% 依存、証明書ストア、プロキシ設定などが使えない |
| カレントディレクトリ | .bat の場所から実行することが多い | C:\Windows\System32 になることが多い | 相対パスで参照しているファイルが見つからない |
| 共有パス（UNC）実行 | ユーザー資格情報でアクセス | コンピューターアカウント／SYSTEM の資格情報でアクセス | 共有の権限が合わずに .bat 自体が読めない・実行できない |
| 高速スタートアップ | 影響を受けにくい | 条件次第で スタートアップ処理が走らない/タイミングが崩れる | 「再起動では動くがシャットダウン→起動だと動かない」など |
失敗しやすいポイント（manage-bde で AD へ回復キー保存する場合）
manage-bde を使って回復キーを AD にバックアップする処理は、起動時の差分の影響を受けやすいです。特に以下は「同じ .bat でも GPO でだけ失敗する」原因になりがちです。
SYSTEM で動くこと自体が悪いのではなく、前提がズレる
スタートアップ スクリプトは多くの場合 SYSTEM で動きます。SYSTEM は強い権限を持つ一方で、次のような “ユーザー実行と違う不便さ” があります。
- ネットワーク共有へアクセスする際、ユーザー資格情報ではなく「端末（コンピューター）アカウント」の権限でアクセスする。
- ドライブレターの割り当てや、ユーザー固有の環境変数が存在しない。
- 対話的に実行されない（GUI 表示やユーザー入力を前提にすると詰む）。
0x80070522 が出るときに見るべきこと
0x80070522 は「必要な特権がない（A required privilege is not held by the client）」系のエラーです。手動実行で成功し、スタートアップでだけ出る場合、実務的には次のどれかが多いです。
- 実際にはスタートアップで期待した権限で動いていない（例：スクリプト呼び出しの階層で別ユーザーに落ちる、32bit/64bit の差で別 exe を呼んでいる、など）。
- “権限不足” に見えて、実は前段の失敗が原因（例：共有から .bat を読めていない、カレントが違って補助ファイルが無い、DNS 未解決など）。
- AD 側の書き込み権限や委任が足りない（特に OU 単位で権限を絞っている環境）。この場合は 0x80070005（アクセス拒否）系が出ることもあります。
共有パス上の .bat を “そのまま実行” する罠
スタートアップ スクリプトが参照する .bat が \\server\share\script.bat のような共有パスに置かれていると、次のような理由で「実行できない／途中で止まる」ことがあります。
- 共有の NTFS/共有権限がユーザー向けで、端末（Domain Computers）に権限が無い。
- 起動直後はネットワークが不安定で、共有に到達できない。
- 実行できたとしても、相対パス参照（
tools\xxx.exeなど）がカレントディレクトリの差で失敗する。
この系統は「他の .bat は動くのに、今回だけ動かない」も説明できます。今回の .bat だけが 共有上の追加ファイルを参照している、または ネットワーク依存（AD 連携）が強い、という差が出やすいからです。
Fast Startup（高速スタートアップ）で “起動扱い” が変わる
高速スタートアップが有効な端末では、シャットダウン後の起動が「完全な再起動」と同じにならないことがあります。その結果、環境によってはスタートアップ スクリプトの実行タイミングが変わったり、期待した回数で走らなかったりします。
- 検証時は、まず シャットダウン→電源ON と 再起動 の両方で挙動を比較する。
- 再起動でだけ動くなら、高速スタートアップが関与している可能性を疑う。
切り分け手順：まず「走っているか」「どこで落ちているか」を確定させる
原因調査を最短で進めるコツは、推測よりも先に “証拠（ログ）” を取ることです。スタートアップ スクリプトは失敗しても画面に出ないため、ログ設計がないと永遠に迷子になります。
最優先：標準出力・標準エラーをローカルにログ出力する
まずは .bat の先頭にログ出力を仕込みます。ポイントは 必ずローカル（例：C:\ProgramData） に吐くことです。共有へログを出すと、ネットワーク未確立でログ自体が取れないことがあります。
@echo off
setlocal EnableExtensions EnableDelayedExpansion
set "LOGDIR=C:\ProgramData\BitLockerAdBackup"
if not exist "%LOGDIR%" mkdir "%LOGDIR%"
set "LOG=%LOGDIR%\startup_adbackup.log"
echo ==== %DATE% %TIME% ==== >> "%LOG%"
echo ScriptPath=%~f0 >> "%LOG%"
echo Computer=%COMPUTERNAME% >> "%LOG%"
whoami >> "%LOG%"
echo CurrentDir=%CD% >> "%LOG%"
echo Path=%PATH% >> "%LOG%"
echo ======================= >> "%LOG%"
rem 以降、各コマンドの末尾に >> "%LOG%" 2>&1 を付けてログへこれだけでも「そもそも起動時にスクリプトが実行されているか」「実行されているが途中で止まっているか」が分かります。
manage-bde の “取得系” のログに注意（回復パスワードを漏らさない）
manage-bde -protectors -get は出力に回復パスワード（Numerical Password）が含まれることがあります。そのままログへリダイレクトすると回復キーを平文で残す事故になり得るため、ログに残す行は絞り込みます（ID だけ取る、など）。
GPO が適用されているかを gpresult で確認する
スクリプトの問題に見えて、単純に GPO が当たっていないこともあります。端末で次を実行し、対象 GPO が「コンピューターの結果」に出るか確認します。
gpresult /h C:\ProgramData\gpresult.html出力した HTML を開き、該当 GPO の適用状況と、スタートアップ スクリプトの設定が反映されているかを見ます。
SYSTEM 条件で再現させる（PsExec が使えるなら強力）
「手動だと成功する」が再現性の罠なので、GPO に近い条件（SYSTEM）で実行して差分を消します。ツールが使える環境なら次のテストが有効です。
psexec -s -i cmd.exe開いた SYSTEM のコマンドプロンプトで、実際に .bat と同じ manage-bde コマンドを実行し、ログの差を見ます。可能なら「共有から実行する」条件も含めて再現させると、共有権限・ネットワークの問題を早期に特定できます。
原因別チェックリスト（症状から当たりを付ける）
| よくある原因 | 出やすい症状 | 確認方法 | 現実的な対処 |
|---|---|---|---|
| SYSTEM/ユーザーで前提が違う（権限・環境） | 手動OK、GPOだけNG。ログに 0x80070522 など | ログに whoami、%CD%、%PATH% を残す／PsExec で SYSTEM 実行 | スケジュールタスクで「最上位の特権で実行」＋実行条件を揃える |
| 起動時に AD/DC に到達できない | 起動直後だけ失敗、しばらくしてからなら成功 | nltest /dsgetdc:、DNS 解決、イベントログ | タスクに遅延（1〜5分）／ネットワーク利用可条件／Always wait for the network を有効化 |
| 共有パス（UNC）からの実行が不安定 | ログが残らない、最初の行すら動かない | 共有のアクセス権（Domain Computers）／起動時に共有へ到達できるか | GPO でローカルにコピーしてから実行（推奨） |
| 相対パス・作業フォルダの違い | 補助ファイルが見つからない／コマンドが見つからない | echo %CD% と dir をログ | pushd %~dp0 でカレント固定／フルパス指定 |
| Fast Startup の影響 | 再起動では動くが、シャットダウン→起動で動かない | 操作（再起動/シャットダウン）で再現性を比較 | 高速スタートアップ無効化、またはタスク方式へ切替 |
根本対策として知っておきたい：BitLocker は GPO で “自動保存” できる
運用要件が許すなら、回復キーの AD 保存はスクリプトで後追いするより、BitLocker のポリシーで “保存を必須化” する方が安全で確実です。代表例としては次のような設定です（環境により項目名は多少異なります）。
- コンピューターの構成 ＞ 管理用テンプレート ＞ Windows コンポーネント ＞ BitLocker ドライブ暗号化（OS ドライブ / 固定データドライブ）
- 回復方法の設定で「回復情報を AD DS に保存する」を有効化
- 可能なら「回復情報が AD DS に保存されるまで BitLocker を有効にしない」を有効化
ただし、既に暗号化済みの端末へ後追いで回復キーを集めたい、あるいは移行期間だけスクリプトが必要、というケースも多いはずです。以降は “スクリプトでやる前提” の実務解を説明します。
実務で安定した解決策：ローカルへコピー＋即時（1回だけ）のスケジュールタスク
スタートアップ スクリプトのクセ（起動タイミング、共有実行、Fast Startup 等）を避けるため、現場で安定しやすいのが次の方式です。
- GPO（GPP）で .bat を端末ローカルにコピーする
- 同じ GPO で「即時（1回だけ）」のスケジュール タスクを作成し、ローカルの .bat を実行させる
- 実行後にタスク（必要なら .bat や作業ファイル）を削除し、ワンショットで終わらせる
このやり方だと、「共有から実行できない」問題と「起動直後はネットワークが不安定」問題を切り離して考えられます。さらに、タスク側で「最上位の特権で実行」「ネットワーク利用可」「遅延実行」などの条件を付けられるため、スタートアップ スクリプトより制御しやすいのが利点です。
手順：GPP でファイルをローカルへコピーする
GPO 管理エディターで、次のように設定します（例）。
- コンピューターの構成 ＞ 基本設定 ＞ Windows の設定 ＞ ファイル
- アクション：作成（または更新）
- ソース：
\\ドメイン\SYSVOL\ドメイン\scripts\BitLocker\adbackup.bat（または配布用共有） - ターゲット：
C:\ProgramData\Company\BitLocker\adbackup.bat
配布元は SYSVOL 配下に置くと、通常はドメイン参加端末が読みやすく、権限設計もシンプルです（ただし組織の運用ルールに従ってください）。
手順：GPP の「即時タスク」で 1 回だけ実行させる
続けて、スケジュール タスクを作成します。
- コンピューターの構成 ＞ 基本設定 ＞ コントロール パネルの設定 ＞ スケジュール タスク
- タスクの種類：Immediate Task（At least Windows 7）（環境により表記は異なります）
- 実行アカウント：SYSTEM
- 最上位の特権で実行：有効
- 操作：プログラムの開始（
cmd.exe） - 引数：
/c "C:\ProgramData\Company\BitLocker\adbackup.bat" - 条件（任意だが推奨）：ネットワークが利用可能な場合のみ開始、開始を遅延（1〜5分）
「Immediate Task」は “ポリシーが適用されたタイミングで 1 回だけ実行” できるため、スタートアップ スクリプトよりも意図した通りに動きやすいことが多いです。
実行後の削除：タスクとファイルを残さない
タスク自体の削除は、GPP の設定（タスク完了後に削除）でできる場合があります。できない場合は、.bat の最後に schtasks /Delete を入れて自分自身のタスクを消す方式もあります。
また、ワンショット運用にするなら「完了マーカー」を作って二重実行を防ぐと事故りません。例えば C:\ProgramData\Company\BitLocker\adbackup.done のような空ファイルを作り、タスクのアイテム レベル ターゲットで “done が無いときだけ実行” にします。
サンプル：安全にログを取りつつ AD バックアップを実行する .bat
以下は考え方のサンプルです。環境に合わせてドライブ文字やログ保存先を調整してください。回復パスワードをログに残さないため、manage-bde -protectors -get の出力はそのままログに出さず、ID 抽出に必要な行だけを処理します。
@echo off
setlocal EnableExtensions EnableDelayedExpansion
set "MOUNT=C:"
set "BASE=C:\ProgramData\Company\BitLocker"
set "LOGDIR=%BASE%\log"
set "DONE=%BASE%\adbackup.done"
if not exist "%BASE%" mkdir "%BASE%"
if not exist "%LOGDIR%" mkdir "%LOGDIR%"
set "LOG=%LOGDIR%\adbackup_%COMPUTERNAME%.log"
echo ==== %DATE% %TIME% ==== >> "%LOG%"
echo Computer=%COMPUTERNAME% >> "%LOG%"
whoami >> "%LOG%"
if exist "%DONE%" (
echo Already done. Exit. >> "%LOG%"
exit /b 0
)
rem ネットワーク/ドメイン到達性の簡易チェック（必要に応じて強化）
nltest /dsgetdc:%USERDOMAIN% >> "%LOG%" 2>&1
echo nltest_exit=%ERRORLEVEL% >> "%LOG%"
rem ここで少し待つ（起動直後の不安定回避）
timeout /t 30 /nobreak >> "%LOG%" 2>&1
rem 回復用プロテクタ ID を取得（Numerical Password の行はログに残さない）
set "KPID="
for /f "usebackq tokens=1,* delims=:" %%A in (`%SystemRoot%\System32\manage-bde.exe -protectors -get %MOUNT% -type RecoveryPassword ^| findstr /i "ID"`) do (
set "KPID=%%B"
)
set "KPID=%KPID: =%"
if not defined KPID (
echo Protector ID not found. >> "%LOG%"
exit /b 1
)
echo ProtectorID=%KPID% >> "%LOG%"
rem AD へバックアップ
%SystemRoot%\System32\manage-bde.exe -protectors -adbackup %MOUNT% -id %KPID% >> "%LOG%" 2>&1
set "RC=%ERRORLEVEL%"
echo adbackup_exit=%RC% >> "%LOG%"
if not "%RC%"=="0" (
echo Failed. >> "%LOG%"
exit /b %RC%
)
rem 完了マーカー
type nul > "%DONE%"
echo Success. >> "%LOG%"
exit /b 0ポイントは次の通りです。
- 実行状況を必ずローカルログへ（標準出力/標準エラーを含める）。
- 回復パスワードの漏えい対策として、取得コマンドの出力は絞り込む。
- 起動直後の不安定を避けるため、ネットワークチェック＋短い待機を入れる（タスク側の遅延と併用でもOK）。
- 二重実行を防ぐため、完了マーカーを作る。
成功確認：AD 側に回復キーが保存されているかをチェックする
「スクリプトが成功した」だけでは不十分で、AD に回復情報が作成されていることまで確認します。
- Active Directory ユーザーとコンピューター（ADUC）で「高度な機能」を有効化
- 対象コンピューター オブジェクトを開く
- 環境によっては「BitLocker 回復」タブ、またはコンピューター配下の
msFVE-RecoveryInformationオブジェクトが見える
運用上は、回復情報を閲覧できる権限を必要最小限にし、監査（誰が回復キーを参照したか）もセットで設計するのがおすすめです。
まとめ：スタートアップ スクリプトの “クセ” を受けない形に寄せるのが最短
GPO のスタートアップ スクリプトで manage-bde の AD バックアップが動かないときは、コマンド自体よりも 実行条件の差で詰まっていることがほとんどです。特に「SYSTEM」「共有からの実行」「起動直後のネットワーク」「Fast Startup」はハマりどころが多いため、
- ローカルにコピーしてから実行する
- 即時（1回だけ）のスケジュール タスクで、最上位権限＋遅延＋ネットワーク条件を付ける
- ログを残して、失敗箇所を可視化する
この 3 点を押さえると、再現性の低いトラブルでも短時間で原因にたどり着き、目的（BitLocker 回復キーの AD 保存）を確実に達成できます。
コメント