MENU

タスク スケジューラをgMSAに移行する手順とエラー対処｜Windows ServerとPowerShell完全ガイド

Active Directory

既存のスケジュール タスクを通常のドメイン サービス アカウントから gMSA（グループ管理サービス アカウント）へ切り替えると、パスワード管理の負担やセキュリティ リスクを大幅に減らせます。本記事は、GUI／PowerShell／CLI いずれでも迷わず移行できるように、前提条件の確認から一括置換、そして典型エラーの原因切り分けまでを“現場でそのまま使える”形でまとめた保存版ガイドです。

ITtripTOOLS
その「面倒」、無料で解決。 ITtripがつくる、6つの道具。 無料ツール一覧へ すべて無料・追加課金なし
先頭0を守るCSV編集こわさないCSV PDFに直接書き込みかけるPDF 写真＋説明をPDFに写レポ スマホ⇄PCで共有コピペ便 · 文章・写真 みんなの日程を調整日程Fit 匿名質問・投票を集めるKOEQ
目次

背景と目的：なぜ「通常のサービスアカウント」から gMSA へ？

タスク スケジューラは長年、CORP\service.account のような通常のドメイン アカウントで動かす運用が一般的でした。しかし、定期的なパスワードローテーションや、パスワードの秘匿・配布、共有による内部統制リスクなど、運用負債が蓄積しがちです。gMSA（Group Managed Service Account）は、Active Directory が安全にパスワードを自動管理し、対象サーバーが必要に応じて取得する仕組みのため、下記の点で有利です。

  • パスワード管理が不要：AD が自動ローテーション。人手による定期差し替えが不要。
  • 安全な配布モデル：パスワードを人やスクリプトが保持せず、漏えいリスクが低い。
  • 複数サーバー共有に強い：対象を制限しつつ、スケールアウトや冗長構成に対応。
  • タスク実行の安定性：「ユーザーがログオンしているかどうかにかかわらず実行」が自然にマッチ。

前提条件チェックリスト（必ず最初に確認）

項目要件 / 確認ポイント確認・準備コマンド
ドメイン機能ドメイン コントローラーが Windows Server 2012 以降Get-ADDomain（AD モジュールで現状把握）
KDS ルートキー存在必須。新規作成時はレプリケーション考慮Get-KdsRootKey / Add-KdsRootKey –EffectiveTime ((Get-Date).AddHours(-10))
対象サーバーの権利gMSA のパスワード取得許可（PrincipalsAllowedToRetrieveManagedPassword）gMSA 作成時に対象サーバー（MyServer$）やグループを指定
サーバー側準備gMSA のインストールInstall-ADServiceAccount -Identity MyTaskGmsa
Test-ADServiceAccount -Identity MyTaskGmsa
タスク実行権必要に応じて「バッチとしてログオン」(SeBatchLogonRight) を付与ローカル セキュリティ ポリシー or GPO（ユーザー権利の割り当て）

補足：KDS ルートキーはドメイン内複数の DC にレプリケートされます。-EffectiveTime ((Get-Date).AddHours(-10)) を使うと「10 時間前に作られた」と見なして即時利用しやすくなります（大規模環境ではレプリケーション完了を十分に考慮してください）。

gMSA の作成と配布（ドメイン管理者作業）

最小構成の例

# 例: gMSA 名 MyTaskGmsa、DNS ホスト名は慣習的に FQDN を付ける
New-ADServiceAccount `
  -Name "MyTaskGmsa" `
  -DNSHostName "MyTaskGmsa.corp.example.com" `
  -PrincipalsAllowedToRetrieveManagedPassword "DOMAIN\MyServer$"

# 対象サーバー側

Install-ADServiceAccount -Identity "MyTaskGmsa"
Test-ADServiceAccount    -Identity "MyTaskGmsa"  # True が返れば準備完了

複数サーバーで共有する場合

複数サーバーで同一の gMSA を使う場合は、PrincipalsAllowedToRetrieveManagedPassword にコンピューター アカウントのグループを指定するのが運用しやすいです。

# 事前に "GmsaTargets-Task" というドメイングループに対象サーバー（Computer）を追加
New-ADServiceAccount `
  -Name "BatchJobGmsa" `
  -DNSHostName "BatchJobGmsa.corp.example.com" `
  -PrincipalsAllowedToRetrieveManagedPassword "DOMAIN\GmsaTargets-Task"

# 各サーバーで

Install-ADServiceAccount -Identity "BatchJobGmsa"

権限管理はグループで束ねるのがベストプラクティスです。対象サーバーの増減があっても gMSA 本体の変更が不要になります。

タスク スケジューラのアカウントを gMSA に切り替える（GUI）

  1. タスク スケジューラ → 該当タスクのプロパティを開く。
  2. [全般]タブ → [ユーザーまたはグループの変更] をクリック。
  3. DOMAIN\MyTaskGmsa$ と、末尾に “$” を付けて入力して [OK]。
  4. パスワード入力ダイアログが出ても空欄のまま [OK] を押す（gMSA はパスワードを持たない）。
  5. [最上位の特権で実行する]が必要ならチェックする。

重要：パスワードの入力を強制されたり、空欄で通らない場合、gMSA として認識されていません。$ の付け忘れ、対象サーバーでの Install-ADServiceAccount 未実施、あるいは対象サーバーが PrincipalsAllowedToRetrieveManagedPassword に含まれていない等を再確認してください。

なお、gMSA を指定すると「ユーザーがログオンしているかどうかにかかわらず実行する」が自動的に有効な扱いになり、GUI 上でグレーアウトされることがあります。仕様上問題ありません。

タスク スケジューラのアカウントを gMSA に切り替える（PowerShell）

単一タスクを置換

$taskName = 'MyTask'
$p = New-ScheduledTaskPrincipal -UserID 'DOMAIN\MyTaskGmsa$' -LogonType ServiceAccount -RunLevel Highest
Set-ScheduledTask -TaskName $taskName -Principal $p
# 動作確認
Start-ScheduledTask -TaskName $taskName

既存タスクのバックアップ（強く推奨）

# 既存設定をすべて XML 退避
Get-ScheduledTask | ForEach-Object {
  $xml = Export-ScheduledTask -TaskName $_.TaskName
  $xml.Save("C:\Backup\Tasks\$($_.TaskName).xml")
}

特定アカウントで動くタスクを一括置換（ドライラン付き）

$from = 'DOMAIN\service.account'
$to   = 'DOMAIN\MyTaskGmsa$'
$dryRun = $true  # 実行前に $false に切り替える

$targets = Get-ScheduledTask | Where-Object {
$_.Principal.UserId -eq $from
}

$principal = New-ScheduledTaskPrincipal -UserID $to -LogonType ServiceAccount -RunLevel Highest

foreach ($t in $targets) {
"{0} → {1} / Task: {2}" -f $from, $to, $t.TaskName
if (-not $dryRun) {
Set-ScheduledTask -TaskName $t.TaskName -Principal $principal
}
}

# 置換後のテスト実行

if (-not $dryRun) {
$targets | ForEach-Object { Start-ScheduledTask -TaskName $_.TaskName }
}

CLI（schtasks）でピンポイント変更

schtasks /change /TN "\MyTask" /RU DOMAIN\MyTaskGmsa$ /RP ""

/RP ""（空パスワード）を明示すると、旧来の挙動によるエラーを回避できるケースがあります。

動作確認とログの見かた

イベント ビューアー

  • ログ：アプリケーションとサービス ログ → Microsoft → Windows → TaskScheduler → Operational
  • 主なイベント：
    • 201（Task started）
    • 102（Task completed successfully）
    • 203（Task failed to start）

誰のトークンで実行されたかを確認する

アクションに次のようなコマンドを一時的に入れて実体確認します。

whoami > C:\Temp\whoami.txt && echo %DATE% %TIME% >> C:\Temp\whoami.txt

または PowerShell で：

'User: {0}, Time: {1}' -f [System.Security.Principal.WindowsIdentity]::GetCurrent().Name, (Get-Date) |
  Out-File C:\Temp\whoami.txt -Append

セキュリティ ログ（イベント ID 4624）のログオン タイプが 4（Batch） であることも参考になります。

よくあるハマりポイント（原因と対処まとめ）

症状 / エラー主な原因対処
GUI でパスワードを求められる／空欄で通らないgMSA として認識されていない$ 末尾を付ける、Install-ADServiceAccount 実施、PrincipalsAllowedToRetrieveManagedPassword を見直す
0x8007052e（ユーザー名またはパスワードが違う）-LogonType Password を使っている／パスワード必須の扱い-LogonType ServiceAccount を使う。schtasks は /RP "" を明示
「ユーザーがログオンしているかどうかにかかわらず実行する」がグレーアウトgMSA 仕様（パスワード保存不要＝非対話で実行）問題なし。設計上の挙動
アクセスが拒否されました (0x5)実行先フォルダー/共有/レジストリ等の ACL 不足、または SeBatchLogonRight 未付与対象リソースに gMSA を許可、必要に応じて「バッチとしてログオン」を付与（GPO 推奨）
0x8007010B（パスが無効）「開始 (作業フォルダー)」や実行ファイルパスの誤りUNC/ローカル パスの再確認。gMSA とは無関係の入力ミスのことが多い
UNC 共有へのアクセス失敗共有/NTFS 権限に gMSA が入っていない、またはネットワーク制約共有と NTFS 両方に gMSA を追加。必要なら Kerberos/SPN 周辺も点検
タスクの GUI で編集できない管理者権限不足／古い OS のスナップイン管理者で最新 OS から mmc.exe → タスク スケジューラ スナップインを使用

実運用に効く「設計と運用」チェックポイント

命名規則と分割統治

  • gMSA 名は用途が分かるように：gmsa-TASK-DataExport、gmsa-BATCH-Accounting など。
  • 機能境界・データ境界ごとに gMSA を分ける（最小権限）。

権限設計

  • 必要なフォルダー／共有／レジストリ／サービスへの ACL をgMSA に直接付与。間接グループを併用する場合も管理しやすい単位で。
  • 「バッチとしてログオン」権は GPO でサーバー単位に配布すると横展開が容易。

監査と可視化

  • タスク スケジューラの Operational ログを収集基盤（SIEM 等）へ転送し、201/102/203 を監視。
  • 成功・失敗のメトリクスをダッシュボード化し、移行後の早期異常検知に活用。

バックアップとロールバック

  • Export-ScheduledTask による XML 退避を実施（前述スクリプト）。
  • ロールバック用に旧アカウントを一定期間は無効化せず保持（期限付き）。

移行シナリオ：段階的に安全に置換する

  1. 棚卸し：対象タスクを抽出。Get-ScheduledTask で現在の UserId とアクション、依存先（UNC/DB/サービス）を書き出す。
  2. gMSA 設計：用途別に gMSA を分割。対象サーバー集合をグループ化して PrincipalsAllowedToRetrieveManagedPassword に指定。
  3. 権限前払い：必要なフォルダー／共有／DB ログイン等に gMSA を事前付与。
  4. 一括置換（ドライラン→本番）：PowerShell で Principal を差し替え。すべてのタスクを手動実行してログを確認。
  5. フォロー期間：7～14 日は集中的に 201/102/203 を監視し、失敗の再発率を追う。
  6. 旧アカウントの無効化→削除：依存が残っていないことを確認のうえ段階的に廃止。

ケース別 Tips（現場で遭遇しやすい微妙なハマり）

PowerShell スクリプトの実行ポリシー

タスクのアクションが powershell.exe -File の場合、実行ポリシーで弾かれると gMSA 以前に失敗します。アクション側で -ExecutionPolicy Bypass を明示するか、署名/ポリシーを整備してください。

powershell.exe -ExecutionPolicy Bypass -File "C:\Jobs\DoWork.ps1"

作業フォルダー（Start in）未設定

相対パスを使うスクリプトは「開始 (作業フォルダー)」が空だと失敗しがちです。アクションで必ず明示しましょう。

ネットワーク越しの実行ファイル

実行ファイルを UNC（\\server\share\app.exe）から呼ぶ場合、共有と NTFS の両方に gMSA を付与してください。アプリ自身が別のホストへアクセスする二段越しは、Kerberos の委任設計（必要に応じて制約付き委任）も検討対象になります。

「最上位の特権で実行」と UAC

レジストリ/HKLM を書き換える等、管理者特権が必要なバッチは RunLevel Highest を忘れずに。PowerShell の Principal 作成時に -RunLevel Highest を付けるとミスしにくいです。

トラブル対応の深掘り：原因切り分けフロー

  1. アカウント認識：タスクの 全般 タブで DOMAIN\gmsa$ になっているか。パスワードを要求されるなら未認識。
  2. ホスト準備：Test-ADServiceAccount -Identity gmsa が True か。
  3. ログオン種別：Principal が -LogonType ServiceAccount になっているか（XML でも確認可）。
  4. 最低限の権限：実行先パス、作業フォルダー、出力先に gMSA 権限があるか。
  5. 外部依存：ファイル共有／DB／API など外部接続先に gMSA を許可しているか。
  6. ログ解釈：TaskScheduler/Operational の 201/203、Security 4624 のログオン タイプ。

XML で Principal を点検する

# XML を開いて <Principals> セクションを確認（LogonType=ServiceAccount になっているか）
$xml = Export-ScheduledTask -TaskName 'MyTask'
$xml.OuterXml | Out-File C:\Temp\MyTask.xml

実例：サービス アカウントから gMSA への完全移行スクリプト

以下は「旧アカウントで動く全タスク」を「用途別 gMSA」にマッピングして置換するテンプレートです。タグ名やパスで仕分けすると安全です。

# マッピング例：タスク名プレフィックスで gMSA を切り替える
$map = @{
  'ACC-' = 'DOMAIN\gmsa-ACC-Batch$'
  'ETL-' = 'DOMAIN\gmsa-ETL-Data$'
  'OPS-' = 'DOMAIN\gmsa-OPS-Maint$'
}

$all = Get-ScheduledTask

foreach ($t in $all) {
$prefix = ($map.Keys | Where-Object { $t.TaskName.StartsWith($*) } | Select-Object -First 1)
if ($null -ne $prefix) {
$gmsa = $map[$prefix]
try {
$p = New-ScheduledTaskPrincipal -UserID $gmsa -LogonType ServiceAccount -RunLevel Highest
Set-ScheduledTask -TaskName $t.TaskName -Principal $p
Write-Host "Replaced: $($t.TaskName) → $gmsa"
}
catch {
Write-Warning "Failed: $($t.TaskName) / $($*.Exception.Message)"
}
}
}

セキュリティ メモ：GPP（資格情報）廃止環境からの移行

かつて GPP（グループ ポリシー プレファレンス）でタスク資格情報を配っていた環境では、すでに資格情報保存が禁止されている場合があります。この状況で旧式の「パスワードありタスク」を編集すると、保存時に失敗したり、0x8007052e が出やすくなります。gMSA へ移行すれば、パスワードを保存しない前提になるため、これらの問題は根本から解消されます。

Q&A

Q. gMSA はローカル グループに追加できますか？

A. はい。通常のセキュリティ プリンシパルとして扱えるため、ローカル グループや ACL に追加可能です。権限は最小限に留めましょう。

Q. タスクが UI を表示する必要があります。gMSA で可能ですか？

A. 原則として非対話実行が前提です。UI 表示が要る処理は設計を見直すか、運用フローを分離してください。

Q. 1 つの gMSA を大量のサーバーで共有しても大丈夫？

A. 技術的には可能ですが、影響範囲が広がるため推奨しません。役割単位で分割し、PrincipalsAllowedToRetrieveManagedPassword もグループで厳格に管理しましょう。

Q. 旧アカウントをすぐに削除してよい？

A. 監視期間を置いてから段階的に無効化→削除が安心です。残余タスクや手動バッチが潜んでいることがあります。

まとめ：これだけ押さえれば安全かつ確実

  • 前提条件の三点セット：DC バージョン / KDS ルートキー / パスワード取得対象の指定。
  • gMSA 作成～配布：New-ADServiceAccount → 各サーバーで Install/Test。
  • タスク置換：GUI は $ 付きで空パスワード、PowerShell は -LogonType ServiceAccount。
  • 検証：手動実行＋ TaskScheduler/Operational（201→102）で成功確認。
  • トラブル時：末尾 $／Install-ADServiceAccount／権限／作業フォルダー／UNC 権限の順に分解。

この手順をテンプレート化しておけば、以後のサーバー増設やアプリ更新時も高速・安全に展開できます。gMSA への移行は、パスワード管理の悩みを終わらせ、ガバナンスと安定運用を同時に実現する最も効果的な打ち手です。

付録：本記事のクイックリファレンス

手順ポイント参考コマンド／操作
1. gMSA の前提条件確認DC は 2012 以降／KDS ルートキー／対象サーバーを PrincipalsAllowedToRetrieveManagedPassword に追加Add-KdsRootKey –EffectiveTime ((Get-Date).AddHours(-10))
2. gMSA 作成・配布DNSHostName は慣習的に FQDN 付与。サーバー側で Install/TestNew-ADServiceAccount / Install-ADServiceAccount
3. タスクへ設定（GUI）DOMAIN\gmsa$ を入力、パスワードは空欄のまま OKタスクの 全般 タブ → ユーザーまたはグループの変更
4. タスクへ設定（PowerShell）-LogonType ServiceAccount を必ず指定New-ScheduledTaskPrincipal → Set-ScheduledTask
5. CLI 一括置換/RP ""（空）を明示schtasks /change /TN "\MyTask" /RU DOMAIN\gmsa$ /RP ""
6. 動作確認201（開始）→ 102（成功）を TaskScheduler/Operational で確認Start-ScheduledTask -TaskName ...

付録：トラブル 早見表（エラーコード別）

コード意味観点対処
0x8007052eユーザー名またはパスワードが違うgMSA をパスワード型で扱っている／$ 無し-LogonType ServiceAccount、DOMAIN\gmsa$ を使用
0x8007010Bパス/フォルダー無効Start in 未設定、UNC 参照、相対パス絶対パス記述・作業フォルダー明示
0x5アクセス拒否ACL/共有、ユーザー権利不足gMSA に必要権限付与、SeBatchLogonRight 付与
0x41301/0x41302実行中/キュー待ち長時間実行/競合同時実行数・スロットリング設定を見直し

スニペット集（コピペ可）

gMSA の存在・利用可否チェック

Get-ADServiceAccount -Identity "MyTaskGmsa"
Test-ADServiceAccount -Identity "MyTaskGmsa"   # True なら OK

タスクを新規作成（最小構成）

$action = New-ScheduledTaskAction -Execute "powershell.exe" -Argument '-File "C:\Jobs\DoWork.ps1"'
$trigger = New-ScheduledTaskTrigger -Daily -At 02:00
$principal = New-ScheduledTaskPrincipal -UserID 'DOMAIN\MyTaskGmsa$' -LogonType ServiceAccount -RunLevel Highest
Register-ScheduledTask -TaskName "MyNewTask" -Action $action -Trigger $trigger -Principal $principal -Description "Run with gMSA"

UNC 共有にアクセスするタスクの権限付与例

# 管理端末から：共有と NTFS の両方に gMSA を付与（例）
# 共有権限（サーバー側で GUI or PowerShell）
# NTFS 権限（icacls）
icacls \\filesrv\share\Jobs /grant "DOMAIN\MyTaskGmsa$":(RX,M)
Active Directory
Active Directory PowerShell Windows Server gMSA タスク スケジューラ

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次