このエントリはシリーズになっています。他のエントリも合わせて参照してください。
- [Windows Server 2012でのDHCPを利用したNAPの構築方法 part1 | WindowsServer管理者への道](https://windowsadmin.ebisuda.net/2013/04/26/windows-server-2012%e3%81%a7%e3%81%aedhcp%e3%82%92%e5%88%a9%e7%94%a8%e3%81%97%e3%81%9fnap%e3%81%ae%e6%a7%8b%e7%af%89%e6%96%b9%e6%b3%95-part1/)
- [Windows Server 2012でのDHCPを利用したNAPの構築方法 part2 | WindowsServer管理者への道](https://windowsadmin.ebisuda.net/2013/05/07/windows-server-2012%e3%81%a7%e3%81%aedhcp%e3%82%92%e5%88%a9%e7%94%a8%e3%81%97%e3%81%9fnap%e3%81%ae%e6%a7%8b%e7%af%89%e6%96%b9%e6%b3%95-part2/)
- [Windows Server 2012でのDHCPを利用したNAPの構築方法 part3 SCCM(WSUS)連携 | WindowsServer管理者への道](https://windowsadmin.ebisuda.net/2013/05/09/windows-server-2012%e3%81%a7%e3%81%aedhcp%e3%82%92%e5%88%a9%e7%94%a8%e3%81%97%e3%81%9fnap%e3%81%ae%e6%a7%8b%e7%af%89%e6%96%b9%e6%b3%95-part3-sccmwsus%e9%80%a3%e6%90%ba/)
前回はDHCPを利用したNAP環境を構築しました。今回はセキュリティ更新プログラムの更新の動作をSCCM上のWSUSと連携させて行なってみました。実際にはソフトウェア更新部分にはSCCMサーバーを利用しており、大部分はWSUSでも同じです。途中うまく行かず試行錯誤しておりますが、そのまま記録しておきました。
前提条件は以下です。
・SCCMが構成されていること
・SCCMでソフトウェア更新ポイントが構成されていること
・クライアントにSCCMクライアントがインストールされている(されるように構成されている)こと
まずNPSサーバー上でのポリシーの設定を行います。
重要及びそれ以上の更新プログラムが存在しており、インストールされていない場合には検疫されるように設定しました。
設定後にクライアント側でどのように認識されているのかはnetshコマンドで確認できます。
netsh nap client show state
クライアントの状態:
名前 = Network Access Protection Client 説明 = Microsoft Network Access Protection Client プロトコルのバージョン = 1.0 状態 = 有効 制限の状態 = 制限なし トラブルシューティングの URL
制限の開始時刻 = 拡張状態 = グループ ポリシー = 構成済み 強制クライアントの状態:
ID = 79617 名前 = DHCP 検疫強制クライアント 説明 = DHCP ベースの強制を NAP に提供します。 バージョン = 1.0 ベンダー名 = Microsoft Corporation 登録日 = 初期化済み = はい ID = 79619 名前 = IPsec 証明書利用者 説明 = IPsec ベースの強制をネットワーク アクセス保護に提供します。 バージョン = 1.0 ベンダー名 = Microsoft Corporation 登録日 = 初期化済み = いいえ ID = 79621 名前 = RD ゲートウェイ検疫強制クライアント 説明 = NAP 用に RD ゲートウェイを強制します バージョン = 1.0 ベンダー名 = Microsoft Corporation 登録日 = 初期化済み = いいえ ID = 79623 名前 = EAP 検疫強制クライアント 説明 = ネットワーク アクセス保護の強制を 802.1X や VPN テクノロジで使用される EAP 認証ネットワーク接続に提供します。 バージョン = 1.0 ベンダー名 = Microsoft Corporation 登録日 = 初期化済み = いいえ System Health Agent (SHA) の状態:
ID = 79744 名前 = Windows セキュリティ正常性エージェント 説明 = Windows セキュリティ正常性エージェントは、コンピューターのセキュリティ設定を監視します。 バージョン = 1.0 ベンダー名 = Microsoft Corporation 登録日 = 初期化済み = はい エラーのカテゴリ = なし 修復の状態 = 成功 修復の割合 = 0 修正のメッセージ = (3237937214) - Windows セキュリティ正常性エージェントは、このコンピューターのセキュリティ状態の更新を終了しました。 確認の結果 = (0x00000000) - (0x00000000) - (0x00000000) - (0x00000000) - (0x00000000) - (0x00000000) - (0x00000000) - (0x00000000) - 修復の結果 = OK
上記結果は成功になっていたが、Windows FireWallを手動で設定変更すると設定が改めて確認され、検疫されました。
■SCCMクライアントのインストール
テストで用意したクライアントはインストール直後でまだSCCMクライアントがインストールされていませんでしたので、まずはSCCMクライアントをインストールします。(※もちろん本来は事前にインストールされておいてしかるべきです。)
しかし、インストールできませんでした。
クライアント側のインストールログ(c:\Windows\ccmsetup\Logs\ccmsetup.log)を確認した所ADにアクセスできないので失敗している模様です。検疫中でDCへのアクセスを許可していないので当然ですね。
検疫ネットワークを構成した際には、セットアップは検疫ネットワーク外で行うなどの対処が必要ですね。ここでは一時的に制限を解除してクライアントのインストールを完了しました。
インストール後、SCCMが動作しだすと以下のように検疫された上で強制的に更新ソフトウェアがインストールされ再起動を促されました。
この後再起動後を実施しましたが、再起動後も検疫されたままの状態です。
どうやら、きちんとSCCM(WSUS)のソフトウェア更新機能が動作していないようです。
確認の為に更新プログラムの確認を手動で行いました。
結果、エラーコード 8024402Cで失敗してしまいました。これはきちんとWSUSと通信できていないようです。WSUSとの通信を確認します。
ポリシー上、アクセスするのは以下のアドレスです。
telnetで8530ポートへの接続を確認した所、そもそもTCPでコネクションが貼れない状態でした。
サーバー側できちんと8530ポートで待ち受けているのかを確認します。
これはきちんと待ち受けが出来ています。
再度クライアント側で確認した所
telnet stcsccm1 8530
というコマンド入力ではきちんと接続が行えました。つまり、DNSでの名前解決に失敗している状態でした。
現在の設定では検疫されている状態で修復サーバーとしてSCCMサーバーのみを設定しているため、ActiveDirectoryへのログオンやDNSの名前解決等もまともに行えず修復動作にも支障をきたしてしまっている状態です。名前解決ができるようにする方法はいくつかありますが、とりあえずDCへのアクセスは許可する方針にしました。
修復サーバーグループは1つのポリシーで1つしか選択できないため、同一のグループにsccmサーバーとdcを記述しました。この状態でクライアントを再起動しました。
きちんとDCへのホストルートが追加されました。
その後はきちんと検疫～更新プログラムの適用動作が行われました。
ユーザーにはこのように通知されます。自分からクリックしたことで表示されていますのでこのレベルではNAPにより検疫されていることに気が付かないユーザーも出てしまいそうですね。
アクションセンター経由で確認した所、きちんと更新中のステータスになっていました。
その後、特になにも表示されずに通常通りアクセス可能な状態になりました。特に何も通知されないのはやはりちょっと気になります。
未適用の更新プログラムは存在しない状態にきちんとなっています。
しかし、検疫されなくなった後でも、裏で更新プログラムが適用され続けています。ネットワーク復帰のタイミングはこれでいいのでしょうか?ちょっと疑問が残る所ではありますが、更新プログラムの適用に長い時間がかかるケースもあるでしょうからこのタイミングでもいいのかもしれません。
適用完了後、再起動を促されました。
ひと通りうまく動いているようです。