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

Windows 10 バージョン 1607 および Windows Server 2016 (ビルド 14393) 以降のセキュリティが強化された Windows ファイアウォールで、既定で有効である受信の規則 "mDNS (UDP 受信)" が、正常に機能しない事象が確認されております。

該当の規則は、同OSバージョンからサポートされるようになった mDNS (マルチキャストDNS) の通信を許可するための規則となりますが、現在の Windows 10 ならびに Windows Server 2016 の OS バージョンでは、製品の不具合により通信が許可されません。

この不具合については、将来のOSバージョンにて修正を検討しておりますが、次の手順で該当の規則を上書き設定することで問題を回避することができます。

- 手順

1. [スタート (Windows ロゴ)] – [Windows 管理ツール] – [セキュリティが強化された Windows ファイアウォール] をクリックします。

2. 左ペインの [受信の規則] を右クリックして [新しい規則] をクリックします。

3. 規則の種類の選択画面で [事前定義] を選択して、セレクトボックスから "mDNS" を選択し、[次へ] をクリックします。

4. 事前定義された規則の画面で、中央の規則の欄に表示された "mDNS (UDP 受信)" にチェックを入れ、[次へ] をクリックします。

5. 操作の画面で、[接続を許可する] を選択して [完了] をクリックします。

皆様、こんにちは。Windows プラットフォーム サポート担当の永谷です。

今回は "無線 LAN プロファイル  (接続するための設定) をグループ ポリシー (以後 : GPOと表記) を利用して

ドメイン クライアントへ配布する手順" を紹介します。

これまで手動で端末ごとに無線 LAN プロファイルを設定頂いていた方も、

これを機に GPO のご利用についても併せてご検討ください。

- 対象の環境

・ 無線 LAN 接続に、Windows 標準の無線 LAN サプリカントを利用している

・ ドメイン に参加しており GPO の適用が可能な無線 LAN クライアント

- 本 Blog 内で設定する内容

認証方式に EAP-TLS を利用しコンピューターのクライアント証明書を利用して RADIUS 認証を実施する設定を実施。

★ 具体的な設定は下記の通りです。

-----------------------------

ポリシー名 : wlan

プロファイル名 : testssid

接続先 SSID : testssid

自動接続 : はい

ステルス SSID を利用 : いいえ

認証 : WPA2-エンタープライズ

暗号化 : AES

ネットワークの認証方法 : EAP-TLS

認証モード : コンピューターの認証

-----------------------------

上記の設定をご利用いただく場合、事前にクライアントに EAP の要件を満たした

コンピューター証明書をインポートしておく必要がございます。

タイトル : PEAP および EAP の証明書の要件

URL : https://technet.microsoft.com/ja-jp/library/cc731363(v=ws.11).aspx

===============================

設定方法 (Windows Server 2012 R2 を利用した場合)

===============================

ドメイン クライアントに対して無線 LAN プロファイル する場合はグループポリシーを利用した方法を使用し、設定を行う事が可能です。

1. ドメイン コントローラーでグループポリシーの管理を起動します

2. グループ ポリシーを適用したい任意の OU 等を右クリックし、[このドメインに GPO を作成し、このコンテナにリンクする] を選択します。

3. 任意の GPO 名を入力し OK をクリックします。

4. 作成された GPO を右クリックし、編集 をクリックします。

5. 以下のパスを展開し、[Windows Vista 以降のリリース用の新しいワイヤレス ネットワーク ポリシーの作成] をクリックします。

コンピュータの構成

  ポリシー

      Windows の設定

         セキュリティの設定

             ワイヤレス ネットワーク (IEEE 802.1) ポリシー

6. [以下のプロファイルの順序で利用できるネットワークに接続します" 下部の [追加] をクリックします。

7. プロファイル名を入力します。

8. ネットワーク名 (SSID) を入力し、右の [追加] をクリックください。

この時点で以下のように表示されている事をご確認ください。

9. 続けて [セキュリティ] タブをクリックします。

10. [ネットワークの認証方法の選択] にて "Microsoft : スマート カードまたはその他証明書" を選択します。

11. 続けて [認証モード] より "コンピューター認証" を選択します。

この時点で以下のように表示されている事をご確認ください。

12. 設定に間違いがなければ [OK] をクリックします。

13. "ネットワークのアクセス許可" タブを開きます。

以下のように構成されていれば特に変更頂く必要はございません。

14. [OK] ボタンをクリックし、プロパティ画面を閉じます。

15. Windows のドメイン クライアントを再起動するか、

管理者ユーザーで起動したコマンド プロンプトにて gpupdate /force を実行し、グループ ポリシーを適用します。

★ 次回は無線 LAN クライアントを特定の SSID にしか繋げさせない場合の設定方法をご案内予定です。

特記事項

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

皆様、こんにちは。Windows プラットフォーム サポート担当の永谷です。

今回はグループ ポリシー (以後 : GPOと表記) を利用して無線 LAN 接続を行う SSID を制限する方法を紹介します。
グループ ポリシーを利用した無線 LAN プロファイルの配布方法については以下の弊社公式 Blog を参照ください。

タイトル : 無線 LAN プロファイルをグループ ポリシー利用して配布する手順について
URL : https://blogs.technet.microsoft.com/jpntsblog/2018/04/30/gpo_wlanprofile/

- 対象の環境
・ 無線 LAN 接続に、Windows 標準の無線 LAN サプリカントを利用している
・ ドメイン に参加しており GPO の適用が可能な無線 LAN クライアント

===============================
設定方法 (Windows Server 2012 R2 を利用した場合)
===============================

1. ドメイン コントローラーでグループポリシーの管理を起動します
2. グループ ポリシーを適用したい任意の OU 等を右クリックし、"このドメインに GPO を作成し、このコンテナにリンクする" を選択します。
3. 任意の GPO 名を入力し OK をクリックします。
4. 作成された GPO を右クリックし、編集 をクリックします。
5. 以下のパスを展開し、"Windows Vista 以降のリリース用の新しいワイヤレス ネットワーク ポリシーの作成" をクリックします。

コンピュータの構成

  ポリシー

      Windows の設定

         セキュリティの設定

             ワイヤレス ネットワーク (IEEE 802.1) ポリシー

例) "connect" という SSID への接続のみを許可したい場合は、以下のように設定します。
ネットワーク名 : connect
ネットワークの種類 : インフラストラクチャ
アクセス許可 : 許可

6. 以下のように "アドホック ネットワークに接続しない"、"インフラストラクチャ ネットワークに接続しない" にチェックを入れます。

7. [OK] ボタンをクリックし、プロパティ画面を閉じます。
8. Windows クライアントを再起動するか、管理者ユーザーで起動したコマンド プロンプトにて gpupdate /force を実行し、

グループ ポリシーを適用します。
9. "connect" 以外の SSID に接続できなくなっている事をご確認ください。

下記の画像は Windows 10 での GPO 適用後の表示例ですが、接続制限されている (許可されていない)  SSID のアイコン表示が変化していることが確認できます。

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

こんにちは。Windows サポート チームの矢澤です。
今回は Windows 10 RS2 (1703) 以降における Microsoft アカウントとの「設定の同期」の仕様変更についてご案内いたします。

 
1. RS1 (1607) 以前の動作
[設定] - [アカウント] - [メール ＆ アプリのアカウント] にて [Microsoft アカウント] から Microsoft アカウントを追加することにより「設定の同期」が利用できます。

2. RS2 (1703) 以降の動作
ドメイン ユーザーにおいては、Microsoft アカウントを追加しても、「設定の同期」が無効化されており、グレーアウトします。
 

 
3. 仕様変更の理由
ドメイン ユーザーにて「設定の同期」が行われると、ドメインの管理者が意図しない設定が有効になることから、ドメイン ユーザー アカウントと Microsoft アカウントを同期させない要望が弊社に多数寄せられた結果、RS2 (1703) 以降においてドメイン ユーザーでは Microsoft アカウントと「設定の同期」が無効 (グレーアウト) となるように仕様が変更されました。
 

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

Windows 10 Version 1607 および Windows Server 2016 の KB4074590 の「既知の問題」について、本 Blog で補足します。
KB4074590 (OS Build 14393.2068)
KB4074590 (OS ビルド 14393.2068)

[ 問題の概要 ]
Windows 10 Version 1607 および Windows Server 2016 の KB4074590 で、以下の現象を公開しています。

[ 問題の詳細 ]
KB4074590 で winnat.sys ドライバーの不具合を修正した結果、winnat.sys が予約する TCP ポート番号が変化します。
これにより、KB4074590 を適用すると、以前はアプリケーション用に予約できていたポート番号を winnat.sys が予約することで、そのアプリケーション用に予約できなくなる可能性があります。

[ 対応策 ]
この不具合修正は KB4074590 以降の更新プログラムにも引き継がれます。
仮に KB4074590 を適用せずに、それ以降の更新プログラムを適用しますと、KB4074590 に記載の本現象が発生する可能性があります。

KB4074590 以降の更新プログラムを適用する際に、一度、本現象に記載の「回避策」を実施ください。

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

こんにちは。Windows プラットフォーム サポートです。
Windows 10 Version 1703 (RS2) 以降の Windows 10 において、固定ユーザー プロファイルを利用したユーザーで端末にログオンすると、スタート メニュー (タスクバー左端の Windows ロゴ マーク) が動作しない場合がございますので、本 Blog にて補足します。

[問題の概要]
固定ユーザー プロファイル用のプロファイルを作成する際に、Windows 10 version 1703 以降の Windows 10 では、以下のように手順内の [コピー先] ダイアログの UI が、Windows 10 version 1703 より前の Windows 10 と異なっております。

図. CopyTo ダイアログ

※ "コピー先" ダイアログ は、参考情報 Create mandatory user profiles の How to create a mandatory user profile 項目の手順 9 のダイアログに該当します。

Windows 10 RS2 以降で実装されております本チェックボックスは、チェックした状態で固定ユーザー プロファイルを作成すると、スタート メニュー (タスクバー左端の Windows ロゴ マーク) が動作しない事象が発生します。
なお、2018 年 6 月時点においても修正予定は未定となりますので、本チェックボックスの詳細については、修正完了後に本ブログで改めてご案内いたします。

[回避策]
"固定プロファイル" のチェックボックスをチェックしない状態で手順を進めれば、従来通りの構成内容で固定ユーザー プロファイルを作成できますので、不具合が修正されるまではチェックボックスをチェックしない状態で固定ユーザー プロファイルを作成してください。

[今後の方針]
現在、弊社開発チームにて不具合修正に向けて調査を進めております。
不具合が修正されましたら本ブログにて公開しますので、恐れ入りますが不具合が修正されるまでは上記の回避策にてご対応いただけますようお願いいたします。

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


SMBv1 を無効化する方法として、サーバー マネージャーやコントロール パネル上から SMBv1 の機能を削除すると、その影響でソース srv のイベントの一部が記録されない動作となります。
本 blog にて、この動作について補足します。


[動作の説明]
サーバー マネージャーおよびコントロール パネルから SMBv1 (SMB1.0/CIFS ファイル共有のサポート) の機能を削除すると、SMBv1 の機能を提供するドライバー モジュール自体が削除されます。
ソース srv のイベントは、この SMBv1 の機能を提供するドライバーにて制御・記録されるため、モジュール自体が削除されることで、この処理が実行されず一部のイベントが記録されない動作となります。
サーバー マネージャーおよびコントロール パネルによる SMBv1 の機能削除は、Windows Server 2016、Windows Server 2012 R2、Windows 10、Windows 8.1 にてサポートされます。


この場合に記録されなくなるイベント ID は以下の通りです。

イベント ID: 2000 ～ 2027

[対処策]
次のレジストリを使用した無効化方法であれば、ドライバー モジュールは削除されません。
SMBv1 を無効化し、かつソース srv のイベントについても記録させる必要がある場合は、以下のレジストリによる無効化にて対応をお願いします。


- レジストリによる無効化手順
1. レジストリ エディターを開き、以下のサブキーに SMB1 をエントリとして作成し、値として 0 を設定します。

レジストリ サブキー: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
レジストリ エントリ: SMB1
REG_DWORD: 0 = 無効
既定値: 1 = 有効 (レジストリ キーは作成されません)

2. コンピューターを再起動します。

[参考情報]
- サーバー マネージャー / コントロール パネルからの無効化手順
クライアント オペレーティング システムの場合:
1. [コントロール パネル] を開き、[プログラム] をクリックし、次に [Windows の機能の有効化または無効化] をクリックします。
2. Windows の設定画面で [SMB1.0/CIFS ファイル共有のサポート] のチェックボックスをオフにし、[OK] をクリックしてウィンドウを閉じます。
3. コンピューターを再起動します。

サーバー オペレーティング システムの場合:
1. [サーバーマネージャー] を開き、[管理] メニューをクリックし、[役割と機能の削除] を選択します。
2. 設定画面で [SMB1.0/CIFS ファイル共有のサポート] のチェックボックスをオフにし、[OK] をクリックしてウィンドウを閉じます。
3. コンピューターを再起動します。


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

こんにちは。Windows サポート チームの矢澤です。
Windows 10 RS4 (1803) における移動ユーザー プロファイルとフォルダー リダイレクトの問題が報告されておりますので、本 blog にてご案内いたします。

1. 移動ユーザー プロファイルにてログオン・ログオフ遅延が発生する
1-1. 事象
RS4 の端末において、移動ユーザー プロファイルを構成するとログオン・ログオフが遅延します。
ログオフ時の画面に「移動ユーザー プロファイルが完全に同期されていません。イベント ログで詳細を確認するか、管理者に問い合わせてください。」が出力されます。
また、Application イベントログにイベント ID:1504 および 1509 が記録され、移動ユーザー プロファイルが同期できないエラー、警告が出力されます。

1-2. 原因
移動ユーザー プロファイルに含めないフォルダーを指定する以下のレジストリが RS4 では既定の状態で存在しません。

     HKCU\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\ExcludeProfileDirs

RS3 (1709) までは本レジストリに既定で以下の値が設定されており、移動ユーザー プロファイルの対象から除外されるフォルダーを既定で指定されておりましたが、RS4 では本レジストリが存在しないことで、AppData\Local などファイルサイズが大きいフォルダーも移動ユーザー プロファイルの対象としてログオフ時にファイルサーバーにアップロードされ、ログオン時にファイルサーバーからダウンロードされるため、ログオン・ログオフ遅延が発生します。

     AppData\Local;AppData\LocalLow;$Recycle.Bin;OneDrive;Work Folders

1-3. 回避策
既にファイルサーバーのプロファイル フォルダー配下に、AppData\Local や AppData\LocalLow フォルダーが存在している場合には事前に削除し、以下の手順にて ExcludeProfileDirs キーをグループ ポリシーにて配布します。

1. ドメイン コントローラーに管理者としてログオンします。

2. [グループ ポリシーの管理] を開き、RS4 の移動プロファイル対象ユーザーに適用される GPO を [編集] します。

3. 以下のパスに移動します。

     [ユーザーの構成] - [基本設定] - [Windows の設定] - [レジストリ]

4. [新規作成] - [レジストリ項目] を選択し以下の設定をします。
※[キーのパス] の [...] をクリックし以下のパスをクリックしても設定が可能です。

     アクション: 更新
     ハイブ: HKEY_CURRENT_USER
     キーのパス: SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
     値の名前: ExcludeProfileDirs
     値の種類: REG_SZ
     値のデータ: AppData\Local;AppData\LocalLow;$Recycle.Bin;OneDrive;Work Folders
          ※値のデータはお客様の指定があれば追加ください

5. [OK] をクリックし、エディターを閉じます。

6. 対象ユーザーにてログオン・ログオフし、事象が改善されるかをご確認ください。

1-4. 対処策
2018 年 7 月 25 日にリリースされる累積更新プログラムに本問題の対策が含まれる予定です。

2. フォルダー リダイレクトにて AppData\Roaming がリダイレクトされない
2-1. 事象
RS4 の端末において、フォルダー リダイレクトが有効なユーザーがログオンすると AppData\Roaming フォルダーのリダイレクトに失敗します。

2-2. 原因
AppData\Roaming がリダイレクト可能なフォルダーとして認識されない不具合が内在しています。

2-3. 回避策
回避策はありません。

2-4. 対処策
2018 年 6 月 27 日にリリースされた累積更新プログラム KB4284848 を適用ください。
適用後に再起動し、ログオンすることで AppData\Roaming がリダイレクトされます。

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

Windows 10 Version 1709 以降における以下の事象についてご案内します。

[ 問題の概要 ]

Windows 10 Version 1709 以降で、有線 LAN (イーサネット) に接続すると、モバイル ブロードバンドからインターネット接続ができなくなります。

[ 対応策 ] - Windows 10 Version 1709 の場合

Windows 10 Version 1709 では、KB4284822 の更新プログラムで本問題の修正を行いました。

この修正を有効にするためには、KB4284822 以降の更新プログラムを適用し、以下 2 つのレジストリを追加します。

キー : HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\WcmSvc\Local

名前 : fMinimizeConnections

種類 : DWORD

設定値 : 0

キー : HKEY_LOCAL_MACHINE\Software\Microsoft\Wcmsvc

名前 : IgnoreNonRoutableEthernet

種類 : DWORD

設定値 : 1

- Windows 10 Version 1803 の場合

Windows 10 Version 1803 では、以下のレジストリを追加します。

キー : HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\WcmSvc\Local

名前 : fMinimizeConnections

種類 : DWORD

設定値 : 0

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

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

Windows Server 2016 にてドメイン コントローラーを構築した際に、大文字と小文字の SRV レコードが登録する事象についてご案内いたします。

1. 事象
Windows Server 2012 R2 以前のドメイン環境に大文字が一文字でも含まれるホスト名の Windows Server 2016 のドメイン コントローラーを追加すると、大文字と小文字の SRV レコードが登録されます。また、大文字が含まれる SRV レコードを [DNS の管理] コンソールから削除しても再度同じレコード追加されて削除ができません。

2. 原因
Windows Server 2016 がドメイン コントローラーに昇格する時に Windows Server 2012 R2 以前のドメイン コントローラーに自身の SRV レコードが全て小文字として追加されます。同様に Windows Server 2016 自身へ自身の SRV レコードを追加する際には、大文字と小文字を区別したホスト名がそのまま登録されるため、大文字が含まれる SRV レコードが作成されます。それぞれのドメイン コントローラーに登録された SRV レコードの情報が複製されることで SRV レコードが重複して登録されることになります。また、[DNS の管理] コンソールから大文字を含む SRV レコードを削除してもActive Directory のデータベースからは削除されないため残存し続けます。

3. 影響
Windows では大文字と小文字を別の文字として扱うことは基本的にはございませんので大文字と小文字の SRV レコードが存在することの影響はありません。そのため、本事象を無視してご利用いただくことの問題はございませんが、以下の点については多少影響がございますので、回避策を実施するかどうかの検討をお願いします。

・Windows Server 2012 R2 以前の OS と混在している環境においては Windows Server 2016 のドメイン コントローラーに認証が偏ることがあります。
例えば、Windows Server 2012 R2 が 1 台、Windows Server 2016 が 1 台の環境では 1:1 で認証が分散されますが、Windows Server 2016 の SRV レコードが 1 つ増えますので論理的には 1:2 で Windows Server 2016 のドメイン コントローラーに認証が偏ることが考えられます。

・Windows Server 2016 のドメイン コントローラーを降格した場合には、大文字を含む SRV レコードが残存し続けます。
例えば、降格したサーバーがメンバーサーバーとして存在している場合には、SRV レコードが残存していることにより降格したサーバーに認証要求が発生し、次のドメイン コントローラーを探索するまでに 0.4 秒の遅延が発生します。

4. 回避策
予め Windows Server 2016 のホスト名を全て小文字とした状態でドメイン コントローラーに昇格することで本事象は発生しませんが、既に本事象が発生している環境においては以下の手順でホスト名を小文字に変更して再昇格を実施ください。既に Windows Server 2016 を降格して再昇格の予定がない場合には 4-2 のみ実施ください。

4-1. Windows Server 2016 のドメイン コントローラーを通常降格する
ドメイン コントローラー降格手順 (Windows Server 2012) を参照いただき、Windows Server 2016 の通常降格を実施します。Windows Server 2016 でも手順は変わりありません。

4-2. ADSI エディターから SRV レコードを削除して再登録する
降格した Windows Server 2016 のドメイン コントローラーのレコードを削除する場合には、[DNS の管理] コンソールからではなく、直接 Active Directory のデータベースから削除します。SRV レコードの再登録が全て完了するまではドメイン内のクライアントがドメイン コントローラーを探索することができなくなりますので、メンテナンス時間を設けて作業を実施ください。

1. レコードが登録されているゾーンの記憶域のタイプをコマンド プロンプトの dnscmd /enumzonesコマンドにて確認します。

※記憶域のタイプによって、AD 上の以下のデータベースに DNS の情報が保存されますので、ADSI エディターにて記憶域に接続します。

2. ADSI エディターを開き、SRV レコード が格納されている記憶域に接続し、[CN=MicrosoftDNS] – [<ゾーン名>] を開きます。

3. SRV レコードである [_gc._tcp] から [_ldap._tcp.ForestDnsZones] まで選択し (サイト名の先頭に F 以降が含まれる場合にはそこまで選択し) 削除します。

4. 稼働しているドメイン コントローラーにてコマンド プロンプトを開き、 dnscmd /zonereload <ゾーン名> && net stop netlogon && net start netlogon コマンドを実行して、稼働しているドメイン コントローラーの SRV レコードを再登録します。同様に稼働しているドメイン コントローラー全てでコマンドを実行します。

5. [DNS の管理] コンソールから降格した Windows Server 2016 の SRV レコードが削除されていることを確認します。

4-3. Windows Server 2016 のホスト名を全て小文字に変更する
大文字が含まれるホスト名を全て小文字に変更するだけでは [OK] ボタンが活性化しませんので、FQDN のドメイン名を NetBIOS ドメイン名に変更することで [OK] ボタンを活性化させます。

左図：変更前                                                                                右図：変更後

4-4. Windows Server 2016 をドメイン コントローラーとして再昇格する
ドメイン コントローラー降格手順 (Windows Server 2012) の 「C. ドメイン コントローラーの再昇格」を参照いただき、Windows Server 2016 の再昇格を実施します。Windows Server 2016 でも手順は変わりありません。

5. 対処策
本事象の修正プログラムのリリースは 2018 年 7 月現在では未定となります。
最新情報が入手でき次第本 blog をアップデートいたします。

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

現在サポートしているすべての OS バージョンで 2018 年 7 月公開の更新プログラムを適用すると、後述の問題が発生することが判明しましたので、本 Blog で現象の概要と対策をご案内します。

[ 問題の概要 ]

2018 年 7 月公開の更新プログラムを適用後、以下のような問題が発生することがあります。

• STOP エラー 0xD1 (ブルースクリーン) が発生する。
• SQL Server サービスの再起動が「TCP ポートがすでに使用されています。」というエラーにより失敗する。
• World Wide Web Publishing サービス (W3SVC) を停止しようとすると「停止中」の状態のままになり、W3SVC の停止や再起動ができなくなる。

[ 対象 OS ]

この現象は、現在サポートしているすべての OS バージョンで発生します。

[ 原因 ]

OS の tcpip.sys ドライバーの問題により、NSI (Network Store Interface) サービスに対して TCP コネクションテーブル等のネットワークに関する情報の要求があった場合に、タイミングによって問題が発生する可能性があります。

このような NSI に対する要求は OS の通常動作時にも発生し得ます。

また、Microsoft Network Monitor や Wireshark などの Network Monitoring ソフトが動作している環境では、特に頻繁に発生するため、問題の発生確率が上がります。

[ 対応策 ]

下記の一覧をもとに、問題が修正された更新プログラムを適用ください。

※ 問題の発生する更新プログラムを適用前の場合、問題が修正された更新プログラムを適用ください (問題の発生する更新プログラムを同時に適用しても問題ありません)。

※ 問題の発生する更新プログラムを適用済みの場合、問題が修正された更新プログラムを追加で適用ください。

※ 適用後は OS 再起動が必要です。 

※ 補足事項

- Windows 8.1 / Windows Server 2012 R2 の場合

セキュリティのみの更新プログラム (Security-only update) を適用する場合は、「KB4345424」を適用ください。KB4345424 は KB4338824 (Security-only update) の内容に、本問題の修正を追加しています。

マンスリー ロールアップ (Monthly Rollup) を適用する場合は、「KB4338815 (Monthly Rollup) + KB4345424」または「KB4338831 (Preview of Monthly Rollup)」を適用ください。

- Windows Server 2012 の場合

セキュリティのみの更新プログラム (Security-only update) を適用する場合は、「KB4345425」を適用ください。KB4345425 は KB4338820 (Security-only update) の内容に、本問題の修正を追加しています。

マンスリー ロールアップ (Monthly Rollup) を適用する場合は、「KB4338830 (Monthly Rollup) + KB4345425」または「KB4338816 (Preview of Monthly Rollup)」を適用ください。

- Windows 7 SP1 /Windows Server 2008 R2 SP1 の場合

セキュリティのみの更新プログラム (Security-only update) を適用する場合は、「KB4345459」を適用ください。KB4345459 は KB4338823 (Security-only update) の内容に、本問題の修正を追加しています。

マンスリー ロールアップ (Monthly Rollup) を適用する場合は、「KB4338818 (Monthly Rollup) + KB4345459」または「KB4338821 (Preview of Monthly Rollup)」を適用ください。

[ 更新履歴 ]

2018/07/19 : 本 Blog の公開

[ 補足 ]

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

こんにちは。Windows Platform サポート チームの加山です。
ドメイン コントローラーをベアメタル回復からリストアする際に、ドメイン コントローラー特有の注意点がございますので、ベアメタル回復からリストアする際の注意点および具体的な手順の一例についてご案内いたします。

[1] ドメイン コントローラーをベアメタル回復からリストアする際の注意点

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

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

[2] ドメイン コントローラーをベアメタル回復でバックアップ/リストアする手順

以下では、Windows Server 2012 R2 のメイン コントローラーをベアメタル回復でバックアップ/リストアする具体的な手順についてご案内いたします。
後述の手順は一例となりますので、オプションの選択方法などは適宜環境に合わせて変更してください。
なお、Windows Server 2012 R2 以外の OS でもリストア時の注意点は同様になりますので、参考にしていただけますと幸いです。

[2-1] ドメイン コントローラーをベアメタル回復でバックアップする手順

(1) Windows Server バックアップ機能のインストール

Windows Server バックアップ機能をインストールしていない場合には、まず Windows Server バックアップ機能をインストールします。

1. 対象の端末に、端末の管理者権限を持つユーザーでログオンします。
2. [サーバー マネージャー] を開き、[管理] - [役割と機能の追加] の順にクリックします。

3. [役割と機能の追加ウィザード] が起動しましたら、[開始する前に] で [次へ] をクリックします。


4. [インストールの種類の選択] で [役割ベースまたは機能ベースのインストール] がチェックされた状態で [次へ] をクリックします。


5. [対象サーバーの選択] で [サーバー プールからサーバーを選択] をチェックし、[サーバー プール] から対象のサーバーを選択して [次へ] をクリックします。


6. [サーバーの役割の選択] で既定の状態で [次へ] をクリックします。


7. [機能の選択] で [Windows Server バックアップ] をチェックし、 [次へ] をクリックします。


8. [インストール オプションの確認] で [インストール] をクリックします。


9. [インストールの進行状況] で [インストールが正常に完了しました。] と表示されましたら [閉じる] をクリックします。

(2) Windows Server バックアップ (ベアメタル回復) の実行

Windows Server バックアップ ツールを利用し、ベアメタル回復のバックアップを取得します。

1. 対象の端末に、端末の管理者権限を持つユーザーでログオンします。
2. [サーバー マネージャー] を開き、[ツール] - [Windows Server バックアップ] の順にクリックします。


3. [Windows Server バックアップ] が起動しましたら、左ペインで [ローカル バックアップ] をクリックします。


4. 右側の [操作] ペインで [単発バックアップ] をクリックします。


5. [単発バックアップ ウィザード] が起動しましたら、[バックアップ オプション] で [別のオプション] をチェックして [次へ] をクリックします。


6. [バックアップの構成の選択] で [カスタム] をチェックして [次へ] をクリックします。


7. [バックアップする項目を選択] で [項目の追加] をクリックします。


8. [項目の選択] で [ベア メタル回復] をチェックし、[OK] をクリックします。
※ [ベア メタル回復] をチェックすると、すべての項目がチェックされます。


9. [バックアップする項目を選択] で [ベア メタル回復] が含まれていることを確認し、[次へ] をクリックします。


10. [作成先の種類の指定] で [リモート共有フォルダー] をチェックし、[次へ] をクリックします。


11. [リモート フォルダーの指定] で [場所] にバックアップの保存先共有フォルダーの UNC パスを入力し、その他のオプションは変更せずに [次へ] をクリックします。
場所の例: ホスト名が MyFileServer のサーバーの SharedFolderName という名前の共有フォルダーにバックアップを保存する場合

\\MyFileServer\SharedFolderName

12. [確認] で [バックアップ] をクリックします。


13. [バックアップの進行状況] で [状態] が [完了しました] に変わりましたら、[閉じる] をクリックします。

[2-2] ドメイン コントローラーをベアメタル回復でリストアする手順

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

1. 対象の端末に Windows Server 2012 R2 のインストール メディアを挿入します。
2. 対象の端末の電源をオンにします。
3. もし "Press any key to boot from CD or DVD.." と表示されたら、任意のキーを押します。
4. 言語などの選択画面が表示されたら、[次へ] をクリックします。


5. [コンピューターを修復する] をクリックします。


6. [オプションの選択] 画面が表示されたら、[トラブルシューティング] をクリックします。


7. [詳細オプション] で [コマンド プロンプト] をクリックします。


8. 下記のコマンドを実行し、ネットワークを初期化します。
wpeutil InitializeNetwork


9. 下記のコマンドを実行し、NIC に対応付いている Idx を確認します。
netsh interface ipv4 show interfaces


10. 下記のコマンドを実行し、IP アドレスとサブネット マスク、デフォルト ゲートウェイを設定します。
netsh interface ipv4 set address <手順 9 で確認した Idx の値> static <IP アドレス> <サブネット マスク> <デフォルト ゲートウェイ>


11. 下記のコマンドを実行し、コマンド プロンプトを終了します。
exit

12. [オプションの選択] で [トラブルシューティング] をクリックします。


13. [詳細オプション] で [イメージでシステムを回復] をクリックします。


14. [イメージでシステムを回復] で [Windows Server 2012 R2] をクリックします。


15. "このコンピューター上にシステム イメージが見つかりません" というメッセージが表示された場合は、[キャンセル] をクリックします。


16. [システム イメージ バックアップの選択] で [システム イメージを選択する] を選択し、[次へ] をクリックします。


17. [復元するコンピューターのバックアップの場所を選択してください] で [詳細設定] をクリックします。


18. [ネットワーク上のシステム イメージを検索する] をクリックします。


19. [ネットワーク フォルダー] にバックアップ イメージが格納されている UNC パスを入力し、[OK] をクリックします。(前述の手順で 参照先 DNS サーバーについては設定していないため、UNC パスは IP アドレスで指定してください。)

20. 認証ポップアップにバックアップ イメージの保存先にアクセスするための資格情報を入力し、[OK] をクリックします。


21. 復元するコンピューターのバックアップの場所を選択し、[次へ] をクリックします。


22. [復元するシステム イメージの日時を選択してください] で復元するシステム イメージの日時を選択し、[次へ] をクリックします。


23. [他の復元方法を選択してください] で既定の状態で [次へ] をクリックします。


24. [完了] をクリックします。


25. 警告メッセージが表示されたら、[はい] をクリックします。


26. 復元処理が完了したら "今すぐ再起動しますか?" と表示されますので、[今すぐ再起動] をクリックします。

(2) 1 台目のドメイン コントローラーをシステム状態から authsysvol としてリストア

1. 1 台目にベアメタル回復からリストアしたドメイン コントローラーに管理者としてログオンします。
2. [スタート] - [ファイル名を指定して実行] をクリックします。
3. "msconfig" と入力して [OK] をクリックします。


4. [ブート] タブを開き、[セーフ ブート] をチェックし、[Active Directory 修復] をチェックし、[OK] をクリックします。


5. [システム構成] で [再起動] をクリックし、再起動します。


6. OS 起動後、管理者としてログオンし、コマンド プロンプトを起動します。
7. 次のコマンドを実行し、システム状態データの "バージョン識別子" を確認します。
wbadmin get versions -backupTarget: -machine:

8. 資格情報を求められる場合は、ファイル サーバーのローカル Administrator の資格情報を指定します。
9. 更に次のコマンドを実行し、システム状態データのリストアを行います。
wbadmin start systemstaterecovery -version: -backupTarget: -machine: -authsysvol -quiet

10. 資格情報を求められる場合は、ファイル サーバーのローカル Administrator の資格情報を指定します。
11. 復元完了後にシステムを再起動し、管理者としてログオンします。
12. [スタート] - [ファイル名を指定して実行] をクリックします。
13. "msconfig" と入力して [OK] をクリックします。
14. [ブート] タブを開き、[セーフ ブート] のチェックを外し、[OK] をクリックします。

(3) 2 台目のドメイン コントローラーをベアメタル回復からリストア

[2-2] - (1) と同様の手順で 2 台目のドメイン コントローラーをベアメタル回復からリストアします。

ドメイン コントローラーをベアメタル回復でバックアップ/リストアする手順は以上となります。

こんにちは。Windows サポート チームの矢澤です。
Windows 10 RS4 (1803) におけるコンピューター証明書の発行における問題が報告されておりますので、本 blog にてご案内いたします。

1. 事象
RS4 の端末において、MMC スナップインからコンピューターの証明書の発行要求を行うと「利用できない種類の証明書です」というエラーが表示され、テンプレートの一覧が表示されず、コンピューター証明書の取得ができない事象が発生します。

2. 原因　
RS4 においてコンピューター証明書のテンプレートを取得するための処理の過程で、システムの SID をアクセス トークンに含めない状態となるためです。

3. 対処策
2018 年 8 月 22 日にリリースされる予定の累積更新プログラムに本事象の修正が含まれる予定です。
対策バージョンがリリースされましたら改めて情報をアップデートします。

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

ドメイン コントローラー間でのレプリケーションが行われなくなる原因の 1 つに USN ロールバックと呼ばれる事象があります。
この USN ロールバックは、イメージからのリストアなどのサポートされない方法で復元してしまった場合に発生します。
USN ロールバックが起きると、ドメイン コントローラー間での USN (更新シーケンス番号) の不整合が発生してしまうため、レプリケーションが停止されます。

同様の問題を扱った弊社の公開情報は既に存在しますが、一部分かりづらい箇所もあるため、改めてこの問題について執筆します。
この記事では、USN ロールバックが発生しているかどうかを確認するための方法と、回復の手順をまとめました。

==================================================
** USN ロールバック発生時の特徴 **
==================================================
レプリケーションが停止した場合、下記のような特徴が見られるかどうかで、USN ロールバックによるものかどうかを判断することができます。

< 特徴 1 >
"repadmin /showrepl" コマンドを実行し、DSA オプションの欄を確認します。
現象が発生しているドメイン コントローラーでは、[DISABLE_INBOUND_REPL] および [DISABLE_OUTBOUND_REPL] というオプションが追加されています。
これにより、入出力方向のレプリケーションが停止されていることが分かります。

// 正常なドメイン コントローラー
******************************
DSA オプション: IS_GC
******************************

// 現象が発生しているドメイン コントローラー
******************************
DSA オプション: IS_GC DISABLE_INBOUND_REPL DISABLE_OUTBOUND_REPL
******************************

< 特徴 2 >
Netlogon サービスの [状態] が [一時停止] となる。

< 特徴 3 >
レジストリ値 Dsa Not Writable のデータが 4 となっている。

- 当該レジストリ値
キー: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
値の名前: Dsa Not Writable
値の種類: REG_DWORD
値のデータ: 4

< 特徴 4 >
Directory Service のイベント ログに ID: 2095 が記録されている。

==================================================
** USN ロールバックからの回復手順 **
==================================================

概要
-----------------
USN ロールバックが発生すると、不具合が発生しているドメイン コントローラーが保持している AD データベースを破棄し、再構成するために、対象のドメイン コントローラーの強制降格、再昇格を実施する必要があります。
また、対象のドメイン コントローラーが FSMO の役割を保持している場合には、事前に正常なドメイン コントローラーに強制転送しておく必要があります。

なお、本手順は Windows Server 2016 を前提とした表記となっております。

作業手順
-----------------
A. FSMO 役割の確認と転送手順
A-1. FSMO の役割確認
A-2. FSMO の役割転送 (A-1 で降格対象のドメイン コントローラーが FSMO 役割を保持していた場合にのみ実施)

B. ドメイン コントローラーの降格手順
B-1. ドメイン コントローラーの強制降格手順
B-2. Metadata Cleanup 手順

C. 再昇格手順

作業手順詳細
-----------------
A-1. FSMO の役割の確認
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
USN ロールバックが発生しているドメイン コントローラーが、FSMO の機能を持っていないかを確認します。
確認の結果、FSMO の機能を持っていない場合、A-2 の作業は不要です。

作業対象:
USN ロールバックが発生しているドメイン コントローラー

作業手順:
1. 以下のコマンドを実行し、 FSMO の役割をどのサーバーが担っているか確認します。

netdom query fsmo

(出力例)--------------------------------------
スキーマ マスター DC01.test.local
ドメイン名前付けマスター DC01.test.local
PDC DC01.test.local
RID プール マネージャー DC01.test.local
インフラストラクチャ マスター DC01.test.local
コマンドは正しく完了しました。
----------------------------------------------

A-2. FSMO の役割の転送
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
本手順では強制的に正常なドメイン コントローラーに FSMO の役割を転送します。
A-1 で USN ロールバックが発生したドメイン コントローラーが FSMO の役割を保持していた場合にのみ実施します。

作業対象:
FSMO の役割の転送先となる正常なドメイン コントローラー

作業手順:
1. FSMO 転送先ドメイン コントローラーにログオンします。
2. コマンド プロンプトを管理者権限で開きます。
3. ntdsutil と入力します。
4. roles と入力し、Enter キーを押します。
5. connections と入力し、Enter キーを押します。
6. connect to server localhost と入力し、Enter キーを押します。
7. server connections: プロンプトで q と入力し、もう一度 Enter キーを押します。

--- USN ロールバックが発生しているドメイン コントローラーが保持している FSMO の役割に対してのみ実施します ---

8. RID プール マネージャーを転送する場合には、Seize RID master と入力し、実行します。
9. インフラストラクチャ マスターを転送する場合には、Seize infrastructure master と入力し、実行します。
10. PDC エミュレーターを転送する場合は、Seize PDC と入力し、実行します。
11. ドメイン名前付けマスターを転送する場合は、Seize naming master と入力し、実行します。
12. スキーマ マスターを転送する場合には、Seize schema master と入力し、実行します。
13. q を 2 回実行し、コマンド プロンプトを閉じます。
14. 転送が正常に行われた確認する場合には、A-1 の手順を実施します。

B-1. ドメイン コントローラーの強制降格手順
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
本手順では USN ロールバックが発生したドメイン コントローラーを強制的に降格します。

作業対象:
USN ロールバックが発生しているドメイン コントローラー

作業手順:
1. 降格対象のドメイン コントローラーに管理者権限のユーザーでログオンします。
2. [サーバー マネージャー] を起動します。
3. ウィンドウ上部のツールバーより [管理] - [役割と機能の削除] をクリックし "役割と機能の追加ウィザード" を開きます。
4. "役割と機能の削除ウィザード (対象サーバーの選択)" 画面にて、[サーバー プールからサーバーを選択] を選択した上で [サーバー プール] 内の自ホストを選択し、[次へ] をクリックします。
5. "役割と機能の削除ウィザード (サーバーの役割の選択)" 画面にて、役割項目内から下記のチェックを外し、[次へ] をクリックします。

- Active Directory ドメイン サービス
# 各役割のチェックを外すと "{サービス名} を必要とする機能を削除しますか?" と表示されます。
既定の状態で [機能の削除] をクリックします。

6. "検証結果" のダイアログが表示されたら、[このドメイン コントローラーを降格する] をクリックします。
7. "資格情報" 画面にて、以下を指定し、[次へ] をクリックします。

[この操作を実行するには資格情報を指定してください] : 管理者権限を持つユーザーの資格情報を指定します。
[このドメイン コントローラーの削除を強制] : チェック ボックスを "オン" にします。
[ドメイン内の最後のドメイン コントローラー] : チェック ボックスを "オフ" にします。

8. "警告" 画面にて、対象のドメイン コントローラーの役割の確認が表示されます。内容を確認した上で [削除の続行] のチェック ボックスをオンにし、[次へ] をクリックします。
9. "新しい Administrator パスワード" 画面にて、降格後の作業対象のサーバーの Administrator パスワードを入力し、[次へ] をクリックします。
10. "オプションの確認" 画面にて、内容を確認し、[降格] をクリックします。
11. 降格処理が完了したら "サインオフしようとしています" というメッセージが表示され、自動で再起動が行われます。

B-2. Metadata Cleanup 手順
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
B-1 の手順で強制降格した場合には、以下の手順で降格したドメイン コントローラーの情報を手動で削除する必要があります。

作業対象:
正常に稼働しているドメイン コントローラーのうち、任意の 1 台

作業手順:
1. 管理者権限を持つユーザーで正常なドメイン コントローラーにログオンします。
2. [サーバーマネージャー] を起動します。
3. ウィンドウ上部のツールバーより [ツール] - [Active Directory ユーザーとコンピューター] をクリックします。
4. [Active Directory ユーザーとコンピューター] 画面左ペインにて以下まで展開します。

Active Directory ユーザーとコンピューター
- <ドメイン名>
- Domain Controllers

5. 右ペインにて <削除対象のドメイン コントローラー> を右クリックし、[削除] をクリックします。
6. "'<削除対象のドメイン コントローラー>' という名前の コンピューター を削除しますか?" と表示されたら、[はい] をクリックします。
7. 警告メッセージが表示されるので、下記チェック ボックスをオンにし、[削除] をクリックします。

[完全オフラインで、削除ウィザードを使用して削除できないこのドメイン コントローラーを削除する]

# ドメイン コントローラーがグローバル カタログである場合、"この Active Directory ドメイン コントローラーはグローバル カタログです。削除を実行しますか?"と表示されます。
# FSMO の機能を保持している場合には、警告のダイアログが表示されます。
正しく動作しているドメイン コントローラーに FSMO の役割が転送されます。
内容を確認し、[OK] をクリックします。"

8. [サーバー マネージャー] の画面に戻り、[ツール] - [Active Directory サイトとサービス] をクリックします。
9. 左ペインの [Sites] - [<サイト名>] - [Servers] - [<ドメイン コントローラー名>] - [NTDS Settings] を選択します。
10. 右ペインに [レプリケート元サーバー] が削除対象のドメイン コントローラーとなっているオブジェクトが存在していれば、左ペインの [NTDS Settings] を右クリックし、[すべてのタスク] - [レプリケーション トポロジの確認] をクリックします。
11. 右ペインにて [最新の情報に更新] し、削除対象のドメイン コントローラーとのオブジェクトが削除されることを確認します。
12. 9 から 11 までの手順を [Sites] - [<サイト名>] - [Servers] の削除対象のドメイン コントローラーを除く、すべてのドメイン コントローラーについて実行します。
13. 左ペインにて [Sites] - [<削除対象のドメイン コントローラーのサイト名>] - [Servers] - [<削除対象のドメイン コントローラー名>] を選択した状態で右クリックし、表示されるメニューで [削除] をクリックします。

C. 再昇格手順
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
降格作業を実施後に再度昇格を行う手順です。

作業対象:
降格を実施し、再昇格を行うドメイン コントローラー

作業手順:
1. 降格対象のドメイン コントローラーに管理者権限のユーザーでログオンします。
2. [サーバー マネージャー] を起動します。
3. ウィンドウ上部のツールバーより [通知] をクリックし、[このサーバーをドメイン コントローラーに昇格する] をクリックします。
4. "配置構成" 画面にて、以下を選択、入力し、[次へ] をクリックします。

配置操作を選択してください : 既存のドメインにドメイン コントローラーを追加する
この操作のドメイン情報を指定してください : <既存ドメイン名>
この操作を実行するには資格情報を指定してください : <ドメイン管理者ユーザー アカウント / パスワード>

5. "ドメイン コントローラー オプション" 画面にて、要件に合わせてドメイン コントローラー オプションや DSRM のパスワードを選択、入力し、[次へ] をクリックします。
6. "DNS オプション" 画面にて、[次へ] をクリックします。

# 権限のある親ゾーンが見つからないことを示すダイアログが表示された場合は、そのまま次に進みます。

7. "追加オプション" 画面にて、以下を選択し、[次へ] をクリックします。

レプリケート元 : [任意のドメイン コントローラー]

8. "パス" 画面にて、以下を確認し、[次へ] をクリックします。

データベースのフォルダー : C:\Windows\NTDS
ログ ファイルのフォルダー : C:\Windows\NTDS
SYSVOL フォルダー : C:\Windows\SYSVOL

9. "オプションの確認" 画面にて、[次へ] をクリックします。
10. "前提条件のチェック" 画面にて、内容を確認し、[インストール] をクリックします。
11. インストールが完了すると自動的に OS が再起動されます。

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

今回は、Windows 10 にて、スマート カード PIN ロック時の統合ブロック解除画面が表示されない事象について案内します。

問題となる事象
Windows 10 (すべてのバージョン) にてグループ ポリシーにて "ログオン時に統合ブロック解除画面を表示する" の設定を有効にしている環境にて、
以下の手順を行った場合に、統合ブロック解除画面が表示されない事象を確認しております。
本事象については、弊社にて調査中でございます。

事象の発生する具体的な手順は以下となります。

<前提条件>
以下のポリシーが "有効" 設定されている環境にて、スマート カードを使用したログオンを行う環境における事象です。

[コンピューターの構成] - [管理用テンプレート] - [Windows コンポーネント] - [スマート カード]
"ログオン時に統合ブロック解除画面を表示する"

<事象発生手順>
1) Windows 10 クライアントから、スマート カードを使用したログオンを実行し、誤った PIN を入力してログオンに失敗します。

2) 上記 1) の手順を繰り返し、スマート カードの PIN がロックされる状態まで連続して失敗させます。（※ロックされる回数として設定されている回数以上繰り返します）
※ロックされるまでの試行回数が 5 回未満の環境では、本事象は発生いたしません。

3) 上記 2) にて PIN がロックされると以下の画面が表示されますので [OK] をクリックします。

"スマート カードがブロックされています。スマート カードのブロックを解除する方法について
は、管理者に問い合わせてください。"

4) 上記 3) の後、本来表示されるべき "統合ブロック解除画面" が表示されません。

回避策

以下のいずれかを実行後、再度、ロックしたスマート カードを使用してログオンを試行すると、正常に "統合ブロック解除画面" が表示されます。

a) 該当のクライアント端末を再起動後、ロックしたスマート カードでログオンを試行する。

b) 該当のクライアント端末に、一旦、スマート カードを使用せずに（ユーザー名とパスワード等で）正常にログオン後、再度、ロックしたスマート カードでログオンを試行する。

c) スマート カードを使用したログオンのみしか許容していない環境等で b) の回避策が取れない場合には、一旦別のアカウントで正常にログオン後、再度、ロックしたスマート カードでログオンを試行する。

d) ロックしたスマート カードを使用して、別の端末にてログオンを試行する。

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

今回は、「ドメインコントローラ（以下DC）の正常性の確認について」をご紹介していきたいと思います。DCを降格させたり、DCに昇格させたりと動作をさせていく上で、実際にDCが正常に降格されているのか、またはDCへ正常に昇格されているのか確認したいですよね。DC正常性の確認の手順を下記にお纏めいたしました。

==================================================

DCの正常性を確認する方法

==================================================

<作業の流れ>

(1) AD データベースの複製状況の確認

(2) SYSVOL、NETLOGON 共有の確認

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

(4) 各種イベント ログの確認

<詳細な手順>

----------------------------------------

(1) AD データベースの複製状況の確認

----------------------------------------

コマンド プロンプトにて repadmin /showrepl コマンドを実行し、Active Directory データベースの複製にエラーが無いことを確認します。

また、グローバル カタログ サーバーの場合は "DSA OPTIONS: IS_GC" という項目があることを確認します。

> repadmin /showrepl

出力結果例）

--------------

Repadmin: フル DC localhost に対してコマンド /showrepl を実行しています

Default-First-Site-Name\DC02

DSA オプション: IS_GC

<<<---- グローバル カタログ サーバーの場合は、IS_GC と表示されていることを確認します。

サイト オプション: (none)

DSA オブジェクト GUID: b3db08eb-75c6-411d-b56c-5a06d4365995

DSA 起動 ID: 19a5c6a9-96cc-4cce-bcc7-ed759412899f

====入力方向の近隣サーバー==================

DC=TEST,DC=LOCAL

Default-First-Site-Name\DC01 (RPC 経由)

DSA オブジェクト GUID: 326e1109-b33d-4026-aab7-8a5bc2cd960a YYYY-MM-DD HH:MM:SS の最後の試行は成功しました。

<<<---- 直近の日時で複製が成功していることを確認します。

----------------------------------------

(2) SYSVOL、NETLOGON 共有の確認

----------------------------------------

コマンド プロンプトにて net share コマンドを実行し、SYSVOL 及び NETLOGON が共有されているかを確認します。 共有名に NETLOGON 及び SYSVOL が表示されていることで正常に共有できていると判断できます。

> net share

出力結果例）

<<<---- NETLOGON が共有されていることを確認します。

<<<---- SYSVOL が共有されていることを確認します。 

---------------------------------------

(3) ドメイン コントローラー診断テストの確認

----------------------------------------

コマンド プロンプトにて dcdiag /v コマンドを実行し、各テストにエラーが無く、"合格しました" と表示されることを確認します。 Advertising に合格していることで、ドメイン コントローラー、及びグローバル カタログとして正常に機能していると判断できます。

> dcdiag /v

出力結果一部例）

--------------

テストを開始しています: Advertising

The DC DC02 is advertising itself as a DC and having a DS.

The DC DC02 is advertising as an LDAP server

The DC DC02 is advertising as having a writeable directory

The DC DC02 is advertising as a Key Distribution Center

The DC DC02 is advertising as a time server

The DS DC02 is advertising as a GC.

......................... DC02 はテスト Advertising に合格しました

----------------------------------------

(4) 各種イベント ログの確認

----------------------------------------

システム、ディレクトリ サービス、DNS サーバー、DFS Replication の各種イベント ログにおいて、異常を示唆するようなエラーや警告のイベントが記録されていないか確認します。

以上、DC の正常性の確認方法となります。

****************************************************************************************

上記は DC の正常性を確認するための一般的な方法となりますが、DC の降格を行った後に正常に降格ができたか、残存している情報がないかを確認したい場合には、上記の内容に加えまして以下の項目をご確認いただき、降格させた DC の情報が残存していないことをご確認下さい。

==================================================

降格させた DC の情報が存在しないことの確認手順

==================================================

<作業の流れ>

(1) 複製に使用する接続オブジェクトが削除されていることの確認

(2) DC のコンピュータ オブジェクトが削除されていることの確認

(3) FRS または DFSR のオブジェクトが削除されていることの確認

(4) DNS レコードが削除されていることの確認

<詳細な手順>

----------------------------------------

(1) 複製に使用する接続オブジェクト

----------------------------------------

1. [Active Directory サイトとサービス] スナップインを起動します。
2. [Sites] - [<サイト名>] - [Servers] - [DC 名] - [NTDS Settings] を選択します。
3. 右ペインに [レプリケート元サーバー] が降格させた DC となっているオブジェクトが存在していれば、左ペインの [NTDS Settings] を右クリックし、[すべてのタスク] - [レプリケーション トポロジの確認] をクリックします。
4.  右ペインにて [最新の情報に更新] し、降格させた DC とのオブジェクトが削除されていることを確認します。
5.  2. から 4. までの手順を [Sites] - [<サイト名>] - [Servers] のすべての DC について実行します。
6.  左ペインにて [Sites] - [<降格させた DC のサイト名>] - [Servers] - [<降格させた DC>] が存在しないことを確認します。

----------------------------------------

(2) DC のコンピュータ オブジェクト

----------------------------------------

[Active Directory ユーザーとコンピュータ] MMC スナップインを開き、 [Domain Controllers] 配下に降格させた DC が削除されているか確認します。

----------------------------------------

(3) FRS または DFSR のオブジェクト

----------------------------------------

1. [スタート] - [ファイル名を指定して実行] を選択し、adsiedit.msc と入力して [OK] をクリックします。
2. [ADSI エディタ] を右クリックして表示されるメニューから "接続" をクリックします。
3.  接続の設定画面で "名前" 欄に "Domain NC" と入力し、他は既定の状態で [OK] をクリックします。
4.  以下のオブジェクトを展開します (Windows Server 2008 ネイティブ以降の機能レベルで SYSVOL の複製に DFSR を使用している場合には 4. 5. を飛ばして 6. に進みます)。 [Domain NC [Domain Name]] - [DC=・・・(Domain Name)] - [CN=System] - [CN=File Replication Service] - [CN=Domain System Volume (SYSVOL share)]
5.  [CN=<降格させた DC>] が存在しないことを確認します。
6.  以下のオブジェクトを展開します。 [Domain NC [Domain Name]] - [DC=・・・(Domain Name)] - [CN=System] - [CN=DFSR-GlobalSettings] - [CN=Domain System Volume] - [CN=Topology]
7.  [CN=<降格させた DC>] が存在しないことを確認します。

----------------------------------------

(4) DNS レコード

----------------------------------------

1. [スタート] - [管理ツール] - [DNS] を起動します。
2.  [前方参照ゾーン] - [_msdcs.<フォレスト ルート ドメイン>] 配下に "データ" が降格させた DC となっている CNAME レコードが存在しないことを確認します。
3.  [前方参照ゾーン] - [<降格させた DC が所属するドメイン>] ゾーン配下の NS レコードのプロパティを開きます。
4.  [ネーム サーバー] タブで降格させた DC の FQDN が表示されていないことを確認します。
5.  [前方参照ゾーン] - [<降格させた DC が所属するドメイン>] ゾーン配下に "名前" が降格させた DC となっている A レコードが存在しないことを確認します。

こんにちは。Windows サポートチームの矢澤です。
今回は RS3 (1709) から新しく実装された Windows Hello の多要素認証についてご紹介します。
詳細は以下の公開情報に記載されておりますが、わかりにくい点もありますのでこちらの blog にて補足します。

Title: 多要素のロック解除
URL:https://docs.microsoft.com/ja-jp/windows/security/identity-protection/hello-for-business/feature-multifactor-unlock

◆動作◆
「最初のロック解除要素である資格情報プロバイダー」「2 番目のロック解除要素である資格情報プロバイダー」にて設定されたプロバイダー (PIN、顔、指紋、信頼された信号) から一つずつ要素を利用して、ログオンおよび画面ロックの解除において二要素認証を実現します。

◆設定方法◆
ローカル グループ ポリシーエディター (gpedit.msc) では以下のパスで指定します。

[コンピューターの構成] - [管理用テンプレート] - [Windows コンポーネント] - [Windows Hello for Business] - [デバイスのロック解除要素を構成する]

設定名は Windows Hello for Business ですが、通常の Windows Hello (WorkGroup, ドメイン環境) でも動作し、設定後は再起動などは不要で、[スタート] + L の画面ロックをすることですぐに設定した内容での動作を確認できます。また、少なくともどちらかの設定に PIN が含まれている必要があります。

◆GUID◆
既定では「最初のロック解除要素である資格情報プロバイダー」に [PIN/顔/指紋]  が登録され、「2 番目のロック解除要素である資格情報プロバイダー」に [PIN/信頼された信号] が登録されますので、追加、削除などしたい場合には以下の GUID を参照いただき、設定を変更ください。

PIN: {D6886603-9D2F-4EB2-B667-1971041FA96B}
顔：{8AF662BF-65A0-4D0A-A540-A338A999D36F}
指紋：{BEC09223-B018-416D-A0AC-523971B639F5}
信頼された信号：{27FBDB57-B613-4AF2-9D7E-4FA7A66C21AD}

◆適用順序◆
「最初のロック解除要素である資格情報プロバイダー」と「2 番目のロック解除要素である資格情報プロバイダー」という名称ですが、どちらのリストから開始されても問題ありません。

例えば、「PIN/顔」＋「PIN/指紋」と設定した場合には先に「2 番目のロック解除要素である資格情報プロバイダー」に設定されている指紋認証からでも認証を開始することができ、その後に顔認証でロックが解除される状態となります。なお、最初は必ず顔認証してから、次に指紋認証、などといった順序を厳密に定義することはできません。

◆両方のリストに含まれる要素◆
「最初のロック解除要素である資格情報プロバイダー」と「2 番目のロック解除要素である資格情報プロバイダー」の両方に含まれる要素があった場合、両方に含まれる要素を最初に利用した場合は、「最初のロック解除要素である資格情報プロバイダー」と「2 番目のロック解除要素である資格情報プロバイダー」に設定されている残りの要素を追加認証で利用することができます。

例えば、「PIN/顔」＋「PIN/指紋」と設定した際に、先に PIN にて認証をした場合は、追加の要素としては「顔」「指紋」の両方が利用可能です。なお、この設定では、以下のような形で認証が可能です。

・PIN + 顔
・PIN + 指紋
・顔 + PIN
・顔 ＋ 指紋
・指紋 ＋ PIN
・指紋 ＋ 顔

◆生体認証のロック◆
生体認証に 3 回失敗した場合には、使用した生体認証(顔認証 or 指紋認証) にロックがかかり PIN を入力しないと解除されません。多要素ロックの設定をしている場合には、追加要素の認証が成功してデスクトップ画面が表示されないと、生体認証が再度認識されません。

例えば、「PIN/顔」＋「PIN/指紋」と設定した際に、指紋認証に 3 回間違えてロックがかかり、PIN にて解除した場合には、PIN にて認証したことになりますので、「顔」もしくは「指紋」にて追加の要素で認証する必要がありますが、「指紋」はロックがかかっているため、「顔」を使用して認証する必要があります。

◆パスワード◆
サインイン オプションとしてパスワードのアイコンは必ず表示されますので、多要素のロック解除の設定をした場合でもパスワードのアイコンをクリックし、パスワードを入力することで 1 要素のみでロックを解除することができます。

こんにちは。Windows サポートチームの矢澤です。
今回は Windows Server 2012 のサーバーに WSUS から KB2992611 が再配信されてしまう以下の公開情報に記載されいる以下の既知の問題 4 について本 blog にて補足します。

この更新プログラムを置き換える KB3042058 または別の更新プログラムをインストールして、置き換えられた更新プログラムが削除されると、KB2992611 が既にインストールされていても Windows Update から KB2992611 が提示されます。 この問題は、置き換えられた更新プログラムの削除処理で (KB2992611 と共にインストールされる) 更新プログラム KB3018238 が削除されたために発生します。

Title: [MS14-066]SChannel の脆弱性により、リモートでコードが実行される(2014 年 11 月 11 日)　
URL:https://support.microsoft.com/ja-jp/help/2992611/ms14-066-vulnerability-in-schannel-could-allow-remote-code-execution-n

[1] KB2992611 について
Windows Server 2008 R2 および Windows Server 2012 向けの KB2992611 は KB3018238 を含んだ形となっている特殊な更新プログラムです。

[2] KB3018238 について
既知の問題 2 に記載されている通り、KB3018238 は暗号スイートに関する更新プログラムとなり、Windows Server 2008 R2 および Windows Server 2012 向けとして KB2992611 に内包されてリリースされております。

2014 年 11 月 18 日に、Windows Server 2008 R2 および Windows Server 2012 用のリリースに新しい二次パッケージが追加されました。この新しいパッケージは更新プログラム 3018238 です。更新プログラム 3018238 は、セキュリティ更新プログラム 2992611 と共に自動的かつ透過的にインストールされます。

[3] StartComponentCleanup について
Windows 8 / Windows Server 2012 から StartupComponentCleanup という機能が実装されました。この機能は新しい更新プログラムによって置き換えできる更新プログラムがインストールされていることを検知した場合には、端末の容量削減のために古い更新プログラムを自動的に削除する機能となります。なお、削除された更新プログラムはインストール済の更新プログラムからも削除されます。

Title: StartComponentCleanup タスクによる、不要な更新プログラムの削除について
URL:https://blogs.technet.microsoft.com/askcorejp/2015/12/03/startcomponentcleanup/

[4] StartComponentCleanup が動作する仕組み
StartComponentCleanup タスクによって更新プログラムが削除される要件としては以下の 2 点となりますので、上書きするような更新プログラムをインストールしたからといって即座に置き換え対象の更新プログラムが削除されるわけではありません。

・更新プログラムの適用後 30 日以上であること
・30 日経過以後に、更新プログラムの適用や削除が実行されること

[5] 既知の問題 4 について
KB2992611 がインストールされている環境において、KB3018238 を置き換えるような更新プログラムがインストールされ、[4] の条件が満たされると、StartComponentCleanup が動作し KB3018238 を削除します。StartComponentCleanup によって KB3018238 が削除されると、この更新プログラムを内包している KB2992611 が完全にインストールされていないとみなされ、WSUS から KB2992611 が再配信されます。
これが既知の問題 4 に記載されている内容となり、StartComponentCleanup の機能を持つ Windows Server 2012 のみで事象が発生します。

[6] 対処策1：対象の更新プログラムを「拒否」にする
以下の手順により KB2992611 を WSUS 上で「拒否済み」状態とし、KB2992611 の再配信を停止します。

1. WSUS 管理コンソールを起動して、左ペインのツリーより [更新] をクリックします。
2. 右ペインの [検索] をクリックします。
3. 検索ボックスに 2992611 を入力して [検索] をクリックします。
4. 検索結果に一致する更新プログラムが表示されますので、KB2992611 を右クリックし [拒否] をクリックします。

[7] 対処策2：配信された更新プログラムを「非表示」にする
WSUS から配信された更新プログラム KB2992611 をクライアント側で「非表示」にして、自動適用や表示上の対象外とします。下記の公開情報にて紹介している手順にて、更新プログラムを「非表示」にすることが可能です。クライアント OS 向けに公開している情報となりますが、Windows Server 2012 でも同様の手順となります。

Title: Windows 7 の Windows Update で更新プログラムが検出された場合に、更新プログラムを非表示に設定することでインストール対象から除外する方法
URL:https://support.microsoft.com/ja-jp/help/2463965

[8] その他の事例
2018 年 9 月現在、他の更新プログラムによって同様の事象が発生したという報告は確認できておりません。

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

2018 年 9 月 11 日公開の更新プログラムを適用すると、以下の問題が発生することが判明しましたので、本 Blog で問題の内容と対応策をご案内します。

[ 問題の概要 ]

2018 年 9 月 11 日公開の更新プログラムを Hyper-V ホストに適用後、NLB ユニキャストモードを構成している仮想マシンを再起動すると、その仮想マシンへの通信ができなくなります。

※ NLB マルチキャストモードまたは IGMP マルチキャストモードを利用している仮想マシンは影響ありません。

[ 対象 OS ]

この現象は、現在サポートしているすべての OS バージョンで発生します。

[ 原因 ]

Hyper-V ホストで MAC アドレス スプーフィング機能が動作しなくなることで発生します。

仮想マシンで NLB をユニキャストモードで構成している場合、本来は仮想マシン上のネットワークアダプタの MAC アドレスが NLB ユニキャストモードの 仮想 MAC アドレス (02-BF-XX-XX-XX-XX) に変更されます。

しかし、Hyper-V ホストで MAC アドレス スプーフィング機能が動作しなくなると、仮想マシン上のネットワークアダプタの MAC アドレスが実 MAC アドレス (例 : 00-15-5D-XX-XX-XX) となります。

これにより、NLB ユニキャストモードを構成した仮想マシンへの通信ができなくなります。

[ 対応策 ]

本問題が発生した場合、以下のように対応ください。

1. Hyper-V ホストで、問題が修正された更新プログラムを適用するか、または、問題の発生する更新プログラムをアンインストールして、OS 再起動します。

2. 1 の完了後に、NLB ユニキャストモードを構成している仮想マシンで OS 再起動します。

※Preview of Monthly Rollup の修正内容は 10 月の Monthly Rollup に含まれる予定です。

※現時点で未修正のバージョンは、修正を公開次第、本 Blog の情報を更新予定です。

[ 更新履歴 ]

2018/09/25 : 本 Blog の公開

[ 補足 ]

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

皆様、こんにちは。Windows プラットフォーム サポート担当の永谷です。
今回はモバイル ブロードバンド接続 (LTE 等) の "自動接続を抑止する" 手順を紹介します。

- 対象の環境
Windows 10 v1607 (RS 1) 以降の OS にてモバイル ブロードバンド接続をご利用頂いている環境
今回の Blog では、弊社サポート部門へのお問合せも数多くお寄せいただいておりますモバイル ブロードバンド接続の自動接続設定を [無効] にする設定をご案内致します。
自動的にモバイル ブロードバンド接続が行われてしまう動作を抑止したいお客様は是非お役立てください。

===============================
設定方法
===============================
下記レジストリ値を端末に設定いただくことでモバイル ブロードバンド接続が "自動的に接続すること" を抑止することが可能です。
- レジストリ：
キー : HKLM\Software\Policies\Microsoft\Windows\WwanSvc\GroupPolicy
名前 : DisableWwanAutoConnect
種類 : REG_DWORD
値 : 1

(補足)
・レジストリ パスについては、WwanSvc キーは既定では存在しないキーのため、WwanSvc キーより新規で作成いただく必要がございます。
・レジストリ設定後は OS、または WwanSvc サービスの再起動が必要です。
・本設定を実施した場合、モバイル ブロードバンド接続 (LTE) の自動接続が行われなくなります。
・当該レジストリで LTE の自動接続設定を [有効] に強制することはできません。
・設定を元に戻す際には、"値" を 0 にして端末を再起動して下さい。

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