こんにちは。Windows Commercial Support Directory Services チームです。

Windows にソフトウェアをインストールするとき、「なぜこのフォルダーに入るの？」と疑問に思ったことはありませんか？
この記事では、Windows のフォルダーにはそれぞれ決められた役割があること、そしてアプリケーションがどこにインストールされるのが推奨されるかを解説します。

はじめに — よくある疑問

Windows にアプリケーションをインストールすると、インストール先は大きく分けて以下の 3 パターンがあります。

「Program Files ではなく AppData の中にインストールされたけど大丈夫？」
「C:\ の直下にフォルダーを作ってインストールしてもいいの？」

これらの疑問に答えるために、まず Windows のフォルダー構成のルールから見ていきましょう。

1. Windows のフォルダーには「役割」がある

Windows には各フォルダーには明確な役割が定められています。大きく分けると、ユーザーのデータを置く場所と、アプリケーションのデータを置く場所が区別されています。

ユーザーのデータを置く場所

ユーザーが自分で作成・編集するファイル（文書、写真、動画など）の保存先です。

アプリケーションのデータを置く場所

アプリケーションが内部的に使う設定ファイルやキャッシュなどの保存先です。ユーザーが直接編集する必要はないため、隠しフォルダーになっています。

ポイント: たとえば Outlook の .pst ファイルは、ユーザーのデータのように見えますが、実際にはアプリケーションが管理するデータとして AppData に保存されます。ユーザーが直接操作するのではなく、Outlook の画面を通じて管理するという考え方です。

2. AppData フォルダーの中身 — Roaming・Local・LocalLow の違い

C:\Users\<ユーザー名>\AppData\ の中には、さらに 3 つのフォルダーがあります。

1
2
3
4

AppData
├── Roaming    … 別の PC に引き継いでも問題ない設定
├── Local      … この PC だけで使うデータ
└── LocalLow   … セキュリティが制限されたアプリ用

それぞれの役割を詳しく見てみましょう。

Roaming フォルダー

移動ユーザー プロファイルやフォルダー リダイレクトで別の PC に引き継いでも問題ない設定データ（ブラウザーのブックマーク、アプリの個人設定など）を保存します。

Microsoft の公式ドキュメント (ApplicationData クラス (Microsoft Learn)) では、RoamingFolder はユーザー設定やカスタマイズ、リンク、小さなデータ ファイルの保存に使用し、大容量のデータ、デバイス固有のデータ、即時同期に依存するデータには使用すべきではないとされています。

Local フォルダー

この PC だけで使うデータ（キャッシュ、一時ファイル、ダウンロード履歴など）を保存します。他の PC に引き継ぐ必要はありませんが、クラウドにバックアップされるため、デバイスのリセットや移行時に失われることはありません。

Microsoft の公式ドキュメント (設定とその他のアプリ データを格納および取得する (Microsoft Learn)) では、以下のように説明されています：

ローカル アプリ データは、アプリ セッション間で保持する必要があり、アプリ データのローミングには適していない情報に使用する必要があります。他のデバイスには適用できないデータもここに保存する必要があります。

LocalLow フォルダー

セキュリティが制限された状態（低い整合性レベル）で動作するアプリケーションのデータを保存します。たとえば、ブラウザーの保護モードで使われるデータが該当します。通常のアプリがこのフォルダーを使うことはほとんどありません。

❗ Roaming に保存すべきでないデータについて:
デバイス固有の情報（ローカル ファイルへのパス名など）、大容量のデータ、即時同期に依存するデータは Roaming に保存しないでください。これらは Local フォルダーに保存します。詳しくは Store and retrieve settings and other app data - Roaming data (Microsoft Learn) をご覧ください。

3. アプリケーションはどこにインストールされるべきか

パターン A: 全ユーザー向けインストール (管理者権限が必要)

PC のすべてのユーザーが使えるようにインストールする一般的な方法です。

C:\Program Files\ にはプログラム本体だけを置き、設定データやユーザーデータは置きません。これは、Program Files フォルダーには標準ユーザーの書き込み権限がないためです。

パターン B: 特定ユーザー向けインストール (管理者権限が不要)

現在サインインしているユーザーだけが使えるようにインストールする方法です。管理者権限が不要なため、UAC (ユーザー アカウント制御) のダイアログが表示されません。

「AppData にインストールされたけど大丈夫？」の答え:
VS Code のユーザーインストールが AppData\Local\Programs\ にインストールされるのは、Microsoft のガイドラインに従った正しい動作です。管理者権限なしでインストールする場合の正式な保存先がこのフォルダーです。

4. 推奨されないインストール方法

ドライブ直下にフォルダーを作る

1
2

C:\MyApp\         ← 非推奨
C:\tools\         ← 非推奨

C:\ ドライブの直下にアプリケーション用のフォルダーを作成することは、Microsoft のガイドラインで明確に推奨されていません。Program Files フォルダーにはパスにスペースが含まれることで問題が起きるアプリもありますが、それでもドライブ直下への配置は避けるべきとされています。

Program Files に設定データを保存する

C:\Program Files\<アプリ名>\config.ini のように、Program Files の中にアプリの設定ファイルを置くのも不適切です。標準ユーザーには書き込み権限がないため、設定の保存に失敗します。設定データは ProgramData や AppData に保存しましょう。

5. まとめ — フォルダー構成の全体像

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

C:
├── Program Files\            … 全ユーザー向けアプリの本体 (64-bit)
├── Program Files (x86)\      … 全ユーザー向けアプリの本体 (32-bit)
├── ProgramData\              … 全ユーザー共通のアプリ設定 (隠しフォルダー)
├── Users\
│   ├── <ユーザー名>\
│   │   ├── Desktop\          … デスクトップ
│   │   ├── Documents\        … ドキュメント
│   │   ├── Downloads\        … ダウンロード
│   │   └── AppData\          … アプリ設定 (隠しフォルダー)
│   │       ├── Roaming\      … 別の PC に引き継いでも問題ない設定
│   │       ├── Local\
│   │       │   └── Programs\ … ユーザー向けアプリの本体
│   │       └── LocalLow\     … 制限付きアプリのデータ
│   └── Public\               … 全ユーザー共有のデータ
└── Windows\                  … OS のシステムファイル

6. 環境変数の対応表

スクリプトや設定で使われる環境変数と、実際のパスの対応です。

参考情報

この記事の内容は、以下の Microsoft 公式ドキュメントに基づいています。

• KNOWNFOLDERID (Microsoft Learn) — Windows の既知フォルダーの一覧と各フォルダーのパス・用途
• About User Profiles (Microsoft Learn) — ローカル / 移動 / 必須プロファイルの種類と仕組み
• Store and retrieve settings and other app data (Microsoft Learn) — Local / Roaming / Temporary 各フォルダーの使い分けガイド
• ApplicationData Class (Microsoft Learn) — アプリケーション データ ストアの API リファレンスと用途の説明
• Windows application development - Best practices (Microsoft Learn) — アプリケーション開発のベストプラクティス
• Single Package Authoring (Microsoft Learn) — Per-machine / Per-user インストールのガイドライン

本記事はマイクロソフト社員によって公開されております。

こんにちは、Windows サポートの相沢です。

本記事では、Windows 11, versions 24H2 および 25H2 で順次有効化されている “新しいスタート メニュー” で発生する問題についてご報告させていただきます。

対象バージョン

Windows 11, version 24H2
Windows 11, version 25H2

事象

Windows 11, versions 24H2 および 25H2 では 2025.10 D (KB5067036) のプレビュー更新プログラムを適用後、 新しいスタート メニュー (Start 5.0) が制御された機能ロールアウト (CFR) により段階的に有効化されています。

新しいスタート メニューは、以下のような UI で表示されます。

この新しいスタート メニューに切り替え後のデバイスでは、新規にアプリケーションをインストールした際にスタート メニューのアプリケーション一覧には直ぐに反映されない不具合が報告されています。また、アプリケーションをアンインストールした場合も同様にスタート メニューのアプリケーション一覧から直ちに削除されません。

以下は、アプリケーション インストール後も一覧に表示されない例です。(O と S の間に Ricoh 社のアプリケーションが表示されない)

原因

弊社は現在、本不具合の修正に向けて取り組んでおります。

回避策

本事象は、ユーザーを再ログオンし直すか、StartMenuExperienceHost プロセスを一度終了すれば回避することができます。

// StartMenuExperienceHost.exe を再起動後、正常に表示される

本情報の内容（添付文書、リンク先などを含む）は、作成日時点でのものであり、予告なく変更される場合があります。

変更履歴

• 2026/04/16 : 本記事の公開

みなさま、こんにちは。Windows サポート チームです。
本記事では、オンプレミス環境 における Windows OS のマスター イメージ作成を対象に、Sysprep を用いた際の一般的な注意点と、サポート部門としてお勧めする展開方法を整理してご紹介します。

これから初めてマスター イメージを作成される方はもちろん、すでに運用中のイメージをお持ちの方にとっても、現在の構成や手順を見直すためのチェックリストとしてご活用いただければ幸いです。

目次

1. Sysprep の考え方
2. マスター イメージの前提条件
3. マスター イメージとして設定可能な範囲
4. 品質更新プログラムの適用
5. アップグレード環境について
6. 複数ユーザー プロファイルが存在する環境
7. ドメイン参加状態での Sysprep
8. まとめ
9. 参考技術情報

1. Sysprep の考え方

Sysprep は、Windows を大量展開する際にマスター イメージを作成する工程を支援するためのツールです。
そのため、Sysprep コマンドは「マスター イメージ作成」という明確な目的のもとで実行されることが前提となっており、運用環境での利用や、イメージ作成以外の目的での使用はサポートされていません。

上記を含め、その他にも Sysprep の利用がサポートされていないシナリオが存在しており、それらは以下の公開情報に記載されておりますのでご確認ください。

サポートされていないシナリオ

2. マスター イメージの前提条件

配布可能なマスター イメージは、以下の前提条件を満たしている必要があります。

条件 A: Sysprep を実施していること

Sysprep は、端末固有の情報（SID、CMID、SusClientID など）を初期化し、別の端末へ安全に展開できる状態にするためのツールです。
Sysprep を実行せずに端末を複製した場合、これらの固有情報が重複し、認証エラー、管理ツール上の誤認識、セキュリティ上の問題など、広範な不具合を引き起こす可能性があります。
また、不具合の発生の有無に関わらず Sysprep を実行していないイメージはサポートされません。

条件 B: ボリューム ライセンス メディアを使用すること

再イメージング権は、ボリューム ライセンス契約に基づくメディアにのみ付与されています。
使用可能なイメージは以下のとおりです。

•   Microsoft 365 管理センター（旧 VLSC）から入手したイメージ
•   Visual Studio サブスクリプションのテスト用イメージ
•   OEM ベンダーがイメージ作成用途として別途提供しているメディア

OEM プリインストール イメージには再イメージング権がないため、別の端末へ展開することを目的とした Sysprep の実施やマスター イメージ作成はサポートされていません。

3. マスター イメージとして設定可能な範囲

Sysprep は端末固有の情報（SID、CMID、SusClientID など）を初期化するためのツールですが、どの設定が保持されるか、または初期化されるかは、実際に Sysprep を実行した結果に依存します。
OS やアプリケーションの設定の中には、Sysprep 実行時に初期化されるため、展開後に再設定が必要なものが存在します。

また、OS の設定箇所は非常に多数にわたり、削除対象などを網羅するリストはありませんので、あらかじめ検証環境にて検証していただくことをお勧めしております。

4. 品質更新プログラムの適用

マスター イメージ作成時点での最新の累積的な品質更新プログラム (QU) を適用することをお勧めしております。
これにより、既知の不具合や Sysprep 実行時の問題を未然に回避できる可能性が高まります。

Microsoft Update カタログからスタンドアロン インストーラーを取得することで、Windows Update 経由で品質更新プログラムをダウンロード・インストールする工数を削減できるため利用をお勧めしています。

5. アップグレード環境について

アップグレード環境での Sysprep 実行は、サポート対象ではあるものの、問題が生じる可能性が高いため、弊社サポート部門としては、クリーン インストールされた環境を対象にしていただくことをお勧めしております。

本項では、その背景について説明します。

既存のマスター イメージを、展開予定の Windows バージョンに合わせてアップグレードし、その後 Sysprep を実行する運用を行われているケースもあります。
しかしながら、OS のアップグレード処理では多くの機能変更や内部構成の更新、初期化処理が行われるため、アップグレード後の環境では Sysprep が失敗するケースが多く報告されています。

アップグレード環境における Sysprep 失敗について調査を行うことは可能ですが、事象発生後のログから取得できる情報には限りがあり、原因の特定に至らないケースも少なくなく、最終的にクリーン インストールされた環境での Sysprep の実行が唯一の解決策となる場合もあります。

なお、ボリューム ライセンスをご契約のお客様であれば、各 Windows バージョンのインストール イメージを個別に入手することが可能です。 
そのため、利用予定のバージョンの OS をクリーン インストールした環境を基に、マスター イメージを作成する方法をお勧めしております。

Sysprep 実行時のエラー発生リスクをできる限り低減したい場合は、問題発生時に都度トラブルシュートを行う運用ではなく、バージョンごとにマスター イメージを作成する構成をご検討ください。

6. 複数ユーザー プロファイルが存在する環境

複数のユーザー プロファイルが存在する状態での Sysprep 実行は想定されていません。

実際に、

•   Sysprep 実行時の失敗
•   展開後のユーザー プロファイル破損

といった事象が報告されています。
マスター イメージ作成作業は、OS に既定で存在し有効化することで利用できる built-in administrator アカウントのみ存在している状態で実施するようにしてください。
もしマスター イメージでのカスタマイズ時に任意のローカル ユーザーを作成のうえ作業した際には、built-in administrator アカウントを有効にしていただいたうえで、該当のユーザーを削除していただき Sysprep を実施いただくことをお勧めしております。

7. ドメイン参加状態での Sysprep

ドメイン参加状態または過去にドメインに参加していた端末に対する Sysprep の実施は弊社サポート部門としてはお勧めしていません。
ドメインに参加することで、マスター イメージの構成として意図しないグループ ポリシーが適用され、これらのポリシー設定によって Sysprep の実施が失敗するリスクも高くなります。

また、ドメインに一度参加した後に離脱してワークグループの環境に戻しても、すべてのポリシー設定が既定のものに戻るわけではありません。

やむを得ずドメイン参加が必要な場合は、

•   専用 OU を用意する
•   不要なポリシーを極力適用しない

といった対策を行ってください。

8. まとめ

Sysprep はマスター イメージ展開において非常に有用なツールですが、効果的に活用するためにも、事前に前提条件と制約について認識しておく点が重要です。
マスター イメージの作成時や展開時のトラブルを未然に防ぐために、

•   クリーンな環境で作成する
•   不要な設定やアプリを入れない
•   事前検証を十分に行う

ことを弊社サポート部門としては強くお勧めいたします。

9. 参考技術情報

•   Sysprep (システム準備) の概要
•   サポートされていないシナリオ
•   Sysprep Command-Line Options

特記事項

本情報の内容 (添付文書、リンク先などを含む) は作成日時点のものであり、予告なく変更される場合がございます。

更新履歴

2026/04/14 : 本ブログの公開

本記事はマイクロソフト社員によって公開されております。

こんにちは、Windows サポートの新井です。
本記事では、2026 年に有効期限を迎える Secure Boot 証明書について、想定される影響やよくあるご質問をご案内いたします。

■ 概要

Microsoft が提供する Secure Boot 証明書は、2026 年 6 月から 10 月にかけて順次有効期限を迎えます。

有効期限を迎えた場合でも、直ちに Windows OS の起動や機能に影響が生じるものではございませんが、Secure Boot の保護機能や一部のセキュリティ更新の適用に影響する可能性がございます。

■ よくある質問 (FAQ)

• 更新せずに期限が切れると、どうなりますか?
• 期限が切れると証明書は失効しますか?
• オフライン環境でも更新できますか?
• Secure Boot が無効な場合も対応が必要ですか?
• IT 管理デバイスとホームデバイスの違いは何ですか?

更新せずに期限が切れると、どうなりますか?

更新が行われていない状態で Secure Boot 証明書の期限を迎えても、デバイスは引き続き正常に動作し、直ちに Windows OS の起動や機能に影響が生じるものではございません。

更新された証明書を必要とするブート関連のセキュリティ コンポーネントを除き、Windows 更新プログラムは引き続きインストールされます。

一方で、新しい Secure Boot の保護機能や脆弱性の修正の一部が適用できなくなるなど、セキュリティ面での保護が不十分な状態となります。詳細は以下をご参照ください。

Windows デバイスでセキュア ブート証明書の有効期限が切れた場合
https://support.microsoft.com/ja-jp/topic/c83b6afd-a2b6-43c6-938e-57046c80c1c2

期限が切れると証明書は失効しますか?

いいえ、有効期限が切れただけでは Secure Boot 証明書は失効いたしません。現時点では、強制失効の予定は公式にアナウンスされておりません。

将来的に強制失効が実施される場合には、少なくとも 6 か月前に公式にアナウンスされる予定でございます。

オフライン環境でも更新できますか?

オフライン環境においても、Secure Boot 証明書の更新は可能でございます。更新に必要なコンポーネントは Windows 更新プログラムに含まれております。更新方法には、管理者による手動更新と、条件を満たしたデバイスに対して段階的に適用される自動更新があります。詳細は以下もあわせてご参照ください。

TPM-WMI イベント ID: 1801 について
https://jpwinsup.github.io/blog/2025/10/28/UEFI/Secure%20Boot/about-tpm-wmi-1801/#■-対処策について

Secure Boot が無効な場合も対応が必要ですか?

Secure Boot を現在無効化しており、今後も有効化する予定がない場合には、直ちに対応が必要となるものではございません。
一方で、将来的に Secure Boot を有効化する可能性がある場合は、更新をご検討いただけますと幸いです。

IT 管理デバイスとホームデバイスの違いは何ですか?

IT 管理デバイスは、企業・学校などの組織が独自の IT 部門や管理手段 (例: グループ ポリシー、Intune など) により管理をしている Windows デバイスを指します。この場合は、組織の方針に沿って、Secure Boot 証明書更新を展開・管理・監視するためのガイダンスが提供されております。

セキュア ブート証明書の更新: IT プロフェッショナルと組織向けのガイダンス
https://support.microsoft.com/ja-jp/topic/e2b43f9f-b424-42df-bc6a-8476db65ab2f

ここでいうホームデバイスは、組織による一元管理を受けていない Windows デバイスを指します。Secure Boot の証明書更新は通常の Windows 更新プログラム経由で段階的に配信され、多くの場合、特別な操作は不要でございます。

Microsoft が管理する更新プログラムを使用したホーム ユーザー、企業、学校向けの Windows デバイス
https://support.microsoft.com/ja-jp/topic/29bfd847-5855-49f1-bb94-e18497fe2315

■ 更新状況の確認

Windows セキュリティ アプリでの更新確認

2026 年 4 月以降、Windows セキュリティ アプリ上で、Secure Boot 証明書が最新の状態に更新されているかどうかをご確認いただけるようになっております。[デバイス セキュリティ] > [セキュア ブート] の下に現在の状態が色分けにて表示され、対応が必要かどうかについてもご確認いただけます。

ただし、エンタープライズ管理下のデバイスでは、IT 管理者が一元的に管理・把握することを前提としているため、Secure Boot 証明書の更新状態は Windows セキュリティ画面には表示されないことがございます。詳細は以下をご参照ください。

Windows セキュリティ アプリのセキュア ブート証明書の更新状態
https://support.microsoft.com/ja-jp/topic/5ce39986-7dd2-4852-8c21-ef30dd04f046

■ 更新履歴

• 2026-04-10 本記事を新規公開しました。

こんにちは。Windows Commercial Support Directory Services チームです。
今回は以下のマイクロソフトの URL でご案内している LSA 保護について補足させていただきます。

追加された LSA 保護を構成する

LSA 保護とは、lsass.exe を「Protected Process Light (PPL)」として実行し、保護されていないプロセスによるメモリの読み取りやコード インジェクションを防ぐ仕組みです。
また、Protected Process Light（PPL）は Windows の特別な保護プロセス モードで、重要プロセスを改ざん・停止・メモリ読み取りから守るための OS レベルの保護機構です。
上記 URL では、LSA 保護が有効な状態、また、LSA 保護の監査モードとなっている状態で、適切に署名されていないプラグインやドライバーが読み込まれると以下のイベントが記録されることをご案内しています。

イベントが記録される場所

1

[アプリケーションとサービス] - [Microsoft] - [Windows] - [CodeIntegrity] - [Operational]

LSA 保護が有効なときに記録されるイベント

1
2

イベント ID : 3033
Code Integrity determined that a process (<lsass.exe のパス>) attempted to load <読み込みが阻止されたモジュールのパス> that did not meet the Microsoft signing level requirements.

1
2

イベント ID : 3063
Code Integrity determined that a process (<lsass.exe のパス>) attempted to load <読み込みが阻止されたモジュールのパス> that did not meet the security requirements for Shared Sections.

LSA 保護の監査モードとなっているときに記録されるイベント

1
2

イベント ID : 3065
message: Code Integrity determined that a process (<lsass.exe のパス>) attempted to load <読み込みが阻止されたモジュールのパス>  that did not meet the security requirements for %5. However, due to system policy, the image was allowed to load.

1
2

イベント ID : 3066
Code Integrity determined that a process (<lsass.exe のパス>) attempted to load <読み込みが阻止されたモジュールのパス>  that did not meet the %5 signing level requirements or violated code integrity policy. However, due to code integrity auditing policy, the image was allowed to load.

上記 URL では LSA 保護について説明しており、その中でこれらのイベント ID 3033、3063、3065、3066 を紹介していますが、これらのイベントは LSA 保護に特化したイベントではないため、LSA 保護が有効、監査モードの状態以外にも記録されます。
単にこれらのイベント ID が記録されたことをもって、即座に LSA 保護によるプラグインやドライバーの読み込みの阻止が行われたと判断することはできない点にご留意ください。

これらのイベントのメッセージ中の <lsass.exe のパス> の欄に lsass.exe のパスが記載されていることをご確認ください。
イベントのメッセージ中に lsass.exe のパスが記録されている場合は、LSA 保護により記録されたものと判断できます。
逆に、lsass.exe 以外のパス (例えば MsMpEng.exe や msedge.exe) が記録されている場合は、LSA 保護により記録されたものではありません。
イベント ID 3033、3063、3065、3066 が出力された際は、メッセージ中に lsass.exe のプロセスのパスが記録されているかどうかまでご確認いただくようお願いいたします。

更新履歴

2026/4/10 : 本ブログの公開

※ 本情報の内容 (リンク先などを含む) は、作成日時点でのものであり、予告なく変更される場合があります。

こんにちは、Windows サポート チームの岩永です。
本記事では、イベントログ ファイルの最大サイズを増強した際のパフォーマンスへの影響と、推奨される対処策についてご案内いたします。

イベントログ ファイルの最大サイズとパフォーマンスの関係

Windows のイベントログはより多くのイベントを記録するために最大サイズを拡張できますが、サイズを大きくするほどパフォーマンスが指数的に劣化する場合があります。
その理由は、以下のイベントログの仕組みにあります。

• イベントログ ファイルはバイナリ形式で保存されている
• イベント ビューアーは、表示時にバイナリを XML 形式へ変換している
• ファイル サイズが大きいほど、この変換処理や表示に消費する (CPU 使用率が上がり、メモリの使用量が増大する)

適切な最大サイズの目安

最適なサイズは環境によって異なりますが、目安となるサイズを求める計算方法の一例を以下のブログの “Maximum log size (KB)” の項目で説明しています。

Understanding the Windows Server Event Log | Microsoft Community Hub

この計算式の概要は以下のとおりです。

1

最大サイズ (バイト) = 平均イベント サイズ (バイト) × 1 日のイベント数 × 保持日数

例として、Security ログで 1 日あたり 5,000 件のイベントが記録され、28 日間分のデータを保持する場合は 70 MB (≈ 500 バイト × 5,000 件 × 28 日) が最大サイズの目安となります。

実際のイベント数は、環境やログの種類によって異なります。算出した値は概算として扱い、実際の環境で十分な件数が保持されているか確認してください。

イベントログの最大ファイルサイズとしては、2TB まで指定することができますが、前述のブログでは、大きくても 4 GB を推奨しています。しかしながら、4 GB に設定しても期待するパフォーマンスが得られないケースも報告されています。
理由としては、イベントログ ファイルの最大サイズをどれだけ調整してもファイルが 1 つであることには変わりはなく、処理を分散しづらく、特定の CPU やコアに負荷が集中しやすくなってしまうためです。

推奨策: イベントログのアーカイブ

イベントログの保持量を確保しつつパフォーマンスを維持するには、最大サイズの拡張は行わず、アーカイブ機能を活用したほうが効果的です。
イベントログのアーカイブを有効にすると、ログが最大サイズに達した際に自動的に別ファイルへ退避されます。
アーカイブ ファイルは Archive-<Log Name>-YYYYMMDDHHMMSSmmm.evtx の形式で保存されるため、ファイル名だけで処理対象の時間を絞り込むことができます。
また、複数ファイルを並行してチェックする場合は CPU・コアへの負荷が分散され、パフォーマンスの劣化も抑制できる傾向にあります。

アーカイブの設定手順

イベントログのアーカイブを有効化するには、いくつか方法がございますが、ここではグループポリシーによる設定方法を説明します。

1. グループ ポリシー エディターを開く

2. 以下のパスに移動する
   コンピューターの構成 > 管理用テンプレート > Windows コンポーネント > イベントログ サービス > [対象ログ]

3. 「ログがいっぱいになったときに自動的にバックアップする」 を 有効 に設定する

アーカイブ ファイルは、元のログ ファイルと同じフォルダー (既定: %WinDir%\System32\Winevt\Logs) に保存されます。ディスク容量にご注意ください。

修正履歴

• 2026.04.02 本ブログを公開

※ 本情報の内容 (添付文書、リンク先などを含む) は、作成日時点でのものであり、予告なく変更される場合があります。

本記事はマイクロソフト社員によって公開されております。

こんにちは、Windows サポート チームの浅野です。

Windows 11 Version 22H2 より、印刷時に起動する印刷ダイアログの UI が刷新され、新しい印刷ダイアログへの変更が行われております。
今回は、新しい印刷ダイアログの動作で、よくお問い合わせをいただく内容や、
皆様にご認識いただきたい情報について本ブログにてご案内をさせていただきます。

“アプリで印刷設定を変更できるようにする” 機能の動作

Windows 11 にて採用されている新しい印刷ダイアログにつきましては、
以下の画像の通り、”アプリで印刷設定を変更できるようにする” という機能がございます。

本設定は、印刷ダイアログ上で印刷の向きなどの設定を変更することで、
ユーザーごとのプリンターの既定の印刷設定も同時に変更される機能となります。

ユーザーごとの既定の印刷設定とは、プリンターのプロパティ上の [全般] タブの [基本設定] の項目となり、
例えば、本チェックが入った状態で用紙の向きを縦から横に変更し印刷を実施した場合、ユーザーごとの基本設定の印刷の向きも横に変更されるため、
その後の印刷時にも印刷の向きなどの変更した設定を引き継ぐ動作となります。
“アプリで印刷設定を変更できるようにする” のチェックを外せば、ユーザーごとの基本設定の変更を行わないため、変更した内容は該当の印刷のみに利用されます。

なお、本機能は、従来より実装されていながらも問題があり動作しておらず、
2025 年 9 月のプレビューリリース更新プログラムで修正されたため、これ以降の更新プログラムで動作いたします。

印刷ダイアログのプレビュー機能について

Windows 11 の印刷ダイアログでは、プレビュー機能が搭載されておりますが、印刷ダイアログだけでは動作せず、アプリケーション側での対応が必要になります。
もし、アプリケーション側が印刷プレビューに対応していない場合には、”このアプリは印刷プレビューをサポートしていません” というメッセージが表示されます。
アプリケーション側の対応は、アプリケーションモデルの変更といった大幅な変更が必要なことが多いため、
印刷の設定の変更や印刷するドキュメントの変更などで印刷プレビューを有効にすることはできません。

なお、下記のブログでご紹介している、印刷ジョブを確認する印刷キューアプリと
本プレビュー機能は異なる機能であることをご注意ください。
印刷キューアプリのプレビュー機能について

管理者権限で実行するアプリケーション

印刷元アプリケーションが管理者権限で動作している場合、新しい UI の印刷ダイアログではなく、
Windows 10 以前から利用されていた従来の印刷ダイアログが表示されます。
新しい印刷ダイアログはユニバーサル Windows プラットフォーム (UWP) アプリであるため、
本動作は印刷ダイアログの仕様となります。

アプリケーションが印刷設定を指定する場合の動作

従来の印刷ダイアログでは、ダイアログの表示時にアプリケーションが使用する印刷キューと指定したり、用紙の向きなどの印刷の設定を指定することが可能でした。
新しい印刷ダイアログでは、アプリケーションが、印刷キューと指定したり、用紙の向きなどの印刷の設定を指定したとしても、その内容は反映されません。
こちらも新しい印刷ダイアログの仕様となることご注意ください。

本投稿が少しでも皆様のお役に立てば幸いです。 ​

※ 本情報の内容 (リンク先などを含む) は、作成日時点でのものであり、予告なく変更される場合があります。

更新履歴
2026/04/02 本 Blog の公開

みなさま、こんにちは。Windows サポート チーム 郭です。

以下の公開情報では、BitLocker 機能に関するよくあるお問い合わせを紹介しています。
URL: https://learn.microsoft.com/en-us/windows/security/operating-system-security/data-protection/bitlocker/faq

本ブログ記事では、公開情報には含まれていないものの、企業の IT 管理者様から特に多く寄せられる BitLocker の実際の運用に関する質問をご紹介いたします。BitLocker の運用にあたり、少しでも参考になれば幸いです。

目次

BitLocker 運用方法・設定関連

-複数端末に対して、一意の PIN を設定して有効化する機能はありますか。
-Intune でサイレント暗号化を設定したいですが、構成プロファイルの推奨設定値はありますか。
-Hybrid Entra 参加の環境で、回復キーは Entra ID（またはオンプレミス）に固定して保存するように指定できますか。
-サイレント暗号化を設定したが、開始されません。どこを確認すればよいですか。
-複数の端末に対して、一括でオンプレミス AD または Entra ID へバックアップできますか。
-BitLocker を運用するにはどんなライセンスが必要ですか。

BitLocker 回復キー関連

-回復キーはどこから確認できますか。
-回復キーを紛失してしまったが、Microsoft に確認することで復旧はできますか。
-Hybrid Entra 参加の環境ですが、回復キーはオンプレミス環境、Entra ID のどちらに保存されますか。

複数端末に対して、一意の PIN を設定して有効化する機能はありますか。

セキュリティ観点において、一意の PIN を設定すると脆弱であるため、上記のシナリオを実現する既定の機能は BitLocker 側に特に用意がなく、各端末側で PIN つきで BitLocker を有効にする必要があります。

その際に、以下のコマンドを実行することで、一意の PIN を作成し、BitLocker を有効にすることが可能ですので、サンプルとしてご参考ください。

1
2
3

Add-BitLockerKeyProtector -MountPoint C: -RecoveryPasswordProtector  
$SecureString = ConvertTo-SecureString "123456" -AsPlainText -Force  
Enable-BitLocker -MountPoint C: -TpmAndPinProtector -Pin $SecureString -usedspaceonly -skiphardwareTest  

回復キーはどこから確認できますか。

回復キーは BitLocker 有効化する際に、設定によって保存先が異なることがございますが、主な保存先での確認方法は以下の公開情報に記載されておりますので、ご参考ください。

タイトル：BitLocker 回復キーを見つける
URL: https://support.microsoft.com/ja-jp/windows/6b71ad27-0b89-ea08-f143-056f5ab347d6

回復キーを紛失してしまったが、Microsoft に確認することで復旧はできますか。

弊社はお客様環境における回復キーを収集・管理していないため、残念ながら上記の場合は、弊社でも回復キーを突破する手段をご提供できかねます。
回復キーは複数の場所に保存できますので、まずは 回復キーはどこから確認できますか。 で該当するすべての保存先をご確認ください。
また、Bitlocker を運用・管理するうえで、回復キーは非常に大事なものですので、定期的なバックアップを実施するようお願いいたします。
コマンドでのバックアップ方法に関しては、後述する BackuptoAAD-BitLockerKeyProtector/Backup-BitLockerKeyProtector コマンドをご参考ください。

Hybrid Entra 参加の環境ですが、回復キーはオンプレミス環境、Entra ID のどちらに保存されますか。

結論：どちらか片方、またはその両方へバックアップされる可能性があります。

回復キーの保存は、Bitlocker 有効化時またはドメイン参加・Entra 参加時に、一度のみ行われる処理となります。
Hybrid Entra 参加の際に、オンプレミス AD と Entra ID の両方へ試みる動作となりますが、どちらかあるいはその両方への保存が正常に完了すれば、回復キーの保存処理も正常完了とみなされます。そのため、何等かのネットワーク通信不良で、片方のみ通信可能な環境では片方しか回復キーが保存されていない場合があります。

Hybrid Entra 参加の環境で、回復キーは Entra ID（またはオンプレミス）に固定して保存するように指定できますか。

回復キーの保存先を指定することが出来ないため、既定の動作では上記の指定ができません。
一方、後述する BackuptoAAD-BitLockerKeyProtector/Backup-BitLockerKeyProtector コマンド に記載のコマンドを定期的に実行することで、指定する保存先へ明示的にバックアップすることが可能です。

複数の端末に対して、一括でオンプレミス AD または Entra ID へバックアップできますか。

Bitlocker 既定の機能としては特に用意されていませんが、以下の PowerShell コマンドをスクリプト化し、複数の端末へ配布することによって、実現することが可能です。

タイトル：回復パスワードをリセットしてバックアップする
URL: https://learn.microsoft.com/ja-jp/windows/security/operating-system-security/data-protection/bitlocker/operations-guide?tabs=powershell#reset-and-backup-a-recovery-password
※ 上記の記事では、使用済みの回復キーを削除し、新たに回復キーを生成したうえ、Entra ID または オンプレミス AD へ保存する流れですが、削除・再作成する必要がなければ、以下のコマンドレットのみ実行すれば、該当する保存先にバックアップ可能です。

1
2

BackuptoAAD-BitLockerKeyProtector -MountPoint $env:SystemDrive -KeyProtectorId "{ID}"
Backup-BitLockerKeyProtector -MountPoint $env:SystemDrive -KeyProtectorId "{ID}"

補足

上記の “{ID}” は以下のコマンドで取得した “KeyProtectorId” に置き換えます。

1

(Get-BitLockerVolume -mountpoint $env:SystemDrive).KeyProtector | where-object {$_.KeyProtectorType -eq 'RecoveryPassword'} | ft KeyProtectorId,RecoveryPassword

Bitlocker 関連の GPO / 構成プロファイルを設定して、端末側で Bitlocker を有効にしましたが、以下のエラーになりました。

エラー メッセージ：BitLocker スタートアップ オプションのグループポリシー設定は競合しているため、適用できません。詳細については、システム管理者に問い合わせてください。

TPM が搭載されている PC に対して、以下の BitLocker スタートアップ オプションが用意されています。
・TPM スタートアップ の構成
・TPM スタートアップ PIN の構成
・TPM スタートアップ キー の構成
・TPM スタートアップ キーと PIN の構成

それぞれのオプションには、以下の指定方法が用意されています。
・許可する
・要求する
・許可しない

ただし、「要求する」と指定できるものは 1 つのみとなっており、ほかに「要求する」または「許可する」が同時に存在する場合は、上記のエラーとなります。従いまして、「要求する」と指定した項目以外は、すべて「許可しない」と指定してください。

補足：BitLocker を有効にする際のみではなく、解除するときも上記のチェックが実施されるため、その際に、競合となるグループポリシーが検知されたら、同様にエラーとなりますので、ご留意ください。

Intune でサイレント暗号化を設定したいですが、構成プロファイルの推奨設定値はありますか。

多くの企業様では、サイレント暗号化をしつつ、回復キーを Entra ID に保存する運用をされております。
その際に、サイレント暗号化の必須設定に加え、回復キの作成を許可し、そのバックアップが正常に Entra ID に保存されてから、暗号化を開始する設定をご案内しております。

Intune の構成プロファイル一式を以下に記載しますので、ご参考ください。
（本記事掲載時点の画面表示となりますので、今後画面やレイアウトが変更される場合がございます）

構成
-> ポリシー
-> 新しいポリシー
-> プラットフォーム：Windows 10 以降。プロファイルの種類：テンプレート
-> Endpoint Protection

Intune から一意の PIN をつけて、サイレント暗号化をかけることが可能ですか。

サイレント暗号化では、TPM スタートアップの構成のみサポートされているため、TPM スタートアップ PIN の構成を要求する場合は、サイレント暗号化は動作しなくなります。
そのため、PIN つきでサイレント暗号化をかけることができません。

サイレント暗号化を設定したが、開始されません。どこを確認すればよいですか。

弊社の過去事例において、以下の場合、サイレント暗号化が開始されないことがありますので、該当しないかご確認ください。

(1) Intune からサイレント暗号化の設定を配布していない
サイレント暗号化として推奨される設定について、(Intune でサイレント暗号化を設定したいですが、推奨の設定はありますか。) をご確認ください。

(2) BitLocker Drive Encryption Service （BDESVC）サービスが無効になっている
解決方法：BitLocker Drive Encryption Service （BDESVC）サービスのスタートアップ種類を手動に変更する
コマンド：

1

sc.exe config BDESVC start= demand

(3) BitLocker MDM policy Refresh タスクが無効になっている、あるいは、削除されている

(4) セキュアブート機能が対応されていない、または、UEFI モードになっていない
確認方法：
セキュリティで保護されたブート状態を確認するには、System Information アプリケーションを使用します。 これを行うには、次の手順を実行します。

[スタート] を選択し、[検索] ボックスに「msinfo32」と入力します。
次のように、[ セキュア ブート状態] 設定が [オン] になっていることを確認します。

セキュア ブート状態の設定がサポートされていない場合は、このデバイスで サイレント暗号化を使用することはできません。

(5) WinRE （回復環境）が無効になっている
確認方法：
管理者権限で以下のコマンドを実行し、”Windows RE の状態:” が “Enabled” になっているか確認します。

1

reagentc /info

回復環境の有効化：
管理者権限で以下のコマンドを実行します。（何等か環境固有の理由でエラーとなった場合は、回復環境有効化のトラブルシューティングが必要です）

1

reagentc /enable

BitLocker を運用するにはどんなライセンスが必要ですか。

端末側で BitLocker を有効にするには、Windows Pro / Enterprise / Pro Education / SE / Education のエディションが必要です。また、Intune で BitLocker CSP または構成プロファイルを配布して、BitLocker を管理する場合、Windows Enterprise E3/E5, Windows Education A3/A5 のライセンスが必要です。

タイトル：Windows エディションとライセンスに関する要件
URL: https://learn.microsoft.com/ja-jp/windows/security/operating-system-security/data-protection/bitlocker/configure?tabs=common#windows-edition-and-licensing-requirements

[特記事項]

本情報の内容（添付文書、リンク先などを含む）は、作成日時点でのものであり、予告なく変更される場合があります。

本記事は、マイクロソフト社員によって公開されております。

こんにちは、Windows サポートチームの岩永です。
本記事では Windows Error Reporting (WER) のイベント ID: 1001 のイベントについてご案内いたします。

■ 概要

アプリケーション イベントログに Windows Error Reporting (WER) のイベント ID: 1001 が定期的に記録されることがあります。
本イベントは、過去に発生した問題をレポートできない場合に記録されるイベントであり、記録された日時にはクラッシュなどの問題が発生していないため無視して差し支えありません。
また、問題のレポートをクリアすることで、当該イベントの記録を抑制できる場合があります。

■ 事象

イベントの例

アプリケーション イベントログに、以下のようなイベントが定期的に記録されることがあります。

• イベント ソース: Windows Error Reporting
• イベント ID: 1001
• レベル: 情報

事象の詳細

アプリケーションのクラッシュなどが発生した場合に、Windows Error Reporting (WER) が「問題のレポート」を作成し、Microsoft への送信を試みることがあります。
この際、ネットワーク到達性の問題や通信のブロックなどが影響し送信が完了しない場合、問題のレポートが報告されていない状態となります。このような未報告のレポートがある場合、起動時などで再送を試行します。
この再送が完了しないとイベント ID 1001 が記録されるため、通信のブロックなどで継続に未報告の状態のままになると定期的に該当イベントが記録されることとなります。

ただし、本イベントのレベルは “情報” であり、Windows Error Reporting (WER) の イベント ID: 1000 と異なり、アプリケーションやシステムに異常があることを示すものではありません。

そのため、本イベントは無視して差し支えありません。

■ 対処策について

本イベントの記録を抑制する方法として、問題のレポートをクリアする方法があります。
以下の手順により、クリアし、イベントが抑制されるかご確認ください。

1. タスクバーの [検索] ボックスに [問題のレポートをすべて表示] と入力し、起動します。
2. 発生元を選択し、[問題レポートをすべてクリア] をクリックします。
   
3. [すべて消去] をクリックします。
   

関連記事

アプリケーションまたはサービスのクラッシュ動作のトラブルシューティング ガイダンス - Windows Server | Microsoft Learn
https://learn.microsoft.com/ja-jp/troubleshoot/windows-server/performance/troubleshoot-application-service-crashing-behavior

Windows エラー報告と Windows 診断の有効化に関するガイダンス - Windows Client | Microsoft Learn
https://learn.microsoft.com/ja-jp/troubleshoot/windows-client/system-management-components/windows-error-reporting-diagnostics-enablement-guidance

WER について - Win32 apps | Microsoft Learn
https://learn.microsoft.com/ja-jp/windows/win32/wer/about-wer

修正履歴

• 2026.03.25 本ブログを公開

本情報の内容 (添付文書、リンク先などを含む) は、作成日時点でのものであり、予告なく変更される場合があります。

※ 本記事はマイクロソフト社員によって公開されております。

こんにちは。日本マイクロソフトサポートです。

本公開情報では Windows Update を行う上で必要な接続先エンドポイントについてお伝えさせていただきます。

概要

Windows Update で更新プログラム等を適用する場合、インターネット上の弊社エンドポイントへの通信の疎通が正常に行える必要があります。

ネットワーク設定等に起因してエンドポイントへの通信が行えない場合、 Windows Update の動作に影響を及ぼし意図しない動作が発生する場合があります。

そのため、ネットワーク接続に制限がある環境やインターネット接続に失敗した旨のエラーが発生する場合、後述の各エンドポイントへの通信の疎通が可能であるかご確認ください。なお、疎通の必要なエンドポイントは OS ごとに異なるものとなります。

また、記載のエンドポイントへの接続が制限されている場合、ネットワーク管理者等にご確認いただき、必要に応じてエンドポイントへの通信の許可をご実施ください。

なおエンドポイントについては変更される可能性があるため、最新情報については弊社公開情報をご確認ください。

OS ごとに必要なエンドポイントについて

Windows 11 / Windows Server 2025

< 公開情報 >

Title：Windows 11 Enterprise の接続エンドポイントの管理

URL： https://learn.microsoft.com/ja-jp/windows/privacy/manage-windows-11-endpoints

Windows Server 2022

< 公開情報 >

Title：Windows 10 Enterprise バージョン 21H2 の接続エンドポイントを管理する

URL： https://learn.microsoft.com/ja-jp/windows/privacy/manage-windows-21h2-endpoints

Windows Server 2019

< 公開情報 >

Title：Windows 10 Enterprise Version 1809 の接続エンドポイントの管理

URL： https://learn.microsoft.com/ja-jp/windows/privacy/manage-windows-1809-endpoints

Windows Server 2016

証明書の取得について

Windows Update に直接使用するエンドポイントではありませんが、証明書チェーンの信頼に必要な中間証明書およびルート証明書を取得できない場合、Windows Update の動作に影響を及ぼす可能性があります。

そのため、前述のエンドポイントに加え、以下の接続先への通信を許可いただくか、必要な証明書を手動でインストールする必要があります。

A) ctldl.windowsupdate.com

B) www.microsoft.com/pkiops/certs

配信の最適化を使用する場合に必要なエンド

Windows Update を行う場合に配信の最適化機能を使用する場合、前述のエンドポイントに加え配信の最適化で使用されるエンドポイントを許可する必要があります。

詳細については以下の公開情報に記載がございますので、ご参考頂けますと幸いです。

Title：配信の最適化ワークフロー、プライバシー、セキュリティ、エンドポイント

URL： https://learn.microsoft.com/ja-jp/windows/deployment/do/delivery-optimization-workflow

Azure Firewall での Windows Update 通信の許可について

Azure Firewall を利用している環境では、Application Rule で FQDN タグ「WindowsUpdate」を許可することが可能です。
本タグを許可することで Windows Update に必要な通信先を許可することが可能となりますので、ご参考頂けますと幸いです。

Title：FQDN タグの概要

URL： https://learn.microsoft.com/ja-jp/azure/firewall/fqdn-tags

補足情報

エンドポイントへの疎通に問題が疑われるエラーについて

以下のようなエラーが生じている場合、インターネット上のエンドポイントへの疎通に問題がある可能性が推測されます。

< 公開情報 >

Title：エラー メッセージ (Winhttp.h)

URL： https://learn.microsoft.com/ja-jp/windows/win32/winhttp/error-messages

Title：WUA ネットワーク エラー コード

URL： https://learn.microsoft.com/ja-jp/windows/win32/wua_sdk/wua-networking-error-codes-

[特記事項]

本情報の内容（添付文書、リンク先などを含む）は、作成日時点でのものであり、予告なく変更される場合があります。

※本記事はマイクロソフト社員によって公開されております。

概要

本記事では、更新プログラムを Windows Server Update Services (以降、 WSUS) や Configuration Manager (以降、 CM) で配信されている環境にて、 WSUS / CM サーバー側で承認済みの更新プログラムがクライアント側で検出されず、 “最新の状態です” のメッセージから変わらない場合にクライアント側でご確認いただきたいポイントを何点かご紹介させていただきます。

なお、 WSUS サーバー側のチェックポイントにつきましては、別途弊社 Configuration Manager / WSUS サポート チームにて同様のブログ記事を公開しておりますので、必要に応じてご参照くださいますと幸いです。

WSUS から更新プログラムが配信されないときのチェックポイント | Japan Microsoft Configuration Manager Support Team Blog

更新プログラムが検出されない事象について

WSUS / CM サーバー側で承認済みの更新プログラムがクライアント側で検出されない場合、可能性の一つとして、デュアル スキャンによる影響が疑われます。
デュアル スキャンは WSUS や CM から更新プログラムを受信するよう設定されているクライアントにおいて、インターネット上の Windows Update サーバーに対しても更新プログラムのスキャンを行う動作を指します。
この動作は特定のグループ ポリシーなどが設定されている場合に行われるものとなりますが、デュアル スキャン状態での運用を想定しない環境では WSUS / CM サーバー側で承認済みの更新プログラムが検出されない場合があります。

デュアル スキャン状態であるかの確認方法

クライアント側で以下の手順を行うことで確認することが可能です。

1. コマンド プロンプトにて以下のコマンドを実行します。

powershell "(New-Object -ComObject "Microsoft.Update.ServiceManager").Services | ft Name,ServiceID, IsDefaultAUService"

2. 実行結果を確認し、以下のように “Windows Server Update Service” 以外のサービスの [IsDefaultAUService] 列が True となっている場合、デュアル スキャン状態であると判断できます。

1
2
3
4
5
6
7
8

C:\Windows\System32>powershell "(New-Object -ComObject "Microsoft.Update.ServiceManager").Services | ft Name,ServiceID, IsDefaultAUService"

Name                          ServiceID                            IsDefaultAUService
----                          ---------                            ------------------
DCat Flighting Prod           8b24b027-1dee-babb-9a95-3517dfb9c552              False
Windows Store (DCat Prod)     855e8a7c-ecb4-4ca3-b045-1dfa50104289              False
Windows Server Update Service 3da21691-e39d-4da6-8a4b-b43877bcb1b7              False
Windows Update                9482f4b4-e343-43b6-b170-9a65bc822c77               True

該当する場合、以下の確認ポイントをご確認、ご対応いただき、デュアル スキャンの制御または無効化を試みます。

確認ポイント その1 : デュアル スキャンを制御するポリシーの設定

デュアル スキャンの動作を制御するポリシーを明示的に設定することで、承認済みの更新プログラムが検出されるかをご確認ください。

Windows 10 バージョン 1909 以前および Windows Server 2016、2019

通常の更新プログラムのチェック時において、デュアル スキャンの動作を無効化する以下のポリシーを有効化します。

1
2

- [コンピューターの構成] - [ポリシー] - [管理用テンプレート] - [Windows コンポーネント] - [Windows Update]
  - Windows Update に対するスキャンを発生させる更新遅延ポリシーを許可しない

Windows 10 バージョン 2004 以降および Windows Server 2022 以降

更新プログラムごとにスキャン ソースを指定可能な以下のポリシーにて、Windows Server Update Service を指定します。

1
2
3
4

※ OS バージョンによりパスが異なります。
- [コンピューターの構成] - [ポリシー] - [管理用テンプレート] - [Windows コンポーネント] - [Windows Update] もしくは
- [コンピューターの構成] - [ポリシー] - [管理用テンプレート] - [Windows コンポーネント] - [Windows Update] - [Windows Server Update Service から提供される更新プログラムの管理]
  - Windows Update の特定のクラスにソース サービスを指定する

確認ポイント その2 : デュアル スキャン状態となるグループ ポリシー (あるいはレジストリ) の削除

ローカル グループ ポリシーや GPO などで以下のポリシーを設定されている場合は削除します。

1
2
3
4
5
6
7

※ OS バージョンによりパスが異なります。
- [コンピューターの構成] - [ポリシー] - [管理用テンプレート] - [Windows コンポーネント] - [Windows Update] - [Windows Update の延期] もしくは      
- [コンピューターの構成] - [ポリシー] - [管理用テンプレート] - [Windows コンポーネント] - [Windows Update] - [Windows Update for Business] もしくは      
- [コンピューターの構成] - [ポリシー] - [管理用テンプレート] - [Windows コンポーネント] - [Windows Update] - [Windows Update から提供される更新プログラムの管理]      
  - [品質更新プログラムをいつ受信するかを選択してください]
  - [プレビュー ビルドや機能更新プログラムをいつ受信するかを選択してください] (もしくは [機能更新プログラムをいつ受信するかを選択してください])
  - [ターゲット機能更新プログラムのバージョンを選択する]

削除後はコマンド プロンプトにて gpupdate /force コマンドを実行し、グループ ポリシーを再更新します。

(あるいはレジストリを直接編集し、設定されている場合は以下のレジストリを削除します。)

1
2
3
4
5
6
7
8
9
10

・ HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\DeferQualityUpdates
・ HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\DeferQualityUpdatesPeriodInDays
・ HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\DeferFeatureUpdatesPeriodInDays
・ HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\PauseQualityUpdates
・ HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\PauseQualityUpdatesStartTime
・ HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\DeferFeatureUpdates
・ HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\PauseFeatureUpdates
・ HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\PauseFeatureUpdatesStartTime
・ HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\BranchReadinessLevel
・ HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\TargetReleaseVersionInfo

確認ポイント その3 : Windows Update に関連するグループ ポリシーのキャッシュの削除

グループ ポリシー削除後もキャッシュ情報に残存した情報により、引き続きデュアル スキャンが有効な状態となる場合が過去事例より報告されております。
つきましては、前項実施後に合わせて以下のこれらグループ ポリシーに関するキャッシュ情報 (レジストリ キー) も削除します。

1
2

・ HKLM\SOFTWARE\Microsoft\WindowsUpdate\UpdatePolicy\GPCache\CacheSet001\WindowsUpdate
・ HKLM\SOFTWARE\Microsoft\WindowsUpdate\UpdatePolicy\GPCache\CacheSet002\WindowsUpdate

確認ポイント その4 : 更新の一時停止 & 再開操作による更新の一時停止に関する残存レジストリの削除

(キャッシュを含めた) グループ ポリシーのほかに、過去に更新の一時停止を行った際に作成されたレジストリが残存していることに起因して、同様にデュアル スキャンが行われる事例が報告されております。
残存したレジストリは下記操作を行うことで削除することが可能です。

【操作手順】

1. [Windows Update] 画面を開き、 [1 週間一時停止する] (もしくは [更新を 7 日間一時停止]) を押下します。

2. 一時停止状態となりましたら、再度 [更新の再開] を押下します。

ここまでの確認ポイントをご確認、ご対応いただきましたら、念のため下記ページの手順にて Windows Update に関するキャッシュ情報を削除の上、改めて更新プログラムのスキャンを実行いただき、承認済みの更新プログラムが検出されるかをご確認ください。

Windows Update クライアントの情報をクリアにする手順 | Microsoft Japan Windows Technology Support Blog

[特記事項]

本情報の内容（添付文書、リンク先などを含む）は、作成日時点でのものであり、予告なく変更される場合があります。

みなさま、こんにちは。Windows サポート チームです。
本記事では Windows クライアント OS における自動修復およびインプレース アップグレードによる修復の方法をご紹介します。
Windows クライアント OS ではなく、Windows Server 2025 などの サーバー OS をご利用の場合は、下記の記事をご覧ください。

更新プログラム適用に伴う破損修復 (サーバー編)

なお、各手順をご実施前に、念のため各種データのバックアップをご実施いただくことをお勧めいたします。

目次

0. 全体の流れ
1. 事前準備
2. 自動修復を実施します
3. 更新プログラムの再適用
4. インプレース アップグレードによる修復
　4-1. オンプレミス環境の現在のバージョンの Windows を再インストールして問題を修正する
　4-2. オンプレミス環境の ISO メディアを使用したインプレース アップグレード
　4-3. Azure VM 環境のインプレース アップグレード
5. クリーン インストールおよび環境の再構築について

0. 全体の流れ

1. 事前準備

更新プログラムの適用に失敗し、以下の公開情報に記載されているような OS の破損が疑われるエラー コードが確認された場合、修復コマンドを実施によって事象が改善する場合があります。

タイトル : Common corruption errors
URL : https://learn.microsoft.com/en-us/troubleshoot/windows-server/installing-updates-features-roles/fix-windows-update-errors?utm_source=chatgpt.com#common-corruption-errors

その事前準備として、以下の手順をご実施ください。

Windows 11 24H2 以降 : Windows Update に接続できるよう、以下のグループポリシーを一時的に設定しておきます。

• [コンピューターの構成] - [管理用テンプレート] - [システム] - [オプション コンポーネントのインストールおよびコンポーネントの修復のための設定を指定する] : 無効 or 未構成

Windows 11 23H2 まで : Windows Update に接続できるよう、以下のグループポリシーを一時的に設定しておきます。

• [コンピューターの構成] - [管理用テンプレート] - [システム] - [オプション コンポーネントのインストールおよびコンポーネントの修復のための設定を指定する] : 有効

    項目 [Windows Server Update Service (WSUS) の代わりに、Windows Update から修復コンテンツとオプションの機能を直接ダウンロードする] にチェック追加

• [コンピューターの構成] - [管理用テンプレート] - [Windows コンポーネント] - [Windows Update] - [インターネット上の Windows Update に接続しない] : 無効 or 未構成

• [コンピューターの構成] - [管理用テンプレート] - [システム] - [インターネット通信の管理] - [インターネット通信の設定] - [Windows Update のすべての機能へのアクセスをオフにする] : 無効 or 未構成

• [コンピューターの構成] - [管理用テンプレート] - [Windows コンポーネント] - [Windows Update] - [Windows Server Update Service から提供される更新プログラムの管理] - [Windows Update の特定のクラスにソースサービスを指定する] : 無効 or 未構成

2. 自動修復を実施します

以下の公開情報の手順に従い、管理者権限で以下 2 つの自動修復コマンドを実行します。

1. DISM.exe /Online /Cleanup-image /Restorehealth
2. sfc /scannow

タイトル : システム ファイル チェッカー ツールを使用して不足または破損しているシステム ファイルを修復する
URL : https://support.microsoft.com/ja-jp/topic/79aa86cb-ca52-166a-92a3-966e85d4094e

実施手順

1. コマンド プロンプトを管理者として起動します。

2. 以下のコマンドを入力します。

   1	DISM.exe /Online /Cleanup-image /RestoreHealth

3. 「復元操作は正常に完了しました」 と完了しましたら、 続けて次のコマンドを実行します。

   1	sfc /scannow

4. sfc /scannow のコマンドが完了しましたら、 3. 更新プログラムの再適用 にお進みください。

なお、手順 3 で 「ソース ファイルが見つかりませんでした」というエラーが発生した場合、修復に必要なソースが見つからないか、取得に失敗した可能性があります。
その場合は、4. インプレース アップグレードによる修復 に進んでください。

3. 更新プログラムの再適用

更新プログラムの再適用を行い、正常に適用できた場合：作業完了
更新プログラムの再適用後も、適用できなかった場合： 4 へ

4. インプレース アップグレードによる修復

後述のいずれかの方法でインプレース アップグレードを実施ください。
実施後に更新プログラムの適用を行い、事象が改善するか確認ください。

4-1. オンプレミス環境の現在のバージョンの Windows を再インストールして問題を修正する

下記公開情報を元に、Windows Update を使用したインプレース アップグレードを実施ください。

タイトル: 現在のバージョンの Windows を再インストールして問題を修正する
URL: https://support.microsoft.com/ja-jp/windows/497ac6da-7cac-4641-82a5-f50398d879a0

「現在のバージョンの Windows を再インストールして問題を修正する」 が利用不可能あるいは実施しても改善しない場合：4-2 へ

4-2. オンプレミス環境の ISO メディアを使用したインプレース アップグレード

手順は以下のとおりです。

1. ご利用の Windows と同じバージョンの OS イメージ (ISO ファイルでも DVD や USB 等の物理メディアでも可) を用意します。
2. ISO ファイルの入手方法につきましては、補足情報 をご参考ください。
3. OS イメージ内の setup.exe を実行します。
4. 「セットアップ」の画面が立ち上がりますので、画面にしたがって進めていきます。
5. 「インストール準備完了」という画面で、ユーザー情報およびアプリケーションが引き継がれる形となっているかを確認します。
6. 引き継がれる設定となっている場合は「インストール」を選択し、インプレース アップグレードを進めます。
7. インプレース アップグレードの完了を待ちます。処理中は複数回の OS 再起動が発生します。

以上で手順は完了です。更新プログラムを適用します。
更新プログラムが適用できない場合や、ISO メディアによるインプレース アップグレードができない場合：5へ

4-3. Azure VM 環境のインプレース アップグレード

Azure VM 環境の場合、以下の公開情報を参考し、Azure 環境でインプレース アップグレードを実施します。

タイトル : In-place upgrade for supported VMs running Windows in Azure (Windows client)
URL : https://learn.microsoft.com/en-us/troubleshoot/azure/virtual-machines/windows/in-place-system-upgrade?toc=%2Fazure%2Fvirtual-machines%2Ftoc.json

以上で手順は完了です。更新プログラムを適用します。
更新プログラムが適用できない場合や、Azure VM 環境のインプレース アップグレードができない場合：5へ

5. クリーン インストールおよび環境の再構築について

インプレース アップグレード後も事象が改善されない場合、オンプレミス環境につきましては OS のクリーン インストールを、Azure VM 環境につきましては、環境を再構築することをお勧めいたします。
今すぐ再構築することが難しい、もしくは再構築を実施する前に、手動での修復を試したい、という場合は、以下のブログ記事を参考し、手動による修復をお試しいただけます。

更新プログラム適用に伴う破損修復 (手動修復編)

[補足事項] インプレース アップグレードに使用する ISO メディアの入手方法

・ インプレース アップグレードする OS が最新版の Home / Pro / Education の場合は、 以下の URL から Windows 11 のインストール メディア作成ツールを使用し、ISO メディアを作成してください。

タイトル : Windows 11 のダウンロード
URL : https://www.microsoft.com/ja-jp/software-download/windows11
参照個所 : Windows 11 のインストール メディアを作成する

・ Enterprise エディションの場合で、ボリューム ライセンス契約をお持ちの場合は、ご契約のアカウントにて Microsoft 365 管理センターより入手ください。
入手方法についてご不明な点がありましたら、以下 VLSC 窓口にご相談ください。

1
2
3
4
5
6
7
8
9
10

■ VLSC 窓口情報
VLSC (Volume Licensing Service Center)
電話番号：0120-737-565　
受付時間 : 平日 9:00 - 17:30 (土日祝、弊社指定休業日を除く)
Volume Licensing Support Requests
　Web フォーム: https://support.serviceshub.microsoft.com/supportforbusiness/onboarding?origin=/supportforbusiness/create
　公開情報: https://learn.microsoft.com/ja-jp/microsoft-365/commerce/licenses/contact-vl-support?view=o365-worldwide
お問い合わせの際は以下をお手元にご用意いただけますようお願いいたします。
　- ライセンス契約の契約番号
　- ライセンス契約にご登録のメール アドレス

[特記事項]

本情報の内容（添付文書、リンク先などを含む）は、作成日時点でのものであり、予告なく変更される場合があります。

みなさま、こんにちは。Windows サポート チームです。
本記事では Windows Server OSにおける自動修復およびインプレース アップグレードによる修復の方法を紹介します。
Windows Server OS ではなく、Windows 11 などの Windows クライアント OS をご利用の場合は、下記の記事をご覧ください。

更新プログラム適用に伴う破損修復 (クライアント編)

なお、各手順をご実施前に、念のため各種データのバックアップをご実施いただくことをお勧めいたします。

目次

0. 全体の流れ
1. 事前準備
2. 自動修復を実施します。
　2-1.以下の公開情報の手順に従い、管理者権限で以下 2 つの自動修復コマンドを実行します。
　2-2.実行結果を確認します。
3. 更新プログラムの再適用
4. インプレース アップグレードによる修復
　4-1 インプレース アップグレードの事前確認
　　4-1-1. ISO を利用したインプレース アップグレード手順
　　4-1-2. Azure 環境でインプレース アップグレードする手順
5. 再構築について

0. 全体の流れ

1. 事前準備

Windows Server 2025 以降： インターネット上の Windows Update に接続できるよう、以下のグループポリシーを一時的に設定します。

• [コンピューターの構成] - [管理用テンプレート] - [システム] - [オプション コンポーネントのインストールおよびコンポーネントの修復のための設定を指定する] : [無効] または [未構成]

Windows Server 2022 以前： インターネット上の Windows Update に接続できるよう、以下 3 つのグループポリシーを一時的に設定します。

• [コンピューターの構成] - [管理用テンプレート] - [システム] - [オプション コンポーネントのインストールおよびコンポーネントの修復のための設定を指定する] : [有効]

    項目 [Windows Server Update Service (WSUS) の代わりに、Windows Update から修復コンテンツとオプションの機能を直接ダウンロードする] にチェック追加

• [コンピューターの構成] - [管理用テンプレート] - [Windows コンポーネント] - [Windows Update] - [インターネット上の Windows Update に接続しない] : [無効] または [未構成]

• [コンピューターの構成] - [管理用テンプレート] - [システム] - [インターネット通信の管理] - [インターネット通信の設定] - [Windows Update のすべての機能へのアクセスをオフにする] : [無効] または [未構成]

2. 自動修復を実施します。

2-1.以下の公開情報の手順に従い、管理者権限で以下 2 つの自動修復コマンドを実行します。

1. DISM.exe /Online /Cleanup-image /Restorehealth
2. sfc /scannow

タイトル: システム ファイル チェッカー ツールを使用して不足または破損しているシステム ファイルを修復する
URL: https://support.microsoft.com/ja-jp/topic/79aa86cb-ca52-166a-92a3-966e85d4094e

2-2.実行結果を確認します。

コマンドが正常に完了した場合：3 へ
コマンドがエラーで終了した場合：4 へ

3. 更新プログラムの再適用

正常に適用できた場合: 作業終了
適用できなかった場合: 4 へ

4. インプレース アップグレードによる修復

4-1 インプレース アップグレードの事前確認

サーバーにインストールしている役割と機能によっては、インプレース アップグレードがサポートされない場合はあるため、以下のページに “Upgradeable in-place ?” が Yes である環境構成になっているか、確認します。
※ 各項目に該当するか確認するのに工数を要する見込みですので、より早急にに解決したい場合は、OS の再構築をご検討ください。

タイトル: Upgrade and migrate roles and features in Windows Server
URL: https://learn.microsoft.com/en-us/windows-server/get-started/upgrade-migrate-roles-features

インプレース アップグレードがサポートされる OS であることを確認します。
オンプレミス環境の場合：4-1-1へ
Azure Edition でない Azure 環境の場合：4-1-2へ
Azure Edition 環境の場合： 5へ

4-1-1. ISO を利用したインプレース アップグレード手順

1. ご利用の Windows と同じバージョンの OS イメージ (ISO ファイルでも DVD や USB 等の物理メディアでも可) を用意します。
   ISO ファイルの入手方法につきましては、補足情報 をご参考ください。
2. 対象となるマシンへ OS イメージをマウントします。
3. OS イメージ内の setup.exe を実行します。
4. 「セットアップ」の画面が立ち上がりますので、画面にしたがって進めていきます。
5. 「インストール準備完了」という画面で、ユーザー情報およびアプリケーションが引き継がれる形となっているかを確認します。
6. 引き継がれる設定となっている場合は「インストール」を選択し、インプレース アップグレードを進めます。
7. インプレース アップグレードの完了を待ちます。処理中は複数回の OS 再起動が発生します。

4-1-2. Azure 環境でインプレース アップグレードする手順

以下の公開情報を参考し、Azure 環境でインプレース アップグレードを実施します。
タイトル: In-place upgrade for VMs running Windows Server in Azure
URL: https://learn.microsoft.com/en-us/azure/virtual-machines/windows-in-place-upgrade

上記の操作手順に不明点があり、サポートを受ける場合は、以下のブログ情報を参考し、お問い合わせを発行できます。

タイトル：お問い合わせの発行方法について
URL: https://jpaztech.github.io/blog/information/How-to-inquiry-to-the-Azure-Support/

5. 再構築について

Azure Edtion に該当する場合、インプレース アップグレードはサポートされていないため、再構築する必要があります。
また、前述したインプレース アップグレードを実施しても事象が解消しなかった場合も、再構築することをお勧めいたします。
今すぐ再構築することが難しい、もしくは再構築を実施する前に、手動での修復を試したい、という場合は、以下のブログ記事を参考し、手動による修復をお試しいただけます。

更新プログラム適用に伴う破損修復 (手動修復編)

[補足情報] インプレース アップグレードに使用する ISO メディアの入手方法

ボリュームライセンス(VLSC)契約をお持ちの場合は、ご契約のアカウントにて Microsoft 365 管理センターより入手ください。
入手方法についてご不明な点がありましたら、以下 VLSC 窓口にご相談ください。

1
2
3
4
5
6
7
8
9
10

■ VLSC 窓口情報
VLSC (Volume Licensing Service Center)
電話番号：0120-737-565　
受付時間 : 平日 9:00 - 17:30 (土日祝、弊社指定休業日を除く)
Volume Licensing Support Requests
　Web フォーム: https://support.serviceshub.microsoft.com/supportforbusiness/onboarding?origin=/supportforbusiness/create
　公開情報: https://learn.microsoft.com/ja-jp/microsoft-365/commerce/licenses/contact-vl-support?view=o365-worldwide
お問い合わせの際は以下をお手元にご用意いただけますようお願いいたします。
　- ライセンス契約の契約番号
　- ライセンス契約にご登録のメール アドレス

[特記事項]

本情報の内容（添付文書、リンク先などを含む）は、作成日時点でのものであり、予告なく変更される場合があります。

本章は以下の自動修復編の修復を実行しても、更新プログラムの適用が成功しない場合に、手動による修復を試みる章です。
まだご覧になっていない場合は、OS の種類に応じて確認ください。

更新プログラム適用に伴う破損修復 (クライアント編)
更新プログラム適用に伴う破損修復 (サーバー編)

なお、各手順をご実施前に、念のため各種データのバックアップをご実施いただくことをお勧めいたします。

目次

0. 全体の流れ
1 DISM /Online /Cleanup-Image /RestoreHealth コマンドを実行する
2 修復ソースの入手および修復手順
　2-1 CBS ログから破損個所を確認する
　2-2 修復ソースを特定する
　　2-2-1 ISO メディアによる修復をする
　　2-2-2 修復用の msu ファイルを入手する
　2-3 修復ソースが入手できる別環境を構築する
　　2-3-1 msu ファイルを別環境に当てて、修復用ファイルを抽出する
　2-4 RestoreHealth コマンドの結果を確認する
　2-5 更新プログラムを適用する
3. 新規構築および クリーンインストールを検討する

0. 全体の流れ

1 DISM /Online /Cleanup-Image /RestoreHealth コマンドを実行する

クライアント 編、サーバー 編でRestoreHealth コマンドが正常終了しない場合、修復に必要なデータ (修復ソース) が取得できないものの、RestoreHealth コマンドで検出できる軽微な破損が残存している可能性があります。
その場合、修復ソースを個別に用意のうえ修復することで、更新プログラムの適用に成功する可能性がありますので、2.修復ソースの入手および修復手順へお進みください。

一方で、RestoreHealth コマンドが正常終了した後も更新プログラムの適用に失敗する場合、軽微な破損ではなく、レジストリの一部に不整合が起きているなど、
潜在的な破損が生じている可能性がありますので、3. 新規構築および クリーンインストールを検討するへお進みください。

2 修復ソースの入手および修復手順

2-1 CBS ログから破損個所を確認する

以下手順を実施し、破損個所を特定します。

1. RestoreHealth コマンド実行後に、事象が発生している端末にて %WinDir%\Logs\CBS\CBS.log あるいは CbsPersist_XXXX.logを確認します。

2. “Checking System Update Readiness”で CBS ログ内を検索します。
   “Checking System Update Readiness”の直下にコンポーネント名が列挙されている場合、破損しているコンポーネントの具体的な情報をご確認いただけます。

Checking System Update Readiness.    (p)    CSI Payload Corrupt           (n)           amd64_microsoft-windows-a..modernappmanagement_31bf3856ad364e35_10.0.19045.3636_none_23b3b3ece690d77b\EnterpriseModernAppMgmtCSP.dll    (p)    CBS MUM Missing               (n)           Microsoft-Windows-Client-Features-Package~31bf3856ad364e35~amd64~~10.0.19045.4291    (p)    CSI Manifest Corrupt          (n)           wow64_microsoft-windows-audio-mmecore-acm_31bf3856ad364e35_10.0.19045.1_none_a12b40f4b4c7b751    (p)    CSI Manifest Corrupt          (n)           wow64_microsoft-windows-audio-volumecontrol_31bf3856ad364e35_10.0.19045.3636_none_4514b27cf12f35d5Summary:Operation: Detect and Repair Operation result: 0x800f081fLast Successful Step: Remove staged packages completes.Total Detected Corruption: 4    CBS Manifest Corruption: 4    CBS Metadata Corruption: 0    CSI Manifest Corruption: 0    CSI Metadata Corruption: 0    CSI Payload Corruption: 0Total Repaired Corruption: 0    CBS Manifest Repaired: 0    CSI Manifest Repaired: 0    CSI Payload Repaired: 0    CSI Store Metadata refreshed: FalseStaged Packages:    CBS Staged packages: 0    CBS Staged packages removed: 0

3. 破損しているコンポーネントの Update Build Revision (UBR) 番号を確認します。
   前述の表示例の場合、”19045.3636” と”19045.1” と “19045.4291” が破損個所のUpdate Build Revision (UBR) 番号です。
   修復ソースは OS バージョンによって収集方法が異なりますので、事前にOS バージョンを確認ください。

前提として弊社からのファイル提供はライセンス観点から実施できず、お客様にてご用意いただく必要があります。

OS バージョン( Windows 10 まで / Windows Server 2022 まで)の場合 ：2-2 へ
OS バージョン( Windows 11 以降 / Windows Server 2025 以降)の場合 ：2-3 へ

[補足情報]

Update Build Revision (UBR) に関する情報は以下を参考にしてください。
Windows 11 - release information | Microsoft Learn
Windows 10 リリース情報 | Microsoft Learn
Windows Server のリリース情報 | Microsoft Learn

2-2 修復ソースを特定する

破損コンポーネントにUBR 1 (XXXX.1)が存在するか確認します。

破損コンポーネントにUBR 1 (XXXX.1)がある場合：2-2-1 へ
破損コンポーネントにUBR 1 (XXXX.1)がない場合：2-2-2 へ

2-2-1 ISO メディアによる修復をする

事前準備
UBR 1 (XXXX.1) が含まれる場合は、ISO メディアから修復ソースを入手する必要がありますので、UBR に対応する OS バージョンの ISO メディアをご用意ください。
もしお手元にない場合は、更新プログラム適用に伴う破損修復 (サーバー編) ISO メディアの入手方法 をご確認ください。

1. 事前準備いただいた ISO メディアをマウントします。

2. 管理者権限で起動したコマンドプロンプトより以下のコマンドを実行し、ISO メディアに含まれるエディションを確認のうえ、修復対象の OS エディションに対応するインデックス番号をメモします。

1
2
3
4
5
6

DISM /Get-WimInfo /WimFile:"<Install.wim のパス>"
 
実行例) ISO イメージ（メディア）を F ドライブでマウントした場合
DISM /Get-WimInfo /WimFile:F:\sources\install.wim
 
補足 : Install.wim はマウントしたディレクトリの source フォルダに存在します。

3. ISO ファイルに含まれる install.wim を使用し、修復を行います。

1
2
3
4

DISM /Online /Cleanup-Image /RestoreHealth /source:WIM:<ドライブ名>:\Sources\Install.wim:<Index番号> /LimitAccess
 
実行例)
DISM /Online /Cleanup-Image /RestoreHealth /source:WIM:F:\Sources\Install.wim:1 /LimitAccess

以上で手順は完了です。
破損コンポーネントにUBR 1 (XXXX.1) 以外の UBR があるか確認します。

破損コンポーネントにUBR 1 (XXXX.1) 以外の UBR がある場合：2-2-2 へ
破損コンポーネントにUBR 1 (XXXX.1) 以外の UBR がない場合：2-3 へ

2-2-2 修復用の msu ファイルを入手する

1. Update Build Revision (UBR)に紐づく更新プログラム(KB 番号)を特定します。
   例の場合、UBR 3636 は KB5031445に対応し、UBR 4291 は KB5036892に対応している場合があります。
   ※もし厳密に一致してる KB 番号が存在しない場合は、破損コンポーネントの UBR より大きくもっとも近い KB 番号を参照ください。

   2023 年 10 月 26 日 ? KB5031445 (OS ビルド 19045.3636) プレビュー
   2024 年 4 月 9 日 ? KB5036892 (OS ビルド 19044.4291 および 19045.4291)

2. 弊社カタログサイトから、特定した KB 番号を検索してスタンドアロンパッケージ(.msu)をダウンロードします。

   タイトル: Microsoft Update カタログ
   URL:https://www.catalog.update.microsoft.com/Home.aspx

3. 入手した更新プログラムのスタンドアロンパッケージ(.msu)を以下の公開情報の手順で展開します。

   タイトル: システム ファイル チェッカー ツールを使用して不足または破損しているシステム ファイルを修復する
   URL:https://learn.microsoft.com/ja-jp/troubleshoot/windows-server/support-tools/scripts-extract-msu-cab-files

4. 管理者権限のコマンドプロンプトにて Dism コマンドで修復ソースを指定して修復します。

1
2
3
4
5
6

構文)
DISM /Online /Cleanup-Image /RestoreHealth /source:<手順 2-2 手順 3 で "C:\<path>\<destination>"に指定したフォルダパス> /LimitAccess

実行例) 
DISM /Online /Cleanup-Image /RestoreHealth /source:C:\FixSources /LimitAccess
※完了まで 10 ～ 30　分程度要します。

以上で手順は完了です。2-3 へ進んでください。

2-3 修復ソースが入手できる別環境を構築する

事象が発生している端末にて %WinDir%\Logs\CBS\CBS.log あるいは CbsPersist_XXXX.logを確認し、
最も新しいタイムスタンプの “Checking System Update Readiness”の直下に具体的なコンポーネントが列挙されているか確認します。

破損コンポーネントが存在する場合：2-3-1 へ
破損コンポーネントが存在しない場合：2-5 へ

2-3-1 msu ファイルを別環境に当てて、修復用ファイルを抽出する

1. Update Build Revision (UBR)に紐づく更新プログラム(KB 番号)を特定します。
   例の場合、UBR 3636 は KB5031445に対応し、UBR 4291 は KB5036892に対応している場合があります。
   ※もし厳密に一致してる KB 番号が存在しない場合は、破損コンポーネントの UBR より大きくもっとも近い KB 番号を参照ください。

   2023 年 10 月 26 日 ? KB5031445 (OS ビルド 19045.3636) プレビュー
   2024 年 4 月 9 日 ? KB5036892 (OS ビルド 19044.4291 および 19045.4291)

2. 弊社カタログサイトから、特定した KB 番号を検索してmsu ファイルをダウンロードします。

   タイトル: Microsoft Update カタログ
   URL:https://www.catalog.update.microsoft.com/Home.aspx

3. 入手した更新プログラムの msu ファイルを適用した別環境を構築します。
   ※UBR が複数ある場合は、UBRが小さい更新プログラムから順に適用して後述の修復ソースを入手します。

4. 破損したパッケージの種類によって、修復ソースを入手します。
   Checking System Update Readiness の一覧のパッケージ左記が種類になります。

   // 表示例

   Checking System Update Readiness. (p)    CSI Payload Corrupt           (n)           amd64_microsoft-windows-a..modernappmanagement_31bf3856ad364e35_10.0.19045.3636_none_23b3b3ece690d77b\EnterpriseModernAppMgmtCSP.dll (p)    CBS MUM Missing               (n)           Microsoft-Windows-Client-Features-Package~31bf3856ad364e35~amd64~~10.0.19045.4291 (p)    CSI Manifest Corrupt          (n)           wow64_microsoft-windows-audio-volumecontrol_31bf3856ad364e35_10.0.19045.3636_none_4514b27cf12f35d5

5. 種類と修復ソースの場所と用意の仕方に応じて、入手したパッケージを任意のフォルダに全て格納します。

   例) C:\FixSources

6. 管理者権限のコマンドプロンプトにて Dism コマンドで修復ソースを指定して修復します。

1
2
3
4
5
6

構文)
DISM /Online /Cleanup-Image /RestoreHealth /source:<2-3-1 手順 5 で用意した修復用ソースのフォルダパス> /LimitAccess

実行例) 
DISM /Online /Cleanup-Image /RestoreHealth /source:C:\FixSources /LimitAccess
※完了まで 10 ～ 30　分程度要します。

以上で手順は完了です。2-4 へ進んでください。
Kv

2-4 RestoreHealth コマンドの結果を確認する

RestoreHealth コマンドの結果を確認します。

成功した場合：2-5 へ
失敗した場合：2-1 へ

注意！
破損の修復は一度に全ての破損個所が特定されず、修復が完了したとしても、処理が進むことで潜在化していた破損が顕在化することで、
新たな破損を検出することがありますので、弊社過去事例におきましては、修復修復を繰り返さなければならない事例が多数あります。
そのため、もしお急ぎの場合は、更新プログラム適用に伴う破損修復 (クライアント編) や 更新プログラム適用に伴う破損修復 (サーバー編)で紹介いたしました通り、インプレース アップグレードの実施を検討ください。

2-5 更新プログラムを適用する

更新プログラムを適用します。

成功した場合：作業完了
失敗した場合：3 へ

3. 新規構築および クリーンインストールを検討する

今までご案内した手順においても修復が完了しない場合、OS 標準の機能より検出や修復が出来ないレジストリの不整合などが発生していることが予測されます。　　
OS 標準の機能より検出や修復が出来ない破損につきましては、原則新規構築や、クリーン インストールでの対応が必要となります。

[特記事項]
本情報の内容（添付文書、リンク先などを含む）は、作成日時点でのものであり、予告なく変更される場合があります。

こんにちは。 Windows プラットフォーム サポートの佐藤です。

弊社サポート サービスでは、お問い合わせ内容に深刻度を設けており、1, A ~ C に分類しています。
深刻度 A および 1 は緊急対応の扱いとなり、24 時間 365 日のテクニカル サポートを提供します。
ただし、深刻度 A および 1 はご利用いただけるシナリオや範囲に条件があるため、お客様の状況によっては深刻度 B または C への切り替えをご案内することがあります。

サポート開始後に深刻度の切り替えが必要となった場合、実質的な対応の開始までに時間を要してしまう可能性がございます。
本記事では、サポート サービスをスムーズにご利用いただくために、お客様がお問い合わせする際に指定いただく「深刻度 (重要度 / 緊急度) A」の詳細について紹介します。
なお、本記事は Windows Commercial サポートに関してまとめたものとなります。

※今後の説明については便宜上、深刻度 A および 1 は 「深刻度 A」 に統一して記載します。

▼ 深刻度 A の定義

以下のような状況に該当する場合に、深刻度 A でのサポートを提供します。

・重要なビジネスシステムの停止: 事業上のリスクの発生。重要なアプリケーションやソリューションの完全な喪失
・重要なビジネスシステムの劣化: 事業に相当の損失が発生し、断続的に業務遂行プロセスが停止する時

「重要なビジネスシステムの停止や劣化」とは、サーバーや認証機能などが停止して、多数のユーザーがログインできずに業務を遂行できないなど、ビジネスに多大な影響を及ぼすような危機的状況を示します。
例えば、製造業であれば生産ラインが止まる、金融業であれば取引システムダウン、医療関係であれば医療行為の妨げとなるなど、お客様のビジネスに大規模な損失や影響が発生している状態です。

上記のような状態ではなく、問題が起きた後の原因調査や一般的な技術サポートについては、深刻度 B または C でのサポート窓口営業時間内 (平日 9:00 - 17:30) での対応となります。
※ 土日祝日、年末年始、サポート情報 にてお知らせする休業日を除く

なお、プロジェクトの進捗に影響が出ているので対応を加速して欲しい、原因調査を営業時間外や休日も継続してほしい、といった内容は深刻度 A の定義には該当しません。

▼ 深刻度 A の対応範囲

深刻度 A の定義に該当している場合、24 時間 365 日、「重要なビジネスシステムの停止や劣化」などの危機的な状態の復旧・問題回避までを支援いたします。
なお、お客様側でも、サポート中は弊社エンジニアと常に電話で連絡が取れる体制を維持していただく必要があります。

お客様と連絡が取れないなどの理由で、支援を満足にご提供できないと弊社が判断した場合、または、お問い合わせ内容が深刻度 A に該当しない場合、お問い合わせの深刻度を B または C に変更のうえ、営業時間内での対応とさせていただくことがございます。

緊急対応を経て、業務が遂行できる状態まで回復できた際は、24 時間体制を解除し対応終了となります。復旧済みの問題に対する原因調査は、深刻度 B または C での営業時間内で承ります。

より具体的な状況について、以下にご案内いたします。(クリックして展開)

なお、復旧済みの問題に対する原因調査は、深刻度 B または C での営業時間内で承ります。

以上の通り、深刻度 A は危機的な状態の復旧・問題回避までを目的とした限定的な支援となります。一方で、深刻度 B や C は、お客様の状況や実現されたい内容にそってよりきめ細かなご支援を提供することができます。どのような支援を弊社サポートに希望されるかによって、深刻度を選定していただけますと幸いです。

なお深刻度の違いにかかわらず、どのようなお問い合わせにつきましても、サポート担当一人ひとりが誠心誠意をもってお客様の助けになるように努めてまいりますので、どうぞよろしくお願いいたします。

※本情報の内容（添付文書、リンク先などを含む）は、作成日時点でのものであり、予告なく変更される場合があります。

こんにちは。Windows Commercial Support Directory Services チームです。

本記事では、ドメイン コントローラー (以降 DC) に対して Windows Server バックアップを利用したベアメタル バックアップ/回復の実施手順をご案内します。
システム状態のバックアップ/リストアとは異なり、ベアメタル回復ではディスク全体を復元するため、OS やデータ ボリュームを含むサーバー全体を復元することが可能です。
また、本記事では Active Directory (AD) の観点から注意が必要な点についても合わせてご案内します。

事前確認事項

Active Directory データベースのスキーマ拡張の前など、ドメイン環境に大きな変更を加える作業の前には、ドメイン コントローラー全台でバックアップを取得することをお勧めいたします。
全台でバックアップを取得することで、万が一障害が発生した際にドメイン コントローラー全台でリストアを実施することにより、作業前までの状態にロールバックすることができます。

ドメイン コントローラーの Active Directory としての機能だけでなく、OS の状態をそのままバックアップ/リストアしたい場合には、Windows 標準の方法としてベアメタル回復でバックアップ/リストアする方法がございますが、ドメイン コントローラー全台をベアメタル回復しただけでは、SYSVOL の複製元となるドメイン コントローラーが存在しないため、複製障害の要因となりますのでご注意ください。
ドメイン コントローラー全台をベアメタル回復からリストアする際には、1 台目のドメイン コントローラーをベアメタル回復からリストアした後、1 台目のドメイン コントローラーのみ SYSVOL の複製元であることを明示するため、システム状態のリストア (authsysvol オプション付き) を実施する必要がございます。
2 台目以降のドメイン コントローラーにつきましては、複製先のドメイン コントローラーとなりますため、ベアメタル回復のリストアのみの実施で問題ございません。

ドメインコントローラーのベアメタル回復バックアップとリストア手順

バックアップとリストア手順はそれぞれ公開情報にまとまっております。「事前確認事項」に記載の通り、留意が必要なのはリストア時となります。それぞれ詳細を以下におまとめしております。バックアップ リストアに際しては、公開情報にある制限事項についてもご確認ください。

ベアメタル回復バックアップの手順

以下の公開情報を参考に、バックアップの作業を進めてください。「バックアップ手順」の手順 8 の [項目の選択] 画面で、ベアメタル回復にチェックを入れてバックアップを実施ください。

• Windows Server バックアップによるバックアップ手順

ベアメタル回復によるリストア手順

大きな流れとして以下のようになります。

1. 1 台目をベアメタル回復からリストアする。
2. 1 台目のシステム状態のリストア (authsysvol オプション付き)を実施する。
3. 2 台目以降をベアメタル回復からリストアする。

(1) 1 台目のドメイン コントローラーをベアメタル回復からリストアする手順

1. 以下の公開情報を参考に、ベアメタル回復のリストアを進めてください。

• Windows Server バックアップによるベアメタル リストア手順

2. ベアメタル回復によるリストアが完了したら、以下の公開情報にある「1 台目に復元する DC での手順」を参考に、SYSVOL の権限あるシステム状態の復元を実施ください。

• ドメイン コントローラーのバックアップとリストアについて

(2) 2 台目以降のドメイン コントローラーをベアメタル回復からリストアする手順

以下の手順を実施いただくだけで問題ございません。

• Windows Server バックアップによるベアメタル リストア手順

参考情報

• Active Directory の権限のある復元について

• ドメイン コントローラーのバックアップとリストアについて

• Windows Server バックアップによるバックアップ手順

• Windows Server バックアップによるベアメタル リストア手順

変更履歴

2026/3/5: 本記事の公開

本情報の内容（添付文書、リンク先などを含む）は、作成日時点でのものであり、予告なく変更される場合があります。

概要

本ブログ記事では、App Control for Business (日本語名: ビジネス向けアプリ コントロール) の基本的な構成方法について、よくお問い合わせいただくご質問内容も踏まえてご紹介します。
なお、App Control for Business についての詳細な情報は弊社公開情報に記載があるため、本ブログ記事では公開情報のご紹介も交えながら App Control for Business の構成方法を説明します。

※本ブログ記事では以下の条件を前提に説明をしますのであらかじめご了承ください。

• お問い合わせの比較的多い、ユーザーモードの実行可能ファイルの制御について言及します。
• App Control for Business は Windows Server でも利用可能ですが、本ブログ記事では Windows 11 のようなクライアント OS について言及します。
• 本ブログ記事で紹介するスクリプトについてはあくまでサンプル コードであり、実運用を踏まえた実装や動作検証等を別途ご実施ください。

App Control for Business とは

App Control for Business は、Windows 上でドライバーやアプリケーションなどの実行可能ファイル (例：.exe / .dll / .sys) の実行を制御する機能です。
制御可能なファイルの種類は以下の公開情報をご参照ください。

App Control for Business および AppLocker 機能の可用性

以前は Windows Defender Application Control (WDAC) や Microsoft Defender Application Control と呼ばれていましたが、2026 年現在は App Control for Business に名称が統一されています。
設定は OS 全体に適用され、デバイス上のすべてのアプリケーションを制御できます。
App Control for Business についての機能概要につきましては、以下の公開情報が参考になりますので是非ご参考にしていただければと思います。

App Control for Business と AppLocker の概要 - ビジネス向けアプリ コントロール

Windows では同様にアプリケーションの実行を制御する機能として AppLocker があります。
AppLocker についても上記の公開情報の AppLocker の項目へ記載がありますので、併せてご確認いただければと思います。
加えて、App Control for Business と AppLocker について比較した表も以下の公開情報へ記載されています。

App Control for Business および AppLocker 機能の可用性

App Control for Business と AppLocker の概要 - App Control または AppLocker を使用するタイミングを選択する にも記載がありますが、現在、AppLocker ではセキュリティ修正のみが行われており、新機能の追加については App Control for Business において継続的に行われているため、基本的には App Control for Business を利用して実行可能ファイルの実行制御を行うことをお勧めします。
ただし、AppLocker はユーザーやグループ単位での実行可能ファイルの実行制御ができますので、システム全体で実行可能ファイルの制御を希望しない場合は AppLocker を用いるなど、場合に応じて使い分けると良いです。
また、App Control for Business と AppLocker は共存して動作することができます。
App Control for Business と AppLocker が共存する場合、両方で許可されたときのみ実行可能ファイルは実行できます。
対して、App Control for Business と AppLocker のいずれかで実行可能ファイルの実行がブロックされる場合は、実行可能ファイルの実行はできません。
この動作を応用することで、App Control for Business で大まかなルールを作成し、AppLocker を用いて実行可能ファイルの実行制御を微調整していく、ということも可能です。

App Control for Business の設定について

App Control for Business の設定は XML 形式のポリシー ファイルを作成したうえで、XML ファイルをバイナリ変換して端末へ適用する、という流れが一般的な手順です。
App Control for Business のポリシー作成において、よくある作成方法として以下の方法があります。

1. Windows に既定で存在するサンプル ポリシーを拡張してポリシーを作成する
2. ゴールデン コンピューターを用意してポリシーを作成する

どちらの方法が良いか、ということは状況によって異なりますが「1. Windows に既定で存在するサンプル ポリシーを拡張してポリシーを作成する」でポリシーの構成を行うケースが多いものと考えています。
そのため、本ブログ記事では「1. Windows に既定で存在するサンプル ポリシーを拡張してポリシーを作成する」について集中的に説明します。
なお、「2. ゴールデン コンピューターを用意してポリシーを作成する」についての設定方法について簡単に説明をすると、マスターとなるゴールデン コンピューターを構築したうえで、C: 配下に含まれる実行可能ファイルを走査してポリシーを作成する方法です。
ただし、この方法は C: 配下のファイルをすべて走査するため、ポリシー ファイルの生成に時間を要することに加えて、C: 配下の実行可能ファイルの許可ルールがすべてポリシー ファイルへ記載されるため、ポリシーのファイル サイズがとても大きくなってしまいます。
特に Intune から App Control for Business のファイルを配信する場合は、Intune より配信可能なファイル サイズに制限があることから App Control for Business のポリシーを配信できなくなるようなケースもありますのでご留意いただければと思います。
ゴールデン コンピューターを用意したポリシーの作成方法については、英語の公開ブログではありますが、以下のブログが参考になりますので、ゴールデン コンピューターを用意したポリシーの作成を行う場合はぜひご参考ください。

Getting Started with Windows 10 Device Guard – Part 1 of 2
Getting Started with Windows 10 Device Guard – Part 2 of 2

それでは、以下より「1. Windows に既定で存在するサンプル ポリシーを拡張してポリシーを作成する」の方法でのポリシーの構成方法について説明します。
App Control for Business のポリシーの生成方法は大きく分けて以下の生成方法があります。

1. PowerShell スクリプトを用いた生成方法
2. App Control for Business Wizard を用いた生成方法

ただし、App Control for Business Wizard につきましては、ライセンスの都合上現状有姿での提供となっており、ソフトウェア自体に対する技術サポートが提供されておりませんので、本ブログ記事では「1. PowerShell スクリプトを用いた生成方法」について説明します。

ポリシーの種類

App Control for Business のポリシーには以下の種類があります。

1. Single policy
2. Multiple policy

上記について、「1. Single policy」については App Control for Business のポリシーを単一のファイルで表現する際に利用され、主に Windows Server 2016, Windows Server 2019, Windows 10 Enterprise LTSC 2019 などの OS において利用されていました。
また、Single policy の App Control for Business のポリシーは C:\Windows\System32\CodeIntegrity 配下のフォルダーへ SiPolicy.p7b という名前で配置して動作させる特徴があります。
ただし、Windows 10 バージョン 1903 および Windows Server 2022 より新しい OS では「2. Multiple policy」が利用可能であり、特に制約がなければ、より柔軟なポリシーの構成や管理が可能な「2. Multiple policy」を使用することをお勧めします。
そのため、本ブログ記事でも Multiple policy を前提に説明します。
なお、Multiple policy のポリシー ファイルは C:\Windows\System32\CodeIntegrity\CIPolicies\Active 配下のフォルダーへ {<PolicyID>}.cip というファイル名で配置されますが、この先の説明で Multiple policy についてお伝えしますのでここでは詳細の説明はしません。
ところで、App Control for Business は実行可能ファイルの実行制御を行う機能ですが、例外的にアプリケーションの実行制御を目的としない AppId Tagging policy というポリシーもあります。
このポリシーを使用すると、App Control for Business の設定に基づいてプロセスにタグを付与できます。
ただし、このポリシーはアプリケーションの実行を制御するものではなく、タグ付けのみを行います。
なぜこのようなポリシーがあるのかというと、Windows Firewall にはプロセスに付与されたタグを基にファイアウォールのルールを定義する機能があるためです。
例えば、特定のタグが付与されたプロセスからの HTTP 通信を許可または拒否する、といったシナリオを実現する際に、このポリシーを利用できます。(参考: App Control tagging policies)。

Base policy と Supplemental Policy

App Control for Business のポリシーの説明を行いましたので、Base policy と Supplemental policy について説明を行います。
Multiple policy を構成するポリシーとして、さらに Base policy と Supplemental policy というポリシーがあります。
Base policy は文字通りベースとなるポリシーであり、Supplemental policy は Base policy を拡張するポリシーです。
特に複雑な制御を行わない場合は Base policy のみで十分であり、Supplemental policy の作成は必須ではありません。
どのような場合に Supplemental policy を必要とするかということについて例を挙げて考えてみます。
例えばある会社で、会社全体では kaisya.exe の実行を許可しており、総務部では kaisya.exe に加えて soumu.exe の実行許可をして、労務部でも同様に roumu.exe の実行を許可するというシナリオがあったとします。
この場合、Base policy として kaisya.exe を許可し、Supplemental policy として soumu.exe の実行許可をしている総務部専用の policy と roumu.exe の実行を許可している労務部専用のポリシーを作成したうえで、総務部では kaisya.exe を許可している Base policy + soumu.exe を許可している Supplemental policy を適用し、労務部では kaisya.exe を許可している Base policy + roumu.exe を許可している Supplemental policy を適用することで、会社全体で共通するポリシーは Base policy にまとめて各部署専用のポリシーは Supplemental policy へ切り出す、というような運用ができます。

上記について詳細は ビジネス ポリシーに複数のアプリ制御を使用する へ記載がありますので、ぜひご参考にしていただければと思います。
今回は Supplemental Policy の作成については説明はしませんので、上記の公開情報を参考に構成していただければと思います。

ポリシーの大まかな種類の説明は以上です。
以下では具体的なポリシーの設定について説明します。

App Control for Business の状態

App Control for Business のポリシーを適用する手順を説明する前に、App Control for Business が構成されているかを確認する方法についてお伝えします。
App Control for Business の状態はシステム情報 (msinfo32) の [システムの要約] のうち “ビジネス向けアプリコントロール ポリシー” および “ビジネス向けアプリコントロールのユーザー モード ポリシー” にて確認することができます。
“ビジネス向けアプリコントロール ポリシー” はカーネル モードで動作するドライバー等の実行可能ファイルを制御する際に利用し、”ビジネス向けアプリコントロールのユーザー モード ポリシー” はユーザー モードで動作する実行可能ファイルを制御する際に利用します。
“ビジネス向けアプリコントロール ポリシー” は Windows 11 において既定で “強制” となっており、”ビジネス向けアプリコントロールのユーザー モード ポリシー” は既定で “監査” もしくは “無効” となっています。
このように App Control for Business の構成には “無効”, “監査”, “強制” の 3 つの状態が存在します。
“強制” の状態では、実行可能ファイルはブロックされます。
“監査” の状態では、実行可能ファイルは実際にはブロックされず、イベントログへ “もし強制状態であればこの実行可能ファイルは実行をブロックされていた” のような趣旨のイベントが発生します。
“無効” は文字通り App Control for Business の構成が行われていないことを示します。

とりあえずポリシーを適用してみる

ここでは Windows に既定で存在するサンプル ポリシーを利用して App Control for Business を構成する手順を紹介します。
今回は PowerShell コマンドで App Control for Business を構成します。
App Control for Business の構成自体は以下のコマンド レットを実行し、OS を再起動することで構成が完了します。

1
2
3
4
5
6

$DefaultWindowsPolicy=$env:windir+"\schemas\CodeIntegrity\ExamplePolicies\DefaultWindows_Enforced.xml"
[xml]$PolicyXML = Get-Content $DefaultWindowsPolicy
$PolicyId = $PolicyXML.SiPolicy.PolicyId
$PolicyPath="C:\Windows\System32\CodeIntegrity\CiPolicies\Active\"
$PolicyBin = $PolicyPath+$PolicyId+".cip"
ConvertFrom-CIPolicy $DefaultWindowsPolicy $PolicyBin

上記について少し丁寧に説明をします。
上記の PowerShell コマンドでは Windows に既定で存在するサンプル ポリシーを利用して App Control for Business を構成しているわけですが、サンプル ポリシーは %OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies 配下に存在します。
%OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies には様々なサンプル ポリシーが存在します。
各サンプル ポリシーの詳細な説明は以下の公開情報にありますのでぜひご参考にしていただければと思います。

App Control for Business の基本ポリシーの例

ここでは Windows に既定で存在する実行ファイルは実行を許可するポリシーである DefaultWindows_Enforced.xml を利用して App Control for Business を構成します。
なお、サンプル ポリシーとして DefaultWindows_Enforced.xml のほかに DefaultWindows_Enforced.xml もありますが、_Enforced を含むポリシーは “強制” のポリシーであり _Audit を含むポリシーは “監査” のポリシーです。

App Control for Business の構成を行うためには、ポリシーファイルである xml ファイルをバイナリ変換したうえで所定の場所へ配置する必要があります。
ConvertFrom-CIPolicy コマンドレットが App Control for Business の xml ファイルをバイナリ ファイルへ変換するコマンドとなっており、前述の計 6 行のコマンドを実行しますと %OSDrive%\Windows\System32\CodeIntegrity\CIPolicies\Active 配下へ {<ポリシー ID>}.cip というファイル名のファイルが作成されます。

なお、ConvertFrom-CIPolicy へコマンドの詳細の記載があります。

OS を再起動しますと前述の通り msinfo32 にて App Control for Business が強制になっていることが確認できます。
この状態で利用の許可されていない 3rd パーティ製のアプリケーションの実行を行うと App Control for Business によってアプリケーションの実行が制御されます。

App Control for Business のオプションを追加してみる

App Control for Business にはオプションという概念があります。
オプションを利用することで、App Control for Business のポリシーを強制モードにする、や、スクリプトに対する App Control for Business の制御が行われないようにする、といった、App Control for Business のポリシー全体の特性を決めるような設定ができます。
詳細は 表 1. ビジネス 向けアプリ制御ポリシー - ポリシー ルール オプション へ記載がありますのでぜひご参考にしてみてください。

ここではスクリプトを用いて App Control for Business のポリシーへオプションを追加する方法について記載します。
以下にサンプル スクリプトを記載しますが Set-RuleOption コマンドにてオプションを追加しています。
オプション 3 というのがオプション Audit mode を示します。
オプションの番号と機能の対応も 表 1. ビジネス 向けアプリ制御ポリシー - ポリシー ルール オプション へ記載があります。
以下のコマンドでは、もともと強制モードのポリシーである DefaultWindows_Enforced.xml へ Audit mode のポリシーを追加したので、DefaultWindows_Enforced.xml のポリシーは Audit mode で動作するようになります。
ぜひコマンドを実行し、OS を再起動のうえ、App Control for Business が監査モードで動作することをご確認いただければと思います。

1
2
3
4
5
6
7

$DefaultWindowsPolicy=$env:windir+"\schemas\CodeIntegrity\ExamplePolicies\DefaultWindows_Enforced.xml"
Set-RuleOption -FilePath $DefaultWindowsPolicy -Option 3 -Delete
[xml]$PolicyXML = Get-Content $DefaultWindowsPolicy
$PolicyId = $PolicyXML.SiPolicy.PolicyId
$PolicyPath="C:\Windows\System32\CodeIntegrity\CiPolicies\Active\"
$PolicyBin = $PolicyPath+$PolicyId+".cip"
ConvertFrom-CIPolicy $DefaultWindowsPolicy $PolicyBin

なお、Set-RuleOption へコマンドの詳細の記載があります。
上記ではオプションを追加するコマンドをご紹介しましたが、以下のように記載することでオプションを削除することもできます。

1

Set-RuleOption -FilePath $DefaultWindowsPolicy -Option 3 -Delete

App Control for Business のルールを追加してみる

App Control for Business にはルールという概念があります。
ルールを利用することで、特定のパスのファイルの実行は許可するようにしたり、特定の署名を持ったアプリの実行を許可する、などの制御ができます。
詳細は 表 2. App Control for Business ポリシー - ファイル ルール レベル へ記載がありますのでぜひご参考にしてみてください。

ここではスクリプトを用いて App Control for Business のポリシーへルールを追加する方法について記載します。
以下にサンプル スクリプトを記載しますが Merge-CIPolicy コマンドレットに対して -Rules オプションを指定してルールを追加しています。
例では $Rules 変数へ FilePath ルールで C:\my\* と C:\my2\* の実行許可を行っております。

1
2
3
4
5
6
7
8
9
10
11
12

$DefaultWindowsPolicy=$env:windir+"\schemas\CodeIntegrity\ExamplePolicies\DefaultWindows_Enforced.xml"
$WDACPolicy="C:\temp\DefaultWindows_Enforced.xml"

$Rules += New-CIPolicyRule -FilePathRule 'C:\my\*'
$Rules += New-CIPolicyRule -FilePathRule 'C:\my2\*'
Merge-CIPolicy -OutputFilePath $WDACPolicy -PolicyPaths $DefaultWindowsPolicy -Rules $Rules

[xml]$PolicyXML = Get-Content $WDACPolicy
$PolicyId = $PolicyXML.SiPolicy.PolicyId
$PolicyPath="C:\Windows\System32\CodeIntegrity\CiPolicies\Active\"
$PolicyBin = $PolicyPath+$PolicyId+".cip"
ConvertFrom-CIPolicy $WDACPolicy $PolicyBin

なお、Merge-CIPolicy へコマンドの詳細の記載があります。
実行を拒否するポリシーは以下のように記載することで生成することができます。

1

$Rules += New-CIPolicyRule -FilePathRule 'C:\my\*' -Deny

おわり

今回のブログでは App Control for Business の構成のために必要な基本的な概念の説明と具体的な設定方法についてご説明をいたしましたがいかがでしたでしょうか。
本ブログ記事が皆様の理解に役立つことになれば幸いです。

こんにちは、Windows サポート チームです。
今回は、Windows Server 2025 Standard Edition 環境において、Windows Admin Center (WAC) の GPU 拡張機能がホスト マシンの表示時に表示されない事象と、GPU 割り当て機能のエディション要件についてお知らせします。

対象

以下の条件に該当する環境が対象です。

• ホスト OS: Windows Server 2025 Standard Edition
• 管理ツール: Windows Admin Center (WAC)

事象

Windows Admin Center を使用してホスト マシンを表示する際、GPU の割り当てを管理するための GPU 拡張機能が画面上に表示されません。
そのため、WAC の GUI から 仮想マシン (VM) への GPU の設定操作を行うことができません。

原因

本事象には、以下の 2 つの要因が関係しています。

• 要因 1: Windows Admin Center 製品側の不具合
  ホスト OS が Windows Server 2025 Standard Edition である場合に、WAC の GPU 拡張機能が正しく表示されない不具合が存在することが確認されています。

• 要因 2: 構成によって必要な Windows Server エディションが異なる
  Hyper-V における GPU 割り当て機能 (GPU DDA および GPU パーティション分割 (GPU-P)) は、構成によって必要なエディションが異なります。

• 単一の Hyper-V ホストの場合、GPU DDA および GPU-P は Standard Edition・Datacenter Edition のいずれでも利用可能です。
• Hyper-V クラスター構成の場合、GPU DDA および GPU-P の利用には Datacenter Edition が必須です。これは仕様によるものであり、不具合ではございません。

Hyper-V クラスター環境における要件の詳細については、以下の公式ドキュメントをご参照ください。
Windows Server および Azure Local 上のクラスター化された VM で個別のデバイス割り当てで GPU を使用する | Microsoft Learn

WAC の GPU 拡張機能が表示されない問題について

現時点では、WAC の GPU 拡張機能が表示されない不具合に対する回避策はございません。
WAC 製品側の修正対応が完了するまでの間は、Powershell での操作をご検討ください。

PowerShell での操作方法は以下の公式ドキュメントをご参照ください。
クラスター化された VM で個別のデバイス割り当てで GPU を使用する

GPU 割り当て機能のエディション要件について

Hyper-V クラスター環境で GPU 割り当て機能をご利用になる場合は、ホスト OS を Windows Server Datacenter Edition へ変更することをご検討ください。
単一の Hyper-V ホスト環境であれば、Standard Edition のままご利用いただけます。

本問題に対する弊社の対応状況について

WAC の GPU 拡張機能が表示されない不具合については、2025 年 12 月時点で Windows Admin Center 製品の不具合として開発部門へ報告済みです。
今後、修正に関する具体的な情報が更新され次第、本記事でお知らせいたします。

本情報の内容 (添付文書、リンク先などを含む) は作成日時点のものであり、予告なく変更される場合があります。

更新履歴

2026/02/26 : 新規作成

本ブログは 2026 年 3 月 3 日時点での動作を元に作成しておりますが、将来的に動作が変更になる可能性がございますので予めご了承ください。

本記事はマイクロソフト社員によって公開されております。

こんにちは。Windows Commercial Support Directory Services チームです。

本記事では、Windows Hello for Business (WHfB) の 1 台のデバイスあたりの登録上限と、登録情報の削除方法についてご案内します。
WHfB の登録ユーザーが一定数を超えるケースや、ユーザーの利用終了時に登録情報を削除したいケースでお役立てください。

1 台のデバイスに登録できるユーザー数の上限

1 台のデバイスでサポートされている WHfB 登録の最大数は 10 ユーザー です。
これにより、10 人のユーザーがそれぞれ顔と最大 10 個の指紋を登録できます。

参考: Windows Hello for Business に関する一般的な質問 - 1 台の Windows デバイスで Windows Hello for Business に登録できるユーザーの数はいくつですか?

1 つのデバイスでサポートされている登録の最大数は 10 です。 これにより、10 人のユーザーがそれぞれ顔と最大 10 個の指紋を登録できます。 ユーザーが 10 人を超えるデバイスの場合、または多数のデバイス (サポート技術者など) にサインインするユーザーの場合は、FIDO2 セキュリティ キーの使用をお勧めします。

11 名以上でご利用された場合、利用できたとしても保証いたしかねる動作となります。また、ご利用されたことによって発生した問題を解消するためには、利用人数を 10 ユーザー以下に減らしていただく必要があるといったことも考えられますので、10 ユーザー以下でのご利用をご検討ください。
また、10 ユーザー以上での利用シナリオが想定される場合には、上記公開情報にもございますように FIDO2 セキュリティ キーの使用をご検討ください。

PIN/生体情報の削除方法

WHfB の登録情報 (PIN/顔/指紋) は、対象のユーザー自身 が削除する必要があります。

利用ユーザーによる削除手順

コマンド プロンプトから以下の手順で作業いただくことで、PIN/顔/指紋の Windows Hello for Business のデータを削除することができます。

1. コマンド プロンプトをユーザー権限で開きます。

2. 以下のコマンドを実行します。

   1	certutil -deletehellocontainer

3. ログオフを実施します。

4. Windows Hello for Business での認証タイル (PIN/顔/指紋) が表示されないことを確認します。

管理者ユーザーによる削除手順

PIN/生体情報は利用ユーザーで削除する必要がありますので管理者側から直接削除することはできませんが、
以下の手順で管理者ユーザー側から当該ユーザーのコマンド プロンプトを開くことにより情報を削除することができます。

1. 管理者として当該端末にログオンします。

2. 以下のコマンドを実行して、削除予定ユーザーでコマンド プロンプトを起動します。

   1	runas /user:<ドメイン名>\<削除ユーザー名> cmd

   ※ パスワードが不明な場合は、ドメイン コントローラー上の [Active Directory ユーザーとコンピューター] 上で当該ユーザーのパスワードをリセットします。
   ※ Entra ID ユーザーの場合は、Azure ポータル上で当該ユーザーのパスワードをリセットします。

3. 新しく開いたコマンド プロンプトにて以下のコマンドを実施して Windows Hello for Business の情報を削除します。

   1	certutil -deletehellocontainer

4. コマンド プロンプトを終了します。

   1

   exit

よくあるご質問 (FAQ)

Q: 管理者が WHfB の登録情報を一括で削除できますか？

A: Microsoft Intune をご利用の場合、ワイプ時に以下のいずれかのオプションの状態でワイプを実行することで、WHfB の情報も削除されます。

• デバイスをワイプし、デバイスの電源が失われてもワイプを続行する
• オプションが選択されていない (チェック無し)

参考: リモート デバイス アクション: ワイプ

上記以外の方法では、Windows Hello for Business の情報はユーザー個別となっておりますため、全ユーザーを一括して削除する方法はございません。お手数ではございますが、上述した手順にて各ユーザーの設定を削除いただけますと幸いです。

参考情報

• Windows Hello for Business に関する一般的な質問
• Azure AD 参加後に有効になる Windows Hello for Business とその無効化方法について | Japan Azure Identity Support Blog

更新履歴

2026/3/3 : 本ブログの公開

こんにちは。Windows Commercial Support Directory Services チームです。

本記事では、Active Directory データベースに含まれる内容をバックアップを採取した時点に戻すことを目的とした、Active Directory の権限のある復元 (Authoritative Restore) の手順についてご案内します。

Active Directory のバックアップとリストアにあたり理解しておくべきこと

ドメインコントローラーをバックアップからリストアするにあたり、AD 特有のデータとして以下の 2 点が存在すること、それぞれ別々の仕組みで動作 (情報をドメイン コントローラー間で複製) していることを理解することが重要です。

• AD データベース
  ユーザーやコンピューターなどのオブジェクトに関する情報が含まれるデータベースです。

• SYSVOL
  グループ ポリシーの設定情報などが含まれるフォルダーです。

リストアを実施するにあたり、権限のない復元 (Non-Authoritative Restore) と 権限のある復元 (Authoritative Restore) と呼ばれる方法があります。
ややこしいことに、前述のとおり AD データベースと SYSVOL はそれぞれ異なる仕組みで動作しているため、AD データベースと SYSVOL のそれぞれに権限のない復元と権限のある復元が存在します。
つまり、”AD データベースの権限のない復元” と “AD データベースの権限のある復元”、”SYSVOL の権限のない復元”、”SYSVOL の権限のある復元” の 4 通りが存在します。

さらにややこしいことに、同じ “権限のある復元” という呼び名でも、”AD データベースの権限のある復元” を実施する時の目的と、”SYSVOL の権限のある復元” を実施する時の目的は異なります。そのため、この 4 通りの復元方法の動作の違いやそれぞれの目的をしっかり理解することが重要です。

AD データベースの権限のない復元を実施した際の複製動作

AD データベースの権限のない復元を実施した場合、復元後に他の DC と複製を行うと、更新情報が新しい側の情報が採用されます。そのため、復元によってバックアップ取得時点の状態に戻したとしても、他の DC が保持しているより新しい更新情報によって上書きされ、結果として復元前の状態に戻ってしまいます。

以下に具体例を示します。DC01 と DC02 という 2 台の DC が存在しているとします。この時、あるユーザー A の [部署] 属性が “営業” であったとします。この状態で DC02 のバックアップを取得し、その後にユーザー A の [部署] 属性を “技術サポート” に変更したとします。この状態から DC02 をバックアップから復元すると、DC01 上の AD データベースに格納されているユーザー A の [部署] 属性は “技術サポート” になっていますが、DC02 の AD データベースに格納されているユーザー A の [部署] 属性は “営業” に戻ります。その上で DC01 と DC02 が複製を実施すると、DC01 の [部署] 属性が “技術サポート” であるという更新情報の方が新しいため、DC02 の [部署] 属性も “技術サポート” に変更されます。

SYSVOL の権限のない復元を実施した際の複製動作

一方で SYSVOL の複製の場合は、権限のない復元を実施すると、AD データベースの動作とは異なり、一旦自身が持っている情報をすべて破棄し、その他の DC が持っている SYSVOL の内容を複製してきた上で、それを自身の SYSVOL とします。つまり、DC01 と DC02 という 2 台の DC が存在し、DC02 の方を SYSVOL の権限のない復元を実施することを考えると、一旦 DC02 は自身が保持している SYSVOL の内容をすべて破棄し、DC01 の SYSVOL を DC02 の方へコピーしてきて、それを DC02 の SYSVOL とします。

AD データベースの権限のある復元を実施した際の複製動作

AD データベースの権限のある復元は、あるオブジェクトの属性情報をバックアップを取得した時点の状態に戻すことを目的として実施されます。

ここでも前述の [部署] 属性の例を用いて、AD データベースの権限のある復元の動作を説明します。前述の例と同様、あるユーザー A の [部署] 属性が “営業” である状態で DC02 のバックアップを取得します。
その後ユーザー A の [部署] 属性を “技術サポート” に変更した上で、DC02 をバックアップから “AD データベースの権限のある復元” を実施します。AD データベースの権限のある復元を実施する際は、”どのオブジェクトに対して権限のある復元をするのか” を指定しなければならないため、ここではユーザー A のオブジェクトに対して権限のある復元を実施するとします。

すると、ユーザー A の属性のバージョン番号に非常に大きな値が加算されます。こうすることによって、本来であれば DC02 が保持しているユーザー A の情報の方が DC01 よりも古いにも関わらず、DC02 のユーザー A の情報の方が新しいという扱いにすることにより、復元後に DC01 と DC02 が複製すると、DC02 が持つユーザー A の情報で、DC01 の持つユーザー A の情報が上書きされます。
つまり、復元後に DC01 と DC02 が複製しあった後、ユーザー A の [部署] 属性は DC02 のバックアップ取得時点のものである “営業” に戻ります。AD データベースの権限のない復元と異なり、ユーザー A の [部署] 属性がバックアップ取得時点の状態に戻っていることがお分かりいただけると思います。

SYSVOL の権限のある復元を実施した際の複製動作

前述のとおり、SYSVOL で権限のない復元を実施した場合、一旦自身が保持している SYSVOL の内容は破棄する動作となります。一方で、SYSVOL で権限のある復元を実施した場合、自身の SYSVOL を破棄するのではなく、自身が保持する SYSVOL の内容が正として、他の DC と複製を開始するようになります。SYSVOL の権限のある復元を実施した DC が正とする代わりに、その他のすべての DC で SYSVOL の権限のない復元を実施する必要があります。

SYSVOL の権限のある復元手順について

ドメイン コントローラーのバックアップとリストアについて でも記載がある wbadmin start systemstaterecovery 実行時における -authsysvol は SYSVOL の権限のある復元を実施するためのオプションであり、このオプションを付けない場合は SYSVOL の権限のない復元となります。

Active Directory の権限のある復元手順

wbadmin start systemstaterecovery 実行時の -authsysvol は SYSVOL に対してのみ「権限のある復元」を行うためのオプションです。
そのため、-authsysvol を付ける場合（SYSVOL の権限のある復元）でも、付けない場合（SYSVOL の権限のない復元）でも、AD データベースの復元としては権限のない復元（Non-Authoritative Restore） になります。

これは、ドメイン コントローラーを 1 台だけバックアップから戻す場合でも、全台をバックアップから戻す場合でも同様です。
（権限のない復元のまま他の DC と複製が行われると、USN/更新番号の関係で「更新情報が新しい側」の内容が採用され、バックアップ時点に戻したつもりの内容が結果的に上書きされます。）

そのため、バックアップ取得時点の内容を Active Directory 上でも正として反映させたい（= 他の DC 側を上書きしたい）場合は、システム状態の復元後に ntdsutil による Active Directory の権限のある復元 を追加で実施する必要があります。

Active Directory データベースに含まれる内容をバックアップを採取した時点に戻すためには、ドメインの 1 台のドメイン コントローラー (DC) で権限のある復元を実行します。

システム状態のリストア

1. 復元を実施する DC に管理者権限を持つユーザーでサインインします。

2. [ファイル名を指定して実行] から msconfig を実行します。

3. [ブート] タブの [セーフ ブート] をオンにします。

4. [Active Directory 修復] を選択し、[OK] をクリックします。

5. [再起動] をクリックします。

6. OS が起動してきたら、ディレクトリ サービス復元モードの Administrator でサインインします。

7. コマンド プロンプトを起動します。

8. 以下のコマンドを実行し、対象のバックアップの “バージョン識別子” を確認します。

   1	wbadmin get versions

9. 以下のコマンドを実行し、システム状態の復元を実施します。

   1	wbadmin start systemstaterecovery -version:<バージョン識別子> -quiet

10. 復元が完了したら、次の “ntdsutil コマンドを使用した権限のある復元” を実施します。

ntdsutil コマンドを使用した権限のある復元

1. ntdsutil と入力し、Enter を押します。

   1

   ntdsutil

2. activate instance ntds と入力し、Enter を押します。

   1	activate instance ntds

3. authoritative restore と入力し、Enter を押します。

   1	authoritative restore

4. 復元対象に応じて以下のコマンドを入力し、Enter を押します。

   • OU を復元する場合は restore subtree <OU の DN> を実行します。

     1	restore subtree OU=Sales,DC=contoso,DC=com

   • 特定のユーザーを復元する場合は restore object <ユーザーの DN> を実行します。

     1	restore object CN=user1,OU=Sales,DC=contoso,DC=com

   • 特定のグループを復元する場合は restore object <グループの DN> を実行します。

     1	restore object CN=SalesGroup,OU=Sales,DC=contoso,DC=com

5. “この Authoritative Restore を実行しますか?” と表示されたら、[はい] をクリックします。

6. その他にも権限のある復元を実施したいオブジェクトがある場合には、対象のオブジェクトに対して手順 5 および 6 を実施します。

7. q と入力して Enter を押すことを 2 回繰り返し、ntdsutil を終了します。

   1

   q

8. [ファイル名を指定して実行] から msconfig を実行します。

9. [ブート] タブの [セーフ ブート] をオフにし、[OK] をクリックします。

10. [再起動] をクリックします。

参考情報

• AD でユーザー アカウントとグループを復元する - Windows Server | Microsoft Learn

補足: パーティションを丸ごと復元したい場合
特定のオブジェクトではなく、パーティション全体をバックアップ取得時点の状態に戻したい場合は、すべてのドメイン コントローラーで権限のない復元を実施する（ドメイン コントローラーの全台リストア）方法をご検討ください。
詳細は ドメイン コントローラーのバックアップとリストアについて を参照してください。

変更履歴

2026/2/24: 本記事の公開
2026/3/3: 復元対象に応じて実行するコマンドを修正しました。また、補足を追記しました。

本情報の内容（添付文書、リンク先などを含む）は、作成日時点でのものであり、予告なく変更される場合があります。