こんにちは。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 環境でノードのシャットダウンを行う場合には、事前にノードの一時停止とドレインをご実施いただくことを推奨しております。そのため、本問題の発生有無にかかわらず、メンテナンス時には上記公開情報の手順に従ってノードのシャットダウンをご実施いただくことをご検討ください。

いかがでしたでしょうか。本投稿が少しでも皆様のお役に立てば幸いです。
本情報の内容（添付文書、リンク先などを含む）は、作成日時でのものであり、予告なく変更される場合があります。

こんにちは、Windows サポート チームの中森です。
本記事では、Windows OS 既定で利用できるイベント ログの取り扱いコマンドについて、ご案内いたします。

はじめに：イベント ログ操作のインターフェースについて

イベント ログの操作インターフェースは、Windows Vista / Windows Server 2008 以降に大きく機能改善が行われており、イベント ログの取得、書き込みのインターフェースが Windows XP / Windows Server 2003 以前と異なります。

Event Logging API (Windows XP / Windows Server 2003 以前のインターフェース)
Windows Event Log API (Windows Vista / Windows Server 2008 以降のインターフェース)

Windows XP/Windows Server 2003 以前のインターフェースにつきましては、レガシーなインターフェースと定義されており、当該インターフェースを利用する OS コマンドや、PowerShell コマンドレットは利用を非推奨とアナウンスさせていただくケースがございます。

アナウンス例:
Get-EventLog
— 抜粋 —
EventLog 名詞を含む PowerShell コマンドレットは、アプリケーション、システム、セキュリティなどの Windows クラシック イベント ログでのみ機能します。 Windows Vista 以降の Windows バージョンで Windows イベント ログ テクノロジを使用するログを取得するには、Get-WinEventを使用します。
— 抜粋ここまで —

レガシーなインターフェースを利用する Windows OS 既定のコマンドやコマンドレットを利用した場合、想定外な事象が生じる可能性がございますため、移行可能な方法がある場合には、お早めに移行をご検討いただけますと幸いです。

Windows OS 既定で利用できるイベント ログの取り扱いコマンドについて

上記で、ご紹介した EventLog 名詞を含む PowerShell コマンドレットは、WinEvent 名詞のコマンドレットを利用いただくことを推奨しており、現行の運用スクリプトにて確認された場合には置き換えや以降をご検討いただけますと幸いです。弊社サポートとしても EventLog 名詞のコマンドレットにて確認される問題は対処されないことが多く、WinEvent 名詞への移行をお願いしております。

推奨されるコマンドレット例:
Get-WinEvent

ここで、大変恐縮ではございますが、特にリモート コンピューターに対してイベント ログの書き込みを行うコマンドは、レガシーなインターフェースを使用しており、互換性のために Windows OS に含まれていると、ご認識いただけますと幸いでございます。

レガシーな API 利用例:
Write-EventLog
eventcreate
Windows Script Host/LogEvent

一部、代替のコマンドが用意されているケースはございますが、リモート コンピューターの指定はコマンド既定では持ち合わせておらず、別途コンピューター間のリモート実行は、他テクノロジーを利用いただく必要がございます。

なお、Windows PowerShell を利用される場合には、PowerShell 自体にリモート コンピューターに対してコマンド実行を要求する機能が備わっており、そちらの利用をご検討いただけますと幸いです。

about_Remote_Requirements

または、他コンピューターのイベント ログを特定のサーバーにて管理されたい場合、各コンピューター上のコマンド実行ではなく、Windows イベント コレクターと呼ばれる機能をご利用いただくことも、ご検討いただけますと幸いです。

Windows イベント コレクター

修正履歴

• 2026.05.21 本ブログを公開

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

こんにちは、Windows サポートチームの八木です。
本記事では、メモ帳アプリから Microsoft Print to PDF への印刷をキャンセルした場合にアプリがクラッシュする事象についてご案内します。

事象

メモ帳アプリから Microsoft Print to PDF へ印刷する際、PDF の保存先を指定するダイアログが表示されますが、ここで [キャンセル] をクリックしてダイアログを閉じると、メモ帳アプリがクラッシュして異常終了します。この場合、編集中であった未保存のデータは失われます。事象が発生すると、アプリケーションイベントログに以下のようなイベントが記録されます。

ログの名前: Application
ソース: Application Error
日付: YYYY/MM/DD hh:mm:ss
イベント ID: 1000
タスクのカテゴリ: アプリケーション クラッシュ イベント
レベル: エラー
キーワード:
ユーザー: USERNAME
コンピューター: COMPUTERNAME
説明:
障害が発生しているアプリケーション名: Notepad.exe、バージョン: 11.2512.29.0、タイム スタンプ: 0x69d8addd
障害が発生したモジュール名: Microsoft.UI.Input.dll、 バージョン: 10.0.27107.1034、タイム スタンプ: 0x331dc33f
例外コード: 0xc0000409
フォールト オフセット: 0x000000000001b50e
フォールト プロセス ID:
アプリケーションのフォールトの開始時刻:
Faulting アプリケーション パス: C:\Program Files\WindowsApps\Microsoft.WindowsNotepad_11.2512.29.0_x64__8wekyb3d8bbwe\Notepad\Notepad.exe
Faulting モジュール パス: C:\Program Files\WindowsApps\Microsoft.WindowsAppRuntime.1.7_7000.785.2325.0_x64__8wekyb3d8bbwe\Microsoft.UI.Input.dll
Report Id:
Faulting パッケージの完全名: Microsoft.WindowsNotepad_11.2512.29.0_x64__8wekyb3d8bbwe
Faulting パッケージ相対アプリケーション ID: App

原因

メモ帳アプリによる印刷が失敗した場合にエラーダイアログを表示させようとしますが、メモ帳アプリが依存している Microsoft.WindowsAppRuntime.1.7 コンポーネントの不具合によって例外が発生し、メモ帳が異常終了します。

この Microsoft.WindowsAppRuntime.1.7 コンポーネントの不具合については、弊社開発部門において問題を認識しており現在修正を検討しています。修正が行われた際にはこの記事をアップデートしてお知らせします。

対処策

暫定対処として、印刷時にキャンセルを行わないように頂くことや、メモ帳アプリから Microsoft Print to PDF へ印刷される際には予め編集内容を保存頂くことをご検討下さい。

変更履歴

• 2026/05/18 : 本 Blog の公開

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

いつも弊社製品をご利用いただきまして誠にありがとうございます。マイクロソフトの Windows サポートチームです。
今回は、NTFS でフォーマットされた外付け USB ドライブ（USBメモリやHDDなど) の安全な取り外し時にエラーとなった場合の対応についてご案内させていただきます。

事象

NTFSでフォーマットされた外付けUSBドライブ（USBメモリやHDDなど）を接続し、タスクトレイの「ハードウェアを安全に取り外してメディアを取り出す」をクリックすると、以下のエラーメッセージが表示され、安全に取り外すことができません。

「プログラムが’ボリューム’デバイスをまだ使用しているため、デバイスを停止できません。デバイスを使用していると思われるプログラムを閉じてから、再試行してください。」

対象 OS

Windows 11 24H2 以降の OS バージョン

対応

外付け USB ドライブの既定のポリシーは「クイック取り外し」に設定されており、書き込みキャッシュは無効になっています。
そのため、エラーが表示された場合でも、”安全な取り外し” 通知アイコンを利用せずにUSBドライブを取り外していただいて問題ございません。
※ただし、ファイルコピー中などディスクにアクセスしている最中の取り外しは避けてください。

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

変更履歴

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

こんにちは、Windows サポートチームの八木です。
本記事では、Windows Server 2025 でブルースクリーン (Blue Screen of Death、BSoD、BugCheck) が発生した場合に、メモリダンプが生成されない場合がある問題とその解消方法をご案内します。

対象の OS

• Windows Server 2025

概要

一部のサードパーティ製ストレージドライバーを利用する Windows Server 2025 において、2025 年 12 月以降の更新プログラムを適用すると、ブルースクリーン (Blue Screen of Death、BSoD、BugCheck) が発生した場合に、メモリダンプが生成されない場合があります。

この問題が発生した場合、システムイベントログには以下のようなイベント volmgr ID 161 が記録され、そのイベントの詳細情報には 0x00040042 が記録されます。

Log Name: System
Source: volmgr
Date: MM/DD/YYYY hh:mm:ss
Event ID: 161
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: COMPUTERNAME
Description:
Dump file creation failed due to error during dump creation. BugCheckProgress was: 0x00040042

原因

Windows Server 2025 向けに 2025 年 12 月に公開した更新プログラム (KB5072033) において、メモリダンプの生成時に利用される弊社ドライバー diskdump.sys の実装に変更が加えられました。この変更により diskdumps.sys が使用するメモリ量が増加し、その影響でサードパーティ製ストレージドライバーで利用できるメモリが不足し、メモリダンプの生成処理が失敗する場合がありました。

解決方法

今回の事象の影響を鑑みて弊社ドライバー diskdump.sys の実装変更を従来の内容に戻すことに致しました。この新たな変更内容は 2026 年 5 月の更新プログラム (KB5087539) に含まれていますので、2026 年 5 月以降の更新プログラムを適用頂くことで、本事象を解消頂くことができます。

変更履歴

• 2026/05/13 : 本 Blog の公開

こんにちは、Windows サポート チームです。
今回は、Azure Local 24H2 環境においてクラスター シャットダウン後に全ノードを起動した際、Cluster IP Address および Cluster Name リソースが自動的にオンラインにならない場合がある事象についてお知らせします。

対象

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

• Azure Local 24H2
• Network ATC を使用して仮想ネットワーク (vNIC) が構成されている環境
• クラスター シャットダウン後に全ノードを同時に起動する運用を行っている環境

事象

クラスター シャットダウンを実施し、全クラスター ノードの OS を停止した後に再起動すると、Cluster IP Address および Cluster Name リソースが自動的にオンラインにならない場合があります。

この状態では、Cluster IP Address リソースが “CannotComeOnlineOnThisNode” の状態に遷移し、10 分後の自動リスタート試行でも “Resource is not in the right state to be restarted” としてスキップされます。
その結果、手動で Start-ClusterResource を実行しない限り、Cluster IP Address および Cluster Name がオフラインのままとなります。

フェールオーバー クラスタリングの診断ログには、以下のようなエラーが記録されます。

1

[RES] IP Address Cluster IP Address: Open: Unable to find netinterface for node <ノード番号> on network <ネットワーク GUID>, status 5035.

1

[RHS] Resource Cluster IP Address has indicated that it cannot come online on this node.

1

[RCM] Resource Cluster IP Address is not in the right state to be restarted

原因

本事象は、OS 起動時における Network ATC サービスと クラスター サービスの起動タイミングに起因する Race Condition (競合状態) によって発生します。

OS 起動時に、Network ATC サービスが仮想 NIC (vNIC) の再構成処理を行いますが、この処理中にクラスター サービスが Cluster IP Address リソースのオンライン処理を開始する場合があります。
具体的には、vManagement (compute_management) ネットワークの vNIC が以下の 3 段階の再登録処理を経る途中で、Cluster IP Address のオンライン処理が開始されるため、該当ネットワークの netinterface がまだクラスターに登録されておらず、オンラインに失敗します (status 5035)。

1. 既存のネットワークから削除
2. 一時的に別のクラスター ネットワークに再登録
3. 正しいネットワークに再登録完了

また、この失敗時の状態 “CannotComeOnlineOnThisNode” は通常の失敗とは異なる終端状態であるため、10 分後の自動リスタート処理でも再試行されず、手動での介入が必要となります。

暫定対処

クラスター シャットダウン後に全ノードを起動した場合、以下の手順で Cluster IP Address および Cluster Name を手動でオンラインにしてください。

手順

1. 全ノードの OS が起動した後、1 ～ 2 分間待機します。
2. 任意のノードで以下の PowerShell コマンドを実行します。

1

Start-ClusterResource -Name "Cluster IP Address"

上記により Cluster IP Address がオンラインになると、依存関係にある Cluster Name も自動的にオンラインになります。
その後、仮想マシンやその他のソフトウェアの導入作業等を進めていただけます。

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

本事象については、vNIC 再登録時の Race Condition に起因する既知の不具合として、開発部門にて修正を進めております。
理想的には、Network ATC の処理完了後にクラスター サービスが起動すべきとの見解であり、修正プログラムの作成に取り組んでおります。
修正プログラムのリリース時期等、具体的な情報が更新され次第、本記事でお知らせいたします。

1
2

Update:
2026 年 5 月末現在、本件につきましては引き続き開発部門にて課題として取り組んでおります。

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

更新履歴

2026/05/01 : 新規作成
2026/06/01 : 現在の対応状況を更新。

Windows プラットフォーム サポートの亀井です。

以下のバージョンの Windows において、2026 年 4 月のセキュリティ更新プログラム適用後より、
RDP ファイル (.rdp) をダブル クリック等で開いた際の動作が変更され、
リモート デスクトップ接続アプリに新しいセキュリティ警告ダイアログが表示されるようになりました。

• Windows 10
• Windows 11
• Windows Server 2016
• Windows Server 2019
• Windows Server 2022
• Windows Server 2025

当該動作変更に関しまして、弊社サポート窓口にも多くのお問い合わせをいただいておりますので、
動作変更の概要、ダイアログの動作、推奨される対処策、シナリオ別の対応方法、よくある質問をご紹介します。

動作変更の詳細につきましては、以下の公開情報にも記載されておりますので、併せてご参照ください。

• リモート デスクトップ (RDP) ファイルを開くときのセキュリティ警告について | Microsoft Learn

なお、今後の更新プログラムにより動作がさらに変更となる可能性がございます。
本記事の内容は公開日時点の情報となる点にご留意ください。

目次

概要について

• リモート デスクトップとは
• 今回の RDP セキュリティ警告の変更について
• ダイアログの動作について

対処策について

• 推奨される対処策について
• シナリオ別の対処策について

よくある質問について

• よくある質問

リモート デスクトップとは

リモート デスクトップ (RDP: Remote Desktop Protocol) は、インターネットや社内ネットワークなどのネットワーク接続を介して、別の場所にあるコンピューターへ接続するための機能です。接続先のコンピューターの画面を手元のデバイスに表示させ、ファイルを開いたり、アプリケーションを実行したり、マウスやキーボードにより操作することができます。

接続に必要な設定情報 (接続先のコンピューター名や、リダイレクトするローカル リソースなど) をあらかじめ記述したファイルが RDP ファイル (.rdp) です。RDP ファイルを使用することで、接続の都度必要な情報を入力することなく、ダブル クリックするだけで目的のコンピューターに接続することが可能です。

一方で、RDP ファイルには、クリップボード、ドライブ、カメラ、プリンターなどのローカル デバイス/リソースをリモート コンピューターと共有する設定 (リダイレクト) を含めることができるため、悪意のある第三者が細工した RDP ファイルを介して、攻撃者が用意したサーバーへ接続させ、ローカル リソースの情報を窃取するような攻撃にも悪用されうる側面がございます。

今回の RDP セキュリティ警告の変更について

2026 年 4 月のセキュリティ更新プログラム以降、RDP ファイルを開いて接続を開始する際、新しいセキュリティ警告ダイアログが表示されるようになりました。

本変更は、上述の RDP ファイルを悪用したフィッシング攻撃などからユーザーを保護することを目的としており、具体的には以下の 2 点が主な変更内容となります。

1. 初回起動時に、教育用ダイアログが表示される
   更新プログラム適用後、そのアカウントで初めて RDP ファイルを開いた際に、RDP ファイルとは何か、どのようなフィッシング リスクがあるかを説明する教育用ダイアログが表示されます。

2. RDP ファイルを開くたびに、リダイレクト リソースごとに明示的な許可が必要になる
   従来は、RDP ファイル側で指定されたリダイレクトが既定で有効となっていましたが、本変更以降は、RDP ファイルが要求するすべてのリダイレクト (クリップボード、ドライブ、プリンター、カメラ、マイク等) は既定でオフ となります。ダイアログ上でユーザー様が明示的にチェックを入れた項目のみが有効化される動作となります。

また、以下の点にもご留意ください。

• 本変更の影響を受けるのは、RDP ファイルを開いて開始される接続のみ です。mstsc 等でコンピューター名を直接入力して開始する接続については、これまでと動作は変わりません。
• RemoteApp のショートカットや RD Web アクセスからダウンロードされる RDP ファイルも、本変更の対象となります。
• Azure Virtual Desktop や Windows 365 から取得する RDP ファイルは通常 Microsoft によって署名されているため、原則としてこれらのサービスへの接続時には新しいセキュリティ ダイアログは表示されません。

現在のダイアログの動作について

今回の更新プログラム適用後に RDP ファイルを開くと、以下の順序でダイアログが表示されます。

1. 初回起動ダイアログ (教育用ダイアログ)

更新プログラム適用後、そのアカウントで初めて RDP ファイルを開いた際に 1 度のみ表示されるダイアログです。
RDP ファイルとフィッシングのリスクに関する説明が記載されております。
このダイアログで接続を許可した後は、同じアカウントでの RDP ファイル接続時には再度表示されません。

注意: この初回起動ダイアログは、後述の RedirectionWarningDialogVersion レジストリを適用しても抑止することはできません。

2. 接続セキュリティ ダイアログ

RDP ファイルを開くたびに、接続が確立される前に表示されます。
接続先のコンピューターのアドレスや、RDP ファイルが要求しているリダイレクト項目 (クリップボード、ドライブ、プリンター、カメラ、マイク、スマート カードなど) ごとにチェック ボックスが表示されます。

すべてのリダイレクトは既定ではオフとなっており、ユーザーが明示的にチェックを入れた項目のみが有効化されます。

RDP ファイルに有効なデジタル署名が付与されており、接続元のコンピューターで当該署名の証明書が信頼されているかどうかにより、以下の 2 種類に分かれます。

(A) 検証可能な発行元を含まない RDP ファイル (デジタル署名なし、または信頼されていない)

RDP ファイルがデジタル署名されていない場合、または署名が信頼されていない場合には、ダイアログ上部に「警告: 不明なリモート接続」というバナーが表示され、公開元フィールドは「不明な発行元」と表示されます。

この場合、RDP ファイルを開くたびに毎回、必要なリダイレクト項目にチェックを入れ直す必要がございます。

(B) 検証可能な発行元を含む RDP ファイル (デジタル署名あり、信頼されている)

RDP ファイルに有効なデジタル署名が付与されており、かつ接続元のコンピューターで当該署名の証明書が信頼されている場合、
ダイアログ上部に「このリモート接続の発行元を確認する」というバナーが表示され、発行元の名前が表示されます。

この場合、ダイアログ下部に「この発行元からのリモート接続に関する選択を記憶する」というチェック ボックスが表示されます。
このチェックを入れて接続した場合、以降、同じ公開元の RDP ファイルを開いた際には、チェックを入れたリダイレクト項目の選択状態が記憶される動作となります。

推奨される対処策について

「毎回ダイアログが表示されて煩わしい」や 「リダイレクト設定 (プリンターなど) を記憶させたい」などセキュリティ警告を抑制されたい場合、推奨する対応は、RDP ファイルに適切なデジタル署名を付与し、接続元のコンピューターで当該証明書を信頼させる方法となります。

上述の通り、接続元が信頼している証明書で署名された RDP ファイルを開いた場合には、「この発行元からのリモート接続に関する選択を記憶する」チェック ボックスを利用することで、毎回リダイレクトするリソースのチェックを入れ直す必要が無くなり、リダイレクト項目の選択状態を保持することが可能です。

署名をされる場合は、信頼される認証機関より発行された証明書等を利用して、rdpsign.exe コマンドで RDP ファイルに署名ください。

また、rdpsign コマンドの詳細は以下の公開情報をご参照ください。

• rdpsign | Microsoft Learn

シナリオ別の対処策について

シナリオ 1: RemoteApp / RD Web アクセス環境をご利用の場合

RD Web アクセスよりダウンロードされるデスクトップ接続、 RemoteApp 接続用の RDP ファイルも本変更の対象となります。

RD 展開プロパティにおきまして、証明書のペインより接続元が信頼しうる証明書を設定することで、発行される RDP ファイルに署名を付与することが可能です。
クライアント端末で当該証明書が信頼されている場合、ダイアログは「検証可能な発行元を含む RDP ファイル」として表示されます。

シナリオ 2: 社内配布用の RDP ファイルを利用されている場合

社内で配布している RDP ファイルについては、証明書にて rdpsign.exe で署名を実施し、GPO 等でクライアントに証明書を配布いただく方法を推奨いたします。

シナリオ 3: 一時的に以前の動作へ戻したい場合 (暫定対策)

業務影響等により、恒久対応 (署名) までの間、一時的に従来のダイアログ動作へ戻す必要がある場合には、以下のレジストリ値を設定することで、接続セキュリティ ダイアログ (2 つ目のダイアログ) を更新前のバージョンのダイアログに戻すことが可能です。

よくある質問

Q1. リダイレクト項目の選択を記憶させ、毎回チェックを入れる必要を無くすことはできますか?

A. RDP ファイルに有効なデジタル署名を付与し、接続元コンピューターで当該証明書が信頼されている場合にのみ、「この発行元からのリモート接続に関する選択を記憶する」チェック ボックスが表示され、リダイレクト項目の選択状態を記憶させることが可能です。
署名されていない RDP ファイルの場合、当該チェック ボックスは表示されず、記憶させることはできません。

Q2. セキュリティ警告ダイアログ自体を完全に非表示にすることはできますか?

A. いいえ、できません。公開情報 より、「RDP ファイルを開くたびに、接続が確立される前にセキュリティ ダイアログが表示されます」と記載されており、本ダイアログを完全に抑止する設定は提供されておりません。

Q3. mstsc からコンピューター名を直接入力して接続する場合にも、このダイアログは表示されますか?

A. いいえ、表示されません。本更新プログラムで影響を受けるのは、RDP ファイルを開くことで開始される接続のみです。

Q4. セッション コレクション側でリダイレクトを有効にしているのに、対象のリソースがリダイレクトされません。

A. 今回の変更により、セッション コレクション側でリダイレクトを許可していても、クライアント側で RDP ファイルを開く際のダイアログで対象のリソースのリダイレクトを明示的にオプトイン (チェック) しない限り、リダイレクトは動作しません。
クライアント側でリソースのリダイレクトを明示的に許可しているかご確認ください。

Q5. GPO 等で、既定で特定のリダイレクトにチェックを入れた状態にすることはできますか?

A.
署名されていない RDP ファイルにおいて、既定でリダイレクトへチェックを付与する設定は提供されておりません。
本動作変更の目的が「悪意のある RDP ファイルによる意図せぬローカル デバイスへのリダイレクトを防止する」ことにあるため、
ユーザー様による明示的な許可 (オプトイン) が必要となっております。

署名されている RDP ファイルにつきましては、接続時に表示されるセキュリティ警告ダイアログ上で「この発行元からのリモート接続に関する選択を記憶する」にチェックを入れていただくことで、以降、同じ公開元の RDP ファイルで接続する際に、リダイレクト項目の選択状態が記憶される動作となります。

Q6. RedirectionWarningDialogVersion レジストリで、新しい初回起動ダイアログも抑止できますか?

A. いいえ、できません。当該レジストリは 接続セキュリティ ダイアログ (2 つ目のダイアログ) を旧バージョンに戻すためのものであり、初回起動ダイアログ (教育用ダイアログ) は抑止されません。

参考情報

• リモート デスクトップ (RDP) ファイルを開くときのセキュリティ警告について | Microsoft Learn
• rdpsign | Microsoft Learn
• Windows App とは? | Microsoft Learn

本記事の内容が、皆様の RDP ファイルを取り巻く環境の運用のご参考となれば幸いです。

こんにちは。Windows プラットフォーム サポートの馬場です。
今回は、Microsoft の技術サポートとライセンス専門窓口であるクリアリングハウスの対応範囲に関してご案内させていただきます。

Microsoft 技術サポートに RDS (Remote Desktop Service) のライセンスに関するお問い合わせをいただくことがございますが、お問い合わせの内容によっては、ライセンス専用窓口である Microsoft クリアリングハウスが対応しているものがございます。

リモート デスクトップ ライセンス Web サイトで問題が発生している場合、または RDS ライセンス サーバーのライセンス認証またはクライアント アクセス ライセンスのインストールに関するご支援が必要な場合は、Microsoft クリアリング ハウスのサポートにお問い合わせいただく必要があります。

以下の項目に関しましては、Microsoft 技術サポートにお問い合わせいただいても代行することができないため、Microsoft クリアリング ハウスをご案内することになります。

具体的な項目は以下の公開情報内にも記載がございます。

リモート デスクトップ サーバー ライセンス

ライセンス サーバーのアクティブ化
ライセンス サーバーの非アクティブ化
ライセンス サーバーの再アクティブ化
ライセンス サーバーのダウングレード
クライアント アクセス ライセンス (CAL) に関するお問い合わせ
クライアント アクセス ライセンス (RDS CAL) のインストールまたはアクティブ化
クライアント アクセス ライセンスの転送 (RDS CAL)
クライアント アクセス ライセンスのダウングレード (RDS CAL)

上記に該当する場合には、Microsoft 技術サポートへお問い合わせいただいても承れないため、Microsoft クリアリング ハウスへのお問い合わせをご案内することになることをご留意ください。

なお、Microsoft クリアリング ハウスでは、AI による自動音声サポートで対応させていただく場合があることも、併せてご留意ください。

上記に該当する場合には、必要な情報をご準備いただいた上で、以下公開情報内の該当する項目より手順をご実施ください。
Contact Us

その他参考情報:
Activate Microsoft perpetual products using the Product Activation portal
2025 年 12月 3日以降、一部ライセンス アクティベーションは電話での対応を終了し
オンライン(https://aka.ms/aoh) に移行しております。

Windows ライセンス認証における電話認証手順の変更について
上記に伴い、オンラインサイト(https://aka.ms/aoh) のご利用方法を上記でご案内しております。

更新履歴 - Update History

• 2026/07/10 : Microsoft クリアリング ハウス URL更新

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

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

はじめに — よくある疑問

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

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

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

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

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

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

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

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

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

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

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

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

1
2
3
4

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

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

Roaming フォルダー

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

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

Local フォルダー

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

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

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

LocalLow フォルダー

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

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

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

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

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

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

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

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

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

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

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

1
2

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

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

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

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

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

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

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

6. 環境変数の対応表

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

参考情報

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

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

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

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

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

対象バージョン

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

事象

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

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

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

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

原因

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

回避策

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

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

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

変更履歴

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

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

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

目次

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

1. Sysprep の考え方

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

実際に、

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

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

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

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

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

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

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

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

8. まとめ

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

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

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

9. 参考技術情報

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

特記事項

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

更新履歴

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