 TechNet Magazine January 2007
TechNet Magazine January 2007
JANUARY 2007
SharePoint

今月の TechNet Magazine は、SharePoint とその最新リリースの新機能に論点を絞っています。ここでは、SharePoint Server 2007 を紹介し、これまでよりも高度なコラボレーション サイトをより簡単に構築できる新機能について説明します。概要では、全社規模の検索とドキュメント管理などを扱います。 SharePoint のセキュリティ、高速なコマンドライン管理タスク、および SharePoint を使用した組織の Wiki の構築に関する記事も取り上げます。そしていつものように、Raymond Chen の「DLL Hell からの脱却」、.NET Framework の DataList.Sort メソッドを使用した VBScript でのソートに関する「The Scripting Guys」など、人気のあるコラムのまとめもあります。

特集
SharePoint Microsoft Office SharePoint Server 2007 の概要

SharePoint の新バージョンは、1 つの統合プラットフォーム上で、コラボレーションと情報管理に関する顧客ニーズを満たすものです。この記事では、企業の作業スタイルを変えるであろう、MOSS の新機能とツールについて説明します。

Thomas Rizzo SharePoint のセキュリティを強化する 7 つの新機能

SharePoint で利用される企業データが増え、ビジネス ワークフローに不可欠になっていくにつれ、セキュリティがますます重要になります。ここでは、MOSS の 7 つの新機能によって組織のセキュリティがどのように向上するかについて説明します。

Adam Robert Buenz SharePoint Enterprise Search ですべてを見つけ出す

従業員が情報を見つけ出す間にも、時間とコストは失われていきます。エンタープライズ検索で、解決しましょう。MOSS では情報を迅速に検索できるエンタープライズ検索ツールを提供しています。その情報がイントラネット サイトや稼動中の基幹業務アプリケーション内に格納されていても、あるいは従業員 1 人の記憶の中にしか存在しない情報であっても即座に検索します。

Matt Hester SharePoint の優れたコマンド ライン管理

GUI だけで解決しようとしないでください。SharePoint を管理するための有用で簡単な方法は数多くあります。コマンド プロンプトだけでなくスクリプト共通プロシージャを使用しても、管理タスクを実行できます。

Todd Klindt 作業上での Wiki の使用

Wiki は、柔軟性の高い、新しいコラボレーション手段を提供し、形にとらわれない方法による考察や意見交換を促します。MOSS 2007 を使用すると、Wiki を組織に非常に簡単に実装できます。ここでは、ワークスペースで Wiki の構築と使用を開始するために必要な知識について説明します。

Mauro Cardarelli
コラム
編集者から

Joshua Trupin ツールボックス

IT プロのための新製品

Greg Steen ユーティリティ スポットライト

Internet Explorer 管理者キット

Lance Whitney SQL に関する Q&A

データ アーカイブ、リンク サーバー、帯域幅の測定など

Nancy Michell The Cable Guy

TCP 受信ウィンドウ自動チューニング

Joseph Davies Windows PowerShell

Windows PowerShell のコンストラクト

Don Jones 		Hey, Scripting Guy!

発言には注意しましょう

Microsoft Scripting Guys Exchange Queue & A

すべての質問にお答えします (質問を作った本人ですから)

KC Lemson、Paul Bowden セキュリティ ウォッチ

Windows Vista の Services Hardening

Wole Moses デスクトップ ファイル

Windows 自動インストール キット

Wes Miller フィールド ノート

義母のテクニカル サポート

James Snell Windows 秘話

DLL Hell からの脱却

Raymond Chen


 SharePoint: Microsoft Office SharePoint Server 2007 の概要
SharePoint Thomas Rizzo

Microsoft Office SharePoint Server 2007 の概要
概要:
  • SharePoint の Web 統合
  • コンテンツ管理
  • ビジネス インテリジェンス

ある 2 つの現象によって、企業での作業スタイルが変わりつつあります。マイクロソフトではこの新しい作業スタイルを "new world of work" と呼んでいます。
第 1 に、"共同作業を行うチームのメンバが、異なる場所で、また異なる時間に働いている" というケースが増えています。このようにばらばらに働いているメンバどうしを結び付けるために、コラボレーション ソフトウェアの重要性が高まっています。第 2 に、デジタル情報の利用が急拡大すると共に、ビジネス データに対する遵守規則がこれまでになく複雑化しています。各企業は、コラボレーションと共有の実現、および、情報セキュリティとプライバシーの確保に取り組んでいます。これらすべての要件 (働く時間や場所が異なる相手とコミュニケーションをとること、効果的なコラボレーション ツールを利用すること、データを扱う際のセキュリティを確保すること) を満たすソリューションが、情報と人材を最大限に活用するうえで不可欠です。
Microsoft® Office SharePoint® Server (MOSS) 2007 は、多様な技術を 1 つの統合プラットフォームと企業向けサービス群にまとめたものです。これらの技術は、コラボレーション、ポータル、エンタープライズ検索、ワークフロー、ビジネス プロセスなど多岐にわたります。MOSS は、Windows® SharePoint Services (WSS) をベースにした、SharePoint Portal Server (SPS) の次世代製品です。MOSS と WSS の連係動作については、図 1 の円グラフを参照してください。緑の部分は、WSS によって提供される機能を表します。MOSS は WSS をベースにしており、円グラフ全体は MOSS によって提供される機能を表します。MOSS が備えている機能には、ポータル、検索、エンタープライズ コンテンツ管理、ビジネス プロセス、ビジネス フォーム、ビジネス インテリジェンス (BI) などがあります。
図 1 MOSS および WSS によって提供されるサービス
図 1 MOSS および WSS によって提供されるサービス (画像を縮小するには、ここをクリックします)
図 1 MOSS および WSS によって提供されるサービス
図 1 MOSS および WSS によって提供されるサービス (画像を拡大するには、ここをクリックします)
ここからは、MOSS の技術面の特長、および、これらの技術を利用してユーザーの生産性を向上させる方法について説明します。

SharePoint と Web 2.0
Web 2.0、Enterprise 2.0、複合アプリケーション、コミュニティ主導型コンテンツなどさまざまな名前で呼ばれているインターネット技術 (Ajax、RSS、ブログ、Wiki) を利用すると、コンテンツ、コラボレーション、およびデータ フローをより効率的に制御できます。また、これらの技術では、Windows の双方向性、および、Web の特長である配備しやすさと使いやすさが必要です。ただし、インターネットの概念を企業環境に持ち込むと、別の問題が発生します。たとえば、サービス提供元を検証して信頼できるか、そのサービスを自社の現行の基盤にスムースに組み込むことができるか、などの問題です。
MOSS 2007 では、多くの新機能が提供されていると共に、既存のコラボレーション プラットフォームが強化されています。具体的には、ドキュメント管理機能や警告機能が組み込まれているほか、ブログ (図 2 を参照)、Wiki、RSS フィード公開/受信を行う Web パーツなどの機能が追加されています。Microsoft Office Outlook® 2007 を使用している場合、Outlook と SharePoint との間で、コラボレーション データ (予定表、仕事、連絡先など) の双方向同期を実行できます。たとえば、連絡先を変更したい場合や予定を移動したい場合は、Outlook と SharePoint のいずれか一方で変更作業を行えば、その変更内容がもう一方に反映されます。
図 2 ブログと Wiki をサポートする MOSS 2007
図 2 ブログと Wiki をサポートする MOSS 2007 (画像を縮小するには、ここをクリックします)
図 2 ブログと Wiki をサポートする MOSS 2007
図 2 ブログと Wiki をサポートする MOSS 2007 (画像を拡大するには、ここをクリックします)
また、Outlook は、オフラインでのドキュメント ライブラリの取得をサポートします。ネットワークに接続していない状態でドキュメントに変更を加え、次にオンラインになったときに変更点を同期できます。
さらに、MOSS にはコミュニティー主導型コンテンツを監査し遵守すべき規則を強制する機能が実装されています。それによりこれらの新しい機能を提供するために、ユーザーが管理体系またはセキュリティを犠牲にする必要はありません。
MOSS 2007 の主要な新機能の 1 つとして、ポータル エクスペリエンスの個人用設定が拡張されています。MOSS には SharePoint サイトの機能を十分に利用できるように機能強化された My Site が導入されています。ユーザーは、リスト、ドキュメント ライブラリ、またはサブサイトを My Site に作成でき、個人用ビューとワークグループ ビューの両方でサイトの表示をカスタマイズできます。また、My Site は、組織階層および同僚の情報追跡に関する新しい Web パーツを提供します。たとえば、電話番号、肩書き、オフィス所在地、その他の情報など同僚に関するメタデータが変更された場合に警告できます。図 3 は、MOSS のカスタマイズされた My Site を示しています。
図 3 より SharePoint を中心に据えた機能をサポートする My Site
図 3 より SharePoint を中心に据えた機能をサポートする My Site (画像を縮小するには、ここをクリックします)
図 3 より SharePoint を中心に据えた機能をサポートする My Site
図 3 より SharePoint を中心に据えた機能をサポートする My Site (画像を拡大するには、ここをクリックします)

エンタープライズ検索
ハード ドライブの容量が小さかったときは、どこにデータが保存されているかを覚えておくことはあまり問題になりませんでした。しかし、記憶領域が爆発的に大きくなり、ユーザーはいわば無制限にデータを記録できるようになりました。これにより検索があらゆる情報アーキテクチャにおいて重要な要素になりました。MOSS では、最初に SPS 2003 で提供された検索プラットフォームを基に構築された、企業リポジトリ検索機能が向上しています。MOSS 2007 は引き続き、ファイル共有、Web サイト、Exchange Server、Lotus Notes リポジトリなどの、構造化されていないと思われるデータ リポジトリをすべてクロールします。
SPS では、基幹業務アプリケーションまたはリレーショナル データベースなど構造化されたリポジトリの検索を行うのは容易ではありませんでした。加えて、構造化されたリポジトリまたは構造化されていないリポジトリはメタデータにより補完されており、使いこなすためには従業員各自に専門知識が必要でした。MOSS では、ビジネス データ カタログ (BDC) と呼ばれる新しい技術により、新しい Knowledge Network を介して特定の知識や経験を持った人員を検索できるようになりました。
BDC を使用して、ADO.NET プロバイダ経由または Web サービス経由でデータを公開するシステムに対して、接続、クロール、および検索を行うことができます。接続するシステムに関する必要な情報を含む XML 設定ファイルを作成します。これには、サーバーまたはエンドポイントの名称、システムからオブジェクトを列挙し取得する方法、バックエンド システムがサポートするフィルタリング、バックエンド データが SharePoint データにマップされる方法などを含めることができます。次に、SharePoint のエンタープライズ検索機能を使用して、他のエンタープライズ リポジトリをクロールするのと同様に BDC データを検索できます。
既定では、SharePoint はバックエンド システムから各ビジネス エンティティに対してプロファイル ページを作成します。これらのプロファイル ページは SharePoint の他のページと同様にカスタマイズできます。図 4 は、ビジネス データと他の情報の両方を返す、カスタマイズされたプロファイル ページを示しています。また、SharePoint には多数のビジネス データ Web パーツがあります。これにより、ユーザーのページに BDC データを表示できます。必要に応じて、それらのページ上のデータに、利用可能なメタデータに基づいてフィルタをかけることもできます。ビジネス データが SharePoint にマップされたので、新しいビジネス データの列タイプを使用して SharePoint リスト内のデータにアクセスできます。今後は、データ入力エラーおよびデータの最適化作業は発生しません。なぜなら、リストに保持されているデータは信頼できるバックエンド システムから提供されるからです。
図 4 バックエンド サービスから SharePoint ページへのビジネス データの取り出し
図 4 バックエンド サービスから SharePoint ページへのビジネス データの取り出し (画像を縮小するには、ここをクリックします)
図 4 バックエンド サービスから SharePoint ページへのビジネス データの取り出し
図 4 バックエンド サービスから SharePoint ページへのビジネス データの取り出し (画像を拡大するには、ここをクリックします)
Knowledge Network では、高度な機能を使用して、特定の知識や経験を持った人員を検索できます。企業内のソーシャル ネットワークにより業務は遂行されます。多くの場合、遂行している業務で直面する問題を解決できる専門家を見つけることができれば従業員の生産性はより向上します。しかし、直接面識のある同僚の中に必要としている知識を持っている同僚がいない場合、おそらくその問題に対する専門家を探すことをやめてしまうでしょう。Knowledge Network は、物理的なソーシャル ネットワークではなく、ソフトウェアが、ユーザーの組織におけるソーシャル マップの構築を支援し、構築されたソーシャル ネットワークの検索を可能にします。結果は、社会的距離で分類したり、肩書きや部署などのメタデータ プロパティでフィルタ処理したりできます。
個人情報を扱う他のソリューションと同様に、Knowledge Network は優れたセキュリティおよびプライバシー モデルを提供します。それによって、ネットワークに参加するかどうかを選択でき、ネットワーク内のどの関係者に何を表示するかを制限できます。Knowledge Network は、ユーザーの SharePoint My Site などサーバー側の情報をクロールします。Knowledge Network にはクライアント側のコンポーネントもあります。それは Outlook とインスタント メッセンジャーに組み込まれ電子メールと連絡先をクロールします。クライアント側では、スケジュールされたクロールが行われる日時、およびクライアントのクロールによりサーバー プロファイルに公開される情報を制御できます。このシステムの課題の 1 つは、人に関するデータを最新の状態に保つことです。Knowledge Network では、ソフトウェアによって情報の更新がすべて保持されると共に、ユーザーが情報の可視性とアクセシビリティを制限できます。

エンタープライズ コンテンツ管理
単なるドキュメント管理からさらに進化した MOSS 2007 は、レコード、Web コンテンツ、電子フォームの管理に対するサポートを追加することにより、堅牢なエンタープライズ コンテンツ管理ソリューションを提供します。SharePoint のレコード管理機能では、コンテンツの保持、監査、バーコード化、ラベル作成などの遵守すべきニーズを満たす、管理されたリポジトリを構築できます。Exchange Server との統合が強化されたことにより、レコード リポジトリは、SharePoint 内に作成および保管された情報に加えて、電子メール メッセージを公式な記録として保持できます。保存ポリシーで指定されている期間よりも長く保存する必要があるという法的要件がある場合は、レコード管理機能で、レコードおよび法的な記録を検索する法的検索を行うことにより、保存ポリシーを解除できます。
Web コンテンツ管理の領域では、MOSS 2007 は Microsoft Content Management Server 2002 に取って代わるものとなります。この変更により、SharePoint はイントラネットからエクストラネットおよびインターネット対応サイトまで、ユーザーの Web ニーズに対応できます。SharePoint にこれらの機能すべてを組み込むことにより、インフラストラクチャ全体で 1 つのテクノロジをサポートするだけで済みます。SharePoint は、テスト サーバーと展開サーバーを別にしたコンテンツの展開をサポートします。また、SharePoint では、ASP.NET 2.0 Master Pages がサポートされているので、サイトのカスタマイズをより容易に行うことができます。加えて、多言語対応については、SharePoint はサイト バリエーションをサポートします。1 つのサイトに複数のバリエーションを使用でき、ページを表示しているクライアントのブラウザの言語設定に基づいて自動的に対応する言語ページにリダイレクトできます。
電子フォームについては、SharePoint は InfoPath® Forms Services と呼ばれる新しい機能を追加します。これにより InfoPath フォームを電子フォームに変換できます。InfoPath フォームの作成プロセスでは、デザイナ内のボックスがチェックされます。Web に変換されない機能を使用しようとすると警告が発生し、フォームを SharePoint リスト内の信頼できる場所に保存するように促されます。次に、ユーザーは Web ブラウザだけを使用して、フォームの表示、編集、送信を実行できます。
SPS 2003 のユーザーから要望のあった重要な機能の 1 つは、ワークフロー機能を強化することでした。多くのユーザーは SharePoint に保存したコンテンツにワークフローを組み込むことを希望していました。MOSS は単なるワークフローの強化以上の、.NET Framework 3.0 の新しい Windows Workflow Foundation 機能を追加します。これにより Windows Workflow Foundation にワークフローを構築でき、これらのワークフロー機能を SharePoint 内に埋め込むことができます。Windows Workflow Foundation のホスティングに加えて、SharePoint には、ドキュメント承認ワークフローおよびドキュメント検証ワークフローを含む多くのワークフローも既定で含まれています。図 5 は、MOSS の既定のワークフローを設定する方法を示しています。
図 5 MOSS でのワークフローの設定
図 5 MOSS でのワークフローの設定 (画像を縮小するには、ここをクリックします)
図 5 MOSS でのワークフローの設定
図 5 MOSS でのワークフローの設定 (画像を拡大するには、ここをクリックします)
MOSS ではワークフローを監視でき、現在のタスクのステータスや履歴を表示できます。さらに、SharePoint は Office クライアントと統合されたので、エンド ユーザーは Office アプリケーションからワークフローを開始できます。加えて、エンド ユーザーは、ワークフロー タスクが割り当てられるとそれをすぐに知ることができます。また、Office アプリケーションを終了することなくそれらのタスクを完了できます。
また、MOSS は、ビジネス インテリジェンス ポータルとしての役割がさらに向上しています。これらのポータルには通常、並べ替えやフィルタ処理が可能なレポート、チャート、データのテーブルが含まれ、グラフィックスによってデータのステータスを視覚的に表すことができるという特徴があります。MOSS では、ビジネス インテリジェンス ポータルは、単にビジネス インテリジェンス (BI) ダッシュボード テンプレートを使用して新しいページを作成するだけで構築できます。BI ダッシュボードには、既定で主要業績評価指数 (KPI) リストと Excel® Web Access Web パーツが含まれています。
KPI リストは MOSS での新しいリスト タイプで、これを使用して Excel、SQL Server™ Analysis サービス、SharePoint リスト、手動で入力した情報などの情報ソースに接続できます。またこれらのデータ ソースから KPI を追跡することが可能です。KPI リストにより、視覚的な指標を使用して、現在の値、ターゲットの値、傾向、ステータスを表示できます。
Excel Web Access は、MOSS での Excel サービスの一部で、Excel のサーバー側バージョンです。これによって、Web ブラウザを介して Excel の情報を計算して表示できます。Excel サービスを使用して、スプレッドシートをデスクトップ上の Excel アプリケーションから直接 SharePoint 内の信頼できる場所に公開できます。するとユーザーは、Web ブラウザから Excel のスプレッドシートまたはチャートを表示できます。次に、パラメータまたはフィルタリングがある場合、ユーザーはこれらの機能を使用して Excel 情報の Web ブラウザでの表示を修正できます。

詳細について
ここでは、MOSS の新しい機能のほんの一部を取り上げることしかできませんでした。詳細については、オンライン リソースを参照してください。SharePoint Team Blog (英語) および SharePoint Server TechCenter (英語) から始めることをお勧めします。

Thomas Rizzoマイクロソフトの SharePoint グループのディレクターです。Thomas は以前、SQL Server グループおよび Exchange Server グループで働いていました。また、本を 4 冊執筆しています。彼の連絡先は、thomriz@microsoft.com (英語) です。
© 2007 Microsoft Corporation and CMP Media, LLC. All rights reserved; 許可なしに一部または全体を複製することは禁止されています.


 SharePoint: SharePoint のセキュリティを強化する 7 つの新機能
SharePoint Adam Robert Buenz

SharePoint のセキュリティを強化する 7 つの新機能
概要:
  • 認証プロバイダ
  • ネイティブ暗号化機能
  • 代替アクセス マッピングとゾーン
  • Information Rights Management

Microsoft Office SharePoint Server (MOSS) 2007 環境に効果的なセキュリティ対策を実装すると、管理オーバーヘッドが大幅に削減され、チームは
安全な環境でコラボレーションを行い、ビジネス データを共有できるようになります。MOSS 2007 に組み込まれている革新的な認証機能を使用すると、カスタム認証プロバイダ、インターネット スタイルのフォーム ベースの認証、および Web シングル サインオン (SSO) を活用して Web ベースのセキュリティ規格を導入できます。また、MOSS は、2007 Microsoft® Office システム ファイルなどのビジネス資産に対するきめ細かい権限管理とネイティブ暗号化機能を提供し、クライアント認証にかかわる遵守の負担を軽減します。
すばやく導入できる MOSS 2007 の 7 つのセキュリティ機能は次のとおりです。
1. プラグ可能な認証プロバイダ MOSS 環境で使用する認証プロバイダを構成することは、インターネット スタイルの SharePoint® 認証をセットアップする際に、セキュリティ上重要なことです。MOSS は、ユーザーの Windows ID を正しく解決するための統合認証や基本認証 (ダイジェスト認証も追加) など、SharePoint の以前のバージョンで使用できる Windows® ベースの認証方式を、引き続きサポートしています。ただし、Windows ID への解決は唯一のオプションではなくなりました。複数の認証プロバイダを導入して、たとえば、内部ユーザーのログインには Windows 認証を使用し、外部ユーザーのログインには別個のプラグ可能なプロバイダを使用する構成が可能です。
MOSS は ASP.NET 2.0 上に構築されるので、プラグ可能な認証プロバイダを使用できます。これにより、メンバ データ ストアと対応する ASP.NET 2.0 メンバシップ プロバイダ (およびオプションのロール プロバイダ) が存在する限り、構成可能なディレクトリを使用してユーザー情報を格納できます。プラグ可能なプロバイダ資格情報は、メンバシップ プロバイダに対応する machine.config ファイルに格納されたノード値に応じて、ハッシュされるか、暗号化されるか、テキスト形式で格納されます。メンバシップ プロバイダの中には MOSS で使用できるものがあります。たとえば、LDAP V3 メンバシップ プロバイダ (MOSS に付属) や、ASP.NET 2.0 に付属の SQL Server™ メンバシップ プロバイダおよび Active Directory® メンバシップ プロバイダがあります。
実装可能なメンバシップ プロバイダとロール プロバイダは、付属のプロバイダだけではありません。ASP.NET 2.0 メンバシップ アーキテクチャを使用することで、カスタム プロバイダを作成して、Microsoft Access™ データベースや Oracle データベースなどのメンバシップ ストア、XML ファイル、または暗号化されていないテキスト ファイルを使用することもできます。カスタム認証プロバイダは ASP.NET MembershipProvider インターフェイスを継承しています。このインターフェイスは ProviderBase クラスを継承しています (図 1 を参照)。
図 1 .NET メンバシップ クラスの階層構造
図 1 .NET メンバシップ クラスの階層構造
Windows 認証ではなく ASP.NET 2.0 認証を MOSS で使用する場合に、注意すべき点がいくつかあります。多くのユーザーにとって最大の影響は、Microsoft Office クライアントの相互運用性が低下することです。これは、MOSS と Office クライアントとの間の Web サービス通信が元来 Windows ID を想定して設計されていることに起因しています。
また、コンテンツのクロールやインデックスなどの MOSS サービスでは、プラグ可能なプロバイダを使用している最中でも Windows アカウントを使用する必要があります。Windows ID に解決しない認証を使用してクロールやインデックスなどのサービスを実行するには、Windows 認証を使用する追加 MOSS ゾーンを作成することが必要です (ゾーンについては、この記事で後述)。
スマート カードなどのセキュリティ メカニズムに基づく委任 PKI インフラストラクチャがあり、公開キーや資格情報がクライアントによって保持されている場合、一般的には、Windows ID を解決して、実装に応じて適切なクライアント証明書の承認および認証を受ける必要があります。このために、追加 MOSS ゾーンを作成したり、他の認証構成を作成したりする必要が生じることがあります。
2. フォーム ベースの認証と Web シングル サインオン MOSS 2007 で使用できるもう 1 つの認証メカニズムが、ASP.NET 2.0 に基づくフォーム ベースの認証です。SharePoint の以前のバージョンでこれを実現するには、カスタム Internet Server Application Programming Interface (ISAPI) 拡張機能を使用するか、IIS 6.0 のツールキットから CustomAuth ISAPI 拡張機能を導入するしかありませんでした。また、この方法を採用したとしても、SharePoint には Windows ユーザー ID に解決し直すためのアカウントが必要となり、境界ベースの展開が制限を受けます。
フォーム ベースの MOSS 認証では、プラグ可能な認証およびロール プロバイダを活用して、インターネット スタイルのセキュリティ メカニズムを実現するので、旧式の NT ログイン プロンプトを使用する必要がなくなります。その代わりに、ユーザーのニーズに合わせてカスタム ログイン プロセスを構築できます。認証プロセスの保護を強化するには、フォーム認証の Cookie や認証チケットを暗号化して、改ざんを防ぎます。
フォーム ID プロバイダは、ローカルに常駐している必要はなく、外部 ID 管理システムへのプラグインが可能で、その場合は外部 ID 管理システムがユーザー資格情報の検証を行います。この機能は Web シングル サインオンとして知られており、外部認証には HTTP モジュールを使用します。このシナリオでは、組織とビジネス パートナーとの間で ID を統合して、MOSS 実装に対する認証に各組織独自のログインを使用できます。
3. MOSS アプリケーション接続文字列の暗号化 重要な接続文字列情報を web.config ファイルにテキスト形式で保管するというのは、セキュリティ上あまり良い方法ではありません。情報が漏れると、ユーザーが SQL データベース サーバーを対象とするオブジェクト インスタンスを作成し、重要データを操作することが可能になります。一方、ASP.NET 2.0 に備わっている機能を使用すると、Windows Data Protection API (DPAPI) または RSA 暗号化のどちらかのテクノロジを使用してデータを暗号化できます。DPAPI は、Windows に組み込まれている暗号化機能を利用して、MOSS サーバー マシン キーの暗号化や復号化を行います。RSA 暗号化を使用すると公開キー アルゴリズムを使用できますが、暗号化キーに適したコンテナという追加オーバーヘッドが発生します。
MOSS 2007 の場合、具体的にはプラグ可能な ASP.NET 2.0 SQL Server 認証プロバイダの場合、<connectionStrings> ノードがセキュリティ侵害が最も発生しやすい箇所なので、それを暗号テキストに変換することが必要になるでしょう。
<connectionStrings>
<add name="MembershipConnectionString"
     connectionString="connectionString"/>
</connectionStrings>
DPAPI 暗号化の場合は、仮想ディレクトリにも物理ディレクトリにもネイティブ マシン キー暗号化を使用するので、実装が比較的単純で簡単です。これをプログラムで実装する方法もありますが、次のコマンドをコマンド プロンプトに入力するのが最も簡単です。
aspnet_regiis.exe -pe section -app MOSS_virtual_directory -prov provider

aspnet_regiis.exe -pef section MOSS_physical_directory -prov provider
主な検討事項が接続文字列ノードに暗号化を実装することだけの場合は、セクション パラメータを指定することで特定のセクションだけ暗号化できます。
aspnet_regiis.exe -pef "connectionStrings" "C:\Inetpub\wwwroot\WssVirtual " -prov "Provider"

aspnet_regiis.exe -pe "connectionStrings" -app "/MOSSAppinstance" -prov "Provider"
実装すると、機密情報のノードは XML 形式に従った暗号値に置き換わります。
<connectionStrings confiProtectionProvider=
"EncryptionProvider">
<EncryptedData>
<CipherData>
<CipherValue>XXXXXXXXXXXXXXXXXXXXXXXXXXXXX
</CipherValue>
<CipherData>
</EncryptedData>
</connectionStrings>
MOSS の全体的なアーキテクチャと同様に、独自の暗号化プロバイダを作成して、web.config や machine.config などの関連 MOSS 構成ファイルの暗号テキストを管理できるという点、さらに暗号化方式が RSA や DPAPI に限定されないという点で、このモデルはプラグ可能です。
暗号化を使用するといくつかの影響があります。暗号化にはローカル マシン キーを使用しているので、この構成ノードはそれを作成した MOSS サーバー上でしか使用できません。それ以外では、暗号プロセスが失敗します。侵入者がサーバーにアクセスできた場合、マシン キーを取得して接続文字列を復号化できてしまいます。また、復号化プロセスが、アプリケーションのパフォーマンスに若干の影響を与えます。
4. 代替アクセス マッピングとゾーン 代替アクセス マッピング (AAM) は、SharePoint 環境に複数のエントリ ロケーションをセットアップする場合に不可欠です。AAM 自体の機能は、ユーザーによるアクセス先が 1 つの物理サイトになるような複数の URL を指定できるようにすることです (図 2 を参照)。AAM を使用すると、ユーザーを MOSS サイトの同じ物理パスに導くことができますが、その際にさまざまな認証プロバイダと Web アプリケーション セキュリティ ポリシーを使用できます。また、AAM は、複数ドメインの使用、リバース プロキシ、およびその他の URL リダイレクト メカニズムを補います。MOSS が使用する URL は既定でマッピング済みですが、SharePoint の設計者が URL を明示的に作成して追加することで、さまざまなエントリ方法に対処できるように拡張できます。AAM は、内部および公開 URL マッピングを確実に正しく動作させるために必要です。SQL Server 認証プロバイダ
ここでは、プラグ可能な ASP.NET 2.0 SQL Server 認証プロバイダの実装手順について説明します。このプロバイダでは、web.config 接続文字列を暗号化して使用するフォーム ベースの認証を使用しており、この実装は、境界 (エクストラネット) MOSS 展開としては典型的なものです。
プラグ可能な SQL Server プロバイダを有効にする最初の手順として、ユーザー資格情報ストレージとして使用するデータベースを適切な SQL Server インスタンス上に作成します。これを、サービス プロバイダがメンバシップ データ ストアとして使用します。それには、次のコマンドを [名前を指定して実行] ダイアログ ボックスかコマンド プロンプトで実行します。
%WINDIR%\Microsoft.NET\Framework\v2.0.50727\aspnet_regsql
SQL Server ウィザードが起動するので、メンバ データの格納に使用するデータベースを構成します。
データベース ストレージ用のメンバシップ プロバイダがセットアップされていない場合は、アプリケーション サービスで使用する SQL Server を構成して、新しいデータベースが作成されるようにします。既存のデータベースがある場合は、関連情報を追加します (組織がデータベースの統合を目的としている場合)。
SQL 接続文字列の接続先はこの SQL インスタンスになるので、使用するデータベースで SQL Server 認証を使用するようセットアップする必要があります (図 A を参照)。ここでは、プレーン テキストのユーザー名とパスワードを使用しますが、その理由は、後の手順で、不正使用を防ぐために、ネイティブ ASP.NET 2.0 暗号化機能を使用して、プライベートな接続情報を暗号テキストで保存する方法を説明するためです。

ログイン フォームの作成
フォーム ベースの認証が使用されるサイトは、境界ネットワーク上に配置され、あらゆるインターネット ユーザーが自由にアクセスできるよう、外部と接しているのが一般的です。これを踏まえて、エクストラネット サイト コレクションを作成する場合は、インターネット プレゼンス MOSS テンプレートを選択するのが最適です。このテンプレートを使用すると、ログイン フォームを手動で作成する必要がなくなります。現在のサイトを拡張する場合、またはカスタム ログイン フォームを実装する場合は、Microsoft Visual Studio® 2005 を使用して行うのが簡単です。必要なコーディング量が比較的少なくて済みます。
はじめに、Visual Studio で、サイト コレクションの物理ディレクトリを Web サイトとして開きます。一般的には次に示すような場所に格納されています。
C:\Inetpub\wwwroot\wss\VirtualDirectories\<GUID>
まず、default.aspx ページを追加します。このページが IIS 仮想サーバー設定の既定ドキュメントです。ソリューション エクスプローラの [項目の追加] を使用して、Visual Studio のツールボックスで新しく作成した Web フォーム サーフェイスにログイン コントロールを追加します。
図 a SQL Server 認証のセットアップ
図 a SQL Server 認証のセットアップ (画像を縮小するには、ここをクリックします)
図 a SQL Server 認証のセットアップ
図 a SQL Server 認証のセットアップ (画像を拡大するには、ここをクリックします)

図 b [アプリケーション構成の管理] 画面での認証プロバイダの選択 (画像を縮小するには、ここをクリックします)
図 b [アプリケーション構成の管理] 画面での認証プロバイダの選択
図 b [アプリケーション構成の管理] 画面での認証プロバイダの選択 (画像を拡大するには、ここをクリックします)
同じページで、メンバシップ プロバイダ セクションで認証用に使用されているプロバイダが AspNetSqlMembershipProvider と指定されていること、およびロール マネージャ名が AspNetSqlRoleProvider であることを確認します。また、エンド ユーザーによる匿名アクセスを許可する場所を指定します。指定するには、/_layouts/setanon.aspx に移動してサイト全体を選択するか、ニーズに適したセキュリティ設定を行います。
次に、web.config を編集して大幅な変更を行います。<authentication> 要素が、<forms> 要素を使用するよう設定されていることを確認します。一般的に、この設定は Windows 認証をフォーム認証に切り替えると自動的に構成されます。これはログイン プロセスにおいて重要な部分ですが、その理由は、これによってユーザー認証チケットに関するデータが保持されるからです。チケットが、ASP.NET 2.0 認証方式を使用してページ ポストバック上のユーザー資格情報を保証します。しかし、web.config にはユーザー ストアへの SQL 接続に関する設定が含まれていないので、メンバシップ データベースに接続するための接続文字列を入力する必要があります。
<connectionStrings>
<remove name="LocalSqlServer" />
<add name="LocalSqlServer" connectionString="Server=SQLserver;
Database=aspnetdb;uid=username;
pwd=password;" providerName="System.Data.SqlClient" />
</connectionStrings>
サーバーの管理サイトの web.config ファイルにも同じ変更を行い、認証の種類が同じになるようにすると共に、PeoplePickerWildCard が AspNetSqlMembershipProvider に解決されるようにして、ユーザー追加を行う参照コントロールで適切な検索パスが使用されるようにします。
バックエンド XML ファイルに変更を行っているので、MOSS により IIS のリセットが要求されます。SQL Server データベースに接続されると、Web サイトを簡単に参照できます。ただし、コンテンツを管理するサイト コレクションの所有者がいません。WAT で、[セキュリティ] タブに移動してユーザーを追加し、サイト コレクション管理者に指定します。指定するには、[SharePoint サイトの管理] に移動して [サイト コレクションの管理者] にユーザーを追加します。web.config の peoplepicker ノードに対する変更は既に行われているので、名前が正しいことを確認してください。
最後に、接続文字列を DPAPI を使用して暗号化します。暗号化するには、[名前を指定して実行] ダイアログ ボックスを開いて、次のコマンドを実行します。
aspnet_regiis.exe -pef "connectionStrings"
"C:\Inetpub\wwwroot\WssVirtual\<GUID> "
£prov "DataProtectionConfigurationProvider"
操作が正常に完了すると、確認ダイアログが表示されます。

図 2 URL マッピングとゾーン
図 2 URL マッピングとゾーン (画像を縮小するには、ここをクリックします)
図 2 URL マッピングとゾーン
図 2 URL マッピングとゾーン (画像を拡大するには、ここをクリックします)
MOSS で AAM によるサイト マッピングをより細かく管理できるようにした新機能がゾーンです。ゾーンを使用すると、ユーザーがコンテンツへの接続に使用する AAM URL マッピングに応じて、複数の認証プロバイダを同じ物理パスと MOSS コンテンツにマップできます。AAM URL マッピングを指定する場合、必須ではありませんが、ゾーンを認証メカニズムにバインドすることをお勧めします。認証プロバイダ ページに定義されていないゾーンに対する AAM URL マッピングでは、Default ゾーンのセキュリティ設定が使用されます。
ゾーンを設定するには、その前にある程度の計画を立てておく必要があります。その理由は、複数の URL エントリ ポイントからアクセスして認証され、ポータルにルーティングされる多くのユーザーが、ゾーンによって大きな影響を受けるからです。新しい Web アプリケーションを拡張する場合は、使用するゾーンを設定の Load Balancing URL セクションに指定します (図 3 を参照)。外部からのアクセスが最も多いと予想される URL (たとえば、インターネットに公開する URL) は、Default ゾーンに配置することをお勧めします。この URL は、ゾーンが不明の場合に使用されます。
図 3 MOSS ゾーンの構成
図 3 MOSS ゾーンの構成 (画像を縮小するには、ここをクリックします)
図 3 MOSS ゾーンの構成
図 3 MOSS ゾーンの構成 (画像を拡大するには、ここをクリックします)
各ゾーン内では、ゾーンのユーザーの権限設定を定義するグローバル Web アプリケーション セキュリティ ポリシーをバインドできます。これにより、大規模な権限変更を一括管理できるようになります。Web アプリケーションには、さまざまなサイト コレクション内の複数のサイトが含まれることが多く、アプリケーションの規模と複雑さが増すほど、これらのサイトの権限管理が問題になります。MOSS 2007 を使用すると、アプリケーションの特定のユーザーまたはグループに対するフル アクセス、フル読み取りアクセス、書き込み拒否アクセス、すべて拒否アクセスなどのポリシー設定をバインドするグローバル セキュリティ ポリシーを実現できます。MOSS が提供し、SharePoint のサーバー管理インターフェイスから管理する、きめ細かい権限設定を、これらのポリシーは上書きできるので、構成の計画には十分な注意が必要です。
これらの機能を併用して、外部と接するサイトに、AAM 設定の定義に基づく、自社ユーザーのエントリ用と外部ユーザーのエントリ用の 2 つの URL を持たせることができます。これらの URL は、内部ユーザー用が contoso で、信頼される外部パートナー用が extranet.contoso.com など、一意です。2 つとも同じコンテンツにマップされますが、サイトへのアクセスには専用のゾーンを経由し、専用の認証プロバイダと専用のアプリケーション セキュリティ ポリシーを使用します。内部 URL のイントラネット ゾーンを構成すると、内部ユーザーはドメイン認証された Windows ID に解決され、外部パートナーは外部ゾーン経由の Web シングル サインオン認証をログインに使用することになり、どちらの場合も所属組織のユーザー資格情報を使用できるようになります。オブジェクトごとに手動で設定するのではなく、Web アプリケーション セキュリティ ポリシーをゾーンにバインドする機能を活用することで、すべての信頼される外部ユーザーにフル読み取りアクセスを付与することが可能になります。
5. セキュリティ保護されたコラボレーション向けのコンテンツ SharePoint サイト コレクションを制限すると、ユーザーが操作できる情報はアクセスが承認されているものだけに限定されます。新しい柔軟な権限メカニズムを使用すると、MOSS 環境に保存されるさまざまな種類のビジネス情報の管理能力が向上します。
MOSS 2007 を使用すると、バインド先のオブジェクトがサイト コレクション、個々のサイト、ドキュメント ライブラリ、サブフォルダ、リスト、個々のドキュメントまたはリスト アイテムのどれであっても、そこに ID をバインドできます。これにより、きめ細かいアクセス制御と該当オブジェクトに対する明示的なメンバシップとを強制して、アクセスを拒否したりユーザー インターフェイスを調整したりできるので、ユーザーはアクセスできないアイテムの存在に気付きません。MOSS のこの機能は、アイテムごとのセキュリティ (ILS) または保護されたオブジェクト (SO) として知られています。MOSS オブジェクト権限は元来階層的なので、リスト アイテムなどの個々のオブジェクトからリストやドキュメント ライブラリなどの大規模なアイテムまで対応できます。権限の継承を実装すると、下位レベルの子オブジェクトが上位レベルの親オブジェクトから権限を継承するかどうかを選択できます。既定で用意されている、ユーザーまたは SharePoint グループに付与可能な一意の権限は 33 あり、それぞれをオブジェクトにバインドできます。また、新しい権限レベルを作成することもできます。
たとえば、プロジェクト管理サイトで、Microsoft Word ドキュメントとして作成されてドキュメント ライブラリに格納された設計仕様書やコーディング作法など、開発に関する機密資料にアクセスできるユーザーを、開発担当者とプロジェクト管理者のみに限定できます。ライブラリの既定の権限はサイト権限から継承されますが、権限を変更して開発担当者やプロジェクト管理者だけがアクセスできるようにしたり、表示とアクセスの許可を Word ドキュメントごとに特定のプロジェクト管理者や開発チームに限定することもできます。一方、機密ではない資料は、アイテム、フォルダ、またはドキュメント ライブラリのレベルで完全に公開できます。
権限をイベント リストのプロジェクト完了日などのイベント アイテムに対して指定して、限られたメンバーだけが特定イベントを表示できるようにできます。さらに、ILS 機能を検索結果にまで拡張して、検索を実行しているユーザーのセキュリティ コンテキストにマップされているオブジェクトだけ返すこともできます。こうした制御により、事実上、ユーザー インターフェイスは該当するユーザーのコンテキスト専用になります。
権限管理アーキテクチャは MOSS 2007 で大幅に向上しています。権限は SharePoint のグループとドメイン グループ、および個々のレベルに対して設定できます。既定では、所有者 (フル コントロールを取得)、訪問者 (投稿者権限を取得)、メンバ (読み取り権限を取得) などのグループが既定で作成されます。個人またはドメイン グループは、これらの既定のグループに割り当てたり、サイト コレクション レベルで作成および管理できるカスタム グループに割り当てたりできます。カスタム グループには、さまざまな独自の権限レベルを持たせることができます。
グループをロールに基づいて作成する場合は、「開発担当者」グループと「プロジェクト管理者」グループを作成できます。その上で、きめ細かく権限を割り当てて、たとえば、開発担当者には関連コーディング ドキュメントをアップロードできるようにし、プロジェクト管理者にはそうしたドキュメントを評価および承認できる読み取りおよび承認権限を付与できます。グループ メンバシップはサイト コレクション内で一定なので、作成されたグループは別のプロジェクト サイトで再利用できます。
6. プラグ可能なシングル サインオンの統合 一般的なコンピュータ環境内では、ユーザーがアクセスできるサードパーティ製アプリケーションの数に制限はない上、アプリケーションごとに独自の認証基準があり、さまざまなセキュリティ問題やパスワードの使い回しにつながっています。MOSS SSO サービスを使用すると、接続された基幹業務システムへのマッピングに使用するユーザーの資格情報を暗号化してバックエンド キャッシュできるので、こうした問題が緩和されます。これにより、ビジネス データ カタログ (BDC) や SharePoint DataView Web Parts (DVWP) などの MOSS メカニズムを使用して、業務上重要な情報を取得して表示できるようになります。
MOSS SSO プロバイダは、ここで説明しているその他のアプリケーション アーキテクチャ機能と同様、プラグ可能です。MOSS に付属のプロバイダ (SpsSsoProvider) の他に一意の SSO プロバイダを指定することもできますが、環境内で同時に登録できる SSO プロバイダは、基幹業務システムにつき 1 つだけです。
7. Information Rights Management (IRM) ビジネス情報がオフラインで取得されている場合も含めて情報をクライアント レベルで保護することは、機密データを扱うことが多い企業、中でも California Senate Bill No. 1386, Sarbanes-Oxley (SOX Compliance) や Health Insurance Portability and Accountability Act (HIPAA) などの法令に対処する必要がある企業にとっては重大な課題です。サーバー側の Information Rights Management (IRM) は、MOSS リポジトリと統合して、Windows Rights Management (WRM) フレームワーク上に構築される共通ソリューションを提供します。IRM を使用すると、アクセス権限をドキュメント レベルで適用することで、ドキュメントの保存場所やそれを開くユーザーにかかわらず、ビジネス データを厳重に管理できます。一般的な IRM 実装では表示や印刷の承認しかできませんが、この機能を拡張することで、所定の時間を経過したユーザーの資格情報の検証を必須にしたり、IRM を使用しない資産のアップロードをユーザーに許可しないようにしたりできます。また、制限ポリシーを解除する有効期限タグをスケジュールしたり、グローバルな組織 IRM 権限ポリシーにバインドしたりすることもできます。
IRM 機能はプロテクタによって提供され、いくつかのプロテクタは、MOSS 2007 と共にインストールされます。プロテクタとは、ファイルの種類ごとの暗号化プロセスを管理するアプリケーションで、一般的には、MOSS 内に保存されるすべてのファイルについて専用の組み込みプロテクタが用意されています (Microsoft Office システム ファイルは OpenXML ファイル形式と共にネイティブでサポートされています)。ただし、MOSS 内のその他のプロバイダと同様、プロテクタのアプリケーション アーキテクチャはプラグ可能になっているので、他のファイルの種類用にカスタム プロテクタを実装できます。
IRM 実装の最初の手順は、MOSS 環境がすべての要件を満たしていることを確認することです。WRM Services Client がすべての MOSS フロントエンド Web サーバーにインストールされていること、および Microsoft Rights Management Services (RMS) が MOSS フロントエンド Web サーバーに接続できることが必要です。次に、MOSS が SharePoint のサーバーの管理にアクセスするために使用する RMS サーバーを指定する必要があります。指定するには、Active Directory の既定値を使用するか、場所を指定します。
IRM は、ドキュメント ライブラリなどの SharePoint データ ストア構造と直接連携して、権限を管理します。ユーザーが IRM 対応のドキュメント ライブラリに移動してドキュメントをダウンロードしようとすると、MOSS はそのドキュメント ライブラリ用に構成された権限を目的のドキュメントにバインドします (図 4 を参照)。その結果、MOSS の権限とドキュメントの権限とが一対一でマッピングされ、ドキュメントに関連する SharePoint ロールがドキュメント自体の IRM 権限レベルに変換されます。
図 4 ドキュメント ライブラリからの IRM 権限の変換
図 4 ドキュメント ライブラリからの IRM 権限の変換 (画像を縮小するには、ここをクリックします)
図 4 ドキュメント ライブラリからの IRM 権限の変換
図 4 ドキュメント ライブラリからの IRM 権限の変換 (画像を拡大するには、ここをクリックします)
ドキュメントはオフラインでの保護のためにローカルで暗号化されており、ドキュメント ライブラリにアップロードされるまでその状態が維持されます。アップロードされたドキュメントは、復号化された状態で維持されるので、SharePoint Gatherer で内容のインデックスを作成してフルテキスト検索できます (ただし、復号化された状態で内容にアクセスできるユーザー アカウントはありません)。
MOSS 2007 には、管理オーバーヘッドをあまり増やさずに効果的なセキュリティを組織に導入するのに役立つ新機能がいくつか用意されています。さらに、これらの機能は柔軟性が高く大幅なカスタマイズが可能なので、ユーザーがアクセスできる情報を必要なものにだけに制限できます。簡単な例については、見出し一覧の「SQL Server 認証プロバイダ」を参照してください。

Adam Robert BuenzARB Security Solutions LLC (sharepointsecurity.com (英語)) の SharePoint 設計者であり開発者です。Adam はセキュリティを中心に据えたコラボレーション環境に注目しています。Adam の連絡先は adam@sharepointsecurity.com です。


 SharePoint: SharePoint Enterprise Search ですべてを見つけ出す
SharePoint Matt Hester

SharePoint Enterprise Search ですべてを見つけ出す
概要:
  • エンタープライズ検索ソリューションのアーキテクチャ
  • ビジネス データのインデックス作成とクエリ
  • LOB データと人の知識

皆さんはおそらく、サーバーの稼働時間や利用可能性、ソフトウェアの更新、セキュリティなどを憂慮して、多くの時間を費やしてきたのではないでしょうか。たとえ、インフラストラクチャが完全に稼働していたとしても、
ネットワーク全体ですべてのアプリケーションとファイルが使用可能であっても、依然、生産性は失われています。従業員に必要なデータはすべて揃っています。ただし、彼らがそのデータを見つけ出すまでにどれくらいの時間がかかるのでしょうか。
情報過多を克服するために多くの手段がとられてきました。デスクトップ検索機能の台頭により、自分のシステムに保存されているさまざまなデータの中から情報の断片を見つけ出すのは容易になりました (2006 年 8 月の掲載記事「Find Anything with Windows Desktop Search」(英語) を参照してください)。しかし、ポータルや共有リソースに保存された数々のデータ、ビジネス アプリケーション内に留まったままのデータについてはどうでしょう。ましてや、従業員個人の記憶の中に蓄積された価値ある情報については置き去りのままではないでしょうか。この情報はユーザーにとって極めて重要です。業務を遂行するため、または迅速で適切な意思決定を下すうえで不可欠なデータと言えます。ネットワークの方々に散らばったデータを見つけ出し、集めるまでにどれくらいの時間を要するでしょう。こうした時間が企業の業績に及ぼす潜在的な影響を考える必要があります。
企業内に点在する情報を見つけ出すための時間。この時間こそ減らさなくてはなりません。どうしたら可能でしょうか。答えは至って簡単です。エンタープライズ検索機能を持つ検索エンジンを導入することで、問題は解決です。
エンタープライズ検索は組織内のどのような場所に格納された情報も見つけ出すことができます。デスクトップ、インターネット サイト、基幹業務アプリケーション、あるいはユーザーの記憶の片隅など、データがどのような場所に存在したとしてもエンタープライズ検索ツールはそのデータを見つけ出すのに役立ちます (ユーザーの脳にチップを埋め込む必要はありませんのでご安心ください)。
エンタープライズ検索ソリューションとは、デスクトップ検索とイントラネット検索機能を統合したものです。突き詰めれば、エンタープライズ検索ツールは統合検索、つまり、1 回のクエリで複数のデータ ソースにアクセスする検索を実行できる必要があります。ユーザーがクエリを入力するインターフェイスは 1 つです。しかし、内部ではそのクエリが複数の異なる検索エンジンに送信され、1 つに集約されたビューに結果が表示されます。
この記事では、Microsoft SharePoint ソリューションの次世代を担う Microsoft® Office SharePoint® Server 2007 (MOSS 2007) の持つ強力な検索エンジンが、組織内に積み上がった情報の山を打ち崩すためにどのように役立つかについて解説します。MOSS 2007 は旧バージョンに比べ、さまざまな点で改良され、一部のコンポーネントが再開発されたほか、まったく新しい機能も加わりました。ここではインデックス作成、伝達、関連性、コンテンツ ソースなどの主要コンポーネントについて取り上げ、優れたエンタープライズ検索機能を使用するにあたり、これらがどのように機能するかについて解説していきます。

SharePoint で企業全体を検索する
エンタープライズ検索は主要な機能が異なる 4 つのバージョンで構成されます。Microsoft Office SharePoint Server 2007 for Search Standard Edition、Microsoft Office SharePoint Server 2007 for Search Enterprise Edition、Microsoft Office SharePoint Server 2007 Standard、および Microsoft Office SharePoint Server 2007 Enterprise の 4 種類です。
2 つの Search エディションと完全な SharePoint Server エディションとの違いは、人の検索機能 (Knowledge Network for MOSS 2007 との統合を含む)、ビジネス データ カタログ、または高度な検索センターにあります。2 つの Search エディションにはこれらが含まれていません。図 1 に主要な違いを示します。
Figure 1 4 つの Search が提供する主な違い (Close Figure 1)

 | Microsoft Office SharePoint Server 2007 for Search Standard Edition | Microsoft Office SharePoint Server 2007 for Search Enterprise Edition | Microsoft Office SharePoint Server 2007 Standard Edition | Microsoft Office SharePoint Server 2007 Enterprise Edition
インデックス | 特別な構成なしに使用できる 40 種のファイルの種類 (拡張可能) | 特別な構成なしに使用できる 40 種のファイルの種類 (拡張可能) | 特別な構成なしに使用できる 40 種のファイルの種類 (拡張可能) | 特別な構成なしに使用できる 40 種のファイルの種類 (拡張可能)
ファイルの共有、Web サイト、SharePoint サイト、Exchange パブリック フォルダ、Notes データベース ファイルでの検索サポート (特別な構成不要) |  |  |  |
サード パーティ製ドキュメント リポジトリに対する検索のサポート |  |  |  |
人と専門家の検索のサポート |  |  |  |
構造化データ ソースの検索のサポート |  |  |  |
セキュリティで保護されたコンテンツへのアクセス制御の提供 |  |  |  |
拡張された検索センター UI の提供 |  |  |  |
ドキュメントの制限 | 400,000 | 無制限 | 無制限 | 無制限
UI には他の候補を表示する機能など、さまざまな新機能が加わりました。インターネット検索エンジンの主軸であるこの機能は、一般的な検索用語にスペルミスがあった場合にユーザーに修正候補を提示します (図 2 を参照)。 インターフェイスでは、ヒット ハイライト機能や "おすすめコンテンツ" もフル サポートされます。しかし、これらは新しい検索機能のほんの一部に過ぎません。
図 2 SharePoint Search に新しく導入される自動スペルチェック機能
図 2 SharePoint Search に新しく導入される自動スペルチェック機能 (画像を縮小するには、ここをクリックします)
図 2 SharePoint Search に新しく導入される自動スペルチェック機能
図 2 SharePoint Search に新しく導入される自動スペルチェック機能 (画像を拡大するには、ここをクリックします)

人の知識を検索する
最も注目すべき新機能として、特定の知識や経験を持った「人」を検索できるようになったことが挙げられます。この機能により、ユーザーは組織内の人が持つ知識を引き出し、活用できるようになります。高く積み上がった情報の山を打ち崩す重要な第一歩です。
そのために、Active Directory® の配布リストや SharePoint のユーザー グループなどの、すべてのライトウェイト ディレクトリ アクセス プロトコル (LDAP) で、インデックス作成機能と検索機能を実行できるようになりました。実際には、MOSS は LDAP ディレクトリを直接検索しません。人の検索を行うには、LDAP の情報を MOSS にインポートする必要があります (企業のインフラストラクチャ全体で検索を実行することもできます)。
検索結果は個人の "社会的距離" に応じてグループ化できます。"社会的距離" とはユーザーの物理的な距離 (販売アシスタントが CFO に連絡しようとは思わないでしょう) と共通の関心事を意味します。図 3 に、人の検索の結果を表示しています。
図 3 関連知識を持つ同僚を見つける
図 3 関連知識を持つ同僚を見つける (画像を縮小するには、ここをクリックします)
図 3 関連知識を持つ同僚を見つける
図 3 関連知識を持つ同僚を見つける (画像を拡大するには、ここをクリックします)

ビジネス データを検索する
SharePoint ではさまざまな種類のビジネス データにもインデックスを付けることができます。人事アプリケーション、CRM、予算報告書などの LOB アプリケーションもその対象になります。従来、LOB アプリケーションの通常のインターフェイス以外からこの種のデータにアクセスすることは困難で、一般的な従業員がこのデータを検索して使用する妨げとなっていました。
しかし、今後は MOSS 検索によりリレーショナル データベース、Lotus Notes データベースなど、どのような LOB アプリケーションのデータも検索できるようになりました。つまり、ADO.NET または Web サービスを使用してアクセスできるようになったのです。この機能の優れた点は、独自にコードを記述する必要がないことです。ビジネス データ カタログ機能を使用することで、ビジネス データの取得はドキュメントや Web サイトにアクセスするのと同じくらい容易になります。ビジネス データ カタログ機能は検索センターによって提供される資産管理やカスタマイズされたスコープに簡単に統合できます。

関連性を返す
もちろん、いくら新機能がたくさん盛り込まれたとしても、新機能によってもたらされる検索結果が正確でなければ価値はありません。幸い、MOSS では関連性の面で劇的な改良がなされました。これらの改良点について説明する前に、エンタープライズ検索における関連性と、インターネット検索における関連性は異なることについて理解することが重要です。
おそらく、イントラネット検索についても、インターネット検索と同じツールで実行できる (その精度も同じである) と考える読者が多いのではないでしょうか。簡単に説明すると、これらはまったく異なる環境で、まったく異なるニーズと要件に基づいて行われます。これらの違いは主にセキュリティ、構造、階層の 3 つにグループ分けすることができます。
エンタープライズに比べると、インターネットのセキュリティは放置状態とも言えます。インターネット上のデータは一般的に匿名でアクセスでき、インデックス作成、検索には認証、セキュリティ調整などは不要です。一方、エンタープライズ環境では検索者の権限と照合して結果をフィルタリングするなど、厳密なセキュリティ モデルに従う必要があります。
構造の影響はその密度に関係します。インターネットの世界は広大で深く、他のサイトとリンクすることでそのコンテンツを増やしています。それに比べてエンタープライズでは、通常、リンクはナビゲーションのために使用するのがほとんどで、その構造は単純です。
リンクの構造は広い意味では、サイトの階層という要因に関連しています。インターネットでは通常、階層という概念はなく、トップレベルに位置するサイトもごく限られています。一方、企業のイントラネットは通常、計画段階から階層構造を持って作られます。企業に複数のルート レベルが存在しても、組織の主要ポータルは通常、1 つだけです。
これらの根本的な違いにより、エンタープライズ検索ソリューションがデータにインデックスを作成し、結果を返す方法が変わってくるのです。MOSS 2007 はエンタープライズのさまざまなニーズに対応することを目的とします。MOSS には Microsoft リサーチと MSN® チームの作業を組み合わせた既存のテクノロジを使用して開発された、新しいランキング エンジンが使用されています。一連の関連性アルゴリズムを作成することで、関連性が向上し、ドキュメントと LOB データをクロールすることで得られた内外の情報が収集されます。エンタープライズ データにインデックスが作成される場合、200 種以上のドキュメントの種類がスキャンされ、言語の検出、メタデータの抽出、テキスト分析の実行にアルゴリズムが適用されます。これらの新しいアルゴリズムは、エンタープライズ データと LOB アプリケーションのニーズを満たすように特別に調整され、結果の制度を劇的に向上します。
一部のメタデータ タグは関連性を算出する場合に使用されます。次に考慮点をまとめます。
  • クリックの距離: 信頼できるサイトからの距離を参照します (距離が短いほど、関連性は上がります)。
  • アンカー テキスト ハイパーリンクは対象を探す上で注釈の役割を果たします。さらに、アンカー テキストは非常に説明的な傾向があります。
  • URL の深さ: 階層の上位にある URL は関連性が高い傾向があります。
  • URL 照合: 直接、URL に含まれるテキストと照合します。
  • メタデータ抽出: タイトルと作成者の記載がない場合は、ドキュメントからそれらを自動的に抽出します。
  • 自動言語検出: ユーザーの言語で表記されている結果の優先度を付けます。
  • ファイルの種類のバイアス: 特定のファイルの種類に対する関連性がより高くなる傾向があります (たとえば、PPT ファイルは XLS ファイルに比べ関連性が高くなることが、より頻繁に起こります)。
  • テキスト分析: 用語の照合、用語の頻度、語句の変化などの要因に基づいた、従来のテキスト ランキング。

インデックス作成のしくみ
MOSS 2007 ではインデックス作成サービスの機能とコンテンツの管理方法において、重要な改良点が盛り込まれています。初心者の方は、SharePoint サーバー、Web サイト、ファイル共有、Exchange パブリック フォルダ、Lotus Notes データベース、LOB アプリケーションの中から、当てはまるコンテンツ ソースを指定できます。全体的なインデックス作成の管理操作性は合理化され、複数のコンテンツ ソースにわたって何を、どのように、いつ、インデックス化するかをユーザーが自由に選択できるようになりました。これは各種ルールをクロールすることで可能になり、この機能でパスを含めたり除外したりできるようになります。クローラが URL のリンクをたどる方法を構成することもできます。組み込みのログにより、クロールされたサイトの数とインデックスの作成方法を総合的に参照できます。
インデックスは Windows® デスクトップ検索で使用されるインデックス テクノロジに似ています。コンテンツ インデックスとプロパティ ストアの 2 つの主要コンポーネントがインデックス機能の核になります。これにより非常に効率的にデータを処理できます。コンテンツ インデックスにはファイルに含まれる実際のテキストのほか、企業のインデックスに含まれる関連した単語をインデックスに変換したものも含まれます。プロパティ ストア データベースは結果の処理に重要な役割を果たします。プロパティ ストアのデータベースには、ストアにあるすべてのドキュメントに関する、あらゆるメタデータ プロパティ (作成者、作成日付、ドキュメントの種類など) が格納されています。構造上、プロパティ ストアはプロパティとその値のテーブルで構成されます。テーブルの各行は、完全なテキスト インデックスで、個別のドキュメントに対応します。プロパティ ストアにはドキュメントにインデックスが作成されるときに取得されたドキュメント レベルのセキュリティが保持され、強制的に使用されます。
インデックス作成とストレージ処理は、コンテンツ ソースのクロールを行うインデックス エンジンにより始まります。エンジンはコンテンツ ソースを読むために適切なプロトコル ハンドラが存在することが確認されると、クロールを開始します。コンテンツ ソースの正しいプロトコル ハンドラが読み込まれると、プロトコル ハンドラと必要な IFilter が、コンテンツ リソースからアイテムの抽出とフィルタリングを開始します。IFilter はインデックス エンジンが新しいファイル タイプのコンテンツを開き、読み込み、インデックスを付与できるようにするアドインで、このアドインがなければ完全なインデックスは作成されません。IFilters は各ドキュメントのテキストとメタデータを抽出し、ストリームをインデックス エンジンに戻します。
そして、ドキュメントのプロパティはプロパティ ストアに格納され、ドキュメントの実際のテキストはコンテンツ インデックスに配置されます。その前の段階で、インデックス エンジンは "不要な" 単語を取り除きます。また、エンジンはワードブレーカとステマを使用して情報を処理し、データを最適化することで、より快適なクエリの実行を可能にします (ワードブレーカはテキストを単語や句に分けます。ステマは指定された単語の活用形を生成します)。
インデックス エンジンは継続的な伝達を使用することで、インデックスがほぼ即座に作成されるようになりました。継続的な伝達を使用すると、別のコンテンツ ソースにクロール処理が移動してもインデックスは継続的に作成されます。この強化により、ほぼ即座に結果を得られるようになりました。SharePoint Portal Sever 2003 では大規模なコンテンツのクロールには数日を要し、インデックスはクロールが完了したときにのみ伝達されていたため、劇的な改善と言えます。

クエリのしくみ
ユーザーがクエリを入力するか、カスタム アプリケーションからインデックスが呼び出されると、クエリ エンジンは要求の処理を開始します。最初に、クエリは言語固有のワードブレーカに渡されます。言語を識別できない場合は、特定の言語に依存しないワードブレーカが呼び出されます。クエリが分析されると、エンジンからステマ (ステミングが有効な場合) に情報が渡り、さらに処理を進めます。この 2 段階の処理でクエリから返される結果の関連性と効率が上がります。
クエリでプロパティ情報が指定されている場合は、プロパティ ストアのドキュメントと突き合わせて、コンテンツ インデックスが確認されます。続いて、クエリのプロパティが確認のために再度照合されます。クエリ エンジンはさらに詳細なレベルのフィルタリングを実行し、ユーザーがアクセス権を持たない結果を取り除きます。照合結果は関連性の高い順に一覧で返されます。図 4 に、インデックス作成とクエリの全コンポーネントの相関図を示します。
図 4 MOSS 2007 Enterprise Search 環境のアーキテクチャ
図 4 MOSS 2007 Enterprise Search 環境のアーキテクチャ (画像を縮小するには、ここをクリックします)
図 4 MOSS 2007 Enterprise Search 環境のアーキテクチャ
図 4 MOSS 2007 Enterprise Search 環境のアーキテクチャ (画像を拡大するには、ここをクリックします)

管理の強化
管理者にとって、検索環境の管理は容易になるはずです。エンド ユーザーと管理者は改良された共通のツールを使用します。これにより、プラットフォームへの接続ポイントが異なることで発生する複雑さを軽減できます。さらに、MOSS 2007 の新しい管理モデルにより、検索エンジンの利点はさらに大きくなります。(図 5 に、検索設定の変更に使用されるメイン ページを示します。)
図 5 検索設定を構成する
図 5 検索設定を構成する (画像を縮小するには、ここをクリックします)
図 5 検索設定を構成する
図 5 検索設定を構成する (画像を拡大するには、ここをクリックします)
さまざまな検索機能を制御するためのスコープも改良されています。スコープを使うことで、コンテンツ ソース内の検索が容易になり、本質的にはインデックスを小さな塊で管理できるようになります。SharePoint Portal Server 2003 ではスコープはコンテンツ ソースに接続されていたため、柔軟性が制限され、管理面でも多少困難さが残りました。MOSS 2007 では、コンテンツ ソースを切り離したことで、より大きな柔軟性が得られるようになりました。URL、種類、作成者など任意のプロパティを基にスコープを定義できます。また、特定の作成者ごとにすべての技術関連ドキュメントをまとめるなど、複数のルールを持つスコープを組み合わせることもできます。
もちろん、検索エンジンのパフォーマンスを向上するための手段として最も重要なのは、現在のインデックスの使い方を理解することです。管理用ツールセットとして新しく追加されたものの中で、最も優れたツールの 1 つはクエリ レポート機能です。特別な構成なしに使用できるクエリ レポート機能により、クエリのボリューム傾向、上位クエリ、クリック率、結果が得られなかったクエリなどに関する情報を迅速に検索できるようになります。クエリ レポートはサイト レベルでの詳細情報と、プロバイダ レベルの主要サービスを提供します。図 6 に、サンプル レポートを示します。情報を Microsoft Excel® にエクスポートし、詳細な分析やデータ上でのピボットを行うこともできます。
図 6 MOSS 2007 のクエリ レポート
図 6 MOSS 2007 のクエリ レポート (画像を縮小するには、ここをクリックします)
図 6 MOSS 2007 のクエリ レポート
図 6 MOSS 2007 のクエリ レポート (画像を拡大するには、ここをクリックします)

セキュリティと特権
先にも述べたように、クエリ エンジンによって結果がフィルタリングされるため、ユーザーにはアクセス許可が付与されているドキュメントのみ表示されます (SharePoint Portal Server 2003 では、ユーザーに表示されるリンクの中に、権限によって表示が制限される可能性のあるものも含まれていました)。セキュリティ調整で注意すべき点は、MOSS 2007 では Web クロールに対して、セキュリティ調整を行わないことです。HTTP プロトコルではアクセス制御情報を確認する方法がないため、Web サイトを調整する方法はありません。また、MOSS 2007 はビジネス データ カタログ、または人の検索でもセキュリティの調整を行うことはできません。
MOSS 2007 は既存のアクセス制御リスト (ACL) を順守することで、インデックスに含まれるドキュメントのセキュリティを確保します。これは他の検索ツールとの主な違いです。ファイルに手動で権限を設定するために構成ファイルを使用しなければならない一部の検索エンジンとは異なり、MOSS 2007 では現在の権限を同期することができます。
インデックスは 1 つのドキュメントの ACL に対する変更を素早く反映できます。たとえば、現在、インデックスに格納されている Excel スプレッドシートがあり、このドキュメントの ACL が制限するように変更されたとします。管理者はこのドキュメントに再度インデックスを作成し、クロールを実行するだけで、セキュリティ調整が即座に行われます (必要な場合は、ドキュメントはインデックスから完全に削除されます)。
さらに、個々のドキュメントに固有の権限を割り当てたり、ドキュメント ライブラリや親ディレクトリから権限を継承するように設定したりできます。この機能により、ドキュメントを表示、編集、保存できるグループや個人を選択する処理が、一層容易になります。
認証とサインオン管理でも強化された点があります。今回のバージョンからセキュリティ資格情報キャッシュが拡張可能になったため、MOSS はサード パーティのソースや独自にコードを記述したアドオンなども、シングル サインオン用の資格情報キャッシュ システムに受け入れられるようになりました。さらに、今後は、主要な認証でサード パーティ システムを受け入れられるようになります。これら 2 つの機能拡張は新しい ASP.NET プロバイダ モデルに組み込まれ、他のディレクトリ サービスでも使用できます。

カスタマイズ
MOSS 2007 ではユーザー インターフェイスを変更するために数々のオプションが設けられています。UI は Web サイトを変更するためにこれまでにも使用してきた各種ツールの多くと共にカスタマイズすることができます。また、マスタ ページの作成に役立つ Office SharePoint Designer などの新しいツール (ブランド化されたサイトにビルドに簡単な方法を提供します) も加わりました。図 7 に、編集中の検索結果ページを示します。
図 7 検索結果ページの外観をカスタマイズする
図 7 検索結果ページの外観をカスタマイズする (画像を縮小するには、ここをクリックします)
図 7 検索結果ページの外観をカスタマイズする
図 7 検索結果ページの外観をカスタマイズする (画像を拡大するには、ここをクリックします)
特別な構成なしに使える MOSS 2007 の検索センターのインターフェイスには、[すべてのサイト] と [人] の 2 種類のタブがあります。タブを追加するのは簡単で、ユーザーが最も頻繁に使用する情報の種類に応じて、異なるタブを追加できます。たとえば、企業アプリケーション、データベース、またはディレクトリ サービスなどへの直接的な入り口を作成することもできます。これらのタブとスコープを関連付けることもできます。これは特定のコンテンツに意味のわかりやすい検索タブを作成するのに役立ちます。検索専用エディションでは検索タブのカスタマイズはサポート外ですので、注意してください。

まとめ
ここまでお読みいただいたとおり、MOSS 2007 ではエンタープライズ検索機能に新しい極めて強力な機能拡張が加わり、ユーザーの効率と生産性をさらに向上させることができます。詳細については、Microsoft Office SharePoint Server TechCenter (英語) を参照してください。

Matt HesterMicrosoft Across America の TechNet プレゼンタ。ライブ プレゼンテーションを閲覧するには、www.technetevents.com/mhester (英語) を参照してください。blogs.technet.com/matthewms (英語) ではブログも公開されています。


 SharePoint: SharePoint の優れたコマンド ライン管理
SharePoint Todd Klindt

SharePoint の優れたコマンド ライン管理
概要:
  • STSADM を使用して SharePoint を構成する
  • 日常の管理タスクをスクリプト化する
  • 高度な STSADM 操作

ユーザーが Windows や Microsoft Office でどのように作業するか考えてみてください。マウスが好きで、ポインタでメニューやツールバーをナビゲートして一般的なタスクを実行するユーザーもいれば、キーボードが好きで、
慣れ親しんだキー入力やショートカットをすばやく実行するユーザーもいます。どのタスクでも、多くの場合、実行するための方法は複数存在します。
グラフィカル インターフェイスが使いやすいのは事実ですが、同じ作業を繰り返し実行する必要があるタスクでは、GUI を使うと手間がかかる場合があります。キーボードを使った方が簡単な作業もあります。SharePoint® 管理を実行する場合、グラフィカル インターフェイスを使った作業に行き詰まりを感じることがあると思います。しかし、SharePoint にはグラフィカル インタフェースよりも優れた方法が用意されています。
Windows® SharePoint Services (WSS) および Microsoft® Office SharePoint Server 2007 (MOSS) を管理する主要なインタフェースは、GUI ベースの SharePoint のサーバー管理です。しかし、SharePoint には、さらに強力な管理機能のためのコマンド ライン ツールもあります。STSADM.exe という名前のこのツールは、SharePoint のサーバー管理の全機能に加え、多くの管理者が望んでいるコマンド ラインの柔軟性も備えています。この記事では、STSADM を使用した WSS と MOSS の管理についての短期集中コースを提供します。また、環境の構成方法に関するいくつかのヒントと、一般的な STSADM コマンドについても一部説明します。高度な STSADM コマンドについても一部紹介します。これらの高度なコマンドを知っていれば、使用する必要が生じたときにヒーローになれるかもしれません。

はじめに
STSADM は隠れた存在であるため、STSADM をこれまで知らなかった方もいるかもしれません。STSADM は、Windows SharePoint Services 2.0 では既定で c:\program files\common files\microsoft shared\web server extensions\60\bin にあります。バージョン 3.0 では、既定で c:\program files\common files\microsoft shared\web server extensions\12\bin にあります。
このツールに簡単にアクセスするためには、2 つの異なる方法を使用します1 つ目は、単に上記のディレクトリを、使用している PATH 環境変数に追加するという簡単な方法です。この方法を使用すると、ファイル システム内でいつでも STSADM を使用できます。ただし、これは常に使用できるとは限りません。2 つ目の方法は、CDM.EXE へのショートカットを作成し、STSADM の場所を初期のディレクトリとして設定する方法です。ショートカットが STSADM を直接ポイントするようにすることはできないのでしょうか。STSADM はインタラクティブではないため、その方法は機能しません。そのため、ショートカットが STSADM を直接ポイントするようにした場合、その使用法が表示されてもすぐに消えてしまいます。
STSADM を実行する場合は、Web サーバー上のローカル Administrators グループのメンバであることが必要です。また、アプリケーションをローカルで実行する必要もあります。つまり、STSADM を使用して、SharePoint サーバーをリモートで管理することはできません。
STSADM で実行できる操作を確認するには、コマンド プロンプトで「stsadm.exe -help」と入力します。新しい操作が追加されている可能性があるため、更新プログラムおよび修正プログラムを適用した後にこのリストを必ずチェックしてください。go.microsoft.com/fwlink/?LinkId=77516 (英語) には、stsadm.exe 操作の簡単なガイドもあります。

STSADM の基本機能
ここでは、既存の SharePoint インストールを調整する際に使用できるいくつかのコマンドを紹介します。STSADM を使用して SharePoint に機能を追加し、構成設定を変更することができます。
STSADM では実行する操作の前に -o パラメータを付けます。単に「STSADM -operationname」と入力しただけでは機能しません。たとえば、サイト テンプレートをインストールに追加する場合は、次のコマンドを使用します。
Stsadm -o addtemplate -filename <filename of the template>
-title <title of template> -description <description of template>
または、Web パーツ パッケージを追加する場合は、次のコマンドを使用します。
Stsadm -o addwppack -filename <filename of the Web Part Package>
操作の使用についての詳細は、操作を引数なしで単純に渡すと、入力の必要がある内容が示されます。「STSADM -help operationname」と入力した場合も、使用法についての情報が示されます。
テンプレートを管理する場合、追加されたテンプレートを参照するには enumtemplates 操作を使用します。インストールされているテンプレートを削除するには deletetemplate を使用します。同様に、Web パーツ パッケージを処理するためのコマンドもあります。各仮想サーバーまたは Web アプリケーションにインストールされている Web パーツ パッケージをリストするには enumwppacks 操作を使用できます。また、追加されている Web パーツ パッケージを deletewppack を使用して削除できます。
STSADM には、SharePoint 設定を処理する 2 つの操作、setproperty と getproperty もあります。パラメータを指定せずに実行すると、表示または操作できるプロパティのリストが示されます。STSADM そのものと同じように、このリストは更新プログラムおよび修正プログラムで変更されます。ただし、他のプロパティよりも有用なプロパティはごくわずかです。図 1 に、SharePoint をインストールした後に設定できるプロパティをいくつか示します。この中には、SharePoint 管理者からの質問が多い最も一般的なプロパティが含まれています。
Figure 1 有用な SharePoint プロパティの設定 (Close Figure 1)

プロパティ | 機能
alerts-enabled | 仮想サーバーまたは Web アプリケーションに対する警告のオン/オフを切り替えます。
alerts-limited | ユーザーに対して、仮想サーバーまたは Web アプリケーションに特定の数の警告を設定するように制限するかどうかを指定します。
alerts-maximum | 警告制限が設定されている場合、ユーザーが設定できる最大警告数を表します。
days-to-show-new-icon | これは、通知ポストなど、Web サイトに追加された項目の横に "新規" アイコンが表示される長さを設定します。
job-immediate-alerts | SharePoint が送信された即時警告を確認する頻度を指定します。SharePoint 2.0 の既定値は 5 分です。ここで間隔を調整できます。時間を短縮すると、Web サーバーやデータベース サーバーの負荷が増えるので、このプロパティを変更する場合は注意が必要です。
job-daily-alerts | 日単位の警告が送信される時間を指定します。SharePoint 2.0 の既定では "22:00 ～ 06:00" です。ユーザーがサーバーと同じ時間帯にいない場合、このプロパティを調整できます。
job-weekly-alerts | ここでパターンを確認できます。これは、週単位警告のスケジュールを設定します。
ここでは、1 つプロパティを取り上げてその使用法について簡単に説明します。次のコマンドを入力すると、SharePoint は 10 分おきに即時警告を送ります。
Stsadm -o setproperty -pn job-immediate-alerts -pv "Every 10 minutes"
上記のコマンドでは、-propertyname や -propertyvalue ではなく、-pn や -pv を使用しています。これらは、単語全体を入力したくない場合に使用できるショートカットです。また、ここで取り上げる例やコマンドはすべて、Windows SharePoint Services のバージョン 2.0 と 3.0 の両方で機能します。

日常の管理
毎日の SharePoint 管理は極めて簡単です。多くの SharePoint 管理者は、ユーザーやサイトの処理に関する日常のタスクを大量に抱えています。STSADM には、これらのタスクを合理化できるいくつかの操作があります。
最初に、サイトと Web について説明します。一貫性を保つため、ここでは "サイト" はサイト コレクション、"Web" はサブサイト (サブ Web とも呼ばれます) の意味で使用します。わかりにくい用語もありますが、STSADM で使用する内容と同じ意味で使用していれば、必要なコマンドを見つけやすくなります。
大規模な SharePoint インストールを実行する場合、ユーザー用の新しいサイトの作成に長時間かかる可能性があります。著者自身も繰り返し経験しています。SharePoint のサーバーの管理では、新しいサイトは非常に簡単に作成できます。ただし、筆者自身はこのタスクを非常に頻繁に実行するため、STSADM を使用した方がすばやく実行できます。
著者の場合、この作業には createsite 操作を使用します。この操作は非常に簡単で、次のパラメータを取ります。
  • url <url>
  • ownerlogin <DOMAIN\name>
  • owneremail <someone@example.com>
  • ownername <display name>
  • lcid <language>
  • sitetemplate <site template>
  • title <site title>
  • description <site description>
  • quota <quota template>
これらをコマンド プロンプトで実行するには、「stsadm -help createsite」と入力します (図 2 を参照)。これら 9 つのパラメータの中で、必須のフィールドは URL、ownerlogin、および ownermail だけです。
図 2 createsite パラメータ
図 2 createsite パラメータ (画像を縮小するには、ここをクリックします)
図 2 createsite パラメータ
図 2 createsite パラメータ (画像を拡大するには、ここをクリックします)
定期的に作成するサイトがある場合は、一歩先まで踏み込んで、STSADM のラッパー スクリプトを作成し、タスクを自動化することでプロセスを合理化できます。たとえば、個人用のサイトの作成を自動化するには、次のコマンドを createpersonalsite.cmd という名前でテキスト ファイルに保存します。
stsadm -o createsite -url http://localhost/users/%1 -ownerlogin contoso\%1
-owneremail %1@contoso.com -sitetemplate usersite.stp
-title "Personal site for %1" -description "Personal site for %1" -quota "500 MB"
次に、ユーザー jsmith のサイトを作成します。このコマンドを実行するだけです。
createpersonalsite.cmd jsmith
サイトの作成をスクリプト化すると、入力の手間を大幅に省くことができ、新たに作成するサイトすべての一貫性を確実に保つことができます。createweb 操作は、Web レベルでも同じ機能を提供します。
Windows SharePoint Services 2.0 では、特定の仮想サーバーのサイト コレクションに関する大量のリストを簡単に作成するには、STSADM を使用する以外にありません。enumsites を使用すると、特定の仮想サーバーまたは Web アプリケーションのサイト コレクションをすべて XML 形式でリストできます。これをデータ ビュー Web パーツと組み合わせると、サイト コレクションのリストを簡単に表示できます (詳細については、見出し一覧の「データ ビュー Web パーツの使用」を参照)。
STSADM には、deletesite 操作 という名前から想像できるとおり、サイトを削除するための操作があります。実行する必要があるのは、URL を指定することだけです。オプションで、-deleteadaccounts を渡して Active Directory® でアカウントを削除することもできます。Web で作業している場合は、deleteweb 操作を使用できます。
サイトまたは Web のユーザーを追加、削除、および列挙することもできます。関連する操作は、adduser、deleteuser、および enumusers です。これらの操作は、ユーザーをサイトにまとめて追加する必要がある場合や、監査目的でサイトへのアクセス権を持っているユーザーのリストを維持する必要がある場合に使用すると便利です。
Web で作業している場合は、renameweb 操作にアクセスして、Web の名前や URL を変更できます。たとえば、Web の名前を "oldname" から "coolnewname" に変更する場合は、次のコマンドを使用します。
Stsadm -o renameweb -url http://localhost/oldname -newname coolnewname
この操作は、プロジェクト名を変更する場合やビジネス ユニットを再調整する場合に大いに役立ちます。Windows SharePoint Services 2.0 では、これは大きな問題です。Web の移行は SMIGRATE.exe だけでしか実行できず、SMIGRATE.exe ではメンバシップや警告などのユーザー関連の設定を維持できないからです。Windows SharePoint Services 3.0 では、STSADM で Web およびサイトのバックアップと復元を実行できるので、それほど大きな問題ではありません。

バックアップと復元
STSADM の最も有用な利用法の 1 つは、サイトおよび Web のバックアップと復元です。小規模または中規模インストールの場合、この機能は障害時復旧計画の基礎となります。backup 操作はそのままバックアップを意味し、使い方も簡単です。バックアップするサイトと、バックアップ ファイルの書き込み先を、次のように STSADM に指示するだけです。
Stsadm -o backup -url http://localhost -filename site.bak
この操作は、サイト コレクション全体を site.bak というファイルにダンプします。それには、Web、ドキュメント バージョン、リスト、ユーザーなどすべてのサイト コンテンツが含まれます。サーバーのファイル システム レベルで行われたサイト定義や変更はバックアップされません。
backup 操作が重要な場合は、いくつかの潜在的な問題に注意する必要があります。サイトが大きい場合、コンテンツ データベースがバックアップ プロセス中にロックされる可能性があります。ロックされた場合、backup 操作が完了するまで、そのデータベース内のすべてのサイトにユーザーがアクセスできなくなる場合があります。この問題は Service Pack で一部対処されていますが、サイトのサイズは大きくなるので、引き続き注意する必要があります。STSADM では、バックアップと復元操作の実行中にサーバーの temp ディレクトリも使用するため、ドライブの容量も監視してください。
データ ビュー Web パーツの使用
enumsites コマンドをデータ ビュー Web パーツと組み合わせると、サイト コレクションのリストを簡単に表示できます。ここでは、その方法について説明します。
最初に、実行するスケジュール済みタスクを次のように作成します。
stsadm –o enumsites –url http://localhost
>c:\inetpub\wwwroot\excludedsite\sites.xml
XML ファイルが IIS によって公開されていても、SharePoint では管理されていないディレクトリに書き込まれていることを確認します。次に、Microsoft FrontPage® (または FrontPage の後継製品である Microsoft Office SharePoint Designer 2007) を使用して、データ ビュー Web パーツを Web パーツ ページに追加し、これを XML ファイルの URL にポイントします。
データ ビュー Web パーツには、並べ替え、フィルタ、グループ化などの機能があります。また、URL フィールドをリンクにしてサイトに直接移動することもできます。代わりに Web のリストを使用する場合は、enumsubwebs 操作で、サイト コレクションまたは Web 内のサブ Web の XML 出力を提供します。

最後に、STSADM のバックアップ機能は小規模または中規模のサイトでは適切に機能しますが、この機能は特に拡張されないことに注意してください。非常に大きいサイト (数 GB 以上) の場合、バックアップと復元のプロセスの速度は若干遅くなる可能性があります。
サイトの復元もバックアップと同様に非常に簡単です。STSADM -o restore は、STSADM -o backup で作成されたファイルを取得し、SharePoint でこのファイルをサイトに書き込みます。このコマンドは優れた柔軟性を備えています。サイトを元の場所に復元したり (サイトを誤って削除した場合など)、同じ仮想サーバー上の別のサイトとして復元したり (データが破壊されるリスクを負うことなくサイトのプロセスをテストする場合など)、サイトを全く異なるサーバーや仮想サーバーに復元することができます。
別のサイトまたはサーバーに復元する方法は、個々のドキュメントを復元するよりも若干簡単です。サイトがバックアップ済みで、ユーザーが復元されたドキュメントを必要としている場合は、サイト全体を復元する必要はありません。サイト全体を復元すると、バックアップが保存されているため、サイトに対するすべての変更が失われます。代わりに、サイトを別の URL に復元し、ドキュメントを取り出して、それらを元のサイトに保存することができます。
Windows SharePoint Services 2.0 では、STSADM に 1 つの非常に重要な制限があります。それは、バックアップ時に処理できるのはサイトのみで、Web は処理できないという制限です。この点について管理者から不満があがったため、マイクロソフトはその声に応えました。Windows SharePoint Services 3.0 では、backup および restore 操作で web を処理できるようになりました。また、import と export の 2 つの新しいコマンドも追加されています。
Web をエクスポートするには、次の簡単なコマンドを使用します。
Stsadm -o export -url http://localhost/web -filename backup.dat
export には、-versions スイッチを含む便利なオプションがあります。これにより、バックアップ ファイルの大きさを、バックアップするファイル バージョンを制限することで決定できます。
Web をサーバーにインポートして戻すには、次のコマンドを使用します。
Stsadm -o import -url http://localhost/web2 -filename backup.dat
サイトが大きい場合は、バックアップ ファイルが複数になる場合があります。この場合は、STSADM -o import を最初のファイルにポイントして、後続のファイルが自動的に取得されるようにします。

高度な操作
STSADM に慣れてきたところで、難しい状況に対応できる 1 組の操作を紹介します。1 つ目は、新しく追加された migrateuser という名前の操作です。バージョン 2.0 は、自身を Active Directory と同期しません。アカウントの名前が変更された場合、SharePoint にはログインできなくなります。以前は、1 人のドメイン ユーザーから別のドメイン ユーザーへ、ユーザーのアクセス権を移行することはできませんでした。Windows SharePoint Services 2.0 Service Pack 2 (SP2) 以前は、ユーザーをすべての Web から削除し、手動で新しいアカウントを追加する必要がありました。
SP2 には新しい API が導入され、STSADM はその API を活用しています。jsmith というアカウントの名前が jjones に変更された場合は、次のコマンドを使用します。
Stsadm -o migrateuser -oldlogin domain\jsmith -newlogin domain\jjones -ignoresidhistory
実際にはアカウントを移行していないため、Windows セキュリティ ID (SID) の履歴は無視できます。このコマンドでは、URL が不要です。このコマンドは、サイトまたは Web に関係なく、コンテンツ データベース全体を変更します。
もう 1 つの有用な操作は unextendvs です。SharePoint で仮想サーバーや Web アプリケーションを表示しない場合は、それを拡張解除します。通常、これは SharePoint Configuration Analyzer から行います。ただし、Web ファームでは、SharePoint Configuration Analyzer を実行する場合、サーバーにすべて同じ修正プログラムが適用されている必要があります。サーバーがファームの残りのサーバーと同期しなくなる可能性があるため、SharePoint Configuration Analyzer では拡張解除オプションは使用されません。STSADM を使用すると、次のコマンドで仮想サーバーを拡張解除できます。
Stsadm -o unextendvs -url http://localhost
サーバーが Web ファーム内に存在しなくなったら、必要なメンテナンスを実行できます。
Web ファームについては、管理を容易にするため、すべてのサーバーで SharePoint Configuration Analyzer を同じポートに置く場合があります。SharePoint がインストールされるときにポートはランダムに生成されますが、STSADM にはそのポートを指定したポートに変更できる次の操作が含まれています。
Stsadm -o setadminport -port 1026
これによって、必要なすべてのデータベースが変更され、IIS が変更され、管理ツールの SharePoint Configuration Analyazer へのショートカットが調整されます。

まとめ
Windows SharePoint Services は優れたソリューションであり、強力な管理機能を必要とします。STSADM は、構成および一般的な日常のタスクの自動化を含め、SharePoint の管理を実現するための 1 つの手段を提供します。実際、STSADM がジョブを実行する唯一の方法である場合もあります。

Todd KlindtUGS のシステム アナリストです。彼は、1 日中 ShwarePoint に興じ、それで報酬を得ています。彼は、Windows SharePoint Services MVP でもあり、また水瓶座でもあります。


 SharePoint: 作業上での Wiki の使用
SharePoint Mauro Cardarelli

作業上での Wiki の使用
概要:
  • Wiki とは
  • SharePoint での Wiki の構築
  • 変更の編集と追跡

Wiki の概念が誕生してから 10 年以上経ちます。Wiki (「早い」という意味のハワイ語) は、ユーザーが Web ページのコンテンツをごく単純な形式で自由に作成したり編集したりできるオンラインの場所で、
使用するのはブラウザのみです。その目的は、仮想コミュニティのメンバが、コンテンツ (他の作成者によるコンテンツも含む) を組み込んだり、変更、削除したりして、ページを完全に自由に編集できる場所を提供することです。構造化された知識交換と一対多の通信を目的として設計されたブログとは違って、Wiki では複数のユーザーが共同で作業を行うことができます。
最近では、Web 2.0 という次世代のオンライン ツールが注目されています。Web 2.0 は、コンテンツ作成の障壁を低くして、ユーザーがオンライン情報を作成したり使用したりできるようにすることが前提です。この現象は、インターネットの世界だけでなく、会社のファイアウォール内でも起きています。これを Enterprise 2.0 と考えてください。Enterprise 2.0 は、従業員全員がコンテンツを簡単に作成できるようにするツールです。ブログや Wiki のようなテクノロジによって、今後の会社の知的資産についての考え方、保管方法、および再利用方法が変わっていくでしょう。
マイクロソフトは、普及している SharePoint テクノロジの 3 つ目のバージョンである Microsoft® Office SharePoint® Server (MOSS) 2007 の導入により、この次世代の機能を促進します。MOSS 2007 では、ブログや Wiki の作成のサポートなど、コラボレーションと通信の機能が拡張されています。この記事では、MOSS 2007 で Wiki の構築を開始する方法について説明します。

はじめに
SharePoint Portal Server 2003 を使用したことがあれば、サイト テンプレートの使い方はよくご存じでしょう。サイト テンプレートは、特定のページ タイプ (チーム会議や社交行事など) のレイアウトに使用できるフレームワークを提供します。サイト テンプレートによって、特定のコンテンツのプレースホルダが事前に設定されます。MOSS 2007 では、テンプレート タイプの新しいコレクションが導入されており、サイト テンプレートの用途が広がります。その 1 つは Wiki 用のテンプレートです。
図 1 に、SharePoint サイトの作成に使用される [新しい SharePoint サイト] ページを示します。テンプレート リストに Wiki サイト用の項目があることに注目してください。このテンプレートを選択すると、最初の Wiki をすばやく簡単に作成できます。図 2 を見てください。これは、新しく作成された Wiki の既定のレンダリングです。Wiki の構造では、この既定のページがユーザーのホーム ページになります。このページのすべてのコンテンツが編集可能です。適切な権限が与えられたユーザー (仮想コミュニティ) は、このページを変更したり新しいページを作成したりできます。
図 1 新しいサイト用の Wiki テンプレートの選択
図 1 新しいサイト用の Wiki テンプレートの選択
図 2 編集可能な状態の新しい SharePoint Wiki
図 2 編集可能な状態の新しい SharePoint Wiki (画像を縮小するには、ここをクリックします)
図 2 編集可能な状態の新しい SharePoint Wiki
図 2 編集可能な状態の新しい SharePoint Wiki (画像を拡大するには、ここをクリックします)
先に進む前に、一歩戻って、Wiki をユーザーに対して導入することについて話しましょう。前に説明したように、Wiki はインターネット上で、場合によってはサードパーティ製のツールを介して使用されてきました。ただし、多くの場合、Wiki の使用は専門性が高く、口コミでゆっくり広まっています。MOSS 2007 では、すべてのイントラネット ユーザーに Wiki 機能を提供することにより、この状況を変えようとしています。これは非常に効果的な (おそろしくもある) 提案です。Wiki の価値を、技術者以外のインターネットに詳しくない同僚にどのように説明しますか? Wiki の目的が、すべてのユーザーが自由に発言できる環境で独創的な意見交換を促すことである、ということを説明する必要があります。Wiki によりコンテンツ コラボレーションが可能になりますが、実際にはそれ以上の効果があります。Wiki の最終的な成果は個々のドキュメントやチャプタではなく、まとまった本のようなものです。そしてこの本は決して完成させる必要はなく、必要なときにいつでも変更できます。
それでは、本題に戻りましょう、Wiki を初めて使用する方は、[この Wiki サイトの使用方法] ハイパーリンクからオンライン ガイドラインにアクセスできます。既定の Wiki テンプレートには、新しいユーザーがすぐに慣れて参加するために十分なドキュメントが用意されています。

Wiki の動作
すべての Wiki ページの右上に、アクション ボタンがあります。[編集] ボタンをクリックすると、コンテンツの編集用のページが表示されます。図 3 に例を示します。編集はすべてブラウザ内で行います。Microsoft Word のような外部ツールを使用する必要はありません。また、編集内容は、保存するとオンラインでリアルタイムに反映されます。さらに、Web デザインや開発のスキルも必要ありません。編集インターフェイスでは、標準のボタンを使用して、太字、色、箇条書き、イメージなどを含む完全なリッチ テキストを作成できます。ユーザーは、既存のページを編集モードで開いて、コンテンツを追加または変更するだけです。これだけです。
図 3 ブラウザ内での Wiki コンテンツの全体的な編集
図 3 ブラウザ内での Wiki コンテンツの全体的な編集 (画像を縮小するには、ここをクリックします)
図 3 ブラウザ内での Wiki コンテンツの全体的な編集
図 3 ブラウザ内での Wiki コンテンツの全体的な編集 (画像を拡大するには、ここをクリックします)
コンテンツが常に変わる環境では、変更をどのように管理しますか? すべての作業内容を管理する必要があるとは限りませんが、変更を追跡してバージョン履歴を保持する何らかの手段が必要になるでしょう。MOSS 2007 がその役割を果たします。[履歴] ボタンをクリックしたときに表示される標準ページを図 4 に示します。ページの中央で、テキストに対するすべての編集内容が追跡されていることがわかります。左側では、変更が行われるたびに追跡された変更の履歴を確認できます。コミュニティには、変更を確認、追跡、およびロールバックする十分な権限が与えられます。これは強力な概念です。Wiki を構築したり変更したりすると、MOSS 2007 によってその動作が追跡されます。
図 4 時間経過に伴う Wiki エントリの変更の追跡
図 4 時間経過に伴う Wiki エントリの変更の追跡 (画像を縮小するには、ここをクリックします)
図 4 時間経過に伴う Wiki エントリの変更の追跡
図 4 時間経過に伴う Wiki エントリの変更の追跡 (画像を拡大するには、ここをクリックします)
このように、Wiki は Web ページではありません。無制限のページの集まりです。Wiki コミュニティのメンバとして、ユーザーが自分で、新しいアイデアや論点を取り入れることができます。テキストを既存のページに追加するのではなく、新しいページに追加できます。MOSS 2007 では、Wiki ページを簡単に追加できます。[新規] をクリックするだけで、新しい Wiki ページが作成されます。コンテンツの追加を開始してください。まだ先があります。

まとめ
MOSS 2007 で Wiki の概念を取り入れていない場合がありますが、その幅広い可用性により、Wiki は注目されるようになっています。Wiki を使用すると、組織の従業員による共同作業の方法を変えることができます。ドキュメントの制限に縛られなくなります。Wiki は形にとらわれない考察や幅広いコラボレーションを促進します。これは Enterprise 2.0 の哲学に関連するさまざまな概念にうまく溶け込みます。Wiki はイネーブラです。つまり、すべてのユーザーが参加して、ただ後に続くだけでなく、新しい方向に進めるようにします。

Mauro Cardarelliボストンに拠点を置く IT コンサルティング サービス会社である Jornata 社の業務執行役員です。彼の任務は、テクノロジの普及、アーキテクチャのデザイン、ソフトウェアの開発などです。彼の連絡先は、 mauro.cardarelli@jornata.com (英語) です。


 編集者から: ときに業界は
編集者から

ときに業界は 地震のように変動します。これは、テクノロジだけでなく、政治、ファッションなど、あらゆるものに当てはまることです。私は、2、3 週間前、ラスベガスの Windows Connection 会議で話をしたときに、このことを考えていました。5 年前の 11 月、私は Comdex に参加する予定でした。Comdex は世界のあらゆる部門のテクノロジのバイヤーや学習者が集まる巨大なショーです。しかし、約 20 年間着実に規模を拡大してきたこのショーは、ほとんど一夜で終了しました。そのため、私はこの巨大な、広範囲に焦点を置くショーに参加する代わりに、特定の地域向けに放送され、大成功を収めているショーで、数人の開発者といくつかの IT 製品に重点を置いた話をしました。私の話は同じ地域内の同じ人々にしか届きませんでしたが、その規模の方が参加全員にとって有意義でした。
私の話は、すべてテクニカル ライティングに関すること、つまり、どこで、どのように、なぜ書くのか、という内容でした。私たちの業界の変動は、Comdex の歴史だけでなく、技術通信の世界にも反映されています。5 年前、私は同様のセッションを開催しました。その内容はすべてマガジンに関することでした。その当時は、ほとんどの人がブログのことを聞いたことがありませんでした。コミュニティ サイトは、現在のもののきざしがわずかにある程度でした。この 5 年間、書き言葉の送信方法がこれまでにない規模で変化しています。
もちろん、これは良くもあり悪くもあることです。通信形式が異なれば目的も異なります。ユーザーは自分の考えをオンラインで自発的に書き込むことができますが、マガジンにそれらの考えを載せることは、通常、言葉を編集して技術的に検証することを意味します。ブログの投稿は削除できますが、だれかの家に行って、28 ページのセクションを切り取ってほしいなどと頼むことはできません。
とにかく、私がこの変化について話すのには理由があります。マガジンについてフィードバックを送っていただいた多数の読者の皆様に応えて、私たちはコラムのラインアップを拡充しています。今回は、現在印刷版になっている TechNet オンラインの人気のあるコラム、「The Cable Guy」の初回の記事を紹介します。ポストマスタからもご連絡をいただき、Exchange Server 2007 のことが大きく取り上げられそうであることを知りました。そのため、定期的なコラムとして Exchange Queue & A を始めました (ちょっと待ってください。何て気の利いた名前でしょう)。
マガジンで取り上げられているマイクロソフト テクノロジについて知りたい場合は、お知らせください。私たちが皆さんのお役に立つには、皆さんが必要としているものを提供することが最善の方法です。£Joshua Trupin

次のマイクロソフト技術支援スタッフに心より感謝します。Puneet Arora、Jeff Bienvenu、Nino Bilic、Eric Broberg、Ramesh Chinta、Matt Cohen、Michael Dalton、George Irimescu、Bryan Jeffries、Dave Kong、Vijay Krishna、Rob Lefferts、Lawrence Liu、Bob Ma、Manu Namboodiri、Joel Oleson、Arpan Shah、Troy Starr、James Sturms、Jim Truher、Blaine Young。


 ツールボックス: IT プロのための新製品
ツールボックス
IT プロのための新製品
Greg Steen

サーバー管理
Windows Server 2003 リソース キット ツール
go.microsoft.com/fwlink/?LinkId=77796 (英語)
Microsoft Windows Server 2003 リソース キット ツールは、管理タスクを効率化し、自動化するために役立つ 100 種類以上のユーティリティを集めたツール セットです。ネットワークのトラブルシューティングを行うための Active Directory® ツールから、CD/DVD 画像書き込みソフトウェアまで、多様なツールが収録されています。
Custom Reason Editor (custreasonedit.exe) はシャットダウン イベントの追跡ツールを整理するうえでたいへん便利です。Windows Server® 2003 の 1 コンポーネント、シャットダウン イベントの追跡ツールはシステムがシャットダウンした理由をイベント ログに記録します。一方、Custom Reason Editor ツールでは構成可能なパラメータを含む、独自に記述可能な一覧を作成できます。この一覧で指定されるパラメータは、既定で有効になっている事前定義された理由を上書きします。このツールを使用すると、イベント アイテムを論理的に整理できることから、問題が発生しているプロセス、アプリケーション、またはシステムの状態を収集および特定しやすくなります。
DNS Resolver Tool は DNS 解決のために SMTP サービスの実行をシミュレーションするコマンドライン ユーティリティで、コマンド パラメータとして指定する DNS クエリの状態に応じて、メッセージを表示します。このユーティリティは SMTP サービスがインストールされているすべての Windows Server 2003 ホストで実行可能で、バッチ ファイルで使用できるエラー コードを返します。CDBurn.exe と DVDburn.exe は ISO イメージから CD と DVD を作成できるコマンド ライン ユーティリティです。新しいディスク イメージを書き込む前にメディアを消去する /Erase スイッチ付きの RW メディアも制限付きでサポートします。たとえば、インフラストラクチャのアーカイブ プロセスを自動化するために使用できます。
Windows Server 2003 Resource Kit
Windows Server 2003 Resource Kit (画像を縮小するには、ここをクリックします)
Windows Server 2003 Resource Kit
Windows Server 2003 Resource Kit (画像を拡大するには、ここをクリックします)
アカウントが正常にロックアウトされているかを確認する必要がある場合、Account Lockout Status ツールを使用すると、コマンド ライン、GUI オプションを問わず、簡単にすばやく確認できます。ツールは到達可能なすべてのドメイン コントローラに対してクエリを実行し、ターゲット ユーザーのアカウントの状況を確認します。自動化ツールの決定版とも言える、Robust File Copy Utility (Robocopy.exe) では、ファイルの移動とコピーに多様なオプションを提供します。このツールではコピーの対象を指定する際に、ワイルドカード文字だけでなく、ファイル属性も使用できます。また再帰的なコピーも指定できます。同期用のツールも使用可能で、ソース ディレクトリから削除されたファイルやディレクトリを、対象となるディレクトリから削除するよう設定することも可能です。
もう 1 つご紹介したいユーティリティは Tail (tail.exe) です。このシンプルなツールは、Linux/UNIX ユーティリティのように、ファイルの最後から N 行を表示できます。ファイルに新しい行が追加されれば、表示内容も更新されます。これはログ ファイルに書き込まれるタスクをデバッグ、またはモニタする際にたいへん便利です。
Time It (timeit.exe) は時間を計測し、そのデータを独自のデータベース ファイルに保存します。ユーザーは管理タスクに実際にかかる時間をテストする場合に活用できます。
これらのツールはローカライズされておらず、英語のみで記述され、テストされています。また、実行時には "予期しない結果を起こす" 可能性もあります。これらのユーティリティのいずれかを運用環境で使用する前に、必ず、英語以外のシステムでテストしてください。
価格: 無償ダウンロード。

問題の追跡
ASP.NET Issue Tracker
www.ASP.NET/StarterKits/WhitePapers/Issue%20Tracker%20Whitepaper.htm (英語)
自分にとって、それだけでアプリケーションの価値が上がるポイントが 2 つあります。「無償」であること、そして「カスタマイズ可能」であることです。ASP.NET Issue Tracker は ASP.NET オンライン開発者コミュニティから入手可能で、次の 2 つの働きがあります。ASP.NET 1.1 framework の下で Web アプリケーションのプログラム方法を学習するためのスタート キットとして設計された Issue Tracker は、単純ながら、プロジェクトに関連する問題点の追跡に有用なツールです。
インターフェイスは直感的で、プロジェクト、ユーザー、問題点を簡単に作成できます。アプリケーションはロール ベースの権限を併用して複数のユーザーをサポートするため、問題へのアクセスを制限できます。また、プロジェクトごとに独自の問題点のカテゴリとさまざまな種類のデータ フィールドも作成できます。タスクには、状態や優先度、そしてマイルストーンを割り当てることができ、プロジェクトの整理に役立ちます。
もう 1 つのお薦めは、プロジェクトの作成時、プロジェクトごとに独自の状態コード、プロパティ、マイルストーンを指定でき、それらを表す画像を使用できる点です。すべてのコードはダウンロード可能です。.NET の開発ツールをお持ちの場合、または既存のコードを介して作業が可能であれば、必要になるカスタム機能のベースとして、スタート キットを使用できます。
価格: 無償。

システムの監視
NetHealth Sentinel Professional
www.nethealthsys.com (英語)
ネットワークとシステムの監視は非常に重要です。コンピュータの状態を離れた場所から確認できるアプリケーションには常にアンテナを張っています。NetHealth Sentinel Professional は NetHealth Systems 社が提供するまさにリモート管理のためのアプリケーションです。
Sentinel Professional はエージェントベースのソリューションで、監視対象のコンピュータの状況を見極めることができます。アプリケーションは、Admin Server、Admin Console、Connection Manager、Remote Agent の 4 つのコンポーネントに分かれます。Admin Server はスケジュールされたタスクを実行するほか、構成情報の格納、Connection Manager を介した警告の収集を行います。
Admin Console は Admin Server へのグラフィカル インターフェイスで、監視対象のシステムを表示、構成すると共に、スケジュールされたタスク、またはイベントの設定もこなします。Connection Manager は、Remote Agents (監視対象のシステムに常駐するホスト エージェント) からすべてのデータを収集します。Remove Agent は、Windows サービスとして実行され、セキュリティで保護された接続を通じて、Connection Manager と安全に通信します。Remote Agent ごとに 1 つ以上の Connection Manager に警告を送信するよう構成できます。
NetHealth Sentinel Professional
NetHealth Sentinel Professional (画像を縮小するには、ここをクリックします)
NetHealth Sentinel Professional
NetHealth Sentinel Professional (画像を拡大するには、ここをクリックします)
指定した監視グループに属すすべてのコンピュータのイベントを集約する機能も優れています。使いやすい GUI で、イベント ビューのデータ列をアイテム別のグループにドラッグ アンド ドロップすることもできます。
このアプリケーションの Vital Signs パネルでは、監視しようとしている統計の概要を迅速に取得できます。既定では CPU、ディスク、メモリ使用状況を参照できますが、Monitor タブに必要なカウンタを追加することもできます。
NetHealth Sentinel Professional にはコンピュータの "通常" 運用状態にレベルを設定できる基準設定機能があり、運用中、設定された基準値を超えた場合に警告をトリガします。
価格: $495 (10 クライアント アクセス ライセンス パック)。

データの暗号化
TrueCrypt
www.truecrypt.org (英語)
TrueCrypt Foundation 社の TrueCrypt は無償、オープンソースの "オンザフライ" 方式の暗号化ツールです。このツールは正しいパスワードと暗号化キーを使用し、暗号化されたボリュームからデータを読み取る場合はその暗号化解除を、暗号化ボリュームのメモリに書き込む場合はそのデータの暗号化を行います。特にお薦めしたいのは、どの段階でもボリュームが暗号化解除された状態にならないという点です。アプリケーションがメモリに含まれるデータの暗号化解除中に、メモリ ダンプを作成する場合を除き、保護しようとしている情報が攻撃者の目にふれることはありません。このような状態はシステムのメモリ ダンプ機能をオフにするだけで容易に回避でき、わずか一瞬でも、少量のデータが暗号化解除された状態でメモリ上に存在することにはありません。
このアプリケーションは仮想ボリュームと物理パーティションまたはデバイスのいずれもサポートします。 仮想ボリューム、別名 "作成者のファイル置き場" では任意のファイル拡張子を使用でき、また、拡張子を一切使用しないようにすることもできます。拡張子がなければ、万一攻撃者が機密データを覗こうとしても、ランダムなデータの羅列にしか見えません。TrueCrypt "ファイル署名" は存在しないのです。
TrueCrypt
TrueCrypt (画像を縮小するには、ここをクリックします)
TrueCrypt
TrueCrypt (画像を拡大するには、ここをクリックします)
また、TrueCrypt は "トラベラー モード" で実行できます。これは、アプリケーション ファイルと共に USB キー上にファイル コンテナを作成できることを意味し、ホスト システムに TrueCrypt をインストールする必要なく、どこにでも暗号化されたデータを持ち運ぶことができます。しかし、メモリ経由で読み取り/書き込みを行う性質上、トラベラー ディスクを使用するシステムの管理者権限が必要になります。
また、TrueCrypt にはトラベラー ディスクを設定するためのウィザードが用意されています。これはシステム管理者情報を持ち運ぶにはたいへん便利な方法で、慎重を期する社内データの取り扱いが容易になります。
また、一段上のセキュリティを施すために、TrueCrypt にはファイルコンテナ内に隠しボリュームを作成できる機能もあり、たとえ侵入者が外部のボリュームにマウントできたとしても、ディスク上にある隠された内部ボリュームを発見することはできません。各ボリュームはランダム データで初期化されるため、外部ボリュームにある隠しボリュームを、簡単には発見できない "空き領域" のように見せかけることができます。
TrueCrypt は AES、Blowfish、CAST5、Serpent、Triple DES、Twofish、およびこれらのアルゴリズムの組み合わせを使用して、データを暗号化できます。このアプリケーションは暗号化操作に LRW モードを使用します。LRW モードはセクタベース ストレージ用の暗号化で、IEEE 標準になっています。ヘッダー ハッシュ アルゴリズムの場合、Whirlpool、SHA-1、または RIPEME-160 を選択して使用でき、さらに保護を強化するため、アプリケーションによってハッシュがシステム上に保存されることはありません。アプリケーションは FAT12、FAT16、FAT32、NTFS の各種ファイル システムをサポートします。ただし、市場に出回っている他の Windows ベースのセクタ暗号化ユーティリティと同じように、Windows ブート パーティションを暗号化することはできません。
価格: 無償。

ブック レビュー
Hacking Web Services
www.charlesriver.com (英語)
Shreeraj Shah 著の『Hacking Web Services』 (Charles River Media、2006) には Web サービスの開発、展開、サポートに関連する有益なリソースが掲載されています。この書籍は Web サービスとコンポーネント テクノロジの一般的なセキュリティ リファレンスとして、たいへん分かりやすくまとめられています。また、インフラストラクチャや開発現場の保護に関係する技術を詳述している点で非常に優れています。
この書籍は Web サービスについて、比較的掘り下げた内容から入ります。"The Consequences of Procrastination (先送りの影響)" と題されたケース スタディでは、セキュリティ プロシージャで先手を打つ利点と、反応システムの不利益について解説されています。"Web Services Scanning and Enumeration (Web サービスのスキャンと列挙型)" では、Web サービスのプロファイルおよびフットプリント Web サービスに対する、wsChess、Net-Square (net-square.com/wschess/index.shtml) の .NET ベースの Web サービス セキュリティ ツールキットの使用方法を取り上げています。
この本にはユーティリティ CD が付属し、SOAPWall と呼ばれる .NET ベースのサンプル アプリケーションが含まれています。このアプリケーションでは、.NET Web サービスで注入文字やバッファのオーバーフローを防ぐ方法を参照することができます。また、CD にはさまざまな種類の Web サービス攻撃のデモも収録されています。
価格: $49.95。
Shreeraj Shah 著の『Hacking Web Services』 (Charles River Media、2006) には Web サービスの開発、展開、サポートに関連する有益なリソースが掲載されています。この書籍は Web サービスとコンポーネント テクノロジの一般的なセキュリティ リファレンスとして、たいへん分かりやすくまとめられています。また、インフラストラクチャや開発現場の保護に関係する技術を詳述している点で非常に優れています。
この書籍は Web サービスについて、比較的掘り下げた内容から入ります。"The Consequences of Procrastination (先送りの影響)" と題されたケース スタディでは、セキュリティ プロシージャで先手を打つ利点と、反応システムの不利益について解説されています。"Web Services Scanning and Enumeration (Web サービスのスキャンと列挙型)" では、Web サービスのプロファイルおよびフットプリント Web サービスに対する、wsChess、Net-Square (net-square.com/wschess/index.shtml) の .NET ベースの Web サービス セキュリティ ツールキットの使用方法を取り上げています。
この本にはユーティリティ CD が付属し、SOAPWall と呼ばれる .NET ベースのサンプル アプリケーションが含まれています。このアプリケーションでは、.NET Web サービスで注入文字やバッファのオーバーフローを防ぐ方法を参照することができます。また、CD にはさまざまな種類の Web サービス攻撃のデモも収録されています。
価格: $49.95。

ツールボックスにご意見、ご要望をお送りください。
ここで取り上げてほしいお薦めのツールやユーティリティがございましたら作者 tntools@microsoft.com まで英語でご連絡ください。

このコラムに掲載されている内容は作者独自の意見に基づくもので、必ずしもマイクロソフトの意見を反映しているものではありません。すべての価格は発表時のもので、変動する可能性があります。

Greg Steen技術者、起業家、熱狂的 IT ファン。より簡単な操作、開発に役立つ IT プロフェッショナルのためのツールとメソッドを日夜追い求めています。


 ユーティリティ スポットライト: Internet Explorer 管理者キット
ユーティリティ スポットライト
Internet Explorer 管理者キット
Lance Whitney
この記事で使用しているコードのダウンロード: ユーティリティ スポットライト: Internet Explorer 管理者キット 7 (KB)

CIO から組織全体に Internet Explorer 7 の最新バージョンをインストールするように命じられました。期日も予算も厳しい一方で、要件は多数あります。すべてのユーザーに同じ機能と設定を適用するカスタマイズ パッケージが必要です。また、必要に応じて適用した設定を変更できる必要があります。
さらに、Internet Explorer® を制限し、ユーザー側では設定を変更できないようにする必要もあります。このような Internet Explorer のインストールを迅速かつ簡単に作成し、供給するには、どうすればよいでしょうか。
マイクロソフトでは、Internet Explorer 管理者キット (IEAK) を用意しています。この無償構成ツールは Internet Explorer のカスタマイズされたインストール パッケージを作成する IT 管理者、開発者、ISP、および他のユーザーの支援を目的として作成されました。Yahoo! では実際に IEAK 7 のベータ バージョンを使用して、Yahoo! Web サイトからのダウンロード用にカスタマイズされた Internet Explorer 7 のパッケージを作成しました。
IEAK を使用して作成される Internet Explorer 7 のビルドには、ユーザーが指定する機能とオプション以外は含まれません。個別のセキュリティ設定を使用して、各種コントロールへのユーザー アクセスを制限できます。
Internet Explorer の展開後、Active Directory® を導入している環境であれば、グループ ポリシーを使用してブラウザの設定を制御、および更新することもできます。あるいは、必要に応じて、IEAK を使用し多様な Internet Explorer の設定を管理することもできます。
IEAK 7 は Internet Explorer のパッケージを作成するためのシンプルなグラフィカル インターフェイスを備え、旧バージョンよりさらにユーザー フレンドリーな仕様になっています。ユーザーは、ステップごとの画面に従い、ビルドに組み込む機能やオプションを選択します。
IEAK の新規リリースでは旧バージョンへの変更に加え、一部のオプションが追加、または削除されています。このバージョンより、Internet Explorer のビルドに既定の RSS Web フィードを追加したり、1 つ以上のホーム ページ、検索ページをポイントしたりできるようになりました。また、フィッシング対策フィルタのサポートも追加できます。さらに、Microsoft® Windows® 悪意のあるソフトウェアの削除ツールを実行、更新するように設定することもできます。ただし、Outlook® Express および Windows Media® Player は、Internet Explorer 7 に同梱されなくなったため、IEAK ではカスタマイズできません。
32 ビットまたは 64 ビット プラットフォームの Windows XP Service Pack 2 (SP2)、Windows Server® 2003 SP1、または x86 ベース、x64 ベース、あるいは Itanium ベースの Windows Vista™ 用の Internet Explorer パッケージを作成できます。IEAK 7 を実行するには、あらかじめ、パッケージを作成するコンピュータに Internet Explorer 7 をインストールしておく必要があります。互換性の観点から、ビルドを適用するコンピュータと同じ OS がインストールされているコンピュータで IEAK を実行してください。
このコラムでは Internet Explorer 7 インストール ビルドを作成するための IEAK の使用方法と、ブラウザの設定を管理、または更新する方法について解説します。

IEAK 7 の入手方法
http://www.microsoft.com/technet/prodtechnol/ie/ieak/ja/default.mspx から最新バージョンの IEAK 7 を無償でダウンロードできます。また、このページでは IEAK に関する文書、リリース ノートも入手できます。
ダウンロードした ieak.msi ファイルを使用して IEAK 7 をインストールすると、[ISP として外部配布]、[コンテンツ プロバイダまたは開発者として外部配布]、[企業イントラネットを介した内部配布]の、どのライセンス モードを使用するかを確認する画面が表示されます。その後に続く画面とビルドされるパッケージは、この画面で選択するモードによって異なります。ビジネス環境向けのビルドを作成する場合は、[企業イントラネットを介した内部配布] のライセンス モードを選択してください。IEAK がインストールされると、[スタート] メニューに「Microsoft IEAK 7」というプログラム グループが作成され、その中には [IEAK ヘルプ]、[IEAK プロファイル マネージャ]、[Internet Explorer カスタマイズ ウィザード] の 3 つの項目が含まれています。
インストール パッケージをビルドする場合は、[Internet Explorer カスタマイズ ウィザード] を使用します。使用方法は簡単で、ウィザードの各画面に従って操作するだけでパッケージのデザインを進められます。もう少し具体的に説明します。各オプションの構成方法を知るには、Internet Explorer の各種機能とコントロールを十分に理解している必要があります。さいわいなことに、EAK 7 ではこの点も考慮されています。ツールの組み込みヘルプは旧バージョンに比べ、さらに詳しく、分かりやすくなりました。カスタマイズ ウィザードの各画面に表示される [ヘルプ] ボタンから、画面の設定やオプションなどの情報にアクセスできます。IEAK のヘルプ ファイルにアクセスするには [IEAK ヘルプ] をクリックするか、「C:\Program Files\Microsoft IEAK 7」の「IEAKHelp.chm」をダブルクリックします。各コンポーネントを理解し、必要なオプションを計画するために、ビルドを作成する前にこのドキュメントを参照することをお勧めします。
カスタマイズ ウィザードでは次の 5 段階でパッケージの作成を実行します。
  1. 情報の収集
  2. セットアップ パラメータのカスタマイズ
  3. インストール方法のカスタマイズ
  4. ブラウザのカスタマイズ
  5. 追加のカスタマイズ
IEAK 7 では数々の画面が能率化され、プロセスは旧バージョンに比べ操作しやすくなっています。操作性は向上していますが、カスタマイズ ウィザードではパッケージのオプションを選択するため、多数の画面を操作する必要があります。画面の多くには個別の説明が付与されていますし、より込み入った内容については前述のヘルプを参照していただくこととして、このコラムではすべての画面を取り上げることは割愛します。その代わりとして、各段階で実行する操作を要約し、一部の特に重要な画面について解説します。
段階 1 情報の収集: ここではインストール パッケージの配置場所、ビルドを実行する OS およびプラットフォーム、Internet Explorer の配布方法、カスタマイズするオプションなどを決定します。この段階では Internet Explorer 7 の配布方法を、図 1 に示す 3 つの方法から選択できます。1) ファイル インストール。この方法ではビルドに含まれるファイルが均一なディレクトリ構造で配置されます。2) CD-ROM。この方法ではインストール ディスクが作成されます (リモートのユーザーをサポートする場合は便利です)。3) 構成のみのパッケージ。この方法では既存の Internet Explorer 7 のインストールにカスタマイズした設定を適用できます。Windows Vista のように Internet Explorer 7 が既にインストールされ、カスタマイズした設定のみを適用する場合は、最後のオプションを使用します。
図 1 配布方法の指定
図 1 配布方法の指定 (画像を縮小するには、ここをクリックします)
図 1 配布方法の指定
図 1 配布方法の指定 (画像を拡大するには、ここをクリックします)
この段階ではビルドに使用する言語も指定できます。サポートする必要がある言語ごとに、ローカライズされたバージョンの Internet Explorer 7 を作成できます。
段階 2 セットアップ パラメータのカスタマイズ: ここではパッケージをビルドするために使用する Internet Explorer の最新のコンポーネントと更新プログラムをダウンロードします。
段階 3 インストール方法のカスタマイズ: この段階ではユーザーが実際に使用するインストール方法を選択します。インタラクティブ (インストール中にユーザー自身が操作を進め、選択します)、ハンドフリー (実行中のインストールは表示されますが、ユーザーは操作できません)、完全サイレント (インストールはバックグラウンドで実行され、ユーザーには表示されません) のいずれかを選択します。CD-ROM を作成する場合は、この段階で CD 用のスタート ページと他の要素を作成するよう求めるメッセージが表示されます。
段階 4 ブラウザのカスタマイズ: ここでは Internet Explorer の外観をカスタマイズします。ホーム ページ、サポート ページ、お気に入りの URL を設定し、プロキシの設定を構成します。また、ブラウザのプライバシーとセキュリティの設定を行います。この段階では自動構成ファイル、またはインターネット設定 (INS) ファイルの名前と場所も指定できます。これらのファイルはグループ ポリシーを使用しない場合に、ブラウザの設定を管理する場合に役立ちます。
INS ファイルは単純なテキスト ファイルで、一般的なブラウザのホーム ページやお気に入りの設定、セキュリティの各種オプション、プロキシ構成などの各種設定が含まれています。この INS ファイルは内部の Web サーバーに配置します。各コンピュータはこのファイルをポイントし、ブラウザの各種設定を取得します。後日、設定を変更する必要が発生したときは、単にこの INS ファイルを編集するだけで、変更は自動的に各コンピュータに反映されます。設定を更新、および適用する頻度は指定することができます。
また、この段階でプロキシ サーバーを設定することもできます。IP アドレスとポート番号を手動で入力する方法と、プロキシ情報を指定した JScript® (JS)、JavaScript (JVS)、または PAC (Proxy Auto-Configuration) ファイルを作成し、その名前を指定する方法のいずれかを選択します。IEAK ヘルプにはこれらのファイルの作成に使用できるコードの例が掲載されています。
また、Windows Vista を使用して、Windows Vista 用の Internet Explorer 7 パッケージを作成する場合は、保護モードを使用することもできます。参照元のコンピュータで Internet Explorer 7 を保護モードに変更し、設定を IEAK にインポートするだけです。
段階 5 追加のカスタマイズ: この段階では、ビルドに適用するユーザー ポリシーとセキュリティの制限を設定します。非表示の設定、またはユーザーが変更できないようにする設定については、個別に選択して制限できます。図 2 の [追加の設定] 画面には有効、または無効にできる各種コントロールが 5 つのカテゴリ別に表示されます。これらの画面の各種設定は Internet Explorer 7 に設けられた 5 種類のテンプレートから作成されています。この設定はウィザードの段階 2 で最新のブラウザ コンポーネントをダウンロードした後にインストールされたものです。グループ ポリシーを使用する場合は、この段階をバイパスできます。グループ ポリシーを使用しない場合は、5 種類のカテゴリに分類されたオプションを構成できます。これらのカテゴリは ADM テンプレートから直接取得されるため、各 ADM ファイルをテキスト エディタで編集し、カスタマイズした独自のコントロールを追加することも可能です。ADM ファイルは Windows の オペレーティング システムおよびプラットフォームごとに、「C:\Program Files\Microsoft IEAK 7\pol-icies」の下にある各サブディレクトリに配置されています。図 3 には、5 種類のカテゴリが簡単な解説と共に表示されます。
Figure 3 [追加の設定] 画面のカテゴリ (Close Figure 3)

カテゴリ | 説明
Control Management (コントロール マネージメント) | このカテゴリでは特定の ActiveX コントロールを有効、または無効にできます。このカテゴリの設定は Windows Vista には適用されません。適用されるのは Windows XP および Windows Server 2003 のみです。
Custom Settings (カスタム設定) | このカテゴリにはセキュリティの設定が表示されます。特定のコントロールやアクションをゾーン (インターネット、イントラネット、信頼済みサイト、制限付きサイト) ごとに有効、または無効にできます。
Corporate Settings (企業用の設定) | このカテゴリではブラウザ キャッシュのサイズとパラメータを設定できます。
Corporate Restrictions (企業の制限) | ここでは Internet Explorer の特定のコントロールおよび画面を制限できるので、ユーザーはそれらを参照できなくなります。これらの設定は Windows Vista には適用されません。適用されるのは Windows XP および Windows Server 2003 のみです。
Internet Settings (インターネットの設定) | このカテゴリではオートコンプリートのオプション、表示サイズのほか、Internet Explorer のインターネット オプションに表示される詳細設定を構成できます。
図 2 Internet Explorer の各種機能のカスタマイズ
図 2 Internet Explorer の各種機能のカスタマイズ (画像を縮小するには、ここをクリックします)
図 2 Internet Explorer の各種機能のカスタマイズ
図 2 Internet Explorer の各種機能のカスタマイズ (画像を拡大するには、ここをクリックします)

ビルドの確認
カスタマイズ ウィザードで各画面の設定操作を終えると、段階 1 で指定した場所、または既定の c:\builds にパッケージが作成されます。この際、IEAK は作成先ディレクトリ名にその日の日付を使用します。たとえば、2007 年 1 月 1 日であれば、ディレクトリ名は「01012007」になります。このディレクトリの下には「INS」の他に、選択した配布方法に応じて「FLAT」、「CD」、「BrndOnly」のサブディレクトリが作成されます。サブディレクトリの数は選択した配布方法の数により異なります。
「INS」ディレクトリはパッケージを作成する場合にカスタマイズした内容を保持するためのワークスペース、またはリポジトリの役割を果たします。このディレクトリには install.ins というテキスト ファイルが格納され、作成した設定内容がすべて含まれています。カスタマイズ ウィザードを再実行すると、前回の選択内容がこのファイルから自動的に読み込まれます。
「FLAT」、「CD」、「BrndOnly」の各ディレクトリには実際のインストール ファイルが格納されます。これら 3 種類のパスの下には、Windows XP や Windows Vista などの 32 ビット環境であれば、「Win32」のように、OS およびプラットフォーム別の名前が付いたサブディレクトリが作られます。最下位のサブディレクトリには、パッケージ用に使用した言語の名前が付きます。日本語を使用すると、このサブディレクトリの名前は「JA」になります。たとえば、2007 年 1 月 1 日に日本語で 32 ビット Windows 用に、「ファイル配布」を使用してビルドを作成すると、ビルドのディレクトリ パスは「c:\builds\01012007\FLAT\WIN32\JA」になります。
「ファイル配布」で作成したインストールは「FLAT」ディレクトリにあるサブディレクトリをさらに下へと移動し、言語名のサブディレクトリの下にある IE7Setup.exe ファイルになります。これは自己展開型の実行可能ファイルで、ビルドを作成するバイナリ ファイルと構成ファイルがすべて含まれます。Internet Explorer 7 パッケージを展開するために必要なのは、このファイルだけです (インストールには「INS」ディレクトリに含まれるファイルは不要です)。この 1 つのファイルを配布用サーバーにコピーし、パッケージをテストした後、各ユーザーにファイルを配布できるようになります。
配布方法として CD-ROM を選択した場合は、「CD」ディレクトリの内容をすべて CD にコピーする必要があります。このディレクトリには自動的に生成された「autorun.inf」ファイルのほか、CD から Internet Explorer をインストールするための実行可能ファイルを含むディレクトリが格納されています。
「構成のみのパッケージ」を使用した場合は、「BrndOnly」のディレクトリ構造を下へと移動し、言語のサブディレクトリにある「Setup.exe」が生成されたビルドになります。これは自己展開型の実行可能ファイルで、このファイルを配布用サーバーにコピーして展開できます。

設定の管理
Internet Explorer 7 パッケージには最初に必要になる機能と設定のすべてが含まれています。しかし、オプションを変更する必要がある場合はどうすればよいでしょう?方法は 2 つあります。Active Directory を使用する環境であれば、グループ ポリシーを通じて、ブラウザの設定を更新できます。Active Directory での更新が不可能な場合は、IEAK に含まれる「プロファイル マネージャ」というツールを使用して設定を変更できます。まず、グループ ポリシーを使用した更新方法について概説します。
グループ ポリシーを使用した場合: グループ ポリシーは、ブラウザ設定のすべてをサポートするため、Internet Explorer の管理に最も適した方法です。旧バージョンの IEAK と Internet Explorer を使用している場合は、グループ ポリシー コンソールに ADM ファイルと IEM (Internet Explorer Maintenance) ファイルを追加し、Internet Explorer 用のすべての設定を組み込む必要があります。ただし、Internet Explorer 7 の場合は、Windows XP SP2 および Windows Vista に、ブラウザを管理、更新するために必要なグループ ポリシーの設定がすべて含まれています。
グループ ポリシー エディタ (gpedit.msc) を開き、[管理用テンプレート]、[Windows コンポーネント]、[Internet Explorer] の順にクリックすると、Internet Explorer 7 に必要なすべての設定を参照できます。
IEAK プロファイル マネージャを使用した場合: IEAK プロファイル マネージャを使用して、Internet Explorer 7 用の設定を格納する自動構成または INS ファイルを作成します。プロファイル マネージャでは、最初に新しい INS ファイルをロードするか、作成するよう求めるメッセージが表示されます。カスタマイズ ウィザードで構成した内容と同じ設定で、新しい INS ファイルを最初から作ることができます。しかし、それでは同じ作業の繰り返しになります。パッケージを作成したとき、ブラウザ設定を格納するための既定の install.ins ファイルが IEAK により作成されました。プロファイル マネージャで INS ファイルを新たに作成する代わりに、install.ins ファイルを使用しましょう。このファイルをロードするには、ビルドのディレクトリにある INS のパスを参照します。たとえば、c:\builds\01012007\INS を参照します。ファイルに到達するまで、残りのサブディレクトリを展開します。
プロファイル マネージャの設定は 図 4 に示すように、2 つのセクションで構成されています。ウィザードの設定はホーム ページ、プロキシ設定、セキュリティ ゾーンなどの各種ブラウザ オプションが対象になります。これらはカスタマイズ ウィザードの 3 ～ 5 の段階に相当します。ポリシーと制限のセクションはユーザーの制限を制御するためのもので、カスタマイズ ウィザードの段階 5 のポリシーと制限で表示される 5 つのカテゴリに相当します。
図 4 プロファイル マネージャを使用した Internet Explorer の構成
図 4 プロファイル マネージャを使用した Internet Explorer の構成 (画像を縮小するには、ここをクリックします)
図 4 プロファイル マネージャを使用した Internet Explorer の構成
図 4 プロファイル マネージャを使用した Internet Explorer の構成 (画像を拡大するには、ここをクリックします)
パッケージを作成した時点でこれらの設定は既に定義したので、変更する必要はありません。変更は不要ですが、設定した内容が正しいことを確認する良い機会でもあります。
プロファイル マネージャで設定を確認した後、install.ins ファイルを適切な場所に保存し、内部の Web サーバーにコピーします。ファイルをコピーするためには、サーバーの汎用名前付け規則 (UNC) パスを入力する必要があります。これはカスタマイズ ウィザードの段階 4 の自動構成画面で指定したパスと同一です。さらに、図 5 で示すように、INS ファイルと共に CAB ファイルを保存するよう求めるメッセージが表示されます。なぜでしょう。プロファイル マネージャで Internet Explorer 7 の設定を変更する場合、IEAK ではご使用の Windows クライアントに、レジストリのエントリを頻繁にダウンロードする必要があります。これらのエントリは INF ファイルに格納され、CAB ファイルに保存されます。新たな変更により、INS ファイルのバージョン番号が変わると、ダウンロード用の新しい CAB ファイルが生成されます。この CAB ファイルは INS ファイルと同じ Web サーバーに格納してください。
図 5 自動構成ファイルの保存
図 5 自動構成ファイルの保存 (画像を縮小するには、ここをクリックします)
図 5 自動構成ファイルの保存
図 5 自動構成ファイルの保存 (画像を拡大するには、ここをクリックします)
INS ファイルと CAB ファイルの両方をコピーし、Web サーバーの別の場所に保存することをお勧めします。このコピーはバックアップとテストのいずれの役割も果たします。今後、プロファイル マネージャを使用して Internet Explorer の設定を変更する場合、テスト用の INS ファイルをロードして編集し、変更内容をテストした後で、稼動中の INS ファイルを変更することができます。
プロファイル マネージャを使用してブラウザの設定またはコントロールを変更することは簡単です。適切なカテゴリを選択するだけで、そのオプションを有効、または無効にすることができます。変更が完了した後、この INS ファイルを再度保存し、サーバーにコピーします。
INS ファイルは単純なテキスト ファイルであることから、次のような使い方も可能です。INS ファイルを開き、その設定内容を参照するためにメモ帳が使用できます。それでは INS ファイルをメモ帳で変更することはできるでしょうか。それも可能です。そして変更した内容は反映されます。ただし、プロファイル マネージャを使用して INS を変更する方法には、いくつかの利点があります。プロファイル マネージャでは、必要に応じて CAB ファイルが自動的に作成されます。さらに、INS が変更されるたびに、新しいバージョン番号と時間が付与されます。そのため、INS ファイルの変更にはプロファイル マネージャを使用してください。

まとめ
IEAK は Internet Explorer 7 のビルドを迅速に、効果的に作成およびカスタマイズするための有効なツールです。最新バージョンの IEAK 7 には、よりわかりやすい画面、さらに使いやすくなったヘルプなど、旧バージョンからの修正点が盛り込まれ、快適にインストール パッケージをデザインできるようになりました。IEAK を理解し、使用することで、信頼性のある Internet Explorer 7 のビルドをユーザーに配布できるようになり、同時に組織への貢献にもつながります。
Internet Explorer 7 の自動配布
マイクロソフトでは Internet Explorer 7 の最終バージョンのリリース後早い時期に、優先度の高い更新プログラムとして、自動更新、および Windows Update と Microsoft Update の各サイトから Internet Explorer 7 を配信する予定です。環境によっては、これが管理者にとって問題になる可能性があります。ユーザーにローカル管理者の権限を付与していない場合は、ユーザーはこの変更を受信しません。Microsoft Systems Management Server (SMS) または Windows Server Update Services (WSUS) を使用する環境でも、ユーザーが受信する更新は既に制御されています。ただし、ユーザーの一部またはすべてにローカル管理者権限が付与されていて、更新を管理するシステムが導入されていない場合は、Internet Explorer 7 の更新をブロックする必要がある場合があります。マイクロソフトでは Internet Explorer 7 Blocker Toolkit を作成しました。このツールキット (Microsoft ダウンロード センターで利用できます) にはグループ ポリシーのテンプレートと Internet Explorer 7 の更新が実行されないようにレジストリを設定するスクリプトの両方が含まれます。

Lance WhitneyIT コンサルタント、トレーナー、テクニカル ライター。Internet Explorer のバージョン 4.0 以降、インストール パッケージの作成とサポートを担当しています。元々はジャーナリストでしたが、15 年前、IT 業界への転向を実現しました。


 SQL に関する Q&amp;A: データ アーカイブ、リンク サーバー、帯域幅の測定など
SQL に関する Q&A
データ アーカイブ、リンク サーバー、帯域幅の測定など
Nancy Michell

データ アーカイブ
Q 私のグループで使用する完全なデータ アーカイブ方法が必要です。現在の方法は標準モデルに基づいており、データをバックアップしてから、履歴データを削除するユーティリティを実行しています。削除したデータを取得する必要がある場合は、環境とデータベースを復元します。
私は、段階的に実行できるアーカイブ ソリューションを探しています。第 1 段階では、データをデータベースから削除しますが、リアルタイムにデータにアクセスできるようにします。つまり、実稼働データベースのサイズを管理しやすいようにデータを削除しますが、エンド ユーザーはデータにまだアクセスできるようにします。第 2 段階で、データを完全に削除します。したがって、そのデータにアクセスするには復元が必要です。このような方法はありますか?
A 最も簡単な方法は、データベースのアーカイブ コピーを復元し、ユーザーの要求に応じてトリミング後の新しいデータベースかトリミング前の古いデータベースにアクセスするようにアプリケーションを変更することです。その結果、削除期間ごとにデータベースのコピーを保持することになります。
データの変更が遅く、削除と削除の間でほとんどのデータに変更がない場合は、重複が多くなりスペースの無駄遣いになる可能性があります。その一方で、データへのアクセス頻度が低いので、このアーカイブしたデータを、多数の小さい高価な高速ドライブではなく、少数の大きい安価な低速ドライブに保存することができます。データが期間ごとに全体的に更新される場合は、この方法が適しています。このプロセスは管理が非常に容易で、ほとんどの人が簡単に行えます。
データベース スナップショットを使用することも検討してください。データベース スナップショット機能を使用すると、古いデータベースのトリミング前に特定の時点のレプリカを作成できます。スナップショットは一部のシナリオでうまく機能しますが、影響も多数あります。データベース スナップショットは "copy-on-write" で、元のデータベースと、スナップショットが取得された時点のデータベース間の変化を連続的に保持します。元のデータベースからの変更が多い場合は、スナップショットがきわめて大きくなる可能性があります。
ある意味で、データベース スナップショットはバックアップ/復元の逆です。スナップショットは、差分のみ保管するため、変更が少ないと予測される場合に適しています。一方、バックアップ/復元は、変更が多いと予測される場合に適しています。しかし、スナップショットの管理が困難な状態では、"copy-on-write" のスペース節約の利点は失われます。
もう 1 つの方法は、テーブルのパーティション分割を使用することです。これにより、特定のテーブルを取得し、異なるパーティションに属するキー値の範囲を指定して、パーティションを別々のファイルグループに配置できます。どのデータを 1 つのテーブル内のどのファイルグループに格納するかを管理すると、関連コストを制御しやすくなります。どのファイルグループをどの物理ドライブに配置するか (安価なドライブと高価なドライブについては、前の説明を参照してください)、およびバックアップするファイルグループとバックアップの頻度を選択することができます。ファイルグループを読み取り専用にする場合は、部分バックアップを使用することもできます。

データベースの個数
Q 私の会社では、約 5,000 人の顧客に対応できるアプリケーションを実装し、ホストする予定です。機密性を保証するために、顧客 1 人につき 1 つのデータベースを実装したいと考えています。サーバー リソースの使用効率は低下するでしょうか。特定のデータとインデックス サイズ、ユーザー接続数、およびデータベースが 1 つまたは 5,000 個の場合のワークロードについて教えてください。
A スタッフの数がどんなに多くても、データベース間で同じコード ベースを維持するのは困難です。データベース コードの 1 つのバグを修正したら、それを 5,000 回展開しなければなりません。さらに、データベースの回復時間が非常に長くなります。バックアップやデータベースの整合性チェックに時間がかかるからです。このように考えてください。銀行では、当座預金口座を持つ顧客ごとに別個のデータベースをホストに実装していますか。
SQL Server™ では非常に多くのデータベースを作成できますが、それが必ずしも最善の方法とは限りません。同じ期間に各データベースで 1 つのトランザクションを実行するのに必要な作業を考えてください。各データベースにはそれぞれのトランザクション ログがあります。言うまでもなく、オンライン トランザクション処理 (OLTP) のパフォーマンスの鍵は、トランザクション ログでディスクへのシーケンシャルな書き込みによる利点を生かせる環境を維持することです。これらのデータベースからトランザクションを読み取るだけでなく、これらのデータベースでトランザクションを実行する場合は、この方法を使用しないでください。

リンク サーバーに対するクエリの実行
Q 私は、SQL Server 2005 Service Pack 1 (SP1) でデータ ウェアハウスを開発しています。ソース サーバーはパートナーのドメインで、宛先サーバーは私の会社のドメインです。ソースからリンク サーバー経由でレコードを取得します。ソース テーブル間の結合を使用してソースからクエリを実行すると、クエリは短時間で実行されます。しかし、宛先テーブルでは単純な結合を使用してもクエリに長時間かかります。なぜでしょう。
A サーバーを越えた結合を行わないのが最善策です。特にドメインの境界を越えないようにします。とは言うものの、この特定の結果に基づいて言えば、パートナーはあなたのドメインを信頼しているのに対し、あなたがパートナーのドメインを信頼していないために、この問題が発生している可能性があります。クエリを書き直してソースから実行し、結果を宛先にコピーしてください。これにより、良い結果が得られる可能性があります。

帯域幅の測定
Q データベース ミラーリングに使用される帯域幅の測定に関するベスト プラクティスはありますか? ログ生成レートの約 3 倍にする必要があるということはわかっています。しかし、要求の負荷が高くない場合は、Web からブロードバンド接続を経由してデータベース ミラーリングを行うことはできますか?
A 生のスループット以外に、ラウンドトリップ メッセージの待ち時間 (安全性が full の場合はさらに重要になります) とリンクの信頼性を考慮する必要があります。データベース ミラーリングは、信頼性のあるネットワーク接続用に最適化されているため、再接続時に大きなオーバーヘッドが生じる可能性があります。ブロードバンド接続が不安定な場合は (接続が切れる、遅延が長いなど)、接続を維持できないことがあります。詳細については、ミラーリング パフォーマンスの考慮事項に関するホワイトペーパー (英語) を参照してください。
SQL Server へのアクセスの保護
実稼働環境で SQL Server へのアクセスを保護するための推奨事項をお探しですか?「Microsoft patterns & practices Developer Center」 (英語) を参照してください。特に興味深いのは次の 3 つのパターンでしょう。
  • Security Engineering Index (英語)
  • Security Guidance for Applications Index (英語)
  • Threat Modeling Web Applications (英語)

完全な運用環境のセットアップ方法について詳しく知りたいですか? 次の 2 つの参考資料があります。
  • Windows Server System Reference Architecture (英語)
  • Data Services Implementation Guide (英語)

次の Microsoft IT 技術支援スタッフに心より感謝します。Denis Altudov、Jayashree Anand、Gus Apostol、Bhavana Bartholf、Mike Blaszczak、Dibyendu Chakraverty、Shaun Cox、Laurentiu Cristofor、Ernie DeVore、Michael Epprecht、Nakul Garg、Phil Hummel、Steve Lindell、Kaloian Manassiev、Al Noel、Ward Pond、Paul Randal、Remus Rusanu、Mike Shelton、Christy Sutton、Kevin Tsai、Peter Ty、Val Wittenberg、Steven Wort、Kalyan Yella、Frankie Yuen。


 The Cable Guy: TCP 受信ウィンドウ自動チューニング
The Cable Guy
TCP 受信ウィンドウ自動チューニング
Joseph Davies

"TechNet Magazine" の The Cable Guy の初回の記事へようこそ。TechNet Web サイトのコラムのファンである皆さんは、既にご存じのように、私たちはネットワークに関するあらゆる事柄を取り上げてきました。そしてこれからも毎月この伝統を守っていきます。もしあなたが新しい読者で、過去のコラムをお探しなら、Cable Guy サイトを参照してください。
では、最初のトピック、TCP 受信ウィンドウについて説明します。
TCP 接続を用いたスループットはアプリケーションの送受信、TCP の実装の送受信、および TCP ピア間の伝送パスにより制限される場合があります。このコラムでは、TCP 受信ウィンドウ、TCP 受信ウィンドウが TCP スループットに及ぼす影響、TCP ウィンドウ スケーリングの使用法、および受信データに対して TCP スループットを最適化する Windows Vista™ の新しい受信ウィンドウ自動チューニング機能について説明します。

TCP 受信ウィンドウ
TCP 接続には重要な特徴がいくつもあります。第 1 に、TCP 接続は 2 つのアプリケーション レイヤ プロトコル間での論理ポイント ツー ポイント回線であるということです。TCP は一対多の配信サービスを提供しません。TCP は一対一の配信サービスだけを提供します。
第 2 に、TCP 接続は接続指向であるということです。データが伝送される前に、2 つのアプリケーション レイヤ プロセスが、TCP 接続確立プロセスを使用して、TCP 接続を正式にネゴシエートする必要があります。同様に、TCP 接続は TCP 接続終了プロセスを使用して、ネゴシエート終了後に正式に閉じられます。
第 3 に、TCP 接続で送信された信頼できるデータはシーケンシャルなものであり、受信側から受信確認を受けます。受信確認が受けられない場合は、そのセグメントは再伝送されます。受信側では、複製されたセグメントは破棄され、シーケンシャルでない順番で届いたセグメントは適切な順序で再配置されます。
第 4 に、TCP 接続は全二重であるということです。それぞれの TCP ピアについて、TCP 接続は 2 つの論理パイプから構成されます。送信パイプおよび受信パイプの 2 つです。 TCP ヘッダーには送信データのシーケンス番号および受信データの受信確認 (ACK) の両方が含まれます。
さらに、TCP は受信および送信論理パイプを介して送信されたデータを連続するバイト ストリームとして認識します。それぞれの TCP ヘッダーのシーケンス番号および受信確認番号は、バイトの境界線上で定義されます。TCP はバイト ストリーム内ではレコードまたはメッセージの境界を識別しません。アプリケーション レイヤ プロトコルでは受信するバイト ストリームを適切に解析できる必要があります。
一度に送信できるデータの量を制限し、受信側のフロー制御を提供するために、TCP ピアはウィンドウを使用します。ウィンドウとは、受信側が送信側に送信を許可するバイト ストリーム上のデータの幅のことです。送信側はウィンドウ内に含まれるバイト ストリームのバイトのみを送信できます。ウィンドウは、送信側の送信バイト ストリームおよび受信側の着信バイト ストリームに沿ってスライドします。
指定された論理パイプ (全二重 TCP 接続の 1 方向) の場合、送信側は送信ウィンドウを保持し受信側は受信ウィンドウを保持します。送信中のデータまたは ACK セグメントがない場合、論理パイプの送信および受信ウィンドウは一致します。言い換えれば、送信側が送信を許可した送信バイト ストリーム内のデータの幅は、受信側が受信可能な着信バイト ストリーム内のデータの幅と一致するということです。図 1 はこの送信と受信の関係を示しています。
図 1 送信および受信ウィンドウの一致
図 1 送信および受信ウィンドウの一致 (画像を縮小するには、ここをクリックします)
図 1 送信および受信ウィンドウの一致
図 1 送信および受信ウィンドウの一致 (画像を拡大するには、ここをクリックします)
受信ウィンドウのサイズを示すために、TCP ヘッダーには 16 ビットのウィンドウ フィールドが含まれています。受信側がデータを受信すると、受信側は送信側に ACK を送信し、バイトの受信に成功したことを示します。それぞれの ACK 内で、ウィンドウ フィールドは受信ウィンドウ内に残るバイト数を記録します。データが送信され、受信確認され、アプリケーションにより取得されると、送信および受信ウィンドウの両方が右側にスライドします。受信ウィンドウとは、送信側から受信側に受信確認されていないデータをどれだけ送信可能かを制御するウィンドウのことです。
受信ウィンドウ内にはアプリケーションにより取得されていないデータ、および受信はされていても受信確認されていないデータが存在するので、TCP 受信ウィンドウには図 2 が示すように補足的な構造があります。
図 2 TCP 受信ウィンドウのデータの型
図 2 TCP 受信ウィンドウのデータの型 (画像を縮小するには、ここをクリックします)
図 2 TCP 受信ウィンドウのデータの型
図 2 TCP 受信ウィンドウのデータの型 (画像を拡大するには、ここをクリックします)
最大の受信ウィンドウと現在の受信ウィンドウの間の差に注目してください。最大受信ウィンドウは固定サイズです。現在の受信ウィンドウは可変サイズで、受信側が送信側に送信を許可するデータの残存量に対応しています。現在の受信ウィンドウのサイズは、送信側に送り返される ACK 内で使用されるウィンドウ フィールドの値のことです。また最大受信ウィンドウ サイズと受信され受信確認されていてもアプリケーションにより取得されていないデータ量の差のことでもあります。

TCP 受信ウィンドウおよび TCP スループット
TCP スループットを最適化するには (一般的なエラーのない伝送パスを想定したとして)、送信側は送信側と受信側の間の論理パイプを最大限活用する量のパケットを送信する必要があります。論理パイプの容量は次の数式により計算できます。
Capacity in bits = path bandwidth in bits per second * round-trip time (RTT) in seconds
この容量は帯域幅遅延積 (BDP) と呼ばれています。パイプは太い (広帯域幅) または細い (低帯域幅) または短い (低 RTT) または長い (高 RTT) 場合があります。パイプが太くて長い場合、BDP は最大になります。高 BDP 伝送パスの例には、衛星間通信または大陸間を結ぶ光ファイバ リンクを含むエンタープライズ ワイド エリア ネットワーク (WAN) があります。
高 BDP 伝送の送信側のパフォーマンスの向上
新しい受信ウィンドウ自動チューニング機能は、高 BDP リンク経由のデータ受信のパフォーマンスを向上させますが、送信側のパフォーマンスについてはどうでしょうか。
ネットワークを氾濫させるほどの TCP ピアの送信を防ぐ既存のアルゴリズムは、スロー スタート アルゴリズムおよび輻輳回避アルゴリズムとして知られています。これらのアルゴリズムは、接続上で最初にデータを送信したとき、および失われたセグメントを回復したときに、送信ウィンドウ (送信側が送信可能なセグメント数) を増加させます。
スロー スタート アルゴリズムは、それぞれの受信確認セグメントを受信した場合 (Windows XP および Windows Server 2003 での TCP の場合)、またはそれぞれのセグメントが受信確認された場合 (Windows Vista および Windows Server "Longhorn" での TCP の場合) に 1 つの完全な TCP セグメントにより送信ウィンドウを増加します。輻輳回避アルゴリズムは、受信確認されたデータの完全なウィンドウそれぞれに対して 1 つの完全な TCP セグメントを追加することにより送信ウィンドウを追加します。
これらのアルゴリズムは BDP 値が小さい場合および受信ウィンドウ サイズが比較的小さな場合に適しています。しかし、往復遅延時間が 100ms の高速 WAN リンクに接続されている 2 つのサーバー間でデータをレプリケートする場合のように、受信ウィンドウ サイズが大きく BDP 値も高い TCP 接続の場合、これらのアルゴリズムはこの高速接続環境の帯域を十分に利用できるほど速く送信ウィンドウを増加しません。
このような状況で TCP 接続の帯域をより利用するために、次世代の TCP/IP スタックには Compound TCP (CTCP) が含まれます。CTCP は、大きな受信ウィンドウ サイズおよび高い BDP 値を使用する接続に対して送信ウィンドウをより強制的に増加します。CTCP は、遅延の変動およびパケットロスを監視することにより、これらの種類の接続におけるスループットの最大化を試みます。加えて、CTCP のこれらの動作は、他の TCP 接続に悪影響を及ぼすことはありません。
マイクロソフトでの内部テストでは、往復遅延時間 (RTT) が 50ms の 1Gbps 接続環境での大規模なファイル バックアップに必要な時間が約半分に減少しました。BDP 値がより大きい接続ではさらにパフォーマンスが向上します。CTCP および受信ウィンドウ自動チューニングは、リンク使用率を増加させるために一体となって機能し、その結果 BDP 値が大きい接続でのパフォーマンスが大幅に向上します。
CTCP は、Windows Server "Longhorn" が実行中のコンピュータでは既定で有効になっています。また Windows Vista を実行中のコンピュータでは既定で無効になっています。"netsh interface tcp set global congestionprovider=ctcp" コマンドを使用して CTCP を有効にすることができます。"netsh interface tcp set global congestionprovider=none" コマンドを使用して CTCP を無効にすることができます。

TCP ヘッダー内でのウィンドウ フィールドのサイズは 16 ビットです。これにより TCP ピアは最大 65,535 バイトの受信ウィンドウ サイズに対応します。次の数式を使用して任意の TCP ウィンドウ サイズに対するスループットを概算できます。
Throughput = TCP maximum receive windowsize / RTT
たとえば、65,535 バイトの受信ウィンドウでは、伝送パスの実際の帯域幅に関係なく、RTT が 100ms のパス上では、およそ 1 秒あたり 5.24 メガビット (Mbps) のスループットしか実現できません。今日の高 BDP 伝送パスでは、初期に設計された TCP ウィンドウ サイズは、最大値に設定したとしても、それがスループットのボトルネックになってしまうのです。

TCP ウィンドウ スケーリング
より大きなウィンドウ サイズが高速伝送パスに対応できるようにするために、RFC 1323 (ietf.org/rfc/rfc1323.txt (英語)) が、受信側が 65,535 バイトよりも大きなウィンドウ サイズを提供することを許可するウィンドウ スケーリングを定義します。TCP ウィンドウ スケール オプションにはウィンドウ スケーリング要素があります。ウィンドウ スケーリング要素と TCP ヘッダー内の 16 ビットのウィンドウ フィールドを組み合わせると、受信ウィンドウ サイズを最大約 1 GB に増加できます。ウィンドウ スケール オプションは接続を確立するプロセス中に同期 (SYN) セグメント内にのみ送信されます。両方の TCP ピアについて、受信ウィンドウ サイズに対して、異なるウィンドウ スケーリング要素を使用するように指定できます。TCP ウィンドウ スケーリングで送信側が接続上により多くのデータを送信できるようにすることで、TCP ノードは高 BDP を使用する伝送パスの種類のいくつかをより有効に利用できます。
受信ウィンドウ サイズは TCP スループットにとって重要ですが、最適な TCP スループットを判断するための他の重要な要素は、受信ウィンドウ内に蓄積されたデータをアプリケーションが取得する速度 (アプリケーション取得比率) です。アプリケーションがデータを取得しないと、受信ウィンドウは次第にいっぱいになり、受信側が提供する現在のウィンドウ サイズが小さくなります。極端な例では、最大受信ウィンドウすべてがいっぱいになった場合、受信側が提供するウィンドウ サイズは 0 バイトになります。この場合、受信ウィンドウがクリアされるまで送信側はデータの送信を停止する必要があります。したがって、TCP スループットを最適化するには、接続に対する TCP 受信ウィンドウを、接続する伝送パスの BDP およびアプリケーション取得比率の両方を反映した値に設定する必要があります。
たとえ BDP およびアプリケーション取得比率の両方を正確に判断できたとしても、それらは時間と共に変化します。BDP 比率は伝送パスの輻輳に基づいて変化します。またアプリケーション取得比率はアプリケーションがデータを受信する接続数に基づいて変化します。

Windows XP の受信ウィンドウ
Windows XP (および Windows Server® 2003) での TCP/IP スタックでは、最大受信ウィンドウ サイズに多数の重要な属性があります。第 1 に、デフォルト値は送信インターフェイスのリンク速度に基づいています。実際の値は、TCP 接続を確立する間にネゴシエートされ、最大セグメント サイズ (MSS) まで自動的に調整されます。
第 2 に、最大受信ウィンドウ サイズは手動で設定できます。HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\TCPWindowSize および HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\Interface\InterfaceGUID\TCPWindowSize のレジストリ値により最大 65,535 バイト (ウィンドウ スケーリングなしの場合) または 1,073,741,823 バイト (ウィンドウ スケーリングありの場合) に設定できます。
第 3 に、最大受信ウィンドウ サイズにウィンドウ スケーリングを使用できます。HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\Tcp1323Opts レジストリ値を 1 または 3 に設定することによりウィンドウ スケーリングを有効にできます。既定では、ウィンドウ スケーリングは、受信された SYN セグメントがウィンドウ スケール オプションを含む接続に対してのみ使用されます。
最後に、最大受信ウィンドウ サイズは、接続が開始されたときに SO_RCVBUF Windows Sockets オプションを使用することにより、アプリケーションで指定できます。ウィンドウ スケーリングの場合、アプリケーションは 65,535 バイトより大きいウィンドウ サイズを指定する必要があります。
拡張可能なウィンドウをサポートするにもかかわらず、Windows XP での最大受信ウィンドウ サイズで引き続きスループットを制限できます。その理由は、最大受信ウィンドウ サイズは、アプリケーションによって指定されない限り、すべての TCP 接続に対する固定の最大サイズだからです。これを使用して、いくつかの接続に対してはスループットを増加し、また他の接続に対してはスループットを減少できます。また、TCP 接続に対する固定の最大受信ウィンドウ サイズは、アプリケーション取得比率または伝送パス内の輻輳により変化しません。

Windows Vista の受信ウィンドウ自動チューニング
特に高 BDP を使用する伝送パスに対するスループットを最適化するために、Windows Vista (および "Longhorn" というコード名の Windows Server の次のバージョン) の次世代 TCP/IP スタックは受信ウィンドウ自動チューニングをサポートします。この機能は BDP およびアプリケーション取得比率を測定し、また進行中の伝送パスとアプリケーションに対するウィンドウ サイズを調整することにより、最適な受信ウィンドウ サイズを決定します。
受信ウィンドウ自動チューニングは、既定で TCP ウィンドウ スケーリングを有効にし、16 MB までの最大受信ウィンドウ サイズを許可します。データが接続上で伝送される間、次世代の TCP/IP スタックは接続を監視し、現在の BDP およびアプリケーション取得比率を測定し、スループットを最適化する受信ウィンドウ サイズに調節します。次世代の TCP/IP スタックは TCPWindowSize レジストリ値を使用しなくなりました。
受信ウィンドウ自動チューニングには多くの利点があります。受信ウィンドウ自動チューニングは、接続ごとに最適な受信ウィンドウ サイズを自動的に決定します。Windows XP では、TCPWindowSize レジストリ値がすべての接続に適用されます。アプリケーションは、Windows Sockets オプションを使用して TCP ウィンドウ サイズを指定する必要がなくなりました。また IT 管理者が、特定のコンピュータに対して TCP 受信ウィンドウ サイズを手動で設定する必要がなくなりました。
受信ウィンドウ自動チューニングにより、Windows Vista ベースの TCP ピアは、通常、Windows XP ベースの TCP ピアよりもより大きな受信ウィンドウ サイズを提供できます。これにより他の TCP ピアは、ACK (TCP 輻輳管理による制限) が待機することがなくなり、より多くの TCP データ セグメントを送信するので、Windows Vista ベースの TCP ピアへのパイプを十分に使用することができます。 Web ページまたは電子メールなどの典型的なクライアント ベースのネットワーク トラフィックの場合、Web サーバーまたは電子メール サーバーは、より多くの TCP データをより迅速にクライアント コンピュータに送ることができます。その結果ネットワーク パフォーマンスが全体的に向上します。接続に対する BDP およびアプリケーション取得比率が高いほど、パフォーマンスはより向上します。
ネットワークへの影響については、これまでは TCP データ パケットのストリームは通常より遅い、一定のペースで送信されてきましたが、それがより迅速に送信されることにより、データ伝送中のネットワーク使用率がより大きくなります。Windows XP および Windows Vista ベースのコンピュータの場合、長く、太いパイプで同じデータ伝送が実行されます。伝送されるデータ量は同じです。しかし、Windows Vista ベースのクライアント コンピュータに対するデータ伝送は、より大きな受信ウィンドウ サイズと、サーバーからクライアントへのパイプをサーバーが十分に使用できることによって、より速くなります。
受信ウィンドウ自動チューニングは高 BDP 伝送パスのネットワーク使用率を増加させるので、サービスの品質 (QoS) の使用またはアプリケーション送信比率の調整が、稼働中の伝送パスまたは容量が限界に近づいている伝送パスに対して重要になる場合があります。この予期される必要に対処するため、Windows Vista はグループ ポリシーに基づいた QoS 設定をサポートします。これにより IP アドレスまたは TCP ポート上で送信されるトラフィックに対する調整比率を定義できます。詳細については、ポリシーに基づく QoS に関するリソース (英語) を参照してください。
データが失われる確率の高いネットワークの TCP スループットの増加
データが失われる確率の高いネットワークでは、頻繁なタイム アウトと再伝送のために TCP スループットが極端に減少します。データが失われる確率の高いネットワークの例としては、IEEE 802.11、汎用パケット ラジオ サービス (GPRS)、ユニバーサル モバイル通信システム (UMTS) に基づくような、無線ネットワークがあります。これらはネットワークの状態、シグナル減衰、電磁干渉、コンピュータの設置場所の変更などによりパケットが失われる確率が高くなります。
次世代の TCP/IP スタックは、データが失われる確率の高い環境でのスループットを最適化するために、次の 4 つの RFC をサポートします。

RFC 2582: 新しい Reno アルゴリズムによる TCP 高速回復アルゴリズムの修正
RFC 2001 で定義される高速回復アルゴリズムは、Reno アルゴリズムに基づいています。これによって、高速な再伝送イベントのためにセグメントが再伝送された場合に送信側が送信するデータの量が増加します。Reno アルゴリズムは失われたセグメントが単一の場合適切に機能しますが、失われたセグメントが複数の場合は適切に機能しません。新しい Reno アルゴリズムは、データのウィンドウ内の複数のセグメントが失われ、送信側が部分的な受信確認 (正常に受信したデータの部分だけに対する受信確認) を受信した場合に、送信側が高速回復中に送信比率を増加させることにより、より高速なスループットを提供します。

RFC 2883: TCP の選択的受信確認 (SACK) オプションの拡張
RFC 2018 で定義される SACK は、SACK TCP オプションを使用することにより、受信データの非連続ブロックを 4 つまで受信側が示すことができます。RFC 2883 は、重複したパケットを受信確認するために、SACK TCP オプションで追加フィールドの使用を定義します。これにより送信側は、不必要なセグメントをいつ再伝送したかを判断し、今後の不必要な再伝送を防ぐように自身の動作を調節できます。送信される再伝送が少なくなればなるほど、全体的なスループットが良くなります。

RFC 3517: TCP の損失復旧アルゴリズムに基づく慎重な選択的受信確認
Windows Server 2003 および Windows XP における TCP/IP の現在の実装では、送信先においてどの TCP セグメントが到着していないかを判断するためだけに SACK の情報を使用します。RFC 3517 は、重複する受信確認が受信された場合に損失を復旧するために SACK 情報を使用する方法を定義します。また接続上で SACK が有効な場合は、より古い高速回復アルゴリズムを置き換えます。次世代 TCP/IP スタックは SACK 情報の追跡をピア接続ベースで保持し、送信先において複数のセグメントが受信されないときにより迅速に復旧できるように、入ってくる受信確認だけでなく重複する受信確認も監視します。

RFC 4138: Forward RTO-Recovery (F-RTO): TCP の誤った再伝送タイムアウト検出 (Detecting Spurious Retransmission Timeouts) 用のアルゴリズムおよびストリーム制御伝送プロトコル (SCTP)
RTT の突然の増加により、TCP セグメントの誤った再伝送が引き起こされる場合があります。以前に送信されたセグメントの再伝送タイムアウト (RTO) が次第に期限切れになり、TCP がそれらの再伝送を開始します。データのウィンドウを完全に送信する直前にこの増加が発生した場合、送信側はデータのウィンドウ全体を再伝送します。F-RTO アルゴリズムは、次の動作により TCP セグメントの誤った再伝送を防ぎます。
RTO が複数のセグメントに対して期限切れになると、TCP は最初のセグメントを再伝送します。最初の受信確認が受信されると、TCP は新しいセグメントの送信を開始します (提供されたウィンドウ サイズで可能な場合)。次の受信確認で、タイム アウトしたが再伝送されていない他のセグメントが確認された場合、TCP は、タイムアウトは誤りと判断し、タイム アウトした他のセグメントの再伝送を行いません。
この結果、無線クライアントが 1 つのアクセス ポイントから他のアクセス ポイントに移動した場合など、RTT が突然一時的に増加した環境では、F-RTO が不必要なセグメントの再伝送を防ぎ、より迅速に送信比率を通常に戻します。SACK に基づく損失の復旧および F-RTO の使用は、GPRS リンクを使用する接続に最適です。

Joseph Daviesマイクロソフトのテクニカル ライターとして Windows ネットワークのトピックに関する講義および執筆を 1992 年から行っています。Joseph Davies は、Microsoft Press 向けに本を 5 冊執筆しており、また月間の TechNet Cable Guy コラムの著者でもあります。


 Windows PowerShell: Windows PowerShell のコンストラクト
Windows PowerShell
Windows PowerShell のコンストラクト
Don Jones

先月は、Windows PowerShell を使って、実際にスクリプトを作成しなくても、管理タスクの解決にすぐに使用できる方法を紹介しました。Windows PowerShell は優れたインタラクティブ シェルではありますが、その強力かつ簡単なスクリプト言語を実際に利用して初めて、その機能を活用し、複雑なタスクを自動化することができます。
ただ、ちょっと考えてみてください。マイクロソフトは本当に別のスクリプト言語を必要としているのでしょうか。マイクロソフトは、何といっても、ログオン スクリプト プロセッサである KiXtart と VBScript (Visual Basic® Scripting Edition) を提供しています。しかし、この答えはイエスです。マイクロソフトは、実際に別のスクリプト言語を必要としていたのです。その理由を説明しましょう。
Windows PowerShell™ の言語は、管理者が多くのトレーニングを積まなくても利用できるようにシンプルかつ直感的であることが必要でした。また、Windows PowerShell そのものがユーザーに提供しているすべての強力な機能に対応できるように、言語には高い柔軟性も要求されました。
Windows PowerShell は、Microsoft® .NET Framework に基づいているため、そのスクリプト言語構文は .NET に近いものであることが求められました。Windows PowerShell のスクリプト言語をアセンブルする際、デザイナは必然的に非常に簡素化された C# ("C シャープ" と発音し、.NET Framework に同梱されている言語の 1 つ) の構文を選びました。どうして VBScript のような構文にしなかったのでしょうか。Windows PowerShell スクリプト言語は実際 VBScript とあらゆる点で異なるわけではありませんが、C# 構文により近づけることで、PowerShell が .NET Framework プログラミングを学ぶ際の第一歩となるようにしたのです。上のレベルの Visual Studio® に移行することに決めてから、C# アプリケーションの作成を開始しても、Windows PowerShell スクリプト構文のほとんどが移行後も役に立ちます。
Windows PowerShell スクリプト言語に限らず、どのスクリプト言語においても、最も重要な点の 1 つはそのコンストラクトです。これらの特殊な言語要素を使って、Windows PowerShell で論理比較を実行し、比較の結果に基づいて異なるアクションを実行したり、1 つ以上の命令を何度も繰り返すことができます。

論理的な考え方
論理比較は、多くのスクリプト言語コンストラクトの中心であり、Windows PowerShell も例外ではありません。比較では、基本的に 2 つの値またはオブジェクトを参照し、比較が True または False のどちらであるか評価します。たとえば、ユーザーのパスワードの有効期限が今日の日付と同じかどうかを確認するとします。その結果は、日付が同じであれば True、異なる場合は False になります。True と False は先頭の文字を大文字にしています。これらの用語は、Windows PowerShell 内で特別な意味を持つからです。
次に、Windows PowerShell 内で実行できる実際の論理比較の例を示します。
PS C:\> $a = 1
PS C:\> $b = 2
PS C:\> $a -eq $b
False
$a という名前の変数を作成し、1 の値が含まれるようにその変数を設定しました。Windodws PowerShell では、変数名の先頭にドル記号が付いているため、簡単に見分けることができます。= は、値を代入するために使用されるので、専門用語では代入演算子と呼ばれます。次に、2 つ目の変数として $b を作成し、2 の値を代入しました。その後、実際の論理比較として、Windows PowerWhell に -eq (equality) 演算子を使用して $a と $b の内容を比較するように命令しました。PowerShell は比較を実行し、2 つの値が等しくないと判断したため、False という結果を表示しています。
Windows PowerShell の演算子は、これまで使用されている他のスクリプト言語とは若干異なり、C# とも異なります。多くの言語は = 演算子を使用して等値チェックだけでなく、値の代入も実行します。Windows PowerShell では、混乱を避けるために各関数専用の演算子を使用しています。図 1 に、Windows PowerShell の比較演算子と、既に慣れ親しんでいる他の言語 (VBScript) の対応する演算子を示します。
Figure 1 PowerShell 比較演算子 (Close Figure 1)

演算子 | 名前 | 説明
-eq | Equality (等値) | 値が同じかどうかをテストします。他の言語では、等しいかどうかテストする場合、= または == が使用されます。
-ne | Not Equal (次の値に等しくない) | 値が等しくないかどうかをテストします。他の言語では、等しくないかどうかのテストに、<> または != が使用されます。
-gt | Greater Than (次の値より大きい) | ある値が他の値よりも大きいかどうかをテストします。他の言語では、> 文字が使用されます。
-lt | Less Than (次の値より小さい) | ある値が他の値よりも小さいかどうかをテストします。他の言語では、< 文字が使用されます。
-ge | Greater Than or Equal To (次の値以上) | ある値が別の値以上かどうかをテストします。VBScript および他の言語の >= と似ています。
-le | Less Than or Equal To (次の値以下) | ある値が別の値以下かどうかをテストします。VBScript および他の言語の <= と似ています。
これらの比較演算子には、他にも興味深い機能があります。次の比較を見てみましょう。
PS C:\> $a = "TechNet"
PS C:\> $b = "technet"
PS C:\> $a -eq $b
True
既定では、比較演算子は大文字と小文字を区別しません。つまり、先頭が大文字の "TechNet" は、"technet" と同じとみなされます。多くの管理者は大文字と小文字の区別を気にしないので、これは便利です。ただし、Windows PowerShell では、比較演算子の前に C の文字を付けることで大文字と小文字を区別した比較を実行することができます。
PS C:\> $a -ceq $b
False
同様に、Windows PowerShell が大文字と小文字を区別しない比較を実行するかどうかわからなくなった場合は、i の文字を前に付けることで大文字と小文字を区別しない比較を実行できます。
PS C:\> $a -ieq $b
True
論理比較の結果は常に 2 つの値、つまり True または Flase のいずれかになることを覚えておいてください。

決定
論理比較の作成方法を理解したら、それらをコンストラクトで使用することができます。最初に紹介するコンストラクトを使用すると、Windows PowerShell で比較に基づいた決定を行うことができます。これは If コンストラクトと呼ばれ、そのバリエーションがいくつかあります。最も単純な例を次に示します。
PS C:\> if ($a -eq $b) {
>> Write-Host "They are equal"
>> }
>>
They are equal
この例には注目すべき興味深い点がいくつかあります。最初に、この例でも変数 $a と $b にはそれぞれ "TechNet" と "technet" の値が代入されています。まず、If キーワードを使用してコンストラクトを開始しています。その後のかっこ内に、実行する論理比較を入力しています。その後に続く中かっこは、条件コード、つまり比較によって True の結果が返された場合に Windows PowerShell が実行するコードの呼び出しの開始を知らせるものです。前述の例から、この比較では True が返されることがわかっているので、実行する条件コードを予想できます。条件コードとして「Write-Host "They are equal"」と入力し、Enter キーを押します。最後に、閉じ中かっこを入力し、Enter キーを 2 回押して条件コード セクションを終了します (空の行で 2 回目の Enter キーを押すと、作成が完了し、コードを実行をできる状態であるとパーサーが判断します)。
このコンストラクトはスクリプト ファイルからは実行されていません。このコンストラクトは Windows PowerShell コマンド ラインに入力しているだけです。これは、Windows PowerShell が Windows スクリプトの中でもユニークな存在であることを表しています。スクリプトは、インタラクティブに作成できるだけでなく、ファイルに挿入して永久保存することができるのです。
開始中かっこを入力して Enter キーを押すとすぐに、Windows PowerShell には >> プロンプトが表示されました。これは、"コンストラクト内にユーザーが存在していることを認識し、コンストラクト内で実行する内容を入力できます" ということを伝えています。閉じ中かっこを入力し、Enter キーを 2 回押した後、Windows PowerShell では直ちにコンストラクトが実行されて、その論理比較が True であることが確認され、条件コードが実行されます。これは、通常のプロンプトに戻る前に、"They are equal" が表示されていたことからわかります。Windows PowerShell を使用してスクリプトをインタラクティブに作成すると、それらをより永続的なスクリプトにアセンブルする前にコードをすばやくテストできるので、学習とデバッグの両方を簡単に行うことができます。
Windows PowerShell では、Enter キーを押すなどの動作を必ず行う必要はありません。たとえば、次の例は、前の例と内容的には同じです。
PS C:\> if ($a -eq $b) { Write-Host "They are equal" }
They are equal
この例はすべて 1 行に入力しているため、Windows PowerShell は特殊な >> プロンプトを表示する必要はありません。行の最後に Enter キーを押すと、コンストラクトが単純に実行されるだけです。Windows PowerShell は、コンストラクトが実行できる状態であることをどうやって知るのでしょうか。この場合、閉じ中かっこが入力された時点で完了ということを意味します。
If コンストラクトには他のバリエーションがあることは前にも説明しました。次の例は、シェルではなく、PS1 スクリプト ファイルに表示される完全な例です。
if ($a -eq $b) {
  Write-Host "They are equal"
} elseif ($a -lt $b) {
  Write Host "One is less than the other"
} else {
  Write Host "One is greater than the other"
}
コンストラクトは、If キーワードを使用して同じように開始されています。ただし、比較結果が False であった場合は、Elseif キーワードを使用して別の比較を実行することを指定しています。その 2 番目の比較結果も False だった場合は、最後のキーワード Else で、最後のコードが実行されます。

繰り返しの実行
Windows PowerShell には、比較結果が True または False になるまでコードを何度も実行するための 1 組のコンストラクトがあります。プログラマはこれらを loop コンストラクトと呼んでいます。最も有用な loop コンストラクトの 1 つを使用すると、コレクション内のオブジェクトを列挙し、各オブジェクトに対して 1 行以上のコードを実行することもできます。このコンストラクトは foreach コンストラクトと呼ばれます。このコンストラクトの例を次に示します。
PS C:\> $names = get-content "c:\computers.txt"
PS C:\> foreach ($name in $names) {
>> Write-Host $name
>> }
>>
don-pc
testbed
最初に Windows PowerShell Get-Content cmdlet に対して c:\computers.txt ファイルのコンテンツを取得するように命令しています。このファイルは著者自身が作成したファイルで、各行に 1 つのコンピュータ名が含まれています。Windows PowerShell は各行を 1 つのオブジェクトとして扱うため、ファイルは必然的にそれらのオブジェクトを含むコレクションになります。コレクションは変数 $names になります。foreach キーワードを使い、ループが実行されるたびに現在のオブジェクトを表す変数 $name を使用して Windows PowerShell で $names コレクションを列挙するように命令しています。ループ コードは中かっこの中にあります。そのため、ファイル内の各名前について、その名前がコマンド ラインに出力されます。また、コンストラクトの後の出力を確認すると、Windows PowerShell が実行した正確な内容がわかります。これは、管理スクリプトにおける明確な利点を示しています。たとえば、サーバー名の一覧を簡単に作成でき、Windows PowerShell で各リストから情報を取得できるのです。

実際のコンストラクト
ここでは、論理比較、If コンストラクトおよび foreach コンストラクトを使って、実際に何か役に立つことを実行してみましょう。サーバーのセットにおける Messenger サービスのステータスをすばやくチェックしたいと思います。サービスはほとんどのサーバーで停止されることが予想されますが、Windows PowerShell では、サービスが予想された状態になっているサーバーをすべてリストする作業は行いません。必要なのは、Messenger サービスが実際に開始されているサーバーをリストすることです。それらのサーバーでなんらかの作業を実行する必要があるからです。
Windows PowerShell Get-Service cmdlet を使用すれば、ローカル コンピュータに必要な情報を取得できることはわかっていますが、実際の目標であるリモート コンピュータにはアクセスできません。この場合、Get-WMIObject cmdlet を使って Windows Management Instrumentation (WMI) 経由で同じ情報にアクセスし、リモート コンピュータを使用することができます。この場合のスクリプトを次に示します。
$names = get-content c:\computers.txt
foreach ($name in $names) {
  $svc = get-wmiobject win32_service '
   -computer $name -filter "name='messenger'"
  if ($svc.started -eq $True ) {
    write-host "$name has Messenger running"
  }
}
3 行目の ' という文字に注目してください。この文字は、Windodws PowerShell に、次の行が継続行であることを知らせるものです。これは、行全体を折り返さないとマガジンに収まらないような場合に便利です。また、If コンストラクトが $svc.started to $True を比較していることにも注目してください。変数 $True は、ブール型の True 値を表す、Windows PowerShell の特殊な変数です (比較変数 $ False はブール型の False を表します)。実際は、次のように若干簡素化して表すことができます。
$names = get-content c:\computers.txt
foreach ($name in $names) {
  $svc = get-wmiobject win32_service '
   -computer $name -filter "name='messenger'"
  if ($svc.started) {
    write-host "$name has Messenger running"
  }
}
前にも説明したように、If コンストラクトの条件は単純に True または False になる必要があります。通常、2 つの値を比較すると、このスクリプトの最初のバージョンで示したように、True または False を取得できます。ただし、Started プロパティは True または False のいずれかであるため、実際には True または False と比較する必要はありません。

役に立つツール
これで、ジョブを実行する際に、コンストラクトを利用する簡単で役に立つ管理ツールを使用できるようになりました。Windows PowerShell にインタラクティブ入力する場合でも、PSI ファイルに保存して簡単に再利用する場合でも、このツールはさまざまなコンピュータ上のサービスのステータスをチェックすることができる便利なツールであり、コンストラクタのデモは管理タスクを自動化するうえで役立ちます。

Don JonesSAPIEN Technologies のプロジェクトおよびサービスの責任者であり、『Windows PowerShell: TFM』(SAPIEN Press、2006) の共著者でもあります。Don に対するお問い合わせについては、彼の Web サイト (ScriptingAnswers.com)(英語) を参照してください。


 Hey, Scripting Guy!: 発言には注意しましょう
Hey, Scripting Guy!
発言には注意しましょう
Microsoft Scripting Guy

アメリカ南北戦争中 (正確にはスポットシルバニアの戦いに際し) に、北軍のジョン・セジウィック将軍は、部下たちが南軍の狙撃兵たちによる不規則かつ無作為な発砲におじけづいているのを見て落胆していました。言い伝えによれば、セジウィックは部下たちにこう言いました。「そんな風に逃げ回るな。恥を知れ。南軍はこの距離では象でも撃てまい。」その直後に、セジウィックは戦死した最高位の北軍将校となりました。セジウィックにとっては不幸なことに、南軍の狙撃兵は象を撃つことはできなかったかもしれませんが、将軍を撃つことはできたのです。
もちろん、言うまでもなくこの話の教訓は明らかです。きっとこういうことだと思われるでしょう。「だれかが撃っているときには頭を下げろ」、良い教訓だと思われますか。残念ながら、私たちはそのように考えませんでした。代わりに、私たちは次の教訓を学びました。「発言には注意しましょう。いつの日か、それが跳ね返ってきて自分を撃つかもしれないからです。」ジョン・セジウィックにとってこの言葉は真実でした。そしてこれは他の大勢の人々にとっても同様に真実です。たとえば、長い間 IBM の社長であったトーマス・ワトソンを、アメリカの史上最も偉大な企業家の 1 人として覚えている人はいないでしょう。代わりに、「私が思うに、全世界には 5 台のコンピュータが売れるだけの市場があるだろう」という言葉を語った人としてワトソンは歴史に名を残しました。
興味深いことに、ワトソンがこの言葉を実際に語ったという証拠はありません。単にその事柄に関するだれか他の人の考えを述べたにすぎないのかもしれません。しかし気にする人はほとんどいないでしょう。結局のところ、IBM の社長がコンピュータにとっての市場などはないと語ったかもしれないという考えそのものが、ささいなことに思える事実を無視できないということをたいへんよく表しているのではないでしょうか。
ちなみに、ワトソンは「成功したいなら、普通の倍失敗しなさい。」とは語りました。このアドバイスに Scripting Guy は心から同感します。
まあ、少なくとも、普通の倍失敗するという部分に。
またこのような格言もあります。「VBScript でスクリプトを書いているライターは、.NET Framework ではスクリプトが書けない。」明らかに Microsoft® .NET Framework ではスクリプト ライターはスクリプトを書けないということは、「南軍はこの距離では象でも撃てまい。」または「私が思うに、全世界には 5 台のコンピュータが売れるだけの市場があるだろう。」という言葉ほど印象的ではありません。しかし、そのような発言は一様にまったく的外れです。.NET Framework は C# および Visual Basic® を使用する開発者を念頭に置いて設計されているのは事実です。また VBScript ではネイティブ .NET Framework クラスをインスタンス化できません。しかしこのことは .NET Framework ではすべてのライターがスクリプトを書けないということでは決してありません。
そうです。.NET Framework クラスの大部分が VBScript では使用できないままになっていることは否定できません。しかし、COM を呼び出すことができるラッパーが付いている .NET クラスはかなり多くあります。これが意味するところは単純で、COM インターフェイスを含むこれらのクラスを、VBScript のようなスクリプト言語で使用できるということです。信じられないと思いますか。図 1 に示されるレジストリの HKEY_CLASSES_ROOT の部分を見てください。System で始まるクラスはすべて見ることができるはずです。
図 1 レジストリのシステム クラス
図 1 レジストリのシステム クラス (画像を縮小するには、ここをクリックします)
図 1 レジストリのシステム クラス
図 1 レジストリのシステム クラス (画像を拡大するには、ここをクリックします)
これらの大部分は .NET Framework クラスです。またこれらのほとんどが VBScript を介してインスタンス化できます。
言ったとおりでしょう。
もちろん、深夜番組で広告される商品を購入したことのある人ならだれでも証言できるように、何かができるからといってそれをしなければならないということにはなりません (たいていそれらの商品には店でおおっぴらに購入できない何らかの理由があります)。確かに、スクリプト内で System.ContextMarshalException クラスのインスタンスを作成できますが、なぜそうするのか、それをどう使用するのかということはわたしたちにはわかりません。
しかしこれはすべての .NET Framework クラスに当てはまるわけではありません。たとえば、スクリプトの世界における最大の悩みの種は項目を分類する簡単な方法がないという事実です。リストをアルファベット順に置くには非接続のレコードセットを使用するか、または暗号のようなソート関数をすべて自分で作成する必要があります。次に示すようなバブル ソート コードです (胃が弱い方は飛ばして次の段落に進む方がよいかもしれません)。
For i = (UBound(arrNames) - 1) to 0 Step -1
    For j= 0 to i
        If UCase(arrNames(j)) >
          UCase(arrNames(j+1)) Then
            strHolder = arrNames(j+1)
            arrNames(j+1) = arrNames(j)
            arrNames(j) = strHolder
        End If
    Next
Next
落ち込まないでください。コードを書きはしましたが、私たちもすべての意味が完全にわかっているわけではありません。
このような状況で .NET Framework をどのように利用できるでしょうか。その質問に答えるために、非常に単純でわかりやすい短いスクリプトを見てみましょう。
Set DataList = CreateObject _
      ("System.Collections.ArrayList")

DataList.Add "B"
DataList.Add "C"
DataList.Add "E"
DataList.Add "D"
DataList.Add "A"

DataList.Sort()

For Each strItem in DataList
    Wscript.Echo strItem
Next
ご覧のように、ここでは NET Framework クラスの System.Collections.ArrayList のインスタンスを作成しています。次に、Add メソッドを使用してリストに 5 つの項目を追加します。すべてうまくいっていますが、1 つだけ問題があります。これらの項目はいわゆる無作為な形式 (B、C、E、D、A) で追加しましたが、アルファベット順 (A、B、C、D、E) で表示する必要があります。バブル ソート コードを使うときがきましたね。
いいえ、違います (たいへん無愛想で申し訳ありませんが、間違いは間違いです)。バブル ソート コードを持ち出す必要はありません。配列リストの Sort メソッドを呼び出すだけでよいのです。
DataList.Sort()
これだけです。そのコード 1 行だけで、配列リストのすべての項目を並べ替えることができます。
証明しましょうか。手厳しい方々ですね。いいでしょう。皆さんが疑い深いことは予期していました。なぜスクリプトが、リスト内のすべての項目をループする For Each ループを含み、画面上にそれぞれの値をエコーするのか、これがその理由です。
For Each strItem in DataList
    Wscript.Echo strItem
Next
さて、皆さんが取り組むことができる質問をご紹介します。このスクリプトを実行すると、どのような結果を得ることができますか。
良い読みです。
A
B
C
D
E
すばらしいでしょう。
うーん、完全には満足していない方もおられるようですね。確かにこれでうまくいっていますが、本当に表示したいことは、それらの値をエコー バックして降順に並べ替えることでした。つまり A から Z へのリストではなく Z から A へのリストを表示したかったわけです。そうなっていないならどうすればよいでしょうか。。。
問題はありません。お答えしましょう。
Set DataList = CreateObject _
      ("System.Collections.ArrayList")

DataList.Add "B"
DataList.Add "C"
DataList.Add "E"
DataList.Add "D"
DataList.Add "A"

DataList.Sort()
DataList.Reverse()

For Each strItem in DataList
    Wscript.Echo strItem
Next
そのとおりです。非常に長いスクリプトになりましたね。しかし、ここで重要な追加があります。追加した 1 行のコードをご覧ください。それは Sort メソッドの直後の 1 行です。
DataList.Reverse()
わかりましたか。リストを昇順に並べ替えた後に、驚くべきことに配列内の各項目をすべて逆の順番にする Reverse メソッドを呼び出しました。これにより何が得られるでしょうか。次のような出力が得られます。
E
D
C
B
A
感動せずにはいられないでしょう。
でもちょっと待ってください。ここからこれまでより、さらに良くなるのです。VBScript 配列から項目の削除を試みたことはありますか。もしなくても泣かないでください。これからあなたにそうしていただくわけではありません。代わりに、.NET Framework 配列リストから項目を削除することがどのくらい簡単なのかをお伝えします。D の文字は好きではないですよね。削除しましょう。これが配列リストを作成し、並べ替えて、D のエントリを削除するスクリプトです。
Set DataList = CreateObject _
  ("System.Collections.ArrayList")

DataList.Add "B"
DataList.Add "C"
DataList.Add "E"
DataList.Add "D"
DataList.Add "A"

DataList.Sort()
DataList.Remove("D")

For Each strItem in DataList
    Wscript.Echo strItem
Next
もう一度 Sort メソッドの直後の短いコード行を見てください。
DataList.Remove("D")
ここでは、Remove メソッドを使用して D に等しい項目を削除しています。次にスクリプトを実行した結果を示します。
A
B
C
E
さようなら D。
そしてこの一番良い部分を見逃さないでください。配列のサイズ変更や再ディメンションを行うことなく項目を削除できるのです。かっこいいでしょ。もちろん、私たちもサイズ変更や再ディメンションなどを行わずに配列に項目を追加できました。スクリプト作成がより簡単になったと思われませんか。
信じられないかもしれませんが、これでもまだ .NET Framework 配列リストを使用して行うことのできるほんの少しの部分を取り上げたとさえ言えないのです (詳細については .NET Framework SDK 配列リスト (英語) を参照してください)。
この配列リストはスクリプト ライターにとって有益でしょうか。こう考えてみましょう。.NET Framework 配列リストを見た今となっては、少なくともここで使用したような単純な項目には、もはや組み込まれている VBScript 配列を使用したいとは思われないことでしょう。
正直なところ、私たち Scripting Guy はスクリプト ライターが使用できるのはどのクラスか (および使用できないのはどのクラスか) ということに関してまだ .NET Framework を徹底的に調査してはいません。これについては現在取り組んでいるところです。とりあえず、.NET Framework SDK (英語) を自由に参照してください。この SDK ページを参照すると、ほとんどの場合、スクリプト ライターが使用できる新しくて興味深い事柄を発見できます。
たとえばどんなことがあるでしょうか。乱数を生成する方法についてはどうでしょうか。VBScript 乱数生成スクリプトを使用して 1 から 100 の乱数を生成したいですか。問題ありません。これとよく似たコードを使用するだけです。
Randomize
Wscript.Echo Int((100 - 1 + 1) * Rnd + 1)
数式を覚えましたか。覚えていなくても心配する必要はありません。.NET Framework System.Random クラスを使用する方がより簡単でより直感的であることがわかっていただけるでしょう。
Set objRandom = CreateObject("System.Random")
Wscript.Echo objRandom.Next_2(1,100)
おそらく説明なしでこれは理解できるでしょう。いずれにせよ、短いスクリプトを紹介します。なぜなら TechNet Magazine ではコラムニストは毎月何かしらのスクリプトを書かなければならないからです (なぜですかと突っ込まないでください。私たちではなく TechNet Magazine のポリシーだからです)。
ご覧のとおり、System.Random クラスのインスタンスを作成し、次に Next_2 メソッドを呼び出し、2 つのパラメータにメソッドを渡します。
  • 1、今回の範囲内の最初の数 (1 から 100 までの間で乱数を生成するということを思い出してください)。
  • 100、今回の範囲内の最大数。
これで作業は完了です。
最後にもう 1 つだけ質問に答える時間がありそうです。緑色のシャツの人、どうぞ。スクリプト ライターは .NET Framework でスクリプトが書けないと言った人は本当にいるのですか。さて、正直なところ、まず、おーっと、時間がなくなったようです。来月またお会いしましょう。
良い時、良い時
間もなく 2 月です。それが意味することは 1 つだけです。バレンタインデーではありません。大統領の誕生日でもありません。え、グラウンドホッグ・デーですか。いいえ、2 月が近づくにつれ世界で最も重要な (といってもこの世界だけでの話ですが) 国際スクリプト競技会 2007 Winter Scripting Games も近づくのです。今年の競技会はこれまでで最も大きく最も良いものになると断言できます。今回は 4 つの部門があります。
  • VBScript 初心者
  • VBScript 上級者
  • Windows PowerShell™ 初心者
  • Windows PowerShell™ 上級者
詳細については 2007 Winter Scripting Games のホーム ページ (英語) を参照してください。
はい、何でしょう。そうそう、ありがとうございました。そして、そうそう、グラウンドホッグ・デーおめでとう。

Windows PowerShell を今すぐダウンロードしてください
Windows PowerShell 1.0 はダウンロード可能になりました。そして無料です。この機会を逃さないでください。ソフトウェアのダウンロード (英語) からダウンロードしてご使用ください。

Microsoft Scripting Guyマイクロソフトの仕事をしています、というよりもマイクロソフトにより雇われています。野球をプレイしたり監督したり観戦したり (または他のさまざまな活動を) しているのでない限り、彼らは TechNet Script Center を運営しています。詳細については、http://www.microsoft.com/japan/technet/scriptcenter/default.mspx を参照してください。


 Exchange Queue &amp; A: すべての質問にお答えします (質問を作った本人ですから)
Exchange Queue & A
すべての質問にお答えします (質問を作った本人ですから)
KC Lemson and Paul Bowden

Exchange Queue and A の初回の記事へようこそ。私たちは、これから一連の質問に回答します。正直に言うと、質問は私たち自身で考えたものなので、これを Q&A コラムとして位置付けるのはフェアではないでしょう。
だれかが質問して、だれかが回答する、という状況でなければ、Q&A とは言えないからです。しかし、私たちはこれらの質問が Microsoft® Exchange Server のユーザーが抱く質問の代表的なものであることを確信しています。私たちが教訓を重視するのはそのためです。今後、皆様のご質問を心から歓迎します。ご質問は queuea@microsoft.com までお送りください。
現在のところ、このコラムは数人で交代して執筆する予定です (どの執筆者の記事が掲載されるかは見てのお楽しみです)。執筆者は全員、Exchange に長年かかわってきた者です。今月の回答 (質問もです) は、マイクロソフトの Exchange 製品チームのリード プログラム マネージャである KC Lemson と Paul Bowden が担当しました。私たちは二人とも Exchange の開発に長年携わっています。何度も異動しましたが、メッセージングから離れることはできませんでした。
KC は、この 6 年間 Exchange グループに所属し、Microsoft Outlook® Web Access (OWA) のプログラム マネージャ、Exchange のプレリリース カスタマ プログラムを担当するリード プログラム マネージャなど、さまざまな任務を果たしてきました。現在は Exchange のユーザー エクスペリエンス マネージャとして、製品デザインおよび顧客調査を担当しています。Exchange に加わる前の 3 年間は、Outlook のテスト担当者でした。電子メールに添付された実行可能ファイルをブロックすることがかなり悪いことと考えられていた時代に、添付ファイルのテストを実施していました。KC のブログは blogs.technet.com/kclemson (英語) にあります。
Paul がこの 3 年間取り組んできた Exchange Best Practices Analyzer (ExBPA) ツールはすばらしいものでした。実際、2 か月前に彼の成果に対して賞が与えられ、彼はビル・ゲイツと一緒に写真を撮りました。しかし、Exchange Server 2007 プロジェクトの終了と共に、次のことを始めるときが来ました。Paul は XML の夢からさめて、現実に戻らなければなりません。Exchange の次期バージョン (Exchange Server 2007 の出荷後すぐに作業が開始されます) のリリース マネージャに就任するのです。
ところで、このコラムのウィットに富んだネーミングをご覧いただけましたか? もちろん、私たちはこの名前を自分たちの手柄にすることはできません。KC のブログの読者に提案していただいた名前なのです (Tim、シャツは気に入りましたか?)。次点は、"Pushing the Envelope" および "When I'm X64" という名前でした。後者は KC がとても気に入ったので、www.whenimx64.com を登録し、そこから自分のブログにリンクするように設定しました。私たちが生活のすべてについて権限を持てたらいいのですが。
注記 : KC は、最初はこのコラムの名前として "The Monthly Queue and A" を提案しました。しかし、編集者に、私たちの実際の能力やスケジュールどおりに原稿を提出できるかどうかがわからないと指摘されました (編集者は私たちよりもていねいに、かつ遠慮がちに答えてくれましたが、私たちは彼の考えていることがわかりました)。同じように、私たちもこのコラムの読者からどのようなフィードバックが来るのか、そして繰り返す価値があるのかわかりません。そして、この名前に出会いました。ご意見を queuea@microsoft.com までお寄せください。
説明はこのくらいにして、質問に移りましょう。

Q なぜユーザーは Exchange Server 2007 に興奮するのでしょうか。
A 初回のコラムでマーケティングの質問を扱うのが危険であることはわかっています。しかし、私たちは Exchange Server 2007 にとても興奮しているので、皆さんとこの興奮を共有したいのです。ここでは "market-ecture" (マーケテクチャ) を制限して、Exchange の管理者やユーザーが Exchange 2007 に興奮する技術的な理由をいくつかお話しします。

スケーラビリティとパフォーマンスの向上
まず、明確なのが 64 ビットであることです。「それがどうかしたのか」と思われるかもしれません。32 ビット Windows® では、合計 4 GB (232 バイト) のメモリしかサポートできません。そのうち 2 GB は既定でカーネルが使用するため、アプリケーションで使用できるのは残りの 2 GB だけです。現行バージョンの Windows では、boot.ini で /3GB スイッチを使用することにより、最大 3 GB のメモリ ヘッドルームをアプリケーションに割り当てることができます。しかし、これを一度使用すると、Windows カーネルが多少不安定になり、やがてサーバーを再起動してリソースを解放しなければならなくなります。
さいわい、64 ビットのサポートと、Exchange の基礎となるデータベース エンジン (JET) の大幅な変更により、この問題は解決されます。Exchange サーバーは、他のシステム リソース (CPU など) よりもはるかにディスク I/O に制約されます。したがって、メモリをシステムに追加すると、メモリに情報を格納することによってディスクを読み取る必要がなくなるため、ディスク I/O を大幅に減らすことができます。その結果、Exchange 2007 では、同サイズの物理ハードウェア上で Exchange 2003 よりもはるかに大きなメールボックスをサポートできます。たとえば、マイクロソフトのメール サーバーは、2 GB のメールボックス クォータが設定された 4,000 ユーザー、合計 6 テラバイト (TB) のデータをサポートします。Exchange 2007 はもっと多くのメモリを利用できますが、それだけ多くのメモリが必要であるという意味ではありません。私たちは 32 ビットの Windows Server® 2003 と Exchange 2003 を 4 GB 以下のメモリの環境で実行してメールボックスをテストし、64 ビットの Windows Server 2003 と Exchange 2007 をインストールしましたが、パフォーマンスは変わりませんでした。
また、Exchange 2007 では、クラスタ連続レプリケーション (CCR) およびローカル連続レプリケーション (LCR) という新しい 2 つの方法により可用性が向上します。これらのテクノロジを使用すると、ストレージ障害で重大な問題が発生する危険性が低くなります。LCR はデータベースのローカル コピーを同じコンピュータ上に保管しますが、それを別のストレージ メディアに保存することもできます。CCR を使用すると、ネットワーク上の 2 台のコンピュータで同じ処理を実行できます。CCR と、このコラムで既に説明したディスク I/O の機能強化により、ストレージ ハードウェアに関する選択肢が広がりました。SATA ドライブや SCSI ドライブなどの直接接続型のストレージ メディアを使用する場合は、大幅に費用効率が高まり、パフォーマンスが向上します。

管理
マイクロソフトは、Exchange 2007 で管理を行う場合の新しい操作性に多額の投資を行いました。たとえば、図 1 に示すコマンドライン インターフェイスです。このインターフェイスは Exchange 管理シェル (EMS) と呼ばれ、Windows PowerShell™ をベースにしています。コマンド ラインが好きでない場合は、Exchange 管理コンソール (EMC) という GUI も使用できます。この GUI は、以前のシステム マネージャよりも直観的でわかりやすいインターフェイスになっています (図 2 を参照)。コマンドライン インターフェイスを既に使用しているか、これから使用する場合は、Exchange 2007 で EMS について調べてみてください。
図 1 Exchange 管理シェルでのストレージ グループ ステータスの表示
図 1 Exchange 管理シェルでのストレージ グループ ステータスの表示 (画像を縮小するには、ここをクリックします)
図 1 Exchange 管理シェルでのストレージ グループ ステータスの表示
図 1 Exchange 管理シェルでのストレージ グループ ステータスの表示 (画像を拡大するには、ここをクリックします)
図 2 Exchange 管理コンソールでの同じステータスの表示
図 2 Exchange 管理コンソールでの同じステータスの表示 (画像を縮小するには、ここをクリックします)
図 2 Exchange 管理コンソールでの同じステータスの表示
図 2 Exchange 管理コンソールでの同じステータスの表示 (画像を拡大するには、ここをクリックします)
Exchange 2003 では、複雑な管理タスクを実行するのに Windows Management Instrumentation (WMI) スクリプトを使用する必要がありました。しかし、EMS では、"CD C:\TEMP" を見て新しいバンドのアルバムと思わないユーザーであれば、だれもがこれらのタスクを実行できます。私たちの 1 人は元 UNIX のシステム管理者です。そのために私たちの客観性についてここで疑問が出るかもしれません。しかし、これまでにコマンド ラインを使用したことがないユーザーにとってもシェルがとても直観的で使いやすいということを保証してくれる多くのサード パーティを紹介できます (詳細については、次回の Exchange Queue and A コラムを参照してください)。
Windows PowerShell の美しさの 1 つは、オブジェクトベースであることです。サーバーからメールボックスまたは SMTP コネクタのリストなどの情報を取得すると、その情報は自動的にオブジェクトや変数に格納され、簡単に読み取ることができるようにテキストとして stdout に出力されます。その後、そのオブジェクトを別のコマンドに直接渡したり、パイプラインで処理したりできます (この場合は、テキストではなくオブジェクトを渡すことにより、簡単にデータを変更したりその一部を処理したりできます)。ここに簡単な例を示します。
Get-Mailbox | Set-Mailbox -ProhibitSendQuota 250MB
Get-Mailbox コマンドは、システム内のメールボックスのリストを取得します。| (パイプ記号) は、左側のコマンドの出力が右側のコマンドに渡されることを示します。次の "Set-Mailbox-ProhibitSendQuota 250MB" は、電子メールを 250 MB 以上送信できないように、すべてのメールボックスにクォータを設定することを意味します。値を 250000000、250000 KB、または .25 GB と設定することもできます。シェルは柔軟にデータを処理できます。
Exchange 2007 で管理を行う場合に役立つもう 1 つの機能強化は、トランスポート ルールを作成できるようになったことです。Outlook のウィザードによく似たルール ウィザードを使用して、システム内を流れるメッセージにビジネス ロジックを適用できます。本文に社会保障番号が含まれていると思われる電子メールを、正規表現に基づいてブロックしますか? チェックしてください。組織内の 2 つの部門間で電子メールをやり取りできないように、倫理的境界を設定しますか?チェックしてください。組織外に送信されるすべての電子メールに免責事項を追加しますか? チェックしてください。
私たちがとても興奮する管理機能の最後の 1 つは、カスタマイズ可能なシステム メッセージです。特別な構成を行わなくても、配信しないレポートや、ストレージ クォータを超えたときにユーザーに表示するメッセージに、独自のカスタム テキストを追加できるようになりました。

ヘルプ デスクの支援
多くのお客様にとって、費用の最も大きな部分を占めるのが、Outlook で新しいプロファイルを構成するときにかかるヘルプ デスク コストです。Outlook 2007 の Autodiscover を使用すると、Outlook を起動するだけで、自動的に電子メール アドレスが検索され、サービス接続ポイントを使用して Active Directory® から Exchange サーバーの情報が取得されます。Active Directory に接続していない場合は、電子メール アドレスとパスワードを入力するだけで、RPC over HTTP (今回から Outlook Anywhere という名前になりました) に使用するサーバーなどの基本構成情報が格納された指定 Web サーバー (http://autodiscover.contoso.com (英語) など) から、Autodiscover によって XML ファイルをダウンロードできます。
他にヘルプ デスク コストがかかるのは、スパム対策フィルタによる、一見避けられないと思われる誤検知の管理です。ユーザーは Outlook に送信者のセーフ リストを保管して、それらの送信者のメッセージをコンテンツ フィルタリングの対象から除外できますが、Exchange 2007 以前は、そうしたリストで回避できるのは Outlook のフィルタだけでした。しかし、メッセージは Exchange のフィルタを通ってから Outlook で調べられるため、ユーザーは信頼している送信者からの電子メールを受け取ることができない場合がありました。
Exchange 2007 はここでも次のように役立ちます。Exchange 2007 のエッジ サーバーまたはハブ サーバーの役割でスパム対策のコンテンツ フィルタを使用する場合は、ユーザーの送信者セーフ リストをそのサーバーに適用するように構成できます。これにより、そのリスト内の送信者から送信されたメッセージはスパム コンテンツ フィルタの対象から除外されます。当然のことですが、あるユーザーにとってスパムである内容が、別のユーザーにとってはニュースレターであることもあります。したがって、送信者セーフ リストはユーザーごとに作成されます。

エンド ユーザーの喜び
Exchange 2007 のユニファイド メッセージング (UM) を使用すると、送られてきたボイスメールやファックスを受信トレイで受信できます (今までにこのような経験がない場合は、何が受信できないのかさえわかりません)。また、Exchange サーバーを呼び出して、午前 8 時の会議の参加者全員に自分が遅れることを知らせるように設定することもできます。小規模の組織でも、お客様から電話があったときにシステムで正しい転送先に電話を転送できるように、容易に自動応答に独自のカスタマイズができます。UM を使用するには、IP-based PBX (IP/PBX) を使用するか、従来の回路交換ベースの PBX を Voice over IP (VoIP) ゲートウェイに接続します。
リンク アクセスは OWA 2007 の新機能です。VPN クライアントがインストールされていない状況で、会社のネットワーク上のファイル共有または SharePoint® サイトにある Microsoft Word 文書を表示する必要がある場合は、どうすればよいでしょう。問題ありません。まず OWA 2007 を読み込んでドキュメント リンクに移動します。次に、ファイル共有または SharePoint サイトの名前 (http://mysharepointsite または \\server\share) を入力し、ファイルを探して開くだけです。もちろん、管理者がこのような操作をロックできるセキュリティ制御も多数あります。たとえば、特定のリストを除くすべてのサーバーを許可する、特定のリストを除くすべてのサーバーを拒否する、ユーザーが個人のコンピュータから OWA にログインした場合にのみドキュメントへのアクセスを許可する、などの制御です。
OWA には WebReady ドキュメント表示 (専門用語で "トランスコード") も組み込まれています。これにより、適切なアプリケーションがローカルにインストールされていない場合に、特定のファイルの種類を HTML に変換するように Exchange に指示できます。Exchange 2007 では、既定で DOC、DOT、RTF、WBK、WIZ、XLS、XLK、PPT、PPS、POT、PWS、および PDF のトランスコードのサポートが付属しています。トランスコード エンジンはプラグ可能なアーキテクチャを採用しているため、新しいファイルの種類のサポートをサービス パックで追加できます。また、ユーザーにトランスコードを許可するファイルの種類を指定したり、トランスコードをまったく許可しないように指定できる管理オプションもあります。
Exchange ActiveSync® を使用して Exchange と同期するモバイル デバイスがある場合は、電子メールに返信するか電子メールを転送するときに、メッセージがテキストに変換されなくなったことがわかるでしょう。テキストは一番上に追加されますが、残りのメッセージの HTML 本文はそのままです。これは、ActiveSync をサポートするデバイスで機能します。クライアントにこの機能は必要ありません。

Q Exchange 2007 は「実稼働環境には 64 ビットのみ」と聞きました。これはどういう意味でしょうか。
A Exchange 2007 には、32 ビット版と 64 ビット版があります。64 ビット版は、コア サーバーの役割 (メールボックス、ハブ トランスポート、エッジ トランスポート、クライアント アクセス、ユニファイド メッセージング) を実稼働環境で使用することを目的としています。32 ビット版は、Exchange 2007 の新機能を評価することを目的としています。管理ツールは 32 ビットの実稼働環境でも使用できるため、64 ビットの Exchange 2007 の運用サーバーを 32 ビットの Windows XP デスクトップ コンピュータから管理できます。また、Exchange 2007 のスキーマは、ルート ドメインのコンピュータからインストールする必要があります。Exchange そのものはルート ドメインにインストールする必要はありませんが、スキーマ マスタへのネットワーク接続を維持する方法として、スキーマ拡張をルート ドメインで行う必要があります。ルート ドメインに 64 ビット サーバーがない場合は、32 ビット版から setup.exe を使用してスキーマを拡張できます。
32 ビット サーバーに何か問題があるのでしょうか。1 台のサーバー上で数千のユーザーを管理したことがあれば、その問題はまさに、前に説明したようなメモリに制限がある状況でパフォーマンスと安定性のバランスをとることであることがおわかりいただけるでしょう。この 2 年以内に新しいコンピュータを購入した場合は、既に x64 拡張に対応している可能性があります。実際、最近は、64 ビット モードに対応していないコンピュータを新しく購入するのが難しいほどです。したがって、ご使用の環境で Exchange が既に実行されているコンピュータは、64 ビットに対応していながら、ただ 32 ビット オペレーティング システムを実行しているだけかもしれません。新しい 64 ビット対応のコンピュータを手に入れたら、忘れずに Windows Server 2003 SP1 の 64 ビット版をインストールしてください。
では、セットアップ時に、実稼働環境で 32 ビットのインストールを使用しないようにという警告が表示されるのはなぜでしょうか。Exchange を複数のバージョンでコンパイルすることはとても簡単ですが、各コンポーネントは 64 ビット用に完全に最適化され、調整されています (実際、64 ビット システムのディスク I/O を機能強化するために私たちが選択したコード パスの一部が原因で、32 ビット環境でパフォーマンスが低下します)。要するに、32 ビットで使用するときは、負荷のかかる状況 (シミュレーションなど) では実行しないでください。64 ビット システムでのパフォーマンスや、サーバー上で対応できるユーザー数を正しく推測できなくなります。
さて、疑問は解決しましたか。32 ビット版の Exchange 2007 を使用してできることは、次のとおりです。
  • 実際のユーザー メールボックスが存在しないテスト サーバーで新機能を評価する。
  • 新しい管理コンソール、シェル、または OWA インターフェイスを試す (キーボードによだれをたらさないように気を付けてください)。
  • Exchange 2007 サーバーを管理する。
  • Active Directory フォレストのスキーマを拡張する。
メールボックスを移行する準備が整ったら、サーバーを 64 ビットのオペレーティング システムで 64 ビットの Exchange 2007 と共に実行する必要があります。そうしなければ、セットアップと ExBPA を自分で愚痴を言いながら行うことになります (図 3 を参照)。Paul はこれを事実として知っています。彼はコードを書いたのですから。
図 3 64 ビットのみの環境に 32 ビット版をインストールしようとした場合
図 3 64 ビットのみの環境に 32 ビット版をインストールしようとした場合 (画像を縮小するには、ここをクリックします)
図 3 64 ビットのみの環境に 32 ビット版をインストールしようとした場合
図 3 64 ビットのみの環境に 32 ビット版をインストールしようとした場合 (画像を拡大するには、ここをクリックします)

Q Exchange 2007 を実行するにはどのくらいのメモリが必要ですか。
基本インストールの場合は 1 GB 以上の物理 RAM が必要です。前に説明したように、一部のサーバーの役割はメモリを集中的に使用します。オールインワン サーバー (メールボックス、クライアント アクセス、ハブ トランスポート、ユニファイド メッセージングなど) をインストールする場合は、おそらくまず 2 GB の RAM を搭載し、メールボックスの数と使用状況に応じてメモリを拡張することになるでしょう。エッジ トランスポートの役割またはクラスタをインストールする場合は、別のコンピュータにインストールする必要があります。1 つのクラスタには、メールボックスの役割しかインストールできません。
Exchange サーバーについに 4 GB 以上の RAM を搭載できるようになったことを聞いたら驚くでしょう。現在の多くのコンピュータには標準で 6 GB または 8 GB の RAM が搭載されているので、DDR モジュールを外すか /BurnMemory を使用して RAM を 4 GB に下げるのは非常に残念なことです (残念ながら、Exchange 2003 は、4 GB 以上のメモリがある場合はパフォーマンスが低下し、不安定になります。詳細については、go.microsoft.com/fwlink/?LinkId=76537 (英語) を参照してください)。
インフラストラクチャ サーバー (ハブ、クライアント アクセスなど) の場合は、最も負荷の高い状態でも、4 GB 未満の RAM で十分です。お金をかけたくなるのはメールボックス サーバーです。新しく最適化された 64 ビットの JET のキャッシュでは、投入可能な限りのメモリを利用する必要があるでしょう。もちろん、Exchange 2003 とは違って、Exchange 2007 では最大 50 個のストレージ グループがサポートされています。
各ストレージ グループで複数のデータベースをサポートできますが、それで費用を節約できるわけではありません。特に LCR や CCR (前に説明した 2 つのデータベース レプリケーション形式) は、1 つのデータベースを持つストレージ グループでしか機能しません。一連のストレージ グループを作成するか、各ユーザーに 2 GB 以上のメールボックスを用意する場合は、RAM を追加する必要があります。RAM のサイズ決定の詳細については、「Exchange Team Blog」 (英語) が非常に参考になりますが、まずは図 4 と図 5 の表を参照してください。
Figure 5 RAM とストレージ グループ (Close Figure 5)

物理 RAM | 推奨する最大ストレージ グループ数
2 GB | 2
4 GB | 8
8 GB | 24
12 GB | 40
16 GB 以上 | 50
Figure 4 ユーザー タイプ別 RAM (Close Figure 4)

ユーザー タイプ | メールボックスの役割のための推奨メモリ
ライト | 基本 2 GB + 2 MB/メールボックス
平均 | 基本 2 GB + 3.5 MB/メールボックス
ヘビー | 基本 2 GB + 5 MB/メールボックス
ところで、Microsoft IT では多数のストレージ グループ (7 の倍数) を使用しています。これは、ストレージ グループにローテーションのバックアップ スケジュールを適用し、ある特定の曜日には一部のストレージ グループのみバックアップするからです。私たちはこのスケジュールを "candy cane backups (棒キャンディのバックアップ)" と呼んでいます。Excel スプレッドシートでバックアップ スケジュールを作成し、特定の曜日にバックアップするストレージ グループを赤の斜線で色付けしているからです。この情報がお役に立てたならさいわいです。次回は "本当の" 質問をお送りください。

KC LemsonExchange Server チームのリード プログラム マネージャです。彼女は、自由な時間を使ってナイジェリア王室の財産保護の手助けをしています。
Paul BowdenExchange Server チームのリード プログラム マネージャです。彼女は、自由な時間を使ってナイジェリア王室の財産保護の手助けをしています。Paul Bowden も Exchange Server チームのリード プログラム マネージャです。彼は、自由な時間のほとんどを、要求に応じて PayPal アカウント情報を再確認することに費やしています。


 セキュリティ ウォッチ: Windows Vista の Services Hardening
セキュリティ ウォッチ
Windows Vista の Services Hardening
Wole Moses

いくつかの強力なウイルスやワームが Windows システムに大きな損害を与え、IT 部門を混乱に陥れ、企業や個人に修復のための多額の出費を強いた直後の 2002 年初頭、マイクロソフトは信頼できるコンピューティング イニシアチブ (Trustworthy Computing Initiative) を発表しました。この中で、マイクロソフトは
これまでのセキュリティ対策の至らなさを認め、充実した機能や使いやすさを強調するソフトウェア開発から、ソフトウェアのセキュリティと整合性に重点を置く開発へと、速やかに正しい方向へ舵を切りパラダイムを変えました。2003 年 8 月に猛威をふるった Blaster ワームが、セキュリティに対するこの方針をさらに推進させました (Blaster 関連の話題については、見出し一覧の「クローンの攻撃」を参照してください)。
信頼できるコンピューティング イニシアチブの柱は、セキュリティ保護のためのコーディング哲学である「設計による安全性確保」 (Secure by Design)、既定の設定で Windows® の各コンポーネントのセキュリティが最大限強化されることを保証する「既定設定による安全性確保」 (Secure by Default)、企業や個人による Windows インフラストラクチャのセキュリティ保護を支援するツールと規範ガイダンスの作成に関連する「導入/展開時の安全性確保」 (Secure in Deployment) です。
全般的に見て、信頼できるコンピューティング イニシアチブは、セキュリティの大幅な向上につながりましたが、残念ながら、イニシアチブ開始の 2 年前にリリースされていた Windows XP はその恩恵を十分に受けることができませんでした (Service Pack 2 (SP2) にはこの哲学が大幅に採用されていますが、Windows XP をこのイニシアチブに沿って完全に作り替えることはできませんでした)。
このため、信頼できるコンピューティングの目標に完全に沿った最初のマイクロソフト オペレーティング システムは Windows Vista™ になります。Windows Vista Services Hardening (図 1 参照) は、信頼できるコンピューティング イニシアチブの既定設定による安全性確保の原則を具体的に実装したものであり、現存する悪意のあるソフトウェアの多くが実行する不適切なサービス動作を防ぐ重要な新機能です。Service Hardening により、マイクロソフトは Windows サービスの既定の動作とセキュリティ プロファイルを変更する点において大きな進歩を遂げました。
Figure 1 既定設定による安全性確保 : Windows サービス (Close Figure 1)

機能 | 説明 | 成果
最小限の特権 | Windows Vista サービスは、実行に必要な最低限の特権を使用するよう構成されています。 | Windows Vista は、Windows サービスに付与される既定のセキュリティ特権のレベルを低くし、悪意のあるソフトウェアによる潜在的な影響を抑えます。
サービスの分離 | サービス SID を使用して、サービスを特権の低いアカウントで実行できるようにします。 | Windows Vista は、サービスの SID に基づいてリソースへのアクセスを制限することで、悪意のあるソフトウェアによる操作を封じ込めています。
ネットワーク アクセスの制限 | すべての Windows Vista サービスでは、ネットワーク制限が既定で実装されています。 | Windows Vista では、悪意のあるソフトウェアがサービスを使用して不正なネットワーク アクティビティを実行することを防ぎます。
Session 0 分離 | Session 0 はサービス専用に予約されています。 | Windows Vista では、悪意のあるソフトウェアは特権の高いサービスと同じセッションで実行できないので、メッセージ ベースの攻撃で特権の高いサービスを乗っ取ることができません。

サービスの危険性
NT サービスとして知られてきた Windows サービスは、稼働期間の長い実行可能アプリケーションであり、専用の Windows セッションで実行されています。サービスは、コンピュータの起動時に自動的に開始でき、一時停止や再開が可能です。また、通常はユーザー インターフェイスは表示されず、ログオンしたユーザーとも既定のコンピュータ アカウントとも違うアカウントのセキュリティ コンテキストで実行できます。このため、Windows サービスは、ある種のアプリケーション開発やそうしたアプリケーションを必要とするエンド ユーザーにとって、非常に便利なものです。その一方で、こうした機能と柔軟性により、従来の Windows サービスは脆弱でもありました。これにはいくつかの理由があります。
まず、これまで、Windows サービスはローカル システム アカウントなどの特権の高い Windows アカウントで実行されるのが一般的でした。ローカル システム アカウントで実行されているサービスが悪意のあるソフトウェアによって悪用されると、システムはそのソフトウェアの意のままに攻撃を受ける可能性が非常に高くなります。たとえば、Windows XP のリモート プロシージャ コール (RPC) サービスはどうでしょう。Windows XP SP2 より前は、RPC サービスはローカル システム アカウントで実行されていたので、Blaster や Welchia などのワームは RPC の脆弱性を悪用して管理タスクを実行できました。
次に、サービスの多くがネットワーク対応なので、悪意のあるソフトウェアが、ネットワーク経由の受信接続を作成することによってサービスを悪用したり、感染したサービスが、送信接続を作成して他のシステムを感染させたりキーストロークを盗んで転送したりするなどの不正行為を働いたりするおそれがあります。今日のほとんどのワームや悪意のあるソフトウェアによる感染は、何らかの形でネットワーク接続を介して発生しています。
最後に、サービスは実行期間が長く、システムが起動されてからシャットダウンされるまで実行されるのが普通です。これは悪意のあるソフトウェアの作成者にとって好都合です。なぜなら、システムが動作している間中サービスの欠陥を探すことができ、不法行為を実行できる時間を十分確保できるからです。

クローンの攻撃
その男は大勝利を目前に控えていました。なにもかも計画どうりに進めば、世界中の数十万の Windows システムを思いのまま動かすことができるようになり、好きな指令を出しては、椅子にゆったり腰掛けて、世界中にあるコンピュータがあらゆる指令に忠実に従うのを眺めていられるのですから。
男がとった方法は、根気が要りますが、発見されづらいものでした。まず、いくつかのコンピュータ システムに探りを入れ、脆弱なエントリ ポイントを探しました。望ましいエントリ ポイントを探すのに、それほど時間はかかりませんでした。既知の脆弱性に対するセキュリティ更新プログラムが適用されていないシステムに侵入する方法を、男は完璧に把握していたのです。
標的となった脆弱性が災いの元となったのは、そこから侵入されると、システムに対する管理権限が男の手に渡ってしまうからでした。普通のアカウントを使えるようになるのとは訳が違います。Windows で最も強力な管理アカウントを操作できるようになったのです。これで、思いつくまま好きなことができるようになりました。
男はしばらく考えてから、セキュリティ更新プログラムが適用されていない脆弱なコンピュータ用に作った悪意のあるコードを試してみました。すると、うまく動作したのです。たったこれだけで、男は侵入したコンピュータに対する無制限の特権を手に入れました。そしてそれを利用して、侵入したコンピュータにトロイの木馬コードをダウンロードしてインストールさせ、レジストリを変更し、コンピュータを再起動させ、感染したシステムを自分に代わって忠実に指示を実行するように仕立て上げました。男が行ったレジストリ変更により、侵入されたコンピュータでは起動されるたびに悪意のあるソフトウェアが実行されるようになりました。
ここで、男の意図がはっきりしてきました。感染したコンピュータは、接続されているネットワーク上に存在する他のすべてのコンピュータについて、特定のネットワーク ポートに探りを入れ始めました。目的のネットワーク ポートが開いていたコンピュータのセキュリティが脆弱だった場合は、そこにトロイの木馬コードがダウンロードされてインストールされました。レジストリも同じように改ざんされました。このサイクルが次々と繰り返され、攻撃クローンの大軍が作り上げられました。その日のうちに、世界中の何千という Windows システムが、男の指示以外にはまったく従わない邪悪なクローン軍に加わりました。
それでもまだ不満だったようで、男は照準をマイクロソフトの Windows Update サイトに合わせ、2003 年 8 月 15 日に、世界中のコンピュータが脆弱性修正プログラムをダウンロードできなくするサービス不能攻撃をしかけるよう、クローンに命じました。ちなみに、その脆弱性修正プログラムは、公開されてから数か月以上経っていたものでした。
ここまでお話すれば、これが 2003 年 8 月に世界中の Windows コンピュータを襲った MS Blaster ワーム大流行の顛末であることにお気付きでしょう。Blaster による攻撃は、Windows に対する最も深刻な攻撃の 1 つに数えられており、何十億ドルという損害を与えました。MS Blaster は感染したコンピュータに対して絶大な力を持つのですが、皮肉なことに、その実装は実にシンプルでした。

Blaster のしくみ
Blaster とその派生物は、Windows RPC サービスの脆弱性を使用してバッファ オーバーフローを引き起こします。この脆弱性を突くことに成功した攻撃者は、感染したシステムでローカル システム権限を使用してコードを実行して、プログラムをインストールしたり、データを表示、変更、または削除したり、完全な特権を持つ新しいアカウントを作成したりできるようになります。
Blaster は、ネットワークを自動的にスキャンして、TCP ポート 135 が開いているコンピュータを探します。そうしたコンピュータが見つかると、Blaster は RPC の脆弱性の悪用を試みます。成功すると、そのコンピュータのポート 4444 に接続し、Trivial File Transfer Protocol (TFTP) を起動させ、感染したシステムから MSBLAST.EXE という自身のコピーをダウンロードさせます (TFTP は、Windows 2000、Windows XP、および Windows Server 2003 にオペレーティング システムの一部として含まれています)。攻撃元の感染したシステムは、新たに感染したコンピュータに MSBLAST.EXE を起動するよう指令し、感染したコンピュータは攻撃側に加わります。また、Blaster はコードを HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft \Windows\CurrentVersion\Run レジストリ キーにも書き込み、そのコンピュータが起動されるたびに自身が実行されるようにします。

Services Hardening
Windows Vista では、サービスの最小限の特権での実行、サービスの分離、ネットワーク アクセスの制限、Session 0 分離という 4 つの方法でサービスのセキュリティを強化しています。以下でそれぞれについて説明します。
最小限の特権での実行 多くの Windows サービスが、Windows で最も強力なアカウントであるローカル システム アカウントのコンテキストで実行されていました。ローカル システム アカウントのユーザー権限や特権を使用すると、ほとんどすべてのシステム オブジェクトや他のユーザーのプロファイルにアクセスしたり、ユーザーを偽装したり、HKLM\SECURITY などの重要なレジストリ キーを開いたり、コンピュータの資格情報をリモート サーバーに送信したりできます。悪意のあるソフトウェアの作成者はこのレベルで Windows に対してアクセスと制御ができることを好むので、ローカル システム セキュリティのコンテキストで実行されているあらゆるサービスが魅力的な標的になります。
現実には、多くの Windows サービスがローカル システム アカウントで実行されるよう構成されていますが、そのほとんどは、ローカル システム アカウントにしかない特権のうちの一部だけを必要としています。残念ながら、Windows XP や以前のバージョンの Windows は「全部かゼロか」で動作するので、必要な特権だけを選択するメカニズムはありません。こうして、多くの Windows サービスが、不要なセキュリティ特権を持ったまま実行されています。
Windows Vista Service Hardening では、この問題に対応するため、最小限の特権という概念をサービスの構成に導入しています。最小限の特権を使用することで、サービスは、ログオンに使用するアカウントに割り当てられている既定の特権をすべて持つのではなく、機能するために必要最小限の特権だけを持って実行されるようになります。
たとえば、あるサービスでは、オペレーティング システムの一部として動作する必要があるが、セキュリティ トークンを作成する必要がないとします。最小限の特権を使用すると、トークン作成特権を除外できます。これにより、後でサービスに脆弱性が見つかるような事態になっても、攻撃による被害が抑えられます。開発では、SC.exe (図 2 参照) などのツールを使用したり、プログラム的な方法を使用するなどして、個々のサービスで必要となる特権を定義および指定できます。Windows Vista のすべてのインストール済みサービスでは、既定で特権が最小限になっています。特別な構成をする必要はありません。
図 2 SC コマンド オプションは Windows Vista のサービス特権を定義します。
図 2 SC コマンド オプションは Windows Vista のサービス特権を定義します。 (画像を縮小するには、ここをクリックします)
図 2 SC コマンド オプションは Windows Vista のサービス特権を定義します。
図 2 SC コマンド オプションは Windows Vista のサービス特権を定義します。 (画像を拡大するには、ここをクリックします)
サービスの分離 Windows Vista より前の Windows では、サービスで特権オブジェクト (重要なレジストリ キーやファイルなど) にアクセスする必要が生じた場合、サービスがアクセス権を取得する方法には次の 3 つがありました。ローカル システム アカウントを使用してオブジェクトにアクセスする方法、レジストリ キーまたはファイルのセキュリティを低くして特権レベルの低いアカウントでもアクセスできるようにする方法、およびサービス専用のアカウントを作成して、オブジェクトへのアクセスをそのアカウントだけに許可する方法です。
どの方法も機能しますが、それぞれに基本的な問題があります。最初の 2 つはそもそも危険性が高く、最後の 1 つも新しいアカウントのパスワードを手動で管理する必要が生じることが頭痛の種になります。
たとえば、ウイルス対策プログラムが、ウイルス シグネチャ ファイルやウイルス対策ソフトウェア関連のレジストリ エントリなど、重要なシステム オブジェクトにアクセスする必要があるサービスをインストールするとします。ウイルス対策ソフトウェアが、必要なオブジェクトにアクセスするのに、ローカル システム アカウントや、その他の組み込みセキュリティ アカウントを使用するよう構成されていた場合、こうしたアカウントを使用する Windows サービスが悪意のあるソフトウェアによって感染すると、悪意のあるソフトウェアが、ウイルス対策シグネチャ ファイルにアクセスして書き換えたり、レジストリ設定を変更してウイルス対策ソフトウェアの動作に影響を及ぼしたり、ウイルス対策サービスそのものをシャットダウンしたりする可能性があります。現実にも、今日の悪意のあるソフトウェアはまさにこうしたテクニックを使用して機能したり自身の存在を隠したりしています。
Windows Vista では、セキュリティや管理に対するこうした懸念にサービスの分離で対応しています。サービス セキュリティ ID (SID) を含むアクセス制御エントリを使用して、ファイルやレジストリ キー アクセスなどのリソースのセキュリティを保護することで、サービスがオブジェクトを排他的に使用できるようになります。上記の例で説明したウイルス対策サービスは、特権レベルの低いアカウントで実行されても、重要なシグネチャ ファイルやレジストリ キーへのアクセスを確保できます。こうしたアクセスを実現するには、(特権の低いアカウントで実行されている) ウイルス対策サービスに Windows Vista によって SID が割り当てられる必要があります。SID が割り当てられると、ウイルス対策プログラムは、ファイル システムとレジストリ オブジェクトのアクセス制御リスト (ACL) を変更して、ウイルス対策サービスに排他的なアクセス権を付与できます。
もう 1 つ例を示します。2003 年のことですが、Welchia ワームが RPC の脆弱性を悪用して、自身を %System%\Wins\Dllhost.exe に書き込みました。また、感染した Windows システムに自身のサービスをインストールするために、キーを HKLM\SYSTEM\CurrentControlSet\Services に追加しました。しかし、Windows Vista であれば、どちらの場所にも特定の適切なサービスしかアクセスできないようにし、サービスにはアクセス用に特権の低いアカウントを付与することで、Welchia を封じることができたでしょう。
ネットワーク アクセスの制限 Windows Vista には、Windows XP SP2 ファイアウォールで実装された機能の上に構築された新しいファイアウォールが導入されています。主な新機能には、送信フィルタと IPsec 統合があります。また、新しいファイアウォールは Windows Vista Services Hardening と統合されており、悪意のあるソフトウェアが改ざんされた Windows サービスを使用して不適切なネットワーク アクティビティを実行することが困難になっています。
Windows Vista ファイアウォールでは、サービスの動作に制限を加えるネットワーク ファイアウォール ポリシーが Windows サービスに割り当てられます。たとえば、プラグ アンド プレイのようなサービスには、ネットワーク ポートを介した通信が不要なので、「ネットワーク アクセスなし」の制限が割り当てられます。この制限が適用されていると、そのようなサービスを標的にした改ざんでは、ネットワーク ベースのアプローチでは目的のサービスに到達できません。制限が適用されたサービスで通信しようとしても、それが送信でも受信でも、ファイアウォールによってブロックされます。ネットワークへのアクセスが必要なサービスについては、特定のポートだけを使用するよう構成できます。開発では、この機能を利用して、サービスのネットワーク アクセスを制限できます。
ネットワーク関連の制限を Service Hardening と組み合わせることで、サービス ベースの潜在的な攻撃に対する堅牢な防御を実現できます。これは、Windows の以前のバージョンに比べて大きな進歩です。これまでの Windows には、どのサービスがどのような方法でどこからネットワークと通信できるかを指定する方法がありませんでした。一方、Windows Vista Firewall Network 制限を RPC サービスに適用することで、Blaster、Sasser、Welchia などのウイルスが、感染したサービスを使用して他のコンピュータと通信することはできなくなります。
Session 0 分離 Windows XP のユーザーの簡易切り替えでは、各ユーザーを異なる Windows セッションに割り当てることで、ユーザーの同時ログオンを実現しています。Session 0 は起動時に作成され、その後も必要に応じてセッションが追加されます。サービスは常に Session 0 で実行されますが、Windows Vista より前では、ユーザー アプリケーションも Session 0 で実行できます。しかし、ユーザー アプリケーションと Windows サービスが同じセッションで実行されるということには、セキュリティ リスクが伴います。なぜなら、サービスは特権レベルで実行されているので、悪意のあるソフトウェアが自身の特権レベルを上げる手段として標的にするからです。
Windows Vista では、こうしたセキュリティ リスクに対応するため、Session 0 をサービス専用にしてアプリケーションは別のセッションで実行し、また Session 0 を非対話型にしました (つまり、サービスは、ユーザーがアクセスできるダイアログ ボックスやプロンプトなどのユーザー インターフェイスを作成できません)。こうした変更を伴うので、Session 0 の分離は、Windows サービスまたはドライバの開発においてアプリケーションの互換性に影響を与えます。

まとめ
Windows Vista は、マイクロソフトがリリースする初めての完全な信頼できるコンピューティング デスクトップ オペレーティング システムで、Windows ユーザーの保護を目指して進歩していくことでしょう。当然のことながら、コンピュータ セキュリティはますます重要になり、悪意のあるソフトウェアの作成者は Windows を悪用する新たな方法を探したり、試したり、研究したりし続けることでしょう。それでも、Windows Vista の新しい Service Hardening 機能により、既定のセキュリティ設定の強化や攻撃を受ける可能性を低減することで、敷居は一段と高くなっています。これらの大幅な機能強化の詳細については、http://www.microsoft.com/japan/whdc/system/vista/Vista_Services.mspx を参照してください。

Wole MosesMicrosoft Regional Windows Lead で、在籍 8 年のベテランです。現在 Wole は、トルコのイスタンブールを拠点に、急速に拡大する中東およびアフリカ市場の顧客に対し、IT インフラストラクチャの最適化と最大限のセキュリティを両立させるため、マイクロソフト ベースのソリューションの構想と設計を支援しています。


 デスクトップ ファイル: Windows 自動インストール キット
デスクトップ ファイル
Windows 自動インストール キット
Wes Miller

マイクロソフトは、Windows Deployment チームが開発した 2 つのバージョンの展開ツールをこれまでに提供してきました。最初のバージョンは、deploy.cab ファイルの形式で、何年も Windows CD-ROM に同梱されていました。ドキュメントと、無人セットアップ ファイルを作成するためのツール (セットアップ マネージャなど) や
展開するデスクトップの準備に使用する Sysprep ツールなどが付属していました。展開ツールのもう一方のバージョンは、OEM プレインストール キット (OPK) でした。これは、特に OEM システムの製造元のニーズを満たすように設計され、それらの製造元しか利用できませんでした。Windows® PE は、もともとこの方法で配布されました。Windows Vista™ 用の新しいバージョンの OPK がありますが、これも引き続き OEM でのみ利用できます。
さいわい、他の多くのマイクロソフト ユーザーは (一部のユーザーは Windows XP タイムフレーム中に Windows PE を取得できませんでしたが)、Windows 自動インストール キット (WAIK) という OPK によく似たツールを利用できるようになります。WAIK は、Windows Vista の出荷後に www.microsoft.com/downloads/search.aspx?displaylang=ja から無料でダウンロードできます。このツールには、Windows PE 2.0、Windows Deployment Services、ImageX、および Windows System Image Manager が含まれます。Windows System Image Manager は、これまでに説明しませんでしたが、セットアップを自動化する unattend.xml ファイルを作成できるツールです。すべてのツールのドキュメントも付属しています。
WAIK を入手する方法としてお薦めするのは、microsoft.com/japan/technet/desktopdeployment から完全な Microsoft Solution Accelerator for Business Desktop Deployment 2007 (BDD) をダウンロードすることです。これにより、WAIK だけでなく、ユーザー状態移行ツール (USMT) や Application Compatibility Toolkit (ACT) も入手できます。他にも、BDD には Windows Vista を正しく展開するためのツールとガイドが含まれています。

Windows PE 2.0
ｎ
図 1 実行中の ImageX コマンドライン ツール (画像を縮小するには、ここをクリックします)
図 1 実行中の ImageX コマンドライン ツール
図 1 実行中の ImageX コマンドライン ツール (画像を拡大するには、ここをクリックします)
後で説明する Windows Deployment Services (WDS) は、イメージを簡単にキャプチャできる軽量の GUI ツールを提供しますが、このツールには ImageX の完全な機能は備わっていません。ImageX が Windows PE で展開用のイメージをキャプチャするように設計され、テストされていることも重要です。実際に稼働している Windows システムの "生の" キャプチャを行うようには設計されていません。
他のシステム イメージング ツールに慣れている方は、ImageX もある程度使用できるでしょう。イメージを容易にキャプチャして適用できるように、簡単に使用できる設計になっています。そのうえさらに、これまでよく使用されていた展開ツールにはない重要な機能が備わっています。たとえば、すぐに思いつくのは、イメージをローカル ファイル システムの一部として簡単かつ透過的にマウントできる機能です。この機能を使用すると、既存のイメージ内からファイルの表示、変更、または削除が可能になります。
ImageX には、図 2 に示すイメージ操作スイッチがあります。ここで 2 つのコマンドを取り上げて詳しく説明します。
Figure 2 イメージ操作スイッチ (Close Figure 2)

図 3 Windows System Image Manager (画像を縮小するには、ここをクリックします)
図 3 Windows System Image Manager
図 3 Windows System Image Manager (画像を拡大するには、ここをクリックします)
左上にある [配布共有] ペインには、SIM で追加したドライバとその他のパッケージが表示されます。既定では、配布共有はマウントされませんが、簡単に開いたり作成したりできます。
[配布共有] ペインの下にある [Windows イメージ] ペインには、WIM 内の特定の Windows ボリューム イメージの構成オプション (コンポーネントとパッケージ) が表示されます。一度にマウントできる Windows ボリューム イメージは 1 つ (Windows Vista DVD 上の 1 つの SKU) です。
中央にある [応答ファイル] ペインには、新規または既存の Windows Vista の無人セットアップ ファイルの構成オプションと、マウントした WIM ボリューム イメージのカタログで定義されている既定の設定 (使用可能な設定と構成) が表示されます。
ウィンドウの右上にある [プロパティ] ペインでは、[応答ファイル] ペインのコンポーネントの各プロパティを編集できます。
一番下にある最後の [メッセージ] ペインには、詳細なフィードバックが表示されます。たとえば、Windows Vista の無人セットアップ ファイル (常に XML 形式) の生の XML や、現在使用している構成セットに関連する検証出力やメッセージなどがあります。[構成セット] タブには、構成セットを開いている場合にのみデータが表示されます。
これまでの説明からわかるように、WAIK には、Windows Vista の展開に役立つ強力なツール セットが用意されています。Windows Deployment チームは、Windows Vista を過去の Windows バージョンよりも簡単に展開できるツール コレクションの作成という大きな仕事を成し遂げました。

Wes Millerテキサス州オースティンにある Pluck 社 (pluck.com) の開発マネージャです。以前は Winternals Software 社に勤務し、その後はマイクロソフトで Windows のプログラム マネージャ兼プロダクト マネージャとして働いていました。Wes は、このコラムに協力してくれたマイクロソフトの Scott Dickens と John Macintyre に感謝しています。Wes の連絡先は、technet@getwired.com (英語) です。


 フィールド ノート: 義母のテクニカル サポート
フィールド ノート
義母のテクニカル サポート
James Snell

結婚しました 昨年のことです。ただ、美しい妻を迎え入れるのと引き換えに、妻の家族全員に対するテクニカル サポート契約を結んだことになっているようです。先日も、おろおろする義母から「ねえ、あなた、コンピュータに詳しいのよね」という電話を受けて行ってみると、義母の Windows® XP コンピュータはよくあるスパイウェアやアドウェア、ツールバーなどのオンパレードになっていました。
IT のプロなら、コンピュータの修理はお手の物です。でもそれが親族のものとなると、話は簡単ではありません。感染したコンピュータを直す最も手っ取り早い方法は、ハード ディスクをフォーマットして Windows を再インストールすることですが、たいていの人はデータが全部なくなるのは嫌だと言って拒むので、しかたなく延々とクリーンアップを繰り返す羽目になります。そのうえ、そのコンピュータが手元になかったり、インターネットに接続できなかったとしたら、どうすればいいでしょうか。
このような事態には、512MB USB キーを用意して、ウイルス対策ソフトウェア、スパイウェア対策ソフトウェア、パーソナル ファイアウォール ソフトウェアなどを集め、ツールキットを作っておきます。そして、更新を怠らず、いつも手元に置いておきます。
Windows XP Service Pack 2 (SP2) を USB ドライブに載せておくこともお勧めします。現在の Windows XP は最初から SP2 ですが、義母のバージョンはそれ以前のエディションでした。Windows XP SP2 のインストールは、http://www.microsoft.com/japan/technet/prodtechnol/winxppro/maintain/winxpsp2.mspx からダウンロードできます (複数のコンピュータ用のバージョンが必要です。単一コンピュータ用のインストール環境では Windows Update を使用します)。266MB もあるので、ダウンロードに時間はかかりますが、一度で済みます。
さて、半日かけて、フォーマットしてから OS をインストールするか、または、ウイルスやスパイウェアをこつこつ削除した後、Windows に必要なソフトウェア更新を適用して、ファイアウォールを追加し、ウイルス対策定義を更新したりしたとします。次に何をすればいいでしょうか。少なくとも毎週末この作業にかり出されないようにはしたいものです。いくつかの方策を施すと、こうした事態をできるだけ避けることができます。

ジャンクウェアを消せ!
義母のシステムは、それなりに役に立つものからまったくのジャンクまで、主に友人にインストールしてもらったソフトウェアでいっぱいでした。これが繰り返されないようにするため、管理者アカウントに強力なパスワードをかけ、義母を標準ユーザーとしてセットアップし、管理者アカウントをめったに使わずに済むようにしました。今度だれかが義母のために何かをインストールしようとしても、そのためには管理者としてログインしなくてはいけなくなるので、それだけでも抑止力になります。あとは、ちょっとしたユーザー教育を施しておけば、ジャンクははびこらなくなるでしょう (Get Safe Online (getsafeonline.org、英語) には、PC の安全を守るための優れたヒントが掲載されています)。
義母のセキュリティ ニーズは、パスワードに関しては普通とは違っています。わたしは義母のユーザー アカウントのパスワードは解除し、義母にはその状態のまま使うよう勧めました。結局、悪意があってコンピュータに物理的に近づく者がいるとした場合、本体からデータを盗むくらいなら、本体を家から持ち出すと考えたからです。
コンピュータの前面にある扉の内側に、付箋 (管理者パスワードなどのメモ) を付けておくのは、ばかげたことのように思われるかもしれません。しかし、わたしが知らないうちに義母に管理者パスワードを知られてしまったら、という心配はしていません。そもそも、義母のコンピュータなのですから。企業ではベスト プラクティスとは認めてもらえない話ですが、機密データはないし、義母もコンピュータを他人に使われることを気にしていません。この場合の目標は、義母がユーザーとして楽をすること、そしてもっと重要なことは、義母のテクニカル サポート エンジニアであるわたしが楽をすることなのです!

敵をはね返せ!
次のステップは、保護をもう少し強化することです。わたしは、ファイアウォールが Windows に統合されていること、そしてサードパーティ製のファイアウォールが存在することを評価しています。しかし、ファイアウォール 1 つだけで保護できるとまでは信頼していません。安全性を高めるため、義母はいま、ファイアウォールが統合されている ADSL ルーターを使っています。たしかに、出費はかさむし、設定して実行する手間もかかります。しかし、保護は確実に強化されます。そして、ルーター本体では LED がピカピカ光ります。なかなかいいでしょう?
ただし、ルーターの初期構成は安全ではないことは覚えておいてください。いくつか調べた中には、Web インターフェイスと telnet インターフェイスの既定の設定が、外部と接している側で有効になっているものがありました。面倒がらずに、高度な設定オプションを確認してください。
ソフトウェア ファイアウォールを実装するには、ネットワーク コンポーネントが稼働している必要があります。起動の初期段階の保護機能は Windows ファイアウォールだけです (これも、コンピュータをインターネットに接続する前に Windows SP2 をインストールしておく必要があるもう 1 つの理由です)。Windows ファイアウォールを無効にしたとしても、ユーザーが選んだファイアウォールを起動するまでは、Windows ファイアウォールによって保護されます。また、ルーター ファイアウォールを設定しておけば、ルーターは別のデバイスなので、何かのソフトウェアによって電源が切られることはありませんし、電源が切られているときは、義母は使っていません。この方法を、わたしはデータの二重ロックに相当するものと考えています。攻撃が成功するには、ルーターとソフトウェア ファイアウォールを同時に破る必要があります。不可能ではありませんが、ほとんどありえません。

手間をかけても保護する
適切なバックアップがあれば、こうした対策全体がどれほど楽になることでしょう。わたしは、最も大事な情報だけでもバックアップを取ろうとしない人には我慢なりません。DVD はレコーダもメディアもそれほど高くありませんし、Windows にはバックアップ ソフトウェアが付属しています。問題は、ほとんどの人が使おうとしないことです。義母相手の解決策は、マイ ドキュメント フォルダの標準バックアップを定期的に行うことと、ファイルを CD 書き込みフォルダ (%userprofile%\Local Settings\Application Data\Microsoft\CD Burning) に直接保存することです。これを成功させるためには、スケジュール タスクがユーザーのログオン中にだけ実行されるようにする必要があります。CD 書き込みウィザードが定期的に (うっとうしい) プロンプトを表示して、義母が空のディスクを挿入するまで待ちます。義母がそれに従ってくれれば、わたしはもう満足です。

コミュニケーション
Windows Live™ Messenger をセットアップすると、デスクトップ共有を構成できます。こうしておくと、家に帰った後に何かをセットアップする必要が生じても、再び駆けつけることなく (必ず喜ばれますが) 、何が起こっているのかがわかります。ちなみに、リモート コンピュータを管理できることや (もちろん権限が要りますが)、こちらがマウスを動かすと向こうでもわかることは、ルーターの LED がピカピカ光ることより感心されています!

James Snellイギリス在住の元マイクロソフト サポート担当者です。これまで、ホーム ユーザーやマイクロソフトの世界最大規模の顧客に対応してきました。現在は父親業という新たな分野でスキルを磨いています。James の連絡先は James.Snell@lineone.net (英語) です。


 Windows 秘話: DLL Hell からの脱却
Windows 秘話
DLL Hell からの脱却
Raymond Chen

DLL HELL 問題が知らない間に進行するため、このような軽蔑的なニックネームが付いています。あるプログラムをインストールしたら、突然、関係がないと思われるプログラムが停止することがあります。これは、知らない間に、共有 DLL ファイルで 2 つのプログラムが関連付けられているからです。システム ディレクトリに必要な MSVCRT.DLL ファイルについて、2 つのプログラムで想定されているバージョンが異なる可能性があります。つまり、1 つ目のプログラムが ActiveX® コントロールをアップグレードした場合、同じコントロールを使用する 2 つ目のプログラムがそのアップグレードされたコントロールとまったく互換性がないかもしれません。
両方のプログラムが会社の日常業務に不可欠である場合は、どちらのプログラムに原因があるかは問題ではありません。重要なのは、2 つのプログラムを開始して実行する必要があるということです。"損をする" と "誰かのせいで損をする" に大きな違いはありません。どちらにしても、あなたの会社は損をしており、問題をすぐに解決するのがあなたの仕事です。
以前は、どちらのプログラムを優先させるかを選択する必要がありました。Windows® 2000 から、このような競合の解決策が利用できるようになりました。しかし、これらはシステムを立て直すことのできる一時的な解決策にすぎず、競合を完全に解決できる方法を調べる必要があります。
Windows 2000 では、現在ダイナミックリンク ライブラリ リダイレクトという名前で知られている機能の基本バージョンが実装されました。DLL リダイレクトを有効にするには、リダイレクトする DLL を持つプログラムと同じ名前のファイルを作成し、そのファイル名の最後に .local を付けます。たとえば、リダイレクトを C:\Program Files\Litware Inc\Invoice.exe に適用するには、C:\Program Files\Litware Inc\Invoice.exe.local というファイルを作成します。ファイルの内容は重要ではありません。重要なのはファイルの存在です。
プログラムのリダイレクトを有効にすると、そのプログラムが DLL を読み込もうとするたびに、まずプログラムが格納されているディレクトリ、次に通常の検索場所、の順に検索が行われます。したがって、MSVCRT.DLL ファイルが競合する場合は、各プログラムのリダイレクトを有効にして、MSVCRT.DLL の個人用コピーを各プログラムのインストール ディレクトリに格納します。各プログラムは、独自のバージョンの MSVCRT.DLL、つまりプログラムのテストに使用された バージョンの DLL を受け取ります。
この手法の不思議なところは、プログラムが完全なパスを使用して DLL を読み込む場合でも機能するということです。たとえば、プログラムが C:\Program Files\Common Files\Proseware Inc\taxplugin.dll を読み込もうとしているとします。Proseware 2.0 にアップグレードした後で、あなたはその tax プラグインが invoice プログラムと互換性がないことに気付きます。そこで、tax プラグインの古いバージョンを C:\Program Files\Litware Inc\taxplugin.dll にコピーします。プログラムが完全なパスを使用して tax プラグインを読み込んでも、DLL リダイレクトによって現在のディレクトリが検索され、Proseware Inc ディレクトリのプラグインの代わりにローカルのプラグインが優先的に使用されます。
Windows XP と Windows Vista™ では、DLL リダイレクトのルールが少し異なりますが、一般原則は同じです。.local ファイルの他に、.local ディレクトリも作成できます。その場合は、プログラムのインストール ディレクトリではなく .local ディレクトリが検索されます。これにより、リダイレクトを同じディレクトリ内の複数のプログラムに、競合することなく適用できます。
アプリケーション マニフェストを含むプログラムにはリダイレクトを適用できません。いわゆる既知の DLL もリダイレクトできません。詳細については、「Dynamic-Link Library Redirection」 (英語) を参照してください。
DLL リダイレクトを使用しても、DLL Hell から完全に抜け出すことはできません。しかし、問題を解決しながら、少なくともその傷口を応急的に処置することはできます。
図 1
図 1

Raymond Chen彼の Web サイト「The Old New Thing」 (英語) および彼の最新の著書『The Old New Thing』 (英語)(Addison-Wesley、2006 年) で、Windows の歴史と Win32 プログラミングについて執筆しています。ただし、彼が The Old New Thing という名前の猫を飼っているわけではありません。