 TechNet Magazine October 2007

TechNet Magazine October 2007

グリーン コンピューティング: グリーン データセンターを構築する

世界各地の企業が省エネルギーを進め、コストを削減する方法を考え始めていますが、実際にどのように行動するかについての指針はほとんどありません。ここでは、組織でのグリーン データセンター (地球環境に配慮したデータセンター) の計画、設計、および導入に関する基本情報を提供します。

Dave Ohara Windows の管理: Active Directory レプリケーション ガイド

Active Directory により、大規模な環境や分散環境をサポートできる幅広い柔軟性が提供されますが、データの整合性は維持しにくくなる可能性があります。Active Directory のレプリケーションでは、環境全体に更新を伝達する方法と、競合の解決方法が定義されています。この記事では、このデータの整合性の維持という課題に対処するために必要な情報を提供します。

Laura E. Hunter System Center: 新しいソフトウェア更新プログラムの管理ツール

System Center Configuration Manager 2007 では、各クライアントでの対応および適用が確実に強化される更新プログラムを管理するための、まったく新しいメカニズムが導入されました。今月のコラムでは、この強化された手法によって、すべてのコンピュータを最新の状態にする方法について説明します。

Steve Rachui 通信: マイクロソフトの Exchange エッジ トランスポート サーバー

マイクロソフトでは、どのようにして大量に送信されてくる悪意のあるコンテンツをそのメッセージング環境から排除しながら、従業員に正当なメッセージを配信しているのでしょうか。その方法の 1 つは、Exchange Server 2007 エッジ トランスポート サーバーと Forefront Security for Exchange Server を展開することです。ここでは、組織の安全性を維持するためにこれらのテクノロジがどのように役立つかについて説明します。

Kay Unkroth SQL Server: SQL Server の CPU パフォーマンスを最適化する

データベース サーバーの CPU 使用率を正常に保つには、必要な処理に CPU が使用され、最適化が不十分なコードや動作の遅いハードウェアのために無駄なサイクルが発生しないようにすることが重要です。ここでは、SQL Server とハードウェアを最大限活用するためのヒントを紹介します。

Zach Nichter 編集長から: さらなる飛躍へ

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

Greg Steen SQL に関する Q&A: ログインのトリガ、データ ファイルのデフラグなど

Edited by Nancy Michell ユーティリティ スポットライト: Virtual Machine Remote Control Plus

Matthijs ten Seldam ビジネスにおける IT: 行政機関における IT インフラストラクチャの価値を計算する

Acer Maamoun The Cable Guy: 認証済みインターネット プロトコル

Joseph Davies Windows PowerShell: スクリプトを使用しないで作業する

Don Jones Hey, Scripting Guy!: Silverlight の光あれ

The Microsoft Scripting Guys セキュリティ ウォッチ: BitLocker と信頼という複雑なもの

Justin Troutman デスクトップ ファイル: WIM と ImageX のパワー ユーザー ガイド

Wes Miller フィールド ノート: PC をリサイクルする

Jim Lynch Windows 秘話: ワトソン博士の呼び出し

Raymond Chen


 グリーン コンピューティング: グリーン データセンターを構築する
グリーン コンピューティング Dave Ohara

グリーン データセンターを構築する
概要:
  • エネルギー監視システム
  • グリーン データセンターの重要な特徴
  • H.R. 5646 の影響
  • 取り組みを始める際のベスト プラクティス

最近、"グリーン" (地球環境への配慮) が大きな話題となっており、その概念は、人々のデータセンターに関する考え方に影響を与えています。世界各地の企業が、新しいハードウェアやサービスを購入することで、省エネルギーを実現し、
コストを削減する方法を発表しています。しかし、どのように行動すればエネルギー コストを制御できるかについての指針はほとんどありません。これまで、電力はスペース コストと同様に一般管理費として扱われてきました。しかし、その信頼性、供給、容量に関するコストと問題が増加しているため、電力に特化した戦略が必要になりました。
パフォーマンスの最適化とコスト削減に関するプロジェクトは、ほぼすべてのビジネス分野で日々のベスト プラクティスの一環として実施されています。したがって、エネルギー コストも同様に扱うべきではないでしょうか。
多くの IT プロフェッショナルは、サーバーの構成とセットアップ、組織で購入する機器の仕様、およびデータセンターのアップグレードと構築の要件を決定しています。アプリケーション開発中に初期設計について意見を述べることさえあります。このようなプロジェクトで、IT プロフェッショナルは、環境に配慮し、あらゆるデータセンターのエネルギー効率に影響を与える絶好の機会を手にしていることは明らかです。
どのような戦略であっても、最初の一歩は、現在のエネルギーの使用状況を把握することです。データセンターで、どの部分にエネルギーが使用され、具体的にどのような機器や使用方法の効率がよく、何が無駄であるかを把握する必要があります。残念ながら、人々が各自の行動の結果を確認できるレベルまで詳細な使用状況を報告できる電力消費計測システムが導入されていることはまれです。ほとんどの組織では、消費量をまとめて計上している毎月の電気料金を確認しているのが現状でしょう。これでは、個人がそれぞれの意思決定の影響を確認できず、自分たちの変化が実際に省エネルギー化につながっていることを証明する方法もないため、省エネルギーへの意欲が湧きません。
グリーン データセンター イニシアチブの推進を検討するときに直面する最初の問題の 1 つは、経営陣の支持を得られるかどうかです。この記事では、その支持が "まだ得られていない" ものとして話を進めます。経営陣の支持を得るには、この計画にリソースと予算を確保してもらうための本格的な取り組みが必要です。グリーン データセンターについて話されることは多くありますが、いまだに経営レベルでの本格的な支持が得られていないことが多いのが現実です。既にこのような経営陣の支持を得ている場合は、現時点でグリーン データセンターを運営していることでしょう。
しかし、必要な支持が得られていないとしても、グリーン データセンター イニシアチブを推進するためにできることは多くあります。では、目的を達成するための効果的な行動を判断するにはどうすればよいでしょうか。さいわい、省エネルギーは新しい概念ではないため、IT プロフェッショナルは他の業界から多くのことを学習できます。

エネルギー消費状況の概要
このトピックの執筆時に直面した最大の難関の 1 つは、さまざまな資料から提供される数字に大きな開きがあり、その意味を読み解くことでした。一部の調査では、米国における電力消費全体の 1.2 ～ 2.0% をデータセンターが占めるとされています。ある推計では、データセンター自体を 1 つの業界と見なした場合、米国のデータセンターは電力消費に関しては上位 5 業界に迫ろうとしています。また、米国ではエンタープライズ データセンターの運用コストの 15 ～ 20% が電力費であると言われています。
米国エネルギー合理化経済評議会の依頼を受けてローレンス バークレー国立研究所が実施した調査では、データセンターは通常のオフィス ビルの 40 倍もエネルギーを消費する場合があるとされています。この調査では、施設という観点からエネルギー効率を向上させるためにできることについて、詳しく報告されています (eetd.lbl.gov/emills/PUBS/PDF/ACEEE-datacenters.pdf を参照してください)。手始めに、この調査でまとめられているベスト プラクティスを組織のデータセンターでどの程度実施するかを決定するとよいでしょう。
電力消費に関しては、さまざまな見方、調査、および数字があることは間違いありません。ただし、共通している 1 つのテーマは、多くの無駄があるということです。最大限の処理性能を求めて、どれほど多くのサーバーを購入しているか考えてみてください。つまり、予算内で可能な限りの高性能 CPU、メモリ、記憶域、および冗長電源装置を購入していないかということです。これらのサーバーの多くは、過去 3 ～ 5 年の間、平均して 10 ～ 15% の使用率で運用されています。CPU が注目されることが多いのですが、他の要素もここでは重要な役割を果たしています。メモリ、ディスク、およびネットワーク インターフェイスはそれぞれかなりの電力を消費し、合計すると CPU の電力消費量を上回ります。
また、プロセッサから冗長電源装置に至るまで、過剰なハードウェア容量は、すべて大きな無駄につながります。ほとんどの IT 部門ではリスク回避を信条としているため、余分な容量を確保することが一般的です。経費の面では最高の意思決定になるとは限らなくても、最も安全な意思決定は余分なハードウェア容量を確保することです。しかし、ライフサイクル コストを計算するとき、エネルギーは主要因の 1 つにも関わらず、通常は見過ごされます。さらに残念ながら、展開後は意思決定者にとって経費の面でメリットがないため、エネルギー効率のよいソリューションの購入を促す材料がありません。
しかし、至るべき中間点はあります。経営陣が実際に使用されているデータセンターのハードウェア容量がいかに少ないかを認識し、コスト削減の手段としてサーバーの統合に期待を寄せたとき、振り子は別の方向に動き出します。サーバーが展開された後に統合を図るよりも、事前にサーバーの規模を決定する方がはるかに簡単です。
IT 業界の成熟度が新たなレベルに達したことで、コスト削減を伴う最適化が優先課題の 1 つとなりました。エネルギー消費は、経営陣が IT ハードウェアのライフサイクルに関して下した意思決定の有効性を測る際に使用できる指標の 1 つです。AMD、Intel、およびサーバー OEM とコンポーネント OEM はいずれも、自社のプラットフォーム製品の 1 ワットあたりのパフォーマンスを発表しています。1 ワットあたりのパフォーマンスの数値は、1 パフォーマンス単位あたりのワット数という逆の式を使用することで、運用コストの計算に使用できます。IT ソリューション開発に携わる人々(施設、アプリケーション開発、アーキテクト、運用、および事業部) は、1 ワットあたりのパフォーマンスから、"見返りに得られることは何か" という問いに対する答えが得られるほか、エネルギー効率という観点からソリューションを比較できるようになります。
一般的に、エネルギー コストが無視され、運用費と施設費に影響する意思決定が見過ごされるのはなぜでしょうか。電力や冷却上の制約のために、能力が限られているデータセンターをいくつご存知でしょうか。かつては、データセンター用の物理的な空間を確保することが課題となっていました。しかし、現在は、すべての機器に電力を供給し、冷却するだけの能力を確保しているか、また、この能力でどの程度先まで運用を続けられるかということが課題となっています。

エネルギー監視システムの重要性
正確なエネルギー消費量を計測することは困難です。前述のとおり、ほとんどの企業は、事業部ごとの電力消費量を把握するのではなく、全体の電力費のみを計上しています。電力を一般管理費扱いにするこの方法では、事業部は電力費を管理できないという認識が生まれます。しかし、これは真実ではありません。
データセンターは 1 平方フィートあたり通常のオフィスに比べて 10 倍の電力を消費する場合があるため、小さな効率の向上でも、大きな節約になる可能性があります。データセンターが省エネルギー プログラムを導入する最大の理由が、コスト削減であるというのは驚くべきことではありません。問題は、通常は電力消費量の計上に最もコストのかからない方法が使用されていて、データセンターの運用にかかる毎月の施設費がまとめて計上されていることです。さらに、コストは各グループが使用する空間の広さやポートの接続を基に割り当てられます。この方法では、ある 1 つのデータセンター設備の運用にかかるコストの正確な内訳を得ることは到底できません。
データセンターの機器ごとに実際の電力使用量を計測できるソリューションが組織に導入されていることはまれです。これは主に、エネルギー計測およびレポート システムを導入するには、かなりの初期投資が必要になるためです。ただし、このようなシステムへの投資は、いずれ大きな費用削減につながります。
もちろん、電力監視システムだけでは不十分です。エネルギーの消費をより細かく管理し、最終的に投資の見返りを得るには、収集したデータの使用方法を計画する必要があります。新聞紙や紙製品の世界最大のメーカーであるカナダの企業 Abitibi Consolidated を例に考えてみましょう。2001 年、オンタリオ州の電力市場は規制緩和が実施される予定であったため、Abitibi Consolidated は、激しく変動する市場価格や可用性の影響を受ける可能性がありました。最適な形で電力を購入できるように、同社は監視および計測システムを導入しました。この新しいシステムを導入して数か月のうちに、同システムの購入費は回収できました。同社は電力をより効率よく購入することで、1% のコスト削減を実現したのです。
データセンターへのエネルギー監視システムの導入が容認されるには、どの程度の省エネルギーを実現する必要があるでしょうか。マイクロソフトで Windows Server® 2008 のゼネラル マネージャを務めている Bill Laing は、最近のインタビューで Windows Server 2008 では既定で省電力機能が有効になり、最高 20% も電力消費量を削減できると答えています。これは大きな節約です (図 1 は、Windows Server 2008 Beta 3 の電源オプションの一部です)。ただし、消費電力コストの削減量から、節約される電力を直接計算できるわけではありません。新しいデータセンターの構築費や、現在効率の悪い構成をサポートしている他のシステムの数など、関連する要因は多数あります。
図 1 Windows Server 2008 Beta 3 の電源オプション
図 1 Windows Server 2008 Beta 3 の電源オプション
現時点では、Windows Server 2003 SP1 の [プロセッサの電源消費とパフォーマンスのバランスの取れたサーバー] というオプションを利用できます。しかし、計測システムが導入されていない場合は、節約される電力や、この変化の実現とサポートに関連するその他の要因を計測することはできません。
また、多くのデータセンターでは、24 時間のうちに見られる電力消費量の変化は 4% のみです。つまり、電力消費量は実際に処理されているデータの量に左右されません。ただし、ハードウェア ベンダによる最近の技術革新のおかげで、新しい機器ではこの状況に変化が見られ、負荷が少ない場合は消費される電力量が減少しています。

グリーン データセンターを定義する
グリーン データセンターの条件や特徴は、数ページにわたって挙げることができます。もちろん、ここではすべてに言及する余裕はありませんが、グリーン データセンターの導入を真剣に考える場合に、念頭に置くべきいくつか重要な特徴を取り上げたいと思います。現在は計画段階でしかなくても、この一覧を使用して、現在のデータセンターの状態を特定できます。
  1. 計測データを分析して、要素レベル (2U サーバー、4U サーバー、スイッチ、SAN、UPS など) のエネルギーの使用状況と、これらが使用している電力費の計上先となる事業部を確認します。
  2. エネルギーの使用状況を継続的に監視し、ピーク時と使用量が低いときのエネルギーの需要を確認します。
  3. エネルギーの容量をデータセンター全体から回路にいたるすべてのレベルで監視し、すべての回路が許容範囲内にあることを確認します。
  4. 省エネルギー計画を文書化し、報酬の対象とします。
  5. 省エネルギー計画を定期的に見直し、不備を修正するようにします。
  6. 事業部ごとのコストを計上するしくみを確立することで、行動を誘発し、事業部間で省エネルギー化を促進します。これについては、経営陣レベルで指揮を執る必要があります。
  7. サーバーで CPU の調整機能を有効にし、パフォーマンス ラボで、さまざまな負荷を与えたときの消費電力の範囲を計測します。
  8. 温度プロファイルを使用して、温度が高い場所と冷却しすぎている場所を特定します。
  9. IT パフォーマンスの設計内容にエネルギー効率の測定値を含めます。
  10. 実際のデータのフィードバックを各組織に提供し、各組織が適切に対応できるようにします (California ISO は、図 2 のように、Web サイト上でリアルタイムのデータを一般に公開しています)。
図 2 California ISO の Web サイトで提供されている、現在の電力の需要と顧客が現在求めている節約レベルを示す実際の使用状況のスナップショット
図 2 California ISO の Web サイトで提供されている、現在の電力の需要と顧客が現在求めている節約レベルを示す実際の使用状況のスナップショット
上記の特性を多く満たしていればいるほど、高度なエネルギー監視システムを有効に運用できる可能性が高くなります。また、現在のデータセンターのレベルを確認するための質問が 8 項目記載されたスコアカード (図 3 を参照) を用意しました。レベルには、入門、中級、および上級があります。
Figure 3 データセンターのグリーン (環境配慮) レベル (Close Figure 3)

レベル | 確認事項
入門 | 毎月の電気料金を確認している
容量計画のために定期的に電気設備の確認を実施している
中級 | 電子回路の負荷と電力消費量を自動的に計測および報告する機能を導入している
機器を購入するときにエネルギー効率を確認する
上級 | ラック、機器、および回路ごとの電力消費量を監視している
監視とレポートの履歴データを分析している
各部門が変更と導入の影響を理解できるように、リアルタイムのエネルギー消費レポートを使用している
有利な利用料金を引き出すためにデータを使用して電力会社と交渉している

情報収集は戦いの半ば
直面することになるもう 1 つの問題は、組織全体での標準化です。この記事で説明したような変更、つまりエネルギーを計測するパラダイムの変更や、組織内のすべての事業部の参加を必要とする変更を実施するには、複数のデータセンターにまたがり、多数の IT グループと協力する、施設グループ間での調整が必要です。このような組織上の問題は、省エネルギー プログラムを導入する際に最大の障害となります。
データセンター全体の電力消費状況を把握するための担当スタッフまたはチームを用意することが重要です。ほとんどの企業では、電力消費に関しては、このような一元的な情報管理職が用意されていませんが、これを設けることは非常に重要です。また、ツールで異なる施設のデータを同じ方法で収集し、一定の方法で各事業部に結果が報告されるようにすることも重要です (図 4 は、レポート データを示すダッシュボードの例です)。
図 4 世界規模のデータ監視ダッシュボードの例 (OSIsoft 提供)
図 4 世界規模のデータ監視ダッシュボードの例 (OSIsoft 提供)
適切な計測方法がなければ、本当に効率よく運用しているかどうかを知ることはできません。また、各事業部が、それぞれの取り組みが成果を上げているかどうかを知ることもできません。人々の行動を本当に変えるのであれば、ユーザーにリアルタイムの情報を履歴データの傾向と共に提供し、自分たちの行動の成果を視覚的に把握できるようにする必要があります。各事業部が運用しているシステム、使用しているツール、および成果の報告に使用している計測方法が異なる場合、省エネルギーを実現したグループに適切な報酬を与えることはできません。

業界の取り組み
さまざまな組織が、環境配慮型事業への取り組みを進めています。他業界のリーダー (ボーイングやトヨタなどの企業から、カリフォルニア州政府などの政府機関まで) が、運用と製品のエネルギー効率の向上を図り、かなりの投資を行っています。
IT 業界に関しては、2006 年に米国の下院によって法案 H.R. 5646 （現在は公法 109-431) が可決されました。これにより、環境保護庁 (EPA) が、サーバーとデータセンターのエネルギー コストと電力消費、およびエネルギー効率のよいシステムに移行した場合の効果について調査することになりました。この調査は、EPA プログラムの 1 つである ENERGY STAR によって実施され、米国のコンピュータ サーバーとデータセンターで使用される電力量の増加に関する短期の予測、コンピュータ サーバーとデータセンターのエネルギー効率が向上した場合のコストと省エネルギー効果の見積もり、エネルギー効率のよいコンピュータ サーバーやデータセンターの普及を促進するための報奨プログラムまたはボランティア プログラムについての見通しが報告されました。この調査の最終結果は、2007 年 8 月に連邦議会に提出されました。この調査の詳細については、energystar.gov を参照してください。
環境配慮型の建築物に関する新しい建築基準法の策定も進められています。この基準法では、目的やエネルギー消費量に応じた回路のサブ メータリングを 1 時間ごとに実行する、建築物メーターを使用してエネルギー消費に関するデータをメーター データ管理システムに伝達する、メーター データ管理システムを使用して、データを格納しメーターごとの 1 時間、1 日、1 か月、および 1 年のエネルギー消費量の算出値が記載されたユーザー レポートを作成するなどの基準が定められています。実施した変更が有効であることを証明する必要がある省エネルギー プログラムに参加した場合 (再生可能エネルギー クレジット、カーボン クレジット、エネルギー節減プログラムなど)、システムはこれらの基準の多くを満たす必要があります。
一部のユーザーから仕様テストの策定が求められていますが、多様なユーザーに適用できるテストを策定することは困難です。テストの標準化に向けた取り組みは進められています。しかし、ほとんどのパフォーマンス テストと同様に、このようなテストは "認識される" 結果の最適化には使用できますが、これらの結果は実際の使用状況を表していません。たとえば、1 ガロンあたりのマイル数 (MPG) について考えてみましょう。この EPA の格付けでは、標準的なドライバが標準的な都市部と高速道路を走行した場合の、ガソリン 1 ガロンあたりの走行距離 (マイル数) を予測しています。ただし、ほとんどのドライバや走行環境は一般的なものではなく、燃費に影響する要因が大きく異なっている可能性があります。これと同じことが、データセンターの省エネルギー化にも当てはまります。各組織の正確な結果は、各自の環境でエネルギーの節約量を計測することでしか得られません。

節約が可能な部分
節約に関する判断を下すときに検討すべき要因は多数あります。たとえば、ある地域で電力が増加した場合のコストを知っていますか。電力による制約を最小限に抑える戦略はありますか。データセンターを電力がより安く入手できる場所に移動することで、問題を解決できますか。既存の施設での運用を改善することに注力すればよいでしょうか。
一部の企業にとっては、コストを削減する一番の方法は、より安い価格で電力が提供されている地域にデータセンターを移動することかもしれません。また、サーバーの仮想化も、エネルギー消費量を削減する方法の 1 つです。実際、一部の電力会社 (PG&E、SoCal Edison、SDG&E など) は、サーバー仮想化プロジェクトを実施し、サーバー機器の削減を実現した顧客に報奨金を進呈しています。
しかし、より簡単で、それほど大掛かりでない行動をとることもできます。ほとんどの IT 部門は、現在、各部門のシステムが消費している電力量をまったく認識していません。つまり、節約を実現できる可能性は十分にあります。手始めに、個々の機器のエネルギー消費量を確認し、機器レベルで変更できることはないか検討します。小さな変更でも多数集まれば、大きな節約につながります。
比較のために、家にある個々の機器が消費している電力量について、住人にまったく知識がない標準的な世帯について考えてみましょう。単純に、毎月請求される電気代だけを支払っている世帯です。この場合、Kill A Watt など、各機器の電力消費量を計測する簡単で安価な機器を使用できます。電子レンジを使用していないときに、電子レンジに供給されている電力はどれくらいでしょうか。電話の充電器を電源につないだままでは、どれくらい電力が消費されるでしょうか。これと同じように、ラックに電力メーターを取り付け、各機器のデータを収集することもできます。エネルギー消費に関する SNMP トラップ機能がある一部のサーバーからは、管理ツールを使用して直接データを収集できます。

取り組みを開始するために
図 5 は、計画を進める際に利用できるベスト プラクティスの概要を示しています。この段階で理解しておく必要があるのは、2 つの対極的な方法のいずれかを選ばなければならないわけではないということです。よりバランスの取れた方法を選択してください。おそらくそのほうが現実的です。草の根レベルの取り組みから始めて、社内で省エネルギーに熱心な人を見つけてください。事業部内の一部の機器を計測し、使用状況を目に見える形で提示してください。勢いを得て、定量化できる結果を示すことにより、企業の環境配慮型事業への投資を拡大するために必要な支持を得ることができます。
Figure 5 省エネルギー計画を実施するための重要事項 (Close Figure 5)

現在のシステムの状態を把握するために、手動でデータを収集します。機器やアプリケーションが消費する電力量を特定し、コストを分析します。
変更の有効性を測るために、閉ループ フィードバック システムを作成します。
適切な場所および適切なレベル (機器、IT 組織、事業部、アプリケーションなど) で電力消費を監視するようにします。
投資資金を集めるために、省エネルギー プロジェクト用基金を設立します。
組織内で省エネルギー化を推進できる人々を見つけ、参加してもらいます。
社内で省エネルギーを推進しそうな人はだれでしょうか。その人物は上層の幹部社員ですか、中間管理職、または会社が環境に与える影響を気にかける一社員でしょうか。どの企業にも、熱心な人がいます。まず決定しなければならないことは、草の根レベルの方法を試して、取り組みを始める時点からこのような人々に参加してもらうかどうかです。
最終的に、どのような方向に進むとしても、データセンターの省エネルギー プログラムを計画する場合は、IT グループ間の協力が必要です。最近まで、IT ソリューションの一般的な計画では、初期段階の設計フェーズで電力コストを無視し、購入するハードウェアとソフトウェア、ソリューションにかかる人件費とホスティング コストしか考慮していませんでした。データセンターでのソリューションの運用にかかる一般管理費に電力費が埋もれているときは、省エネルギー化の優先度は高くありません。ソリューションが消費している実際の電力量を提示することが、組織の行動を変えるための最初の重要なステップです。

Dave Ohara は、テクノロジ分野で 26 年にわたる経験を持ち、マイクロソフト、Apple、Hewlett-Packard などでの勤務歴があります。これまでは、製品開発、マーケティング、技術エバンジェリズム、インフラストラクチャ アーキテクチャ、プロセス エンジニアリング、信頼性エンジニアリング、および流通ロジスティクスに携わり、現在は、グリーン イニシアチブに取り組む複数の企業に協力しています。
© 2007 Microsoft Corporation and CMP Media, LLC. All rights reserved; 許可なしに一部または全体を複製することは禁止されています.


 Windows の管理: Active Directory レプリケーション ガイド
Windows の管理 Laura E. Hunter

Active Directory レプリケーション ガイド
概要:
  • Active Directory に移行する
  • 整合性を維持する
  • 競合の解決に対処する
  • Windows Server 2008 での変更点

Windows 2000 Server と Active Directory が導入されるまで、多くの企業環境では、サーバー インフラストラクチャに Windows NT を使用して、ID やアクセスを管理していました。
Windows NT® 4.0 がリリースされる頃には、Windows NT は安定したネットワーク オペレーティング システム (NOS) になっていましたが、大規模な企業で展開することを考えた場合、多くの欠点がありました。
まず、Windows NT は、フラットな名前空間を使用してネットワーク リソースを格納していました。つまり、リソースを複数の小さなサブセットに分割したり、きめ細かな管理を構成したりすることはできませんでした。たとえば、マーケティング部門のリソースを格納する部門用のコンテナを構成したり、部門内のユーザーのパスワードのみを再設定できる権限を持つローカル管理者を構成したりすることはできませんでした。このため、Windows NT のセキュリティは、ほぼ "全か無" でした。管理タスクをデスクトップ サポート エンジニアに委任する必要がある場合、自分がそのタスクを実行する場合よりもはるかに強力な権限を与えなければならないことがほとんどでした。
また、Windows NT は、サイズが 40 MB を超えることが想定されていない、セキュリティ アカウント マネージャ (SAM) データベースにすべての情報を格納していました。使用中の SAM データベースがこの推奨最大サイズを超えた場合 (構成にもよりますが 25,000 ～ 40,000 個のオブジェクトを格納した時点でこのサイズに達します)、環境を複数のドメインに分割する必要があったため、ネットワークを管理する作業や、ユーザーにリソースへのアクセスを提供する作業が複雑になりました。各 NT ドメインには 1 台のプライマリ ドメイン コントローラ (PDC) が存在し、このコンピュータに SAM データベースの唯一の読み取りおよび書き込み可能なコピーが格納されていました。1 台以上のバックアップ ドメイン コントローラ (BDC) を展開してフォールト トレランスを確保することもできましたが、これらの BDC は読み取り専用であったため、書き込み操作を必要とする、ユーザーのパスワードの変更などの更新操作を実行することはできませんでした。
さらに、Windows NT は NetBIOS 名前解決を使用していました。これはブロードキャストに基づいた解決方法であるため、ユーザーがネットワーク リソースを (特に低速または使用率が高い WAN リンクを経由して) 参照すると、多くの場合、膨大な量のトラフィックが生成されました。

新しいモデルの登場
2000 年にリリースされた Windows® 2000 では、それまで提供されていた NOS 製品が一新されました。新しい NOS サービスである Active Directory® は、想像どおり Windows NT とは異なるものでした。Active Directory は、X.500 標準に基づいて構築されたため、フラットな名前空間が使用されなくなり、階層的な組織構造が提供されました。これにより、リソースを 1 つのドメイン内にある複数の組織単位に分類し、各 OU の管理をタスク レベルで委任できるようになりました。
Windows NT からのもう 1 つの大きな変更点は、マルチマスタ レプリケーションのモデルが新しくなったことです。Windows NT では 1 台の書き込み可能な PDC と、それに関連付けられた BDC が使用されていましたが、Active Directory では、各ドメイン コントローラが Active Directory データベースへの書き込みを実行できるようになりました。
しかし、大規模な環境や分散環境をサポートできる柔軟性が提供された一方で、Active Directory の整合性の維持という新たな課題も生まれました。John Smith と Jane Dow が、国内の離れた位置にあるそれぞれのオフィスで同じオブジェクトに変更を加えたときに、それらの変更が競合したらどうなるでしょうか。Active Directory のレプリケーション モデルでは、更新を環境内のすべてのドメイン コントローラに伝達する方法だけでなく、実質上どの場所からでも変更を加えることができるマルチマスタ レプリケーションで発生した競合に対処する方法も定義されています。

Active Directory レプリケーションのしくみ
この記事の例では、サイト内レプリケーションについてのみ説明します。基本的に、サイト内レプリケーションは変更をすばやく同じサイト内の DC にレプリケートすることを目的としており、変更通知を使用して実行されます。サイト内レプリケーションでは、DC1 でレプリケーションが必要な変更が発生したことを DC1 が DC2 に通知した後、DC2 がその変更を DC1 からプルします。同様に、DC2 で変更が発生したことを DC2 が DC1 に通知した場合、DC1 はその変更を DC2 からプルします。おわかりのように、Active Directory のすべてのレプリケーションは、プッシュ操作ではなくプル操作によって実行されます。
Active Directory には数十万または数百万個のオブジェクトが格納される可能性があるため、Active Directory データベースを名前付けコンテキストと呼ばれるセクションに分割する必要があります。各ドメイン コントローラにある Active Directory データベースのローカル コピーには、3 個以上の NC が格納されます。
スキーマ NC この NC は、フォレスト内の他のすべてのドメイン コントローラにレプリケートされます。この NC には、Active Directory 内のさまざまなオブジェクトのクラスと属性を定義する Active Directory スキーマに関する情報が格納されます。
構成 NC この NC も、フォレスト内の他のすべての DC にレプリケートされます。この NC には、Active Directory の物理的なレイアウトに関係するフォレスト全体の構成情報、および表示指定子とフォレスト全体の Active Directory クォータに関する情報が格納されます。
ドメイン NC この NC は、1 つの Active Directory ドメイン内の他のすべての DC にレプリケートされます。この NC には、特定の Active Directory ドメイン内に存在する実際のユーザー、グループ、コンピュータ、その他のオブジェクトなど、最もアクセス頻度の高い Active Directory データが格納されます。
各名前付けコンテキストは別々にレプリケートされるため、レプリケーション トラフィックが最適化されます。つまり、変更頻度が少ない NC (スキーマ NC など) がレプリケートされることによって、変更頻度が多い NC (ドメイン NC など) のレプリケーションに使用されるネットワーク帯域幅が狭くなることはありません。
ディレクトリの変更は、どの Active Directory DC からでも実行される可能性があるため、Active Directory レプリケーションは 2 種類の書き込み操作を追跡する必要があります。1 つは、特定の DC に直接変更が加えられたときに発生する、変更元の書き込みです。たとえば、DC1 に接続してユーザーのパスワードを変更した場合、DC1 ではその変更が変更元の書き込みと見なされます。Active Directory が追跡するもう 1 つの書き込み操作は、レプリケーション書き込みです。ご想像どおり、これは別のドメイン コントローラから変更がレプリケートされたときに発生します。DC1 で変更元の書き込みと見なされた変更は、DC2、DC3、およびドメイン内の他の DC にレプリケートされるときにはレプリケーション書き込みと見なされます。
Active Directory のドメイン コントローラでは、レプリケーション メタデータを使用して、ディレクトリに加えられた変更の転送が管理されます。つまり、Active Directory は、変更された実際のデータ ("人事部長" に変更された John Smith の説明など) をある DC から別の DC に転送するだけでなく、変更が発生した DC、変更が発生した時間、その他の重要な情報など、発生した変更に関する追加情報も転送します。DC は、これらの情報を使用して、レプリケーションを最も効率的な方法で管理できます。
まず、更新シーケンス番号 (USN) というレプリケーション メタデータについて説明します。各ドメイン コントローラは、そのドメイン コントローラに固有の USN を保持しています。その DC から Active Directory に変更が加えられると、DC の USN は 1 増加します。つまり、ある DC が午前 11 時に 1000 という USN を保持していて、午前 11 時 30 分にその USN が 1005 に変更されていた場合、その DC から Active Directory データベースに 5 回変更が加えられたことになります。USN にとって、変更の内容は重要ではありません。DC の USN は、5 個の異なるオブジェクトが変更、作成、または削除された場合でも、これらの操作のいくつかが数回ずつ実行されて合計 5 回になった場合でも、5 増加します。また、USN は、特定のドメイン コントローラの内部のみで使用されるデータであり、他の DC の USN と関連し合うことはありません。ドメイン内のある DC で午前 11 時 30 分に変更が発生し、このドメインに USN 1051 が割り当てられたとします。また、同じドメインの 2 番目の DC で、まったく同じ時刻に変更が発生し、このドメインに USN 5084 が割り当てられたとします。これら 2 つの DC は、ほぼ同じ時刻に発生した変更に対してまったく異なる USN を割り当てられていますが、このことは、これらの変更のレプリケーション方法とは無関係です。つまり、ある DC の更新シーケンス番号を他の DC と比較することによって、両者で発生した変更を比較することはできません。
DC の USN が 1 増加するのは、その DC で変更が発生したときだけではありません。Active Directory データベースへの変更は、変更元の書き込みまたはレプリケーション書き込みから構成されるということを思い出してください。ドメイン コントローラの更新シーケンス番号は、どちらの種類の書き込み操作が発生しても増加します。つまり、別の DC から変更がレプリケートされたときにも増加するということです。このため、各 DC には、どの変更が既にレプリケートされたかを追跡する方法が必要です。追跡する方法がなければ、レプリケーションが発生するたびに Active Directory データベース全体をネットワーク経由で送信することになります。このような状況を回避するために、各 Active Directory ドメイン コントローラは、レプリケーション パートナーである他のドメイン コントローラの警告を発生させるベクタ (HWMV : High Watermark Vector) の値を保持しています。各 DC は、リモート DC の名前が変更されたときや、リモート DC がディレクトリから削除されたときに問題が発生しないように、この HWMV をリモート DC のグローバル一意識別子 (GUID) と関連付けています。
まずは簡単な例で説明しましょう。contoso.com ドメインで 2 台のドメイン コントローラ dc1.contoso.com と dc2.contoso.com が構成されていたとします。contoso.com ドメインの DC は 2 台のみであるため、DC1 と DC2 の間でのみレプリケーションが発生します (この簡単な例で Active Directory レプリケーションのすべてのシナリオを説明することはできません。後ほどこの例を複雑にして、さらに詳しい説明を行います。)
この例では、DC1 の USN が 3000、DC2 の USN が 4500、およびこれら 2 つの DC が相互に最新の状態になっているとします。
段階 1: DC1 と DC2 の状態は相互に最新になっています。DC1 が保持している DC2 の HWMV は 4500、DC2 が保持している DC1 の HWMV は 3000 です (図 1 を参照)。
図 1 2 台の DC の現在の状態
図 1 2 台の DC の現在の状態
段階 2: 管理者が DC1 に新しいオブジェクトを作成し、これによって DC1 の USN が 3001 に増加します (図 2 を参照)。DC2 が保持している DC1 の HWMV が変更されていないことに注目してください。これは、DC1 が変更を保持していることをまだ DC2 に通知していないためです。
図 2 新しいオブジェクトの追加
図 2 新しいオブジェクトの追加
段階 3: DC1 が、変更を保持していることを DC2 に通知します。その後、DC2 が DC1 との間でレプリケーションを開始し、その変更を要求します。DC2 は、この要求の一部として、自身に格納されている DC1 の HWMV を DC1 に送信します (図 3 を参照)。
図 3 変更の通知
図 3 変更の通知
段階 4: DC1 が、USN 3001 に対応する変更、つまり段階 2. で DC1 に作成されたオブジェクトを DC2 に送信します。DC2 は自身の USN を 4501、自身が保持している DC1 の HWMV を 3001 にそれぞれ更新します (図 4 を参照)。
図 4 変更と更新
図 4 変更と更新
ここまでは順調ですね。しかし、ここで 1 つ問題があります。それは、DC2 で発生した変更を DC1 にレプリケートする必要があるということです。この変更が USN と HWMV のみであった場合、ここで DC2 は DC1 にアクセスし、DC1 が DC2 にレプリケートしたものと同じ変更を DC1 にレプリケートします。この結果、無限にレプリケーションが発生し続け、徐々に使用可能な帯域幅が狭くなります。この問題を解決するには、さらに何個かパズルのピースが必要です。その 1 つ目は、最新ベクタ (UTD ベクタまたは UTDV) です。
UTDV は、伝達をダンプするために使用されるレプリケーション メタデータです。つまり、同じ変更をネットワーク経由で何回もレプリケートすることによって帯域幅が無駄に使用されることを防ぐために、このデータが使用されます。各 DC は、特定の名前付けコンテキストの複製が格納された他のすべての DC の UTDV が記録されたテーブルを保持しています。ドメイン NC の場合、ドメイン内の各 DC は、ドメイン内のすべての DC の UTDV を保持します。構成 NC とスキーマ NC の場合、各 DC はフォレスト内のすべての DC の UTDV を保持します。UTDV テーブルは、各 DC がそれぞれのレプリケーション パートナーから受信した USN の最高値だけでなく、特定の NC をレプリケートしているすべての DC から受信した USN の最高値も追跡します。レプリケートされる各変更には、この追跡を実現する次の情報が含まれています。
  • 変更をレプリケートしている DC の GUID。この変更は、変更元の書き込みまたはレプリケーション書き込みとしてレプリケートされています。
  • 変更をレプリケートしている DC の USN。この変更は、変更元の書き込みまたはレプリケーション書き込みとしてレプリケートされています。
  • 変更が発生した DC の GUID。この GUID が変更をレプリケートしている DC の GUID と一致する場合、この変更は変更元の書き込みとしてレプリケートされています。GUID が一致しない場合は、UTDV テーブルが使用されます。
  • 変更が発生した DC の USN。この USN が変更をレプリケートしている DC の USN と一致する場合、この変更は変更元の書き込みとしてレプリケートされています。USN が一致しない場合は、UTDV テーブルが使用されます。
この処理をわかりやすく説明するために、上記の例の構成を複雑にし、3 番目のドメイン コントローラである DC3 を追加します。この場合、DC1、DC2、および DC3 は、すべてが相互にレプリケーション パートナーの関係にあります。つまり、DC1 の変更は DC2 と DC3、DC2 の変更は DC1 と DC3、DC3 の変更は DC1 と DC2 にそれぞれレプリケートされます。
段階 1: DC1、DC2、および DC3 は、すべて相互に最新の状態になっています。
段階 2: DC3 が変更元の書き込みを 1 回実行します。内容は、ユーザー アカウント jsmith のパスワードの再設定です。DC3 は、変更を保持していることを DC1 と DC2 に通知します。DC1 と DC2 は、変更元の書き込みを DC3 からプルした後、各自の HWMV テーブルと UTDV テーブルに格納されている DC3 の値を更新します (図 5 を参照)。
図 5 HWMV テーブルと UTDV テーブルの更新
図 5 HWMV テーブルと UTDV テーブルの更新
段階 3: ここで、最新ベクタが使用されます。DC2 は、変更を保持していることを DC1 に通知します。次に DC1 は、DC2 に次の情報を送信することによって新しい変更を要求します。
  • DC1 に格納されている DC2 の HWMV の値 (この場合は 4501)。
  • DC1 の UTDV テーブル (図 6 を参照)。このテーブルには、DC1 が DC3 を含むすべての DC から受信した、変更元の USN の最高値が格納されています。
Figure 6 UTDV テーブル (Close Figure 6)

この NC をレプリケートするすべての DC | UTDV
<DC2 の GUID> | 4501
<DC3 の GUID> | 7002
DC2 は、4501 という HWMV に基づいて、該当する変更を DC1 にレプリケートしたことがないことを認識します (図 7 を参照)。
Figure 7 レプリケートが必要な変更 (Close Figure 7)

プロパティ | 値 | ローカル DC の GUID | ローカル DC の USN | 変更元 DC の GUID | 変更元 DC の USN
jsmith のパスワード プロパティ | %#FH%2rfg2 | <DC2 の GUID> | 4501 | <DC3 の GUID> | 7002
しかし、DC2 は、レプリケーションの開始前に DC1 から受信した UTDV テーブルに基づいて、DC1 はその変更を既に DC3 から受信しているため、実際にはその変更を必要としていないと判断します。ここで、DC1 は自身の HWMV テーブルに格納されている DC2 の値を更新して、増加した USN を反映します (図 8 を参照)。帯域幅を節約するために、実際のデータは送信されません。
図 8 伝達のダンプ
図 8 伝達のダンプ
段階 4: この伝達のダンプは、DC2 が変更を保持していることを DC3 に通知した場合や、DC1 が変更を保持していることを DC2 と DC3 に通知した場合にも発生します。3 台の DC は、それぞれの HWMV テーブルに格納されている各レプリケーション パートナーの値を更新します (図 8 を参照) が、実際のデータは既に段階 2. で各 DC に転送されているため、再度ネットワーク経由で送信されることはありません。

マルチマスタ環境での競合解決
ここまでの例では、1 人の管理者が同時に 1 台の DC に変更を加えていたため、各変更が競合することもなく、問題は発生しませんでした。しかし実際には、このようなことはめったにありません。Active Directory オブジェクトは、ドメイン内のどのドメイン コントローラからでも更新される可能性があるため、2 人の管理者が 2 台の異なるドメイン コントローラから加えた変更が競合することも考えられます。Active Directory 環境で発生する可能性がある競合は 3 種類あり、解決方法もそれぞれ異なります。
プロパティの変更の競合 この競合は、2 人の管理者が、競合する方法で同じオブジェクトを更新した場合に発生します。たとえば、1 人の管理者があるユーザーの説明を "マーケティング" に設定し、異なる DC を管理している別の管理者がそのユーザーの説明を "販売およびマーケティング" に設定した場合などがあります。
作成した新しいオブジェクトの競合 この競合は、2 人の管理者が、同時に同じ名前のオブジェクトを作成した場合に発生します。たとえば、jsmith という名前のユーザーが 2 人同時に作成された場合などがあります。
削除されたコンテナ内に移動されたオブジェクトの競合 この競合が発生することはほとんどありません。この競合は、1 人の管理者がコンテナ内のオブジェクト (OU など) を作成または移動したのと同時に、異なる DC を管理している別の管理者がそのコンテナを削除した場合に発生します。
ここで、最初の 2 つの種類の競合を解決するために、主に競合の解決に使用される 2 つのレプリケーション メタデータを紹介します。バージョン ID の値は、オブジェクトの個々の属性に割り当てられています。初期値として、そのオブジェクトの作成時に 1 が割り当てられます。バージョン ID は、いずれかの DC が個々の属性に変更を加えると 1 増加します。このため、特定のユーザーの説明属性が既定値 (空または <not set> (未設定)) から "マーケティング部門" に変更された場合、説明属性のバージョン ID は 2 になります。その後説明が "販売およびマーケティング部門" に変更された場合、バージョン ID は 3 になります。バージョン ID は、これまでに紹介した他のメタデータと共に、すべてのレプリケーション エントリに格納されています。
バージョン ID は、レプリケーション トラフィックの削減にも使用できます。たとえば、DC2 の管理者が (入力ミスなどにより) 1 つの属性に複数回変更を加え、その結果 DC2 でバージョン ID 2、3、4、および 5 に対応する変更元の書き込みが発生した場合、最新のバージョン ID である 5 に対応する書き込みのみがレプリケートされます。どのような場合でも古い変更はすべて上書きされるため、この属性を使用することにより、複雑な作業を行うことなく、無駄に帯域幅を使用するトラフィックを削減できます。
Active Directory に加える変更には、競合の解決に使用されるもう 1 つのレプリケーション メタデータであるタイムスタンプが含まれています。このデータは、変更が加えられた日時を示しています。
タイムスタンプ属性は、Active Directory レプリケーションの状態を事前に確認する方法としても使用されます。ある DC が特定の DC から最近のタイムスタンプの変更を受け取っていない場合、その DC で問題が発生している可能性があることを示すエラー メッセージが生成されます。
では、これら 2 つの属性はどのようにして競合の解決に使用されるのでしょうか。競合の種類ごとに見ていきましょう。

プロパティの変更の競合を解決する
contoso.com ドメインのユーザー オブジェクト jsmith の例で考えてみましょう。まず、DC1 の管理者が jsmith の説明を "マーケティング" に変更します。ほぼ同時に、DC3 の管理者がこのユーザーの説明を "販売およびマーケティング" に変更します。ここで、jsmith の説明に関する DC1 と DC3 の情報が比較されます (図 9 を参照)。
Figure 9 ほぼ同時に発生した変更 (Close Figure 9)

サーバー | プロパティ | 値 | バージョン ID | タイムスタンプ | ローカル DC の GUID | ローカル DC の USN | 変更元 DC の GUID | 変更元 DC の USN
DC1 | jsmith の説明プロパティ | "マーケティング" | 2 | 2007-06-07 14:03:25 | <DC1 の GUID> | 3003 | <DC1 の GUID> | 3003
DC3 | jsmith の説明プロパティ | "販売およびマーケティング" | 2 | 2007-06-07 14:04:57 | <DC3 の GUID> | 7003 | <DC3 の GUID> | 7003
DC2 は、両方の変更を同時に受信した場合、どちらが "優先度の高い" 変更であるかを特定する必要があります。以下に、競合の解決に使用される条件を、適用される順序に従って示します。
  1. バージョン ID が大きい方の変更が "優先度の高い" 変更として反映され、"優先度の低い" 変更は上書きされます。この場合、どちらのレコードのバージョン ID も 2 であるため、2 番目の条件で比較する必要があります。
  2. レコードのバージョン ID が等しい場合、タイムスタンプの時刻が遅い方の変更が優先度の高い変更として反映され、優先度の低い変更は上書きされます。この場合、DC3 で発生した変更元の書き込みのタイムスタンプの時刻の方が遅いため、jsmith の説明は "販売およびマーケティング" に設定されます。このようなことはめったにありませんが、バージョン ID とタイムスタンプが両方とも等しい場合、確実に優先度を決定できる 3 番目の条件が必要です。
  3. バージョン ID とタイムスタンプが両方とも等しい場合、DC から生成されたときに割り当てられた GUID の番号が小さい方の書き込みが優先され、GUID の番号が大きい方の書き込みは上書きされます。このため、DC1 の GUID が 1234567890、DC3 の GUID が 2345678901 である場合、DC1 で発生した変更元の書き込みが優先されます。
タイムスタンプを 1 つ目の条件にした方が理にかなっていると思うかもしれませんが、理屈はそれほど単純ではありません。Active Directory の競合を解決するための 1 つ目の条件としてタイムスタンプを使用した場合、悪意のある管理者は、管理している DC の時刻を遅らせるだけで、タイムスタンプを比較したときにその DC の変更が常に優先されるため、自分が加えた変更を伝達することができます。

作成した新しいオブジェクトの競合を解決する
同時に 2 つのオブジェクトが作成された場合、Active Directory は、既に説明した 3 つの条件を使用して、優先度の高いオブジェクトを決定します。ただし、上記の場合とは異なり、優先度の低いオブジェクトは上書きされず、オブジェクト名が変更されます。変更後の名前には CNF (競合したオブジェクトを表します) という文字列が使用され、その後にコロンと優先度の低いオブジェクトの GUID が続きます。これにより、管理者は保持する必要があるオブジェクトと削除する必要があるオブジェクトを、さらに体系的に決定できるようになります。

削除されたコンテナ内に移動されたオブジェクトの競合を解決する
既に説明したとおり、削除されたコンテナ内に移動されたオブジェクトの競合が発生することはほとんどありません。この競合は 2 つのシナリオのいずれかでのみ発生します。1 つは、ある DC の管理者が "トレーニング" OU などの特定のコンテナ内にオブジェクトを作成し、同時に別の DC の管理者が "トレーニング" OU を削除した場合です。もう 1 つは、ある DC の管理者がコンテナ内にオブジェクトを移動したのと同時に、別の DC の管理者がそのコンテナを削除した場合です。
この場合の解決方法は非常に単純です。Active Directory は、"不明な" オブジェクトを、Active Directory 内の特殊なコンテナである LostAndFound コンテナに移動します。これは不明なオブジェクトを格納するためのコンテナであり、各 Active Directory ドメインのルートにあります。contoso.com ドメインの場合、LostAndFound コンテナは LDAP://cn=LostAndFound,dc=contoso,dc=com という LDAP パスにあります。Active Directory ユーザーとコンピュータ スナップインを起動したときに LostAndFound コンテナが表示されない場合は、[表示] メニューの [拡張機能] をクリックします。

USN のロールバックを回避する
Active Directory 環境で発生する最悪の状況の 1 つは、その原因と回避策を理解すれば最も簡単に回避できる状況でもあります。USN のロールバックは、ネットワーク上で発生しているレプリケーションが完全に停止する可能性のあるエラー状態です。この状態は、ドメイン コントローラを長時間オフラインにしてからオンラインに戻した場合や、サポートされていない方法を使用してドメイン コントローラを復元した場合などに発生します。
USN のロールバックが発生する根本的な原因は、Active Directory マルチマスタ環境でオブジェクトの削除が処理される方法と関係しています。ある DC でオブジェクトを削除したが、完全には削除していない場合、そのオブジェクトは廃棄済みオブジェクトとして他の DC にレプリケートされ、削除されたことがそれらの DC に通知されます。廃棄済みオブジェクトへの変更で最も顕著なのは、isDeleted 属性が TRUE に設定されることです。廃棄済みオブジェクトに変更された場合、サイズを減らすために、ユーザー オブジェクトの説明、個人情報、グループ メンバシップなど、そのオブジェクトに格納されているほとんどの値が削除されます。この処理の詳細については、Gil Kirkpatrick の記事「Active Directory の廃棄済みオブジェクトを復元する」(technetmagazine.com/issues/2007/09) を参照してください。
USN のロールバックは、これらの廃棄済みオブジェクトが永久に存在し続けないことが原因で発生する場合があります。これらは、既定で 60 日後または 180 日後に Active Directory データベースから完全に削除されます (この期間は、最初に Active Directory 環境を作成したときに実行していた Windows Server® のバージョンによって異なります)。この 60 日または 180 日の期間を廃棄済みオブジェクトの有効期間といいます。この期間中に、すべてのドメイン コントローラを 1 回以上レプリケートする必要があります。1 回もレプリケートされなかった場合、問題はないが有用性もないドメイン コントローラと見なされ、その結果 USN のロールバックが発生する可能性があります。基本的に USN のロールバックは、ドメイン コントローラが完全に古くなり、1 つ以上の廃棄済みオブジェクトが完全に削除されたことによって、最新の完全な Active Directory データベースのローカル コピーを他の DC にコピーできなくなったときに発生します。この問題を回避するには、オフライン期間が廃棄済みオブジェクトの有効期間を過ぎたドメイン コントローラをオンラインに戻さないようにする必要があります。代わりに、マイクロソフト サポート技術情報の資料 216498 (support.microsoft.com/kb/216498) の手順に従って Active Directory から古い DC のメタデータを削除した後、ドメイン コントローラを最初から再構築してください。
USN のロールバックが発生する 2 つ目のシナリオは、サポートされていない方法でドメイン コントローラが復元された場合です。最もよくあるのは、ディスク複製ツールやディスク イメージング ツールを使用した場合です。このシナリオでロールバックが発生した場合、復元された Active Directory データベースは、自身の状態が "戻された" ことを認識しません。これは、復元方法が Active Directory に対応していなかったためです。Windows 2000 と Windows Server 2003 の最初のリリースでは USN のロールバックを検出するのは困難でしたが、Windows Server 2003 SP1 (および今後リリースされる Windows Server 2008) には、DC が適切に復元されなかったことを検出するコントロールが組み込まれています。これらの新しい OS のバージョンでは、DC がイベント ID 1115、2095、2103、および 2110 をディレクトリ サービス イベント ログに記録します。これらのイベントの内容と、Windows Server 2003 で USN のロールバックから DC を回復させる方法については、サポート技術情報の資料 875495 (support.microsoft.com/kb/875495) を参照してください。Windows 2000 で USN のロールバックに対処する方法については、サポート技術情報の資料 885875 (support.microsoft.com/kb/885875) を参照してください。

Windows Server 2008 で更新されたマルチマスタ モデル
間もなくリリースされる Windows Server 2008 では、読み取り専用ドメイン コントローラ (RODC) の導入によって、マルチマスタ モデルが若干変更されます。RODC は、主にブランチ オフィスへの展開を行う場合や、特定の場所に専任の IT スタッフを配置しておらず、特定の DC の整合性を維持するために追加の作業を行う必要があるシナリオで使用することを目的としています。RODC の技術的な詳細をすべて説明するには 1 つの記事全体が必要になるため、ここでは知っておいたほうがよい重要な点のみを概説します。
その名前が示すとおり、RODC に格納された Active Directory データベースのコピーは読み取り専用です。RODC に接続すると、必要なほとんどの情報を読み取ることができますが、RODC への書き込み操作を実行することはできません。
また、RODC は出力方向のレプリケーションを実行しません。これは、ここまで説明してきたマルチマスタ レプリケーション モデルからの抜本的な変更です。RODC は、他の書き込み可能な Windows Server 2008 DC から入力方向のレプリケーションを受信しますが、他の DC に情報をレプリケートすることはありません。これにより、悪意のあるユーザーが何らかの方法で RODC から Active Directory を変更できた場合でも、それらの変更が環境内の他の部分に伝達されないため、セキュリティが強化されます。
さらに、皆さんにとって最も興味深いことかもしれませんが、RODC は既定でユーザーのパスワードをレプリケートしません。Active Directory データベースの入力方向のレプリケーションが、書き込み可能な DC から RODC に対して実行された場合、すべてのユーザー オブジェクトのパスワードに関する情報はレプリケートされません。これにより、DC が盗まれた場合でも、DC のハード ドライブにパスワードの情報は格納されていないため、ブランチ オフィスのセキュリティが強化されます。全体として見ると、最初に考案されたマルチマスタ Active Directory レプリケーションにこのような変更が加えられた新しいモデルでは、ブランチ オフィスや他の遠隔地にあるドメイン コントローラのセキュリティが大幅に強化されました。

Laura E. Hunter は、Windows Server のネットワークの分野で、Microsoft MVP を 4 回受賞しています。彼女は IT 業界に携わって 10 年のベテランであり、『詳説 Active Directory 第 2 版』(O'Reilly、2006 年) をはじめ、個人または共同で、IT 関連の書籍、記事、ホワイト ペーパーなどを多数執筆しています。


 System Center: 新しいソフトウェア更新プログラムの管理ツール
System Center Steve Rachui

新しいソフトウェア更新プログラムの管理ツール
概要:
  • 従来の更新プログラムの管理方法
  • SCCM 2007 の新しいプロセス
  • カスタム構成と柔軟性
  • 細かく調整された更新スケジュール

ソフトウェア更新プログラムを管理する機能は、Systems Management Server (SMS) 2.0 のセキュリティ更新プログラムおよび Office 更新プログラムのスキャン ツールで初めて導入されました。これらのツールは、改訂が何回も行われました。Extended
Security Update Inventory Tool は、追加の製品のスキャンをサポートするように改訂されました。Inventory Tool for Microsoft® Updates は、セキュリティ ツールと Office ツールを 1 つの製品に統合するように改訂されました。また、Inventory Tool for Dell Updates も改訂されました。サードパーティ製品への修正プログラムの適用をサポートするために、カスタム更新プログラム用の発行ツールも導入されました。Inventory Tool for Microsoft Updates (ITMU) だけをとっても、3 回の改訂を行いました。これらの各ツールには、独自のカタログ、スキャン インフラストラクチャ、および独自の要件や課題があります。これらのシステムのカタログは、時間の経過と共に非常に大きくなり、サイズの制限により、新しい更新プログラムを優先して古い更新プログラムは削除されていました。
さまざまなオプションがあるため、これらのツールを使用して更新プログラムを展開することは困難な場合があります。明らかに、このプロセスを簡略化する必要がありました。SMS の次期リリースである System Center Configuration Manager 2007 (SCCM) は、その点で大きく進歩しました。SCCM では、ソフトウェアの更新メカニズムは、確実により良い結果が得られるように構築されています。完全に異なる手法で更新プログラムの管理操作を行うため、従来のカタログやスキャン エンジンは廃止されます。従来はハードウェア インベントリを使用していた更新の状態の報告では、state message (状態メッセージ) という新しいメカニズムが採用されました。このメカニズムによって、各クライアントの対応状況と適用状況を確実に特定できるようになります。 SCCM 2007 の更新プログラムの新しい管理手法では、大幅な機能強化を実現しています。
SCCM 2007 では、次の 2 つの新しいコンポーネントが導入されています。これについては、更新プログラムの管理機能について詳しく説明する前に紹介します。
Software Update Point (ソフトウェア更新ポイント、SUP) 既にに説明したように、SCCM ではカタログはありません。代わりに、SCCM は専用の Windows Server® Update Services (WSUS) サーバーと直接やり取りをします。このサーバーは、Software Update Point (ソフトウェア更新ポイント、SUP) として機能し、メタデータのダウンロードやクライアントのスキャン機能を提供します。SCCM では、スキャン プロセスに重点を置くことができるように、WSUS の更新バイナリの配布機能が無効になっています。この調整により、WSUS は、専用サーバーの SUP ごとに 25,000 台までのクライアントのスキャンを処理するように拡張できます。SCCM では、可用性やスケールを向上するために、ネットワーク負荷分散 (NLB) クラスタの外部に SUP を構成し、各プライマリ サイトで、最大 4 つの SUP を有効にして、合計 100,000 台のクライアントを処理することができます。
構成アイテム (CI) 構成アイテムは、展開先のシステムに必要な特定の構成を定義するために、SCCM で使用される新しい手法です。SCCM の更新プログラム管理機能では、このインフラストラクチャを使用するようになりました。似ている点はありますが、更新プログラムは、通常のソフトウェア配布とは異なるものだと考える必要があります。更新プログラムは、管理コンソールのそれ専用のノードに配置され、この特殊な CI メカニズムを使用します。クライアント側では、更新プログラムは選別してダウンロードされ、ローカルに保存されます。

更新プログラム管理を構成する
更新プログラム管理のセットアップには、通常、3 つの領域 (クライアント エージェントの有効化、SUP の構成、および更新プログラムを配布するための構成) があります。
SCCM クライアント エージェント (図 1 参照) は、他のクライアント エージェントと同様で、管理コンソールのノードと同じノードで構成されます。[Software Updates Client Agents] (ソフトウェア更新クライアント エージェント) ノードのプロパティ ページでは、このエージェントを有効にし、更新プログラムのインストールと Deployment Re-evaluation (展開の再評価) の設定を構成します。Software Updates Client Agent (ソフトウェア更新クライアント エージェント) を有効にする設定は、サイト全体に適用されます。つまり、この機能が有効になっているサイトに割り当てられたすべての SCCM クライアントでは、この役割が有効になります。環境内の一部のシステムでこの機能を無効にする必要がある場合は、ローカル ポリシーの上書き設定を使用して、システム単位でサイト全体の設定を無効にすることができます。
図 1 クライアント エージェントのプロパティ
図 1 クライアント エージェントのプロパティ
この設定では、更新プログラムの期限に関する処理方法を指定することもできます。たとえば、インストールが完了していない 4 つの更新プログラムがあるとします。その中の 1 つ (更新プログラム A) は、他の 3 つよりも期限が 1 日前に設定されています。しかし、期限に達していないものがあっても、4 つの更新プログラムをすべて同時にインストールする方が望ましい場合は、このタブにある [Enforce all mandatory deployments] (必須の展開をすべて適用する) チェック ボックスをオンにして、この構成を実現できます。また、この設定では、管理者は更新プロセスに関するすべての通知や更新プロセスが実行していることを示唆するようなものが表示されないように指定することもできます。これらのオプションは、図 1 に示しています。
[Deployment Re-evaluation] (展開の再評価) タブの設定では、展開を再評価するタイミングをスケジュールできます。SCCM クライアントはこのスケジュールに従って評価され、以前にインストールされた更新プログラムがまだ必要であるかどうかを確認します。このような更新プログラムがインストールされていない場合は再インストールされます。

SUP を構成する
既に説明したように、SUP は、スケジュールに沿ってすべての使用可能な更新プログラムの情報をダウンロードしたり、SCCM クライアントと直接対話して、更新プログラムのデータベースに基づいて対応状況のスキャンを実行したりするコンポーネントです。SUP プロセスでは、WSUS はインストールされず、SCCM を使用するために WSUS を構成するだけなので、SUP を構成する前に WSUS 3.0 以降のサーバーを設置する必要があります。また、WSUS 管理コンソールをサイト サーバーにインストールして、WSUS サーバーとの接続を有効にする必要もあります。SCCM が WSUS サーバーで SUP の役割を有効にすると、WSUS サーバーは SCCM 専用になり、SCCM クライアントだけで使用されるようになります。
SUP は、SCCM の新しいサイト システムの役割です。この役割を構成するには、まず、管理コンソールのサイト システム ノードに移動し、新しいサイト システムを追加します。次に、[Software Update Point] (ソフトウェア更新ポイント) を選択して、ウィザードの指示に従って、次の情報を収集します。
  • プロキシ構成
  • ポート情報と SSL 情報
  • この SUP で更新プログラムを同期する方法 (Microsoft Update から、上位の SUP から、または手動)
  • 同期スケジュール
  • 必要な更新プログラムの分類 (重要な更新プログラム、ドライバ、セキュリティ更新プログラム、更新プログラムのロールアップなど)
  • Windows®、Exchange Server、SQL Server™ など、更新プログラムを入手できる製品 (図 2 を参照)
  • 言語
図 2 New Site Role Wizard (新しいサイトの役割ウィザード) での製品の設定
図 2 New Site Role Wizard (新しいサイトの役割ウィザード) での製品の設定
ウィザードが完了すると、SUP がインストールされ、SCCM の要件をサポートするように内部構成が調整されます。SCCM のインストール先の Logs フォルダにある SUPSetup.log を確認して、インストールが正常に完了したことを確認することをお勧めします。
SUP をインストールしたら、同期を実行して、SUP で更新プログラムを取得して、SUP と SCCM のデータベースに格納する必要があります。同期は、手動で実行するか、SUP のセットアップ ウィザードの実行時に構成したスケジュールに従って実行されます。手動による更新プログラムの同期は、任意の時点で開始できます。SUP が最初にインストールされた後に、同期が行われるようにすることをお勧めします。図 3 に、この操作を行う方法を示します。
図 3 手動による同期の実行
図 3 手動による同期の実行
同期プロセスには、2 つの手順があります。まず、SUP (WSUS) サーバーは SCCM の設定に基づいて構成され、構成された更新プログラムは SUP (WSUS) サーバー自体に同期されます。これが完了したら、SUP (WSUS) の更新情報が SCCM データベースに同期され、更新プログラムの展開で使用できるようになります。この 2 番目の手順によって、ソフトウェア更新プログラムごとに必要な CI が 1 つ SCCM データベースに作成されます。この処理には時間がかかる場合があります。初期同期には数時間かかることがよくあります。同期プロセスは、WSyncMgr ログ ファイルで確認できます。図 4 と図 5 にログ ファイルの抜粋を示します。図 4 は、SUP (WSUS) サーバーが Microsoft Update の更新プログラムの一覧を更新することを要求する同期プロセスを示しています。図 5 は、SUP インベントリを SCCM データベースと同期するプロセスの開始部分を示しています。
図 4 更新プログラム一覧の同期
図 4 更新プログラム一覧の同期
図 5 更新プログラムを CI として SCCM データベースと同期する
図 5 更新プログラムを CI として SCCM データベースと同期する
WSUS サーバーを SUP として構成したら、必要なすべての管理作業は SCCM 管理コンソールで実行できます。構成の変更を WSUS サーバーに対して直接実行すると、SCCM に悪影響を与える可能性があります。また、この構成は、1 時間ごとに SCCM が SUP を調査して構成が正しいことを確認するときにリセットされます。
複数の層で構成された階層では、ソフトウェア更新プログラムを展開するプライマリ サイトごとに、少なくとも 1 つの SUP が必要です。階層内では、これらの SUP は、1 つの SUP (通常は階層の最上位にあるもの) とだけ連動し、Microsoft Update と同期します。それ以外の SUP は、構成済みの上位の SUP レプリケーション パートナーと同期します。

更新プログラムの展開を構成する
クライアント エージェントを構成し、SUP を構成して同期したら、実際の展開を実行できます。まず、SCCM 管理 UI のさまざまなノードについて説明しましょう。基本的に、実際の展開に必要となる主なノードには、[Update Repository] (更新プログラム リポジトリ)、[Update Lists] (更新プログラム一覧)、[Deployment Templates] (展開用テンプレート)、[Deployment Management] (展開管理)、および [Deployment Packages] (展開パッケージ) の 5 つです。
[Update Repository] (更新プログラム リポジトリ) には、同期済みで、展開に使用できるすべての更新プログラムが格納されます。1 つ以上の更新プログラムを選択し、Deploy Software Updates Wizard (ソフトウェア更新プログラムの展開ウィザード) を起動すると、更新プログラムを展開できます。このウィザードでは、展開用テンプレートの構成 (または既存のテンプレートの選択) と、展開自体の構成の 2 つのタスクが実行されます。このプロセスについては、次のセクションで説明します。更新プログラムの一覧は非常に大きくなることがありますが、SCCM 2007 の新機能である検索フォルダを使用すると、重要度、分類、製品、リリース日、優先度などの 28 項目の条件に基づいて、必要な更新プログラムを見つけることができます。
管理者は、更新プログラムの一覧を使用して、管理する更新プログラムの定型セットを作成できます。この一覧は、対応状況に関するレポートの作成、展開の作成、および管理の委任に使用できます。更新プログラムの一覧が作成されると、パッケージや提供情報と同様に、子サイトで再利用するために下位階層にレプリケートされます。更新プログラムの一覧は、レプリケート時には特定の展開には結び付けられておらず、単なる更新プログラムの一覧でしかありません。更新プログラムの一覧が完成してレプリケートされたら、その一覧を選択して更新プログラムを展開するように指定することで、その一覧に含まれる更新プログラムを 1 つの単位として展開できます。

Deployment Templates (展開用テンプレート)
展開用テンプレートには、ソフトウェア更新プログラムの展開中に使用する共通の設定 (スケジュールや展開するコレクションの情報など) が含まれており、更新プログラムの展開に関する管理の作業時間を減らすために開発されました。テンプレートは、環境内の複数の展開条件に対応するために作成することが可能で、展開ウィザードで適切なテンプレートを選択するだけで使用できます。展開用テンプレートであらかじめ構成されている設定には、展開するコレクション、更新プログラムの期限の設定 (図 6 参照)、再起動の設定、メンテナンス期間などがあります。多数の更新プログラムが展開されているときには、更新プログラムが同時に期限切れになることがあるので、展開先のシステムのパフォーマンスに影響を与える可能性があります。また、展開の作成時に、テンプレートの設定がその展開に適用されることに注意してください。展開内で手動で変更しない限り、テンプレートの設定は展開に適用されます。テンプレートの設定自体を後で変更するだけでは、変更されたテンプレートを使用している既存の展開に、変更後の設定は適用されないことにも注意してください。
図 6 ウィザードでの展開スケジュールの設定
図 6 ウィザードでの展開スケジュールの設定
図 6 のオプションは、Deployment Template Wizard (テンプレートの展開ウィザード) か、新しいテンプレートの作成時には Deploy Software Updates Wizard (ソフトウェア更新プログラムの展開ウィザード) で構成できます。この画面では、期間の設定が 0 に設定されていますが、この設定の既定値は 2 週間です。この設定が 0 以外の値に設定されている場合、クライアントでは、更新プログラムの展開で遅延が発生し、許容される遅延期間は、ここで指定されている期間になります。展開が使用できるようになってから構成された期限までの間、エンド ユーザーは、インストール スケジュール期限前の更新プログラムを手動でインストールすることができます。期限に達したときに、更新プログラムは強制的に適用されます。更新プログラムの展開で遅延が発生した場合は、この設定が適切に構成されていることを確認してください。

Deployment Management (展開管理)
ソフトウェア更新プログラムの展開を構成すると、[Deployment Management] (展開管理) ノードで構成済みの展開にアクセスすることができます。構成済みのソフトウェアの展開は、展開パッケージとは異なることに注意してください。展開に関する設定と展開に含まれている更新プログラムは、このノードで表示して操作できますが、パッケージそのものを表示したり、操作したりすることはできません。ここに表示される展開設定には、Deploy Software Updates Wizard (ソフトウェア更新プログラムの展開ウィザード) で指定された設定と、選択されたテンプレートから継承された設定が反映されます。

Deployment Packages (展開パッケージ)
展開パッケージは、更新プログラムの具体的な内容 (ソース ディレクトリ、配布ポイントなど) を定義するという点で、標準の SMS パッケージと似ています。展開パッケージは、更新プログラムの配布に使用する実際の展開とは関係なく、基本的には更新プログラムを保存する場所です。ある展開で必要な更新プログラムが複数の展開パッケージに含まれている場合、SCCM エージェントでは、更新プログラムの最適な取得元を判断します。この際、SCCM エージェントでは、その更新プログラムを含む入手可能な任意の展開パッケージを使用できます。
Deploy Software Updates Wizard (ソフトウェア更新プログラムの展開ウィザード) は、SCCM で更新プログラムを展開するのに使用します。このウィザードでは、個々の更新プログラムまたは更新プログラムの一覧のどちらも使用することができます。図 7 に、ウィザードの起動方法を示します。
図 7 Deploy Software Updates Wizard (ソフトウェア更新プログラムの展開ウィザード) の開始
図 7 Deploy Software Updates Wizard (ソフトウェア更新プログラムの展開ウィザード) の開始
このウィザードでは、展開の名前、既存のテンプレートと新しいテンプレートのどちらを使用するか (新しいテンプレートを選択すると、前に説明したテンプレートの設定画面が表示されます)、展開パッケージの設定 (既存か新規か)、展開ポイントの設定、ダウンロード場所のオプション、ダウンロードする更新プログラムの言語、展開スケジュールの情報を指定します。
構成が完了すると、ポリシーが更新され、展開される更新プログラムがクライアントに通知され、更新プログラムがクライアント システムにインストールされます。クライアント側のプロセスは以前のリリースとは大きく異なるため、この記事では扱いません。主な相違点だけ説明すると、更新プログラムのスキャンがローカルで実行されなくなり、すべてのスキャンが SUP で行われるようになりました。ただし、更新プログラムの対応状況に関する詳細情報は、以前のバージョンと同様、ローカルの Windows Management Instrumentation (WMI) リポジトリに格納されます。
また、以前のバージョンとは異なり、更新の状態をサイト サーバーに送信する際にハードウェア インベントリは使用されません。代わりに、新しい種類の合理的なステータス メッセージである state messages (状態メッセージ) が、管理ポイント経由でサイト サーバーに送信されます。state messages (状態メッセージ) では、対応状況のスキャン用に管理された各クライアントに関するデータを提供し、展開の進行状況を追跡します。SCCM には、ソフトウェアの更新管理用の新しいレポートが多数あります。たとえば、展開済みの全更新プログラムに関する各コンピュータの全体的な対応状況、各クライアントの展開の適用状況、解決すべき最大の問題をランク付けした一覧を提供する、スキャンと展開のクライアント エラー レポートなどがあります。
SCCM では、従来の更新プログラムのスケジュールされた適用と強制的な適用以外に、現在、自動更新で行われているのと同じように、スケジュールで指定されているインストールの期限前に、承認済みの更新プログラムをインストールできます。この便利な追加機能は、展開の期限前に、より多くのシステムで必要な更新プログラムが適用されるようにするのに役立ちます。
カスタム更新プログラムを適用する場合も、SCCM を使用できます。SMS 2003 R2 のカスタム更新プログラム用発行ツールは、SCCM 2007 で System Center Updates Publisher (System Center 更新プログラム パブリッシャ) として生まれ変わりました。そのため、すべてのカスタム更新プログラムは、既に説明したのと同じ方法で展開できます。
SCCM では、更新プログラムの管理機能が大幅に変更されましたが、管理者には、以前のバージョンよりも使いやすく、優れた機能強化として受け入れられるでしょう。SMS 2003 に慣れている場合、一部の概念の変更を最初は難しいと思うかもしれませんが、この新しい手法に慣れる労力は無駄にはなりません。がんばってください!

Steve Rachui は、マイクロソフトのプロダクト サポート サービス グループに所属するマネージャビリティ サポート エスカレーション エンジニアです。バージョン 1.2 のころから SMS のサポートを担当しています。Steve の連絡先は steverac@microsoft.com (英語のみ) です。


 通信: マイクロソフトの Exchange エッジ トランスポート サーバー
通信 Kay Unkroth

マイクロソフトの Exchange エッジ トランスポート サーバー
概要:
  • Exchange エッジ トランスポート サーバーの役割
  • テスト ラボをセットアップする
  • トランスポート エージェントとトランスポート イベント
  • エージェントの内部構成
この記事で使用しているコードのダウンロード: ExchangeEdge2007_10.exe (354KB)

マイクロソフトでは、通常の 1 営業日に約 1,300 万件のメッセージをインターネット経由で受信し、そのうちの 1,050 万件を正当でないメッセージとしてブロックしています。インターネット上でスパム攻撃やウイルスが発生している場合などの危機的な状況では、
これが 9,000 万件を超えることもあります。もちろん、これはマイクロソフト固有の現象ですが、詐欺、スパム、フィッシング、電子メールによって媒介されるウイルス、ディレクトリ ハーベスト攻撃、分散型サービス拒否 (DDoS) 攻撃などの問題は、マイクロソフト固有のものではありません。このような問題がある中で、大量に送信されてくる、正当でない、悪意のあるコンテンツをメッセージング環境から排除しながら、従業員に正当なメッセージを確実に配信するにはどうすればよいでしょうか。
信頼できるメッセージングの保護を実現する方法の 1 つは、Exchange Server 2007 エッジ トランスポート サーバーと Forefront Security for Exchange Server をインターネットと組織の運用環境の間にある境界ネットワークに展開することです。これにより、10 を超えるエッジ トランスポート エージェントから構成されるチームを境界に配置して、運用システムとユーザーを保護できます。望ましくないコンテンツをできるだけ早い時点でブロックすることの重要性は明らかです。ただし、メッセージング環境が危機的な状況に置かれる可能性があることを考えると、コンテンツがサーバーに配信される前にブロックするのが理想的です。ただ、単にメッセージをブロックする以外にも、メッセージングを保護する手段は多数あります。
これは、Exchange Server 2007 と Forefront Security for Exchange Server で提供されるスパム対策およびウイルス対策エージェントのアーキテクチャと主要機能を説明する 2 部シリーズの第 1 部です。説明を現実的かつ実践的なものにするために、この第 1 部の記事では、マイクロソフトが自社の運用環境で採用しているメッセージング保護の設計を再現したテスト ラボを構築する方法について説明します。その後、Exchange Server 2007 のエッジ トランスポートのアーキテクチャについて詳しく説明します。
この記事では、スクリプトとバッチ ファイルを頻繁に使用して、重要な構成作業のほとんどを自動化します。これらのファイルには、実行される各手順を説明したコメントも含まれています。これらのスクリプトは、TechNet Magazine Web サイト (technetmagazine.com/code07.aspx) からダウンロードできます。

エッジ トランスポートのトポロジ
図 1 は、Microsoft IT がマイクロソフトの運用環境に実装しているエッジ トランスポートの設計を示しています。エッジ トランスポートのアーキテクチャについて説明する前に、非常に興味深い設計上の特徴をいくつか示します。実装の詳細に興味がある場合は、補足記事「Exchange に関する詳細情報」に記載されている IT ショウケースのホワイト ペーパーを参照してください。
図 1 マイクロソフトのエッジ トランスポートのトポロジ
図 1 マイクロソフトのエッジ トランスポートのトポロジ
図 1 を分析すると、マイクロソフトのエッジ トランスポートのトポロジは十分に冗長であることがわかります。どこにも単一障害点はありません。また、負荷分散を実現するために、外部では DNS ラウンド ロビンを使用し、内部では複数のブリッジヘッドがあるメッセージング コネクタを使用しています。また、すべてのトランスポート サーバー (ハブ トランスポートとエッジ トランスポート) で、ウイルスをスキャンするための Forefront Security for Exchange Server が実行されていることにも注意してください。これにより、メッセージ ルーティング トポロジ内のトランスポート サーバーにメッセージが届いた時点で、すべての受信メッセージ、送信メッセージ、および内部メッセージをスキャンできます。
セキュリティに関連するもう 1 つの重要な設計上の特徴は、エッジ トランスポート サーバーが社内の Active Directory® 環境の一部ではないことです。実際、エッジ トランスポート サーバーを Active Directory フォレストに展開する必要はありません。ただし、Microsoft IT では、管理フレームワークの一貫性を維持したり、共通のポリシー セットを適用したり、シングル サインオンをサポートしたりするために、すべてのエッジ トランスポート サーバーをエクストラネット フォレストに展開し、運用環境から分離しています。
また、インターネット経由で送信されてきたすべてのメッセージは、北米にあるエッジ トランスポート サーバーを介してマイクロソフトに配信されていることもわかります。ダブリンとシンガポールにあるエッジ トランスポート サーバーは、送信メッセージのみを処理します。すべての受信トラフィックを北米のエッジ トランスポートで処理するメリットは、セキュリティとスパム対策を一元的に管理しながら、内部メッセージング バックボーン上の大規模な地域データセンターから送信メッセージが転送されないようにできることです。
マイクロソフトのエッジ トランスポート トポロジを設計したのは、Microsoft IT のシステム エンジニアである Omesh Desai です。Omesh に最も重要な設計上の特徴を尋ねたところ、次のような回答を得ました。「マイクロソフトのエッジ トランスポートの設計では、Exchange 自体のスパム対策およびウイルス対策機能を利用して、メッセージング バックボーン内の複数の層でメッセージングを保護しています。メッセージング境界のセキュリティを確保することが最優先ですが、単純な管理モデルも私たちにとっては重要です。エッジ トランスポート サーバーは、より強力なファイアウォール構成によってセキュリティを強化すると同時に、IP 評価サービス、コンテンツ フィルタの自動更新、セーフリスト集約、および電子メールの消印の検証によってスパム フィルタの精度を高めるのに役立っています。すべての内部のサーバー間通信は、既定で暗号化されています。また、可能であれば、外部の送信先との通信も暗号化しています。
エッジ トランスポート サーバーには、2 つのデュアルコア 64 ビット プロセッサと 8 GB のメモリを使用しています。これら 6 台のサーバーは、2 つのデータセンター間で負荷分散されており、インターネット上でウイルスが発生した場合など、メッセージの送信量が急増しても対応できるだけの十分な処理能力を確保しています。」

エッジ トランスポートのテスト ラボ
テスト ラボをセットアップする
架空のドメイン名とプライベート IP アドレスを使用することがベスト プラクティスであるため、ここでは AdventureWorks.com と 192.168.xxx.0 ～ 24 の IP アドレスを使用します。負荷分散やフォールト トレランスはテストしないため、冗長システムやファイアウォール アレイは用意していません (もちろん、セキュリティ上の理由から、Microsoft IT が実際に使用しているファイアウォール システムについて説明することはできません)。いずれにしても、このような詳細情報は、このテストにとって重要ではありません。
テスト環境では、Exchange Server 2007 と共に使用される最も一般的なファイアウォール システムの 1 つである ISA Server 2006 を使用します。外部ファイアウォールと内部ファイアウォールの両方で ISA Server 2006 を実行することにより、テスト環境の複雑さを抑えています。ただし、運用環境では、セキュリティを確保するために、外部と内部で別々のファイアウォール システムを使用することをお勧めします。また、この記事の範囲には含まれないため、IP セキュリティ (IPsec) ポリシーの展開や、トランスポート層セキュリティ (TLS) 用の環境の準備は行いませんでした。
ただし、バーチャル マシンと 32 ビットの評価版ソフトウェアは使用しました。この評価版は、マイクロソフト Web サイトからダウンロードできます。マイクロソフトは、32 ビット版の Exchange Server 2007 の運用をサポートしていませんが、テスト環境でこれが問題になることはありません。
このテスト ラボでは、できる限り既定の設定を使用しています。Exchange Server 2007 のセットアップを実行し、エッジ トランスポート サーバーで運用環境をサブスクライブする前に特に注意する必要があるのは、IP 構成、ファイアウォール、および DNS ゾーンのみです。IP 構成の詳細については、この記事のダウンロード ファイルに含まれている Test Lab - IP Configuration.xls ファイルを参照してください。同じ IP アドレスの割り当てを使用する場合は、ISA01_Firewall_Policies.vbs スクリプトを ISA01 コンピュータ上で直接実行して外部ファイアウォール ISA01 を構成し、ISA02_Firewall_Policies.vbs を使用して内部ファイアウォール ISA02 を構成できます。この記事のダウンロード ファイルには、DNS サーバーを構成するためのバッチ ファイル (INTERNET01_DNS_Config.bat、AD01_DNS_Config.bat、および AD02_DNS_Config.bat) も含まれています。これらのバッチ ファイルは DNS コマンド ライン ツール (dnscmd.exe) を使用するため、Windows サポート ツールをインストールしておく必要があります。このツールをインストールしなかった場合、DNS コンソールを使用して DNS レコードを手動で作成する必要があります。
既存の環境の影響を受けないようにするために、テスト ラボはインターネットに接続されていません。このような環境の分離は、優れた予防策です。インターネットに接続されていないため、署名の更新、IP 評価、およびコンテンツ フィルタの更新のダウンロードはすべて失敗しますが、テストではこのことは重要ではありません。エラー メッセージが表示されないようにするには、Forefront Server Security Administrator コンソールの [スキャナの更新] を参照し、すべてのスキャン エンジンの更新頻度を 1 回に設定して、過去の日付を指定します。

これらの機能の実際の動作を確認するには、テスト環境を構築することをお勧めします。当然ながら、運用システムをテスト目的で使用することは絶対に避けてください。この環境では、少なくとも、メールボックス、クライアント アクセス、およびハブ トランスポート サーバーの役割を持つ Exchange Server 2007 サーバーが 1 台必要です。エッジ トランスポート サーバーの役割を割り当てる場合は、2 台目の Exchange サーバーが必要になります。複数の役割を持つサーバーにすべてのトランスポート エージェントを展開する場合は、Install-AntispamAgents.ps1 スクリプト (ハブ トランスポート サーバーの %ProgramFiles%\Microsoft\Exchange Server\Scripts フォルダにあります) を実行することで、エッジ トランスポート サーバーのインストールを省略できます。しかし、この方法では Microsoft IT の展開を再現することは非常に困難です。より実際に近い環境をテスト ラボに実装するには、さらに数台のサーバーを含める必要があります。図 2 は、この記事用の調査に使用したテスト環境を示しています。より詳細な図は、この記事のダウンロードに含まれています。ラボのセットアップの詳細については、補足記事「テスト環境をセットアップする」を参照してください。
図 2 エッジ トランスポートのテスト環境
図 2 エッジ トランスポートのテスト環境
Microsoft IT は、エッジ トランスポート サーバーのサブスクリプションを設定し、関連するコネクタを構成する作業で、すべての既定のコネクタを削除してから 4 つの送信コネクタを作成することにより、さまざまな種類の簡易メール転送プロトコル (SMTP) ホストや内部のハブ トランスポート サーバーとの効率的な通信を実現しました。１ つ目の送信コネクタは、特定のアドレス空間の定義に一致しないすべての送信先を対象とする汎用のインターネット コネクタです。
2 つ目の送信コネクタは、拡張 SMTP (HELO ドメイン) をサポートしていない既知の送信先用の詳細なアドレス空間が定義されているインターネット コネクタです。Microsoft IT はこのコネクタの ForceHELO パラメータを $true に設定して、SMTP 接続の確立時に発生する、EHLO、失敗応答 500、HELO という不要なシーケンスを回避しています。
3 つ目の送信コネクタは、TLS をサポートし、暗号化された接続を経由してセキュリティで保護された通信を行うパートナーや他のリモート ドメイン (TLS ドメイン) 用の詳細なアドレス空間が定義されているインターネット コネクタです。このコネクタでは、RequireTLS パラメータが $true に設定されています。
4 つ目の送信コネクタは、受信したインターネット メッセージを企業環境内のハブ トランスポート サーバーに転送する受信コネクタです。エッジ トランスポート サーバーの構成の詳細についても、この記事の最後の補足記事「Exchange に関する詳細情報」に記載されている IT ショウケースのホワイト ペーパーを参照してください。
Microsoft IT と同様のコネクタ トポロジをテスト ラボに適用するために、Omesh が Microsoft IT 用に作成したスクリプトに基づいたプロシージャを使用しました。セキュリティ上の理由から、個々のコマンドは大幅に変更し、短縮していますが、結果として得られるコネクタ トポロジは、Microsoft IT のトポロジに対応しています。次にその手順を示します。
  1. 複数の役割を持つ Exchange サーバー (HUB-MBX-01) とエッジ トランスポート サーバー (EDGE01) で、既定のコネクタを削除します。
  2. HUB-MBX-01 で、この記事のダウンロードに含まれている HUB-MBX-01_recv_connector.ps1 スクリプトを実行して、新しい受信コネクタを作成します。
  3. EDGE01 で、EDGE01_recv_connector.ps1 スクリプトを実行して、内部と外部のメッセージング接続用の新しい受信コネクタを 2 つ作成します。
  4. EDGE01 で、次のコマンドを実行して、サブスクリプション ファイルを作成します。
    New-EdgeSubscription -FileName
    "c:\subscriptionfile.xml"
生成されたサブスクリプション ファイルをハブ トランスポート サーバーのルート フォルダ (c:\subscriptionfile.xml) にコピーします。
5. HUB-MBX-01 で、サブスクリプション ファイルのパスが c:\subscriptionfile.xml であることを確認し、HUB-MBX-01_complete_subscription.ps1 スクリプトを実行します。このスクリプトは、送信コネクタを自動的に作成することなく、エッジ同期のサブスクリプション ファイルをインポートし、インターネットおよび内部接続用の送信コネクタを作成した後、結果として得られた構成をエッジ同期によってエッジ トランスポート サーバーにレプリケートします。
6. 構成を検証するために、インターネット ホストから Contoso.User@contoso.com と Fabrikam.User@fabrikam.com としてテスト メッセージを Administrator@adventureworks.com に送信してから、受信したメッセージに返信することによって、受信および送信メッセージの転送が機能することを確認します。
各スクリプト ファイルをメモ帳で開き、構成を実行するスクリプトで使用されているコマンドレットとパラメータを確認することをお勧めします。これらのコマンドレットとパラメータの詳細については、オンラインで Exchange Server 2007 の製品ドキュメントを参照してください。

エッジ トランスポートのアーキテクチャ
では、エッジ トランスポート エージェントにアクセスしてみましょう。これらのエージェントは、エッジ トランスポート サーバーの役割がインストールされたときから、HELO または EHLO が送信されてくるのを待機しています。エッジ トランスポート サーバー上で Get-TransportAgent コマンドレットを実行すると、図 3 に記載されている 11 個のエントリが表示されます。すべてのエージェントは既定で有効になっており、適切な設定を使用してメッセージを保護します。
Figure 3 トランスポート エージェント (Close Figure 3)

SMTP 受信エージェント
接続フィルタ エージェント
受信用アドレス書き換えエージェント
エッジ ルール エージェント
コンテンツ フィルタ エージェント
Sender ID エージェント
送信者フィルタ エージェント
受信者フィルタ エージェント
プロトコル分析エージェント
添付ファイル フィルタ エージェント
ルーティング エージェント
送信用アドレス書き換えエージェント
FSE ルーティング エージェント
Get-TransportAgent コマンドレットの結果と図 3 の一覧には、優先度の高い順にエージェントが列挙されていますが、これはエージェントが処理を実行する順序ではありません。基本的に、処理順序は登録されたエージェントに対応する SMTP 受信イベントとルーティング イベントの発生順序によって決まります。エージェントとイベントの関係については、図 4 を参照してください。この図は、トランスポート エージェントがエッジ トランスポートのアーキテクチャにどのように統合されているかを示しています。
図 4 エッジ トランスポート アーキテクチャ内のトランスポート エージェント
図 4 エッジ トランスポート アーキテクチャ内のトランスポート エージェント
トランスポート イベントは、メッセージ処理のさまざまな段階で発生し、スパム フィルタ処理、ウイルス スキャン、およびその他の作業を行うために、追加のコードを呼び出します。このように疎結合された拡張可能な設計では、エッジ トランスポートのプロセス (EdgeTransport.exe) がイベント ソースの役割を想定します。イベント ハンドラ、つまりトランスポート エージェントは、Microsoft® .NET Framework 2.0 を基盤としたマネージ委任オブジェクトであり、コールバック通知を受信するためにイベント ソースに登録されます。
図 5 は、Forefront Security が展開されているエッジ トランスポート サーバーにインストールされたすべてのエージェントがどのイベントに登録されているかを示しています。登録されているエージェントの数が多いため、これらの登録状況を整理するのは難しいかもしれませんが、がっかりしないでください。Get-TransportPipeline | Format-List コマンドをエッジ トランスポート サーバー上で実行すると、各トランスポート イベントにどのエージェントが登録されているかをより容易に分析できます。Microsoft Exchange Transport サービス (MSExchangeTransport.exe) が実行中で、前回サービスが再起動されてから少なくとも 1 つのメッセージがエッジ トランスポート サーバーから送信されていることを確認します。出力からわかるように、同じイベントの種類に複数のエージェントを登録することも、複数のイベントに個々のエージェントを登録することもできます。イベントに登録できるかどうかは、対応するエージェントの処理要件によってのみ決まります。
図 5 イベントへのトランスポート エージェントの登録状況
図 5 イベントへのトランスポート エージェントの登録状況
最も重要なイベントの 1 つは OnSubmittedMessage ルーティング イベントです。このイベントはメッセージが送信キューに配信されたときに発生します。すべてのメッセージは、SMTP、ファイル システム、またはその他のメカニズムのいずれを経由して送信されたかにかかわらず、このキューを通過する必要があります。カテゴライザは、Exchange Server トランスポート アーキテクチャの主要なコンポーネントの 1 つで、受信者の解決、メッセージの分岐とルーティング、および配信状態通知 (DSN) の生成を行います。したがって、OnSubmittedMessage イベントは、すべての受信メッセージを処理する必要があるエージェントの登録先として最適です。FSE ルーティング エージェントは、OnSubmittedMessage イベントに登録されている Forefront Security コンポーネントで、すべての受信メッセージをウイルス スキャン エンジンに渡します。FSE ルーティング エージェントが OnSubmittedMessage イベントに登録されているため、すべてのメッセージはウイルス対策ソリューションを経由することになります。
では、なぜすべてのエージェントを OnSubmittedMessage イベントに登録して、作業完了というわけにいかないのでしょうか。理由は、サーバーが配信の成功を確認する前の可能な限り早い時点で、望ましくないメッセージをブロックする必要があるためです。このイベントの前にメッセージをブロックしないと、スパムやウイルス攻撃の発生中に、サーバーが 9,000 万件の不要なメッセージを処理し、9,000 万件の配信不能レポート (NDR) を生成する可能性があります。これは、悪意のないユーザーにとっては深刻な脅威となります。スパムおよびウイルス攻撃は、必ずと言ってよいほど偽装された発信者情報を使用します。元のメッセージを作成していない受信者に数百万件の NDR が送信された場合、自分の組織のリソースと送信先の組織のリソースが無駄に使用されるだけでなく、悪意のあるユーザーがメール フラッディング攻撃や DDoS 攻撃を行う機会を与えることにもなります。悪意のある送信者の攻撃をできるだけ早く回避することは、自分自身を保護するだけでなく、他のユーザーを保護することにもなります。
メッセージを効率的にブロックするには、サーバーが "250 OK" 状態コードを返してデータの受信を確認する前に、トランスポート エージェントがリモート ホストとの SMTP 対話に割り込む必要があります。SMTP のストア アンド フォワードの原則に従うと、メッセージの配信が確認されていない場合、サーバーは NDR を生成することなく、受信したデータを安全に破棄できます。SMTP 受信エージェントは、この動作を実現できます。SMTP 受信イベント (リモート ホストによるサーバーへの接続、SMTP セッションの確立、SMTP コマンドの送信、メッセージの送信、および接続の終了) に基づいて、トランスポート パイプラインが SMTP 受信エージェントを起動するため、SMTP 受信エージェントは SMTP セッションと対話することができます (各操作に関連する SMTP 受信イベントについては、図 6 を参照してください)。Exchange Server 2007 のすべてのスパム対策エージェントは、配信前にメッセージを拒否し、リモート SMTP ホストを切断できるため、SMTP 受信エージェントとして実装されます。
Figure 6 SMTP セッション イベント (Close Figure 6)

操作 | 関連イベント
サーバーへの接続 | OnConnectEvent
SMTP セッションの確立 | OnHeloCommand、OnEhloCommand、OnAuthCommand、OnEndOfAuthentication
SMTP コマンドの送信 | OnMailCommand、OnRcptCommand、OnDataCommand、OnNoopCommand、OnHelpCommand
メッセージの送信 | OnEndOfHeaders、OnEndOfData
コマンドまたはメッセージの拒否 | OnReject
接続のリセット | OnRsetCommand
接続の終了 | OnDisconnect
処理を行う状況という点から、SMTP 受信エージェントとルーティング エージェントの違いを認識しておくことは重要です。ルーティング エージェントはメッセージのすべてのプロパティにアクセスできますが、SMTP 受信エージェントは SMTP セッションと対話するため、状況に応じて動作が異なります。たとえば、スパム フィルタは、リモート ホストが実際にメッセージを転送するまで、メッセージのプロパティを操作できません。したがって、このエージェントを正しい SMTP 受信イベントに登録することが重要です。詳細については、補足記事「トランスポート エージェントの開発」を参照してください。

Exchange に関する詳細情報
  • Microsoft Exchange Server 2007 のエッジ トランスポートとメッセージング保護 (Microsoft IT ショウケースのテクニカル ホワイト ペーパー)
  • Windows PowerShell スクリプト センター
  • Exchange Server 2007 TechCenter
  • Microsoft Exchange チーム ブログ「EHLO さえあれば」

第 2 部の前に
トランスポート アーキテクチャとテスト シナリオの詳細に進む前に一息入れましょう。この記事では、Microsoft IT と同様のエッジ トランスポート サーバーの展開から、メッセージ処理中にトランスポート パイプラインで発生する内部イベントに至るまで、さまざまな基本事項を説明しました。この 2 部シリーズの次の記事では、いくつかの興味深いテスト シナリオを使用して、エッジ トランスポート エージェントの動作について詳しく説明します。
それまでは、Microsoft Visual Studio 2005 Professional Edition の 90 日間の試用版 (go.microsoft.com/fwlink/?LinkId=98043) をダウンロードし、Steve の説明に従って、テスト環境でサンプル エージェントのコンパイルとインストールを実行することをお勧めします。開発者でなくても、これらの作業は非常に簡単に実行できると思います。Exchange Server 2007 では、Visual Studio 2005 を使用してカスタム エージェントを非常に便利に開発できるため、このようなコンポーネントに依存するビジネス アプリケーションが増えたとしても驚くことではありません。

Kay Unkroth は、15 年間、マイクロソフトのサーバー テクノロジを専門とするサポート エンジニア、システム開発者、コンサルタント、トレーナー、著者としての職歴を持つ企業家です。また、ドキュメント管理とローカライズ サービスの専門企業 Biblioso Corporation の共同創立者であり、会長でもあります。


 SQL Server: SQL Server の CPU パフォーマンスを最適化する
SQL Server Zach Nichter

SQL Server の CPU パフォーマンスを最適化する
概要:
  • データベースのパフォーマンスに関する問題のトラブルシューティングを行う
  • ハードウェアに原因があるかどうかを確認する
  • パフォーマンス モニタを使用してデータベースのボトルネックを追跡する
  • クエリのパフォーマンスを評価する

データベース システムのパフォーマンスに関する問題のトラブルシューティングは、手に負えないほど厄介な作業になる場合があります。調査が必要な箇所を知っていることも重要ですが、特定の要求に対してシステムがなぜそのように動作するのかを知っていることの方が重要です。データベース サーバーの CPU 使用率に影響する要因は
さまざまです。たとえば、SQL ステートメントのコンパイルと再コンパイル、インデックスの欠落、マルチスレッド操作、ディスクのボトルネック、メモリのボトルネック、定期的なメンテナンス、ETL (抽出、変換、読み込み) 処理などがあります。CPU が使用されること自体は、悪いことではありません。CPU があるのは、作業を行うためですから。CPU 使用率を正常に保つには、必要な処理に CPU が使用され、最適化が不十分なコードや動作の遅いハードウェアのために無駄なサイクルが発生しないようにすることが重要です。

問題を特定する 2 つの作業
大きく分けて、CPU のパフォーマンスに関する問題を特定するために行う作業は 2 つあります。1 つ目は、システムのハードウェアのパフォーマンスを確認することです。この作業を行って、調査が必要な箇所を特定しておくと、サーバーのクエリ効率を確認するという 2 つ目の作業を行う際に役立ちます。通常、SQL Server™ のパフォーマンスに関する問題を特定する場合は、2 つ目の作業のほうが効果的です。ただし、クエリのパフォーマンスに関する問題の原因となっている箇所を正確に把握していない場合は、必ず最初にシステムのパフォーマンスを評価してください。通常、最終的には、両方の作業を行うことになります。2 つの作業について説明する前に、まず基盤となる技術について説明します。

基盤技術を理解する
ハイパースレッディング
ハイパースレッディングについては、これが SQL Server に影響するしくみを考えると、少し詳しく説明しておいた方がよいでしょう。ハイパースレッディングでは、1 つの物理プロセッサにつき 2 つの論理プロセッサが OS に提供されます。基本的には、物理プロセッサの時間をリースすることにより、各プロセッサがより有効に使用されるようにするための技術です。ハイパースレッディングのしくみの詳細については、Intel の Web サイト (intel.com/technology/platform-technology/hyper-threading/index.htm) を参照してください。
SQL Server システム上では、実際には DBMS が OS に対して非常に効率的なキュー処理とスレッディングを行っているため、既に CPU 使用率が高いシステムでハイパースレッディングを有効にしても、物理 CPU への負荷が増すだけです。SQL Server が複数のスケジューラを操作するために複数の要求をキューに入れた場合、1 つの物理プロセッサが 2 つの論理プロセッサとして使用されている場合でも、OS は要求された処理を実行するために、その物理プロセッサのスレッド間でコンテキストを切り替える必要があります。Context Switches/sec が 1 物理プロセッサあたり 5,000 を超えている場合は、システムでハイパースレッディングを無効にした後、再度パフォーマンスをテストすることを強くお勧めします。
まれに、SQL Server システム上で高い CPU 使用率を示すアプリケーションがある場合、ハイパースレッディングが効果的に作用することがあります。SQL Server システムで、ハイパースレッディングを有効にした状態と無効にした状態の両方でアプリケーションをテストしてから、運用システムに変更を実装するようにしてください。

コンピュータの RAM は接続型のストレージ デバイスよりも処理性能が優れていますが、ハイエンドのデュアルコア プロセッサは、その RAM よりも格段に高速です。高性能の CPU は、現在のトップエンドの DDR2 メモリの約 6 倍、およびトップエンドの DDR3 メモリの約 2 倍のスループットを処理できます。通常、メモリのスループットは、最速のファイバ チャネル ドライブの 10 倍以上です。また、ハード ディスクは、限られた数の IOPS (1 秒あたりの入出力操作) しか実行できません。この数は、ドライブが実行できる 1 秒あたりのシーク数によってのみ制限されます。ただし、1 つのストレージ ドライブのみによって、エンタープライズ データベース システムのストレージ要件が満たされることはあまりありません。現在の一般的な構成では、エンタープライズ データベース サーバーにストレージ エリア ネットワーク (SAN) を使用するか、ディスク I/O プロセッサの問題を解消または最小限に抑えることができる大規模な RAID グループを使用しています。最も重要なことは、どのような構成であっても、ディスクとメモリのボトルネックが、プロセッサのパフォーマンスに影響する可能性があるということです。
I/O 速度の違いにより、ディスクからデータを取得する場合は、メモリからデータを取得する場合よりもかなりコストがかかります。SQL Server のデータ ページは 8 KB です。SQL Server のエクステントは、この 8 KB のページを 8 ページ使用して構成されるため、64 KB になります。SQL Server がディスク上の特定のデータ ページを要求するとき、取得されるデータ ページだけでなく、そのデータ ページがあるエクステント全体が取得されるため、このことを理解しておく必要があります。実際には、SQL Server にとってこれがコスト効率の向上につながる理由がありますが、ここでは詳細は省きます。バッファ プールから既にキャッシュされているデータ ページを取得する際にかかる時間は、最速で 0.5 ミリ秒未満ですが、ディスクから 1 つのエクステントを取得する場合は、最適な環境で 2 ～ 4 ミリ秒です。通常、パフォーマンスがよく、正常なディスク サブシステムでは、読み取りに 4 ～ 10 ミリ秒かかると思われます。メモリからデータ ページを取得する場合は、通常、ディスクからデータ ページを取得するよりも 4 ～ 20 倍高速です。
SQL Server はデータ ページを要求するとき、ディスク サブシステム上のデータ ページを検索する前に、まずメモリ内のバッファ キャッシュを確認します。データ ページがバッファ プール内で見つかった場合、プロセッサはこのデータを取得し、要求された作業を行います。これは、ソフト ページ フォールトと呼ばれます。要求の一環として取得されるデータを使用するには、このデータがバッファ キャッシュに読み込まれている必要があるため、ソフト ページ フォールトは SQL Server にとって理想的な処理です。バッファ キャッシュにないデータ ページは、サーバーのディスク サブシステムから取得する必要があります。OS がデータ ページをディスクから取得する必要がある場合、その動作はハード ページ フォールトと呼ばれます。
メモリ パフォーマンス、ディスク パフォーマンス、および CPU パフォーマンスの相関関係を知るには、共通の指標から考えると全体図を把握しやすくなります。その指標とはスループットです。科学用語を使用せずに説明すると、スループットは、限られた大きさのパイプにどれだけ多くのデータを詰め込むことができるかを示す数値です。

作業 1: システムのパフォーマンス
サーバーの CPU がボトルネックになっているかどうかを確認する方法はごくわずかしかなく、高い CPU 使用率を引き起こす可能性がある要因もそれほど多くありません。これらの問題の中には、パフォーマンス モニタまたは同様のシステム監視ツールを使用して追跡できるものや、SQL Server Profiler などのツールを使用して追跡できるものがあります。別の方法としては、クエリ アナライザや SQL Server Management Studio (SSMS) から SQL コマンドを使用します。
システムのパフォーマンスを評価する際の私の方針は、"最初は全体を見て、後から範囲を絞り込む" というものです。当然ながら、問題のある領域を特定しなければ、それらの問題に取り組むことはできません。パフォーマンス モニタなどのツールを使用して全体的な CPU 使用率を評価したら、そのツールを使用して、非常に単純かつ理解しやすいいくつかのパフォーマンス カウンタを確認します。
パフォーマンス モニタを使用する場合、最も頻繁に参照するパフォーマンス カウンタの 1 つは % Processor Time です。これは、[カウンタの追加] ウィンドウを開くと強調表示されているカウンタです。% Processor Time は、プロセッサが処理を実行してビジー状態になっている時間を示しています。通常、ピーク稼働時間のほとんどの間、この値が 80% 以上を示す場合、プロセッサの使用率は高いと見なされます。ピーク稼働時間のサーバーの使用率が 80% 未満の場合でも、ときどき使用率が 100% に急上昇することがありますが、これは一般的な動作であり、異常が発生しているわけではありません。
確認が必要なもう 1 つのカウンタは Processor Queue Length です。これは、パフォーマンス モニタの System パフォーマンス オブジェクトのカウンタです。Processor Queue Length は、CPU 上で処理を実行するために待機しているスレッドの数を示しています。SQL Server では、データベース エンジンのスケジューラによって処理を管理し、SQL Server 自体の要求をキューに入れたり処理したりします。SQL Server は SQL Server 自体の処理を管理するため、各論理プロセッサにつき 1 つの CPU スレッドしか使用しません。つまり、SQL Server 専用のシステムでは、処理を実行するためにプロセッサのキューで待機しているスレッドの数を最小限に抑える必要があります。通常、SQL Server 専用のシステムでは物理プロセッサ数の 5 倍未満の数である必要がありますが、私は 2 倍でも問題であると考えます。DBMS が他のアプリケーションとシステムを共有しているサーバー上では、% Processor Time および Context Switches/sec パフォーマンス カウンタと併せてこのカウンタを確認し (コンテキスト スイッチについては後述します)、他のアプリケーションか DBMS を別のサーバーに移動する必要があるかどうかを判断するとよいでしょう。
CPU 使用率が高いだけでなく、プロセッサのキューが使用されている場合は、SQL Server: SQL Statistics パフォーマンス オブジェクトの Compilations/sec と Re-Compilations/sec カウンタも確認します(図 1 参照)。クエリ プランのコンパイルと再コンパイルを行うと、システムの CPU 使用率が増加します。Re-Compilations の値はゼロに近いはずですが、システム内の傾向を観察し、サーバーの通常の動作とコンパイル数を確認してください。再コンパイルは常に回避できるとは限りませんが、クエリとストアド プロシージャを最適化することで、再コンパイルを最小限に抑えたり、クエリ プランを再利用したりできます。SQL Server: SQL Statistics パフォーマンス オブジェクトの Batch Requests/sec を使用して、コンパイルと再コンパイルの値を、実際にシステムが受け取る SQL ステートメントの数と比較します。1 秒あたりにシステムが受け取るバッチ要求の中に、コンパイルと再コンパイルが高い割合で含まれる場合、この領域を見直す必要があります。場合によっては、開発したコードがどのようにまたはなぜこのようなシステム リソースの問題に関与しているかを SQL 開発者が理解していないことがあります。この記事では後ほど、可能な限りこのような事態に陥らないようにするための参考情報を提供します。
図 1 監視するカウンタの選択
図 1 監視するカウンタの選択
パフォーマンス モニタで Context Switches/sec というパフォーマンス カウンタを確認します (図 2 を参照)。このカウンタは、他の待機中のスレッドの処理を行うために、(SQL のスケジューラではなく) OS のスケジューラのスレッドが切り替えられた回数を示します。コンテキストの切り替えは、IIS や他のベンダのアプリケーション サーバー コンポーネントと共有されているデータベース システムでより頻繁に発生する傾向があります。Context Switches/sec のしきい値は、サーバーのプロセッサ数の 5,000 倍を目安にします。この値は、ハイパースレッディングが有効になっていて、中程度から高い CPU 使用率を示すシステムでは高くなります。CPU 使用率とコンテキストの切り替え数の両方が定期的にしきい値を超える場合は、CPU がボトルネックになっています。この現象が定期的に見られ、使用しているシステムが古い場合は、CPU を追加購入するか、より高速な CPU を購入することを検討する必要があるでしょう。詳細については、補足記事「ハイパースレッディング」を参照してください。
Figure 2 監視が必要なパフォーマンス カウンタ (Close Figure 2)

パフォーマンス カウンタ | カウンタ オブジェクト | しきい値 | 説明
% Processor Time | Processor | 80% 以上 | メモリ不足、クエリ プランの再利用率が低いこと、クエリが最適化されていないことなどが、原因として考えられます。
Context Switches/sec | System | プロセッサ数の 5,000 倍以上 | サーバー上に他のアプリケーションが展開されていること、SQL Server の複数のインスタンスが同じサーバー上で実行されていること、ハイパースレッディングが有効になっていることなどが、原因として考えられます。
Processor Queue Length | System | プロセッサ数の 5 倍以上 | サーバー上に他のアプリケーションが展開されていること、コンパイルや再コンパイルが頻繁に発生すること、SQL Server の複数のインスタンスが同じサーバー上で実行されていることなどが、原因として考えられます。
Compilations/sec | SQLServer:SQL Statistics | 傾向 | Batch Requests/sec と比較します。
Re-Compilations/sec | SQLServer:SQL Statistics | 傾向 | Batch Requests/sec と比較します。
Batch Request/sec | SQLServer:SQL Statistics | 傾向 | Compilations/sec および Re-Compilations/sec と比較します。
Page Life Expectancy | SQLServer:Buffer Manager | 300 以上 | メモリ不足の可能性があります。
Lazy Writes/sec | SQLServer:Buffer Manager | 傾向 | データ キャッシュがフラッシュされる頻度が高いか、メモリ不足の可能性があります。
Checkpoints/sec | SQLServer:Buffer Manager | 傾向 | PLE および Lazy Writes/sec と比較して、チェックポイントの影響を評価します。
Cache Hit Ratio: SQL Plans | SQLServer:Plan Cache | 70% 以上 | プランの再利用率が低いことを示しています。
Buffer Cache Hit Ratio | SQLServer:Buffer Manager | 97% 以上 | メモリ不足の可能性があります。
SQL Server レイジー ライタ (SQL Server 2000 での名称) またはリソース モニタ (SQL Server 2005 での名称) は、CPU 使用率が高いときに監視すべき領域の 1 つです。バッファおよびプロシージャのキャッシュをフラッシュすると、リソース モニタという名前のリソース スレッドにより CPU 時間が増大する可能性があります。リソース モニタは、どのページを保持し、どのページをバッファ プールからディスクにフラッシュする必要があるかを決定する SQL Server プロセスです。バッファおよびプロシージャ キャッシュ内の各ページには、もともとページがキャッシュに読み込まれたときに使用されるリソースを表すコストが割り当てられています。このコストの値は、リソース モニタがページをスキャンするたびに減少します。ある要求でキャッシュ領域が必要になった場合、各ページに関連付けられているコストを基にメモリからページがフラッシュされます。コストが最も低いページからディスクにフラッシュされます。リソース モニタの動作状況は、パフォーマンス モニタで SQL Server: Buffer Manager オブジェクトの Lazy Writes/sec パフォーマンス カウンタを参照することで追跡できます。この値の傾向を追跡して、使用中のシステムでの標準的なしきい値を特定してください。通常、このカウンタは、メモリが不足しているかどうかを確認するために、Page Life Expectancy および Checkpoints/sec カウンタと併せて参照されます。
Page Life Expectancy (PLE) カウンタは、メモリが不足しているかどうかを確認する際に役立ちます。PLE カウンタは、あるデータ ページがバッファ キャッシュに保持されている時間を示します。このカウンタのしきい値として業界で認められている値は 300 秒です。長時間の平均が 300 秒未満である場合は、データ ページがメモリからフラッシュされる頻度が高すぎます。この場合、リソース モニタの負荷が高くなり、その結果、プロセッサの負荷も高くなります。PLE カウンタは、Checkpoints Pages/sec カウンタと併せて評価する必要があります。システムのチェックポイントが発生すると、バッファ キャッシュ内のダーティ データ ページがディスクにフラッシュされ、PLE 値が減少します。リソース モニタ プロセスは、これらのページをディスクにフラッシュするメカニズムであるため、システムのチェックポイントが発生した場合は Lazy Writes/sec の値も増加すると考えてください。チェックポイントの完了直後に PLE 値が増加した場合は、一時的な現象であるため、無視して問題ありません。一方、定期的に PLE の値がしきい値よりも低くなる場合は、メモリを追加することで、問題が緩和されると同時に、一部のリソースが再び CPU に解放される可能性があります。これらのカウンタはすべて、SQL Server: Buffer Manager パフォーマンス オブジェクトのカウンタです。

作業 2: クエリのパフォーマンス
SP によるトレース
SQL Server アプリケーションをトレースする場合は、トレース用のストアド プロシージャについて知っておくとよいでしょう。トレース用の GUI インターフェイス (SQL Server Profiler) を使用すると、システムの負荷が 15 ～ 25% 増加する可能性があります。トレースにストアド プロシージャを使用すると、この負荷を約半分に抑えることができます。
システムのいずれかの部分がボトルネックになっていることがわかっていて、現在使用している SQL ステートメントの中で、サーバーで発生している問題の原因になっているものを特定する必要がある場合は、次のようなクエリを実行します。このクエリを実行すると、各ステートメントとこれらが現在使用しているリソースのほか、パフォーマンスを向上させるために見直す必要があるステートメントを確認できます。SQL トレースの詳細については、msdn2.microsoft.com/ms191006.aspx を参照してください。
SELECT
    substring(text,qs.statement_start_offset/2
        ,(CASE
            WHEN qs.statement_end_offset = -1 THEN len(convert(nvarchar(max), text)) * 2
            ELSE qs.statement_end_offset
        END - qs.statement_start_offset)/2)
    ,qs.plan_generation_num as recompiles
    ,qs.execution_count as execution_count
    ,qs.total_elapsed_time - qs.total_worker_time as total_wait_time
    ,qs.total_worker_time as cpu_time
    ,qs.total_logical_reads as reads
    ,qs.total_logical_writes as writes
FROM sys.dm_exec_query_stats qs
    CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) st
    LEFT JOIN sys.dm_exec_requests r
        ON qs.sql_handle = r.sql_handle
ORDER BY 3 DESC

新しいクエリが SQL Server に発行されると、クエリ プランが評価、最適化、およびコンパイルされ、プロシージャ キャッシュに格納されます。クエリがサーバーに発行されるたびに、プロシージャ キャッシュが確認され、要求に合ったクエリ プランが検索されます。適合するものが見つからなかった場合、SQL Server はこの要求用に新しいプランを作成しますが、この操作によって負荷が上昇する可能性があります。
CPU のパフォーマンスを向上させるために T-SQL を最適化する際の考慮事項を次に示します。
  • クエリ プランの再利用
  • コンパイルおよび再コンパイル回数の削減
  • 並べ替え操作
  • 適切でない結合
  • インデックスの欠落
  • テーブルとインデックスのスキャン
  • SELECT 句と WHERE 句での関数の使用
  • マルチスレッド操作
では、先ほどと同じように、少し全体的な視点に立って考えてみましょう。通常、SQL Server はデータをメモリとディスクの両方から取得します。また、1 つのデータ ページのみが操作されることはあまりありません。多くの場合、アプリケーションの複数の部分で、レコードの操作、複数の小さなクエリの実行、テーブルの結合などが行われた結果、関連データの総合的な表示が提供されます。OLAP 環境では、アプリケーションが数百万行を 1 つまたは 2 つのテーブルから取得し、それらのデータを統合、ロールアップ、および要約して地域別売上レポートを作成している場合があります。このような状況では、データがメモリにある場合はミリ秒単位でデータが返されますが、同じデータを RAM ではなくディスクから取得する場合、このミリ秒が分単位に変わる可能性があります。
最初の例としては、大量のトランザクションがあり、プランの再利用率がアプリケーションによって異なる状況が挙げられます。クエリ プランの再利用率が低い場合、SQL ステートメントのコンパイル回数が増加し、その結果 CPU の処理量が大幅に増加します。2 番目の例としては、システム リソースの使用率が高いことが原因で、システムの CPU の負荷が高くなる状況が挙げられます。大量の新しいデータ ページ用の領域を確保する場合、既存のデータを頻繁にバッファ キャッシュからフラッシュする必要があるため、このような状況が発生します。
たとえば、トランザクション数の多いシステムがあるとします。このシステムでは、発送用のダンボールに関する情報を取得する次のような SQL ステートメントが、15 分間に 2,000 回実行されます。クエリ プランが再利用されない場合、1 ステートメントあたりの実行時間は 450 ミリ秒と仮定できます。最初の実行後、同じクエリ プランが再利用された場合、2 回目以降のクエリはおそらく約 2 ミリ秒で実行されるため、全体の実行時間は約 5 秒に短縮されます。
USE SHIPPING_DIST01;
SELECT
    Container_ID
    ,Carton_ID
    ,Product_ID
    ,ProductCount
    ,ModifiedDate
FROM Container.Carton
WHERE Carton_ID = 982350144;
トランザクションが多いシステムのパフォーマンスを最適化する場合、クエリ プランを再利用することが重要になります。これは多くの場合、クエリやストアド プロシージャをパラメータ化することで実現されます。クエリ プランの再利用については、次の資料を参照してください。
  • SQL Server 2005 のバッチのコンパイル、再コンパイル、およびプランのキャッシュに関する問題 (microsoft.com/technet/prodtechnol/sql/2005/recomp.mspx)
  • SQL Server のストアド プロシージャを最適化して再コンパイルを回避する (sql-server-performance.com/rd_optimizing_sp_recompiles.asp)
  • SQL Server 2000 におけるクエリの再コンパイル (msdn2.microsoft.com/aa902682.aspx)
SQL Server 2005 の動的管理ビュー (DMV) を使用すると、さまざまな情報を確認できます。CPU 使用率が高い場合、いくつかの DMV を使用して、CPU が適切に使用されているかどうかを判断できます。
1 つ目の DMV は sys.dm_os_wait_stats です。DBA は、この DMV を使用して、SQL Server が使用する各リソースの種類や関数を確認できます。また、この DMV では、使用される各リソースをシステムが待機する時間も計測されます。この DMV のカウンタは累積的です。つまり、システムの他の領域に影響している可能性があるリソースを特定するには、まずデータに目立った問題がないことを確認した後、DBCC SQLPERF('sys.dm_os_wait_stats', CLEAR) コマンドを実行して、カウンタのすべてのデータをリセットする必要があります。sys.dm_os_wait_stats DMV は、SQL Server 2000 でデータベースの整合性を確認するために使用するコマンドである DBCC SQLPERF(WAITSTATS) に相当します。待機の種類については、SQL Server Books Online (msdn2.microsoft.com/ ms179984.aspx) を参照してください。
すべての処理が最適な状態で実行されていても、通常はシステムで待機が発生することを認識しておいてください。必要なのは、それらの待機が CPU のボトルネックの影響を受けているかどうかを判断することです。シグナルの待機は、待機時間全体と比較してできる限り低い割合である必要があります。特定のリソースがプロセッサ リソースを待機する時間は、待機時間全体からシグナルの待機時間を減算することで求められます。この値は、待機時間全体の約 20% 未満である必要があります。
sys.dm_exec_sessions DMV は、SQL Server 上で開かれているすべてのセッションを表示します。この DMV では、各セッションのパフォーマンスの概要と、各セッションの開始後に実行されたすべての処理を確認できます。これらのデータには、セッションが待機に費やした時間、CPU 使用率の合計、メモリ使用量、読み取りと書き込みの回数などがあります。また、ログイン、ログイン時間、ホスト コンピュータ、およびセッションが最後に SQL Server の要求を発行した時刻も確認できます。
sys.dm_exec_sessions DMV を使用すると、アクティブなセッションのみを確認できるため、CPU 使用率が高い場合は、まずこのビューを参照してください。まず CPU 時間が長いセッションを確認します。次にその処理を実行しているアプリケーションとユーザーを確認し、さらに細かく調査していきます。sys.dm_exec_sessions DMV と sys.dm_exec_requests DMV の両方を使用することで、sp_who および sp_who2 ストアド プロシージャによって取得できる情報のほとんどを取得できます。sql_handle 列を使用してこのデータを sys.exec_sql_text 動的管理関数 (DMF) と結合すると、セッションが現在実行しているクエリを取得できます。図 3 のコードは、サーバーの現在の状態を確認するために、このデータをまとめて取得する方法を示しています。
Figure 3 サーバーの動作状況を特定する (Close Figure 3)
SELECT es.session_id
    ,es.program_name
    ,es.login_name
    ,es.nt_user_name
    ,es.login_time
    ,es.host_name
    ,es.cpu_time
    ,es.total_scheduled_time
    ,es.total_elapsed_time
    ,es.memory_usage
    ,es.logical_reads
    ,es.reads
    ,es.writes
    ,st.text
FROM sys.dm_exec_sessions es
    LEFT JOIN sys.dm_exec_connections ec
        ON es.session_id = ec.session_id
    LEFT JOIN sys.dm_exec_requests er
        ON es.session_id = er.session_id
    OUTER APPLY sys.dm_exec_sql_text (er.sql_handle) st
WHERE es.session_id > 50    -- < 50 system sessions
ORDER BY es.cpu_time DESC
このステートメントは、調査が必要なアプリケーションを特定する際に役立ちます。あるアプリケーションのすべてのセッションの CPU、メモリ、読み取り、書き込み、論理読み取りを比較し、CPU リソースが他のリソースよりも多く使用されていると判断した場合、そのアプリケーションの SQL ステートメントを調査します。
アプリケーションの SQL ステートメントの履歴を追跡する場合、SQL Server トレースを使用します。SQL Server Profiler ツールやトレース システム ストアド プロシージャを使用してこれらの履歴を記録することで、現在の状態を評価できます (詳細については、補足記事「SP によるトレース」を参照してください)。Profiler を確認して、CPU 使用率が高いステートメントのほか、ハッシュや並べ替えの警告、キャッシュの欠落など、赤いフラグでマークされている事項を調べる必要があります。これにより、リソース使用率が高い SQL ステートメントや期間を絞り込むことができます。Profiler は、SQL ステートメントのテキスト、実行プラン、CPU 使用率、メモリ使用量、論理読み取り、書き込み、クエリ プランのキャッシュ、再コンパイル、キャッシュからのクエリ プランの取り出し、キャッシュの欠落、テーブルとインデックスのスキャン、統計の欠落、およびその他のさまざまなイベントを追跡できます。
sp_trace ストアド プロシージャまたは SQL Server Profiler を使用してデータを収集したら、通常はデータベースを使用します。このデータベースにトレース データを格納するには、トレースの完了後にデータを読み込むか、データベースへの書き込みを実行するようにトレースを構成します。トレースの完了後にデータベースにデータを格納するには、fn_trace_getinfo という SQL Server システム関数を使用します。この方法のメリットは、複数の方法でデータの照会と並べ替えを行い、最も CPU 使用率が高い SQL ステートメント、最も読み取り数が多い SQL ステートメント、再コンパイルの回数、およびその他の多くの情報を確認できることです。この関数を使用して、Profiler のトレース ファイルをテーブルに読み込む例を次に示します。既定では、指定したトレースのすべてのトレース ファイルが、作成された順序で読み込まれます。
SELECT * INTO trc_20070401
FROM fn_trace_gettable('S:\Mountpoints\TRC_20070401_1.trc', default);
GO

まとめ
これまで見てきたとおり、CPU 使用率が高い場合でも、必ずしも CPU がボトルネックになっているとは限りません。CPU 使用率が高い場合、他のさまざまなアプリケーションやハードウェアがボトルネックになっている可能性もあります。他のカウンタが正常な値であるにもかかわらず CPU 使用率が高い場合は、システム内に原因があるかどうかを調査し、解決策 (CPU の追加購入や SQL コードの最適化など) を特定します。どのような作業を行うにしても、あきらめないことが大事です。この記事のヒントを参考に、いくつかの調査を行って対策を実践すれば、SQL Server の CPU 使用率の最適化という実行プランを達成することは可能です。

Zach Nichter は、10 年以上の経験を持つ SQL Server プロフェッショナルです。DBA、チーム リード、マネージャ、コンサルタントなど、さまざまな SQL Server サポートの職を務めてきました。現在は、Levi Strauss & Co. の DBA アーキテクトとして、SQL Server のパフォーマンス、管理、アーキテクチャ、およびその他の戦略を主導しています。Zach は、www.sqlcatch.com で公開されているビデオ ブログの作者でもあります。


 編集長から: さらなる飛躍へ
編集長から
さらなる飛躍へ
Joshua Hoffman

信じられないかもしれませんが、過去の出来事を振り返ることで、私の初めての編集後記を始めたいと思います。このような文芸的手段を早々に使ったからといって、それが特に良い前兆であるというわけでもないのですが、書いていきましょう。
2005 年の夏、『TechNet Magazine』の 2 冊の創刊号は好評をはくしました。これを機に発行回数を増やし、IT プロフェッショナルへの優れた技術情報の定期的な配信が開始されました。編集主幹の Joshua Trupin と Stephen Toub (姉妹誌『MSDN Magazine』の当時の技術編集者) は、通常の仕事を抱えながらも優れた専門家を集め、創刊号を企画し、すばらしい仕事を成し遂げました。
私は新しい技術編集者としてチームに参加し、謙虚な気持ちで彼らの仕事を受け継ぎました。なんだかんだ言ってもやはり、雑誌を作るというのはすごいことなのです。私は IT プロフェッショナル (まさしくオタク) としての経歴を持ち、過去 4 年は Microsoft Consulting Services に勤務していました。出版作業に関する知識など、ほとんど持ち合わせていませんでしたから、読むべき資料は膨大でした。すぐに 3 つの号の企画を立てなければなりませんでした。新しいチームメイト、執筆者、技術校閲者、ビジネス パートナー、そして言うまでもなく、読者について知る必要がありました。そして何よりも、長年マイクロソフトに勤務していた者にとっては理解しがたい、絶対変更不可能な締め切りという課題もありました。
しかし、寛大で辛抱強く、ユーモアに富んだチームに支えられたおかげで、自分の仕事を成し遂げることができました。著者、校閲者、そして読者である皆さんのおかげで、この仕事は魅力的でやりのある、かつ実り多い仕事となりました。また、この仕事を通じて、多くの新しい友人を作る機会に恵まれました。過去 2 年を振り返り、このチームで成し遂げたことを誇りに思います。しかし今は、新しい編集長として、今後の仕事に胸を弾ませています。
本誌は、IT プロフェッショナルがマイクロソフトの製品とテクノロジを使用して、成功を収めるのに役立つことを使命としています (私たちの給与は、何よりも皆さんの成功の是非で決まります)。読者の皆さんからは、本誌について、良かった点や、さらに重要なことには、改善の必要な点についてご指摘いただいております。私たちは読者からのフィードバックを真摯に受け止め、絶えず本誌の向上のために取り組み、新しい執筆者やコラムを取り入れたり、新しいコンテンツやメディアによってオンライン プラットフォームを一層強化したり、皆様に最良の方法で活用していただけるように努めてまいります。これらのことは、皆様からの継続的なフィードバックなしでは成功しません。皆様のご意見、ご要望をお聞かせください。私たちが何をすべきか。その鍵は皆さんが握っています。tnmag@microsoft.com (英語) 宛に、電子メールで皆さんのご意見をお聞かせください。—Joshua Hoffman

次のマイクロソフト技術支援スタッフに心より感謝します。Omesh Desai、Raja Ganjikunta、Saleem Hakani、Justin Hall、Michael Murgolo、John Orefice、Jim Truher、Marc Umeno、Jeff Wettlaufer、Buck Woody、Minxiao Zhou


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

スクリプト作成環境の強化
PowerShell Analyzer
www.pwershellanalyzer.com
Windows PowerShell™ についていろいろとうわさになっています。これには正当な理由があります。今までに、この次世代のスクリプト言語を使用する機会がなかった方は、実際に確かめてみてください。Microsoft® Exchange 2007 にアップグレードした方であれば、新しい Exchange 管理シェルが Windows PowerShell に基づいて構築されていることがすぐにわかるでしょう。Exchange 管理シェルでは、Exchange 管理コンソールで行えるすべての操作をコマンド ラインから実行できるため、反復的なタスクを自動化するのに役立ちます。残念ながら、構文とセマンティクスを理解するには多少の学習が必要になりますが、ここで ShellTools が提供する PowerShell Analyzer が役立ちます。
このアプリケーションは、基本的には Windows PowerShell スクリプトを作成したりデバッグしたりするための IDE です。しかし、従来の "記述 - コンパイル - テスト" のサイクルとは違って、"キーボードで管理" の精神に従い、Windows PowerShell の実行空間とのリアルタイムでの対話が可能です。PowerShell Analyzer を使用すると、コマンドを 1 行ずつ入力するか、または UI の下部にあるエディタで Windows PowerShell スクリプトを作成、編集、および実行できます。どちらの方法でも、基本的なコード補完機能を使用できるので、コマンドレットの多くのパラメータを参照するのに役立ちます (Windows PowerShell を初めて使用する方のために説明しますが、コマンドレットとは、抽象的な、タスク指向のパラメータ化されたコマンドのことです)。
さらに役立つ機能として、PowerShell Analyzer には、クイック アクセス タブが用意されています。このタブには、各コマンドレットについて詳細な説明、構文、パラメータの説明、および例が表示されます。さらに、Windows PowerShell プロバイダ、使用可能な組み込みのヘルプ ファイル、およびコマンドレットの短いエイリアスに関する参考資料もあります。
コマンドを Windows PowerShell から実行すると、実際に返されるのは、画面上の明らかなテキスト出力結果ではなく Microsoft .NET Framework オブジェクトです。PowerShell Analyzer を使用すると、返された結果のプロパティを取得して、それらを多くの "ビジュアライザ" に渡すことができます。これらのビジュアライザを使用すると、ツリー形式で XML データを調べたり、データを並べ替えやグループ化が可能な階層構造のテーブル ビューに表示したりして、オブジェクトと対話できます。また、さまざまなグラフを生成して、返されたデータセットを可視化することもできます。もちろん、実行するすべてのコマンドやスクリプトに対して、これらのすべてのオプションを使用できるわけではありません。しかし、使用できる場合は、データを適切に表現して、後で再利用できるように保存したりエクスポートしたりできます。
PowerShell Analyzer では、複数の実行空間を同時に操作して、タスクを容易に切り替えることもできます。また、エディタ ウィンドウには、コードのアウトライン表示機能や、カスタマイズ可能なコードの強調表示スタイルが用意されており、スクリプトを読みやすくすることができます。
つまり、Windows PowerShell を使用する場合に、PowerShell Analyzer のようなツールを使用すると、スクリプトの作成、編集、デバッグ、およびデータの可視化を容易に行えます。

価格 : 129 ドル (直販、1 ライセンスごと)
PowerShell の図

ディスクを最適化する
Auslogics Disk Defrag
www.auslogics.com/disk-defrag
ハード ディスクを使えば使うほど、そのディスク上の断片化されたファイルは増えます。ファイルの作成や削除、アプリケーションのインストールや削除、一時的なディスク キャッシュやファイルの生成などは、すべて断片化の原因となります。また、ディスク上の空き領域が少なくなると、ほとんどいっぱいになっている領域内の使用可能な "ホール" (穴) に新しいファイルが分散されるため、断片化の割合が大幅に高くなる可能性があります。このような断片化は、システム パフォーマンス低下につながります。
もちろん、皆さんもご存知のとおり、Windows® の最新バージョンには、最適化ツールが組み込まれています。しかし、専用オプションを探している場合や、最近 Windows Vista® にアップグレードして、前のバージョンの最適化ツールで提供されていたコントロールや UI を使いたい場合などは、Auslogics の Disk Defrag という、非常に興味深いツールを試してみることをお勧めします。
Disk Defrag は、Windows XP、Windows 2000、Windows Server® 2003、および Windows Vista で動作します。そしてお望みどおり、FAT16、FAT32、および NTFS ボリュームを最適化できます。このアプリケーションは軽量で、数回クリックするだけでインストールできます。
アプリケーションの実行も簡単です。最適化するドライブを選択し、[Next] (次へ) をクリックして、進行状況を見守るだけです。実行が完了すると、結果の概要が表示されます。この概要には、ファイル、ディレクトリ、断片化されているファイル、最適化されたファイル、およびスキップされたファイルの合計数と、断片化が何パーセント減少したかが含まれます。必要であれば、Disk Defrag の [Display Report] (レポートの表示) ボタンをクリックして、HTML 版の最適化レポートを生成することもできます。このレポートには、ディスクに関する便利な追加情報が含まれます。たとえば、スキップされたファイルとその場所の一覧、断片の数、実行の経過時間、ディスクのクラスタ情報などです。

価格 : 無償
インストールおよび使用が容易な Disk Defrag
インストールおよび使用が容易な Disk Defrag

ファイルを転送する
FileZilla
filezilla.sourceforge.net
優れた SFTP クライアントほど、作業を楽にしてくれるものはありません。このことは特に、FileZilla クライアントのように、クライアントが堅固に作成されていて無償である場合に当てはまります。FileZilla は、オープン ソースのプロジェクトであり、SourceForge.net 上でホストされています。Tim Kosse 氏と彼の数人の仲間によって、コンピュータ サイエンス クラスのプロジェクトとして 2001 年に開始されました。FileZilla は、Windows NT®4.0 から Windows Vista まで、すべてのバージョンの Windows で動作します。プロジェクトはこの 6 年間で大幅に拡大しましたが、現在でも Kosse 氏がこのアプリケーションのプロジェクト リーダーを務めています。
標準の FTP 接続に加えて、このクライアントでは、Secure Shell バージョン 2 (SSH2) を使用した SFTP 経由の接続、および暗黙的および明示的な暗号化に対応した FTP over TLS と FTP over SSL 経由の接続をサポートします。これにより、多種多様なサーバーに接続できます。また、使用するローカル ポートを制限したり、IPv4 と IPv6 の両方に対して非パッシブ転送用の特定の IP バインドを設定することで、FileZilla をローカル ファイアウォールに対応させることが可能です。このクライアントは、SOCKS4/5、HTTP1.1、FTP プロキシなどの多くのプロキシ構成もサポートしています。
FTP 接続のサーバー認証に関しては、FileZilla は、匿名、通常のユーザー名とパスワード、およびアカウント ベースの構成をサポートしています。さらに、Kerberos Generic Security Services (GSS) のサポート (システムへの Kerberos for Windows のインストールが必要) を有効にして、GSS 対応のサーバーのリストを作成できます。もちろん、GSS を使用するには、有効な Kerberos V5 チケットが必要です。Ident サーバーのサポートを有効にすることもできます。Ident サーバーは、クライアントを識別する手段として Ident サーバーを必要とするサーバーに接続する場合に使用します。
FileZilla では、多数の FTP サイトを容易に管理したり、接続をツリーに似た構造に整理したりできます。設定した接続ごとに、既定のローカル ディレクトリやリモート ディレクトリの設定、接続先のポートの指定、構成済みプロキシを使用しないオプションの選択、アクティブまたはパッシブ転送モードの明示的な選択、およびサーバーのタイム ゾーン オフセットの設定も行えます。保存された接続以外に、FileZilla には、一度だけの転送用にクイック接続機能も用意されています。この機能を使用すると、アドレス、ユーザー名、パスワード、およびポートを入力してボタンをクリックするだけで接続できます。すべての設定と接続を構成したら、それらを XML にエクスポートして、バックアップしたり他のシステムで再利用したりできます。
このアプリケーションの UI は Windows エクスプローラのインターフェイスに似ており、ローカル システムとリモート システムの間で簡単にファイルをドラッグ アンド ドロップできます。ファイル転送に関しては、ダウンロードとアップロードの速度を定義済みのルール セットに基づいて制限するオプション、一定の速度 (kBs) で制限するオプションがあります。これらのオプションの他に、既定のファイル上書き設定も指定できます。既定では、FileZilla は、MODE Z をサポートするサーバー上では MODE Z による圧縮ファイル転送を使用するように構成されています。ただし、圧縮レベルを調整したり、この機能を無効にすることもできます。また、転送キュー機能もあります。この機能を使用すると、転送するファイル セットをキューに入れて、その転送リストをインポートしたりエクスポートしたりして再利用できます。これは反復的なシステム管理タスクに最適な機能です。

価格 : 無償

実行可能ファイルを編集する
PE Explorer
www.heaventools.com
アプリケーションの核心に迫ってみたいと思っている方は、HeavenTools が提供する PE Explorer を試してみることをお勧めします。このアプリケーションを使用すると、Windows アプリケーションの実行可能バイナリに使用されている、Portable Executable (PE) ファイルの内部を詳しく調べることができます。簡単に言えば、PE Explorer には、これらの実行可能ファイルの内容を調べたり編集したりするための UI が用意されています。PE Explorer では、EXE や DLL などの一般的なファイルから、DPL や CPL などの珍しいファイルに至るまで、さまざまな種類のファイルを開くことができます。
最初に実行可能ファイルを調べると、PE Explorer には、ファイルのヘッダーに関する情報が表示されます。たとえば、コード セクションの数、イメージのサイズ、アプリケーション サブシステム、スタック サイズ情報などです。別のビューには、実行可能ファイル内のセクション ヘッダーの概要が表示されます。セクション ヘッダーをダブルクリックすると、ウィンドウが開き、各セクションの内容を調べることができます。
気弱な人には向きませんが、このアプリケーションでは、読み込んだ PE のセクションの抽出、再計算、および削除が可能です。ウイルス、マルウェア、およびその他の危険な実行可能ファイルの検出に最適なツールとして、このアプリケーションの Digital Signature Viewer を使用すると、読み込んだ実行可能ファイル内の Microsoft Authenticode デジタル署名 (存在する場合) を確認および検証できます。これは、実行可能ファイルの発行元と整合性を確認するための強力な手段です。
PE Explorer には、高速な逆アセンブル機能も組み込まれています。この機能を使用すると、実行可能ファイルのアセンブリ コードを確認できます。PE Explorer は、一般的な Intel x86 の命令セットと、MMX、3D Now!、SSE/2/3 などの拡張命令セットをサポートしています。逆アセンブラは、PE のデータ部分から ASCII テキスト文字列を抽出することもできます。
Dependency Scanner という機能もあります。この機能は、PE ファイルが静的にリンクしているすべてのモジュールと遅延読み込みされたモジュールをスキャンし、それらのモジュールを階層ツリー構造で表示して、PE のリンク先を示します。
PE Explorer の中で私がとてもおもしろいと思う機能 の 1 つは、Resource Editor です。この機能を使用すると、指定した実行可能ファイルのリソースの表示、抽出、置換、編集、および削除ができます。UI には、画像、サウンド、ダイアログ、メニュー、XML データ、HTML データ、ツールバーなどの埋め込みリソースがディレクトリに似た構造で表示されます。これらのリソースのすべてを直接編集できるとは限りませんが、ほとんどのリソースは置換と編集が可能です。これにより、実際のソース コードにアクセスしなくても、自分のカスタム ブランドをアプリケーションに追加したり、ダイアログ メッセージを変更したり、ツールバーのアクションをカスタマイズしたりできます。PE Explorer は、実行可能ファイルを詳しく調べたいユーザーにとって非常に便利なツールです。ただし、本当に必要な唯一の機能が Resource Editor である場合は、同じ会社が提供する低価格の Resource Tuner アプリケーションをご検討ください。

価格 : $129 (直販、個人ライセンス)、$199 (直販、ビジネス ライセンス)
PE Explorer のスクリーンショット
PE Explorer のスクリーンショット

ブック レビュー
『Endpoint Security』
www.awprofessional.com
堅牢な従来のネットワーク境界を社内のインフラストラクチャに追加することは、資産を保護する上で重要な作業です。ただし、これは確実な方法ではありません。今日のハードウェアとソフトウェアでは移動性と接続性が向上しているため、企業インフラストラクチャに本当の意味での境界は存在しません。それどころか、インフラストラクチャはリモート エンドポイントにまで拡大しています。実際、自分の環境の外部からの攻撃を防いでいても、自宅からノート パソコンを持ち込んだユーザーが管理されていない企業ネットワークに接続し、無意識のうちに攻撃を開始する可能性があります。
ネットワーク アクセス制御に関する情報を把握して、インフラストラクチャのエンドポイントをセキュリティで保護したいと思っている場合は、Mark Kadrich 著『Endpoint Security』 (Addison-Wesley Professional、2007 年) を参照することをお勧めします。この書籍では、最初にエンドポイントの正確な意味を定義し、Windows クライアント、Linux クライアント、埋め込みデバイス、携帯電話、PDA (携帯情報端末) などの多くの種類を紹介しています。Kadrich 氏は、ネットワークを "管理上の問題" と考えています。一般的である有機的なたとえで複雑なネットワークを表現するのではなく、便利な管理しやすい方法で描写および視覚化できるものとして複雑なネットワークを説明しています。
この書籍では、ネットワーク アクセス制御 (NAC) の基本と、基本レベルの信頼の確立について詳しく説明しています。ソース ソフトウェアとビルド環境のセキュリティ保護と管理によって、エンドポイント システム用の安全なベースラインを構成する方法も説明されています。エンドポイントのセキュリティと信頼性を保持するのに役立つツールの概要では、ファイアウォールやウイルス対策ソフトウェアなどのおなじみのツールについて説明し、事前対応型のパッチ管理、最終的には高度なツール (侵入検出および防止システム、ホスト整合性チェック ツール、暗号化など) の必要性を指摘しています。
この書籍の後半では、多種多様なクライアントのオペレーティング システム (Microsoft Windows、Apple OS X、Linux など) のセキュリティ保護について詳しく説明しています。後半の各章には、エンドポイント システムに対して初期の状態確認を実行する方法の概要が示されています。また、PDA、Smartphone、および埋め込みデバイスのための独立した章もあり、これらのデバイスがどのようにインフラストラクチャにとって深刻な脅威となっているのか、また、これらのデバイスにおける多種多様な通信をセキュリティで保護する方法について説明しています。
最後に、Kadrich 氏は 4 つのケース スタディを取り上げ、それぞれについて、エンドポイントがどのように危険にさらされたか、また、どのように障害に対処できたかを説明しています。全般的に『Endpoint Security』には、セキュリティ プロフェッショナルにとって有用な情報が記載されており、エンドポイント境界の視点から、ネットワークのセキュリティ保護についてベンダにとらわれない見解が示されています。

価格 : 54.99 ドル (定価)

Greg Steen は技術プロフェッショナルであり、企業家でもあります。また、新製品のファンとも言えます。より簡単な操作、開発に役立つ IT プロフェッショナルのためのツールと参考資料を日夜追い求めています。ご提案などがございましたら、tntools@microsoft.com (英語) 宛に電子メールをお送りください。


 SQL に関する Q&amp;A: ログインのトリガ、データ ファイルのデフラグなど
SQL に関する Q&A
ログインのトリガ、データ ファイルのデフラグなど
Nancy Michell

サービス アカウントを設定する
ヒント : より安全なパスワード
SQL Server 2000 エンジンでは、SQL Server のログインごとに 2 つのログイン パスワードを保持しています。1 つ目はユーザーによって入力された実際のパスワードで、2 つ目はすべて大文字のパスワードです。
この方法は、大文字と小文字を区別しないパスワードの検証で役に立ちます。なぜなら、ユーザーは大文字と小文字が混在するパスワードと大文字のみのパスワードのどちらを使用してもログインでき、サーバーへのアクセスが許可されるからです。ただし、この便利な機能には問題があります。すべて大文字のパスワードを保持すると、考えられるパスワードの数が減り、ブルート フォース攻撃によるパスワードの推測が容易になります。
SQL Server 2005 では元のパスワードのコピーのみが保持されます。ユーザーが入力するパスワードは、サーバーで保持されているパスワードと一致する必要があります。パスワードが一致しない場合は、ログインは失敗しユーザーのアクセスは拒否されます。大文字と小文字の使用を含め正確なパスワードの文字列を忘れてしまった場合は、パスワードをリセットする必要があります。
ユーザーのログイン名が SQLCOMMUNITY の場合、次のコマンドを使用して、この SQL Server ログインのパスワードをリセットすることができます。
Use Master;
ALTER LOGIN SQLCOMMUNITY WITH PASSWORD = 'k3t9h4s8wJF7t';
このコマンドは、SQL Server ログイン SQLCOMMUNITY のパスワードを k3t9h4s8wJF7t にリセットします。

質問 - SQL Server™ 2000 では、管理ツールのサービス アプレットで SQL Server エンジンと SQL Server エージェントのサービス アカウントを設定していました。SQL Server 2005 では、構成マネージャ ツールを使用する必要があるという話を耳にしました。どうして Windows のツールを使い続けることができないのでしょうか。
回答 - SQL Server 2005 は以前のバージョンよりもセキュリティを考慮したデザインになっています。多くの企業では、ユーザーは SQL Server を実行するために LocalSystem などの内部アカウントを設定しています。しかし、多くの場合、このようなアカウントは、ユーザーが必要とする Windows® の権利やアクセス許可のレベルを上回っているか、または下回っています。昇格した権限を持たない Windows アカウントを作成し、SQL Server 2005 エンジンと SQL Server 2005 エージェントのサービスを実行する必要があります。構成マネージャでサービス アカウントを選択すれば、SQL Server とオペレーティング システムの両方で適切な権利とアクセス許可が自動的に付与されます。Windows のツールを使用して SQL Server のサービスを管理すると、適切な権利が付与されないか、または過剰に権利を付与する可能性があります。
詳細については、「ヒント : サービス アカウントの変更」を参照してください。

サーバーにログオンしているユーザーを特定する
質問 - だれがいつサーバーにログオンしているか知りたいのですが。また、特定のユーザーについては特定の期間だけログオンできるように制限したり、トレースを起動してユーザーの操作を追跡する方法を知りたいのですが。このようなことは可能でしょうか。
回答 - はい、Service Pack 2 がインストールされていれば、SQL Server 2005 でこういったことをすべてできます。
SQL Server 2005 では、ログイン トリガを作成することができ、LOGON イベントに応じて T-SQL やストアド プロシージャを起動することができます。ログイン トリガを使用して、ログイン操作の追跡、SQL Server へのログインの制限、特定のログインに対するセッション数の制限などをすることによって、ユーザーを監査または制御することができます。LOGON イベントは、ログインが正常に認証された後にしか発生しませんが、発生するのは、ユーザー セッションが実際に確立される直前です。そのため、トリガ内部で発生したすべてのメッセージ (メッセージやエラーなど) は、PRINT ステートメントから SQL Server のエラー ログに送信されます。ログインの認証が失敗した場合は、ログオン トリガは起動しません。
次の例では、ログイン トリガの作成方法と、ユーザーがログインすると同時に SQL Server のエラー ログにメッセージを送信する方法を示します。
ALTER TRIGGER Ops_Login
ON ALL SERVER
AFTER LOGIN
AS
PRINT SUSER_SNAME() + ' has just logged in to ' + LTRIM(@@ServerName) + ' SQL Server at '+LTRIM(getdate())
GO
サーバー レベルで設定されたすべてのトリガを表示するには、次のクエリを使用します。
SELECT * FROM sys.server_triggers;

デフラグのベスト プラクティス
質問 - SQL Server のデータ ファイルの断片化を解消する最善の方法は何でしょうか。Windows のデフラグ ツールでは、SQL Server のデータ ファイルは 1 つのデータとして処理され、きめ細かい最適化は行われません。
回答 - データベースをバックアップして復元することで、SQL Server のデータ ファイルの断片化を解消できます。連続ファイルに空き領域が含まれる場合、データベースも連続して記述する必要があります。そうは言うものの、一般的に、物理ファイルを最適化しても、その際に生じるダウンタイムに値する成果は得られません。通常は多くの外部断片化がないのが、その理由です。定期的にデータのインデックスを再設定し、内部断片化をできるだけ減らすことの方が断片化の解消に役に立ちます。こうすると、先読みの効果とバッファされるデータの量を最大化できます。
効率的なディスク入出力を実現するうえで最も重要な要因は、ディスクの配置と RAID 構成が正しいことを確認し、I/O の負荷を適切に処理するようにディスク アレイをスケール変換し、Log、Data、TempDB、およびバックアップ ファイルのレイアウトを適切に管理することです。データ ファイルのサイズ管理の主な方法として、自動拡張と自動圧縮を使用しない場合は、作成されるボリューム レベルのファイルの断片の数は減少します。たとえば、500 MB ごとの自動拡張を 10 回実行すると、新たに 10 個の物理ファイルの断片が追加されるでしょう。これに対して、5 GB を手動で 1 回拡張した場合、追加されるファイルの断片は 1 つだけです。

ヒント : サービス アカウントの変更
SQL Server サービスのログイン アカウントを Windows NT® アカウントで構成する際、SQL Server では Windows ユーザーの権利やアクセス許可がいくつかのファイル、フォルダ、レジストリ キーに設定されることをご存知でしたか。また、管理ツールのサービス コンソールから SQL Server のサービス アカウントを設定することもできます。ただし、サービス コンソールを使用して SQL Server のサービス アカウントを設定すると、権利とアクセス許可は設定されません。そのため、前述の SQL Server と Windows アイテムの適切なセキュリティ設定の欠如により、深刻な問題が発生することがあります。
したがって、SQL Server や SQL Server エージェントのサービス アカウントを変更する場合は、サービス コンソールではなく SQL Server 構成マネージャを使用することを強くお勧めします。ただし、既にサービス コンソールを使用してアカウントを変更してしまった場合でも、この問題を解決することができます。
手順 1: 次のレジストリ キーとそのサブキーに完全な権限を適用します。
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\90
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\<MSSQL.x>
手順 2: 次の NTFS フォルダで、MSSQLServer サービスと SQLServerAgent サービス (ローカルの Windows NT のアカウントか ドメインの Windows NT のアカウントのどちらか) のスタートアップ アカウントにフル コントロールを設定します。
Drive:\Program Files\Microsoft SQL Server\<MSSQL.1>\MSSQL
ただし、SQL Server または SQL Server エージェントのサービス アカウントを変更する場合は、手動で行うのではなく、SQL Server 構成マネージャを使用することをお勧めします。

技術的知識を提供してくれた次の Microsoft IT 技術支援スタッフの皆様に感謝します。Cary Gottesman、Saleem Hakani、Trayce Jordan、Peter Kalbach、Al Noel、Uttam Parui、Amber Sitko、Buck Woody


 ユーティリティ スポットライト: Virtual Machine Remote Control Plus
ユーティリティ スポットライト
Virtual Machine Remote Control Plus
Matthijs ten Seldam
この記事で使用しているコードのダウンロード: UtilitySpotlight2007_10.exe (10163KB)

仮想化は、今注目の話題です。多くの IT プロフェッショナルはハードウェアの仮想化を使用して、シナリオの学習およびテストを行っています。このためマイクロソフトでは、Virtual PC 2007 の提供を開始しました。これは、スタンドアロンでインストールして、限られた数のバーチャル マシンを使用するためのソフトウェア仮想化ソリューションです。この新製品は
データセンターを仮想化する Virtual Server 2005 に置き換わるものではありません。
Microsoft® Virtual Server 2005 では多くのサーバーの負荷を仮想化することができますが、インターフェイスが Web アプリケーションである点が Virtual PC と異なります。Web ベースの管理にはそれなりの利点があります。ただし毎日の業務のためには、Windows® アプリケーションのように動作するリッチな UI が望まれているのも事実です。
Virtual Machine Remote Control Plus、略して VMRCplus は、Virtual Server 2005 の代替 UI です。VMRCplus は Windows Forms アプリケーションであるため、Virtual Server とそのバーチャル マシンを容易に管理できます。Virtual Server には、バーチャル マシンをリモート コントロールするための VMRC というツールが付属していますが、VMRCplus には Virtual Server の構成を管理する機能と、バーチャル マシンをリモート コントロールする機能の両方を備えており、すべてを 1 つのアプリケーションで実行できます。

Virtual Machine Manager
VMRCplus のメイン ウィンドウは、Virtual Machine Manager (バーチャル マシン マネージャ) と呼ばれます (図 1 を参照)。この例では、Virtual Machine Manager は localhost に接続され、5 台のマシンが稼動しています。そのうち 3 台は保存された状態で、残りはオフです。リストの 6 番目のマシンが選択され、ゲスト オペレーティング システム、CPU の負荷、ディスクおよびネットワーク I/O の統計情報、およびインストール済みの追加バージョンなどの追加情報が表示されています。リストは [Status] (状態) によって並べ替えられています。
図 1 VMRCplus Virtual Machine Manager
図 1 VMRCplus Virtual Machine Manager
バーチャル マシンを表示させるには、Virtual Machine Manager から Virtual Server のホストに接続します。ホストを切り替えるには、ホストのタブを選択し、ツールバーのボックスの一覧からホストに接続するか、ホスト名または IP アドレスを入力します。接続に成功すると、ホスト名または IP アドレスがリストに追加されます。
CPU やメモリの情報など、Virtual Server のホスト プロパティの一部はウィンドウの下部に表示されます。メモリ メーターでは、バーチャル マシンで使用できる RAM の残量をひとめで確認できます。

Virtual Server の管理
Virtual Machine Manager は単に情報を表示するだけはありません。設定を構成することもできます。[View] (表示) メニューのオプションでは、VMRCplus が [Virtual Machine] (バーチャル マシン) リストを更新する間隔を設定できます。現在の更新間隔の設定は、ウィンドウの右下隅に表示されます (図 1 を参照)。
[Virtual Server] メニューからは、Virtual Machine Remote Control (VMRC) の設定、新しいバーチャル マシンの既定の場所、セキュリティ設定、サービスのプロパティなど、Virtual Server の構成にアクセスできます。[VMRC settings] (VMRC の設定) ページでは、任意のプロパティを設定したり、VMRC を完全に無効化したり、Virtual Server を既定の設定に戻したりすることができます。
Virtual Server のアクセス許可を変更するには、セキュリティの設定ページで行います。既定では、ローカルの Administrators グループが Virtual Server のフル コントロール権限を保有しています。ここでは、グループまたはユーザーのアクセス許可を指定できます。ローカル Administrators グループのメンバでない場合は、最初にグループまたはアカウントを追加し、適切なアクセス許可を設定する必要があります。ただし、VMRCplus を実際に実行する場合は管理者でなくてもかまいません。一般のユーザー アクセス権限で十分です。
物理的なプロパティも含め、Virtual Server ホストのプロパティを図 2 に示します。プロセッサの機能からわかるように、このホストはハードウェアで支援される仮想化をサポートします。
図 2 Virtual Server のプロパティ
図 2 Virtual Server のプロパティ

バーチャル ディスクおよびネットワークの管理
VMRCplus には、特定の Virtual Server 機能を対象とした "マネージャ" が含まれています。Virtual Disks Manager (バーチャル ディスク マネージャ) には、作成できる仮想ディスクの種類 (動的または固定のハード ディスク、フロッピー ディスク、差分ディスクなど) に対応したタブ付きインターフェイスがあります。バーチャル ディスクを検査することもできます。
Virtual Networks Manager (バーチャル ネットワーク マネージャ) では、バーチャル ネットワークを管理できます。バーチャル ネットワークは、バーチャル ネットワーク構成ファイル (NVC) から追加することも、新規に作成することもできます。バーチャル ネットワークの作成時に、ホスト ネットワーク アダプタを関連付けたり、ネットワークをゲスト専用として指定したりできます。また、同じウィンドウでバーチャル DHCP サーバーを有効にして、その設定を開くこともできます。

バーチャル マシンの管理
これまでに紹介したマネージャはすべて、Virtual Server の管理を行います。VMRCplus では、どのようにしてバーチャル マシンを作成および構成するのでしょうか。
バーチャル マシンの作成は非常に簡単です。つまり、メニューの [Virtual machine] (バーチャル マシン) から [Create] (作成) をクリックするだけです。表示されるダイアログ ボックスには、Virtual Server のものと同等の既定値がいくつか表示されますが、内容が一部異なります。たとえば、VMRCplus は常に 2 つのバーチャル ハードディスクを作成し、それらを SCSI に関連付けます。また VMRCplus では、一度に複数のバーチャル マシンを作成できます。これには [Create multiple virtual machines] (複数のバーチャル マシンの作成) をクリックし、必要な数を選択するだけです。指定したマシン名に、ハイフンと連番が自動的に追加されます。
非常に強力な機能として、親バーチャル マシンから複数のバーチャル マシンを作成する機能があります。最新のパッチ、サービス パック、修正プログラム、およびツールを指定してバーチャル マシンを作成し、それを他のバーチャル マシンのベースとして使用するとします。最終段階で sysprep を実行して親をシャットダウンすれば、複数のバーチャル マシンを作成して、親のプロパティを継承させることができます。
わずか数秒で、親に基づいて多くのバーチャル マシンを作成でき、新しいバーチャル マシンを同じ場所からすばやく起動できます。作業を完了したら (たとえば、テストを完了したら)、作成したバーチャル マシンを削除します。この操作も簡単です。VMRCplus では、バーチャル マシン リストから複数のマシンを選択することも、列を並べ替えることもできます。これにより、複数のバーチャル マシンを選択して削除 (登録を解除) する作業や、バーチャル マシンを削除 (この場合はファイルも削除) する作業を容易に実行できます。
この他にもバーチャル マシンで使用できる複数選択コマンドがあります。たとえば、複数のバーチャル マシンを選択して開始したり、コンソールを開いたり、状態を保存したりできます。これらの操作は、UI から実行することもショートカット キーから実行することもできます。
ハードウェアの設定ページを使用してバーチャル マシンを構成することも簡単です。メモリ量の設定、SCSI コントローラの追加、(ドラッグ アンド ドロップ操作による) ディスクまたはイメージの関連付け、およびネットワーク アダプタの有効化と構成を行うことができます。詳細プロパティ ウィンドウでは、より詳細な構成項目を設定できます。たとえば、特定のユーザー アカウントでバーチャル マシンを実行し、Virtual Server の起動時にマシンが自動的に起動するように設定することができます。

リモート コントロール
最後に、VMRCplus には、バーチャル マシンのリモート コントロール セッション (VMRC セッション) を提供する Console Manager (コンソール マネージャ) もあります。コンソールを開くには、実行中のバーチャル マシン (複数可) を選択し、プロパティ ツールバーのバーチャル マシン コンソール ボタンをクリックします。
[Console Manager] (コンソール マネージャ) ウィンドウ (図 3 を参照) には、リモート セッションの順番の付いたタブがあります。対応するタブをクリックすることで、バーチャル マシンの表示を切り替えることができます。頻繁に使用される機能を含むツールバーもあります。
図 3 Console Manager
図 3 Console Manager
図からわかるように、Console Manager にはコンテキスト メニューがあり、バーチャル フロッピー イメージや ISO イメージを関連付けたり、ホスト ドライブをマウントしたり、最新のパッチをインストールすることができます。また、CD/DVD およびフロッピー メディアの状態、バーチャル マシンの最新パッチのバージョン、現在アクティブなホスト キー、および動的な画面サイズ調整設定を示すステータス バーもあります。VMRCplus では、ホスト キーを設定できます。バーチャル マシンのハードウェア設定、および詳細プロパティにアクセスすることもできます。
VMRCplus には、この他にも便利な機能があります。たとえば、バーチャル マシン設定のスクリーン ショットを撮り、.jpg ファイルとして保存できます。これは、シナリオのトラブルシューティングを行う際に非常に役立ちます。"テキストをバーチャル マシンに送信する" (Send Text to Virtual Machine) こともできます。つまり、キー入力によりテキストをバーチャル マシンに送信できます。これはクリップボード機能ではありませんが、ホストからバーチャル マシンにプロダクト キーをコピーして貼り付ける必要があるような場合に便利です。
VMRCplus は当初、一部の基本機能を処理する開発者用ツールとして Paul Despe 氏によって開発されましたが、Virtual Server の全機能には対応していませんでした。また、これはテスト用にのみ使用され、多くの問題点もありました。私は、およそ 1 年前にコードを入手して書き直し、機能の強化と拡張に着手しました。その後、これはマイクロソフト社内の Virtual Server ユーザーの間で愛用されるようになりました。ただし、VMRCplus は、マイクロソフトによるサポート対象外のアプリケーションであることに注意してください。VMRCplus は現状のまま提供され、付属する使用許諾契約書が適用されます。
VMRCplus は Virtual Server 2005 Service Pack 1 用に開発されました。以前のバージョンとの互換性の問題はないはずですが、テストは Service Pack 1 でのみ行われています。このため、VMRCplus を使用する前に、お使いの Virtual Server ホストを Service Pack 1 に更新してください。VMRCplus は、TechNet Magazine の Web サイト (technetmagazine.com/code07.aspx) からダウンロードできます。

Matthijs ten Seldam は、Microsoft Consulting Services のプリンシパル コンサルタントです。 彼はセキュリティ、展開、および自動化の分野を担当しており、仮想化の分野を専門にしています。


 ビジネスにおける IT: 行政機関における IT インフラストラクチャの価値を計算する
ビジネスにおける IT
行政機関における IT インフラストラクチャの価値を計算する
Acer Maamoun

行政諸機関における、ハードおよびソフト両面での IT インフラストラクチャへの投資メリットを実証することは容易ではありません。一般の大企業では、あらゆる追加や整備に対して経営陣がビジネス ケース (投資対効果検討書) を作成し、その他の資金調達要求との兼ね合いを取りながら優先順位が付けられます。
ビジネス ケースの設定方法は多岐にわたるため、IT マネージャは特定組織の事情に最も適したビジネス ケースを選択する必要があります。このことは行政機関についても同様です。IT を業務上の他の優先事項とうまく提携させることが重要です。行政部門においては、プロジェクトおよび政策のポートフォリオ構築手法に公共的価値の概念を取り入れることにより、IT 組織はビジネス ケースを明確に示すことに成功しています。
インフラストラクチャの改善がいかにして生産性やサービスの向上につながるかを実証するビジネス ケースを構築するのは、困難なプロセスです。IT インフラストラクチャの投資価値を定義および評価するソリューションについて、実際に行政の IT 組織で採用されているものを見ていきましょう。

投資の正当性を評価する
IT 組織の共通の悩みは、あまりにも多くの要求が、これまた非常に多くのさまざまな業務領域から出されることです。そして言うまでもなく、それぞれが緊急度の高い要求なのです。新しい政策は、個々の部門の規制に関する要求や、ミッションの優先事項に対応しているという傾向があります。これらの政策はランダムな組み合わせのように見えながら、実際には特定の部門が求めている公共的価値と密接に関係している場合がよくあります。
一方で、個別部門の運営を支援するために分配される運営コストによって、エンタープライズ規模の機能や共有サービスのコスト (および価値) が見えなくなることがあります。このような環境では、新しいインフラストラクチャへの投資価値、またはエンタープライズ規模で影響を与える、あるいは個別部門の目標に間接的に対応する、既存インフラストラクチャの改良に対する投資価値の適切な評価は非常に困難です。
このため、米国一般調達局による連邦政府エンタープライズ アーキテクチャ フレームワーク (GSA Federal Enterprise Architecture Framework) (whitehouse.gov/omb/egov/a-1-fea.html) (英語) に説明されているように、IT 組織はエンタープライズ規模での IT サポートが困難であると考えがちです。このような環境では、エンタープライズ アーキテクチャにおける共有された見解、共通のビジネス ケース開発モデル、およびポートフォリオ管理プロセスを採用した IT 投資の要望と支出の公平化に対するほとんどの取り組みは、実現が困難です。より効率的なモデルは、公共的価値のメリットを効果的かつ最大限に引き出す活動をサポートすることです。この場合、共通の公共的価値基準を選択し、ビジネス ケース開発、ポートフォリオ管理、メリットの実現、および評価のプロセス全体に対して適用する必要があります。

価値を測定する
実際にエンタープライズ規模の IT 投資には、いくつかの実質的な問題があります。第一に、公共的価値のメリットに関する影響は間接的かつ長期的です。これらのメリットは、組織の部分ごとに不均衡に発生することが多く、必ずしも容易に特定できるわけではありません。そのうえ、関連するリスクやコストの方が、視覚的に定量化するのが難しい公共的価値よりもずっと認識されやすいのです。
インフラストラクチャ投資により、将来の投資および現在の活動をどのように達成できるかに基づいて、ビジネス ケースを作成する必要があります。この価値を計算する方法は複数ありますが、どれにも長所と短所があり、それぞれに特定の組織の事情や成熟度に対する適合性が異なります。
数学的モデル これらのメソッドは、潜在的なメリットの数学的モデリングに基づいています。1 つの効果的なメソッドは「リアル オプション」と呼ばれ、財務理論に基づきます。一定期間中に定められたコストで何らかの行為を行う権限 (つまりリアル オプション) を明示的に考慮することにより、将来的な変更と柔軟性を検討します。オプションには、投資の遅延、拡大、準備、中止、入力または出力の変更、試験的なプログラムの開発などが含まれます。
リアル オプションは、投資決定が将来のイベントの影響を受ける場合に特に適しています。IT インフラストラクチャの場合、このようなイベントとして、規制に関する要件、ビジネス要求、大規模な運用上の障害などの重要なイベントなどが挙げられます。
シミュレーション 不確定性解析はモンテ カルロ シミュレーションに基づきます。これは自動ツールを使用し、変数値の選択とプロセスの繰り返しに基づいて代替シナリオの結果を計算します。このシミュレーションでは、値の範囲 (影響を受けるワークステーションの台数や、電子チャネルの取り込み数など) と各変数の確率分布を特定する必要があります。シミュレーションの結果は可能性のある結果の範囲であり、メリットおよびコストとリスクの平均値を特定することができます。値およびリスク変数を慎重に選択してインフラストラクチャ投資の予測インパクトを反映することで、投資収益を適切に算出することができます。
シナリオ 数学的モデルまたはシミュレーション モデルが実用的でない場合や、組織の事情とスキルに適さない場合は、代わりにシナリオベースの手法を使用できます。官庁の業務やミッション、政治的な優先事項、環境の傾向 (テクノロジを含む) を考慮することで、次の 3 ～ 5 年に関する説得力のあるシナリオをいくつかに絞って作成することができます。各シナリオは、インフラストラクチャ投資のメリットを実証することだけを目的とします。
長期的な計画とは異なり、シナリオは相互に排他的である必要はなく、また将来の可能性や確率に適応できます。シナリオでは、将来の選挙、政治的論争の結果、企業買収やベンダー戦略における大きな変化などの IT 市場の動向を考慮することができます。
最悪の場合のシナリオ これはシナリオ ベースの手法の 1 つであり、近いうちに発生するビジネスまたはミッションの変更に対応するため、または現在のサービス レベルを維持するために緊急に投資が必要であると IT 組織が考える場合に使用されます。インフラストラクチャの問題が対応されない状態では問題が悪化し、問題を解決するために必要な労力が増えることになります。変更を推し進める人は抵抗に直面し、その努力はなかなか評価されません。このような状況は、影響を受ける業績に関する評価尺度と評価 (たとえば要求に対する応答時間や修理に要する時間) を強調することで部分的に対処することができます。この情報は幅広く公開し、人々が業績の変化の可能性に気づきやすいようにする必要があります。
最悪の場合のシナリオは、否定的な結果とリスクの増大に焦点を合わせ、投資を行わない場合の結果を意図的に強調するものです。この手法は、例外的な場合に限って、しかも細心の注意を払って使用します。この手法を定期的に使用すると、確立された投資管理プロセスを IT 組織が覆そうとしているような印象を与え、意見の対立や、こうしたプロセスでまさに解決しようとした不均衡につながる場合もあります。

計画方法を選択する
図 1 に各メソッドの長所と短所、およびどのような場合にそれらを検討するかをまとめました。投資効果を確実に比較できるようにするためには、一度選択したメソッドを組織全体で一貫して使用する必要があります。
Figure 1 ビジネス ケースの手法 (Close Figure 1)

メソッド 利点 欠点 検討する場合
リアル オペレーション (数学的メソッド)
  • 綿密性
  • 確かな理論に基づく
  • 複雑
  • 無形価値が多い場合は不適切
  • 価値および将来価値をほとんど定量化できる場合
  • 堅実な投資評価の考え方がある場合
  • スキルをすぐに使用できる場合
シミュレーション
  • 代替価値を検討できる
  • 代替手段を容易に構築できる
  • 無形資産については平均値が無意味な場合がある
  • 変数の範囲選択が非常に重要
  • 明白に認識できるメリットが多い場合
  • ツールのサポートが利用可能な場合
シナリオ
  • 有形無形のメリットを任意に組み合わせることができる
  • 異なる手法を組み合わせて、まったく異なるシナリオを検討できる
  • 比較可能なシナリオにまとめるための厳しい規律が必要
  • 計画対象期間が異なる場合がある
  • 無形価値が多い、またはメリットの本質が不明瞭な場合
  • 組織の考え方が他のメソッドに反する場合
最悪の場合のシナリオ
  • 投資を行わない場合の結果を効果的に視覚化する
  • 作成が簡単
  • 優先順位を付ける上では役に立たない
  • 誤用のおそれがある
  • 投資が必要不可欠で期限を過ぎている場合
説明した手法の効果は、さまざまな要因によって変わります。このため、まずは次の質問に答えることから始めると良いでしょう。予算や資本計画などの必須プロセスとの統合性または互換性のレベルはどの程度か。選択したビジネス ケース メソッドは使いやすいか。利害関係者に効率的に価値を伝えることができるか。
組織は、特定の部門に適合する指針値を選択する柔軟性と、すべての部門での比較を確実に行えるようにするための指導のバランスを取る必要があります。さらに、ビジネス ケースの期間中だけでなく、投資のライフサイクルを通じて一定の評価基準を使用できることが非常に重要です。同様に、さまざまな種類の投資に対応する実用性も必要です。
つまり、価値に対するアプローチは、組織の統治構造内の関係者と協力して選択し、開発することが必要です。選択したフレームワークにより、内部および外部の利害関係者に効率よく価値を伝えるこができるようになることが重要です。このことは、選出議員や官庁だけでなく、企業経営者にも当てはまります。
参考資料
  • Web キャスト: 戦略的なビジネス資産としての IT
  • IT マネージャ コネクション シリーズ

Acer Maamoun は、マイクロソフト勤務のエンタープライズ戦略コンサルタントです。彼は、IT 戦略および業務提携の分野で 18 年以上の経験があります。


 The Cable Guy: 認証済みインターネット プロトコル
The Cable Guy
認証済みインターネット プロトコル
Joseph Davies
このコラムには、Windows Server 2008 のプレリリース版に関する説明が含まれています。記載されている内容は変更されることがあります。

Windows Vista および Windows Server 2008 (現在ベータ テスト段階) は、いずれも、インターネット キー交換 (IKE) プロトコルの拡張版である認証済みインターネット プロトコル (AuthIP) をサポートしています。AuthIP も IKE も、キー マテリアルを特定するために使用されるプロトコルで、
インターネット プロトコル セキュリティ (IPsec) を使用して保護される通信のセキュリティ パラメータをネゴシエートします。AuthIP では、多くの構成で、IPsec ポリシー構成と保守が容易になり、IPsec ピア認証の柔軟性が高まります。この記事では、AuthIP のプロトコルの詳細と、AuthIP と IKE の両方をサポートするか IKE のみをサポートする IPsec ピア間の共存動作について説明します。

IKE の概要
ネゴシエーションの例
具体的な共存動作を確認するために、Windows Vista ベースと Windows XP ベースの IPsec ピア間で IPsec 保護をネゴシエートする際の処理を調べてみましょう。

例 1: 要求モードの 2 つの Windows Vista ベースの IPsec ピア
この例では、Windows Vista ベースの IPsec ピア (Peer 1) がイニシエータで、レスポンダ (Peer 2) でも Windows Vista を実行しています。どちらのピアも、着信と発信の両方に要求 (Request) モードが構成されています。要求モードでは、IPsec ピアが IPsec 保護を要求しますが、必須とはしません。交換されるメッセージを以下に示します。
  1. Peer 1 から TCP 同期 (SYN) セグメントをクリア テキストで送信し、Peer 2 との TCP 接続を開始します。
  2. Peer 2 から TCP SYN-Acknowledgment (ACK) セグメントを送信します。
  3. Peer 1 から TCP ACK セグメントを送信します。
  4. Peer 1 から AuthIP ベースの ISAKMP メッセージを送信し、AuthIP のメイン モード ネゴシエーションを開始します。
  5. Peer 1 から IKE ベースの ISAKMP メッセージを送信し、IKE のメイン モード ネゴシエーションを開始します。
  6. Peer 2 から AuthIP ベースの ISAKMP メッセージを応答として返し、AuthIP のメイン モード ネゴシエーションを続行します。
  7. Peer 1 と Peer 2 が AuthIP のメイン モード、クイック モード、および拡張モード (省略可) のネゴシエーションを完了します。
  8. この TCP 接続経由で送信されるこれ以降のセグメントが、IPsec により保護されます。
メッセージ 1 ～ 5 の正確な順序は、ネットワークの待ち時間によって異なります。この記事の例は、待ち時間が非常に短いネットワークを想定しています。このようなネットワークでは、Peer 1 が初期 ISAKMP メッセージ (メッセージ 4 と 5) を送信できるようになる前に、TCP ハンドシェイク (メッセージ 1 ～ 3) が完了します。待ち時間が長いネットワークでは、Peer 1 がクリア テキストの TCP SYN セグメント、AuthIP ベースの ISAKMP メッセージ、および IKE ベースの ISAKMP メッセージを、メッセージ交換の最初の 3 メッセージとして送信します。

例 2: 要求モードの Windows Vista ベースの IPsec ピアと要求モードの Windows XP ベースの IPsec ピア
この例では、Windows Vista ベースの IPsec ピア (Peer 1) がイニシエータで、レスポンダ (Peer 2) は Windows XP を実行しています。どちらのピアも、着信と発信の両方に要求モードが構成されています。交換されるメッセージを以下に示します。
  1. Peer 1 から TCP SYN セグメントをクリア テキストで送信し、Peer 2 との TCP 接続を開始します。
  2. Peer 2 から TCP SYN-ACK セグメントを送信します。
  3. Peer 1 から TCP ACK セグメントを送信します。
  4. Peer 1 から AuthIP ベースの ISAKMP メッセージを送信し、AuthIP のメイン モード ネゴシエーションを開始します。
  5. Peer 1 から IKE ベースの ISAKMP メッセージを送信し、IKE のメイン モード ネゴシエーションを開始します。
  6. Peer 2 から IKE ベースの ISAKMP メッセージを応答として返し、IKE のメイン モード ネゴシエーションを続行します。
  7. Peer 1 と Peer 2 が IKE のメイン モードとクイック モードのネゴシエーションを完了します。
  8. この TCP 接続経由で送信されるこれ以降のセグメントが、IPsec により保護されます。

例 3: 要求モードの Windows Vista ベースの IPsec ピアと必須モードの Windows XP ベースの IPsec ピア
この例では、Windows Vista ベースの IPsec ピア (Peer 1) がイニシエータで、レスポンダ (Peer 2) は Windows XP を実行しています。Peer 1 では発信に要求モードが構成され、Peer 2 では着信に必須 (Require) モードが構成されています。必須モードでは、IPsec ピアは IPsec 保護を必須とし、保護されていないパケットを確認なしで破棄します。交換されるメッセージを以下に示します。
  1. Peer 1 から TCP SYN セグメントをクリア テキストで送信して TCP 接続を開始しますが、Peer 2 ではこのメッセージを確認なしで破棄します。
  2. Peer 1 から AuthIP ベースの ISAKMP メッセージを送信して AuthIP のメイン モード ネゴシエーションを開始しますが、Peer 2 ではこのメッセージを確認なしで破棄します。
  3. Peer 1 から IKE ベースの ISAKMP メッセージを送信し、IKE のメイン モード ネゴシエーションを開始します。
  4. Peer 2 から IKE ベースの ISAKMP メッセージを応答として返し、IKE のメイン モード ネゴシエーションを続行します。
  5. Peer 1 と Peer 2 が IKE のメイン モードとクイック モードのネゴシエーションを完了します。
  6. Peer 1 から (IPsec で保護された) TCP SYN セグメントを再送信します。
  7. Peer 2 から (IPsec で保護された) TCP SYN-ACK セグメントを送信します。
  8. Peer 1 から (IPsec で保護された) TCP ACK セグメントを送信します。

IKE は、RFC 2409 (ietf.org/rfc/rfc2409.txt) で規定されているインターネット標準で、IPsec セキュリティ アソシエーション (SA) を確立するメカニズムを定義します。SA は、双方の IPsec ピアが相互に同意できるポリシーとキーを組み合わせたもので、ピア間の通信を保護するのに役立つセキュリティ サービスとメカニズムを定義します。具体的には、IKE は RFC 2408 で規定される Internet Security Association and Key Management Protocol (ISAKMP) と Oakley Key Determination Protocol (RFC 2412) との組み合わせです。IKE は Oakley Key Determination プロトコルを使用して、保護された通信のシークレット キー マテリアルを生成します。
IKE は ISAKMP を使用して SA をネゴシエートします。ISAKMP には、ピアの識別と認証、SA の管理、およびキー マテリアルの交換を行う機能があります。ISAKMP は、特定のキー交換プロトコル、暗号化や整合性のアルゴリズム、および認証方式に依存しない、保護された通信をネゴシエートするためのフレームワークです。
IPsec の各ピアは IKE を使用して、メイン モードとクイック モードのネゴシエーションを実行します。メイン モードのネゴシエーションでは、ISAKMP SA が作成され、これによりセキュリティ ネゴシエーションが保護されます。イニシエータとレスポンダは、メイン モードのネゴシエーション中に、ISAKMP SA の暗号化とハッシュのアルゴリズムのネゴシエート、キー決定マテリアルの交換、およびピア相互の識別と認証のために、一連の ISAKMP メッセージを交換します。
クイック モードのネゴシエーション フェーズでは、2 つの IPsec SA (着信データ用の SA と発信データ用の SA) が作成され、2 つの IPsec ピア間で送信されるデータを保護します。イニシエータとレスポンダは、クイック モードのネゴシエーション中に、着信と発信の両方の IPsec SA の暗号化とハッシュのアルゴリズムをネゴシエートするために、一連の暗号化された ISAKMP メッセージを交換します。
IKE ベースのメイン モードとクイック モードのネゴシエーションの詳細については、「IPsec セキュリティ アソシエーションの IKE ネゴシエーション」(microsoft.com/technet/community/columns/cableguy/cg0602.mspx) を参照してください。

AuthIP の概要
AuthIP は IKE の拡張版で、ユーザー ベースの認証、複数の資格情報での認証、強化された認証方式のネゴシエーション、および非同期認証をサポートする柔軟性の高いプロトコルです。IKE と同様、AuthIP はメイン モードとクイック モードのネゴシエーションをサポートしています。また、AuthIP は拡張モードもサポートします。これは、IPsec ピア ネゴシエーションの一部で、このモード中に 2 回目の認証を実行できます。拡張モードの使用は任意で、複数の認証に使用できます。たとえば、拡張モードでは、コンピュータ ベースの認証とユーザー ベースの認証を個別に実行することができます。
複数認証のサポートは、ネットワーク アクセス保護 (NAP) プラットフォームの IPsec 実施に採用されています。IPsec 実施では IPsec ピアがコンピュータ資格情報を使用して認証を行うだけでなく、正常性証明書を使用してシステムの正常性要件に準じていることを証明します。ネットワーク アクセス保護の詳細については、microsoft.com/nap を参照してください。また、AuthIP の機能の詳細については、「Windows Vista の AuthIP」(microsoft.com/technet/community/columns/cableguy/cg0806.mspx) を参照してください。

AuthIP メッセージ
IKE でも AuthIP でも、キー交換と SA ネゴシエーションのプロトコルとして ISAKMP を使用します。ISAKMP メッセージは、ユーザー データグラム プロトコル (UDP) 経由で送信され、ISAKMP ヘッダーと 1 つまたは複数の ISAKMP ペイロードで構成されます。ISAKMP ヘッダーには、メッセージの種類など、メッセージについての情報が含まれます。図 1 に、ISAKMP ヘッダーのフォーマットを示します。
図 1 ISAKMP ヘッダーのフォーマット
図 1 ISAKMP ヘッダーのフォーマット
ISAKMP ヘッダーの Initiator Cookie と Responder Cookie には、IPsec ピアによって選択されたゼロ (0) 以外の乱数が設定されます。Next Payload フィールドは、ISAKMP ヘッダーの直後に続く ISAKMP メッセージの最初のペイロードを示します。RFC 2408 では、Next Payload フィールドの値が定義されています。ペイロードの種類 128 ～ 255 は、プライベートで使用するために予約されています。Major Version フィールドと Minor Version フィールドは、ISAKMP メッセージを送信している IPsec ピアの ISAKMP のバージョンを示します。IKE と AuthIP では、メジャー バージョンは 1、マイナー バージョンは 0 です。
Exchange Type フィールドは、実行される ISAKMP 交換の種類を示します。交換の種類により、ISAKMP ペイロードの構造と順序が示されます。RFC 2408 では、Exchange Type フィールドの値が定義されています。交換の種類 128 ～ 255 は、プライベートで使用するために予約されています。
Flags フィールドには RFC 2408 で定義されている 3 つのフラグが設定されます。最下位ビット (ビット 0) は "暗号化" ビットで、ISAKMP ペイロードが暗号化されているか (1 に設定されている場合)、暗号化されていないか (0 に設定されている場合) を示します。暗号化は、ISAKMP SA 用にネゴシエートされたアルゴリズムを使用して行われます。これは、Initiator Cookie フィールドと Responder Cookie フィールドの組み合わせにより特定されます。次のビット (ビット 1) は "コミット" ビットで、キー交換が同期されるか (1 に設定されている場合)、同期されないか (0 に設定されている場合) を示します。コミット ビットは、SA がネゴシエーションを完了してから暗号化データが送信されるようにするために使用されます。次のビット (ビット 2) は "認証のみ" ビットで、メッセージに情報提供の交換の種類である Notify ペイロード全体が含まれるか (1 に設定されている場合)、含まれないか (0 に設定されている場合)、および認証はされていても暗号化はされていないことを示します。
Message ID フィールドには、メッセージの一意の識別子が設定されます。Message ID は、両方の IPsec ピアが同時に IPsec SA の確立を試みた場合に、競合を防ぐために使用されます。Length フィールドは、ISAKMP メッセージ全体の長さを示します。
IKE の場合、ISAKMP メッセージには、一連の ISAKMP ペイロードが含まれます。最初のペイロードは、ISAKMP ヘッダーの Next Payload フィールドにより示されます。各 ISAKMP ペイロードには、それぞれ次のペイロードを示す Next Payload フィールドがあります。最後のペイロードの Next Payload フィールドは 0 に設定されます。図 2 に、IKE メッセージのフォーマットを示します。
図 2 IKE メッセージのフォーマット
図 2 IKE メッセージのフォーマット
AuthIP は、ISAKMP ヘッダーの Exchange Type フィールド内の交換の種類が 243 (メイン モード)、244 (クイック モード)、245 (拡張モード)、および 246 (通知) である ISAKMP メッセージを使用します。AuthIP ベースの ISAKMP メッセージとの重要な違いは、ISAKMP ペイロードが 1 つしか含まれないことです。これは、Crypto ペイロードまたは Notify ペイロードのいずれかになります。Crypto ペイロードには、メイン モード、クイック モード、または拡張モードのネゴシエーションで使用される埋め込みペイロードが含まれます。Crypto ペイロードには、ISAKMP ヘッダーの Flags フィールドに設定された "暗号化" ビットの値に応じて、プレーン テキストまたは暗号化された一連のペイロードが含まれます。図 3 に、Crypto ペイロードを含む AuthIP メッセージのフォーマットを示します。
図 3 Crypto ペイロードを含む AuthIP メッセージのフォーマット
図 3 Crypto ペイロードを含む AuthIP メッセージのフォーマット

AuthIP と IKE の共存
Windows Vista® と Windows Server® 2008 は、IKE と AuthIP の両方をサポートします。しかし、Windows® XP と Windows Server 2003 がサポートしているのは、IKE のみです。開始側の IPsec ピアが AuthIP と IKE 両方をサポートしていて、AuthIP と IKE の両方を使用する接続セキュリティ ポリシーがある場合、このピアでは応答側の IPsec ピアが AuthIP または IKE のどちらをサポートしているかを特定する必要があります。その上で、IPsec 保護のネゴシエーションに最適なプロトコルを使用する必要があります (AuthIP の方が IKE よりも優先的に使用されます)。
応答側の IPsec ピアのネゴシエーション プロトコルを判断するため、AuthIP と IKE の両方を使用する開始側 IPsec ピアは、次のメッセージを同時に送信します。
  • メッセージ 1 - メイン モードのネゴシエーションを開始する AuthIP メッセージ
  • メッセージ 2 - メイン モードのネゴシエーションを開始する IKE メッセージ
応答側ノードが AuthIP をサポートしている場合は、メッセージ 1 に応答してメイン モードのネゴシエーションを続行する AuthIP メッセージを返し、メッセージ 2 は確認なしに破棄する必要があります。AuthIP をサポートしていない応答側ノードでは、メッセージ 1 の Exchange Type フィールドに応答側ノードがサポートする値が含まれていないため、メッセージ 1 を確認なしに破棄し、メッセージ 2 に応答します。
メッセージ 1 がネットワーク上で失われたり、メッセージ 2 の後に受信された場合に、Windows Vista または Windows Server 2008 を実行する IPsec ピア間で IKE ベースのネゴシエーションが行われないようにするため、Windows Vista または Windows Server 2008 を実行する IPsec ピアはメッセージ 2 に AuthIP Supported vendor ID ISAKMP ペイロードを設定してメッセージ 2 を送信します。AuthIP Supported vendor ID ペイロードは、IPsec ピアが AuthIP をサポートしていることを示します。
したがって、Windows Vista または Windows Server 2008 を実行する IPsec ピアが AuthIP supported vendor ID ペイロードを含むメッセージ 2 を受信した場合、開始側の IPsec ピアがメッセージ 1 と 2 を再送するのを待って、メッセージ 1 に応答します。
開始側 IPsec ピアは、応答を受信するかタイムアウトになるまで、メッセージ 1 と 2 の再送を続けます。イニシエータは応答を受信すると、この応答の ISAKMP ヘッダーを基にレスポンダの機能を判断します。Exchange Type が 243 (AuthIP ベースのメイン モードのネゴシエーションを示す交換の種類) に設定されている場合、レスポンダは AuthIP に対応しています。Exchange Type が 2 (ID 保護および IKE ベースのメイン モードのネゴシエーションを示す交換の種類) に設定されている場合、レスポンダは IKE に対応しています。
イニシエータはこの応答を基に、AuthIP メイン モードのネゴシエーションの次の AuthIP メッセージか、IKE メイン モードのネゴシエーションの次の IKE メッセージを応答として返します。IPsec ピアは、ISAKMP SA のネゴシエーションに使用されたものと同じプロトコルを、この SA の有効期間を通じて使用する必要があります。

Joseph Davies は、マイクロソフトのテクニカル ライターであり、月刊の TechNet Cable Guy コラム (Microsoft.com/technet/community/columns/cableguy) の執筆者でもあります。


 Windows PowerShell: スクリプトを使用しないで作業する
Windows PowerShell
スクリプトを使用しないで作業する
Don Jones

カンファレンス、パブリック ニュースグループ、あるいは私個人のサイトであれ、Windows PowerShell について話すたびに、必ず Windows PowerShell の学習は "先送りする" と話す管理者に会います。なぜでしょうか。最も一般的な理由は、
"スクリプトの作成方法を今すぐに学習する時間がない"、というものです。
これは、よくある意見です。私たち管理者は忙しく、新しいテクノロジを学習するための自由な時間はあまりないというのが実情です。しかし私たちは常に前進して、Windows Vista®、Windows Server® 2008、Exchange Server 2007 などの新しいソフトウェアを学び、私たちの仕事にとって重要なテクノロジを熟知していなければなりません。Windows PowerShell™ は、これらのテクノロジの大きな部分を占めています。
Windows PowerShell のスクリプトの学習を先延ばしにする別の理由として管理者からよく聞くのは、私の同僚の管理者が言うように、「プログラマになることへの懸念」です。なるほど、それなら私が何かお役に立てるかもしれません。Windows PowerShell でコードをまったく記述することなく、本当にすばらしいことが実行できることを知って驚かれることでしょう。

パイプラインについて
私は以前、Windows PowerShell で使用される、極めて柔軟で強力なオブジェクト指向のパイプラインについて記事を書いたことがあります ("オブジェクト指向" という言葉から、私の話がプログラマの世界に向かっているのではないかと疑われるかもしれませんが、どうか最後までお読みください)。私がパイプラインについて気に入っている点の 1 つは、対話的に使用できるということです。すぐに結果が表示され、必要な情報を正確に得られるように、出力結果を容易に調整することができます。たとえば、数台のリモート コンピュータにおける空きディスク領域の一覧を取得するとします。それらのコンピュータの名前は C:\Computers.txt というテキスト ファイルに記述されています。これはコンピュータ名が 1 行に 1 つずつ記述された単純なテキスト ファイルであり、データベースのように複雑ではありません。
まず、この空きディスク領域の情報をローカル コンピュータから取得できるかどうかを確認します。1 台のコンピュータ上で取得可能であることがわかれば、複数のコンピュータ上でタスクを実行するのは非常に簡単です。お気づきかもしれませんが、ここではスクリプトは必要ありません。すべてをシェルで対話的に実行し、Enter キーを押すとすぐに結果が得られます。
このようなタスクのヒントをお教えします。リモート コンピュータからインベントリ管理情報の一覧を取得する場合は、おそらく Windows® Management Instrumentation (WMI) を使用することになるでしょう。この例では、WMI を使用する必要があること以外、私は何も知らないとします。そのため、Live Search にアクセスして、検索用語として「windows wmi free disk space」と入力します。いくつかの結果が表示され、その抜粋に "Win32_LogicalDisk" という語句が含まれています。これは WMI クラスのように見えます。これが私が探しているものかもしれません。私は、これらの検索結果のいずれもクリックせずに、代わりに、新しい検索用語として「Win32_LogicalDisk」と入力します。検索結果の一番上に、MSDN® サイト上の Win32_LogicalDisk のドキュメント ページ (msdn2.microsoft.com/aa394173.aspx) のリンクが表示されます。そのページにアクセスすると、このクラスのプロパティの 1 つが FreeSpace であることがわかります。これは期待できそうです。

コマンドレットを検索する
次に、WMI クラスのプロパティを取得するコマンドレットを検索する必要があります。Windows PowerShell の注目すべき特性の 1 つは、すばらしい自己検出機能が組み込まれているということです。つまり、シェルを使用して、シェル自身の機能に関する情報を簡単に得ることができます。「Help *wmi*」と入力すると、WMI の操作に関する情報が表示されます。図 1 のような結果が表示されます。Gwmi はエイリアス、Get-WMIObject はそのエイリアスが指すコマンドレットです。基本的には、これら 2 つの方法で同じ機能にアクセスできます。どちらを使用するか決めるのに悩む必要はありません。実行結果は同じなので、私は入力する文字数が少ない Gwmi を使用します。
図 1 WMI の操作に関する情報
図 1 WMI の操作に関する情報
PS C:\> gwmi win32_logicaldisk
Windows PowerShell では大文字と小文字が区別されません。管理者には Shift キーを押すなどの細かい作業を行う時間がないことを知っているからです。
図 2 に示すように、このコマンドの結果には、5 つのローカル ドライブすべてと、それらのドライブの FreeSpace プロパティがバイト単位で表示されています。また、これらの各ドライブの DriveType プロパティも表示されており、コンピュータ上に 2、3、および 5 のドライブの種類があることがわかります。
図 2 すべてのローカル ドライブとその FreeSpace プロパティ
図 2 すべてのローカル ドライブとその FreeSpace プロパティ

今月のコマンドレット
Get-Content を使用して、テキスト ファイルの内容を読み取ったことがあるかもしれませんが、このコマンドレットは、ファイルの各行を [string] オブジェクトとして扱います。他のコマンドレットで使用できるように、それらのオブジェクトをパイプラインに渡します。ただし、Get-Content には、柔軟性を向上させるオプションが多数用意されています。たとえば、–readCount パラメータを使用すると、パイプラインに一度に渡す [string] オブジェクトの数を指定できます (既定ではすべてのオブジェクト)。また、–totalCount パラメータを使用すると、ファイルから読み取る行の合計数を指定できます。これらのパラメータは両方とも、パフォーマンス上の理由でファイル全体を一度に処理したくない場合など、非常に大きなファイルを操作するときに便利です。
他にも便利なパラメータがあります。–encoding パラメータです。このパラメータを使用すると、Unicode、ASCII、UTF7、UTF8 などのさまざまなエンコードの種類のファイルを正しく読み取ることができます。サポートされているすべてのエンコードの種類の一覧を表示するには、"help gc" (gc は Get-Content のエイリアス) を実行します。

データを調整する
この時点で 2 つの問題があります。1 つ目の問題は、私に必要なのは FreeSpace だけで、他のすべてのプロパティは必要ないということです。2 つ目の問題は、ローカル ハード ディスクの空き領域のみ知る必要があり、光学式ドライブ、リムーバブル ドライブ、またはネットワーク ドライブの空き領域を知る必要はないということです。この場合、おそらく DriveType プロパティがドライブを区別するのに役立つでしょう。先ほどの Web ブラウザに戻って、ドキュメントにそれぞれの DriveType の値が何を表すかを説明した表が含まれているのを確認します。必要なのは DriveType が 3 (ローカル ハード ディスク) のドライブだけです。今までにやったことがないので、Gwmi コマンドで何らかのフィルタが可能かどうかを確認することにしました。"Help Gwmi -full" を実行すると、コマンドの動作に関する詳細情報といくつかの例が表示されます。–filter という便利そうなパラメータを見つけたので、これを使って実行してみます。
gwmi win32_logicaldisk -filter "drivetype = 3"
うまくいきました。ドライブの一覧には、ローカルの固定ディスクのみ表示されています。これで 2 つ目の問題は解決されました。次は、必要ないプロパティを取り除いて、1 つ目の問題を解決する必要があります。
Get-Command を実行して Windows PowerShell のすべてのコマンドレットの一覧を表示し、最終的に Select-Object を見つけました。Select-Object の説明には、"Select specified properties of an object or set of objects." (オブジェクトまたはオブジェクトのセットの指定したプロパティを選択します。) とあります。次のコマンドを試します。
gwmi win32_logicaldisk -filter "drivetype = 3" | select freespace
Gwmi の結果を Select (Select-Object のエイリアス) にパイプすることで、必要なプロパティのみ取得できます。さて、ここで困ったことが起きました。表示されたのは数字の一覧なので、これはあまり良い結果ではありません。これではどのドライブにどれだけの空き領域があるかわかりません。そのため、再びドキュメントに戻って、DeviceID プロパティにドライブ文字が含まれることを確認しました。すぐにコマンドを改訂して再実行します。
gwmi win32_logicaldisk -filter "drivetype = 3" | select deviceid,freespace
完璧です。一覧には 2 つのプロパティしか表示されていないので、シェルでは情報が見栄えの良い表になります。Windows PowerShell が一覧と表の使用を選択する場合については、来月説明します。

計算する
空き領域に関する情報は取得できましたが、バイト単位であるため、MB や GB などの単位ほど便利ではありません。おそらく、FreeSpace プロパティ自体は必要ではなく、FreeSpace プロパティに基づいて計算された値の方が必要でしょう。ForEach-Object コマンドレット (または % などの多くのエイリアス) が役に立ちます。このコマンドレットでは、特殊な変数 $_ を使用して、現在の論理ディスクを参照できます。また、各ディスクのプロパティに個別にアクセスして、計算を行うこともできます。改訂したコマンドを次に示します。
gwmi win32_logicaldisk -filter "drivetype = 3" | % { $_.deviceid; $_.freespace/1GB }
ここでは、Select を削除して、ForEach-Object のエイリアス (%) で置き換えただけです。この ForEach-Object コマンドレットに必要なのは、コマンドレットが取得した各 Win32_LogicalDisk に対する処理を指定することです。そのため、DeviceID プロパティを取得して、出力結果が GB で得られるように、FreeSpace プロパティを 1 GB で割ることを指定しました。Windows PowerShell は KB、MB、および GB の意味を "知っています"。

複数のコンピュータ
これで、この作業を 1 台のコンピュータに対して実行したので、次は複数のシステムに対して実行します。私は、テキスト ファイルの内容を取得する方法は知っています。Type コマンドを使用して MS-DOS® の場合と同じ方法で取得できますが、Windows PowerShell では、Type は実は Get-Content のエイリアスです。
Type c:\computers.txt
必要なのは、これらの各コンピュータについて、既に調べた WMI コマンドを実行することです。"それぞれについて" (for each one) という語句から、ForEach-Object というコマンドレットを思い出すでしょう。それでは、家庭向けのテレビ番組でよく言われるように、すぐにお見せしましょう。次の最終的なコマンドをご覧ください。
type c:\computers.txt | % { $_;
gwmi –computername $_ win32_logicaldisk -filter "drivetype=3" | % { $_.deviceid; $_.freespace/1GB} }
ぞっとするでしょう。コマンドレット名ではなく、エイリアスだけを使用したため、読みにくくなっています。しかし、少しずつ見ていくと、簡単なものです。
  • まず、テキスト ファイルの内容を "Type" で参照しています。
  • その内容を ForEach-Object にパイプします。
  • ForEach-Object は、$_ 変数を使用して現在の項目を出力します (現在のコンピュータ名です)。
  • 次に、ForEach-Object は、私の WMI コマンドを実行します。その WMI コマンドは、別の ForEach-Object を呼び出します。
これらのエイリアス名をコマンドレット名に展開すると、わかりやすいかもしれません。同じコマンドを次に示します。ただし、今回はエイリアスではなくコマンドレット名を正確に記述し、コマンドをそれぞれ別の行に分けているので、各セクションを容易に調べられるでしょう。
Get-Content C:\Computers.txt |
ForEach-Object {
 $_; Get-WMIObject –computername $_
Win32_LogicalDisk -filter "DriveType=3" |
 ForEach-Object {
 $_.DeviceID; $_.FreeSpace/1GB
 }
}
出力結果は、魅力的ではありませんが、実用的です。図 3 に示します。
図 3 最終結果
図 3 最終結果

スクリプトの作成は必要ない
このウォークスルーのポイントは、スクリプトを作成しなくても Windows PowerShell を使用できることを示すことです。また、このようないくつかの例と、Windows PowerShell に関するちょっとした調査により、目的のタスクを達成するのに必要な情報の一部を、実際に見つけることができます。
つまり、これからは Windows PowerShell の時代だということです。Windows PowerShell の学習を今すぐ始めてみてはいかがでしょうか。学習すれば、Windows PowerShell なしで今までどのようにやってきたか不思議に思うことさえあるかもしれません。スクリプトという言葉のせいで、取り組むのをためらわないでください。

Don Jones は SAPIEN Technologies のリード スクリプト グルで、ScriptingTraining.com のインストラクタです。Don に対するお問い合わせについては、彼の Web サイト (ScriptingAnswers.com) を参照してください。


 Hey, Scripting Guy!: Silverlight の光あれ
Hey, Scripting Guy!
Silverlight の光あれ
Microsoft Scripting Guys
この記事で使用しているコードのダウンロード: HeyScriptingGuy2007_10.exe (156KB)

人類の歴史上、 相反する勢力の衝突は昔からありました。ローマ人対野蛮人の群れ、ハットフィールド家対マッコイ家、Scripting Guys 対 "システム管理スクリプトについてのコラムでは実際にシステム管理スクリプトを話題にするべきで、歴史上の相反する勢力の衝突 (あるいは、げんこつの話。(編集者注)) などを話題にするべきではない" と考えている人々の衝突です。
コンピュータの世界も相反する勢力の衝突と無縁ではありません。特に開発者とシステム管理者の対立が思い出されます。カール マルクスがこのような状況を評して言ったように、「こいつが死んでるか、でなけりゃオレの腕時計が止まっているかのどっちか」でした。
待ってください、すみません。これはグルーチョ マルクスの言葉でした。カール マルクスは「芸術は常にあらゆる場所で秘密の告白であり、同時に時の不滅の動きである」と言った人です。実際のところ、私たちにはこの言葉の意味がわかりません。それに、グルーチョの皮肉が開発者とシステム管理者の対立にあまり関係ないとしても、グルーチョ マルクスの方がカール マルクスよりずっと気が利いていました。
それでも、Scripting Guys が毎朝仕事の前に「システム管理者は開発者ではない」と機械的に忠誠の誓いを述べていたのは、カール マルクスのおかげだったと確信しています。この文句は確かに本当でした。システム管理者は開発者ではありませんでした。開発者とはコンピュータ プログラムを記述する人ですが、システム管理者とは、ええと、実のところ、マイクロソフトにシステム管理者が何をしているか知っている人がいるかどうか自信がありません。しかし、システム管理者の仕事が何であれ、コンピュータ プログラムの記述でなかったことは確かです。
もちろん、カール マルクスは「時代は変わる」という歌も作りました (または、少なくともその歌を作ったと言いました)。
TechNet スクリプト センター (microsoft.com/technet/scriptcenter) のおかげもあって、システム管理者は徐々に VBScript の長所を理解し、独自のユーティリティを書き始めました。このユーティリティは一般的なコンピュータ プログラムほど完璧でも包括的でもありませんが、それでも便利な管理タスクが実行されます。システム管理者は、このようなユーティリティを書く際に、開発者が使うスキルとよく似たスキルを身に付ける必要がありました。
話はここからです。Windows PowerShell™ (microsoft.com/technet/scriptcenter/hubs/msh.mspx) が出現したことで、システム管理者やスクリプト作成者も Microsoft® .NET Framework を使用できるようになりました。Windows Vista® ではガジェット (microsoft.com/technet/scriptcenter/topics/vista/gadgets-pt1.mspx) が導入され、システム管理者、少なくともスクリプトを作成するシステム管理者は、開発者と対等な立場になりました。そして現在 (太鼓の連打をお願いします)、Microsoft Silverlight が公開されています。Microsoft Silverlight は、「Web 上で次世代の Microsoft .NET ベースのメディア エクスペリエンスとリッチ インタラクティブ アプリケーションを実現する、クロスブラウザ、クロスプラットフォーム対応のプラグイン」です。
おもしろそうですね。しかし、それが自分のようなシステム管理スクリプト作成者にどう関係があるのか、と言われそうですね。正直、私たちも完全に確信しているわけではありません。しかし、Silverlight を使用すると、とてもかっこいいユーザー インターフェイスやマルチメディア プレゼンテーションを実に簡単に作成できます。また、宣伝材料では Web アプリケーションを作成する手段として、必ず Silverlight が話題になりますが、これに関してあまり知られていない事実があります。Silverlight はスクリプト作成者が大好きなメディアである HTML アプリケーション (HTA) (microsoft.com/technet/scriptcenter/hubs/htas.mspx) でも、同じようにうまく機能するようです。したがって、Silverlight を試してみる価値は十分にあるでしょう。

先に進む前に
今回は Silverlight の多くの機能や考えられる使い方を説明するつもりがないことをお伝えしておきます。このテクノロジをいろいろ試すのに十分なコード例を紹介することが今回の主な目標です。Silverlight をインストールするには (ちなみに無料です)、Silverlight のホーム ページ (microsoft.com/silverlight) を参照してください。また、silverlight.net/GetStarted では SDK、サンプル プロジェクトなど、さまざまな役に立つものを入手できます。
ここでは、Silverlight が既にインストールされていること、さらに、TechNet Magazine Web サイトのコード ダウンロード セクション (technetmagazine.com/code07.aspx) から図 1 で説明するファイルをダウンロード済みであることを前提とします。
Figure 1 Silverlight プロジェクトのコンポーネント (Close Figure 1)

ファイル | 説明
CreateSilverlight.js | Silverlight の初期スタートアップ設定の指定に使用される JScript スクリプト (初期リリースでは、JScript スクリプトだけをサポートしていました)。ユーザー インターフェイスとグラフィック オブジェクトの構成に使用される XAML ファイルを含みます。
SampleProject.js | JScript 関数を入力できる、単なる空のファイルです。
Silverlight.js | Silverlight コントロールの初期化に使用するファイルです。
SampleProject.html | これこそがおもしろい部分です。SampleProject.html は 3 つの .js ファイルを読み取るコードを含む、簡単な HTML ファイルです。また、Silverlight コントロールを初期化するコードも含んでいます。
SampleProject.xaml | このファイルの用途は何でしょう。答えを確かめるには、コラムの本文に戻る必要があります。
少なくとも今月のコラムのとおりに操作しない場合は、必ずしも SampleProject.js は必要ではありません。Silverlight では、スクリプトをプロジェクトのオブジェクトやイベントにアタッチできます。このようなスクリプトは、HTML ファイルにハードコーディングすることも、(今回のように) 外部の "インクルード" ファイルから読み取ることもできます。また、SampleProject.html を HTA に変更するつもりです。実は SampleProject.hta と名前を変更するだけです。簡単でしょう。
必ず、すべてのファイルを 1 つのフォルダに保存してください。さて、ここからがおもしろいところです。

XAML ファイル
ご想像のとおり、今月の Hey, Scripting Guy! のポイントはどれも XAML ファイルに関係しています (ついでに、XAML は "ザメル (zamel)" と発音します。"キャメル (camel)"、"ママル (mammal)"、"エナメル (enamel)" などと韻を踏んでいます)。XAML は Extensible Application Markup Language の略です。特に、XAML は、XML に似た言語を使って、ユーザー インターフェイスを作成する方法を提供します。この機能を使えば、特にシステム管理者がユーザー インターフェイスを簡単に作成できるようになるのでしょうか。答えはすぐにわかります。
この答えを探すには、まずメモ帳を起動して SampleProject.xaml ファイルを開きます。既存のコードがある場合は、次のコードに置き換えます。
<Canvas
 xmlns="http://schemas.microsoft.com/
    client/2007"
 xmlns:x="http://schemas.microsoft.com/
    winfx/2006/xaml">
</Canvas>
注 : SampleProject.hta は SampleProject.xaml から情報を読み込むようにあらかじめ構成されています。別の XAML ファイルを使用するには、CreateSilverlight.js ファイルを編集する必要があります。
コードを貼り付けたら、SampleProject.xaml ファイルを保存し、SampleProject.hta ファイルをダブルクリックします。何が表示されるでしょうか。そうですね、大きくて間の抜けた灰色の四角形が表示されます。
待ってください。まだ行かないでください。確かに表示されるのはこれだけです。
見栄えが悪いのは、まだ何もしていないからです。ここまでの作業では、XAML ファイルにキャンバス (Canvas) を追加しただけです。しかし、これは大事な一歩です。つまり、油絵を始めるには、まず絵の具を塗るキャンバスを用意する必要があります。同じことが、Silverlight にも当てはまります。プロジェクトに要素を追加する前に、まず "絵の具を塗る" キャンバスを用意する必要があります。そして今、キャンバスの用意ができました。
ところで、幅 300 ピクセル、高さ 300 ピクセルの灰色の四角形が表示されたのはなぜでしょう。答えは簡単です。CreateSilverlight.js ファイルの既定の仕様だからです。この既定値が気に入らなければ、CreateSilverlight.js を開いて、必要に応じて設定を調整するだけです。幅 300 ピクセル、高さ 800 ピクセルの白いキャンバスはいかがでしょう (これから例に使うこの設定は、気に入っていただけると思います)。では、CreateSilverlight.js に次の 3 行があることを確認します。
width:'800', // Width of rectangular region of
             // control in pixels.
height:'300', // Height of rectangular region
              // of control in pixels.
background:'white', // Background color of
                    // control.
注 : お気付きのように、元の .js ファイルでは、背景色は #D6D6D6 に設定されていました。ここでは白 (white) に設定しました。つまり、XAML ファイルでは RGB 値と色の名前の両方で色を表すことができることがわかります (色の名前と値の完全な一覧については、msdn2.microsoft.com/bb188314.aspx を参照してください)。Scripting Guys は色を RGB 値で表す方が好みなのですが (「我が家は FFFFFACD 色に FFCD5C5C 色の飾りが付いているんだ」)、ここでは色の名前を使うことにします。
おまけのヒント : キャンバスの背景色には純色以外も使用できます。図 2 のコードを XAML ファイルに貼り付け、表示を確認します。
Figure 2 すてきな色 (Close Figure 2)
<Canvas
 xmlns="http://schemas.microsoft.com/client/2007"
 xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
 Width="800"
 Height="300">

 <Canvas.Background>
 <LinearGradientBrush>
 <GradientStop Color="Blue" Offset="0.0" />
 <GradientStop Color="Black" Offset="1.0" />
 </LinearGradientBrush>
 </Canvas.Background>

</Canvas>
試してみましたか。かなりクールでしょう。
もちろん、空白のキャンバスは、それ自体ではあまりおもしろくありません。そこで、このキャンバスにオブジェクトを追加してみましょう。Silverlight にはあらゆる種類のさまざまなオブジェクト (楕円、四角形、線、多角形など) を追加できますが、古き良き形式のテキスト ブロックをキャンバスに追加することにしましょう。その方法は、次のタグを XAML ファイルの <Canvas> タグと </Canvas> タグの間に挿入することです。
<TextBlock
 Name="Test"
 FontSize="40"
 FontFamily="Georgia"
 FontWeight="Bold"
 Canvas.Top="20"
 Canvas.Left="20"
 Text="The TechNet Script Center">
</TextBlock>
ご覧のとおり、この XAML コードはそれほど複雑ではありません。まず、<TextBlock> タグを使い、このタグにさまざまな TextBlock パラメータ (Name、FontSize など) を含めます。次に、</TextBlock> タグを使って、TextBlock の終了を示します。どこがクールなんだと言いたそうですね。オブジェクトを XAML ファイルに追加する方法は、どれもこれとほぼ同じです。幅 300 ピクセル、高さ 100 ピクセルの四角形を追加する場合は、次のコードをご覧ください。
<Rectangle
 Height="300"
 Width="100"
 Fill="Blue">
</Rectangle>
ところで、四角形などの図形をキャンパスに追加する場合は、必ず、Fill や Stroke の色を指定してください。色を指定しないと、Silverlight ではキャンバスに透明な四角形が追加されます。四角形は確かに存在しますが、スーパーマンのように X 線が見えるのでない限り、この四角形は見えません。
Fill と Stroke の色と言えば、これは一部の Silverlight オブジェクトに色を設定する方法です。オブジェクトによっては、ブラシを使う必要があるものもあります。たとえば、おまけのヒントで示したように (説明はしていませんが)、LinearGradientBrush を使います。オブジェクトを純色で塗りつぶす場合は、その名前が示すとおり SolidColorBrush を使用できます。たとえば、図 3 の、テキストを赤く "塗りつぶして" いる (厳密には、TextBlock の Foreground プロパティを塗りつぶしている) XAML タグを見てください。
Figure 3 テキストを塗りつぶす (Close Figure 3)
<TextBlock
 Name="Test"
 FontSize="40"
 FontFamily="Georgia"
 FontWeight="Bold"
 Canvas.Top="20"
 Canvas.Left="20"
 Text="The TechNet Script Center">

 <TextBlock.Foreground>
 <SolidColorBrush Name="test_brush" Color="red"/>
 </TextBlock.Foreground>

</TextBlock>
もっとクールな効果に、テキストを画像で塗りつぶす ImageBrush プロパティがあります。
<TextBlock.Foreground>
 <ImageBrush Name="test_brush" ImageSource="Sunset.jpg"/>
</TextBlock.Foreground>
もう 1 つヒントを紹介します。ImageBrush プロパティを使う場合、テキストが大きいほど表示の効果を高めることができるので、FontSize の値を大きくしたくなるでしょう。
試してみて結果をご覧ください。思いどおりの効果が得られるでしょう。

でも待ってください、お楽しみはこれからです
本当のことを言うと、ここまでは私たちに都合の良いことだけを取り上げてきました。Silverlight でテキストを表示できるのはクールです。四角形、楕円、多角形などを描けるのはもっとクールです。しかし、Silverlight プロジェクトにアニメーションを追加できることに比べれば、たいしたことではありません。
繰り返しますが、この記事では、Silverlight アニメーションを作成する方法の一部を紹介するだけです。単にそれ以上の説明のスペースがないためです (私たちを責めないでください。"TechNet Magazine" を Hey, Scripting Guy! Magazine にするよう提案し続けているのですが、明らかに私たちの電子メールは読まれていません)。
前置きはこれくらいにして、テキストがゆっくりと (しかし確実に) フェードインする、クールな効果を紹介しましょう。図 4 のコードを XAML ファイルの <TextBlock> タグと </TextBlock> タグの間に追加します。
Figure 4 TextBlock の妙技 (Close Figure 4)
<TextBlock.Triggers>
 <EventTrigger RoutedEvent=
     "TextBlock.Loaded">
 <BeginStoryboard>
 <Storyboard>
 <DoubleAnimation
 Storyboard.TargetName="Test"
 Storyboard.TargetProperty="Opacity"
 From="0.0" To="1.0"
 Duration="0:0:5" />
 </Storyboard>
 </BeginStoryboard>
 </EventTrigger>
</TextBlock.Triggers>
確かにこのコードではとても複雑な処理をしているように見えますが、さいわいにも大部分はお決まりのタグです。まず、アニメーションを XAML ファイルに追加するだけではいけません。アニメーションを実行するタイミングを指定する必要があります。そのためには TextBlock に一連のトリガを指定する必要があります。今回は、次のように TextBlock が読み込まれるたびに起動するトリガを作成しましょう。
<EventTrigger RoutedEvent="TextBlock.Loaded">
Silverlight では、アニメーションはストーリーボード (映画業界からの借用語) 上で実行する必要があります。<BeginStoryboard> タグと <Storyboard> タグがあるのはこのためです。
テキストをフェードインするには、Opacity プロパティを変更する必要があります。 プロパティの値を 0.0 (透明) から 1.0 (不透明) に徐々に増やします。Opacity は Double のプロパティ (倍精度の数値に基づくプロパティ) なので、DoubleAnimation アニメーションを使用します。では、DoubleAnimation アニメーションはどのように使うのでしょうか。もちろん、アニメーションで動かすオブジェクト (この場合は TextBox に付けた Test という名前) と、対象にするプロパティ (Opacity) を指定します。さらに、アニメーションの範囲 (透明度 0.0 ～ 1.0) とアニメーション全体の実行時間 (5 秒間) の両方を指定します。つまり、次のようになります。
<DoubleAnimation
 Storyboard.TargetName="Test"
 Storyboard.TargetProperty="Opacity"
 From="0.0" To="1.0"
 Duration="0:0:5" />
注 : 5 秒間を指定する構文が 0:0:5 (時、分、秒) となっていることを確認してください。5 とだけ指定してもエラーは発生しませんが、アニメーションが完了するまで 5 日間かかります。
試してみましたか。では、今度は次のスクリプトを試してみてください。次のように、DoubleAnimation タグの内部で AutoReverse プロパティを True に設定します。
AutoReverse="True"
アニメーションがフェードインし、その後フェードアウトして元に戻ります。
RepeatBehavior プロパティを Forever に設定すると、テキストはフェードインとフェードアウトを、永遠に繰り返します。
RepeatBehavior="Forever"
永遠は少々長すぎるでしょうか。では RepeatBehavior を、たとえば 3x に設定して、アニメーションを 3 回再生して停止するようにしましょう。
RepeatBehavior="3x"
自分で言うのもなんですが、なかなかクールでしょう。しかし、フェードインとフェードアウトを繰り返すテキストではなく、少しずつ色が変わるテキストを表示する場合はどうでしょうか。この場合は、次の例のように ColorAnimation アニメーションを使います。
<ColorAnimation
 Storyboard.TargetName="test_brush"
 Storyboard.TargetProperty="Color"
 From="Red" To="Blue" Duration="0:0:5" />
注 : この例を試す場合は必ず赤いテキストから始めてください。テキストを赤く塗りつぶす方法はもう説明しましたね。
どうです、おもしろかったでしょう。おや、少しがっかりしているようですね。気持ちはわかります。ColorAnimation はすてきでしたが、本当は、画面のあちこちに画像を動き回らせたかったんですよね。落ち込まないでください。画面のあちこちに画像が動き回るようにできなければ、Silverlight ではありません。次のスクリプトを試してみてください。
<DoubleAnimation
 Storyboard.TargetName="Test"
 Storyboard.TargetProperty="(Canvas.Left)"
 To="150"
 Duration="0:0:5" />
ご覧のように、TextBlock が最初の位置から、キャンバスの左端 (Canvas.Left) から 150 ピクセルの位置までゆっくり移動します。TextBlock を上下に動かすには、次のように Canvas.Top プロパティを使用するだけです。
<DoubleAnimation
 Storyboard.TargetName="Test"
 Storyboard.TargetProperty="(Canvas.Top)"
 To="150"
 Duration="0:0:5" />
このようなアニメーションを組み合わせて、TextBlock を上下左右の両方に動かすことはできるでしょうか (わくわくしますね)。さっぱり分かりません。しかし、ヒントをお教えします。両方のアニメーションを (次々に) XAML ファイルに貼り付け、結果を確認します。
注 : 今のは嘘です。最初からこのアニメーションを組み合わせることができることはわかっていました。実際、1 つの Silverlight プロジェクトに大量のアニメーションを詰め込むことができます。1 つのアニメーションが終わってから次のアニメーションが開始するようにタグの追加が必要な場合があるので、これは少々厄介です。しかし、XML に似たタグを少し入力するだけで、とてもおしゃれなアニメーションを作成できます。

残念ですが、今日はここまで
ええ、わかっています。私たちも終わりにしたくはありません。すてきなものが完成したときは特にそうです。でも、心配しないでください。これで終わりにする必要はありません。Silverlight についてもっとお知りになりたい方は、scripter@microsoft.com (英語のみ) までご連絡ください。皆さんの関心が高ければ、今後のコラムで取り上げることを検討します。また、TechNet スクリプト センター (microsoft.com/technet/scriptcenter/resources/tnmag/archive.mspx) を参照してください。完全な XAML の例 (これが本当の eXAML でしょうか) へのリンクを掲載します。それまでは、カール マルクスとフリードリヒ エンゲルスがその宣言『ブリュッセル共産主義通信委員会から G. A. ケトゲンへの手紙』の末尾で述べたように、「おやすみなさい、お帰りの際は安全運転で」。

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


 セキュリティ ウォッチ: BitLocker と信頼という複雑なもの
セキュリティ ウォッチ
BitLocker と信頼という複雑なもの
Justin Troutman

Windows Vista。これまでこの 2 つの単語を記事に載せたことはありません。そのため、このコラムを執筆していると、おもちゃ屋に入って、「いくらでも好きなものを選んでいいよ」と言われた 5 歳の子供になったような気分になります。説明したい機能、調べておく価値のある分野、取り上げることができるテーマなどが山ほどあります。
少し前のことですが、セキュリティの権威である Bruce Schneier 氏のブログを読んでいたとき、当時知らなかった "BitLocker™" という単語が目に留まりました。私は、すぐに、これが Windows Vista® の暗号化機能であることを突き止め、直後には嫌な気分になってしまいました。「何てことだ。Windows Vista が暗号化を行うとは。きっとろくなものじゃない。まともに機能したとしても、どこかにバックドアがあるに違いない。」
「ユーザーはなぜ Windows® に組み込まれたセキュリティ機能を利用することをためらうのか」という、(真実はどうであれ) 歴史的な論争があります。しかし、この理由を説明するためにこのコラムを執筆するわけではありません。むしろ、BitLocker にはチャンスを与えるべきだと信じる理由を説明したいと考えています。また、暗号化ソフトウェアやハードウェアに活力を与えるような考えには賛成したいとも思っています。
ただし、誤解しないでください。BitLocker をセキュリティの問題を全体的に解決する万能薬と言っているわけではありません。BitLocker は、セキュリティというパズルを組み立てる数多くのピースの 1 つに過ぎません。この機能の目標は、特定の脅威モデルに対する回復性を提供することです。
BitLocker は、特に、ラップトップ コンピュータの紛失 (または盗難) に重点を置いています。モバイル ワーカーは、常に、あらゆる場所 (電車、飛行機、飲食店、ホテル、自宅、ブランチ オフィス) へあらゆる種類の機密情報を携行します。こうした機密情報は、ラップトップ コンピュータなどのモバイル デバイスで持ち運びされますが、一般に、モバイル デバイスは本質的なセキュリティが欠如しており、データはきわめて脆弱なままです。では、ユーザーの 1 人が、ラップトップ コンピュータをどこかに放置すると、こうしたデータはどうなるでしょうか。
人間からだらしなさを取り除くことはできません。さいわい、こうしただらしなさによって生じる混乱を制限することはできます。企業にとっては、漏えいした機密データの処理にかかるコストに比べれば、ラップトップ コンピュータの買い換えなど安いものです。これが、BitLocker が提供を目指すセキュリティです。

評判について考える
ここでは、変わった観点から BitLocker を説明しましょう。実は、まだ試したことがないので、「BitLocker を使ったこともない人の意見なんて。まして、それについて役立つ話などできるわけがない」と、皆さんはお考えでしょう。ここは、我慢して聞いてください。実際には、暗号化を高レベルな視点から捉え、ソリューションの成功に不可欠な設計哲学について説明したいと考えています。
すべては Bruce Schneier 氏のブログの一節から始まりました。たとえば、これから見たい新作映画があるとします。予告編や主な出演者から、その映画についていくつかの想定を行います。もちろん、出演者が優れているからといって、名作であるとは限りません。しかし、俳優陣によって映画の大部分が決まり、何を期待するかも決まってきます。主演は Chris Rock と Ben Stiller ですか。それとも Kate Winslet と Johnny Depp ですか。
映画の例と同様に、世界的な尊敬を集めるセキュリティの権威が自身のブログで BitLocker について述べているのを読んだとき、私はいくつか想定を行いました。まず、この新しいテクノロジは、佳作程度の価値があるか、公共の場で発表しなければならないほど役に立たないかのどちらかに違いないと考えました。驚いたことに、Bruce Schneier 氏の出した結論は肯定的なものでした。
彼の記事の中で、「警察向けのバックドアは用意されていない」という文が目に留まりました。これには衝撃を受けました。彼のブログは自信を持って書かれており、Microsoft® System Integrity チームのブログへのリンクが含まれていました。このリンクにアクセスすると、Niels Ferguson 氏 (マイクロソフトのセキュリティ専門の開発者) からの投稿がありました。この投稿では、法の執行を目的として、マイクロソフトが故意に BitLocker にバックドアを組み込んだという噂は憶測にすぎないと非難していました。Ferguson 氏は、バックドアは許されないものであり、これを支持するプロジェクトの一員になったことはないと、はっきりと述べています (マイクロソフトは、法律によって強制的にバックドアを組み込まざるを得ないとするならば、バックドアを実装していることを公表するか、その機能から完全に撤退するだろう、とも説明しています)。
投稿者が Niels Ferguson 氏であるということが Schneier 氏の自信の根拠となっており、私の自信にもつながっています。Ferguson 氏は責任を持って発言することが知られており、その意見は信用できることが実証されています。Bruce Schneier 氏と Niels Ferguson 氏は、『実用的な暗号化』(簡潔、正確、かつ安全な優れた暗号化の適用に関する影響力のある書籍) を共同で執筆しました。また、ブロック暗号の Twofish も共同で設計しています。Twofish は、Advanced Encryption Standard (AES) の選考過程で最終段階まで残り、暗号化の骨組みを構築した 128 ビットの Feistel ネットワークです。
もちろん、熟練した暗号技術者がプロジェクトに参加したからといって、最終製品のセキュリティが確保される保証はありません。このようなベテランの技術者でも、たまには、キーの打ち間違いの 1 つや 2 つはあります。しかし、BitLocker の長期的な成果とは関係なく、彼らがプロジェクトに参加したことが、少なくとも、BitLocker の作成時の設計方針を正当なものにするうえで、なんらかの役割を果たしたことは確かです。
キーの打ち間違いと言えば、暗号化のセンスがまったくない開発者が誠意を持って取り組んだ場合にも、製品のリリースだけを気にしている開発者が不誠実に取り組んだ場合にも起こりえます。故意かどうかに関係なく、どちらも作成時のセキュリティ エラーです。しかし、BitLocker にはどちらも当てはまらないようです。少なくとも 1 人の有能な暗号技術者を関与させたり、その作業をサポートする豊富な人材を確保したりすることは良い兆しです。

信頼について
つい最近、PGP 暗号化の作成者である Phil Zimmerman 氏から、彼の経験に基づいて得られた法則を教わりました。『開発者のためのセキュリティ信条』という書物が出版されるとしたら、彼の助言は間違いなくその冒頭を飾るでしょう。彼の主張する設計哲学は、特に BitLocker を意識したものではありませんが、ほぼすべての暗号化ソリューションに当てはめることができます。「わかりきったことだ」とか、「熱くなりすぎている」と受け取られるかもしれませんが、セキュリティの現状を考えると、あえて述べておく価値があります。
開発者が暗号化インフラストラクチャを設計するときは、簡潔、正確、かつ安全に行う必要があります。ミスは避けられないものですが、当然起こるものとして容認し、軽視してはいけません。開発者は、細部にまでこだわる、完璧主義の忠実な支持者でなければなりません。Zimmerman 氏は、このことを「ミスをすれば人命が犠牲になると考えて設計しなさい」と表現しました。誇張だと思いますか。2005 年のコンピュータ セキュリティ カンファレンスで、NSA (国家安全保障局) の暗号技術者である Brian Snow 氏 (当時既に定年を迎えていました) は、「セキュリティ デバイスには機能と保険が必要です。顧客ではベータ テストを行いません。製品にエラーがあれば、だれかが命を落とすかもしれません」と述べました。ですから、忘れないでください。ミスを犯すと、金銭だけでは済まされない場合があります。
ユーザーは、保証を得て当然です。ユーザーの信頼を獲得し、それを維持することがきわめて重要です。Zimmerman 氏は、「ユーザーの信頼を獲得してください。いったんその重荷を背負ったら、決して下ろすことはできません」と、信頼維持の重要性を説きました。そうすることで、企業は、セキュリティが確保されているという、ユーザーからの保証と評判を維持できます。これらを失うと、回復は不可能です。
マイクロソフトが BitLocker (ついでに言えば、他の製品) を設計しているときに、このような観点を念頭に置いていたことを願っています。そうは言うものの、マイクロソフトにこのような適切な考え方が実際にあり、真剣に採用すべき暗号化テクノロジを提供していると、楽観的に考えている理由を説明します。

廉価版認証と Elephant
根本的には、BitLocker とは、Windows Vista Enterprise Edition と Ultimate Edition で、すべてのシステム ボリューム データを暗号化する方法のことです。こう言うと単純なアプリケーションのように聞こえますが、その制約について考えてください。BitLocker はセクタ単位のレベルでデータを暗号化します。また、暗号化したテキストはプレーンテキストの長さを超えることができません。そのため、ナンス (認証に一度だけ使用される数値または文字列)、Initialization Vector (IV)、メッセージ認証コード (MAC) など、他のデータのために残される領域がありません。このように厳しい制約や条件が課せられることはよくあると予想していましたが、メッセージ認証はなんらかの方法で対処されることもわかっていました。
BitLocker は、よく廉価版の認証と呼ばれる認証に依存しています。セキュリティが侵害され、暗号化したテキストが操作されても、意味のあるプレーンテキストにはならないと考えられるため、被害は通常想定するほど控えめなものではありません。つまり、暗号化したテキストが操作されると、敵対者がなんらかの機能を実行できるのではなく、たとえば、システムのクラッシュにつながります。
BitLocker を開発したマイクロソフト チームは、まったく新しいブロック暗号の分析には許容できないほど多くの時間が必要になることがわかっていましたが、既存の設計もまだ十分に分析されておらず、またそれほど効率的でもありませんでした。そこで、マイクロソフトでは、暗号化に CBC (暗号ブロック連鎖) モードの AES (以下 AES–CBC) を選択しました。AES–CBC は、選択平文攻撃モデルの下では識別不能 (IND-CPA) ですが、完全性は保持されません。また、MAC 用の空き領域がなく、CBC が機密性のモードであるため、完全性はまったく保持されません。これは、象 (Elephant) が列をなして、部屋に入るのを待っているようなものです。
この新しい Elephant コンポーネントには 2 つのディフューザがあります。これらのディフューザは、定番の AES-CBC よりもはるかに優れた、廉価版の認証を行うように構築されています (ただし、標準への厳しい準拠ポリシーに従う必要があるユーザー向けに、Elephant なしで AES-CBC を実行するオプションがあることに注意してください)。常に理想的であるとは限りませんが、廉価版の認証は、特定の制約下では最適なソリューションであり、Elephant はその状況下で最善を尽くすことを目的としています。では、実際どのように動作するのでしょうか。
図 1 に、動作の流れを示します。暗号化が行われるときに、プレーンテキストとセクタ キーが XOR で組み合わされます。次に、組み合わされたテキストが、キーのない 2 つのディフューザを経由して流れます。その後、AES-CBC を使用して暗号化されます。セクタ キーと AES-CBC の両方にキー マテリアルが必要であるため、個別にキーが付けられます。この方法により、AES-CBC と Elephant の構造のセキュリティを、AES-CBC のセキュリティに軽減するための証明の形式化が簡単になります。Elephant は、新しいプリミティブです。厳密な分析が完了するまでは、新しいプリミティブを受け入れるのに抵抗があるかもしれません。しかし、BitLocker では、Elephant を使用した AES-CBC の方が、AES-CBC 単独の場合よりも攻撃されにくいことを示す場合があるため、この方法によってバランスを取ります。
図 1 Elephant を使用した廉価版の認証
図 1 Elephant を使用した廉価版の認証
セクタ キーと AES-CBC コンポーネントは、共に 256 ビットのキー マテリアルを受け取り、キーの長さを 512 ビットにします。ただし、既定では、これらの各コンポーネントはそれぞれ 128 ビットのキー マテリアルしか使用しません。つまり、キー マテリアルの一部は使用されません。それは、キーの長さの変化に合わせてキー管理インフラストラクチャを変更するよりも、不要なビットを破棄する方が簡単だからです。
ブロックの長さは 512 ～ 8,192 バイトの範囲内で、任意の 2 の累乗値が許可されます。暗号化したテキストが変更されると、すべてのセクタのプレーンテキストがランダムに変更されるようにするには、ブロック暗号をこのようなさまざまなブロック サイズで動作するように設計します。さらに、セクタごとに少しずつ変化させるアルゴリズムによって、(Liskov、Rivest、Wagner が提唱したような) 調整可能なブロック暗号のように動作すると、敵対者はあるセクタの暗号化したテキストを別のセクタに移動できません。

時がたてばわかる
BitLocker の暗号化セキュリティばかりに注目すると、全体像を見失います。BitLocker のセキュリティ保護は、その役割を果たすには必ずしも十分ではありません。これは、BitLocker はそれ自体が 1 つのソリューションではないためです。BitLocker は、多くの Windows Vista の付属コンポーネントの 1 つです。マイクロソフトによると、BitLocker は Windows Vista に密接に統合されているそうです。しかし、OS に密接に統合されていると、別のコンポーネントの障害が、BitLocker の障害またはセキュリティ侵害につながると考えるのが妥当ではないでしょうか。
個人的には、モジュール方式や障害の分離の正当性を確信しています。モジュール化されずに密接な統合を行うと複雑さが増します。もちろん、これが Windows Vista と BitLocker に当てはまるとは限りませんが、時間がたち、十分に分析されたら、そのとおりになるかどうかがわかります。
それでは、BitLocker についての私の意見を述べましょう。暗号技術者の使命を果たした正真正銘の信頼できる暗号技術者を採用したことに対して、Microsoft System Integrity チームに敬意を表します。この機能が、販促活動ではなく暗号化のために設計されたことは明らかです。したがって、「BitLocker は真剣に検討すべきである」というのが私の考えです。ここでは、BitLocker のセキュリティが十分であるかどうかについては述べません。繰り返しになりますが、その答えは時間の経過と、実社会からの評価によってわかります。多くの暗号化プリミティブや暗号化プロトコルが侵害されてきました。しかし、少なくとも、Microsoft System Integrity チームは、さらに優れたソリューションを構築する技術とプラットフォームを私たちに用意しています。

Justin Troutman は、熟練の暗号技術者であり、数学を専攻する大学生です。主な研究分野は対称暗号化です。彼は、暗号専門の調査およびコンサルティング会社である Extorque の創立者でもあります。


 デスクトップ ファイル: WIM と ImageX のパワー ユーザー ガイド
デスクトップ ファイル
WIM と ImageX のパワー ユーザー ガイド
Wes Miller
このコラムは、Windows 自動インストール キット (WAIK) と Windows Server 2008 のプレリリース版を基にしています。ここに記載されているすべての情報は変更される可能性があります。

以前のコラムでも、ImageX と Windows Imaging (WIM) 形式については説明しました。数か月前に開催された Tech•Ed では、Windows 展開サービス (WDS)、ImageX、および Windows 自動インストール キット (WAIK) を使い始めようとしている IT プロフェッショナルから、いくつかのコメントや質問を受けました。
そこで、より詳しいユーザー ガイダンスが必要であると実感しました。そのため、今月のコラムでは、ImageX と WIM 形式に重点を置き、その活用方法について説明します。ImageX と WIM を併用すると、Windows Vista® と Windows Server® 2008 だけでなく、Windows® XP、Windows Server 2003、Windows 2000 も同様に容易に展開できます。

WAIK の変更点
Windows Server 2008 が間もなくリリースされることで、WAIK にどのような影響があるのかを知りたい思っている人もいるでしょう。マイクロソフトは、Windows Server 2008 のタイムフレームに WAIK の更新版をリリースする予定です。WIM 形式への大きな変更はありません (ImageX ツールと形式は変更されません)。Windows Server 2003 向けの WDS にも変更はありません。うわさに反して、マルチキャストは Windows Server 2003 の WDS では利用できず、Windows Server 2008 を実行する WDS サーバーでのみ WDS の新しいマルチキャスト展開機能を使用できます。
Windows PE 2.0 と Windows セットアップは、次の操作をサポートするために変更されます。
  • Windows Server 2008 と Windows Vista の展開。
  • Windows Server 2008 WDS サーバーからの WDS によるマルチキャスト展開。
  • Windows PE x86 ディスクからの Windows Vista と Windows Server 2008 の x64 バージョンおよび x86 バージョンの展開。
1 点目は、Windows PE 2.0 では Windows Server 2008 を Windows Vista とまったく同じように容易に展開できることを意味します。つまり、いずれの場合でも同じツールとプロセスが機能します。2 点目の変更は、WDS サーバーで Windows Server 2008 を実行すると、WDS によるマルチキャスト展開を使用できるようになります。そして、3 点目は、Windows PE 2.0 の x86 ディスクを使用して、そこから x86 または x64 バージョンの Windows のイメージを展開できることを意味します。
この 3 点目については、Tech•Ed の Windows x64 に関する講座で説明しました。残念ながら、この点については、ブログや Windows のテクニカル コミュニティで混乱が生じていました。これは、すべての Windows Vista または Windows Server 2008 の DVD で Windows x64 と Windows x86 が配布されるということではありません。また、(可能ですが) Windows x64 イメージと Windows x86 イメージを単一の WIM ファイルにまとめる必要があるということでもありません。単一のファイルにまとめても、単一インスタンス化による記憶域の節約にはなりませんが、WIM を 1 つのファイルとして扱うことはできます。
つまり、x86 ベースの展開プロセス (およびカスタム スクリプトやカスタム ツール) の開発に何年も費やしてきた企業ユーザーや OEM は、32 ビットのセットアップを使用して WIM 内から Windows x86 または Windows x64 を展開できるようになります。これは、2005 年に Windows x64 が登場したとき以来、企業ユーザーからずっと寄せられていた要望です。

ImageX の基本事項
/mount、/mountrw、および /delete を使用する
ここでは、ImageX で /mount、/mountrw、および /delete スイッチを使用する際の重要なヒントを紹介します。
  • ボリュームを編集する場合は、/mountrw を使用してマウントします。
  • WIM は空のディレクトリにマウントして、同じディレクトリに格納されている他のファイルとの混乱を排除し、ImageX で不要な警告メッセージが表示されないようにします。
  • 変更を保存する場合には、読み取り/書き込みイメージに対して /unmount /commit を実行します。私は、変更を行ったときに、その変更をコミットし忘れて破棄してしまったことが何度もあります。
  • /mountrw を使用してファイルを削除したり、/delete を使用してボリューム イメージを削除しても、空き領域は増えません。実際には、これらのスイッチの使用よって、さらに多くの領域が使用されることがあります。詳細については、このコラムの /export に関するセクションを参照してください。
  • 一度の読み取り/書き込みアクセスでマウントできるのは、1 つの WIM ファイルだけです。2 人のユーザーが同じ WIM を同時に編集したり、1 人のユーザーが 2 つのボリューム イメージを同時に編集することはできません。
  • ドライバは、マウントされる各イメージのシステムで使用できる Windows の非ページ プール メモリ量に依存するため、読み取り専用モード (/mount) でも、同時にマウントするボリューム イメージ数を制限する必要があります。そのため、この制限は、システムごと (またはシステム アーキテクチャごと) に異なる場合があります。同時に 5 つ以上のイメージをマウントすることはお勧めしません。
  • /mountrw を使用して大幅な編集を行っても、変更する際には、ほとんど時間はかかりません。ただし、/commit では、すべての新しいファイル データを圧縮して格納する必要があるため、このスイッチの実行には、かなりの時間がかかる場合があります。
  • 変更は一度コミットされると、元に戻せないため、/delete と /mountrw を使用する際には注意が必要です。
  • WIM ファイルにボリューム イメージが 1 つしかない場合、/delete は実行できません (WIM ファイル全体を削除するか、別のボリューム イメージを追加する必要があります)。
  • ボリューム イメージの内容のディレクトリ ツリーをすばやく取得するには、/mount ではなく、次のコマンドを使用します。
ImageX /dir <path_to_wim_file> <image index>
  • 2 つの WIM ファイルを同時に編集している場合、/unmount を同時に実行しないようにしてください。マウントとマウント解除のイベントは、一方が他方をブロックしないように順番に行ってください。

ImageX は、OEM と企業ユーザーから報告されたツールの使用方法を反映するようにデザインされました。図 1 はそのプロセスを示しています。
図 1 ImageX の使用
図 1 ImageX の使用
手順 5. が重要であることを強調しておきます。実環境では、イメージは常に変化しています。そのため、イメージのキャプチャと変更の作業は、できる限り迅速かつ容易に行える必要があります。
そのため、既に作成したイメージに (/append スイッチを使用して) 別のイメージを追加できます。開発チームでは、当初、ユーザーは追加の SKU (Windows のバージョン) を既存のイメージに追加すると考えていました。しかし、Windows Vista の開発初期に企業ユーザーとの連携を深めるうち、これが、X をすばやく展開して手順 2. のいずれかの変更を行った X1 を再キャプチャするために使用されていることがわかりました。また、この手順により、限られた数のファイルだけを変更しているため、イメージをすばやく再キャプチャできることもわかりました。
このことがわかったとき、開発チームは、元のイメージを保持することがすべての状況で意味をなすわけではないことに気付きました。このシナリオとこの後で紹介する別のシナリオに対応するために追加された /export スイッチについては、このコラムの後半で説明します。

常時行われる変更
開発チームは早くから、WIM ファイルを編集可能にする必要があると考えていました。既に、セクタベースのイメージ形式が機能しないと考えていたため (詳細については 2006 年 12 月号のコラム technetmagazine.com/issues/2006/12/DesktopFiles を参照)、Windows ファイル システムの一部としてファイルをネイティブかつ容易にマウントし、WIM ファイルのマウントされたボリューム イメージに容易に変更を加えられるソリューションを提供する必要がありました。つまり、"不確定要素" (と呼ぶことにします) が、他にもいくつかありました。セクタベース イメージは比較的容易にマウントできますが、WIM など、特殊なアーカイブ形式のマウントには特殊な手法が必要でした。
このような特殊な形式には、コマンド ラインからアクセスできる必要があります (ただし、ZIP ファイルや CAB ファイルをネイティブに処理するのに使用される一般的な Windows のシェル拡張は除きます)。残念ながら、こうしたハンドラではエクスプローラによるオブジェクトへの抽象的なアクセスしか許可されません。
その結果、WIM ソリューションにはドライバ (wimfltr.sys) と ImageX が含まれ、実際にドライバを読み込む役割を果たし、WIM をマウントするインターフェイスを処理します。図 2 のように、ドライバによって Windows ファイル システムに抽象概念が追加されます。次のようなコマンドを実行すると、この図に示すように、ImageX によって wimfltr.sys ドライバが読み込まれ、ドライバによって最初のボリューム イメージ (下記のコマンドでは 1 が使用されているため) がマウントされた空のディレクトリ上に重ねられます。
図 2 WIM ボリューム イメージのマウント
図 2 WIM ボリューム イメージのマウント
ImageX /mount iso\sources\boot.wim 1 mount
ImageX /mountrw iso\sources\boot.wim 1 mount
これは、WAIK の既定の動作です。したがって、マウントされたディレクトリでディレクトリ一覧を調査または生成すると、boot.wim のボリューム イメージ 1 のルートを確認できます。もちろん、/mountrw または /mount のどちらを使用するかによって、このディレクトリが読み取り専用か読み取り/書き込み可能かが決まります (詳細については補足記事「/mount、/mountrw、および /delete を使用する」を参照してください)。
当初、/mountrw 機能は、ドライバやその他の XCOPY 可能なファイルまたはコンテンツを容易に追加し、応答ファイルをセットアップし、マウントされた WIM ファイルのオフラインのレジストリを必要に応じて変更できるようにデザインされました (図 3 参照)。(MSI を使用してインストールするアプリケーションはオフラインでインストールできないため) アプリケーション全体が追加または削除されるようにはデザインされませんでした。
図 3 マウントされた WIM ファイルの変更
図 3 マウントされた WIM ファイルの変更
WIM ファイルがマウントされている最中に変更を加えても、実際の WIM ファイルは (少なくともすぐには) 変更されないことを理解することが重要です。この場合、変更されるのは、実際の WIM ファイルではなく、重ね合わせと WIM ファイルへの変更内容を結合した WIM ファイルのキャッシュです。補足記事でも触れたように、この点については注意する必要があります。変更作業が完了したら、WIM ファイルに変更をコミットするため、必ず /unmount スイッチと /commit スイッチを使用する必要があります。このスイッチを使用しないと、変更内容は完全に破棄されます。
変更をコミットして保存すると、ドライバに WIM ファイル自体を変更するように指示することになります。ドライバにより、ファイル データが追加されます (/commit の実行時に初めてファイル データが WIM に追加されるため、多くの変更を加えた場合は、/commit の実行にはかなりの時間がかかる可能性があることに注意してください)。
また、セクタベースのイメージ形式とは異なり、ボリューム イメージに含まれるファイルを 1 つ以上変更している場合があります。その結果、(同一のファイルが既に一度格納されていない限り) 単一インスタンスではなくなり、元のファイル データが失われます。NTFS ボリュームや FAT ボリュームとは異なり、WIM ではファイルが削除済みとしてマークされません。ファイルは参照されなくなりますが、削除されません。そのため、/mountrw を使用して頻繁に編集を加えたり、/append 使用して多数のイメージを追加したり、/delete を使用してボリューム イメージを削除したりしても、WIM ファイルによってファイル データが参照されなくなるだけで、関連するファイル データがすべて削除されるわけではありません。
したがって、開発チームは、ある意味では "WIM デフラグ ツール" とも呼べる /export スイッチを作成しました。

エクスポート
/export に関する重要な注意点
/export を使用して新しい WIM ファイルを作成する場合、現在使用されている既定の圧縮の種類を使用するのではなく、使用する圧縮の種類を指定できます。現在使用している圧縮の種類から変更する場合、エクスポートにはかなりの時間がかかることがあります。
/export を (ボリューム イメージを既存の WIM ファイルに追加することで) 実質的に /append として使用した場合、WIM ファイルの /compression 属性を変更できません。
まったく新しい Windows PE 2.0 ボリューム イメージをエクスポートする場合には /boot スイッチを指定できます。

/export スイッチは、既に説明したシナリオと、開発チームが発見したより難解なシナリオへの対応策として作成されました。簡単に言うと、/export を使用することで、既存のボリューム イメージを 1 つ (または 2 ～ 3 つ) 取得してエクスポートすることができます。つまり、別の WIM ファイルからイメージをエクスポートすることで、上記の WIM ファイル X と X1 をすばやく取得し、X のみ、X1 のみ、または X1 と Y1 の両方を使用して新しい WIM を作成します。
X に変更を加え、/append を実行して変更を X1 として追加するシナリオを想像してみてください。ここで、X を新しいイメージに置き換えたため、X を削除するとします。/delete スイッチを使用することで、ImageX では X イメージが使用されなくなります。ただし、X に関連するすべての情報を削除して空き領域を確保するには、次のコマンドを実行する必要があります。
ImageX /export source.wim 2 destination.wim "New image for Q4CY07"
このコマンドにより、2 番目のボリューム イメージが新しい名前の新しい WIM ファイルにエクスポートされ、ボリューム イメージ 1 に関する以前の情報が完全に削除されます。また、1 つの WIM ファイルに再構築する場合には、分割した複数の WIM イメージからボリューム イメージをエクスポートすることもできます (詳細については、このコラムの後半で説明します)。分割イメージは /mountrw を使用して編集することはできません。これは、分割イメージの再構築が必要な理由の 1 つです。ImageX では、/export を使用して新しい WIM ファイルを作成したり、既存の WIM ファイルに追加したりすることができるため、/import コマンドがありません。このトピックの詳細については、補足記事「/export に関する重要な注意点」を参照してください。
また、これは peimg /prep を実行する場合にも重要です。このコマンドによって、使用する Windows PE イメージが準備されますが、WIM ファイル内の情報はクリーンアップされません。理想的には、Windows PE リリース プロセスの一環として、イメージを準備して、それを新しい boot.wim ファイルにエクスポートするのが望ましいです。ブート プロセスでは、\sources\boot.wim で WIM ファイルを見つけることだけが指定されているため、正しいファイル名を指定し、ファイルがブート ボリューム イメージとしてマークされるようにする必要があります。
既に説明しましたが、古いボリューム イメージが廃棄できるか、複数のイメージをまとめられるようになったときに、/export を実行してイメージを最適化できます。また、/mountrw や /delete を使用して大幅な変更を行った場合にも、/export を実行できます。これを実行しないと、WIM ファイルは (診断できない難解な方法で) 徐々に増大し続けます。定期的に /mountrw や /delete を使用している場合には、イメージが適切に最適化されるように、ワークフローへの /export の追加を検討してください。

分割
開発初期に発生した別の問題は、WIM ファイルを複数の新しいメディアにまたがって格納する必要があるかもしれない、ということでした。Windows が複数の CD で出荷される (また、実際そうであったように DVD で出荷される可能性がある) と予想していたため、WIM と ImageX に分割のサポートを組み込みました。
既に説明したように、/split を使用して作成した分割イメージは基本的に読み取り専用です。新しい分割イメージは、直接 /capture を実行したり、ImageX を使用してマウントしたり、/append を使用して追加することはできません。そのため、標準ワークフローを完了してリリースできる状態になった後にのみ、WIM ファイルを分割することをお勧めします。つまり、すべての編集は通常の WIM ファイルで行い、展開シナリオのリリース プロセスの一環として、WIM ファイルを分割することを検討してください。
イメージを適用する際には、分割イメージは厄介な場合もあります。分割イメージを使用するときには、セットアップではなく ImageX を使用することをお勧めします。また、ネットワーク経由でイメージを適用する (適用元のディスクのイメージを作成せずに最適なパフォーマンスを実現する場合) か、ドライブにイメージを直接コピーしてから適用することをお勧めします (適用時にはディスク自体で読み取りと書き込みを行うため、ディスクの制限を受けることに注意してください)。

検証ツール
ImageX を使用しているときには、非常に重要なデータを大量に移動しています。今年の Tech•Ed では、「イメージが有効であることを確認する方法はありますか」という質問を頻繁に耳にしました。その方法は、特別簡単ではありませんが、それほど難しくもありません。
WIM について特に理解しておく必要があるのは、ほとんどのアーカイブ形式と同様、破損しやすいということです。ほとんどの場合、WIM ファイルの破損は、ファイルがネットワーク経由で転送されるときに発生します。Windows Vista では、当初、特定のネットワーク カードに特異な問題が確認されました。パケットが破棄されると、WIM ファイルが破損し、その方法は診断が困難な場合がありました。この状況は、数年前、driver.cab ファイルのサイズが増大したときに同様のランダムな破損が発生した状況とよく似ています。一般的に、不良イメージやセットアップのエラーに関するレポートを受信した場合は、そのレポートが生成されたシステムで使用されている NIC の種類を確認することをお勧めします。これは、ImageX を単独で使用している場合と WDS を実行している場合のどちらにも当てはまります。
では、イメージが適切かそうでないかはどのように確認できるでしょうか。まず、/check スイッチを使用できます。このスイッチを使用すると、WIM ファイルのその他の整合性チェックを省略でき、WIM が破損していないことを適用前に検証します。同様にイメージの適用時にも /check を実行してください。イメージの適用にかかる時間が長くなりますが、イメージが検証されます。
また、問題が発生している場合や単純に細部までこだわりたい場合は、ファイルのキャプチャ前と適用後に、ファイルに対してハッシュ ユーティリティを実行できます。イメージをマウントして再度ハッシュすることで、キャプチャ後にイメージを検証することもできます。この方法は、イメージが適切にキャプチャされたことを確認するのに悪くありません。
イメージが最初から適切にキャプチャされるようにしたい場合があるでしょう。/check スイッチと形式自体は、適切にキャプチャされないイメージを修復する回復ツールとしてではなく、チェックポイントとしてデザインされています。

ブートとフラグ
既に説明したように、/boot を使用し、Windows PE の WIM ボリューム イメージをキャプチャしてブートすることができます。これは、特定のボリューム イメージのブート セクタと考えてください。ブート セクタは、１ つの WIM につき、1 つのボリューム イメージにのみ存在でき、Windows PE 2.0 でのみ有効です。Windows PE 1.x の WIM ボリューム イメージはブートできないことに注意してください。理由は、単純に不可能だからです。
Windows ボリューム イメージのフラグが参照されている場合があります。フラグは、Windows セットアップでのみ使用されます。ボリューム イメージの 2 というフラグは、ボリューム イメージに Windows PE とセットアップが含まれていることを意味します。9 というフラグは、Windows PE だけが含まれていることを意味します。その他のフラグが設定されていたり、フラグがない場合、そのイメージがセットアップとして使用されない、または使用できないことを意味します。イメージのフラグは、変更を加えるために ImageX を使用してキャプチャした後でも設定できます。WAIK (および必要に応じて Business Desktop Deployment Solution Accelerator) を使用して Windows PE WIM ブート イメージを作成すると、初めにフラグが適切に設定されるので、この方法を使用することをお勧めします。

HTA ユーザーへの注意点
最近、Windows PE 2.0 で HTA ファイルを実行すると発生する問題に関していくつかの報告を耳にしました。残念ながら、大量のスクリプトが含まれる HTA ファイルで発生する問題のようです。図 4 で、私が作成したサンプル ファイルのスクリーンショットをご覧ください。表示されたスクリプト エラーでは、情報が提供されていません。この問題は、複数のユーザーから報告され、私自身も体験しました。
図 4 HTA スクリプト エラー
図 4 HTA スクリプト エラー
ただ、ありがたいことに、この問題はわりと容易に修正できます。イメージを準備するときに、HTA のサポートだけでなく、XML のサポートも追加してください。HTA コンポーネントにない依存関係が、XML アドイン モジュールに含まれているようです。このサポートを追加することで、問題を解決できます。
このコラムの執筆に協力してくれた ImageX 開発者の Bruce Green 氏、Windows Deployment Test チームの Minxiao Zhou 氏と Raja Ganjikunta 氏に感謝します。

Wes Miller は、テキサス州オースティンにある Pluck 社 (www.pluck.com) の開発マネージャです。以前は、オースティンにある Winternals Software に勤務しており、その前はマイクロソフトで Windows のプログラム マネージャとプロダクト マネージャを兼任していました。Wes の連絡先は、technet@getwired.com (英語のみ) です。


 フィールド ノート: PC をリサイクルする
フィールド ノート
PC をリサイクルする
Jim Lynch

Communty Microsoft Authorized Refurbisher (MAR) プログラム (microsoft.com/mar) は、Microsoft Unlimited Potential イニシアチブの中でも特殊で比較的知名度の低いプロジェクトです。このプログラムでは、十分なサービスを受けていない多くの地域を対象に、教育を改善し、ビジネスや雇用を創り出し、持続的なビジネス チャンスを生み出す多様なプロジェクトをサポートしています。2000 年に英国で始まった Community MAR プログラムは、現在、世界 50 か国の 800 社以上の PC 再利用業者で構成されています。
Community MAR プログラムの中で最も驚くべき特徴の 1 つは、Windows® 2000 と Windows XP のライセンスをたったの 5 米ドルで提供できることです。Community MAR プログラムでは、修理した PC で、年間 200,000 を上回るライセンスを非営利組織、学校、図書館、大学などに提供しています。また、米国では、低所得者や障害のある方にテクノロジ アクセス プログラムを提供しています。このような方法で、Community MAR プログラムは、情報格差で苦しむ人々に手を差し伸べ、教育と雇用の機会を得る方法を提供しています。
十分なサービスを受けていない子供たちに手を差し伸べるため、Community MAR プログラムは世界各地で展開しています。たとえば、Operation Homelink は米軍兵の低所得世帯にコンピュータを提供し、英国の Computer Aid International は、最大の非政府組織で、アフリカにコンピュータを提供しています。また、Computers for Schools Canada の再利用業者ネットワークでは、カナダの学校に提供されるコンピュータの大部分を提供しています。
再利用の重要性
アメリカ環境保護庁は近年テネシー大学と協力して、エネルギー、原料、CO2、および毒物排出の観点から、電子機器の再利用の重要性を証明しました。そこで開発された Electronics Environmental Benefits Calculator (eerc.ra.utk.edu/ccpct/eebc/eebc.html) によると、CRT モニタを使用するコンピュータをたった 1 台再利用するだけで、次のメリットがあります。
  • 30 ポンドの有害廃棄物を削減する
  • 77 ポンドの固形廃棄物を削減する
  • 77 ポンドの原料を削減する
  • 147 ポンド (17.5 ガロン) の水が汚染されるのを防ぐ
  • 32 トンの空気が汚染されるのを防ぐ
  • 1,333 ポンドの CO2 が排出されるのを防ぐ
  • 7,719 キロワットのエネルギーを削減する

事実、Community MAR プログラムは、元来テクノロジの利用が限られていた学校や慈善団体の電子機器の循環を促進する目的で、2000 年に英国で始まったものです。このプログラムは、2003 年には米国とオーストラリアに拡大し、2005 年には世界規模で展開されるようになり、現在は、(営利、非営利、政府、学校ベースなどの) すべての種類の再利用業者が参加できるようになりました。また、コンピュータの再利用が活性化され、修理産業が作られました。
Community MAR プログラムのメリットで、あまり明らかになっていないものの 1 つには、環境面に関するものがあります。電子機器を長期間使用することで、その機能を最高の状態で維持し、経済的、環境的、社会的に最も大きな利益をもたらすので、電子機器の寿命を延ばすことは最も効果的なリサイクル方法です。耐用年数を過ぎたリサイクルは確かに良いことで必要なことですが、それではどんな物でも 10 ～ 30% の原料とエネルギーを無駄にすることになります。
当然、コンピュータの製造には莫大な環境コストがかかります。アリゾナ州立大学の環境科学者 Eric D. Williams 氏によると、標準的な 53 ポンドのデスクトップ コンピュータとモニタを製造するには、化石燃料 530 ポンド、化学物質 50 ポンド、水 3,330 ポンドが必要です。コンピュータの寿命を 2、3 年延ばすことによって、ライフサイクルが終わり耐用年数を過ぎたコンピュータをリサイクルするよりも 5 ～ 20 倍のエネルギーを削減することができます (補足記事「再利用の重要性」では、もっと驚くような数字を紹介しています)。
全体としては、マイクロソフトは、この革新的なプログラムを通じて、テクノロジの恩恵を必要としている人々にその手助けをすることによって、地域を変えられる機会作りを支援しています。Community MAR プログラムによって、コンピュータの再利用に対する人々の意識が高まり、また人々からのサポートが得られたことは、予想していなかった付加利益です。

Jim Lynch は TechSoup.org でコンピュータのリサイクルと再利用についてのプログラム ディレクタをしています。TechSoup.org はサンフランシスコに拠点を置く非営利組織で、世界各国の慈善団体を対象にハードウェア、ソフトウェア、ノウハウをとても安く供給することを使命としています。


 Windows 秘話: ワトソン博士の呼び出し
Windows 秘話
ワトソン博士の呼び出し
Raymond Chen

ワトソン博士 (drwtsn32.exe) で、 Winlogon プロセスのメモリ ダンプを採取するように指定すると、その終了と同時に Windows® がシャットダウンされることをご存知の方もいらっしゃるでしょう。「Winlogon プロセスにデバッガを接続しただけで、なぜシステム全体がシャットダウンされるのだろう」と不思議に思う方もいるかもしれません。
デバッガを接続したことが原因でシステムがシャットダウンされたわけではありません。特定のプロセスに対してワトソン博士を実行することと、デバッガをプロセスに接続することは違います。デバッガを接続する際には ntsd などを使用しますが、これには所定の特権が必要です。実際、Windows チームでは、この方法を使用して Winlogon プロセスで発生した問題をデバッグします。このため、「Winlogon プロセスにデバッガを接続すると、なぜシステム全体がシャットダウンされるのか」という質問への逐語的な回答は、「システムがシャットダウンしたのは、デバッガを Winlogon プロセスに接続したからではない」というものになります。
しかし、ワトソン博士は “一般開業医” ではなく “監察医” です。ワトソン博士は、問題のあるプロセスのメモリ ダンプを採取すると、そのプロセスを終了します。ワトソン博士では問題を修正しないので、問題のあるプロセスを実行したままにすると、そのプロセスで再度クラッシュが発生します。そして、ワトソン博士が再度呼ばれ、無限ループが発生することになります。ワトソン博士は、実際にはデバッグを行わないデバッガであると言えます。優秀なワトソン博士は、現場に現れ、状況を十分に把握し、プロセスを終了します。つまり、メモリ ダンプを採取した後に Winlogon プロセスを終了することが原因で、システムがクラッシュしていたのです。
Winlogon プロセスを終了するとシステムが再起動します
Winlogon は "重要なシステム プロセス" として知られています。重要なプロセスが終了すると、システムは強制的に再起動されます。Winlogon プロセスがシステムの機能にとって重要であると考えられる理由は何でしょうか。まず第一に、Winlogon プロセスによってセキュリティ シーケンス (<B>Ctrl</B> + <B>Alt</B> + <B>Del</B>) が処理されることが挙げられます。Winlogon プロセスが実行されていない場合、セキュリティ シーケンスが機能しなくなります。これでは、少々困ったことになります。さらに悪いことに、公式なセキュリティ シーケンスの不在により、別のプログラムで、ユーザーが <B>Ctrl</B> + <B>Alt</B> + <B>Del</B> キーを押すのを待機して、偽のパスワード ダイアログを表示することが可能になります。なりすましが可能になるため、これでは適切なセキュリティ シーケンスとは言えません。なりすましを防止するため、状況が悪化する前に、Windows は自動的にシャットダウンされます。
タスク マネージャを起動し、Winlogon などの重要なシステム プロセスを強調表示して [プロセスの終了] をクリックし、プロセスを終了することを承認すると、どうなるでしょうか。Winlogon プロセスが終了されシステムが再起動されます (ただし、この操作を実行できるのは、このプロセスを終了する特権を持つ管理者のみです)。
以前のバージョンの Windows のタスク マネージャでは、重要なシステム プロセスを終了できないようにしようとしていましたが、どのプロセスが重要であるかを判断するアルゴリズムが十分ではありませんでした。その気になれば、タスク マネージャを欺いて、タスク マネージャで終了できないプログラムを作成することが可能でした。もちろん、終了することができないプログラムを作成することはできません。ただ、タスク マネージャ以外のプログラムを使用して、プログラムを終了する必要がありました。たとえば、プログラムを終了するプログラムには、taskkill などがあります。
不正な操作を防止するため、タスク マネージャで重要なシステム プロセスを終了できるようになりました。結局、何もしなければ操作を間違えることもないのです。つまり、タスク マネージャでは、プロセスの終了処理が監視されなくなりました。終了しない方がよいプロセスを終了しようとしても、警告が表示されることはありません。重要なシステム プロセスを終了した場合は、その結果を受け入れるしかないのです。

Raymond Chen は自分の Web サイト「The Old New Thing」および同じタイトルの書籍 (Addison-Wesley、2007 年) で、Windows の歴史と Win32 プログラミングについて扱っています。彼は、メカニズムをオペレーション可能にする仕事は他の人に任せています。