9 月号 2008 9 月号 2008
ISA Server: ISA Server 2006 のセキュリティ保護ガイド
多くの組織が、環境の保護に ISA Server 2006 を利用していますが、ISA Server 自体のセキュリティを確保するという重要な対策を講じている組織はほとんどありません。ここでは、セキュリティの構成ウィザードと管理に関する役割を使用して、攻撃対象領域を制限し、ISA Server 2006 のセキュリティを確保するガイドを提供します。 Alan Maddison
ISA Server: ISA Server 2006 を使用して TS ゲートウェイのセキュリティを強化する
Windows Server 2008 では、新しい TS ゲートウェイ機能を使用することで、VPN を使用せずに、ユーザーがどこからでも各自のデスクトップにアクセスできるようになります。この記事では、ISA Server 2006 経由で TS ゲートウェイを公開する方法と、この ISA Server 2006 による公開シナリオを拡張してクライアントの正常性の強制を実装する方法について説明します。 Thomas W. Shinder および Yuri Diogenes
IIS 7.0: IIS 7.0 のパフォーマンス向上機能トップ 10
IIS の最新リリースである IIS 7.0 では、一般的な開発シナリオと管理シナリオをサポートするのにより適した、モジュール型の拡張可能なプラットフォームを導入し、大幅なパフォーマンス向上を可能にしています。この記事では、このようなパフォーマンス向上を実現する IIS 7.0 の主要な 10 個の機能について説明します。 Mike Volodarsky
モビリティ: 基幹業務アプリケーションをモバイルで使用できるようにする
現在、多くのモバイル ワーカーは、オフィスで使用している基幹業務アプリケーション (CRM、ERP など) に、現場でモバイル デバイスからアクセスできる必要があります。この記事では、Windows Mobile と Mobile Device Manager を使用して、重要な基幹業務アプリケーションに対応した豊富なモバイル機能をどのように展開できるかについて説明します。 Matt Fontaine
セキュリティ: 共有アカウントのパスワード管理について
特権アカウントのパスワードを共有することは珍しくありませんが、このようなパスワードを適切に管理できていない組織は数多く存在します。その結果、深刻なセキュリティ上の問題が発生します。この記事では、共有している特権アカウントにまつわる危険と、より強力なセキュリティで保護されたパスワードを管理するより良い方法を紹介します。 Chris Stoneff
Columns
編集長から: 新学期: | レター: 読者の皆さんからの声: | ツールボックス: IT プロフェッショナル向けの新製品:
Exchange Queue & A: ディスク パーティションの配置、SCR の計画など: 2008 年 9 月号の Exchange Queue & A コラムでは、必要なグローバル カタログ サーバーの数の計算、サーバーのサイト メンバシップの変更などの質問にお答えします。Henrik Walther | ユーティリティ スポットライト: Windows Memory Diagnostic: このコラムでは、無償のユーティリティを使用して、Windows の実行中に発生した問題がメモリの問題に起因するかどうかを確認する方法について説明します。Lance Whitney | SharePoint の内部: SharePoint のディレクトリ統合: Pav Cherny が、SharePoint に組み込まれている Directory Management Service の制限事項について説明します。また、このコンポーネントを、SharePoint の受信者情報とその他のディレクトリ ソリューションとを同期できる、カスタム ソリューションに置き換える方法について説明します。Pav Cherny
Windows PowerShell: 文字列理論: Windows PowerShell にはオブジェクト指向という性質がありますが、Windows PowerShell を使用して複雑な文字列を解析することもできます。Don Jones が、Select-String を使用して Windows PowerShell で複雑な文字列を解析する方法について説明します。Don Jones | Hey, Scripting Guy!: トースターと常時連絡を取れるようにする: 仮想データベース テーブルとも言える切断されたレコードセットを使用して、データの分類と大きなデータ セットを処理する際の VBScript の制限に対処する方法を紹介します。Microsoft Scripting Guys | デスクトップ ファイル: WDS の高度な機能: Windows Deployment Services に関する 3 回目のコラムでは、パフォーマンスとスケーラビリティ、ログ記録、およびコマンド ラインによる自動化を強化する機能を紹介します。Wes Miller
セキュリティ ウォッチ: パスワードとクレジット カード、第 3 部: 3 回シリーズの最終回では、Jesper Johansson が、ソフトウェア ベンダ、セキュリティ スイート、およびマーケティング活動によって真のセキュリティ向上が妨げられる状況について説明し、このような慣習によってテクノロジのセキュリティ エコシステムの崩壊がもたらされる可能性について警告します。Jesper M. Johansson | フィールド ノート: 内部改革: Romi Mahajan が "内部改革" の理論を説明します。この理論では、比較優位を維持する鍵として、従業員の創造性と資本の両方を重視しています。Romi Mahajan | Windows 秘話: 電源が入っていない Windows 95: Raymond Chen が、ささいな診断コードが原因で Windows 95 のビルド速度が突然遅くなった経緯について説明します。Raymond Chen


ISA Server 2006 のセキュリティ保護ガイド
Alan Maddison
概要 :
  • サーバーのセキュリティ保護のベスト プラクティス
  • セキュリティの構成ウィザードのセットアップ
  • セキュリティの構成ウィザードのチュートリアル
  • 管理に関する役割の割り当て

目次
サーバーのセキュリティを確保する
セキュリティの構成ウィザードをセットアップする
SCW を実行する
管理に関する役割
多くの IT プロフェッショナルが、テクノロジ資産の保護に ISA Server 2006 (Internet Security and Acceleration Server 2006) を利用していますが、さらに ISA Server 自体のセキュリティを確保している人はほとんどいません。最近
ISA Server 2006 をインストールした方であれば、インストールが完了した直後に ISA Server を保護するメッセージが表示されたことを覚えていらっしゃるかもしれません。残念ながら、私たち IT プロフェッショナルの多くは、時間を割いて (または時間がないために) この重要な作業を実行することはほとんどなく、この作業は結局は決して実行されることのないやるべきことの 1 つになるだけです。
現在の常に変化するセキュリティ情勢では、このように ISA Server のセキュリティ保護を怠ることはもはや許されません。さいわい、ISA Server のセキュリティ保護に使用されるツールは、大きな進化を遂げています。ISA Server 2004 以前のバージョンで提供されていたセキュリティ強化ウィザードの持つ課題の多くに取り組む必要はなくなりました。Windows Server® 2003 に付属のセキュリティの構成ウィザード (SCW) など、洗練された手順やツールを利用できます。
この記事では、サーバー保護の一般的なベスト プラクティスについて簡単に説明します。また、ISA Server 自体のセキュリティ保護戦略を順を追って説明します。ここでは、セキュリティの構成ウィザードを使用して ISA Server の攻撃対象領域を縮小し、管理に関する役割を使用して ISA Server へのアクセスを制限します。

サーバーのセキュリティを確保する
サーバーがデータセンターに置かれていようと、オフィスの隣のサーバー ルームに置かれていようと、サーバーのセキュリティ保護については、多くの要素とベスト プラクティスがあります。管理者の責任として、これらのベスト プラクティスがどのようなものかを理解し、各組織にとって現実的な方法でこれらの要件を実装するよう尽力する必要があります。ここ数年、セキュリティの重要性が広く認められるようになるにつれ、管理者の多くは、このような要件の中核をなす作業にかなり精通してきていますから、ここでは詳細な説明ではなく、簡潔に概要のみを示します。
環境のセキュリティを確保するために最初に実行する必要がある作業は、サーバーを物理的に安全な状態にすることです。つまり、具体的に言うと、サーバーへの物理的なアクセスを制限します。小規模環境では、サーバー ルームのドアを常に施錠し、サーバー ルームに出入りできるスタッフはごく少数に限るようにします。大規模環境でも、上記の基本要件はほぼ変わりありませんが、より洗練された方法で実装されるでしょう。たとえば、多くの組織では電子監視を採用しています。これにより、サーバーの設置場所への出入りを監査できるだけでなく、職務構造に応じて、個々のラックやケージへのアクセスを制限することさえできます。
ISA Server または ISA 構成保管サーバーの盗難や物理的な侵害に対処する際は、いくつか考慮すべき独自の要素があります。盗まれたサーバーから入手できる情報の性質を考えると、環境内のすべての ISA Server とトラフィック (暗号化されたトラフィックも含む) が侵害される可能性があります。
サーバーが侵害や盗難などの被害を受けている可能性がある場合は、この被害を受けたサーバーがまだ設置場所にある場合はこれを直ちに隔離し、証拠を保存するための標準の手順に従ってください。これらの必要な手順を実行したら、すべての機密情報を変更するプロセスに着手する必要があります。問題のサーバー上にインストールされているすべての証明書を失効し、すべての事前共有キーと共有シークレットを変更してください。また、レプリカの構成保管サーバーを保持している場合は、必ず問題のサーバーに関連するデータを削除します。
サーバーの物理的安全を確保できたら、次は、仮想化層、OS、およびアプリケーションを含め、すべてのソフトウェアに修正プログラムを適用するための体系的な方法を用意します。修正プログラムと更新プログラムは、定期的に確認し、適用する必要があります。ただし、運用システムにこのような更新プログラムを適用する前に、忘れずにこれらをテストしてください。修正プログラムによって、アプリケーションやデータの整合性に影響する問題が起きるのであれば、適用するメリットはありません。
データの整合性が損なわれた場合は、バックアップを利用しなければならなくなります。これは、インフラストラクチャの保護に関するまた別の主要な要素につながります。必要な状況が発生した場合にデータをすばやく完全に復元できないと、ダウンタイムにより作業に大きな影響が出て、その結果、侵害による被害額が増加します。
他に考慮すべき 2 つの要素は、監視と監査です。優れたセキュリティの計画を確立するには、アプリケーションとシステムの監視が不可欠です。ログ、特にセキュリティ関連のログの確認を怠ると、実際に被害をこうむるまで、侵害が試みられていることに気付くことはないでしょう。
同様に、監査も欠かせません。多くの組織、特に大規模環境では、監査を行うことが多くの場合規定されているか、法律によって義務付けられいることさえあります。いずれにせよ、どのような環境であっても、取り組みが有効なものになるよう、資産保護の方法と統制状況を定期的に見直すことが重要です。
また、ISA Server 2006 は Windows Server® 2003 上で実行されるため、『Windows Server 2003 セキュリティ ガイド』を確認して、必要な推奨作業を実行することも重要です。『Windows Server 2003 セキュリティ ガイド』については、microsoft.com/technet/security/prodtech/windowsserver2003/w2003hg/sgch00.mspx を参照してください。
マイクロソフトでは、現在、Baseline Security Policy テンプレートの実装を推奨していますが、インターネット プロトコル セキュリティ (IPsec) フィルタは実装しないでください。

セキュリティの構成ウィザードをセットアップする
では、ISA Server 自体のセキュリティを強化するにはどうしたらよいでしょうか。ISA のセキュリティ保護に使用する基本のツールは、セキュリティの構成ウィザード (SCW) です。これは、攻撃対象領域を縮小するツールです。SCW は、サーバーのサービス、ネットワーク セキュリティ、レジストリ、および監査ポリシーを対象とするセキュリティ ポリシーを作成し、必要なサービスと機能のみが使用されるようにシステムを構成します。使用する ISA Server サービスのみを構成する必要があることに留意してください。たとえば、Web プロキシ サービスは既定では有効になっていますが、この機能を使用しない場合は無効にします。したがって、SCW が提供する構成オプションには十分に注意する必要があります。
SCW は Windows Server 2003 では既定でインストールされないため、まず、コントロール パネルのプログラムの追加と削除の [Windows® コンポーネントの追加と削除] を使用して、手動で SCW をインストールしてください (SCW は、Windows Server 2008 では既定でインストールされます)。[Windows コンポーネントの追加と削除] の画面が読み込まれたら、スクロールして、SCW のチェック ボックスをオンにします。
インストールが完了すると、SCW は [管理ツール] の下に表示されます。SCW の使用を開始する前に、ISA Server 2006 用の更新プログラム (go.microsoft.com/fwlink/?LinkId=122532) をダウンロードして、SCW を更新する必要があります。この更新プログラムは、ISA Server 2006 Standard Edition、ISA Server 2006 Enterprise Edition、および ISA Server 構成保管サーバー用の役割を追加するものです。
更新プログラムをダウンロードしたら、パッケージを実行してファイルを展開する必要があります。ファイルを展開したら、2 つの .xml ファイル (isa.xml と isaloc.xml) を SCW 用の kbs フォルダにコピーします。これは、Windows Server の既定のインストールでは、c:\windows\security\msscw\kbs です。
ファイルをコピーするときに、同じ名前の既存の 2 ファイルを上書きするかどうかを確認するメッセージが表示されます。この 2 ファイルは ISA Server 2004 用のファイルなので、上書きする前にバックアップを作成してください。最後に、isascwhlp.dll ファイルを bin フォルダにコピーします。このフォルダの場所は、通常 c:\windows\security\msscw\bin です。SCW への ISA の役割の追加が完了したら、インストールを開始できます。
マイクロソフトでは、基本的に、ISA Server の構成が完了した時点でのみ、SCW を実行することを推奨しています。Enterprise Edition を実行している場合、これにはすべてのアレイとすべてのアレイ メンバの構成も含まれます。

SCW を実行する
まず、[管理ツール] から SCW を起動します。SCW プロセスを正常に完了するには、管理アクセス許可が必要なことに注意してください。
図 1 は、このウィザードの最初の画面を示しています。この画面上のテキスト、特に「このウィザードでは、このサーバーによってリッスンされる受信ポートが検出されます」という警告のテキストを読むと、なぜこのプロセスを開始する前に、ISA Server とアレイを完全に構成しておくことが重要であるかがわかります。
図 1 セキュリティの構成ウィザードの開始画面 (画像をクリックすると拡大表示されます)
環境を完全に構成していないと、ISA 構成を完了した後に、高い確率で SCW の構成を変更し直さなければならなくなります。次の画面 (図 2) では、実行する作業を指定します。ここでは、[新しいセキュリティ ポリシーの作成] を選択します。
図 2 新しいセキュリティ ポリシーの作成 (画像をクリックすると拡大表示されます)
次は、ポリシーのベースラインとなるサーバーを選択するよう指示されます。新しいポリシーを作成しているので、既定では SCW を実行しているコンピュータを使用する選択になっています。ただし、この動作は、前の画面で実行するよう選択した作業に応じて変わります。いずれにせよ、ベスト プラクティスとしては、ベースラインに使用するサーバー上に SCW をインストールしておくことをお勧めします。SCW が対象サーバーにインストールされていないと、ポリシーの作成に使用した情報が失われます。したがって、スムーズに作業を終えられるように、SCW はベースラインとするサーバーにインストールして実行してください。
[次へ] をクリックすると、SCW が ISA Server の分析を開始します。この分析では、サーバー上にインストールされている役割、サーバー上にインストールされることが予想される役割、インストールされているサービス、および基本ネットワーク情報が特定されます。処理が完了すると、[構成データベースの表示] をクリックしてデータベースを表示できます。構成データベースには、サポートされるすべてのサーバーの役割、クライアント機能、ポートなど、さまざまな情報が保持されています。
次に、SCW では、役割に基づくサービスの構成手順が開始されます。[次へ] をクリックすると次の画面が表示され、この画面ではサーバーの役割を選択します (図 3 参照)。SCW が実行する初期スキャンの信頼性は高く、正しいサーバーの役割が既に指定されていると思われます。ただし、再度確認して、不要な役割は削除することが非常に重要です。サーバーが複数の役割を実行する場合は、適切な役割がすべて選択されていることを確認してください。
図 3 サーバーの役割の指定 (画像をクリックすると拡大表示されます)
ISA Server 2006 Enterprise Edition を実行している場合に注意する点は、構成保管サーバーについて考慮が必要なことです。構成保管サーバーが ISA Server としても機能するサーバー上にインストールされている場合 (なお、これは推奨されるベスト プラクティスではありませんが、このように構成されることがよくあります)、構成保管サーバーの役割も選択する必要があります。実際には ISA Server 2006 の役割しかないサーバーに対しては、この 2 つの役割をホストするサーバーのベースライン スキャンは使用しないでください。
次は、サーバーのクライアント機能を選択します。つまり、サーバーが必要とするサービスを指定する必要があります。たとえば、ほとんどのサーバーは DNS クライアントを必要としますが、サーバーがドメインのメンバであった場合は、ドメイン メンバ機能が必要です。
この作業が済むと、[管理とその他のオプション] 画面が表示されます。ここでは、サービスを使用するかネットワーク接続を利用するアプリケーション、管理、およびオペレーティング システムのオプションを指定します。ここで選択されていないサービスは、無効になります。ただし、オプションを選択し [次へ] をクリックすると、許可する追加のサービスを選択できるオプションが提供されます。
次に、指定されていないサービスをどのように扱うかを構成します。ここでは、ポリシーの適用時に、メイン データベースに含まれていないか、ベースライン サーバーにインストールされていないサービスが見つかった場合に実行する動作を定義できます。一般的なベスト プラクティスとしては、予測できない攻撃要因を制限するため、不明なサービスは無効にすることをお勧めします。ただし残念ながら、このオプションを選択した場合、サーバー間になんらかの形で差異があると、悪い結果を招く可能性があります。また、将来アプリケーションまたはネットワーク サービスを追加する場合も、この設定について注意が必要です。
ウィザードの次のセクション (図 4) では、SCW によって変更されるサービスを確認できます。この構成画面では、サービスの現在の状態と、ポリシーが適用された後の変更後の状態を比較できます。
図 4 サービスの変更の確認 (画像をクリックすると拡大表示されます)
変更されるサービスを確認したら、[ネットワーク セキュリティ] のセクションに進みます。ここでは、通常、Windows ファイアウォールと IPsec の設定を変更します。ただし、ISA Server 2006 を構成しているので、このセクションは省略します (図 5 参照)。
図 5 ネットワーク セキュリティの設定の省略 (画像をクリックすると拡大表示されます)
次は、ネットワーク認証方法とセキュリティに関するレジストリ設定の構成に進みます。このセクションの最初の画面は、サーバー メッセージ ブロック (SMB) 署名に関する画面です。SMB プロトコルは、マイクロソフトの主要ネットワーク プロトコルの 1 つで、この画面の設定により、man-in-the-middle 攻撃の可能性を縮小するために、署名付きの通信が可能になります。
既定の設定 (図 6) でも、ISA Server SMB 通信に対して適度なセキュリティが得られます。ただし、すべての通信に署名することによる影響を考慮する必要があります。CPU サイクルに余裕がない場合、2 つ目のチェック ボックスはオフにしてください。また、忘れずに、このポリシーを適用するすべてのサーバーについて考慮してください。サーバーのワークロードが異なっている場合、このチェック ボックスをオンにするかどうかの判断基準には、CPU 使用率の最も高いサーバーを使用する必要があります。
図 6 署名付きの通信を必要とするかどうかの指定 (画像をクリックすると拡大表示されます)
次の一連の画面では、ISA Server が使用する LMCompatibility レベルを構成します。最初の画面では、3 種類の選択肢が表示されます。レガシ Windows クライアント (Windows 95 または Windows 98 など) が展開されているか、アクセス制御にローカル アカウントを使用していない限り、既定で選択されている [ドメイン アカウント] をそのまま使用してください。
2 番目の画面は LMCompatibility のレベルを構成する画面で、ドメイン コントローラについての情報を指定します。Windows NT® 4.0 ドメインを展開していない場合は、既定の指定 (Windows NT 4.0 Service Pack 6a 以降の OS) をそのまま使用してください。このダイアログ ボックスでは、選択されたサーバーの時計と時計を同期するオプションも選択してください。[次へ] をクリックすると、LAN Manager (LM) の受信通信について、追加の構成オプションが表示されます (図 7 参照)。
図 7 受信認証方法の指定 (画像をクリックすると拡大表示されます)
この LMCompatibility レベルに関する 3 番目の画面では、Windows NT LAN Manager (NTLM) Version 2 を必要とするかどうかと LM ハッシュを維持するかどうかを指定します。環境がこの構成をサポートする場合、この 2 つのオプションを選択しないことでセキュリティが大幅に向上するため、この 2 つのオプションはどちらも選択しないでください。次に、[レジストリ設定の概要] が表示されます。各項目を見直し、ポリシー設定が正しいことを確認してください。
次は、ウィザードの最後のセクションである監査に進みます。このセクションで行う構成は、どの構成もロール バックできないことに注意してください。ただし、監査はシステムの機能には影響しないため、このセクションは省略しないようにしてください。
既定では [成功のアクティビティを監査する] が選択されていますが、これではログオンの失敗に対するイベント ログ エントリは作成されません。しかし、ログオンの失敗についての情報は、侵入の試みについて貴重な情報を提供できます。したがって、一般的なベスト プラクティスとしては、[成功と失敗のアクティビティを監査する] を選択することをお勧めします。
次に、監査の構成を確認し、[次へ] を 2 回クリックしてセキュリティ ポリシーを保存します。この画面 (図 8) に表示されるのはファイル名のみですが、簡単な説明を追加することもできます。この説明は、複数の管理者がセキュリティ関連の業務を担当している大規模な環境では、役立つ可能性があります。
図 8 セキュリティ ポリシーの名前と説明の指定 (画像をクリックすると拡大表示されます)
最終構成が保存されると、ポリシーを直ちに適用するか、後で適用するかを指定するオプションが表示されます。ポリシーを後で適用する場合は、プロセスは完了です。ポリシー構成に誤りを見つけた場合は、監査の設定を除き、ポリシーをロール バックできます。

管理に関する役割
ISA Server の攻撃対象領域を縮小することは、外部ソースからの侵害の可能性を縮小するうえで欠かせない作業です。ただし、ISA Server 内の管理に関する役割の割り当てを確認して、内部ソースからの侵害の可能性を制限することも重要です。管理に関する役割および関連付けられている一般的なタスクの一部を、図 9 および 10 に示します。
図 9 Standard Edition の役割と関連付けられているタスク
タスク | 監視監査者 | 監査者 | 管理者 (完全)
ダッシュボード、警告、接続、セッション、およびサービスの表示 | 可 | 可 | 可
警告の確認 | 可 | 可 | 可
ログ情報の表示 | – | 可 | 可
警告定義の作成 | – | – | 可
レポートの作成 | – | 可 | 可
セッションおよびサービスの停止と開始 | – | 可 | 可
ファイアウォール ポリシーの表示 | – | 可 | 可
ファイアウォール ポリシーの構成 | – | – | 可
キャッシュの構成 | – | – | 可
仮想プライベート ネットワーク (VPN) の構成 | – | – | 可
図 10 Enterprise Edition の役割と関連付けられているタスク
タスク | アレイ監視監査者 | アレイ監査者 | アレイ管理者
ダッシュボード、警告、接続、およびセッションの表示 | 可 | 可 | 可
警告の確認とリセット | 可 | 可 | 可
ログ情報の表示 | – | 可 | 可
警告定義の作成 | – | - | 可
レポートの作成 | – | 可 | 可
セッションおよびサービスの停止と開始 | – | 可 | 可
ファイアウォール ポリシーの表示 | – | 可 | 可
ファイアウォール ポリシーの構成 | – | – | 可
キャッシュの構成 | – | – | 可
仮想プライベート ネットワーク (VPN) の構成 | – | – | 可
NLB の Drain または Stop コマンドの実行 | – | 可 | 可
ローカル構成 (アレイ メンバのレジストリ内) の表示 | – | 可 | 可
ローカル構成 (アレイ メンバのレジストリ内) の変更 | – | – | –
ご覧のように、ISA Server に関連付けられている管理タスクは、かなり細かく分類されています。このため、組織内のユーザーに正しい役割を割り当てることは簡単だと思われます。
また、役割の割り当てに際しては、最小限の特権の概念を採用することが一番適切な方法であることに留意してください。どのユーザーにも、業務を遂行するうえで必要最小限の特権しか付与されないようにします。
また、ISA Server 2006 Standard Edition の Local Administrators グループのメンバは、ISA Server 管理者 (完全) と同じ権利を持つことにも注意してください。Enterprise Edition の場合、構成保管サーバーの役割がインストールされているサーバー上の Local Administrators グループのメンバは、Enterprise 構成を完全に制御できます。つまり、ISA Server がドメインのメンバである場合は、Domain Admins グループと、ISA Server の Local Administrators グループのメンバである他のグループのメンバシップについて、慎重に確認してください。

Alan Maddison は、Brocade 傘下の Strategic Business Systems でマイクロソフト テクノロジを専門とするシニア コンサルタントを務めています。


ISA Server
ISA Server 2006 を使用して TS ゲートウェイのセキュリティを強化する
Thomas W. Shinder および Yuri Diogenes
概要 :
  • TS ゲートウェイと共に ISA Server を使用する 2 つのシナリオ
  • ISA Server 2006 の構成
  • テストと監視

目次
境界を越えて
1 つ目のシナリオ
ISA Server 2006 を構成する
クライアント アクセスをテストおよび監視する
ISA Server から監視する
2 つ目のシナリオ
クライアントについて
まとめ
Exchange Server 2007 の Outlook Anywhere の成功に続き、Windows Server 2008 では、セキュリティ保護と制御が確保された方法で、デスクトップにどこからでもアクセスできる機能を提供しています。
Windows Server® 2008 のターミナル サーバー ゲートウェイ サービス (TS ゲートウェイ) は、Windows® ターミナル サーバー サービスの持つ柔軟性を備えているだけでなく、HTTP 接続を使用してどこからでもターミナル サーバーに接続できる機能を提供しています。このサービスでは、HTTPS (SSL) を経由した RDP (リモート デスクトップ プロトコル) を使用して、セキュリティを強化します。また、ターミナル サービス リソースに一元的にアクセスできるクライアント インターフェイスを提供します。
この新しい TS ゲートウェイ サービスは、コンピュータにリモートからアクセスする必要があるユーザーに、次のような大きなメリットを提供します。
  • RDP を使用して内部リソースに接続する前に、仮想プライベート ネットワーク (VPN) セッションを確立する必要がありません。
  • ネットワーク アクセス保護 (NAP) と Windows セキュリティ正常性チェックを使用して RDP 接続を制御し、セキュリティを強化できます。
  • 受信 TCP ポート 3389 を開く必要がないため、ファイアウォール経由のより安全な Web 公開を実現できます。
Microsoft® Internet Security and Acceleration (ISA) Server 2006 を使用すると、TS ゲートウェイ サービスのセキュリティを強化しながら、内部リソースへの外部アクセスを許可できます。ISA Server 2006 が要求を受信してこれを内部の TS ゲートウェイ サービスに HTTPS を使用して渡すという SSL 間ブリッジ シナリオを設定できます。要求をブリッジするだけでなく、ISA ファイアウォールでは SSL 通信を暗号化し、アプリケーション層の検査を実施します。
HTTP プロトコル ストリームが検査に合格すると、通信は再び暗号化され、ターミナル サービス プロキシに転送されます。プロトコル ストリームが検査に不合格になると、接続は破棄されます。

境界を越えて
マイクロソフトはセキュリティについてこれまで多大な努力をしてきました。Windows Server 2008 は、これまでで最高のセキュリティと堅牢性を備えた Windows です。また、ユーザーが同社の製品を実装する方法と、ユーザーがベスト プラクティスに従って環境を安全な状態に保つことについても、心を砕いています。ベスト プラクティスでは、アクセスの複数ポイント (つまり層) で保護を提供する多層防御型の方法が必要であると規定されています。この記事に関係のある層は、ポリシー、手順、および認識層、境界層、内部ネットワーク層、およびホスト層です。
ISA Server 経由で外部ユーザーが内部リソースにアクセスできるようにするには、関係する各製品の境界を把握する必要があります。境界層のセキュリティについては、ISA Server 2006 と TS ゲートウェイで提供されますが、内部リソースについては、必要に応じてアクセスを許可または拒否するポリシーを用意する必要があります。ネットワーク ポリシーとアクセス サービス (NPAS) を使用すると、これを実現できます。NPAS はポリシー、手順、および認識層で機能します。また、内部ネットワーク層については、内部リソース (ドライブ、クリップボード、プリンタなど) へのアクセスをターミナル サービス リソース承認ポリシーで定義して対応します。
この記事では、まず、ISA Server 2006 経由でターミナル サービス ゲートウェイを公開する方法について説明します。次に、ISA Server 2006 による公開シナリオを拡張して、NAP を使用したクライアントの正常性の強制を実装します。NAP を使用することで、ホスト層レベルでのアクセス制御に役立つクライアント正常性ポリシーを作成できます。

1 つ目のシナリオ
ここでは、ISA Server 2006 経由で TS ゲートウェイを公開する方法を説明します。図 1 は、接続中のコンピュータとデータ フローの概要です。このシナリオでは、TS ゲートウェイ自体にネットワーク ポリシー サーバー (NPS) の役割を実装していますが、2 つ目のシナリオではこれを変更して、セントラル NPS サーバーを使用します。以下の処理の流れを確認して、この TS ゲートウェイ公開ソリューションの各コンポーネント間で、どのように通信が行われるかを理解してください。
図 1 ISA Server 2006 経由の TS ゲートウェイの公開 (画像をクリックすると拡大表示されます)
  1. 外部 RDP ユーザーが接続を開始します。クライアント側でまず実行する必要がある処理は、TS ゲートウェイの外部名 (ここでは tsg.contoso.com) を解決することです。外部 DNS がこの名前を解決し、ISA Server の外部 IP アドレスを提示します。
  2. RDP クライアントと ISA Server の外部インターフェイス間で、SSL トンネルが確立されます。ISA Server には、tsg.contoso.com に対して発行された証明書を使用する、TCP ポート 443 用の Web 公開ルールがあります。
  3. ルールを評価し、トラフィックが許可されることを確認すると、ISA Server は DNS クエリを (ドメイン コントローラにある) 内部 DNS サーバーに送信して、Web 公開ルールに指定されているサーバーの名前を解決します。
  4. 次に ISA Server は、TS ゲートウェイへの SSL トンネルを開き、TS ゲートウェイに認証要求を渡します。
  5. TS ゲートウェイ サーバーがユーザーの資格情報を検証し、ユーザーに接続を確立する資格があることを確認します。
  6. ユーザーに接続を確立する資格があることが確認できると、TS ゲートウェイ サービスは TCP ポート 443 で要求を受信し、RDP パケットを TCP ポート 3389 (既定) 経由でアプリケーション (CRM アプリケーションなど) が配置されている内部のターミナル サーバーに転送します。
これ以降は、この RDP クライアントが ISA Server 経由で TS ゲートウェイに送信するパケットは、すべて内部のターミナル サーバーに転送されます。また、これと逆方向の通信も許可されます。
ここで基盤となる HTTP プロキシを経由した RPC は、RDP/RPC/HTTPS でしかないことに注意してください。RDP クライアントは RDP ヘッダー内に RPC 通信をカプセル化し、これは SSL (またはトランスポート レベルのセキュリティ、TLS) を使用して保護される HTTP ヘッダーを使ってカプセル化されます。HTTP を経由した RPC ソリューションに必要なコンポーネントは、すべて展開されている必要があります。TS ゲートウェイの役割のサービスをインストールすると、HTTP プロキシを経由した RPC が自動的にインストールされるのはこのためです。このプロトコルのしくみの詳細については、ISA Server チームのブログ (blogs.technet.com/isablog) で「Testing RPC over HTTP through ISA Server 2006 Part 1; Protocols, Authentication and Processing」(ISA Server 2006 を使用した HTTP を経由した RPC のテスト第 1 部、プロトコル、認証、および処理) を参照してください。
この実装には、Windows Server 2008 にターミナル サービス ゲートウェイがインストールされている必要があります。また、この機能は、HTTP プロキシを経由した RPC に依存しています。HTTP プロキシを経由した RPC を利用する RDP が機能するには、インターネット インフォメーション サービス (IIS) 7.0 がインストールされ、実行されている必要があります。また、ネットワーク ポリシーとアクセス サービスも必要ですが、任意で、インターネット認証サービス (IAS) の後継にあたる NPS サーバーを使用するように TS ゲートウェイを構成して、ターミナル サービスの接続承認ポリシー (TS CAP) の保存、管理、検証を一元管理することもできます。また、TS ゲートウェイ サーバー用の SSL 証明書がない場合は、これを取得する必要もあります。ISA Server 2006 が、この証明書を発行した証明機関 (CA) を信頼していることが重要です。ですから、この証明書は、必ず信頼されたルート証明機関ストアにインポートしてください。
Active Directory® ドメイン サービスは、ユーザーが Active Directory セキュリティ グループのメンバでないと TS ゲートウェイ サーバーへの接続を許可しない TS ゲートウェイ承認ポリシーを構成する場合にのみ必要です。この記事のシナリオでは、Windows Server 2003 SP2 を実行するコンピュータで Active Directory を使用します。
ターミナル サービス ゲートウェイ サービスのインストールが完了すると、図 2 の画面が表示され、インストールされたコンポーネントが表示されます。TS ゲートウェイに接続するには、クライアントでは、Windows Vista®、RDP 6.0 以降がインストールされている Windows XP SP2、Windows Server 2008、RDP 6.0 以降がインストールされている Windows Server 2003 SP1 のいずれかを実行している必要があります。TS ゲートウェイの構成の詳細については、『Windows Server 2008 TS ゲートウェイ サーバーのセットアップに関するステップ バイ ステップ ガイド』(go.microsoft.com/fwlink/?LinkId=122251) を参照してください。次は、ISA Server 2006 の構成方法について説明します。
図 2 TS ゲートウェイのインストールの概要 (画像をクリックすると拡大表示されます)

ISA Server 2006 を構成する
まず、外部の RDP クライアントからの要求を処理する Web リスナを作成します。ここでは、Web リスナに次のパラメータを割り当てました。
  • 認証 : 基本
  • 認証の検証 : Windows (Active Directory)
  • 接続 : ポート 443 での SSL (HTTPS) 接続を有効にする
  • 証明書 : tsg.contoso.com に対して発行された証明書
  • ネットワーク : 外部
次に Web 公開ルールを作成します。ISA Server 2006 からすると、RDP クライアントでは Outlook® Anywhere が使用するものと同じプロトコルを使用するため、Exchange Server 2007 ウィザードを選択します。それには、次の手順に従います。
  1. [ファイアウォール ポリシー] を右クリックし、[新規作成] をポイントして、[Exchange Web クライアント アクセス公開ルール] をクリックします。
  2. [新しい Web 公開ルール ウィザードへようこそ] ページで、ルール名を入力し、[次へ] をクリックします。
  3. [ルールの動作の選択] ページで [許可する] を選択し、[次へ] をクリックします。
  4. [サービスの選択] ページで、Exchange Server のバージョンを選択します (ここでは [Exchange Server 2007] を選択しました)。[Outlook Anywhere (RPC/HTTP)] チェック ボックスをオンにし、[次へ] をクリックします (注 : [Exchange Server に Outlook 2007 用の追加のフォルダを公開する] チェック ボックスはオンにしないでください)。
  5. [公開の種類] ページで、[1 つの Web サイトまたは負荷分散装置を公開する] を選択し、[次へ] をクリックします。
  6. [サーバー接続セキュリティ] ページで、[公開された Web サーバーまたはサーバー ファームへの接続に SSL を使用する] を選択し、[次へ] をクリックします。
  7. [内部公開の詳細] ページで、[内部サイト名] ボックスに TS ゲートウェイ サーバーの名前を入力します。[コンピュータ名または IP アドレスを使用して、公開されたサーバーに接続する] チェック ボックスをオンにし、[コンピュータ名または IP アドレス] ボックスにサーバー名を入力します。TS ゲートウェイ サーバーの名前がわからない場合は、[参照] をクリックして、サーバーのある場所を参照します。このページで使用する名前は、TS ゲートウェイ Web サイトにバインドされている Web サイト証明書に記載された共通名またはサブジェクト名と一致している必要があります。
  8. [パブリック名の詳細] ページで、[要求の許可] ボックスの一覧の [次に入力したドメイン名] をクリックし、[パブリック名] ボックスにこの URL に対して発行された証明書の名前と一致するパブリック名 (ここでは「tsg.contoso.com」) を入力します。[次へ] をクリックします。
  9. [Web リスナの選択] ページで、ドロップダウン リストをクリックし、前に作成した Web リスナを選択して、[次へ] をクリックします。
  10. [認証の委任] ページで、[委任できません。クライアントは直接認証できます] を選択し、[次へ] をクリックします。
  11. [ユーザー セット] ページで、既定のオプション (すべてのユーザー) が選択されていることを確認して、[次へ] をクリックします。次に、[完了] をクリックして、設定を適用します。
ルールをダブルクリックし、[パス] タブを参照すると、/rpc/* というパスしか表示されません。これは、Exchange Server 2007 Outlook Anywhere ウィザードを使用したことによる現象です。

クライアント アクセスをテストおよび監視する
前述のとおり、TS ゲートウェイに接続するには、RDP 6.0 以降のクライアントが必要です。RDP クライアント アプリケーションを構成するには、これを起動して、接続先のターミナル サーバーの名前をコンピュータ フィールドに入力します。[オプション] ボタンをクリックし、[詳細設定] タブの [設定] をクリックし、TS ゲートウェイ サーバーの外部名を入力します (図 3 参照)。この記事の例では、これは、受信要求を受け付けるための Web 公開ルールで使用している Web リスナにバインドされている証明書に記載されている名前です。この例では、Windows NT® LAN Manager 認証が使用されています。この一連の操作が完了したら [OK] をクリックし、[接続] をクリックします。認証用のダイアログ ボックスが表示されたら、ターミナル サーバーへのアクセス権を持つユーザーの資格情報を入力し、[OK] をクリックします。
図 3 RDP クライアントの構成 (画像をクリックすると拡大表示されます)
RDP 6.0 クライアント (Windows XP と Windows Server 2003 の場合) では、図 3 の画面が表示されます。認証は 2 回求められます。1 回目は TS ゲートウェイ コンピュータでの認証で、2 回目はアクセスするターミナル サーバーでの認証です。これは、重要なポイントです。2 回認証が行われるのは ISA Server の構成によるものだと思われるかもしれませんが、実際には、Web 公開ルールが "すべてのユーザー" に適用されているため、ISA Server では認証をまったく処理していません。これにより、ISA ファイアウォール経由の匿名接続を可能にしています。
Windows Server 2008 付属の RDP クライアントには、[リモート コンピュータに TS ゲートウェイの資格情報を使用する] というチェック ボックスがあります (図 4 参照)。このチェック ボックスをオンにすると、資格情報を 2 回入力する必要がなくなり、ユーザーの操作性が高まります。このシングル サインオン オプションは、SP1 を適用すると Windows Vista でも利用できます。
図 4 Windows Server 2008 の RDP クライアント (画像をクリックすると拡大表示されます)
接続は、TS ゲートウェイ マネージャの監視オプションを使用して監視できます。また、TS ゲートウェイ サービスでは、承認されていないユーザーがサーバーへの接続を試みた場合に詳細情報を提供します。図 5 は、TS ゲートウェイ経由で接続するアクセス許可のないユーザーによる接続試行イベントが表示されているイベント ビューアの画面です。
図 5 TS ゲートウェイ サービスに記録されたイベント (画像をクリックすると拡大表示されます)
このイベントでは、ISA Server 2006 の内部 IP アドレスが記録されています。これは、Web 公開ルールで [ISA Server コンピュータからの要求にする] が有効にされているためです。元のクライアント IP アドレスを記録する場合は、ISA Server 2006 Web 公開ルールを変更して、[公開先] タブで [元のクライアントからの要求にする] を選択する必要があります。

ISA Server から監視する
ISA Server 2006 Supportability Update の新機能を使用すると、内部ネットワークへの接続を詳細に監視して把握することができます。図 6 では 1 つの接続が選択されていて、この接続の Request: 行には HTTP プロキシを経由した RPC 用の URL を伴う RPC_IN_DATA 動詞が表示されています。
図 6 Supportability Update を使用した ISA Server 2006 のログ (画像をクリックすると拡大表示されます)
さらにログの内容を確認すると、もう 1 つの HTTP を経由した RPC 動詞、RPC_OUT_DATA があることを確認できます。ここでは RDP/HTTP 用の RPC_IN_DATA と RPC_OUT_DATA ですが、どの HTTP メソッドが使用されているかを把握しておくことが重要です。というのも、これらのメソッドをブロックするように HTTP フィルタが構成されている場合、ISA Server でトラフィックがブロックされてしまうからです。環境をロックダウンする場合は、これらの 2 つのメソッドのみを許可する RDP/HTTP Web 公開ルールを構成できます。通常公開に使用される HTTP メソッドの詳細については、「ISA Server 2004 の HTTP フィルタリング」(technet.microsoft.com/library/cc302627) を参照してください。

2 つ目のシナリオ
このシナリオでは、TS ゲートウェイは、別のサーバー上にある NPS セントラル ポリシーを使用します。TS ゲートウェイ経由でリモートから接続するクライアントに、NAP ポリシーを強制します。このシナリオでは、NPS サーバーを追加する以外は、1 つ目のシナリオで使用したのと同じコンポーネントを再び使用します。ただし、NAP 強制により、クライアント側ではより多くのコンポーネントが使用されます (図 7 参照)。
図 7 シナリオ 2 のトポロジの主なコンポーネント (画像をクリックすると拡大表示されます)
個々のコンポーネントについて説明します。Windows Vista クライアントにインストールされているシステム正常性エージェント (SHA) は、クライアントの正常性の状態を監視し、レポートするクライアント側コンポーネントです。Windows Vista には Windows SHA が付属していますが、独自の SHA を開発している他のベンダもあります。
クライアントがネットワークへのアクセスを試行すると、クライアント側の NAP エージェントによって NAP 強制サーバーとの通信が確立されます。NAP エージェントは、クライアントの正常性ステートメント (SoH) を NAP サーバーに送信します。
TS ゲートウェイ上にある TS のリソース承認ポリシー (TS RAP) は、着信 RDP 要求の受信に利用できるコンピュータを特定するためのコンポーネントです。また、TS RAP では、どのユーザーがどのサーバーへの RDP 接続を確立できるかについても特定できます。
セントラル NPS サーバーは、内部コンピュータへのアクセスを規制する条件、制約、および設定を制御します。セントラル NPS サーバーにインストールされているシステム正常性検証ツール (SHV) では、クライアントが発行した SoH が、管理者によって設定されたポリシーに準拠しているかどうかを評価します。
では、セントラル NPS サーバーをポイントするように、TS ゲートウェイを変更しましょう。TS ゲートウェイ マネージャ コンソールを開き、サーバーの名前を右クリックし、[プロパティ] をクリックします。サーバーのプロパティ ウィンドウで、[TS CAP ストア] タブをクリックし、[セントラル NPS サーバー] を選択します。次に、NPS サーバーの名前または IP アドレスを入力し、[追加] をクリックします。[共有シークレット] ダイアログ ボックスが表示されます。シークレットを入力し、[OK] をクリックします。もう一度 [OK] をクリックして、ダイアログ ボックスを閉じます。このシークレットは NPS サーバーで使用されるので、覚えておく必要があります。
NPS が既に別のサーバー上にインストールされているという前提条件で実行する必要がある手順を次に示します。
  1. ネットワーク ポリシー サーバー コンソールを開き、左側のウィンドウで [NPS (ローカル)] をクリックします。
  2. 右側のウィンドウで、[NAP を構成する] をクリックします。[NAP で使用するネットワーク接続方法の選択] ページが表示されます。
  3. [ネットワーク接続の方法] ボックスの一覧の [ターミナル サービス ゲートウェイ (TS ゲートウェイ)] をクリックし、[次へ] をクリックします。
  4. [Specify NAP Enforcement Servers Running TS Gateway] (TS ゲートウェイを実行する NAP 強制サーバーの指定) ページで [追加] ボタンをクリックします。
  5. [New TS Gateway] (新しい TS ゲートウェイ) ウィンドウで、TS ゲートウェイ サーバーのフレンドリ名と IP アドレスを入力します。このウィンドウの下部に共通シークレットを入力します。これには、TS ゲートウェイ サーバーの構成に使用したのと同じシークレットを使用します。[OK] をクリックします。
  6. [クライアント デバイスのリダイレクトと認証方法の構成] ページでは、リダイレクトされるデバイスとすべての許可される認証方法 (パスワードまたはスマート カード) を指定できます。この例では、既定のオプションを使用し、[次へ] をクリックします。
  7. [ユーザー グループとコンピュータ グループの構成] ページで、接続の確立を許可するユーザー グループを追加します。この例では、[ユーザー グループ: (必須)] の [ユーザーの追加] をクリックし、[Domain Admins] を選択します。[OK] をクリックして、[次へ] をクリックします。
  8. [NAP 正常性ポリシーの定義] ページでは、既定の SHV が既に選択されています。また、このページの下部では、非準拠のコンピュータのアクセスが拒否されることを確認できます。既定のオプションを使用して、[次へ] をクリックします。
  9. [NAP 強制ポリシーおよび RADIUS クライアント構成の完了] ページで、これまでに選択したオプションの内容を確認します。ハイパーリンクをクリックすると、[NAP 強制ポリシーおよび RADIUS クライアント構成の完了] ページが表示され、選択した項目についての概要を確認できます。処理が完了したら、[完了] をクリックします。
このウィザードを使用すると、さまざまな重要なポリシー (接続要求ポリシー、ネットワーク ポリシー、および正常性ポリシー) の設定を構成できるので、このシナリオの NAP の構成に必要な作業を大幅に軽減できます。

クライアントについて
サーバーのセットアップと構成は完了しましたが、最後にクライアント側で必要な作業について説明しましょう。
NAP 強制ポリシーを利用するには、クライアントでは Windows Server 2008 または Windows Vista が実行されている必要があります。Windows XP の場合は、NAP クライアントが含まれる SP3 をインストールしておく必要があります。
オペレーティング システムの要件以外に、クライアント側で有効にする必要がある関連サービスと設定がいくつかあります。これは、次のとおりです。
  • TS ゲートウェイ サーバーの名前を信頼済みサーバーの一覧に追加します。
  • NAP エージェント サービスを開始し、サービスのスタートアップの種類を [自動] に設定します。
  • TS ゲートウェイ検疫強制クライアントを有効にします。
このソリューションを容易に展開できるよう、マイクロソフトではターミナル サービス NAP クライアント構成コマンド (Tsgqecclientconfig.cmd) を作成しました。これは、go.microsoft.com/fwlink/?LinkId=122267 からダウンロードできます。このコマンドを実行すると、クライアントは TS ゲートウェイ用の NAP 強制クライアントとして構成されます。このコマンドはシステム特権を使用して実行する必要があることに注意してください。
この記事では、Windows Server 2008 が提供する新しい TS ゲートウェイ機能について説明し、TS ゲートウェイを ISA Server 2006 経由で安全に公開する方法を紹介しました。また、この 2 つの製品を連携して使用することで得られるセキュリティ上のメリットの概要についても説明しました。
現在の世の中では、どこからでも接続できることが、ほとんどすべての成功するビジネスにとっての重要な要件の 1 つになっています。ただし、このような接続を実現するために、優れたユーザー エクスペリエンスが犠牲にならないようにする必要もあります。また、さらに重要なことですが、これはセキュリティを確保した状態で実現される必要があります。

Dr. Thomas W. Shinder は、MCSE および ISA Server MVP 資格保持者です。1996 年以来、テクノロジ関連の教育者、ライター、およびコンサルタントとして活躍しており、ISA ファイアウォールについての書籍を 6 冊執筆しています。また、ISA ファイアウォールの管理者と愛好者のインターネット上の最大のコミュニティである ISAserver.org の思想的指導者であり、中心的な運営者でもあります。

Yuri Diogenes は、MCSE+S、MCTS、MCITP、Security+、Network+、および CCNP 資格保持者であり、Microsoft ISA Server/IAG チームのセキュリティ サポート エンジニアです。Microsoft TechNet ライブラリと ISA Server チームのブログの記事を執筆しており、1993 年以来、マイクロソフト テクノロジに携わっています。マイクロソフトに入社する以前は、マイクロソフト トレーナー、サポート アナリスト、およびコンサルタントとして働いていました。


IIS 7.0
IIS 7.0 のパフォーマンス向上機能トップ 10
Mike Volodarsky
概要 :
  • アプリケーションのフットプリントを最小化する
  • 帯域幅コストを削減する
  • 強化されたキャッシュ機能を使用する

目次
より軽量な Web サーバー
軽量 OS を基盤に構築する
特化型アプリケーション トポロジ
強化されたアプリケーション サポート
アプリケーション集積度を高める
圧縮により帯域幅を削減する
メディア ビット レートを調整する
出力キャッシュ
ISAPI コードを IIS 7.0 モジュールに変換する
サーバーの拡張性
まとめ
IIS 7.0 の採用を計画している企業の方とお会いしたときに必ず聞かれるのは、IIS 7.0 に移行することでサーバーやアプリケーションのパフォーマンスは向上するかどうかということです。概ね、
その質問に対する回答は「向上する」になりますが、IIS 7.0 にアプリケーションを初めて移行した時点で、パフォーマンスの向上が見られない場合があることも覚悟してください。
これを理解するには、IIS 7.0 の性質を理解する必要があります。IIS 6.0 は、セキュリティ、信頼性、およびパフォーマンスの強化という 3 つの目標を掲げたエンジニアリング リリースでした。これに対して、IIS 7.0 はプラットフォーム リリースです。IIS 7.0 の目的は、IIS 6.0 の高品質な基本の Web サーバー コアを、現在の主要な開発シナリオと管理シナリオをサポートできる、モジュール型の拡張可能なプラットフォームに変換することでした。
たとえば、主要な変更の 1 つとして、厳密に最適化された Web サーバー コードのパスが破棄され、Web サーバーから特別な処理を受けないスタンドアロンのモジュールに作り変えられていることを考えると、多数のアーキテクチャ上の変更や新機能は、実際には Web サーバーのパフォーマンスに悪影響を与える可能性があります。ただし、IIS 製品チームのパフォーマンスに対する多大なる取り組みのおかげで、IIS 7.0 は IIS 6.0 と同レベルの (一部の領域では IIS 6.0 を上回る) パフォーマンスを実現しています。私は Web サーバー コアと統合パイプライン開発に携わった経験から、これを実現するにはさまざまな設計上の工夫と製品実装において、たいへんな努力が必要であったことを断言できます。
いずれにせよ、IIS 7.0 は、これまでのどの IIS リリースよりも、サーバー ファームの大幅なパフォーマンス向上とパフォーマンス関連コストの削減を実現できる高い可能性を持っています。
IIS 7.0 に移行しただけで、このようなメリットが実現されるとは限りませんが、中には、移行するだけで、このようなメリットを実際に実現できる環境もあります。たとえば、Microsoft.com では CPU 使用率が 10% 改善されました (詳細な解析結果については、Microsoft.com チームのブログ go.microsoft.com/fwlink/?LinkId=122497 を参照してください)。また、SSL (Secure Sockets Layer) や Windows® 認証 (いずれも現在はカーネル内で実行) など、特定の領域でパフォーマンスが大幅に向上したり、マルチコア コンピュータとマルチプロセッサ コンピュータ上でハードウェア追加による拡張が容易になるといったメリットを実感できる場合もあります。
しかし、IIS 7.0 の真の威力は、既存機能のパフォーマンス強化により実現されるのではなく、積極的に使用する必要がある IIS 7.0 の新機能によって実現されます。このような機能は、多くの場合、プラットフォームの持つ柔軟性と拡張性の高さと、新しいパフォーマンス機能に根ざしています。この記事では、IIS 7.0 に移行することで可能になるパフォーマンスの向上を実現する最も重要な 10 個の機能について説明します。

より軽量な Web サーバー
軽量な IIS 7.0 サーバーを展開できるのは、サーバーのモジュール型アーキテクチャのおかげです。実際、IIS 7.0 の Web サーバー機能はすべて、個別に追加または削除できるモジュール コンポーネントとして実装されています。ですから、アプリケーションの運用に必要ないサーバー機能を削除できるため、攻撃対象となる領域を大幅に削減できる、運用フットプリントを縮小できる、パフォーマンスが向上するなど、注目に値するメリットが得られます。
IIS 7.0 の完全な Web サーバー機能には、ネイティブ IIS モジュールや統合パイプラインにサービスを提供する ASP.NET モジュールも含め、44 個のモジュールが含まれています。これらのモジュールにより、認証 (Windows 認証モジュールとダイジェスト認証モジュール)、アプリケーション フレームワーク サポート (FastCGI モジュール)、アプリケーション サービス (セッション状態モジュール)、セキュリティ (要求フィルタ モジュール)、パフォーマンス (出力キャッシュ モジュール) などのサービスが提供されます。しかし、静的コンテンツを提供するだけの最小構成の Web サーバーであれば、たった 2 個のモジュールで機能します。
要求ログ モジュールや失敗した要求のトレース モジュールの場合など、不要なモジュールから生じるオーバーヘッドはかなり大きくなることがあります。このようなモジュールが不要な場合、環境からこれらを削除することで、全体のスループットが向上するだけでなく、応答時間も短縮され、サーバー負荷の指標である TTFB (最初のバイト受信までの時間) と TTLB (最後のバイト受信までの時間) が低下します。
図 1 は、完全な機能セット、該当ワークロードの既定の機能セット、および該当ワークロードに最低限必要な機能セットの構成に対して実行した、HTML ファイル (静的ワークロード) と "hello world" ASP.NET ページ (ASP.NET ワークロード) を使用した簡単なスループット テストの結果です。完全構成でもほとんどの二次的機能は無効になっていますが、最小構成ではこれらの機能を完全に削除することで、静的ワークロードと ASP.NET ワークロードの両方で、かなりのスループットの向上が認められました。
図 1 100 台の同時実行クライアントを使用した 3 種類の構成における静的ワークロードと ASP.NET ワークロードのスループット率 (画像をクリックすると拡大表示されます)
また、特に共有ホスティング環境や、大量のワーカー プロセスが使用されている場合などでは、メモリ フットプリントの改善やサイトの集積度の向上も認められる場合があります。これは、通常、各プロセスに読み込まれる DLL 数が少なくなり、モジュールの初期化と要求の処理時に発生するメモリ割り当てが省かれることで実現されています。図 2 は、前出のスループット テストにおけるメモリ使用率 (IIS ワーカー プロセスのプライベート バイト) を示しています。この例では、それほど大きな改善は見られませんが、ASP.NET アプリケーション ドメインのオーバーヘッドが、モジュールの削除による使用メモリの削減量よりも比較的高いため、メモリ使用率の向上は予期したとおりの結果だと言えます。
図 2 100 台の同時実行クライアントを使用した 3 種類の構成における静的ワークロードと ASP.NET ワークロードのメモリ使用率 (プライベート バイト) (画像をクリックすると拡大表示されます)
IIS 7.0 では、アプリケーション レベルでどのモジュールを有効にするかについてより細かい制御ができるだけでなく、モジュールの前提条件を設定してワークロードを基にモジュールの使用方法を制御できます。これには詳細な構成が必要ですが、複数サイトがある環境や複数の異なるワークロードをサポートするアプリケーションでは、追加のメリットを得られる可能性があります。
ただし、必要な機能を特定することは厄介な場合があります。というのは、アプリケーション フレームワークのサポートに必要な最小限の機能だけでなく、アプリケーションが間接的に依存している可能性がある追加機能についても考慮する必要があるからです。たとえば、アプリケーションは特定の認証方法やさまざまな IIS 機能で提供される認証セマンティクスに依存している可能性があり、このような場合に該当するモジュールを削除するとアプリケーションのセキュリティに悪影響を及ぼす可能性があります。同様に、アプリケーションが機能やパフォーマンスを実現するのに、いくつかのモジュールに依存している場合、これらのモジュールを削除するとアプリケーションが正しく動作しなくなったり、パフォーマンスが低下する可能性があります。

軽量 OS を基盤に構築する
Windows Server® 2008 でも OS レベルのコンポーネント化が行われており、これを利用して Web サーバーの攻撃対象領域をさらに縮小することができます。Server Core は Windows Server 2008 オペレーティング システムの最小インストール オプションで、最小限のコア OS サブシステムのセットが含まれています。Server Core は、軽量な IIS 7.0 Web サーバーの環境として理想的なインストール オプションです。
ただし、Server Core を評価するときは、一部の制限によりアプリケーションが影響を受ける可能性があることに注意してください。Server Core では Microsoft® .NET Framework がサポートされていないので、ASP.NET、IIS 対応の .NET 拡張、IIS マネージャを利用できません。また、Microsoft 管理コンソール (MMC) も利用できないため、ローカルの管理作業にはコマンド ライン ツールを使用する必要があります。パフォーマンスの観点では、既に IIS のコンポーネント化を適切に利用している場合、Server Core と完全な Windows Server 実装で実行されるアプリケーション ワークロード間で、メモリ フットプリントやスループットに違いが見られない可能性があります。これは、IIS とアプリケーションによって実行される作業が、どちらのプラットフォーム上でも同じためです。ただし、違いが見られるものが 1 つあります。それは、サーバーの全体的なフットプリントで、ディスク領域とメモリ使用率の両方で違いが見られます。
図 3 に、完全な Windows Server 2008 構成と Server Core で静的ワークロード テストを実行した後のフットプリントの違いの例を示します。IIS のリソース使用率はどちらの場合もほぼ同じですが、Server Core では OS 全体のフットプリントが縮小したので、はるかに少ないメモリでワークロードをサポートできました。フットプリントが低くなることで、アプリケーションのワークロードを機能性の低いハードウェアに展開でき、運用環境ではなく、アプリケーションの処理要求にのみ注意を向けることができます。もちろん、これが Server Core が仮想化環境として適切なオプションである理由です。
図 3 完全な Windows Server 2008 実装と Server Core 間の静的ワークロード テスト実行後のメモリ フットプリントの違い (画像をクリックすると拡大表示されます)

特化型アプリケーション トポロジ
アプリケーション ワークロードを最適化するときに、ワークロードを種類ごとに分離できます。たとえば、アプリケーションを 30 台の同じ Web サーバーから成るファームで実行するのではなく、10 台の Web サーバー、5 台のアプリケーション サーバー、およびキャッシュと圧縮を実行する 3 台のプロキシ サーバーで実行することができます。
このような特化が有効である理由はいくつかあります。まず、多くのアプリケーション ワークロードのパフォーマンスは、メモリを始めとして、さまざまな共有リソースに大きく依存しており、アプリケーションの複数の構成要素間でリソースの競合が発生する可能性があります。このようなリソースの競合が発生すると、各サーバーが他のリソースで十分に活用されることを妨げるボトルネックが生じかねません。アプリケーションの構成要素を分離することで、分離されなければ競合することになるリソースに各構成要素がいつでもアクセスできる状態になり、同じハードウェア リソースでも利用効率が向上します。
また、特化により、アプリケーションがローカルにより多くのデータをキャッシュできるようになり、パフォーマンスが向上する可能性があります。これには、仮想メモリの変換ルック アサイド バッファ (TLB)、ファイル システムのキャッシュ、他のオペレーティング システム キャッシュやアプリケーション キャッシュなどの下位レベルのキャッシュが含まれます。CPU にも、特化によるメリットがあります。アプリケーションの特定の構成要素のみを処理することで、並行して実行される操作の数が減少するので、アプリケーションのコンテキスト スイッチの回数が減り、CPU の作業効率を最大限に高められます。
特化により、ワークロードごとの最適化も可能になるので、アプリケーションの各構成要素が効率よく機能するようにできます。このような最適化の多くは、アプリケーション全体が同じサーバーでサポートされている場合、そのアプリケーションの各構成要素の要件が競合するため、実現できません。
これがよく発生する領域の 1 つは IIS と ASP.NET のスレッド構成ですが、この構成は同時実行に大きく影響するだけでなく、多くのアプリケーションのメモリ使用率、待ち時間、およびスループットに間接的に影響します。IIS の静的ファイル ワークロードは非常に非同期的で厳しい同時実行要求制限を必要としますが、利用可能なスレッド数はわずかで済みます。一方、ASP.NET 機能の多くは、同期的で長い時間リソースを占有し、多くのスレッドを必要としますが、メモリへの影響を低減できるよう同時実行制限がゆるいものもあります。静的ワークロードを分離し、要求処理パイプラインの構成要素を異なるプロセスやサーバーに分散することで、個々のワークロードの同時実行を最適化できます。
さらに、特化によって、アプリケーションが個々のワークロードやアプリケーション構成要素を個別にスケール アウトできるようになるため、全体的なスケーラビリティを向上することができます。これにより、同じテンプレートをアプリケーション全体に適用するのではなく、最も必要とされる箇所でアプリケーション トポロジの収容力と冗長性を高めることができます。このモデルでは、物理サーバー、仮想サーバー、または同じコンピュータのアプリケーション プールでも、特化されたリソースとして扱うことができます。
アプリケーション トポロジで特化を行うことで得られるメリットを評価する際には、まずアプリケーションの処理上または多くのリソースを必要とするボトルネックを特定します。このような領域が特化を行う最有力候補になります。というのも、この領域は、分離すると最適化できる可能性が高く、最大限のエンティティの追加によるスケール アウトが要求されるからです。次に、これらの領域を分離することで、アプリケーションの他の領域でより有効にリソースを使用できるかどうかを評価します。最後に、分離されたアプリケーション コンポーネントを連携させるために必要な接続メカニズムに伴うオーバーヘッドを評価する必要があります。

強化されたアプリケーション サポート
IIS 7.0 には、FastCGI によるアプリケーション フレームワークの拡張サポートが実装されています。FastCGI は多くのオープンソース アプリケーション フレームワークによってサポートされているオープン プロトコルで、このサポートがなければ安定した高パフォーマンスの IIS とのネイティブ サポートは実現できない可能性があります。IIS で長年サポートされている CGI (Common Gateway Interface) プロトコルと異なり、FastCGI は Windows プラットフォーム上ではるかに優れたパフォーマンスを実現します。これは主に FastCGI ではプロセスを再利用できるアーキテクチャが採用されていることにあります。プロセスの再利用により、要求ごとにプロセスを作成することで生まれる大きなオーバーヘッドが省かれ、クライアントが固定キープアライブ接続を活用できます。
CGI などのメカニズムを使用して IIS でアプリケーション フレームワークをサポートしている場合、FastCGI プロトコルに移行することで、パフォーマンスを (場合によっては安定性も) 向上できる可能性があります。
このサポートを初めて利用したアプリケーション フレームワークは PHP です。実際、IIS 製品チームは Zend Technologies 社から直接協力を得て、IIS の FastCGI 実装が PHP とスムーズに連携し、Windows 上での PHP フレームワークのパフォーマンス向上を実現できるようにしました (このプロジェクトの詳細については、私のブログ go.microsoft.com/fwlink/?LinkId=122509 を参照してください)。IIS で実行される ASP または ASP.NET アプリケーションと、他のテクノロジを使用する PHP または他の FastCGI 準拠のアプリケーション フレームワークが含まれるという Web サーバー テクノロジが混在している環境では、IIS 7.0 プラットフォームで、これらのアプリケーションを統合できる可能性があります。
PHP や他のアプリケーション フレームワークを IIS 7.0 と FastCGI に移行すると、ASP.NET 統合パイプラインなどの IIS 7.0 機能を利用できます。これにより、アプリケーション フレームワークを ASP.NET に変換しなくても、ASP.NET サービスを使用してアプリケーション フレームワークの機能を強化する非常に便利な手段が得られます。また、異なるフレームワークを使用するアプリケーション間での連携も可能になります。これを使用して、コードを変更することなく既存のアプリケーションの機能を拡張し、パフォーマンスを改善する方法の例については、私の MSDN® Magazine の記事「統合 ASP.NET パイプラインでアプリケーションを拡張する」(msdn.microsoft.com/magazine/cc135973.aspx) を参照してください。

アプリケーション集積度を高める
IIS 7.0 には、1 台のサーバーでホストできるアプリケーションの集積度を高めることを目的としたさまざまな機能拡張が施されています。このような機能拡張は、共有ホスティングの品質を向上する目的で IIS 7.0 が提供しているさまざまな機能の一部であり、これにはサイト プロビジョニングとアプリケーション分離機能の強化が含まれます。
この機能強化ではパフォーマンスの観点から、IIS 7.0 サーバー上にプロビジョニングできるアプリケーションを増やすことと、一度にアクティブにできるアプリケーションを増やすことの 2 点に重点を置いてアプリケーション集積度を向上しています。
IIS 7.0 では、1 台のサーバーで以前よりも多くの数のアプリケーションをプロビジョニングできます。社内テストでは、1 台のサーバーに最大 100,000 件のサイトをプロビジョニングできました。これには、多数のサイトとアプリケーションを作成して構成する機能が必要です。
ただし、高速のプロビジョニングは古い API では実現できないため、これを実現するには、新しい構成 API に移行する必要があります。また、すべての IIS 構成 API で同じパフォーマンス特性が提供されるわけではないので、確実に高いパフォーマンスが得られるように、APIを選択する際には十分に検討する必要があります。迷う場合は、新しい IIS 構成オブジェクトを直接利用する構成オプションを選ぶことをお勧めします。これには、Microsoft.Web.Administration 名前空間、AppCmd.exe コマンド ライン ツール、スクリプト、.NET、または C++ コードからアクセスする IIS の COM 構成オブジェクトが含まれます。
プロビジョニング可能なサイト数とアクティブにできるサイト数の差は、固定アプリケーションとワーカー プロセスを使用して要求処理を実行する IIS アーキテクチャにおいては非常に重要です。このモデルでは、アクティブなアプリケーションは、サーバーのリソースをより多く消費しますが、キャッシュの利用と初期化コストがないことにより、パフォーマンスを維持できます。
アクティブな各アプリケーションには、(推奨されるアプリケーション分離モデルが使用される場合は) 一定量のメモリと個別のワーカー プロセスが必要なため、アクティブにできるアプリケーションの数はアプリケーションのメモリ フットプリントに大きく依存します。したがって、静的コンテンツのみを処理するアプリケーションのワーカー プロセスでは 3 MB しか必要としません (また同じワーカー プロセスを他の静的コンテンツ アプリケーションと共有することもできます) が、一部の動的なアプリケーションは、あまり使用されていない状態でも 100 MB 以上の RAM を必要とする場合があります。このため、最大集積度を特定する場合、アプリケーションのフットプリントに対して IIS ワーカー プロセス自体のメモリ オーバーヘッドがかなり高くなります。
一般的な共有ホスティング シナリオでは、通常、80/20 の配布という現象が見られます。これは、要求の 80% がサイトの 20% に渡されるというものです。その結果、どの時点でもアクティブなサイトは少数にとどまります。アクティブなサイト数を増やすため、IIS 7.0 ではアクティブ ライフタイム管理機能を提供しています。この機能は、より多くのアクティブ アプリケーションをホストできるよう、アクティブでないアプリケーションのメモリを回収できるようにするためのものです。
IIS 7.0 は、動的アイドルという新しいアルゴリズムを導入しています。これは、サーバー上の利用可能なメモリに基づいて事前にワーカー プロセスのアイドル タイムアウトを調整するものです。メモリが少なくなったときに、アイドル状態のアプリケーションが削除される速度が速くなるので、より多くのアクティブ アプリケーションがホストされるようになります。ただし、メモリが利用可能な場合は、より高いパフォーマンスを提供できるようタイムアウトまでの時間が通常どおり確保され、アプリケーションの状態が維持されます。より多くのアプリケーションをアクティブにできるよう、動的アイドル機能では、メモリ不足状態が発生して、スラッシングによるパフォーマンスの大幅な低下を招くことがないようにします。
アクティブなアプリケーションを多数ホストできるようにするには、64 ビット オペレーティング システムを利用して、4 GB 以上のメモリを割り当てられるという特性を活用することをお勧めします。また、IIS のワーカー プロセスが 32 ビット モード (SysWoW64) で実行されるように構成することもお勧めします。このモードでは、IIS のワーカー プロセス自体のメモリ消費を節約できるだけでなく、OS では 32 ビット環境で割り当て可能である以上のメモリを割り当てることができます。

圧縮により帯域幅を削減する
インターネットに接続しているデータセンターの最大の運用コストの 1 つが帯域幅のコストであることは、驚くことではありません。また、要求されたコンテンツを送信するのに必要な帯域幅も、認識されるアプリケーションの応答性に影響する主要な要素です。
アプリケーション応答を送信するのに必要な帯域幅を削減する最も有効な方法の 1 つは、HTTP 圧縮を使用することです。これにより、応答のサイズを大幅に削減でき、HTML のような容易に圧縮できるテキスト コンテンツに適用した場合は、通常 1/10 に削減できます。最大のメリットは、ほぼすべてのデスクトップ ブラウザがこれをサポートしていることと、少ないデータを送信することで得られる待ち時間上のメリットと比較して、デスクトップのハードウェア側で圧縮解除コストが軽いことです。また、圧縮は HTTP 1.1 プロトコルで規定されているコンテンツ エンコード ネゴシエーションに基づいて処理されるため、圧縮を有効にしても、圧縮をサポートしていないクライアントでは圧縮されていないコンテンツを受け取るので問題にはなりません。
IIS 7.0 は、IIS 6.0 で導入された "静的圧縮" および "動的圧縮" という 2 種類の圧縮機能を提供しています。静的圧縮は静的コンテンツを事前に圧縮してディスクに保存することで、将来、圧縮済みのコンテンツを直接処理して、圧縮のオーバーヘッドが生じないようにすることができます。動的圧縮はリアルタイムで応答を圧縮することで、アプリケーションが生成する応答の圧縮を可能にします。IIS 7.0 上のどのアプリケーション フレームワークでも、動的圧縮 (ASP、ASP.NET、または PHP) を利用できます。
定説に反して、動的圧縮は通常、法外な CPU オーバーヘッドを伴うことはありません。実際、多くの場合、動的圧縮はアクセス頻度の高いサーバーで全体の CPU 使用率の 5% 未満のオーバーヘッドしか生みません。動的圧縮は、アプリケーション ワークロードの帯域幅を最大限節約できるよう、比較的自由に展開できます。
圧縮と CPU オーバーヘッドの望ましい割合を実現できるように圧縮の度合いを構成することで、さらに圧縮オーバーヘッドを最適化できます。しかし、それだけではありません。圧縮コンテンツをキャッシュできるようにアプリケーションを構成すると、要求されたデータがキャッシュ内にあった場合に、既に圧縮されているコンテンツを処理することで、圧縮のオーバーヘッドを削減できます。ASP.NET と IIS の出力キャッシュはどちらも、圧縮コンテンツをサポートするクライアント用に圧縮コンテンツをキャッシュするだけでなく、非圧縮コンテンツを必要とするクライアントからの要求を処理するオプション機能によってアップグレードされています。

メディア ビット レートを調整する
メディア コンテンツを提供するサイトが増えるにつれ、多くのビジネスで帯域幅コストが急速に増大しています。さらに困ったことに、クライアントに送信されるメディア コンテンツは、実際には使用されないことが多いので、メディア帯域幅の大半は無駄に使用されています。なぜこのような事態が起きるのでしょうか。
最後にオンライン ビデオを鑑賞したり、ネットサーフィン中にビデオを見たりしたときのことを考えてみてください。ビデオは最後まで見ましたか。ビデオ サイトにアクセスするユーザーは、一般的に、ビデオの一部だけを見て次のビデオを見始めたり、閲覧中のページから移動してしまいます。ただし、プログレッシブ ダウンロードを使用してビデオを提供する Web サーバーでは、通常、このような数秒間の再生に必要なデータよりもかなり多くのデータを送信しています。そして、このデータのほとんどは使われることがありません。
平均してビデオが 5 秒間しか再生されないのに、この 5 秒間に (バッファとして) 30 秒分のビデオ データが提供されるとすると、帯域幅の 80% 以上を無駄にしていることになります。
1 年前、IIS 7.0 のベータ リリースを導入していたあるお客様のために、この問題を解決する目的で、自動的にビデオ ビット レートを検出し、サーバーがほぼ同じレートで確実にクライアントにビデオを提供するようにする帯域幅調整モジュールを作成しました。IIS メディア チームは、Bit Rate Throttling Module (図 4 参照) というこのモジュールを採用し、iis.net ダウンロード センター (iis.net/downloads/?tabid=34&g=6&i=1640) で提供しています。このモジュールの詳細については、Scott Guthrie のブログ (go.microsoft.com/fwlink/?LinkId=122514) を参照してください。
図 4 ビット レートの調整により帯域幅使用率を最小化 (画像をクリックすると拡大表示されます)
Bit Rate Throttling Module では、一般的なビデオの種類のほとんどのエンコード レートを自動的に検出します。初期バッファ遅延が発生しないように (ファスト スタート) クライアントに事前に送信されるデータの量や、コンテンツを提供するエンコード レート率を制御できます。また、最大帯域幅と現在の接続など、その他にも多くのオプションを構成したり、プログラムを使用してモジュールを制御したりすることができます。

出力キャッシュ
一般にキャッシュは、何度も同じ処理を実行するアプリケーションのパフォーマンスを向上する最適な方法です。多くの手間が必要とされ、アプリケーションの処理オーバーヘッドを削減する必要に迫られるアプリケーションのパフォーマンス向上とは異なり、キャッシュは同じコンテンツに対して繰り返し発行される要求のオーバーヘッドを削除できます。
IIS 7.0 以前は、IIS と ASP.NET では、どちらも IIS カーネル キャッシュと ASP.NET 出力キャッシュの形でキャッシュ機能を提供していました。IIS カーネル キャッシュを利用すると最高のパフォーマンスが得られましたが、主に静的コンテンツしかキャッシュできませんでした。ASP.NET 出力キャッシュは、動的コンテンツのキャッシュ ソリューションという点では、はるかに包括的なものでしたが、パフォーマンスと効率的なメモリ管理という点においては比較的劣っていました。IIS 7.0 で導入された新しい出力キャッシュは、IIS カーネル キャッシュと ASP.NET 出力キャッシュの溝を埋めています。
IIS 7.0 の出力キャッシュを利用すると、ASP、ASP.NET、PHP、他の IIS 7.0 対応アプリケーション フレームワークなど、任意のアプリケーションの動的コンテンツをキャッシュできます。この新機能では、コンテンツの可変性と有効期限という基本的なサポートを提供することで、IIS カーネル キャッシュではキャッシュできないコンテンツのキャッシュの実装を可能にしています。ただし、カーネル キャッシュの制限に適合するコンテンツに対しては、カーネル キャッシュを使用できます。
また、IIS 7.0 出力キャッシュは、ASP.NET 出力キャッシュでしか提供されない高度なキャッシュ機能 (キャッシュの依存関係やキャッシュの無効化など) を必要としない ASP.NET コンテンツをより高いパフォーマンスで処理する、ASP.NET 出力キャッシュの代替機能として利用できます。
出力キャッシュの一般的な課題は、必要なキャッシュの正確性とデータの新しさを維持しながら効率のよい応答のキャッシュを実現できる、適切なコンテンツの有効期限、無効化、および可変性のポリシーを定義することにあります。多くの場合、適切なキャッシュ ルールを構成するだけで適切なポリシーを定義できますが、実行時の情報に基づいたより複雑なポリシーが必要になる場合があります。このような状況に対応するため、IIS 7.0 出力キャッシュでは、必要なキャッシュ動作を保証するのに使用できるプログラム API を提供しています。この API により、本来ならキャッシュのメリットを得られないコンテンツで、キャッシュによるパフォーマンス向上が見られる可能性が生まれます。また、ASP.NET 統合パイプラインを使用すると、ASP.NET 以外のコンテンツにも ASP.NET 出力キャッシュを使用できます。
動的コンテンツの出力キャッシュを展開することは容易ではなく、IIS 7.0 プラットフォームの異なるキャッシュ機能の効率性と柔軟性を利用できるよう、重層的な戦略が必要になることがあります。この場合は、通常、応答に影響する複数のパラメータの記述して、キャッシュの新しさを維持する有効期限戦略と無効化戦略を定義したうえで、必要なセマンティクスをサポートするキャッシュを定義します。
しかし、ほとんどの場合、このような複雑な対応はそれだけの価値があります。IIS 7.0 出力キャッシュを実装することで、アプリケーションの全体的なスループットを桁違いに改善できるだけでなく、データベース層およびビジネス層のコンポーネントの負荷もそれに合わせて削減できます。

ISAPI コードを IIS 7.0 モジュールに変換する
IIS 7.0 では新しいサーバー API が導入されており、IIS 7.0 の全モジュールはこの API を基盤にしています。これは、以前のバージョンの IIS で使用されていたレガシ API である ISAPI フィルタと ISAPI 拡張 API に置き換わる API です。以前のバージョンをサポートする必要がない新しいモジュールでは、新しい API の方が使いやすく、より信頼性の高いサーバー側コードを作成できます。また、機能面でも優れています。
ただし、IIS 7.0 では、オプションの IIS 7.0 モジュールにより実装される互換性レイヤを利用して、既存の ISAPI フィルタと拡張をサポートするオプションも提供しています。これにより、既存の ISAPI コンポーネントは、書き換えなしで IIS 7.0 でも機能するようになっています。
既存の ISAPI 投資を使用することで IIS 7.0 への移行のハードルは低くなりますが、レガシ ISAPI コードを新しい IIS 7.0 API へ移植することをぜひ検討してください。コードを移植すると、ISAPI 互換性レイヤのオーバーヘッドを取り除いて、ISAPI コンポーネントでは得られないパフォーマンス向上を実現できます。ISAPI コンポーネントが実行する作業に応じて、このパフォーマンス上のメリットにはかなりの開きが出る可能性があります。たとえば、IIS 7.0 モジュール API では、構成メタベースや、サイト、アプリケーション、URL に関連するその他の任意のデータのキャッシュの組み込みサポートが提供されるので、コンポーネント内部での処理を大幅に高速化できます。
また、IIS モジュール API を利用すると、モジュールが、要求エンティティ データの受信や応答の送信など、時間のかかる操作を非同期に実行できます。このような作業を非同期に実行すると、サーバーでは、要求スレッド数の制限のために数十台かせいぜい数百台の同時接続クライアントで限界に達するのではなく、大量 (数万台) の同時実行クライアントに対応できるようになります。また、非同期処理により、他の要求やアプリケーション内の作業の処理に対する影響を取り除き、メモリ使用率を低減し、CPU 使用率を大幅に改善することができます。
ネイティブ API を使用すると、特定のパフォーマンスの影響パターンを得られるだけでなく、要求処理作業の柔軟性を高めることができます。このため、サーバー コンポーネントのデザインを改善して、大幅な効率化を実現できます。たとえば、これまでワイルドカード ISAPI 拡張と子要求の実行が必要だった特定のフィルタ作業は、1 つのモジュールとして元の要求処理中に実行できるほか、応答に IIS カーネル キャッシュも利用できます。
これには、移行によるメリットを最大限得られる最適なデザインを特定するために、多少のプロトタイプ作成とテストが必要になる場合があります。ISAPI と IIS 7.0 モジュール API の根本的なアーキテクチャの違いにより、直接的な移植は必ずしも適切な移植方法ではありません。ただし、IIS 7.0 モジュール API は ISAPI よりも簡単に使用できるため、比較的容易に移行できます。

サーバーの拡張性
IIS 7.0 には、エンド ツー エンドの拡張性が備わっています。この拡張性を使用するには、サーバー運用についての実践的な知識がかなり必要ですが、アプリケーション固有のパフォーマンス向上についても大きな可能性を開きます。サーバー アーキテクチャと要求処理についての知識を身に付ければ、この拡張性を利用してご使用のアプリケーション、ワークロード、およびハードウェア要件に適したカスタムのパフォーマンス ソリューションをデザインできます。
これは、任意の組み込みの IIS 7.0 機能をカスタム実装で置き換える形で実現できます。IIS 7.0 の機能については、多くの最適化が施され、パフォーマンス テストを行っていますが、当然ながら、すべての使用状況において最適化されているわけではありません。したがって、固有のワークロードに合わせて最適化することで、特定のモジュールのパフォーマンスを向上できる可能性があります。たとえば、ファイル システム API を使用してファイルを一覧表示するのではなく、ディレクトリ一覧モジュールを再実装してディレクトリをメモリにキャッシュすることもできます。
また、この拡張性を利用して新しいパフォーマンス機能を作成することもできます。組み込み機能のうち、このような機能の例としては、出力キャッシュ、圧縮モジュール、その他いくつかの内部キャッシュが挙げられます。
カスタマイズしたパフォーマンス機能が必要かどうかを判断するには、アプリケーションのパフォーマンス特性とワークロードを理解して、解消する必要があるボトルネックを把握する必要があります。IIS 7.0 は、パフォーマンスを分析するための診断サポート機能を豊富に備えています。これらを利用することで、必要な機能の要件とデザインの候補をより明確に把握できるようになります。

まとめ
IIS 7.0 は基本的に機能リリースですが、そのモジュール アーキテクチャ、構成可能性、および新しいパフォーマンス機能により、特筆すべきパフォーマンス強化を実現しています。このような機能強化は、サーバー統合によるビジネス コストの大幅な節約につながります。また、帯域幅コストを削減したり、より優れたユーザー エクスペリエンスを提供したりすることもできます。
IIS 7.0 のパフォーマンス強化の多くを適切に利用するには、多くの場合、現在使用中のアプリケーション プラットフォームを詳細に分析し、IIS 7.0 アーキテクチャの詳しい知識を身に付ける必要があります。この記事で紹介した IIS 7.0 のアーキテクチャと機能の詳細については、iis.net を参照してください。また、私のブログ mvolo.com では、IIS 7.0 を積極的に利用してアプリケーションのパフォーマンスを向上し、運用コストを削減する手法について紹介する予定です。
Mike Volodarsky は、マイクロソフトの IIS チームの元プログラム マネージャです。この 5 年間は、ASP.NET 2.0 と IIS 7.0 のコア機能の設計と開発を推進してきました。現在は、IIS 7.0 と Windows Server 2008 を使用した高パフォーマンス Web ファームのための高度な Web サーバー テクノロジを開発しています。Mike は『Internet Information Services (IIS) 7.0 Resource Kit』の主執筆者であり、MSDN Magazine への寄稿や自身の IIS 7.0 ブログ (mvolo.com) への投稿も活発に行っています。


モビリティ
基幹業務アプリケーションをモバイルで使用できるようにする
Matt Fontaine
概要 :
  • モバイル LOB アプリケーションに対するビジネス ニーズ
  • mLOB の開発と展開のための堅牢なプラットフォーム
  • モバイルのセキュリティ、管理、および準備

目次
リモートでの作業を可能にし、リモート ワーカーを管理する
セキュリティとデバイスの管理
相互運用性
IT とユーザーの生産性
開発と配布
まとめ
現在、多くの企業は従来の通話機能、メッセージング機能、および生産性を高める機能だけでなく、オフィスで使用している基幹業務 (LOB) システムにモバイル ワーカーが
モバイル LOB (mLOB) アプリケーションからアクセスできることを求めています。通常、その対象となるシステムには顧客関係管理 (CRM)、エンタープライズ リソース プランニング (ERP)、ビジネス インテリジェンス (BI)、財務、会計用のアプリケーションなどがあります。当然ながら、mLOB 機能を実現すると、モバイル ユーザーは機能豊富な業務アプリケーションにアクセスして、移動中でもリアルタイムでデータを操作できるので、販売にかかる時間が短縮し、顧客満足度が向上し、ビジネス生産性が向上します。典型的なビジネス シナリオには次のようなものがあります。
  • 営業チームは Microsoft Dynamics™ CRM Mobile を使用して、どこからでも顧客データを閲覧したり、更新したりできます。別の mLOB アプリケーションを使用すれば、リアルタイムの価格データや在庫データにアクセスできます。さらに、営業部員は専用のデバイスを使用して、注文書の入力から署名の収集に至るまでの販売資料をその場で収集できます。実際、Windows Mobile® デバイス用の店舗販売時点管理アプリケーションもあります。このアプリケーションでは、バー コードをスキャンしたりクレジット カードを読み取ったりすることが可能で、バックエンドの LOB データ システムに接続して情報を処理できます。
  • 従業員の予定と現在地に基づいて移動経路を設定する ERP ソリューションを使用すると、現地サービスを行う従業員のスケジュールを設定できます。また、GPS 対応の Windows Mobile デバイスを使用すると、自動的に従業員の居場所を追跡できます。現地サービスを行うスタッフは、その日の最初の仕事だけを受信し、その仕事が完了すると次の仕事が自動的に割り振られます (図 1 参照)。
  • 製造業の企業では、無線 IC タグ (RFID) に対応した倉庫で、RFID スキャン機能を搭載した Windows Mobile デバイスを使用して在庫を管理し、すぐにデータベースに情報を格納することができます。また、危険度の高い作業環境向けに、耐久性の高い Windows Mobile デバイスや "本質的に安全" だと認定された Windows Mobile デバイスもあり、安全性の重要な要件を満たし、かつ必要な場所にデータを送信できます。
  • モバイル デバイスを使用する役員は、1 日のうちに (おそらく本社から遠く離れた場所で) 開催される顧客との会議、役員会議、報道機関向けのイベントになど出席する場合、どこにいても、会計報告、経費報告書、または顧客情報を入手できます。
このようなビジネス シナリオやその他多くのビジネス シナリオによって、最先端の企業が mLOB アプリケーションを採用するようになっています。この記事では、Windows Mobile と Mobile Device Manager を連携することで、IT プロフェッショナルが現代の企業でますます需要が高まっている豊富なモバイル機能をどのように展開できるようになるかについて説明します。
図 1 完了した現地サービスの仕事を表示している mLOB アプリケーション

リモートでの作業を可能にし、リモート ワーカーを管理する
Windows Mobile はさまざまな業界でリモートでの作業を可能にする強力なプラットフォームであることが証明されています。というのも、Windows Mobile は既存の Windows® ベースの IT 資産と問題なく連動し、そのモバイル メッセージングとユニファイド コミュニケーション (UC) は Exchange Server と Office Communications Server によって提供され、そしてその操作性は Windows と同様なのでユーザーと IT プロフェッショナルの両者が Windows Mobile を使用および理解するのに必要なトレーニングが少なくて済むからです。
Mobile Device Manager のリリースによって、Windows Mobile はビジネス環境でモバイル デバイスを展開する手段として、いっそう魅力的な選択肢となりました。Mobile Device Manager を使用すると、Active Directory® とグループ ポリシーによって、モバイル デバイスをネットワークで接続された PC やファイル共有と同様に、モバイルで準備、管理、およびセキュリティ保護することができます。ポリシーとソフトウェアは自動的に電話に適用されます。また、セキュリティ、ソフトウェア、およびハードウェアのポリシーは、高度なインベントリ レポート機能を使用して非常に細かく管理できます。
このような技術革新の根底には、モバイル デバイスは独自のミドルウェアの世界に閉じこもるのではなく、IT システムが発展した先にある自然なものになるのが理想的だという考えがあります。企業が Windows Mobile デバイスでメッセージング、通信、および基本的な生産性を実現する機能以上の機能を手に入れることを望んでいる場合は、モバイル デバイスをネットワーク上の重要な資産として捉えることが非常に重要です。
では、皆さんが基本的な機能からの前進を望んでいる企業に所属しているとしましょう。その場合は、Windows Mobile と Mobile Device Manager の機能を使用すると、mLOB アプリケーションに最適なプラットフォームを利用できるのでこの前進を実現できます。次は、このことについて説明します。

セキュリティとデバイスの管理
mLOB アプリケーションが魅力的なのは、顧客、財務、在庫に関する業務上重要な情報に、時間と場所を選ばずアクセスできる機能があるためですが、同時にこのような機能によってセキュリティを確保するのが困難になります。ユーザーは、小型のデバイスを使用して、さまざまな場所のパブリック ネットワーク経由で、このような情報を入力したり、アクセスしたりします。
多くの企業では、仮想プライベート ネットワーク (VPN) 接続を使用したラップトップから、イントラネット上の他の共有リソースやツールだけでなく、LOB アプリケーションにもモバイルでアクセスできるようになっています。Mobile Device Manager では、モバイル VPN を使用して、この機能を Windows Mobile デバイスに拡張します (図 2 参照)。Mobile Device Manager ゲートウェイ サーバーによって、Windows Mobile とネットワークの間で IPsec で暗号化されたトンネルが使用できるようになり、インターネットやワイヤレスのパケット データ ネットワークなど公共の接続経由で企業のファイアウォールの内側にある情報に安全にアクセスできるようになります。Windows Mobile では、この設定で複数の暗号化をサポートしています。
図 2 Mobile Device Manager を使用した詳細なデバイスの管理、セキュリティ、およびモバイル VPN (画像をクリックすると拡大表示されます)

相互運用性
デバイスやメモリ カードに格納されているデータに暗号化のポリシーを設定して適用することができます。mLOB アプリケーションを使用する従業員は機密情報を自分のモバイル デバイスにダウンロードすることがありますが、モバイル デバイスは他のネットワーク デバイスよりもずっと紛失しやすいものです。さいわい、モバイル VPN に対応したデータ接続があるすべてのデバイスに対してリモート デバイス ワイプを実行できます (図 3 参照)。たとえば、製薬会社の営業担当者が顧客のファイルを自社の CRM システムから自分のモバイル デバイスにダウンロードしている場合に、そのデバイスをタクシーに置き忘れると、深刻な問題につながることがあります。
図 3 モバイル デバイスが紛失または盗難に遭った場合にデバイス上の情報をリモートから削除できる (画像をクリックすると拡大表示されます)
Mobile Device Manager はこのような問題に対応できるように設計されています。実際、Mobile Device Manager を使用すると、特定のハードウェア機能の無効化から、インストールできるアプリケーションの制御、特定のネットワーク リソースへのアクセス制限まで、Windows Mobile デバイスの機能とユーザー ポリシーのほぼあらゆる側面を管理できます。これらの作業はすべて 1 つのソリューションから実行でき、すべてモバイルで実行できます。ユーザーが mLOB 機能を使用している場合、このような機能はさらに重要になります。たとえば、ユーザーが Bluetooth ネットワークを使用できないようにして、制御されていないデバイスにデータをダウンロードできないようにすることが可能です。また、特定のユーザーだけがモバイル対応の会計ソフトウェア クライアントをインストールできるようにして、必要なユーザーにだけ自動的にアップロードとインストールが行われるように設定することができます。
関連リソース
  • Microsoft System Center Mobile Device Manager 2008
  • Microsoft System Center Mobile Device Manager 2008 の概要
  • Microsoft System Center Mobile Device Manager 2008: テクニカル ホワイト ペーパー
  • Microsoft System Center Mobile Device Manager 2008: ビジネス ユーザー向け概論
  • Windows Mobile Line of Business Solution Accelerator 2008
さらに、Mobile Device Manager では、可用性やセキュリティに問題を引き起こす可能性があるサードパーティ製のネットワーク運用センター (NOC) に、企業のデータを渡す必要がありません。基本的に、Mobile Device Manager を使用すると、ほぼあらゆる規模のモバイル デバイスの展開を完全に制御できるので、mLOB 機能の展開、管理、およびセキュリティ保護を簡単に実行できます。
ネットワークの統合によって、もう 1 つのメリットが生じます。この非常にきめ細かい制御はすべて Active Directory とグループ ポリシーによって行われるので、モバイル デバイスを他のネットワーク クライアントと別個に管理する必要がありません。ですから、コストと時間を大幅に節約できます。しかし、最も重要な点は、一貫したセキュリティ ポリシーとアクセス ポリシーを採用できることです。グループ ポリシーを使用すると LOB データへのモバイル アクセスを非常に効率よく制御できます。アクセスが必要なユーザーには簡単にアクセスを提供でき、アクセスが不要なユーザーについては個別または一括で制限できます。
mLOB の展開 (およびモバイル デバイス全般) を管理する際のもう 1 つの大きな検討事項は、既存のインフラストラクチャとの相互運用性です。Windows Mobile とは異なり、モバイル デバイスのオペレーティング システムには他の IT 資産の形式との接点がなく、独自の言語、サーバー、およびツールが必要なものがあります。複雑なアプリケーションや重要なデータ アクセスをモバイル デバイスで使用する場合、これらの要素はますます重要になります。
Windows Mobile と Mobile Device Manager は、そのような相互運用性を備えています。Windows Mobile は Windows OS なので、Microsoft® Exchange Server、Microsoft Forefront™、SQL Server®、Microsoft Office Communications Server など他の Windows ベースの IT 資産と問題なく連動します。このような製品ファミリ内の相互運用性によって、最先端の mLOB 機能を簡単に設計して構築できます。
たとえば、Windows Communication Foundation (WCF) はアプリケーション間の通信を可能にする Microsoft .NET Framework テクノロジですが、WCF によって、サービス指向アーキテクチャ (SOA) を使用している mLOB の実装で、Exchange Server をメッセージの送受信ユーティリティとして使用できます。ときどきしか社内ネットワークに接続しない従業員が最新情報を入手するには、新しい Sync Framework を使用できます。Sync Framework によって、SQL Server Compact 3.5 を使用している Windows Mobile デバイスのデータと SQL Server 2008 上の企業データを簡単に同期できます。数多くの既存のネットワーク リソースと連携するモバイル インフラストラクチャがない場合、このようなシナリオを実現するのは難しいでしょう。

IT とユーザーの生産性
生産性の向上は mLOB を展開する際の重要な目標です。しかし、機能が難しすぎてユーザーが使用できず、IT プロフェッショナルが管理できなければ、コストがメリットを上回るか少なくとも投資収益率 (ROI) が減少するでしょう。Windows Mobile の開発目的はデスクトップの場合とできる限り同じ Windows エクスペリエンスを実現することです。このようなエクスペリエンスを実現することで、すべての関係者にとってソリューションの価値が高まります。
IT の側から見ると、Mobile Device Manager を使用した Windows Mobile は、Windows Mobile デバイスがネットワークのメインストリームに参加できるように設計されています。これは、使い慣れているテクノロジ、具体的には Active Directory と Windows Server® を使用することで実現しています。Mobile Device Manager は IT 管理ソリューションである System Center ファミリ製品の一部で、世界中の多数の IT プロフェッショナルが使用しています。Windows ベースの環境に精通した IT プロフェッショナルは、一連の新しいツールとその使い方をゼロから学習しなくても、既に使い方を把握している Microsoft 管理コンソール スナップインを使用できます。
同じことがユーザーにも当てはまります。Windows Mobile はデスクトップと同じように使用できるので、ユーザーが簡単に理解できます。Office Mobile Outlook® を含む Office Mobile スイートを使用すれば、新しいアプリケーションを学習する必要なく作業を実行できます。デバイスの管理は一元的に行われるので、ユーザーが気にする必要はありません。mLOB アプリケーションは、ユーザーが使い慣れている同じプログラムのデスクトップ版と同じように動作するように設計できるので、一般的な Windows ソフトウェアと同様に動作するように新しいツールを構築できます。このようにユーザーが簡単に使用できるので、サポートへの問い合わせが減り、発生する問題の深刻さが低下します。ですから、これは IT プロフェッショナルにとっても朗報です。
生産性の向上につながる Windows Mobile と Mobile Device Manager のプラットフォームの側面は他にもあります。モバイル VPN によって、高速な再接続機能が確保されるだけでなく、異なるネットワーク間でもシームレスで切断しにくい接続が確保されるので、ユーザーは必要なときに接続できるようになり、ヘルプ デスクに対するよくある問い合わせの原因がまた 1 つ減ることになります。Windows Mobile では複数のデバイス フォーム ファクタがサポートされています。これにより、企業は少数のデバイスに標準化できる一方で、従業員は引き続き各自のニーズに合ったデバイスを選択できます。さまざまなデバイスを使用できることで、バー コードによる在庫管理や GPS 対応のデバイスによる移動経路の設定など、生産性を向上する mLOB シナリオも可能になります。

開発と配布
豊富なデータ、高い処理能力、および特殊化した機能という LOB アプリケーションに付随する性質は、アプリケーション ベースの生産性が向上するように設計されたモバイル プラットフォームで最も効果を発揮する傾向があります。Windows Mobile ではモバイル ワーカーがデスクトップと同様のエクスペリエンスを利用できるので、mLOB アプリケーションの開発、配布、および管理が簡単になります。
まず、Windows Mobile では .NET Compact Framework というバージョンの .NET をサポートしています。.NET Framework は世界中の数百万人もの開発者が使用しているプログラミング ツールなので、多くの IT 部門では Windows Mobile に対応するように mLOB アプリケーションをカスタマイズしたり作成したりする開発スキルを社内で保有しています。社内に開発スキルがなくても、市場で簡単にこのようなスキルを入手することもできます。
また、Windows Mobile では市販されている数多くの mLOB アプリケーションをサポートしています。マイクロソフトでは Microsoft Dynamics 製品ファミリの一部として、Microsoft Dynamics CRM Mobile、Microsoft Dynamics AX Mobile Sales などの mLOB ソリューションを提供しています。また、Microsoft Dynamics Mobile Development Tools を使用すると、開発者はソフトウェアをモバイル環境対応にするテクノロジを利用できます。マイクロソフトは他の Microsoft Dynamics ソリューションをモバイル対応にすることに取り組んでおり、近日中に Microsoft Dynamics NAV のサポートが開始されます。さらに、SAP、Siebel、PeopleSoft、SalesForce.com など、主要な LOB ソリューションのほとんどでは、Windows Mobile と互換性があるバージョンのアプリケーション スイートが提供されています。
mLOB アプリケーションを購入または開発したら、Mobile Device Manager と Windows Server Update Services 3.0 を使用してモバイルで展開して管理できます。グループ ポリシーを使用すると、アプリケーションを受信するデバイスやデバイスからアクセスできる機能を設定できます。アプリケーションを更新する場合も同様に簡単な方法で実行できます。

まとめ
従業員や役員が mLOB アプリケーションを使用している企業の数は増加しています。このため、IT システムの展開と管理の担当者が考慮すべき問題も増加しています。Windows Mobile と Mobile Device Manager は、ネットワークに対応したモバイル デバイスの構想を実現し、mLOB を開発して展開するための管理しやすいプラットフォームを提供します。このプラットフォームによって、セキュリティとユーザーの生産性が最大限に高められるだけでなく、IT 部門の頭痛の種とインフラストラクチャへの投資を最小限に抑えられます。また、Mobile Device Manager を使用すると mLOB の展開を多数のユーザーに拡大することができるので、ユーザーあたりの ROI が増加する一方で、mLOB の開発と展開にかかるユーザーあたりのコストが削減されます。このように、Mobile Device Manager を使用すると Windows Mobile を簡単に管理できるので、運用方法に悩むことなく、mLOB アプリケーションの最も効果的な活用方法について独創的に考えられるようになります。

Matt Fontaine はワシントン州シアトル在住のライターであり、コンサルタントでもあります。彼は、ハイ パフォーマンス コンピューティング、エンタープライズ ソフトウェア、生命保険、商業用不動産、エンジニアリング、建設、一般消費財など、さまざまな業界に応対しています。Matt は、エバーグリーン州立大学の名誉ある卒業生です。


セキュリティ
共有アカウントのパスワード管理について
Chris Stoneff
概要 :
  • 特権アカウントのパスワードを共有するリスク
  • パスワードの格納方法
  • 共有パスワードの管理と保護
  • 規制遵守

目次
問題を理解する
長いほど良い
ドメインによる侵害
弁明
規制策定者の意図
自動化によるアプローチ
検討事項
管理者が対応に追われているもので一般的なものの 1 つに、共有している特権アカウントのパスワードを定期的に変更する作業があります。
たとえば、Administrator アカウントや root アカウント、Firecall アカウント、プロセス アカウントなどです。組み込みの Administrator アカウントまたは root アカウントは、Windows®、Linux、および UNIX のすべてのバージョンに組み込まれているアカウントで、常に同じセキュリティ ID (SID) またはユーザー ID (UID) を持っています。Firecall アカウントは、セキュリティで保護されたシステムに対して緊急にアクセスが必要な場合に使用できるアカウントです。このような Firecall アカウントや Administrator アカウントは、特権のないユーザーが、問題発生時に主要システムにアクセスするのに使用することがあります。プロセス アカウントは、サービス、タスク、COM+ アプリケーション、埋め込みアイテム (スクリプトやログインが必要な他のバイナリ ファイル) の実行に使用するアカウントです。
現在、多くのシステムはインストール スクリプトやイメージを使用して展開されています。また、ワークステーションやサーバーでは、Administrator という同じ名前のアカウントと同じ 8 文字のパスワードが使用されていて、そのパスワードは、おそらくシステムの展開時に設定してから一度も変更されていないでしょう。そのため、複数形の passwords ではなく単数形の password を使用しました。
ベスト プラクティスに従って、または規制遵守の一環として、このようなアカウントのパスワードを変更せざるを得ない状況に追い込まれている管理者もいるでしょう。たとえば、このような規制遵守の対象になるものには、米国企業改革法 (SOX)、クレジット カード業界 (PCI) のセキュリティ基準、または医療保険の相互運用性と説明責任に関する法律 (HIPAA) などがあります。このようなアカウントのパスワードを把握している管理者や技術者が退職したときには、セキュリティ侵害やクレジット カードを処理できなくなる危険性を恐れて、パスワードを変更することがあります。このような要因はありますが、企業自体のセキュリティと保護する必要がある企業データのセキュリティを確保できるかどうかは、管理者がこのようなアカウントのパスワードを変更するかどうかにかかっています。

問題を理解する
このようなアカウントとパスワードを管理する際には、次の 3 つの事項を理解しておく必要があります。
  1. パスワードが古くなると、パスワードの安全性が弱まります。
  2. 一般的に、パスワードは長いほど、解読するのが難しくなります。
  3. コンピュータがドメインに属しているだけでは、コンピュータの認証方法は変わりません。すべてのドメインは、ワークグループという概念に基づいています。
「パスワードが古くなると、パスワードの安全性が弱まります」という表現は誤解を招く可能性があります。これは、「コンピュータに侵入する意思がある場合、それを実現するのに必要なのは時間だけです」という意味です。「パスワードを解読するには、どれくらいの時間がかかりますか」という質問に対する明確な回答はありませんが、次の質問は、特定のシステムのパスワードを解読するのに必要な時間を特定するのに役立ちます。
  • そのパスワードは何人の人が把握していますか。
  • そのパスワードを把握している人は、現在も在籍していますか。
  • そのアカウントのパスワードを把握している人が退職している場合、その人は円満に退社しましたか。
  • フロッピー ディスク、CD ドライブ、DVD ドライブ、またはネットワークからブートするアクセス許可を拒否していますか。
  • コンピュータのユーザーは、ローカルの Administrators グループのメンバですか。
  • 社内の全システムの特権アカウントで同じパスワードを使用していますか。
まずは、1 つ目の質問から見てみましょう。秘密を知っている人が多ければ多いほど、その秘密が公知となる可能性は高くなると言えます。私は、共有しているパスワードに同じ値を設定して、IT スタッフと研修中のスタッフに、そのパスワードを通知した方が、パスワードを要請されたときに、その都度入力するよりも都合がよいと思っている管理者がいる企業で働いたことがあります。当然の結果ですが、このようなことを続けていくうちに、その企業では、承認されていない設定を使用しているコンピュータが増え、通常のネットワーク ユーザーが、このような特権アカウントでログインできるようになりました。
このようなパスワードを把握している人が全員退職していなくて、会社に対する満足度と忠誠心が高ければ、このアクセスによる危険性は多少軽減されます。けれども、対処しなければならない悪意のあるユーザーはいつ現れるかわかりません。パスワードを把握しているユーザーが仲たがいした状態で退職した場合、このアカウントを使用してネットワークに入り込む方法を把握している規制できない悪意のある分子を抱えることになります。
ハード ドライブ以外のデバイスからブートするアクセス許可を拒否していない場合、Windows PE などの承認されていないイメージを使用してブートしたり、コンピュータのファイル システムから直接読み取って、セキュリティで保護されたコンピュータの記憶域にアクセスできるさまざまな Linux システムを使用してブートしたりするのを許可することになります (多くのセキュリティ侵害は、内部的な要素に起因しています。全スタッフと研修中のスタッフが現在も会社で働いていたとしても、パスワードとシステムのセキュリティが確保されていることの保証にはなりません)。
前任者のアカウントを使用してログインできるという理由で、そのアカウントを使用してネットワークにログインしている人は少なくありません。単にシステム パスワードを変更しないという悪習を指摘してるだけだと考えれば興味深いことかもしれませんが、このようなユーザーが悪意を持っていた場合、ユーザーがシステムに対して及ぼす可能性のある損害を考えると恐ろしことでもあります。
DVD ドライブやネットワークからのブートを許可すると、ユーザーの操作を監査できなくなります。たとえば、Linux のブート ディスクやネットワーク イメージを使用すると、ファイル システムに直接アクセスできることがあります。複数のシステムで特権アカウントに同じユーザー名とパスワードを使用している場合、そのシステムには大きな欠陥があることになります (ただし、これらの項目については、後で詳しく説明します)。
適切なパスワードの有効期限と長さは、パスワードの解読に使用する方法によって異なります。強引な方法を使用したパスワードの解読に対応する場合、問題となるのは時間です。パスワードの変更頻度が低いほど、パスワードを解読しようとしているユーザーがパスワードを取得するのにかけられる期間が長くなります。
また、長いパスワードを使用すると、パスワードには、さまざまな文字が含まれるようになるので、パスワードの解読には時間がかかります。パスワードの長さが 7 文字以下であるのか、8 ～ 14 文字であるのか、または 15 文字以上であるのかは重要な検討事項です。パスワードが 15 文字以下で Windows を使用している場合は、システム構成またはグループ ポリシーで、LAN Manager (LM) ハッシュを無効にしていますか。
パスワードの長さが、どのようなものに影響があるのかについてですが、Windows の場合は明快です。マイクロソフトのハッシュ処理についての歴史は省略しますが、マイクロソフトでは、LM ハッシュとメッセージ ダイジェスト 4 ハッシュ (MD4) という 2 種類のハッシュを採用しています。マイクロソフトでは、既定で LM ハッシュを使用します。ハッシュの格納を明示的に無効にしない限り、すべてのパスワードの値は 14 文字まで格納されます。格納される 14 文字のパスワードは、2 つの 7 文字の値で構成された文字列に分けられます。1 つ目の文字列は前半の 7 文字で、2 つ目の文字列は後半の 7 文字です (図 1 参照)。
図 1 ハッシュ テーブルの例
アカウント名 | RID | LM ハッシュ | NT ハッシュ | パスワード | 説明
Administrator | 500 | aad3b435b51404ee: aad3b435b51404ee | 31d6cfe0d16ae931: b73c59d7e0c089c0 | 空白のパスワード | LM ハッシュは、長さが 20 文字のパスワードの LM ハッシュと同等です。
Administrator | 500 | 0182bd0bd4444bf8: aad3b435b51404ee | 328727b81ca05805: a68ef26acb252039 | 7 文字のパスワード = 1234567 | 前半の 7 文字を表している 1 つ目の文字列は、8 文字のパスワードと同等です。
Administrator | 500 | 0182bd0bd4444bf8: 36077a718ccdf409 | 0182bd0bd4444bf8: 36077a718ccdf409 | 8 文字のパスワード = 12345678 | 前半の 7 文字を表している 1 つ目の文字列は、8 文字のパスワードと同等ですが、2 つ目の文字列は異なります。
Administrator | 500 | aad3b435b51404ee: aad3b435b51404ee | b79d07c2ecb3d565: 033ece663f5a0b2e | 20 文字のパスワード = 9876543210 9876543210 | 14 文字以上のパスワードでは、LM ハッシュを作成できないので、LM ハッシュは空白のパスワードと同等です。
Fred | 1221 | e52cac67419a9a: 224a3b108f3fa6cb6d | 8846f7eaee8fb117: ad06bdd830b7586c | 同じ | この 3 つの例では、LM ハッシュと NT ハッシュが同じです。つまり、これらのアカウントのパスワードは同じということになります。マイクロソフトでは、ハッシュ アルゴリズムを変更することはありません。
Monday | 1385 | e52cac67419a9a: 224a3b108f3fa6cb6d | 8846f7eaee8fb117: ad06bdd830b7586c | 同じ
SvcAcctX | 1314 | e52cac67419a9a: 224a3b108f3fa6cb6d | 8846f7eaee8fb117: ad06bdd830b7586c | 同じ
このようにパスワードの長さが 7 文字しかないと、パスワードは単一の LM ハッシュに格納されることになります。マイクロソフトでは、何年にもわたって、8 文字以上のパスワードを使用するように推奨してきましたが、その理由は、パスワードが 2 つの LM ハッシュ値に分けられるには、パスワードの長さが 8 文字以上である必要があるからです。
ただし、LM ハッシュは、一般的に知られているので、簡単に裏をかくことができるという点に注意する必要があります。現在、LM ハッシュは、旧バージョン (Windows NT® 4.0 などの下位レベル システム) との互換性を確保するために使用されています。
理想としては、より長いパスワードを使用するのが望ましいですが、現時点では、少なくとも LM ハッシュが作成されない 15 文字以上のパスワード (厳密には、パスフレーズ) を使用することをお勧めします。ご使用の環境で 15 文字以上のパスワードの使用を義務化するのが適していない場合は、イメージ作成処理 (ローカル ポリシーを使用) と Active Directory® グループ ポリシーの両方で LM ハッシュの格納を無効にすることをお勧めします。
このポリシーは、[コンピュータの構成\Windows 設定\セキュリティの設定\ローカル ポリシー\セキュリティ オプション] にあります。"ネットワーク セキュリティ: 次のパスワードの変更で LAN Manager のハッシュの値を保存しない" ポリシーの設定を [有効] に設定します。
大文字と小文字の使用だけでなく、数字や特殊文字の使用を検出するポリシーを適用すると良いでしょう。また、可能であれば、パスワードの文字数が 15 文字以上であるかどうかを検出するポリシーを適用することをお勧めします。

長いほど良い
現在、コンピュータへの侵入に使用する手法に、レインボー テーブルと呼ばれるものがあります。この手法では突破口として LM ハッシュを使用しますが、長いパスワードを使用すると、レインボー テーブルの有効性を無効にできます。
セキュリティの専門家であるはずの管理者が、レインボー テーブルについて、ほとんど知らない (または、まったく知らない) という事実には驚きました。レインボー テーブルの作成方法はさまざまですが、対象のアルゴリズムによって異なります。しかし、レインボー テーブルは単に 0 ～ 14 文字の LM ハッシュ値を事前に計算した一覧にすぎません。
レインボー テーブルを使用した攻撃の対策では、攻撃者が LM ハッシュを取得しなければならないという点を利用できます。このことは、許可しているシステムのブート方法 (CD、DVD によるブートを許可しているかどうか)、ユーザーがローカルの Administrators グループのメンバであるかどうか、という質問と関連があります。このような LM ハッシュは、pwdump などのフリーウェアを使用して、ものの数秒で取得できます。レインボー テーブルを使用した攻撃では、取得した LM ハッシュを検索して、パスワードを特定します。
私の個人的な好奇心を満たすために、システムの組み込みの Administrator アカウントにパスワードを設定しました。このパスワードは 14 文字にし、さまざまな大文字と小文字の文字だけでなく、特殊文字と数字を含めました。インターネットから無料でダウンロードしたレインボー テーブルを使用すると、システム上の全アカウントのパスワードのハッシュ値を取得することができ、Administrator のパスワードの解読には 2 分もかかりませんでした。
1 つ目の LM ハッシュ値を取得し、2 つ目の LM ハッシュ値を取得後、これらの値を組み合わせてパスワードを入手する処理を見るのは、かなり興味深いものでした。繰り返しになりますが、これより前の部分で説明したようにグループ ポリシーを使用して LM ハッシュを無効にしていれば、この攻撃を完全に阻止することができなかったとしても、大幅に制限することができます。

ドメインによる侵害
ドメインに参加しても問題は解決しません。というのも、ドメインに参加しているコンピュータの認証方法も同じだからです。繰り返しになりますが、すべてのドメインはワークグループの概念に基づいています。しかし、これは、必ずしも理解しやすいものではありません。このテーマについては多くの雑談を交わしましたが、私は管理者に対して、「コンピュータへのアクセスに必要なものはユーザー名とパスワードである」ということを頻繁に指摘していることに気付きました。このことを踏まえて、ワークグループにおける Windows の機能について説明しましょう。
システムにアクセスするときには、リモート システムにユーザー名とパスワードを提示する必要があります。Windows では、統合認証を使用して、この処理が行われます。つまり、別の Windows システムにアクセスする際には、現在ログインしているユーザー名とパスワードが使用されるということです。ですから、リモート システムに同じユーザー名とパスワードが格納されていれば、別の Windows システムにアクセスする際にユーザー名とパスワードの入力を求められることはありません。
これは「パススルー認証」と呼ばれることがあり、ワークグループ内だけでなく、ドメイン間でも機能します。ただし、最悪の場合は、システムからユーザー名とパスワードが要求されることがあります (つまり、ログイン情報を再入力する必要があります)。
ワークステーションやサーバーをドメインに追加し、Active Directory が中央アカウント リポジトリになっても、ローカルのセキュリティ アカウント マネージャ (SAM) やローカルのアカウント ストアが消えてなくなるわけではありません。このようなローカル SAM に生じる変化は、SAM が管理とセキュリティ保護の対象から外れて、問題の要因となることです。システムの組み込みの Administrator アカウントや root アカウントのパスワードを最後に変更したのは、いつですか。できたら、すべてのアカウントのパスワードの有効期間を確認できるレポート ユーティリティをダウンロードして、その結果が監査に合格するかどうかを確認してみてください。
意味がよくわからない場合は、任意のドメイン ワークステーションに、管理者特権のあるドメイン アカウントを使用してログオンしてください。システムでコンピュータの管理ユーティリティを起動し、ToldYouSo という名前のローカル ユーザーを作成します。このアカウントのパスワードを設定したら、このアカウントをシステムのローカルの Administrators グループに追加します。それから、別のドメイン ワークステーションでも、同じ手順を実行します。
どちらかのワークステーションに、ローカル アカウント ToldYouSo でログオンし、\\systemName\c$ というパスを使用して、もう 1 台のコンピュータにアクセスします。このようにすると、管理用共有にアクセスすることが可能で、しかもパスワードの入力を求められることもありません。この例に皆さんが驚いていないことを願います。この例に驚いた方がいる場合は、ぜひ、ここから学んでください。再度、繰り返しになりますが、システムがドメインに参加していても、システムがワークグループに参加しているときと同様に動作するという事実は変わりません。
共有している特権アカウントのパスワードをめったに変更しない場合、そのアカウントは危険にさらされていることになります。このような場合、ネットワーク全体を侵害するのに必要なのは時間だけです。

弁明
管理者と話をすると、その人が CIO であっても、このようなアカウントのパスワードを変更しない主な理由として、次のようなことを挙げています。
  • 何千台ものシステムがあるので、これらのアカウントのパスワードを変更する時間的な余裕と人的な余裕がない。
  • 必要な予算がない。
  • Administrator アカウントを完全に無効にしているので問題ない。
  • これまでにシステムが侵害されたことはないので、パスワードを変更しないことは問題ではない。
  • 監査担当者がパスワードを変更していないことに気付かない。
最初の 2 項目については声を大にして言いますが、これらは正当な弁明にはなりません。どのような理由であれ、この問題に対応していない企業が私の個人情報を保持している可能性があると考えるとぞっとします。
ネットワーク上のすべてのシステムに機密情報が格納されているわけではありませんが、このようなシステムのユーザーは、社会保険番号、医療記録、財務データなどの機密情報にアクセスできる可能性があります。システムの管理者であれば、キー ロガーや画面をキャプチャするユーティリティをインストールしたり、グループ ポリシーを無効にしたり、さまざまなサブシステムに shim を導入してデータを取得して転送したりすることが可能です。悪意のあるユーザーが、このようなことを個人コンピュータ レベルで行っている場合は、Administrator というアカウントを使用するので、このようなユーザーを特定するのは困難です。
Windows で組み込みの Administrator アカウントを無効にしても、このアカウントを使用してログオンできなくなるわけではない、ということはご存じですか。次の例を試してみてください。システムをセーフ モードで再起動し、組み込みの Administrator アカウントでログオンします。この場合、おそらく、オリジナルのイメージでアカウントに与えられたパスワードを使用してログオンできます。この動作の詳細については、マイクロソフト サポート技術情報の資料「[HOWTO] Administrator アカウントを無効にした後でコンピュータにアクセスする方法」(support.microsoft.com/kb/814777) を参照してください。

規制策定者の意図
SOX、PCI、HIPAA などの規制に対応するのは、目が回るような作業です。各規制は拡大解釈が可能で明確に定義されていないので、その要件を理解するのは困難です。ですが、このような規制では、概してこれから述べるようなことを目的としていると言えます。
まず、特権アカウントと情報に常時アクセスできるユーザーを保証し、これを実現するための手段を提供する必要があります。これは、どのような場合においても適切な対応です。というのも、特権アカウントは、任意のシステムであらゆる処理を実行する権限を持っているアカウントだからです。それが組み込みの Administrator アカウントと Firecall アカウントです。これらのアカウントは、おそらくヘルプ デスクのスタッフ全員と管理者全員が把握しています。
このような共有アカウントのパスワードを管理するソリューションを実装するということは、組み込みの Administrator アカウントの監査証跡をゼロから作成するようなもので、流動的なパスワードを使用できるようになります。ソリューションは自動化されるので、このようなアカウントのパスワード変更に何週間もの時間をかけて生産性が低下することはありません。また、このソリューションでは監査機能が提供されるので、最終的に、企業では監査の合格率が高まります。

自動化によるアプローチ
このようなアカウントに対応する最も効率的な方法は、複数のアカウントで同じパスワードを共有することがないように、アカウントを定期的に変更することです。共有のパスワードを使用している場合、あるシステムが侵害されると、別のシステムも侵害されることになるでしょう。ですから、共通のローカル アカウントやドメイン アカウントは存在しないようにすることをお勧めします。
このようなアカウントのパスワードを管理して、無作為な文字列を割り当てる自動化されたソリューションを使用する際には、監査担当者から最低条件として課せられているものだけを対象にするのではなく、それ以上の条件も対象とすることをお勧めします。15 文字、20 文字、127 文字のように長いパスワードを設定できる (図 2 参照) 場合に、何の努力もしないで 8 文字のパスワードを使用するのは適切ではありません。
図 2 非常に長いパスワードを自動的に作成する機能を使用する (画像をクリックすると拡大表示されます)
また、図 3 に示すように、特権アカウントは毎日ランダムに変更することをお勧めします。90 日ごとに実行しなければならない理由はないので、隔月または毎日実行できる場合は、そのようにすることをお勧めします。とにかく、この処理を自動化すれば、管理者であるあなたの作業が増えることはありません。また、これを定期的に行えば、ユーザーはツールの監査対象の取得インターフェイスからパスワードを回復する必要があるので、これまでにはなかった監査証跡を実現できます (書面に記載したパスワードを封筒に入れて、オフィスの片隅にある金庫に保管している場合、そのようなパスワードについては、パスワード管理ソリューションを使用した場合のような監査証跡を得ることはできません)。
図 3 特権アカウントを毎日ランダムに変更する (画像をクリックすると拡大表示されます)
パスワードを回復したら、一定期間経過後に、そのパスワードを再度ランダムに設定できることを確認します。ここでは先ほどのスケジュール設定したアトランダムなジョブではなく、(数か月ではなく数時間だけ有効な) 1 回限りのパスワードの作成について話しています。この場合も、ユーザーは、ツールの監査対象の取得インターフェイスからパスワードを回復する必要があるので、監査証跡を実現できます。

検討事項
共通アカウントのパスワード管理に関する問題には対応する必要があります。つまり、確実かつ定期的にパスワードを変更する方法を見つける必要があります。また、このソリューションは拡張性と柔軟性を備えていて、また、パスワードへのアクセスをセキュリティで保護し、ツールとツールのユーザーによるすべての操作を監査する必要があります。さらには、共有アカウントの情報を使用したシステムの侵害を防ぐため、すべてのシステムに一意なパスワードを発行する必要があります。
この問題に長年取り組んでいるベンダは数多く存在しますが、この分野には新たなベンダも参入しています。この問題に対応するツールを購入する際には、ご自身で調査を行い、ご使用の環境に適していることを確認してから購入することをお勧めします。

Chris Stoneff は、セキュリティとシステム管理に関するソフトウェアを開発している Lieberman Software (liebsoft.com) のプロダクト マネージャです。彼を最も駆り立てるのは、物事のしくみを理解することだけでなく、なぜ物事がそういうしくみなのかを知ることです。


ここ数週間、幸運にも、働く IT プロフェッショナルとはどういうものかという再教育研修を受講してきました。夏の終わりが近づき、学校のことを思い出す時期なので、確かにふさわしい研修だったと思います。でも、正直言って、少しショックでした。
実は、ここ、マイクロソフトの Magazine チーム (MSDN Magazine と TechNet Magazine の発行を担当するグループ) が、プロセスの見直しと強化を行っている最中です。いまや 2008 年なので、紙の上でレイアウトを行ったり、色鉛筆で印を付けたりすることをやめて、完全にデジタルに移行する必要があるとようやく決断しました (そう、私たちは革新者なんです)。でも、冗談は抜きにして、大手ソフトウェア会社が盛んに宣伝しているデジタルの効果に気付く時期にきていました。
新しいデジタル ワークフローに順応する際、記事のステータスを追跡するツールが妨害となっていることがすぐに明らかになりました。このツールは既に "デジタル" でしたが、(二度と利用されないことを願う) かなり時代遅れのテクノロジに基づいて作成されており、各レイアウトの上部に色付きの小さなボックスを表示することでステータスを示していました。ハイテクなんてものじゃないですよね。そのため、この概念を実証する代替ツールの作成に取りかかり、SharePoint が理想的だと考えました。
話が飛びますが、皆さんと同じように SharePoint 管理者を尊敬するようになりました。これは SharePoint に対する非難ではありません (どちらかと言えば、SharePoint はプラットフォームの機能と柔軟性を証明しています)。でも、SharePoint でカスタム ワークフロー ソリューションを作成するのは本当に大変です (ありがたいことに、「SharePoint の内部」という新しいコラムが役に立ちます)。第一線を退いて数年たった今、自らこの課題に取り組んだことは、周囲に対するアピールとなりましたが、もう一度学校に通う必要があるようです。
世の中には、もう一度基礎を詳しく学習したり、何か新しいことに取り組んだりするのに大いに役立つリソースが溢れています。TechNet (technet.microsoft.com/cc138021) の新しい「How Do I?」ビデオ シリーズから、マガジンで提供しているスクリーンキャスト (.com/video)、TechNet Edge (edge.technet.com) まで、あらゆるリソースが役立ちます。しかし、TechNet Magazine 自体で取り上げる "基礎情報" も充実させる必要があると考えています。自慢するわけではありませんが、これまで私たちは、皆さんに知られ、(願わくば) 大好きになっていただいた詳しい内容の技術資料を提供してきたと自負しています。それでも、ときどき基礎を見直すことも大事です。では、残りの夏をお楽しみください。もうじき学校に戻らなくてはいけないのですから。—Joshua Hoffman

次のマイクロソフト技術支援スタッフに心より感謝します。Nathan Bigman、Nino Bilic、Mai-lan Tomsen Bukovec、Eric Charran、Trina Gorman、Gershon Levitz、Thomas Marquardt、Mandy Maxwell、Michael Murgolo、Sanjeev Nair、Michelle Rutzer、Jez Sadler、Jim Truher、Shimon Yannay


レター 読者の皆さんからの声

SharePoint Capacity Planning Tool
弊社の従業員数は 600 人未満ですが、多くの従業員は PC やイントラネットを積極的には使用していません。しかし、社内でのコミュニケーションとコラボレーションが一般に強く求められています。弊社の作業環境には Windows® SharePoint® Services (WSS) 3.0 が最適だと思いますが、私の上司は 1 台のサーバー分しか予算を立てていません。
SharePoint Capacity Planning Tool を使ってみようとしたのですが、1 台のサーバー モデルのシミュレーションを行うことはできませんでした。1 台のサーバー モデルのシミュレーションを行う方法をご存知ですか。
—Allen M
1 台のサーバーのシミュレーションを行う方法はないと思います。しかし、すべてのユーザー操作を考慮することなく規模を決定することは困難です。私でしたらクアドコアの CPU を使用して、8 GB の RAM から試してみます。基本的に中規模のサーバーなら、これで問題なく動作します。
Joel Oleson 氏は、サイズの決定に関する多くの参考資料を集めてブログ (blogs.msdn.com/joelo/archive/2007/07/09/capacity-planning-key-links-and-info.aspx) で公開しています。この資料は、企業のニーズに合った最適な意思決定をするのに役立つ可能性があります。
—Pav Cherny (コラムニスト、
「SharePoint の内部」担当)

Microsoft Bob
「Windows 秘話 : 歴史が空き領域を埋める」(2008 年 7 月号、technet.microsoft.com/magazine/cc565089) は、Windows XP ディスクに潜んでいる Microsoft® Bob プログラムを紹介することを目的としたコラムだったと思いますが、これはまた、このプログラムの酷評にすぎなかったのではないでしょうか。ですが、私の子供たちは、このプログラムが大好きで、コンピュータの基本的な文書処理を学ぶのに使用しました。Bob は、私たちが初めて購入した自宅用コンピュータ、Windows 95 搭載の NEC Ready に同梱されていました。そして子供たちは成長すると、Bob を使って何時間も遊んだりするようになりました。
コラムの中で、Bob は粗悪なテクノロジの製品として扱われていますが、実際はすばらしいソフトウェアで、単に「大人」という間違った市場に出荷されただけのことです。これは子供向けのソフトウェアだと思います。子供向けのソフトウェアとして紹介されていたら、違う観点で評価され、おそらく違う運命をたどったと思います。最初から子供向けのソフトウェアとして紹介されていたら、私の孫たちも楽しむことができたかもしれません。
—Jim S

印刷物の消滅
2008 年 7 月号の「編集者から : 印刷物の消滅」(technet.microsoft.com/magazine/cc595615) を読みましたが、非常に興味深かったです。個人的な意見ですが、紙ベースの情報技術に関する専門書はもうすぐ消滅して、デジタル メディアに取って代わられると思います。しかし、この記事には、アンケートに答えた 90% の読者が印刷物の方を好むという結果が記載されていました。このアンケート結果は、どちらの媒体の読者の意見も平等に反映されているのでしょうか。それとも、印刷媒体で連絡を取った人のみがこのアンケートに回答したのでしょうか。このアンケートの対象者には、新聞やそちらで発行しているような雑誌は読まず、すべての情報をオンラインで入手し、このアンケートのことなど聞いたことのない、若い世代が含まれていないように思われます。
印刷物のテキストを読んでいる人は、変動するテキストからビデオや Web キャストを再生することはできません。また、印刷されたインターネット リンクは、マウスでクリックして、ホーム ページ、ニュースグループ、ブログなどを開くことはできませんし、印刷したテキストに記載されたアドインやツールをダウンロードすることもできません。
要するに、紙ベースの書籍は、あまり役に立たない妥協の産物だということです。紙ベースの書籍を読むことのメリットは DVD を使用する場合のメリットと比べるとごくわずかです。DVD では、その全コンテンツをノート PC にコピーできるので、いつどこにいても DVD のコンテンツにアクセスできます。このことに読者が気付くのに、それほど時間はかからないと思います。
—Ulrich S
お便りとフィードバックをお寄せいただき、ありがとうございます。読者の 90% が印刷物を好むことに関するご質問についてですが、このアンケートは毎年恒例の編集調査の一環として、紙ベースではなく、オンラインで行いました。また、アンケートの対象者は、印刷物の購読者と Web の読者の両方を含んでおり、その割合はほぼ同等です。質問は紙ベースの記事とオンライン記事の両方を読んだことがあると答えた読者に対して行い、その 90% が紙ベースを好むと回答しました。
コンテンツをオンラインで公開することのメリット (豊富なメディア、グローバルなアクセス、クリック可能なリンクなど) に関してはまったく同感ですが、やはり印刷されたページで記事を読むことが、より魅力的な経験となるように感じます。私は紙ベースの方がコンテンツが読みやすく、また親しみやすいと感じますし、多くの人が同じように感じています。各媒体それぞれに長所があるので、私たちは両方の媒体を使用して TechNet Magazine を公開し続けています。改めて、ご意見ありがとうございました。
—Joshua Hoffman (編集長)


ツールボックス IT プロフェッショナル向けの新製品
Greg Steen

サーバーを監視する
Mastering SQL Server 2005 Reporting Services Infrastructure Design
sybex.com
インフラストラクチャが複雑になるにつれて、我々管理者のまわりには多くの情報があふれかえります。そういった情報のほとんどはファイルやデータベースに記録されています。しかし、そのすべての情報を理解するためには、分析エンジンと、分析されたデータを意味のある形で表すためのツールが必要です。これを行うための非常に便利なツールの 1 つが Microsoft® SQL Server® 2005 Reporting Services です。このツールを使用すると、そのすべてのデータを集約してから、人間が判読できる形式で表すことができます。また、情報をさまざまな場所に自動的に配信したり、必要に応じて、ビジネス上の意思決定を賢明に下すのに必要な、ほぼリアルタイムのデータをビジネス ユーザーに効率的に提供したりできます。
企業のニーズに応じ、企業と共に拡張される Reporting Services インフラストラクチャ (または、あらゆる新しいサーバー インフラストラクチャ) を適切に計画、展開、および管理するには、準備、専門知識、そして少しの根気が必要です。Reporting Services インスタンスの展開を検討している場合は、Joseph L. Jorden 著の『Mastering SQL Server 2005 Reporting Services Infrastructure Design』 (Sybex、2007 年) を参照してください。展開についての知識を深め、正しく運用するためのポイントを理解することができます。
この書籍では、Reporting Services 展開の技術的な詳細について説明する前に、システムの実装において忘れられがちな点について詳しく説明されています。このような点は、システムを実装する理由とビジネスで使用する要件を決定し、エンド ユーザーの期待にどう応えるかを定義することに関係します。レポート システムの管理方法を変更するための方針に関する章があります。ここでは、変更管理のさまざまな手法が取り上げられ、変更管理の要求フォームのテンプレートおよびガイドラインが提供されています。お役所仕事の利点を賞賛するわけではありませんが、ここでのちょっとした構造によって、さらに安定した環境を確保できます。
Reporting Services のビジネス面について説明した後は、展開について取り上げ、インストール、拡張、自動化、および構成の基礎について詳しく説明しています。また、Microsoft Windows® SharePoint® Services (WSS) と統合する方法に関するヒントも提供されています。最初に展開時のチェックリストが提供され、問題を回避するのに役立ちます。
SQL Server 2005 Reporting Services の便利な新機能の 1 つは、アドホック レポート機能です。この機能を使用すると、ユーザーは実行中にレポートを作成できます。この書籍では、この機能を有効にしてレポート ビルダ ツールを設定する方法について説明しています。次に、レポートのサブスクリプションを作成する方法について説明しています。サブスクリプションを使用すると、電子メール、ファイル共有、または SharePoint の統合配信を経由して、レポートをスケジュールに従って配信できます。
すべてのシステムは時間の経過と共にメンテナンスを行う必要があります。次の章では、インスタンスのバックアップ、レポート コンテンツの管理、およびログを使用した問題のトラブルシューティングなど、基本的な作業について説明しています。セキュリティについて詳しく説明している章もあり、展開の認証と承認のオプションについて取り上げています。
プログラマは、Reporting Services の拡張に関する章のほか、Microsoft .NET Framework に基づくアプリケーションを使用したレポートへのアクセスと操作に関する章を高く評価するでしょう。レポート定義言語 (RDL) は Reporting Services の基本的な側面の 1 つです。この書籍では、使用できるいくつかの重要な要素、RDL ファイルの構造、およびこうしたファイルの作成と展開の基礎に関する章に重点を置いています。
最後は、Reporting Services 展開のパフォーマンス チューニングに関するいくつかのヒントとテクニックで締めくくっています。パフォーマンスの測定、構成ファイルへの変更、およびパフォーマンス コンソールの使用に関する情報を入手できます。Reporting Services を SharePoint と統合する方法に関するすばらしい付録もあります。お使いの環境に SQL Server 2005 Reporting Services の展開を予定している場合は、この書籍を参照することをお勧めします。新たなことを始めるのにとても役立ちます。

価格 : 49.99 ドル (直販)

環境を監査する
Alloy Discovery Professional Edition
alloy-software.com
仕事を遂行し、問題のトラブルシューティングを行い、システムが最新でセキュリティ ポリシーやソフトウェア ポリシーに準拠していることを確認するためには、担当範囲の特定のシステムに関する情報をすばやく取得できることが重要です。また、こうした情報をビジネス ユーザーが理解しやすい形式にすると、インフラストラクチャをひとめで評価できるようになり、大きなメリットになります (そして、言うまでもありませんが、経営陣に好印象を与えることができます)。それだけでも十分だと思いますが、情報にすばやくアクセスすることにより、ユーザーに適切なライセンスが与えられていることを確認するために、だれがどのようなソフトウェアを使用しているかを特定することもできます。そういったインベントリと監査のツールの中でお試しいただきたい 1 つが、Alloy Software の Alloy Discovery Professional Edition です。
このアプリケーションは設定が非常に簡単で、グループまたは LAN 上の一連のコンピュータの監査をすぐに開始できます。UI によって、コンピュータが Internet Explorer® とよく似たわかりやすいビューにグループ化され、いったんグループまたは監査可能なコンピュータを設定すると、クリックするだけでグループの監査が実行されます。収集される情報は非常に広範で、ハードウェア、ソフトウェア、およびデバイスからプリンタ、共有、およびイベントにまで及びます。資産タグ、シリアル番号、稼働時間の統計情報、環境変数、ネットワーク構成、およびローカル ユーザー アカウントを表示することもできます。基本的には、お使い環境に関して知っておくべきすべてのことを、机の前から離れることなく収集できます (ご自身の健康のために、ときどき散歩することをお勧めしますが)。
必要に応じてコンピュータを監査するのとは別に、定期的に監査を実行することもできます。LAN には直接接続されていないコンピュータ、または監査タスクを実行できる特権ではリモートに接続できないコンピュータの場合、Alloy Discovery は対象のコンピュータを監査するエージェントベースの方法を提供します。この種の監査をスクリプトにし、そのスクリプトを定期的に実行するようスケジュールを設定するか、エージェントを使用して実行した後、エージェントから Alloy Discovery のメイン リポジトリに電子メールが送信されるように設定できます。もう 1 つの方法として、エージェントをフラッシュ ドライブに入れ、コンピュータのところまで行って、監査を開始する方法があります。監査を行った後、メイン リポジトリを併用する方法に応じて、情報を自動または手動で同期できます。
Alloy Discovery には、インベントリ全体を分析するため、監査結果に適用できるフィルタも用意されています。たとえば、アプリケーションをサポートするためにメモリをアップグレードする必要があるコンピュータの台数や、環境内で Windows® XP Professional と Windows Vista® Business エディションがそれぞれ実行されているコンピュータを確認することができます。
データを入手したら、レポートを作成します。アプリケーションは、HTML ページにレポートを発行し、このページでは詳細内容にドリル ダウンすることができます。スケジュールされたタスクを設定して、こうしたレポートを定期的に生成することもできます。これは、ネットワーク運用センター向けの優れたオプションです。また、たとえば、すべての監査情報を XML、CSV、または Microsoft Excel® にエクスポートして、監査担当者に証拠を見せることもできます。

価格 : 基本製品 795 ドル (直販)、各ノードにつき +3 ドル﻿
Alloy Discovery を使用して環境を監視する(画像をクリックすると拡大表示されます)

パスワードを管理する
Password Corral
cygnusproductions.com
現在のように相互接続される環境では、パスワードは避けがたい現実です (少なくとも、すべてがバイオメトリクス ベースになるまで、もしくはすべてを信頼することができるある種の理想郷がつくられるまでですが、どちらのシナリオも近い将来には実現しないでしょう)。私と同じような嗜好をお持ちなら、さまざまな環境にそれぞれ異なる種類のパスワードを設定し、こうしたパスワードをさまざまなメディア間で変えているでしょう。
通常主に使用しているパスワード以外に、管理者アカウント、サービス アカウント、さまざまなドメイン アカウント用のシステム パスワードもあります。もちろん、これらすべてのパスワードには異なるユーザー名が関連付けられています。数え上げればきりがありません。では、これらすべてのパスワードを最も安全かつ簡単に管理するにはどうすればよいでしょう。
その方法の 1 つが、すべてのデータを強力に暗号化されたファイルに保管する、パスワード リポジトリを使用する方法です。これを行うための優れたソリューションが Password Corral です。簡単に使用でき強力に暗号化できるこのアプリケーションは 2001 年から存在しており、Diamond2 暗号化または Blowfish 暗号化を使用してすべてのパスワードをファイル内に暗号化します。これは長期間にわたりテストが繰り返され、現在および将来のリリースのために、今もなお積極的なサポートと開発が行われています。
プログラムをインストールしたら、新しいユーザーを作成し、システム上 (またはネットワーク ドライブ上) でパスワード ファイルを配置する場所を選択することによって、新しいパスワード ファイルを利用できます。言うまでもありませんが、すべてのアカウントについての、あらゆるパスワードの機密情報を 1 つの Password Corral ファイル内に保存する場合は、Password Corral のパスワードを非常に強力にして頻繁に変更する必要があります。このパスワードだけは覚えておき、保護する必要があるため、適切な配慮を行ってください。
認証されると、Password Corral によって、Internet Explorer によく似た UI が提供され、左側に階層フォルダ構造が、右側に詳細ウィンドウが表示されます。パスワードをツリーに似た構造のフォルダに整理することができます。各パスワードには説明、ユーザー名、パスワード、参照 URL、参照電子メール アドレス、およびアカウントに関するコメントを含めることができます。また、各アカウントのパスワード ポリシーの種類をアプリケーションに指示して、有効期限サイクルの日数およびパスワードが期限切れになるまでの残り日数を指定できます。
表示オプションの 1 つで期限切れのパスワードをフィルタ選択できるため、次回使用するときにリセットする必要があるアカウントを確認できます。もう 1 つの便利な機能は、プログラムからパスワードを生成できることです。この機能を使用すると、各アカウント用に独自の強力なパスワードを考案する必要がなくなります。パスワード ジェネレータはカスタマイズできるので、必要な長さ、複雑さ、および文字の組み合わせを設定することができます。
別の便利な機能として、いったんすべてのパスワードを入力したら、任意のフィールドにデータを入力してパスワードを簡単に検索できます。これは、深いフォルダ構造の中からほとんど使用しないアカウントを検索する際に役に立ちます。アプリケーションのタイムアウトを設定することもできるので、Password Corral を終了し忘れた場合にアプリケーションによって自動的にロックがかかり、機密情報を保護することができます。また、パスワードを使用した後に、バッファにコピーしたパスワードが残ったままになっていると、アプリケーションは既定でクリップボードの内容を自動的に消去してから終了します。
常にパスワードにアクセスする必要がある場合は、アプリケーションのシステム トレイ アイコンのオプションを使用できます。アイコンをダブルクリックするだけでアプリケーションを起動することができます。Password Corral を使用してアカウントを他の場所に保存する必要がある場合、アプリケーションでファイルからアカウントをインポートできるので、新たにデータ入力を行う必要がなくなります。必要に応じて、パスワードのエクスポートや印刷もできますが、使用し終わったらパスワードが記載された紙を食べるようにしてください。全体として、これは非常に役立つ無償ツールです。

価格 : 無償
Password Corral を使用してすべてのパスワードを管理する(画像をクリックすると拡大表示されます)

ファイルの使用状況を監査する
File System Auditor
scriptlogic.com
共有ファイル システムの監査証跡を管理すると、頭痛の種の多くを取り除くことができます。ただし、それよりも重要な点は、情報の保存に関する一定のポリシー標準を満たす必要があることです。だれが何をいつ行ったかを確認できるように、ScriptLogic の File System Auditor を試してみることをお勧めします。このアプリケーションは集中管理型の管理システムで、対象システム上のファイルの使用をほぼリアルタイムに監査し、使用状況をレポートするために情報を SQL Server データベースに格納します。
File System Auditor では、Microsoft SQL Server Desktop Engine (MSDE)、SQL Server 2000、およびすべてのバージョンの SQL Server 2005 (無償の SQL Server 2005 Express を含む) がサポートされます。監視対象の各システムにはエージェントをインストールする必要があります。このエージェントは、ファイルの使用状況を監視し SQL Server にレポートを返すために使用されます。インストールしたら、Database Wizard (データベース ウィザード) を使用してデータベース リポジトリを作成します。監査に関するすべての情報はここに記録されます。
システム管理者は、頻繁に使用されるシステムの帯域幅と詳細度について考えるようになってきています。しかし、アプリケーションは、さまざまな操作を 1 つの監査エントリにまとめる、高度な監査システムを意図的に使用します。帯域幅の点では、File System Auditor はファイルへの初回アクセス時に 100 バイトだけデータを使用し、その後のアクセスごとに 10 ～ 20 バイトを使用します。
なぜ Windows に組み込まれている監査を使用しないのか疑問に思われるかもしれませんが、専用の監視アプリケーションの方が一元管理、イベントの結合、レポート機能の点でやや柔軟性が高く便利です。そのうえ、すべての情報を SQL データベースに格納することで、他のシステムからでも非常に簡単に情報を参照できるようになります。
データベースを構成したら、Agent Configuration Console (エージェント構成コンソール) を使用して対象のサーバーにエージェントを設定します。サーバーの名前を入力するか、Active Directory® を使用して名前を参照します。File System Auditor ではクラスタ化されたファイル サーバーもサポートされるため、クラスタ インスタンスの名前を入力することができます。次に、(アカウントにリモートにアクセスできる場合は、ボタンをクリックして) エージェント サービスをインストールし、エージェントが使用する Windows アカウントまたは SQL Server アカウントを選択して、File System Auditor データベースに接続します。
監視に関する 3 種類の除外項目をサーバー単位に設定できます。Path (パス) フィルタ、Process Exclusion (プロセス除外) フィルタ、および User Exclusion (ユーザーの除外) フィルタの 3 種類です。Path (パス) フィルタでは、パスを選択し、すべてのファイルか特定の種類のファイルに対して、特定のフォルダおよびファイルのイベント (アクセス許可の変更、作成、削除など) を含めるか除外するかを選択できます。Process Exclusions (プロセス除外) フィルタおよび User Exclusions (ユーザーの除外) フィルタでは、対象のサーバー上の特定のプロセスに関連するファイルおよびフォルダのイベントに対して同じ処理を行うことができますが、ファイルの種類に対するフィルタはサポートされません。
設定が完了し監査イベントの収集を開始したら、その監査データを使用するために、Report Configuration Console (レポートの構成コンソール) を起動します。レポートを設定するには、ユーザー、特定のファイルやフォルダのイベント、パス、サーバー、プロセス、日付範囲などのデータにさまざまなフィルタを設定できます。また、レポートのスケジュールを設定し、発行されたレポートを SMTP サーバー経由で電子メール配信されるようにもできます。最後に、システム上のファイル状態をリアルタイムに確認するには、File System Auditor の Real Time Viewer (リアルタイム ビューア) を起動し、ログ ファイルを "追跡" するようにスクロールしながら未加工のイベントそのものを監視できます。

価格 : プログラムおよび 1 サーバー ライセンス 800 ドルから (直販)
File System Auditor を使用したファイル使用状況の監査(画像をクリックすると拡大表示されます)

Greg Steen は技術プロフェッショナルであり、企業家でもあります。また、新製品のファンとも言えます。より簡単な操作、品質保証、および開発に役立つ IT プロフェッショナルのための新しいツールを日夜追い求めています。


ユーティリティ スポットライト Windows Memory Diagnostic
Lance Whitney

コードのダウンロード : Utility2008_09.exe (640 KB)

目次
Windows Memory Diagnostic を入手する
メモリをテストする
サポートしている PC の 1 台で、フリーズ、クラッシュ、ブルー スクリーンなどの問題が発生しています。ハードウェアのどこかが故障したのでしょうか。新しくインストールしたアプリケーションが問題の原因でしょうか。それともメモリに問題があるのでしょうか。原因を確認する方法の 1 つは、無償の Microsoft® Windows® Memory Diagnostic ユーティリティを使用することです。このツールでは、PC の RAM に対してさまざまなテストを実行して、メモリ モジュールのいずれかに欠陥があるかどうか確認します。

Windows Memory Diagnostic を入手する
Windows Memory Diagnostic を使用するには、このプログラム唯一のファイル (mtinst.exe) を oca.microsoft.com/en/windiag.asp からダウンロードして実行します。Windows Memory Diagnostic をインストールする必要はありません。次のスクリーンショットに示すように、このツールには 2 つの選択肢が表示されます。
図 1 起動可能なメディアを作成するための Windows Memory Diagnostic のオプション (画像をクリックすると拡大表示されます)
  • [Create Startup Disk] (起動ディスクの作成): プログラムを含む起動用のフロッピー ディスクを作成できます。
  • [Save CD Image to Disk] (CD イメージをディスクに保存する): プログラムの ISO イメージをハード ドライブに保存できます。その後、CD 作成用ソフトウェアを使用して保存したイメージを CD に書き込み、この CD から起動できるようにします。起動可能なメディアを作成したら、PC を再起動してフロッピー ディスクまたは CD から診断を開始します。
メモリをテストする
プログラムが読み込まれると、すぐに RAM のスキャンが始まります。Windows Memory Diagnostic ツールは Standard (標準) モードで開始します。このモードには 6 種類の連続するメモリ テストが含まれ、それぞれのテストで独自のアルゴリズムを使用してさまざまな種類のエラーをスキャンします。画面に実行されている各テストが表示され、進行状況、およびスキャンされたメモリ アドレスの範囲が一覧表示されます。この 6 種類のテストが完了すると、同じ組み合わせのテストで 2 回目のパスが実行され、このソフトウェアを終了するまで繰り返しパスが実行され続けます。ただし、メモリに問題が発生しているかどうか確認するには通常 1 回のパスで十分です。
もっと徹底したテストを実行する場合は、Extended (拡張) モードに切り替えることができます。このモードでは 11 種類のメモリ テストが実行されます。2 種類のテストだけが実行される Basic (基本) モードもありますが、万全を期すには Standard (標準) モードか Extended (拡張) モードを使用することをお勧めします。拡張モードのテスト スイートを実行する場合は、Windows Memory Diagnostic を夜間に実行することをお勧めします。
各テストが完了するたびに、"Succeeded" (成功) または "Failed" (失敗) というメッセージが表示されます。"Failed" (失敗) のメッセージの後にはエラーの詳細が表示され、多くの場合、いずれかの RAM モジュールに問題があることが示されます。PC の環境によっては、診断によってメモリの問題を特定のモジュールに絞り込むことができます。
この場合、[View errors by memory module] (メモリ モジュール別にエラーを表示) というオプションが表示されます。このオプションを使用すると、問題が発生して交換が必要なモジュールを特定できます。
[Advanced options] (詳細オプション) 画面では、Basic (基本)、Standard (標準)、および Extended (拡張) の各モードを切り替えることができます。また、この画面ではスキャン中にプロセッサのキャッシュを無効にすることもできます。無効にすると、Windows Memory Diagnostic から直接 RAM 上のデータにアクセスできるようになり、より徹底的なテストを実行できます。[System Information] (システム情報) コマンドを選択すると、各スロットに取り付けられている RAM の容量や種類が一覧表示されます。
Windows Memory Diagnostic では、Intel Pentium/Celeron プロセッサ、AMD K6/Athlon/Duron プロセッサなど、x86 ベースのプラットフォームがサポートされています。ただし、このツールでテストできるのは 4 GB の RAM までです。4 GB を超えるとスキャンされません。
また、この診断ツールには、Windows Vista® にインストールされたバージョンもあり、[管理ツール]、および Windows Vista のインストール メディアの [コンピュータを修復する] というオプションから実行できます。ただし、Windows Vista バージョンでは、表示されるフィードバックや使用できるオプションが少なくなります。したがって、次回いずれかの PC に問題が発生した場合に備えて、スタンドアロン版を手元に置いておくことをお勧めします。
Lance Whitney は、IT コンサルタントであり、トレーナーであり、テクニカル ライターでもあります。Windows のワークステーションおよびサーバーをカスタマイズすることに数えきれないほどの時間を費やしてきました。元々はジャーナリストでしたが、15 年前、IT 業界への転向を実現しました。


SharePoint の内部 SharePoint のディレクトリ統合
Pav Cherny

コードのダウンロード : SharePoint2008_09.exe (2,775 KB)

目次
SharePoint Directory Management Service
カスタム Directory Management Service
SharePoint および ILM
まとめ
Microsoft Windows SharePoint Services (WSS) 3.0 および Microsoft Office SharePoint Server (MOSS) 2007 には、Directory Management Service という形式のディレクトリの同期機能が含まれています。この機能を使用すると、Active Directory の SharePoint リソース用に、メールが有効な連絡先およびグループ オブジェクトを準備することができます。このような種類の
SharePoint® リソース用の受信者オブジェクトを準備すると、ユーザーはドキュメントや他の情報を送信する際に、Microsoft® Outlook® アドレス帳から SharePoint ライブラリ、リスト、およびグループを直接選択できます。
また、SharePoint 受信者オブジェクトにより、Exchange Server 組織でメッセージ転送や形式変換を制御する方法ももたらされます。特に、スパム送信者などの認証されていない送信者が、Active Directory® のメッセージの配信制限を設定して SharePoint ライブラリにメッセージを送信するのを防ぐことができます。
ただし、SharePoint のディレクトリ管理機能は限られています。この記事の執筆時点では、基盤となるメッセージング システムとして Exchange Server 2003 を想定しています。現時点では、Exchange Server 2007 かサード パーティのメッセージング システムを使用する場合に必要なレベルの相互運用性を実現するためには、組み込みのディレクトリ管理機能をカスタム ソリューションに拡張するか、置き換える必要があります。
今月のコラムでは、SharePoint のディレクトリ管理機能について簡単に確認し、既存の制限事項を克服する手法について説明します。組み込みの Directory Management Service は、最も基本的なユーザー要件だけを満たすことを前提としています。さまざまなメッセージング システムやディレクトリ プラットフォームが存在する環境では、より優れた柔軟性および機能が必要になります。組み込みのコンポーネントをカスタム ソリューションに置き換えることによって、SharePoint の受信者情報と、API やインポート機能を提供する任意のディレクトリ ソリューションとの同期を取ることができます。
この点を証明するために、Exchange Server 2007 と互換性がある、SharePoint の受信者情報の同期方法について説明します。同様に、カスタム ソリューションを使用して受信者情報と IBM Lotus Notes やその他のシステムとの同期を取ることができます。
また、Microsoft Identity Lifecycle Manager (ILM) 2007 Feature Pack 1 (FP1) に含まれている Identity Information Server などのメタディレクトリ サービスに基づいてディレクトリの準備処理を一元管理する機能も提供されます。ここでは特に、SharePoint と ILM 2007 を統合して、SharePoint ドキュメント ライブラリ用にディレクトリ オブジェクトの準備を調整する方法について説明します。このソリューションを構築するためのツール、ソース コード、および順を追った説明は、このコラムの付属リソース (technetmagazine.com のコード ダウンロード セクションからダウンロードできます) として入手できます。

SharePoint Directory Management Service
Exchange Server ではほぼすべての構成情報および受信者情報用に Active Directory が使用されますが、それとは異なり、SharePoint では構成データベースおよびコンテンツ データベースが使用されます。そのため、SharePoint では、メールが有効なライブラリ、リスト、およびグループの受信者情報をデータベースからディレクトリに反映する必要があります。いずれにせよ、メッセージング クライアントは受信者情報がアドレス帳で見つかることを期待しており、通常、その受信者情報はディレクトリ オブジェクトから生成されるためです。
SharePoint ではこういった目的のために組み込みの Directory Management Service が含まれています。この Directory Management Service は、E-mail Integration (電子メール統合) Web サービス (SharepointEmailWS.asmx) の一部で、SharePoint 3.0 サーバーの全体管理の [サーバー構成の管理] ページの [受信メールの設定] で構成できます。図 1 は、組み込みの Directory Management Service のしくみを示しています。
図 1 SharePoint Directory Management Service のアーキテクチャ(画像をクリックすると拡大表示されます)
ディレクトリ管理のために Web ファームを有効にしてから、EmailSettings.aspx を使用するなどしてライブラリ、リスト、またはグループに電子メールアドレスを割り当ててメッセージを受信できるようにした場合は、E-mail Integration (電子メール統合) Web サービスを暗黙に呼び出して、Active Directory に対応する受信者オブジェクトを準備します。まず、SharePoint では電子メール アドレスの情報がコンテンツ データベースに格納されます。次に、Web アプリケーション プール アカウントの ID を使用して、準備要求が E-mail Integration (電子メール統合) Web サービスに送信されます。準備要求が失敗すると、コンテンツ データベース内に電子メール アドレス情報は格納されますが、Active Directory には対応する受信者オブジェクトが存在しなくなります。
関連リソース
  • SharePoint 製品およびテクノロジ Web サイト
  • Windows SharePoint Services TechCenter
  • Windows SharePoint Services デベロッパー センター
  • Microsoft SharePoint 製品およびテクノロジ チームのブログ
準備要求の失敗には多くの原因があります。最も一般的な原因は IIS メタベースへのアクセス許可がないことです。SharepointEmailWS.asmx はアプリケーション プール アカウントの Web サービスになるよう設計されているため、この Web サービスは IIS メタベースをチェックして、呼び出し元がアプリケーション プール アカウントかどうかを確認します。そうでない場合は、SharePoint サイトおよび Active Directory のアクセス許可レベルに関係なく、アクセスを拒否します。
ただし、SharepointEmailWS.asmx は呼び出し元の ID を使用してこのアクセス確認を実行します。そのため、アプリケーション プール アカウントを呼び出す場合、メタベースにアクセスして、自身のアクセス許可を確認する必要があります。これを成功させるには、アプリケーション プール アカウントのアクセス許可を昇格することが必要になります。
もちろん、Web サーバーで昇格されたアクセス許可は、セキュリティ上の懸念事項の要因になります。ASP.NET Web サービスへのアクセスを制御する場合さらに優れた方法があります。そのうえ、SharePoint ではサーバーの全体管理サイトに Directory Management Service が見つかることを想定していますが、このサイトは、攻撃を受ける可能性のある領域を減らすためにロック ダウンされている Web ファームではまったく使用することができません。そのため、SharePoint の運用環境で組み込みの Directory Management Service を使用する場合は、セキュリティ構成が緩和されることを受け入れる必要があります。
組み込みの Directory Management Service が、クライアントとサーバーが緊密に結び付けられたアーキテクチャに基づいていることからさらに制限が生じます。Microsoft.SharePoint.dll は System.DirectoryServices.dll を直接使用します。そのため、独自のロジックを実装して準備処理をカスタマイズすることはできません。たとえば、組み込みの Directory Management Service 実装では、Exchange Server 2007 をサポートするための受信者属性の一部が書き込まれず、属性の生成ルールをカスタマイズするオプションがありません。
独自のロジックを実装できないということは、たとえば、準備処理をカスタマイズして、カスタムの承認を実装できないことを表します。SharePoint では、グループに対する承認プロセスがサポートされますが、この機能はサーバーの全体管理サイトに基づいています。SharePoint ファームの管理者だけが保留中の要求を承認できますが、SharePoint 管理者は必ずしも Active Directory 準備処理の承認を担当するわけではありません。
さらに重要なのは、メールが有効なドキュメント ライブラリやリストの承認プロセスがない点です。ディレクトリ管理を有効にすると、基本的に Web ファーム内のすべてのサイト管理者に、Active Directory でメールが有効な連絡先およびグループを作成する権利が与えられます。Web ファームごとのすべての受信者オブジェクトが同じ組織単位 (OU) に格納されるため、OU に基づいて受信者管理を構造化することもできません。
Directory Management Service では SharePoint OU 内で受信者オブジェクトが見つかることを想定しているため、受信者オブジェクトを別の OU に移動することはできません。そのため SharePoint サーバーの全体管理アプリケーション プール アカウントに Active Directory の管理者アクセス許可を付与する必要があります。また、SharePoint と Active Directory の間で双方向同期を実装する方法がありません。Active Directory でオブジェクトの属性を変更しても、その変更は SharePoint 環境には反映されません。

カスタム Directory Management Service
組み込みの Directory Management Service で柔軟性の向上を実現できる余地があることは証明できたので、別の方法についていくつか説明しましょう。よい知らせとしては、SharePoint を使用して独自の Directory Management Service を実装できることが挙げられます。必要な操作は、SharePoint 3.0 サーバーの全体管理の [サーバー構成の管理] ページの [受信メールの設定] で、Web サービスをリモート Directory Management Service として登録することだけです。
カスタム Web サービスを配置および登録するための順を追った詳細な説明については、付属リソースの Directory Integration Based on a Custom Directory Management Service.xps ワークシートを参照してください。また、私が作成したカスタム Web サービスは、コマンドレットや Exchange 管理ツールを使用しないで、Exchange Server 2007 と互換性がある受信者オブジェクトを Active Directory に準備する方法を示しています。対応するソース コードは EmailIntegrationService フォルダにあります。図 2 はこのソリューションのアーキテクチャを示しています。
図 2 カスタム Directory Management Service のアーキテクチャ(画像をクリックすると拡大表示されます)
SharePoint SDK で説明されているように、カスタム Web サービスのインターフェイスは、Directory Management Service インターフェイスに準拠する必要があります。MSDN® Web サイト (msdn.microsoft.com) で "SharepointEmailWS" を検索すると、必要なすべての詳細情報を入手できます。また、付属リソースの EmailIntegrationService\App_Code フォルダにある Service.cs ファイルも確認してください。このファイルは、必須の Web サービス インターフェイスを実装しますが、Active Directory オブジェクトを準備する実際のコードは SPRecipient.cs にあります。たとえば、SPRecipient.cs の UpdateRecipientAttributes 関数は、Exchange Server 2007 の必須属性を作成します。SPRecipient.cs はコード ファイルです。独自にカスタム Directory Management Service を構築する場合は、このコード ファイルを置き換える必要があります。
カスタム Directory Management Service は、アクセス許可の昇格の必要性をなくし、SharePoint をサード パーティのディレクトリまたはメッセージング システムと統合するための優れたツールです。IIS メタベースを確認して Web サービスによるアプリケーション プール アカウントへのアクセスを制限する必要はありません。代わりに、Web サービスの web.config ファイルに <authorization> セクションを追加できます (例については、付属リソースを参照してください)。
ただし、いくつか問題が残ります。作成した Directory Management Service を SharePoint が呼び出すかどうかや、呼び出すタイミングを制御できません。特に、メールが有効なドキュメント ライブラリやリストを削除した場合、SharePoint は Directory Management Service を呼び出しません。そのため、個々の受信者オブジェクトが Active Directory に残ります。組み込みの Directory Management Service またはカスタム ソリューションのどちらを使用する場合でも、Active Directory の受信者情報が SharePoint リソースと一致するという保証はありません。

SharePoint と ILM
ディレクトリの統合を信頼できるものにするには、ILM のような本格的なディレクトリ管理パッケージの展開を検討する必要があります。このシステムでは、収集ベースのディレクトリ同期モデルが使用されます。管理エージェントは接続先のソースから情報を収集し、その情報を共通のメタディレクトリにインポートし、メタディレクトリから情報をエクスポートして、接続先のシステムに格納します。接続元のシステムでは、通常、情報をメタディレクトリに格納しません。情報を収集することによって、それぞれの同期サイクルとの一貫性を保つことができます。
もう 1 つのメリットは、Active Directory、Lotus Notes など市販のさまざまなシステムをサポートするエージェントが ILM に含まれていることです。必要な操作は、SharePoint 用のカスタム管理エージェントを実装して、環境内でサポートされている別のディレクトリ プラットフォームと SharePoint 情報との同期を取ることだけです。
SharePoint から必要な情報を取得し、その情報をインポート ファイルに保存して、インポートされた情報をメタディレクトリに転送するロジックを実装する必要があります。しかし、その情報をメタディレクトリから Active Directory または別のディレクトリ プラットフォームにエクスポートするロジックを実装する必要はありません。図 3 は、ILM を使用して SharePoint から Active Directory への同期を実装する方法を示しています。その他の方向に同期を行ってディレクトリ オブジェクト用の SharePoint リソースを準備することもできますが、この方法は不要または省略可能と見なされています。
図 3 Identity Lifecycle Manager ベースのディレクトリ統合(画像をクリックすると拡大表示されます)
SharePoint の管理エージェントを開発する際は、手始めに blogs.msdn.com/alextch/archive/2007/09/02/wsslistsandilm.aspx にある Alex Tcherniakhovski の記事「ILM 2007 と SharePoint Services リストの接続」を参照することをお勧めします。Alex は、ドキュメント ライブラリに送信された InfoPath® ベースの準備要求を使用する、ILM を基にしたディレクトリ管理ソリューションを構築する方法を説明しています。Alex の管理エージェントは承認されたすべての要求をドキュメント ライブラリから取得し、対応するメタディレクトリ オブジェクトを作成します。その後、メタディレクトリ オブジェクトが接続先のディレクトリにエクスポートされます。
しかし SharePoint の既定では、リストまたはグループのメールを有効にしたときに、InfoPath ベースの準備要求は生成されません。カスタム Directory Management Service を使用するとこの操作を実現できますが、そうすると、どのような状況でも SharePoint から Directory Management Service が呼び出されないことが原因で前述した一貫性の問題が発生します。このような理由から、作成した管理エージェントでは、必要な SharePoint の受信者情報をサイト コレクション内のリストおよびグループから直接取得することをお勧めします。承認プロセスが必要な場合は、管理エージェントで新しいリソース用の InfoPath ベースの準備要求を生成し、その後承認されたすべての要求を処理します。
SharePoint 情報を取得するオプションはいくつかあります。SharePoint オブジェクト モデル、または SharePoint Web サービスを利用して、コンテンツ データベースから情報を直接読み取ることができます。
コンテンツ データベースに直接アクセスすることはお勧めできません。将来のバージョンではデータベース構造が変更される可能性があり、それによりディレクトリ管理ソリューションが機能しなくなるためです。
管理エージェントで SharePoint オブジェクト モデルを直接使用することは、同じように少し複雑になります。オブジェクト モデルではコードをローカルで実行することが求められますが、環境内のあらゆる SharePoint ファーム上の Web サーバーに ILM をインストールすることは、ディレクトリ管理のインフラストラクチャを複雑にする可能性があるためです。
SharePoint Web サービスを使用することを考えるかもしれませんが、そうすると、SharePoint Web サービスを使用して必要な情報 (SharePoint グループの電子メール アドレス情報や受信メール サーバーの表示アドレス) に簡単にアクセスできないため、別の問題が発生します。
結局、SharePoint オブジェクト モデルを使用するカスタム SharePoint Web サービスを実装して必要な情報を収集し、その情報を XML ドキュメントの形式で呼び出し元に返すのが最善のように思えます。図3 に示されているように、カスタム SharePoint Web サービスの個別のインスタンスを使用して、ILM の展開を一元化し、さまざまなファームおよびサイト コレクションを統合することができます。
触れておかなければならない点がもう 1 つ残っています。それは、ILM ベースのディレクトリ統合では、カスタム Directory Management Service の必要性がなくならない点です。このカスタム サービスでは、ILM によってディレクトリ オブジェクトが準備されるため、何も行う必要がありません。ですが、SharePoint 3.0 サーバーの全体管理でディレクトリの管理を有効にできるようにするカスタム サービスを提供する必要があります。そうしないと、たとえば、最初に電子メール アドレスをグループに割り当てることができません。図4 は最終的なソリューション アーキテクチャを示しています。
図 4 Web サービスを基にした SharePoint のディレクトリ統合(画像をクリックすると拡大表示されます)
web.config ファイルの OpMode パラメータ (<add key="OpMode" value="dummy"/>) を設定することによって、付属リソースに含まれているカスタム Directory Management Service をダミーのサービスに変更できます。この構成では、何も行わなくても、カスタム サービスにより、準備の呼び出しに応答して常に成功が返されます。
また、カスタム サービスは ResolveUsers メソッドを公開します。このメソッドは、SharePoint の管理エージェントから呼び出され、NetBIOS ベースのユーザー アカウント名を識別名に解決します。この手順は、グループを準備するときに必要になります (SharePoint はグループのメンバシップ情報を NetBIOS ベースのユーザー アカウント名の一覧として返しますが、Active Directory では識別名が前提とされています)。これで処理は完了です。最終的なソリューションの配置方法の詳細については、付属リソースに含まれている Configuring Directory Integration based on ILM 2007.xps ファイルを参照してください。
WSS 3.0 および MOSS 2007 には Directory Management Service が含まれており、さまざまなプラットフォームで動作するメッセージング ベースのコラボレーション用に、SharePoint を Exchange Server 2003 に統合できます。
ただし、いくつかの制限があります。ユーザーは組み込みの Directory Management Service をカスタム ソリューションに置き換える必要があります。また、ILM などの本格的なディレクトリ管理ソリューションを使用して、ディレクトリ管理のインフラストラクチャに SharePoint を統合することもできます。この方法によって最も高いレベルの柔軟性が提供され、収集ベースの同期モデルを使用することによって情報の一貫性が保たれます。

Pav Cherny は、主にコラボレーションとユニファイド コミュニケーションに関するマイクロソフト テクノロジを扱う IT 専門家であり、IT 関連書籍の執筆も行っています。これまでに、IT の運用とシステム管理についてのホワイト ペーパー、製品マニュアル、書籍などを執筆してきました。Pav は、ドキュメント管理とローカライズ サービスの専門企業 Biblioso Corporation の代表取締役です。


Windows PowerShell 文字列理論
Don Jones

目次
現実の世界での例
複雑な一致
文字列が使用されることの多い世界
私は、Tech•Ed や TechMentor などのカンファレンスで講演をする際、宣言を行う (ユーザーが Windows PowerShell などに関する要点を覚えるのに役立つ原則を発表する) のが習慣になっています。私が行った最新の宣言は、「Windows PowerShell で文字列を解析しようとしている方は、間違ったことをしようとしています。」というものです。
これは、Windows PowerShell™ はオブジェクト指向のシェルであるという私の考え方に由来しています。サービスの一覧をテキスト ファイルにダンプし、開始されているサービスを確認するためにそのテキスト ファイルを解析するというような処理を行おうとしているとしたら、必要以上の労力を使うことになります。これは、UNIX など、テキストベースの OS では有効な方法ですが、Windows PowerShell (および Windows® 自体) では、はるかに効率的な方法でオブジェクトを使用することができます。
ビデオ
このビデオでは、Don Jones が、Windows PowerShell を使用して複雑な文字列を解析する方法について説明しています。ぜひ、ご覧ください。

ユーザー独自のスクリプトを使用した場合でも、書式設定コマンド、フィルタ コマンド、エクスポート コマンドなどの、シェルのさまざまなコマンドを使用してスクリプトの出力を操作できるように、書式設定されたテキストではなくオブジェクトが生成されます (スクリプトの出力としてのカスタム オブジェクトの概念の詳細については、2008 年 7 月号の Windows PowerShell コラムを参照してください)。
フロリダ州オーランドで最近開催された TechMentor で、私は、受講者の 1 人の発言によって、ほぼすべての規則には、とりわけ原則には、例外があるということを思い出しました。その発言とは、「IIS のログ ファイル内で検索を行う場合はどうですか。その場合は、テキストを解析しなければいけないのではありませんか。」というものです。
確かに、そのとおりです。Windows PowerShell はオブジェクトを扱うのに適しているかもしれませんが、さいわい、Windows PowerShell ではテキスト文字列の解析も適切に行うことができます。そう言われてみると、IIS のログ ファイル、ファイアウォールのログ ファイル、およびその他のテキストベースのログは、絶好の例ですね。

現実世界での例
私は実際、自分が勤めていた会社のために、ファイアウォールの一連のログ ファイルを解析しなければならないことがありました。従業員が不適切な Web サイトを閲覧しているのが見つかり、人事部は追跡調査の一環として、その従業員がアクセスした Web サイトの包括的な一覧を必要としていました。これを 1 日のログ ファイルから抜き出すだけでも少し困難ですが、人事部のスタッフが求めていたのは、過去数週間分の一覧を取得するという、手動で行う気にはなれない作業でした。
会社の動的ホスト構成プロトコル (DHCP) サーバーは、その従業員のコンピュータでは数か月間、同じ IP アドレス (この例では 192.168.17.54 とします) が使用されていたことを示しました。これはめったに電源を切らないデスクトップ コンピュータだったので、もちろん、これは珍しいことではありません。また、ファイアウォールのログには発信元 IP アドレスが記録されていたので、私は Windows PowerShell が役立つと考えました。
秘密は、見過ごされがちな Select-String コマンドにあります。また、正規表現 (これについては、2007 年 11 月号の Windows PowerShell コラムで説明しました) についての実用的な知識も必要です。
Select-String コマンドは、テキスト ファイルが格納されているファイル パス、および検索対象となる正規表現または単純な文字列を受け取ります。続いて、各ログ ファイル内の、正規表現または単純な文字列に一致する各行を出力します。作業を開始するにあたって、私は単純に、その従業員のデスクトップ コンピュータの IP アドレスが含まれている行をすべて取得しようと考えました。ログ ファイルの各行には、日付とタイム スタンプが含まれていました。人事部のスタッフが求めていたものは、これですべてです。
コマンドは次のとおりです。
select-string -path c:\logs\*.txt -pattern "192.168.17.54"
-allmatches –simplematch
–simpleMatch パラメータは、指定したパターンが正規表現ではなく単なる単純な文字列であることを示しています。図 1 は、出力の一部を示しています。この出力をファイルにパイプすることもできます。出力には、検索対象に一致する内容が見つかったファイルの名前、および行の番号が含まれていることに注意してください。これは、ある時点で再び出力を確認し詳細を調べる場合に、非常に役立ちます。
今月のコマンドレット : Start-Sleep
1 日の長い勤務時間の途中で皆さんに必要なもの (短時間の昼寝) を提供するコマンドレットを紹介します。Start-Sleep は、短時間の休憩を提供します。休憩が与えられるのは Windows PowerShell スクリプトですが。
スクリプトで、短時間の停止が必要になるのは珍しいことではありません。たとえば、サービスを開始し、そのサービスが起動して実行されるようになるまで数秒間待ち、その後、そのサービスを使用する他の処理を実行する必要があるとします。Start-Sleep は、この動作にまさに必要なものです。たとえば、Start-Sleep 10 を実行すると、シェルは 10 秒間停止します。より厳密な制御が必要な場合は、たとえば、Start-Sleep -milli 100 を実行して 100 ミリ秒間停止することができます。Start-Sleep を使用すると、指定した時間、シェル (スクリプト、パイプライン、およびその他すべてを含みます) が完全に停止します。今度は、私が切望してきた Start-Nap (昼寝開始) コマンドレットをだれかが作成してくれるとよいのですが。
図 1 Select-String コマンドの出力 (画像をクリックすると拡大表示されます)

複雑な一致
私が要求されたとおりのものを人事部のスタッフに提供した後で、人事部のスタッフは、必要なものは結局それではなかったことに気付きました。私のレポートには、207.68.172.246 (MSN® Web サイト) など、多くの IP アドレスへのアクセスが記録されていました。調査担当スタッフから次に出された要求は、特定の IP アドレス (問題となっている Web サイトの 1 つに対応する IP アドレスであると調査担当スタッフが見なしたもの) へのアクセスのみが記録されるようにレポートの対象を限定することでした。このコラムでは、調査で浮かび上がった実際の IP アドレスは公表しません。代わりに、この例では 207.68.172.246 を使用します (通常、MSN Web サイトは不適切とは見なされませんが)。
この要求は場合によってはもう少し対処が困難なものだったでしょうが、私が扱っていたログ ファイル内では、発信元 IP アドレスと宛先 IP アドレスは隣同士にあり、コンマで区切られていたので、検索文字列を "192.168.17.54,207.68.172.246" に変更して再び検索を行うだけで済みました。
しかし、より複雑なログ ファイルでは、可変データが 2 つの IP アドレスの間に格納されている可能性があるので、単純な文字列の一致はうまく機能しません。このような場合は正規表現を使用する必要があり、正規表現は単純なログ形式に対しても適切に機能するので、ここでは、正規表現を使用した方法について説明します。
正規表現内では、ピリオド文字は、任意の 1 文字を表すワイルド カードです。また、(.)* という部分式を使用して、2 つの IP アドレス (発信元 IP アドレスと宛先 IP アドレス) の間にある任意の数の文字を検索することができます。ただし、IP アドレス自体に含まれているリテラル文字のピリオドをエスケープするために円記号を使用する必要があります。
その結果、コマンドは次のようになります。
select-string -path c:\logs\*.txt -pattern
"192\.168\.17\.54(.)*207\.68\.172\.246" –allmatches
今回は正規表現を使用するので、–simpleMatch パラメータを削除しました。このコマンドを実行して得られた出力では、特定の従業員のコンピュータから不適切と見なされた特定の Web サイトへのアクセスのみが表示されました。出力には、調査担当スタッフが求めていた日付とタイム スタンプの情報も含まれていました。図 2 は、上記のようなコマンドを実行した場合に得られる可能性がある出力の一部を示しています。
図 2 特定のサイトへのアクセスのみを表示するように対象が限定された検索結果 (画像をクリックすると拡大表示されます)
調査担当スタッフからそこまでは要求されませんでしたが、出力を Format-Table にパイプし、Format-Table を利用して計算列を表示することもできます。ログ ファイルのファイル名、および検索対象に一致する内容が見つかった行の番号を表に含めることができます。また、一致する内容が見つかった行自体を表示することもできます。しかし、行の残りの部分 (この例では日付とタイム スタンプ) のみが表示されるように、シェルを使用して、正規表現に一致した箇所を空の文字列に置き換えることもできます。これは高度な処理ですが、これを紹介すると、Windows PowerShell を使用して次のように 1 つのコマンド ラインで文字列データを操作し大幅にカスタマイズされた出力を生成する方法を示すことができます。
select-string -path c:\logs\*.txt -pattern
"192\.168\.17\.54(.)*207\.68\.172\.246" -allmatches |
ft  filename,linenumber,@{"Label"="Time";
"Expression"={$_.line.replace
($_.matches[0],"")}} –auto
図 3 は、最終結果がどのようなものになるかを示しています。
図 3 Select-String コマンドの書式設定された出力 (画像をクリックすると拡大表示されます)

文字列が使用されることの多い世界
オブジェクト指向という性質は Windows PowerShell の最大の強みの 1 つであることは自信を持って宣言できます。とはいえ、オブジェクトを使用できない場合もあります。
Windows PowerShell はオブジェクト指向の世界に存在しているかもしれません。ですが、さいわい、Windows PowerShell チームは、現実世界では書式設定された文字列の形式で外部データが存在することが多いと気付いたので、Select-String コマンドを盛り込みました。Select-String を使用できるようになり、また、正規表現をよく知っておけば、Windows PowerShell を使用して、どんなに複雑な文字列でも解析できる 1 行のコマンドを記述することができます。

Don Jones は『Windows PowerShell: TFM』の共著者であり、他にも IT に関連する多数の書籍を執筆しています。Don に対するお問い合わせについては、彼のブログ (www.concentratedtech.com) を参照してください。


Hey, Scripting Guy! トースターと常時連絡を取れるようにする
Microsoft Scripting Guys

コードのダウンロード : HeyScriptingGuy2008_09.exe (150 KB)

この私たちの現代世界を簡潔にまとめるとしたら、「常時接続」という表現が適切でしょう。携帯電話のおかげで、家にいなくても電話を受けることができます。他の人は、時間と場所を問わず、あなたに電話をかけることができます (へぇ、それはすばらしい…ですね)。また、ワイヤレスでコンピュータが使用できるおかげで、会社にいなくても仕事ができるようになりました。自宅や海辺など、思いつく限りのすべての場所から仕事ができます。
これは実際にあった話ですが、編集者の両親が最近キャンプに行ったとき、キャンプ場のワイヤレス ネットワークに接続できなかったため、偉大な探検家ルイスとクラークのように不便な生活を強いられたそうです。しかし、さいわいにも、衛星テレビは見ることができました。
ただし、話はここからです。GPS 機器は、ほとんど誤差なく所在地を示すことができます。また、あなたの所在地を他の人に知らせることができるものもあります (今日ほど「逃げても無駄だぞ」という慣用句が的を射ている時代はないでしょう)。このコラムを執筆している Scripting Guy が望めば、小切手が決済されるたびに当座預金口座から電話で知らせが来るようにしたり、車に毎月のステータス レポートを送らせることだってできます。まるでそれだけでは不十分だと言わんばかりに、トースターは、彼が休暇で不在になるときには、いつでも犬の散歩と植木の水やりを代行すると申し出てきました。
そうですね。確かに最後のトースターの件に関しては、まだ実現された話ではありません。でも、Scripting Guy が望めば、インターネットに対応したトースターを買うことはできます。帰宅途中にトースターに電話して、家のドアを開けたときには、焼きたてのトーストができあがっているようにできます。ですが、正直なところ、ドアを開けたときに焼きたてのトーストが欲しい理由は理解できません。でも、あなたが理解できるのであれば、どうぞご利用ください。
もちろん、世間が常時接続した状態を保つことにやっきになっているのであれば、流行にとらわれたことのない Scripting Guys が、非常時接続を推奨するのは無理もないことでしょう。それはつまり、Scripting Guys が携帯電話とラップトップ コンピュータを破棄するように推奨している、ということになるのか、ですって。 いいえ、そうではありません。いくら Scripting Guys だってそのようなことはしません。彼らが主張しているのは、切断されたレコードセットをスクリプトのコレクションに加えることです。でも、携帯電話やラップトップ コンピュータを破棄したい方については引き止めたりすることはありませんので、ご自由にどうぞ。
注 Harris Interactive 社の調査によると、アメリカ人の 43% が仕事に関係したメールをチェックするために休暇中にラップトップ コンピュータを使ったことがあるそうです。また、50% 以上の人が電子メールやボイスメールをチェックするために休暇中に携帯電話を使ったことがあると答えています。そして、この結果には、1 年の間に休暇を取らない 40% のアメリカ人は含まれていません。
多くの人が、切断されたレコードセットを喜んでスクリプトのコレクションに加えるでしょう。「切断されたレコードセットが何であるかわからないことを除いて」という但し書き付きになりますが。切断されたレコードセットという概念に詳しくない方のために説明すると、これは、いわば実際のデータベースに接続されていないデータベース テーブルのようなものです。これはスクリプトにより作成されており、メモリ内にのみ存在し、スクリプトが終了するときに消滅します。つまり、切断されたレコードセットは、数分間だけ存在する架空のデータ構造で、データと共に消滅します。「なるほど、それは本当に便利そうですね Scripting Guys さん。教えてくれてどうもありがとう。」という声が聞こえてきそうですね。
正直に言いますと、切断されたレコードセットは、それほどワクワクするものではなさそうです。実際のところ、ワクワクするものではありませんが、とても役に立つことがあります。ベテランの VBScript スクリプト作成者はご存じだと思いますが、VBScript のデータ分類機能は世界一優れたものというわけではありません (データ分類機能がないことが世界最良のデータ分類機能であると思っている場合は別ですが)。同様に、ひいき目に見ても VBScript の大きなデータ セットを処理する能力も限られています。Dictionary オブジェクト (最大 2 つのプロパティを持つアイテムの作業に制限されます) または配列 (大部分が単一プロパティのデータ一覧に制限されます) の以外は、そんなところです。
切断されたレコードセットは、この両方の問題に対処できます (そしてその他の問題にも対処できます)。データ (特に複数プロパティを持つデータ) を分類する必要がある場合は、お任せください。先に述べたように、切断されたレコードセットは実質上データベース テーブルと同じようなものなので、データベース テーブルを分類するのは簡単な作業です (そうですね、厳密に言うなら、データベース テーブルを分類しないことの方が、データベース テーブルを分類するよりも簡単な作業でしょう)。複数プロパティを持つ多数のアイテムを整理する必要がある場合も、お任せください。切断されたレコードセットはデータベース テーブルと実質上同じようなものであることはお知らせしましたよね。なんらかの方法で情報をフィルタ処理したり、データに特定の値が含まれているかどうかを検索したりする必要がある場合は、データベース テーブルと実質的に同じものを使える方法があれば万事解決です。
おっしゃるとおり、具体例をお見せしましょう (私たちが話していることを自分たちで理解していることを前提としていますが)。まず始めに、図 1 に示す野球の統計データがあるとします。この統計は、MLB.com の Web サイトから取得したもので、タブ区切りファイル C:\Scripts\Test.txt に格納されています。
図 1 タブ区切りファイルに保存されている統計
Player | Home Runs | RBI | Average
D Pedroia | 4 | 28 | .276
K Kouzmanoff | 8 | 25 | .269
J Francouer | 7 | 35 | .254
C Guzman | 5 | 20 | .299
F Sanchez | 2 | 25 | .238
I Suzuki | 3 | 15 | .287
J Hamilton | 17 | 67 | .329
I Kinsler | 7 | 35 | .309
M Ramirez | 12 | 39 | .295
A Gonzalez | 17 | 55 | .299
この一覧自体には何も問題はありませんが、打ったホームランの数によって選手の一覧を並べ替えて表示したいとします。切断されたレコードセットをこの処理に利用できるのか、ですって。それについては、今からご説明しましょう。図 2 をご覧ください。たくさんのコードがありますが、心配しないで大丈夫です。すぐに見かけほど難しくないことがおわかりいただけると思います。
図 2 切断されたレコードセット
Const ForReading = 1
Const adVarChar = 200
Const MaxCharacters = 255
Const adDouble = 5

Set DataList = CreateObject("ADOR.Recordset")
DataList.Fields.Append "Player", _
  adVarChar, MaxCharacters
DataList.Fields.Append "HomeRuns", adDouble
DataList.Open

Set objFSO = _
  CreateObject("Scripting.FileSystemObject")
Set objFile = objFSO.OpenTextFile _
  ("C:\Scripts\Test.txt", ForReading)

objFile.SkipLine

Do Until objFile.AtEndOfStream
    strStats = objFile.ReadLine
    arrStats = Split(strStats, vbTab)

    DataList.AddNew
    DataList("Player") = arrStats(0)
    DataList("HomeRuns") = arrStats(1)
    DataList.Update
Loop

objFile.Close

DataList.MoveFirst

Do Until DataList.EOF
    Wscript.Echo _
        DataList.Fields.Item("Player") & _
        vbTab & _
        DataList.Fields.Item("HomeRuns")
    DataList.MoveNext
Loop
まず、次の 4 つの定数を定義します。
  • ForReading: テキスト ファイルを開いて、そのデータを読み取るときに使用します。
  • adVarChar: Variant データ型を使用するフィールドを作成する標準の ADO 定数です。
  • MaxCharacters: Variant データ型のフィールドが保持できる最大文字数 (この場合は 255 文字) を示すのに使用する標準の ADO 定数です。
  • adDouble: Double (Numeric) データ型を使用するフィールドの作成に使用する ADO 定数です。
この 4 つの定数の定義の後には、次のコード ブロックがあります。
Set DataList = CreateObject _
    ("ADOR.Recordset")
DataList.Fields.Append "Player", _
    adVarChar, MaxCharacters
DataList.Fields.Append "HomeRuns", _
    adDouble
DataList.Open
これは、切断されたレコードセットを実際に設定して構成するスクリプト部分です。このタスクを実行するには、まず、ADOR.Recordset オブジェクトのインスタンスを作成する必要があります。言うまでもありませんが、このオブジェクトを作成することで、仮想データベース テーブル (つまり、切断されたレコードセット) が作成されます。
次のコード行 (そして Append メソッド) を使用して、新しいフィールドをレコードセットに追加します。
DataList.Fields.Append "Player", adVarChar, MaxCharacters
ご覧のとおり、ここでは特別なことはしていません。単に Append メソッドを呼び出す際に次の 3 つのパラメータを渡しているだけです。
  • フィールド名 (Players)
  • フィールドのデータ型 (adVarChar)
  • フィールドに保存できる最大文字数 (MaxCharacters)
Players フィールドを追加したら、2 番目のフィールドである、Numeric (adDouble) データ型の HomeRuns フィールドを追加できます。その作業が終了したら、Open メソッドを呼び出して、レコードセットを開いて、作業をする準備ができていることを宣言します。
次に Scripting.FileSystemObject オブジェクトのインスタンスを作成して、C:\Scripts\Test.txt ファイルを開きます。スクリプトのこの部分は、実のところ切断されたレコードセットとは関係ありません。これは、テキスト ファイルからデータを取得するために必要な処理です。テキスト ファイルの最初の行には、次のようなヘッダー情報が含まれています。
Player     Home Runs     RBI        Average
この情報はレコードセットには必要ないので、ファイルを開いたら、まず SkipLine メソッドを呼び出して、この最初の行をスキップするように指示します。
objFile.SkipLine
これで、実際のデータが含まれている最初の行へと移動できたので、ファイルの残りのデータを行ごとに読み取る Do Until ループを設定します。ファイルから 1 行のデータを読み取るたびに、strLine という名の変数に値を格納し、Split メソッドを使用して (行データをタブで分割することにより) その行データを値の配列に変換します。
arrStats = Split(strStats, vbTab)
確かに、これは大雑把な説明ですが、大部分の方は、これまでのコラムからテキスト ファイルの情報を取得する方法は理解していると思うので問題ないでしょう。手短に言うと、1 回目のループ処理が完了すると、arrStats 配列には、図 3 に示すアイテムが含まれるようになります。
図 3 配列の内容
アイテム番号 | アイテム名
0 | D Pedroia
1 | 4
2 | 28
3 | .276
さて、ここからがおもしろいところです。
DataList.AddNew
DataList("Player") = arrStats(0)
DataList("HomeRuns") = arrStats(1)
DataList.Update
ここで、選手 1 (D Pedroia) の情報を切断されたレコードセットに追加します。レコードをレコードセットに追加するために、まず AddNew メソッドを呼び出します。このメソッドでは、空の新しいレコードが作成されるので、この新しいレコードを使用して作業をします。その次の 2 行のコードを使用して、2 つのレコードセット フィールド (Player と HomeRuns) に値を割り当てます。その後、Update メソッドを呼び出して、レコードをレコードセットに書き込みます。それから、再度、ループの先頭に戻り、テキスト ファイルの次の行 (つまり次の選手) に対して同じ処理を繰り返します。どうですか。たくさんコードがあるように見えますが、とても単純でわかりやすいですよね。
では、すべての選手の情報がレコードセットに追加されたらどうなるのかをご説明しましょう。テキスト ファイルを閉じると、次のコード ブロックが実行されます。
DataList.MoveFirst

Do Until DataList.EOF
  Wscript.Echo _
    DataList.Fields.Item("Player") & _
    vbTab & _
    DataList.Fields.Item("HomeRuns")
  DataList.MoveNext
Loop
1 行目では、MoveFirst メソッドを使用してカーソルをレコードセットの先頭に移動します。これを実行しないと、レコードセットのデータの一部しか表示されないことがあります。その後、データがなくなるまで (つまり、レコードセットの EOF (ファイルの終わり) プロパティが True になるまで) 実行する Do Until ループを設定します。
このループ処理では、Player フィールドと HomeRuns フィールドの値がエコー バックされるだけです (特定のフィールドを指定するのに少し変わった DataList.Fields.Item("Player") という構文を使用している点にご注意ください)。 その後、MoveNext メソッドを呼び出してレコードセットの次のレコードに移動します。
言うまでもないことですが、これは本当に簡単でしたね。すべての作業を完了すると、次のような情報が返されます。
D Pedroia       4
K Kouzmanoff    8
J Francouer     7
C Guzman        5
F Sanchez       2
I Suzuki        3
J Hamilton      17
I Kinsler       7
M Ramirez       12
A Gonzalez      17
ご覧のとおり、考えてみるとそれほど大したものではないですね。選手の名前とホームランの合計数は取得できましたが、ホームランの合計数で並べ替えられていません。困りましたね。どうして切断されたレコードセットでは自動的にデータが並べ替えられないのでしょうか。
これには実は相応の理由があります。レコードセットに並べ替える基準となるフィールドを伝えなかったからです。でも、これは簡単に修正できます。スクリプトを変更して、MoveFirst メソッドを呼び出す直前に並べ替えの情報を追加すれば良いだけです。つまり、スクリプトの該当部分を次のように変更します。
DataList.Sort = "HomeRuns"
DataList.MoveFirst
一目瞭然ですが、ここでは何も特殊なことはしていません。HomeRuns フィールドを Sort プロパティに代入しているだけです。このスクリプトを実行した場合の出力は次のようになります。
F Sanchez       2
I Suzuki        3
D Pedroia       4
C Guzman        5
J Francouer     7
I Kinsler       7
K Kouzmanoff    8
M Ramirez       12
J Hamilton      17
A Gonzalez      17
ずっとわかりやすいですね。ただし、1 つだけ問題があります。普通、ホームランの合計数は、選手が打ったホームランが多い方から少ない方という降順で表示されます。降順でデータを並べ替える方法はあるのでしょうか。
もちろんあります。その場合に必要なことは、次のように、便利な DESC パラメータを付け加えるだけです。
DataList.Sort = "HomeRuns DESC"
DESC パラメータは何をしてくれるのかというと、このパラメータを追加した場合の結果を見てもらえば、わかるでしょう。
A Gonzalez      17
J Hamilton      17
M Ramirez       12
K Kouzmanoff    8
I Kinsler       7
J Francouer     7
C Guzman        5
D Pedroia       4
I Suzuki        3
F Sanchez       2
ちなみに、複数のプロパティで並べ替えることは可能です。その場合に必要な作業は、並べ替えの対象となる各プロパティを Sort ステートメントに指定するだけです。たとえば、最初にホームランの数で並べ替えて、次に打点で並べ替えたい場合も問題ありません。次のコマンドを使うと、この処理を簡単に行うことができます。
DataList.Sort = "HomeRuns DESC, RBI DESC"
試してみて結果をご覧になってください。休暇中にメールをチェックするほど楽しくはありませんが、それに近い楽しさはあると思います。
注 レコードセットに追加していないフィールドでデータを並べ替えることはできません。これはどういうことかというと、たとえば、RBI というプロパティを Sort ステートメントに追加する場合は、その前に、スクリプトの適切な場所に次の行を追加する必要がある、ということです。
DataList.Fields.Append "RBI", adDouble

DataList("RBI") = arrStats(2)
また、出力を確認するには、Wscript.Echo ステートメントを次のように変更する必要があります。
Wscript.Echo _
  DataList.Fields.Item("Player") & _
  vbTab & _
  DataList.Fields.Item("HomeRuns") & _
  vbTab & DataList.Fields.Item("RBI")
他に、切断されたレコードセットで何を行うことができるのか、ですって。そうそう、こんなことができます。全選手のすべての情報を取得して、データを打率で並べ替えるとします (これには、他にも必要な作業はありますが、元のスクリプトを変更して、RBI フィールドと Batting-Average フィールドを作成する必要があるというのが主な作業です)。結果は次のようになります。
J Hamilton      17      67      0.329
I Kinsler       7       35      0.309
A Gonzalez      17      55      0.304
C Guzman        5       20      0.299
M Ramirez       12      39      0.295
I Suzuki        3       15      0.287
D Pedroia       4       28      0.276
K Kouzmanoff    8       25      0.269
J Francouer     7       35      0.254
F Sanchez       2       25      0.238
この一覧には何も問題はありませんが、打率が 3 割以上の選手の一覧が必要な場合やある特定の条件に合う選手のデータだけを表示する場合はどうしたら良いのか知りたい方がいるようですね。そうですね。その方法の 1 つとして、Filter をレコードセットに割り当てることができます。
DataList.Filter = "BattingAverage >= .300"
レコードセットのフィルタは、データベースのクエリとほぼ同じ働きをします。つまり、返されるデータをレコードセットの全レコードのサブセットに制限するメカニズムを提供します。ここでは、Batting-Average フィールドに .300 以上の値があるフィールド以外のすべてのレコードを除外するように Filter に指示しています。さて、どうでしょう。フィルタでは指示した処理が実行されます。
J Hamilton      17      67      0.329
I Kinsler       7       35      0.309
A Gonzalez      17      55      0.304
子供たちがこのように反応するとしたらすばらしいと思いませんか。
1 つのフィルタには複数の条件を含めることができます。たとえば、次のコマンドでは、BattingAverage フィールドの値が .300 以上であり、かつ HomeRuns フィールドの値が 10 より大きいレコードのみを返すように制限しています。
DataList.Filter = _
  "BattingAverage >= .300 AND HomeRuns > 10"
また、次のフィルタでは、BattingAverage フィールドの値が .300 以上であるか、または HomeRuns フィールドの値が 10 より大きいレコードのみを返すように制限しています。
DataList.Filter = "BattingAverage >= .300 OR HomeRuns > 10"
両方のフィルタをご自分で試して、違いを確かめてください。どうせならついでに、次のフィルタも試してみてください。
DataList.Filter = "Player LIKE 'I*'"
フィルタではワイルドカードを使用することもできます。これには、(等号ではなく) LIKE 演算子を使用して、MS-DOS® で dir C:\Scripts\*.txt のようなコマンドを実行する場合と同様にアスタリスクを使います。上記の例では、I で始まる名前の選手の一覧が返されます。というのも、ここでは「Player フィールドの値が I で始まり、その後には任意の文字列が続くすべてのレコードの一覧を表示するように」と指示する構文を使用しているからです。これもご自分で…。もう言いたいことは、おわかりですよね。
ところで、0.309 のような打率の表記にはこだわっていませんよね (通常、打率の前には 309 のように 0 を付けません)。こだわりがある場合でも大丈夫です。FormatNumber メソッドを使えば、打率をお好みの表記に変えることができます。
FormatNumber (DataList.Fields.Item("BattingAverage"), 3, 0)
Wscript.Echo ステートメントの数字を表示するところに、このメソッドを含めます (または、出力内容を変数に代入して、Echo ステートメントにその変数を組み入れることも可能です)。
Wscript.Echo _
  DataList.Fields.Item("Player") & _
  vbTab & _
  DataList.Fields.Item("HomeRuns") & _
  vbTab & DataList.Fields.Item("RBI") & _
  vbTab & _
  FormatNumber _
  (DataList.Fields.Item("BattingAverage"), _
   3, 0)
お楽しみいただけましたでしょうか。
残念ながら、今月も時間切れのようです。まとめとして言いますと…。すみません、電話が鳴っています。
とにかく、お伝えしたいのは…。おっと、今度は携帯電話が鳴っています。おまけに、トースターからメールが届きました。「重要なお知らせ : トーストが焼き上がりましたが、バターとジャムのどちらを塗りますか」という内容です。もう行かなければなりません。では、また来月お会いしましょう。
Dr. Scripto のスクリプト パズル
パズルを解く能力だけでなく、スクリプト作成スキルもテストする月に 1 度の課題です。

2008 年 9 月 : スクリプト探し
これは簡単な言葉探しです (もしかすると、そう簡単ではないかもしれませんが)。次の一覧にある VBScript 関数とステートメントをすべて探し出してください。ちょっとした仕掛けが隠されています。残った文字は、PowerShell™ コマンドレットの名前になっています。
単語の一覧 : Abs、Array、Atn、CCur、CLng、CInt、DateValue、Day、Dim、Else、Exp、Fix、InStr、IsEmpty、IsObject、Join、Len、Log、Loop、LTrim、Mid、Month、MsgBox、Now、Oct、Replace、Set、Sin、Space、Split、Sqr、StrComp、String、Timer、TimeValue、WeekdayName

解答 :
Dr. Scripto のスクリプト パズル
解答 : 2008 年 9 月 : スクリプト探し

Scripting Guys は、マイクロソフトの仕事をしています、というよりもマイクロソフトにより雇われています。野球をプレイしたり監督したり観戦したり (または他のさまざまな活動を) しているのでない限り、彼らは TechNet スクリプト センターを運営しています。詳細については、www.scriptingguys.com を参照してください。


デスクトップ ファイル WDS の高度な機能
Wes Miller

目次
コマンド ラインからの管理
イメージ ストア
マルチキャスト
WDS によるログ記録
その他の問題点
まとめ
ここ 2 回のコラムでは、Windows Deployment Services (WDS) について紹介してきました。先々月のコラムでは、マイクロソフトが提供している PXE (Pre-boot eXecution Environment) ベースの展開ツールの歴史を紹介し、先月は WDS の概要を説明しました。今月は、もう少し高度なトピックを紹介します。
具体的には、WDSUtil (WDS の強力なコマンドライン ユーティリティ)、WDS イメージ ストア、WDS のログ記録機能、Windows Server® 2008 に収録されている WDS のマルチキャスト機能を使用する方法を紹介します。
Windows® 2000 と Windows Server 2003 に同梱されていたリモート インストール サービス (RIS) の機能は期待されていましたが、残念ながら、その機能には制限がありました。特に顕著だったのは下記の 3 点でした。
  • パフォーマンス (よりスケーラブルな展開)
  • ログ記録と監査
  • コマンド ラインによる自動化
今月のコラムを読み進めると、WDS の初期リリース (Windows Server 2008 に同梱されている WDS) では、これらの点が大幅に改善されたことがおわかりいただけると思います。

コマンド ラインからの管理
WDS で管理コンソールが大幅に強化されたことについては、先月のコラムでお知らせしました。ですが、多くの企業にとってさらに重要なのは、WDSUtil.exe という新しいコマンドライン ユーティリティ (図 1 参照) が用意されていることです。WDSUtil は、(SP1 と WDS、または SP2 がインストールされている) Windows Server 2003 で WDS オプション コンポーネントをインストールしている場合、または Windows Server 2008 で WDS の役割をインストールしている場合にインストールされます。
図 1 WDSUtil を使用してアーキテクチャ探索のオプションを有効にする (画像をクリックすると拡大表示されます)
WDSUtil は非常に強力なユーティリティですが、複雑なユーティリティでもあります。実際、WDSUtil を使用すると、Microsoft® 管理コンソール (MMC) を使用して行えるすべての処理だけでなく、それ以外の処理を行うこともできます。その好例をご覧に入れるため、次のコマンドを実行してみてください (このコマンドは、発生している問題を診断するのに最適なコマンドです)。
wdsutil /get-server /show:config
結果は、WDS の MMC で表示されるものとほぼ同じですが、WDSUtil を使用すると、テキスト ファイルにエクスポートできて、簡単に解読できる形式で結果を出力できます。
これでは情報が足りないという方は、次のコマンドを実行してみてください。このコマンドでは、より詳細な情報が返されます。
wdsutil /get-server /show:all /detailed
また、次のコマンドを実行すると WDS サーバーを停止および再開できます。
wdsutil /stop-server
wdsutil /start-server
WDSUtil のコマンドライン リファレンスについては、go.microsoft.com/fwlink/?LinkId=112194 を参照してください。.chm 版をご希望の場合は、go.microsoft.com/fwlink/?LinkId=89381 からダウンロードしてご利用いただけます。
RIS では、Active Directory® サービスのインターフェイスに詳しくない限り、コマンド ラインを使用して、特定の MAC アドレスまたは GUID が Active Directory のコンピュータ アカウント オブジェクト (MAO) と関連付けられているかどうかを簡単に調べることはできませんでした。しかし、WDSUtil では、そのどちらを使用しても関連付けられている MAO をクエリすることができます。
GUID は混乱を招くことがあります。というのも、GUID はバイナリ文字列または GUID 文字列として入力することが可能で、その違いはバイト オーダーとハイフンの有無だけだからです。これに対して MAC アドレスは、次のいずれかのコード行を使用して、ハイフンあり/ハイフンなしのどちらの状態でも入力できます。
wdsutil /get-device /id:01-23-45-67-89-AB
wdsutil /get-device /id:0123456789AB
次のコマンドを実行すると、バイナリ文字列を使用してデバイス情報を取得できます。
wdsutil /get device /id:ACEFA3E81F20694E953EB2DAA1E8B1B6
また、次のコマンドを実行すると、GUID 文字列を使用してデバイス情報を取得できます。
wdsutil /get device /id:E8A3EFAC-201F-4E69-953-B2DAA1E8B1B6
皆さんが使用している多くのコンピュータでは 64 ビット版の Windows を実行できると思いますが、中にはアーキテクチャが適切に報告されないコンピュータもあります。WDS を使用すると、WDS に組み込まれている小規模なネットワーク ブート プログラムを実行して、システムが x64 に対応しているかどうかを特定できます。図 1 に示すように、この処理は次のコマンドを使用して行えます。
wdsutil /set-server /architecturediscovery:yes
実際、WDSUtil /set-server コマンドを実行すると、多数のサーバーの設定を構成できます。次のコマンドを実行して、その動作を確認してください。
wdsutil /set-server /?
Windows Server 2003 を実行している WDS サーバーを Windows Server 2008 にアップグレードした場合は、次のコマンドを実行して、RIPrep イメージを Windows イメージング形式のイメージに変換できます。
WDSUtil /convert-RIPrepImage
WDSUtil を使用して RIPrep イメージを変換することはできますが、それ以外の RISetup イメージ (従来の RIS インストール、WDS でスクリプト化されたレガシ インストール) を変換することはできません。
WDSUtil は、繰り返し作業を自動化できるという点で優れています。図 2 に示すコマンドを参照すると、WDSUtil の機能の考え方がつかめると思います。新しい WDS サーバーを展開している場合でも、複数のサーバーに対してイメージを追加または変更している場合でも、マルチキャスト インフラストラクチャを管理している場合でも、特定のブート クライアントで使用するネットワーク ブート プログラムを指定している場合でも、WDSUtil を使用すると RIS にはなかった強力な機能が提供されます。
図 2 WDSUtil のコマンド
コマンド | 説明
/add | デバイス、イメージ、またはイメージ グループを追加する。
/approve-AutoAddDevices | 保留中の自動追加デバイスを承認し、そのデバイスの構成情報を設定する。
/convert-RiprepImage | RIPrep レガシ イメージを WIM イメージに変換する。
/copy-Image | イメージ ストア内でイメージを複製する。
/delete-AutoAddDevices | すべてまたは特定の保留中の自動追加デバイスを削除する。
/disable | WDS サーバーまたはトランスポート サーバーを無効にする。
/disconnect-Client | クライアントをマルチキャスト転送または名前空間から切断する。
/enable | WDS サーバーまたはトランスポート サーバーを有効にする。
/export-Image | イメージ ストアの既存イメージを別の WIM イメージにエクスポートする (ImageX で /export を使用する場合と同等)。
/get | デバイス、イメージ、イメージ グループ、WDS サーバー、またはトランスポート サーバーのプロパティと属性を取得する。
/initialize-Server | 初期インストール後、WDS サーバーを使用できるように構成する。
/new | キャプチャを作成するか、イメージ、マルチキャスト転送、および名前空間を探索する。
/progress | 特定のコマンドが実行されているときに進行状況を表示する。
/reject-AutoAddDevices | すべてまたは特定の保留中の自動追加デバイスを拒否する。
/remove | イメージ、イメージ グループ、マルチキャスト転送、および名前空間を削除する。
/replace-Image | イメージを新しいイメージで置き換える (上書きする)。
/set | デバイス、イメージ、イメージ グループ、WDS サーバー、またはトランスポート サーバーのプロパティと属性を設定する。
/start | WDS サーバーまたはトランスポート サーバーを開始する。
/stop | WDS サーバーまたはトランスポート サーバーを停止する。
/uninitialize-Server | サーバーの初期設定時に加えた変更を元に戻す (未構成の状態に戻す)。
/update-ServerFiles | サーバーの System32\RemInst ディレクトリにある最新バージョンで、サーバーの REMINST 共有にあるファイルを更新する。
/verbose | 特定のコマンドが実行されているときに詳細情報を表示する。

イメージ ストア
先月のコラムでは、RIS でディスクにファイルをより効率的に格納するために使用されていた単一インスタンス記憶域 (SIS) が、WDS で廃止されたことを説明しました。現在、すべてのネイティブ モード (WIM) イメージは、OS に関係なく、WDS イメージ ストアに格納されます。また、以前のコラムで、単一インスタンス機能を使用すると、ボリューム イメージに関連ファイルがある場合に、.wim ファイルの領域を節約できることを紹介しましたが、WDS イメージ ストアは、それと同じように機能します。実際、このストアでは、イメージを格納する際に WIM の機能を使用しています。
WDS イメージ ストアを使用するには、少なくとも 1 つのイメージ グループが必要です。ただし、通常、WDS の初期設定時に、イメージ グループを作成するように要求されます。インストール イメージを追加する際に、新しいイメージ グループを作成することは可能です。このようにイメージ グループを作成すると、インストール イメージは作成したイメージ グループに追加されます (図 3 参照)。
図 3 新しいイメージ グループの作成 (画像をクリックすると拡大表示されます)
イメージ ストアについて説明しましょう。RemoteInstall ディレクトリには、Images という名前のサブディレクトリがあり、作成した各イメージ グループのディレクトリは、ここに格納されます。図 4 に示すように、イメージ グループにインポートした各インストール イメージには、.wim ファイルと .rwm ファイル (リソース WIM) がそれぞれ 1 つずつあります。
図 4 イメージ グループのコンテンツ (画像をクリックすると拡大表示されます)
図 4 のファイルをよく見ると、このイメージ グループは、次のファイルで構成されています。
  • install.wim (Windows Server 2008, Standard Edition)
  • install-(2).wim (Windows Server 2008, Enterprise Edition)
  • install-(3).wim (Windows Server 2008, Datacenter Edition)
  • install-(4).wim (Windows Server 2008, Standard Edition (Server Core)
  • install-(5).wim (Windows Server 2008, Enterprise Edition (Server Core)
  • install-(6).wim (Windows Server 2008, Datacenter Edition (Server Core)
今度は、これらのファイルのサイズを、MMC に表示されるファイルのサイズ (図 5 参照) と比較してみましょう。図 4 の .wim ファイルのサイズは、対応する Res.rwm ファイルのサイズと比べると、かなり小さいことがわかります。というのも、表示されている .wim ファイルは、使用する領域を抑えるために実際のファイルのスタブになっているからです。.wim ファイルの復元に必要なメタデータは含まれていますが、ファイル リソースは含まれていません。イメージ グループのリソースは、そのイメージ グループの .rwm ファイルに格納されます。
図 5 サーバー マネージャで表示されるイメージ (画像をクリックすると拡大表示されます)
イメージ ストアのインストール イメージを編集する方法は 2 とおりあります。1 つは、イメージをエクスポートして編集し、既存のイメージを置き換える (または新しいイメージとしてインポートする) 方法です。もう 1 つは、編集するインストール イメージを MMC で無効にし、.wim ファイルをマウントして直接編集する方法です。
RIS でいつも問題となっていたのは、イメージの複製です。SIS ファイルをネットワーク経由でコピーすると、SIS は NTFS 属性なので、SIS の情報が失われます。つまり、40 GB の RISetup イメージと RIPrep イメージを別のサーバーに複製する場合、SIS Groveler を使用してイメージのサイズを 5 GB まで縮小していても、実際にはネットワーク経由で 40 GB のイメージを複製することになりました。しかし、WDS イメージ ストアでは、このような問題は発生しません。イメージ ストアのアーキテクチャの特性により、イメージは分散ファイル システム (DFS) サーバーに保存し、DFS レプリケーション (DFS-R) を使用して、イメージをサイト間で複製できます。
ただし、詳細は WDS のバージョンによって異なります。Windows Server 2003 の場合は、go.microsoft.com/fwlink/?LinkId=81031 からダウンロードできるドキュメントの「第 7 章 : イメージを操作する」を参照してください。Windows Server 2008 については、「DFS を使用してイメージを格納および複製する」(go.microsoft.com/fwlink/?LinkId=121960) を参照してください。サーバー間でイメージ グループをコピーする場合も、すべてのリソースは .rwm ファイルに格納されているので、.wim ファイル全体を転送する場合 (RIS SIS アーキテクチャの場合) と比べると、ネットワーク経由で送信されるデータはごく少量です。
今度は、どのような場合に新しいイメージ グループを作成し、どのような場合に既存のイメージ グループを使用するのかについて説明しましょう。通常、その規則は .wim ファイルの場合と同じです。主に Windows Server 2008 のイメージで構成されているイメージ グループに Windows XP Professional SP3 のイメージを追加することはできますが、それほど領域を節約できるわけではないので、あまり意味がありません。.wim ファイルの場合と同様に、通常、少なくとも次の項目のイメージ グループを用意することをお勧めします。
  • Windows の各リリース (リリースとは、SKU (Windows XP Professional) とサービス パック改定 (SP3) の両方を指します)。
  • Windows Server 2003 以前の (Multilanguage User Interface を使用していない) 各ローカライズ版。Windows Vista® 以前のリリースのローカライズ版ビルドでは、まったく別のバイナリが使用されていたので、単一インスタンスという観点では、.wim ファイルに適切に格納できませんでした。
  • 各リリースのすべてのサービス パック。Windows Server 2008 と Windows Vista SP1 のイメージを同じイメージ グループに格納することはできますが、そのようなことをした場合に、ご使用の環境で意味があるのかを検討する必要があります。
イメージ ストアでは SIS よりも効率的に領域を節約できます。ディスク上の領域もネットワークの帯域幅のどちらも節約することが可能で、通常、イメージ ストアを正常に運用するのに必要な作業はわずかです。

RIS の最大の欠点は、スケーラビリティがないことです。マルチキャスト展開とは名ばかりで、単に展開のプロセスを整えているだけでした。マルチキャスト展開は、迅速な展開であると思われがちですが、ここで焦点となるのは速度ではなく数量です。RIS を使用して複数のシステムを展開することは可能で、実際、約 75 台のシステムを同時に展開することができました。
しかし、すべてのシステムの展開が完了するかなり前の段階で、パフォーマンスが低下し、各システムのインストールにかかる時間は徐々に長くなりました。もっと悪いことに、システムの数が多くなるほど、エラーが発生する可能性も高くなりました。また、複数のインストールを行うと、サーバー メッセージ ブロック (SMB) ネットワーク トラフィックによりネットワークの負荷が過剰に高くなります。そのため展開時には、従業員が Microsoft Exchange Server などの重要なネットワーク リソースにアクセスできない状況が生じる可能性があります。
マルチキャストは、展開するシステムの数を増やすためのものです。マルチキャストを使用すると、4 台のサーバーを展開している場合でも、100 台のシステムを伴うカンファレンス センターを展開している場合でも、ネットワークの負荷が過剰に高くなることなく、適度な時間で展開を完了することができます。マルチキャストを使用して 1 台のシステムを展開することはできますが、複数台のシステムがマルチキャスト転送をリッスンする状況でないとマルチキャストを使用するメリットは実感できません。
マルチキャストを使用するには、マルチキャストをサポートしているルーターが必要です。通常、これはルーターでインターネット グループ管理プロトコル (IGMP) 捜索を有効にする必要があるということになります。また、Windows Vista RTM に同梱されている Windows PE 2.0 では、マルチキャスト転送の受信がサポートされていないので、Windows Server 2008 RTM または Windows Vista SP1 に同梱されている Windows PE 2.1 が必要です。
同一ネットワークに複数の WDS サーバー (または他のマルチキャスト サーバー) がある場合は、カスタマイズした IP アドレス範囲を指定する必要があることにも注意してください。この範囲は、WDS の MMC を使用して簡単に変更できます。必要な操作は、サーバーを右クリックし、[プロパティ] をクリックして、[ネットワーク設定] タブをクリックするだけです。
マルチキャスト サーバーでマルチキャスト ブロードキャストを行う際には、最も低速なクライアントが受信できる速度に合わせることも、それより速い速度で調整し、その速度に対応できないクライアントについてはサポートを断念することもできます。信頼性を確保するため、WDS は、マルチキャスト転送を受信するクライアントの中で最も低速なクライアントが対応できる速度で実行されます。
マルチキャスト転送のパフォーマンスが期待値よりも低いと感じる場合は、「wdsutil /Get-MulticastTransmission /Show-clients」というコマンドを実行してください。このコマンドを実行すると、転送の速度を制限しているクライアントを特定できます。問題のあるクライアントを切断すると、そのクライアントではマルチキャストではなく SMB を使用するように設定がリセットされます。低速なクライアントを自動的に切断するスクリプトのサンプルについては、go.microsoft.com/fwlink/?LinkId=121961 を参照してください。
マルチキャスト転送を作成するには、インストール イメージを右クリックして [マルチキャスト転送の作成] をクリックするか、または WDS コンソールで [マルチキャスト転送] を右クリックして [マルチキャスト転送の作成] をクリックします。マルチキャスト転送を作成する際には、自動キャストまたはスケジュールされたキャストを指定できます。自動キャストは、定期的にオンライン状態になるクライアントが複数あって、各クライアントで同じイメージを使用する場合に便利です。新しいクライアントは、最初にインストール イメージを要求したクライアントのために初期化されたアクティブなマルチキャスト転送に自動的に追加されます。スケジュールされたキャストを使用すると、グループ サイズを設定し、そのサイズに達したときに転送を開始するようにできます。
また、転送の開始時間を設定することもできます。クライアントがマルチキャスト転送を使用しているときには、イメージ名をクリックして、クライアントを確認できます。また、右側のウィンドウでは、マルチキャスト転送に接続しているクライアントの詳細を確認できます。
通常、エンド ユーザーは、WDS セットアップ クライアントでマルチキャストを使用します。ただし、Windows Server 2008 Windows 自動インストール キット (WAIK) に収録されている WDSMCast という名前のコマンド ライン ユーティリティを使用すると、WDS からマルチキャスト転送を使用して .wim ファイルを要求できます。.wim ファイルは、ファイル全体が転送され、クライアントに適用される必要があるので、イメージを格納して適用するのに十分なディスク領域があることを確認する必要があります。来月は、WDSMCast をカスタム展開プロセスに組み込む方法を紹介します。

WDS によるログ記録
WDS では、さまざまな情報をログに記録したり、追跡したりすることができますが、その多くは、領域を節約するために既定で無効になっています。イベント ログには、クライアントが Windows イベント ログに記録するもの、WDS の他の要素についてトレース ログに記録されるものの 2 種類があります。
しかし、Windows Server 2008 では、WDS は、既定で多くの情報をログに記録します。このログは、管理ツールのイベント ビューアで確認できます。また、WDS ログは、イベント ビューアの [アプリケーションとサービス ログ\Microsoft\Windows\Deployment-Services-Diagnostics] で確認できます。これらのログは、MMC (図 6 参照) で WDS の役割を表示したときにも参照できます。
図 6 サーバー マネージャで表示される WDS イベント (画像をクリックすると拡大表示されます)
WDS クライアントのログ記録 (図 6 に示すようにイベント ログで確認できます) は、次の引数を指定して WDSUtil を実行することで開始できます。
wdsutil /wdsclientlogging /enabled:yes /logginglevel:info
トレース ログは、WDS のサブコンポーネントについても有効にすることができます。トレースを構成するには、図 7 に示すレジストリ キーの下に DWORD レジストリ値を作成します。すべてのトレース ログは、\Windows\tracing に格納されます。ログ記録を開始するには、レジストリ値を作成後に、ログ記録の対象となるサブコンポーネントを再起動する必要があります。
図 7 トレース ログの設定
WDS コンポーネント | レジストリ キー | レジストリ値 | ログ ファイル名
サーバー | HKLM\SOFTWARE\Microsoft\Tracing\WDSServer\EnableFileTracing | 1 | wdsserver.log
マルチキャスト | HKLM\System\CurrentControlSet\Services\WDSServer\Providers\WDSMC\TraceDisabled | 0 | wdsserver.log
管理コンポーネント | HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Tracing\WDSMGMT\EnableFileTracing | 1 | wdsmgmt.log
MMC | HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Tracing\WDSMMC\EnableFileTracing | 1 | wdsmmc.log
WDS にはパフォーマンス カウンタが用意されています。システムのパフォーマンスに問題が生じた場合だけでなく正常時にシステムのパフォーマンスを解析する場合にも、このパフォーマンス カウンタを監視できます。WDS のパフォーマンス カウンタについては、go.microsoft.com/fwlink/?LinkId=121962 を参照してください。既に説明しましたが、問題が発生したときには、WDSUtil で /detailed、/verbose、または /progress スイッチを使用して、詳細情報を入手できます。
WDS クライアントで WDS サーバーとの接続または対話で問題が発生している場合、問題を解決するには Microsoft ネットワーク モニタ (Netmon) を使用することをお勧めします。ネットワーク モニタは、go.microsoft.com/fwlink/?LinkId=121491 からダウンロードしてご利用いただけます。

その他の問題点
私は、これまでに、ここで紹介すべきいくつかの問題に遭遇しました。1 つはメモリです。WDS の中核部分は、Windows PE 2.x ベースです。つまり、WDS クライアントでは、最低 384 MB の RAM が必要であるということになります。また、最適なパフォーマンスを実現するには、512 MB の RAM が必要です。また、Windows PE 2.x は、ACPI (Advanced Configuration and Power Interface) に対応していないシステムではブートできません。ACPI に対応していないハードウェアは、古いハードウェアだけであるとは限らず、比較的新しいシステムでも ACPI をサポートしていないものがあることが報告されています。
このようなシステムでは、Windows Vista または Windows Server 2008 がサポートされない点にも注意してください。ACPI をサポートしないシステムでは、Windows Server 2003 あるいは、以前の WDS サーバーまたは RIS サーバーを維持して、プレステージされたクライアントがサーバーを利用できるようにするか、PXE 以外のメカニズムを使用して Windows をインストールする必要があります。
最後になりますが、サーバーで Windows PE 1.x イメージをブートするには、Windows Server 2003 あるいは以前の WDS サーバーまたは RIS サーバーが必要であることに注意してください。というのも、Windows Server 2008 に同梱されている WDS では、Windows PE 1.x イメージ (RAMDisk または PXE) をブートできないからです。

まとめ
ここ 3 回のコラムでは、WDS の歴史、基本事項、および高度なトピックを取り上げました。来月は、WDS のカスタム シナリオを紹介します。具体的には、WDS を操作および調整して、既存の WDS の動作や設定を使用することなく、必要なタスクを実行する方法を紹介します。

Wes Miller は、テキサス州オースティンにある CoreTrace 社 (www.CoreTrace.com) のシニア テクニカル プロダクト マネージャです。以前は Winternals Software 社に勤務し、その後はマイクロソフトでプログラム マネージャとして働いていました。Wes の連絡先は、technet@getwired.com (英語のみ) です。


セキュリティ ウォッチ パスワードとクレジット カード、第 3 部
Jesper M. Johansson

目次
過剰な更新テクノロジ
セキュリティに関する矛盾したメッセージ
チェック ボックスこそすべて
召集
ここ 2 回の TechNet Magazine の記事では、セキュリティ プロフェッショナルと IT 業界全体が、どのようにユーザーを混乱させ、効果的なセキュリティ向上を実は妨げているかについて説明しました。このシリーズの第 1 部と第 2 部では、ユーザーに誤解を招くおそれのある情報を提示するソリューション、ログオン手順を
必要以上に複雑にするソリューション、不適切な操作を指示するソリューションなどの問題について説明しました。前回までは、業界がユーザーのセキュリティに配慮していることを示そうとして、その結果、必要以上に状況を悪化させているさまざまな例を紹介しました。このシリーズの最終回となる第 3 部では、ユーザーが利用できる最も重要なテクノロジの一部が、ユーザーの期待値に達していない理由について説明します。これらすべてを説明したら、召集をかけます。

過剰な更新テクノロジ
コンピュータの安全を保つ主な見解の 1 つ (実際、疑う余地のない必要条件) は、すべてのソフトウェアを最新の状態に保つことです。ほぼすべての大手ソフトウェア プロバイダでは、現在なんらかの形式で、ソフトウェアの少なくとも一部を最新の状態に保つための半自動的化されたメカニズムを使用しています。しかし、これはそれほど単純なことではありません。
1 つ目の問題は、インストールしているソフトウェアの数が多くなると、更新するソフトウェアの数も多くなることです。しかも、複数のソフトウェア ベンダのソフトウェアを使用している場合は、対応しなければならない更新メカニズムも多くなります。これが混乱の原因です。
たとえば、既定の設定では、Internet Explorer® は自動的に更新されます。しかし、Internet Explorer は他のテクノロジの入れ物にすぎません。このことに起因して発生する可能性がある問題が、2008 年の CanSecWest カンファレンスで Shane Macaulay 氏が Java と Adobe Flash の脆弱性を利用して Mac のハッキングを行った際に証明されました (この記事の執筆時点では欠陥が未公表のため、詳細は不明です)。ただし、私が指摘したいのは、これらのテクノロジはいずれも組み込みのコンポーネントではないにもかかわらず、どちらもインターネット上で非常に幅広く使用されているのでほとんどのコンピュータで使用できるという点です。どちらのテクノロジも最新の状態を保つのは少し困難です。というのも、それぞれに自動更新メカニズムがありますが、いずれのメカニズムもあまり頻繁に起動されることがないからです。
さらに、ほとんどのエンド ユーザーは Java と Adobe Flash が存在していることにも更新する必要があることにも気付いていません。多くの場合、これらのテクノロジはコンピュータの OEM イメージに含まれた形で提供されているので、ユーザーはオペレーティング システムと区別できません。エンド ユーザーにとっては、Windows® Update に更新プログラムがないことが表示されれば、更新プログラムはないということになります。
2 つ目の問題は、更新メカニズムが必要以上に複雑である場合が多い点です。通常、ユーザーは更新ツールを実行する必要があることに気付かないので、完全に自動化されていない更新メカニズムはなかなか普及しません。また、多くの場合、更新プログラムをインストールするにはユーザーは管理者である必要があります。最悪のシナリオでは、単に更新プログラムが利用できるという通知を受けるにもユーザーが管理者でなければならないことがあります。
最後の問題は、ベンダがソフトウェアの更新テクノロジを使用して、ユーザーがインストールしていない、まったく無関係なソフトウェア (ツール バーなど) を展開することが一般的化していることです。ソフトウェアの更新テクノロジは、ソフトウェアの更新プログラムの展開という非常に明確な処理を目的としていたものから、追加のソフトウェアを配布する手段に変化してしまいました。
この問題の非常にわかりやすい例は、Microsoft® Windows Update サービス (図 1 参照) と、Apple Software Update (図 2 参照) です。どちらも、更新メカニズムを使用してソフトウェアを更新するだけでなく、ユーザーがインストールしていなかった新しいソフトウェアを配布しています。
図 1 Windows Update を使用した Silverlight の展開 (画像をクリックすると拡大表示されます)
図 2 Apple Software Update を使用した Safari の配布 (画像をクリックすると拡大表示されます)
Apple の例では、QuickTime だけをインストールしている場合でも、iTunes と Safari の両方をインストールできるという情報が提供されます。興味深いことに、これらのソフトウェアはすべて既定でインストールするように、チェック ボックスがオンになっています。
Windows Update の例では、更新サービスによって展開された最近の新しいソフトウェアは Silverlight™ です。マイクロソフトでは以前にもこの手法を使用して新しいソフトウェアを配布しています。マイクロソフトの名誉のために付け加えておきますが、少なくともマイクロソフトはチェック ボックスをオンにして既定で新しいソフトウェアがインストールされるようにはしていません。
このような更新メカニズムを通じて新しいソフトウェアを配布する方法は、ユーザーに 2 つの問題をもたらします。1 つ目の問題は、多くのユーザーが当初よりも多くのソフトウェアをコンピュータにインストールするようになることです。ご存じのとおり、実体のあるすべてのソフトウェアにはバグが付き物で、そのようなバグの中にはセキュリティの脆弱性の原因となるものがあります。このような脆弱性の中には、いずれなんらかの攻撃に使用されるものがあります。この結果、かなりの数のユーザーが、(ソフトウェアの更新メカニズムを通じてコンピュータに展開された) 不要で使ってもいないソフトウェアを介して攻撃を受けることになります。
もう 1 つの問題は、ユーザーがソフトウェアの更新メカニズムの価値を誤解するおそれがあることです。ソフトウェアの更新メカニズムが、新しい更新プログラムではなく新しいソフトウェアを展開するために使用されるものだと解釈すると、ユーザーは更新メカニズムが煩わしいと感じて使用しなくなる可能性があります。ソフトウェアの更新メカニズムによって配布された、まったく使用しないプログラムに由来する脆弱性を通じて攻撃を受けたユーザーがどう感じるか、想像してみてください。
テクノロジ エコシステムの正常性や安全にとって、ユーザーの安全を確保するテクノロジをユーザーが信用しなくなることよりも危険なことがいくつかあります。ユーザーの信頼を失うと、そのようなテクノロジは拒否されるようになり、最終的には使用されなくなります。更新テクノロジのように、コンピュータの保護に不可欠なテクノロジが信用されなくなれば、テクノロジ エコシステム全体が危険にさらされます。テクノロジ エコシステム全体を保護するために、マイクロソフトでは海賊版ソフトウェアを実行しているコンピュータにもセキュリティ更新プログラムを配布しています。
これに対して、Mozilla Firefox のシンプルな更新専用のインターフェイスには本当に尊敬の念を覚えます (図 3 参照)。これからも Mozilla が、ソフトウェアの更新ツールを通じて追加のソフトウェアを配布するという誘惑に屈しないことを心から願います。
図 3 業界内で最もシンプルなインターフェイスの 1 つである Firefox のソフトウェアの更新インターフェイス (画像をクリックすると拡大表示されます)

セキュリティに関する矛盾したメッセージ
ユーザーに対する共通のメッセージを業界で決定できれば良いと思います。業界内の競争は避けられませんが、ユーザーは自分にとって何が重要なセキュリティであるかを知る必要があります。残念ながら、IT 業界が矛盾したメッセージを発信し続ければ、ユーザーは何が重要であるか知ることができません。はっきり言って、私は自社のメッセージが一貫している企業であれば、多少の不満はありますが、評価に値すると考えています。
おそらく共通のメッセージが業界で決定されることはないでしょうが、少なくともメッセージには一貫性と誠実さが必要です。今後もユーザーからセキュリティ テクノロジの信頼を得られるようにすることは非常に重要なので、業界全体がメッセージの矛盾を改善する必要があります。
同様に、現在、何が実際の価値につながっているのか問う必要もあります。たとえば、私は IT 業界がユーザーに働きかけているほどウイルス対策ソフトウェアが効果的であったり、重要であったりするとは思っていません。私の 7 才になる息子が使用しているコンピュータと我が家の台所にあるコンピュータについて考えてみましょう。どちらのコンピュータにもウイルス対策ソフトウェアをインストールしていますが、インストールしてから 3 年間、いずれのコンピュータでも警告が表示されたことはありません。ウイルス対策ソフトウェアを放棄する必要があると述べるつもりはありません。現時点では、ウイルス対策ソフトウェアはテクノロジ エコシステムの主要なコンポーネントです。私たちが突然すべてのウイルス対策ソフトウェアを削除したとすれば、すぐに攻撃者がウイルス対策が行われていないことを悪用するので、ウイルスに感染するコンピュータが増えるのは間違いないでしょう。
ここで重要なのは、IT 業界はユーザーが本当に必要としているセキュリティ製品の機能とは何か、その機能はどれほど効果があるか、このようなユーザーにとってのニーズや価値について企業間で意見を交換する方法は何かを考える必要があるということです。現在、ユーザーが受け取っているセキュリティについてのメッセージには、あまりにも多くの矛盾を抱えていて、かつ誇張された情報が含まれており、中には不正確な情報が含まれていることもあります。

チェック ボックスこそすべて
たとえば、セキュリティ ソフトウェア業界はパッケージ製品が基本となっています。現在、セキュリティ ソフトウェアはほぼ例外なく、無関係に思われる機能の寄せ集めとして販売されています。しかも、そのような機能のうちどの機能をユーザーが実際に必要としているのかについての情報は、実質的にありません。
この結果、オンにするチェック ボックスの数を増やす競争が発生しているようです。チェックリストは製品の比較に役立ちますが、不要な機能や望ましくない機能だけでなく、意味が不明な機能までもが生み出される原因になります。図 4 ～ 7 は、4 社のセキュリティ ソフトウェア ベンダが公表している各社のチェック マークの一覧です。17 個のチェック マークがある製品が、10 個のチェック マークしかない製品よりも優れていると考えてよいものでしょうか。
実際のところ、私はこれらの図を非常におもしろいと思っています。図 4 では、最新バージョンであるという理由で製品にチェック マークが付いています。図 5 の製品は、ベンダの主張によれば "悪意のある Web サイトから PC への攻撃を防ぐ" という理由でチェック マークが付けられています。図 6 の製品は、"保護者機能" という理由でチェック マークが付けられています。言うまでもないことですが、子供を守れない製品を欲しいと思う人はいないでしょう。しかし、創意工夫大賞は、レジストリのクリーンアップやハード ディスクの最適化などの機能をセキュリティ製品に含めたベンダに贈りましょう。レジストリのクリーンアップ機能は必要かもしれませんが、めったに使用しませんし、ハード ディスクの最適化機能は OS に組み込まれています。事実、Windows OS には、図 7 に示されている 17 個のチェック マークのうち 15 個に対応するソリューションが既に組み込まれています。
図 4 このベンダの最上位製品にはチェック マークが 10 個しかありません (画像をクリックすると拡大表示されます)
図 5 11 個のチェック マークが付いたこの製品の方が優れていると考えるのが妥当でしょう (画像をクリックすると拡大表示されます)
図 6 ちょっと待った、この製品には 12 個のチェック マークが付いています (画像をクリックすると拡大表示されます)
図 7 しかし 17 個のチェック マークが付いているこの製品が最高のソリューションに違いないですよね (画像をクリックすると拡大表示されます)
このような一覧表には気になる傾向があります。これらの製品ではオペレーティング システムに組み込まれている機能が重複しているだけではなく (しかも、販売資料ではその事実の指摘を怠っています)、明らかに間違った主張が行われています。たとえば、あらゆる場所からの攻撃を完全に阻止できるセキュリティ ソフトウェアは存在し得なく、単に攻撃を防ぐのに役立つだけです。また、本当に攻撃者からユーザーの存在を隠せる製品も存在しません。
問題は、ソフトウェア セキュリティ産業の大部分が、他のベンダが開発した製品によって発生した脆弱性からユーザーを守ることに基づいて発展してきたことにあります。しかし、そのようなベンダによるユーザーの保護が改善されてきているため、セキュリティ ソフトウェア業界は、そのビジネス モデルが危機にさらされていることに気付き始めています。確かに新しいリスクが発生するとセキュリティ ソフトウェア業界の存在意義は高まりますが、ベンダは脅威ではなくなった脅威からユーザーを守るだけなく、ユーザーがリスクを管理できるようにする必要があります。

召集
この 3 回シリーズの記事から学んでいただきたいことを 1 つ挙げるとすれば、私たちは業界全体として、ユーザーや顧客に正直になる必要があるということです。私たちは、リスクについて説明し、ユーザーがこのようなリスクに対処する方法を説明し、ユーザーが自分で自分を保護する方法を身に付けられるように対応を始める必要があります。
このシリーズで取り上げたすべての "ソリューション" について私が最も心配しているのは、長い目で見ると確実にセキュリティの低下につながる深刻な可能性があることです。ユーザーだけでなく、IT 管理者までもが、このような製品によって本当のセキュリティ リスク (特にこのような製品が誤解を招きかねない表現で解決すると主張しているリスク) が解決されると実際に信じた場合、私たちは本当に自分で自分を保護する方法をユーザーに伝える機会を逃すことになります。
たとえば、パスワード認証システムについて考えてみましょう。このシリーズの第 1 部で説明した、パスワードによる認証システムに対する脆弱な拡張機能が、実際にユーザーを保護するとユーザーが信じれば、ユーザーのセキュリティがさらに甘くなり、さらに脆弱なパスワードを使用するようになるでしょう。このシリーズで取り上げた最悪の例では、新しいテクノロジを実装したことで、実装していなければユーザーが使用するはずであったセキュリティよりも脆弱なセキュリティをユーザーが使用するようになりました。つまり、悪意のあるユーザーが (多くの場合難しいことではありませんが) このようなシステムの攻略方法を考え出すころには、私たちはセキュリティに関して現在よりもさらに悪い状況に陥っているでしょう。この結果、重大な信用問題が発生し、ユーザーが本当に価値のあるソリューションを放棄する可能性もあります。
今こそ、私たちの事業を支えるテクノロジ エコシステムを保護するために行動する必要があります。もちろん革新は必要ですが、革新のための革新によって、実際のリスク分析が妨げられないよう細心の注意を払う必要もあります。注意を払わなければ、単なるセキュリティ ショーを演じるだけになり、最終的にはセキュリティ ショーによって自分たちの首を絞めることになります。
このシリーズで説明した他の例についても同じことが当てはまります。たとえば、見掛けだけの無意味な安全性のごまかしについて考えてみましょう。これはユーザーにとってのメリットがまったくなく、ユーザーにセキュリティの価値に関する誤った認識を与え、オンライン サービスのプロバイダが、ユーザーに間接的な被害を及ぼすような機能の強化でやり過ごすことを可能にしています。一方、ユーザーに正しい情報を伝えるには、総額で数千ドル、特に極端な場合でもおそらく数万ドルしかかかりません。これほどわずかな予算を割いて、ベンダに顧客と事業を保護するよう要請することは、本当に無理なことでしょうか。
この要求には多くの効果があります。まず、ユーザーは判断を下すことができず、ユーザーに判断させないようにするべきだという認識に対処する必要があります。ユーザーが判断を下せるように指導することは不可能ではありません。というのも、このようなユーザーは、コンピュータの購入、サイトの使用、いずれかの製品やサービスの購入など、多くの判断を下しているからです。自動車を安全に運転する方法を学ぶ必要があるのと同様に、コンピュータを安全に使用する方法も学ぶ必要があります。現在、ユーザー個人が攻撃対象となっているので、テクノロジを当てにして判断を下すことはできません。むしろ、セキュリティ技術はユーザーが賢明な判断を下せるように、正しい情報を適切なタイミングで提供する意思決定支援システムになる必要があります。
世界中で最も使いづらいユーザー インターフェイスの一部は、セキュリティ ソリューションのユーザー インターフェイスです。なぜならセキュリティ ソリューションでは、あらゆる種類の意思決定をユーザーから見えないところで行ったり、利用できるデータ全部を (わかりにくい方法で) ユーザーに表示したりしているためです。いずれの方法も効果はありません。1 つ目の方法では、正しい選択を行うためにテクノロジを当てにできないので、ユーザーが危険にさらされます。さらに、テクノロジによってユーザーのビジネス目的が妨害されているとユーザーが認識すれば、そのテクノロジが使用されなくなるのは時間の問題です。また、2 つ目の方法はうまく行きません。というのも、ユーザーが IP アドレス、プロセス ID、およびユーザーにとって無意味なその他のデータにわずらわされたくないと考えるからです。ユーザーが関心を持っているのは、自分のパスワードとクレジット カードがコンピュータでどのように扱われているかということだけです。結局、これがユーザーにとってのセキュリティというものなのです。

Jesper M. Johansson は、セキュリティ ソフトウェアの開発に取り組むソフトウェア アーキテクトで、TechNet Magazine の編集にも携わっています。管理情報システムの博士号を持ち、セキュリティ分野で 20 年以上の経験があります。また、エンタープライズ セキュリティの MVP でもあります。最新の著書には、『Windows Server 2008 Security Resource Kit』があります。


フィールド ノート 内部改革
Romi Mahajan

経営の専門家、および事業戦略家として名高い Gary Hamel 氏は、同氏の著書『経営の未来』で、長期にわたって比較優位を生み出すのは改革を推進する文化であり、その文化自体、経営管理手法が進化した成果であると論じています。産業は、さまざまな方向に向かって数え切れないほど自ら改革され、生まれ変わってきましたが、ほとんどの企業はピラミッド式の経営文化に染まったままです。このため、従業員の創造性と資本に見合った利益が得られないというだけの理由で、本当に改革を推進する文化の出現が妨げられています。
このような階層は改革の天敵であり、従業員の創造性が解放されれば、長期にわたって革新的な比較優位の中心的原動力になります。従業員の創造性が制約を受けると、従業員の 80% 以上が自分の仕事に熱中しなくなります。Hamel 氏は、これは事業の失敗だけではなくモラルの低下にもつながると考えています。
非常に基本的なレベルでは、この書籍は産業界に対して過剰な階層構造を追放するよう強く呼びかけています。本質的なレベルでは、この主張は根本から官僚主義を批判しています。意思決定権は無関心なマネージャや金持ちの役員の手にゆだねておくべきではありません。
Hamel 氏は、IT ではなく経営こそ改革の原動力だと主張しています。そもそも IT は商品化できるものですから、どうすれば比較優位を生み出すことができるのでしょうか。IT が改革の原動力ではなく、生産性の向上、稼働時間、信頼性、新しいアプリケーションの迅速なインストール、およびシングル サインオン (および類似テクノロジ) から比較優位が生まれないとしたら、私たちは一体何についてこれほどいつも苦労しているのでしょうか。
所属する IT 組織や企業全体の本質をよく検討して、ひょっとしたら Hamel 氏の主張にも一理あるかどうか確かめるつもりはありますか。どうすれば IT が商品と見なされないようにできるでしょうか。
Hamel 氏の概念の長所を取り入れ、この概念を利用して将来 IT 組織が改革の中心的存在になるようにする過程で、私は "内部改革" という理論を考案しました。従業員の創造性と資本を最大限に活用することは、比較優位を維持する鍵であり、大きな組織はそれぞれの役割に固有の改革を行う必要があります。組織が採用する必要があるのは、官僚機構ではなくコミュニティです。そして、最も重要なのは、経営が真の改革を妨げていることがあまりにも多い点です。真の改革には、経営の関与が不可欠です。
IT 組織について考えてみましょう。IT スタッフは知性があり、熱心で、周囲に影響を与えたがる傾向があります。より少ないリソースでより多くの仕事をこなすよう要求されることが多いので、IT スタッフ基本的作業を行うばかりで改革に費やせる時間がほとんどありません。
私の内部改革の理念は、Hamel 氏の意見を IT 分野に応用しています。基本原則は次のとおりです。
  • IT スタッフが本来備えている創造性を考慮すると、この能力を活用する IT 管理モデルを確保するのが最も有益です。
  • 革新は、発想、試行、エラー、修正という系統的でありきたりの手法から生まれますが、これは IT に固有の手法です。
  • コミュニティが隅々まで公然と受け入れられると、技術的な解決策が明らかになります。ここでも、IT は主導的役割を果たし、自ら行動を起こすことができます。
  • IT では、人材こそ比較優位の唯一の原動力です。
  • IT 管理はプロジェクトと予算中心の考え方から、改革的な経営中心の新しくて刺激的な考え方に進化する必要があります。
  • IT はコスト削減ではなく、大きな成果の創造を目標にする必要があります。
この理念に賛成する心構えはできていますか。内部改革の概念を実行して、IT 組織がこの大規模な実験を行うのに最適だと示すことができるでしょうか。マネージャは権力を捨て、自身のコミュニティを受け入れる心構えができているでしょうか。経営者は権力をあきらめ、私たちの才能全体を受け入れる心構えができているでしょうか。

Romi Mahajan は Ascentium Corporation のマーケティング最高責任者です。Ascentium に加わる前は、マイクロソフトに 7 年以上勤務し、最後はテクニカル オーディエンスおよびプラットフォーム マーケティングを率いるディレクタを務めていました。テクノロジ、政治、経済学、社会学など幅広い分野で自身の考えを発表しています。


Windows 秘話 電源が入っていない Windows 95
Raymond Chen

Windows® 95 向けの 32 ビット プログラムには一般的な 32 ビット コンパイラを使用することができ、16 ビット プログラムには一般的な 16 ビット コンパイラを使用できますが、Windows 95 自体には、32 ビットと 16 ビット両方の環境を理解して、そのギャップを埋めることができる特殊なコンパイラが必要でした。Windows 95 には、それら 2 種類のコードの結び付ける方法を理解するカスタム リンカと、VxD (Windows 95 のドライバ形式) 用のカスタム リンカも必要でした。
Windows 95 チームは、こうした特殊な目的を持ったコンパイラとリンカを用意することを、言語部門とツール部門に依頼しました。言語部門は、変わった要求だと思ったことでしょう。「X、Y、Z の 3 つのことを行うコンパイラを作成するつもりで、その役割はたった 2 つの DLL をコンパイルするだけだって」。そのとおりなのです。しかし、実は、この 2 つの DLL が非常に重要でした。
明らかに途方もない要求なのにもかかわらず、言語部門とツール部門が期待に応えてくれたことで、この非常に特殊なコンパイラとリンカが Windows 95 ビルド プロセスの一部になりました。もちろん、コンパイラは最初から完全な形ではありませんでした。Windows チームはまず暫定版を受け取り、その後、新たな最適化が実装され、バグが修正されていく過程で定期的に更新版を受け取りました。
ある日、Windows 95 のビルド速度が突然落ちました。数秒でリンクされていたファイルが、突然リンクに数分かかるようになったのです。依然としてファイルは正常に生成されていましたが、大変時間がかかりました。この現象は、ある開発者のコンピュータ上だけで起こっていたわけではありません。チーム全体のあらゆる開発者がこの問題に直面しました。リンカの一部に異常があり、コードが突然この異常に遭遇してしまったのでしょうか。リンカのバグを偶然発見したのでしょうか。
いくつかデバッグを行った後で、問題の原因がわかりました。最新バージョンのリンカにはいくつか診断コードが含まれていて、言語部門の担当者は最新のリンカを Windows チームに引き渡す前にこうした診断コードを削除し忘れていたのです。この診断コードは、コンパイラ チームのメンバのオフィスにあるコンピュータに格納されていたファイルに記録をログ出力するものでした。そして、そのコンピュータの電源がたまたまオフになっていたのです (これは、Leslie Lamport の発言を思い起こさせます。Leslie Lamport が分散システムを評して「聞いたこともないコンピュータが停止しただけで何もできなくなってしまうシステム」と表現したのは有名な話です)。
そのバージョンのリンカは、数週間は順調に実行されていました。Windows 95 をビルドする際だれかが VxD をリンクしようと試みるたびに、その開発者のコンピュータにあるファイルが更新されていました。そのコンピュータの電源が入っていてネットワークに接続されている限り、だれも気付きませんでした。しかしある日そのコンピュータの電源が切られたため、すべての処理の速度が落ちたのです。
問題さえわかってしまえば、コンパイラの担当者がリンカから診断コードを削除した修正プログラムを Windows チームに提供するまでそう長くはかかりませんでした。
このジョークの落ちは、だれが話すかによってさまざまです。私がこの話をすると、「そのコンパイラの開発者は、後に Windows チームに移籍し、私の上司になったんだ」という落ちになります。上司をちょっとからかいたいときは、この話を何度も持ち出して楽しんでいます。
しかし、私の上司がこの話をすると、ジョークの落ちはまったく違ったものになります。「後からわかったことだけど、その診断コードを作成したのは私ではなっかったんだ。作成したのは私の同僚の 1 人で、自分のコンピュータが診断情報であふれかえるのが嫌で、私のコンピュータをこっそり使ったんだよ。」

Raymond Chen は自分の Web サイト「The Old New Thing」および同じタイトルの書籍で、Windows の歴史と Win32 プログラミングについて扱っています。彼の DNA は無意味なコードで満たされています。