オフライン環境や WSUS 運用中の Windows Server 2019 で「.NET Framework 4.8 を入れたいのに 0x80092004（Cannot find object or property）」で失敗する――この現場あるあるに対して、原因の切り分けから再現性の高い回避策、運用でつまずきがちなポイントまでを一気にまとめました。最短で復旧し、以後同じトラブルを起こさないための恒久対策も併せて解説します。
症状の全体像と前提
.NET Framework 4.8（オフライン インストーラや CAB 直適用）を Windows Server 2019 に導入しようとすると、セットアップ中または DISM の実行中に 0x80092004 でロールバックされる場合があります。既にレジストリ上は 4.8 が入っているように見える、WSUS では「承認済み／必要なし」になっている、アプリ側は 4.8 未検出でセットアップが進めない――といった状態不一致も頻発します。
エラー 0x80092004 の正体
0x80092004 は暗号 API のエラー コードで、ざっくり言えばパッケージのデジタル署名の検証に必要な情報が見つからないことを示します。オフライン環境や古いサービス スタック更新（SSU）、ルート証明書不足、時刻ずれなどが重なると、CAB／MSU の検証が失敗して適用できません。特に WSUS で配布する際、クライアント側の検証で止まるため、管理コンソールからは原因が見えにくいのが厄介です。
まずはここを確認（4 つの速攻チェック）
| チェック項目 | 見るべきポイント | 対処のヒント |
|---|---|---|
| 4.8 が既に導入済みか | HKLM\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full\Release が 528040 以上なら 4.8 系。例：528049 = 4.8.03761 | 導入済みならまず再起動。アプリや役割（IIS 等）が 4.8 を検出するには再起動が必要な場面が多い。 |
| WSUS の承認／必要性 | 管理側で「承認」でも、クライアントが「必要なし」と判断すると配信されない。 | クライアント視点では「既に 4.8」と見えているパターン。レジストリ確認＆再起動で解消することがある。 |
| 再起動の保留 | 保留中の再起動があると更新やロールアップがブロックされる。 | 再起動の保留を解除し、あらためて 4.8 を適用。 |
| 署名検証の失敗 | 0x80092004 は署名検証系。ルート証明書や SSU、不整合な更新履歴が疑わしい。 | 証明書／SSU の最新化、修復ツール実行、適用順序の見直しで改善。 |
再起動の保留を簡単チェック
# 再起動保留の代表的な場所
Test-Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending'
現場で成功報告が多い解決手順（再現性重視）
インストール済みかを厳密に判定し、未導入なら再起動から
まずは OS 側の認識を確認します。以下のどちらかで OK です。
# PowerShell（推奨）
(Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full').Release
# コマンドプロンプト
reg query "HKLM\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full" /v Release 値が 528040 以上であれば 4.8 系です。528049 = 4.8.03761 といったビルドも確認できます。導入済みと判定できた場合、まずサーバを再起動してからアプリの再検出を行います。多くの製品（Exchange Server の CU など）で、再起動後にセットアップが先へ進む実例があります。
旧ビルド（4.8.3761.0）を先に入れ、WSUS/Windows Update で最新版へ上げる
オフライン インストーラ（例：KB4486153）や CAB 直適用で 0x80092004 が出る環境でも、Developer Pack（Dev Pack）ビルド 4.8.3761.0 は通るケースが目立ちます。Dev Pack にはランタイムが同梱されるため、「ランタイムだけ欲しい」環境でも実害はありません。導入後、WSUS 有効なネットワークにつないだタイミングで累積更新により 4.8.3928 等へ自動更新されます。
サイレント導入例
ndp48-devpack-enu.exe /q /norestart /log %TEMP%\ndp48-devpack.log
セットアップ後はレジストリの Release 値とイベントログ（Application の MsiInstaller）を確認し、必ず再起動します。
Microsoft .NET Framework Repair Tool を先行実行してから再インストール
インストーラの残骸や MSI サービスの不整合、署名検証まわりのキャッシュ不具合で失敗している場合、.NET Framework Repair Tool の実行で整合性が戻り、その後のオフライン インストーラ適用が成功する実例があります。実行時は「MSI サービスの再登録」「Windows Installer キャッシュの修復」にチェックを入れ、完了後に再起動 → 再インストールの順で進めます。
Visual Studio Installer から「.NET 4.8 Developer Pack」を追加
GUI ベースで依存関係や証明書をまとめて取得できるため、CAB の個別適用より成功率が高い方法です。開発用途に限らず運用サーバでも Dev Pack はランタイム同梱のため問題ありません。環境差によるエラー切り分けにも有用です。
DISM で CAB を個別適用する場合のコツ（順序が重要）
更新の依存関係を満たすため、以下の順序で適用します。
dism /online /add-package /packagepath:"windows10.0-kb4486129-x64.cab"
dism /online /add-package /packagepath:"windows10.0-kb4486153-x64.cab"
- 先に KB4486129、続いて KB4486153 を適用。
- IIS を使う環境では、この順序で IIS の .NET 4.8 機能（Web-Asp-Net45 等）が正しく表示されます。
- 適用の前後で
dism /online /get-packagesを取り、状態遷移（Install Pending → Installed）を記録しておくと良いです。
証明書とサービス スタック更新（SSU）を最新化する
0x80092004 が署名検証の失敗である以上、ルート証明書の不足／期限切れや、SSU が古いといった要因を潰すのが近道です。オフライン環境では次のような手順が有効です。
- オンライン接続可能な信頼済み端末で最新のルート証明書セット（SST 等）をエクスポート。
- オフラインのサーバに持ち込み、ローカル コンピューターの [信頼されたルート証明機関] にインポート。
- サーバの SSU を先に適用。SSU は LCU（累積更新）の基盤であり、更新適用の成否に直結します。
- システム時刻・タイムゾーンを NTP 基準と突き合わせ、±5 分以内に収める。
これらを済ませてから 4.8 の再適用を試すと、0x80092004 が解消するケースが多く報告されています。
「導入済みなのに検出されない」を解消する運用テクニック
- 再起動必須：.NET の主要更新後は OS の再起動が必要です。特に ASP.NET/IIS 連携や Exchange の前提条件チェックは再起動後に成功へ転じます。
- WSUS の「必要なし」：レジストリの
Releaseが 528040 以上なら、WSUS クライアントは「既に 4.8」と判断します。アプリは独自の検出をしている可能性があるため、アプリ側のセットアップを再起動後に再試行します。 - 役割と機能の整合：IIS の
Web-Asp-Net45が無効のままだと、アプリが「4.8 不足」と誤検知することがあります。役割の有効化状態を確認しましょう。
ログで原因に迫る（見るべき場所）
| ログ | パス | 見るポイント |
|---|---|---|
| CBS.log | C:\Windows\Logs\CBS\CBS.log | 0x80092004 の直前にある Failed to verify file/catalog 等の記録。どの CAB／カタログで失敗したか。 |
| DISM ログ | C:\Windows\Logs\DISM\dism.log | 署名検証の詳細や保留中の操作の有無。 |
| MsiInstaller | イベント ビューアー（アプリケーション） | Dev Pack/Repair Tool 実行時の成功・失敗、再起動要求。 |
| CodeIntegrity | イベント ビューアー（Windows ログ→システム） | 署名検証トラブルのヒント（証明書の期限、チェーン切断）。 |
署名をローカルで検証する簡易コマンド
# PowerShell で CAB/MSU の署名状態を見る
Get-AuthenticodeSignature .\windows10.0-kb4486153-x64.cab | Format-List
環境別の具体策（シナリオ別ガイド）
完全オフライン（インターネット遮断）
- オンライン端末で最新のルート証明書（SST）と必要な CAB/MSU を収集。
- サーバへ持ち込み、SSU → .NET 関連 CAB（KB4486129 → KB4486153）の順で適用。
- 適用後は再起動し、
Release値とWeb-Asp-Net45の状態を確認。
WSUS 管理下（分離ネットワーク）
- 対象製品「Windows Server 2019」と、.NET ランタイムの分類が同期対象になっているかを確認。
- 自動承認ルールが不足している場合は、Feature Pack/Update を含める。
- クライアント側が「必要なし」と判定する場合でも、Dev Pack 旧ビルド → 累積更新の流れで解消できることが多い。
Exchange Server など前提条件が厳密な製品
- 4.8 の導入後は必ずOS 再起動 → 製品セットアップ再実行の順で進める。
- 役割と機能（IIS、.NET Extensibility 4.7 以上、ASP.NET 4.7 以上など）が揃っているかを確認。
DISM／インストーラ適用時の細かな勘所
- 適用順序：前述の通り KB4486129 → KB4486153。依存のあるパッケージは必ず下位を先に。
- 保留状態の解消：
dism /online /cleanup-image /restorehealth前に再起動。保留更新が残ったままでは失敗しがち。 - 言語パック：多言語構成では、言語別パッケージの適用順が影響することがあります。基本は OS 基本言語 → 追加言語の順。
- 時刻同期：証明書の有効期間外だと検証に失敗。NTP での同期ができないセグメントでは、時刻ずれを人手で補正。
PowerShell での一括自動化サンプル（安全な順序で段階適用）
$ErrorActionPreference = 'Stop'
function Get-Net48Release {
try {
(Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full').Release
} catch { return 0 }
}
function Is-RebootPending {
Test-Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending'
}
function Install-Cab([string]$cabPath) {
Write-Host "Installing $cabPath ..."
Start-Process -FilePath dism.exe -ArgumentList "/online","/add-package","/packagepath:`"$cabPath`"" -Wait -PassThru
}
# 1) 既に 4.8 系なら再起動だけでよいことが多い
$release = Get-Net48Release
if ($release -ge 528040) {
Write-Host "Detected .NET 4.8 (Release=$release). Consider rebooting the server."
return
}
# 2) 保留中の再起動があれば先に解消
if (Is-RebootPending) {
Write-Warning "Reboot is pending. Please reboot and re-run this script."
return
}
# 3) 旧ビルド Dev Pack のサイレント導入（存在すれば）
$devPack = "C:\Package\net48\ndp48-devpack-enu.exe"
if (Test-Path $devPack) {
Start-Process $devPack -ArgumentList "/q","/norestart","/log:%TEMP%\ndp48-devpack.log" -Wait
$release = Get-Net48Release
if ($release -ge 528040) {
Write-Host "Dev Pack installed. Release=$release"
Write-Host "Please reboot to finalize."
return
}
}
# 4) CAB 個別適用（順序が重要）
$cab1 = "C:\Package\net48\windows10.0-kb4486129-x64.cab"
$cab2 = "C:\Package\net48\windows10.0-kb4486153-x64.cab"
if (Test-Path $cab1 -and Test-Path $cab2) {
Install-Cab $cab1
Install-Cab $cab2
$release = Get-Net48Release
if ($release -ge 528040) {
Write-Host "CAB applied. Release=$release"
Write-Host "Please reboot to finalize."
return
} else {
Write-Warning "CAB applied but Release not updated. Run Repair Tool next."
}
} else {
Write-Warning "CAB files not found. Skipping DISM stage."
}
Write-Host "Consider running .NET Framework Repair Tool and retry installation." Release 値の読み取りとバージョン対応の目安
厳密な対応は OS／ビルドに依存しますが、Windows Server 2019 の目安としては以下を用いると実務上十分です。
| Release 値 | 意味（目安） | 備考 |
|---|---|---|
| 528040 以上 | .NET Framework 4.8 系導入済み | アプリ要件の「4.8 以上」は満たす。 |
| 528049 | 4.8.03761（初期ビルド） | 導入後に累積更新で 4.8.392x 等へ。 |
| 5283xx / 5284xx | 4.8 系の更新ビルド | 累積更新の適用で変動。 |
バージョン番号（4.8.3928 など）は、%windir%\Microsoft.NET\Framework64\v4.0.30319 配下のファイルやアプリのヘルプでも確認できます。要件が「4.8 系であること」なら Release 値の判定で十分です。
「CAB 直打ち」より成功率を上げる小ワザ
- 検証はローカルに寄せる：CAB を一旦ローカル ドライブに置いてから適用（UNC 直適用より安定）。
- パッケージ キャッシュを掃除：不要な一時ファイルが干渉する場合、
DISM /Online /Cleanup-Image /StartComponentCleanupを先に。 - ロールバックの痕跡を消す：失敗直後は保留状態が残るため、再起動→ログ確認→再試行のリズムを徹底。
セキュリティ／運用上の注意点（恒久対策）
- ルート証明書の配布手順を定常化：隔離セグメントでも四半期ごとに SST を更新し、GPO で自動配布できるようにする。
- SSU を最優先で配布：月例対応のチェックリストに「SSU → LCU → 機能更新」の順序を明記。
- 時刻同期の担保：インターネット遮断でも、セグメント内の NTP（ドメイン コントローラー等）を維持。
- 再起動の運用窓口：再起動保留が溜まると一気に失敗が増えるため、計画再起動の枠をあらかじめ確保。
よくある質問（FAQ）
ランタイムだけ欲しいのに、Dev Pack を入れても良い？ 問題ありません。Dev Pack ≒ Runtime で、ランタイムが同梱されています。後で不要な SDK を削除する必要も通常はありません。 WSUS で承認しているのにクライアントへ降りてこない。 クライアント側が「必要なし」と判定している可能性が高いです。レジストリの Release が既に 528040 以上か、再起動保留が残っていないかを確認してください。 Repair Tool 実行後も 0x80092004 が消えない。 証明書チェーンまたは SSU が原因の可能性大。ルート証明書の更新 → SSU の先行適用 → 再起動の順でやり直します。時刻ずれも忘れずに確認してください。 DISM の順序は必ず KB4486129 → KB4486153？ はい。4.8 導入に付随するコンポーネント（IIS 関連等）との整合性を取りやすい順序です。逆順にすると機能の表示が欠ける報告があります。
トラブルシューティング用コマンド スニペット集
# 現在の .NET 4.x 系の状態
dir 'HKLM:\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full' | fl *
# IIS の .NET 4.8 関連機能（有効/無効）
Get-WindowsFeature Web-Asp-Net45,NET-Framework-45-Features
# 保留中の更新をざっと把握
dism /online /get-packages | findstr /i "pending"
# 失敗直後の CBS ログ末尾を確認（100 行）
Get-Content C:\Windows\Logs\CBS\CBS.log -Tail 100
# .NET Dev Pack のサイレント導入（ログ必須）
Start-Process .\ndp48-devpack-enu.exe -ArgumentList "/q","/norestart","/log:%TEMP%\ndp48.log" -Wait 実運用での落とし穴と回避策
- 多言語 OS：言語パックの組み合わせで一部のコンポーネントが保留に回ることがあります。基本言語で安定させてから追加言語を適用。
- クラスタ ノード：ロールの切り替えと再起動を計画的に。各ノードで Release 値を記録し、段階導入。
- 古いイメージの横展開：構築時のゴールデン イメージに 4.8 と SSU を含め、初回起動後に 0x80092004が出ないようにする。
- セキュリティ ハードニング：アプリロックやデバイス ガードのポリシーが署名検証を阻害することがあります。適用時のみ一時的に緩和する選択肢も検討。
まとめ（解決の順番を固定化する）
Windows Server 2019 で .NET Framework 4.8 の導入に失敗する主因は、ほぼ例外なく署名検証の不成立か状態不一致です。以下の順で対処すれば、短時間で収束できます。
- Release 値で導入済みか判定（528040 以上なら 4.8 系）→ 導入済みなら再起動してアプリ再検出。
- 保留中の再起動を解消し、Dev Pack 4.8.3761.0のサイレント導入を試す。
- 難しければ.NET Framework Repair Toolを実行してから再試行。
- DISM で CAB 個別適用（KB4486129 → KB4486153 の順）。
- なお失敗する場合はルート証明書と SSU を最新化し、時刻ずれを修正。
この手順を標準化して運用に組み込めば、ほとんどの環境で .NET Framework 4.8 を安定して導入でき、0x80092004 の再発も抑えられます。
付録：現場配布チェックリスト
- ［ ］ オフライン配布用の CAB/MSU と Dev Pack を検証済み（署名良好）。
- ［ ］ ルート証明書 SST を最新化し、GPO で展開。（隔離網は手動）
- ［ ］ SSU → LCU → .NET の順で配布する運用を徹底。
- ［ ］ 再起動の保留を監視し、月例再起動の枠を確保。
- ［ ］ Release 値の自動収集（PowerShell/監視ツール連携）。
- ［ ］ 失敗時のログ採取手順（CBS、DISM、MsiInstaller、イベント ID）。
参考スクリプト：Release 値を資産管理に送る（一例）
# 例：Release 値を CSV に吐く。SCCM/Intune/監視に流用可。
$server = $env:COMPUTERNAME
$release = try { (Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full').Release } catch { 0 }
$dt = Get-Date -Format 'yyyy-MM-dd HH:mm:ss'
"$server,$release,$dt" | Out-File -FilePath C:\Temp\net48-inventory.csv -Append -Encoding utf8
以上、Windows Server 2019 環境で .NET Framework 4.8 がインストールできない問題（0x80092004）の原因と解決策を網羅的に解説しました。記事中の順序通りに実施することで、失敗の再現性を断ち、安定した導入と運用につなげられます。
コメント