新しいBITSジョブを作成できませんでした｜BITS-Client 16398と上限の確認

「新しいBITSジョブを作成できませんでした」が出たら、イベント本文のジョブ数と上限、所有者、残っているジョブを確認してから対処します。

BITS-ClientのイベントID 16398を調べている場合も、番号だけではなく、同じイベントに表示されたメッセージ、アカウント、ジョブ数、設定された上限を記録してください。ジョブの作成上限を超えている場合は、残ったジョブと作成元アプリの確認が中心です。BITS関連ファイルの一括削除や全ジョブのリセットから始めると、進行中の転送まで失う可能性があります。

BITS-Client 16398で最初に確認すること

1. イベントビューアで発生時刻、プロバイダー、ID、メッセージ全体を保存する。ジョブ数とグループポリシーの上限が書かれていれば、その数値と所有者を控える。
2. その時刻に失敗したアプリを確認する。Windows Update、管理ツール、独自のダウンロード処理など、作成元により復旧方法が違う。
3. 一度だけの過去ログか、現在も繰り返しているかを分ける。更新や転送が成功しているなら、過去のイベントを消すことを目的に設定を変更しない。

BITSは転送をジョブとして管理します。ジョブ数の制限と、同時に使う帯域幅やジョブ内のファイル数は別です。「転送が遅い」ことと「新しいジョブを作れない」ことを同じ原因として扱わないでください。

ジョブ数の上限はユーザー単位とPC単位に分かれる

これらは公式資料の既定値で、構成済みポリシーがあれば設定を優先して確認します。ジョブ数やファイル数のポリシーには、管理者特権・サービスアカウントに対する適用除外が説明されています。管理者として調査したからといって、元の一般ユーザーのジョブ上限が増えたわけではありません。

ジョブは転送しただけではキューからなくならず、作成元アプリがCompleteまたはCancelで終了処理する必要があります。終了処理をしないアプリがジョブを残すと、新しい作成が制限されることがあります。90日待てば必ず解消するという前提で放置せず、作成元の処理を確認してください。

手順1：サービスと利用できるログを読み取る

以下は管理者として開いたWindows PowerShellでの調査例です。ジョブの削除、サービス停止、レジストリ変更は行いません。PowerShell 7でBitsTransferの読み込みに問題がある場合は、Windows標準のWindows PowerShellで確認します。

Import-Module BitsTransfer -ErrorAction Stop
Get-Service -Name BITS | Select-Object Name, Status, StartType
Get-WinEvent -ListLog '*Bits*' |
    Select-Object LogName, IsEnabled, RecordCount

見つかったログをイベントビューアで開き、エラーの発生時刻に絞ってメッセージを確認します。ログが無効、閲覧権限がない、保存期間を過ぎている場合は、「イベントが見えない」だけで異常なしとは判断しません。BITSのサービス状態だけでも、ジョブ数が上限に達したかは分かりません。

手順2：全ユーザーのジョブと所有者を確認する

$diagnosticBitsJobs = @(Get-BitsTransfer -AllUsers -ErrorAction Stop)
$diagnosticBitsJobs |
    Format-List JobId, DisplayName, OwnerAccount, JobState,
        CreationTime, ModificationTime, ErrorCode, ErrorDescription

Get-BitsTransferは、指定なしでは現在のユーザーのジョブだけを返します。-AllUsersには管理者権限が必要です。ジョブIDは切り詰めずに記録し、表示名が同じでも別ジョブであることに注意してください。ジョブ名だけでWindowsのもの、不要なものと断定せず、所有者・時刻・作成元アプリと照合します。

$diagnosticBitsJobs | Group-Object -Property OwnerAccount |
    Sort-Object -Property Count -Descending |
    Select-Object Name, Count
$diagnosticBitsJobs | Group-Object -Property JobState |
    Select-Object Name, Count

ユーザー別の件数をイベントに記録された件数・上限と比較します。現在の一覧はエラー発生時から変化している場合があるため、件数が減っていても当時の上限超過を否定できません。逆に、古いジョブがあるというだけで全件を不要と判断することもできません。

手順3：構成されたBITSポリシーを確認する

Pro等で利用できるグループポリシーエディターでは、「コンピューターの構成」→「管理用テンプレート」→「ネットワーク」→「Background Intelligent Transfer Service (BITS)」を開きます。ジョブ数はMaxJobsPerUser／MaxJobsPerMachineに相当する設定で確認し、「最大同時転送数」や帯域幅の項目と混同しないでください。Homeでgpedit.mscがない場合も、非公式な追加ツールを入れることから始める必要はありません。

構成済みの値を読み取る例です。値がないときは未構成の可能性があり、制限が無限になったという意味ではありません。ドメインやMDMで管理しているPCでは、配布元の設定も管理者が確認します。

$bitsPolicyPath = 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\BITS'
if (Test-Path -LiteralPath $bitsPolicyPath) {
    Get-ItemProperty -LiteralPath $bitsPolicyPath |
        Select-Object MaxJobsPerUser, MaxJobsPerMachine,
            MaxFilesPerJob, JobInactivityTimeout
}
else {
    Write-Output 'No configured BITS policy key was found here.'
}

BITSのポリシーを「無効」または「未構成」にすると、既定値に戻る項目があります。ジョブ上限がなくなるとは限りません。作成元のジョブが増え続けている場合、上限を大きくするだけでは再発防止にならず、キューの肥大化も招きます。必要な件数を確認して管理者が調整してください。

手順4：不要と確認できたジョブだけを整理する

最初に作成元アプリの停止・再試行・修復手順を使います。手動でキャンセルする場合は、アプリの担当者と利用者が不要と確認できたジョブに絞ります。Remove-BitsTransferは対象ジョブの転送全体と一時ファイルを削除し、すでに転送された未確定ファイルも利用できなくなるため、単なるログの削除ではありません。

次の例は、一覧からコピーした実際のJobIdを入力して、1件だけに一致するかを検査し、削除予定を表示します。-WhatIfの段階ではキャンセルしません。未知のジョブやWindows・管理ツールのジョブを試しに指定しないでください。

$selectedBitsJobId = [guid](Read-Host '不要と確認済みのJobIdを入力')
$selectedBitsJob = @(
    Get-BitsTransfer -AllUsers -ErrorAction Stop |
        Where-Object { $_.JobId -eq $selectedBitsJobId }
)
if ($selectedBitsJob.Count -ne 1) {
    throw 'Exactly one matching BITS job is required.'
}
$selectedBitsJob | Format-List JobId, DisplayName, OwnerAccount, JobState
Remove-BitsTransfer -BitsJob $selectedBitsJob -WhatIf

所有者・作成元・削除の影響が確認できた場合に限り、同じPowerShellでRemove-BitsTransfer -BitsJob $selectedBitsJob -Confirmを実行して確認します。その後はGet-BitsTransferで一覧を取得し直してください。削除・完了後のジョブオブジェクトをそのまま再利用しません。Transferredのファイルを確定するComplete処理は、アプリの状態管理にも関わるため、全件へ一律に実行しないでください。

一括リセット・Downloaderの全削除を最初に行わない

bitsadmin /resetはジョブをキャンセルする操作です。/allusersを付けても、Local Systemのジョブまで通常の管理者コンソールから必ず処理できるわけではありません。キャンセルできないからといってSYSTEMで一括実行することを一般的な解決策にはしません。Get-BitsTransferで実際の対象と権限を確認する方が、削除範囲を判断しやすくなります。

CドライブのDownloader配下をワイルドカードで再帰削除すると、別の転送やジョブ情報も巻き込む可能性があります。16398が記録されたという理由だけでデータベースの破損を断定し、そのフォルダーを全削除する手順には進まないでください。BITSサービスを止めて再起動するだけでも、残ったジョブの終了処理や作成元の不具合が直るとは限りません。

再発を防ぐために作成元を調べる

• 同じアプリ・アカウントのジョブが増え続けないか、一定時間後に一覧を読み取り直す。
• アプリの更新、通信先の認証・プロキシ、再試行の間隔、完了／キャンセル処理を確認する。ユーザーとサービスアカウントではログオンや通信設定が違う。
• 業務スクリプトでは失敗時にも作成済みジョブを追跡し、無制限に新しいジョブを作る設計を避ける。
• 失敗していた更新・ダウンロードが成功したことと、新しい同種イベントが増えていないことを合わせて確認する。

管理者へ渡す情報

イベント全文と時刻、OSのバージョン、失敗したアプリ、ユーザー別件数、JobId・所有者・状態・エラー、ポリシーの構成値、実施済みの操作をまとめます。ジョブ情報にはユーザー名やファイル・URL等が含まれる場合があるため、公開の掲示板へ丸ごと貼らず、調査に必要な範囲で共有してください。

Microsoftの公式資料

• Microsoft：BITSのジョブ数ポリシーと既定値
• Microsoft：ジョブ作成失敗・GUID・上限
• Microsoft：ジョブの保持とComplete・Cancel
• Microsoft：Get-BitsTransferと全ユーザー表示
• Microsoft：Remove-BitsTransferの削除範囲
• Microsoft：bitsadmin resetの制約
• Microsoft：イベントログの列挙と読み取り
• Microsoft：BITSのMDMポリシー・非活動タイムアウト