こんにちは、Windows サポートの前田です。

今回は、Windows 11 を搭載した非コンバーチブル型のノートブック PC でタスクバーのすぐ上の領域がマウス操作できなくなる動作についてご案内します。

事象の概要

Windows 11 を搭載した非コンバーチブル型のノートブック PC で、タスク バーのすぐ上にあるわずかな帯状の領域を、マウスで操作できなくなる場合があります。
例えば、デスクトップで範囲選択を行う際に、タスクバーの境界の少し上までしか選択が行えず、範囲選択できるエリアが狭まった状態になります。

原因/条件

本事象には、次の 2 つの問題が関係しています。

<問題 1. コンバーチブル デバイスにおけるタスク バーの動作>
Windows 11 の 2023 年 2 月のプレビュー更新プログラムでは、端末をタブレットとして使用するときにタスク バーの表示を最適化する機能が追加されました。
この変更以降、コンバーチブル デバイスでは、ラップトップ モードで動作している場合も、タスク バーが拡張できる高さを前提として画面上に配置されます。
このため、表示上はタスク バーが通常の高さであっても、拡張時の高さを前提とした領域配置の影響で、タスク バーのすぐ上に操作できないわずかなエリアが生じる場合があります。

この動作は、Windows が端末をコンバーチブル デバイスとして認識している場合に発生します。
実際の筐体が通常のノートブック PC であっても、後述する “ConvertibleSlateModeChanged” の値が 1 の場合は、端末の形態が変化したことのあるコンバーチブル デバイスとして扱われ、本問題が発生します。

<問題 2. Sysprep 実行時の端末形態の誤判定>
Windows 11, version 24H2、25H2 において、2026 年 1 月のプレビュー更新プログラム以降では、端末の形態を判定する処理が変更されており、Sysprep 実行時に “ConvertibleSlateModeChanged” のレジストリが意図せず 1 に設定されてしまう場合があります。

具体的には、Explorer の起動後に以下のレジストリの状態が変わったことが検出されると、”ConvertibleSlateModeChanged” の値が 1 に設定されます。

　キー: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\PriorityControl
　値の名前: ConvertibleSlateMode

Sysprep /generalize 実行時には上記レジストリ値が削除されますが、2026 年 1 月のプレビュー更新プログラム以降を適用した環境では、Sysprep /generalize 実行時に上記の ConvertibleSlateMode レジストリ値が削除された際に、ハードウェアの姿勢が変化したものと判断され、Sysprep を実行したユーザーのプロファイルに次の値が作成されます。

　キー: HKEY_CURRENT_USER\Software\Microsoft\TabletTip\ConvertibleSlateModeChanged
　値の名前: ConvertibleSlateModeChanged
　値のデータ: 1

Sysprep 実行時に応答ファイルで CopyProfile を指定している場合、この値は Default ユーザー プロファイルにもコピーされ、Sysprep の完了後に当該端末にログオンする新規ユーザーに ConvertibleSlateModeChanged=1 が引き継がれます。
結果として通常のノートブック PC もコンバーチブル デバイスとして認識され、問題 1 に記載したタスク バーの上にわずかな操作できないエリアが生じます。

問題 2 の ConvertibleSlateModeChanged が設定されるのは、次の条件をすべて満たす場合です。

　・2026 年 1 月のプレビュー更新プログラム以降が適用されていること
　・Explorer の起動時の ConvertibleSlateMode の状態から変化すること
　・リモート デスクトップ セッションではないこと

ConvertibleSlateModeChanged の設定は、特定の OEM や機種に依存した動作ではなく、上記の条件に基づいて行われ、この値が 1 になることで結果として問題 1 のタスク バーの動作が発生します。
また、Sysprep 実行時に CopyProfile を指定していると、当該フラグがユーザー プロファイルへ引き継がれるため、Sysprep 後に端末にログオンする新規ユーザーで事象が発生する状態になります。

対処策について

有効な対処策と致しましては、端末がコンバーチブル デバイスとして判定されないようにすることです。

<マスター イメージ作成時に Sysprep を実行する際の事象防止手順>

1. マスター イメージの作成元の PC に、イメージ作成に使用されている管理者アカウント (Administrator 等) でサインインします。

2. コマンド プロンプトから以下のコマンドを実行し、ConvertibleSlateMode 値を削除します。

　reg delete “HKLM\SYSTEM\CurrentControlSet\Control\PriorityControl” /v ConvertibleSlateMode /f

3. Explorer プロセスを再起動します。
   　※ Explorer が保持している ConvertibleSlateMode の状態をリセットするために必要ですので必ず実行ください。

4. 以下のコマンドを実行し、当該フラグが存在しないことを確認します。

　reg query “HKCU\Software\Microsoft\TabletTip\ConvertibleSlateModeChanged” /v ConvertibleSlateModeChanged

　もし当該フラグが存在した場合は、以下のコマンドを実行して削除します。

　reg delete “HKCU\Software\Microsoft\TabletTip\ConvertibleSlateModeChanged” /v ConvertibleSlateModeChanged /f

5. 通常どおりの応答ファイルを指定して Sysprep を実行し、マスター イメージを作成します。

<既に事象が発生している環境における対処手順>

1. 事象が発生しているユーザーでサインインし、コマンド プロンプトから以下のコマンドを実行します。

　reg delete “HKCU\Software\Microsoft\TabletTip\ConvertibleSlateModeChanged” /v ConvertibleSlateModeChanged /f

2. 一度サインアウトし、もう一度サインインします。

3. 事象が解消されたかどうかご確認ください。

本手順の影響範囲は、実行したユーザーのプロファイルに限られます。
複数のユーザーが存在する場合には、すべてのユーザーで実施してください。

また、事象発生環境のデフォルト プロファイルに当該フラグが引き継がれてしまっている場合には、今後端末にログオンするすべての新規ユーザーで当該事象が発生してしまいますので、今後ユーザーを追加される可能性がある場合には、以下の手順も併せて実施してください。

<デフォルト プロファイルから該当のフラグを削除する手順>

1. 管理者権限でコマンド プロンプトを起動します。

2. 以下のコマンドを実行し、既定プロファイルのレジストリ ハイブをバックアップします。

　copy “C:\Users\Default\NTUSER.DAT” “C:\NTUSER_Default.bak”

3. 以下のコマンドを実行し、既定プロファイルのレジストリ ハイブを読み込みます。

　reg load HKLM\TmpDefault “C:\Users\Default\NTUSER.DAT”

4. 以下のコマンドを実行し、当該フラグの有無を確認します。

　reg query “HKLM\TmpDefault\Software\Microsoft\TabletTip\ConvertibleSlateModeChanged” /v ConvertibleSlateModeChanged

5. 手順 4 で当該フラグが存在した場合は、以下のコマンドを実行して削除します。

　reg delete “HKLM\TmpDefault\Software\Microsoft\TabletTip\ConvertibleSlateModeChanged” /v ConvertibleSlateModeChanged /f

6. 以下のコマンドを実行し、読み込みを解除します。

　reg unload HKLM\TmpDefault

7. 手順 6 が正常に終了したことをご確認ください。
   　エラーとなる場合はハイブが読み込まれたままとなりますので、しばらく待ってからもう一度実行します。

8. その後、新規ユーザーで初回ログオンし、問題が発生しないことをご確認ください。

本記事の内容は執筆時点の情報に基づいており、今後の更新で動作が変更される可能性がありますこと、ご了承ください。

こんにちは。Windows サポート チームです。

Windows Server 2025 の Hyper-V では、NUMA スパンニングを無効にした場合の仮想プロセッサの割り当て制限が厳格化されています。本記事では、NUMA スパンニングを無効にした場合の動作例を基に、Windows Server 2022 以前と Windows Server 2025 の仮想マシン起動動作の違いを説明します。

NUMA スパンニング無効時の挙動の差分概要:

Windows Server 2022 以前では、NUMA スパンニングを無効にしても、起動中の仮想マシンに割り当てられている論理プロセッサの合計が物理 NUMA ノード単位でオーバーコミットした状態でも、仮想マシンを起動できました。Windows Server 2025 では、NUMA スパンニングを無効にした場合、起動中の仮想マシンに割り当てられている論理プロセッサの合計が物理 NUMA ノード単位でオーバーコミット状態になると、仮想マシンを起動できません。

動作例の構成

本記事では、次の構成を動作例として説明します。

• Hyper-V ホスト: 物理 NUMA ノード 2 個
• 物理 NUMA ノードあたりの論理コア数: 16
• NUMA スパンニング: 無効
• 対象 OS: Windows Server 2022 以前、Windows Server 2025

単一の仮想マシンを起動する場合

仮想マシンに 24 vCPU を割り当て、仮想 NUMA ノード数を 1 に設定します。この構成では、1 つの仮想 NUMA ノードが 24 vCPU を必要とします。一方、物理 NUMA ノードあたりの論理コア数は 16 です。

NUMA スパンニングを無効にした場合、仮想 NUMA ノードは 1 つの物理 NUMA ノード内に配置される必要があります。そのため、24 vCPU を必要とする仮想 NUMA ノードを、論理コア数が 16 の物理 NUMA ノードへ配置することはできず、仮想マシンの起動に失敗します。

同じ 24 vCPU の仮想マシンで、仮想 NUMA ノード数を 2 に変更し、仮想 NUMA ノードあたりの最大プロセッサ数を 16 に設定します。この構成では、各仮想 NUMA ノードに必要な vCPU 数が物理 NUMA ノードあたりの論理コア数に収まるため、仮想マシンは起動します。

この単体仮想マシンの動作は、Windows Server 2022 以前と Windows Server 2025 で同じです。

複数の仮想マシンを起動する場合

24 vCPU を割り当て、仮想 NUMA ノード数を 2 に設定する仮想マシンを 3 台用意します。各仮想 NUMA ノードには 12 vCPU が割り当てられるため、各仮想 NUMA ノードに必要な vCPU 数は物理 NUMA ノードあたりの論理コア数に収まります。

Windows Server 2022 以前では、3 台すべての仮想マシンを起動できます。仮想マシン全体では 72 vCPU が割り当てられるため、物理 NUMA ノード単位では仮想プロセッサのオーバーコミットが発生します。

Windows Server 2025 では、1 台目の 24 vCPU の仮想マシンは起動します。1 台目の起動後は、各物理 NUMA ノードに 4 論理コアが残ります。2 台目の仮想マシンは、各仮想 NUMA ノードに 12 vCPU を必要とするため、物理 NUMA ノードごとに必要な vCPU を割り当てられず、起動に失敗します。

この違いにより、Windows Server 2022 以前では起動できていた仮想マシンが、Windows Server 2025 では起動できない場合があります。

まとめ

NUMA スパンニングを無効にした Windows Server 2025 の Hyper-V ホストでは、物理 NUMA ノード単位の仮想プロセッサ オーバーコミットはできません。Windows Server 2022 以前では起動できていた仮想マシンが、Windows Server 2025 では起動できない場合があります。

物理 NUMA ノード単位の vCPU オーバーコミットが発生する構成では、NUMA スパンニングを有効にすることをご検討ください。NUMA スパンニングの構成手順は、Hyper-V で NUMA を構成する をご確認ください。

参考情報

• Hyper-V の NUMA
• Hyper-V で NUMA を構成する

更新履歴

• 2026/09/14 : 本 Blog の公開

事象

OS 起動時に LBFO のメンバー NIC がリンクアップしているにもかかわらず、チーミング アダプターが初期化に失敗して起動できない事象が稀に発生することがあります。

本事象が発生すると、”ネットワーク接続” 画面でチーミング アダプターが「無効」と表示され、”ネットワーク接続” 画面から有効化しても「無効」状態から復旧しません。

Get-NetAdapter の実行結果では、メンバー NIC が Up 状態でリンク速度を表示している一方で、チーミング アダプターは Not Present 状態でリンク速度が “0 bps” と表示されます。

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

PS C:\> Get-NetAdapter

Name                          InterfaceDescription                     Status       LinkSpeed
----                          --------------------                     ------       ---------
<メンバー NIC 1>              <メンバー NIC の説明>                       Up           <リンク速度>
<メンバー NIC 2>              <メンバー NIC の説明>                       Up           <リンク速度>
<チーミング アダプター名>      Microsoft Network Adapter Multiplexor      Not Present  0 bps

PS C:\> Get-NetAdapter -Name <チーミング アダプター名> | Format-List Name, Status, LinkSpeed, AdminStatus, MediaConnectionState, DriverFileName

Name                 : <チーミング アダプター名>
Status               : Not Present
LinkSpeed            : 0 bps
AdminStatus          : Down
MediaConnectionState : Unknown
DriverFileName       : NdisImPlatform.sys

また、事象が発生すると、Microsoft-Windows-MsLbfoProvider/Operational イベントログでは、
“DriverEntry exiting, Status = 0” が記録された後、”Initializing TeamNic” 以降のイベントが記録されません。

正常時

1
2
3
4

"Information" "[日付]" "Microsoft-Windows-MsLbfoEventProvider" "10" "DriverEntry exiting, Status = 0"
"Information" "[日付]" "Microsoft-Windows-MsLbfoEventProvider" "17" "Initializing TeamNic <アドレス>, Status = 0."
"Information" "[日付]" "Microsoft-Windows-MsLbfoEventProvider" "11" "Member <GUID> created."
"Information" "[日付]" "Microsoft-Windows-MsLbfoEventProvider" "12" "Aggregator  <GUID> created."

事象発生時

1

"Information" "[日付]" "Microsoft-Windows-MsLbfoEventProvider" "10" "DriverEntry exiting, Status = 0"

原因

OS の起動時に、NdisImPlatform ドライバーのロードと NIC チーミング アダプターのデバイス追加処理が並行して実行されます。
これらの処理が開始されるタイミングによっては、ドライバーのロードが完了する前にデバイス追加処理が行われることがあります。
この場合、チーミングアダプターの初期化が失敗するため、本事象が発生します。

この事象は NdisImPlatform ドライバーのロード完了までに要する時間に依存して、稀に発生することがあります。
また、ブートログを有効にした環境では、NdisImPlatform ドライバーのロード完了までの時間が延びるため、事象が発生する可能性が少々高まります。

対処策

ブートログを有効にしている場合は、以下の手順でブートログを無効化することで本事象の発生を抑止することができます。

1. “ファイル名を指定して実行” より msconfig を入力して OK を押下します。
2. “ブート” タブを選択し、”ブートオプション” 内にある “ブートログ” のチェックを外します。

ブートログを無効にしている場合でも、事象が発生した際は以下のいずれかの方法で復旧してください。

(A) デバイスマネージャーから対象の NIC チーミング アダプターを一度無効化した後に再度有効化する
(B) OS を再起動する

特記事項

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

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

システム ドライブの空き容量を確認したところ、C:\Windows\Installer フォルダーが大きな領域を使用していたため、配下のファイルを削除してよいか、というお問い合わせをいただくことがありますが、このフォルダー配下のファイルの削除は、大変危険です。

そこで今回は、Windows Installer キャッシュの役割、手動で削除できない理由、およびキャッシュされた MSI ファイルから製品の製造元を確認する方法をご紹介します。

概要

Windows Installer キャッシュは、Windows Installer を使用してインストールされた製品の保守に必要な重要なファイルを保持する領域です。既定では C:\Windows\Installer フォルダーが使用されます。

結論として、C:\Windows\Installer 配下のファイルやフォルダーを、空き容量確保を目的として手動で削除することは推奨しておりません。

キャッシュを削除すると、その時点では問題が見えなくても、後から製品の更新、修復、アンインストールを行った際に失敗してしまい、更新も修復もアンインストールも何もできなくなってしまいます。
もし、容量の削減が必要な場合は、キャッシュを削除するのではなく、対象製品の開発元またはサポート窓口にご確認いただき、ご案内する手順をご確認ください。

1. Windows Installer キャッシュの詳細

MSI ファイルを使用して製品をインストールすると、Windows Installer は、以後の製品保守に必要なファイルを Windows Installer キャッシュへ格納します。また、MSP ファイルを使用して製品へ更新プログラムを適用した場合にも、保守に必要な情報が追加されます。

MSP ファイルは、Windows Installer ベースのアプリケーションへ更新プログラムを配信するためのパッチ パッケージです。製品の更新が繰り返される環境では、インストールされている製品や適用済みの更新プログラムに応じて、Windows Installer キャッシュの使用量が増えることがあります。

キャッシュされたファイルは、主に次の操作で使用されます。

• 製品の更新
• 製品の修復
• 製品のアンインストール
• 適用済みパッチの管理

C:\Windows\Installer 配下のファイル名は、元のインストール パッケージ名や製品名と一致しない場合があります。また、製品ごとにキャッシュされるファイルの種類や数、必要となる容量は異なります。このため、ファイル名、作成日時、サイズだけで、不要なファイルかどうかを判断することはできません。

参考情報:

• 不足している Windows インストーラー キャッシュ ファイルを復元する - Windows Client
• パッチ パッケージ - Win32 apps

2. 手動で削除できない理由

Windows Installer キャッシュ内のファイルは、単なる一時ファイルではありません。Windows Installer が、インストール済み製品の更新、修復、アンインストールなどを行うために使用するファイルです。

このため弊社技術情報でも、Windows Installer キャッシュは削除しないよう案内されています。キャッシュが欠損しても、通常使用している間は直ちに問題が発生しないことがあります。しかし、その後に製品を更新、修復、またはアンインストールした際、必要な MSI ファイルや MSP ファイルが見つからず、処理に失敗するリスクがあります。

キャッシュの欠損に関連して、セットアップ ログや MSI の詳細ログに、次のようなエラーが記録される場合があります。

• エラー 1612: この製品のインストール ソースを使用できない
• エラー 1635 / 1636: Windows Installer の MSP ファイルを処理できない
• エラー 1642: 対象製品が見つからない、または対象バージョンが一致しない

また、キャッシュされたファイルは、そのコンピューター上の製品のインストール状態に対応する一意のファイルです。このため仮に別のコンピューターから同名または類似のファイルをコピーしても、正しく復旧できるとは限りません。弊社技術情報でも、欠損したファイルだけを以前のバックアップから置き換える方法ではなく、必要に応じてシステム状態の完全な復元や、OS とアプリケーションの再インストールが必要となる場合があることも説明しています。

重要
C:\Windows\Installer 配下の MSI、MSP、サブ フォルダーを手動で削除しないでください。レジストリとの照合だけで「孤立している」と判断するツールや、キャッシュの一括クリーンアップをうたうサード パーティ製ツールについても、実行前に対象製品の開発元へサポート可否をご確認ください。

容量を削減したい場合

Windows Installer キャッシュだけを対象とする、すべての製品に共通した安全な手動削除手順はありません。削除や容量削減の方法は、キャッシュを使用している製品ごとに異なります。

まず、後述の方法でキャッシュ ファイルに記録された製品名や製造元を確認し、対象製品を特定します。そのうえで、次の対応を検討してください。

1. 製品の開発元またはサポート窓口へ、キャッシュ容量を削減するためのサポート済み手順があるか確認します。
2. 製品側で古い更新プログラムを整理する機能が提供されている場合は、その手順に従います。
3. 製品のアンインストールと再インストールを行う場合も、事前に製品固有の手順、前提条件、データのバックアップ方法を確認します。

製品をアンインストールして最新バージョンを再インストールすることで、過去のパッチ管理データが整理される場合があります。ただし、実施可否や具体的な手順は製品によって異なり、キャッシュが既に欠損しているとアンインストール自体が失敗する可能性もあります。必ず製品の開発元が案内する方法に従ってください。

参考情報:

• 不足している Windows インストーラー キャッシュ ファイルを復元する - Windows Client

3. MSI キャッシュの製造元を確認する方法

Windows Installer キャッシュ内の MSI ファイルは、元の製品名と異なる名前で保存されていることがあります。MSI データベース テーブル エディターである Orca を使用すると、MSI ファイル内の Property テーブルから、パッケージに記録された製品情報を確認できます。

Orca は Windows SDK の「Windows Installer Developers 向けコンポーネント」として提供されています。導入方法については、次の公開情報をご確認ください。

• Orca.exe - Win32 apps
• Windows インストーラー開発者向けの Windows SDK コンポーネント

確認手順

注意
Orca は MSI データベースを編集できるツールです。調査対象のキャッシュ ファイルを直接編集しないでください。必要な権限を持つ管理者が、対象の MSI ファイルを作業用フォルダーへコピーし、コピーしたファイルを参照用として開いてください。元のファイルは移動、名前変更、削除しないでください。

1. C:\Windows\Installer で、確認対象の拡張子が .msi, .msp のファイルを特定します。
2. 対象ファイルを作業用フォルダーへコピーします。
3. Orca を起動し、メニューの File - Open から、コピーした MSI ファイルを開きます。
4. 左側の Tables 一覧から Property を選択します。
5. 次のプロパティを確認します。

6. 確認後は、変更を保存せずに Orca を終了します。

Property テーブルには、インストールで定義されたプロパティ名と値が格納されています。ProductName、Manufacturer、ProductVersion は、製品を特定して問い合わせ先を確認する際の手掛かりになります。

ただし、Manufacturer は MSI パッケージの作成者が設定した製造元名であり、デジタル署名によって検証された発行元名と同義ではありません。パッケージの真正性や署名者を確認する必要がある場合は、ファイルのプロパティに デジタル署名 タブが存在するかを確認し、署名の詳細と証明書の状態も併せて確認してください。署名されていないパッケージでは、デジタル署名タブが表示されない場合があります。

また、MSP ファイルは MSI ファイルと構造が異なり、同じ Property テーブルの手順では製造元を確認できない場合があります。MSP ファイルを含む削除可否の判断は行わず、まず関連する MSI の製品情報を確認したうえで、製品の開発元へお問い合わせください。

参考情報:

• プロパティ テーブル - Win32 apps
• Manufacturer プロパティ - Win32 apps
• ProductName プロパティ - Win32 apps
• ProductVersion プロパティ - Win32 apps
• デジタル署名と Windows インストーラー - Win32 apps

まとめ

• Windows Installer キャッシュは、一時ファイルの保管場所ではなく、製品の更新、修復、アンインストールなどに必要な領域です。
• C:\Windows\Installer 配下を手動で削除すると、後から製品の保守処理が失敗する可能性があります。
• すべての製品に共通する安全なキャッシュ削除手順はありません。容量削減方法は製品ごとに異なるため、製品の開発元が案内する手順に従ってください。
• MSI ファイルに記録された製品名や製造元は、Orca の Property テーブルで確認できます。ただし、Manufacturer は署名によって検証された発行元情報ではありません。

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

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

更新履歴
2026/09/01 本 Blog の公開

こんにちは。Windows プラットフォーム サポートの城風です。
今回は、機能更新プログラム (Feature Update) 適用時に OS のライセンス認証が外れる動作とその対処方法についてご説明します。

概要

デジタル ライセンスによる認証が完了していない環境では、機能更新プログラム適用後に OS のライセンス認証が外れる動作が発生します。
対処策としては、主に機能更新プログラム適用前にデジタル ライセンスによる認証を完了させておくこと、もしくは機能更新プログラム適用後に再度ライセンス認証を行うことが挙げられます。

デジタル ライセンスによるライセンス認証とは

Windows OS のライセンス認証は、Windows デジタル ライセンスもしくは 25 文字のプロダクト キーのいずれかを用いて実施する必要があります。
デジタル ライセンスによるライセンス認証は、Windows 10 以降におけるライセンス認証方式です。
OS のプロダクト キーに依存しない認証方式であり、インターネットに接続することで、ライセンス認証の情報が自動的にマイクロソフトのライセンス認証サーバーにデジタル ライセンスとして保存されるため、一度認証すれば以降プロダクト キーは不要となります。

デジタル ライセンスは、お使いのハードウェアに関連付けられるため、一度認証したハードウェアはプロダクト キーがなくなった状態でも認証状態を引き継げる、といった利点があります。
機能更新プログラムを適用した際には、固有のプロダクト キーがワイプされますが、デジタル ライセンスを取得しているハードウェアは機能更新プログラム 適用後もライセンス認証がされた状態を引き継ぐことができます。

詳細

デジタル ライセンスが付与されていない場合の挙動
何らかの理由でデジタル ライセンスが付与されていない環境では、機能更新プログラム適用後にライセンス認証が外れる動作が発生します。
これは、機能更新プログラムの適用により固有のプロダクト キーがワイプされ既定のプロダクト キーに置き換わることでライセンス認証されていない状態となる仕様によるものです。

対処策

機能更新プログラム適用後に OS のライセンス認証が外れた場合の対処策
機能更新プログラム適用後にライセンス認証が外れる事象を回避するためには、以下いずれかの対処を行う必要があります。

1. 機能更新プログラム適用前にデジタル ライセンスを付与する
2. 機能更新プログラム適用後に再度ライセンス認証を実施する
3. 認証方式を変更する

以下はデジタル ライセンスが付与されない場合に確認するポイントとなります。

確認ポイント その 1 : 通信先のブロックについて
デジタル ライセンスを付与するためには、ライセンス認証を行うためのエンドポイントに通信できる環境でライセンス認証を行う必要があります。
サードパーティー製品などでインターネット接続が制限されている環境では、デジタル ライセンスによる認証を行うためのエンドポイントについて のエンドポイントがブロックされていないかをご確認ください。

確認ポイント その 2 : Web 認証やボリューム ライセンス認証管理ツール (VAMT) を使用したライセンス認証について
デジタル ライセンスによるライセンス認証は、その性質上、Web 認証やボリューム ライセンス認証管理ツール (VAMT) を使用したライセンス認証の場合には付与されません。
このため、Web 認証や VAMT を用いて OS のライセンス認証を実施している環境の場合には、機能更新プログラム適用後に再度ライセンス認証を実施してください。

確認ポイント その 3 : Microsoft Account Sign-in Assistant (wlidsvc) サービスが無効な場合について
Microsoft Account Sign-in Assistant (wlidsvc) サービスが無効の環境では、デジタル ライセンスは付与されません。
デジタル ライセンスを付与したい場合には、Microsoft Account Sign-in Assistant を有効にした上で再度 OS のライセンス認証を実施してください。
この動作は下記の公開情報にも記載されていますのであわせてご確認ください。

Title: Policy CSP - Accounts
URL: https://learn.microsoft.com/ja-jp/windows/client-management/mdm/policy-csp-accounts#allowmicrosoftaccountsigninassistant

参考

デジタル ライセンスが付与されているかの確認方法
[設定] -> [システム] -> [ライセンス認証] -> [ライセンス認証の状態] から確認することができます。
デジタル ライセンスの付与状況は、コマンドやその他レジストリ等にもその状態は出力されないため、[ライセンス認証の状態] から目視で確認をしていただく必要があります。

表示例 : Windows はデジタル ライセンスによってライセンス認証されています

デジタル ライセンスを付与しライセンス認証を行う方法
デジタル ライセンスによる認証は、マイクロソフトのライセンス認証サーバーに、ライセンス認証の情報を保存する動作により完了するため、インターネットに接続可能な環境でライセンス認証を実施することで、付与されます。

デジタル ライセンスによる認証を行うためのエンドポイントについて
ファイアウォール、プロキシ サーバーや何らかのアプリケーションを利用して通信を制御している環境の場合、下記公開情報に記載のエンドポイントを許可した状態で、ライセンス認証を実行してください。

Title: Windows のライセンス認証または検証がエラー コード 0x8004FE33で失敗する
URL: https://learn.microsoft.com/ja-jp/troubleshoot/windows-server/networking/windows-activation-validation-fails
※ “方法 3: 証明書失効リストの URL を除外するようにプロキシ サーバーを構成する” に記載のエンドポイントをご確認ください。

特記事項

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

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

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

この記事では外字として登録された EUDC 文字が正しく表示・印刷されない場合がある問題と、その解消方法についてご案内します。

対象バージョン

Windows 11, version 25H2
Windows 11, version 24H2
Windows Server 2025

概要

Windows 11 version 24H2/25H2 または Windows Server 2025 に 2025 年 9 月以降の更新プログラムを適用すると、Unicode 私用領域 (PUA) に割り当てられた一部の EUDC (End-User Defined Character) 文字（外字）が正しく表示・印字されない場合があります。

この影響を受ける UNICODE 文字のコード範囲は以下の通りです。

U+E76C
U+E78D - U+E796
U+E7C7 - U+E7C8
U+E7E7 - U+E7F3
U+E815 - U+E864

この文字コード範囲に EUDC 文字が登録されている場合、その登録された文字ではなく他の文字や記号が表示されてしまいます。

ご利用の Windows が該当するかどうかを判断するには、検索ボックスまたは [ファイル名を指定して実行] に winver と入力し、表示された OS ビルドの番号をご確認ください。以下の範囲に含まれる場合は該当します。

Windows 11, version 24H2 の場合：

26100.4484 以上、 26100.8328 未満

Windows 11, version 25H2 の場合：

26200.6584 以上、 26200.8328 未満

Windows Server 2025 の場合：

26100.6584 以上、 26100.33296 未満

解決方法

本問題に対する修正を含む更新プログラムがリリースされています。

Windows 11 version 24H2/25H2 の場合、2026 年 4 月にリリースされたプレビュー更新プログラム、または、2026 年 5 月にリリースされた更新プログラム（それ以降にリリースされた更新プログラムを含みます）を適用頂くことで、事象は解消します。

2026 年 4 月 30 日 — KB5083631 (OS ビルド 26200.8328 および 26100.8328) プレビュー

2026 年 5 月 12 日 — KB5089549 (OS ビルド 26200.8457 および 26100.8457)

Windows Server 2025 の場合、2026 年 8 月にリリースされた更新プログラム（それ以降にリリースされた更新プログラムを含みます）を適用頂くことで、事象は解消します。

2026 年 8 月 11 日 — KB5120233 (OS ビルド 26100.33296)

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

更新履歴

2026/08/24 本 Blog の公開

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

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

Windows 11 バージョン 24H2、25H2、26H1、または Windows Server 2025 の日本語版をクリーン インストールした後、エクスプローラーや設定アプリは日本語で表示されているのに、Windows セキュリティを開くと一部または全体が英語で表示される場合があります。

「日本語の言語パックが正しく入っていないのでは」と考え、言語設定をやり直したくなるところですが、Windows セキュリティだけが英語で、ほかの Windows の画面が日本語で表示されている場合は、まず Windows セキュリティ アプリの更新状態をご確認ください。

TL;DR

まず、Windows セキュリティ プラットフォームの更新プログラム KB5007651 の適用をご検討ください。弊社に報告されております事例では、最新版の適用により事象が改善し、日本語で表示されるようになることがわかっております。Windows Update または組織で使用している更新管理の経路を通じて KB5007651 を適用するか、Microsoft Update カタログからパッケージをダウンロードして手動で適用してください。

図の内容は本文でも説明しています。小さい画面では、図を選択すると拡大表示できます。

目次

• どのような事象か
• なぜ Windows セキュリティだけ英語になるのか
• 対処方法
• 適用後の確認
• 改善しない場合に確認すること
• 展開イメージを運用するときのポイント
• よくある質問

どのような事象か

本記事で扱うのは、次の条件に該当する事象です。

• Windows 11 バージョン 24H2、25H2、26H1、または Windows Server 2025 をクリーン インストールした直後である
• Windows の表示言語は日本語に設定されている
• エクスプローラーや設定アプリなど、Windows のほかの画面は日本語で表示される
• Windows セキュリティを開いたときだけ、一部または全体が英語で表示される

一方、サインイン画面や設定アプリを含む Windows 全体が英語で表示される場合は、Windows の表示言語や言語パックの構成を確認する必要があります。その場合は、本記事とは異なる事象として切り分けてお考えください。

また、Windows セキュリティに警告やエラーが表示される、ウイルスと脅威の防止を開けない、保護機能が無効と表示されるといった症状は、表示言語の問題とは別に確認する必要があります。

なぜ Windows セキュリティだけ英語になるのか

Windows の画面は、すべてが 1 つの言語ファイルだけで表示されているわけではありません。Windows 本体の言語リソースに加え、個々のアプリがそれぞれの表示用リソースを持っています。

Windows 11 や Windows Server 2025 のインストール メディア、展開イメージは、作成された時点のファイルを収録したスナップショットです。弊社で確認した Windows 11 の事例では、クリーン インストール直後の Windows セキュリティ アプリにおいて、日本語表示用リソースが含まれておらず、英語表示にフォールバックする動作でございました。また、Windows Server 2025 におきましても同様の事象が発生することが報告されております。

Windows セキュリティ アプリと関連する Windows セキュリティ プラットフォームは、Windows セキュリティ アプリの更新として提供される KB5007651 で更新されます。弊社で確認した Windows 11 の事例では、KB5007651 の適用により Windows セキュリティ アプリが更新され、日本語表示用リソースが正しく反映されるようになりました。Windows Server 2025 におきましても Windows Update から同じ KB5007651 が提供されることを確認しています。このため、本記事に記載した条件に該当する場合は、言語パックを入れ直すのではなく、代わりに KB5007651 の適用をお試しください。

なお、同じ英語表示となる場合でも、言語設定、更新の失敗、アプリの登録状態など、本記事に記載の事象とは別の要因で発生している場合があります。KB5007651 の最新版を適用しても改善しない場合は、後述の「改善しない場合に確認すること」へ進んでください。

KB5007651 は同じ KB 番号のまま新しいバージョンが継続的に公開されます。Microsoft Update カタログに複数の検索結果が表示される場合は、古いバージョンではなく、更新日とバージョンが最も新しいものを選んでください。

対処方法

KB5007651 は、Windows Update、Windows Server Update Services (WSUS)、Microsoft Update カタログから入手できます。Windows 11 と Windows Server 2025 で更新方法に違いはありません。

図の内容は本文でも説明しています。小さい画面では、図を選択すると拡大表示できます。

方法 1: Windows Update または WSUS から適用する

インターネット上の Windows Update を利用している端末では、次の手順で更新します。組織で WSUS などの更新管理を行っている場合は、組織で定められた手順に従って KB5007651 を配布、適用してください。

1. Windows セキュリティ アプリを終了します。
2. [設定] - [Windows Update] を開きます。
3. [更新プログラムのチェック] を選択します。
4. Update for Windows Security platform - KB5007651 が検出された場合は、更新を適用します。
5. 再起動を求められた場合は、画面の案内に従って再起動します。
6. Windows セキュリティ アプリを開き直し、日本語で表示されるか確認します。

Windows セキュリティ アプリの更新はバックグラウンドで適用される場合があります。更新操作の直後に KB5007651 が一覧に表示されない場合でも、Windows セキュリティを開き直して表示をご確認ください。

方法 2: Microsoft Update カタログから手動で適用する

Windows Update や WSUS から KB5007651 が提供されない場合は、Microsoft Update カタログから手動でダウンロードして適用できます。

1. Windows セキュリティ アプリを終了します。
2. Microsoft Update カタログを開きます。
3. 検索結果から、更新日とバージョンが最も新しい Update for Windows Security platform - KB5007651 の [ダウンロード] を選択します。
4. ダウンロード画面で、端末のアーキテクチャに対応するファイルを選択します。
5. ダウンロードしたインストーラーを右クリックし、[管理者として実行] を選択します。
6. Windows セキュリティ アプリを開き直し、日本語で表示されるか確認します。

なお、2026 年 8 月 21 日時点で Microsoft Update カタログに掲載されている最新版は、Version 10.0.29628.1000 です。今後、新しいバージョンへ置き換わるため、実施時点で更新日とバージョンを確認してください。

ここで示す Version 10.0.29628.1000 は、Microsoft Update カタログに掲載されている Windows セキュリティ プラットフォーム更新のバージョンです。Windows セキュリティの [バージョン情報] には複数の項目が表示され、すべてがこの値と同じになるわけではありません。

インストーラーは画面を表示せずに終了する場合がありますが、画面が表示されなかったことだけでは適用完了と判断できません。実行後に Windows セキュリティを開き直し、日本語表示へ改善したか確認してください。改善しない場合は、[バージョン情報] 画面全体のスクリーンショットを保存し、ほかの確認情報とともに Microsoft サポートへご提示ください。[バージョン情報] 画面だけで適用完了を判定するものではありません。

適用後の確認

更新後は、Windows セキュリティ アプリをいったん終了してから開き直し、次の点を確認します。

• ナビゲーションや各ページの見出しが日本語で表示されること
• [ウイルスと脅威の防止]、[アカウントの保護]、[ファイアウォールとネットワーク保護] などのページを開けること
• 更新前に英語で表示されていた箇所が日本語に切り替わっていること

Windows セキュリティの [設定] - [バージョン情報] では、アプリや関連コンポーネントのバージョンを確認できます。問題が残る場合には、更新前後の画面を記録しておくと切り分けに役立ちます。

図の内容は本文でも説明しています。小さい画面では、図を選択すると拡大表示できます。

改善しない場合に確認すること

最新版の KB5007651 を適用しても英語表示が残る場合は、次の点をご確認ください。

1. 英語表示の範囲
   Windows セキュリティ全体が英語なのか、特定のページや項目だけが英語なのかを確認します。必要に応じて画面全体のスクリーンショットを保存してください。

2. Windows のバージョンと OS ビルド
   winver を実行し、表示された Windows のバージョンと OS ビルドを確認します。

3. Windows セキュリティのバージョン情報
   Windows セキュリティの [設定] - [バージョン情報] 画面を確認します。複数のバージョンが表示されるため、画面全体のスクリーンショットを保存しておくことをお勧めします。

4. Windows 全体の表示言語
   [設定] - [時刻と言語] - [言語と地域] を開き、Windows の表示言語が日本語であることを確認します。Windows セキュリティ以外のアプリにも英語表示がある場合は、言語パックや優先する言語の構成も確認します。

これらの情報を添えて Microsoft サポートへお問い合わせいただくと、更新プログラムが適用されていない状態なのか、特定の表示項目に限られた別の問題なのかを切り分けやすくなります。

展開イメージを運用するときのポイント

多数の端末を展開する環境では、クリーン インストールやイメージ展開の完了だけでなく、Windows セキュリティ アプリを含む最新更新の適用までを初期構築手順に含めることをお勧めします。

• KB5007651 の適用を、イメージ展開後の初期構築手順へ含める
• WSUS を使用する場合は、Windows セキュリティ プラットフォームの更新を同期、承認できる構成か確認する
• インターネットへ接続できない端末では、展開時点の最新版を Microsoft Update カタログから入手し、事前に検証してから配布する
• 基準イメージを長期間使う場合は、イメージの作成日だけでなく、展開後に適用するアプリ更新の手順も定期的に見直す

KB5007651 は同じ KB 番号でバージョンが更新されるため、特定のファイル名やバージョンを長期間固定するより、展開時点の最新版を確認する運用をお勧めします。

よくある質問

Q1. Windows セキュリティが英語表示でも、保護機能に問題はありますか?

弊社で確認した事例は、Windows セキュリティ アプリの表示言語だけに生じる問題でした。Microsoft Defender ウイルス対策やファイアウォールなど、保護機能の動作には影響しないことを確認しています。

ただし、Windows セキュリティに警告やエラーが表示される、各ページを開けない、あるいは保護機能が “無効” と表示される場合は、表示言語とは別の問題として確認してください。

Q2. 日本語の言語パックを入れ直す必要はありますか?

Windows セキュリティ以外の画面が日本語で表示されている場合は、言語パックを入れ直す前に KB5007651 を適用し、Windows セキュリティ アプリを最新にしてください。Windows 全体が英語で表示される場合や、複数のアプリで日本語表示が不足している場合は、Windows の表示言語を確認し、必要に応じて言語パックのインストールをご検討ください。

Q3. Microsoft Update カタログに KB5007651 が複数表示されます。どれを選べばよいですか?

KB5007651 は同じ KB 番号のまま新しいバージョンが公開されます。更新日とバージョンを比較し、端末のアーキテクチャに対応する最新版を選択してください。

Q4. 手動インストーラーを実行しても画面が表示されません。

インストーラーは画面を表示せずに終了する場合がありますが、それだけでは適用完了と判断できません。Windows セキュリティ アプリを開き直し、日本語表示へ改善したか確認してください。改善しない場合は、Windows セキュリティの [設定] - [バージョン情報] 画面全体のスクリーンショットを保存し、Microsoft サポートへご提示ください。

Q5. WSUS から配布できますか?

はい。KB5007651 の公開情報では、WSUS から利用できる更新プログラムとして案内されています。組織の同期対象と承認規則をご確認ください。

Q6. Windows Server 2025 でも同じ対処を利用できますか?

はい。KB5007651 の公開情報ではビルド 22000 以降が対象と案内されており、Windows Server 2025 でも Windows 11 と同じ方法で適用できます。Windows Update または WSUS から適用するか、Microsoft Update カタログからパッケージをダウンロードして手動で適用し、Windows セキュリティを開き直して表示をご確認ください。

参考情報

• Windows セキュリティ アプリの更新 | Microsoft サポート
• Microsoft Update カタログ: KB5007651
• Windows セキュリティ アプリ | Microsoft Learn

本記事の内容が、Windows 11 または Windows Server 2025 の展開後に表示言語を確認する際の参考となれば幸いです。

本情報の内容は作成日時点のものであり、予告なく変更される場合があります。

更新履歴
2026/08/21 本 Blog の公開
2026/09/04 Windows Server 2025 を対象に追加

こんにちは、Windows サポートの新谷です。

今回は、Windows 11 でキオスクを構成する方法についてご案内します。

概要

キオスクは、許可したアプリのみをユーザーから使用可能にし、メンテナンスや展開のコストを下げ、また画一的なサービスの提供を可能にすることを目的とした構成です。
キオスクを実現する機能としては、Assigned Access と Shell Launcher があります。それぞれ、主な利用シチュエーションは次のようになります。

• Assigned Access: UWP アプリや Edge を全画面で実行する場合や、許可した複数のアプリを利用する場合
• Shell Launcher: カスタムした Windows デスクトップアプリで Explorer を置き換えて利用する場合

(参考)Windows kiosks configuration options overview
https://learn.microsoft.com/en-us/windows/configuration/kiosk/

シングルアプリ キオスクでは許可したアプリを全画面で利用可能で、マルチアプリ キオスクでは 1 つまたは複数のアプリをスタート メニューから利用可能です。
マルチアプリ キオスクは Windows 11 では Assigned Access で構成します。
カスタムしたデスクトップアプリをご利用の場合には Shell Launcher が選択肢となります。

各機能を利用可能なエディションは以下の通りです。

キオスクを Windows 11 で構成する手順としては次の流れとなります。

1. Assigned Access または Shell Launcher を構成する XML ファイルを作成
2. MDM Bridge WMI Provider 経由で XML ファイルをローカル端末に反映
3. (Intune の場合) 2. で検証した XML ファイルをカスタムポリシーにて配布し、反映

注意

Intune デバイス構成テンプレートについて

Intune には「デバイスの構成」テンプレート内にキオスク プロファイルのテンプレートが用意されていますが、Windows 11 では意図したとおりに動作しないことがあります。
Windows 11 でキオスクを構成する場合は、Intune のキオスク テンプレートは使用せず、本記事で紹介するカスタム構成プロファイル (OMA-URI) による XML の配布を行ってください。

展開方法

下記に、XML のサンプルや各機能の注意点をご説明します。

本記事のサンプルは、Windows 11 バージョン 22H2 以降を対象とします。

• Assigned Access: Windows 11 Pro、Enterprise、Education、IoT Enterprise
• Shell Launcher: Windows 11 Enterprise、Education、IoT Enterprise
• Assigned Access を使用する端末では、ユーザー アカウント制御 (UAC) を有効にしてください。
• キオスク ユーザーは端末のコンソールからサインインしてください。リモート デスクトップ接続ではキオスク エクスペリエンスを利用できません。
• 検証中に端末を管理できるように、キオスク ユーザーとは別の管理者アカウントを用意してください。

シングルアプリ キオスク XML

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

<?xml version="1.0" encoding="utf-8"?>
<AssignedAccessConfiguration
  xmlns="http://schemas.microsoft.com/AssignedAccess/2017/config"
  xmlns:rs5="http://schemas.microsoft.com/AssignedAccess/201810/config"
  xmlns:v4="http://schemas.microsoft.com/AssignedAccess/2021/config">
    <Profiles>
        <Profile Id="{EDB3036B-780D-487D-A375-69369D8A8F78}" Name="Edge Kiosk">
            <KioskModeApp
              v4:ClassicAppPath="%ProgramFiles(x86)%\Microsoft\Edge\Application\msedge.exe"
              v4:ClassicAppArguments="--kiosk https://www.microsoft.com --edge-kiosk-type=public-browsing --kiosk-idle-timeout-minutes=2"/>
        </Profile>
    </Profiles>
    <Configs>
        <Config>
            <AutoLogonAccount rs5:DisplayName="Kiosk User"/>
            <DefaultProfile Id="{EDB3036B-780D-487D-A375-69369D8A8F78}"/>
        </Config>
    </Configs>
</AssignedAccessConfiguration>

XML の各要素について補足します。

• KioskModeApp: シングルアプリ キオスクで起動するアプリを指定する要素です。UWP アプリの場合は AppUserModelId 属性で AUMID を指定します。Edge 等のデスクトップアプリの場合は v4:ClassicAppPath で実行ファイルのパスを指定し、v4:ClassicAppArguments で起動引数を指定します。
• v4:ClassicAppPath: デスクトップアプリの実行ファイルのパスを指定します。%ProgramFiles(x86)% 等の環境変数が使用できます。
• v4:ClassicAppArguments: アプリに渡す起動引数を指定します。Edge の場合、以下のキオスク モード引数を指定します。
  • --kiosk <URL>: キオスクモードで開く URL を指定します。
  • --edge-kiosk-type=fullscreen: 指定した URL を全画面表示します (デジタルサイネージ用途)。
  • --edge-kiosk-type=public-browsing: InPrivate モードの制限付きブラウザーとして動作します (公共端末用途)。
  • --kiosk-idle-timeout-minutes=<分>: 指定した時間無操作が続くとブラウザーをリセットします。
• AutoLogonAccount: Assigned Access が自動ログオン用のローカル標準ユーザー アカウントを作成し、管理します。rs5:DisplayName でサインイン画面に表示される表示名を設定できます。
• DefaultProfile: Config 内でユーザーに割り当てるプロファイルを Id で指定します。

マルチアプリ キオスク XML

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

<?xml version="1.0" encoding="utf-8" ?>
<AssignedAccessConfiguration
  xmlns="http://schemas.microsoft.com/AssignedAccess/2017/config"
  xmlns:rs5="http://schemas.microsoft.com/AssignedAccess/201810/config"
  xmlns:v5="http://schemas.microsoft.com/AssignedAccess/2022/config">
  <Profiles>
    <Profile Id="{9A2A490F-10F6-4764-974A-43B19E722C23}" Name="Edge Kiosk">
      <AllAppsList>
        <AllowedApps>
          <App DesktopAppPath="%ProgramFiles(x86)%\Microsoft\Edge\Application\msedge.exe" />
          <App DesktopAppPath="%ProgramFiles(x86)%\Microsoft\Edge\Application\msedge_proxy.exe" />
          <App AppUserModelId="Microsoft.MicrosoftEdge.Stable_8wekyb3d8bbwe!App" />
        </AllowedApps>
      </AllAppsList>
      <v5:StartPins>
        <![CDATA[
          { "pinnedList": [
            { "desktopAppLink": "%ALLUSERSPROFILE%\\Microsoft\\Windows\\Start Menu\\Programs\\Microsoft Edge.lnk" }
          ] }
        ]]>
      </v5:StartPins>
      <Taskbar ShowTaskbar="false" />
    </Profile>
  </Profiles>
  <Configs>
    <Config>
      <AutoLogonAccount rs5:DisplayName="Kiosk User" />
      <DefaultProfile Id="{9A2A490F-10F6-4764-974A-43B19E722C23}" />
    </Config>
  </Configs>
</AssignedAccessConfiguration>

XML の各要素について補足します。

• AllowedApps: キオスク ユーザーに許可するアプリを指定します。Edge にてセカンダリ タイルを利用する場合、DesktopAppPath で msedge.exe および msedge_proxy.exe のパスと、AppUserModelId (AUMID) の両方を指定する必要があります。
• StartPins: Windows 11 のスタート メニューにピン留めするアプリを指定します。デスクトップアプリの場合は desktopAppLink でスタート メニューのショートカットパスを指定します。
• Taskbar: タスクバーの表示/非表示を制御します。
• AutoLogonAccount: Assigned Access が自動ログオン用のローカル標準ユーザー アカウントを作成し、管理します。
  • Account: 既存のローカル、ドメイン、または Microsoft Entra ID ユーザーを割り当てる場合は、AutoLogonAccount ではなく Account を使用します。Microsoft Entra ID ユーザーは <Account>AzureAD\user@domain</Account> の形式で指定します。複数の Config 要素を定義して、複数のユーザーに同じプロファイルを割り当てることもできます。

Shell Launcher XML

Shell Launcher では、アプリをシェルとして起動します。以下は、自動ログインのキオスク ユーザーに対してメモ帳をシェルとして設定する例です。
Shell Launcher v1 では Win32 アプリに限られていましたが、v2 では UWP アプリを起動可能となりました。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

<?xml version="1.0" encoding="utf-8"?>
<ShellLauncherConfiguration
  xmlns="http://schemas.microsoft.com/ShellLauncher/2018/Configuration"
  xmlns:V2="http://schemas.microsoft.com/ShellLauncher/2019/Configuration">
    <Profiles>
        <DefaultProfile>
            <Shell Shell="%SystemRoot%\explorer.exe"/>
        </DefaultProfile>
        <Profile Id="{EDB3036B-780D-487D-A375-69369D8A8F78}">
            <Shell Shell="%SystemRoot%\System32\notepad.exe" V2:AppType="Desktop" V2:AllAppsFullScreen="true">
                <DefaultAction Action="RestartShell"/>
            </Shell>
        </Profile>
    </Profiles>
    <Configs>
        <Config>
            <AutoLogonAccount/>
            <Profile Id="{EDB3036B-780D-487D-A375-69369D8A8F78}"/>
        </Config>
    </Configs>
</ShellLauncherConfiguration>

XML の各要素について補足します。

• DefaultProfile: どのプロファイルにも該当しないユーザーに対するシェルを指定します。通常は explorer.exe を指定して通常のデスクトップを維持します。
• Shell: シェルとして起動する実行ファイルのパスを指定します。Win32 アプリの場合はフルパスまたは環境変数を含むパス、UWP アプリの場合は AUMID を指定します。
• V2:AppType: アプリの種別を指定します。Desktop (Win32) または UWP を指定します。UWP を指定する場合、Shell 属性には実行ファイルのパスではなく AUMID を記述します (例: Shell="Microsoft.BingWeather_8wekyb3d8bbwe!App")。
• V2:AllAppsFullScreen: true に設定すると、シェルアプリおよびそこから起動されるすべてのアプリが全画面 (またはデスクトップアプリの場合は最大化) で実行されます。
• DefaultAction: シェルプロセスが終了した際の既定のアクションを定義します。RestartShell、RestartDevice、ShutdownDevice 、DoNothing から選択します。
• ReturnCodeActions: シェルプロセスの特定の終了コードに対するアクションを個別に定義できます (省略可)。

終了コードに対応するアクションがなく、DefaultAction も未定義の場合、Shell Launcher は何も実行せず、終了したカスタム シェルは再起動されません。

AUMID の確認方法

許可するアプリの AUMID は次のような PowerShell コマンドで確認できます。

1

Get-StartApps | Where-Object { $_.Name -like "*Edge*" }

インストール済みのパッケージアプリ一覧から確認する場合:

1

Get-AppxPackage | Select-Object Name, PackageFamilyName

ローカル端末への適用

作成した XML ファイルをローカル端末に適用するには、MDM Bridge WMI Provider を使用します。
MDM Bridge WMI Provider へのアクセスにはシステム (SYSTEM) 権限が必要です。管理者権限の PowerShell では権限不足となりますのでご注意ください。

1. PsExec をダウンロードし、管理者権限のコマンドプロンプトから以下を実行して SYSTEM 権限の PowerShell を起動します。

1

psexec -i -s powershell.exe

2. 以下のコマンドで XML を適用します。XML ファイルのパスは環境に合わせて変更してください。プロパティ名は Assigned Access の場合は Configuration、Shell Launcher の場合は ShellLauncher を使用します。

1
2
3
4
5
6
7
8
9
10
11

$namespaceName = "root\cimv2\mdm\dmmap"
$className = "MDM_AssignedAccess"
$obj = Get-CimInstance -Namespace $namespaceName -ClassName $className

# Assigned Access の場合
$obj.Configuration = [System.Net.WebUtility]::HtmlEncode((Get-Content -Path ".\kiosk.xml" -Encoding UTF8 -Raw))

# Shell Launcher の場合
# $obj.ShellLauncher = [System.Net.WebUtility]::HtmlEncode((Get-Content -Path ".\kiosk.xml" -Encoding UTF8 -Raw))

Set-CimInstance -CimInstance $obj

3. 適用後、端末を再起動するとキオスク構成が有効になります。

構成の解除

ローカル端末に適用したキオスク構成を解除する手順です。

管理者アカウントでサインインし、手順 1 と同様に PsExec から SYSTEM 権限の PowerShell を起動します。
次のコマンドにより対象のプロパティを $null に設定します。

1
2
3
4
5

$namespaceName = "root\cimv2\mdm\dmmap"
$className = "MDM_AssignedAccess"
$obj = Get-CimInstance -Namespace $namespaceName -ClassName $className
$obj.Configuration = $null   # Shell Launcher の場合は $obj.ShellLauncher = $null
Set-CimInstance -CimInstance $obj

再起動すると、構成が解除されます。
なお、Assigned Access の構成を解除した後も、スタート メニューの変更などが完全に元に戻らない場合があります。

Shell Launcher 利用時の前提条件

Shell Launcher は Windows のオプション機能として提供されています。使用前に有効化が必要です。
Intune で配布する場合には、自動で有効化されるため、手動での有効化は必要ありません。

1

Enable-WindowsOptionalFeature -Online -FeatureName "Client-EmbeddedShellLauncher" -All

Shell Launcher 利用時の注意

Shell Launcher は指定したアプリをシェルとして起動する機能であり、指定したアプリ以外の実行を自動的に禁止するものではありません。キーボード ショートカットや「ファイルを開く」ダイアログ ボックス、子プロセスの起動などから、シェル以外の機能にアクセスできてしまう場合があります。
Shell Launcher を使用する際は、想定外のアクセスが発生しないことを事前に検証してください。必要に応じて、標準ユーザー アカウントの使用、AppLocker によるアプリの実行制御、グループ ポリシーによる機能制限などを併用することをお勧めします。

Intune によるリモート展開

ローカルでの検証が完了したら、Intune のカスタム構成プロファイルを使用して複数端末に展開できます。

1. Microsoft Intune 管理センター > デバイス > 構成プロファイル > プロファイルの作成
2. プラットフォーム: Windows 10 以降、プロファイルの種類: テンプレート を選択し、カスタム で作成
3. 構成設定にて OMA-URI 設定を追加:
   • Assigned Access の場合:
     • OMA-URI: ./Vendor/MSFT/AssignedAccess/Configuration
     • データ型: 文字列 (XML ファイル)
     • 値: XML ファイルを指定
   • Shell Launcher の場合:
     • OMA-URI: ./Vendor/MSFT/AssignedAccess/ShellLauncher
     • データ型: 文字列 (XML ファイル)
     • 値: XML ファイルを指定
4. 構成プロファイルを保存
5. 対象デバイスを含むグループに、プロファイルを割り当て
6. Intune 管理センターより、対象デバイスの状態を確認し、対象デバイスでも構成が変更されたことを確認

トラブルシューティング

キオスク構成が期待通りに動作しない場合、次のポイントを確認してください。

• イベント ログ:
  • Microsoft-Windows-AssignedAccess/Admin および Microsoft-Windows-AssignedAccess/Operational を確認します。Operational は既定で無効なため、XML を再適用する前に有効化してください。
  • Intune から配布した場合は、Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Admin を確認します。
  • 自動ログオンに失敗する場合は、Microsoft-Windows-Authentication User Interface/Operational を確認します。
• XML の検証: XML のスキーマエラーがある場合、構成は適用されません。エラーの詳細はイベント ログに記録されます。
• AUMID の確認: 指定した AUMID が対象端末に存在しない場合、アプリは表示されません。
• アカウントの確認: 指定したユーザーアカウントが端末上に存在することを確認してください。Assigned Access は管理者アカウントには適用されません。Shell Launcher は管理者アカウントにも適用できますが、カスタム シェルはサインインしたアカウントと同じ権限で実行されるため、標準ユーザー アカウントの使用をお勧めします。

参考情報

• Windows クライアントでキオスクを構成する
• Shell Launcher を使用して Windows クライアントのキオスクを作成する
• AssignedAccess CSP
• 割り当てられたアクセス構成 XML ファイルを作成する
• シェル起動ツール構成ファイルを作成する

以上の内容がお役に立ちましたら幸いです。
本記事の内容は執筆時点の情報に基づいており、今後の更新で動作が変更される可能性がありますこと、ご了承ください。

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

Windows Server 2016 は 2027 年 1 月 12 日にサポート終了を迎えます。本記事は、Windows Server 2016 で稼働するドメイン コントローラーを Windows Server 2022 または Windows Server 2025 へ移行、アップグレードする際の主な考慮事項や手順をまとめたものです。

ドメイン コントローラーの移行にあたっては、移行先 OS の更新プログラムで有効になる脆弱性対応を確認し、移行元 OS にも同じ脆弱性へ対応する更新プログラムを適用しておくことが重要です。移行元と移行先で脆弱性対応の状態をそろえることで、新旧のドメイン コントローラーを並行稼働させる期間の認証動作の互換性を確保します。

移行方式について

ドメイン コントローラーを新しい Windows Server へ移行する方法には、主にインプレース アップグレードとローリング アップグレードがあります。

インプレース アップグレードは、既存のドメイン コントローラー上で OS を新しいバージョンへ直接アップグレードする方式です。サーバー名や IP アドレスなどを維持できる一方、既存 OS の構成や問題を引き継ぐ可能性があり、問題が発生した場合の切り戻しにも制約があります。

ローリング アップグレードは、新しい OS をクリーン インストールしたサーバーを既存ドメインへ追加し、ドメイン コントローラーへ昇格した後、既存のドメイン コントローラーを順次降格する方式です。新旧のドメイン コントローラーを一時的に並行稼働できるため、複製や認証の正常性を確認しながら段階的に移行できます。

弊社では、既存環境への影響を抑え、問題発生時の切り分けや切り戻しを行いやすくするため、ローリング アップグレードをお勧めします。

詳細は、以下の公開情報をご確認ください。

• ドメイン コントローラーを新しいバージョンの Windows Server にアップグレードする
• ホスト名と IP アドレスを引き継ぐドメイン コントローラーの移行手順

更新プログラムについての考慮事項

脆弱性対応の段階的な展開

Active Directory、Kerberos、Netlogon、証明書ベース認証などに関する脆弱性対応では、認証への影響を抑えながら対処できるように、更新プログラムの動作が段階的に変更される場合があります。主な段階として、互換 (監査) モードと強制モードがあります。

互換 (監査) モードでは、脆弱性への保護を導入しつつ、従来の動作や脆弱性対応が完了していない認証を一時的に許容します。強制モードへ移行した際に拒否される可能性があるクライアント、アカウント、機器、アプリなどは、監査イベントや警告イベントとして記録されます。この期間にイベントを監視し、影響対象を特定して必要な対処を行います。

強制モードでは、脆弱性対応の要件を満たしていない認証や通信が拒否されます。また、互換 (監査) モードで使用できた一時的な回避設定が無効になり、互換動作へ戻せなくなる場合があります。

すべての脆弱性対応が同じ名称や展開方法を使用するわけではありません。更新プログラムを適用する前に、対象となる脆弱性ごとの公開情報を確認し、現在のフェーズ、互換設定の有無、強制モードへの移行時期、拒否される条件を確認することが重要です。

移行元の脆弱性対応を先に完了する

Windows Server 2022 または Windows Server 2025 のドメイン コントローラーを既存ドメインへ追加する前に、移行先 OS の更新プログラムで有効になる Active Directory、Kerberos、Netlogon、証明書ベース認証などの脆弱性対応を確認します。そのうえで、同じ脆弱性へ対応する Windows Server 2016 向け更新プログラムを、既存のすべてのドメイン コントローラーへ先に適用します。

移行元と移行先では OS ごとに KB 番号が異なりますが、同じ脆弱性への対応が有効であり、認証プロトコルの動作に互換性がある状態へそろえることが目的です。Windows Server 2016 側で必要な脆弱性対応、監査イベントへの対処、主要な認証シナリオの確認を完了し、認証および複製が安定していることを確認してから、Windows Server 2022 または Windows Server 2025 へのローリング アップグレードを開始します。

この順序にすると、新しい OS のドメイン コントローラーを追加した時点で、既存の Windows Server 2016 ドメイン コントローラーとの間に脆弱性対応の差異が生じることを避けられます。また、Windows Server 2016 の更新による影響を確認してから OS 移行へ進むため、問題が発生した場合の切り分けも行いやすくなります。

新規サーバーへの更新プログラムの適用順序

新規サーバーに対する更新プログラムの適用は、AD DS の役割をインストールする前でも、ドメイン コントローラーへの昇格後でも実施できます。更新プログラムには OS コンポーネントの修正が含まれるため、役割の有効化前に適用した修正も、後から AD DS をインストールして昇格した際に使用されます。

新しいサーバーには、移行計画で定めた Windows Server 2022 または Windows Server 2025 の累積更新プログラムを適用し、再起動を完了してからドメイン コントローラーへ昇格します。この時点では、既存の Windows Server 2016 ドメイン コントローラー側でも、同じ脆弱性への対応と認証への影響確認が完了している状態とします。

移行前に確認する段階的な脆弱性対応

Active Directory、Kerberos、Netlogon、証明書ベース認証に関する脆弱性対応には、更新プログラムを適用するだけでなく、監査イベントの確認や環境側の修正が必要なものがあります。

以下は、本記事の公開時点における Windows Server 2016 の更新履歴を基準に、移行前に確認する脆弱性対応を分類したものです。更新プログラムの EXPIRED 状態は今後変更される可能性があるため、実際の作業時には更新履歴と各脆弱性の最新情報を再確認してください。

互換 (監査) モード用の更新候補を確認する

各脆弱性対応について、互換 (監査) モードが導入された時期から完全強制フェーズまでに公開された、月例または帯域外 (Out-of-band: OOB) の累積更新プログラムを確認します。本記事の公開時点で EXPIRED と表示されていない更新プログラムがある場合は、段階適用の候補となります。

候補となる更新プログラムが見つかった場合は、個別の記事で目的の脆弱性対応と互換 (監査) モードが含まれることを確認します。その後、すべてのドメイン コントローラーおよび脆弱性対応に関与するサーバーへ適用し、監査イベントを一定期間収集します。検知した対象へ対処した後に、次の累積更新プログラムへ進みます。

候補がすべて EXPIRED となっている場合、または候補に目的の互換 (監査) モードが含まれない場合は、強制モードへ直接移行するものとして扱います。OOB 更新プログラムの状態は今後変更される可能性があるため、本表は利用可能性を保証するものではありません。

長期間更新されていない環境での進め方

長期間更新されていない Windows Server 2016 へ新しい累積更新プログラムを適用すると、過去に段階的に展開された複数のセキュリティ変更がまとめて有効になります。このため、最新の累積更新プログラムへ進む前に、上表を基に、現在利用できる更新プログラムで互換 (監査) モードを経由できる脆弱性対応と、強制モードへ直接移行する脆弱性対応を整理します。

Windows 10 and Windows Server 2016 update history で、月例と OOB の両方を確認します。EXPIRED と表示された更新プログラムは候補から除外し、設計時と実施直前に、候補の提供状態、修正内容、置き換え関係、前提条件、既知の問題を個別記事でご確認ください。

互換 (監査) モードを利用できる場合は、監査イベントから影響対象を特定して対処した後、次の更新プログラムへ進みます。利用できない場合は、強制モードの拒否条件を基に、暗号化方式、サービス アカウント、委任、信頼、証明書ベース認証、Netlogon、非 Windows 機器などを更新前に確認します。

各 Step の前には、Active Directory の正常性とバックアップ、主要な認証シナリオ、作業の中止基準を確認します。更新後は監査またはエラー イベントと認証結果を確認し、必要に応じてクライアントやサービスを再起動して新しい Kerberos チケットを取得します。

2020 年の更新状態から段階的に更新する例

長期間更新プログラムを適用していない環境の一例として、すべての Windows Server 2016 ドメイン コントローラーが 2020 年 12 月の累積更新プログラムで止まっているパターンを取り上げます。

以下は、このパターンから段階的な脆弱性対応を最短の手順で進めるシミュレーションです。本記事の公開時点で EXPIRED と表示されていない OOB 更新プログラムも候補に含めています。実際に使用する更新プログラムは、対象環境の現在の更新状態を起点として、作業時点の更新履歴、個別記事、既知の問題、置き換え関係を確認して決定してください。

次の図は、各脆弱性対応の互換 (監査) モード、既定動作、強制モード、完全強制モード、および本例で適用する更新プログラムの位置関係を示しています。横軸が時間、縦軸が脆弱性対応です。青色の期間が互換 (監査) モード、橙色の期間が更新後の既定動作または完全強制前の強制段階、赤色の期間が完全強制モード、ひし形が更新プログラムの適用位置を示します。強制と完全強制が分かれていない脆弱性対応は、最終的な強制フェーズを赤色で示します。

上記の図の通り、適用する更新プログラムが、次に確認する脆弱性対応の互換 (監査) モード内に収まっていることが確認できます。KB5022289 では 2022 年の 3 つの脆弱性対応を、KB5048671 では証明書ベース認証と 2024 年の PAC 検証を同時に監査し、少ない適用回数で複数の脆弱性対応となるようにしております。

Step 0: 正常性を確認してバックアップを取得する

この例では、2020 年 12 月の更新状態で確認できる Netlogon のイベント ID 5829 を基に、Secure RPC に対応していないデバイスの特定と対処が完了しており、CVE-2020-1472 への対応に問題がない状態を前提とします。

• CVE-2020-1472 Netlogon

Step 0 は更新プログラムを適用する手順ではなく、段階更新を開始する前の事前準備です。後述の「ドメイン コントローラーの正常性確認」に従って現在の状態を確認し、後続の各 Step で比較する基準として結果を保存します。

万が一の障害に備えて、すべてのドメイン コントローラーでシステム状態バックアップの取得をご検討ください。取得方法とリストア手順の詳細は、以下の記事をご確認ください。

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

Step 1: 2021 年 11 月の OOB 更新で CVE-2021-42287 の監査を開始する

本記事の公開時点では、2021 年 11 月 14 日の OOB 更新プログラム KB5008601 に EXPIRED の表示はありません。この OOB 更新プログラムを適用する目的は、CVE-2021-42287 の互換モードを有効にし、強制モードで拒否される可能性がある Kerberos チケットをイベント ID 35、36、37、38 で事前に監査することです。

2021 年 11 月の月例累積更新プログラム KB5007192 は EXPIRED となっていますが、その修正を累積的に含む KB5008601 は本記事の公開時点で EXPIRED と表示されていないため、CVE-2021-42287 の互換モードへ移行する候補として使用します。また、KB5008601 には同月の既知の Kerberos 認証問題に対する修正も含まれます。

• 2021 年 11 月 14 日 - KB5008601 (OS ビルド 14393.4771) Out-of-band
• CVE-2021-42287 で追加された監査イベントについて

すべてのドメイン コントローラーへ適用した後、Kerberos チケットの有効期間を考慮して 1 週間以上運用し、KDC のイベント ID 35、36、37、38 を確認します。イベントが記録された場合は、未更新のドメイン コントローラー、古い TGT、サードパーティー実装など、イベントに対応する原因を解消します。

Step 2: 2023 年 1 月の累積更新プログラムで 3 つの脆弱性対応をまとめて監査する

2023 年 1 月 10 日の累積更新プログラム KB5022289 を、ドメイン コントローラーと脆弱性対応に関係するメンバー サーバーへ適用します。本記事の公開時点では、KB5022289 に EXPIRED の表示はありません。

• 2023 年 1 月 10 日 - KB5022289 (OS ビルド 14393.5648)

この更新プログラムを適用する目的は、次の 3 つの脆弱性対応を互換または監査フェーズでまとめて確認することです。

• CVE-2022-37966: イベント ID 42 により Kerberos の暗号化方式に関する問題を確認する
• CVE-2022-37967: 監査モードでイベント ID 43、44 を確認する
• CVE-2022-38023: 互換モードでイベント ID 5838、5839 を確認する

KB5021654 は 2022 年 11 月相当の修正を含みますが、CVE-2022-37967 のイベント ID 43、44 が記録される監査モードは 2022 年 12 月以降です。このため、本シミュレーションでは KB5021654 を Step 2 の候補とせず、3 つの確認を同時に実施できる KB5022289 を使用します。

適用後は Kerberos チケットの有効期間を考慮して 1 週間以上監視し、検知した対象へ各脆弱性の記事に記載された対処を行います。

Step 3: 2024 年 12 月の累積更新プログラムで証明書認証と PAC 検証を監査する

2024 年 12 月 10 日の累積更新プログラム KB5048671 を、ドメイン コントローラーと PAC 検証に関係するリソース サーバーへ適用します。

• 2024 年 12 月 10 日 - KB5048671 (OS ビルド 14393.7606)

この Step では、KB5014754 の証明書ベース認証について KDC のイベント ID 39、40、41 を確認します。また、CVE-2024-26248 および CVE-2024-29056 の PAC 検証について、リソース サーバーの Security-Kerberos イベント ID 23 を確認します。弱い証明書マッピング、未更新のドメイン コントローラー、信頼先など、検知した対象を強制モードへ進む前に解消します。

• KB5014754 証明書ベース認証
• CVE-2024-26248、CVE-2024-29056 PAC 検証

Step 4: 2025 年 6 月の累積更新プログラムで CVE-2025-26647 を監査する

2025 年 6 月 10 日の累積更新プログラム KB5061010 をドメイン コントローラーへ適用します。この時点で、前の Step までに監査した脆弱性対応は強制モードへ移行するため、各イベントへの対処が完了していることを事前に確認します。

• 2025 年 6 月 10 日 - KB5061010 (OS ビルド 14393.8148)

適用後は CVE-2025-26647 の KDC イベント ID 45 を確認します。認証に使用する証明書の発行元 CA が NTAuth ストアに登録されているかを確認し、検知した対象へ対処します。

• CVE-2025-26647 Kerberos 証明書認証

Step 5: 2026 年 3 月の累積更新プログラムで CVE-2026-20833 を監査する

2026 年 3 月 10 日の累積更新プログラム KB5078938 をドメイン コントローラーへ適用します。この更新時点では CVE-2026-20833 の初期展開フェーズで動作するため、KDC のイベント ID 201、202、206、207 を監査できます。

• 2026 年 3 月 10 日 - KB5078938 (OS ビルド 14393.8957)

AES に対応していないクライアント、AES キーを保持していないサービス アカウント、AES で暗号化されたサービス チケットを処理できないアクセス先などを特定し、各イベントと公開情報に従って対処します。

• CVE-2026-20833 への対応とその影響について

Step 6: 移行元と移行先の更新状態をそろえる

Step 1 から Step 5 までの監査イベントへの対処が完了し、主要な認証、複製、DNS、SYSVOL に問題がないことを確認します。

移行先となる Windows Server 2022 または Windows Server 2025 に、Windows Server 2016 へ適用した更新プログラムと同じリリース月の月例累積更新プログラムを適用します。OS ごとに KB 番号は異なるため、それぞれの更新履歴から同じ月に対応する KB を選びます。

• Windows 10 and Windows Server 2016 update history
• Windows Server 2022 update history
• Windows Server 2025 update history

移行先 OS の再起動を完了し、Windows Server 2016 と移行先 OS で脆弱性対応の状態がそろったことを確認します。その後、新しいサーバーをドメイン コントローラーとして追加し、主要な認証シナリオを確認しながらローリング アップグレードを進めます。

今後の更新プログラムの適用について

脆弱性対応の互換 (監査) モードを活用し、強制モードへ移行する前に影響対象を確認できるようにするため、ドメイン コントローラーには更新プログラムをタイムリーに適用することをお勧めします。OS の移行時にまとめて更新するのではなく、毎月公開される更新情報、既知の問題、段階的に展開されるセキュリティ変更を確認し、検証および変更管理を行ったうえで継続的に適用してください。

更新プログラムの適用を長期間見送ると、互換 (監査) モードを利用できる期間を過ぎ、後から更新した際に強制モードへ直接移行する場合があります。その結果、事前に監査イベントから影響対象を確認する機会が得られず、認証への影響を予測しにくくなります。

本ブログでも、Active Directory の認証動作に影響する更新プログラム、段階的な展開の予定、監査イベント、強制モードへ移行する前に必要な対処などについて、引き続き情報を発信してまいります。更新プログラムを適用する際は、Windows の更新履歴や Microsoft Learn とあわせて、本ブログの関連情報もご確認ください。

ドメイン コントローラーの正常性確認

移行前の Active Directory に複製エラーや DNS の問題がある場合、新しいドメイン コントローラーを追加しても問題は解消せず、初回複製の失敗などにつながる可能性があります。移行の前後で、すべてのドメイン コントローラーの正常性を確認します。

主な確認項目は以下のとおりです。

• dcdiag /e /c /v の結果
• repadmin /replsummary の結果
• repadmin /showrepl * /csv の結果
• Directory Service、DFS Replication、DNS Server、System の各イベント ログ
• SYSVOL および NETLOGON 共有の状態
• DNS の名前解決とドメイン コントローラー ロケーターの動作
• FSMO 役割、グローバル カタログ、サイトおよびサブネットの構成

確認方法の詳細は、以下の記事をご参照ください。

• ドメインコントローラ (DC) の正常性の確認方法について

ドメインおよびフォレストの機能レベル

移行先 OS に必要な機能レベルは以下のとおりです。

• Windows Server 2022: フォレスト機能レベル Windows Server 2008 以上
• Windows Server 2025: ドメインおよびフォレスト機能レベル Windows Server 2016 以上

移行前に現在のドメインおよびフォレスト機能レベルを確認し、必要な機能レベルに達していない場合は、新しいドメイン コントローラーを昇格する前に引き上げます。機能レベルは自動的には変更されません。

機能レベルを変更する場合は、Active Directory の複製が正常であること、バックアップを取得済みであること、すべてのドメイン コントローラーが引き上げ先の機能レベルをサポートしていることを確認します。ドメイン機能レベルを先に引き上げ、その後にフォレスト機能レベルを引き上げます。

• Active Directory Domain Services の機能レベル
• Active Directory Domain Services でドメインおよびフォレストの機能レベルを上げる

Windows Server 2022 へ移行する場合の追加注意事項

本記事で整理した範囲では、Windows Server 2022 への移行について、後述する Windows Server 2025 固有の注意事項に相当する追加事項はありません。
ただし、更新プログラムと脆弱性対応の整合、Active Directory の正常性、機能レベル、SYSVOL の DFSR 移行、バックアップなど、本記事に記載した共通の要件は Windows Server 2022 への移行時にもご確認ください。

Windows Server 2025 へ移行する場合の追加注意事項

Windows Server 2025 では、Active Directory と認証に関する既定のセキュリティ設定や暗号化方式が強化されています。
Windows Server 2025 のドメイン コントローラーを追加する場合は、前述の機能レベルと更新プログラムの要件に加えて、以下の項目を昇格前にご確認ください。

参考: KRBTGT アカウントと AES キー

Windows Server 2025 のドメイン コントローラーは RC4 で暗号化された TGT を発行しません。
既存ドメインで KRBTGT アカウントに AES キーがない場合は、Kerberos 認証やログオンに失敗する可能性があります。

KRBTGT アカウントと AES キーの確認は、前述の「Step 2: 2023 年 1 月の累積更新プログラムで 3 つの脆弱性対応をまとめて監査する」に含まれています。
Windows Server 2025 のドメイン コントローラーを昇格する前に Step 2 を完了し、イベント ID 42 が記録された場合は、公開情報に従って KRBTGT アカウントのパスワード更新を計画してください。
パスワード更新は既に発行された TGT や認証済みセッションへ影響する可能性があるため、Active Directory の複製、システム状態バックアップ、メンテナンス時間、再認証方法を事前にご確認ください。

• Active Directory アカウント
• Kerberos での RC4 使用状況の検出と修復

Linux デバイスのドメイン参加を事前に検証する

Windows Server 2025 のドメイン コントローラーに Linux デバイスを参加させる構成では、使用する Linux ディストリビューション、Samba、SSSD、realmd などのバージョンと、Kerberos、LDAP、DNS の設定をご確認ください。
Windows Server 2025 には 2025 年 9 月 9 日の KB5065426 以降で Active Directory とネットワークに関する複数の修正が含まれているため、最新の累積更新プログラムを適用した検証環境で、ドメイン参加、ログオン、グループ解決、Kerberos チケットの取得を事前にご確認ください。

• 2025 年 9 月 9 日 - KB5065426 (OS ビルド 26100.6584)
• Windows Server 2025 update history

スキーマ拡張前に更新プログラムを適用する

Windows Server 2025 のドメイン コントローラーが FSMO 役割を保持する環境では、一意の値が必要な複数値属性へ重複した値を追加でき、スキーマの不一致によって Active Directory のレプリケーション エラーが発生する問題がありました。
この問題は 2025 年 11 月 11 日の KB5068861 で修正されています。

Exchange などの製品によるスキーマ拡張を行う前に、スキーマ マスターを含む Windows Server 2025 のドメイン コントローラーへ KB5068861 以降の累積更新プログラムを適用してください。
スキーマ拡張前後には、repadmin /replsummary と repadmin /showrepl * /csv を使用して、すべてのドメイン コントローラー間の複製が正常であることをご確認ください。

• 2025 年 11 月 11 日 - KB5068861 (OS ビルド 26100.7171)

LDAP 署名の既定値を確認する

Windows Server 2025 以降の新しい Active Directory 展開では、[ドメイン コントローラー: LDAP サーバー署名要件の適用] ポリシーによって LDAP 署名が既定で必要です。
Windows Server 2025 へのインプレース アップグレードでは既存の LDAP セキュリティ設定が保持されるため、展開方式によって適用される設定が異なります。

ローリング アップグレードで Windows Server 2025 のドメイン コントローラーを追加する場合も、昇格前後にこのポリシーと [ドメイン コントローラー: LDAP サーバー署名必須] の実効設定をご確認ください。
イベント ID 2887 などを監視し、署名されていない LDAP バインドを行うクライアント、機器、アプリを特定して、署名付き LDAP または LDAPS へ移行します。
互換性のために署名要件を緩和する場合は、一時的な変更として期限と対象を定め、可能な限り早く署名を有効に戻すことをお勧めします。

• Windows Server での Active Directory Domain Services の LDAP 署名

参考: RC4 のみに依存するアカウントと機器

2026 年 4 月の KB5082063 以降では、CVE-2026-20833 への対応として、Kerberos サービス チケットで使用する既定の暗号化方式が AES に変更されています。
RC4 のみに依存するアカウント、クライアント、機器への対応は、前述の「Step 5: 2026 年 3 月の累積更新プログラムで CVE-2026-20833 を監査する」に含まれています。

Windows Server 2025 のドメイン コントローラーへ 2026 年 4 月以降の更新プログラムを適用する前に Step 5 を完了し、イベント ID 201、202、206、207 と、アクセス先の機器やサービスが AES に対応していることをご確認ください。
CVE-2026-20833 のサービス チケット変更は主に SPN が登録されたアカウントに影響しますが、Windows Server 2025 では RC4 で暗号化された TGT が発行されないため、SPN の有無だけでログオンへの影響を判断しないでください。
長期間パスワードを変更していない組み込み Administrator なども含め、ログオンに使用する重要なアカウントが AES キーを保持していることをご確認ください。

• 2026 年 4 月 14 日 - KB5082063 (OS ビルド 26100.32690)
• CVE-2026-20833 への対応とその影響について

NTLMv1 への依存がないことを確認する

Windows Server 2025 では NTLMv1 が削除されており、[ネットワーク セキュリティ: LAN Manager 認証レベル] ポリシーや LmCompatibilityLevel の設定にかかわらず、NTLMv1 の認証要求は行われません。
NTLMv2 は引き続き使用できますが、NTLM 自体も非推奨であり、将来の無効化に向けた準備が必要です。

Windows Server 2025 への移行前に NTLM の監査を有効にし、サポートが終了した OS、ネットワーク機器、IP アドレスを指定した接続、SPN が登録されていないアプリなど、NTLM に依存する処理を特定します。
NTLMv1 を使用するシステムは、NTLMv2 または Kerberos へ移行してください。

• NTLM の廃止に向けた対応について

SYSVOL 複製方式の確認

Windows Server 2016 は、FRS を使用した SYSVOL 複製をサポートする最後の Windows Server リリースです。Windows Server 2019、Windows Server 2022、Windows Server 2025 のドメイン コントローラーを追加するには、SYSVOL の複製方式が DFSR へ移行済みである必要があります。

移行前に、以下のコマンドで現在の状態を確認します。

1
2

dfsrmig /getglobalstate
dfsrmig /getmigrationstate

dfsrmig /getglobalstate の結果が Eliminated (3)、日本語環境では「削除済み」であることを確認します。また、dfsrmig /getmigrationstate の結果で、すべてのドメイン コントローラーがグローバル状態 Eliminated へ正常に移行し、移行状態が一貫していることを確認します。

いずれかのドメイン コントローラーが Eliminated に到達していない場合や、移行状態が一貫していない場合は、新しいドメイン コントローラーを追加する前に FRS から DFSR への移行を完了します。

• Windows Server バージョン 1709 では FRS がサポートされなくなりました
• FRS から DFSR への移行 (SYSVOL)

バックアップと復旧手順

構成変更の前に、すべてのドメイン コントローラーでシステム状態バックアップの取得をご検討ください。取得方法とリストア手順の詳細は、以下の記事をご確認ください。

バックアップの取得だけでなく、障害発生時にどの時点で作業を中止するか、追加したドメイン コントローラーをどのように切り離すか、Active Directory の権威のない復元または権威のある復元が必要となる条件も事前に整理します。

• Active Directory のバックアップとリストア

新しいドメイン コントローラーの昇格

新しいサーバーは、ワークグループの状態からドメイン参加とドメイン コントローラーへの昇格を同時に行うのではなく、いったん既存ドメインのメンバー サーバーとして参加させた後に昇格する方法をお勧めします。

先にメンバー サーバーとして参加させると、名前解決、ドメイン参加、セキュア チャネル、時刻同期、必要な通信ポートなどの問題を昇格前に切り分けられます。ドメイン参加に関する問題と昇格処理の問題を分けて確認できるため、昇格時のトラブルを減らすことができます。

最初の新しいバージョンのドメイン コントローラーを追加する際は、スキーマ マスターおよびインフラストラクチャ マスターへ接続できる必要があります。必要な adprep /forestprep および adprep /domainprep は、昇格処理中に自動的に実行されます。

昇格後は、次の作業へ進む前に、初回複製、SYSVOL および NETLOGON 共有、DNS 登録、グローバル カタログ、イベント ログを確認します。一度に複数台を切り替えず、1 台ずつ正常性を確認しながら移行します。

コンピューター アカウントを再利用する構成では、ドメイン参加に関するセキュリティ強化の影響も確認します。

• コンピューター アカウント再利用時のドメイン参加におけるセキュリティ強化について [KB5020276]

FSMO 役割とサービスの移行

新しいドメイン コントローラーの正常性を確認した後、必要に応じて FSMO 役割を移行します。PDC エミュレーターを移行した場合は、外部時刻ソースを含む Windows Time サービスの構成を確認します。

DNS、DHCP、証明機関、NPS、Microsoft Entra Connect などを既存のドメイン コントローラーへ同居させている場合、AD DS の移行とは別に各役割およびアプリの移行計画が必要です。ドメイン コントローラーを降格する前に、依存するサービスが残っていないことを確認します。

古いドメイン コントローラーの降格

既存の Windows Server 2016 ドメイン コントローラーを降格する前に、以下を確認します。

• 新しいドメイン コントローラー間の複製が正常である
• SYSVOL および NETLOGON 共有が存在する
• DNS の委任、フォワーダー、条件付きフォワーダー、逆引きゾーンが移行済みである
• DHCP、ネットワーク機器、アプリ、スクリプトなどの DNS 参照先が変更済みである
• FSMO 役割およびグローバル カタログの配置に問題がない
• 降格対象を固定参照している LDAP、Kerberos、時刻同期などの設定がない
• 有効なシステム状態バックアップがある

正常なドメイン コントローラーは、サーバーを停止または削除するだけでなく、必ず通常の降格手順で AD DS を削除します。通常の降格ができない場合に限り、強制降格とメタデータ クリーンアップを検討します。

• ドメイン コントローラーの降格方法

まとめ

Windows Server 2016 から新しい Windows Server へドメイン コントローラーを移行する際は、新しいサーバーだけを最新にするのではなく、移行元と移行先の各 OS に対して同じ脆弱性へ対応する更新プログラムを適用することが重要です。

そのうえで、既存 Active Directory の正常性、SYSVOL の複製方式、機能レベル、バックアップを確認し、ローリング アップグレードで新しいドメイン コントローラーを 1 台ずつ追加して正常性を確認します。最後に古いドメイン コントローラーを通常の手順で降格することで、問題発生時の切り戻し余地を保ちながら移行できます。

更新履歴

• 2026/08/06: 記事を公開しました。

参考情報

• Windows Server 2012、2012 R2 からの移行、アップグレードにあたって考慮事項等まとめ
• Windows Server 2016 の新機能
• ドメイン コントローラーを新しいバージョンの Windows Server にアップグレードする
• Active Directory Domain Services の機能レベル

こんにちは、Windows サポート チームの岩永です。
本記事では、Microsoft Entra 参加デバイスにおいて、タスク スケジューラやリモート デスクトップ ユーザー グループに対して Entra ID ユーザーを指定する際の制限と、その回避策についてご案内いたします。

オンプレミスの Active Directory 参加環境から Microsoft Entra 参加環境へ移行された際に、「これまで利用していた設定で Entra ID ユーザーを指定できない」といったお問い合わせをいただくことがあります。これは Windows における Entra ID ユーザーの取り扱い上の動作によるものです。本記事ではその代表的な 2 つのケースについてご説明いたします。

タスク スケジューラにおける Entra ID ユーザーの指定

事象

Microsoft Entra 参加デバイス上のタスク スケジューラにて、タスクのプロパティで [ユーザーがログオンしているかどうかにかかわらず実行する] を選択した場合、実行アカウントとして Entra ID アカウントを指定することができません。

タスクの登録時に、オブジェクトが見つからない旨のエラーが表示される場合があります。また、タスクの実行時に資格情報に関するエラーが表示されたり、意図したユーザーでタスクが実行されなかったりする状況が発生します。

動作の詳細

残念ながら、Microsoft Entra 参加デバイスにおいて、タスク スケジューラでは Entra ID アカウントを指定した資格情報の保存に対応していません。指定可能なアカウントは、ローカル アカウント または オンプレミスの Active Directory ドメイン ユーザー アカウント となります。

回避策

本事象を回避するには、以下のいずれかの方法をご検討ください。

1. SYSTEM アカウントやローカル ユーザーを使用する
   タスクの実行に特定の Entra ID ユーザーの資格情報が必須でない場合は、SYSTEM アカウントやローカル ユーザーを実行アカウントに指定することで回避いただけます。
2. Microsoft Entra ハイブリッド参加構成に変更し、オンプレミスの Active Directory ユーザーを使用する
   ハイブリッド参加構成であれば、オンプレミスの AD 上にも存在するユーザーを指定できるため、当該ユーザーをタスクの実行アカウントとして利用できます。

補足: 処理内容に応じた実行方法の検討

タスク スケジューラで特定ユーザーの資格情報を保存して実行する以外にも、実行させたい処理の性質に応じて選択できる方法があります。たとえば、以下のような使い分けが考えられます。

• コンピューターに対して何らかの処理を実行させたい場合 → SYSTEM アカウントで実行する
• サインインしているユーザーのコンテキストで処理を実行させたい場合 → タスク スケジューラではなく、ログオン スクリプトの利用を検討する

処理の目的に合わせて適切な仕組みをご選択いただくことで、Entra ID ユーザーの資格情報をタスク スケジューラに保存せずとも、より安定した運用につながる場合がございます。

リモート デスクトップ ユーザー グループへの Entra ID アカウントの追加

事象

Microsoft Entra 参加デバイスにおいて、[設定] > [システム] > [リモート デスクトップ] から [リモート デスクトップ ユーザー] を開き、AzureAD\<UPN> の形式で Entra ID ユーザーを追加しようとすると、オブジェクトが見つからない旨のエラーが表示され、追加に失敗する場合があります。

回避策

リモート デスクトップ ユーザー グループへの Entra ID ユーザーの追加は、GUI からは行えず、コマンド ライン または MDM ポリシー を使用します。
公開情報: リモート Microsoft Entra参加済みデバイスに接続する | Microsoft Learn でも、以下のように案内されています。

リモート デスクトップ ユーザー グループは、デバイスにリモート接続するためのアクセス許可をユーザーとグループに付与するために使用されます。 ユーザーは、手動または MDM ポリシーを使用して追加できます。

それぞれの方法は以下のとおりです。

1. コマンドを使用して手動で追加する

リモート接続を許可する個々の Microsoft Entra アカウントを追加するには、以下のコマンドを実行します。<userUPN> にはユーザーの UPN (例: user@contoso.com) を指定します。

1

net localgroup "Remote Desktop Users" /add "AzureAD\<userUPN>"

なお、本コマンドは管理者権限が必要であるため、ローカルの Administrators グループのメンバーに所属しているユーザーで実行する必要があります。

2. MDM ポリシーを使用して追加する

Intune などの MDM から LocalUsersAndGroups ポリシー (CSP) を配布することで、リモート デスクトップ ユーザー グループへのメンバー追加を一元的に管理できます。詳細は公開情報の 参加済みデバイスでローカル管理者グループを管理する方法 をご参照ください。

まとめ

本記事では、Microsoft Entra 参加デバイスにおける以下の 2 点の制限と回避策についてご案内いたしました。

• タスク スケジューラでは、Entra ID アカウントを実行アカウントとして指定できません。SYSTEM アカウントやローカル ユーザーを使用するか、Microsoft Entra ハイブリッド参加構成に変更してオンプレミスの Active Directory ユーザーを使用することで回避いただけます。
• リモート デスクトップ ユーザー グループへの Entra ID ユーザーの追加は、GUI からは行えないため、コマンド ライン (net localgroup) または MDM ポリシーを使用します。

参考情報

• リモート Microsoft Entra 参加済みデバイスに接続する | Microsoft Learn

修正履歴

• 2026.07.21 本ブログを公開

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

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

Active Directory 環境のセキュリティ強化において、長年の課題となっているのが「古い暗号化方式の排除」です。
特に Kerberos 認証における RC4 (RC4-HMAC, Rivest Cipher 4) の無効化は、攻撃者による悪用を防ぐために急務となっています。
Microsoft は将来的に、ドメイン コントローラーでの RC4 の既定使用を無効化する計画を発表しています。

本記事では、Kerberos における RC4 のリスク、現状の監査方法、そして AES へ安全に移行するための手順について解説します。

本記事は、弊チームのメンバーが LinkedIn に投稿した以下の記事をベースに、内容を整理・加筆したものです。
Kerberos 認証のセキュリティ強化：RC4 から AES への移行ガイド

1. Kerberos の紹介と RC4 脆弱性

Kerberos は、Active Directory の中核となる認証プロトコルです。ユーザーが一度認証を受けると、チケットを利用してネットワーク上のリソースへアクセスします。

Kerberos 認証の流れ

参考: How the Kerberos Version 5 Authentication Protocol Works

基本的な認証フロー

1. AS-REQ/REP: クライアントが KDC（ドメイン コントローラー）に認証を要求し、TGT（Ticket Granting Ticket）を取得します。
2. TGS-REQ/REP: クライアントが TGT を提示して、特定のリソース サーバーへのアクセスに必要なサービス チケットを取得します。
3. AP-REQ/REP: 取得したサービス チケットを使って、ファイル サーバーや SQL サーバーなどのリソースにアクセスします。

なぜ RC4 から AES へ移行する必要があるのか

Windows Kerberos における RC4 は Windows 2000 時代に導入されましたが、現代の計算能力から見ると脆弱性が顕著です。特に Kerberoasting 攻撃 や AS-REP Roasting 攻撃 の標的となりやすく、パスワードが特定されるリスクが高まっています。

• ソルトの欠如: RC4 はパスワードを暗号化キーに変換する際、ソルト（Salt）を使用せず、パスワードの NTLM ハッシュをそのままキーとして使用します。
• 計算速度: パスワードを守るハッシュ関数の計算が 1 回しか行われないため、攻撃者は非常に高速に総当たり攻撃（ブルート フォース）を行うことが可能です。

2. Kerberos における暗号方式既定値変更 （CVE-2022-37966 / CVE‑2026‑20833）

Windows Server 2008 / Vista 以降の Windows OS では、より強固な AES 暗号化 (AES-SHA1) をサポートしています。Microsoft は RC4 から AES への移行を段階的に進めています。
本章では、その背景にある「Microsoft 側で進められている既定動作の変更」について、2 つのセキュリティ更新プログラムを軸に整理します。

Kerberos 認証では、1 回の認証の中で複数の鍵・チケットが暗号化されます。
RC4 から AES への移行は一度に行われたわけではなく、暗号化の対象ごとに段階的に既定値が変更されてきました。

補足: これらはいずれも “既定値” の変更です。
レジストリや msDS-SupportedEncryptionTypes 属性で RC4 を明示的に指定している場合は、更新適用後も引き続き RC4 が使用されます（詳細は本章末尾「RC4 が継続利用される条件」を参照）。

2-1. CVE-2022-37966 — セッション キーの既定値変更

2022 年 11 月のセキュリティ更新プログラム（CVE‑2022‑37966）では、Kerberos 認証における セッション キーの暗号化方式 の既定値が変更されました。

変更対象

• Kerberos のセッション キー

変更内容

msDS-SupportedEncryptionTypes 属性が未設定、または 0 (既定の暗号化タイプが未指定) のアカウントに対して、以下のように動作が変更されます。

• 従来：サービス チケットのセッション キーは RC4 で暗号化される
• 更新後：AES が既定で利用される動作へ変更

具体的にはドメイン コントローラーの DefaultDomainSupportedEncTypes の既定値 0x27 が利用され、セッションキー用途に AES が既定候補として追加されています。

ポイント

この変更は、

「暗号種別未定義アカウントのセッションキーの既定値を RC4 から AES へ変更する」

というものです。

詳細は CVE-2022-37966 への対応とその影響について をご確認ください。

2-2. CVE-2026-20833 — サービス チケットの既定値変更

2026 年の更新（CVE‑2026‑20833）では、さらに RC4 廃止が推進され、Kerberos の サービス チケット暗号化方式 の既定値が変更されました。

変更対象

• Kerberos のサービス チケット

変更内容

msDS-SupportedEncryptionTypes 属性が未設定、または 0 (既定の暗号化タイプが未指定) のアカウントに対して、以下のように動作が変更されます。

• 従来：サービス チケットは RC4 で暗号化される
• 更新後：AES が既定で利用される動作へ変更

具体的にはドメイン コントローラーの DefaultDomainSupportedEncTypes の既定値 0x18 が利用され、サービス チケットの既定の暗号化方式が AES に変更されました。

ポイント

この変更は、

「サービス チケット発行時の既定暗号方式を RC4 から AES のみに変更する」

というものです。

RC4 が継続利用される条件

以下のようなケースでは、更新適用後も RC4 は継続利用されます。

• msDS-SupportedEncryptionTypes に RC4 が明示的に設定されている場合
• レジストリやポリシーで RC4 を明示的に許可している場合

この場合、KDC は明示設定を優先するため、自動的に AES へ切り替わることはありません。

詳細は CVE‑2026‑20833 への対応とその影響について [KB5073381] をご確認ください。

3. イベント ログによる暗号化タイプの監査 (ID: 4768, 4769)

環境内で RC4 が「どこで」「誰によって」使用されているかを特定するには、ドメイン コントローラーのセキュリティ イベント ログを監査します。

監視対象イベント

• イベント ID 4768: Kerberos 認証チケット (TGT) の要求
• イベント ID 4769: Kerberos サービス チケットの要求

補足 1: ドメイン コントローラーに 2025 年 1 月以降の更新プログラムを適用することで、これらの ID:4768, 4769 イベントには詳細な暗号化情報が記録されるようになりました。監査の前に更新プログラムの確認や適用をお願いします。

補足 2: ID:4768/4769 はチケット要求時に記録され、失敗時も記録されるためトラブルシューティングに有用です。ただし、事前認証（Pre-authentication）段階で失敗した場合は、代わりに ID:4771 が記録されることがあります。

3-1. ID: 4768 (TGT 要求) の監査ポイント

TGT を正常に発行するには、「ユーザー アカウントのキー（User Key）」「クライアント端末のサポート暗号（Advertized Etypes）」「KDC の許可暗号 (GPO や Krbtgt キーなど）」の 3 者間で共通の暗号化タイプが必要です。なお、TGT 本体の暗号化は krbtgt アカウントのキーのみに依存します（クライアントは TGT 本体を復号しないため）。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

Log Name:      Security
Source:        Microsoft-Windows-Security-Auditing
Event ID:      4768
Task Category: Kerberos Authentication Service
Level:         Information
Keywords:      Audit Success
Computer:      DC1
Description:
A Kerberos authentication ticket (TGT) was requested.

Account Information: 
       Account Name:        user1
       Supplied Realm Name:  Contoso.LOCAL
       User ID:                    Contoso\user1
       MSDS-SupportedEncryptionTypes:      0x27 (DES, RC4, AES-Sk)
       Available Keys:      AES-SHA1, RC4

Service Information: 
       Service Name:        krbtgt
       Service ID:          Contoso\krbtgt
       MSDS-SupportedEncryptionTypes:      0x1F (DES, RC4, AES128-SHA96, AES256-SHA96)
       Available Keys:      AES-SHA1, RC4

Domain Controller Information:
       MSDS-SupportedEncryptionTypes:      0x1F (DES, RC4, AES128-SHA96, AES256-SHA96)
       Available Keys:      AES-SHA1, RC4

Network Information:
       Client Address:             ::ffff:192.168.1.101
       Client Port:         49770
       Advertized Etypes:   
              AES256-CTS-HMAC-SHA1-96
              RC4-HMAC-NT

Additional Information:
       Ticket Options:             0x40810010
       Result Code:         0x0
       Ticket Encryption Type:      0x12
       Session Encryption Type:     0x12
       Pre-Authentication Type:     2
       Pre-Authentication EncryptionType:  0x12

確認項目

Account Information: TGT を要求しているアカウント名です。末尾に $ がある場合はコンピューター アカウントです。

Available Keys (重要): AD に保存されている、そのアカウントで利用可能なキーの一覧です。ここに AES-SHA1 が表示されない場合、そのアカウントは AES キーを持っていません。

• 対処法: ドメイン機能レベルが 2008 以上であることを確認し、該当アカウントのパスワード変更（リセット） を実施してください。古いパスワードのままのアカウントは AES キーが生成されていないため、RC4 が使われ続けます。

補足: msDS-SupportedEncryptionTypes (msDS-SET) 属性は、AD がそのアカウントに対して「利用可能（サポート）」と認識している暗号化タイプを示す属性です。

SPN を持たない通常のユーザー アカウントでは、msDS-SupportedEncryptionTypes 属性を設定する必要はありません。ユーザー アカウントの User Key は認証に使用されますが、この属性はチケット暗号化タイプの計算に影響しません。

そのため属性値は既定で空欄となっており、2022 年 11 月更新 (CVE-2022-37966) 適用後のドメイン コントローラーでは DefaultDomainSupportedEncTypes（既定値 0x27）が適用されます。

なお、その後の CVE-2026-20833 への対応により、この DefaultDomainSupportedEncTypes の既定値はさらに 0x18（AES のみ）へ変更されます。

Service Information:

TGT は Krbtgt アカウントのパスワード ハッシュで暗号化されるため、このフィールドには Krbtgt が表示されます。もし Available Keys に AES がない場合も、同様にドメイン機能レベルは 2008 以上であることを確認のうえ、Krbtgt アカウントのパスワード変更/リセットを一度実施してください。（手順：イベント メッセージ ID 42 への対処方法について）

Domain Controller Information:

ドメイン コントローラーに関する情報です。

• msDS-SupportedEncryptionTypes: AES が表示されない場合は、ドメイン コントローラーに適用されている、ネットワーク セキュリティ: Kerberos で許可する暗号化の種類を構成する（Network security: Configure encryption types allowed for Kerberos） グループ ポリシーの設定を確認します。
  • ※ポリシーの設定値は、再起動後に msDS-SupportedEncryptionTypes 属性に反映されます。
• 通常は発生しませんが、msDS-SupportedEncryptionTypes 属性が空欄の場合のみ、ドメイン コントローラー側の DefaultDomainSupportedEncTypes レジストリ値を確認します。
  • ※他にも、DC で使用される暗号化タイプに影響を与えるレジストリは複数存在します。

Network Information:

TGT を要求したクライアント端末の情報です。

• Advertized Etypes: クライアントが申告した「サポート可能な暗号化タイプ」です。ここに AES がない場合、クライアント OS が古い（Windows Server 2003 以前など）か、古い NAS などの可能性があります。
• また、Windows OS の場合は、該当コンピューターに適用されている、ネットワーク セキュリティ: Kerberos で許可する暗号化の種類を構成する グループ ポリシーの設定を確認します。
  • ※ポリシーの設定値は、再起動後に msDS-SupportedEncryptionTypes 属性に反映されます。
• 通常は発生しませんが、msDS-SupportedEncryptionTypes 属性が空欄の場合のみ、ドメイン コントローラー側の DefaultDomainSupportedEncTypes レジストリ値を確認します。

補足: Windows デバイスについては、AES-SHA1 をサポートしていなかった最後のバージョンは Windows Server 2003 です。

Additional Information:

• Result Code は 0x0 以外であればエラーが発生しています。
• Ticket Encryption Type: TGT の暗号化タイプ
• Session Encryption Type: TGS セッション キーの暗号化タイプ
• Pre-Authentication EncryptionType: Pre-Auth（Authenticator）の暗号化タイプ
• 暗号化タイプの詳細はこちら（Auditing for encryption type）

3-2. ID: 4769 (サービス チケット要求) の監査ポイント

サービス チケットを正常に発行・利用するためには、「サービス アカウントが持つ Service Key の暗号化タイプ（msDS-SupportedEncryptionTypes）」、「クライアント端末のサポート暗号（Advertized Etypes）」「KDC の許可暗号 (GPO や Krbtgt キーなど）」の 3 者間で共通の暗号化タイプが必要です。

サービス チケット本体の暗号化方式は、サービス アカウントが持つ Service Key によってのみ決まります。（Service Key の暗号タイプは msDS-SupportedEncryptionTypes によって決めます。）クライアントはサービス チケット本体を復号しないため、クライアントとの共通暗号が影響するのは、TGS-REP のセッション キーの暗号方式のみです。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

Log Name:      Security
Source:        Microsoft-Windows-Security-Auditing
Event ID:      4769
Task Category: Kerberos Service Ticket Operations
Level:         Information
Keywords:      Audit Success
Computer:      DC1
A Kerberos service ticket was requested.

Account Information:
       Account Name:        user1
       Account Domain:             Contoso.LOCAL
       Logon GUID:          {38ebe445-41a6-abc4-7436-555181f7722c}
       MSDS-SupportedEncryptionTypes:      N/A
       Available Keys:      N/A

Service Information:
       Service Name:        DC2022
       Service ID:          Contoso\DC2022
       MSDS-SupportedEncryptionTypes:      0x1F (DES, RC4, AES128-SHA96, AES256-SHA96)
       Available Keys:      AES-SHA1, RC4

Domain Controller Information:
       MSDS-SupportedEncryptionTypes:      0x1F (DES, RC4, AES128-SHA96, AES256-SHA96)
       Available Keys:      AES-SHA1, RC4

Network Information:
       Client Address:             ::ffff:192.168.1.101
       Client Port:         49771
       Advertized Etypes:   
              AES256-CTS-HMAC-SHA1-96
              AES128-CTS-HMAC-SHA1-96
              RC4-HMAC-NT
              RC4-HMAC-NT-EXP
              RC4-HMAC-OLD-EXP

Additional Information:
       Ticket Options:             0x40810000
       Ticket Encryption Type:      0x12
       Session Encryption Type:     0x17
       Failure Code:        0x0
       Transited Services:   

確認項目

Service Information:

アクセス先のサービス（SPN）の情報です。（厳密には、SPN が登録しているオブジェクトです）

• msDS-SupportedEncryptionTypes:
  • ユーザーや gMSA アカウントで AES が表示されない場合、まず AD 側でアカウントの属性値を確認します。設定がない（空欄）の場合、DC のレジストリ DefaultDomainSupportedEncTypes の値に従います。2022/11 更新 (CVE-2022-37966) 適用後のドメイン コントローラーでは DefaultDomainSupportedEncTypes（既定値 0x27）が適用されます。なお、その後の CVE-2026-20833 への対応により、この DefaultDomainSupportedEncTypes の既定値はさらに 0x18（AES のみ）へ変更されます。
  • メンバー コンピューターで AES が表示されない場合は、コンピューターに適用されている、ネットワーク セキュリティ: Kerberos で許可する暗号化の種類を構成する グループ ポリシーの設定を確認します。
    • ※ポリシーの設定値は、再起動後に msDS-SupportedEncryptionTypes 属性に反映されます。
  • 通常は発生しませんが、msDS-SupportedEncryptionTypes 属性が空欄の場合のみ、ドメイン コントローラー側の DefaultDomainSupportedEncTypes レジストリ値を確認します。
  • ドメイン コントローラーに AES が表示されない場合は、上記の ID:4768 Domain Controller Information の記載をご参照ください。

補足: 信頼（Trust Domain Object）に AES が表示されない場合は、まずオブジェクトの msDS-SupportedEncryptionTypes 属性を確認してみてください。

Domain Controller Information / Network Information:

こちらも確認する必要がありますが、考え方は上記 ID:4768 と同じです。

Additional Information:

• Ticket Encryption Type: サービス チケットに対して KDC が選択した暗号化方式です。対象サービス アカウントの msDS-SupportedEncryptionTypes に値が設定されていない場合、暗号化方式は既定で RC4 が使用されます。
• Session Encryption Type: 2022 年 11 月の更新以降、クライアント側が AES をサポートしていることを KDC に通知している場合、セッション キーの暗号化方式は既定で AES が使用されるようになりました。（「2-1. CVE-2022-37966 — セッション キーの既定変更」にてお伝えした内容です。この制御は、DefaultDomainSupportedEncTypes レジストリにより実現しています。）

3-3. ドメイン内での RC4 利用有無を判断するために最低限確認すべきポイント

各イベントログには様々な情報が記録されますが、端的にドメイン環境において Kerberos 認証で RC4 の利用を判断するには、各イベントの以下のフィールドを確認します。
これらのフィールドのいずれかに RC4 を示す 0x17 または 0x18 が記録されている場合、当該認証要求において RC4 が利用されていることを意味します。

ID:4768 (TGT 要求) で確認するフィールド

• Ticket Encryption Type
• Session Encryption Type
• Pre-Authentication EncryptionType

ID:4769 (サービス チケット要求) で確認するフィールド

• Ticket Encryption Type
• Session Encryption Type

RC4 の無効化を最終的なゴールとされる場合は、上記のすべてのフィールドが AES を示す値（0x11 または 0x12）で記録される状態とする必要があります。

参考:各暗号化タイプの etype 値と説明

各暗号化タイプの etype 値と意味は以下の通りです。

補足 1: DES（0x1 / 0x3）は現在サポートされている OS では既定で無効化されているため、通常イベントに記録されることはありません。万一記録されている場合は、当該認証要求において DES が利用されていることを意味しますので、AES 化を進められる際には、これらの認証についても併せて AES への移行をご検討ください。
補足 2: 本表のような etype 値（単一の暗号化方式を表す番号） としての 0x18 は RC4-HMAC-EXP を指します。一方、msDS-SupportedEncryptionTypes や DefaultDomainSupportedEncTypes で使う 0x18 は ビットフラグの合算値（0x8 AES128 + 0x10 AES256）であり、「AES のみ」を意味します。両者は別の体系の値である点にご注意ください。同じ 0x18 でも文脈で意味が異なります。

3-4. AES への対応方法について

ID: 4768 / 4769 のイベント ログを監査するだけで対応を進めることも可能ですが、まずは 「2. Kerberos における暗号方式既定値変更 （CVE-2022-37966 / CVE‑2026‑20833）」に記載の内容を進めていただくことを強くお勧めいたします。
脆弱性対応の手順に沿って対応を進めることで、段階的かつ安全に、もれなく AES への移行を進めることができます。
一方、脆弱性対応を進めるだけでは、すべての認証要求で AES になるわけではありません。脆弱性対応が完了した後に、個別に ID: 4768 / 4769 のイベント ログを確認し、RC4 が利用されている認証要求に対して対応を行います。

ID:4768 (TGT 要求) の場合

Ticket Encryption Type で RC4 が記録されている場合

以下の可能性があります。

• Krbtgt アカウントのパスワードが長期間更新されておらず、AES 鍵が AD 上に保持されていない

• ドメイン コントローラーに適用された GPO（ネットワーク セキュリティ: Kerberos で許可する暗号化の種類を構成する）で AES が許可されていない

• クライアントが AES を通知していない（=Network Information のクライアントが RC4 のみを通知している）

  必要に応じて Krbtgt アカウントのパスワード更新による AES 鍵の生成を行います。手順は イベント メッセージ ID 42 への対処方法について をご参照ください。Krbtgt 側に問題がない場合は、Network Information に記載されているクライアントの AES 対応状況を確認します。

Session Encryption Type で RC4 が記録されている場合

本フィールドで RC4 が記録される場合、Network Information に記載されているクライアントが AES を通知できていない可能性が高いと考えられます。

クライアントの OS バージョンや、当該コンピューターに適用されている ネットワーク セキュリティ: Kerberos で許可する暗号化の種類を構成する グループ ポリシーの設定を確認し、必要に応じてクライアント側で AES を通知できるよう対応します。

Pre-Authentication EncryptionType で RC4 が記録されている場合

本フィールドで RC4 が記録される場合、Account Information に記載されている認証アカウントが AES の長期鍵を AD 上に保持しておらず、RC4 鍵のみが利用可能である可能性が高いと考えられます。

該当する代表的なケースは、ドメイン機能レベルが Windows Server 2008 未満であった時代に作成され、その後パスワードが更新されていないアカウントです。当該アカウントのパスワード更新を実施し、AES 鍵を AD 上に生成してください。

ID:4769 (サービス チケット要求) の場合

Ticket Encryption Type で RC4 が記録されている場合

以下の可能性があります。

• サービス アカウントの msDS-SupportedEncryptionTypes に AES が含まれていない

• サービス アカウントが AES の長期鍵を AD 上に保持していない（RC4 鍵のみ）

  対応としては、当該サービス アカウントのパスワード更新による AES 鍵の生成、もしくは msDS-SupportedEncryptionTypes に AES を含む値（AES に限定する場合は AES のみの値）への設定変更を実施します。

  なお、同じ ID:4769 イベント内の Service Information の Available Keys（サービス アカウントが実保持する鍵の etype 一覧）と Service Information の MSDS-SupportedEncryptionTypes を併用することで、必要な対処を判別できます。

• Service Information の Available Keys に AES が含まれない場合 → 当該アカウントのパスワード更新による AES 鍵の生成

• Service Information の Available Keys に AES が含まれるが Service Information の MSDS-SupportedEncryptionTypes に AES が含まれない場合 → msDS-SupportedEncryptionTypes に AES を含む値への設定変更

  補足: ドメイン機能レベルが Windows Server 2003 以前の時代に作成されたアカウントについては、1 回のパスワード更新では AES 鍵が利用可能な状態にならず、2 回以上のパスワード更新が必要となるケースがあります。

Session Encryption Type で RC4 が記録されている場合

本フィールドで RC4 が記録される場合、Network Information に記載されているクライアントが AES を通知できていない可能性が高いと考えられます。

クライアントの OS バージョンや、当該コンピューターに適用されている ネットワーク セキュリティ: Kerberos で許可する暗号化の種類を構成する グループ ポリシーの設定を確認し、必要に応じてクライアント側で AES を通知できるよう対応します。

3-5. サード パーティ製品については、イベント ログだけでなくベンダーへの確認も推奨

イベント ログからは「クライアント ↔ KDC 間で RC4 が利用されているか」までは判断できますが、「アクセス先が AES に対応しているか」は別観点での確認が必要です。もしクライアントやサービス アカウントを利用しているのがサード パーティ製品である場合は、AES のサポート状況や移行可否について、製品ベンダーへ個別にお問い合わせいただくことを推奨いたします。

なお、ここでいう「サード パーティ製品」とは、サード パーティ OS や機器に限らず、Windows 上で動作する製品であっても Kerberos 認証の実装が Windows 標準実装と異なる可能性のある製品全般を指します。 具体例としては、NAS や独自実装のサーバー アプリケーションなどが該当します。

ID:4768 / 4769 のイベント ログから把握できるのは、クライアントとドメイン コントローラー（KDC）間でやり取りされる AS / TGS 段階の暗号化タイプに限られます。
クライアントがサービスへ AP-REQ を送信する段階（下図 (5)）はドメイン コントローラーを経由しないため、ドメイン コントローラー側のイベント ログでは捕捉できません。

1
2
3
4
5

[クライアント]  --- AS-REQ  (1) --->  [KDC]       ← イベント 4768 が記録される段階
[クライアント]  <-- AS-REP  (2) ----  [KDC]
[クライアント]  --- TGS-REQ (3) --->  [KDC]       ← イベント 4769 が記録される段階
[クライアント]  <-- TGS-REP (4) ----  [KDC]
[クライアント]  --- AP-REQ  (5) --->  [サービス]   ← イベント ログでは捕捉されない段階

そのため、ドメイン コントローラー側で管理しているサービス アカウントの暗号化タイプ対応状況と、実際にサービス（サーバー側のアプリケーション）が受け入れ可能な暗号化タイプとが乖離するケースが存在します。
たとえば、サービス アカウント自体は AES 鍵を保持していても、サービス アプリケーションの実装上 RC4 のみを受け入れる、といった状況が代表的な例として挙げられます。

3-6. 効率的な監査方法

イベント ビューアーでの目視確認は手間がかかると感じられる場合は、XML フィルターを利用して、「ドメイン内での RC4 利用有無を判断するために最低限確認すべきポイント」でご紹介したフィールド（ID:4768 の Ticket Encryption Type / Session Encryption Type / Pre-Authentication EncryptionType、ID:4769 の Ticket Encryption Type / Session Encryption Type）のいずれかに RC4 を示す 0x17 または 0x18 が記録されているイベントを抽出することが可能です。

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

<QueryList>
  <Query Id="0" Path="Security">
    <Select Path="Security">
      *[System[(EventID=4768 or EventID=4769)]]
      and
      *[EventData[
        Data[@Name='TicketEncryptionType']='0x17'
        or Data[@Name='TicketEncryptionType']='0x18'
        or Data[@Name='SessionKeyEncryptionType']='0x17'
        or Data[@Name='SessionKeyEncryptionType']='0x18'
        or Data[@Name='PreAuthEncryptionType']='0x17'
        or Data[@Name='PreAuthEncryptionType']='0x18'
      ]]
    </Select>
  </Query>
</QueryList>

補足: Pre-Authentication EncryptionType は ID:4768 のみに存在する項目です。そのため、クエリ内の PreAuthEncryptionType 条件は ID:4769 のイベントでは単に成立せず、フィルターの動作には影響しません。

より多くの便利な方法を確認されたい方はこちらへ：So, you think you’re ready for enforcing AES for Kerberos? | Microsoft Community Hub

または、Microsoft’s Kerberos-Crypto GitHub repository にて公開しているスクリプトを活用します。こちらは 3-7 節で説明します。

3-7. Kerberos-Crypto スクリプトの活用

microsoft/Kerberos-Crypto リポジトリでは、4768 / 4769 のイベント ログを解析するための 2 つのPowerShell スクリプトが、オープン ソース として公開されています。「2025 年 1 月以降の更新適用済みのドメイン コントローラー」であれば、そのまま利用することが可能です。

*スクリプトは継続的に更新されています。リポジトリの scripts/ ディレクトリ から都度最新版をご利用ください。

List-AccountKeys.ps1 — アカウントで使用可能な暗号化キーを列挙する

このスクリプトを利用することで直近期間 (既定: 30 日) の 4768 / 4769 を集計し、アカウントごとに保持・利用されているキーの etype を一覧化することが可能です。「AES キーを持たないアカウントの洗い出し」 を目的とする場合に有用な方法となります。

1
2
3
4
5

# 過去 60 日で RC4 のキーがまだ観測されているアカウントのみを抽出
.\List-AccountKeys.ps1 -Since (Get-Date).AddDays(-60) -ContainsKeyType RC4

# AES-SHA1 がまだ観測されていないアカウントのみを抽出
.\List-AccountKeys.ps1 -NotContainsKeyType AES-SHA1

出力例:

1
2
3
4

Time                  Name         Type  Keys
----                  ----         ----  ----
1/21/2025 2:00:10 PM  VM01$      Machine {RC4, AES128-SHA96, AES256-SHA96, AES128-SHA256...}
1/21/2025 2:00:10 PM  AdminUser     User {RC4, AES128-SHA96, AES256-SHA96, AES128-SHA256...}

Keys 列の表示は、処理済み (processed) 値 です。Windows Server 2022 以前では、アカウントの実際の設定に関わらず RC4 が常に表示されます。「表示されていること」 = 「実際に使用された」ではない 点にご注意ください。実利用の特定には次の Get-KerbEncryptionUsage.ps1 を使います。

Get-KerbEncryptionUsage.ps1 — 使用中の Kerberos 暗号化の種類を識別し、RC4 などの特定のアルゴリズムの使用を抽出する

このスクリプトを利用することで 4768 / 4769 をリクエスト単位で抽出し、チケットの etype とセッション キーの etype をそれぞれ表示することが可能です。「実際に RC4 を要求しているクライアントの特定」 を目的とした場合に有用な方法となります。
また、このスクリプトでは以下のような引数を指定することができ、特定の etype を要求しているリクエストのみを抽出するといったようなことも可能です。

1
2

# チケットの etype が RC4 のリクエストのみを抽出する場合の実行例
.\Get-KerbEncryptionUsage.ps1 -Encryption RC4 -EncryptionUsage Ticket

出力例 (既定の Format-List 形式):

1
2
3
4
5
6
7

Time       : 1/21/2025 2:00:10 PM
Requestor  : 192.168.1.10
Source     : AdminUser@CONTOSO.COM
Target     : VM01$
Type       : TGS
Ticket     : AES256-SHA96
SessionKey : AES256-SHA96

• Source は要求元アカウント、Target はチケットの宛先 (SPN または krbtgt)。
• Ticket がリソース側 (= ターゲット アカウント) のキー、SessionKey は要求元アカウントのキーに対応します。
• Ticket が RC4 のリクエストが残っている場合、対象 SPN の msDS-SupportedEncryptionTypes (またはドメインの DefaultDomainSupportedEncTypes) の見直し対象となります。

ご利用にあたっての注意事項 (サポート対応について)

本セクションでご紹介する 2 つのスクリプトは、microsoft/Kerberos-Crypto リポジトリでオープン ソース として公開されているスクリプトであり、リポジトリの SUPPORT.md に明記のとおり、サポート対象外となりお客様ご自身の責任で事前に十分な検証のうえご利用いただく必要があります。

もし、スクリプト自体に関する機能要望やご質問がある場合には GitHub Issues にてお知らせください。今後のスクリプトの改善に役立てさせていただきます。

4. RC4 を無効化する方法

監査により RC4 利用箇所を特定し、対処が完了した後、RC4 を無効化します。

4-1. コンピューター オブジェクトに対して GPO 設定

• パス: コンピューターの構成 > ポリシー > Windows の設定 > セキュリティの設定 > ローカル ポリシー > セキュリティ オプション
• ポリシー名: 「ネットワーク セキュリティ: Kerberos で許可される暗号化の種類を構成する」 (Network security: Configure encryption types allowed for Kerberos)
• 設定: RC4_HMAC_MD5 のチェックを外し、AES128_HMAC_SHA1 と AES256_HMAC_SHA1 のみを有効にします。

4-2. レジストリによるドメイン全体の既定値変更

ドメイン コントローラー上で以下のレジストリを設定することで、ドメイン全体で RC4 を無効化可能です（影響が大きいため、十分な検証後に実施してください）。

• キー: HKEY_LOCAL_MACHINE\System\CurrentControlSet\services\KDC
• 値: DefaultDomainSupportedEncTypes
• データ: 0x18 (AES128 + AES256 のみ許可)

4-3. msDS-SupportedEncryptionTypes を設定しているアカウントの設定変更

上記の DefaultDomainSupportedEncTypes レジストリは msDS-SupportedEncryptionTypes を設定していないアカウントに対して有効です。

既定でユーザー アカウントに対して msDS-SupportedEncryptionTypes は設定していませんが、サービス アカウントなどで msDS-SupportedEncryptionTypes を手動で設定している場合は、個別に AES のみサポートするように変更します。（AES のみ：0x18）

5. 参考文献

環境内の Kerberos 認証における RC4 の無効化は大きなプロジェクトであり、段階を踏んで慎重に進める必要があります。

また、Kerberos 認証で利用されるチケットの暗号化タイプは、さまざまな要素によって決定されるほか、チケット自体も複数種類存在するため、全体像を完全に把握するのは容易ではありません。

そこで、本ブログを作成するにあたり参照した技術情報を、種類ごとに整理して共有いたします。少しでも皆さまの理解や検討の助けになれば幸いです。

Kerberos 認証フローについて

• [MS-KILE]: Kerberos Network Authentication Service (V5) Synopsis | Microsoft Learn
• Kerberos Authentication flow | Microsoft Community Hub

Kerberos 暗号化タイプについて

• Decrypting the Selection of Supported Kerberos Encryption Types | Microsoft Community Hub
• Encryption Type Selection in Kerberos Exchanges | Microsoft Learn
• [MS-KILE]: Supported Encryption Types Bit Flags | Microsoft Learn

Kerberos 認証 RC4 無効化のガイダンスや注意事項

• Detect and Remediate RC4 Usage in Kerberos | Microsoft Learn
• Decrypting the Selection of Supported Kerberos Encryption Types | Microsoft Community Hub

更新履歴

2026/07/03 : 本ブログの公開
2026/07/06 : 表記の微修正。公開日付の修正。

こんにちは、Windows サポートの丸山です。

エクスプローラーで ZIP ファイルを展開しようとすると「圧縮 (zip 形式) フォルダーは無効です」というエラーが表示されることがあります。本記事では、この事象の原因と回避策を解説します。

■ 事象

エクスプローラーで ZIP ファイルを開く、または展開しようとすると、以下のエラーが表示されます。

フォルダーを開くことができません。圧縮 (zip 形式) フォルダー ‘C:\Users\xxx\フォルダー.zip’ は無効です。

ZIP ファイル自体は破損しておらず、PowerShell の Expand-Archive コマンドレットや 7-Zip では正常に展開できます。

■ 原因

エクスプローラーの ZIP 展開機能 (zipfldr.dll) は、ZIP ファイル内の各エントリのファイル名の バイト長 を検査しています。このバイト長が 260 以上 (MAX_PATH) の場合、ZIP ファイル全体を「無効」と判定してエラーを返します。

注意すべきポイントは以下の 3 点です。

1. 判定基準は「文字数」ではなく「バイト長」
   ZIP ヘッダの File Name フィールドに格納された生のバイト数が基準です。UTF-8 エンコードの ZIP であれば UTF-8 バイト長、Shift_JIS エンコードの ZIP であれば Shift_JIS バイト長が判定対象となります。

2. ZIP 内の相対パス (エントリ名) のみが対象
   展開先フォルダーの絶対パス (C:\Users\xxx...) ではなく、ZIP ファイル内部に記録されたエントリのパスのみで判定されます。

3. LongPathsEnabled レジストリは効果なし
   zipfldr.dll は Long Path API を使用していないため、LongPathsEnabled レジストリを有効にしても、この制限は緩和されません。

日本語文字は UTF-8 で 1 文字あたり 3 バイト を消費するため (ASCII は 1 バイト)、日本語を多用するファイル名は少ない文字数で 260 バイトに到達します。目安として、日本語のみのパスでは約 86 文字が上限です。

■ 回避策

この事象は zipfldr.dll の実装上の制約であり、ZIP ファイル自体の破損ではありません。以下のいずれかの方法で回避できます。

方法 1: PowerShell の Expand-Archive コマンドレットで展開する (推奨)

.NET の System.IO.Compression を使用した展開機能であり、zipfldr.dll の制限を受けません。

1

Expand-Archive -Path "C:\Users\xxx\ファイル.zip" -DestinationPath "C:\Users\xxx\展開先"

Windows PowerShell 5.1 以降に標準搭載されているため、追加のインストールは不要です。

方法 2: 7-Zip 等のサードパーティ ツールで展開する

7-Zip をはじめとするサードパーティの展開ツールは、独自の実装を使用しており、zipfldr.dll の制約は受けません。

方法 3: ZIP 作成時のファイル/フォルダー名を短くする

ZIP ファイルの作成元において、ファイル名やフォルダー パスを短縮することで、260 バイトの制限を回避できます。

⚠ LongPathsEnabled レジストリの有効化は、本事象の回避策にはなりません。 zipfldr.dll はこの設定を参照しません。

■ まとめ

■ 検証結果

テスト 1: UTF-8 エンコード ZIP の境界値

ZIP エントリ名の UTF-8 バイト数を 258 ~ 262 で変化させた ZIP ファイルを System.IO.Compression.ZipArchive で作成し、Shell.Application COM オブジェクト (zipfldr.dll と同等) で展開を試行しました。

テスト 2: OS バージョン間比較

同一テスト (UTF-8 ZIP, 259/260/261 バイト) を複数バージョンの OS で実施しました。

調査対象の OS すべて同一のしきい値 (260)。 クライアント/サーバーを問わず、OS バージョンによる差異はありませんでした。

テスト 3: LongPathsEnabled の効果検証

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

■ 補足: ZIP ファイルのエンコーディングと MAX_PATH の背景

ここから先は、この問題がなぜ起きるのかについての技術的な背景解説です。上記の回避策で問題が解決した場合は、読み飛ばしていただいて問題ありません。

ZIP ファイルのファイル名エンコーディングの歴史

ZIP フォーマットは、1989 年に Phil Katz 氏が開発した PKZIP によって誕生しました。当時、ZIP ファイル内のファイル名は各国の OEM コードページ (日本では Shift_JIS、米国では CP437) でエンコードされていましたが、ZIP ファイルにはどのコードページを使用したかを示す情報がありませんでした。そのため、異なる言語圏の PC で ZIP を開くとファイル名が文字化けする問題が長年続いていました。

2006 年、ZIP 仕様 (APPNOTE.TXT 6.3.0) に UTF-8 フラグ (General Purpose Bit Flag の bit 11) が追加され、ファイル名を UTF-8 でエンコードできるようになりました。現在の Windows のエクスプローラーは ZIP 作成時にこのフラグを設定するため、文字化けの問題は解消されています。

なぜ日本語ファイル名で問題が起きやすいのか

UTF-8 では日本語文字は 1 文字あたり 3 バイト を消費します (Shift_JIS では 2 バイト)。同じ文字数のファイル名でも、日本語を含むと UTF-8 換算のバイト数が大きくなり、MAX_PATH (260 バイト) の制限に到達しやすくなります。

例えば、全角の 】 (UTF-8: 3 バイト) を半角の ] (UTF-8: 1 バイト) に変えるだけで 2 バイトの差が生じ、260 の境界を越えるかどうかが逆転するケースがあります。

MAX_PATH とは

Windows API で定義されている MAX_PATH は 260 です。この値は MS-DOS 時代の内部バッファサイズに由来し、ドライブ文字 2 + パス区切り 1 + パス本体 256 + NULL 終端 1 = 260 として固定されました。Win32 API が登場した Windows NT 3.1 (1993 年) 以来、30 年以上にわたってこの値は変わっていません。

Windows 10 バージョン 1607 以降、LongPathsEnabled レジストリで一部のアプリケーションに対してこの制限を緩和できるようになりましたが、zipfldr.dll はこの仕組みに対応していません。

■ 更新履歴

• 2026-06-24 初版公開

本記事では、PKI (Public Key Infrastructure / 公開キー基盤) の概要について説明します。
PKI は Windows Server の Active Directory 証明書サービス (AD CS) をはじめ、多くの Windows テクノロジの基盤となる重要な仕組みです。 身近なシナリオを例に挙げながら、PKI が解決する課題と、その基本的な仕組みについて紹介します。

PKI が必要とされる背景

はじめに、PKI がなぜ必要とされるのかを、身近な例を使って考えてみましょう。Surface 購入を例としてみます。

私たちが販売店へ直接行って、 Surface を購入する場合、商品をレジに持っていき、クレジットカードなどを利用して支払いを行い購入する、といった形になると思います。販売店へ直接行く場合は、販売店の店員さんと直接顔を合わせ、値段を確認して、確かに信頼できるお店であることを私たちが自分の目で確認して購入することができます。

一方、Microsoft Store の Web サイトで Surface を購入するシナリオでは、 購入の際に、氏名、住所、クレジットカード番号などの個人情報を Web サイト上で入力します。インターネット越しでのやりとりでは相手の姿が見えません。
入力した情報はインターネットを通じて相手に送られますが、通信経路上で通信相手以外の人に見られることはないでしょうか。また、入力した情報がどこかで書き換えられることはないでしょうか。そもそも、やり取りしている顔も見えない相手は、本当にやり取りしたい相手（Microsoft Store）なのでしょうか。
上記のような不安を簡単にまとめると、以下のような脅威に分類できるかと思います。

• 盗聴 (暗号化されていない通信の傍受): 入力したクレジットカード番号や個人情報が、通信経路上の第三者に盗み見られる可能性があります。
• 改ざん: 注文内容や支払い情報が、通信の途中で第三者によって書き換えられる可能性があります。
• なりすまし: アクセスしている Web サイトが、本物の Microsoft Store ではなく、悪意のある第三者が作成した偽のサイトであり情報が盗まれる可能性があります。

PKI は、インターネット上で見知らぬ相手とやり取りを行うにあたって、このような脅威から守る（安全にやり取りを行う）ための仕組みを提供します。

暗号技術

インターネット上で、上記のような脅威から守るため、そして PKI について理解するうえで、暗号技術が不可欠です。ここでは最低限押さえておきたい暗号方式、そしてデジタル署名について説明します。

暗号方式

暗号化方式としては大きく、共通鍵暗号方式と公開鍵暗号方式(非対称暗号) があります。
押さえておきたいポイント：

• 共通鍵暗号：暗号化と復号に同じ鍵を使う
• 公開鍵暗号：暗号化と復号に異なる鍵（公開鍵と秘密鍵）を使う

共通鍵暗号方式:

データを暗号化する鍵と、データを復号する鍵が同一の暗号方式です。公開鍵暗号方式に比べて処理速度が速いというメリットがある一方で、鍵を事前に安全な方法で共有する必要があるというデメリットがあげられます。
また、共通鍵の鍵を通信相手に事前に共有する仕組みとしては鍵交換と呼ばれる仕組みがあり、鍵交換の仕組みの例としてはハイブリッド暗号などが挙げられます。
共通鍵暗号方式の代表的なアルゴリズム:AES, 3DES, DES 等

公開鍵暗号方式(非対称暗号):

公開鍵(公開し誰でも使える鍵)とそのキーペアとなる秘密鍵(他の人には知られてはいけない鍵)の 2 つの鍵を利用する暗号化方式です。

• 公開鍵：誰に見せてもよい鍵
• 秘密鍵：持ち主だけが厳重に保管する鍵
  公開鍵暗号方式は、暗号化に使用する鍵と、復号に使用する鍵が異なっていることが特徴であり、主に次の2つの目的で利用されます。
• 暗号化：公開鍵で暗号化し、対応する秘密鍵で復号する（内容を第三者に見せないため）
• デジタル署名：秘密鍵で署名を作成し、公開鍵で検証する（送信者本人であることと改ざんされていないことを確認するため）

公開鍵暗号方式の代表的なアルゴリズム:RSA, DSA, ECDSA 等

デジタル署名

インターネット上でデータが改ざんされていないかを確認するために 、デジタル署名と呼ばれる仕組みによって実現しています。
デジタル署名は、ハッシュ アルゴリズム(ハッシュ関数) + 公開鍵の組み合わせで成り立っています。この仕組みにより、受信者は次の2点を確認できます。

• データが途中で改ざんされていないこと
• データが確かに送信者本人によって作成されたこと

ハッシュ関数

ハッシュ関数とはデータの改ざん検知に使われるもので、ハッシュ関数では任意のデータから固定長のデータを生成する関数です。
ハッシュ関数で生成された値をハッシュ値と呼ばれます。(ダイジェストという呼び方もあります。同じものです)

ハッシュ関数は不可逆関数で、ハッシュ値より元の値を算出することはできません。同じデータをハッシュ関数に入力すると同じハッシュ値が生成され、入力する文字列を1文字でも変更すると生成されるハッシュ値は全く違うものになります。
また、ハッシュ値は固定長なので、ハッシュ関数に入力する文字が “A” の一文字でも、数万行になる文字列を入力でも、同じデータサイズのハッシュ値を得られることができます。

デジタル署名の流れ

ハッシュ値と、公開鍵暗号方式の特性を生かし、デジタル署名は以下のような流れで作成と検証が行われます。

送信者が送信するデータのハッシュ値を計算し、自分の秘密鍵でそのハッシュ値を暗号化します。これがデジタル署名です。

送信者は、送信するデータとデジタル署名をセットで受信者に送信します。

受信者は同じハッシュ アルゴリズムで送信されたデータのハッシュ値を計算します。

送信されたデータと一緒に送られたデジタル署名を送信者の公開鍵で復号します。

手順 3 と手順 4 でえられたハッシュ値を比較します。一致すれば改ざんなし、不一致なら改ざんありと判断できます。

ハッシュ関数はデータが 1 文字でも異なればハッシュ値が全く異なるという性質を持っています。これによって、データの改ざんを検出します。
※本記事では広く利用されているRSA方式を例に「秘密鍵で暗号化し、公開鍵で復号する」と 説明していますが、これは比喩的な表現です。実際には、デジタル署名は 暗号化・復号ではなく、数学的な署名・検証処理として実装されています。 ここでは理解しやすさを優先した便宜上の表現を用いています。

デジタル証明書

これまでの内容から、暗号技術によって、データを第三者に読み取られたり、改ざんされたりといった脅威から守ることができることは想像できるかと思います。
やり取りがみられないように、相手から送られてきた公開鍵を使ってデータを暗号化し、やり取りが改ざんされたものではないかどうかはデジタル署名を確認すればよいわけです。実際の通信では、性能や安全性を考慮して複数の仕組みが組み合わされています。

ここで課題がまだ残っています。
この構図は、「受信者が受け取った公開鍵」 は、「本物の通信相手の公開鍵」 であることが前提に成り立ちます。見ず知らずの人が送ってきた公開鍵が、確かに本人のものであることをどのように確認すればよいでしょうか。この問題は、通信の途中に第三者が割り込んで、相手になりすまして情報を受け取ってしまうような攻撃につながります。

現実世界で考えてみましょう。私たちが、自身がその本人であることを証明するとき、どんな手段を取れるでしょうか。
例えば、運転免許証やマイナンバー カードといった身分証を提示する、といった方法が挙げられるかと思います。
身分証を提示された相手は、それらの身分証は公的機関によって本人であることが審査されたうえで発行されている、つまり信頼できる第三者機関から発行されていることをもって、本人であると信用します。

現実世界で利用される身分証明書と似た機能を持つ仕組みは、インターネットの世界でも存在します。
現在のインターネット上における PKI は、信頼のおける第三者機関を信頼する、というモデルとなっており、 「やり取りする相手の本物の公開鍵」であることを、証明機関 (CA: Certificate Authority) が発行するデジタル証明書が証明します。
※証明機関は、認証局、 CA など様々な呼び方があります。

それではここで、冒頭で挙げたMicrosoft Store の Web サイトでのやり取りの例に戻りましょう。
運転免許証などの身分証明書を公的機関から発行してもらう際、本人確認書類など必要な申請書類等を提出し発行してもらうのと同様に、デジタル証明書を発行する場合も必要な申請書類を提出し審査が行われます。
CA は 「この公開鍵は確かに Microsoft Store の Web サイトのものである」 ことを審査の上、証明機関が持つ秘密鍵を用いてデジタル署名を施すことで、デジタル証明書として発行します。CA がデジタル証明書を発行する際に、証明書発行要求元から提出された情報に含まれる公開鍵も付与されます。
※ 実際の審査内容は、証明書の種類によって異なります。

私たちがブラウザーから Microsoft Store の Web サイトにアクセスした際、Microsoft Store の Web サイトから公開鍵付きのデジタル証明書が送信されます。

ブラウザー側では、 受け取った公開鍵付きのデジタル証明書が信頼できるものなのか、つまり信頼できる第三者機関から発行されたものなのか検証（証明書検証) を行います。このようにして、やり取りする相手が本当のやり取り相手であることを確認しています。
証明検証についての詳細は次のブログでご紹介します。

まとめ

インターネット上で見知らぬ相手とやり取りを行う際、盗聴や改ざん、なりすましなどの脅威が挙げられます。そのような脅威に対して、暗号化やデジタル署名、デジタル証明書などで安全な通信を実現しています。
PKI（公開鍵基盤）は、「公開鍵・証明書・認証局を組み合わせて、相手を安全に信頼するための仕組み」です。

• 暗号化: 暗号化方式には主に共通鍵暗号方式と公開鍵暗号方式などが挙げられ、盗聴から保護する。
• デジタル署名: ハッシュ関数と公開鍵暗号方式を利用して、改ざんを検知する。
• デジタル証明書:信頼のおける第三者機関が発行したデジタル証明書を利用して、公開鍵が本人のものであると証明する。

事象

Windows Server 2025 の Hyper-V ホストにおいて、Switch Embedded Teaming (SET) を構成した仮想スイッチが、OS の再起動後に種類が「外部 (External)」から「内部 (Internal)」または「プライベート (Private)」に意図せず変更されます。
これにより、仮想マシンの外部接続が失われます。

変更後の仮想スイッチの種類は、[管理オペレーティング システムにこのネットワーク アダプターの共有を許可する] の設定に応じて異なります。

本事象発生時の確認例

1
2
3
4
5
6
7
8
9
10
11

# 再起動前
Get-VMSwitch | Format-Table Name, SwitchType
# Name           SwitchType
# ----           ----------
# vSwitch-SET    External

# 再起動後 (Internal または Private に変更される)
Get-VMSwitch | Format-Table Name, SwitchType
# Name           SwitchType
# ----           ----------
# vSwitch-SET    Private

対象 OS

• Windows Server 2025

原因

本事象は、Host Network Service (HNS) が OS 起動時に実行する仮想スイッチの整合性確認処理に起因する不具合です。

HNS にはコンテナーやネットワーク仮想化の管理に使用される仮想スイッチについて、過去の障害等で不整合な状態のまま残されたリソースを検出・クリーンアップする処理が実装されています (Windows 11 以降で追加された機能です)。

本不具合では、OS 起動時に仮想マシン管理サービス (VMMS) が SET 仮想スイッチの再構築を完了する前に HNS の整合性確認処理が実行されることで、HNS が SET 仮想スイッチを「不整合なリソース」と誤認識し、物理 NIC の紐づけを解除してしまいます。

対処策

本不具合に対する修正は、以下の 2026 年 5 月の累積更新プログラム (KB5087539) に含まれています。
そのため、2026 年 5 月以降の累積更新プログラムを適用していただくことで、本事象を改善することができます。

• 2026 年 5 月 12 日 — KB5087539 (OS ビルド 26100.32860)

[!NOTE]
上記更新プログラムの公開情報ページには本事象の修正についての記載はありませんが、当該更新プログラムに修正が含まれています。

特記事項

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

更新履歴

• 2026/06/16 : 本 Blog の公開

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

こんにちは、Windows サポートの八木です。

本記事では、以下の対象バージョンの Windows に 2026 年 6 月の更新プログラムを適用した場合に発生する OneDrive へのアクセスの問題についてお知らせいたします。

対象バージョン

Windows 11, version 25H2
Windows 11, version 24H2
Windows 11, version 23H2
Windows 11 Enterprise LTSC 2024
Windows 10 Enterprise LTSC 2021
Windows 10 Enterprise LTSC 2019
Windows 10 Enterprise LTSB 2016
Windows Server 2025
Windows Server 2022
Windows Server 2019
Windows Server 2016

事象

上記対象バージョンの Windows に対して 2026 年 6 月の更新プログラムを適用後、 エクスプローラーの左ペインに表示されている OneDrive のアイコンをクリックしても反応せず OneDrive の内容を参照できない事象が報告されています。

対処方法

2026 年 6 月 24 日（日本時間）に、Windows 11, version 24H2/25H2 向けに本問題を解消するためのプレビュー更新プログラムを公開しました。

2026 年 6 月 23 日 — KB5095093 (OS ビルド 26200.8737 および 26100.8737) プレビュー

2026 年 7 月 15 日（日本時間）に、対象バージョンに記載の全ての Windows 向けに更新プログラムを公開しました。

// Windows 11, version 24H2/25H2, Windows 11 Enterprise LTSC 2024
July 14, 2026—KB5101650 (OS Builds 26200.8875 and 26100.8875)

// Windows 11, version 23H2
July 14, 2026—KB5099414 (OS Build 22631.7376)

// Windows 10 Enterprise LTSC 2021
July 14, 2026—KB5099539 (OS Builds 19045.7548 and 19044.7548)

// Windows Server 2025
July 14, 2026—KB5099536 (OS Build 26100.33158)

// Windows Server 2022
July 14, 2026—KB5099540 (OS Build 20348.5386)

// Windows Server 2019 / Windows 10 Enterprise LTSC 2019
July 14, 2026—KB5099538 (OS Build 17763.9020)

// Windows Server 2016 / Windows 10 Enterprise LTSB 2016
July 14, 2026—KB5099535 (OS Build 14393.9339)

暫定回避策

エクスプローラーの右ペインから C:\Users<UserName><OneDrive> を参照することで OneDrive の参照や編集は可能ですので、暫定対処として、その フォルダーを右クリックし「クイック アクセスにピン留めする」選択すれば、これまでと近い操作方法でアクセス頂くことが可能です。

また、ブラウザーからオンラインで OneDrive にアクセスすることは可能です。

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

変更履歴

• 2026/06/12 : 本記事の公開
• 2026/06/24 : プレビュー更新プログラムの公開について加筆
• 2026/07/15 : 更新プログラムの公開および対象バージョンの追記

こんにちは、Windows サポート チームです。
今回は、Windows Server 2025 でフェールオーバー クラスターを構築した後に作成される「ユーザー マネージャー グループ」役割についてお知らせします。本役割が作成される動作の意味や、削除・停止に関する考え方について解説します。

対象

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

• Windows Server 2025
• フェールオーバー クラスターを構成した環境

事象

クラスターを構成した後、以下の役割が自動的に作成されます。

• 名前 : ユーザー マネージャー グループ
• 種類 : ユーザー マネージャー

結論

• クラスター構成後に「ユーザー マネージャー グループ」が作成されるのは、Windows Server 2025 の新機能であり、想定通りの正常な動作です。
• 本役割は他のクラスター リソースと依存関係を持ちませんが、システムが内部的に使用する役割のため、無効なリソースではありません。
• 削除した場合でも自動的に再作成される仕様のため、削除ではなく「停止」状態での運用を推奨します。Azure 連携を行わない環境であれば、「停止」状態で運用しても製品上の問題はありません。

ユーザー マネージャー グループとは

ユーザー マネージャー グループは、Azure Portal 上の Windows Admin Center (WAC) 連携機能や、認証プロセスにおいてシステムが内部的に使用する役割です。

あくまで内部処理専用のコンポーネントであり、管理者が意識・操作する必要はありません。そのため、クラスター構成後に本役割が作成されることは、想定通りの動作です。

なお、本役割の詳細な仕様に関する公開情報は存在しません。

クラスター構成への影響

本役割はシステムが必要に応じて自動的に利用するものであり、WSFC のクラスター構成の構築・運用において、お客様が特別な設定や意識をする必要は一切ありません。

また、本役割は他のクラスター リソースと依存関係を持たず、独立して動作する設計となっています。そのため、ファイル サーバーや仮想マシンなど他のリソースのフェールオーバー動作に影響を及ぼすことはありません。

フェールオーバー クラスター マネージャーや PowerShell を用いた一般的な管理操作 (役割追加・手動フェールオーバー・フェールバック等) においても、本役割が認証に関与することはありません。

なお、クォーラム領域と合わせて、ユーザー マネージャー グループを明示的にフェールオーバー制御する必要もありません。システムが自動的に管理するため、クォーラム等の移動に合わせて手動で追従させる必要はありません。

削除・停止について

依存関係を持たない役割であるため削除を検討される場合がありますが、本役割を手動で削除した場合でも、クラスター サービスの再起動等のタイミングで自動的に再作成される仕様です。
そのため、永続的に削除する手段や、機能を無効化する設定は存在しません。

一方、「停止」状態に設定した場合は、フェールオーバー・フェールバック実行時も、クラスター サービスの再起動時も「停止」状態が維持され、自動的に「実行中」へ遷移することはありません。「停止」状態は、管理者が明示的に「開始」操作を行わない限り維持されます。

本役割は、Azure Portal の Windows Admin Center (WAC) との認証などに関わる役割になります。
そのため、Azure との連携を行わない環境においては、「停止」状態で運用しても、クラスターの基本機能・運用に支障が生じることはなく、製品上の問題はありません。

以上を踏まえ、削除ではなく「停止」状態での運用をご検討いただけますと幸いです。

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

更新履歴

2026/06/11 : 新規作成

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

こんにちは。
Windows プラットフォーム サポート担当の吉田です。

今回は Windows Update などで更新プログラムの適用に失敗する事象を、GitHub Copilot を活用して調査する手法をご紹介します。

皆様、GitHub Copilot は利用されたことはありますでしょうか？
私は少なくとも調査に使い始めるまでは GitHub Copilot を利用したことがありませんでした。

GitHub Copilot はプログラミングを支援する AI ツールで「コードを自動生成してくれるツール」というイメージをお持ちの方が多いかと思います。
しかし、これからご紹介する手法を用いることでトラブルシューティングの手助けとなりますので、ぜひ本記事を参考にお試しいただければ幸いです。

GitHub Copilot とは

GitHub Copilot は GitHub が提供する AI コーディング アシスタントです。
コードの自動補完や生成が主な機能として知られていますが、VS Code 上のチャット機能 (Copilot Chat) では、自然言語で質問や指示を送ることで、開いているファイルやフォルダーの内容を読み取り、その内容に基づいた回答を得ることができます。

この「ファイルを読み取って自然言語で要約・分析する」能力は、プログラムのコードに限らずログ ファイルの解析にも応用できます。
更新プログラムの適用時に記録されるログは構造化されたテキストであり、Copilot にとってはコードと同様に解釈可能な対象です。
大量のログから関連するエラーや時系列を抽出し、原因と考えられる要因や対処案を提示させることで、効率的に調査を進められます。

GitHub Copilot についての情報は以下の公式サイトをご確認ください。

GitHub Copilot · あなたの AI ペア プログラマー · GitHub
https://github.com/features/copilot

GitHub Copilot を利用して、更新プログラムの適用に失敗する状況の調査を実施する

■ 事前に準備するもの

1. GitHub のアカウント
2. Visual Studio Code (以下 VS Code)

■ 事前準備

本記事は調査手法の解説をメインとするため、事前準備は概要のみ記載します。

1. 以下のサイトにアクセスして GitHub のアカウントを作成します

   GitHub · Change is constant. GitHub keeps you ahead. · GitHub
   https://github.com/

2. Visual Studio Code をインストールします

   Download Visual Studio Code - Mac, Linux, Windows
   https://code.visualstudio.com/download

3. Visual Studio Code の拡張機能にて日本語化パックをインストールします ※既にインストール済みや不要の場合はスキップしてください

   Japanese Language Pack for Visual Studio Code
   https://marketplace.visualstudio.com/items?itemName=MS-CEINTL.vscode-language-pack-ja

4. Visual Studio Code を起動し、ステータスバーの Copilot アイコンにマウスカーソルを移動して「Use AI Features (日本語メニュー：AI 機能を利用する)」を選択
   

5. GitHub Copilot で利用するアカウントでログインするように求められるため、 GitHub アカウントでログインします。

これで調査を行うための事前準備は完了です。
次のセクションにて、実際に調査を行うための作業を進めていきます。

■ ログ採取

更新プログラムが適用できない環境の調査を行うにあたり、更新プログラムの適用が失敗するコンピューター上で以下サイトの資料採取手順に沿ってログを採取します。

初期調査にご取得いただくログ情報https://jpwinsup.github.io/mslog/deployment/general/initiallog-deployment-global/

取得した情報 (ZIP ファイル) は解析作業の中で読み込むため、取得した情報を Visual Studio Code をインストールした環境にコピーしておきます。

■ 解析作業

本項では検証環境で発生した更新プログラムが適用できない問題をサンプルとして進めていきます。
以下のスクリーンショットは検証環境で取得した情報にて実施しているサンプルとなるため、実際の操作はご自身の環境に合わせて読み替えてください。

1. 事前にログ採取にて取得した ZIP を Visual Studio Code をインストールした環境にコピーして展開しておきます。

2. Visual Studio Code を起動します。
   

3. 取得した情報を Visual Studio Code で開きます。

   ファイル > フォルダーを開く > 対象のパスを選択して開く
   ※手順 1 で ZIP ファイルを展開したフォルダーを開きます
   
   

4. Ctrl + Alt + I を押下し、チャット ウィンドウを開きます。

5. 以下のような設定となっていることを確認します。

   ・Mode が Agent 、Ask 、 Plan の中から Agent モードが選択されていること
   ・調査に利用する言語モデルが意図したモデルになっていること

6. 調査したい内容をまとめ、チャット欄に入力して送信します。
   サンプルとして以下のようなプロンプトを入力して送信します。

   2026/04/12 1:00 過ぎに適用した KB5079473 の適用が失敗した要因について調査して。ログ情報から確認できた事ではなく推測が混ざる箇所については推測に基づいている旨を記載してほしい。どのような事象が発生しているか、対処案について調査結果をまとめてほしい。

   

7. 解析結果が出力されるため、結果についての疑問点などをチャット形式で質問し調査を進めます。
   
   失敗の直接的な要因や対処案など、セクションごとに整理されたレポートが出力されます。
   

8. 解析結果にて提示された対処案を実施します。
   

9. 再度更新プログラムの適用を実施し、エラーとなった場合には改めてログ採取の手順に沿って、ログを再度採取して解析作業を行います。

■ 気を付けるポイント

1. 推測に基づく調査結果なのか、ログ情報から確認できた結果であるか判断するために、プロンプトには推測に基づく場合はその旨を明記するよう指示しましょう。

2. 対処案などでレジストリの削除など、問題があった場合にシステム自体に影響があると考えられる作業の場合にはバックアップなどを取得したうえで十分に検証、検討の上自己責任にて作業実施をお願いします。

3. 利用するモデルによって動作や解析速度、AI Credits の消費が異なるため選択は注意が必要です。
   2026/06/01 以降料金体系が新しくなり、AI Credits ベースに移行されることや個人向けプランが拡充されることがアナウンスされています。
   詳細については以下のサイトを参照してご確認ください。

   GitHub Copilot · プランおよび価格
   https://github.com/features/copilot/plans?locale=ja

   Models and pricing for GitHub Copilot - GitHub Docs
   https://docs.github.com/en/copilot/reference/copilot-billing/models-and-pricing

   Plans for GitHub Copilot - GitHub Docs
   https://docs.github.com/en/copilot/get-started/plans

   Usage-based billing for organizations and enterprises - GitHub Docs
   https://docs.github.com/en/copilot/concepts/billing/usage-based-billing-for-organizations-and-enterprises

   Usage-based billing for individuals - GitHub Docs
   https://docs.github.com/en/copilot/concepts/billing/usage-based-billing-for-individuals

4. GitHub Copilot ではデータの利用ポリシーがプランによって異なります。
   GitHub Copilot Free, Copilot Pro, Copilot Pro+ , Copilot Max , Copilot Business , Copilot Enterprise など様々なプランが存在しますが個人向けプランと企業向けプランではデータの利用ポリシーが異なります。
   それぞれ最新のポリシーについては以下のサイトを参照してご確認ください。

   Managing GitHub Copilot policies as an individual subscriber - Model training and improvements
   https://docs.github.com/en/copilot/how-tos/manage-your-account/manage-policies#model-training-and-improvements

■ 最後に…

AI (GitHub Copilot) による調査結果は必ずしも正確とは限らないため、出力された内容は改めてご確認いただき、作業の実施可否についてはご自身の責任でご判断いただきますようお願いいたします。
本記事が皆様の調査の一助となりましたら幸いです。

■ 更新履歴

2026/06/08 : 本記事の公開

Type (時刻同期方式) について

Windows タイム サービスでは、以下のレジストリ値によって時刻同期の方式が決定されます。

• レジストリ キー: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters
• 値の名前: Type
• 種類: REG_SZ
  設定可能な値は以下の 4 種類です。

  Type	説明
  NTP	NtpServer レジストリ に設定されている NTP サーバーと時刻同期を行います。
  NT5DS	ドメイン階層に従って NTP サーバー (時刻ソース) が 自動的に 決定され、時刻同期を行います。
  AllSync	Type=NTP と Type=NT5DS を複合した時刻同期方式です。NtpServer に設定されている NTP サーバーとの同期が行われる場合もあれば、ドメイン階層による同期が行われる場合もあります。
  NoSync	Windows タイム サービスとして時刻同期を行わない構成です。

NtpServer (NTP サーバー) について

時刻同期先の NTP サーバーを指定するレジストリです。

• レジストリ キー: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters
• 値の名前: NtpServer
• 種類: REG_SZ
  NTP サーバーの DNS 名または IP アドレスをスペース区切りで複数指定できます。
  また、各 NTP サーバーの末尾にカンマ区切りでフラグを付与することで、同期モードや動作を指定できます。
  設定例:

  1	time.windows.com,0x9 192.168.1.100,0x9

  上記の例では、time.windows.com と 192.168.1.100 の 2 つの NTP サーバーを時刻同期先として指定し、いずれもフラグ 0x9 を付与しています。

Flag (NtpServer のフラグ) について

NtpServer レジストリ エントリでは、各 NTP サーバーの DNS 名または IP アドレスの末尾にカンマ区切りでフラグを付与できます。
フラグにより、各 NTP サーバーとの同期方式や同期間隔の制御方法を指定できます。

各フラグの意味

各フラグは以下の構成を意味します。

フラグの組み合わせ

各フラグはビットフラグであるため、組み合わせて使用できます。
よく利用される組み合わせの例は以下のとおりです。

補足:
SpecialPollInterval でポーリング間隔を明示的に制御でき、クライアント モードで NTP サーバーへ問い合わせを行います。

SpecialPollInterval について

フラグ 0x1 が指定されている場合、SpecialPollInterval レジストリ値で指定された間隔 (秒) で NTP サーバーへポーリングが行われます。

• レジストリ キー: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpClient
• 値の名前: SpecialPollInterval
• 種類: REG_DWORD
  例えば、SpecialPollInterval の値が 3600 の場合、3600 秒 (1 時間) ごとに NTP サーバーへ時刻同期の問い合わせが行われます。

設定の確認方法

現在の Windows タイム サービスの設定を確認するには、以下のコマンドをご利用いただけます。

w32tm コマンドによる確認

コマンド プロンプトまたは PowerShell を管理者権限で開き、以下のコマンドを実行します。

1

w32tm /query /configuration

上記コマンドにより、現在の Windows タイム サービスの構成情報が表示されます。
Type や NtpServer の設定値もこのコマンドの出力に含まれます。

レジストリによる確認

レジストリ エディター (regedit) を使用して、以下のレジストリ キーを直接参照することでも確認できます。

1

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters

設定変更時の注意事項

Windows タイム サービスのパラメーターを変更した場合、Windows タイム サービスの再起動で設定を反映させることができます。
以下のコマンドを管理者権限のコマンド プロンプトで実行することで、サービスの再起動が可能です。

1
2

net stop w32time
net start w32time

または、以下のコマンドで構成の再読み込みを行うこともできます。

1

w32tm /config /update

※ グループ ポリシーで Windows タイム サービスの設定を管理している環境では、レジストリを直接変更しても、
グループ ポリシーの再適用時に設定が上書きされる場合がございますのでご注意ください。

参考情報

本記事でご紹介した内容の詳細については、以下の弊社公開情報をご参照ください。

• Windows タイム サービスのツールと設定
• Windows タイム サービスのしくみ
  今回の記事が少しでも皆様のお役に立てば幸いでございます。
  ※ 本記事内容は、今後予告なく変更される場合があります。変更時には、更新履歴にて変更内容を記載いたします。

  更新履歴

  2026/6/24 : 本ブログの公開
  2026/6/26 : SpecialPollInterval の補足事項について修正いたしました。

Windows Time サービスとは

Windows Time サービス (W32Time) は、Windows OS に標準で搭載されている時刻同期を行うためのサービスです。
本サービスは NTP (Network Time Protocol) に従い、UDP ポート 123 を使用して、信頼できる時刻ソースから定期的に時刻を取得し、システム時刻を補正する役割を担っています。

なぜ時刻同期が重要なのか

ドメイン環境では、認証の既定プロトコルとして Kerberos が使用されます。
Kerberos は「チケット」と呼ばれる認証情報を用いますが、このチケットには有効期間が含まれています。
そのため、クライアント・ドメイン コントローラー・サービス間で時刻が大きくずれていると、チケットが有効期間外となり認証が失敗するシナリオが存在します。
そのためドメイン環境では、Windows Time サービスが NTP (Network Time Protocol) を用いて階層的な時刻同期を行います。
既定ではフォレスト ルート ドメインの PDC のドメイン コントローラーがドメイン内の最上位のタイム サーバーとなり、他のドメイン コントローラー、ドメイン メンバー コンピューターは自動的に同期先を選択します。
この構造により、ドメイン全体で一貫した時刻が保たれます。

Active Directory 環境における時刻同期

Active Directory 環境では、Windows Time サービスはドメイン階層に従った時刻同期を行います。
フォレスト ルート ドメインの PDC エミュレーターを外部 NTP サーバーと同期させ、その他のドメイン コントローラーやドメイン メンバー コンピューターを既定の動作 (NT5DS) とする場合、以下のような時刻同期構成となります。
このような構成により、ドメイン全体で一貫した時刻が維持される仕組みとなっています。

フォレスト ルート ドメインの PDC エミュレーター (PDCe)

フォレスト内の最上位の時刻ソースとして動作します。
外部 NTP サーバーなどの信頼できるタイム ソースと同期する構成とすることが一般的です。

その他のドメイン コントローラー

最大 6 個のクエリを活用し、同期する先のドメイン コントローラーを探索します。各クエリでは、信頼できる時刻ソースであるかや、同じサイトに所属しているかなどが考慮されています。
同期先に選定されるドメイン コントローラーは構成によって変化しますが PDCe が選択される場合が多いです。

ドメイン メンバー コンピューター

通常は、認証先のドメイン コントローラーと同期します。同期先は PDC エミュレーターに限らず、他のドメイン コントローラーが選択されることもあります。

補足:
Active Directory 環境における時刻同期の階層について、詳細は以下の弊社公開情報をご参照ください。
Windows タイム サービスのしくみ

w32tm.exe について

Windows Time サービス (W32time) の設定確認やトラブルシューティングを行う際には、w32tm.exe を利用します。
w32tm.exeでは、現在の時刻同期の状態や設定内容を確認することができます。
以下に、w32tm.exe の代表的なコマンドについてご紹介いたします。

注意:
WORKGROUP 環境や Microsoft Entra Join のみの環境では、Windows Time サービスのスタートアップの種類が [手動] であり、サービスが起動していない場合があります。その場合、w32tm.exe コマンドを実行してもサービスに接続できずエラーとなりますので、サービスを起動した上でコマンドを実行してください。

現在の時刻同期状態を確認するコマンド

現在の時刻同期状態を確認するには、以下のコマンドを実行します。

1

w32tm /query /status

本コマンドでは、以下のような情報が表示されます。
この結果に含まれる ソース: の情報から、時刻同期先の NTP サーバーを確認することができます。
なお、 ソース: の情報が “Local CMOS Clock” や “Free-runnning System Clock” である場合には時刻同期ができていないと判断できます。

1
2
3
4
5
6
7
8
9
10

C:\>w32tm /query /status
閏インジケーター: 0 (警告なし)
階層: 4 (二次参照 - (S)NTP で同期)
精度: -23 (ティックごとに 119.209ns)
ルート遅延: 0.0064089s
ルート分散: 7.7905363s
参照 ID: 0x142B5EC7 (ソース IP: x.x.x.x)
最終正常同期時刻: 2026/03/19 13:30:00
ソース: DC01.contoso.local
ポーリング間隔: 10 (1024s)

Windows Time サービスの構成を確認するコマンド

Windows Time サービスの構成内容を確認するには、以下のコマンドを実行します。

1

w32tm /query /configuration

本コマンドでは、以下のような情報が表示されます。
グループ ポリシーやレジストリによる設定がどのように反映されているかを確認する際に有効です。

• 同期タイプ（NTP / NT5DS / AllSync など）
• NtpServer の設定内容
• ポーリング間隔に関する設定
• AnnounceFlags の値

時刻同期を手動で実行するコマンド

Windows Time サービスによる時刻同期を手動で実行するには、以下のコマンドを使用します。
本コマンドでは、同期先の再探索を行ったうえで時刻同期を実行します。

1

w32tm /resync /rediscover

特定の NTP サーバーとの通信を確認する

特定の NTP サーバーとの時刻差を簡易的に確認する場合には、以下のコマンドを使用します。
本コマンドでは、指定した NTP サーバーとの時刻差がリアルタイムで表示されます。
ネットワーク疎通や応答遅延の確認を目的とした簡易的なテストとして利用されることがあります。

1

w32tm /stripchart /computer:<NTPサーバー名> /dataonly

参考情報

本記事でご紹介した内容の詳細については、以下の弊社公開情報をご参照ください。

• Windows タイム サービスのしくみ
• Windows タイム サービスのツールと設定
• Windows タイム サービスのテクニカル リファレンス
  今回の記事が少しでも皆様のお役に立てば幸いでございます。
  ※ 本記事内容は、今後予告なく変更される場合があります。変更時には、更新履歴にて変更内容を記載いたします。

更新履歴

2026/6/24 : 本ブログの公開

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

こんにちは、Windows サポートチームの三浦です。
本日はノード シャットダウン時にクラスター サービスが意図せず停止する事象について紹介させていただきます。

事象概要

Windows Server 2025、かつ、2 ノード構成の WSFC 環境において、クラスター コア リソースを所有しているノードのシャットダウンを行うと Lost Quorum によりクラスター サービスが意図せず停止する事象が発生する場合がございます。

なお、本問題はノードのシャットダウン時にのみ発生する可能性があり、ブルースクリーン / 電源断などの予期せぬノード ダウンやネットワーク障害によるハートビート断などのシナリオでの事象の発生例は確認できておりません。

発生環境

Windows Server 2025、かつ、2 ノード構成の WSFC 環境において、クラスター コア リソースを所有しているノードのシャットダウンを行うと発生する可能性がございます。

対処策

本問題は、2026 年 5 月にリリースされた更新プログラムにて修正が行われております。
KB5087539、または、KB5087539 以降にリリースされた累積更新プログラムを適用いただくことで本問題の発生を抑止することが可能でございますので、本問題が発生する場合は、該当の更新プログラムを適用いただくことをご検討ください。

回避策

更新プログラムを適用できない事情がある場合は、事前に作業対象のクラスター ノードを一時停止し、リソースのドレインを行ってからクラスター ノードのシャットダウンを行うことでも本問題の発生を回避することが可能でございます。
具体的な作業手順は本公開情報に記載がございますので、ご確認いただきますようお願いいたします。

なお、本問題の発生条件を満たす環境に限らず、WSFC 環境でノードのシャットダウンを行う場合には、事前にノードの一時停止とドレインをご実施いただくことを推奨しております。そのため、本問題の発生有無にかかわらず、メンテナンス時には上記公開情報の手順に従ってノードのシャットダウンをご実施いただくことをご検討ください。

いかがでしたでしょうか。本投稿が少しでも皆様のお役に立てば幸いです。
本情報の内容（添付文書、リンク先などを含む）は、作成日時でのものであり、予告なく変更される場合があります。