2007年1月アーカイブ

WSUS クライアント関連のトラブル対策 Part.4 です。
前回までで、WSUS の基本的なサイクルに沿った対応方法を紹介してきました。

今回はその他に思いついたものをざっくばらんに。

【事象E: エラーコード 0x8024400a が表示される】

WSUS を使って実運用を開始した当初など、WSUS の管理コンソールや WindowsUpdate.log, ReportEvents.log などあらゆる場所でこのエラー番号を見ることになる場合があります。

これは WSUS (というかそのコンポーネントである IIS) の既知のエラーです。
エラーコードが同じ 0x8024400a でも、エラーメッセージは「エージェントの検出に失敗」だったり「ダウンロードエラー」だったりといろいろありますが、コードが同じであれば原因もほぼ間違いなく同じです。

詳細は下記KBに記載されています。

　A client computer fails with a "0x8024400a" error code when it retrieves new updates from a WSUS server that is running Windows Server 2003 Service Pack 1

で実際に何をするかですが、下記KB内 にある hotfix を適用（要リブート）すればOKです。

　[FIX] POST 要求を送信すると、IIS 6.0 が応答ストリームの途中で "HTTP 100 Continue" 応答を送信する

【事象F: 特定の端末だけ、どうしてもインストールや検出に失敗する】

これまで紹介したすべての事項を確認しても問題がないのに、特定の端末だけインストールや検出がまったくできないといった場合、Windows や WSUS としての問題ではなく、導入されているアプリケーションが原因である可能性があります。

すでに何度か書いていますが、たとえば ISA Server を導入している端末では、ISA 自身の構成として WSUS を許可してあげる必要があります。手元に英語版の ISA しかないので日本語表記の確認ができないのですが、英語の場合は HTTP Connectivity verifiers が有効になっている必要があります。

またサードパーティのソフトウェアでも WSUS の動作を拒否してしまうものがあります。特に多いのがセキュリティ構成管理系の製品で、予め許可していない通信や実行ファイルの起動を拒否してしまうような構成をとっているケースが多いです。
アプリケーションの性質によって何を有効化してあげなければいけないかは違うのですが、比較的失敗の原因として多いものをあげると、

• wuauclt.exe の起動が拒否されている。
• %Windir%\SoftwareDistribution\サブフォルダ にダウンロードされる update.exe （パッチひとつにつき、ひとつのサブフォルダと実行ファイルが存在します） の実行が拒否されている。
• %Windir%\SoftwareDistribution\Download に対して一時ファイルを書き込めないように構成されている。
  　

といったあたりです。
WSUS を邪魔しているアプリケーションが明確な場合は、その製品のログファイルを見たほうが原因を掴みやすいかもしれません。

【事象G: なぜかダウンロードに失敗し続けるパッチがある】

今回はWSUSサーバーとクライアント間での障害をテーマとして扱ってきましたが、少しだけ脇道に入って WSUSサーバーと Microsoft Update サイトとの間で発生する問題をひとつ取り上げておきます。

こっちの方面もいろいろとトラブルのバリエーションがあるんですが、今回は大半のパッチがダウンロードできているのに、なぜかいつまで待っても「ダウンロード」が完了せず、タイムアウトになってしまうパッチが存在するというケースを取上げます。この場合 WSUS サーバー上のイベントログに、具体的にどのパッチのダウンロードに失敗したかのメッセージが表示されます。
私個人の経験ですと、IEの累積パッチや一部のファイルサイズが大きいパッチでこの問題が発生するパターンが多いです。

対応策ですが、本来はネットワークの経路とかきちんと見てあげて滞っているポイントを探し出すべきです。とはいえ、それが簡単にいかない場合もあるでしょう。
その場合、あまりきれいな方法ではありませんが、対象のパッチを（WSUSのシステムを使わずに）マニュアルでダウンロードし、適切なフォルダに放り込んであげるというやり方があります。

具体的な方法ですが、詳細な手順を記載した blog がありましたのでリンクだけ張っておきます。

　WSUSでどうしても同期ができないパッチを回復させる方法 (http://messiah-annex.at.webry.info/200506/article_3.html)

---
これまで長々と書いてきましたが、この4回分の内容が一通り頭の中に入っていれば、WSUS の障害ということで突然呼び出されてもオドオドすることはないかと。。。

次回 Part.5 という形で、いちおうまとめ的なものを書こうと思います。

少し間が開いてしまいましたが、Part.1, Part.2 の続きです。

【事象C: 承認したパッチのダウンロード/インストールが始まらない】

事象B の「いつまで経っても Status Report がサーバーに上がってこない」 を無事に乗り越えると、その端末に対するパッチの承認＆適用プロセスに入ることができます。

ここで発生し得る問題としては「承認したはずのパッチが何時まで経ってもインストールされない（ダウンロードされない）」というものです。

この問題に関しては まずはクライアント側で、WSUS サーバーに対する “ポーリング間隔” がどのように設定されているのかを確認しましょう。 グループ ポリシーであれば [Windows コンポーネント] - [Windows Update] - [自動更新の検出頻度] という項目で、未構成の場合は 22 時間間隔（前後ブレあり）になります。

WSUS はあくまでもクライアント側からの polling によってパッチ適用の必要性を判断しますので、パッチの承認を行っても、その後でクライアントからの検出が行われなければ次のステップに進みません。もしデフォルトのまま22時間という設定であれば、承認後に最長22時間検出が行われないというのは正常動作の範囲内になります。

トラブル対応時などでそのような悠長なことを言っていられない場合は、クライアント側で wuauclt /detectnow と入力し、直ちに検出を開始させましょう。

事象B の問題にあった「ステータスレポート」が問題なく送信できている状態であれば、数分以内に“自動更新の検出”が行われ、承認したパッチのダウンロードが試行されます。
# 検出の具体的なプロセスを確認したい場合は、WindowsUpdate.log を見るとよいでしょう。

---
検出までのプロセスが適切に行われると、必要なパッチのダウンロードが始まります。
# クライアント側の設定によっては、自動ダウンロードする代わりに、通知領域にダウンロードの準備ができたことを示すメッセージが表示されます。

パッチのダウンロードですが、一時保管領域として %Windir%\SoftwareDistribution\Download が使用されます。詳細なところは WindowsUpdate.log 等で確認する必要がありますが、ここに順次新しいファイルが作られていることを確認できれば、ダウンロード・プロセスは問題なく開始されていると考えてよいでしょう。

「検出はされているのに、ダウンロードが開始されない」という場合はいろいろな原因が考えられますが、大抵は Part.1 や Part.2 で紹介したトラブルシューティングのいずれかで解決できるはずです。
落ち着いてひとつひとつ確認していきましょう。

特に原因になっているケースが多いのが、自動更新サービスやデータベースファイルなどの必要機能が何らかの理由で停止／破損してしまっている場合です。
Part.1 や Part.2 でも類似のケースをご紹介しましたが、とりあえず一連の基本確認作業をバッチ化するとこんな感じです。

net stop wuauserv
net stop bits
regsvr32 /u wuaueng.dll /s
rmdir /S /Q %windir%\softwaredistribution
del /Q %windir%\windosupdate.log
regsvr32 wuaueng.dll /s
net start wuauserv
net start bits
wuauclt.exe /resetauthorization /detectnow

ここまでのすべてを実施してもダウンロードが開始されないいとなると、、、
少々一般的ではない障害である可能性がありますので、ログファイルをじっくり見る必要がありそうです。

【事象D: ダウンロードが始ったが完了しない】

さて次の関門は、ダウンロードは始まったぽい（＝「SoftwareDistribution\Download フォルダに何かしらのファイルはある）のに、通知領域にはずっとダウンロード中のメッセージが表示され続け、ダウンロードが完了しないというケースです。

この場合は、Automatic Updates サービスのアクセス権設定（DACL）に問題がある可能性が高いです。Part.1 のときも紹介しましたが、グループポリシーで中途半端に Automatic Updates サービスの動作を設定してしまっていると、予期せず必要な権限を削除してしまっていたという事例が多くみられます。
グループポリシーで設定している場合は、できる限り Automatic Updates サービスの起動状態だけではなく、明示的にアクセス権の設定も合わせてしてあげたほうが無難でしょう。通常は、SYSTEM & Administrators に Full Control, Authenticated Users に Modify 以上の権限があれば WSUS 的には十分です。

なお、グループポリシー以外の方法でサービスに対するアクセス権を設定したい場合ですが、Windows 標準コマンドである SC sdset を利用するのが一般的です。
セキュリティ記述子定義言語 (SDDL) を使用するためパラメータの指定に少々癖がありますが、とりあえず Automatic Updates サービスの権限を正しいものに変更したい場合はこんな感じです。
# 以下を１行で入力します。詳細は KB555336 に記載されています。

sc sdset wuauserv "D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;AU)(A;;CCLCSWRPWPDTLOCRRC;;;PU)"

自分で書いていてイヤになるほどの散文乱文ですが、ここまでの３回に渡った内容を熟知していただければ、WSUSサーバー／クライアント間で発生する問題の大半は解決できるはずです。

次回は、ここまでで紹介しきれなかった個別の事象／既知の問題／参考情報なんかを書いてみたいと思います。

Exchange Server や SQL Server でお馴染みの自習書シリーズに、SMS v4 (System Center Configuration Manager 2007) が加わりました！

全８章で構成され、SMS v4 の主要機能を一通り確認することができるようになっています。
もちろん日本語です。

【SMS v4 自習書シリーズ】
http://www.microsoft.com/japan/technet/prodtechnol/sms/exercises.mspx

SMS v4 β1 を前提として書かれているため、正式版では多少なりとも変更は発生します。

とはいえ、すでに自習書シリーズの名に恥じない良書に仕上がっています。
ドキュメント・ヘッダーに「SMS v4で始めるシステム管理」とある言葉のとおり、“なんとなく SMS v4 というものに興味がある”, “SMS v4 をとりあえず触ってみたい”という方に対する最初の一冊として強くお奨めできます。

また、今回の自習書は SCCM 2007 (SMSv4) 用に構成されているとはいえ、現行製品の SMS 2003 に対しても大まかに適用できる内容になっています。
もちろん細かいレベルではいろいろ違いますが、“SMS 2003 をこれから初めて使用する方”にとっても十分に有用な資料であると思います。

---
このように自習書シリーズを整え始めてきている現状から見ても、最近の Microsoft がシステム管理系製品に十分な力を注ぎ始めていることが分かります。
この流れで、製品リリース後も継続的に情報の提供／更改が行われ続けることに期待します。

後でもう少し分かりやすく整理したいと思いますが、リクエストがあったのでとりあえず私がよく訪れているサイトを並べてみます。

【Microsoft TechNet : Systems Management Server Community】
http://www.microsoft.com/technet/sms/community/default.mspx
Microsof 公式の SMS 関連コミュニティポータル。

【myITforum.com】
http://www.myitforum.com
システム管理系の技術・製品を対象とした世界最大規模のコミュニティ。
Windowsベースのシステムを管理するためのテクノロジーを主に扱っており、中でもSMS関連は群を抜く情報量が集まる。

■ myITforum.com : Microsoft Systems Management Server Community Forum
SMSを対象としたディスカッションフォーラム。

■ myITforum.com : Microsoft Systems Management Server (SMS) List

SMS をテーマとしたメーリングリスト。一日あたりの投稿数は大抵200件を越えるモンスターML。

■ myITforum.com : SMS 2003 Articles
myITforum 内の blogger によって書かれた SMS 関連記事一覧。

【Tek-Tips : Microsoft: SMS (Systems Management Server) Forum】
http://www.tek-tips.com/threadminder.cfm?pid=22

Tecumseh Group, Inc が提供するコミュニティフォーラム。

【FAQShop.com: Welcome to the SMS 2003 Section】
http://www.faqshop.com/sms2003/default.htm

SMS 関連を情報を、局面別の FAQ 集として提供。

とりあえずこんなところでしょうかね。

うーん、気がつけば1週間ほど更新から遠ざかっていたようです。

年明け後もお仕事の方がずっとピークで、特に先週末はここ数年で最もテクニカル・リスクが高い作業だったため、精神的にも肉体的にも相当な負担でした。蓄えられる経験値もここ最近経験しないほど大幅なものでしたが。

で、システム変更後 最初の通常営業日となる本日をとりあえず問題なしに通過することができ、今ようやく精神的な面での荷が下りたところです。
ただ、今週末まで不安で不安でまったく落ち着くことができなかったので、体力的な回復はもう少しかかりそうな気配。

半年以上前から続いている今のお仕事（プロジェクト）の最大の山場はこれで乗り越えることができましたが、まだまだ「残作業」は山積み。
安息の日々が来るのはもう少し先になりそうです。

というわけで更新間隔が開いた言い訳を書いてみました。
更新に飽きたとかではないので、気長にお待ちいただければありがたいかと。

前回の続編です。

【事象B: いつまで経っても Status Report がサーバーに上がってこない】
事象Aの「特定の端末が WSUS クライアントとして認識されない」という問題が解消されると、WSUS 管理コンソール上にそのコンピュータ名が表示されるようになり、さらにしばらく待つとスキャン結果（どの更新プログラムが適用されているか／いないか）が報告されてきます。
WSUS では、このスキャンレポートの情報を基準に、承認された更新プログラムのうち未適用のパッチが自動選別／適用される仕組みになっています。

しかし、待てども待てどもスキャンレポートが検出／報告されないというケースがあります。
また、当初は報告されていたが、いつの間にか報告されなくなっているというケースもあるでしょう。
# 長期間（デフォルトでは30日間）報告がないと、管理コンソール上にその旨を示すメッセージが表示されます。

この場合に疑うべき項目ですが、まずは事象Aのときの問題が再度発生していないか、です。
具体的には「WSUSサーバーアドレスの指定がいつの間にか変わってしまっていないか」「必要なサービス (Automatic Updates / BITS) は起動できているか」「WSUS サーバーに HTTP or HTTPS 通信できているか」「ファイアうウォールなどの障害になり得るアプリケーションが後から追加されていないか」の４点を確認します。
特に、一度はスキャンレポートがされているのに、ある日から出来なくなってしまったという場合にはこれらいずれかが該当する可能性が高いです。

次に、上記いずれでもない場合で、かつ該当クライアントが Windows Server 2003 SP1 または Windows Serer 2003 R2 の場合、下記KBに該当する可能性があります。

A client computer fails with a "0x8024400a" error code when it retrieves new updates from a WSUS server that is running Windows Server 2003 Service Pack 1

タイトルのとおり、0x8024400a のエラーコードが WindowsUpdate.log や WSUS 管理コンソールに表示されている場合、上記KB に記載のとおり更新プログラム (KB898708) を適用して再チャレンジしてみましょう。この更新プログラムは、http://support.microsoft.com/kb/898708/ からダウンロード可能です。
# 更新プログラムの適用を有効にするためには、再起動が必要です。

それ以外に考えられる原因として、Windows Update Agenｔ や関連サービスが conflict を起こしている可能性があります。
Windows Update Agent はその名のとおり、 Windows Update や WSUS サーバーへのアクセスを行う実行ファイルですが、あまり作りがよくないのか、まれに破損している場合があります。
その場合ですが、Web (http://go.microsoft.com/fwlink/?LinkId=43264) から最新版の Windows Update Agent 2.0 をダウンロードし、
　WindowsUpdateAgent20-x86.exe /wuforce
とオプションをつけて再インストールしてみます。
# /wuforce オプションは、現在インストールされていても上書き強制インストールするためのものです。

再インストール後に、Windows Updates サービスと BITS サービスも再起動させておきます。
万が一それらサービス自体が破損している場合を考えて、regsvr32 を使ってサービスの再導入も合わせて実施すれば万全です。regsvr32 を使った必要サービスの再導入は、SMS 2003 ITMU で patch 適用に失敗する場合の対処 batch の記事を参考にしてください。
　

いずれの対応を実施した場合でも、最後にクライアントでコマンドプロンプトを立ち上げて、
　wuauclt /resetauthorization /detectnow
と入力して、直ちにスキャンが開始されるようにします。
問題が解消されていれば、5分程度で WSUS 管理コンソールにスキャン結果が表示されれくるようになります。

Part.3 に続きます。

昨日は 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 はここまで。

一昨日が2007年最初の月例パッチの日だったということで、私も某所で SMS 2003 (ITMU Revision 3) を使った導入に勤しんでおりました。

が、どうも今月は SMS の気分が乗らないらしく、結構な頻度でインストール失敗のログが…
原因は 「Automatic Updates や BITS といった必要なサービスが停止してしまっていた」「モジュールのダウンロードが中途半端な状態で行われて、キャッシュにその情報が残ってしまった」「クライアント上のスキャンプログラムが適切に動いていない」といった、いずれも ITMU ではよく見るものばかりだったのですが、なぜか今回は結構な頻度。

ここの環境はそもそも、いつの間にかポリシーやネットワーク構成が変更されていたり、各クライアントで好き勝手にシステムがいじられたりするようなところなので、最初から成功率100%ということは想定していないのですが、それに加えて12月に ITMU のバージョンを Revision 3 に上げたことも何らかの原因になっているのかもしれません。

こういった場合ですが、「エラーが発生した端末の必要サービスを起動する」「キャッシュを削除する」といった基本的な回避策をとれば、大抵すぐに直ります。
とはいえそういった作業をマニュアルでやっていては何のために SMS を入れているのか分からなくなりますので、バッチ化して SMS や（それが難しい場合は）ログオンスクリプト等で配布すれば効率的です。

その実際に使えるバッチですが、下記で良い感じのモノが紹介されていました。

【ITMU Updates Fail when Scan Tool fails to Run】
http://myitforum.com/cs2/blogs/btucker/archive/2005/11/08/16757.aspx

上記バッチを流せば、ITMU 関連の大抵の“よくあるエラー”は解消されます。
SMS で配信する場合は、パッケージ（プログラム）のプロパティで [非表示 (hidden)] と [プログラムの通知を抑制する (Suppress program notifications) ] の２つを指定しておけば、ユーザーに意識させることがなくなるため better です。

---
なお基本的には上記バッチで十分ですが、障害ケースによってはそもそも "regsvr32 wuaueng.dll /s " などのDLL登録の部分で失敗してしまう場合があります。
そのため、単純に登録するのではなく、いったん regsvr32 /u を使ってコンポーネント解除しておけば、より確実です。

具体的にはこんな感じで。

cd %windir%\system32
regsvr32 /u wuapi.dll /s
regsvr32 /u wuaueng.dll /s
regsvr32 /u wuaueng1.dll /s
regsvr32 /u wucltui.dll /s
regsvr32 /u wups.dll /s
regsvr32 /u wups2.dll /s
regsvr32 /u wuweb.dll /s
regsvr32 wuapi.dll /s
regsvr32 wuaueng.dll /s
regsvr32 wuaueng1.dll /s
regsvr32 wucltui.dll /s
regsvr32 wups.dll /s
regsvr32 wups2.dll /s
regsvr32 wuweb.dll /s
net stop wuauserv
net stop bits
rmdir /S /Q %windir%\softwaredistribution
net start wuauserv
net start bits
exit /B 0

なんか海の向こうでは 2007 International CES でかなり盛り上がっていますね。
CES は Consumer Electronics Show の略で、今年で40回目となる全米家電協会主催の世界最大の家電展示会です。

私は家電系にはできるだけ興味を持たないように努力している（＝一旦興味を持ってしまうと抜け出せないほど熱中してしまうので。。。）のですが、今年の基調講演では Windows IT系な人々にとって見逃せない製品の発表が行われました。
すでにご存知の方も多いと思いますが、 家庭向け初のサーバーOS となる Windows Home Server です。
いよいよ一家に一サーバーという時代が来る可能性があるかと思うと、IT を取り巻く環境の変化に改めて驚かされます。

欧米と日本では家庭環境や文化の違いがありますが、現段階ではどちらの環境でも期待を持てそうな新製品です。

詳細な説明は今後順次出てくると思いますので、とりあえず今日は CES での Windows Home Server 関連 (Bill Gates の基調講演関連) のページを一気に貼り付けておきたいと思います。

---
まず日本語で読めるネット・メディア系だと、CNET Japan が比較的力を入れている気がします。
たとえばこんな感じ。

【ラウンドアップ：「2007 International CES」開幕--今年の目玉は？】
http://japan.cnet.com/news/tech/story/0,2000056025,20340341,00.htm

【マイクロソフト、「Windows Home Server」を発表--ゲイツ氏基調講演】
http://japan.cnet.com/news/media/story/0,2000056023,20340284,00.htm

【CES開幕--今回注目のテクノロジは？】
http://japan.cnet.com/news/biz/story/0,2000056020,20340262,00.htm

【B・ゲイツ氏、CESで基調講演--Vistaやリビング向け戦略を語る】
http://japan.cnet.com/news/biz/story/0,2000056020,20340253,00.htm

---
英語のメディア系はかなり情報があふれていますが、一パラグラフで気軽に読める点がよいのは ActiveWin.com です。具体的な情報が欲しい場合は他のサイトの方がよいです。

【Q&A: Windows Home Server Simplifies Digital Life for Families】
http://www.activewin.com/awin/comments.asp?HeadlineIndex=37918

【Windows Home Server Predictions】
http://www.activewin.com/awin/comments.asp?HeadlineIndex=37917

【CES 2007: You let me down, Bill - keynote analysis】
http://www.activewin.com/awin/comments.asp?HeadlineIndex=37897

---
Microsoft 関係者の Blog もかなり盛り上がっています。
タイトルだけざっと見て紹介しているので中身は違うかもしれませんが、一例を紹介。
# blogs.technet.com で "Windows Home Server" を検索すると、なんと 1500件ほど hit します。

【Windows Home Serverの発表】
http://blogs.msdn.com/hiroyask/archive/2007/01/09/windows-home-server.aspx

【Windows Home Server 2007 @ CES】
http://blogs.technet.com/tliles/archive/2007/01/08/windows-home-server-2007-ces.aspx

【The secret is out. Windows Home Server is announced!】
http://blogs.technet.com/kevin_beares/archive/2007/01/07/the-secret-is-out-windows-home-server-is-announced.aspx

【Windows Home Server】
http://blogs.technet.com/mariaj/archive/2007/01/08/windows-home-server.aspx

【Windows Home Server Announcement】
http://blogs.technet.com/aralves/archive/2007/01/08/windows-home-server-announcement.aspx

【Bill Gates announces Windows Home Server】
http://blogs.technet.com/windowsserver/archive/2007/01/08/bill-gates-announces-windows-home-server.aspx

【Windows Home Server - Its Announced】
http://blogs.technet.com/janelewis/archive/2007/01/08/windows-home-server-its-announced.aspx

【Imagine Halo3 in this bedroom...】
http://blogs.technet.com/keithcombs/archive/2007/01/08/imagine-halo3-in-this-bedroom.aspx

【Microsoft at CES】
http://blogs.technet.com/daven/archive/2007/01/08/microsoft-at-ces.aspx

うーん、この盛り上がりはある意味異常かも。
ホームサーバーという新しい市場を開拓することができるのか、これからの動きに注目です。

そろそろ馴染んできた2007年ですが、今年は1月にパッケージ販売が開始される Windows Vista, そして後半（おそらく年末）に出荷される予定の Windows Server "Longhorn" と、２つの OS に目が離せない年になることは異論の余地がないでしょう。

しかし2007年の個人的最大注目点はそれら OS ではなく、Microsoft のシステム管理系製品ファミリの System Center です。

大雑把に今年一年の予定を洗い出してみると、

• SCOM 2007 のリリース
  MOM 2005 の後継となる System Center Operations Manger 2007 が 1H中にリリースされます。
  正式情報ではありませんが、US の MMS 2007 開催初日にあたる 3月26日発売開始案が有力です。
• SCCM 2007 のリリース
  SMS 2003 の後継、System Center Configuration Manager 2007 のリリースが予定されています。リリース日程は未定ですが、比較的順調に開発・検証が進んでいるようで、1H中という可能性もあります。
• DPM 2006 SP1 の普及
  これはすでに昨年10月にリリース済みですが、SP1 になって Data Protection Manager もようやくエンタープライズでも検討し得るレベルになってきたと思います。シェア拡大が進むかどうかは今年からの動き次第です。
• WSUS 3.0 のリリース
  System Center ファミリには含まれませんが、今やパッチ更新管理のデファクトになりつつある WSUS の新版が 1H中にリリースされる予定です。
• Sytem Center Service Desk のβ2版公開
  完全な新製品である Service Desk は今年中に正式版が出る可能性は低いようですが、ベータ2版としての一般公開が４月ごろに計画されています。

私個人としての最大の注目は、SCCM 2007 (SMS v4) です。
現行製品の SMS 2003 は System Center ファミリの中でも最も古い時期に出ており、そのため現在のビジネスニーズを満たすには厳しい側面も多く現れ始めています。 SCCM 2007 はそういった不満を踏まえ、最も大幅な機能拡張・変更が加えられた製品になります。

これだけ次々と新しいモノが出てくると、System Center ファミリという中でも取捨選択・優先順位付けを上手くしていかなければいけないことが最大の悩みになりそうですヽ(´ー｀)ノ

年末年始は意識的に IT と関わらない生活を試みていたのですが、購入したことも忘れてかけていた ThinkPad X60 が年末に届いたため、セットアップでそれなりの時間を費やしておりました。

まだバリバリ使用しているわけではないのですが、簡単に感想を。

参考までに、現在の私は TOSHIBA dynabook SS M200 (Tablet PC) と IBM ThinkPad T42 の２つを、ノートPCにおける主力としています。その他に、ThinkPad 数台と dynabook ２台と FMV-BIBLO １台 と FLORA １台を所有した過去があるので、私の世代としてはかなりヘビーユーザーなほうかと思います。ただ、ThinkPad の X series は今回が初めてです。

---
で、感想。

何よりも“すっきり感”がいいです。とにかく無駄のないボディ・デザインが気分を落ち着かせます。
これに関しては Lenovo になっても変わらない良さです。

次に重量は、まぁそこそこ軽いかなというレベル。
これまでの主力であった T42 (約 2.2kg) や M200 (約 2.1kg) に比べるとかなり軽い (1.44kg) んですが、最近ではミニノートとかで 1kg を切る製品を出しているメーカーもありますからね。
# 軽さを重視する場合は、 X60 ではなく X60s を選択すれば多少軽くなります。

歴代の ThinkPad と一番大きく変わったのがキー配置ですね。
トラックポイントと絶妙のキーストロークは健在ですが、これまでの ThinkPad には存在しなかった Windows キーが追加されました。私は Windows キーを頻繁に利用するほう (Windows + D とか Windows + R) なので、これまでの ThinkPad ではソフトウェア的に Windows キーを割り当てていたのですが、X60 ではそういった一手間が必要なくなります。

また、アプリケーションキーも追加されています。これに関してはたいてい ［Shift］＋［F10］ で代替できるので、あってもなくても個人的には構わないのですが…
アプリケーションキーが追加されてしまったためか、逆にこれまで存在していた右Altキーがなくなってしまったのです。これは個人的にはかなりイタイ、、、生産性3%ぐらいダウンです(´･ω･`)

次にこれはどうしようもないですが、画面の小ささ(12.1インチ, XGA)は慣れるまで苦労しそう。
今までが SXGA Plus (M200) と SXGA (T42)、自宅のデスクトップは UXGA という環境で慣れているため、これまで必要なかった横スクロールが必要になる場面が多発中。

最後にこれは結構話題になっていましたが、ACアダプタの形状変更。
Lenovo によると、まもなく登場する次世代リチウムイオンへの対応のために電池出力電圧を16Vから20Vに変更し、結果としてこれまでの ACアダプタとの互換性がなくなったということです。

ただそうは言っても、従来からの ThinkPad ユーザーにはかなり不便ですね。
私も従来型のThinkPad 用ACアダプタは１０個近く所有しているのですが、そのうちこの子達の行き場がなくなってしまうことになるのでしょう。逆に新型ACアダプタはまだ１つしか持っていないので、追加アダプタを購入するまではいつも持ち運ばなければいけないなぁ…

---
長々と書きましたが、今後しばらくは私の主力ノートPCとして活躍してくれることでしょう。

昨年の頭に個人目標を書き上げて一年間を過ごしてきたわけですが、目標だけ立てておいて結果報告がないのもどうかと思いますので纏めておきます。

昨年立てた目標は、「06年 課題と目標」 (http://www.wise-hawk.com/blog/2006/01/6.html) に記載がありますので、ご興味があればそちらを参照あれ。

去年は５つの大項目を目標に掲げておりましたので、その流れで纏めます。

【1. 個人タスク（IT系）】
ひとつに Windows Server 2003 R2 、Windows Vista といった新技術情報の追っかけ、もうひとつに SMS や MOM をはじめとするシステム管理系の情報提供の実施を目標としておりました。

今となっては、Windows Server 2003 R2 のリリースなんてもう何年も昔のことのように感じてしまいますが、自分自身でのシステム検証や当 Blog などを通じた情報発信はそれなりにできたと自己評価しております。年初目標で “個人的な予報では、Windows Vista が年内リリースされる確立は35%” なんて書いておりましたが、VL版だけリリースされた結果を見るとなかなかいい線いってましたね…

もうひとつの目標であったシステム管理系の情報提供ですが、こちらは全然ダメだったなぁ～
ウィンドウズ・インフラ・メモ (仮)なんてものを即席で作ってはみたものの、結局ほとんど記事を上げることも出来ず。
# 現在はシステムのバージョンアップに失敗していて、実は更新したくてもできない状態だったり(;´Д｀)

ただ何はともあれお蔭様で、昨年７月付けで Microsoft MVP for Windows Server System - Infrastructure Architect を受賞させていただくことが出来ました。MVP の名前に恥じないよう、これからはもう少し精力的に活動していかないと、、、

【2. 個人タスク（英語）】
年初の予定では“給付金でも使ってそろそろ英会話始めるかな”という感じだったのですが、予想外にお仕事のほうで外国の方ばかりの環境に投げ込まれることになった１年でした。英語スキルの低さで歯がゆい思いをすることが多々ありましたが、どうにか路頭で朽ち果てることなく過ごすことができました。

ただ IT系の専門用語中心の会話なら何とか成り立つものの、日常会話となるとまったくダメダメ。
ちょっとした一言とかがまったく分からないので、突然話しかけられたりするとビビりまくりです。
このあたりはやっぱり、繰り返し練習のできるスクールに通っちゃったほうが早いかも。

【3. 個人タスク（資産形成）】
株式投資を中心としたプチ・リタイアへの道ですが、今年はライブドア・ショックに始まる散々足る１年でした。。。

世間的には日経平均４年連続上昇と堅調だったのですが、私の主戦力である新興市場はジャスダック平均が昨年末比21％安、マザーズ指数が56％安、ヘラクレス指数も52％安となかなか悲惨な状況。
私自身のパフォーマンスを見ても、年間を通じての最大資産と最低資産で３倍以上の開きがある超ジェットコースター型のチャートになっており、かなり精神的に苦しめられました。後半ある程度立ち回りをよくして、どうにかジャスダック平均よりはマシな成績まで戻すことが出来ましたが…

幸いなこととしては、いわゆる「退場」にまでは追い込まれなかったこと、総資産が少ない現段階で貴重な経験を踏むことができたことでしょうか。

【4. 個人タスク(その他)】
“健康”を年初目標にあげておりました。
が、一昨年のバリ島での入院に続き、昨年は体調を崩してまたもや救急車を呼んでもらう事態を１回作ってしまいました。。。(´･ω･`)

健康面への意識という意味でもまじめに自分で取り上げることがなかった一年ですので、この目標に関しては完全に未達です。

【5. 仕事（会社）】
お仕事は、年初のうれしくない大幅な組織変更で嫌気が差していたのですが、前半は広島でのプロジェクトなど複数プロジェクトの掛け持ち、後半は外国人ばかりのお客様先でのプロジェクトとどっぷりプロジェクト三昧の一年だったため、あまり社内の面倒な体制云々は考えずに済みました。
実際、昨年一年間で自席に戻ったのは年間合計で１０回もないと思います(・∀・)

プロジェクトのほうは、まぁいろいろあってストレス溜めまくりですが、どうにか一年間を終えた感じ。
まだしばらく続きますが、爆弾抱えたままゴールできるのかは年初当面の課題になります。

--
以上、2006年の目標に対する結果報告です。
個人的にはかなり「激動」の一年のですが、なんとなく今年は運気が上昇するのではないかと早くも神頼みしてみます(´･ω･`)

ご無沙汰しておりました。
年が明けたとき、本気で「２００６年が来た！」と思ってしまった大ボケ者ですが、今年もよろしくお願いいたします。

年末年始はそれなりに平和に過ごしておりました。年越しの仕事がいっぱい残っているので、あまりリフレッシュ感はありませんが…

今年のプランなり去年の反省なりは、順次書いていく予定です。