8 月号 2008 8 月号 2008
SQL Server: 効果的なデータベース メンテナンスのヒント
経験を積んだデータベース管理者以外のメンバが、なんらかの理由でデータベースの責任者になることは非常によくあります。これらの責任者はデータベースをメンテナンスするための適切な教育を受けていないため、十分な知識がなく、それによって問題が発生します。この記事では、データベース メンテナンスのベスト プラクティスに関する短期集中コースの受講を必要とする、すべての不本意な DBA の皆さんを対象にした手引きを提供します。 Paul S. Randal
Windows の管理: サーバーのパフォーマンスを測定する
ユーザーから、サーバーの処理速度が遅いという不満が寄せられています。この問題を診断するにはどうすればよいでしょうか。パフォーマンス モニタは多くの診断機能を備えており、このような場合に欠かせないツールです。この記事では、サーバーのパフォーマンスを低下させる可能性がある一般的なボトルネックの診断に使用できる重要な指標について概説します。 Steven Choy
System Center: System Center Operations Manager で Windows PowerShell を使用する
Windows PowerShell が System Center Operations Manager 2007 に統合されたことによって、一般的な管理タスクを実行および自動化するための強力な方法が提供されます。この記事では、OpsMgr で Windows PowerShell を使用して、定期的なメンテナンス作業やエージェントの管理などを行う方法について概説します。 Marco Shaw
インターネット インフォメーション サービス: ASP.NET アプリケーションを拡張する : 得られた教訓
ASP.NET アプリケーションの拡張を成功させるには、アプリケーション ライフサイクルの早い段階で、開発者とネットワーク管理者が共同作業を行う必要があります。この記事では、アプリケーションの拡張に必要な要素、およびアプリケーションを意図したとおりに動作させるためにこの共同作業がどのように役立つかについて説明します。 Richard Campbell
Columns
編集長から: Tech•Ed の会場からお伝えします: | レター: 読者の皆さんからの声: | ツールボックス: IT プロフェッショナル向けの新製品:
SQL に関する Q&A: パーティション分割、整合性チェックなど: Paul Randal が、SQL Server に関する質問にお答えします。今月は、非常にサイズの大きなデータベースに対して整合性チェックを実行する方法や、不慮のアップグレードに対応する方法などについて説明します。Paul S. Randal | ユーティリティ スポットライト: Windows Installer CleanUp ユーティリティ: Windows インストーラの構成情報が残っていると、アプリケーションの更新またはアンインストール時に問題が発生することがあります。Windows Installer CleanUp ユーティリティを使用すると、この問題を解決することができます。このユーティリティは、アプリケーションの Windows インストーラ情報を削除し、そのアプリケーションを再インストールするのに役立ちます。Lance Whitney | SharePoint の内部: メッセージング統合のトラブルシューティング: SharePoint と安全なメッセージング環境を統合するのは簡単な作業ではありませんが、システムの統合によってもたらされる生産性の向上を考慮すると、この少し困難な作業には取り組む価値があります。この記事では、メッセージング環境の設定中に発生する可能性がある問題のトラブルシューティング方法についてのヒントをいくつかご紹介します。Pav Cherny
Windows PowerShell: Windows PowerShell 2.0 のリモート管理の概要: Windows PowerShell 2.0 は開発中ですが、最新の CTP ではいくつかの優れた新機能が提供されています。このコラムでは、Windows PowerShell 2.0 CTP2 の最も魅力的な新機能の 1 つであるリモート処理について説明します。Don Jones | Hey, Scripting Guy!: 早いルートを利用する: Windows Vista では、[ファイルを開く] ダイアログ ボックスを表示する ActiveX コントロールである UserAccounts.CommonDialog が廃止されました。この記事では、Visual Basic Express Edition を使用してこの問題を解決する方法について説明します。Microsoft Scripting Guys | デスクトップ ファイル: Windows 展開サービス入門: この記事では、さまざまなバージョンの Windows 展開サービスの特徴、カスタムの OS イメージをキャプチャする方法、およびインストール プロセスのより多くの部分を自動化するために必要な要素について説明します。Wes Miller
セキュリティ ウォッチ: パスワードとクレジット カード、第 2 部: 3 回シリーズの第 2 回では、Jesper Johansson が、ソフトウェア ベンダ、セキュリティ スイート、およびマーケティング活動によって真のセキュリティ向上が妨げられる状況について説明し、このような慣習によってテクノロジのセキュリティ エコシステムの崩壊がもたらされる可能性について警告します。Jesper M. Johansson | 持続可能なコンピューティング: グリーンウォッシングを選別する: 現在、電力消費量を認識することは、IT インフラストラクチャの管理に不可欠です。この記事では、ご使用の環境で電力監視を実装する際に使用できる方法を紹介しているので、組織全体におけるデバイスの電力消費についての理解を深めることができます。Dave Ohara | フィールド ノート: IMAP が世界を救う: 電子メールをいろいろな場所、さまざまな形式、さらにはさまざまなオペレーティング システムに保存してお困りではありませんか。今月は、Dara Korra’ti が、IMAP4 を使用して、1 つの場所からすべてのメールにアクセスできるようにする方法をご紹介します。R’ykandar Korra’ti
Windows 秘話: 過去の遺産による貢献: Raymond が、かつては大きな勢力を持っていた Alpha AXP システムがいったん使用されなくなってから、どのようにして再び使用されるようになり次世代の 64 ビット システムの開発に役立ったかをご紹介します。Raymond Chen


SQL Server
効果的なデータベース メンテナンスのヒント
Paul S. Randal
概要 :
  • データ ファイルとトランザクション ログ ファイルを管理する
  • インデックスの断片化を解消する
  • 正確な最新の統計を得る
  • 破損したデータベース ページを検出する
  • 効果的なバックアップ戦略を確立する

目次
データ ファイルとログ ファイルの管理
インデックスの断片化
統計
破損の検出
バックアップ
まとめ
私は 1 週間のうちに何回か、運用データベースの効果的なメンテナンス方法に関するアドバイスを求められます。また、新しいソリューションの実装を進めていて、新しいデータベースの特性に
合ったメンテナンス方法を探している DBA の皆さんから質問を受けることもあります。ただし、プロの DBA ではなく、なんらかの理由でデータベースの所有者となり、その責任を負っている方から質問を受けることの方がよくあります。私は、このような役割をよく "不本意な DBA" と呼んでいます。この記事では、世の中のすべての不本意な DBA の皆さんに、データベースのメンテナンスに関するベスト プラクティスの手引きを提供します。
IT 分野における大半の作業や手続きと同様、データベースの効果的なメンテナンスを行うための簡単かつ汎用的なソリューションは存在しません。ただし、ほぼ常に対処する必要がある重要な領域がいくつか存在します。私が考える重要な 5 つの領域は、次のとおりです (以下の順序は重要度とは無関係です)。
  • データ ファイルとログ ファイルの管理
  • インデックスの断片化
  • 統計
  • 破損の検出
  • バックアップ
データベースがメンテナンスされていない (または不適切にメンテナンスされた) 場合、上記の 1 つ以上の領域で問題が発生する可能性があります。これらの問題が発生した場合、最終的にアプリケーションのパフォーマンスが低下するだけでなく、ダウンタイムやデータの損失が発生することもあります。
この記事では、これらの問題が重要である理由について説明し、問題を軽減するための簡単な方法をいくつか紹介します。ここでの説明は、SQL Server ® 2005 に基づいていますが、SQL Server 2000 や新しい SQL Server 2008 を使用する場合は主にどのような違いが生じるかについても説明します。

データ ファイルとログ ファイルの管理
データベースの管理作業を引き継ぐときに、まず確認すべき領域として必ずお勧めしているのは、データ ファイルと (トランザクション) ログ ファイルの管理に関する設定です。具体的には、次のことを確認します。
  • データ ファイルとログ ファイルが分かれていて、他のものからも分離されている
  • 自動拡張が正しく構成されている
  • ファイルの瞬時初期化が構成されている
  • 自動圧縮が有効ではなく、メンテナンス プランに圧縮が含まれていない
データ ファイルとログ ファイル (これらは別々のボリューム上に格納されていることが理想的です) が、ファイルを作成または拡張する他のアプリケーションと同じボリューム上に格納されている場合、ファイルの断片化が発生する可能性があります。データ ファイル内で過剰に断片化が進むと、クエリ (特に大量のデータをスキャンするクエリ) のパフォーマンスが若干低下する可能性があります。ログ ファイルの断片化が進んだ場合、パフォーマンスは大幅に低下する可能性があります。特に、各ファイルが必要になるたびに少量ずつサイズを増加するように自動拡張が設定されている場合、この違いは顕著に現れます。
ログ ファイルの内部は仮想ログ ファイル (VLF) というセクションに分かれていて、ある 1 つのログ ファイル (複数のログ ファイルを使用するメリットはなく、データベース 1 つに対して 1 つのファイルを用意した方がよいため、ここではあえて "1 つのログ ファイル" としています) の断片化が進むと、VLF の数が増加します。たとえば、1 つのログ ファイルの VLF が 200 である場合、ログの読み取り (トランザクションのレプリケーションやロールバックなど)、ログのバックアップ、SQL Server 2000 のトリガ (SQL Server 2005 ではトリガの実装が変更されていて、トランザクション ログではなく行バージョン管理フレームワークが使用されます) など、ログに関連する操作のパフォーマンスが低下する可能性があります。
データ ファイルとログ ファイルのサイズ調整に関するベスト プラクティスは、ファイルの作成時に適切な初期サイズを設定することです。データ ファイルの場合は、短い期間内でデータベースにデータが追加される可能性を考慮して初期サイズを設定します。たとえば、データの初期サイズが 50 GB でも、今後 6 か月間でさらに 50 GB のデータが追加されることがわかっている場合は、データ ファイルを作成する時点でサイズを 100 GB に設定した方が、最終的にこのサイズになるまでファイルの拡張を繰り返すよりも適切です。
残念ながらログ ファイルの場合はもう少し複雑で、トランザクションのサイズ (実行時間が長いトランザクションは、完了するまでログから削除できません) やログのバックアップ (このときに、ログ内で使用されていない部分が削除されます) 頻度などの要因を考慮する必要があります。詳細については、私の妻である Kimberly Tripp が SQLskills.com に掲載した人気のブログ記事「トランザクション ログのスループットを高める 8 つの手順」を参照してください。
構成が完了したら、ファイルのサイズを頻繁に監視して、1 日のうちで適切な時間に、先を見通して手動でファイルを拡張します。自動拡張は、万一に備えて有効にしておき、なんらかの異常が発生して拡張が必要になった場合に対処できるようにします。私がファイルの管理を完全に自動拡張に頼ることに反対する 1 つ目の理由は、少量ずつ自動拡張することによって、ファイルの断片化が発生するためです。そして 2 つ目の理由は、自動拡張は処理に時間がかかる可能性があり、その結果、予測できないタイミングでアプリケーションのワークロード処理が妨げられる場合があるためです。
自動拡張のサイズを割合ではなく特定の値に設定して、自動拡張が発生した場合に使用される時間と領域を制限する必要があります。たとえば、100 GB のデータ ファイルを自動拡張するときに使用するサイズを、10% ではなく固定値の 5 GB に設定します。これによって、ファイルのサイズが増加するたびに、拡張されるサイズも (たとえば 10 GB、11 GB、12 GB と) 増加するのではなく、ファイルのサイズが最終的にどれほど大きくなったとしても、常に 5 GB 単位で拡張されます。
トランザクション ログが (手動または自動拡張によって) 拡張されるときは、常にゼロで初期化されます。データ ファイルの既定の動作は SQL Server 2000 と同じですが、SQL Server 2005 からは、ファイルの瞬時初期化を利用できるようになります。瞬時初期化では、ファイルをゼロで初期化する処理が省略されるため、手動での拡張や自動拡張が事実上瞬時に完了します。世間のイメージとは異なるかもしれませんが、この機能は SQL Server のすべてのエディションで提供されています。詳細については、SQL Server 2005 Books Online または SQL Server 2008 オンライン ブックで「ファイルの瞬時初期化」というキーワードで検索を実行し、検出されたページを参照してください。
また、決して圧縮を有効にしないようにしてください。圧縮を使用すると、データ ファイルやログ ファイルのサイズを削減できますが、これはリソースを大量に消費する非常に厄介な処理です。また、データ ファイル内で大量の論理スキャンの断片化が発生し (詳細については後述します)、パフォーマンスの低下にもつながります。私は、圧縮に関する SQL Server 2005 Books Online のトピックに変更を加え、この影響に関する警告を追加しました。ただし、特別な状況では、個々のデータ ファイルとログ ファイルを手動で圧縮する作業を行ってもよいでしょう。
ビデオ
Paul Randal が、手動での圧縮と自動圧縮によって、データベースでどのように断片化に関する重大な問題が発生するかについて、デモンストレーションを行います。

自動圧縮は、パフォーマンスへの影響が最も大きな処理で、バックグラウンドで 30 分おきに起動し、自動圧縮データベース オプションが有効になっているデータベースの圧縮を試行します。これは、空き領域が 25% を超えるデータベースのみを圧縮するという点で、やや予測不可能な処理です。自動圧縮は多くのリソースを使用し、断片化によるパフォーマンスの低下を招くため、どのような状況であっても決して良い考えとは言えません。このため、次のコマンドを使用して必ず自動圧縮を無効にしてください。
ALTER DATABASE MyDatabase SET AUTO_SHRINK OFF;
手動のデータベース圧縮コマンドが組み込まれた定期的なメンテナンス プランを使用することも、ほぼ同じくらいお勧めできません。メンテナンス プランでデータベースが圧縮された後に、データベースが繰り返し拡張される場合、そのデータベースの実行には、拡張された分の領域が必要であることを示しています。
ベスト プラクティスは、安定したサイズになるまでデータベースを拡張し、決して圧縮を実行しないようにすることです。圧縮の欠点について、および SQL Server 2005 で使用される新しいアルゴリズムについては、私が以前に執筆した MSDN® ブログの記事 (blogs.msdn.com/sqlserverstorageengine/archive/tags/Shrink/default.aspx) を参照してください。

インデックスの断片化
ファイル システム レベルやログ ファイル内の断片化だけでなく、テーブルとインデックス データを保存する構造内でも、データ ファイルの断片化が発生する可能性があります。基本的に、データ ファイル内で発生する断片化には次の 2 種類があります。
  • 個々のデータおよびインデックス ページ内での断片化 (内部断片化と呼ばれることもあります)
  • 複数のページで構成されるインデックスまたはテーブル構造内の断片化 (論理スキャンの断片化またはエクステント スキャンの断片化と呼ばれます)
内部断片化は、ページの空き領域が多い状態を指します。図 1 からわかるように、データベースの各ページのサイズは 8 KB で、ページごとに 96 バイトのヘッダーが含まれます。したがって、1 ページにつき約 8,096 バイトのテーブルまたはインデックス データを格納できます (特定のテーブルやインデックスのデータおよび行構造については、私が sqlskills.com/blogs/paul で公開しているブログの「ストレージ エンジンの内部」カテゴリを参照してください)。各テーブルまたはインデックス レコードがページ サイズの半分より大きく、それによって 1 ページにつき 1 つのレコードしか保存できない場合、空き領域が発生します。この状況では、テーブルやインデックス スキーマに変更を加える必要があるため、修正作業が非常に難しいか、修正作業を行うことができない場合もあります。たとえば、GUID などとは異なり、インデックス キーを挿入ポイントがランダムにならないものに変更したりする必要があります。
図 1 データベース ページの構造 (画像をクリックすると拡大表示されます)
一般的には、挿入、更新、削除など、ページ上に空き領域を残す可能性があるデータ変更操作の結果として、内部断片化が発生します。適切に管理されていない FILL FACTOR も、断片化の原因になる可能性があります (詳細については、SQL Server オンライン ブックを参照してください)。テーブルやインデックスのスキーマとアプリケーションの性質によっては、この空き領域は一度作成されると決して再利用されないため、使用できない領域がデータベース内で増加し続ける可能性があります。
たとえば、レコードの平均サイズが 400 バイトである 1 億行のテーブルがあるとします。アプリケーションのデータ変更パターンによって、各ページ上に平均 2,800 バイトの空き領域が残されました。テーブルに必要な領域の合計は約 59 GB です。この数字を計算するには、8 KB のページ 1 ページあたりのレコード数を求めた (8096 - 2800 / 400 = 13) 後、1 億を 13 で除算してページ数を求めます。無駄な領域が存在しなければ、1 ページあたり 20 個のレコードを格納できるため、必要な領域の合計サイズは 38 GB に抑えられます。これは大きな節約です。
したがって、データまたはインデックス ページ上に無駄な領域が存在すると、同じ量のデータを保持する場合でも、余分にページが必要になります。また、より多くのディスク領域が奪われるだけでなく、同じ量のデータを読み取るためにクエリによって発行される I/O の回数も増加することになります。さらに、これらの余分なページによって、データ キャッシュ内のより多くの領域が占有されるため、サーバーのメモリも余分に使用されます。
論理スキャンの断片化は、ページ分割と呼ばれる操作が原因です。これは、特定のインデックス ページに (インデックス キー定義に従って) レコードを挿入する必要があるときに、そのレコード データを格納するための領域をページ上に確保できない場合に発生します。このページは半分に分割され、約 50% のレコードが、新しく割り当てられたページに移動されます。通常、この新しいページは古いページに物理的に隣接していないため、"断片化している" と表現されます。エクステント スキャンの断片化も、概念的には似ています。テーブルまたはインデックス構造内の断片化は、SQL Server が効率的なスキャンを実行できるかどうかに影響します。これは、スキャンの対象がテーブルまたはインデックス構造全体の場合でも、クエリの WHERE 句によって対象が制限される (SELECT * FROM MyTable WHERE Column1 > 100 AND Column1 < 4000 など) 場合でも同様です。
図 2 は、FILL FACTOR が 100% で断片化が発生していない、新しく作成されたページを示しています。各ページの領域全体が使用され、ページの物理的な順序と論理的な順序が一致しています。図 3 は、ランダムな挿入、更新、または削除の後に発生する可能性がある断片化を示しています。
図 2 ページの領域使用率が 100% で断片化が発生していない、新しく作成されたインデックス ページ (画像をクリックすると拡大表示されます)
図 3 ランダムな挿入、更新、削除の後に論理スキャンの内部断片化が発生したインデックス ページ (画像をクリックすると拡大表示されます)
断片化は、テーブルやインデックスのスキーマを変更することによって回避できる場合がありますが、前述のとおり、これは非常に困難であるか、不可能な場合があります。この回避策を選択できない場合は、インデックスの再構築や再編成などの方法を使用して、発生した断片化を解消できます。
インデックスを再構築すると、インデックスの新しいコピーが (可能な限り連続するように最適化された状態で) 作成され、断片化された古いコピーが削除されます。SQL Server では、インデックスの新しいコピーが作成されてから古いコピーが削除されるため、データ ファイル内にインデックスのサイズと同程度の空き領域が必要です。SQL Server 2000 では、インデックスの再構築は常にオフラインで実行されていましたが、SQL Server 2005 Enterprise Edition では、(いくつかの制限はありますが) オンラインでもインデックスを再構築できます。一方、再編成では、インプレース アルゴリズムを使用して最適化とインデックスの断片化解消が行われるため、必要な領域は 8 KB のみです。また、この処理は常にオンラインで実行されます。実際、私は SQL Server 2000 で、インデックスを再構築する代わりにオンラインで領域を効率よく使用できる方法として、インデックスの再編成コードを作成しました。
SQL Server 2005 では、ALTER INDEX … REBUILD コマンドを使用してインデックスを再構築し、ALTER INDEX … REORGANIZE コマンドを使用してインデックスを再編成します。SQL Server 2000 でこれらに相当するコマンドは、それぞれ DBCC DBREINDEX と DBCC INDEXDEFRAG です。
これら 2 つの手法の間には、生成されるトランザクション ログの量、データベース内の必要な空き領域、作業内容を失うことなく処理を中断できるかどうかなど、多くのトレードオフがあります。これらのトレードオフなどに関する説明が記載されたホワイト ペーパーが microsoft.com/technet/prodtechnol/sql/2000/maintain/ss2kidbp.mspx で公開されています。このペーパーは SQL Server 2000 に基づいていますが、概念はそれ以降のバージョンにも適用できます。
管理者によっては、どのインデックスが断片化しているかや、断片化を解消することによってなんらかのメリットを得ることができるかどうかを検証せずに、(たとえばメンテナンス プランのオプションを使用して) 毎晩または毎週、インデックス全体の再構築や再編成を行う場合があります。最小限の労力でなんらかの対策を施す必要がある不本意な DBA の皆さんにとっては良い方法かもしれませんが、リソースが重視される、サイズの大きなデータベースやシステムにとっては、きわめて不適切な選択になる可能性があります。
より賢い方法は、DMV sys.dm_db_index_physical_stats (SQL Server 2000 の場合は DBCC SHOWCONTIG) を使用して、断片化されているインデックスを定期的に確認し、それらのインデックスに対処するかどうか、またどのように対処するかを決定することです。上記のホワイト ペーパーでは、より対象が絞られたこれらの選択肢を使用する方法も記載されています。また、この処理を行うサンプル コードについては、Books Online に記載されている SQL Server 2005 の DMV sys.dm_db_index_physical_stats に関するトピック (msdn.microsoft.com/library/ms188917) のサンプル D、または SQL Server 2000 以降の DBCC SHOWCONTIG に関するトピック (msdn.microsoft.com/library/aa258803) のサンプル E を参照してください。
どちらの方法を使用する場合でも、断片化が発生しているかどうかを定期的に確認し、それらを解消することを強くお勧めします。
クエリ プロセッサは SQL Server のコンポーネントで、どのようにクエリを実行するかを定義します。具体的には、使用するテーブルとインデックスや、目的の結果を得るためにそれらに対してどのような操作を実行するかなどを定義します。この定義はクエリ プランと呼ばれます。この定義を行ううえで最も重要な判断材料の 1 つは、テーブルやインデックス内で使用されている列のデータ値の分布を示す統計です。もちろん、有用な情報をクエリ プロセッサに提供するには、最新の正確な統計を使用する必要があります。これを怠った場合、パフォーマンスの低いクエリ プランが選択される可能性があります。
統計は、テーブルまたはインデックスのデータを読み取り、関連性のある列のデータ分布状況を特定することによって生成されます。統計は、特定の列に格納されているすべてのデータ値をスキャンして (完全スキャン) 構築することも、ユーザーが指定した割合のデータに基づいて (サンプル スキャン) 構築することもできます。列内の値が比較的均等に分布している場合は、サンプル スキャンを使用すれば十分です。サンプル スキャンの方が完全スキャンと比べて短時間で統計を作成および更新できます。
AUTO_CREATE_STATISTICS および AUTO_UPDATE_STATISTICS データベース オプションを有効にすると、統計を自動的に作成およびメンテナンスできます (図 4 参照)。これらのオプションは既定で有効になっていますが、まだデータベースを引き継いで間もない場合は、これらが有効になっているかどうかを確認することをお勧めします。統計の内容は古くなる可能性がありますが、特定の統計に対して UPDATE STATISTICS 操作を使用することによって、これらを手動で更新できます。また、sp_updatestats ストアド プロシージャを使用して、作成日時の古い統計をすべて更新することもできます (SQL Server 2000 では、sp_updatestats を使用すると、作成日時に関係なくすべての統計が更新されます)。
図 4 SQL Server Management Studio を使用したデータベース設定の変更 (画像をクリックすると拡大表示されます)
定期的なメンテナンス プランの一環として統計を更新する場合、注意すべきことが 1 つあります。それは、UPDATE STATISTICS と sp_updatestats では以前に指定したサンプリング レベルが使用されます (指定したことがある場合) が、このレベルが完全スキャンではない可能性があることです。インデックスを再構築すると、自動的に完全スキャンが統計の更新に使用されます。インデックスの再構築後に統計を手動で更新すると、統計の正確さが低下する可能性があります。この状況は、インデックスの再構築時に生成された完全スキャンが、手動での更新に使用されたサンプル スキャンによって上書きされた場合に発生します。一方、インデックスを再編成しても統計が更新されることはありません。
また、すべてのインデックスを再構築する前後のある時点ですべての統計を更新するメンテナンス プランを使用した結果、知らず知らずのうちに正確さを欠いた統計を保持することもよくあります。単純にすべてのインデックスを頻繁に再構築する場合、統計もそれによって自動的に再構築されます。より複雑な方法を使用して断片化を解消する場合は、その作業に統計のメンテナンスも含めるようにしてください。以下にいくつかの推奨事項を示します。
  • インデックスを分析し、操作対象のインデックスと断片化の解消方法を決定します。
  • 再構築されていないすべてのインデックスの統計を更新します。
  • インデックスが作成されていないすべての列の統計を更新します。
統計の詳細については、ホワイト ペーパー「Microsoft® SQL Server 2005 のクエリ オプティマイザが使用する統計情報」(microsoft.com/technet/prodtechnol/sql/2005/qrystats.mspx) を参照してください。

破損の検出
これまでは、パフォーマンス関連のメンテナンスについて説明しました。ここではトピックを変えて、破損の検出と緩和策について説明します。
管理しているデータベースに、だれも気にかけていないまったく不要な情報が格納されていることはまず考えられません。では、データが破損していない状態、および障害が発生した場合に復旧可能な状態を維持するにはどうすればよいでしょうか。この記事では、完全な障害復旧および高可用性戦略を作成する方法については説明しませんが、手始めに簡単にできることをいくつか紹介します。
破損の原因のほとんどは "ハードウェア" です。なぜハードウェアを二重引用符で囲んだかと言えば、この場合は本来の意味ではなく、"SQL Server の基盤となる I/O サブシステム内の要素" を表しているからです。I/O サブシステムは、オペレーティング システム、ファイル システム ドライバ、デバイス ドライバ、RAID コントローラ、ケーブル、ネットワーク、実際のディスク ドライブなどから構成されます。このようなさまざまな場所で問題が発生する可能性があります (そして実際に発生します)。
最もよく問題が発生する状況の 1 つは、ディスク ドライブがデータベース ページを書き込んでいるときに停電が発生した場合です。電力が供給されなくなる前にドライバが書き込みを完了できなかった (または書き込み操作がキャッシュされたが、ドライバのキャッシュをフラッシュできるだけの補助電力が供給されなかった) 場合、ディスク上に不完全なページ イメージが残る可能性があります。この問題が発生する理由は、8 KB のデータベース ページが、実際には 512 バイトのディスク セクタを 16 個連結して構成されているためです。不完全な書き込みでは、新しいページを構成するいくつかのセクタが書き込まれ、以前のページ イメージを構成していたいくつかのセクタが元のまま残ります。これは破損ページと呼ばれます。この問題が発生しているかどうかを検出するにはどうすればよいでしょうか。
SQL Server では、この状況を検出するためのメカニズムが提供されます。このメカニズムでは、ページのセクタごとに数ビットが保存され、特定のパターンがそれぞれの領域に書き込まれます (この処理は、ページがディスクに書き込まれる直前に実行されます)。ページが再度読み取られたときにパターンが一致しない場合、SQL Server はページが "破損" していると判断し、エラーを生成します。
SQL Server 2005 以降では、ページ チェックサムというさらに包括的なメカニズムが提供されます。このメカニズムを使用すると、ページ上のあらゆる破損を検出できます。このメカニズムでは、破損ページを検出するメカニズムと同様、ページがディスクに書き込まれる直前に、ページ全体のチェックサムがページに書き込まれ、ページが再度読み取られるときに、このチェックサムがテストされます。ページ チェックサムを有効にした場合、ページ チェックサムによってページが保護される前に、ページをバッファ プールに書き込み、なんらかの変更を加えて、ディスクに再び書き込む必要があります。
したがって、破損の検出に関するベスト プラクティスは、SQL Server 2005 以降ではページ チェックサムを有効にし、SQL Server 2000 では破損ページの検出を有効にすることです。ページ チェックサムを有効にするには、次のコマンドを使用します。﻿
ALTER DATABASE MyDatabase SET PAGE_VERIFY CHECKSUM;
SQL Server 2000 で破損ページの検出を有効にするには、次のコマンドを使用します。
ALTER DATABASE MyDatabase SET TORN_PAGE_DETECTION ON;
これらのメカニズムを使用すると、ページが破損していることを検出できますが、ページを読み取るとき以外は破損を検出できません。簡単にすべての割り当て済みページの読み取りを強制するにはどうすればよいでしょうか。最も良い方法 (かつ他のどのような種類の破損も検出できる方法) は、DBCC CHECKDB コマンドを使用することです。指定されたオプションにかかわらず、このコマンドでは常にデータベースのすべてのページが読み取られるため、ページ チェックサムや破損ページが確認されます。また、通知を設定して、ユーザーがクエリを実行したときに破損に関する問題が発生した場合、そのことを確認できるようにするとよいでしょう。重要度 24 エラーの通知を使用することによって、これまでに説明したすべての問題の通知を受け取ることができます (図 5 参照)。
図 5 重要度 24 エラーが発生したときに通知を受け取るよう設定する (画像をクリックすると拡大表示されます)
したがって、もう 1 つのベスト プラクティスは、データベースに対して DBCC CHECKDB を定期的に実行し、データベースの整合性を確認することです。このコマンドのバリエーションは豊富で、実行頻度についても多くの質問を受けます。残念ながら、このことに関する説明が記載されたホワイト ペーパーは提供されていません。ただし、私が SQL Server 2005 用に作成したコードで最も重要なコマンドは DBCC CHECKDB で、これについてはかなり詳しくブログに書きました。私のブログ (sqlskills.com/blogs/paul) の「CHECKDB の詳細」カテゴリには、整合性チェック、ベスト プラクティス、使用方法などに関する詳細な説明が記載された記事が多数含まれています。不本意な DBA の皆さんは、データベースの完全バックアップを作成するたびに DBCC CHECKDB を実行することを大まかな目安にしてください (詳細については後述します)。次のコマンドを実行することをお勧めします。
DBCC CHECKDB ('MyDatabase') WITH NO_INFOMSGS,
  ALL_ERRORMSGS;
このコマンドによってデータが出力された場合、DBCC によってデータベース内の破損が検出されたことになります。ここで問題となるのは、DBCC CHECKDB によって破損が検出された場合、どのようにしてその破損に対処すべきかということです。そこで活躍するのがバックアップです。
破損などの障害が発生した場合、最も効果的な復旧方法は、バックアップからデータベースを復元することです。それには、まずバックアップが保管されていて、バックアップ自体が破損していないことが必要です。バックアップを保有していない場合に、大きく破損したデータベースを再び実行するにはどうすればよいかを質問されることが非常によくあります。答えは単純で、それは不可能です。このようなデータベースを実行すると、なんらかのデータ消失が発生し、ビジネス ロジックとリレーショナル データの整合性に大きな影響を与える可能性があります。
このため、必ず定期的にバックアップを作成するようにしてください。この記事では、バックアップと復元を使用する方法の詳細については取り上げませんが、ここでバックアップ戦略を確立する方法について簡単に説明します。
まず、定期的にデータベースの完全バックアップを作成します。これによって、復元ポイントを確保し、後からデータベースを復元できるようになります。データベースの完全バックアップを作成するには、BACKUP DATABASE コマンドを使用します。例については、SQL Server オンライン ブックを参照してください。さらに保護を強化するには、WITH CHECKSUM オプションを使用します。このオプションは、読み取るページにページ チェックサムが含まれている場合、それらのチェックサムを検証し、バックアップ全体のチェックサムを計算します。実行頻度は、ビジネス上どれくらいのデータや作業の消失が許容されるかに応じて設定します。たとえば、1 日に 1 回データベースの完全バックアップを作成すると、障害が発生した場合、1 日分のデータが失われます。データベースの完全バックアップのみを使用する場合は、単純復旧モデル (通称、復旧モード) を使用すると、トランザクション ログの拡張を管理する作業の煩雑さを回避できます。
2 つ目に、いずれかのバックアップが破損した場合に備えて、常に数日分のバックアップを維持しておきます。数日分のバックアップでも、まったくバックアップを作成しないよりは役立ちます。また、RESTORE WITH VERIFYONLY コマンドを使用して、バックアップの整合性を検証します (これについても SQL Server オンライン ブックを参照してください)。バックアップの作成時に WITH CHECKSUM オプションを使用した場合、この検証コマンドを実行すると、バックアップのチェックサムが現在も有効であるかどうかが確認されるだけでなく、バックアップ内のページに含まれているチェックサムもすべて再確認されます。
3 つ目に、1 日 1 回データベースの完全バックアップを作成するだけでは、データや作業の消失量がビジネスに支障のない範囲を超えてしまう場合、データベースの差分バックアップを検討してください。データベースの差分バックアップはデータベースの完全バックアップに基づいたバックアップで、最後にデータベースの完全バックアップを作成してから発生したすべての変更に関する記録が含まれます (差分バックアップは増分バックアップとよく間違えられますが、実際は異なります)。戦略の例としては、1 日に 1 回データベースの完全バックアップを作成し、4 時間ごとにデータベースの差分バックアップを作成することが考えられます。差分バックアップによって、追加の復旧ポイントを確保できます。データベースの完全バックアップと差分バックアップのみを使用する場合も、単純復旧モデルを使用することをお勧めします。
最後に、最大限の復旧性を実現するには、ログ バックアップを使用します。このバックアップは、完全 (または一括ログ) 復旧モデルでのみ使用でき、前回のログ バックアップ以降に生成されたすべてのログ レコードをバックアップします。定期的にデータベースの完全バックアップ (および場合によっては差分バックアップ) と共にログ バックアップを作成することによって、最新の復旧ポイントも含め、非常に多くの復旧ポイントを確保できます。このトレードオフは、ログ バックアップを作成することによってトランザクション ログが "解放" されるまで、ログのサイズが増加し続けることです。この場合の戦略例としては、データベースの完全バックアップを 1 日に 1 回作成し、データベースの差分バックアップを 4 時間ごと、ログ バックアップを 30 分ごとにそれぞれ作成することが考えられます。
バックアップ戦略を決定および構成する作業は複雑になる可能性があります。このため、少なくとも定期的にデータベースの完全バックアップを作成し、1 つ以上の復旧ポイントを確保するようにしてください。
ご存知のとおり、データベースの状態を良好に保ち、可用性を確保するには、いくつかの作業が欠かせません。不本意な DBA の皆さんを対象にした、データベースの最終チェック リストを次に示します。
  • トランザクション ログ ファイルの過剰な断片化を解消する。
  • 自動拡張を正しく設定する。
  • スケジュールされた圧縮操作をすべて無効にする。
  • ファイルの瞬時初期化を有効にする。
  • 定期的にインデックスの断片化を検出してそれらを解消する。
  • AUTO_CREATE_STATISTICS と AUTO_UPDATE_STATISTICS を有効にし、定期的に統計を更新する。
  • ページ チェックサムを有効にする (SQL Server 2000 の場合は、少なくとも破損ページの検出を有効にする)。
  • 定期的に DBCC CHECKDB を実行する。
  • 定期的にデータベースの完全バックアップ、差分バックアップ、およびログ バックアップを作成して復旧ポイントを確保する。
この記事では T-SQL コマンドを使用しましたが、Management Studio からもさまざまな操作を行うことができます。この記事が効果的なデータベース メンテナンスの実施に役立つ指針となることを願っています。ご意見やご質問は paul@sqlskills.com (英語のみ) までお寄せください。

Paul S. Randal は SQLskills.com の代表取締役であり、SQL Server MVP でもあります。1999 年から 2007 年までは、マイクロソフトの SQL Server ストレージ エンジン チームに所属していました。Paul は障害復旧、高可用性、およびデータベース メンテナンスの専門家です。彼のブログは SQLskills.com/blogs/paul で公開されています。

© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved. 許可なしに一部または全体を複製することは禁止されています。


Windows の管理
サーバーのパフォーマンスを測定する
Steven Choy
概要 :
  • パフォーマンス モニタをカスタマイズする
  • 測定する内容と頻度に関するガイダンス
  • 重要なカウンタと予期される値の概要

目次
結果を見やすくする
測定する内容とタイミング
ハード ディスクのボトルネック
メモリのボトルネック
プロセッサのボトルネック
ネットワークのボトルネック
プロセスのボトルネック
まとめ
月曜日の朝、オフィスに着いた途端、熱心なユーザーからサーバーの処理速度が遅すぎるという不満をぶつけられたとします。そのユーザーをサポートするにあたって、まず何をすればよいでしょうか。パフォーマンス
モニタは、Windows® に組み込まれている便利なツールであり、問題を診断するときに役立ちます。
パフォーマンス モニタにアクセスするには、コマンド プロンプトで「perfmon」と入力するか、[管理ツール] メニューの [パフォーマンス] (Windows Vista® または Windows Server® 2008 の場合は [信頼性とパフォーマンス モニタ]) を選択します。監視するパフォーマンス カウンタとオブジェクトを追加するには、単純にプラス記号をクリックし、多数の選択肢から選択します。
では、どのようにしてサーバーのパフォーマンスを測定すればよいでしょうか。60 個を超える基本的なパフォーマンス オブジェクトが提供されており、各オブジェクトには複数のカウンタが含まれています。この記事では、サーバーのパフォーマンスを示すカウンタについて、およびマイクロソフトのサービス サポート部門に所属するエンジニアがパフォーマンスに関する問題のトラブルシューティングに最もよく使用する標準的なサンプリング間隔について説明します。
トラブルシューティングを行うときには、ベースラインによって重要な基準点が提供されることは言うまでもありません。サーバーの負荷はビジネス要件によって異なり、ビジネス サイクルによって変化することもあるので、特定期間の標準的なワークロードに基づいてベースラインを確立することが重要です。このベースラインを使用することによって、変更を監視し、傾向を特定できます。

結果を見やすくする
サーバーのパフォーマンスを表すカウンタの分析について詳しく説明する前に、パフォーマンス モニタを使用してサーバーのパフォーマンスを測定する作業を容易にする 2 つのテクニックについて説明します。これら 2 つのテクニックは Windows Vista と Windows Server 2008 では不要ですが、以前のバージョンの Windows でパフォーマンス モニタを実行する場合は非常に役立ちます。
まず、グラフィカルなビューの傾向線を見えにくくする、紛らわしい不要なサンプル表示を無効にします。Windows Vista と Windows Server 2008 のパフォーマンス モニタでは、最大 1,000 個のデータ ポイントをグラフィカルなビューに表示できます。以前のバージョンの Windows では、表示できるデータ ポイントが 100 個に制限されています。データ ポイントの数が 100 個を超えると、表示上データ ポイント間で値が急激に変化します。このような場合、サンプル ポイントの最小値、平均値、および最大値が同じように垂直線で表されます。
図 1 のグラフからわかるように、同時に表示されるデータの量が多すぎると、傾向線を見分けるのは困難です。図 2 のグラフは、余分な情報を非表示にすることによって、データをどれだけ確認しやすくなるかを示しています。急激な変化を示す垂直線を非表示にする方法の詳細については、サポート技術情報の資料 (support.microsoft.com/kb/283110) を参照してください。
図 1 コンマ区切りを使用せずに紛らわしい垂直線で表されたパフォーマンス データ (画像をクリックすると拡大表示されます)
図 2 コンマ区切りを使用したわかりやすいデータ表示 (画像をクリックすると拡大表示されます)
もう 1 つのテクニックは、数値にコンマ区切りを追加して、カウンタに表示される値を見やすくすることです。Windows Vista と Windows Server 2008 では、既定でコンマ区切りが有効になっています。一方、以前のバージョンの Windows のパフォーマンス モニタでは、コンマ区切りが既定で有効になっていません。
これは、あまり大きな違いを生まないと思うかもしれませんが、図 1 を見てください。この図は、コンマ区切りを使用していないパフォーマンス カウンタを示しています。これに対して、図 2 はコンマ区切りを使用したパフォーマンス カウンタを示しています。後者の方が見やすいことは明らかです。Windows XP でパフォーマンス カウンタにコンマ区切りを追加する簡単な手順については、サポート技術情報の記事 (support.microsoft.com/kb/300884) を参照してください。

測定する内容とタイミング
ボトルネックは、リソースが処理能力の限度近くまで使用された場合に発生し、システム全体のパフォーマンスを低下させます。一般的に、ボトルネックは、リソースの不足や誤った構成、正常に機能しないコンポーネント、およびプログラムによる適切でないリソース要求が原因で発生します。
ボトルネックを引き起こし、サーバーのパフォーマンスに影響を与える可能性のある主なリソース領域は 5 つあります。これらは、物理ディスク、メモリ、プロセス、CPU、およびネットワークです。いずれかのリソースが過剰に使用されると、サーバーやアプリケーションの処理速度が著しく低下したり、これらがクラッシュしたりする可能性があります。ここでは、これら 5 つの領域について説明すると共に、使用した方がよいカウンタに関するガイダンス、およびサーバーのパフォーマンスを測定するときに使用するしきい値の候補を提供します。
サンプリング間隔はログ ファイルのサイズやサーバーの負荷に大きな影響を与えるため、問題が発生するまでの平均経過時間に基づいてサンプリング間隔を設定し、問題が再度発生する前にベースラインを確立できるようにする必要があります。これにより、問題の原因となる傾向を突き止めることができます。
通常の運用時、ベースラインを確立するための適切なサンプリング間隔は 15 分です。問題が発生するまでの平均経過時間が約 4 時間の場合は、サンプリング間隔を 15 秒に設定します。問題が発生するまでの時間が 8 時間以上の場合は、サンプリング間隔を 5 分以上に設定します。そうしなかった場合、最終的にログ ファイルのサイズが非常に大きくなり、データの分析が困難になります。

ハード ディスクのボトルネック
ディスク システムではサーバー上のプログラムとデータが保存および処理されるため、ディスクの使用量と処理速度に影響するボトルネックは、サーバーの全体的なパフォーマンスに大きな影響を与えます。
ディスク オブジェクトがサーバー上で有効になっていない場合は、Diskperf コマンド ライン ツールを使用してディスク オブジェクトを有効にする必要があります。また、% Disk Time は 100% を超える可能性があるため、ハード ディスクの使用率がより正確にわかるように、% Idle Time、Avg. Disk sec/Read、および Avg. Disk sec/write を使用します。% Disk Time の詳細については、サポート技術情報の資料 (support.microsoft.com/kb/310067) を参照してください。
マイクロソフトのサービス サポート部門のエンジニアがディスクの監視に使用するカウンタを次に示します。
LogicalDisk\% Free Space 選択した論理ディスク ドライブ上の空き領域の割合を測定します。この値が 15% を下回る場合は、OS が重要なファイルを格納するための空き領域が不足している可能性があります。当然この場合の解決策は、ディスク領域を追加することです。
PhysicalDisk\% Idle Time サンプリング間隔中にディスクがアイドル状態であった時間の割合を測定します。このカウンタの値が 20% を下回る場合、ディスク システムの使用率は非常に高いと言えます。現在のディスク システムを処理速度の速いディスク システムに交換することを検討してください。
PhysicalDisk\Avg.Disk Sec/Read ディスクからのデータの読み取りにかかる平均時間 (秒単位) を測定します。この値が 25 ミリ秒を超える場合、ディスク システムがディスクからデータを読み取るときに待ち時間が発生しています。SQL Server® や Exchange Server をホストするミッション クリティカルなサーバーでは、許容可能なしきい値が約 10 ミリ秒と非常に小さくなります。この場合、論理上最も適切な解決策は、現在のディスク システムを処理速度の速いディスク システムに交換することです。
PhysicalDisk\Avg.Disk Sec/Write ディスクへのデータの書き込みにかかる平均時間 (秒単位) を測定します。この値が 25 ミリ秒を超える場合、ディスク システムがディスクにデータを書き込むときに待ち時間が発生しています。SQL Server や Exchange Server をホストするミッション クリティカルなサーバーでは、許容可能なしきい値が約 10 ミリ秒と非常に小さくなります。この場合、考えられる解決策は、現在のディスク システムを処理速度の速いディスク システムに交換することです。
PhysicalDisk\Avg.Disk Queue Length ハード ドライブが使用可能になるのを待機している I/O 操作の数を示します。この値がスピンドルの数に 2 を加算した数よりも大きい場合は、ディスク自体がボトルネックになっている可能性があります。
Memory\Cache Bytes ファイル システム キャッシュに使用されているメモリの量を示します。この値が 200 MB を超える場合は、ディスクがボトルネックになっている可能性があります。

メモリのボトルネック
一般的に、メモリ不足の原因は、不十分な RAM、メモリ リーク、および boot.ini 内に配置されたメモリ スイッチです。メモリに関するカウンタの説明を始める前に、/3GB スイッチについて説明します。
メモリが増加すると、ディスク I/O 操作の回数が減少し、さらにアプリケーションのパフォーマンスが向上します。/3GB スイッチは、より多くのメモリをユーザー モードのプログラムに提供する方法として、Windows NT® で導入されました。
Windows では、(システムに搭載された物理 RAM の量に関係なく) 4 GB の仮想アドレス空間が使用されます。既定では、下位の 2 GB はユーザー モードのプログラム用に予約され、上位の 2 GB はカーネル モードのプログラム用に予約されます。/3GB スイッチを使用すると、ユーザー モードのプロセスに 3 GB が提供されます。当然ながら、この結果カーネル メモリが犠牲となり、その仮想アドレス空間は 1 GB のみになります。つまり、Pool NonPaged Bytes、Pool Paged Bytes、Free System Page Tables Entries、およびデスクトップ ヒープがすべてこの 1 GB の空間に詰め込まれるため、問題が発生する可能性があります。このため、/3GB スイッチを使用する前に、各自の環境で徹底的にテストを行うようにしてください。
上記はメモリに関連するボトルネックが発生している疑いがある場合の検討事項です。/3GB スイッチが問題の原因でない場合は、次のカウンタを使用して、メモリの潜在的なボトルネックを診断します。
Memory\% Committed Bytes in Use Commit Limit に対する Committed Bytes の割合 (つまり、使用されている仮想メモリの量) を測定します。この値が 80% を超える場合は、メモリが不足しています。この場合の解決策は、当然メモリを追加することです。
Memory\% Available Mbytes 実行中のプロセスに使用できる物理メモリのサイズ (MB 単位) を測定します。この値が物理 RAM 全体の 5% を下回る場合は、メモリが不足しているため、ページング操作の回数が増加する可能性があります。この問題を解決するには、単純にメモリを追加します。
Memory\Free System Page Table Entries システムによって現在使用されていないページ テーブル エントリの数を示します。この値が 5,000 を下回る場合は、メモリ リークが発生している可能性があります。
Memory\Pool NonPaged Bytes 非ページ プールのサイズ (バイト単位) を測定します。これは、ディスクに書き込むことはできないが、割り当てられている間は物理メモリ内に存在するオブジェクト用のシステム メモリ領域です。この値が 175 MB (/3GB スイッチの使用時は 100 MB) を超える場合は、メモリ リークが発生している可能性があります。システム イベント ログには、一般的なイベント ID 2019 が記録されます。
Memory\Pool Paged Bytes ページ プールのサイズ (バイト単位) を測定します。これは、使用されていないときにディスクに書き込むことができるオブジェクト用のシステム メモリ領域です。この値が 250 MB (/3GB スイッチの使用時は 170 MB) を超える場合は、メモリ リークが発生している可能性があります。システム イベント ログには、一般的なイベント ID 2020 が記録されます。
Memory\Pages per Second ハード ページ フォールトを解決するためにディスクから読み取られた、またはディスクに書き込まれたページの数を測定します。この値が 1,000 を超える場合は、ページングが過剰に発生し、それによってメモリ リークが発生している可能性があります。

プロセッサのボトルネック
プロセッサに負荷がかかる原因としては、プロセッサ自体の処理能力が不十分であることや、アプリケーションの処理が効率的でないことが考えられます。物理メモリの不足が原因でプロセッサのページング操作が大量に発生していないかどうかを再確認する必要があります。マイクロソフトのサービス サポート部門のエンジニアは、次のカウンタを使用して、プロセッサの潜在的なボトルネックを調査します。
Processor\% Processor Time プロセッサがアイドル状態でないスレッドを実行した時間の割合を測定します。この割合が 85% を超える場合は、プロセッサに負荷がかかっており、より処理速度の速いプロセッサをサーバーで使用することが必要になる場合があります。
Processor\% User Time プロセッサがユーザー モードのプログラムを実行した時間の割合を測定します。この値が大きい場合、サーバーのリソースはアプリケーションに占有されています。この場合に考えられる解決策の 1 つは、プロセッサ リソースを占有しているアプリケーションを最適化することです。
Processor\% Interrupt Time 特定のサンプリング間隔中にプロセッサがハードウェア割り込みを受け取って処理した時間の割合を測定します。このカウンタの値が 15% を超える場合、ハードウェアに関する問題が発生している可能性があります。
System\Processor Queue Length プロセッサ キューに格納されているスレッドの数を示します。この値が長時間にわたって CPU 数の 2 倍を超える場合は、サーバーで使用されているプロセッサの処理能力が十分ではありません。

ネットワークのボトルネック
当然ながら、ネットワークのボトルネックは、サーバーがネットワーク経由でデータを送受信する機能に影響を与えます。この場合、サーバーで使用されているネットワーク カードに問題があるか、おそらくネットワークが飽和状態になっており、ネットワークのセグメント化が必要です。ネットワークの潜在的なボトルネックを診断するには、次のカウンタを使用します。
Network Interface\Bytes Total/Sec 各ネットワーク アダプタ経由で送受信されるバイト (フレーム文字を含む) の割合を測定します。インターフェイスの 70% を超える部分が使用されている場合、ネットワークは飽和状態になっています。100 Mbps の NIC の場合、使用されるインターフェイスは 8.7 MB/sec (100 Mbps = 100000 kbps = 12.5 MB/sec x 70%) です。このような場合は、処理速度の速いネットワーク カードを追加するか、ネットワークをセグメント化してください。
Network Interface\Output Queue Length 送信パケットが格納されるキューの長さをパケット単位で測定します。この値が 2 を超える場合、ネットワークは飽和状態になっています。この問題を解決するには、処理速度の速いネットワーク カードを追加するか、ネットワークをセグメント化します。

プロセスのボトルネック
プロセスの動作が適切でない場合やプロセスが最適化されていない場合、サーバーのパフォーマンスは大幅に低下します。スレッド リークやハンドル リークが発生すると、最終的にサーバーがダウンすることになります。また、プロセッサの使用率が大幅に上昇した場合、サーバーのパフォーマンスが低下します。プロセス関連のボトルネックを診断する場合は、次のカウンタが必要不可欠です。
Process\Handle Count プロセスによって現在開かれているハンドルの合計数を測定します。このカウンタの値が 10,000 を超える場合、ハンドル リークが発生している可能性があります。
Process\Thread Count プロセス内で現在アクティブなスレッドの数を測定します。この値がスレッドの最小数と最大数の間で 500 を超える場合、スレッド リークが発生している可能性があります。
Process\Private Bytes このプロセスに割り当てられており、他のプロセスと共有できないメモリの量を示します。この値がスレッドの最小数と最大数の間で 250 を超える場合、メモリ リークが発生している可能性があります。

まとめ
この記事では、マイクロソフトのサービス サポート部門のエンジニアがさまざまなボトルネックを診断する際に使用するカウンタについて説明しました。当然ながら、ほとんどの場合は、使用する一連のカウンタを特定の要件に合わせて選択することになるでしょう。サーバーを監視するたびに一連のカウンタをすべて手動で追加する必要がなければ、時間を節約できると思います。さいわい、パフォーマンス モニタでは、選択した一連のカウンタを後で使用するために、テンプレートに保存できるオプションが用意されています。
パフォーマンス モニタをローカルとリモートのどちらで実行すればよいか、まだ疑問に思っているのではないでしょうか。パフォーマンス モニタをローカルで実行した場合のパフォーマンスへの影響は、環境によって異なります。サーバー上でパフォーマンス モニタを実行する場合でも、間隔を 5 分以上に設定すれば、パフォーマンスへの影響はほとんどありません。
サーバー上でパフォーマンス モニタを実行するとパフォーマンスが低下することを把握している場合は、パフォーマンス モニタをローカルで実行した方がよいでしょう。サーバー上のリソースが不足していると、パフォーマンス モニタはリモート コンピュータからデータをキャプチャできない可能性があります。複数のサーバーを監視したり、それらのサーバーをベースラインとして使用する場合は、パフォーマンス モニタを集中管理用のコンピュータからリモートで実行する方法が適しています。

Steven Choy は、マイクロソフトのプレミア フィールド エンジニアリング部門でシニア プレミア フィールド エンジニアを務めています。彼は、政府機関や民間の顧客を対象に、デスクトップの展開と移行、修正プログラムの管理、およびグループ ポリシーに関するプロジェクトをサポートしてきました。現在は、サーバーの仮想化とサーバーの正常性に関する業務に携わっています。


System Center
System Center Operations Manager で Windows PowerShell を使用する
Marco Shaw
概要 :
  • OpsMgr のコマンド シェル
  • OpsMgr の Monitoring プロバイダ
  • 一般的な管理タスクの自動化
  • Windows PowerShell の実例

目次
Operations Manager のコマンド シェル
OpsMgr の Monitoring プロバイダ
一般的なタスクを自動化する
実際の使用例
まとめ
管理者は System Center Operations Manager 2007 (OpsMgr) で、タスクを自動化するための強力な新しいスクリプト言語である Windows PowerShell を利用できます。Windows PowerShell は、2006 年 11 月のリリース以来 200 万回以上ダウンロードされています。
この記事では、Windows PowerShell® について、および Windows PowerShell を Operations Manager で使用する方法について説明します。また、Windows PowerShell を使用することによってはるかに簡単かつ自動化された方法で実行できる一般的なタスクの一部を取り上げ、便利なスクリプトや説明が提供される Web サイトもいくつか紹介します。現在 Windows PowerShell を使用している多くの専門家からの意見やブログ記事を集めました。
マイクロソフトから Windows PowerShell 2.0 の Community Technology Preview (CTP) 版がリリースされていますが、CTP 版は運用環境で使用する準備が整っておらず、OpsMgr でもテストされていないので、運用システムにはインストールしないようにしてください。

Operations Manager のコマンド シェル
OpsMgr では、コマンド シェルを使用して Windows PowerShell にアクセスします。コマンド シェルは既定の Windows PowerShell 環境に似ていますが、コンソール ファイルを読み込んだり、OpsMgr のコマンドレット、関数、および既定の接続によって環境を初期化するスクリプトを読み込んだりする点が異なります。
コマンド シェルは、[スタート] メニューで提供される OpsMgr のアイコンから起動するか、OpsMgr の UI コンソールでコンピュータ名を右クリックして起動できます (図 1 参照)。コマンド シェルを起動すると、直接 OpsMgr の Monitoring ドライブのパス (後で簡単に説明します) に移動します。
図 1 OpsMgr の UI から起動できるコマンド シェル (画像をクリックすると拡大表示されます)
Windows PowerShell は OpsMgr SDK を介して OpsMgr と対話します。管理者にとって幸運なことに、自動化したりコマンド ラインから実行したりすることが多いタスクの大部分を実行できるコマンドレットが既に提供されています。特定のタスクを実行するためのコマンドレットが提供されていない場合は、Windows PowerShell を使用して SDK と対話できます。
Operations Manager のコマンド シェルで提供されるコマンドはスナップインに含まれています。このスナップインは Windows PowerShell によって読み込まれる DLL で、OpsMgr の管理用コマンドレットを含んでいます。また、このスナップインには OperationsManagerMonitoring という Windows PowerShell プロバイダも含まれています。Monitoring プロバイダとも呼ばれるこのツールを使用すると、ファイル システム内を移動するかのように、接続、グループ、および監視オブジェクト間を移動できます。
Get-OperationsManagerCommand コマンドレットを使用すると、図 2 のように、OpsMgr のみで使用できるコマンドレットの一覧を表示できます (最初のバージョンでは Get-OperationsManagerCommand が関数として提供されていたので、Tab キーによる補完機能はサポートされていませんでしたが、SP1 ではこの関数がコマンドレットとして提供されます)。Operations Manager の最初のリリースでは 74 種類のコマンドレットが提供されましたが、OpsMgr SP1 では 87 種類のコマンドレットが提供されます。
図 2 OpsMgr で使用できるコマンドレットの一覧表示 (画像をクリックすると拡大表示されます)

OpsMgr の Monitoring プロバイダ
Set-Location コマンドレット、またはそのエイリアスである cd を使用すると、グループやコンピュータの構造内を移動できます。既定の Monitoring ドライブの基本的な構造を次に示します。
Monitoring:\->RMS->Groups (as defined in OpsMgr)
  ->Computers(as defined in OpsMgr)
この場所から、さらに具体的なオブジェクトにアクセスできます。今回は、管理サーバーを 1 台のみ使用する単純な環境を扱うことに注意してください。最初に管理グループにインストールされた管理サーバーは、ルート管理サーバー (RMS) と呼ばれます。
コマンド シェルの起動時に Monitoring という名前のドライブが作成され、このドライブが OperationsManagerMonitoring プロバイダのルートにマップされた後、現在の場所またはパスが Monitoring ドライブのルートに設定されます。続いて、接続先となる既定の RMS の名前がレジストリ内から検索されます。RMS への接続が成功すると、現在の場所またはパスが接続 (RMS) の名前に設定されます (図 3 参照)。
図 3 コマンド シェルの場所が RMS に設定された状態 (画像をクリックすると拡大表示されます)

一般的なタスクを自動化する
では、Windows PowerShell を使用して最も一般的ないくつかの管理タスクを実行する方法について説明します。
メンテナンス モードを制御する どのタスクを構成する場合でも、通常はそのタスクが実行される日時を指定する必要があります。ここでは、Get-Date コマンドレットの概要について説明し、日時の指定がどれぐらい簡単であるかを示します。図 4 の画面に表示されているいくつかの例をご覧ください。
図 4 Get-Date コマンドレットの使用 (画像をクリックすると拡大表示されます)
ご覧のとおり、この例では現在の時刻を表すオブジェクトを格納した $date 変数を作成しています。次に、このオブジェクトでサポートされており、ドキュメントで説明が提供されているメソッドを使用して簡単に 5 分後の日時を取得し、続いて 5 時間後の日時を取得しています。過去の値を取得するには、(5) の代わりに (-5) を使用するだけです。
コンピュータから出力されるすべてのアラートをブロックする必要がある場合は、メンテナンス モードを有効にします。OpsMgr 2007 を使用すると、コンピュータやグループ全体ではなく、Windows® サービスや特定のデータベースをメンテナンス モードに切り替えることができます。メンテナンス モードのタスクを実行することに特化したコマンドレットは 3 つあります。これらは、Get-MaintenanceWindow、New-MaintenanceWindow、および Set-MaintenanceWindow です。
コマンド シェル内からコンピュータをメンテナンス モードに切り替えるには、Monitoring プロバイダを使用して目的のコンピュータまたは監視オブジェクトに移動し、New-MaintenanceWindow コマンドレットを呼び出します (図 5 参照)。ご覧のとおり、この処理によって Denver.contoso.com というコンピュータがメンテナンス モードに切り替わります。また、メンテナンス モードがすぐに開始されるようにメンテナンス時間帯の開始時刻を設定し、ちょうど 1 時間後に終了するように終了時刻を設定します。この方法を使用してコンピュータをメンテナンス モードに切り替えても、すべてのアラートが出力されなくなるわけではありません。その理由は、このオブジェクトの HealthService インスタンスと HealthServiceWatcher インスタンスが引き続き有効になっているからです。
図 5 New-MaintenanceWindow コマンドレットの使用 (画像をクリックすると拡大表示されます)
マイクロソフトの OpsMgr チームでプログラム マネージャを務めている Boris Yanushpolsky によって、非常に便利な Windows PowerShell のコードが提供されています。このコードを使用すると、あるコンピュータに関連するすべてのオブジェクトをメンテナンス モードに切り替えることができます。彼は、スクリプトを作成した後にそのコードを使用する方法についても説明しています。詳細については、彼のブログ (blogs.msdn.com/boris_yanushpolsky/archive/2007/07/25/putting-a-computer-into-maintenance-mode.aspx) を参照してください。
場合によっては、オブジェクトが不必要にメンテナンス モードに切り替わっていないかどうかを確認する必要があります。ただし、すべてのオブジェクトを順番に処理してこのことを確認するのは大変な作業になる可能性があります。さいわい、ここでも Boris Yanushpolsky が、OpsMgr SDK を使用する Windows PowerShell スクリプトによって助け船を出しています。彼のブログ記事 (blogs.msdn.com/boris_yanushpolsky/archive/2007/08/06/so-what-is-in-maintenance-mode.aspx) から直接コードをコピーしてコマンド シェル ウィンドウに貼り付けると、メンテナンス モードになっているすべてのオブジェクトを一覧表示できます。
オブジェクトがメンテナンス モードになっている場合、最初に指定した終了時刻よりも早くメンテナンス期間を終了できます。Windows PowerShell に詳しい皆さんは動詞部分が stop や remove などのコマンドレットを予想するかもしれませんが、実際には Set-MaintenanceWindow を使用する必要があります (図 6 参照)。
図 6 Set-MaintenanceWindow を使用した終了時刻の変更 (画像をクリックすると拡大表示されます)
エージェントを管理する 管理者はかなり頻繁にエージェントを操作します。OpsMgr では、エージェントに関するさまざまなタスクを実行できる 6 つのコマンドレットと 1 つの関数 (リリース時点の状況です) が提供されます。次のコマンドを使用すると、これらのコマンドレットと関数の一覧を表示できます。
Get-Command *-agent*
SP1 のリリースでは、Install-AgentByName は関数ではなくコマンドレットとしてパッケージ化されています。優れたサポートと一貫性を提供するための基盤として、このコマンドレットを使用することをお勧めします。
コマンド シェルに組み込まれているヘルプでは、Install-Agent コマンドレットと Uninstall-Agent コマンドレットの使用方法がよくわかる例が提供されます。マイクロソフトの OpsMgr チームでシニア ソフトウェア デザイン エンジニアを務める Roger Sprague は、彼のブログで別の方法を紹介しています。図 7 はこのブログから引用したコードです (元の記事については、blogs.msdn.com/scshell/archive/2006/09/28/getting-started.aspx を参照してください)。
このスクリプトは OpsMgr RTM では問題なく動作します (Monitoring プロバイダのルートに移動する必要があります。この記事の場合は monitoring:\oxford.contoso.com です) が、OpsMgr SP1 では失敗します。OpsMgr SP1 でこのスクリプトを動作させるには、図 7 の最初のコマンドを次のように変更する必要があります。
$managementServer = Get-RootManagementServer
図 7 エージェントのインストール
# Get the Root Management Server.
$managementServer = Get-ManagementServer -Root: $true

# Create the discovery configuration for computer2 and computer3.
$discoConfig = New-WindowsDiscoveryConfiguration -ComputerName: computer2, computer3

# Discover the computers.
$discoResult = Start-Discovery -ManagementServer: $managementServer -WindowsDiscoveryConfiguration: $discoConfig

# Install an agent on each computer.
Install-Agent -ManagementServer: $managementServer -AgentManagedComputer: $discoResult.CustomMonitoringObjects
これでエージェントが監視対象のリモート システムにインストールされましたが、最後に手順が 1 つ残っています。完全にこのシステムを監視する前に、管理サーバーで実際に新しいエージェントを承認する必要があります。何も操作を行わなかった場合、新しいエージェントを監視に使用することが監視サーバーによって自動的に承認されます。ただし、Get-AgentPendingAction コマンドレットを使用すれば、この承認処理を高速に実行できます。これを行うには、次の 1 行のコードを使用します。
Get-AgentPendingAction | Where Object {$_.AgentName –like
'computer*'} | Approve-AgentPendingAction
結果を Approve-AgentPendingAction ではなく Reject-AgentPendingAction に渡すと、承認が完了していない場合に、OpsMgr サーバーでこのエージェントの承認をブロックできます。承認が完了している場合は、代わりに Uninstall-Agent コマンドレットを使用します。
前述のように、Install-AgentByName を使用することによって、エージェントをインストールするコンピュータを直接コマンド ラインで指定することもできます。
管理パックを操作する さまざまな管理パックのタスクを実行するのに役立つコマンドレットが 4 つ提供されます。次のコマンドを使用すると、これらのコマンドレットを一覧表示できます。
Get-Command –noun ManagementPack
次の単純なコマンドを実行すると、現在インストールされている管理パックとそのバージョン番号が表示されます。
Get-ManagementPack | Format-Table –autosize
では、コマンド シェルで次のインストーラを使用して、2 つの一般的な管理パックをインストールしましょう。
  • Internet Information Services System Center Operations Manager2007 Management Pack.msi
  • Windows Server® Base OS System Center Operations Manager2007 Management Pack.msi
この記事の目的は、コマンド シェルを使用すると通常のタスクをどれぐらい簡単に実行できるかを示すことなので、できる限り少数のコマンドを使用してインストールを実行します (図 8 参照)。このインストール処理を変更してインストーラ (.msi ファイル) に quiet フラグを渡すこともできますが、ここではファイルの展開先を手動で選択することにします。
図 8 管理パックのインストール (画像をクリックすると拡大表示されます)
次に、共通ライブラリをインストールします。これを行うには、次のコマンドを使用します。
Get-ChildItem –Path C:\MPs –filter *Library.mp |
ForEach-Object
  {Install-ManagementPack –filePath $_.FullName}
続いて、必要なその他の管理パックをインストールします。
Get-ChildItem –Path C:\MPs –filter *200?.mp |
ForEach-Object
  {Install-ManagementPack –filePath $_.FullName}
図 9 のように、コマンド シェルに組み込まれているヘルプでは、シールされていない管理パックを Export-ManagementPack コマンドレットを使用してエクスポートするすばらしい例が提供されます。すべての管理パックをエクスポートするには、次の行をその下に記載されている行のように変更します。
$mps=Get-ManagementPack |
Where-Object {$_.Sealed –eq $false}

$mps=Get-ManagementPack
図 9 管理パックのエクスポート (画像をクリックすると拡大表示されます)
ユーザー ロールを操作する Get-UserRole コマンドレットではユーザーを管理するための機能が提供されますが、奇妙なことに、対になる Set コマンドレットが提供されないので、通常はこのコマンドレットを使用して変更や更新を行うことはありません (この情報は Windows PowerShell SDK のドキュメントに記載されています)。図 10 のように、まず現在のユーザー ロールを一覧表示し、次にユーザーを読み取り専用オペレータのグループに追加します (図 11 参照)。
図 10 ユーザー ロールの表示 (画像をクリックすると拡大表示されます)
図 11 ユーザーの追加 (画像をクリックすると拡大表示されます)
監査コレクション サービス (ACS) を有効にする ACS は Operations Manager 2007 の新しいオプション機能です。簡単に説明すると、この機能を使用してセキュリティの監査情報を一元的に管理できます。ACS は既定で有効になっておらず、通常は OpsMgr の展開におけるその後の段階で構成されます。
ACS 用に多くのエージェントを有効にする場合は、Windows PowerShell を使用してセットアップを自動化すると便利です。OpsMgr のベータ版では、すべてのエージェントで ACS を有効にするためのスクリプトが提供されました。SystemCenterForum.org の寄稿者でありブログ執筆者でもある Neale Browne は、このスクリプトを強化して他のパラメータのサポートを追加しました。
SystemCenterForum.org サイト (Microsoft® System Center ソリューションを提供しているコミュニティ サイト) では、ACS のセットアップを自動化できる 2 つの Windows PowerShell スクリプトが公開されています。特定のグループに属するすべてのエージェントで ACS のセットアップを実行するには、systemcenterforum.org/wp-content/uploads/ACSBulkEnableGroupDisplayName.zip を使用します。また、監視しているすべてのエージェントで ACS のセットアップを実行するには、systemcenterforum.org/wp-content/uploads/ACSBulkEnableAllAgents.zip を使用します。
エージェントのプロキシ処理を有効にする OpsMgr の環境では、エージェントレスでデバイスを監視する場合があります。このようなデバイスは、エージェントによって管理される、リモートで監視できるデバイスに割り当てるか、管理サーバーに割り当てる必要があります。Windows PowerShell スクリプトを使用して多くのエージェントを構成する方法の詳細については、systemcenterforum.org/enable-agent-act-as-a-proxy-in-bulk-via-powershell を参照してください。このスクリプトの更新版は、systemcenterforum.org/wp-content/uploads/SetAgentProxyBulk_FQDN.zip からダウンロードできます。
他にも、特定の管理パック用にエージェントをプロキシとして動作するように設定する必要が生じる場合があります。詳細については、管理パックのドキュメントを参照してください。

実際の使用例
このセクションではいくつかの実例を紹介し、Windows PowerShell がどれぐらい自動化に役立つかについてさらに詳しく説明します。
アラートを解決する 特定のコンピュータに設定された複数のアラートを削除することになった経験はあるでしょうか。この操作が必要になる状況としては、アプリケーションでエラーが発生した場合や、アラートが動的に解決されなかった場合が考えられます。次の 1 行のコマンドを使用すると、解決状態が 0 になっているすべてのアラートを解決できます。
Get-Alert –criteria 'ResolutionState = ''0''' |
Resolve-Alert | Out-Null
次の例では最初の例と同じ処理を実行しますが、未解決のアラート数が多い大規模な環境では、実行速度がはるかに速くなります。
Get-Alert | Where-Object {$_.ResolutionState -eq 0} |
Resolve-Alert | Out-Null
パフォーマンスが向上する理由は、criteria パラメータを使用すると、渡される値が直接 SQL Server® データベースに提供され、関連するデータのみが返されるからです。これによって、Windows PowerShell コンソールに返されるオブジェクトの数が減少します。
これで、1 つのコンピュータに設定されたすべての未解決のアラートを簡単に削除できるようになりました。必要に応じて、このコマンドが自動的に実行されるように設定することもできます。
最後に、特定の日付に設定されたすべてのアラートを表示できる簡単なコマンドを以下に示します。
Get-Alert -criteria 'TimeRaised >= ''4/25/2008'''
日付値の変更は非常に簡単です。また、この出力を Resolve-Alert コマンドレットに渡すこともできます。
アラートをテストする Windows イベント ビューアで特定のイベントを監視し、それらのイベントに関するテストを実行することが必要になる場合があります。次の 2 行のコマンドを使用すると、簡単なイベント ログのエントリを作成できます。
$api=New-Object -comObject MOM.ScriptAPI
$api.logscriptevent("API test",100,0,
  "Test using PowerShell")
ただし既定では、このエントリは Operations Manager のイベント ログに記録されます。このイベント ログは、特定のイベントの記録先として想定される場所ではないと思います。さいわい、マイクロソフトのプレミア フィールド エンジニアである Stefan Stranger によって、Windows イベント ビューアにイベントを作成できるスクリプトが提供されたので、さらに柔軟に特定のログへの記録を実行できるようになりました。このスクリプトについては、go.microsoft.com/fwlink/?LinkId=120308 を参照してください (このスクリプトは .cab ファイルにパッケージ化されているので、ファイルをダウンロードしたら、ファイルを右クリックしてスクリプトを展開する必要があります)。
Stefan のスクリプトについて唯一注意が必要な点は、イベント ソースとして入力された値によって、エントリの記録先となるログが決定されることです。アラートが適切なログに記録されたかどうかを確認するための最も簡単な方法は、Windows イベント ビューアを開いて最新のエントリのソースを確認することです。
担当者を設定する アラートの担当者を自動的に設定すると役立つ場合があります。コマンド シェルからこの設定を行うための単純な方法を次に示します。
$alert = Get-Alert
  -id f3f73d62-37ab-45ce-a7ff-2bdda0dfaeb4
$alert.set_owner("Administrator")
$alert.update("Updated owner")
このコードの 1 行目では、特定のアラートを表すオブジェクトの ID を取得して、$alert 変数に渡しています。2 行目では、変数を使用して担当者を設定し、最後の行では OpsMgr データベースに更新を適用しています。次のコマンドを使用してアラートの担当者を確認すると、担当者が変更されていることがわかります。
Get-Alert -id f3f73d62-37ab-45ce-a7ff-2bdda0dfaeb4 |
Select-Object Owner
すべてのアラートに担当者を設定するには、次のようにコードを単純化します。
Get-Alert | ForEach-Object {$_.Set_
  Owner("Administrator");
  $_.Update("Owner set")}
監視の状態を復元する "監視しない" 状態になっているエージェントに遭遇する場合があります。このような場合、すべてのエージェントを完全に監視されている状態にすばやく復元してから問題の内容を特定することが必要になる可能性があります。図 12 のスクリプトをコマンド シェルから直接実行すると、影響を受けるすべてのエージェントを、完全に監視されている状態に復元できます。
図 12 正常性サービス ストアのリセット
$all="Microsoft.SystemCenter.AllComputersGroup"
$agents = Get-ChildItem Microsoft.SystemCenter.AllComputersGroup | `
  Where-Object {$_.HealthState -eq 'Uninitialized'}
foreach ($agent in $agents)
{
$agent.DisplayName
Push-Location $all\$agent\Microsoft.SystemCenter.HealthService
Get-Task | Where-Object {$_.Name -eq "Microsoft.SystemCenter.ResetHealthServiceStore"} | `
    Start-Task -Asynchronous
Pop-Location
}
図 12 のコードをご覧ください。変数を宣言した後、この RMS 上で実行されているすべてのエージェントの一覧を取得し、問題が発生している可能性があるエージェントをフィルタ選択します。続いて非同期にタスクを呼び出し、このタスクで、フィルタ選択したすべてのエージェントの正常性サービス ストアをリセットします。
アラートと管理パックを関連付ける 図 13 は、すべての新しいアラートと、各アラートが関連付けられた管理パックの一覧を表示する方法を示しています。
すべての管理パック名を確実に解決するには、コードにいくつか工夫を施す必要がありました。アラートの発生元がルールとモニタのいずれであるかによって、使用するコマンドレットは異なります (図 13 では、Get-Monitor コマンドレット用のちょっとした回避策を実装する必要がありました。OpsMgr SP1 では、このコマンドレットで新しい ID パラメータがサポートされるようになったので、コードが若干単純になるはずです)。
図 13 管理パックの検索
Get-Alert | Where-Object {($_.PrincipalName -ne $null) -and ($_.ResolutionState = '0')}| `
Format-Table –autosize PrincipalName,Severity, `
  @{Label="MP"
      Expression={If(!($_.IsMonitorAlert)){
        ForEach-Object {
          ((Get-Rule $_.MonitoringRuleId).GetManagementPack()).DisplayName}
       }
       Else{
         ForEach-Object {
          $id=$_.ProblemId
          ((Get-Monitor -criteria "Id='$id'").GetManagementPack()).DisplayName}
         }
   }
}
レポートを簡単に生成する 環境をアップグレードする場合、インストールされているすべてのバージョンのエージェントを監査すると役立つことがあります。次のような単純なスクリプトを実行するだけで、便利なレポートを出力できます。
Get-Agent| `
Format-Table DisplayName,@{ `
  Label="Version"
  Expression={ `
    switch ($_.Version){
    "6.0.5000.0" {"RTM"}
    "6.0.6246.0" {"SP1 (RC)"}
    "6.0.6278.0" {"SP1 (RTM)"}
    }
  }
}
図 14 は、このスクリプトの出力を示しています。このスクリプトは、systemcenterforum.org/checking-operations-manager-2007-agent-and-server-versions-via-powershell で公開されている例を拡張したものです。
図 14 いくつかのバージョンのエージェントを示す出力 (画像をクリックすると拡大表示されます)
タスクをスケジュールする Windows PowerShell を定期的に実行することもできます。たとえば、OpsMgr サーバーを管理するためにクライアント コンピュータからそのサーバーに接続しており、OpsMgr の管理ツールをローカルにインストールしているとします。さらに、エージェントのバージョンを示すレポートを毎日実行し、現在の日付が名前に含まれたファイルに出力を保存する必要があるとします。このような場合、Windows に組み込まれているタスク スケジューラを使用して、スクリプトをローカル コンピュータから実行できます。
これを行うには、新しいタスクを作成し、実行するプログラムとして powershell.exe (通常の場所は C:\Windows\System32\WindowsPowerShell\v1.0) を設定するだけです。タスクを作成したら、そのタスクを編集し、次のような内容でコマンドが実行されるようにします。
C:\Windows\System32\WindowsPowershell\v1.0\powershell.exe
  –Command "& {& 'c:\agent_report2.ps1'}"
結局、元の Windows PowerShell コードに多くの変更を加えることになりました (図 15 参照)。まず、OpsMgr の PowerShell スナップインを追加し、OperationsManagerMonitoring プロバイダにマップされた Monitoring ドライブを作成し、RMS への接続を作成する必要がありました。また、OpsMgr 用のカスタム Windows PowerShell スクリプト (Microsoft.EnterpriseManagement.OperationsManager.ClientShell.NonInteractiveStartup.ps1) を読み込むことによって、OpsMgr のみで提供される機能を読み込む必要がありました。
図 15 エージェントのバージョンを表示するスクリプトのスケジュールを設定する
Add-PSSnapin Microsoft.EnterpriseManagement.OperationsManager.Client
New-PSDrive Monitoring Microsoft.EnterpriseManagement.OperationsManager.Client\
  OperationsManagerMonitoring ""
New-ManagementGroupConnection Oxford.contoso.com

Set-Location 'C:\Program Files\System Center Operations Manager 2007'
./Microsoft.EnterpriseManagement.OperationsManager.ClientShell.NonInteractiveStartup.ps1

$file="C:\$(Get-Date -f `"MMddyyyy`").rpt"

Get-Agent -Path Monitoring:\Oxford.contoso.com | `
Format-Table DisplayName,@{ `
  Label="Version"
  Expression={ `
    switch ($_.Version){
    "6.0.5000.0" {"RTM"}
    "6.0.6246.0" {"SP1 (RC)"}
    "6.0.6278.0" {"SP1 (RTM)"}
    }
  }
} | Out-File $file
ただし、他にも問題はあります。お気付きになると思いますが、このスクリプトを実行するシステムにユーザーがログオンしている場合、タスクが実行されるたびに黒いコンソール ウィンドウが表示されます。Sapien の Don Jones と Jeffery Hicks によって、この問題を解決するためのちょっとした工夫が施されました。詳細については、blog.sapien.com/index.php/2006/12/26/more-fun-with-scheduled-powershell を参照してください。
簡単に言えば、スクリプトを VBScript でラップする必要があります。これを行うには、スケジュールしたタスクから次のコードを呼び出す代わりに、図 16 のようなコードを使用します。
C:\Windows\System32\WindowsPowershell\v1.0\powershell.exe
  –Command "& {& 'c:\agent_report2.ps1'}"
図 16 コンソールが表示されないようにする
Dim objShell
Set objShell=CreateObject("WScript.Shell")

'enter the PowerShell expression you need to use short filenames and paths
strExpression="'c:\agent_report2.ps1'"

strCMD="powershell -nologo  -command " & Chr(34) & _
"&{&" & strExpression &"}" & Chr(34)

'Uncomment next line for debugging
'WScript.Echo strCMD

'use 0 to hide window
objShell.Run strCMD,0
これで wscript.exe プログラムがタスクで使用されるようになったので、次の呼び出しを実行します。
C:\WINDOWS\System32\wscript.exe C:\agent_report.vbs
これによって自動的にレポートを作成できるようになり、ログオンしているユーザーにその処理が表示されなくなります。

まとめ
この記事では、OpsMgr 2007 で使用できる新しい自動化機能について駆け足で説明しました。紹介できたのは、Windows PowerShell を使用して OpsMgr を管理する方法のほんの一部にすぎません。
この記事で紹介したすべての方々、および MOM MVP であり SystemCenterForum.org の創設者でもある Pete Zerger の貴重な協力に感謝します。

Marco Shaw は、カナダの電気通信企業に勤務する IT システム アナリストです。彼は IT 業界に 10 年以上携わっており、最近 Windows PowerShell の MVP を受賞しました。Marco は powershellcommunity.org で公開されている新しい PowerShell コミュニティ Web サイトのコミュニティ責任者補佐でもあります。彼のブログは marcoshaw.blogspot.com で公開されています。


インターネット インフォメーション サービス
ASP.NET アプリケーションを拡張する : 得られた教訓
Richard Campbell
概要 :
  • 開発および IT チームによる共同作業の重要性
  • 重要な拡張戦略について理解する
  • チーム間で知識を共有する
  • 主要な知識について意見を一致させる

目次
拡張の基礎
意見の一致
ネットワーク チームが開発チームから得る必要がある情報
開発チームがネットワーク チームから得る必要がある情報
話を拡張に戻します
協力して火を消し止める
私がコンサルタントとしてこれまでに成功させた ASP.NET アプリケーションの拡張は、開発者 (アプリケーションの構築者) と管理者 (アプリケーションの実行者) が共同作業を行うことによって実現されました。残念ながら、この共同作業の必要性は、アプリケーション
ライフサイクルの初期段階では明らかにならない場合があります。このため、私がアプリケーション ライフサイクルに関与するのは、その初期段階ではなく、最終段階で問題が発生したときだけです。
これはまったくの真実ですが、最初から効率的に拡張できるアプリケーションは存在しません。最初からすべてを成功させることは不可能です。アプリケーションの拡張を成功させるには、アプリケーションがどのようにして構築されたか、およびそのアプリケーションが実行される運用環境はどのようなしくみになっているかを理解する必要があります。つまり、開発チームとネットワーク チームの両方から情報を収集する必要があります。知識を共有することなく、成功を収めることはできません。

拡張の基礎
拡張を行う前に、実際に ASP.NET アプリケーションを拡張するために必要な知識について学習しましょう。一般的に使用される戦略としては、専門化と分散の 2 つがあります。大規模な ASP.NET アプリケーションの拡張では、ほとんどの場合、両方の戦略が使用されます。また、ASP.NET アプリケーションの拡張に役立つあらゆる方法は、このいずれかの戦略に分類されます。
専門化では、アプリケーションの要素を分割し、それらを個別に拡張できるようにします。たとえば、ASP.NET ページの表示に使用するサーバーとは別に、専用のイメージ サーバーを構築する場合があります。イメージ サーバーの最適な構成は、ASP.NET サーバーとは大幅に異なります。また、イメージの要求をアプリケーションの他の部分から分離することによって、サードパーティ製のリソースを使用してイメージを提供することもできます。他のリソース ファイルにも同じ方法を適用できます。
これに対して分散は、通常 Web ファームと呼ばれる複数のサーバーに、アプリケーションを対称的に分散させます。ASP.NET アプリケーションは分散に最適です。これは、個々のページ要求が比較的小規模で、特定のユーザーの対話が他のユーザーに大きく依存するからです。分散は、まさに "スケールアウト" という考え方の表れです。スケールアウトでは、中程度のパフォーマンスを提供する複数のサーバーが連携してユーザーにサービスを提供するので、パフォーマンスの高い 1 台の大規模なサーバーがすべての処理を行う "スケールアップ" とは異なります。
専門化と分散を組み合わせると、アプリケーションの中でパフォーマンスの強化が必要な要素のみを分散させることができるので、効率が向上します。たとえば、専用のイメージ サーバーを作成したが、まだイメージの提供速度が不十分である場合は、アプリケーション全体用のサーバーを追加せずに、イメージ サーバーを追加できます。これらの戦略を考慮することは、ASP.NET アプリケーションのパフォーマンスと拡張性を強化するうえで重要です。

意見の一致
どの ASP.NET アプリケーションのライフサイクルでも、高い確率で開発チームとネットワークまたは IT チームのミーティングが開かれます。運が良ければ、このミーティングはアプリケーションを展開する前に開かれますが、問題が発生してから開かれることもあります。たとえば、テスト環境で正常に動作したアプリケーションをユーザーの環境で実行したときに、十分なパフォーマンスが得られない場合などが考えられます (このような状況で私たちコンサルタントにお呼びがかかります)。
開発チームとネットワーク チームのミーティングを開く主な目的は、情報を交換することです。開発チームはアプリケーションに関する重要な知識を持っており、ネットワーク チームは運用環境に関する知識を持っています。各グループはもう一方のグループのデータを理解する必要があるので、ミーティングを開く時期がアプリケーション ライフサイクルの早い段階であればあるほど有効です。
問題が発生して初めてミーティングを開くことは避けてください。2 つのチーム間で十分な共通理解がなければ、アプリケーションのパフォーマンスが要件を満たしていない理由を突き止めるのは非常に困難です。また、一方のチームが守りに入って問題の原因をすべてもう一方のチームに押し付けるという事態も非常に発生しやすくなります。問題の原因は常に両方のチームにあるので、非常に複雑な問題が発生した場合は、必ず両方のチームが解決に当たる必要があります。
ただし、問題が発生していない場合でも、このようなミーティングを進めるのは非常に大変です。過去に私が開いたミーティングでは、ネットワーク チームがテーブルの片方の側に座り、開発チームがもう片方の側に座りましたが、最初は両者の見つめ合いになってしまいました。話を進めるために、私はミーティングの主な目的が知識の交換であることを説明しました。だれが口火を切るかは問題ではありません。それではまず、ネットワーク チームが開発チームから得る必要がある情報について説明します。

ネットワーク チームが開発チームから得る必要がある情報
どの ASP.NET アプリケーションにも独自の可変要素が含まれますが、すべての場合に当てはまる重要な要素があります。そのうちの 1 つが web.config ファイルです (図 1 参照)。web.config は、開発とネットワークに共通する要素です。このファイルは開発チームによって構成されることもあれば、ネットワーク チームによって構成されることもあります。どちらの場合も、web.config の内容によってハードウェアとネットワークの構成が制限され、アプリケーションの動作が直接その影響を受けます。web.config ファイルの詳細を説明するには書籍 1 冊分のスペースが必要になってしまうので、ここではポイントのみを説明しますが、どちらのグループも web.config ファイルについて学習し、その内容によって提供される構成や、それぞれの設定がアプリケーションと環境に与える影響を理解し、意見を一致させる必要があります。
図 1 アプリケーションのいくつかの設定とカスタム エラーの構成を含む基本的な web.config (画像をクリックすると拡大表示されます)
たとえば、web.config の <authorization> セクションでは、アプリケーション内でどのようにユーザーを認証するかを指定し、依存関係を定義します。アプリケーションで Windows® 認証を使用する場合、そのアプリケーションは Active Directory® に依存する可能性があります。フォーム ベースの認証を使用する場合は、ユーザー アカウントのデータ ストアに依存することになります。このセクションの内容については、確実に話し合う価値があります。
特筆すべきは、ユーザーにエラーがどのように通知されるかを指定する <customErrors> セクションです。設定は複雑ではありませんが、どのようなエラー ページを表示するかについて理解するためだけでも、このセクションについて話し合う価値はあります。共同作業サイクルの初期段階では、おそらくカスタム エラー ページは存在しないので、このページについて話し合うことをお勧めします。
web.config の <appSettings> セクションは、特に重要な意味を持ちます。開発者はこのセクションに、データベースの接続文字列など、広い範囲で使用される値を指定します。また、このセクションは依存関係の基盤にも適しており、フェールオーバーや移行などの計画時にも重要な役割を果たします。<appSettings> は完全なカスタム セクションであり、どのような値でも指定できるので、指定した値の意味を伝えるために多くの説明が必要になる場合があります。このセクションにはよく値が孤立 (アプリケーションのどの部分でもこの値が使用されない事態が発生) します。
開発チームが <appSettings> を使用していない場合、ネットワークまたは運用チームは、そのセクションを使用するよう開発チームに要求した方がよいでしょう。このセクションにすべてのデータベース接続文字列を指定しておけば、単純なフェールオーバー戦略を効率的に作成できます。データベース サーバーで障害が発生した場合、代わりの文字列を挿入し、別のデータベース サーバーを参照できます。開発サイクルの初期段階でこの機会を得ることによって、アプリケーションの信頼性と保守性を強化できます。
最後に、拡張という観点から非常に重要な意味を持つ要素は <sessionState> タグです。このタグでは、アプリケーションのセッションに関するデータの格納先を指定します。既定では "InProc" が指定されており、これはセッション データが ASP.NET アプリケーションと同じプロセス空間に格納されることを意味します。セッション データを同じプロセス内に格納するように構成することは、負荷分散の観点から見ると厄介です。これは、常に特定のユーザーからの要求を、セッション データが格納されている同一のサーバーで処理する必要があるからです。このセクションは、拡張方法とフェールオーバーの実装方法に直接影響を与えるので、開発チームとネットワーク チームがこのことについて話し合う価値は大いにあります。早い段階で話し合っておけば、ビクビクしながらアプリケーションをデバッグする必要もなくなります。
セッション状態の話題になれば、通常はそこからアプリケーションの負荷分散要件に関する話題にスムーズに移行できます。環境によっては、特定の機能が実装された専用の負荷分散ハードウェアを使用する場合もありますが、アプリケーションでこれらの機能に対処できなければ、あまり意味がありません。私は、セッション データを同じプロセス内に格納する ASP.NET アプリケーションでハードウェア負荷分散を使用する環境を担当したことがあります。この環境では、セッションが突然終了することがありました。アプリケーション内にバグが存在することも考えられましたが、そうではなく、構成に誤りがありました。
ネットワーク チームは、アプリケーションに適した負荷分散構成に関する正確な情報を開発チームから得る必要があります。この双方向のやり取りで、使用できる負荷分散構成と、アプリケーションで対処できる負荷を確認します。アプリケーション ライフサイクルの早い段階でこの話し合いを持つことの大きな利点は、異なるプロセスにセッション データを格納する、アフィニティを使用しない負荷分散構成を前もって計画できることです。
ASP.NET アプリケーションを展開する準備が整う (または展開の初期段階に達する) ころには、開発チームのメンバは、アプリケーションの高速および低速な部分を熟知しています。最も重要なのは、これらのメンバがシステム内のボトルネックや危険性の高い部分を認識していることです。ネットワークまたは運用チームは、これらのボトルネックについて理解することによって、前もって問題の発生に備えたり、問題を回避したりできます。
たとえば、以前担当した環境では、毎晩あるアプリケーションが稼動していない時間帯に、そのアプリケーションで大量のデータを読み込む処理を実行していました。開発チームはそのデータ読み込みメカニズムを構築し、テストし、そのしくみを理解していました。また、この処理はデータベースに大きな負荷を与えるが、効果が高く、問題の解決に適した方法であることを認識していました。
ただし、開発者はこの処理が実行されることをネットワーク チームに報告せず、実行時刻を午前 1 時に設定しました。これはデータベースのバックアップが実行される時刻とまったく同じです。データベースはオンラインのままでしたが、データベースに送信されたすべてのトランザクションがトランザクション ログに記録されるので、バックアップ処理のパフォーマンスは低下しました。
競合が検出されて初めて、データの読み込みとバックアップを同時に実行したときに作成されるデータベースのトランザクション ログによって、ディスク領域がいっぱいになることがわかりました。データの読み込みを実行する時刻を午前 3 時に変更することによって、問題は完全に解決されました。
このような負荷について早い段階で話し合いを持つことによって、後からアプリケーションで問題が発生する可能性を大幅に低下させることができます。

開発チームがネットワーク チームから得る必要がある情報
ミーティングで、ネットワーク チームが開発チームに情報を提供するときは、まずネットワーク図を使用して説明することを強くお勧めします。ほとんどの場合、開発者はネットワークを図 2 のようなものと考えます。つまり、ネットワークが存在せず、Web サーバー、ブラウザ、およびインターネットのみが存在するようなイメージを持っています。
図 2 開発者が考える単純なネットワーク図 (画像をクリックすると拡大表示されます)
もちろん実際はもっと複雑です。図 3 も単純化されていますが、こちらの方がより現実に近い構造を表しています。図 3 を見てすぐに、仮想プライベート ネットワーク (VPN) ユーザーはどのようにアプリケーションを操作するのか、内部ユーザーとパブリック ユーザーの認証はどのような点で異なるのかなど、さまざまな疑問が浮かぶと思います。
図 3 開発者が理解する必要がある実際のネットワーク (画像をクリックすると拡大表示されます)
単にネットワーク図を提供するだけでは不十分であることは明らかです。図を見ただけで、アプリケーションに影響を与える要素について正確に理解することは不可能なので、ネットワークについて詳しく説明する必要があります。この説明は、実際のパブリック ユーザー、VPN ユーザー、および内部ユーザーの接続プロセスを例に挙げて行う必要があります。また、特に複雑な DMZ 形式のネットワーク アーキテクチャで使用されるさまざまなファイアウォール規則について話し合うことによって、アプリケーションで発生する可能性がある問題を確認します。
言うまでもなく、アプリケーションを展開する前 (開発を始める前でもよいでしょう) に、これらすべての内容について話し合うことが一番ですが、何があってもどこかの時点ではこのような話し合いを持ち、全員がネットワーク図の内容を完全に理解することが重要です。
ネットワークの構成はフェールオーバーおよび冗長性モデルにも影響を与えますが、なんらかのソフトウェアによるサポートを提供するか、少なくとも障害時の動作を認識しなければ、これらのモデルが計画どおりに機能することはほとんどありません。このため、どのような障害が予想されるかについて、細かい部分まで話し合う必要があります。データベース クラスタを実装している場合、データベースへのアクセスに関連するコードが影響を受けることになります。たとえば、サーバー間の切り替えが発生した後でクエリを再試行できるか、冗長なサイトを使用できる場合はどのようにしてデータをそのサイトにレプリケートすればよいか、あるサイトから別のサイトへの切り替えをどのように実行するかなどについて話し合う必要があります。
もう一度言いますが、早い時期に話し合いを持つのが一番です。ただし、時期が遅くなってもまったく話し合わないよりは効果があります。アプリケーション ライフサイクルにかかわるすべてのメンバが、各構成要素のしくみについて理解する必要があります。必要なときに機能しないフェールオーバー ソリューションを実装しても、ストレスのもとになるだけです。
最後に、共有する必要があるもう 1 つの重要なネットワーク リソースは運用ログです。私はいつも、運用ログを開発チームに公開することを推奨しています。たいていネットワーク チームは、「言ってくだされば送りますよ」という反応を返しますが、これでは不十分だと思います。開発者が自分たちでログを (通常はバックアップ サイトから) 取得できるようにした方が効果的です。
問題が発生した場合、運用ログは必要不可欠です。多くの場合、これらのログは、実際にどのような問題が発生したかについて、事実に基づいた真正なデータを提供する最も有用な (かつ唯一の) 情報源になります。ただし、運用ログは通常の状況でも同様の価値をもたらします。開発者は運用ログに定期的にアクセスすることによって、新しく実装した機能がどのように動作するかを確認できます。また、新しい機能が期待どおりに動作しない場合は、そのことに気付き、危機的な状況を迎える前に問題を解決することもできます。全員が運用ログにアクセスできれば、問題に対して迅速に行動を起こし、それらを解決できます。

話を拡張に戻します
ネットワーク チームと開発チームのミーティングにおいて大事なのは、ASP.NET アプリケーションの拡張に関する問題の全容を理解することです。実際にアプリケーションを運用する環境は、そのアプリケーションで実行するコードの動作に直接影響を与えます。また、拡張に関するすべての戦略が、運用環境でのアプリケーションの動作に影響を与えます。アプリケーションの中で SSL に関連する部分を分離するなどの専門化戦略を適用するには、ネットワーク環境に変更を加え、場合によってはサーバー自体に変更を加えることが必要になる場合もあります。
キャッシュの使用など、一見コード中心の変更のようでも、それが環境に影響を与える可能性があります。これは、ASP.NET アプリケーションにデータ キャッシュ機能を追加すると、メモリの使用率が増加する代わりに、データベースを呼び出す回数が減少するからです。このため、必要な ASP.NET サーバーの数が増加したり、サーバー上でのワーカー スレッドの再利用回数が増加すると、ネットワーク監視機能によってイベントが発行される場合があります。
ASP.NET アプリケーションの拡張は、開発チームとネットワーク チームの両方に影響を与えるので、意思決定プロセスにはどちらのグループも参加する必要があります。共同作業を行えば、それぞれのチームが別々に作業していたときには発見できなかった独自の解決策が生まれるでしょう。たとえばネットワーク チームは、開発チームが社内の既存のハードウェア ソリューションを活用して、パフォーマンスおよび拡張要件を満たすアプリケーションを作成できる可能性があることに気付くかもしれません。アプリケーションと環境について詳しく話し合うことによって、このような機会を得ることができます。

協力して火を消し止める
ASP.NET アプリケーションの拡張に関する参考資料

  • 高パフォーマンス ASP.NET アプリケーションの開発
  • .NET アプリケーションを拡張する方法
  • [HOWTO] .NET Framework をベースに構築されたアプリケーションのパフォーマンスの調整
  • 拡張可能なアーキテクチャの実装
  • IIS のパフォーマンスの最適化
  • ASP.NET アプリケーションのスケーリング戦略
拡張時に問題が発生するのは必ずしも悪いことではなく、たいていは良いことです。この問題は、アプリケーションを実行しようとしているユーザーの多さが原因で発生するので、アプリケーションの価値が証明されたことになります。ただし、この状況に対処し、アプリケーションを正常に動作させなくてはなりません。
拡張時の問題は、別のことが原因で発生する場合もあります。たとえば、企業が宣伝活動を行っている場合や企業のことがブログに書かれた場合、非常に多くのソーシャル ネットワーキング サイト ユーザーによってこのアプリケーション (Web サイト) が参照された場合など、さまざまな状況が考えられます。そして突然、問題の火を消し止めてアプリケーションの実行を継続する必要が生じます。ご想像のとおり、このようなシナリオが実際に発生する前に、対処方法を準備しておくことが一番です。開発チームとネットワーク チームのミーティングを締めくくるときに、組織でこのような問題に対処するには共同作業が必要であることを説明するとよいでしょう。
問題の解決に関する疑問として 1 つ目に挙げられるのは、「過剰な負荷が原因でサイトがダウンしていることを検出するにはどうすればよいか」ですが、たいていは「CTO から連絡をもらう」という答えが返ってきます。他の人から連絡を受けた時点で Web サイトの問題に気付いても、適切な行動を取ることはできません。電話が鳴る前に、なんらかの計測結果に基づいて問題を認識できるようにする必要があります。その場合もだれかから連絡はありますが、少なくとも問題の発生を見越して、今までとは異なる受け答えをすることができます。CTO に「本当ですか」と応答しているようでは出世の見込みはありません。
次の疑問は、「まずだれに連絡すればよいか、だれが最初に行動を起こすのか」です。多くの場合、ネットワーク チームのメンバが最初に問題の兆候に気付きますが、比較的経験の浅いメンバである可能性もあるので、明確なエスカレーション計画が必要です。では、次はだれに連絡すればよいでしょうか。難しいのは、早めかつ迅速に診断を行い、どのような問題が発生しているかを把握することです。ネットワーク障害であれば自分たちで解決できるかもしれませんが、拡張に関する問題となると、話はまったく別です。この場合、早めに開発チームのメンバを招集するのが賢明です。
消火活動にかかわるメンバには十分な情報が必要なので、効率よく情報にアクセスできることは重要です。できる限り多くの情報を提供して、効果的な判断を可能にすることを目指します。これによって、解決が必要な問題の範囲を特定できるようになります。
唯一の解決策がコードを記述することである場合、コードを記述せず、それ以上の対応を施さないことがよくあります。もちろん問題が発生したことを記録し、今後の開発作業の優先順位付けに役立てることも重要ですが、山のようなコードを記述し、十分にテストせずにそれらを運用することは適切 (言い方を変えれば賢明) ではありません。消火活動で一番大事なのは、火がそれ以上燃え広がらないようにすることです。
拡張に関する問題が発生した場合、状況によっては単純に待機することが解決策になります。これも選択肢の 1 つとして考えてください。
同時に、このような不測の事態に備えることによって、実際に問題が発生したときにさまざまな技法を迅速に適用できるようになります。多くの場合、拡張に関する問題にネットワーク チームと開発チームが協力して取り組めば、非常に短い時間で問題を解決できます。企業で行っている宣伝活動を成功させることもできるでしょう。
結論を述べますが、ネットワーク チームから得られた教訓は、拡張性とパフォーマンスの高い ASP.NET アプリケーションを提供するには、アプリケーションを構築するメンバと、そのアプリケーションを展開および運用するメンバが緊密に協力する必要があることです。
必ずどこかの段階で共同作業を行うことになるので、早い段階でチーム間のミーティングを開いて情報を共有するに越したことはありません。このミーティングの目的は、アプリケーションの役割、しくみ、依存関係、負荷がかかったときの動作、時間の経過と共に発生する問題への対処方法など、アプリケーションのすべての要素について理解と同意を得ることです。
この共同作業を非常に効率よく行うことができれば、企業の敏捷性は向上します。つまり、発生した問題に迅速に対処し、将来の成功に向けてアプリケーションが必要とする要素に関する明確な目標を確立できるようになります。

Richard Campbell は、マイクロソフトの地域担当責任者であり、ASP.NET の MVP でもあります。また、.NET Rocks (dotnetrocks.com で公開されている .NET 開発者向けのインターネット オーディオ トークショー) の共同司会者も務めています。彼は数年にわたって企業を対象としたコンサルティング活動に従事しており、パフォーマンスと ASP.NET の拡張に関するアドバイスを行っています。さらに、彼は Strangeloop Networks の共同創立者でもあります。


編集長から Tech•Ed の会場からお伝えします
Joshua Hoffman

毎月、編集後記の執筆を始めるときには頭を悩ませます。興味深い話題は常にたくさんあるので、話題を考え出すこと自体はあまり困難ではありませんが、問題は、編集後記を一般の読者が読む約 6 週間前に執筆する必要があるということです (印刷する時間を確保するためというのも理由の 1 つですが、記事をリライトする編集者が私の間違いをすべて修正する時間をたっぷり確保するためというのが主な理由です)。完全に執筆時点に対応した内容を記事にできるブログとは違って、このような状況で "ニュース" を取り上げるのは困難です。というのも、皆さんが読むころには、それは既にニュースではなくなっているからです。
でも、私は今、"太陽がさんさんと降り注ぐ" オーランドで開催中の Tech•Ed 2008 に来ています。これは、マイクロソフトで現在行われていることの中で最も重要なことです。ですから、皆さんが読むころには、少し話題が古くなってしまうかもしれません。厄介ですね。
Tech•Ed は、さまざまな理由から、私たちにとって興味深いイベントです。その理由の 1 つは、このイベントが、多くの読者に (さらには執筆者にも) 直接会うことができる、1 年のうちで数少ない機会だということです。ありがたいことに、電子メール、インスタント メッセージ、および電話は一年中いただくのですが、これほど多くの方々から発信される、勢いのあるアイデアや興味深い会話にかなうものはありません。
また、Tech•Ed は、来年のことを考える絶好の機会でもあります。経営幹部が来場し、大局的な戦略について説明するので、きっと皆さんのお役に立つでしょう。仮想化における新しい方向性、次世代の Web、システム管理における画期的な概念など、いろいろな話を聞くことができます。
ただし、私がここに来ているのには、具体的な理由があります。マイクロソフトのテクニカル フェローで、寄稿編集者でもある Mark Russinovich が、セキュリティ境界の再定義について講演します。また、Steve Riley (彼も寄稿編集者の 1 人です) は、ネットワーク境界の完全な消滅について講演します。これは非常に刺激的で革新的な概念です。そして、Mark Minasi、Romi Mahajan、Dharmesh Godha、および私は、IT が一般消費者向けになっていくことについてのパネル ディスカッションを担当します。
また、私は、TechNet Magazine の記事の執筆を希望する方がまずどうすればよいかについてもお話します。ここ数年間、同様の講演を行ってきましたが、初めて記事を執筆する多くの方々の意欲を引き出すのに一役買ってきたと自負しています。皆さんがこの記事を読むころには、私が講演で使用したスライドが TechNet Magazine のブログ (blogs.technet.com/tnmag) に掲載されている予定ですので、ご自由にご覧ください。ひょっとしたら、来年は、皆さんが TechNet Magazine の記事の執筆者の 1 人として Tech•Ed に参加することになるかもしれませんよ。
そうそう、Tech•Ed のパーティについても忘れてはいけません。私たちは、このパーティも非常に気に入っています。
—Joshua Hoffman

次のマイクロソフト技術支援スタッフに心より感謝します。Sunil Agarwal、Eric Charran、Trina Gorman、Sanjeev Nair、Isaac Roybal、Jez Sadler、Roger Sprague、Stefan Stranger、Kevin Sullivan、Jim Truher、Alan von Weltin、Michael Walsh、Buck Woody


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

SharePoint コンテンツ タイプ
Microsoft® SharePoint® コンテンツ タイプの使用に関する詳しい情報を探しています。このような情報はどこで入手できますか。
- E.A.

このような情報をお探しなら、Microsoft SharePoint 製品とテクノロジ チームのブログ (blogs.msdn.com/sharepoint) と、カスタム コンテンツ タイプを使用したデータ管理の標準化に関する Pav Cherny の記事 (technet.microsoft.com/magazine/cc194408) を参照することをお勧めします。エンタープライズ メタデータの管理に関するホワイト ペーパー (technet.microsoft.com/library/cc262729) も役立つ場合があります。
他には、Andrew May のブログ (blogs.msdn.com/andrew_may) もお勧めです。Andrew は、マイクロソフトのプログラマ兼ライターで、Windows® SharePoint Services 3.0 と Microsoft Office SharePoint Server 2007 のエンタープライズ コンテンツ管理機能に関する開発者向けドキュメントの執筆を担当しています。彼は、ブログではコンテンツ タイプについて書いています。また、コンテンツ タイプや SharePoint 環境のエンタープライズ コンテンツ管理のより複雑な側面を扱った技術的なイラストをあしらったポスターも提供しています。

セキュリティ議論の拡張
「隠すことによるセキュリティに関する大論争」(2008 年 6 月、technet.microsoft.com/magazine/cc510319) という記事は最高でした。唯一残念だと思ったのは、管理者名の変更だけが取り上げられていた点です。管理者名の議論に関して、私はほぼ Roger Grimes 氏と Aaron Margosis 氏の見解に賛成しています。というのも、何もしないよりはましであり、管理上の問題の発生度合いが低いという考えに同感しているからです。ただ、非常に多くの課題があります。管理共有について触れられましたが、完全には掘り下げられてはいませんでした。しかし、これがブロックされると、重大な管理上の問題が発生します。
ぜひ、"攻撃を受ける確率を低くすること" の賛否を巡るこのグループの議論を見たいと思っています。攻撃を受ける確率を低くすることは、隠すことによるセキュリティの 1 種です。というのも、ほとんどのユーザーは場所や ID を伝達するものをシャットダウンすることでそれを実現しているからです。たとえば、多くのユーザーは、隠すことによるセキュリティという名目で IPv6 を排除しています。多くの場合、サービスの削除は、目を閉じながら体内に手を入れて患者が死なないように祈る中世の医療のように行われています。
- Shelly B

説明の焦点が管理者名の変更に限定されていたことについては、まったくそのとおりです。当初の草稿には他の例も多く含まれていましたが、他の例を削減しなければ 20 ページもの長編記事になっていました。そのため 1 つの例に注目したところ、管理者アカウントの問題に最も多く触れていたようです。しかし、この問題については近いうちに詳しく取り上げる予定ですので、ご安心ください。

十分にあいまいではない
「隠すことによるセキュリティに関する大論争」は良い記事でした。この記事について考えてみたところ、2 つのことに気付きました。まず、隠すことの投資収益率 (ROI) が高ければ、隠すことは適切な措置だと思います。また、ほとんどの IT セキュリティには常にあいまいな要素があったと思います。
たとえば、パスワードについて考えてみましょう。私たちは、時間の経過と共にパスワードをより一層あいまいなものにしてきました。初めのころは、ほとんどの PC ではパスワードが不要でした。その後、コンピュータどうしが接続されるようになったときには、簡単なパスワードがあれば十分でしたが、接続対象が増加すると、少なくとも 8 文字のパスワードを指定することが重要となりました。そして、その 8 文字のパスワードの安全性が不十分になると、大文字と小文字を組み合わせたり、パスフレーズを使用したりする必要が出てきました。おそらく、今後も、既存のあいまいにすることによる保護は、やがて十分にあいまいなものでなくなるというサイクルがずっと続くでしょう。
- Tom B

Tom さん、非常に鋭いご指摘をありがとうございます。特に多要素認証 (たとえば、スマート カードとパスワードの組み合わせ) などのセキュリティ概念の普及により、この傾向がどのように展開するのか非常に興味があります。

TechNet Magazine のポスター
私の会社の開発者のために、いくつかの TechNet Magazine で付録として提供されていたマイクロソフトのポスターを入手したいと思っています。どうすれば購入できますか。
- Helen G

入手可能なポスターは 3 種類あって、Microsoft Exchange Server 2007 Component Architecture、Windows Server® 2008 Active Directory® Feature Components、および Windows Server 2008 Feature Components です。購入についてのお問い合わせは、米国およびカナダにお住まいの場合は 800-444-4881 まで、その他の国と地域にお住まいの方は 785-838-7500 までご連絡ください。


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

サーバーを監視する
PA Server Monitor Pro
poweradmin.com/servermonitor
インフラストラクチャは、あらゆる部分を監視する必要があります。エンド ユーザーに影響が出る前に問題を特定することは、被害対策と通信において最重要事項です (それに、上司に厳しく監視されているのは気分が良いものではありません)。Power Admin LLC 社が提供している PA Server Monitor Professional Eition は、サーバー インフラストラクチャを監視するのに役立つツールの 1 つです。
PA Server Monitor は比較的簡単に使い始められるツールです。このツールの Smart Configuration Process という組み込みの機能を使用すると、LAN 上にあるコンピュータが検出され、各コンピュータの監視項目が自動的に構成されます。検出処理が必要ない場合は、監視項目を構成するコンピュータの一覧をインポートできます。コンピュータを構成したら、GUI を使用して構成内容をエクスポートし、他のコンピュータを構成する際のテンプレートとして使用したり、再インストール時にバックアップとして使用したりすることができます。
PA Server Monitor には、各サーバーに割り当てられる 18 件の監視項目があります。この監視項目には、ディスク領域、イベント ログのエラー、リモートでのスクリプトの実行、ファイルとディレクトリの変更、CPU とメモリの使用率、インターネット制御メッセージ プロトコル (ping) の応答、Windows® サービスの状態などを監視するなど一般的なチェック項目が用意されています。
これ以外にも、TCP ポートの監視など、非常に便利な監視項目があります。TCP ポートの監視では、基本的なポートの状態を確認するだけではなく、コマンド テキストを送信して、その応答をあらかじめ定義した値に対して確認します。ログ ファイルの監視では、正規表現を使用して定義したテキストや単純なテキストとして定義した特定のテキストがログ ファイルに記録されているかどうかを確認できます。ディレクトリ クォータの監視では、エンド ユーザーが、各自に割り当てられているクォータを超えるディスク容量を使用するとメールで通知されるので、各ユーザーが割当てられている制限を超えないようにするのに役立ちます。必要なカスタム タスクに使用するスクリプトの実行を監視できます。また、ファイルの経過期間の監視を使用すると、メールのキューを監視して、キューがパフォーマンス低下の原因にならないようにすることができます。
サーバーの監視項目を定義したら、次は、監視項目のしきい値に到達したときに実行する操作を定義する必要があります。PA Server Monitor には、電子メール、イベント ログ、メッセージ ボックス、ログ ファイル、サービスの再起動、Simple Network Paging Protocol (SNPP)、カスタム動作を実行するカスタム スクリプトなど、15 個の組み込みの操作が用意されています。操作を定義する際には、その操作のエスカレーション チェーンを定義できます。これにより、監視項目のエラー状態が一定の期間を超えた場合に追加の操作を行えます。たとえば、1 つ目の操作として、Web サイトの自動再起動を設定し、2 つ目の操作として、その 5 分後も監視項目のエラー状態が続く場合は、サイトの状況を知らせる電子メール メッセージをハンドヘルド デバイスに送信するように設定できます。
時間がたつと、構成した監視項目の統計を参照する必要が生じる場合もあるでしょう。PA Server Monitor には、必要なメンバに情報を送信するレポート機能が用意されています。組み込みのレポートには、サーバー概要 (特定のサーバーの統計データと情報)、全体の概要 (監視している各コンピュータの簡単な情報)、およびグラフィカルなステータス マップ (地理的に分散したサーバーの状況) があります。レポートは HTML 形式で生成され、Web ブラウザを使用して参照することができるので、管理センターで使いやすい形式になっています。また、簡単なグラフを使用したアドホックなレポートを生成したり、CSV ファイルにエクスポートして、後で参照したりすることもできます。また、レポートの作成はスケジュール設定できるので、定期的にサーバーの最新状態が電子メールで自動的に配信されるようにすることもできます。
PA Server Monitor にはエージェントがありません。このメリットは、Windows Management Instrumentation (WMI) やリモート プロシージャ コール (RPC) などのリモート管理サービスを経由してネットワーク上にあるコンピュータに接続できる権限があるサービスのコンテキストで実行できれば、このツールをすぐに使い始められるということです。ただし、リモート コンピュータに接続するのに管理者特権を持つアカウントが必要になるというデメリットもあります。もちろん、HTTP や SMTP など、管理者特権が必要ないサーバー プロトコルの監視もあります。
もう 1 つの潜在的なデメリットは、複雑で分散したインフラストラクチャとネットワーク トポロジを経由してコンピュータに接続することは、容易な作業ではなく、ドメインとネットワークの信頼関係に左右されるところがあることです。つまり、このエージェントを必要としないアプローチが、使用中の環境で機能するかどうかは、インフラストラクチャの設計とサーバー監視ソリューションで何を実現しようとしているかに大きく左右されます。
価格 : サーバー 1 台 99 ドル (直販)、サーバー 5 台 349 ドル (直販)
PA Server Monitor Professional Edition を使用してサーバーを監視する (画像をクリックすると拡大表示されます)

重複ファイルを削除する
dupeGuru
hardcoded.net/dupeguru
エンド ユーザーと作業をしたり、ユーザーが共有しているディスク領域を管理したりしている場合は、ユーザー ディスク領域が時間の経過と共に非常に雑然とした状態になることをご存じでしょう。このような状況は、1 人のユーザーが同じファイルを複数の場所に保存していたり、複数のユーザーが同じファイルを複数の場所に保存していたりすることが原因で発生します。このようなユーザー領域を整理統合して一掃するには、重複するものを検出するツールが必要不可欠です。それに適しているのが Hardcoded Software 社が提供している dupeGuru です。
このツールでは、指定のフォルダやドライブ上にあるファイルの名前と内容を調べて、重複するファイルがあるかどうかを検出します。dupeGuru では、基本的な文字列の比較だけではなく、あいまい一致のアルゴリズムを使用して重複ファイルを検出しているので、基本的な文字列の比較だけでは検出されないファイルも検出できます。また、重複ファイルが検出されたら、そのファイルをごみ箱に移動するのか、完全に削除するのか、別のフォルダに移動するのか、または既定のアプリケーションを使用してファイルを開いて最終確認をするのかを選択できます。結果は、XHTML 形式のファイルにエクスポートして後で確認できます。
ユーザー設定では、ファイルをスキャンするときに、ファイル名と内容のフィルタをどの程度厳密に適用するのかを指定できます。この設定により、検出される重複ファイルの数を増やすことができますが、不適切なファイルが重複ファイルとして検出される確率も高くなります。dupeGuru には、ファイル名に特定の単語が含まれている重複ファイルを検出する機能もあります。これは、ユーザーが誤って作成した "コピー ～" ファイルや、ディレクトリに散在している "新しいフォルダ" という名前の空のフォルダを検出する場合に役立ちます。
Windows 2000 以降に対応したバージョンと Mac OS X 用のバージョンがあります。音楽ファイルや写真の重複ファイルを削除する必要がある場合は、dupeGuru ME または dupeGuru PE という名前のカスタマイズされたバージョンの導入を検討することをお勧めします。
価格 : 19.95 ドル (直販)
dupeGuru を使用して重複ファイルを削除する (画像をクリックすると拡大表示されます)

環境を監視する
pt360 Tool Suite PRO
packettrap.com
さまざまなネットワーク監視ツールや管理ツールを 1 つのインターフェイスで表示したり、管理したりできると非常に便利です。統合ツールを使用すると、多くの時間 (とデスクトップの領域) を節約できるだけでなく、複数の監視ツール間でデータを簡単に共有することができます。また、さまざまな監視項目を一度に確認することが可能になり、インフラストラクチャについてより完全な状態を把握できるようになります。
これに魅力を感じる場合は、PacketTrap Networks 社が提供している pt360 Tool Suite PRO を試してみることをお勧めします。このツールには、PacketTrap Networks 社が提供しているツールを統合した UI が用意されています。また、このツールを使用すると一元管理を行ったり、統合レポートを作成したりすることもできます。よく使用するツールやよく確認するインフラストラクチャの状態にすぐアクセスできるように、ツール ビューをカスタマイズしたカスタム ダッシュボードを構成できます。pt360 ダッシュボードは、全画面モードで表示することができるので、管理センターで使用する場合に便利です。というのも、チーム メンバが、画面を一目見るだけで、さまざまなネットワークやサーバーのリソース状況を瞬時に確認できるからです。このツールでは、複数のダッシュボードがサポートされるので、ニーズに合わせてさまざまなビューを作成できます。
ダッシュボードを構成するのに必要な作業は、ドロップダウン リストからガジェットを選択し、各ガジェットをクリックして構成するだけです。ガジェットは、Application、Networking、Devices、Availability、および Other という 5 つのカテゴリに分類されており、サーバー、アプリケーション、およびネットワーク デバイスの監視では、簡易ネットワーク管理プロトコル (SNMP) と WMI に依存しています。Application ガジェットを使用すると、Active Directory®、Microsoft® Exchange Server、および SQL Server® の状況を確認することが可能になり、ブラウザ ツールが提供されます。Networking ガジェットを使用すると、デバイス インターフェイスの状況を確認することが可能になり、各クライアントの平均パケット損失数、最大待ち時間、インターフェイスの使用率の上位 10 項目が表示されます。Devices ガジェットを使用すると、CPU とメモリの使用率、ディスクの空き容量、ボリューム一覧、ネットワーク インターフェイスの使用率などの、パフォーマンス インジケータが表示されます。これらのガジェットは、構成可能な WMI クエリを使用して、リアルタイムでサーバーのパフォーマンスを監視できるので非常に便利です。Availability ガジェットでは、コンピュータの稼働時間がグラフ、ゲージ、テキスト、または一覧の形式で表示されます。Other ガジェットには、大きなデジタル時計が配置されています。
pt360 ツール群には、ダッシュボード以外にネットワーク ツールが用意されています。その一例が、Cisco Configurator です。このツールを使用すると、Cisco 機器の構成ファイルをアーカイブ、変更、アップロード、ダウンロード、および比較することができます。これ以外にも 3 つの ping ツールがあります。並べ替えが可能なテーブル ビューを提供するもの、グラフィカルなビューを提供するもの、および一連の IP アドレスに対して ping を実行できるものがあります。その他、自由に使用できるスキャン ツールには、MAC アドレス スキャン ツール、ポート スキャン ツール、SNMP スキャナ、WMI スキャン ツールなどがあります。
このツール群は、syslog サーバーとして使用することが可能で、syslog をサポートするネットワーク上の任意のデバイスに対して syslog メッセージの送受信、記録、および表示を行うことができます。表示ではフィルタ機能がサポートされているので、関心のあるメッセージを特定して、トラブルシューティングを迅速に行えます。
このツール群は、簡易ファイル転送プロトコル (TFTP) サーバーとして使用することが可能で、ネットワークでデバイス間で迅速にファイルを移動することができます。他には、トレースのルーティングや、Whois、Wake On LAN 機能などがあります。もちろん、このツール群は、WMI と SNMP 経由でホストに接続する一元管理ソリューションなので、接続の資格情報がどのように保存されるのかということは重要なポイントです。さいわい、このツール群では、256 ビットの高度暗号化標準 (AES) で暗号化された資格ストアを使用し、このストアで、インフラストラクチャの監視に必要な情報の追加、更新、および削除を行えます。
価格 : 999 ドル (直販、1 ライセンスごと)
pt360 Tool Suite PRO を使用してシステムを監視する (画像をクリックすると拡大表示されます)

ディスクの使用状況を管理する
TreeSize Professional
jam-software.com/treesize/index.shtml
「一体何がサーバーの容量を圧迫しているんだろうか」というセリフを頻繁に口にしていませんか。たとえば、たった今、監視アプリケーションから、ディスク領域不足のしきい値に到達したことを知らせる電子メール メッセージを受信したとしましょう。このサーバーの空き領域を増やすには一体どうしたら良いのだろう、と自問自答されるかもしれません。Shift キーと Del キーを押して完全に削除すべきものを迅速に判断するには、どうしたらよいのだろうかと (これは、ごみ箱に移動するという段階を踏まずにファイルやフォルダを完全に削除するショートカットです)。JAM Software 社が提供している TreeSize Professional は、ホスト モニタの正常な状態を特定するのに役立つツールです。
このツールは、Windows 2000 以降の 32 ビット版と 64 ビット版のどちらの Windows でも実行できます。また、ドライブで多くの領域を使用しているファイルに関する詳細なビューが提供されます。必要な作業は、調査するドライブを選択するだけです。ドライブを選択すると、フォルダ構造が自動的にスキャンされ、スキャンが完了すると、ドライブの状態を示す 7 種類の異なるビューにアクセスできます。1 つ目は Chart ビューです。このビューでは、円グラフ、棒グラフ、および積み上げ棒グラフという 3 つの異なる種類のグラフが表示されます。各グラフでは、さまざまなフォルダをドリルダウンして、ディスク領域を占領しているものを迅速に特定できます。また、グラフの色やスタイルをカスタマイズすることができます。
2 つ目は、Details ビューです。このビューでは、ファイルが並べ替え可能な表形式で表示され、この表に表示する列を指定することができます。ユーザーが頻繁に使用する列は、Microsoft Office ファイルの作成者、フォルダ内にあるファイルの平均サイズ、そのファイルまたはフォルダが親ディレクトリに対して占める割合、ハード リンクなどです。
Extensions ビューには、フォルダをドリルダウンする際に、各ディレクトリで最も多くの領域を占有しているファイルの種類が表示されます。Users ビューでは、特定のユーザー アカウントまたはシステム アカウントのファイルが占有している領域を示す複合ビューが表示されます。このビューは、ディスク領域が不足する原因となっているユーザーを特定するのに役立ちます。File Ages ビューでは、ここ 1 日、1 か月、または 1 年 (この期間はお好みの期間を指定できます) の間に変更、作成、またはアクセスされたファイルの割合を示すグラフィカルなビューが表示されるので、アーカイブまたは削除しても問題ない古いファイルを特定できます。Top 100 ビューには、ドライブ上にあるサイズの大きな上位 100 ファイルが表示されます。7 つ目のビューである History ビューでは、ドライブの使用傾向が時系列で表示されます。
これらの 7 つの各ビューでは、印刷、保存、クリップボードへのコピーなどを行って、後でデータを参照することができます。また、TreeSize では、File Search 機能を使用して、最も大きなファイル、最も古いファイル、一時ファイル、インターネット キャッシュ ファイル、および重複ファイルを簡単に特定できるので、一般的なクリーンアップ メンテナンス タスクをツール バーから迅速に行えます。さらに、TreeSize Professional を使用すると、UNC 共有を経由してネットワーク ドライブをスキャンできます。ただし、ネットワークのオーバーヘッドが伴うため、大幅なパフォーマンスの低下が生じます。
このツールでは、コマンド ライン モードもサポートされています。このモードは、スケジュールを設定したり、夜間に処理を実行したりするのに適しています。Scheduled Task スキャンを作成し、指定のパスをスキャンするように構成して、定期的にレポートを作成するようにすることができます。これは、ユーザー ディスク領域の状態を毎晩監視して、ディスク領域がどのように使用されているのかを注目するのに便利な機能です。
1 テラバイトものユーザー ディスク領域で既に空き領域が不足している場合でも、TreeSize は、ディスク領域の使用傾向を特定して、ディスク領域をより効率的に管理できるようにするのに役立ちます。
価格 : 49.95 ドル (直販、1 ライセンスごと)
TreeSize Professional を使用してディスクの使用状況を管理する (画像をクリックすると拡大表示されます)

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


SQL に関する Q&A パーティション分割、整合性チェックなど
Paul S. Randal

質問 - 運用データベースを SQL Server® 2005 サーバーに誤ってアタッチしてしまったので、現在、SQL Server 2000 を実行している正しいサーバーに運用データベースをアタッチし直そうとしています。データベースを単純に SQL Server 2005 からデタッチして SQL Server 2000 サーバーにアタッチしたり、バックアップと復元によりアタッチし直そうとしたりしましたが、どちらの方法もうまくいきません。どうして SQL Server 2000 サーバーにアタッチできないのでしょうか。このデータベースは、手元にある唯一のデータベースです。
回答 - まずここで注意すべきことは、バックアップを作成することの重要性です。通常、バックアップが必要になるのは、破損などデータ喪失を伴う障害から回復するためであると考えられています。しかし、今回の場合は不慮のアップグレードですが、アップグレード中の問題という、あまり明確ではない障害が発生しています。ただし、この場合も、データベースに何か起きた場合に備えて、常に最新のデータベースの完全バックアップを保持しておく必要があるということが当てはまります。
意図的であるかどうかにかかわらず、アップグレードはやり直しができない操作で、アップグレードによる影響を元に戻すことは非常に困難です。SQL Server を別のバージョンにアップグレードすると、データベースに対して一連のアップグレード処理が実行されます。通常、各処理では、データベースの物理的な変更が行われ、処理ごとにデータベースのバージョン番号が大きくなります。
たとえば、SQL Server 2000 から SQL Server 2005 へデータベースをアップグレードする場合に実行される主な変更の 1 つには、テーブル、インデックス、列、アロケーションなど、データベースのリレーショナル構造と物理構造についての詳細情報を保持しているデータベースのシステム カタログ (多くの場合、システム テーブルやデータベース メタデータと呼ばれます) の構造の変更があります。
このようなアップグレード処理が実行されるごとに、データベースのバージョン番号が大きくなります。たとえば、SQL Server 7.0 データベースのバージョン番号は 515、SQL Server 2000 データベースのバージョン番号は 539、SQL Server 2005 データベースのバージョン番号は 611 (VarDecimal 機能が有効な場合は 612) です。この番号により、データベースに対して最後に実行されたアップグレード処理がどれかを SQL Server が認識できるようにしています。
SQL Server の各リリースでは、新しい SQL Server リリースにアップグレードされたデータベースを読み取ることはできません (たとえば、SQL Server 2000 では SQL Server 2005 にアップグレードされたデータベースを読み取ることはできません)。これは、古いリリースに、アップグレード後の構造とデータベース レイアウトの解釈に必要なコードが含まれていないためです。このことが原因で、SQL Server 2005 にアップグレードされたデータベースを SQL Server 2000 にアタッチし直すことができないという問題が発生しています。
データベースの完全バックアップがない場合、唯一の対処方法は、アップグレードされたデータベースから全データをエクスポートし、このデータを手動で新しい SQL Server 2000 データベースに戻すことです。SQL Server 2005 の新機能を使用していなければ、スクリプトを使用してデータベース構造を書き出して、SQL Server 2000 でデータベースを作成して、データをエクスポートおよびインポートできます。
スクリプトを使用して SQL Server 2005 のデータベースを書き出すには、SQL Server Management Studio のオブジェクト エクスプローラを使用します (データベースを右クリックし、[タスク] をクリックし、[スクリプトの生成] をクリックします)。ウィザードは名前のとおりスクリプトを生成するためのもので、すべてのオブジェクト、インデックス、制約、トリガなどを作成するスクリプトを生成します。
質問 - 最近スキーマを再設計して、メイン テーブルでテーブル分割を使用するとパフォーマンスが向上するという話を聞いたので、そうしました。データベースは、120 GB の単一ドライブ上に保存してあり、テーブルは、単一のファイル グループに含まれてます。スライディング ウィンドウ処理は実施せず、新しいパーティションが毎週追加されるだけです。また、すべてのデータはオンラインで利用できる必要があります。クエリの大半は、1 週間以内のデータを処理するものですが、過去 1 年にわたるデータを処理するクエリが多少あります。これは、単一のファイル グループ内で行う方が簡単に処理できるように思えます。このような理解で正しいですか。または他に理解する必要のあることはありますか。
回答 - 単一のファイル グループは使いやすいように思えるかもしれませんが、そのような方法ではパーティション分割を使用するメリットは実感できないでしょう。パーティション分割を使用する主な目的は、データベース メンテナンスの効率と障害発生時のデータの可用性を向上することです。また、パーティション分割を使用すると、パフォーマンスを向上するスキーマを作成できるというメリットがあります。
パーティション分割の典型的な使用例は、12 個のパーティションがあり、各パーティションが過去 1 年の毎月の売り上げデータを表す売り上げテーブルです。月末に、最も古いパーティションが (アーカイブされるか削除されて) 新しいパーティションに置き換えられます。これが、ご質問にあるスライディング ウィンドウ方式のシナリオです。当月のパーティションは、読み取り/書き込み可能に設定され、それ以前のパーティションは読み取り専用になり、各パーティションは個別のファイル グループに格納されます。このスキーマであれば、パーティション分割による全メリットが得られますが、すべての状況で最適なわけではありません。
私の妻の Kimberly が、上記のスキーマに手を加えて、より効率的なインデックス作成を可能にする方法を思い付きました。売り上げテーブルを 2 つのテーブルに分割してみてください。1 つは読み取り/書き込み可能な 1 個のパーティションを保持し、もう 1 つは読み取り専用の 11 個のパーティションを保持するテーブルとし、両方のテーブルを対象にするパーティション ビューを使用します。
これにより、読み取り/書き込み可能テーブルに含まれるインデックスの数を抑え、読み取り専用テーブルには、レポート クエリをサポートできるように、より多くのインデックスを含められます。その結果、読み取り/書き込み可能なデータでは大量の非クラスタ化インデックスをメンテナンスする必要がないため、読み取り/書き込み可能データに対するデータ操作言語 (DML) 操作の効率が大幅に向上します。
また、読み取り/書き込みデータに対するクエリで、読み取り専用データを処理する必要がなくなるというメリットもあります。SQL Server 2005 では、特に複雑な述語を使用する場合は、クエリ プランでのパーティションの解消は完全であるとは言えませんが、SQL Server 2008 ではこの機能が大幅に強化されています。この詳細については、Kimberly のブログ記事 (sqlskills.com/blogs/kimberly/default,month,2007-10.aspx#a71c70243-3d57-4940-9af7-a802b73f2f93) を参照してください。
どういうことかをご説明するために、複数のファイル グループにまたがるパーティション分割によって実現される機能のいくつかについて説明しましょう。
部分的なデータベースの可用性 これは、プライマリ ファイル グループがオンラインである限り、障害回復中でもデータベースにオンラインでアクセスできるようにする機能です。1 つのファイル グループしかない場合、データベースの復元中はデータベース全体の可用性が失われます。しかし、複数のファイル グループにデータを分散すると、復元中にオフラインになるのは障害のあるファイル グループだけなので、アプリケーションでは処理を続行できる可能性があります。
段階的な部分復元 この手法は、部分的なデータベースの可用性と似ています。ファイル グループが 1 つしかない場合、復元の単位は 1 ページかデータベース全体のどちらかになりますが、ファイル グループが複数あれば、1 ファイル グループのみを復元することができるので、部分的なデータベースの可用性を実現できます。
パーティション分割されたデータベースのメンテナンス 前述のパーティション構成のどちらかを使用することで、すべてのパーティションが単一のファイル グループに保持されている場合でも、パーティションごとにインデックスの断片化を解消できます。しかし、ファイル グループが 1 つしかない場合、ファイル グループ単位での整合性チェックを実行できなくなります。ファイル グループ単位での整合性チェックを実行すると、データベースの整合性チェック (DBCC) での処理に必要なデータ量 (と使用される CPU と I/O リソースの量) が大幅に減少する可能性があります。
簡単に言うと、同じファイル グループ内に複数のパーティションを保持できますが、パーティションとファイル グループを 1 対 1 で対応付けることで、さまざまなメリットが得られます。
質問 - 最近、ハイエンドのデータベース サーバーの 1 つで、恐ろしいことが発生しました。不良メモリ ボードによって、破損が起きていたのです。アプリケーションにでたらめなデータが表示されるようになって、この問題に気が付きました。DBCC CHECKDB を実行したところ、あらゆる種類の破損を検出しました。残念ながら、バックアップにも破損が含まれていたため、手動で不良データを取り除かなければなりませんでした。
手短に説明すると、不良ハードウェアを交換し、ページ チェックサムを有効にしました。定期的に整合性チェックを実行したいのですが、長時間のメンテナンス枠を設けておらず、2.4 TB のデータベースのチェックには時間がかかります。どのような対処が可能でしょうか。
回答 - VLDB (非常にサイズの大きなデータベース) に対して整合性チェックなどのメンテナンスを行う方法についての質問はよく寄せられるようになってきています。多くの DBA は、メンテナンスの時間枠内に DBCC CHECKDB の実行を完了できないことがわかると、その実行を諦めてしまいます (また、データベースが常時稼動されていて、長時間にわたり DBCC CHECKDB に必要な CPU と I/O オーバーヘッドを許容できる時間がない場合もあります)。
整合性チェックを諦めて実行しないのは、絶対にお勧めできませんが、代わりに使用できる方法が 4 種類あります。私は、お客様がこの 4 種類の方法を使用できるようにサポートした経験があるので、それをご紹介しましょう。
DBCC CHECKDB の WITH PHYSICAL_ONLY オプションの使用 通常の DBCC CHECKDB では、大量の論理整合性チェックが実行され、CPU を多く使用します (基本的に、CPU を集中的に使用する操作になります)。WITH PHYSICAL_ONLY オプションを使用すると、非常に高速な DBCC CHECKALLOC アロケーション ビットマップの整合性チェックを実行し、データベース内のすべての割り当て済みページを読み取って監査し、そのページ上のページ チェックサムを強制的にテストするように、整合性チェックが制限されます。これにより、DBCC CHECKDB が I/O を集中的に使用する操作となり、実行時間が大幅に短縮されます (実際、完全な DBCC CHECKDB よりも桁違いに処理時間が短くなる場合があり、大幅に時間を節約できます)。
整合性チェック ワークロードの分割 この場合は、同じサイズの複数のグループにデータベースのテーブルを分割して (最も簡単な方法は、ページ数でテーブルを分割することです)、毎晩、特定の 1 つのグループ内の全テーブルに対して DBCC CHECKTABLE コマンドを使用して整合性チェックを実行します。たとえば、7 つのグループあり、これらのグループを毎日 1 つずつチェックして、DBCC CHECKALLOC と DBCC CHECKCATALOG を週に 1 度実行した場合、全体の処理には 1 週間かかりますが、DBCC CHECKDB を実行した場合と同じ結果が得られます。
複数のファイル グループによるテーブル分割の使用 VLDB の最もサイズの大きいテーブルを、複数のファイル グループに分割できます。整合性チェック方法の一例としては、読み取り/書き込み可能なパーティションを保持しているファイル グループには毎日 DBCC CHECKFILEGROUP を実行し、読み取り専用パーティションを保持しているファイル グループには週に 1 度 DBCC CHECKFILEGROUP を実行することが考えられます。その根拠は、読み取り専用データは、包括的にバックアップされていて、日常的な処理で使用されないためです。したがって、読み取り専用データの場合は破損がそれほど重大な問題にはならないため、整合性チェックを頻繁に実行する必要がありません。
別のサーバーへの整合性チェックのオフロード この場合は、別のサーバーに正規のデータベースの完全バックアップを復元し、そのサーバー上で DBCC CHECKDB を実行します。このようにすると整合性チェックのワークロードが運用サーバーから完全にオフロードされるのは明らかですが、欠点は、破損が見つかった場合、運用サーバー上で整合性チェックを実行する必要があることです。しかし、このような状況が発生するのはごくまれなので、整合性チェックを実行する方法としては問題ないでしょう。
ご覧のとおりに、完全な DBCC CHECKDB の実行時に必要な余分なリソース負荷を削減できる、VLDB の整合性チェックを実行する方法は多数あります。前述のとおり、私は、お客様がこの 4 種類の方法を使用できるようにサポートした経験があるので、この質問をお送りいただいた方の環境でも、この方法が役立つと思います。
ヒント : トリガを使用してサーバー側のロジックを実装する
トリガを使用してサーバー側のロジックを実装しなければならない場合がありますが、これには注意すべき落とし穴があります。ここでは、留意すべき重要な事項をいくつか紹介します。
  • トリガは、行単位でなく、ステートメント単位で実行されます。ですから、トリガ ロジック内にロジックを追加して、ステートメントが影響する行が複数またはゼロであるシナリオを処理できるようにします (影響を受ける行がない場合でも、トリガはステートメント単位で実行されます)。影響を受けるデータは、データ操作言語 (DML) ステートメント用の仮想テーブル内に保持されます。このテーブルは結合が可能なため、ユーザーはテーブル内のデータを操作できます。
  • トリガは、トランザクション内で同期的に実行されます。すぐまたは適当な時間内に応答が返されるかどうか確証を持てない、外部アプリケーションを呼び出す場合や外部リソースにアクセスする場合は、このことを考慮する必要があります。たとえば、あるテーブルに対して Update ステートメントを実行し、この操作内でトリガが実行される場合、(Update ステートメントでは必ず実行される) トランザクションは、トリガの全ロジックの処理が完了しないと、完了できません。外部のアプリケーションまたはプロセスからエラー コードが返された場合、(実装されているエラー処理とエラー コードによりますが) SQL Server ではトランザクションを中止し、トランザクションをロールバックする可能性があります。ですから、トリガ内で外部処理を必要とし、それがトランザクションにおいて重要なものでない (または同じ操作単位内で実行する必要がない) 場合は、その外部処理を別プロセスに切り離して、非同期的にデータを取得するようにすることをお勧めします。SQL Server 2005 では、このような処理を非同期に実行できる SQL Server Service Broker が導入されています。
  • トリガ内のステートメントに起因するエラーは、検出することが非常に困難です。1 つのトランザクション内で複数のテーブルが処理される場合は、エラーが発生した場合にトリガを調べることと、適切なエラー処理を実装することが必要です。データベース内のスキーマを変更した場合は、必ずトリガ ロジックの追跡も行ってください。追跡しないと、小さなトリガが、全体的なパフォーマンスや安定性に大きな影響を及ぼす可能性があります。スキーマの変更に伴う大半の影響は、Visual Studio® for Database Professionals を使用して確認できます。この製品では、プロジェクトの編集中に自動的にスキーマ チェックが実行されるほか、データ型の不整合を確認するスタティック コード分析も実行されます。
—Jens K. Suessmeyer、データベース コンサルタント (マイクロソフト)

Paul S. Randal は SQLskills.com の代表取締役であり、SQL Server MVP でもあります。1999 年から 2007 年までは、マイクロソフトの SQL Server ストレージ エンジン チームに所属していました。また、『DBCC CHECKDB/repair for SQL Server 2005』を執筆し、SQL Server 2008 の開発時にはコア ストレージ エンジンを担当していました。Paul は障害回復、高可用性、およびデータベース メンテナンスの専門家であり、カンファレンスで定期的に発表を行っています。彼のブログは SQLskills.com/blogs/paul で公開されています。


ユーティリティ スポットライト Windows Installer CleanUp ユーティリティ
Lance Whitney

使用中の環境にある PC の 1 つでアプリケーションのアンインストールまたは更新を試みても、コマンドが実行されず、アプリケーションをアンインストールまたは更新できないことを示すエラーが表示されたという経験はありませんか。このような経験がある場合は、この問題の原因が何なのか疑問に思われたことでしょう。
Microsoft® Windows® インストーラ (MSI) テクノロジを使用してインストールされたアプリケーションでは、特定のファイルやレジストリ設定に書き込みを行います。このようなファイルや設定のいずれかが存在しなかったり破損していたりすると、プログラムの削除、更新、または再インストールができないことがあります。このような場合の解決策は、プログラムを新規に再インストールできるようにすべての Windows インストーラ情報を削除することです。マイクロソフトでは、これを行う Windows Installer CleanUp ユーティリティを無償で提供しています。
Windows Installer CleanUp ユーティリティを使用すると、ある特定のプログラムの Windows インストーラ構成に関連付けられているファイルとレジストリ設定がすべて削除されます。このユーティリティを使用しても、そのプログラムの実際のインストール ファイルやレジストリ設定は削除されないこと、このユーティリティが "プログラムの追加と削除" コマンドに取って代わるものではないことに注意してください。
むしろ、このユーティリティは、プログラムの追加と削除ユーティリティなどを使用してアプリケーションをアンインストールまたは更新できない場合に使用します。Windows インストーラ情報を削除すると、アプリケーションを再インストールできるようになります。その後、プログラムはインストールされたままにしておくことも、更新または削除することもできます。
Windows Installer CleanUp ユーティリティで PC 上にある Windows インストーラ ベースのアプリケーションすべてが一覧表示されているようす (画像をクリックすると拡大表示されます)
皆さんの中には、マイクロソフトが提供しているコマンド ライン プログラムである msizap についてよくご存じの方がいらっしゃるかもしれませんが、これは、ある特定のプログラムに関連付けられている Windows インストーラ情報を削除するプログラムです。このコマンドは、Windows Installer CleanUp ユーティリティでも使用されています。このユーティリティは、厄介なコマンド ライン オプションを扱わなくて済むように用意された msizap の操作しやすいフロント エンドです。
このユーティリティをインストールすると、Program Files フォルダの下に Windows Installer Clean Up という名前のサブディレクトリが作成されます。このサブディレクトリには、msicuu.exe、msizap.exe、および readme.txt という 3 つのファイルがあります。msicuu.exe ファイルを使用すると、PC 上にある Windows インストーラ ベースの全アプリケーションが一覧表示され、このようなアプリケーションのうちの任意のものを選択、選択解除、および削除することができます。続いて、選択されたアプリケーションの情報が msicuu.exe プログラムから msizap.exe コマンドに通知され、選択されたアプリケーションに関連付けられている Windows インストーラ情報が msizap.exe コマンドによって削除されます。
Windows Installer CleanUp を実行するには、[スタート] ボタンをクリックし、[すべてのプログラム] をポイントし、[Windows Installer Clean Up] をクリックします。PC 上にある Windows インストーラ ベースの全アプリケーションが一覧表示されます (上記スクリーンショット参照)。問題が発生しているアプリケーションを選択して、[Remove] をクリックします。これにより、そのアプリケーションは Windows インストーラ データベースから削除されるので、そのアプリケーションを新規に再インストールできるようになります。
CleanUp ユーティリティの実行後には、プログラムの追加と削除の一覧にそのアプリケーションが表示されなくなります。そのため、最終的にアプリケーションを削除する必要がある場合は、まずそのアプリケーションを再インストールする必要があります。Windows Installer CleanUp ユーティリティは、Windows インストーラ テクノロジを使用しているアプリケーション (通常、MSI ファイルとしてパッケージ化されたインストール) に対してのみ機能します。
最後に、Windows Installer CleanUp ユーティリティを実行するには管理者としてログインする必要があることをお伝えしておきます。このユーティリティは、すべての 32 ビット版と 64 ビット版の Windows と互換性があります。このユーティリティの詳細とダウンロードについては、support.microsoft.com/kb/290301 を参照してください。

Lance Whitney は、IT コンサルタントであり、トレーナーであり、テクニカル ライターでもあります。Windows のワークステーションおよびサーバーをカスタマイズすることに数えきれないほどの時間を費やしてきました。元々はジャーナリストでしたが、15 年前、IT 業界への転向を実現しました。


SharePoint の内部 メッセージング統合のトラブルシューティング
Pav Cherny

コードのダウンロード : SharePoint2008_08.exe (416 KB)
目次
一般的なトラブルシューティングのアプローチ
SharePoint のメッセージング アーキテクチャ
診断情報の取得
送信メッセージの転送
受信メッセージの転送
ディレクトリの管理
まとめ
適切に設計された SharePoint 環境では、インフォメーション ワーカーが共同作業を行うためにコミュニケーションの習慣や仕事のやり方を変える必要はありません。SharePoint を使用すると、定期的にグループ作業サイトを手動で確認することなく、(通知やアラームなどを使用して) ドキュメントやその他の情報をメールボックスに直接配信できます。
ユーザーは配信されたメッセージに返信したり、新しいアイテムを電子メール メッセージとしてドキュメント ライブラリやリストに送信することによって、ワークフローに参加することもできます。
ただし、SharePoint® と安全性の高いメッセージング環境を統合することは難しい課題です。この統合により、SharePoint 以外のコンポーネントが SharePoint ベースのコラボレーションに影響を及ぼす可能性が生じます。このような統合環境では、問題が発生する場所にかかわらず、問題の根本原因を効率的に特定して取り除くことが課題となります。
今回のコラムでは、すぐに効果が現れる、実績のあるトラブルシューティング戦略に基づいた SharePoint メッセージングの統合について説明します。問題の発生場所を効率的に特定してから、対象を限定した詳細なトラブルシューティング手順を使用して問題を確認します。
大きな組織では、問題の初期解析を行った後、問題を別の専門家に引き渡すことが、この段階的な調査の定義であるかもしれません。問題が SharePoint 以外のコンポーネントと関係している場合は特にその傾向が強くなるでしょう。一方、中小規模の組織では、1 人の IT 管理者が関連するすべてのシステムのトラブルシューティングを直接行う必要があるのは珍しいことではありません。つまり、中小規模の組織では、構造化されたアプローチを使用する必要性がさらに高いということになります。
実用性を重視したコラムにするために、ここでは Active Directory®、Exchange Server 2007、および WSS 3.0 を使用したテスト環境を使用します。このテスト環境を構築する一連の手順、およびこのコラムと付属リソースで説明しているトラブルシューティング ツールは、TechNet Magazine Web サイトのコード ダウンロード セクションで入手できます。

一般的なトラブルシューティングのアプローチ
おそらく他の相互運用シナリオよりも、SharePoint のメッセージング統合のトラブルシューティングを行う際には十分に構造化されたアプローチが必要になります。このようなアプローチを実現するのが困難である要因は、いくつかあります。
複雑なテクノロジを扱う必要があることは言うまでもありませんが、メッセージ転送の問題、メッセージ形式の変換、セキュリティの状態、およびディレクトリ管理の問題に取り組んでいると、わかりづらい SharePoint のエラー メッセージに遭遇することがあるでしょう。また、インターネットのニュースグループは、未解決のディスカッション スレッドや間違った方向に物事を進めるように誘導する解決策 (たとえば、メッセージング統合を行うために、SharePoint サーバーの全体管理のアプリケーション プール ID を使用して、すべての Web アプリケーションを実行するなど) であふれています。
しかし、プラスの面もあります。SharePoint は、非常に柔軟性が高い製品です。たとえば、適切な場所を参照すれば、詳細なトラブルシューティング情報を得ることができます。また、少量の基本的なスクリプトを使用して、トラブルシューティングの効率を大幅に向上させることもできます。
トラブルシューティングを行う際の 1 つ目の目標は、対応している問題を理解することです。問題が発生している場所と、その問題に関連しているコンポーネントを特定する必要があります。また、さまざまなシステム構成で問題を再現し、Windows® イベント ログとテキスト ベースのログ ファイルを詳しく調べてみることもできます。しかし、一部の問題はたまにしか発生しないので、これは厄介な作業になる可能性があります。それでも、問題を再現できれば、その根本原因をさらに早く特定して取り除くことができます。見過ごされることが多いですが、もう 1 つの重要な目標は、構成の変更と修正をすべて記録して、その変更と修正が環境内にある関連しているすべてのシステムに適用されるようにすることです。

SharePoint のメッセージング アーキテクチャ
メッセージングの統合に関する問題に直面したときは、トラブルシューティングを行う前に、まずコーヒーかお茶を飲み、それから SharePoint のメッセージング統合アーキテクチャを確認することをお勧めします。このような手順を踏まないと、違う問題やコンポーネントを修正することになってしまう可能性があります。たとえば、"アクセスが拒否されました" というエラーが表示され、Active Directory で連絡先オブジェクトを作成できない場合、そのエラーは必ずしも Active Directory のアクセス許可を修正する必要があるということを表しているわけではありません (これについては、後で説明します)。
どのような場合も、メッセージングの統合にかかわる各コンポーネントの役割と、個々のコンポーネントの相互作用について理解することは非常に重要です。図 1 は、SharePoint と Exchange Server の接続シナリオにおける重要なコンポーネントを示しています。この詳細については、後続のセクションで説明します。
図 1 SharePoint のメッセージング統合アーキテクチャ (画像をクリックすると拡大表示されます)

診断情報の取得
信頼性の高い診断情報は、最も重要なトラブルシューティング ツールの 1 つです。以前から変わらずにあるのは、Windows イベント ログです。特に、SharePoint サーバーの全体管理を使用して、SharePoint による Web サーバー上の Windows イベント ログへの書き込みのレベルを細かく制御することができるのは有益です (この設定には、[サーバー構成の管理] ページの [ログおよびレポートの作成] で、[診断ログ] をクリックしてアクセスできます)。イベント ログとトレース ログに記録する、最も重要度が低いイベントを指定できます。詳細な情報を検索する場合は、トレース ログ (既定では、%CommonProgramFiles%\Microsoft Shared\Web Server Extensions\12\Logs にあります) が非常に便利ですが、すぐにいっぱいになるため、この機能は慎重に使用してください。
診断情報を取得するもう 1 つの方法は、付属リソースの Web Application Config.pdf で説明しているように、影響を受けた Web アプリケーションに対応する web.config ファイルを構成して、その Web アプリケーションのデバッグを有効にすることです。SharePoint では、詳細なトレース情報がユーザー インターフェイスに直接表示されます。このアプローチのメリットは、何 MB ものトレース データを解析しなくても、関連するエラー情報を確認できることです。ただし、Web アプリケーションのシステム構成を変更する必要があるというデメリットがあります。システム構成を変更する際には、元の web.config ファイルをバックアップし、トラブルシューティングが完了したら元の構成に戻すことを忘れないでください。
また、SMTP サービスを構成して、詳細な処理情報を SMTP プロトコル ログに書き込むこともできます (これには、IIS マネージャで、[全般] タブの [ログの記録を有効にする] チェック ボックスをオンにします)。ODBC ログを使用する予定がない場合でも、付属リソースの SharePoint Messaging Integration.pdf で説明しているように、SMTP サービスの機能を使用する場合は、ODBC のログ モジュールも一緒にインストールするようにしてください。このモジュールをインストールしないと、SMTP サービスではプロトコル ログの書き込みが行われません。既定では、SMTP プロトコル ログは %SystemRoot%\System32\LogFiles\SmtpSvc1 にあります。このログは、SMTP 通信を詳しく分析し、メッセージが SharePoint サーバーから配信されたかどうかを判断するのに使用できるテキスト ファイルです。
SMTP サービスと通信しているハブ トランスポート サーバーでは、送信コネクタと受信コネクタの構成でプロトコル ログを有効にすることもできます (詳細については、SharePoint Messaging Integration.pdf を参照してください)。また、メッセージ追跡、キュー ビューア、パイプライン トレースなど他のさまざまなツールを使用して、Exchange Server 2007 環境内のハブ トランスポート サーバーやメールボックス サーバー間でメッセージが通過する経路を追跡できます。Exchange Server 2007 のメール フローの問題に関するトラブルシューティングの詳細については、「トランスポートおよびメール フローに関する問題」(go.microsoft.com/fwlink/?LinkID=120145) を参照してください。
Active Directory のドメイン コントローラでは、HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics にある対応するレジストリ エントリを設定し、カテゴリの値を 0x0 にすると、重要なイベントだけがログに記録され、0x5 にするとデバッグ情報を含むすべてのイベントが記録されます。0x3 より大きいログ レベルを使用すると、サーバーのパフォーマンスが低下し、Windows イベント ログがすぐにいっぱいになります。通常運用時は、すべての値を 0x0 に設定することをお勧めします。
トラブルシューティングを行う際には、SharePoint、Exchange Server、および Active Directory の各サーバーの詳細な診断情報を収集すると、問題が発生している場所をすばやく簡単に特定するのに役立ちます。システム間の通信のほとんどがコンピュータ ネットワーク経由で実行されるため、TCP/IP ツール (ping、tracert、telnet など) やネットワーク モニタなどの、その他のトラブルシューティング ツールが役に立つ場合もあります。Microsoft® Network Monitor 3.1 は go.microsoft.com/fwlink/?LinkId=120143 で入手できます。

送信メッセージの転送
関連リソース
  • SharePoint 製品およびテクノロジ Web サイト
  • Windows SharePoint Services TechCenter
  • Windows SharePoint Services デベロッパー センター
  • Microsoft SharePoint 製品およびテクノロジ チームのブログ
イベント ログ、トレース ログ、プロトコル ログ、メッセージ追跡ログ、およびネットワーク トレースが準備できたら、SharePoint のメッセージング統合のトラブルシューティングに着手できます。では、まず簡単な部分から始めたいので、送信メッセージの転送について説明しましょう。SharePoint ではさまざまな構成での送信メッセージの転送がサポートされており、Web サーバーのローカル SMTP サービスは必要ありません。ただし、完全なメッセージングの統合シナリオでは、ローカル SMTP サービスを使用するよう構成することをお勧めします。図 2 に、このシナリオの主要なコンポーネントを示します。
図 2 送信メッセージの転送 (画像をクリックすると拡大表示されます)
このメッセージング シナリオは 4 つの段階で構成されています。まず、SharePoint がメッセージを SMTP サービスに転送し、次に SMTP サービスがメッセージを処理して、ハブ トランスポート サーバーがメッセージを受信し、最後に Exchange Server 2007 がメッセージを最終的な送信先に転送する必要があります。
SharePoint がメッセージを SMTP サービスに転送できない場合は、通常、電子メールの通知を送信できないことを示すエラー メッセージがユーザー インターフェイスに表示されます。このエラーの原因は SMTP サービスが実行されていないことである可能性があります。また、SMTP プロトコル ログには、SMTP サービスがエラー コード 550 (Requested action not taken: mailbox unavailable (要求された操作を実行できません : メールボックスが使用できません)) で送信を拒否したということが記録されている場合もあり、これは SMTP サービスに問題があるということを示しています。
これが SharePoint の問題ではないことを確認するためには、基本的なスクリプトを使用し、同じ送信者と受信者の情報を使用して SMTP サービス経由でテスト メッセージを送信します (スクリプトの詳細については、付属リソースの SMTP.vbs を参照してください)。問題の原因が SMTP サービスにある場合は、スクリプトがエラーになります。実際に、図 3 に示しているように、このスクリプトを使用すると問題の根本原因についての重要な手がかりを得ることができますが、残念なことに、デバッグを有効にしいても SharePoint では問題の根本原因が明らかにされません。
図 3 メッセージを中継できないことを示すエラー メッセージ (画像をクリックすると拡大表示されます)
SMTP サービスの構成で Web サーバーの中継許可を与えて、SMTP サービスを再起動すると、SharePoint のメッセージの送信に関する問題を解決することができます。メッセージが SMTP サービスに届くようになったら、SMTP サービスがメッセージをハブ トランスポート サーバーに転送できるかどうかが次の重要な問題になります。
メッセージがキュー フォルダ内に残っている場合は、SMTP サービスがハブ トランスポート サーバーに接続できないことを意味します。これは、Microsoft Exchange Transport サービスが実行されていないこと、またはネットワーク通信や構成に問題があることのどちらかが原因であると考えられます。Telnet クライアントを使用することによって、内部通信用に構成された受信コネクタの宛先ポートに接続できるかどうかをすばやく簡単に確認できます。
宛先ポートは必ずしも TCP ポート 25 というわけではありません。実際、SMTP サービスでこのポートが使用されている場合は、ハブ トランスポート サーバーの既定の受信コネクタにメッセージを転送することがありますが、この受信コネクタは匿名で送信されたメッセージをブロックするように構成されています。この場合は、ドロップ フォルダにメッセージ ファイルがあることが確認できます (ただし、Windows SharePoint Services タイマ サービスを停止しないと、メッセージが数秒後に消えてなくなるので、このサービスを停止する必要があります)。このメッセージ ファイルは、"Diagnostic-Code: smtp;550 5.7.1 Client was not authenticated" というエラーで、メッセージが拒否されたことを示す配信状態通知です。
この問題を解決するには、SharePoint サーバー専用の受信コネクタを作成する必要があります。SharePoint サーバーは内部システムであるため、[外部的にセキュリティで保護 (たとえば、IPsec を使用)] 認証オプションを選択します。このようにすると、拡張された権利を匿名ログオン アカウントに与える必要はありません。また、IPsec を使用して、SharePoint サーバーとハブ トランスポート サーバー間の通信を保護することも検討してください。
メッセージが SMTP のキュー フォルダから配信され、メッセージが正常に転送されたことが SharePoint サーバーとハブ トランスポート サーバーの SMTP プロトコル ログ (%ProgramFiles%\Microsoft\Exchange Server\TransportRoles\Logs\ProtocolLog\SmtpReceive フォルダを確認します) に記録されている場合は、作業が完了したと考えてかまいません。ただし、Exchange Server 2007 がメッセージを宛先に転送できることが前提となります。既に述べたように、メッセージが Exchange 受信者に届かない場合は、Exchange Server 2007 に用意されているメール フローのトラブルシューティング ツールを使用して、問題を調査できます。不適切な受信者情報、スパム フィルタ、およびメッセージのサイズ制限が原因で、この段階で最終的なメッセージの送信ができなくなる可能性があります。

受信メッセージの転送
メッセージを逆の方向に転送する場合は、発生する可能性がある問題がさらにわかりにくくなるため、少し複雑になります。たとえば、SharePoint 製品のドキュメントでは、SharePoint の電子メール ドメイン用に DNS の MX レコードを構成することが推奨されていますが、この構成を使用すると Exchange Server を使用している組織ではメッセージが適切に転送されなくなる可能性が生じます。
Exchange Server 2007 では、関連付けられているアドレス空間と送信コネクタを使用してメッセージを転送します。SharePoint サーバーが内部サーバーである場合も、インターネット経由で転送するために SharePoint のメッセージがエッジ トランスポート サーバーに転送される場合があります。内部メッセージの転送では、詳細なアドレス空間と送信コネクタを使用し、コネクタの構成で SMTP サービスをスマート ホストとして実行している SharePoint サーバーを指定します (詳細については、この記事のダウンロードに含まれている SharePoint Messaging Integration.pdf を参照してください)。適切に定義されたルーティング トポロジと専用のブリッジヘッド サーバーを構築することは、Exchange Server から SharePoint に確実にメッセージを転送できるようにするのに役立ちます。
SharePoint サーバーにメッセージが届いたことを確認するには、Windows SharePoint Services タイマ サービスを停止します。Windows SharePoint Services タイマ サービスがメッセージを処理し、受信者の電子メール アドレスと関連付けられたドキュメント ライブラリに添付ファイルを配置するため、このサービスを停止すると、メッセージは図 4 のようにドロップ フォルダに蓄積されます。ドロップ フォルダにメッセージが配信されない場合は、ハブ トランスポート サーバーでキュー ビューアを使用して、Exchange Server でメッセージが正しく転送されているかどうかを確認します。その後、ハブ トランスポート サーバーと SharePoint サーバーの SMTP サービスの通信を妨げている可能性がある、ネットワーク通信の問題が発生していないかどうかを調査します。
図 4 受信メッセージの転送 (画像をクリックすると拡大表示されます)
Windows SharePoint Services タイマ サービスを再起動すると、ドロップ フォルダからメッセージ アイテムが消えていることを確認できます。ただし、Windows イベント ログに SharePoint でメッセージが正常に処理されたことが記録されていても、メッセージの添付ファイルが所定のドキュメント ライブラリに配置されない場合は、Exchange Server では、メッセージが Exchange の RTF 形式で送信されたということになります。この問題を調査するには、もう 1 度タイマ サービスを停止し、Outlook® クライアントから添付ファイルを追加した別のメッセージを送信し、そのメッセージがドロップ フォルダに配信されたら、メッセージをメモ帳で開きます。メッセージを開いたら、winmail.dat という文字列を検索します。この文字列が見つかった場合は、Exchange Server では間違った形式でメッセージが送信されていることになります。
SharePoint では、メッセージの添付ファイルが MIME 形式または UUENCODE 形式でエンコードされている必要があります。また、SharePoint では winmail.dat に関連する処理の問題が Windows イベント ログに記録されません (図 5 参照)。このような問題が発生した添付ファイルは単にドキュメント ライブラリに表示されないだけです。メモ帳をトラブルシューティング ツールとして使用し、Exchange 管理コンソールでリモート ドメインの定義を SharePoint の電子メール ドメイン用に構成することによって、形式に関する問題を解消できます。それには、[ジャーナル レポートの添付用に送信された元のメッセージの形式] タブの [Exchange リッチ テキスト形式] で [使用しない] を選択します。
図 5 winmail.dat メッセージの処理 (画像をクリックすると拡大表示されます)

ディレクトリの管理
タイマ サービスのさらに便利なイベントの 1 つはイベント 6873 です。これは、不明なエイリアスが原因で、受信メール ファイルの処理中にエラーが発生したことを示すイベントです。このイベントは、Exchange ユーザーがメッセージを送信する際に、不適切な SharePoint の電子メール アドレス (たとえば、存在しないドキュメント ライブラリ) を指定した場合に発生します。
SharePoint サーバーの全体管理の受信メールの設定で Directory Management Service を構成して、メールが有効になっているドキュメント ライブラリ用の受信者オブジェクトを Active Directory に作成することによって、この問題を緩和できます。このように構成すると、Exchange ユーザーは、適切なアドレス情報がを設定された受信者オブジェクトをアドレス帳から簡単に選択できます。
ただし、今度は、これまでとまったく別のトラブルシューティングに関する厄介な問題に対応する必要があることに注意してください。Directory Management Service は、Web サーバーでは管理者特権が必要なので、セキュリティが確保されたシステム構成では、最小特権の原則によりエラーになります。また、製品ドキュメント (technet.microsoft.com/library/cc262947.aspx など) では、Active Directory の SharePoint 受信者オブジェクトに指定した OU で、サーバーの全体管理アプリケーション プール アカウントに "ユーザー アカウントの作成、削除、および管理" の権限を与える必要がある状況が少しおおげさに述べられています。
Directory Management Service では、連絡先オブジェクトとグループ オブジェクトが作成されるので、サーバーの全体管理アプリケーション プール アカウントには、この OU 内の連絡先オブジェクトとグループ オブジェクトに対するフル コントロールが必要になりますが、ユーザー アカウントに対する管理者権限は必要ありません。製品ドキュメントの説明に従って Web ファームで Directory Management Service を設定し、ドキュメント ライブラリでメールを有効にしようとすると、"アクセスが拒否されました" というエラーが発生する可能性が非常に高くなります。
エラー情報では Active Directory の権限に問題があることが指摘されているので、SharePoint の管理者は SharePoint の OU に対するフル コントロールを Everyone にすばやく割り当てるかもしれません。ただし、この方法では Active Directory のセキュリティが脆弱になるだけでなく、問題も解決されません。
構造化されたトラブルシューティングの手順では、まず問題が発生した場所を特定してから、問題が発生している構成を変更する必要があります。このアプローチに従い、ドメイン コントローラの Windows イベント ログを確認し、ネットワーク モニタを使用してネットワーク通信を追跡すると、この問題が発生したときに SharePoint が Active Directory にアクセスしていないことが確認できます。ですから、Active Directory の構成を変更しても問題は解決する可能性は低いと言えます。問題は SharePoint サーバーで発生しています。
残念ですが、この権限の問題についてさらに有益な情報を得るのは非常に困難です。というのも、SharePoint では、Windows イベント ログに詳細な情報が記録されないからです。ただし、SharePoint でデバッグを有効にすると、コール スタックを確認できます (図 6 参照)。ここでは、Directory Management Service で SharePoint Web サービスの CreateContact メソッドを使用していることが示されています。SharePoint SDK では、これが Email Integration Web Service (電子メール統合 Web サービス、<WSS_server>:<admin_port>/_vti_bin/SharepointEmailWS.asmx) であることが通知されます。
図 6 デバッグの結果
Server was unable to process request. ---> Access is denied.
   at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message,      WebResponse response, Stream responseStream, Boolean asyncCall)
   at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[]      parameters)
   at Microsoft.SharePoint.DirectorySoap.SPDirectoryManagementProxy.CreateContact(String Alias,      String FirstName, String LastName, String ForwardingEmail, ContactFlags Flags)
   at Microsoft.SharePoint.SPList.UpdateDirectoryManagementService(String oldAlias, String      newAlias)
   at Microsoft.SharePoint.SPList.Update(Boolean bFromMigration)
   at Microsoft.SharePoint.SPList.Update()
   at Microsoft.SharePoint.ApplicationPages.EmailSettingsPage.SubmitButton_Click(Object sender,      EventArgs args)
   at System.Web.UI.WebControls.Button.OnClick(EventArgs e)
   at System.Web.UI.WebControls.Button.RaisePostBackEvent(String eventArgument)
   at System.Web.UI.Page.RaisePostBackEvent(IPostBackEventHandler sourceControl, String      eventArgument)
   at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean      includeStagesAfterAsyncPoint)
Web ブラウザで SharepointEmailWS.asmx を確認して、サポートされている操作の一覧を見てみましょう。CreateContact メソッドが表示されています。このメソッドのリンクをクリックすると、Active Directory で連絡先を作成する場合に、この Web サービスに送信する必要がある SOAP メッセージが表示されます。この方法では、スクリプトを使用するトラブルシューティング ツールを作成して SharePoint ユーザー インターフェイス以外で作業を行い、テスト実行中に異なるユーザー アカウントをさらに簡単に指定できるので、非常に役に立ちます (ツールの作成については、付属リソースの SharepointEmailWS.vbs を参照してください)。図 7 に、サーバーの全体管理アプリケーション プール アカウントと SharePoint の管理者アカウントを使用してこのスクリプトを実行した場合に返される情報を示します (左側が前者、右側が後者の情報です)。
図 7 2 種類の "アクセスが拒否されました" エラー (画像をクリックすると拡大表示されます)
これらのダイアログ ボックスには、異なるエラー メッセージが表示されています。どちらのメッセージにもアクセスが拒否されたことが示されています。しかし、左側のエラーには処理の問題が表示されていますが、右側のエラーには表示されていません。では、アプリケーション プール アカウントと SharePoint の管理者アカウントでは一体何が違うのでしょうか。
SharePoint 管理者は SharePoint サーバーのローカル管理者ですが、アプリケーション プール アカウントはそうではありません。Web アプリケーションのアプリケーション プール アカウントをローカル Administrators グループに追加して Web サーバーを再起動すると問題は解決しますが、これはすばらしいお知らせというわけではありません。実稼動の Web サーバーで管理者特権のあるアプリケーション プール アカウントを実行するのは適切ではありません。
なぜアプリケーション プール アカウントにはこのような管理者特権が必要なのでしょうか。ここでも、スクリプトを使用すると、その理由が明らかになります。テスト目的で Web サーバーのローカル Administrators グループの権限をすべてのユーザーに与えると、アプリケーション プール アカウントは Email Integration Web Service (電子メール統合 Web サービス) を使用できますが、SharePoint 管理者を含む他のすべてのアカウントについては、このサービスへのアクセスが拒否された状態を維持できます。つまり、Email Integration Web Service (電子メール統合 Web サービス) では、アクセス制御を判断する基準としてアプリケーション プールの構成を使用しているということになります。
アプリケーション プールの構成は IIS メタベース (IIS 7.0 では、applicationHost.config ファイル) の一部であり、既定ではメタベースへのアクセスはローカル Administrators グループに限定されています。さいわい、IIS 6.0 Resource Kit Tools に収録されている Metabase Explorer を使用して、管理者以外のアカウントにメタベースへのアクセス権を与えることができます。IIS 7.0 では、次のコマンドを実行するだけで、簡単に applicationHost.config ファイルへのフル コントロール権限を与えることができます。
CACLS "%SystemDrive%\Windows\System32\inetsrv\config\applicationHost.config"
/G "<application pool account>" :F /E iisreset /noforce
要するに、Active Directory で連絡先オブジェクトを作成するには、サーバーの全体管理アプリケーション プール アカウントに、対象 OU の連絡先オブジェクトとグループ オブジェクトに対するフル コントロール権限が必要になります。また、Web アプリケーションのプール アカウントには、Web ファーム内の SharePoint サーバーのメタベースに対するフル コントロール権限が必要になります。これらの権限を与えると、SharePoint ユーザー インターフェイスを使用して連絡先オブジェクトを作成できるようになります。
でもちょっと待ってください。まだ続きがあります。Active Directory で受信者オブジェクトを作成することは、ディレクトリを統合する処理の半分にすぎません。これ以外に、Exchange 関連の受信者属性を作成し、サーバー ベースのアドレス帳を更新する必要があります。たとえば、Exchange 管理シェル コマンド Update-GlobalAddressList "Default Global Address List" を使用して Exchange Server サーバーのグローバル アドレス一覧を更新すると、Outlook アドレス帳に SharePoint ドキュメント ライブラリ用の受信者オブジェクトが表示されるようになります。しかし、これらの受信者にメッセージを送信すると、アドレス情報が適切ではないことが原因で、図 8 のような配信不能レポートが返されます。
図 8 ドキュメント ライブラリに配信できないメッセージ (画像をクリックすると拡大表示されます)
IMCEAEX は Internet Mail Connector Encapsulated Address for Exchange の頭文字です。これは、Exchange 以外の受信者アドレスが、従来の Exchange Internet Mail コネクタが処理できる形式でカプセル化されていることを意味します。しかし、最近は Exchange Server 2007 とネイティブな SMTP ベースの送信コネクタを使用して形式の異なるアドレスに対処できるようになりました。
つまり、SharePoint の Email Integration Web Service (電子メール統合 Web サービス) では、Exchange Server 2007 でメッセージを転送する際に必要なアドレス属性が記述されず、名前、姓、表示名、および対象のアドレス (必要に応じて、ms-Exch-RequireAuthToSendTo) の属性だけが書き込まれます。しかし、メールのニックネーム、または従来の Exchange DN やプロキシ アドレスを設定したり、受信者オブジェクトと Exchange 受信者ポリシーが関連付けられたりすることはありません。
この問題を解決するには、Exchange 管理シェルの Get-Mailbox コマンドレットを使用して、SharePoint の電子メール ドメインをポイントするすべての受信者オブジェクトと対象のアドレスを取得します。次のように出力を Set-MailContact コマンドレットにパイプして、Exchange 受信者ポリシーをアクティブにします。
Get-Contact | where { $_.WindowsEmailAddress –like
  '*sharepoint.contoso.com' } | Set-MailContact
  -EmailAddressPolicyEnabled:$True
また、Exchange 管理コンソールを使用し、連絡先オブジェクトのプロパティで [電子メール アドレス ポリシーに基づいて電子メール アドレスを自動更新する] チェック ボックスをオンにして、この問題を解決することもできます。

WSS 3.0 と MOSS 2007 では、既定ですべてのメッセージングの統合がサポートされており、電子メール ベースのアラートや通知、ワークフロー、およびドキュメントの送信を有効にすることができます。システムを正しく構成するのは簡単なことではありませんが、メッセージ システムを統合すると従業員の生産性を向上させることができます。具体的には、受信メッセージと送信メッセージの両方が問題なく転送されるようにしたり、ディレクトリを正しく統合したりする必要があります。
SharePoint のエラー メッセージには、わかりづらいものや情報が不足しているものもあります。ですが、今月のコラムでは、統合に関する問題の原因を突き止め、根本原因を特定し、SharePoint サーバーのセキュリティを危険にさらすことなく、その根本原因を解決する方法を説明しましたので、今後は、ぜひこの方法をご活用ください。

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


Windows PowerShell Windows PowerShell 2.0 のリモート管理の概要
Don Jones

このコラムは、Windows PowerShell のプレリリース版を基にしています。ここに記載されているすべての情報は、変更される場合があります。

目次
2 種類のリモート処理
同期と非同期
再利用可能な実行空間
ファンイン リモート処理
Windows PowerShell 2.0 の革新的なアプリケーション
Windows PowerShell 2.0 の最新の Community Technology Preview (CTP) は、お試しになりましたか。最新バージョンである CTP2 には、さらに改良されたリモート管理機能が備わっており、Windows PowerShell 2.0 の新機能について理解を深めるには今が絶好のチャンスです。このコラムを読み進める前に、CTP2 を
go.microsoft.com/fwlink/?LinkID=119707 からダウンロードしてください。
まず、いくつかの重要な点を明確にしておきましょう。CTP は、マイクロソフトが提供するベータ版公開前のコードで、私のような熱心なユーザーが、アプリケーションの次のバージョンでマイクロソフトが何を目指しているかを把握できるようになります。CTP の各マイルストーン (通称、ドロップ) は、それ以前のドロップとはまったく異なる場合があります。このような現象が起こるのは、開発チームがユーザーからフィードバックを収集し、そのフィードバックを慎重に確認して、このユーザーからのフィードバックに基づいてアプリケーションを変更するためです。このような方法を採用していることにより、CTP の利用に関して重要なメリットと注意点が生じます。
ビデオ
このビデオでは、Don Jones が Windows PowerShell 2.0 CTP2 の新しいリモート管理機能について説明しています。ぜひ、ご覧ください。

メリットは、ユーザーが CTP を使用したときに、製品に関するフィードバックを (connect.microsoft.com Web サイト経由で) 製品の開発段階で送信できるので、開発チームがフィードバックに基づいて作業できるということです。ベータ版 (さらに悪い場合はリリース候補版) がリリースされる段階まで待っていると、ユーザーのフィードバックを組み込むことは非常に難しくなります。CTP の提供中はあらゆる問題が発生する可能性がありますが、開発チームは必要に応じて広範囲にわたる大幅な変更を行うことができます。
このため、CTP は運用環境では使用できないという注意点があります。もちろん、Windows PowerShell™ 2.0 CTP2 は、これまで提供された CTP の中で最も安定したプレリリース コードの 1 つですが、次の CTP ドロップはまったく異なるアプリケーションになる可能性があることを覚えておいてください。そのため、次のバージョンでは最初からやり直すことが必要になる可能性があるので、CTP2 に依存しないでください。
CTP は、Windows PowerShell 1.0 と共存させる形でインストールできない点に注意してください。理想的な環境は、利用可能なすべての機能を有効にするために、システムに Microsoft® .NET Framework 3.5 がインストールされている状態です。.NET Framework 3.5 がインストールされていないと、一部の機能が制限されます。
また、CTP は初期段階のコードなので、マイクロソフトでは今のところ最新のオペレーティング システム (つまり、Windows Vista® と Windows Server® 2008) で動作するアプリケーションを最重要視しています。現時点での OS の互換性は、最終的にリリースされるコードで予想される OS の互換性を示すものではありません。下位バージョンへの移植については、開発サイクルの後半で対処します。

2 種類のリモート処理
通常、リモート管理では、ファンインおよびファンアウトという 2 種類のリモート処理が行われます。ファンイン リモート処理では、複数の管理者が 1 台のサーバーに対して Secure Shell (SSH) 接続を確立します。Windows PowerShell は、区分化された安全な方法でこのような接続を確立できるように設計されています。ですから、たとえば、Exchange Server のホスティング サービスを提供している企業では、サーバーの管理者アクセス権を顧客に与えることができます。ファンイン リモート処理を使用すると、リモート サーバーにインストールされた Windows PowerShell のコピーに、リモートから対話形式で安全にアクセスできます (この機能は Windows PowerShell 2.0 のみで使用できます)。
ファンアウト リモート処理は、リモート サーバー群全体に一連のコマンドを同時に発行する場合に使用します。コマンドは、ワークステーションからサーバー群に対して同時に "ファンアウト" されます。各サーバーでコマンドが実行され、Windows PowerShell オブジェクト形式の結果がワークステーションに返されるので、それらの結果を確認して対応できます。Windows PowerShell では、Windows® Management Instrumentation (WMI) と Windows リモート管理 (WinRM) というファンアウト リモート処理の 2 つの主要なテクノロジをサポートしています。これらのテクノロジは、当初は Windows Server 2008 に同梱されていましたが、Windows PowerShell 2.0 CTP で更新されました。

同期と非同期
実は、Windows PowerShell 1.0 にも、WMI に関連付けられたいくつかの基本的なファンアウト機能が備わっていました。たとえば、次のように簡単にコンピュータ名の配列を作成し、各コンピュータの WMI クラスを取得することができました。
$names = @("server1","server2","server2")
Get-WmiObject Win32_OperatingSystem
    –computer $names
Windows PowerShell 1.0 では WMI メソッドを一括で実行する方法が提供されていなかったので、コンピュータを再起動するなどのメソッドを実行するには、もう少し作業が必要でした。しかし、Windows PowerShell 2.0 CTP では Invoke-WmiMethod コマンドレットが導入されたため、次のようなコードを記述すれば済むようになりました。
$names = @("server1","server2","server2")
Get-WmiObject Win32_OperatingSystem     –computer $names | `
 Invoke-WmiMethod Reboot
ただし、この技法には問題があります。この技法は同期的です。つまり、一度に 1 台のコンピュータにしか接続できないので、各コンピュータでの処理が完了しないと他のコマンドを実行できません。ただし、この CTP では、このようなコマンドをバックグラウンドで実行できるバックグラウンド ジョブという新しい概念が導入されました。この概念はきわめて単純なので、次のように AsJob パラメータを追加するだけで WMI コマンドをバックグラウンドで実行できます。
$names = @("server1","server2","server2")
Get-WmiObject Win32_OperatingSystem     –computer $names -asjob
実行後のジョブの状態は Get-PSJob を、ジョブの最終結果は Receive-PSJob を実行して確認できます (ジョブ管理の詳細については、今後のコラムで詳しく説明します)。ただし、Invoke-Command コマンドレットを使用すると、次のようにさらに優れた方法でバックグラウンドでコマンドを実行できます。
$command = { Get-WmiObject     Win32_OperatingSystem }
$names = @("server1","server2","server2")
Invoke-Command –command $command     –computer $names –asjob
このコマンドを実行すると、指定した各コンピュータに Get-WmiObject コマンドが発行され、発行されたコマンドは各コンピュータのローカルで実行されます。通常、Get-WmiObject コマンドは、WMI リモート プロシージャ コール (RPC) 接続に依存しなくても高速に実行されますが、Invoke-Command コマンドレットでは、既定でポート 80 または 443 を使用する WinRM が使用されます。これらのポートを使用すると、簡単にファイアウォールを操作することが可能で、ポートは完全に構成できます。また、Invoke-Command コマンドレットでは、代替の資格情報と調整用の追加パラメータもサポートしているので、何百台ものコンピュータを対象としながら、同時に実行するコンピュータを数台に制限することができます。このため、過密状態や過剰な負荷を回避できます。

再利用可能な実行空間
特定の一連のコンピュータを複数回リモートで管理する予定がある場合は、単純なコンピュータ名の一覧ではなく、実行空間を使用することをお勧めします。Windows PowerShell の実行空間は、単なるシェルのエンジンのインスタンスです。これは、シェル コンソール ウィンドウとしてコンピュータのローカルで実行している場合も、リモート コンピュータのバックグラウンドで実行している場合も同様です。リモートの実行空間は、次のように簡単に開始できます。
$names = @("server1","server2","server2")
New-RunSpace –computer $names
実行空間でも WinRM が使用されるので、既定でポート 80 (–UseSSL パラメータを指定した場合は 443) が使用されます。また、実行空間では、代替の資格情報なども使用できます。次のように、結果の実行空間オブジェクトを取得したら、Invoke-Command コマンドレットに渡すことができます。すると、Windows PowerShell によって、これらの実行空間が存在するコンピュータにコマンドが発行されます。
$command = { Get-WmiObject     Win32_OperatingSystem }
$rs = Get-Runspace
Invoke-Command –command $command     –runspace $rs –asjob
この方法を使用すると、シェルが起動している間は実行空間がアクティブなままなので、開始した実行空間を再利用してさらにコマンドを実行できるというメリットがあります。

ファンイン リモート処理
実行空間は、ファンイン リモート処理でも重要です。たとえば、図 1 は、リモート コンピュータで実行空間を作成し、その実行空間への参照を取得して、Push-Runspace コマンドレットを使用して実行空間をアクティブにしたことを示しています。この時点では、リモート コンピュータでは、SSH や他のリモート シェル ユーティリティの場合と同様にコマンドを実行していました。 Pop-Runspace コマンドレットを実行すると、元のローカルの実行空間に戻ります。シェル プロンプトにより、いつでも自分の現在地を追跡できます。
図 1 実行空間を使用したリモート コンピュータでのコマンドの実行 (画像をクリックすると拡大表示されます)
実際に実行した一連のコマンドは、下記のとおりです。
PS C:\>new-runspace -computer     "WIN-YFZXQMHXAWM"
PS C:\>$server2 = get-runspace -sessionid 2
PS C:\>push-runspace $server2
[win-yfzxqmhxawm]: PS C:\Windows\System32>    pop-runspace
PS C:\>
複数の管理者が 1 台のサーバーでリモートの実行空間を対話形式で同時に開くことができるため、この技法はファンインと呼ばれます。つまり、管理者は各自のワークステーションからサーバーに "ファンイン" します。Windows PowerShell 2.0 の新しいセキュリティ モデルにより、各管理者は、作成できるシェルとコマンドレットが制限されるので、グローバルな変更を行うことができず、各自のシェルの範囲に制限されます (このような新しいセキュリティ技法により、.NET Framework 対象の言語でなんらかのカスタム ソフトウェア開発を行うことが必要になります。Windows PowerShell コラムでは、これについては取り上げませんが、このような機能が存在することを覚えておくと役に立ちます)。

Windows PowerShell 2.0 の革新的なアプリケーション
Windows PowerShell 2.0 CTP には、すばらしい一連の新機能が用意されています。個人的な意見ですが、リモート処理は革新的なアプリケーションです。ほぼすべての環境の各管理者が、リモート処理のメリットを享受できます。
これらの機能について理解して、ぜひ製品チームまで提案をお寄せください。グループ ポリシーで WinRM の既定のポートを管理する必要がある場合、コマンドレットの動作が異なる場合、パフォーマンスの問題が発生した場合、WinRM の構成が難しい場合などの事象が発生した際は、connect.microsoft.com に提案を送るか、私を含む MVP 受賞者とフィードバックを共有して、製品開発にかかわることができます (私に連絡を取りたい場合は、ScriptingAnswers.com のフォーラムにフィードバックをお寄せください)。ぜひ、製品開発に関与して、次世代の Windows PowerShell の革新的なアプリケーションの構築をサポートしてください。
今月のコマンドレット : Select-Object
「Get-Service | ConvertTo-HTML | Out-File Services.htm」を実行してみてください。コマンドレットの実行が完了したら、Web ブラウザで結果の HTML ファイルを確認してください。膨大な量の情報が表示されていると思います。必要な情報を選択して、もう少し情報量を削減する方法があればいいのにとお考えでしょう。まさにこの処理を実行できるのが Select-Object コマンドレットです。たとえば、サービス名とサービスの現在の状態を示す一覧のみが必要だとします。その場合は、「Get-Service | Select Name,Status | ConvertTo-HTML | Out-File Services.htm」というコマンドを実行して必要な情報のみを取得できます。
ただし、Select-Object コマンドレットを使用すると、元のオブジェクト (ここでは、サービス) が破棄され、指定したプロパティのみを含むカスタム オブジェクト (文字どおり PSCustom という種類のオブジェクト) が生成されることに注意する必要があります。Select-Object コマンドレットを実行すると元のオブジェクトの機能にアクセスできなくなるので、このコマンドレットは、できるだけパイプラインの末尾近くで実行し、できる限り元のオブジェクトを使用して作業するのが望ましいでしょう。

Don Jones は『Windows PowerShell v2.0: TFM』の共著者で、ScriptingAnswers.com の Special Forces クラスルーム トレーニング (scriptinganswers.com/training.asp) でトレーニングの講師も務めています。連絡先は jeepdon@mac.com (英語のみ) です。


Hey, Scripting Guy! 早いルートを利用する
Microsoft Scripting Guys

この数か月の間に、Scripting Guys の 1 人は、ここシアトル地域で新しいものを体験する機会がありました。それは米国中のさまざまな都市でテストされているプログラムで、通行料電子徴収と呼ばれているものです。でも、ワシントン州では、このプログラムは Good to Go! と呼ばれています。
このプログラムのしくみをご説明しましょう。フロントガラスに取り付ける電子装置を購入し、口座を開設して、お金を少し入れておきます。高速道路 (freeway) で監視装置の下を通過するたびに、口座から自動的にお金が引き落とされます。基本的に、お金を払うことによって、料金所で停止することなく高速道路 (freeway) を走行することができます (実際は無料ではないので、freeway という呼称はもう現実に即していませんね。ハイウェイ (highway) という呼び方を使用する必要があるようです。ただ、最近では海面下数フィートの所を通っているものもあるので、あまり high というわけでもないように思えますが)。
通行料がかかる場所の多くでは、カープール (自家用車の相乗り) をしている人たちはお金を払う必要がありません。でも、Good to Go! の興味深いところは、カープール専用の車線でのみ通行料が課金されるという点です。これにどんな意味があるのか、ですって。わざわざカープールしている人が、どうしてお金を払わなければいけないのでしょうか。実は、カープールしている人がお金を払う必要があるというわけではありません。このシステムによる料金徴収の対象となるのは、自分の車に 1 人で乗っているときにカープール専用の車線を使用する人だけです。言わずと知れたことですが、カープール専用の車線を走行することを希望する理由は、通常、この車線の車の通行量が少ないからです。車が実際に動いている車線はカープール専用車線だけであるというときもあります。
このシステムには既に何千人もの人が申し込みをしていますが、前述のとおり、システムは現在試験運用中です。シアトル地域には、行き先がどこであれ、早いルートを利用するためならお金を払うことを厭わない人が大勢います。
今月のコラムでは、Scripting Guys は、独自のちょっとした実験を行うことにしました。私たちは、Microsoft® Visual Basic® Express Edition と呼ばれる早いルートをご紹介することにしました。まずは、このルートの最もすばらしい点の 1 つをお伝えしておきましょう。それは、本当に無料だという点です。この情報は、どこで使用しても、何人で使用しても、どのような時間帯に使用しても使用料はかかりません。かなり良さそうな話ですよね。確かに、いくつかの新しいことを学ばなければならないという点では、少し代償を払う必要があるように思えるかもしれません。でも、得られるメリットがその代償に値するものだと確信していただけると思います。
先に進む前に、自分たちが担当分野から少し外れたことをしようとしているのは承知のうえであることをお伝えしておきます。通常、Visual Basic や Visual C#® などの Visual Studio® 製品は、TechNet Magazine ではなく MSDN® Magazine のテーマとなるものです。でも、MSDN と TechNet は 1 つの大きな機能不全。すみません、今のは訂正します。1 つの大きく陽気な集団になる方向にどんどん向かっているようなので、ここでは大目に見ていただければ、さいわいです。また、今月は、従来は開発者専用だったツールの使用方法について説明しますが、この記事が対象とするのは、これまでと同様、Windows® システム管理者です。この記事をもうしばらく読み続けると、私たちの言いたいことがおわかりいただけると思います。
一連の説明を理解するには、まず Visual Basic をインストールする必要があります。ちょっと待ってください。「そんなものは持っていない」とか「そんなものを買う余裕はない」とか言って逃げ出したりしないでください。マイクロソフトでは Visual Basic Express Edition を無償で提供しており、microsoft.com/express/download からダウンロードできます。
この記事では、Visual Basic Express Edition を使用する方法の詳細については説明しません。Visual Basic Express Edition のヘルプにはチュートリアルが用意されていますし、ヘルプ自体もなかなかのものです (信じがたいことかもしれませんが、本当です)。この記事では、Visual Basic Express Edition を使用して Windows Vista® で特定の問題を解決する方法について説明します (ただし、ここで紹介する方法は Vista より前のバージョンの Windows でも機能します)。この記事を読んだ後は、自力で引き続き Visual Basic Express Edition を使い続けることができます。解決する問題は、Windows Vista で、[ファイルを開く] ダイアログ ボックスを表示するにはどうすればよいか、というものです。
[ファイルを開く] ダイアログ ボックスをスクリプトから開く方法については、数年前に説明しました (「ファイルを選択するためのダイアログ ボックスを表示する方法はありますか」(microsoft.com/technet/scriptcenter/resources/qanda/jan05/hey0128.mspx) というコラムを参照してください)。この記事は、Windows Vista が登場するずっと前の 2005 年 1 月に公開されました。その記事で紹介した解決策では、[ファイルを開く] ダイアログ ボックスを開くために UserAccounts.CommonDialog という ActiveX® コントロールを使用しています。このコントロールを使用すると、開くファイルを参照することができます。残念ながら、このコントロールは Windows Vista で廃止されたので、この解決策は新しいシステムでは機能しません (いえ、このコントロールを廃止することが得策かどうかを私たちにたずねた人はいませんでした)。つまり、私たちの知る限りでは、VBScript を使用して、[ファイルを開く] ダイアログ ボックスを開くことができないということです。ですから、スクリプトを作成するのではなく、Visual Basic を使用してアプリケーションを作成します。このアプリケーションが実行する処理の 1 つは、[ファイルを開く] ダイアログ ボックスを開くことです。
ええ、そのとおりです。これからご紹介する例では、Visual Basic で完全なアプリケーションを作成します。これは最初は少し大変な作業に思えるかもしれませんが、Visual Basic Express Edition を使用すると、完全なアプリケーションを作成することはスクリプトを記述するのと同じくらい簡単だということがおわかりいただけると思います。このアプリケーションは 1 つのウィンドウ (フォーム) で構成され、このウィンドウ上のボタンをクリックすると、[ファイルを開く] ダイアログ ボックスを開くことができます。次に、このダイアログ ボックスでは複数のテキスト ファイルを選択できます。ファイルを選択すると、ファイルが読み取られ、選択した一連のファイルの内容がフォームに表示されます。
では、作業に取り掛かりましょう。まず、Visual Basic Express Edition を起動します。最初に行う必要がある作業は、新しいプロジェクトの作成です。これは、[ファイル] メニューの [新しいプロジェクト] をクリックすることによって行います。この操作を行うと、[新しいプロジェクト] ダイアログ ボックスが表示されます (Visual Studio 2008 Express Edition より前のバージョンの Visual Basic Express Edition を使用している場合は、ここで紹介する内容とは少し異なる点がいくつかあるのでご注意ください)。Windows フォーム アプリケーションを作成するので、[Windows フォーム アプリケーション] テンプレートを選択し、プロジェクトの名前を入力します。ここでは、ReadFiles という名前を付けました (図 1 参照)。
図 1 Visual Basic で新しいプロジェクトを作成する (画像をクリックすると拡大表示されます)
プロジェクトの初回作成時には、使用する新しいフォームが 1 つ自動的に用意されます。今回作成するアプリケーションでは、図 2 のようなフォームをユーザーに対して表示します。前述のとおり、フォームにはボタンが配置されており、このボタンをクリックすると、C:\Scripts フォルダが開かれた状態で、[ファイルを開く] ダイアログ ボックスが表示されます。ユーザーは、ファイル システムの任意の場所から 1 つ以上のテキスト ファイルを選択できます。ユーザーがテキスト ファイルを選択すると、選択された各ファイルの 1 行目が読み取られ、その内容がフォームのリスト ボックスに表示されます (この処理に聞き覚えがある方は、ほぼ間違いなく、2008 Scripting Games の初級コース (microsoft.com/technet/scriptcenter/funzone/games/games08/bevent3.mspx) に参加した方でしょう)。
図 2 ユーザーに対して表示される ReadFiles フォーム
フォームを作成するには、ツールボックスからプロジェクトのフォームにコントロールをドラッグする必要があります。既定では、ツールボックスは Visual Basic ウィンドウの左側に表示されます (ツールボックスが表示されていない場合は、Visual Basic ワークスペースの左側にある [ツールボックス] ボタンをクリックし、[すべての Windows フォーム] を展開します)。ツールボックスの [Button] をクリックしてから、フォーム上でマウスをドラッグし、必要なサイズのボタンを作成します。ボタンにラベルを追加するには、フォームに追加したボタンをクリックし、ラベルとして表示する文字列を入力します (または、[プロパティ] ダイアログ ボックスで Text プロパティを編集します。このダイアログ ボックスは、既定では Visual Basic ワークスペースの右下に表示されます)。ここでは、ボタンに Browse for Files というラベルを付けました。次に、[ListBox] をクリックし、フォーム上で先ほどと同じようにマウスをドラッグして、リスト ボックスを作成します。このリスト ボックスは、テキスト ファイルから読み取った行を表示するのに使用します。
これで、フォームの作成に必要な作業は完了です。おもしろいのはここからで、ボタンをクリックしたときになんらかの処理が行われるようにする必要があります。まず、フォーム上の Button コントロールをダブルクリックします。すると、コード エディタが開かれます。コード エディタ上では、次のような Button1_Click サブルーチンという新しいサブルーチンが既に作成されています。
Private Sub Button1_Click _
  (ByVal sender As System.Object, _
   ByVal e As System.EventArgs) _
  Handles Button1.Click
End Sub
このサブルーチンは、フォーム上のボタンがクリックされるたびに実行されます。ご覧のとおり、現時点では、このサブルーチンの中身は空っぽなので、ボタンがクリックされたときに実行する処理をアプリケーションに指示するコードを追加する必要があります。実行する必要があるのはどのような処理なのか、ですって。まず、このコラムの冒頭で説明すると約束した、[ファイルを開く] ダイアログ ボックスを表示する処理を実行する必要があります。Visual Basic で実行するほぼすべての処理の場合と同様に、この処理の実行には Microsoft .NET Framework を使用します。
まず、前述のサブルーチンより前に次の 2 つの Imports ステートメントを追加します。
Imports System
Imports System.IO
これらのステートメントでは、.NET Framework 名前空間を指定しています。これらの名前空間内のクラスを使用するので、クラスを使用する際にクラス名を指定するだけで済むように、これらの名前空間をここでインポートしています。前述のとおり、これらのステートメントをサブルーチンより前に挿入する必要があるという点に注意してください。Imports ステートメントはグローバルです。つまり、Imports ステートメントはサブルーチンや関数の中に記述することができず、独立した状態でサブルーチンや関数の外に記述する必要があります。
VBScript では、スクリプトの先頭に Option Explicit ステートメントを追加しない限り、変数を明示的に宣言する必要はありませんが、Visual Basic では、このステートメントが自動的に追加されるので、すべての変数を宣言する必要があります。OpenFileDialog オブジェクト ([ファイルを開く] ダイアログ ボックスを表します) への参照を保持する次のような変数が必要となります。
Dim dlg As Windows.Forms.OpenFileDialog
(Dim を使用して) OpenFileDialog 型の変数を宣言したので、次のように、このオブジェクトの新しいインスタンスを作成することができます。
dlg = New OpenFileDialog()
しかし、まだダイアログ ボックスは表示していません。まずは、次のように、いくつかのプロパティを設定する必要があります。
dlg.Multiselect = True
dlg.InitialDirectory = "c:\scripts"
dlg.Filter = "txt files (*.txt)|*.txt|" & _
  "All files (*.*)|*.*"
Multiselect プロパティでは、[ファイルを開く] ダイアログ ボックスでユーザーが複数のファイルを選択できるかどうかを指定します。ここでは複数のファイルを選択できるようにする必要があるため、このプロパティを True に設定します。InitialDirectory プロパティには C:\Scripts を設定します。このプロパティを設定しない場合、コンピュータのメイン ディレクトリが開かれた状態のダイアログ ボックスが表示されます。
そして、最後になりましたがもちろん大事な処理として、Filter プロパティを設定します。
dlg.Filter = "txt files (*.txt)|*.txt|" & _
  "All files (*.*)|*.*"
ここでは、ダイアログ ボックスに表示されるファイルをフィルタ処理しています。今回は、.txt ファイルのみを表示します。これらのプロパティを設定すると、図 3 のような状態の [ファイルを開く] ダイアログ ボックスが表示されます。
図 3 テキスト ファイルのみが表示されている [ファイルを開く] ダイアログ ボックス (画像をクリックすると拡大表示されます)
ようやく、ダイアログ ボックスを表示する処理まで辿り着きました。これは、次のように ShowDialog メソッドを使用して行います。
dlg.ShowDialog()
ShowDialog メソッドでは、ユーザーが [開く] をクリックして選択したファイルを開いたのか、それとも [キャンセル] をクリックしてダイアログ ボックスを閉じたのかを示す値を返します。[キャンセル] がクリックされた場合は、何も処理を行いません。そのため、後続の処理を実行する前に、[開く] がクリックされたことを確認するために、次のように If ステートメント内で ShowDialog メソッドを呼び出しています。
If dlg.ShowDialog() = _
  Windows.Forms.DialogResult.OK Then
ええ、わかっています。チェックしているのは Open プロパティではなく OK プロパティです。内部的には、[開く] ボタンは実は [OK] ボタンと同じなのです。ただ、ユーザーに対しては "開く" という言葉を表示した方が理にかなっているので、そのようなラベルを使用しているだけです。
次に、ユーザーがダイアログ ボックスでどのファイルを選択したかを知る必要があります。ファイル名は OpenFileDialog オブジェクトの FileNames プロパティに格納されているので、次のように、このプロパティに格納されているファイル名を順番に読み取っていく For Each ループを設定します。
For Each strName In dlg.FileNames
おっと、うっかりしていました。strName 変数を宣言するのを忘れていたので、次のように宣言します。
Dim strName As String
次は、これらのファイルそれぞれを開き、各ファイルのデータを読み取る必要があります。Visual Basic では、次のように Using ブロックを使用してこれを行います。
Using sr As StreamReader = File.OpenText(strName)
Using ブロックは、VBScript には存在しないものなので、VBScript を使用しているスクリプト作成者にとっては馴染みがないものでしょう。システム リソースを管理するには、VBScript よりも Visual Basic の方が少し優れています (わかりました。訂正します。多くの場合、はるかに優れています)。Using ステートメントの特徴は、ブロックを抜けるときにシステム リソースが確実に解放されることです。ここでは、ファイルの内容を保持し続けたり、大きなメモリ ブロックを使用し続けたりしないようにしているだけです。
これは少し複雑なことに思えるかもしれませんが、Set ステートメントと同じように考えてみてください。新しいオブジェクト (この場合は StreamReader オブジェクト) のインスタンスを作成して、それに File.OpenText メソッドから返されたテキストのストリームを割り当てているだけです。開くファイル (現在ループ処理中の FileNames コレクションに含まれるファイル) の名前を OpenText メソッドに渡しています。
こうして、StreamReader 型の sr 変数にファイルの内容が格納されます。今度は、次のような別の変数が必要です。
Dim strLine As String
この変数は、次のように、先ほど開いたテキスト ファイルの最初の行を格納するのに使用します。
strLine = sr.ReadLine()
StreamReader オブジェクトで ReadLine メソッドを呼び出して、ファイルの最初の行を読み取ります (StreamReader オブジェクトにはファイルの内容が格納されています)。このテキスト行を strLine 変数に格納します。
続いて、次のように ListBox オブジェクトで Add メソッドを呼び出して、この行をリスト ボックスに追加します。
ListBox1.Items.Add(strLine)
この例では、必要なのはファイルの最初の行だけなので (テキスト ファイルのテキスト全体を保持し続ける必要はもうないので)、次のように StreamReader オブジェクトを閉じて、Using ブロックを終了します。
sr.Close()
End Using
その後、ループの先頭に戻り、[ファイルを開く] ダイアログ ボックスで選択された次のファイルを処理します。この処理は、選択されたすべてのファイルから先頭行を読み取り、読み取った行をリスト ボックスに追加するまで繰り返します。完成したコードは、図 4 のようになります。
図 4 完成した ReadFiles コード
Imports System
Imports System.IO

Public Class Form1

  Private Sub Button1_Click _
   (ByVal sender As System.Object, _
    ByVal e As System.EventArgs) _
   Handles Button1.Click
    Dim dlg As Windows.Forms.OpenFileDialog
    Dim strName As String

    dlg = New OpenFileDialog()

    dlg.Multiselect = True
    dlg.InitialDirectory = "c:\scripts"
    dlg.Filter = "txt files (*.txt)|" & _
      "*.txt|All files (*.*)|*.*"

    If dlg.ShowDialog() = _
     Windows.Forms.DialogResult.OK Then
      For Each strName In dlg.FileNames
        Using sr As StreamReader = _
         File.OpenText(strName)
          Dim strLine As String
          strLine = sr.ReadLine()
          ListBox1.Items.Add(strLine)
          sr.Close()
        End Using
      Next
    End If
  End Sub
End Class
アプリケーションを作成するのはスクリプトを作成するのと比べてそれほど難しいことではないとお伝えしましたが、言ったとおりですよね。
F5 キーを押すと (または、デバッグ ツール バーの [デバッグ開始] ボタンをクリックすると)、作成したアプリケーションをテストできます。フォームのボタンをクリックし、[ファイルを開く] ダイアログ ボックスで 1 つ以上のファイルを選択すると、その結果は図 5 のようになります。
図 5 選択されたファイルそれぞれの最初の行がリスト ボックスに表示されているようす
作成したアプリケーションが問題なく動作している場合は、[ビルド] メニューの [ReadFiles のビルド] (ReadFiles の部分にはプロジェクト名が入ります) をクリックします。すると、ReadFiles.exe という名前の .exe ファイルが作成されます。この .exe ファイルは、その他のアプリケーションと同様に実行できるもので、ユーザーに配布できます。
ここで紹介した方法は、[ファイルを開く] ダイアログ ボックスを使用するための "早い" ルートには思えなかったかもしれませんが、Windows Vista ではスクリプトを記述して [ファイルを開く] ダイアログ ボックスを表示できないことを考慮すると、簡単なアプリケーションを作成することはたいした代償ではないでしょう。高速道路 (freeway) で実際にどこかに到達するためにはお金を払わなくてはならないのと同様で、少し面倒かもしれませんが、最終的には目的地に到達することができます。
このようなことに Visual Basic を使用するメリットには、VBScript よりも強力で、優れたユーザー インターフェイスを備えたアプリケーションを簡単に作成できるツールを皆さんが使い始めたという点もあります。これは非常に大きな特典です。また、システム管理者にとっても、Visual Basic の用途は他にもたくさんあります。
それに、新しい有料車線を使用するために運転の仕方を学習し直す必要はなく、自分より前に並んでいる車が実際に動いていることに慣れればよいだけです。同様に、VBScript の知識がある場合は、Visual Basic を使用するためにまったく新しい言語をゼロから学習する必要はなく、はるかに多くのことを実行できることに慣れればよいだけです。
Dr. Scripto のスクリプト パズル
パズルを解く能力だけでなく、スクリプト作成スキルもテストする月に 1 度の課題です。

2008 年 8 月 : スクリプト アルファベット
今月号のパズルでは、空白のマス目に A から Z までのいずれかの文字を当てはめて、スクリプトになんらかの関係がある単語を作成します。それぞれの文字 (A から Z まで) を使用できるのは 1 回だけで、これらの文字はアルファベット順に並ぶわけではありません。当てはめる文字が単語の先頭の文字になる場合もあれば、末尾や中間の文字になる場合もあります。たとえば、最初の行に C を当てはめると、SCRIPT という単語が出来上がります。

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


デスクトップ ファイル Windows 展開サービス入門
Wes Miller

目次
Windows Server 2003 の WDS
Windows Server 2008 の WDS
バージョンを選択する
考慮事項
WDS の使用を開始する
イメージをキャプチャする
キャプチャ入門
イメージの移行
無人インストール
先月のコラムでは、マイクロソフトによって提供されている PXE (Pre-Boot eXecution Environment) ベースの展開ツールの歴史を紹介しました。今月は、Windows 展開サービス (WDS) について詳しく説明します。具体的には、Windows Server 2003 用にリリースされたバージョンと、Windows Server 2008 に付属している更新されたバージョンについて
説明し、その後実際に WDS を使用してみます。
WDS は、リモート インストール サービス (RIS) に変更が加えられたサービスと考えていただくのが一番よいでしょう。いくつかの主要なコンポーネントは、どちらのサービスでも使用されます。実際に、Windows Server® 2003 に付属している WDS のレガシ モードでは、RIS とまったく同じ機能が提供されます。ネイティブ モードまたは 50% の混在モードで WDS を実行する場合は、新しいインフラストラクチャが使用されます。

Windows Server 2003 の WDS
WDS は、Windows Vista® と同時にリリースされました。この措置が必要になった理由は、Windows Vista のセットアップが Windows® Imaging Format (WIM) アーキテクチャを使用して完全に再設計されたことによって、RIS で Windows Vista を (最終的には Windows Server 2008 も) 展開できなくなったためです。その後 WDS は、Windows Server 2003 SP1 を実行するユーザー向けの OOB (Out-of-Band) ダウンロードとして入手できるようになりました。Windows Server 2003 SP2 では、RIS が完全に WDS に置き換わりました。
Windows Server 2003 の WDS には完全な下位互換性があるので、Windows Server 2003 SP2 システムに WDS をインストールするときに、ネイティブ モードに移行する必要はありません。レガシ モード (RIS サーバーと同じ機能が提供されます) または混在モードで実行を継続できるので、WDS または RIS のいずれかを初期化できます。
ネイティブ モードまたは半分がネイティブ モードの混在モードで WDS を実行すると、Windows Vista と Windows Server 2008 を展開できるだけでなく、いくつかの追加機能も利用できます。WDS では、Windows カーネル モードのセットアップ エンジンや、先月のコラム (technet.microsoft.com/magazine/cc645015) で説明した従来の主要なセットアップ エンジンを使用せず、Windows PE をブートストラップ プレインストール環境として使用します。また、RISetup や RIPrep ベースのインストールを使用せず、WIM ベースのイメージを展開します。これによって、展開の速度、容易さ、および信頼性を向上させることができます。
また、Windows PE では Windows の完全インストールを実行する場合と同じ文字セットを表示できるので、米国規格協会 (ANSI) によって定義された文字を使用する必要があることなど、先月説明した多くの制約が取り払われます。
さらに WDS では、RIS にはないいくつかのツールが導入されています。たとえば、管理に役立つ Microsoft® 管理コンソール (MMC) スナップインや、RIS よりはるかに優れた構成機能を提供する非常に包括的なコマンド ライン構成ツールを使用できます。
レガシ モードと混在モードの両方で RISetup や RIPrep ベースの Windows イメージを展開できますが、1 つ覚えておかなければならないことがあります。従来、RIS では単一インスタンス記憶域 (SIS) というコンポーネントを使用して、ディスク上のイメージ記憶域を最適化していました。SIS は後から Windows Storage Server 2003 の一部として提供され、このコンポーネントでは Groveler というサービスが使用されました。これは、同一のファイルを検索するために RIS (および WDS) サーバーのバックグラウンドで実行されるサービスです。いずれかのファイルのサイズとハッシュが一致すると、専用の SIS Common Store フォルダにそのファイルのコピーが保存され、検出された元のバージョンへのハードリンクが作成されます。
SIS は、ストレージの容量を大幅に節約するだけでなく、プロセッサの使用率への影響を最小限に抑えるように設計されています。SIS は、最初は RIS で使用され、後に Windows Server プラットフォームで幅広く利用されるようになった優れた概念です。ただし、新しい WDS では SIS が使用されなくなりました。
Windows Server 2003 の WDS をネイティブ モード (Windows Server 2008 の場合は任意のモード) で実行すると、セットアップに WIM イメージが使用されます。このため、WDS では独自の圧縮形式と、さらに重要なことには独自の単一インスタンス ファイル記憶域モデルが提供され、SIS はまったく使用されません。イメージ ストアによって、RIS で使用されていた記憶域モデルが WDS 用の新しい WIM ベースのデザインに置き換わります。SIS の詳細については、go.microsoft.com/fwlink/?LinkId=120302 を参照してください。

Windows Server 2008 の WDS
Windows Server 2008 では、WDS が Windows Server 2003 で提供される機能のスーパーセットとサブセットの両方の役割を果たすようになりました。また、スタンドアロン モードのトランスポート サーバーで、マルチキャスト通信を使用してイメージを展開できるようになりました。トランスポート サーバーは、優れたパフォーマンス、拡張ファームウェア インターフェイス (EFI) ベースの x64 システムのサポート、および評価指標に基づいた強力なインストール レポート機能を提供する、新しい簡易ファイル転送プロトコル (TFTP) サーバーです。これらについては、来月のコラムで説明します。
Windows Server 2008 の WDS では、Windows Server 2003 で提供されていた機能の 1 つが廃止されました。それは、従来のセットアップのサポートです。このため、RISetup イメージや RIPrep イメージを展開したり、従来の RIS OSChooser を使用してセットアップを開始したりできなくなりました。

バージョンを選択する
Windows Server 2008 のリリース以降、どのバージョンの WDS を使用するべきかという質問を以前よりも頻繁に受けるようになりました。この答えは、Windows Vista より前のバージョンの Windows を展開しているかどうか、および RISetup や RIPrep ベースのイメージを使用したセットアップから完全な WIM ベースのセットアップに移行する準備ができているかどうかによって異なります。
Windows Server 2008 の WDS でも、Windows 2000 以降のバージョンであれば、WIM イメージを使用して展開できます。この展開は、マルチキャストを使用して行います。そのため、現在 RIS から WDS への移行中で、Windows Server 2008 をインフラストラクチャで使用することを検討しており、さらに RIS ベースのイメージから WDS ベースのイメージに移行する意思がある場合は、Windows Server 2008 の WDS に移行することをお勧めします。
また、Windows Server 2003 システム上で RIS から WDS に移行 (実質的には SP2 をインストールすれば完了します) した後、WDS ベースのイメージに移行し、それから Windows Server 2008 の WDS にアップグレードすることもできます。
ただし、この方法はお勧めできません。Windows Server 2008 より前の多くのバージョンと同様、インプレース アップグレードを実行するのではなく、別のバージョンの Windows Server に移行することをお勧めします。
既に説明したように、インフラストラクチャで Windows Server 2008 の x64 バージョンを使用すると、Windows Server 2003 の x64 バージョンを使用する場合よりもメリットがあります。 Windows Server 2008 の x64 バージョンに移行する場合は、Windows Server 2003 サーバーから Windows Server 2008 サーバーへの移行を通じて WDS を移行する方が、インプレース アップグレードよりも簡単かつ確実です。

考慮事項
ここでは、WDS の展開に取り組むときに考慮する必要がある要件をいくつか示します。これらの多くは RIS の展開にも共通しており、WDS の展開で追加された要件ではありませんが、1 台の WDS サーバーを構築する場合でも、インフラストラクチャ全体を構築する場合でも、これらの要件を十分に考慮する必要があります。
特権 WDS サーバーを管理するときは、主に 2 つのことを考慮する必要があります。まず、RIS の場合と同様に、Active Directory® で WDS サーバーを承認する必要があります。これを行うには、フォレストのルート ドメインのドメイン管理者またはエンタープライズ管理者であるか、適切な特権を委任されている必要があります。また、WDS サーバーを管理するには、ドメイン管理者であり、当然 WDS サーバー自体の管理者であることも必要です。
仮想化 Microsoft Virtual PC または Virtual Server で仮想化された Windows Server 2003 または Windows Server 2008 のインスタンス上で WDS を実行し、同じコンピュータ上の Virtual PC または Virtual Server で仮想化されたクライアント PC と通信する場合、PXE ブートの開始時に競合状態が発生し、処理速度が大幅に低下したり、クライアントが停止したりする可能性があります。特にクライアントとサーバーが 1 つのシステムでホストされている場合は、クライアントとサーバーの両方ではなく、いずれかを仮想化することをお勧めします。個人的には、仮想化された WDS サーバーを運用環境で使用しない方がよいと考えています。その主な理由を次に示します。
その他のサービス WDS は、RIS と同様、運用環境で実行されるその他のサービスと必ずしも適切に連携するわけではありません。特に、Microsoft Exchange Server、Systems Management Server (SMS)、および System Center Configuration Manager (SCCM) を実行している運用システム上で RIS や WDS を実行すると問題が発生するようです。
一般に、数台のクライアントが存在する運用環境で WDS サーバーを使用する場合は、そのサーバーに WDS 以外の役割を割り当てないことをお勧めします。これは WDS に限ったことではなく、Windows サーバー製品の役割を混在させる必要があるかどうかを慎重に検討し、展開前にそれらの役割をテストする必要があります。
低速または待ち時間の長いリンク RIS と同様、WDS は低帯域幅接続や、サテライト リンクなどの待ち時間の長い接続で使用することを前提に設計されていません。PXE のハンドシェイクでは問題が発生する場合があり、イメージをダウンロードすることは可能ですが、時間がかかることがほとんどです。

WDS の使用を開始する
WDS の詳細情報

  • Windows Server 2003 の WDS に関するステップ バイ ステップ ガイド
  • Windows 展開サービスに関するステップ バイ ステップ ガイド (Windows Server 2008)
  • Windows Server 2003 で WDS の更新を展開および管理する
  • Windows Server 2008 の Windows 展開サービスに関するドキュメント
  • テクニカル リファレンス : Windows 展開サービス (Windows Server 2008)
まず、Windows Server 2003 の WDS を使用するか、Windows Server 2008 の WDS を使用するかを決定する必要があります。Windows Server 2003 を使用する場合は、SP1 ではなく最初から SP2 を使用することをお勧めします。Windows Server 2003 SP2 では、以前は Windows 自動インストール キット (WAIK) の一部としてダウンロード提供されていた WDS が、(RIS に代わって) オプション コンポーネントとして既定で提供されます。
どちらのバージョンの Windows Server を使用する場合でも、サーバー システムを構築する必要があります。少なくとも 100 Mbps 以上の速度に対応した高品質のネットワーク インターフェイス カード (NIC) を使用する必要があります。NIC のチーミングは使用しないようにしてください。これが原因で、WDS の PXE インフラストラクチャで問題が発生する場合があります。Windows Server 2008 を使用する場合は、Windows Server 2008 の Server Core または完全インストールのいずれかに WDS をインストールできます。
Windows Server 2003 では、WDS が (以前の RIS と同様) オプション コンポーネントとして提供されます。WDS は、OS のセットアップ時にインストールするか、後から [プログラムの追加と削除] の [Windows コンポーネントの追加と削除] を実行して (またはコマンド ラインで sysocmgr.exe を実行して) インストールできます。Windows Server 2008 では WDS が役割として提供され、初期構成ウィザードやサーバーマネージャを使用してインストールする (どちらの場合も [役割の追加]、[次へ] を順にクリックし、[Windows 展開サービス] チェック ボックスをオンにします) か、コマンド ラインで「ServerManagerCmd –install WDS」を実行してインストールできます。
WDS をインストールしたら、このサービスを構成する必要があります。まず、[スタート] メニューの [管理ツール] をポイントし、[Windows 展開サービス] をクリックします。MMC が起動したらサーバーを右クリックし、[サーバーの構成] をクリックして構成ウィザードを起動します。
Windows Server 2003 に WDS をインストールし、既存の RIS サーバーをアップグレードする場合は、既存の RemoteInstall ディレクトリを指定し、既存のインスタンスを混在モードにアップグレードできるようにする必要があります。この場合、RemoteInstall ディレクトリがシステム パーティションに含まれていないことを確認する必要があります。このディレクトリがシステム パーティションに含まれていると、パフォーマンスに影響を与える可能性があります。
図 1 は、Windows Server 2008 で構成ウィザードを完了する前の WDS コンソールを示しています。図 2 は、Windows Server 2008 で提供される WDS 構成ウィザードのウェルカム ページを示しています。図 3 は、WDS 構成ウィザードで PXE を構成するページを示しています。このページでは、サーバーがクライアントに応答しない (初回構築時に役立ちます) か、(Active Directory でステージング済みの) 既知のクライアント コンピュータのみに応答するか、すべてのクライアントに応答するか (および必要に応じてサーバーがすべての不明なクライアントを保留して、管理者がその後の処理を選択できるようにするか) を指定できます。
図 1 インストール済みであるが未構成の WDS
図 2 WDS 構成ウィザード
図 3 PXE サーバーに適用する応答ポリシーの選択
図 4 は、Windows Server 2008 で構成が完了した WDS サーバー (イメージはまだインストールされていません) のプロパティ ページを示しています。使用中のサーバーが既に動的ホスト構成プロトコル (DHCP) サーバーとして構成されている場合は、DHCP オプション 60 を PXEClient に設定し、ポート 67 でリッスンしないように WDS を構成します。これにより、WDS サーバーによる PXE の検出プロセスで、いくつかの処理を省略できます (これについては先月のコラムで説明しました)。
図 4 Windows Server 2008 で構成を完了した WDS サーバー
ウィザードを完了したら、新しいイメージを追加できます。混在モードまたはネイティブ モードで実行する WDS サーバーには、以下の 2 種類のイメージを追加できます。
  • ブート イメージ : Windows PE 2.x を含むイメージ。通常は、Windows Server 2008 または Windows Vista SP1 のインストール DVD からコピーします。マルチキャストを使用する場合は、(Windows Vista または古いオペレーティング システムを展開する場合でも) ブート イメージとして Windows Server 2008 の \Sources\Boot.wim ファイルを使用する必要があることに注意してください。一般に、ブート イメージは Windows PE、Windows Setup.exe、およびその他の依存ファイルで構成されます。
  • インストール イメージ : Windows OS イメージで構成されるイメージ。通常は、Windows Vista または Windows Server 2008 の \Sources\Install.wim ファイルです。
既定のブート イメージと既定のインストール イメージを追加する手順はほぼ同じです。どちらのプロセスでも、まずイメージの種類を右クリックし、その種類のイメージを追加することを選択します。
インストール イメージの場合は、イメージ グループの名前を指定する必要があります (Windows DVD に格納されている既定の WIM に OS の種類が複数含まれているため)。その後、追加する適切な boot.wim または install.wim を参照し、[開く] をクリックします。インストール イメージの場合は、WDS サーバーに追加しないボリューム イメージ (OS イメージ) のチェック ボックスをすべてオフにします。最後に、これらの既定のイメージを使用して、クライアントの PXE インストールを実行します。

イメージをキャプチャする
カスタムの OS イメージを作成するには、キャプチャ イメージを作成する必要があります。キャプチャ イメージとは、Windows システムを WIM イメージとしてキャプチャできるように設計された Windows PE イメージです。キャプチャ イメージを作成するには、前の手順でインストールした boot.wim イメージを使用する方法が最も簡単です。
目的のイメージを右クリックし、[キャプチャ ブート イメージの作成] をクリックします。イメージの名前と説明、およびキャプチャ イメージの展開時にネットワークの接続に関する問題が発生した場合に備えて .wim ファイルのローカル コピーを保存する場所を指定します。その後はウィザードの指示に従ってイメージを作成し、最後に [完了] をクリックします。
次に、WDS MMC で [ブート イメージ] フォルダを右クリックし、[ブート イメージの追加] をクリックします。前の手順と同様、ウィザードの指示に従ってイメージを作成します。完了したら、Windows インストール イメージをキャプチャできるようになります。

キャプチャ入門
当然ながら、オペレーティング システムのイメージをキャプチャする前に、Windows をインストールし、目的のアプリケーション、カスタマイズ、および更新をすべて含める必要があります。次に、そのシステム上で Sysprep を実行します。Sysprep を使用して準備されたシステムからは、Windows インストール イメージのみをキャプチャできます。新しいイメージを保存するローカルの有効な場所 (イメージの破損を回避するため) と、*.wim ファイル拡張子を指定する必要があります。
システムを構成し、正しいバージョンの sysprep.exe をシステムにコピーしたら、次の手順を実行します。
  1. 参照コンピュータのコマンド プロンプトで、sysprep.exe が格納されているディレクトリに移動します。
  2. Sysprep を起動します (sysprep.exe をダブルクリックし、手動でオプションを指定して起動することもできます)。Windows Vista または Windows Server 2008 を実行しているコンピュータでは、「sysprep /oobe /generalize /reboot」というコマンドを実行します。以前のバージョンの Windows を実行しているコンピュータでは、「sysprep -mini –reseal –reboot」というコマンドを実行します。
  3. コンピュータが再起動するときに、PXE ブートを実行します (このプロセスは、使用しているクライアント システムによって異なる場合があります)。
  4. ブート メニューで WDS キャプチャ イメージを選択し、[次へ] をクリックします。
  5. イメージ用のドライブ、およびイメージの名前と説明を選択します。
  6. 既に説明したように、Sysprep が実行されたシステムのみが表示されます。これは仕様なので、回避する方法はありません。
  7. [参照] をクリックし、キャプチャしたインストール イメージを格納するローカル フォルダを参照します。割り当て済みのネットワーク ドライブを選択することもできます。
  8. [WDS サーバーへイメージをアップロードする] チェック ボックスをオンにします。
  9. WDS サーバーの名前を入力し、[接続] をクリックします。
  10. [イメージ グループ] ボックスで、イメージの格納先として使用するイメージ グループを選択し、[完了] をクリックします。
これで、このイメージを WDS サーバーから展開できるようになります。RIS に馴染みのある方はお気付きかもしれませんが、この手順ではオフラインの Windows イメージをキャプチャしました。WDS では、キャプチャするシステムをオフラインにする必要があります。
RIS の RIPrep では、オンラインのシステムをキャプチャできました (と言うよりも、オンラインのシステムをキャプチャする必要がありました) が、そのプロセスは非常に脆弱でした。WDS のキャプチャ プロセスの方が簡単で、間違いなく堅牢であることを実感していただけると思います。

イメージの移行
今まで常に RIS を使用してきた方は、いくつかイメージをお持ちだと思いますが、それらの RISetup ベースのイメージ (スクリプト化されたインストール) を使用することはできなくなります。ただし、RIPrep イメージを WDS WIM ベースのイメージに移行できます。さらに、WDS では WDSUtil を使用してイメージを移行することもできます (この方法については、来月のコラムで詳しく説明します)。
このプロセスは、作成に多くの時間を費やした、どうしても必要なイメージに対してのみ実行することをお勧めします。このプロセスは非常に便利ですが、変換中にいくつかのエラーが発生するという報告が寄せられています。その場合、通常は最初からイメージを作成し直す必要があります。

無人インストール
ここまでの手順で作成したイメージは、手動でインストールできます。インストール プロセスのさらに多くの部分、または全体を自動化するには、2 つの無人セットアップ ファイルを使用する必要があります。まず、WDS のセットアップ プロセスを自動化する応答ファイル (WDS サーバーの \RemoteInstall\WDSClientUnattend ディレクトリに格納されている unattend.xml) が必要になります。そして 2 つ目のファイルは、実際のイメージ無人セットアップ ファイルです。Windows Vista 以降では、これは unattend.xml ファイルのことを指します。Windows Vista より前のバージョンの Windows イメージの場合は、$OEM$ ディレクトリ構造または各イメージのディレクトリの \Unattend に格納されている sysprep.inf ファイルのことを指します。このファイルは、WDS のセットアップ プロセスが完了した後、実際の Windows のインストールを自動化するために使用されます。
WDS の無人ファイルを作成するには、WAIK を使用して WDS 用の unattend.xml ファイルを作成します。このファイルを RemoteInstall ディレクトリまたはサブディレクトリにコピーします。無人ファイルを使用するインストール イメージを右クリックし、[プロパティ] をクリックします。[クライアント] タブで [無人インストールを有効にする] チェック ボックスをオンにし、前述の unattend.xml ファイルを指定します。
Windows Vista より前のバージョンの Windows イメージに使用する無人セットアップ ファイルを作成するには、イメージの $OEM$ ディレクトリに sysprep.inf ファイルをコピーします (D:\RemoteInstall\Images\Windows XP\SP2\$OEM$\$1\sysprep\sysprep.inf など)。Windows Vista イメージの場合は、関連付けるイメージを指定し、[プロパティ] をクリックします。次に、[全般] タブで [イメージを無人モードでインストール可能にする] をクリックします。その後、インストール時に使用する unattend.xml ファイルを指定します。
WDS に関する説明は、これで半分ほど終わりました。今月のコラムでは、WDS の使用方法について説明しました。来月は、WDSUtil、イメージ ストア、およびマルチキャストについてさらに詳しく説明します。そして、WDS に基づいたカスタム展開ソリューションを構築する方法と、カスタム ソリューションの構築が必要な理由について詳しく説明し、このシリーズを完結します。それまでに、このコラムの補足記事「WDS の詳細情報」に記載されている資料に目を通しておいてください。

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


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

目次
擬似的多要素ログオン プロセス
ブラウザのアドインの問題
認証システムは決して変更されてはならない
セキュリティ レベルの低いパスワードにダウングレードする
擬似的多要素ログオンを迂回する
侵害されたパスワードに関する問題
いくつかのメリット
見掛けだけのごまかしでユーザーを誤った方向に導く
開くべきか、開かざるべきか、それが問題だ
安全な通信を提供する
プライバシーについて
3 回シリーズの第 2 回目へようこそ。このシリーズでは、セキュリティの問題に関して、IT 業界がユーザーを助けるのではなく、むしろ混乱させている状況について説明します。2008 年 7 月号の TechNet Magazine では、実行不可能かつ間違ったアドバイスと、紛らわしいログオン手順について説明しました (第 1 部をまだお読みでない方は、
technet.microsoft.com/magazine/cc626076 をご覧ください)。きわめて一般的でありながら間違ったセキュリティ上のアドバイスと複雑なログオン手順が、どのようにユーザーを混乱させ、個人情報を保護するためのユーザーの努力を台無しにしているかについて論じました。
今月の記事では、ユーザーのセキュリティに関する実例を使用して、この議論を続けます。来月号の TechNet Magazine に掲載予定のこのシリーズの最終回では、世界中のセキュリティ プロフェッショナルを召集します。

擬似的多要素ログオン プロセス
2005 年 10 月に、FFIEC (米国連邦金融機関検査協議会) がガイドライン『Authentication in an Internet Banking Environment』(インターネット バンキング環境における認証) を発表しました (www.ffiec.gov/press/pr101205.htm 参照)。履行までの期限がわずか 14 か月であったため、米国内の金融機関はすぐに、この新しいガイドラインを満たすための方法を大急ぎで模索し始めました。
しかし、ほとんどの金融機関は、この期限に間に合いませんでした。そうした金融機関も、最終的にはガイドラインの順守を実現しましたが、その多くは、ガイドラインを満たすこと以外には何の意味もない手段で実現したにすぎませんでした。つまり、ユーザーのセキュリティを強化することにつながらない措置を講じた ("セキュリティ ショー" を演じた) のです。最も注目される役に立たないソリューション例の 1 つは、実際には多要素ではない多要素認証を実現しようとするソリューションです。
たとえば、ユーザーがパスワードを入力するときの入力リズムを測定するテクノロジを考えてください。このテクノロジを Web サイトで使用するソリューションでは、従来のログオン ダイアログ ボックスとまったく同じ外観のログオン ダイアログ ボックスが表示されます。ただし、このダイアログ ボックスは Adobe Flash オブジェクトであるという点が異なります。
Flash オブジェクトでは、キーが押されている時間やキーを押す間隔などの特徴を含む、ユーザーの入力リズムが記録されます。このデータは、パスワードと共に Web サイトに送信され、保存されている値と比較されます。入力リズムのデータと保存されているデータの差異が一定範囲内にあり、パスワードが一致すれば、ログオンが許可されます。これは、クライアント側でサード パーティ製ハードウェアを搭載する必要なく、擬似バイオメトリクス認証方法をサイトで使用できるという概念に基づいたソリューションです。
ここでは、これを擬似的多要素認証と呼びます。擬似的多要素認証は、真の多要素認証ではありません。というのは、真の多要素認証では、次の 2 つ以上の要素が評価されるからです。
  • ユーザーの所有物 (スマート カードなど)
  • ユーザーの知識 (パスワードなど)
  • ユーザーの特徴 (指紋など)
擬似的多要素認証では、実際に複数の要素を認証プロセスに含めるのではなく、たった 1 つの要素 (つまり、パスワード) から複数の条件を読み取ります。そして、読み取った追加の条件を使用して、ユーザーの特徴を推論します。
擬似的多要素認証に使用されるテクノロジには、多くの欠点があります。そうしたすべての欠点により、採用したテクノロジは、解決するはずのセキュリティ上の問題を解決できないという事態を引き起こしています。

ブラウザのアドインの問題
擬似的多要素認証システムでは、必要となる高度なクライアント側の処理を提供するのにブラウザのアドインを使用します。すべてのソフトウェアにはバグが付き物で、そのようなバグの中には脆弱性の原因となるものがあります。ソフトウェアの更新が困難で、更新がインストール済みかどうかをユーザーが把握していない場合、そうした脆弱性は深刻な問題となります。
ブラウザのアドインには、この両方の欠点があり、更新が困難で、インストールされているバージョンが最新かどうかに関する十分な情報がユーザーに提供されません。そのため、ユーザーは、このような欠点がなければ公開する必要がないソフトウェアをインターネットに公開しなければなりません。
アドインを最新の状態に保つために、アドインの Web サイトに定期的にアクセスしてアドインを更新しなければならないこともあります。言うまでもないことですが、ほとんどのユーザーが、このようなことを実行する可能性はきわめて低いでしょう。セキュリティ機能を提供するためだけにエンド ユーザーが関連のないソフトウェアをインターネットに公開する必要があるシステムは、明らかに検討が必要です。

認証システムは決して変更されてはならない
"ユーザーの特徴" という要素には、他の 2 つの要素にはない欠点とも言える特性があります。パスワード (ユーザーの知識) は変更可能で、セキュリティ トークン (ユーザーの所有物) は新たに製造可能ですが、使用できるバイオメトリクス認証システムの数はかなり限られています。たとえば、指紋であれば、通常、1 人のユーザーにつき 10 種類しかありません。もし事故でいずれかの指を失ってしまえば、通常それを元に戻すことはできません。
では、これが、擬似的多要素ログオンの例にどのように当てはまるかを見てみましょう。別の要素の一部として収集された指標を、簡単に置き換えたり変更したりすることはできません。確かに、パスワードが変更されればユーザーの入力の仕方も変わりますが、ユーザーがキーボードのキーを押す大まかな方法は変わりません。この手法で使用されるのは、まさにこの点です。しかし、この指標が侵害された場合、指標を合成することは不可能ではありません。改ざんとまではいかなくても、攻撃者はこれらの指標をキャプチャして、再現することができます。

セキュリティ レベルの低いパスワードにダウングレードする
パスワードは、長いものを使用し、頻繁に変更することをお勧めします。また、このシリーズの第 1 部で説明したように、(一部のアドバイスとは逆に) パスワードを安全な方法で記録しておくこともお勧めします。ただし、この方法は、手作業によるパスワードの入力には向いていません。長いパスワードは入力しづらいので、記録されたパスワードは、コピーして貼り付けられるときにより役立ちます。多数のパスワードを記録しておく最良の方法の 1 つは、Password Safe (sourceforge.net/projects/passwordsafe) などのソフトウェア ユーティリティを使用することです。このようなツールを使用すると、完全にランダムなパスワードを生成し、生成したパスワードを暗号化された形式で保存して、ログオン ダイアログ ボックスに直接貼り付けることができます。つまり、このようなツールを使用すれば、パスワードを把握する必要さえありません。
しかし、問題点もあります。パスワードを入力するときの入力リズムは、ユーザーがパスワードを入力しない限り測定できません。そして、入力リズムを測定するオブジェクトにパスワードを入力する必要がある場合、このパスワードを管理する手法は機能しなくなります。15 文字の完全にランダムなパスワードを正しく入力することは、簡単な作業ではありません。そのため、多くの場合、このようなシステムを使用する際には、ユーザーは単純なパスワードを使用する傾向があります。しかし、15 文字の完全にランダムなパスワードは、単独で使用した場合も、短いパスワードと擬似的多要素認証システムを併用した場合よりもはるかに安全です。
事実上、擬似的多要素認証を単独で実装するということは、ユーザーがセキュリティ レベルの低いパスワードの使用を余儀なくされるということになります。この後すぐに説明しますが、残念ながら、適切なパスワード管理手法を使用するユーザーに対応することで、擬似的多要素認証システムで提供できるほぼすべての価値が無用となります。

擬似的多要素ログオンを迂回する
サイトで擬似的多要素認証を実装している場合でも、擬似的多要素システムを迂回する方法をサポートする必要があります。というのも、ほとんどのサイトでは、サイトにアクセスできるようにするために、すべてのユーザーに "第四者" テクノロジのインストールを求めることはできないからです。一部のユーザー (たとえば、一部の TechNet Magazine 著者) は、このようなソフトウェアのインストールを常に拒否するでしょう。
また、入力リズムはさまざまな理由で変わる可能性があるため、サイトではその変化に対応する必要があります。たとえば、ユーザーが手首をねんざして、入力リズムが一時的に変化しているとします。その際、サイトで入力リズムが分析された結果、第三者がそのユーザーの資格情報を使用してログインを試みていると見なされたら、そのユーザーはどのようにしてサイトにアクセスしたらよいでしょうか。恒久的な負傷であれば、ユーザーが保存されているリズムの値を再設定することで、この問題に対応できます。しかし、一時的な負傷の場合、おそらくユーザーは、すぐに元の入力リズムに戻ると考えて、保存されている値を再設定することは望まないでしょう。
さらに、すべてのユーザーが擬似的多要素認証システムを使用できるわけではありません。たとえば、音声認識インターフェイスを使用してコンピュータを操作している身体に障害のあるユーザーは、プログラムによる入力が禁止されているかどうかによっては、ダイアログ ボックスに情報を入力できない場合があります。その場合、法律の規定によって、障害のあるユーザーに対応する代替システムが必要となる可能性があります。
このすべてのシナリオに対応する最も簡単でわかりやすい方法は、標準のパスワード ベースの認証もサポートすることです。

侵害されたパスワードに関する問題
擬似的多要素認証システムは、パスワード ベース認証に関連するさまざまな問題を解決するとされています。しかし、このシステムでは、パスワードを侵害する深刻なあらゆる手段を完全に遮断することはできません。パスワード ベース認証を使用するシステムを侵害する主な手段には、次の 5 つがあります。ここで "侵害する" とは、攻撃者が別のユーザーのパスワードを取得して使用することを意味します。
  • パスワードの推測
  • キーストローク ロガー
  • フィッシング攻撃
  • ユーザーにたずねる
  • パスワードやそのハッシュを保存するシステムへの侵入
パスワードの推測は、攻撃者にとって、あまり一般的な攻撃方法ではなくなり、キーストローク ロガーとフィッシングによってすっかり影が薄くなっています。また、部分的にではありますが、パスワードの推測は、擬似的多要素認証によって軽減されています。擬似的多要素システムに侵入するには、攻撃者はパスワードだけでなく入力リズムを推測する必要があるため、従来のパスワードを推測する方法が擬似的多要素認証システムで機能する可能性は低いでしょう。入力リズムの指標を合成することは、理論的には可能ですが、通常はフィッシング攻撃やキーストローク ロガーで実際のデータをキャプチャできるため、合成の必要はほとんどありません。また、システムによって、標準のパスワードのみのログオン インターフェイスが提供される場合、攻撃者は単純にそのシステムを使用してパスワードを推測できます。
さらに、パスワードの推測による攻撃の大部分は、強力なパスワードによって阻止できます。強力なパスワードを使用するように (場合によりツールを使用して) ユーザーを指導できれば、擬似的多要素認証は必要ありません (一方、擬似的多要素認証システムで一般的に使用される簡単なパスワードは、パスワードの推測がより実行可能な攻撃方法となる手助けをしていると言えます)。したがって、ここでパスワードの推測による攻撃を軽減する対策として提供している情報が有効になるのは、パスワードのみのログオンがサポートされない場合に限ります。しかし、既に指摘したように、これはほぼ不可能です。つまり、ユーザーが擬似的多要素認証システムで脆弱なパスワードを使用すると、パスワードの推測が再び実行可能な攻撃方法になる場合があります。擬似的多要素認証は、セキュリティを強化するどころか弱めることになります。この問題には、さらなる調査が必要です。
擬似的多要素認証は、キーストローク ロガーの問題を解決することもできません。現在一般的に使用されているキーストローク ロガーで入力リズムをキャプチャするものは把握していませんが、そのようなキーストローク ロガーを設計できない理由はまったくありません。キーストローク ロガーは、キーボードとコンピュータ、またはキーストロークをキャプチャするソフトウェアとの間に介在するハードウェアです。どちらの場合も、ロガーは、擬似的多要素認証ソリューションで使用されるすべてのデータへのフル アクセスを持っています。
実際、認証ソリューションはユーザー モードで実行されますが、キーストローク ロガーはそれよりもはるか下位に位置するため、キーストローク ロガーはさらに多くのデータにアクセスできます。パスワードのキャプチャに使用される Web ベース オブジェクトとキーボードとの間に信頼済みパスがなければ、このような侵害を回避することはできません。擬似的多要素認証ソリューションの普及が進めば、そのようなキーストローク ロガーが作成されるのは、まず間違いないでしょう。
同様に、擬似的多要素認証では、フィッシング攻撃も解決できません。攻撃者は、偽のログオン画面だけでなく、Flash オブジェクトを併用してパスワードと入力リズムをキャプチャできます。
確かに、擬似的多要素認証は、攻撃者がユーザーのパスワードだけを提供する手法を使用している場合には役立ちます。たとえば、ユーザーからパスワードを取得する最も簡単な方法は、ユーザーにたずねることです。驚くことに、直接的であろうと電話やフィッシング メッセージを使用する場合であろうと、ユーザーにたずねるという方法は有効な手法であることは実証されています。
もちろん、ユーザーに入力リズムをたずねることの有効性は、はるかに低くなります。また、企業のパスワード データベースが侵害された場合、おそらく攻撃者が入手できるのはパスワードのみです。しかし、繰り返しになりますが、こうした攻撃が軽減されるのは、システムで標準のパスワードのみの認証を使用していない場合に限られます。
また、実際にパスワード データベース自体が侵害された場合、攻撃者はおそらく、単一 (または多く) の標準のユーザー アカウント パスワードを入手した場合に可能なレベルよりもはるかに深くまでシステムを侵害していると考えられます。したがって、パスワード データベースを入手した攻撃者による攻撃を軽減しようとすることは、あまり有効ではありません。

いくつかのメリット
公平に見て、(システムで標準のパスワードのみのログオン オプションが提供されないことを前提とすれば) 擬似的多要素認証で解決できる問題もいくつかあります。たとえば、擬似的多要素認証を使用すると、パスワードの共有を回避できます。ただし、これは、共同の銀行口座など、複数のユーザーがアカウントを共有することが適正なシステムでは障害となることがあります。
また、適切に設計された (Web サイト ログインではない) 対話型ログイン ダイアログ ボックスを使用すると、入力リズムが一致しなかった場合に別の認証手順を実行するようにユーザーに強制できます。これにより、機密性の高い環境でアカウントが侵害された場合のセキュリティを強化できます。

見掛けだけのごまかしでユーザーを誤った方向に導く
ユーザーを最も混乱させるのは、誤ったセキュリティ情報を提示することです。おそらく最も一般的なのは、図 1 のように、Web ページ上に南京錠のイメージを表示することです。このページでは、南京錠の横に Secure という単語まで表示しています。
図 1 厄介な南京錠アイコンの乱用例 (画像をクリックすると拡大表示されます)
おわかりのように、南京錠のイメージと Secure という単語を追加するだけでページのセキュリティを確保できるわけではありません。しかし、定評がありアクセスが多い Web サイトでさえ、これは不安になるほど一般的に行われています。そのため、多くのユーザーは、このような安全性の視覚的手掛かりを Web ページの本文中で探すことに慣れていて、これらの手掛かりが実際に意味を持つ場所であるアドレス バーを見ていません (この問題については、W3C Web Security Context Wiki のエントリ (w3.org/2006/WSC/wiki/PadlockIconMisuse) を参照してください)。
残念ながら、このような乱用には、他にも非常に多くの例が存在します。調査によると、証明書が一見して明らかに偽物である場合でさえ、ユーザーは悪意のある Web サイトを識別できません (詳細については、www.usablesecurity.org/papers/jackson.pdf を参照してください)。結局は、比較対象として使用できる本物がない場合でも偽物と本物を簡単に識別できる能力があるかどうかにかかっていると言えます。それにはスキルが必要です。ですが、Web ページ上の誤解を招くおそれがある見掛けだけの安全性のごまかしによって、ユーザーは誤った情報に引き寄せられてしまい、そのスキルの形成が妨げられます。
この問題の 1 種で特に気になる例を、図 2 に示しています。この場合、情報が表示されているページは、実際には安全ではありません。アドレス バーを見ると、使用しているプロトコルを示す http という文字列を確認できます。このサイトでは、非常に一般的な最適化の手法が使用されています。つまり、ログオン フォームを含むページが暗号化されるのではなく、フォームの送信のみが暗号化されています。このページに示されているように、"安全であること" が "暗号化されていること" と同等である見なす場合、ログオンは安全です。ただし (非常に重要なことに)、ユーザーは、資格情報が送信される前に送信先を確認することができません。サイトでは、フォームが送信される前にユーザーにサイトの正当性を証明する証明書が表示されません。これは、背後の人が自分のことを受け止めてくれることを前提として後ろに倒れる、信用ゲームのようなものです。フォームが送信されたときには、既に被害が発生している場合があります。
図 2 安全でないページの見掛けだけの安全性のごまかし (画像をクリックすると拡大表示されます)
HTTPS でセキュリティを強化するプロトコルである Secure Sockets Layer (SSL) は、2 つの重要な役割を果たします。1 つ目の役割は、サーバーの正当性をユーザーに証明することで、2 つ目の役割は、クライアントとサーバー間で使用されるセッションの暗号化キーをネゴシエートするための、簡単なメカニズムを提供することです。
フォームの送信だけが暗号化される場合、1 つ目の最も重要な目的は果たされません。この最適化の手法を使用しているサイトでは、キーをネゴシエートするためだけに SSL が使用されています。皮肉にも、それは単純に、標準のキーのネゴシエーション プロトコルを使用することで実行でき、それによって SSL を使用した場合のコストとオーバーヘッドを回避できます。
図 2 のようなサイトは、珍しいものではありません。多くのサイトでは、フォーム自体ではなく、フォームの送信だけに対して SSL の保護が提供されます。しかし、このサイトには、さらに気になる特徴があります。ブラウザのアドレス バーに「https://www.<site>.com」と入力すると (安全な https の表示に注目してください)、SSL を使用していないサイトにリダイレクトされます。サイトに資格情報を送信する前に証明書を調べようとしても、サイトでは証明書の表示が拒否されます。
すべてのサイトがそれほど悪いわけではありませんが、不適切なサイトは数多く存在します。米国の 2 大クレジット カード発行会社は、その一例です。実際、私が使用している 3 大クレジット カード会社のうち、ログオン フォームで証明書を提供しているのは、アメリカン エキスプレスだけです。また、アメリカン エキスプレスのサイトでは、HTTP 要求を HTTPS にリダイレクトしています。お見事です。
見掛けだけの無意味な安全性のごまかしと、ログオン フォームでの証明書の欠如に関する最後の見解を述べましょう。なぜサイトでこのようなことが横行しているのか、疑問に思う人もいるでしょうが、それは単純に経済的な理由です。証明書を表示するにはページを暗号化する必要があり、ページを暗号化すると処理オーバーヘッドが発生します。処理オーバーヘッドとは、同じ負荷の処理に、より多くのコンピュータが必要になることです。そして、コンピュータの台数が増えれば、コストも増えます。残念ながら、顧客のプライバシー保護と増益のどちらかを選択する場合、多くの組織は増益を選択します。

開くべきか、開かざるべきか、それが問題だ
私は先日、健康保険会社から驚くべき電子メール メッセージを受け取りました。ここ 10 年の間にコンピュータを使用したことのある人ならだれでも、要請していない電子メールの添付ファイルは決して開けるべきではないことを知っています。そこで、図 3 のようなメッセージを受け取ったときに、私がどれほど驚いたかを想像してみてください。
図 3 "安全な添付ファイル" を含む電子メール メッセージ (画像をクリックすると拡大表示されます)
どうやら私は、健康保険会社の Web サイトで質問をしていたようです (そして、このメッセージが到着したときには、そのことを忘れていました)。これは、その質問に対する会社からの返答でしたが、初めは巧妙なフィッシングかと思いました。これが正当なメッセージだとわかったとき、身の毛がよだつ思いをしました。
一番最初の手順は、添付ファイルをダブルクリックして、メッセージの暗号化解除を開始することでした。セキュリティ コミュニティと IT 管理者は、10 年間もの歳月を費やし、ユーザーに添付ファイルをダブルクリックしないように指導してきました。それにもかかわらず、添付ファイルをクリックするように求める企業があるというのです (しかも、この方法を使用しているのは、この保険会社だけではありません)。この場合、ユーザーはどのように対応するべきでしょうか。ユーザーが学ぶこと、または忘れるべきことは何でしょうか。
次に、Microsoft® Office Outlook® 2007 のプレビュー機能を使用して添付ファイルを表示しました。図 4 に示すように、Outlook では、このメッセージは攻撃である可能性があると見なされ、開かないように警告されました。
図 4 Outlook 2007 によって安全なドキュメントが悪意のあるドキュメントと見なされる (画像をクリックすると拡大表示されます)
健康保険会社が、世界で最も一般的な電子メール クライアントで使用されるごく基本的なセキュリティ チェックに反することは、皮肉であり、残念でもあります。この保険会社が、新しいセキュリティ ソリューションを Outlook でテストしていないことを考えれば、同社が個人情報を保護するために何かを行っているのかは疑わしいものです。さらにはっきり言えば、顧客のプライバシーが十分に保護されていないとして非難されないように、この会社では他にどのようなソリューションが実装されているのでしょうか。これは、金融機関が演じたセキュリティ ショーと同じです。この場合、ソリューションの主目的は非難の回避であり、実際に顧客を保護することではありません。
添付ファイルが実際には何なのかを見てみたところ、ActiveX® コントロール オブジェクトでした。添付ファイルの内容を確認するには、それを Internet Explorer® で開いてオブジェクトをインストールする必要がありました。表示されたのは、図 5 のような安心感を与えるための画面です。ご覧のとおり、デザイナは、メッセージを通常の封筒のように見せるためにあらゆる手段を講じており、信用できる封筒であることを主張するスタンプまで押されています。
図 5 Trusted というスタンプが押された封筒を表示する安全なドキュメント (画像をクリックすると拡大表示されます)
このようなテクノロジには、さまざまな理由で問題があります。まず、添付ファイルを開くという、ユーザー側で非常に不適切な操作が促進されます。また、実際のメッセージでは、常に確認なしで添付ファイルを開くようにシステムを構成するという非常に不適切なガイダンスが提供されます。電子メール自体では信用できると示されているのに Outlook では信用できない通知されるという、コンピュータの相反するメッセージにより、メッセージがかなり不審に見えます。そして、実際の添付ファイルには、本当に信用できることをユーザーに納得させるための、見掛けだけの無意味な安全性のごまかしが含まれています。ユーザーがこのようなメッセージを信用するようになったら、同じような形態の悪意のあるメッセージを信用するようになるまで、それほど時間はかからないでしょう。

安全な通信を提供する
確かに、このテクノロジで解決するとされる問題は非常に重要です。信用できる方法でユーザーと通信するのは、簡単なことではありません。ただし、この特定のソリューションは過度に設計されています。ユーザーの混乱を招き、ユーザーのシステムが侵害されるという当初の目標とは正反対の結果をもたらす可能性があります。
現在、適切に設計された Web サイトでは、"メッセージ センター" が使用されています。この設計では、企業が顧客とやり取りする必要があるときには、「メッセージ センターにメッセージがあります。Web サイトにアクセスしてログオンし、[メッセージ センター] リンクをクリックしてメッセージを表示してください。」という内容の電子メール メッセージを顧客に送信します。Secure Multipurpose Internet Mail Extensions (S/MIME) を使用してすべての顧客への電子メール メッセージに署名すると、ユーザーに送信元の正当性を証明できるという、おまけのメリットもあります。また、電子メール メッセージに "このリンクをクリックしてください" という事項が含まれない場合には、つまり、ユーザーが企業の URL を手作業で入力することで、間違いなく目的のサイトにアクセスできるという別のメリットもあります。
企業は、メッセージ センターと署名付きメッセージを使用することで、顧客とやり取りする信頼済みパスを確立できます。メッセージ ワークフローで顧客が目にするものはすべて認証済みであり、企業が不適切なセキュリティ対策を促進することもありません。

プライバシーについて
このシリーズの第 1 部と第 2 部では、セキュリティ プロフェッショナルが実はユーザーに害を与えていて、それがどのように行われているかについて説明しました。IT プロフェッショナルはセキュリティを管理する必要があります。しかし、決定事項や実装しているソリューションの多くはユーザーを混乱させ、不適切な判断を促したり、セキュリティに関する誤った認識を与えています。このような相反する概念がユーザーに悪影響を及ぼさないようにする必要があります。
前述のとおり、一般ユーザーにとってセキュリティとは、単純にパスワードとクレジット カード番号を保護することです。ユーザーは、テクノロジが機能すること、そして信用できることを望んでいます。残念ながら、ユーザーは判断を下す必要があり、ユーザーが詳細な情報に基づいて判断を下せるようにすることが私たち IT プロフェッショナルの仕事です。
このシリーズの最終回となる第 3 部では、ユーザーが利用できる最も重要なテクノロジの一部が期待値に達していない理由ついて説明します。また、召集をかけます。ぜひ、2008 年 9 月号のセキュリティ ウォッチ コラムもご覧ください。

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


持続可能なコンピューティング グリーンウォッシングを選別する
Dave Ohara

目次
数値の必要性
エネルギーの使用状況を測定する
力率
運用環境で測定する
Microsoft EnterpriseEngineering Center
まとめ
市場には環境保護、省エネ、効率化をキャッチフレーズとした製品やソリューションが多数出回っています。このようなマーケティング戦略による誇大広告は、何が本当に環境にやさしいのかということに関して市場で混乱を招きます。さまざまな製品の仕様を評価した後でも、環境への影響が最重要事項である場合にどのようなデバイスを
使用するかを IT プロフェッショナルが判断することは、不可能ではないにしても、難しいことです。どのデモを見ても、必ず大幅な省エネを実現できることが強調されているため、ユーザーは、投資収益率 (ROI) により製品の買い換えを正当化できると考えてしまいがちです。省エネが実現されれば、総保有コスト (TCO) は削減されると考えるので、しかたがないことでしょう。
さまざまな業種の企業が、あらゆるものに「環境」というキャッチフレーズを使用し、環境に配慮したソリューションへの世間の関心の高さを利用するという動きにより、"グリーンウォッシング" という概念が生まれました。これは、環境上のメリットを極端に期待させることを示す用語です。では、省エネをキャッチフレーズにしている製品やソリューションの実態はどうなっているのでしょうか。これは、たとえば、自宅でエネルギー効率の良い新しい電球に取り替えることほど明確ではありません。
持続性のある IT の取り組みへの関心が高まり、環境にやさしい IT 機器の市場が拡大されたことにより、多くの人々や組織は、エネルギー効率の良いラップトップ、デスクトップ、およびサーバーを展開したり、エネルギー消費量を削減するために仮想化を使用したりするなど、最終的な結論を早急に出す傾向があります。しかし、エネルギー監査を実施して、購入したデバイスがもたらす実際のメリットを判定している組織はほとんどありません。
理想的なシナリオは運用環境で実際に測定することですが、それにはコストがかかります。運用環境で測定する準備ができていない場合は、パフォーマンス ラボや評価ラボを使用して、監査プロセスの初期段階でエネルギー監査を実施することで、なんらかの行動を起こすことはできます (ほとんどの企業には、実際に購入する前にデバイスをテストおよび評価する研究所やグループがあるのではないでしょうか)。そこで、エネルギー効率をテスト条件の 1 つとして追加すると、製品やソリューションを購入するかどうかを決める際に、製造元が提示している数値に依存するのではなく、テストの結果を判断材料として使用できます。テストを実施する場合は、デバイスの電力消費に関する独自のデータベースを作成することをお勧めします。そうすると、グリーンウォッシングに取り合うことなく、自分の目でどのような効果があるかを確認できます。
当然ながら、実際の負荷での運用について正確な数値が必要な場合は、運用環境での測定が必要になることをお伝えしておく必要があります。運用環境での測定は、早い段階で始めるほど、組織や最終的な収益に良い結果をもたらします。また、このプロセスは、長期的な成功を収めるうえで重要になります。

数値の必要性
理想的なのは、現実的なユーザーの負荷をかけた状態でハードウェア デバイスの 1 ワットあたりのパフォーマンスを評価する独立したテストを行うことです。しかし、業界では、このようなテストの開発と展開は成熟していません。また、SPEC Power ベンチマークなど、現在使用できるテストもまだ初期段階のものです。こうしたエネルギー テストが準備できたとしても、そのテストの有効性は未知数です。ただし、他のテストと同様、製造元は、最良のテスト結果を出すために自社のデバイスを改良する方法を把握しているという点に注意する必要があります。
経験豊富な IT プロフェッショナルは、テスト環境で実施されたテスト結果を疑問視するようになりました。というのも、自動車会社が最も優れた自動車を路上走行試験で使用しているように、IT ベンダは、間違いなく、最も効果的な構成のデバイスをエネルギー テストに使用するからです。
仮想化のテストについて考えてみましょう。このテストでは、仮想化のメリットを実証するために、統合が行われていないサーバーを多数用意したグループを比較に使用します。ベンダは、仮想化のような省エネ プロジェクトで生じる可能性のあるリバウンド効果などの問題について説明することを怠ります。リバウンド効果とは、エネルギー効率によってコストが削減されるということを受けて、その製品やソリューションの需要が高まると、電力量の使用に拍車がかかり、結果的に電力使用量が増加することです。仮想化など、省エネの万能選手として市場に出回っているソリューションを見かけたときには、その宣伝文句を鵜呑みにしないようにする必要があります。そして、すべてのものがどのように連動しているのか、時間の経過と共にどのような波及効果が表れるのかを確認する必要があります。
では、組織にとって正しい道はどうしたら見つかるでしょうか。価格査定を行うコンサルタントは大勢います。しかし、このアプローチには重大な欠点がいくつかあります。効率的な状態を維持するためのノウハウを本当に社外の人間に伝える必要があるのでしょうか。また、長期契約を結ぶこと、コンサルティング サービスへの依存度合いを高めることを望んでいるコンサルタントに頼る必要があるのでしょうか。
これについては、大規模なプロジェクトを編成し、環境の持続可能性に関する戦略の決定に多くの人々を関与させることで対応できます。使用中の環境で特定の場所を選んで、測定を始めたいという衝動に駆られるかもしれませんが、そのようなことはしないでください。この心理は理解できなくはありませんが、このアプローチは単なる無作為の行為でしかないので意味がありません。必要なのは、多くのエネルギーを消費している場所を特定し、その消費量を抑えるには、どこに手を加えたら良いのかを把握することです。

エネルギーの使用状況を測定する
「機能している」ということについての見方を変える必要があります。IT プロフェッショナルは、たとえば、あるサービスが停止していると、あるハードウェアが機能していないことを認識します。しかし、電力消費の点でハードウェアが正常に機能していないときはどうでしょうか。ほとんどの組織には、基準となるエネルギー効率を定めたデータがないため、おそらく、この異常には気付きません。
では、どうすればこのような数値を入手できるのでしょうか。エネルギーの専門家の必要性を示唆する人もいますが、それには、企業を動かすことができて、かつ電力の問題に関して技術的知識を持っている人が必要になります。より単純でわかりやすい方法は、パフォーマンス ラボの既存の機能にエネルギー測定ツールを追加することです。
さまざまなエネルギー測定機器がありますが、残念ながら、現時点では、IT パフォーマンス ラボに最適だと言える機器はありません。低価格であることを優先する場合は、Watts Up Pro がお勧めです。これは、120 V の直列型の電力測定機能を備えた USB デバイスです。もう 1 つのお勧め機器は、ネットワーク接続対応の電力消費機器 (100 ～ 240V、15 ～ 30 アンペア) である Smart-Watt です。Smart-Watt には、環境要因を測定する温度センサーや湿度センサーも用意されています。他には、Extech Appliance Tester 380801 や Fluke 345 Power Clamp など、業務用電力分析装置もあります。テスト環境のニーズに合ったエネルギー測定機器を探すのは、それほど大変なことではないでしょう。

力率
電力測定に馴染みがない場合は、力率の概念を理解することが重要です。AC 電力装置の力率は、有効電力 (実際に使用できる電力) と皮相電力 (見かけ上の電力) の比率で定義され、0 ～ 1 の数値で示されます。有効電力 (ワット) は、作業を行う回路の静電容量です。皮相電力 (VA) は、回路上の電流と電圧の積です。
これがなぜ重要なのか、疑問に思う方もいるかもしれませんが、図 1 をご覧ください。この写真には、ラップトップ コンピュータ、電球、およびコンデンサのエネルギー効率の比較に使用している Smart Works 社製のエネルギー監視機器が写っています。電球の有効電力は 50 ワットで、皮相電力は 50 VA なので、力率は 1.0 になります。純粋な容量負荷がかかるコンデンサでは、有効電力が 2 ワットで、皮相電力が 193 VA なので、力率は 0.01 です。ラップトップでは、22 ワットの電力を使用していますが、測定値は 48 VA なので、力率は 0.47 です。ラップトップの力率が低いのは、非効率な電源の仕様が原因ですが、それは製造原価の目標に起因している可能性が高いと考えられます。
図 1 ラップトップ コンピュータ、電球、コンデンサの電力消費 (画像をクリックすると拡大表示されます)
エネルギー効率への関心が非常に高まっているので、ベンダは、期待されている条件で電源装置のパフォーマンスを向上することに目を向け始めています。既存のデバイスの力率を新しいデバイスの力率と比較すると、より効率的な電源装置と高い力率を備えたソリューションを選択するだけで、電力容量を増強できることがわかります。

運用環境で測定する
パフォーマンス ラボでの測定は、運用環境におけるパフォーマンスを予測することを目的としています。運用環境でエネルギー使用量を測定する場合の問題は、すべてのデバイスの測定に必要なコストですが、運用環境で電力を測定する際のコストを削減する方法が 1 つあります。それは、電力分配器 (PDU) で測定を実施して、複数のデバイスの測定値を集計することです。図 2 は、PDU で複数の同一デバイスを使用した場合に、PDU から取得したエネルギー測定値のサンプルです。この測定方法を使用すると、サーバー 1 台あたりの平均的な電力消費量を計算できるので、運用環境における電力消費量の数値を入手できます。
図 2 電力分配器での測定 (画像をクリックすると拡大表示されます)
各デバイスの電力消費量を測定したら、電力情報を構成管理データベースに統合する必要があります。これが非常に困難である場合は、デバイスとその電力消費量を記載する、独自のデータベースまたは少なくとも Excel® ワークシートを作成して代用できます。より多くのデバイスの測定値を取得したら、全体的な電力容量を計算できるように他のデバイスの概算値を入力できます。エネルギー効率の良い新しいサーバーでは、アイドル時の電力負荷はピーク時の半分以下になります。これに対して、古いサーバーで、旧式のソリューションを実行している場合は、サーバーがアイドル状態であっても、大量の電力が消費されます。これは、電力容量を増強する際に使用できる最もわかりやすい標的の 1 つです。
改善努力を続ける場合は、次に、データセンターで使用しているラックごとの電力消費量を計算します。環境を変える場合は、必ず電力容量と冷却容量も把握しておく必要があります。今後は、デバイスを設置するのに必要な空間だけでなく、その消費電力についても考慮するようになるでしょう。空間は、動きがなく視覚的に捉えられるので、わかりやすい概念です。IT プロフェッショナルであれば、すぐに 1U サーバー、2U サーバー、および 4U サーバーについて説明できますが、200 ワットのサーバーと 450 ワットのサーバーの比較についての話を始めると、IT プロフェッショナルは居心地が悪いと感じるでしょう。これは、消費電力が IT 機器においては新しい概念であり、現在のデータセンターでは、それが顕著に表れています。というのも、多くのデータセンターでは、最大の電力容量に達していても、さらに多くのデバイスを配置するための十分な空間が確保されているからです。

Microsoft Enterprise Engineering Center
Microsoft Enterprise Engineering Center (EEC) では、最近、その施設に電力測定機能を増設しました。EEC (microsoft.com/windowsserver/evaluation/eec/default.mspx) は、ワシントン州レドモンドの Microsoft Corporate Campus にある、最も複雑なコンピューティング環境を検証するための最新の実験施設です。
EEC では、ハードウェア デバイスやネットワーク デバイスに 4,000 万ドル以上を投資しており (図 3 参照)、実在する非常に複雑な企業の運用環境を再現することができます。また、主要なネットワーク、ストレージ、クライアント/サーバー ソリューションのプロバイダと提携して、最先端のテクノロジと従来のプラットフォームを組み合わせた環境も提供します。EEC では、各テストで顧客の現在の環境を正確に再現できるようにすることを目標としています。この施設で開発されている最新のサービスでは、1 ワットあたりのパフォーマンスのベンチマークを提供するためにソリューションのエネルギー消費量をレポートしています。
図 3 EEC ラボ内のある通路 (画像をクリックすると拡大表示されます)
ここ数年の間、EEC では、多くのデータセンターの運用担当者が、デバイスで必要な電力容量と冷却容量不足に悩まされているという現状を目の当たりにしてきました。多くの場合、最新デバイスの電力密度は高くなるので、設備にかかる負荷は増加します。EEC のスタッフは、電力設備と冷却装置のインフラストラクチャのアップグレードにかかるコストと時間を身を持って習得しました。そこで、EEC では、より効率的な運用とコスト効率向上を実現するために、デバイスごとの電力を測定する機能を追加しました。
EEC で使用している一部のツールやデバイスは、この記事の執筆時には販売されていませんでした。これは新しいソリューションなので、EEC では、顧客、ベンダ、およびマイクロソフトの開発チームと協力して、より優れた手法の開発を続けていきます。EEC では、早期のフィードバックを得るために、これまで開発してきた方法を顧客と直接共有し、顧客が独自のベンチマークを作成できるようにしています。
明確な結果が得られるとは限らないことに注意してください。EEC では、EEC パフォーマンス ラボでエネルギー監視機能を使用する際に、同グループが確認した次のような興味深い結果をいくつか共通認識として持っています。
  1. デバイスの電源を切っても、エネルギー消費量は必ずしも期待どおりに減少するとは限りません (図 4 参照)。サーバー ハードウェアに関するある事例では、電源を切っていても、電源プラグがコンセントに差し込まれていると 100 ワットの電力を消費するデバイスがあることに気付きました。これには非常に驚かされ、EEC では何度も設定を確認しました。最終的に、赤外線放射温度計を使用して入り口と出口の温度を測定し、デバイスでは電源が切れている場合でも実際に 100 ワットを消費したことを確認しました。
  2. ソフトウェアは、電力消費量に大きな影響を与える可能性があります。(ハードウェアや BIOS の構成がまったく同じ) 同一のネットワーク スイッチで、異なるネットワーク ソフトウェアを実行したところ、電力消費量に 21% の差が見られました。セキュリティ ツールや監視ツールなど、より多くのプロセスや機能が有効になっているハイエンド ソリューションでは、多くの場合、単純なローエンド ソリューションよりも電力消費量が多くなります。
  3. 仮想化シナリオでは、I/O 使用率や CPU 使用率に対する電力消費量を測定し、特定のハードウェアで 1 ワットあたりのパフォーマンスが最大になるタイミングを判定しました。CPU 使用率に焦点を絞ってしまうと、1 台の物理コンピュータで実行するバーチャル マシンの増加につながり、1 ワットあたりの全体的なパフォーマンスが低下することがわかりました。
  4. より高密度なデバイスでは、ご想像のとおり、電力や冷却に関する問題も多くなります。高密度なシステムを導入する場合は、電力設備や冷却装置の担当者にできるだけ早い段階で相談をする必要があります。このようなデバイスを展開する環境の電力に制約があることがあらかじめわかっている場合、そのデバイス専用の電力監視装置を用意することを検討してください。
  5. 二重電源装置では、単一電源装置よりもはるかに多くの電力を消費する場合があります。
  6. 同一のハードウェアで、構成が同じであるように見えても、電力消費量が大幅に異なる場合があります。消費電力には大きな違いが見られたので、EEC のスタッフは、ハードウェアを再確認して実際に同じように構成されているかを確認しました。
  7. 製品の電力定格は、実際の消費量ではなく、電源装置の定格容量です。
  8. デバイスや従属部品ごとのエネルギー消費量のテストと結果のデータベースを保持することは、知識を蓄積してデータを比較するうえで不可欠です。
  9. 搭載されている RAM の量が同じでも構成が異なると、エネルギーの消費量も異なります。通常、DIMM の数が少ないと、エネルギー消費量は少なくなります (たとえば、2 GB の DIMM が 4 枚と 1 GB の DIMM が 8 枚の場合は前者のエネルギー消費量が少なくなります)。ただし、DIMM の数が少なくてもエネルギー消費量が増加するケースもありました。
図 4 電源をオンとオフにした場合の電力消費量の比較 (画像をクリックすると拡大表示されます)

まとめ
パフォーマンス ラボに電力消費量を測定する機能を追加することにより、各デバイスのエネルギー消費量 (実際の負荷がかかったときの正確な数値) を独自のデータベースに蓄積し始めることができます。このようなソリューションを展開する際には、閉ループ フィードバックの結果を監査して、パフォーマンス ラボのテストが正確かどうかを判断する必要があります。EEC が独自に測定テストを実施したことで突き止めたように、人々がグリーンウォッシングを排除し、真実を見抜けるようにするための非常に興味深い詳細情報があります。
この測定方法をパフォーマンス ラボで実施することにより、市場全体で何が実際に最もエネルギー効率が高いのかということが明らかにされるようになるでしょう。また、製造元は、徐々に、省エネをキャッチフレーズに使用する根拠となるより正確なデータを提供する必要に迫られるようになるでしょう。同様に、IT プロフェッショナルも、一般的な購入条件として各デバイスが消費するワット数について説明するようになるでしょう。特に多くのサーバーを購入する企業にとっては、このようなことが普通に行われるようになるのは望ましいことです。ただし、今日から、電力を貴重な IT リソースの 1 つとして考え始めることにより、先陣を切ることができます。
データセンターの温度管理
データセンターの温度を適切に管理すると、エネルギー消費量を大幅に削減できる可能性があります。データセンター内では、驚くほど多い熱量が発生し、ハードウェアの冷却には驚くほど多くのエネルギーが消費されています。しかし、データセンターの温度をうまく管理して、問題を解決し、より効率的な冷却方法を考案するには、温度監視ソリューションが必要になります。マイクロソフトのデータセンターで使用しているソリューションを考えてみましょう。
Microsoft Research では、データセンターの温度センサー ネットワークを構築しました。このネットワークにより、温度管理が改善されるだけでなく、さまざまな冷却機能の向上も評価できるようになります。たとえば、マイクロソフトのあるデータセンターでは、通路の突き当たりにあるエア カーテンを評価し、暖気と冷気の分離を強化しました。エア カーテンの導入後、一部のサーバーから、過熱状態であることを示す警告が送信されました。当然ながら、運用エンジニアは、冷却装置からの送風量を増加し、より多くの冷気を送り出すようにしました。ところが、驚いたことに、それ以外の多くのサーバーからも過熱状態であることを示す警告が送信されました。警告の送信元サーバーは、すべてラックの下段に配置されていました。冷却装置は上げ床に設置されているので、通常、ラックの下段は最も涼しい場所であると考えられます。
エンジニアは、センサ ネットワークを使用して、ラックは下段が最も熱く、上段の方が涼しいことを確認しました。また、ラックの下段と床の間には、ベルヌーイの法則により、暖気通路から暖風が吹いていることをすぐに突き止めました。エンジニアは、ラックの下段に目張りをして、風速を下げることで、過熱の問題を簡単に解決しました。
これは、Microsoft Enterprise Engineering Center がパフォーマンスのテストを行う際に収集して分析したデータにすぎません。そこで、EEC では、最近、展開テストの準備が整ったことを Microsoft Research に通知しました。1 日のうちに 10 個のラックにシステムを配置し、設置が完了するまで 1 時間しかかかりませんでした。EEC は、冷却に関する問題とそのハードウェア パフォーマンスとの関係を調査して理解を深めることができるようになりました。
当然ながら、ただ監視するだけでは解決策にはなりません。監視による実益は、解決できる問題のある領域を特定して変更を行ったり、さまざまなソリューションを評価して予想していた結果を得られたかどうかを確認したりする能力を得られることです。このような能力を身に付けていれば、新しく導入した冷却ソリューションにより、ラックが過熱されるという予想外の状況が発生しても冷静に対応できます。

Dave Ohara は、テクノロジの分野で 26 年にわたる経験を持ち、現在は、グリーン イニシアチブに取り組む複数の企業に協力しています。


フィールド ノート IMAP が世界を救う
R'ykandar Korra'ti

新たな小さな問題の解決策が、以前からある大きな問題の解決策になることがあります。今月は、そのような解決策をご紹介します。
昨年の冬、私たちの組織の Web 管理者は MacBook を購入しました。それまで、彼女は完全な Windows® ユーザーでしたが、現在は、Mac OS X と Windows XP の両方を使用しています。Windows XP は、バーチャル マシンで実行し、Windows Mobile® デバイスとの同期や他のこまごまとした作業に使用しています。
彼女は、どちらのオペレーティング システムからもメールのアーカイブにアクセスできるようにする必要がありましたが、Mac 側で Entourage を実行するという安易な方法は使用したくありませんでした。そうではなく、OS X に同梱されている電子メール クライアントである Mail.app を実行することを希望していました。ついでにお知らせしておくと、彼女は、あらゆるものをラップトップ コンピュータのローカル ストアに保存していますが、ミラー化はしていません。そして、私の任務は、この状況に対応することでした。
どこからでもアーカイブにアクセスできるようにするのは、既にお知らせしたように、たいした問題ではありません。というのも、Exchange Server、Microsoft® Office Outlook®、Mail など、すべての電子メール製品では IMAP4 に対応しているからです。これが今回のコラムの 1 つ目の教訓です。IMAP4 は、シン クライアントからサーバーにあるメッセージ ストアにアクセスする際に使用するメッセージング プロトコルです。IMAP4 では Exchange Server ユーザーが必要とする全機能は提供されませんが機能します (詳細については、2006 年 3 - 4 月号の TechNet Magazine の記事「How IT Works: IMAP4」(technet.microsoft.com/magazine/cc161016) を参照してください)。
そこで、少し設定を変更して IMAP4 over SSL を有効にし、彼女のラップトップ コンピュータのローカル フォルダにあるものをすべてサーバーにコピーして、ping を実行しました。これで、彼女はどのクライアントからもメールにアクセスすることが可能になり、Windows Mobile デバイスを最新の状態に保つことができるようになりました。これで問題は解決しました。
けれども、一見複雑に見える問題に対して簡単な解決策を考案するのは、新しいテーブルソーを入手するようなものです。突然、ベニヤ板を探し始めたと思ったら、あっという間に、ステージ セットが完成し、「ロミオとジュリエット」を上演する準備が整っているというわけです。
私たちが運営している ISP では、Windows、OS X、Mac OS、Linux だけでなく、すっかりマイナーな OS になってしまいましたが歴史ある AmigaOS システムもサポートしています。随分昔のことになりますが、私たちは Amiga システムで Usenet ニュースと UUCP メールをホストしていました。このシステムでは、RFC-733 で規定されている amiga.uucp 形式のアーカイブが作成されました。また、これ以外に、Microsoft Mail のアーカイブ (.mmf 形式) や同様に旧式の UNIX メールのアーカイブ (.mbox 形式) もあります。これらのアーカイブは、ただサーバー上に存在し、私たちを嘲っているかのようでした。このアーカイブについては、何かと検討する必要があったのですが、恐れをなして逃げ出していた問題でもあります。
このシナリオには、2 つ目の教訓があります。それは、危険なハッカーの座右の銘が「置き換えられないものは消すべからず」だということです。
まず、Microsoft Mail のアーカイブから着手しました。Outlook では、しばらく .mmf ファイルをインポートすることができませんでした。長い年月をかけて Outlook クライアントをアップグレードしてきましたが、何が起こるかわからないので、少なくとも各製品の 1 つ前のライセンスは維持するようにしました。その結果、私たちが所有するライセンスでは Microsoft Corporation の歴史の変遷を見ることができます。MS-DOS® は必要ですか。OS/2 1.31、Microsoft Mail、Office 95 は必要ですか。問題ありません。英語版が必要ですか、それともフランス語版ですか。
Outlook 2000 では、.mmf ファイルをインポートできるようになりましたが、IMAP サポートが適切に動作していなく、ヘッダー データが削除されることがありました。また、IMAP4 と Exchange Server の両方を同時にサポートすることができませんでした。これは、厄介な問題でしたが、致命的な問題ではありませんでした。Outlook 2000 で .mmf ファイルをインポートし、Outlook 2003 のライセンスにアップグレードし、数時間ドラッグ アンド ドロップ操作を行うと、作成されてから 15 年もの年月が経過したアーカイブは、どこからでもオンラインで参照できるようになります。これと同様に、.mbox 形式のアーカイブに関しては、.mbox と互換性のある IMAP サーバーを Linux コンピュータにセットアップし、作業ディレクトリに .mbox 形式のアーカイブを配置しました。その後、Outlook の IMAP サポートを使用して、フォルダに接続し、必要な運用サーバーにフォルダをコピーしました。
.mmf と .mbox については簡単な作業でしたが、Amiga 形式のアーカイブに関しては、RFC-733 形式のヘッダーを RFC-822 形式のヘッダーに変換し、SysV 形式のメッセージ区切り文字を削除し、Amiga の特殊な Hell から奇妙な From: 行を取得するコードを C 言語で記述する必要がありました。これは、この問題を早く解決しなかった代償ですね。けれども、この変換処理が終われば、amiga.uucp 形式のアーカイブは .mbox 形式のアーカイブになります。変換後のファイルを先ほどと同じ作業ディレクトリに配置すると、Outlook の IMAP4 サポートによりメールが新着メールと同様の状態で配信されます。おまけに、添付ファイルが適切にパッケージ化されているという、すてきな状態で配信されます。
1990 年までのすべてのアーカイブをオンラインで持っています。しかも、すべて同じ形式です。ですが、それ以前のものでも同様に対応できるという理由だけで、それより前のアーカイブも探しています。これは常軌を逸した行為でしょうか。

R'ykandar Korra'ti は、小規模な協同組合の ISP ポストマスタを務めており、パートナーの Anna とシアトルに在住しています。マイクロソフト在籍時はメール関連製品を担当していたので、マンドリンの曲の作詞活動 (こちらに関しては有名ではありませんが) をしていないときは、技術資料を執筆しています。彼女の連絡先は、darako@murkworks.net (英語のみ) です。出演契約交渉担当者の方は、こちらまでご連絡ください。


Windows 秘話 過去の遺産による貢献
Raymond Chen

同僚が、ほこりだらけの物置から Alpha AXP コンピュータを引っ張り出してきて、システムを起動したところ、2000 年初期にリリースされた 64 ビット版の Windows® が実行されていることに気付きました。なぜ、このようなことが起こりうるのでしょうか。
当時、私もオフィスで Alpha AXP コンピュータを 1 台所有していました。全盛期には、このコンピュータは一目置かれるほどの力を持っていました。このコンピュータは、小さな冷蔵庫と同じくらいの大きさで、掃除機と同じくらいの音量の騒音を発していました。このコンピュータには、4 基の (もう一度言いますが、4 基ですよ) Alpha AXP プロセッサが搭載されており、各プロセッサは 400 MHz という信じられない速度で実行されていました。また、1 GB の RAM と 12 個の高速な SCSI ドライブで構成された 13 GB のハード ドライブ領域が用意されていました。これは、現在では、たいしたことではないように思えるかもしれませんが、1990 年代には、こうした Alpha AXP コンピュータは人々の羨望の的で、このコンピュータを持っているだけで昼食の席では人気者になれました。
1999 年に Compaq が Alpha AXP における Windows のサポートを打ち切ることを発表すると、多くの Alpha AXP システムは、突然、御役御免になりマイクロソフト社内に転がっているだけという状態になりました。ただし、中には、さまざまな非公式の用途に使用されるようになったものもありました。私は、Alpha AXP システムを使用して Windows ソース コード全体にインデックスを付けました。関数の呼び出し元をたった数秒ですべて特定できたり、デバッグ トレースに表示される関数やダイアログ ボックスに対応するソース コードの場所を特定できたりすると、プログラマにとってどれほど便利か、想像できるでしょう。
ですが、Windows ソース コードにインデックスを付けるという簡単な処理に関しても、Alpha AXP コンピュータはすぐに x86 クラスのコンピュータに見劣りするようになってしまいました。x86 クラスのコンピュータの方が安価かつ高速であり、搭載されているハード ディスク領域やメモリのサイズも大きかったのです。そのため、私の Alpha AXP コンピュータも、他の Alpha AXP コンピュータと同様、すぐに忘れ去られた存在となりました。Alpha AXP のサポートの終了は、Alpha AXP コンピュータの終焉であると思われていました。しかし、その後、最後に次世代の役に立つという輝かしい名誉を得る機会が Alpha AXP コンピュータに与えられました。
当時、64 ビット版の Windows プロジェクトが進行中で、想定されている 64 ビット プロセッサのうち、実際に (物理的に) 使用できるのは Alpha AXP だけでした。Intel Itanium はまだ開発中で、シミュレータ内でしか実行できませんでした。また、AMD64 アーキテクチャはまだ発明されていませんでした。そのため、当初、64 ビット版の Windows は Alpha AXP で開発されました。
Compaq が Alpha AXP における Windows のサポートを打ち切ることを発表したとき、それまでは 32 ビット版の Windows 2000 の開発やテストに使用されていた Alpha AXP コンピュータには、新たな目的が与えられました。そして、Alpha AXP コンピュータに搭載された形では出荷されない 64 ビット オペレーティング システムのテスト コンピュータとしてのひそかな役割を果たすようになりました。Alpha AXP は、単なる概念実証用プラットフォームでした。
Alpha AXP コンピュータはこの役割をりっぱに果たし、64 ビット版の Windows チームはオペレーティング システムを Itanium シミュレータ上で実行するのではなく、実際のハードウェア上で実行することができました (Itanium シミュレータ上で実行すると、パフォーマンスがどれほど低くなるかは、想像できるでしょう)。Alpha AXP は最終的なターゲット ハードウェアではありませんでしたが、大いに役立ちました。Itanium CPU が物理的に使用できるようになると、Alpha AXP が満たしていた特殊な需要は消滅し、Alpha AXP はほこりだらけの物置に再びしまいこまれました。
マイクロソフト アーカイブで働いている友人が、この記事で使用する写真を撮るために、私の古くて頼りになる Alpha AXP をほこりだらけの物置から引っ張り出してきました。写真には、Alpha AXP が完成に貢献した製品の 1 つである 64 ビット版の Microsoft Windows Server® 2003 が Alpha AXP と共に写っています。ええ、そのとおりです。写真に写っているほこりは、物置から出してきた状態そのままのものです。

Raymond Chen は自分の Web サイト「The Old New Thing」および同じタイトルの書籍 (Addison-Wesley、2007 年) で、Windows の歴史と Win32 プログラミングについて扱っています。ほこりだらけの物置に閉じ込めらるのは好きではありません。