Inc.WUSの変更点WUSはSUSを全面的に刷新したもので、基本機能は同じだが、実装の詳細は大幅に変わっている。Page(ASP)ベースのアプリケーションであるのに対し、WUSはASP.NETアプリケーションであり、バンドルされたMSDEデータベースに構成情報と承認の詳細を格納する。2000データベースを使うこともできる。2003上で動作する。この新しいアーキテクチャは、MicrosoftがSUSよりはるかに優れた管理用のユーザー・インターフェイスを構築するのに貢献した。この新しいインターフェイスはローカライズしやすく(最初のリリースでは17の言語がサポートされる)、開発者がサードパーティ・アプリケーション(例えば、パッチ対応監査ツールや、新しい更新プログラムが利用可能になった際に管理者に電子メールで通知する製品など)の統合に利用できるマネージドAPIとSDKをサポートする。WUSでは、主に次のような分野で新機能が提供される。Services(IIS)の生のログにダウンロードやインストールの動作記録を残すが、それらの解析や分析を行うためのレポーティング・ツールは提供していない。WUSは、管理対象コンピュータごとにどのソフトウェア更新プログラムが必要で、どれがインストールされているかを管理者が調べられるステータス・レポート機能を提供し、管理者のシステム監視を支援する。管理者はパッチ適用システムをトラブルシューティングする場合には、各管理対象コンピュータについて、更新プログラムのダウンロード状態や、再起動を待っているかどうかなど、きめ細かなステータス情報も入手できる。企業全体のソフトウェア更新状況の要約レポートは入手できないほか、WUSのレポートは、管理者以外の人が見られるようにイントラネット・サイトに公開することができない。このため、サードパーティのアドオンを導入しなければ、ヘルプデスク担当者やビジネス・マネージャにステータス情報を提供するのは難しい。WUSサーバはSUSと同様に、WANトポロジでのパフォーマンスを向上させ、スケーラビリティを高めるために階層的に構成できる。ステータス情報は親WUSサーバに送られない。複数のWUSサーバを運用する企業では、管理者はシステム全体についての単一で包括的なレポートは入手できず、そうした情報を得るには、複数のWUSサーバに手動で接続しなければならない。WUSのリリース時には、報告データをエクスポートして包括的なレポートに集約するプロセスを自動化する方法を示すサンプル・スクリプトが管理者向けに提供される。この自動化機能は製品本体には統合されない。2005(MOM2005)用管理パックを提供すると表明している。WUSの変更点(2):対象設定が可能にWUSでは、SUSとは異なり、WUSで定義したコンピュータ・グループに基づいて、ソフトウェア更新を一部のコンピュータを対象に承認できる。この機能は特にテストを行ううえで便利だ。テストの際には、管理者はソフトウェア更新プログラムのインストール先をテスト用のコンピュータ群に限定したいからだ。WUSでは、一般に更新承認の設定が異なるサーバとワークステーションとを手動で分けることもできる。SMSとは異なり、WUSの対象設定システムはかなり単純なものだ。Directoryのコンピュータ・グループを利用しておらず、コンピュータは一度に1つのWUSグループにしか所属できない。WUSのグループ割り当ては動的ではなく、クライアントの属性、例えばサーバかワークステーションかといった属性などに基づいている。管理者はWUSサーバからコンピュータをグループに手動で割り当てるか、グループ・ポリシーやローカル・ポリシー、レジストリを編集してWUエージェントにグループ名を設定しなければならない。WUSの変更点(3):より柔軟な承認/発行オプションSUSの承認メカニズムは、ソフトウェア更新プログラムごとにシンプルなチェック・ボックスが用意され、チェックされた更新プログラムが、SUSサーバでカバーされるすべての適用可能なコンピュータにインストールされるというものだが、WUSはさまざまな承認オプションをサポートする。管理者は前述したように対象グループを設定できるだけでなく、ソフトウェア更新プログラムについて「検出のみ」と指定することで、更新プログラムをインストールせずに、適用可能なコンピュータの一覧を入手できる。管理者は「期日付きインストール」と指定して、ソフトウェア更新プログラムをWUエージェントにダウンロードし、ユーザーが期日までの都合の良いときにインストールできるようにすることもできる。ユーザーが更新プログラムをインストールせずに期日になると、WUエージェントが自動的にインストールする。WUS管理者は、ロールバックをサポートするように開発されたソフトウェア更新プログラムについては、インストール後にロールバックを行うこともできる(Microsoftは将来的に、すべてのソフトウェア更新プログラムでインストールを取り消せるようにする計画だ)。管理者はまた、より新しい更新プログラムで代替された更新プログラムを自動的に拒否することができ、承認がその分簡単になる。企業はWUSでサポートするソフトウェア更新プログラムやプラットフォームの種類を絞ることができる。これにより、ストレージやネットワークの要件が管理しやすくなり、検討が必要な更新プログラムの数が少なくなる。2000用更新プログラムに関連するオーバーヘッドを避けることができる。WUSの変更点(4):ネットワークが整備されていない場合のサポートリモート・オフィスが社内ネットワークに接続されていない場合や、広帯域のWANでインターネットに接続されていない場合には、企業はCDやDVDなどのリムーバブル・ディスクを使って、承認データやダウンロードしたソフトウェア更新プログラムのファイルを中央のWUSサーバからリモート・サイトのWUSサーバに移すことができる。このプロセスでは、ソースとなるWUSサーバからデータをエクスポートしてリモートWUSサーバにインポートするのに数段階の手作業が必要になる。このプロセスは、在宅勤務者向けのソフトウェア更新用CDを作る手段としては想定されていない。それでも、これはこうしたシナリオをまったくサポートしていないSUSからの改善点だ。SP4以降が稼働するコンピュータ用のWUエージェントは、WUSサーバに接続して適用すべき新規のソフトウェア更新プログラムの有無を検索し、ローカル・ファイル・システムとレジストリをスキャンして必要なソフトウェア更新を調べる。次に、承認されたソフトウェア更新プログラムをWUSサーバからダウンロードし、各ソフトウェア更新プログラムが求めるインストール・テクノロジを用いてインストールする。最後に、ステータス情報をWUSサーバに返信し、必要に応じて再起動を実行する。SUSと同様、管理者はクライアントがWUSから適用および承認データを取得し、その後、更新ファイルをMicrosoftから直接ダウンロードするように設定できる。このような更新方法は、クライアントからインターネット接続するための帯域幅は広いが、WUSサーバとの帯域幅は限られているような場合には便利である。SP2のものと同じ)。v5の次バージョンとなる最新版のベータ・テストを開始した。詳細はMicrosoftの解説ページ[英文]を参照)。2.0WUエージェントは、ソフトウェア更新プログラムに必要なファイルを完全ダウンロードする代替手段として、バイナリ・デルタ圧縮をサポートしている。これにより、クライアントはファイルの変更部分だけをダウンロードして、新しいパーツのみを既存ファイルにマージできる。その結果、WUエージェントとファイル・ソース(MicrosoftまたはWUSサーバ)間のトラフィックは劇的に緩和される。各クライアントから要求されるデータが少なくなるため、サーバはより多くのクライアントに同時に対応できる。WUSでバイナリ・デルタ圧縮を使用する際にはトレード・オフがある。files)」と呼ばれるソース・ファイルは、従来のソフトウェア更新プログラムの約3倍の容量がある。従って、より大容量のローカル・ストレージが必要になり、各WUSサーバとそのアップストリーム・データ・ソース(Microsoftまたは別のWUSサーバ)間のリンクはファイル転送のためのトラフィックが増大することになる。Service(BITS)のバージョン2.0が必要だ。BITSはHTTPベースのファイル転送テクノロジであり、ユーザーがネットワークから切断されても中断されたファイル転送をその中断個所から復帰できるチェックポイント機能を持っている。BITSは、ネットワーク利用をほかのネットワーク・アダプタのトラフィックに基づいて調節できるため、ネットワーク帯域幅が狭く、接続が断続的なリモート・ユーザーがソフトウェア更新ファイルをバックグラウンドでダウンロードするのに特に適している。3.0が存在しない場合はそれをインストールする。Installerがインストールしたすべてのアプリケーションの更新は、それに依存することになる。3.0は更新ロールバックをサポートし、アプリケーション開発者がより小型のパッチ・ファイルを公開できるようにする。3.0を徹底解剖」を参照)。WUエージェントはさらに、クライアントによる更新のチェック頻度を効率よく管理し、システムのシャットダウン時のみ更新をインストールするオプションを用意する。強制リブートの実行までにユーザーに与える猶予を管理者が設定することもできる。これらの設定オプションはすべてマシン単位であり、更新プログラム単位でコントロールすることはできない。これらWUエージェント側の改良により、必要な帯域幅とダウンロード時間は削減されるが、クライアントは依然としてMicrosoftのサイトまたはWUSサーバという単一の更新ソースでカバーされる。この手順は固定されたワークステーションやサーバにはよいが、WUはクライアントの現在のロケーションと利用可能な帯域幅に合わせて、効率的なソフトウェア更新ファイルのソースを識別することはできないので、ローミングを行うラップトップ・ユーザーにとって理想的ではない。Updateと名称が変更される。Updateサイトの統一的な更新サイトへの統合を反映したものである。2003の検出と更新をサポートする。いずれはすべてのMicrosoft製品の更新をサポートするようになる予定だ。Updateは、パッチやサービスパックだけでなく、開発キット、デバイス・ドライバ、機能パック、ガイダンス・キット、ツール、更新ロールアップ、ノンクリティカルな更新、さまざまなMicrosoft製品をリンクするコネクタなど、多くのものを含む予定だ。Updateのサイトから配布できるようにすることができる。InstallerとWindowsコンポーネント用のUpdate.exeインストーラ・エンジンの2つに削減する意向を発表した。Updateの運用が開始されるころには、この目標にかなり近づくとしている。この2つのインストーラに標準化されることで、Microsoftやほかの管理ツール・ベンダは、システム管理者が管理しやすい更新ソリューションを容易に開発できるようになる。一貫性のあるインストール・スイッチを用いて、標準フォーマットのインストール・ログを標準のファイル・ディレクトリに記述できるようになる。SUSからWUSへの移行の課題WUSは機能的にはSUSに似ているが、まったく異なる基盤テクノロジを採用しているので、WUSをSUSサーバにインストールしても更新されることはなく、両製品が並列してインストールされることになる。WUSにはコマンドラインの移行ツールが付属し、管理者はこれを用いてソフトウェア更新の承認とダウンロード済みソフトウェア更新プログラムをSUSからWUSへと移行できる。この2段階のエクスポート/インポート・プロセスはネットワークでも行えるので、同一マシンまたは別のマシンに新規インストールしたWUSサーバを既存のSUSサーバを用いて更新できる。単一のSUSサーバ、または階層的に配置されていない複数のSUSサーバを利用している組織は、承認とソフトウェア更新データをエクスポートし、SUSをアンインストールする。次にWUSを既存サーバにインストールし、移行した(エクスポートした)データをインポートする。UpdateおよびBITSバージョンに自動的に更新する。組織が異なるコンピュータ名で新たなサーバを使用する場合はさらに、代替サーバのURLでアクセスできるように、クライアントを再設定する必要がある。SUSおよびWUSサーバは単一の階層に混在させることができないので、階層的なSUSシステムの移行はさらに複雑だ。Webサービスとのみ同期ができる。SUSおよびWUS階層システムを、段階的に移行させる場合は並列で稼働させておく必要があるだろう。標準的なHTTPのポート80番の代わりにカスタム・ポート番号を使用するように設定して、SUSとWUSサーバを同じコンピュータ上で稼働させることもできる。(2017/7/21)キーボード配列が異なる言語に誤認識された場合の対処方法を紹介。