昨日は SMS 2003 ITMU を使って更新プログラム管理する場合のトラブルシューティング例を書いたんですが、本日は WSUS でパッチ配信するときに発生する問題とその対処方法を書いてみようと思います。
# WSUS サーバーそのものは、とりえあず問題なく動いているケースを前提としています。
本当は綺麗にまとめたいんですが、とりあえず記憶にある範囲内で思いつくままに書いていきます。
なお文章量が多くなりそうなので、数回に分けて書く予定です。
【基本事項： 最初に確認すべきこと】
まず基本的なところとして、WSUS の動作が期待通りではないときに何を確認するかですが、
- WSUS 管理コンソール
- クライアントの %Windir%\WindowsUpdate.log
- クライアントの %Windir%\SoftwareDistribution\ReportEvents.log
WSUS 管理コンソールで大雑把にクライアント全体の挙動（“WSUS クライアントとして認識されているか”, “更新プログラムの適用状態スキャンが行われているか”, “許可したパッチが期待通り適用されているか”など）を確認し、問題の発生している端末を特定します。
次に、問題の発生している端末上のログファイル２つを確認し、何が原因なのかを突き止めます。場合によってはイベントログにも有用な情報が出ているかもしれません。
どのような問題であってもこの流れは同じです。
ではここから具体的な事象を。
【事象A: 特定の端末が WSUS クライアントとして認識されない】
Group Policy やレジストリを使って WSUS クライアントの指定をしたにもかかわらず、いつまで経ってもWSUS 管理コンソール のコンピュータ一覧に表示されない端末があるというケースです。
適切に動作している場合は、クライアント上で
wuauclt /detectnow
とコマンド入力すれば、即座に WSUS サーバーとの通信が行われ、適用状態のスキャンが開始されます。
さて まず疑うべきは、グループポリシーやレジストリで WSUS サーバーのアドレスを入力ミスしていないか、です。グループポリシーの場合は、「イントラネットの WSUS 更新サービスの場所を指定する」という項目になります。
ここを入力ミスしてしまっていると、どんなに他を頑張っても WSUS サーバーとのコミュニケーションは取れません。 http://WSUSserver の形式で間違いなく指定されているか、目を凝らしてよーく確認しましょう。
# WSUSServer のところは、WSUS サーバーの FQDN/NetBIOS/IPアドレスのいずれでもOKです。
なおサーバーアドレスが間違っている場合、WindowsUpdate.log にサーバーが見つからないことを示す warning が記録されます。
---
WSUS サーバーのアドレスが確かに合っているのに問題が解消されない場合ですが、大きく2つの原因が考えられます。
ひとつは、クライアント上で必要なサービスが起動していないことです。 WSUS は Automatic Updates サービス (wuauserv) と Background Intelligent Transfer Service サービス (BITS) の２つを利用しますので、この2つが稼動している／稼動できることを確認します。スタートアップタイプは必ずしも“自動”である必要はありませんが、環境やセキュリティレベルによっては両方とも“自動”かつ“開始”の状態になっていないと上手く動かないケースがあります。
なおセキュリティ設定等が corrupt し、Automatic Updates サービスを起動しようとしてもアクセスエラーが発生する場合も考えられます。
その場合は、
regsvr32 /u wuaueng.dll
regsvr32 wuaueng.dll
とコマンドラインから入力して、 Windows Updates サービスの再導入を行ってから再チャレンジすると、上手くいくケースが多いです。
ただし、Group Policy で Automatic Updates のスタートアップの種類を指定している場合は、これだけで解消できない場合があります。 これは Automatic Updates サービスに対するアクセス権が不足していることが理由ですので、同時にサービスへのアクセス権として Authenticated Users - Modify の権限を付与しておくと正常稼動するようになります。
# この設定が必要になるのは環境次第であり、必ず行わなければいけないものではないようです。
サービスの起動設定と並んで考えられるもうひとつの原因は、WSUS サーバーとクライアント間のネットワーク通信が適切に行われていないことです。
WSUS はクライアント側から WSUS サーバーに対して、HTTP (80/tcp) で通信を試みます。そのため最低限の条件として、「From クライアント To WSUS サーバー」の関係で 80番が開いている必要があります。
Netsh diag あたりのコマンドを使って、確実に通信ができることを確認しましょう。
# WSUS サーバーの設定により、HTTP ではなく HTTPS(443/tcp) を使用することは可能です。
さらに Proxy が存在する環境の場合、80番が開いているにもかかわらず通信できていないといった症状が発生する場合があります。
具体的には、クライアント上のブラウザから http://WSUSserver/WSUSAdmin と入力すると WSUS 管理コンソールが問題なく表示できる（＝80番でアクセスできている）にも関わらず、Windows Updates サービス的には通信ができていないという現象です。WindowsUpdate.log にはスキャンの開始に失敗していることを示すメッセージなどが記録されます。
これは、Windows Updates サービスが参照する Proxy 設定が、ブラウザ（IE）で指定するプロキシの設定とは違うところを見ている仕様にあるためです。Windows Updates サービスは、ユーザー単位ではなく、コンピュータベースで一意のプロキシ設定情報を持っており、その設定はコマンドラインから
proxycfg
と入力することで確認できます。
WSUS サーバーにアクセスするために Proxy 設定が必要な場合は、この Proxycfg.exe を使って指定してあげましょう。
参考：
- http://support.microsoft.com/kb/417468/ja
- http://msdn2.microsoft.com/en-us/library/aa384069.aspx
---
ここまでやっても駄目な場合は、クライアント側で何か特殊なアプリケーションが稼動していて、そいつが邪魔をしている可能性を考えてみます。たとえば Microsoft 製品を例にとると、 ISA Server が導入されている端末は、ISA Server 自身のファイアウォール機能で WSUS への通信を遮断してしまいます。ISA Server のケースでは、 System Policy で WSUS サーバーへの HTTP通信ができるように許可することで問題が解消されるはずです。
他にも、ネットワーク構成アプリケーションやファイアウォール・マネージメント系のアプリケーションが乗っている端末の場合、それらアプリケーションを疑ってみる価値があります。
---
サービスは動いている。通信も行われている。それでもリストに表示されてこない場合は、環境依存であり一般論が通じない可能性が高いです。
そのため、WindowsUpdate.log をじっくり確認していく必要があります。ログファイル内で、warning というキーワードで検索をかけていき、何が起こっているのかを調べてみると、いつかは苦労が報われる！かもしれません。。。
とりえあず Part.1 はここまで。