お仕事の方で、本当に久々に WSUS の導入部分を担当しています。ここ最近は SMS や MOM といったプロダクトのお話を優先的に引き受けていたので、自分で真面目に WSUS を担当するのは１年半ぶりぐらいかと・・・
# WUS と呼ばれていたころのα版から触っているので、長い付き合いではあるのですが。
さて WSUS は「誰でも簡単に導入・管理することが出来る無償製品」というのがコンセプトなわけでして、実際 クリーンな状態の Windows Server に導入するのは目をつぶっていても出来るほどです。複雑なことをやろうとするとそれなりに制限はありますが、やはりこの容易性は捨てがたいものがあります。
が、逆にそれが仇となっているのか、あまり細かい情報が Microsoft から提供されていない気がするんですよね。特にセキュリティにうるさい環境でいれようとするとちょっとした構成変更が原因で導入・管理エラーが発生しまくります。
そんなときに特に役立つのが Windows Server Update Services Wiki のトラブルシューティング・ページです。
【WSUS Wiki: WSUS Troubleshooting】
http://www.wsuswiki.com/WSusTroubleshooting
いろいろとカテゴリごとにトラブル対応策がリストアップされていますが、特に Troubleshooting WSUS In Production のページが秀逸。
今回の私は、このページに書かれている項目のほぼすべてを経験しました(￣▽￣)
どれも決して難しいトラブルではないんですが、とにかく一個解決しては次の問題という感じの連続攻撃だったため、かなり疲れました。
備忘録を兼ねて、比較的問題判別に時間がかかった項目をあげておきます。
- プロキシを使っている環境で EVENT ID 364 が（同期のタイミングで）発生した場合、“%programfiles%\Update Services\tools\osql\osql.exe” -S servername\WSUS -E -b -n –Q “USE SUSDB update tbConfigurationC set BitsDownloadPriorityForeground=1”とコマンドラインから入力して BITS をフォアグラウンドで実行するように変更すると、動くようになる。若干安定性は悪くなりますが。。。
# ちなみに BitsDownloadPriorityForeground のデフォルト値は 0 です。 なお、Firewall or Proxy 側を変更する方法もあります。 - 通信は出来ているのにファイルを落とせない場合、WSUS Content ディレクトリのアクセス権設定が書き換えられている可能性がある。多少環境に依存しますが、少なくとも Network Services に Read の権限が必要です。
# 特にセキュリティ設定をしていない環境であれば、WSUS のインストール中に勝手に適切な権限が付与されます。 - WSUS に対応するためには、各クライアントにおける Wuaueng.dll のバージョンが 5.8.0.2469 以降である必要がある。
- WSUS のクライアント側で間違ったコンフィグをしてしまった場合、その変更をサーバー側に直ちに反映させるためには wuauclt.exe /resetauthorization /detectnow とクライアント側で入力する。
# /resetauthorization オプションをつけないと、cookie に残った情報がしばらく使用されつづけてしまいます。 - 何かおかしくなったら再インストールもひとつの手。構成情報やDBを残したままアンインストールできるので、たとえば管理用Webサイトの起動がおかしくなったら WSUS のアンインストール ＆ 再インストールをするのが一番スピーディーな解決方法になるケースもある。
- 設定次第ですが、原則として IIS の anonymous access (virtual Self Update ディレクトリ) を許可する必要がある。
# 普通に IIS を入れた場合は、勝手に適切な権限が付与されます。
今回は Wiki のおかげでどうにか大きく止まることもなく進んだ感じです。
うーん、どうもここ最近 エンジニアとしての勘が鈍ってきているように感じます…(´･ω･`)