|
細かい改良点は数え切れないほどだが、現状のWindows
2000と比較したWindows .NET Serverの最大の変更点は、XML
Webサービス・サポート(.NET Frameworkの標準サポート)、Active
Directoryの改良、Internet Information Services(IIS)の改良の3つだろう(ベータ3レベルでのWindows
.NET Serverの機能改良ポイントの詳細については別稿「Insider's
Eye:Windows .NET Serverベータ3の概要」を参照)。
■XML Webサービス・サポート
Windows .NET Serverという名称が付けられたことからも分かるとおり、Windows .NET Serverの大きな目標の1つは、マイクロソフトが提唱するMicrosoft
.NETの普及に向けて、そのサーバ・サイド・ソフトウェアとして機能することである。このためWindows .NET Serverでは、.NET Frameworkが標準でシステムに組み込まれ、これをベースとするXML
WebサービスやWebアプリケーション、Windowsアプリケーションを追加ソフトウェアなしで実行可能になる(現状のWindows 2000では、マイクロソフトから提供されている.NET
Framework再配布パッケージを別途インストールする必要がある。再配布パッケージのダウンロード・サイト)。
なおこれに関連して、メッセージ・システムをサポートするMicrosoft Message Queueが強化され、SOAPフォーマットのメッセージが取り扱い可能になった。またCOM+と.NET
Frameworkが統合され、COM+オブジェクトのメソッドをXML Webサービスとして公開できるようになった。
■Active Directoryの改良
既存のWindows 2000のActive Directoryでは、いったんドメイン・コントローラ(DC)を構成してしまうと、容易にドメイン名を変更できない、フォレストの構成を変更できないなど、インストールや管理面での制限が少なくなかった。これに対しWindows
.NET ServerのActive Directoryでは、ドメインの展開や運用を効率的かつ柔軟に行えるようにさまざまな改良が加えられている。
ネットワーク管理者にとって最も便利なツールの1つは、DCの情報の移行を支援するアップグレード・ウィザードだろう。このウィザードを使えば、DCに格納されている各種情報をリムーバブル・ストレージ(CD-Rなど)にいったん書き出し、別の環境でこの情報を書き戻すなどが可能になる。
Windows .NET ServerのActive Directoryでは、フォレスト内のドメイン(ルート・ドメイン以外)の名称変更や、フォレスト間での信頼関係の構築などが可能になっている。
■Internet Information Services 6.0
周知のとおり、昨年(2001年)はIIS 5.0のセキュリティ・ホールなどを突いて感染を広げるコンピュータ・ワームのCode
RedやNimdaが深刻な社会問題にまで発展した(Code RedやNimdaの詳細はそれぞれ「Insider's
Eye:Code Redワームの正体とその対策」「Insider's
Eye:ネットを震撼させたコンピュータ・ワーム、Nimdaを検証する」を参照)。問題がここまで深刻化したのは、逆にいえば、IISを使ってインターネット向けのWebサーバを公開しているユーザーがそれだけ大勢いたということだ。Windows
2000 Serverに標準搭載されており、手軽で高機能であることから、利用者が多かったのだと思われる。しかしこれらのワーム事件は、少なくとも企業が安心して使えるWebサーバという意味では、その信用に大きく傷をつけたことは疑いがない。
WebサーバであるIISは、XML WebサービスやWebアプリケーションといった.NET環境の普及を図るうえで、その中枢を担う基幹ソフトウェアの1つである。そのIISを信用して使えないというのでは、.NETの普及もままならない。このためWindows
.NET Serverに組み込まれるIISは、IIS 5.0からIIS 6.0へとメジャー・バージョンアップされ、セキュリティや信頼性に関する機能が大幅に強化されている。
まずIIS 6.0では、デフォルトでは各種の拡張機能が無効化された状態(ロック・ダウンされた状態)になる。従ってIIS 6.0によりWebサーバを稼働させるには、必要な機能を管理者が明示的に有効化(アンロック)する必要がある。
IIS 6.0では、Webアプリケーションなどを安全かつ効率よく実行するために、ワーカー・プロセスを完全に独立して実行、管理できるようになった。これにより例えば、特定のワーカー・プロセスが動作不良を起こしても、ほかの正常なプロセスに影響を及ぼすことなく、問題のプロセスだけを停止し、代替プロセスを起動するなどが可能になる。IIS
6.0にはこのためのヘルス・モニタリング機能が搭載されており、定期的にプロセスの応答を検査して、プロセスの状態をモニタすることができる。
マイクロソフトは、自社ソフトウェアにセキュリティ・ホールやバグが見つかった場合には、積極的に情報開示を行い、その問題を解消するためのHotfix(パッチ・モジュール)などを提供している。くだんのCode
RedやNimdaによって悪用されたセキュリティ・ホールも、実際には、感染が広がる以前に公開されていたHotfixによって修復可能だった。つまり、タイムリーにHotfixを適用していれば、Code
RedやNimdaの感染を防ぐことができたわけだ。
しかし現状では、Hotfixを適用するには、ユーザー自身でモジュールをダウンロードし、システムに適用する必要がある(そして基本的に、Hotfixの適用後はシステムの再起動が必要)。現実問題として、時間に追われる管理者にとっては、タイムリーなHotfixマネジメントは望みにくい状態だった。
これに対してIIS 6.0には自動更新の機能が追加され、重要なHotfixのダウンロードと適用をスケジュールできるようになった。この際、サービスの中断が不要なHotfixについては、Webサーバ・サービスを中断することなく(つまり稼働状態を維持したまま)、Hotfixのダウンロードと適用を実行できる。一方、サービスの停止を伴うHotfixについては、ダウンロードを先行して実行しておき、適用は別途スケジュールできるようになっている。
|