 TechNet Magazine December 2007

TechNet Magazine December 2007

通信: Exchange Server 2007 Service Pack 1 で導入される 16 の新機能

一般的な Service Pack とは異なり、Exchange Server 2007 Service Pack 1 は、単なる修正プログラムとセキュリティ更新プログラムではなく、他にも多くのものが提供されます。今月は、SP1 が提供する新機能のうち、最も重要ないくつかの機能の概要を紹介します。

Tony Smith 通信: Exchange Server 2007 Service Pack 1 のスタンバイ連続レプリケーション

Service Pack 1 で提供される最も魅力的な機能の 1 つに、スタンバイ連続レプリケーションがあります。この記事では、この機能を使用して、稼働時間をより長くし、データの損失量を抑え、電子メールを容易に保守および保存できるようにする方法について説明します。

Scott Schnoll 通信: Windows Server 2008 で Exchange Server を実行する

Windows Server 2008 で Exchange Server を実行する準備をしていますか。マイクロソフトの Exchange Server 開発チームは、ここしばらくの間その準備をしてきました。皆さんの環境で Exchange Server の導入準備を進めるのに役立つよう、そこから得た教訓とアドバイスを Paul Bowden が紹介します。

Paul Bowden 通信: Exchange Server 2007 を使用してユニファイド メッセージングを展開する

ボイスメール、FAX 機能、および電子メール メッセージングを 1 つのメールボックスにまとめることは、非常に難しい作業であるように感じられるかもしれません。しかし、考えているよりも簡単です。ここでは、ユニファイド メッセージングを組織に展開するためのガイドを提供します。

Jeff Goodwin セキュリティ: 基本的なコンピュータ フォレンジック ガイド

一般の管理者が基本的な調査に使用できる、簡単で費用のかからないコンピュータ フォレンジックの方法について説明します。

Tom Cloward and Frank Simorjay ネットワーク: Microsoft Security Intelligence Report

マイクロソフトでは、コンピュータ ユーザーが直面するセキュリティの脅威について多くのデータを収集しています。ここでは、最近の傾向、Windows の各バージョンの状況、世界で最も感染の割合が高い地域などについて概説します。

Tim Rains ネットワーク: 特定しにくいネットワークの問題を突き止める

明らかな原因がないのに、他のコンピュータと通信できないコンピュータがある場合は、今月のコラムでご紹介するヒントが問題を速やかに診断して修復するのに役立ちます。

Christopher Stoneff 編集長から: 会話を始める

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

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

Greg Steen SQL に関する Q&A: メモリの構成、パフォーマンスのプロファイル、FILL FACTOR の設定など

Edited by Nancy Michell ユーティリティ スポットライト: Microsoft Security Assessment Tool

今月のコラムで紹介する無料のユーティリティと電子アンケートは、中規模組織でネットワーク セキュリティのリスクを特定して解決するのに役立ちます。

Lance Whitney The Cable Guy: ネットワーク ポリシー サーバー

Windows Server 2008 のネットワーク ポリシー サーバー (NPS) サービスは、Windows Server 2003 のインターネット認証サービスの後継で、システム正常性の要件を義務付ける機能や管理機能の強化など、さまざまな機能強化が施されています。

Joseph Davies Windows PowerShell: 各コマンドレットについて掘り下げる

Windows PowerShell には見過ごされている機能が多数あります。体系的なアプローチを使用して Windows PowerShell コマンドレットについて調べることで、これまでに気付かなかった強力な機能を発見することができます。

Don Jones Hey, Scripting Guy!: 帰ってきた WinRM

執事の仕業でしょうか。ろうそく立てと一緒に食品庫にあったのでしょうか。そんなことは、だれにもわかりません。とにかく、4 週間という長い時間を経て、ついに Scripting Guys が WinRM の第 2 部と共に戻ってきました。

The Microsoft Scripting Guys セキュリティ ウォッチ: Windows ドメインのパスワード ポリシー

今まで、Windows で 1 つのドメインに適用できるパスワード ポリシーは 1 つだけでした。しかし、Windows Server 2008 では管理者が複数のパスワード ポリシーを実装することによって、ユーザーの種類に合わせて異なるポリシーを適用することができます。

Derek Melber デスクトップ ファイル: 仮想世界で Windows を展開する

仮想化について考えていますか。考えていないとしたら、考えるべきです。ここでは、仮想システムを展開するために必要な知識、避けるべきこと、および仮想化の実際のしくみについて説明します。

Wes Miller フィールド ノート: 代替可能な未来

個人の生活におけるテクノロジと認識、および職場におけるテクノロジと認識との境界がなくなり、IT は "コンシューマ主導型" になりました。これは、仕事とプライベートの両方に非常に大きな影響をもたらしています。

Romi Mahajan Windows 秘話: ジョイスティックは電子レンジである必要はない

DirectInput フォース フィードバック ジョイスティック インターフェイスで周期的フォースを指定する方法、およびいくつかの予期しない結果について説明します。

Raymond Chen


 通信: Exchange Server 2007 Service Pack 1 で導入される 16 の新機能
通信 Tony Smith

Exchange Server 2007 Service Pack 1 で導入される 16 の新機能
概要:
  • 新しい管理機能
  • サーバーの役割の強化
  • ユニファイド メッセージングの強化

ほとんどの管理者は、Service Pack をダウンロードして、サーバーやデスクトップ システムに適用するプロセスを熟知しています。このようなダウンロードでは、もちろん、
使用しているシステムを最新の状態に保つのに役立つ修正プログラムやセキュリティ更新プログラムが提供されます。しかし、Service Pack には、それ以外のものが含まれることもあります。これは、間もなくリリースされる Microsoft® Exchange Server 2007 Service Pack 1 に当てはまります。この Service Pack には、多くの魅力的な新機能が含まれています。
このダウンロード (go.microsoft.com/fwlink/?LinkId=91472 で提供予定) を使用すると、Exchange Server 2007 の (SP1 の更新プログラムもすべてインストールされる) 完全インストールを実行することも、既存の Exchange Server 2007 インストールを更新することもできます。Exchange Server 2007 SP1 は、Windows Server® 2003 SP1、SP2、および R2 にインストールできますが、将来リリースされる Windows Server 2008 とも互換性があります。
Service Pack 1 では、多数の新機能や機能強化が導入されるので、そのすべてをこの概要で取り上げることはできません。そこで、ご使用中の Exchange Server 環境を強化するのに使用できる、最も特筆すべき変更の一部を列挙して説明することにします。すべての変更の詳細については、「Exchange Server 2007 SP1 の新機能」(technet.microsoft.com/bb676323.aspx) を参照してください。

Exchange 管理コンソールへの変更点
Service Pack 1 では、Exchange 管理コンソール (図 1 参照) にいくつかの便利な新機能が追加されています。まず、ツールボックスに、パブリック フォルダ管理コンソール、詳細テンプレート エディタ、ルーティング ログ ビューアが含まれるようになりました (ツールボックスには、既定で Exchange Server 2007 と共にインストールされる一連の診断ツール、トラブルシューティング ツール、回復ツールが用意されています)。
図 1 Service Pack 1 の Exchange 管理コンソール
図 1 Service Pack 1 の Exchange 管理コンソール
Exchange 管理コンソール、パブリック フォルダ管理コンソール、詳細テンプレート エディタ、およびキュー ビューアを使用して、結果ウィンドウと作業ウィンドウから一覧をエクスポートすることができます。一覧は、テキスト (タブ区切り)、テキスト (コンマ区切り)、Unicode テキスト (タブ区切り)、および Unicode テキスト (コンマ区切り) 形式でエクスポートすることができます。また、Exchange 管理コンソールの結果ウィンドウのコンテンツをフィルタ処理できるだけでなく、パブリック フォルダ管理コンソール、詳細テンプレート エディタ、およびキュー ビューアの結果ウィンドウのコンテンツもフィルタ処理できるようになりました。
しかし、最も注目に値するのは、Exchange 管理コンソールに、多くの新しい管理インターフェイス (前述のパブリック フォルダ管理コンソールなど) が追加されたことです。このような新しい管理インターフェイスについては、この記事の中で個別に説明します。

IPv6 のサポート
SP1 では Windows Server 2008 をサポートするため、インターネット プロトコル バージョン 6 (IPv6) もサポートされます。もちろん、これは、IPv4 プロトコル スタックと IPv6 プロトコル スタックの両方が有効になっている Windows Server 2008 に Exchange Server 2007 がインストールされている場合の話です。インストール前に IPv4 を無効にすると、Exchange Server は IPv6 をサポートしません。
IP アドレスと IP アドレスの範囲は、IPv4 形式または IPv6 形式で入力できます。1 つを除くすべてのサーバーの役割では、IPv6 アドレスを使用している、デバイス、サーバー、およびクライアントに対してデータを送受信することができます。唯一の例外は、ユニファイド メッセージング サーバーの役割です。これは、いくつかの必要なテレフォニー コンポーネントと音声認識コンポーネントが持つ制限により、ユニファイド メッセージングの役割では IPv4 が必要なためです。

POP3 と IMAP4 の管理 UI
Exchange 管理コンソールには、POP3 と IMAP4 を管理するための新しい管理 UI が含まれています。クライアント アクセス サーバーの POP3 と IMAP4 の設定 (ポートの設定、認証の設定、接続の設定など) はすべて、ここで構成することができます。図 2 に、IMAP4 プロパティ構成ダイアログ ボックスを示します。POP3 の場合も、これと同じオプションが使用できます。
図 2 POP3 と IMAP4 用の Exchange 管理コンソール
図 2 POP3 と IMAP4 用の Exchange 管理コンソール

より堅牢なメールボックスの管理
Exchange 管理コンソールのメールボックスの管理機能では、既存のユーザー アカウントのメールボックスを一括で作成できるようになりました。また、新しいウィザードを使用すると、管理者は、メールボックスに対するフル アクセス権を許可または削除したり、メールボックスに対する "送信者" アクセス許可を構成したりすることができます。

メールボックスのデータを管理するための新機能
管理者は、.pst ファイルをインポートおよびエクスポートして、メールボックスのデータを管理できるようになりました。これは、Exchange 管理シェルで Import-Mailbox コマンドレットと Export-Mailbox コマンドレットをそれぞれ使用して行うこともできます。
Exchange Server のスタンダード クライアント アクセス ライセンスを持つ Exchange Server サーバー上にある管理された既定フォルダには、メッセージング レコード管理 (MRM) を適用することができます (管理されたカスタム フォルダに MRM を適用するには、Exchange Server のエンタープライズ クライアント アクセス ライセンスが必要です)。RemoveManagedFolderAndPolicy という新しいパラメータ (Set-Mailbox コマンドレットで使用します) を使用すると、メールボックスからすべての MRM ポリシーが削除され、メールボックスに適用された MRM ポリシーの一部として作成された管理フォルダすべてから MRM プロパティが削除され、すべての管理フォルダが標準のフォルダに変換されます。
新しいパフォーマンス モニタのカウンタでは、オンラインでのディスクの最適化に関するさまざまな情報 (具体的には、オンラインでのディスクの最適化が前回実行されたのはいつか、完了するのにどれくらいの時間がかかったか、その最適化によって何が行われたか) を監視できます。この情報は、オンラインでのディスクの最適化を実行する適切な間隔を判断するのに役立ちます。

リモート ワイプの確認
Exchange Server 2007 では、管理者やアカウント ユーザーはリモート ワイプを実行してモバイル デバイスからすべてのユーザー データを消去することができます。これは、デバイスの紛失時や盗難時に使用できる便利なセキュリティ機能です。Service Pack 1 では、これに加えて、デバイスがリモート ワイプ要求の受信を確認すると、確認メッセージが送信されます。ユーザーが (Outlook® Web Access (OWA) を通じて) 要求を発信した場合は、そのユーザーに確認の電子メールが届きます。管理者が (Exchange 管理コンソールを通じて) 要求を発行した場合は、管理者とユーザーの両方に確認の電子メールが届きます。

より堅牢な OWA クライアント
Web ベースの電子メール クライアントには、より優れたメッセージングをモバイル ワーカーに提供する、多くの機能強化が用意されています。SP1 では、OWA ユーザーは、個人用配布リストとサーバー側のルールを作成および編集することができます。また、ユーザーは、削除済みアイテム収集機能と削除済みアイテムの回復機能を使用することもできます。
移動コマンドとコピー コマンドが UI に追加されたため、ユーザーは、フォルダ一覧を右クリックして、フォルダの移動とコピーを行えるようになります。アイテム一覧内で右クリックするか、ツール バーのアイコンをクリックすることにより、メッセージ フォルダとパブリック フォルダ内の各アイテムも移動およびコピーすることができます。
また、OWA ユーザーは、/public 仮想ディレクトリを使用しなくてもパブリック フォルダに完全にアクセスできます (これをサポートするために Exchange 2003 バックエンド サーバーを使用する必要はありません)。そして、OWA ではパブリック フォルダ検索機能がサポートされます。
S/MIME 機能を使用して、ユーザーは、署名付きの電子メール メッセージや暗号化された電子メール メッセージを読んだり作成したりすることができるようになります (図 3 参照)。さらに、CNG (Cryptography API: Next Generation) がサポートされ、Suite-B にも準拠しています。また、OWA の UI は、カスタム アプリケーションをシームレスに統合するようにカスタマイズすることができます。
図 3 S/MIME メッセージの設定
図 3 S/MIME メッセージの設定

OWA Light における作成の監視
Outlook Web Access Light (ほぼすべての Web ブラウザで機能するように設計された比較的単純なバージョンの OWA) では、ユーザーが長時間にわたってなんらかの文字列 (メッセージ、予定表のエントリなど) を入力をしている間、アクティビティが監視されるようになりました。これは、ユーザーが、まだ入力を行っている間にセッションがタイムアウトして、データが失われることを回避するための機能です。また、メッセージ作成フォームが開いている間に、操作が行われなかったことが原因でセッションがタイムアウトした場合、メッセージは下書きフォルダに自動的に保存されます。

ダイレクト プッシュのパフォーマンスの向上
ダイレクト プッシュは、モバイル デバイスと Exchange Server 2007 サーバーとの間に HTTPS 接続を確立することにより機能します。Exchange Server 2007 SP1 では、HTTPS 要求ヘッダーと HTTPS 応答ヘッダーのサイズが縮小されたので、モバイル デバイスとの間で送受信するデータの量が少なくなります。

パブリック フォルダ管理
新しく導入されたパブリック フォルダ管理コンソール (図 4 参照) を使用すると、管理者は、Exchange 管理コンソール内から、パブリック フォルダを作成、構成、および管理することができます。アドレス一覧、電子メール アドレス ポリシー、動的配布グループ、および配布リストは、パブリック フォルダに対応しています。アドレス一覧、電子メール アドレス ポリシー、動的配布グループ、および配布グループの受信者をプレビューすると、グループ メンバシップの条件に含まれているパブリック フォルダで、メールに対応しているものを確認することができます。
図 4 パブリック フォルダ管理コンソール
図 4 パブリック フォルダ管理コンソール
Exchange Server 2007 SP1 のパブリック フォルダ管理コンソールを使用すると、パブリック フォルダ管理者権限を構成することができます。Public Folder Administrator の役割にユーザーを追加するには、Add-ExchangeAdministrator コマンドレットまたは Exchange 管理者の追加ウィザードを使用し、パブリック フォルダに対する特定の権限を許可または拒否するには、Add-PublicFolderAdministratorPermission コマンドレットを使用します。

メッセージ処理とメッセージ ルーティングの強化
Active Directory® フォレスト内に展開されたハブ トランスポート サーバーは、組織内のすべてのメール フローを処理し、トランスポート ルールを適用し、ジャーナル ルールを適用し、受信者のメールボックスにメッセージを配信します。組織外に送信されるメッセージは、ハブ トランスポート サーバーによって、ネットワーク境界上のエッジ トランスポート サーバーに中継されます。SP1 では、これらのサーバーの役割が強化されています。
Exchange Server 2007 には、バック プレッシャと呼ばれる、システム リソース監視機能が含まれています。この機能により、ハブ トランスポート サーバーとエッジ トランスポート サーバーは高いリソース使用率に対処できます。SP1 では、必要な空きディスク領域が大幅に (4 GB から 500 MB にまで) 削減されました。
SP1 の Exchange 管理コンソールでは、より多くのトランスポート構成の設定が用意されています。また、権限のあるドメインとして X.400 アドレス スペースを構成することができるようになりました (X.400 の長いアドレスもサポートされるようになりました)。
ハブ トランスポート サーバーは、優先度キューをサポートしています。Outlook ユーザーがメッセージに割り当てた優先度はカテゴライザによって考慮され、"重要度 - 高" で送信されたメッセージが、実際に優先的に処理され、"重要度 - 低" で送信されたメッセージよりも早く配信されるようになります。
Exchange Server 2007 SP1 では、Exchange 管理シェル コマンドレットに IsScopedConnector パラメータが追加されたことと、Exchange 管理コンソールに [Scoped Send Connector] (スコープが限定された送信コネクタ) チェック ボックスが追加されたことにより、送信コネクタのスコープを 1 つの Active Directory サイトに限定することが簡単になっています。送信コネクタのスコープが限定されると、ルーティングを決定する際に、この送信コネクタを検討対象とするのは、送信コネクタのソース サーバーと同じ Active Directory サイト内にあるハブ トランスポート サーバーのみとなります。

エッジ トランスポート サーバーの同期の機能強化
Exchange Server 2007 SP1 では、Start-EdgeSynchronization コマンドレットを使用して、Active Directory から Active Directory Application Mode (ADAM) ディレクトリ サービスへのデータの同期をすぐに開始できます。Exchange Server 2007 SP1 では、このコマンドレットは Server パラメータをサポートしています。このパラメータを使用すると、このコマンドレットをリモート コンピュータから実行できます。
エッジ トランスポート サーバーの同期状態をレポートする診断コマンドレットである Test-EdgeSynchronization コマンドレットは、個々のユーザーの同期結果を検証できる新しいパラメータ セットの追加により強化されています。

TransportConfig オブジェクトの複製
複製された構成スクリプトにより、管理者は、環境内に複数のエッジ トランスポート サーバーが展開されている場合に、同じ構成を簡単に適用することができます。SP1 では、複製された構成情報に、(サーバー全体にかかわるエッジ トランスポート サーバーの役割の設定を制御する) TransportConfig オブジェクトが含まれるようになりました。このオブジェクトが含まれることにより、サーバーの展開、バックアップ、および復元の手順が大幅に効率化されます。

ユニファイド メッセージングの強化
ユニファイド メッセージングは、Exchange Server 2007 の最初のリリースで導入された魅力的な機能でした。Service Pack 1 では、この機能を強化して、多くの新機能や機能強化が導入されています。一部の機能では、同じ Active Directory フォレスト内に Office Communications Server 2007 を展開する必要がありますが、Office Communications Server が必要でない機能も多数あります。今月のコラムでは、ユニファイド メッセージングへの変更点をすべて取り上げることはできませんが、注目すべき追加点の一部を簡単に説明します。ユニファイド メッセージングの詳細については、今月号の TechNet Magazine の「Exchange Server 2007 を使用してユニファイド メッセージングを展開する」を参照してください。
まず、Office Communications Server 2007 を必要とする新機能のいくつかについて説明します。ファイアウォールを通過するメディア ストリームと高品質の音声メッセージがサポートされるようになりました。相手が着信の転送を使用している場合、音声メッセージを残すと、転送されることが通知されます。ユーザーは、PIN を入力することなく、Office Communicator 2007 から Outlook Voice Access にアクセスできます。不在着信通知の電子メール メッセージとボイスメール通知は Office Communicator 2007 に統合されています (図 5 参照)。Office Communications Server 2007 を必要とする新機能は、他にもたくさんあります。
図 5 Office Communicator のボイスメール通知
図 5 Office Communicator のボイスメール通知
ユニファイド メッセージングの機能強化のうち、Office Communications Server を必要としないものの 1 つは、Secure Realtime Transport Protocol (SRTP) のサポートです。Exchange Server 2007 の最初のリリースでは、"セキュリティ保護なし" と "セキュリティで保護" という 2 つのセキュリティ モードが用意されていました。"セキュリティで保護" モードでは、セッション開始プロトコル (SIP) トラフィックのみが暗号化され、RTP トラフィックは暗号化されません。SP1 では、"セキュリティ保護なし"、"セキュリティで保護された SIP"、および "セキュリティで保護" という 3 つのモードが用意されています。"セキュリティで保護された SIP" モードでは、SIP トラフィックのみが暗号化され、RTP トラフィックは暗号化されません。"セキュリティで保護" モードでは、SIP トラフィックと RTP トラフィックの両方が暗号化されます。また、Exchange 管理コンソールを使用して、ダイヤル プラン用に相互トランスポート層セキュリティ (MTLS) を構成することもできます。
その他の変更には、新しく導入されたユニファイド メッセージングの有効化ウィザード (これを使用して、ユーザーの SIP アドレスや E.164 アドレスを追加できます) や、Exchange 管理コンソールを使用してダイヤル プランの URI タイプを構成できるようになったことなどがあります。また、SP1 では、メディア トラフィックをタグ付けするのに DiffServ を使用することにより、サービスの品質 (QoS) がサポートされるようになりました。

高可用性の強化
Service Pack 1 では、既存の高可用性機能が強化されるだけでなく、さらなる高可用性を実現するいくつかの新機能が導入されています。強化された新機能を使用すると、Exchange Server 2007 のサーバーの役割でデータとサービスの可用性が確保されるシナリオをさらに強化することができます。このような新しいシナリオにより、組織では、高可用性を重視したシナリオを、サイトの回復性を重視したシナリオから分離することができます。また、組織の各領域の要件に合った構成を展開できるようになります。
まず、Windows Server 2008 がサポートされるようになったことによって、複数サブネットのフェールオーバー クラスタが可能になり、新しいクォーラム モデル (ディスクとファイル共有の監視) もサポートされるようになります。クラスタのレポートや監視の機能にも、(連続レプリケーション環境を積極的に監視するように設計された追加機能など) 非常に役立つ機能強化が行われています。一方、パフォーマンス関連の機能強化には、ストレージ グループのパッシブ コピーが格納されたディスクへの入出力が少なくなること、ログ ファイルのコピーの高速化、クラスタ化されたメールボックス サーバーをノード間で移動する作業の高速化などがあります。
また、管理と構成を行いやすくするために新しいウィザードが追加されました (図 6 参照)。クラスタ化されたメールボックス サーバーを管理するための新しい UI コントロール ([クラスタ化メールボックス サーバー] タブ、クラスタ連続レプリケーション (CCR) 構成ページなど) が追加されました。
図 6 Manage Clustered Mailbox Server Wizard (クラスタ化されたメールボックス サーバーの管理ウィザード)
図 6 Manage Clustered Mailbox Server Wizard (クラスタ化されたメールボックス サーバーの管理ウィザード)

スタンバイ連続レプリケーション
スタンバイ連続レプリケーション (SCR) では、ローカル連続レプリケーション (LCR) と CCR で使用されていのると同じログ配布テクノロジと再生テクノロジを使用して、今までにない展開の選択肢と構成を提供します。SCR は LCR や CCR と似ていますが、SCR 固有の特徴もあります。SCR の詳細については、今月号の TechNet Magazine で Scott Schnoll が執筆した記事「Exchange Server 2007 Service Pack 1 のスタンバイ連続レプリケーション」を参照してください。

まとめ
Exchange Server 2007 Service Pack 1 は、単なる修正プログラムとセキュリティ更新プログラムではありません。すぐになくてはならないものになる多くの新機能と機能強化が用意されています。今月のコラムでは、すべての新機能と機能強化を取り上げることはできませんが、この Service Pack で提供される機能の概要を理解していただけたのであれば、さいわいです。Service Pack 1 でのすべての変更点の詳細、ダウンロード、Web キャスト、ディスカッション フォーラムについては、Exchange Server TechCenter (technet.microsoft.com/exchange) を参照してください。

Tony Smith は Exchange User Education チームのリード テクニカル ライターで、ユニファイド メッセージングを専門にしています。Tony は、マイクロソフトに勤務する前は、ネットワーク エンジニア、マイクロソフトのベンダ、およびマイクロソフト認定トレーナーとして働いていました。また、Microsoft Learning のための執筆プロジェクト (書籍、ラボ マニュアルなど) にも従事してきました。
© 2007 Microsoft Corporation and CMP Media, LLC. All rights reserved; 許可なしに一部または全体を複製することは禁止されています.


 通信: Exchange Server 2007 Service Pack 1 のスタンバイ連続レプリケーション
通信 Scott Schnoll

Exchange Server 2007 Service Pack 1 のスタンバイ連続レプリケーション
概要:
  • スタンバイ連続レプリケーションを構成する
  • 冗長性を確保することの重要性
  • SCR によってダウンタイムが短縮されるしくみ

Exchange 2007 Service Pack 1 では、いくつかの新機能と機能強化が提供されます。組織は、これらの新機能の 1 つであるスタンバイ連続レプリケーション (SCR) を使用して、データセンター内の冗長性とサイトの回復性を確保できるようになります。SCR は、その名のとおり
スタンバイ回復サーバーを使用するシナリオ向けに設計されています。
Exchange 2007 の製品 (RTM) 版についてよく知っている皆さんは、ログ配布機能と Windows® フェールオーバー クラスタのサポートを利用することで、データセンター内の冗長性とサイトの回復性を確保できることをご存知だと思います。RTM 版では、2 つの形式のログ配布機能 (正式には連続レプリケーションとして知られています) を利用できます。これらは、ローカル連続レプリケーション (LCR、図 1 参照) とクラスタ連続レプリケーション (CCR、図 2 参照) です。
図 1 ローカル連続レプリケーション
図 1 ローカル連続レプリケーション
Figure 2 CCR is log shipping to a second server in a Windows failover cluster
Figure 2 CCR is log shipping to a second server in a Windows failover cluster
管理者は、連続レプリケーションを使用すると、各メールボックス データベースのコピーをオンラインで作成して保守できるため、データの可用性と冗長性を確保できます。このデータベースのコピーは、運用データベースの障害、損失、または破損に対する防御の最前線として機能します。データを復元するためにバックアップ テープを探さなくても、データベースのコピーをアクティブにして、数分以内に運用データベースとして使用することができます。
SCR を使用すると、組織のデータとサービスの可用性が確保されるシナリオをさらに強化することができます。新しいシナリオでは、高可用性を重視したトポロジを、サイトの回復性を重視したトポロジから分離することができます。また、組織の各領域の要件に合った構成を展開できるようになります。
Exchange 2007 の RTM 版ではデータセンター内の冗長性とサイトの回復性が提供されますが、LCR と CCR では各データベースのコピーが 1 つ提供されるだけであるため、冗長性と回復性のどちらを取るかを選択する必要があります。たとえば、CCR によって提供されるデータとサービスの可用性機能について考えてみましょう。1 つのデータセンターにアクティブ ノードとパッシブ ノードの両方を展開した場合、データセンター内のサービスとデータの可用性は提供されますが、サイトの回復性は提供されません (どちらのノードも物理的には同じサイト内に配置されているためです)。また、1 つのデータセンターにアクティブ ノードを展開し、もう 1 つのデータセンターにパッシブ ノードを展開した場合、サイトの回復性は提供されますが、データセンター内の可用性は提供されません (この機能を提供するパッシブ ノードが別のデータセンター内に配置されているためです)。
Service Pack 1 の SCR では、各データベースのコピーを複数作成することで、可用性とサイトの回復性を (どちらか 1 つだけではなく) 両方確保することができます。たとえば、図 3 にあるように、SCR と CCR を組み合わせて使用できます。ローカルのプライマリ データセンターでストレージ グループをレプリケート (CCR を使用して高可用性を確保) し、リモートの別のバックアップ データセンターにも、それらのストレージ グループをレプリケート (SCR を使用してサイトの回復性を確保) します。サイトを回復するシナリオでは、バックアップ データセンターのクラスタ化された代替メールボックス サーバーを使用することによって、スタンバイ クラスタをアクティブにし、すばやく準備することができます。
図 3 レドモンド データセンターに展開された CCR とクインシー データセンターに展開された SCR
図 3 レドモンド データセンターに展開された CCR とクインシー データセンターに展開された SCR
図 3 は、ある企業がレドモンドとクインシーに展開した 2 つのデータセンターを示しています。データセンターごとに、独自の Active Directory® サイトがあります。レドモンド サイトはプライマリ (運用) データセンター内にあり、クインシー サイトはセカンダリ (バックアップ) データセンター内にあります。レドモンドでは、CCR を展開してデータセンター内の冗長性を確保しています。クインシーのスタンバイ クラスタでは、Exchange 2007 に必要なインフラストラクチャ要素だけでなく、SCR ターゲットを構成して、サイトの回復性を確保しています。クライアント アクセス サーバーとハブ トランスポート サーバー、Active Directory サーバーと DNS サーバー、インターネット アクセスなどを含む、これらの追加のインフラストラクチャ要素は、専用リソースまたは非専用リソースにすることができます。専用リソースは、特定のデータセンターのユーザーのみをサポートするように指定されたリソースです。非専用リソースは、ローカル データセンターだけでなく、他の場所のユーザーもサポートするリソースです。組織の要件に応じて、専用リソースと非専用リソースのどちらにするかを判断する必要があります。専用リソースと非専用リソースの詳細については、Exchange Server 2007 ヘルプの「サイトの回復性を確保するための構成」(technet.microsoft.com/bb201662.aspx) を参照してください。また、新しい種類のマジョリティ ノード セット (MNS) クォーラムの使用方法にも注意してください。Exchange Server 2007 の CCR は、従来の返信ノードの代わりに、MNS クォーラムとファイル共有監視を併用します (図 3 参照)。
回復性を重視して設計された、図 4 のような CCR と SCR を組み合わせた環境では、サーバー EXCLUS1 でホストされるメールボックスとサービスに複数層の冗長性が提供されるため、致命的な障害が発生した場合でも、その規模にかかわらずこれらのメールボックスを保護することができます。
図 4 SCR を使用して相互にストレージ グループをレプリケートするスタンドアロンの&#xA;メールボックス サーバー
図 4 SCR を使用して相互にストレージ グループをレプリケートするスタンドアロンの&#xA;メールボックス サーバー
小規模から中規模の組織も SCR からメリットを得ることができます。たとえば、組織は図 4 のようにスタンドアロンのメールボックス サーバー (EXMBX1 と EXMBX2) を 2 台展開し、SCR を使用することによって、一部またはすべてのストレージ グループを一方のメールボックス サーバーからもう一方のメールボックス サーバーにレプリケートできます。
この例の EXMBX1 と EXMBX2 は、どちらも 5 つのアクティブなストレージ グループを持つ運用サーバーです。各ストレージ グループは、対応する SCR ターゲットをもう一方のサーバーに持つ SCR ソースです。ストレージの障害やその他の問題が発生し、SCR ソースとして構成されたアクティブなストレージ グループが使用できなくなった場合、Exchange 管理シェルでいくつかの管理タスクを使用すれば、SCR ターゲットのコピーをすぐにアクティブにすることができます。Microsoft® Office Outlook® 2007、および Exchange 2007 で提供されるデータベースの移植性と自動検出機能によって、いずれかのアクティブなストレージ グループ (さらに言えば、複数のアクティブなストレージ グループ) が失われた場合でも、たった数分のダウンタイムで回復できる可能性があります。

SCR ソースと SCR ターゲット
LCR および CCR と同様に、SCR でもストレージ グループのアクティブ コピーとパッシブ コピーという概念が使用されますが、これらのコピーはそれぞれ SCR ソースおよび SCR ターゲットと呼ばれます。とはいえ、SCR ソースと SCR ターゲットの実体はストレージ グループのコピーです (回復用ストレージ グループは SCR には使用できません)。
SCR にまず必要なもの (SCR ソース) は、シングル コピー クラスタまたは CCR 環境にあるスタンドアロンのメールボックス サーバーまたはクラスタ化されたメールボックス サーバー上の任意のストレージ グループです。ここで 1 つ重要なことがあります。SCR ソースにはクラスタ化されたメールボックス サーバーを使用できますが、SCR 自体はクラスタ ソリューションではないため、Windows クラスタ サービスは必要ありません。SCR のエンドポイント (SCR ターゲット) には、スタンドアロンのメールボックス サーバーか、メールボックスの役割がインストールされているが、クラスタ化されたメールボックス サーバーが構成されていないフェールオーバー クラスタ内のノードを使用できます。

ソースとターゲットの関係
各 SCR ソース ストレージ グループの SCR ターゲットとして使用できるコンピュータの数に制限はありません。たとえば、ソースと同じデータセンター内にあるメールボックス サーバーと、別のデータセンター内にあるメールボックス サーバーをターゲットとして使用できます。ただし、1 つのソースにつき 4 つ以下のターゲットを使用することをお勧めします。4 つを超えるターゲットを使用する場合は、SCR ソース サーバーのリソース (メモリ、CPU、ディスクなど) に与える可能性がある影響を評価し、それに応じて計画を行う必要があります。各 SCR ターゲット コンピュータは、複数のソース サーバーのターゲットとして使用できます。ソース コンピュータとターゲット コンピュータでは、Exchange 2007 Service Pack 1 が実行されている必要があります。また、Exchange 2007 Service Pack 1 でサポートされているオペレーティング システム (Windows Server® 2008 や Windows Server 2003 SP2 など) が実行されている必要があります。ただし、使用するオペレーティング システムにかかわらず、SCR では異なるバージョンのオペレーティング システム間でのレプリケーションはサポートされていません。つまり、SCR ソースのオペレーティング システムと、そのコンピュータをソースとするすべての SCR ターゲットのオペレーティング システムが一致している必要があります。したがって、SCR ソースで Windows Server 2003 が実行されている場合、そのコンピュータをソースとするすべての SCR ターゲットで Windows Server 2003 が実行されている必要があります。
SCR は、Exchange 2007 Standard Edition で使用できます。SCC または CCR 環境内のクラスタ化されたメールボックス サーバーを SCR ソースとして使用する場合は、Exchange 2007 Enterprise Edition が必要です。Enterprise Edition を使用した場合、各 SCR ターゲットでは最大 50 個のインスタンス (50 個のレプリケートされたストレージ グループ) がサポートされます。Standard Edition を使用した場合は、最大 5 個のインスタンスがサポートされます。
SCR ターゲットの要件は他にもあります。まず、ソース コンピュータとターゲット コンピュータは同じ Active Directory ドメインに属している必要があります。属している Active Directory サイトは異なってもかまいません。また、ソースとそのコンピュータをソースとするすべてのターゲットのデータベース ファイルとログ ファイルのパスが、SCR によってレプリケートされる各ストレージ グループ内で一致している必要があります。さらに、あるノードまたはサーバーを SCR ターゲットとして構成した場合、その SCR ターゲット コンピュータ上のストレージ グループで LCR を有効にしたり、そのコンピュータが含まれているスタンバイ フェールオーバー クラスタに、クラスタ化されたメールボックス サーバーを追加したりすることはできません。

SCR を CCR および LCR と比較する
SCR は、LCR と CCR で使用されているものと同じログ配布テクノロジと再生テクノロジを使用して、今までにない展開の選択肢と構成を提供します (図 5 参照)。LCR および CCR と同様、SCR を有効にしたストレージ グループに複数のデータベースを含めることはできません。また、Exchange 組織に複数のパブリック フォルダ データベースが存在する場合、パブリック フォルダ データベースに SCR を使用することはできません。
図 5 別のサーバーまたはフェールオーバー クラスタ内のパッシブ ノードに&#xA;ログを配布する SCR
図 5 別のサーバーまたはフェールオーバー クラスタ内のパッシブ ノードに&#xA;ログを配布する SCR
SCR と CCR および LCR の重要な違いは、SCR では 1 つのストレージ グループにつき複数のターゲットがサポートされるが、LCR と CCR では 1 つのターゲット (パッシブ コピー) しかサポートされないということです。もう 1 つの重要な違いは、CCR および LCR とは異なり、SCR のコピーはバックアップできないということです。SCR の場合、サポートされているバックアップを SCR ソース ストレージ グループに対して作成すると (CCR と LCR の場合は、SCR ソース ストレージ グループのアクティブ コピーまたはパッシブ コピーに対してバックアップを作成すると)、SCR ターゲットのデータベース ヘッダーが更新され、ログ ファイルが切り詰められます。
LCR および CCR と同様に、SCR のログ配布も連続的であり、プル モデルを使用します。新しいログ ファイルが閉じられ、次の世代シーケンス番号を使用して名前が付けられたら、SCR ターゲット コンピュータ上で実行されている Microsoft Exchange Replication Service は、閉じられたトランザクション ログ ファイルを SCR ソース コンピュータからプルします。その後、それらのファイルを検査および検証し、SCR ターゲット コンピュータ上にある、対応するストレージ グループ ログ ファイル フォルダに移動します。

再生待ち時間
ログ ファイルを SCR ターゲット コンピュータにコピーした後、SCR は LCR と CCR では実行されない処理を実行します。SCR は、ログ ファイルをすぐにデータベースのコピーに再生するのではなく、50 個のログ ファイルと 24 時間という組み込みの再生待ち時間を適用します。また、SCR では、これらの組み込みのものよりもさらに長い待ち時間を指定することもできます。再生操作が実行されるまでに待ち時間があることは、さまざまなシナリオで役立ちます。たとえば、アクティブなデータベースが論理的に破損した場合、待ち時間があることによって、SCR ターゲット データベースの論理的な破損を防ぐことができる可能性があります。
再生待ち時間は、管理者が ReplayLagTime というパラメータを使用して制御します。このパラメータには、Exchange レプリケーション サービスが SCR ターゲット コンピュータにコピーされたログ ファイルを再生するまでの待ち時間を指定します。値の形式は "日.時:分:秒" で、既定値は 24 時間です。指定可能な最大値は 7 日です。また、指定可能な最小値は 0 秒です。この値に 0 秒を指定した場合、50 個のログ ファイルという既定の待ち時間の後に、それ以上待ち時間が発生しないことになります。
ReplayLagTime だけでなく、Exchange には 50 個のログ ファイルという組み込みのハードコーディングされた待ち時間が (ReplayLagTime の値にかかわらず) あります。Exchange は、ログ ファイルを再生するタイミングを決定する際、ReplayLagTime と x 個のログ ファイル (x は 50) のうち長い方の時間を使用します。この動作により、連続レプリケーションを使用する SCR ソース (CCR 環境のクラスタ化されたメールボックス サーバーなど) でフェールオーバーが発生し、Restore-StorageGroupCopy コマンドレットを使用して 1 つ以上のストレージ グループをオンラインにする必要が生じたときに、ストレージ グループの再シードを実行する必要性がさらに低下します (シードとは、Extensible Storage Engine (ESE) ストリーミング バックアップ API を使用して、SCR ソース データベースのオンライン コピーを SCR ターゲット コンピュータ上に作成する処理です)。SCR ターゲット上で再生操作を実行するまでに待ち時間があることによって、SCR ソースで損失を伴うフェールオーバーが発生したときに、SCR のコピーの再シードを実行する必要性を最小限に抑えることができます。これは、SCR ソースでデータの損失が発生しても、しばらくすると 2 つのコピーが同じ状態に戻るためです。

切り詰め待ち時間
Exchange 2007 の RTM 版を使用した連続レプリケーション環境では、ログ ファイルがバックアップされ、データベースのコピーに再生されるまで、そのログ ファイルを削除しないというルールが適用されます。SCR を使用した場合、異なるルールが適用されます。(複数のデータベースのコピーという概念を導入している) SCR では、SCR ソース コンピュータ上のログ ファイルがすべての SCR ターゲット コンピュータによって検査されたら、それらのログ ファイルを切り詰めることができます。SCR ソース サーバーでは、すべての SCR ターゲットにすべてのログが再生されていない場合でも、それ以上待機せずにログの切り詰めを実行します。これは、SCR ターゲットのコピーに構成されているログの再生の待ち時間が非常に長い可能性があるためです。
また、TruncationLagTime という新しいパラメータを使用すると、ログを切り詰めるまでの待ち時間をさらに長く設定することができます。このパラメータには、SCR ターゲット コンピュータにコピーされ、データベースのコピーに再生されたログ ファイルを切り詰めるまでの Exchange レプリケーション サービスの待ち時間 ("日.時:分:秒" 形式) を指定します。この待ち時間のカウントは、ログ ファイルがデータベースのコピーに正しく再生された直後に開始されます。指定可能な最大値は 7 日です。また、指定可能な最小値は 0 秒です。0 秒を指定した場合、待ち時間なしでログ ファイルが切り詰められることになります。
SCR 環境では、3 分ごとにバックグラウンド スレッドが実行され、切り詰める必要があるログ ファイルがあるかどうかが確認されます。ログ ファイルの世代シーケンスがストレージ グループのログ ファイルのチェックポイントよりも小さく、ログ ファイルが ReplayLagTime と TruncationLagTime を加算した時間よりも古い場合、SCR ターゲット上のログ ファイルは切り詰められます。
SCR によって拡張された LCR または CCR 環境では、4 つの条件が満たされたときに、SCR ターゲット上のログ ファイルが切り詰められます。これらの条件とは、ログ ファイルがバックアップされていること、ログ ファイルの世代シーケンスがストレージ グループのログ ファイルのチェックポイントよりも小さいこと、ストレージ グループのパッシブ コピーがログ ファイルの切り詰めが可能な状態になっていること、およびすべての SCR ターゲットによってログ ファイルが検査されていることです。

SCR を有効にして管理する
SCR を有効にするには、Exchange 管理シェルで Enable-StorageGroupCopy コマンドレットを使用します。SP1 では、Exchange 管理シェルにいくつかのパラメータが追加されています。既に説明したように、ReplayLagTime と TruncationLagTime を使用すると、SCR ターゲットの一部の動作を制御できます。もう 1 つ、SeedingPostponed パラメータを使用すると、SCR ターゲットの初期シードを省略できます。シードを延期することは、さまざまな状況で役立ちます。たとえば、SCR を有効にするストレージ グループ内のデータベースのサイズが 100 GB であるとします。運用サーバーの稼働率が高いときには、100 GB ものデータをネットワーク上に送信したくないと思います。SeedingPostponed パラメータを使用すると、SCR をすぐに有効にして、シード タスクを後で実行することができます。シードを実行しても問題ない時間になったら、Update-StorageGroupCopy コマンドレットを使用して、手動で SCR ターゲットのシードを実行できます。
SCR の場合、上記で説明したパラメータは Enable-StorageGroupCopy に指定しなくてもかまいませんが、StandbyMachine は必ず指定する必要があります。StandbyMachine には、SCR ターゲットとして構成するコンピュータの名前を指定します。このパラメータの値は、SCR を有効にするストレージ グループの msExchStandbyCopyMachines 属性の値の一部として設定されます。msExchStandbyCopyMachines 属性は、複数の値を持つ Unicode 文字列で、Exchange 組織に Exchange 2007 SP1 を導入したときに Active Directory スキーマに追加されます。SP1 で Active Directory スキーマの更新が必要になるのはこのためです。
StandbyMachine は SCR で中心的な役割を果たすパラメータです。また、SP1 では、このパラメータを使用して SCR ターゲットを有効にしたり管理したりできるように、いくつかのコマンドレットが更新されています。図 6 には、更新されたコマンドレットの説明が記載されています。
Figure 6 StandbyMachine パラメータを使用するコマンドレット (Close Figure 6)

コマンドレット | 説明
Disable-StorageGroupCopy | ストレージ グループの SCR ターゲットを無効にします。
Get-StorageGroupCopyStatus | SCR ターゲットの現在の状態を確認します。
New-StorageGroup | SCR が有効になった新しいストレージ グループを作成します。Enable-StorageGroupCopy コマンドレットを使用して別途 SCR を有効にする必要はありません。
Restore-StorageGroupCopy | SCR を無効にし、SCR ターゲット データベースを回復処理の一環として実行される Mount-Database 操作でマウントできる状態にします。
Resume-StorageGroupCopy | SCR が中断されたストレージ グループの連続レプリケーションを再開します。
Suspend-StorageGroupCopy | SCR が有効になっているストレージ グループの連続レプリケーション操作を中断します。
Update-StorageGroupCopy | SCR ターゲット ストレージ グループのシードまたは再シードを実行します。

SCR ターゲットをアクティブにする
SCR では、元のデータが失われたり使用できなくなった場合に使用できる、データの最新のコピーが 1 つ以上提供されます。SCR ターゲットのコピーを運用データベースとして再準備する処理をアクティブ化といいます。アクティブ化は、データベースの移植性や、2 つの Setup 回復オプション (スタンドアロン サーバー用の /m:RecoverServer とクラスタ化されたメールボックス サーバー用の /RecoverCMS) のいずれかなどの回復処理の一環として実行されます。

SCR の使用例
ここでは、SCR とデータベースの移植性を使用して、どのようにメールボックス データベースの障害から回復するかについて、架空の企業を例に説明します。管理者は、運用データベースが破損していることがわかったら、データベースの移植性を使用して SCR ターゲット データベースをアクティブにします。
この組織では、Exchange 2007 SP1 を展開しており、SCR を使用してストレージ グループのコピーをリモート メールボックス サーバー上に作成することにしました。ソース メールボックス サーバーとターゲット メールボックス サーバーは同じ Active Directory サイト内にあり、Active Directory に統合された DNS サーバーを使用するように構成されています。また、Active Directory のレプリケーションの間隔は 15 分に構成されています。

SCR を有効にして回復のステージングを行う
SCR は、1 つのデータベース MBX1 を含む 1 つのストレージ グループ SG1 のトランザクション ログ ファイルをレプリケートするように構成されています。ストレージ グループ ファイルとデータベース ファイルのパスは、C:\SG1 と C:\SG1\MBX1.EDB です。この例では、EXMBX1 が SCR ソース、EXMBX2 が SCR ターゲットです。この構成は、次のコマンドレットを使用して行いました。
Enable-StorageGroupCopy EXMBX1\SG1 -StandbyMachine EXMBX2
SCR を有効にした後、次のように Get-StorageGroupCopyStatus コマンドレットを使用して、SG1 の SCR の状態を確認しました。
Get-StorageGroupCopyStatus EXMBX1\SG1 -StandbyMachine EXMBX2
SCR ターゲットのアクティブ化処理にかかる時間を短縮するために、ストレージ グループ SG1PORT とデータベース MBX1PORT を使用して、EXMBX2 をあらかじめ構成します。このストレージ グループとデータベースは、後で実行されるデータベースの移植操作の一環として使用されます。SG1PORT と MBX1PORT は、SCR ターゲットのストレージ グループとデータベース ファイルとは異なります。このため、SG1PORT と MBX1PORT のパスは、SCR ターゲットのパスと競合しない一時的なパスを使用して構成されます。SG1PORT と MBX1PORT は、データベースの移植性オブジェクトとしてのみ使用されます。SG1PORT の実際のストレージ グループとデータベース ファイルは必要ありません。このため、管理者は MBX1PORT のマウントを解除し、ストレージ グループ内のすべてのファイルを削除します。このストレージ グループ オブジェクトとデータベース オブジェクトは、後で実行される回復処理でデータベースの移植に使用されるため、Active Directory 内に残ります。

アクティブ化と回復
アプリケーション イベント ログのエントリに、SCR ソース データベースが物理的に破損していることが記録されています。SCR は SG1 で有効になっているため、SG1 の SCR ターゲット データベースを手動でアクティブにし、データベースの移植性を使用してデータの可用性を回復させることにします。SCR ターゲットのコピーをアクティブにするには、まず次のコマンド レットを使用して、SG1 の MBX1 のマウントを解除します。
Dismount-Database EXMBX1\SG1\MBX1
これにより、SCR ターゲット データベースがマウント可能な状態になり、MBX1 にあったメールボックスが MBX1PORT に移動します。
SCR を無効にし、SCR ターゲット データベースをマウント可能な状態にするには、Restore-StorageGroupCopy コマンドレットも実行する必要があります。このタスクを実行すると、ストレージ グループのデータベースがマウント可能なデータベースとしてマークされます。また、そのストレージ グループのデータベースをマウントしたことによってデータが失われた場合、そのことに関するレポートが提供されます。さらに、ストレージ グループのアクティブ コピーによって生成されたすべてのログ ファイルが、パッシブ コピーのストレージ グループ ファイルと同じ場所にあるかどうかも確認されます。見つからないログ ファイルがある場合は、それらのコピーを試行します。SCR ターゲット データベースをマウント可能な状態にするには、次のコマンドレットを使用します。
Restore-StorageGroupCopy EXMBX1\SG1 -StandbyMachine EXMBX2
この例では、SCR ソース ストレージ グループからログ ファイルをコピーできます。これらのファイルをコピーできない場合 (SCR ソース コンピュータがダウンしている場合など) は、Restore-StorageGroupCopy タスクに Force パラメータを追加する必要があります。追加しなかった場合、Restore-StorageGroupCopy は常に SCR ソースに接続して、見つからないログ ファイルをコピーしようとします。SCR ソースが利用できない場合、Restore-StorageGroupCopy タスクは失敗するため、データベースをマウントできる状態にはなりません。Force パラメータを追加すると、ソース ファイルが利用できないことを Restore-StorageGroupCopy タスクが認識してソース ファイルへの接続を省略し、SCR ターゲット データベースをマウント可能な状態にします。
管理者は、Restore-StorageGroupCopy コマンドが完了した後、データベースがクリーン シャットダウン状態であるかどうかを確認する必要があります。データベースがダーティ シャットダウン状態 (technet.microsoft.com/aa996757.aspx を参照してください) である場合は、クリーン シャットダウン状態にする必要があります。データベースの移植 (EXMBX2\SG1PORT) に使用されるストレージ グループのログ ファイル プレフィックス (E00 や E01 など) が、SCR ソース (EXMBX1\SG1) と、SCR ターゲット上のストレージ グループ (SG1PORT) との間で等しい場合、Eseutil を回復モードで実行する必要はありません。レプリケートされたすべてのログ ファイルが再生された後に実行される最後のデータベース マウント操作によって、データベースはクリーン シャットダウン状態になります。データベースがクリーン シャットダウン状態になっていない場合は、データベースに対して Exchange Server データベース ユーティリティ (Eseutil) を回復モード (Eseutil /r) で実行する必要があります。
データベースがクリーン シャットダウン状態になったら、次の 2 つのコマンドを実行して、Active Directory に登録されているストレージ グループ ファイルとデータベース ファイルの場所を更新できます。これらのコマンドによって、SG1PORT と MBX1 のパスが元のパスからステージング ストレージ グループとステージング データベース (SG1PORT と MBX1PORT) のパスに変更されます。
Move-StorageGroupPath EXMBX2\SG1PORT -SystemFolderPath C:\SG1 -LogFolderPath C:\SG1 –ConfigurationOnly

Move-DatabasePath EXMBX2\SG1PORT\MBX1PORT -EdbFilePath C:\SG1\MBX1PORT.EDB –ConfigurationOnly
上記のコマンドには、これらのオブジェクトの構成設定のみが Active Directory で更新されるように、–ConfigurationOnly パラメータを指定する必要があります。移動されるデータやファイルはなく、その必要もありません。データは既に SCR によって EXMBX2 の C:\SG1 にレプリケートされています。
次は、データベース (MBX1PORT) を復元操作時に上書きできるように構成します。これを行うには、Exchange 管理コンソールでデータベース オブジェクトのプロパティの [復元時はこのデータベースを上書きする] チェック ボックスをオンにするか、Exchange 管理シェルで次のコマンドを実行します。
Set-MailboxDatabase EXMBX2\SG1PORT\MBX1PORT -AllowFileRestore:$true
データベースを上書きできるように構成したら、次のコマンドを実行してデータベースをマウントします。
Mount-Database EXMBX2\SG1PORT\MBX1PORT
データベースをマウントしたら、SCR ソース データベース (SG1\MBX1) 上にあるメールボックスを EXMBX2 の MBX1PORT に移動する必要があります。これを行うには、Get-Mailbox コマンドレットを実行し、出力を Move-Mailbox コマンドレットに渡すだけです。この処理では、Move-Mailbox コマンドレットに渡される Get-Mailbox コマンドレットの出力に Exchange System Attendant とシステム メールボックスが含まれないことに注意する必要があります。これらのメールボックスを移動する必要はなく、移動するべきでもありません。システム メールボックスを除くすべてのユーザー メールボックスを移動するには、次のコマンドを実行します。
Get-Mailbox -Database EXMBX1\SG1\MBX1 |where {$_.ObjectClass -NotMatch '(SystemAttendantMailbox| ExOleDbSystemMailbox)'}| Move-Mailbox -ConfigurationOnly -TargetDatabase EXMBX2\SG1PORT\MBX1PORT
これで、クライアントが MBX1PORT にアクセスできるようになりました。ただし、ユーザー メールボックスが EXMBX1\SG1\MBX1 から EXMBX2\SG1PORT\MBX1PORT に移動された後に、ユーザーが各自のメールボックスにアクセスできるかどうかは、Active Directory のレプリケーションの待ち時間によって決まります。つまり、ディレクトリ サーバーの数によっては、環境全体に変更が反映されるまでに時間がかかる場合があるということです。また、クライアントのアクセス方法も重要です。Outlook 2007 を実行しているメッセージング クライアントと Outlook 以外を実行しているクライアントは、ユーザーのクライアント アクセス サーバーによって使用されるディレクトリ サーバーのパスが新しいものに更新されたら、各ユーザー メールボックスにアクセスできるようになります。Outlook 2003 またはそれ以前のバージョンを実行しているメッセージング クライアントは、ユーザーのデスクトップのメッセージング プロファイルに指定されているサーバー名を新しいものに更新する必要があります。

最後の手順
クライアントが各自のメールボックスとメールボックス内のデータにアクセスできるようになったら、最後に SCR を再有効化して冗長性を確保します。これを行うには、EXMBX1 に残っているストレージ グループとデータベース ファイルをすべて削除します。これらのファイルを削除したら、EXMBX1\SG1\MBX1 のパスを一時的な場所に移動し、EXMBX1 を EXMBX2 の SCR ターゲットにすることができます。

Scott Schnoll は、マイクロソフトの Exchange Server チームで、プリンシパル テクニカル ライターとして Exchange Server 2007 向けのコンテンツを執筆しています。マイクロソフトに勤務する前、彼は『Exchange Server 2003 Distilled』(Addison-Wesley Professional、2004 年) を執筆しました。また、『Exchange 2000 Server: The Complete Reference』(McGraw-Hill/OsborneMedia、2001 年) の主執筆者も務めました。


 通信: Windows Server 2008 で Exchange Server を実行する
通信 Paul Bowden

Windows Server 2008 で Exchange Server を実行する
概要:
  • Windows Server 2008 で Exchange Server をセットアップする
  • 構成のヒントとテクニック
  • Exchange Server の環境を把握する

マイクロソフトの Exchange Server 開発チームでの私の仕事は、チームのスケジュール、リズム、優先事項を設定することです。マイクロソフト社内では、私の役職はリリース マネージャと呼ばれるものですが、他社ではだいたいテクニカル プロジェクト マネージャと呼ばれます。この役職に就いたことがある人はご存知だと思いますが、
すぐれた製品を予定どおりに出荷するには、知識、スキル、多大な労力と、チームへの敬意が必要です。このように賢く才能あふれるチームで作業をする場合、チームの信頼は一晩で得られるものではなく、勝ち取る必要があります。
そのやる気を証明する 1 つの方法は、"ドッグフード" サーバー (Exchange Server のプレリリース版を実行する運用サーバー) でメールボックスを運用することです。これは流動的な環境で、2 ～ 3 週間ごとに Exchange Server の新しいビルドにアップグレードします。このような構成により、Exchange Server のプレリリース版を実際の人的操作を伴う実環境でテストできます。最新のテスト ビルドでもメールボックスを運用します。私自身も、実際に、この運用に参加しました。今月のコラムでは、そのときのことをご紹介します。

"Longhorn" について
2006 年の年末、ちょうど Exchange Server 2007 を出荷したとき、Windows Server® "Longhorn" という新しい OS のリリースが近づいていました。新しい Exchange Server プラットフォームの最初の Service Pack の計画をまとめ始めたとき、Exchange Server と Windows® のスケジュールが同じように設定されていて、"Longhorn" (現在は Windows Server 2008 と呼ばれる) の規模が大きくなるということが判明しました。その時点で、Exchange Server 2007 SP1 を Windows Server 2003 と Windows Server 2008 の両方に対応するように設計することを確定しました。複数のバージョンの Windows でエンタープライズ アプリケーションをサポートするには、膨大な量の調整と計画が必要です。たとえば、Exchange Server は IIS と密接に連動しますが、Windows Server 2008 では IIS 7.0 という新しいバージョンが導入されます。
2006 年 12 月下旬にラボで初めて Windows Server 2008 をインストールしたことを覚えています。その日、2 つのことが印象に残りました。1 つはインストールが非常に迅速だったこと、もう 1 つは、Windows Server 2003 とはまったく異なるにもかかわらず管理ツールを非常に直感的に使用できたことです。
私たちのメイン ラボでは、Windows Server 2008 を、Windows Server 2003 のインストールに必要な時間のおよそ 3 分の 1 の時間でインストールできました。インストールが迅速であることの理由の 1 つは、オペレーティング システムの実行に必須ではないオプション コンポーネントが既定で構成されていないためです。これは、コンピュータが攻撃を受ける確率を低減し、操作をできるだけ簡単にするという点で優れています。だれも不要なものは欲しくありません。このようなインストールの一般的な欠点は、新しいコンポーネントを追加するたびにディスクを挿入する必要があることです。しかし Windows Server 2008 では、すべてのファイルが SxS (サイド バイ サイド) フォルダにコピーされます。サーバー マネージャ ツールを使用して必要なコンポーネントを構成すると、オペレーティング システムによりコピーする必要のあるファイルが特定されます。
ここで、Server Core について説明しておきましょう。これは、必要最低限のオペレーティング システムをインストールする Windows Server 2008 のモードです。このモードでは、通常、コマンド プロンプトからサーバー コンソールを操作します。エクスプローラさえもインストールされません。このモードは、ドメイン コントローラや DNS サーバーなどのインフラストラクチャ サーバーに最適ですが、すべての種類のアプリケーションを実行できるわけではありません。Exchange Server ではマネージ コードが広範に使用されるので、Server Core インストールがサポートされません。

Exchange Server をセットアップする
私は、Windows Server 2008 と Exchange Server 2007 SP1 の物理メディアを使用して、それ以上のダウンロードや前提条件なしでコンピュータをゼロからインストールするのが好きです。Exchange Server 用に Windows Server 2008 のインストールを構成する最善の方法は、ServerManagerCmd ツールを使用することです。Exchange Server を Windows Server 2008 でインストールおよび実行するのに必要最低限のオペレーティング システム コンポーネントをインストールする、XML 応答ファイル (図 1 参照) を作成しました。新しいオペレーティング システムをインストールしたら、次のコマンドを実行してシステムをセットアップしました。
Figure 1 Exchange 用の ServerManagerCmd 応答ファイル (Close Figure 1)
<!-- Windows Server 2008 と互換性がある ServerManagerCmd 応答ファイル        --> <!-- 使用方法 : ServerManagerCmd -ip Exchange.xml                                -->

<ServerManagerConfiguration Action="Install" xmlns="http://schemas.microsoft.com/sdm/Windows/ServerManager/Configuration/2007/1">

    <!-- BASE: PowerShell 1.0 機能をインストールする --> <Feature Id="PowerShell"/>

    <!-- PREPARESCHEMA: LDIFDE および他のディレクトリ ツール (LDP、ADSIEdit など) をインストールする --> <Feature Id="RSAT-ADDS"/>

    <!-- CAS/MBX: Web サーバーの役割を他の子コンポーネントと共にインストールする --> <Role Id="Web-Server"/> <RoleService Id="Web-Metabase"/> <RoleService Id="Web-Lgcy-Mgmt-Console"/> <RoleService Id="Web-Basic-Auth"/> <RoleService Id="Web-Windows-Auth"/>

    <!-- CAS: OWA、GZip 形式の圧縮、および Outlook Anywhere サポートの 3 つの認証の種類をインストールする --> <RoleService Id="Web-ISAPI-Ext"/> <RoleService Id="Web-Digest-Auth"/> <RoleService Id="Web-Dyn-Compression"/> <Feature Id="RPC-over-HTTP-proxy"/>

    <!-- EDGE: Active Directory ライトウェイト ディレクトリ サービス (従来の ADAM) をインストールする --> <Role Id="ADLDS"/>

    <!-- UM: Windows Media Player コンポーネントをインストールする --> <Feature Id="Desktop-Experience"/>

</ServerManagerConfiguration>

ServerManagerCmd –ip Exchange.xml
このコマンドを実行してシステムを再起動すると、Exchange Server の役割 (メールボックス、クライアント アクセス、ハブ トランスポート、エッジ トランスポート、ユニファイド メッセージングなど) をインストールするのに必要なものがすべて揃います。
もう 1 つの役立つ技は、-query スイッチを指定して ServerManagerCmd を使用することです。このコマンドを実行すると、役割とサービスの完全な一覧が列挙され、どれが実際に構成されているかが表示されます (図 2 の緑色のテキスト部分が実際に構成されているものです)。
図 2 Exchange Server の役割とサービスを列挙する
図 2 Exchange Server の役割とサービスを列挙する
では、話を戻しましょう。2007 年の初めの数か月間、ラボでは、Windows Server 2008 での優れたパフォーマンスを実現するためにどのような変更が必要かを調べていました。ここから学んだことがあるとすれば、ラボでソフトウェアのインストールとストレス テストをとことん行うことができても、本来の品質は実際にユーザーが実運用展開で確認する必要があるということです。まさにこうした理由で、製品の "ドッグフード" (実際の日常的な作業での使用によるテスト) を行います。2007 年 4 月の Windows Server 2008 Beta 3 のリリースは、それを実行に移して運用環境で展開するというターニング ポイントでした。
私は、Exchange Server を初めて Windows Server 2008 に展開するとき、運用チームのメンバの作業を座って見ていました。Exchange Server のセットアップは順調に進み、サービスはすべて開始されました。後は、メールボックスを移動して、実際に機能するかどうかを確認する必要があるだけでした。ここで、私は、そのチェックを行う役を買って出ました。私のメールボックスのサイズは 2 GB でしたが、26 分後にはメールボックスが使用できるようになり、Windows Server 2008 で実行している Exchange Server で電子メールを送信しました。成功です。

得られた教訓
この Windows Server 2008 への最初のインストール以降、微調整を行い、実用に向けての準備の確認を重ねてきました。その途中、展開方法にかかわる重要な決定をいくつか行う必要がありました。
インストール Exchange Server 2007 SP1 は、Exchange Server 2007 RTM (製品版) と呼ばれるオリジナルの Exchange Server 2007 のインストールへのアップグレードとして使用するか、Exchange Server 2007 SP1 メディアを使用して新しいコンピュータに直接インストールできます。Exchange Server 2007 RTM は Windows Server 2008 を実行しているコンピュータにインストールできないため、これは重要です。
アップグレード オペレーティング システムを Windows Server 2003 SP2 から Windows Server 2008 にインプレース アップグレードできますが、その前にいくつかのコンポーネントをアンインストールする必要があります。その 1 つが、Windows PowerShell™ です。これは Exchange Server の管理の中核部分で、Exchange Server のセットアップも Windows PowerShell ベースです。このため、Exchange Server が既にインストールされている場合には、オペレーティング システムのインプレース アップグレードはサポートできません。つまり、一般的に多くの場合は、新しいコンピュータに Windows Server 2008 をインストールしてから Exchange Server 2007 SP1 をインストールする必要があります。
IPv6 Exchange Server は、Windows Server 2008 のいくつかの新しい機能を活用できるように設計されています。たとえば、IPv6 が既定でインストールされているので、Windows Server 2008 オペレーティング システムで実行している 2 つの Exchange Server 間での通信には、自動的に IPv6 が使用されます。Exchange 管理コンソールのインターフェイスでも、IPv6 アドレスの範囲を使用できますが、1 つ注意点があります。Exchange Server では、各ネットワーク インターフェイスに IPv4 アドレスがバインドされている必要があります。
読み取り専用ドメイン コントローラ Active Directory® 展開に関してはいくぶん大幅な変更が加えられ、読み取り専用ドメイン コントローラ (グローバル カタログ サーバー) という概念が導入されました。この概念により、企業では、一方向のレプリケーションを受信して変更がレプリケートされない Active Directory サーバーを展開できます。これは、ブランチ オフィスや遠隔地など、物理的なセキュリティが保証されない場所で役立つ場合があります。残念ながら、Exchange Server 2007 SP1 では、読み取り専用ドメイン コントローラは使用できず、Active Directory の通常の書き込み可能なパーティションへのアクセスが必要です。

Exchange Server の環境について
Exchange Server と Windows Server のリソース
  • Windows Server 2008 TechCenter
  • Exchange Server TechCenter
  • TechNet Evaluation Center
  • Windows Server 2008 バーチャル ラボ

展開するオペレーティング システム レベルを選択する際には、さまざまな構成を柔軟に実行できます (図 3 参照)。
Figure 3 Exchange Server 環境の表 (Close Figure 3)

Exchange Server のバージョン | サーバー オペレーティング システム | ドメイン コントローラ
Exchange Server 2007 SP1 | Windows Server 2008 | Windows Server 2008
Exchange Server 2007 SP1 | Windows Server 2008 | Windows Server 2003
Exchange Server 2007 SP1 | Windows Server 2003 SP2 | Windows Server 2008
Exchange Server 2007 SP1 | Windows Server 2003 SP2 | Windows Server 2003
もう 1 つの考慮事項は、複数のバージョンが混在する展開です。相互運用する Exchange Server と Windows のバージョンが混在する可能性があるのは確かです。たとえば、クライアント アクセス サーバー用に Exchange Server 2007 SP1 を Windows Server 2008 に展開し、これらのサーバーが Windows Server 2003 メールボックス サーバーに展開している Exchange Server 2007 RTM にアクセスするようにすることができます。
以前のバージョンの Exchange Server と Windows Server 2008 Active Directory を使用する場合、いくつかの注意点があります。Exchange Server 2003 SP2 以降を使用している場合は、Windows Server 2008 ドメイン コントローラを展開して使用できます。しかし、Exchange Server 2000 を展開している場合、それらの Exchange Server サーバーがある Active Directory サイトで Windows Server 2008 ドメイン コントローラの展開を留保するか、Exchange Server 2000 が Windows Server 2008 ドメイン コントローラを使用しないようにディレクトリ サービス アクセス (DSAccess) の設定をハードコードする必要があります。

まとめ
私たちは、Exchange Server 2007 SP1 が Windows Server 2003 と Windows Server 2008 の両プラットフォームで適切に機能するように多大な労力を注ぎました。Exchange Server では、展開の柔軟性と併用によるメリットを提供するように努めました。Exchange Server を Windows Server 2008 に簡単かつ非常にすばやく展開できることは、うれしい驚きとなるでしょう。また、Outlook Anywhere クライアントに対するクライアント アクセス サーバーのスケーラビリティの大幅な向上など、巧妙な内部的なパフォーマンスとスケーラビリティの強化も体感していただけるでしょう。
Windows Server 2008 は、メッセージング領域における今後の革新のためのプラットフォームを提供します。ご期待ください。

Paul Bowden は Exchange Server チームのリード プログラム マネージャです。彼は、自由な時間のほとんどを、要求に応じて PayPal アカウント情報を再確認することに費やしています。


 通信: Exchange Server 2007 を使用してユニファイド メッセージングを展開する
通信 Jeff Goodwin

Exchange Server 2007 を使用してユニファイド メッセージングを展開する
概要:
  • テレフォニーの基礎
  • ユニファイド メッセージングを設計する際の考慮事項
  • ユーザーの移行

Exchange Server 2007 ユニファイド メッセージングを環境に展開することに決めたとします。ユニファイド メッセージング サーバーの役割をインストールし、これを既存の PBX と統合して、現在ではあなたと他の 10 名の従業員のボイスメール、電子メール、および FAX メッセージが Exchange に格納されています。一瞬、
これで非常に大きな仕事をやり遂げたと思ったかもしれません。しかし、同じ機能を、複数のサイトに分散している数千人のサブスクライバに、業務に支障のない形で展開するにはどうしたらよいでしょうか。
そのような場合に、この記事がお役に立てればと思います。この記事は、ユニファイド メッセージングを環境に展開する方法と、このような展開に関係するテレフォニーの概念について、理解を深めていただくことを目的としています。Exchange Server 2007 ユニファイド メッセージングのインストール、構成、または機能については、この記事の最後にある「ユニファイド メッセージングの関連情報」を参照してください。また、マイクロソフトは、Exchange Server 2007 ユニファイド メッセージングに関するコンサルティング、設計、および展開のサポートを提供できる企業をユニファイド メッセージング スペシャリストとして認定しています。インストール、構成、または展開に関するサポートが必要な場合は、いずれかのスペシャリストに問い合わせてください。これらのスペシャリストについても、「ユニファイド メッセージングの関連情報」を参照してください。

はじめに
ユニファイド メッセージング テクノロジは Exchange にとって目新しいものではありません。さまざまな組織が、Exchange と統合できるユニファイド メッセージング製品を提供しています。ただし、Exchange でユニファイド メッセージングがネイティブにサポートされるのは、このバージョンが初めてです。Exchange Server 2007 ユニファイド メッセージングの登場以来、多くの顧客がこの機能を組織内の小規模のグループに展開しています。しかし、さまざまな理由から、すべてのユーザーにユニファイド メッセージングが展開されない場合があります。問題の 1 つは、多くの Exchange 管理者にとってテレフォニーの概念やユニファイド メッセージング サービスの実装に必要なテクノロジは未知のもので、これらのソリューションを設計し、自社に展開する作業にかなり苦労していることです。
どのような展開プロジェクトにも当てはまることですが、段階的なアプローチが通常は最良の結果を生みます。アーキテクチャの計画、ソリューションのテスト、ユーザー コミュニティでのパイロット運用、トレーニング、および新システムへのユーザーの移行という 5 段階が、ユニファイド メッセージング プロジェクトで考慮する必要があるすべての側面と言えます。このプロジェクトを計画する際は、組織の IT 部門と通信部門の両方が参加することが非常に重要です。
従来のボイスメール プラットフォームで当然のように利用されている機能の多くは、新システムでも実現するか、実現できない場合は、新システムの実装時にユーザー コミュニティへの影響を抑えられるような代替ソリューションを設計する必要があります。これは、通信チームの助けを必要とする主要な領域です。同時に、通信チームは、展開が行われてから、新しいボイスメール プラットフォームの管理、トラブルシューティング、およびサポートをどのように進めるかについて、IT チームから学ぶ必要があります。

テレフォニーの基礎
基本のアーキテクチャ、通話フロー、およびユニファイド メッセージング関連の用語を理解していると、かなり計画が楽になります。図 1 は、企業の既存のテレフォニー システムに統合されたユニファイド メッセージング ソリューションの一例を示しています。このような展開を行う際に利用する、いくつかの最も一般的な概念とテクノロジについて、詳しく見ていきましょう。
図 1 PBX とユニファイド メッセージングが統合されたソリューション
図 1 PBX とユニファイド メッセージングが統合されたソリューション
構内交換機 (PBX) は、企業内で使用される専用電話網です。このようなシステムでは、通常、各ユーザーには PBX に接続された机上電話が支給され、この電話機を使用して内線番号 (通常 4 桁または 5 桁の番号) をダイヤルすることで社内の他のユーザーに電話をかけたり、社外の番号に電話をかけたりすることができます。
さまざまな場所に PBX が配置されている場合は、PBX ベンダ固有のネットワーク テクノロジを利用してこれらのシステムが接続される場合があります。これによって、ネットワーク経由で接続された PBX を使用するすべてのユーザーが、内線番号をダイヤルするだけで電話をかけ合えるようになります。
ユニファイド メッセージングでは、2 つの異種システムを統合する必要があります。これらは、Exchange メッセージングと物理的なテレフォニー システムです。ユニファイド メッセージング サーバーとテレフォニー アーキテクチャとの間の通信は、セッション開始プロトコル (SIP) を使用して確立されます。PBX テクノロジの中には、SIP を介して直接ユニファイド メッセージング サーバーと通信できるものも、SIP ゲートウェイを必要とするものもあります。図 1 では、PBX は T1 回線を経由して SIP ゲートウェイに接続されています。通話がユニファイド メッセージングに転送されると、PBX は情報 (発信側の電話番号、受信側の電話番号、なんらかの理由コードなど) を SIP ゲートウェイに送信して、ユニファイド メッセージング サーバーがどのユーザー宛ての通話であるかを認識できるようにします。
PBX の中には、IP ネットワークを経由して接続できるものもあります。テレフォニー ネットワークを構築すると、一元管理を行うボイスメール ソリューションに IP ネットワーク経由で通話をリダイレクトできます。たとえば、図 2 では、チューリッヒとロンドンがネットワークで接続されています。
図 2 より複雑なユニファイド メッセージングの展開
図 2 より複雑なユニファイド メッセージングの展開

通話フロー
ユニファイド メッセージングの関連情報
  • ユニファイド メッセージング スペシャリストの一覧
  • Exchange ユニファイド メッセージング TechCenter
  • サポートされている SIP ゲートウェイ
  • テレフォニー アドバイザ
  • PBX の構成に関するメモ

社外からユニファイド メッセージングのサブスクライバ宛てに電話がかかってきたとします。ここでは、このユニファイド メッセージングのサブスクライバが外出していて、電話に出られないとします。図 1 で、このメッセージの経路をたどることができます。
PBX が通話を SIP ゲートウェイに送信し、SIP ゲートウェイは、SIP over TCP を経由してユニファイド メッセージング サーバーとこの通話に関するネゴシエーションを行います。サーバーは、どのユーザー宛ての電話であるかを示す統合データを SIP ゲートウェイから受信します。ユニファイド メッセージング サーバーは、サブスクライバの不在応答メッセージを再生し、社外の発信者がメッセージを録音できるようにします。この発信者のメッセージは、ユニファイド メッセージングのサブスクライバの Exchange メールボックスに配信されます。
この通話フローは、実際の処理をかなり簡略化したものです。理解する必要があるのは、メッセージが録音されると、ユニファイド メッセージング サーバーがそのメッセージを SMTP 経由でハブ トランスポート サーバーに転送して、メールボックス サーバーに配信されるようにするということです。
ユーザーは、ユニファイド メッセージングのサブスクライバとして、電話 (Outlook® Voice Access を使用) またはコンピュータ (Outlook 2007 または Outlook Web Access を使用) から各自の Exchange メールボックスにアクセスできます。ただし、サブスクライバは電話での再生と呼ばれる新機能を使用すると、電話から Outlook 2007 や Outlook Web Access を使用してメッセージにアクセスできます。この機能は、サブスクライバがコンピュータからメッセージにアクセスするのではなく、指定された電話番号に電話をかけることで、選択したメッセージをユニファイド メッセージングによって再生できる機能です。この方法を使用した場合、ユニファイド メッセージング サーバーはクライアント アクセス サーバーとメールボックス サーバーの両方と通信します。これを理解しておくことは重要です。クライアント アクセス サーバーがローカルに配置されていないリモート オフィスにユニファイド メッセージング サーバーを配置する場合、このユニファイド メッセージング サーバーは、WAN を経由してクライアント アクセス サーバーにアクセスする必要があるため、パフォーマンスが低下する可能性があります。

システムの設計
Exchange のアーキテクチャの設計は、大きく 2 つに分類できます。これらは、集中型と分散型です。一般に、ユニファイド メッセージングのアーキテクチャは、Exchange のアーキテクチャに従っています。つまり、メールボックス サーバーが展開される場所には、ユニファイド メッセージング サーバーも展開されます。もちろん、どんな規則にも例外はあります。
ユニファイド メッセージングのアーキテクチャを設計する際は、5 つの基本的な領域について考慮する必要があります。
  • サーバーの配置場所
  • ユニファイド メッセージング サーバーの数
  • SIP ゲートウェイ
  • メールボックスのストレージ
  • ユニファイド メッセージング サイトの構成
また、ビジネスの継続性についても注意してください。一般に、Exchange に関連する障害回復計画を使用して、ユニファイド メッセージングに関連する要素を特定できます。
サンプルの展開シナリオを使用すると、ユニファイド メッセージング サーバーの役割を理解しやすくなるでしょう。図 2 は、ユニファイド メッセージングを実装した Exchange Server 2007 を大規模な企業に展開した場合の状態をわかりやすく表しています。
より複雑なこの設計では、シアトルとロンドンにプライマリ データセンターがあります。この 2 つの拠点には、メールボックス サーバーとハブ トランスポート サーバーがローカルに配置されているため、ユニファイド メッセージング サーバーがそれぞれのユーザー コミュニティにサービスを提供しています。どちらのサイトにも、通話応答を提供する目的で、ローカルのユニファイド メッセージング サーバーにコール カバレッジを提供する IP PBX が配置されています。
中規模のサイトは、ニューヨークとグラスゴーにあります。この 2 つの拠点には、メールボックス サーバーとハブ トランスポート サーバーがローカルに配置されているため、ユニファイド メッセージング サーバーがそれぞれのユーザー コミュニティにサービスを提供しています。プライマリ データセンターと同様に、どちらのサイトにも、通話応答を提供する目的で、ローカルのユニファイド メッセージング サーバーにコール カバレッジを提供する IP PBX が配置されています。
小規模なサイトには、メールボックス サーバーもハブ トランスポート サーバーもローカルに配置されていませんが、プライマリ データセンターのユニファイド メッセージング機能を利用できるようにしています。オースティンには、アナログ接続を使用してローカルの SIP ゲートウェイに接続する NEC PBX が配置されています。ローカルのエンド ユーザーへの通話はこの SIP ゲートウェイに転送され、SIP ゲートウェイがシアトルのユニファイド メッセージング サーバーとネゴシエートし、ユニファイド メッセージングの通話応答を提供します。
チューリッヒでは Avaya Communication Manager が使用されており、IP ネットワークを経由してロンドンの Avaya Communication Manager に接続されています。ローカルのエンド ユーザーへの通話はこの Avaya Communication Manager ネットワークを経由して転送され、Avaya Communication Manager がロンドンのユニファイド メッセージング サーバーとネゴシエートし、ユニファイド メッセージングの通話応答を提供します。
この例のシアトル サイトでは、物理的に同じ場所に、Exchange メールボックス サーバーとユニファイド メッセージング サーバーが配置されています。シングル サイト アーキテクチャを実装する場合は、すべてのサーバー (メールボックス、ユニファイド メッセージング、クライアント アクセスなど) と PBX 機器を同じサイト内に配置します。複数のサイトを所有している企業では、設計がより複雑になります。この複雑さは手に負えないもののように思えるかもしれませんが、ユニファイド メッセージングの基本原理を適切に理解しておけば対応できます。
図 2 に示されているように、サイトにメールボックス サーバーが配置されている場合は、ユニファイド メッセージング サーバーもこのサイトに配置することをお勧めします。シアトル、ロンドン、ニューヨーク、グラスゴーは、どれもこの設計が適しています。オースティンやチューリッヒにはメールボックス サーバーがローカルに配置されていませんが、IP ネットワークを使用することで、ユニファイド メッセージング サービスを提供できます。オースティンにはアナログ PBX がローカルに配置されています。この場合、SIP ゲートウェイを使用して、シアトルのユニファイド メッセージング サーバーへの IP ネットワーク接続を提供する必要があります。チューリッヒには IP PBX がローカルに配置されており、ネットワーク経由でロンドンの PBX に接続されています。したがって、チューリッヒのユーザーへの通話は、テレフォニー ネットワークを経由して、ロンドンの PBX とユニファイド メッセージング サーバーに転送されます。
チューリッヒのサブスクライバ宛ての通話は、ネットワーク経由で転送され、ロンドンにある集中管理用のユニファイド メッセージング システムによって処理されます。ネットワーク障害が発生した場合は、ネットワークが修復されるまでチューリッヒのすべてのサブスクライバへの通話に応答することができません。ネットワーク障害が発生した場合にもローカルでサービスを提供し続ける必要がある場合は、ユニファイド メッセージング サーバーをチューリッヒに配置します。ネットワーク障害が発生した場合、ユニファイド メッセージング サーバーが引き続き通話に応答し、ネットワークが修復された時点で通話を配信します。
各環境に適したアーキテクチャを設計する際に、考慮すべき最も重要な要素は、おそらくサーバーの配置でしょう。図 3 のフローチャートは、適切なサーバーの配置を決定する際に役立ちます。
図 3 サーバーの配置を決定する
図 3 サーバーの配置を決定する

サーバーの要件を見積もる
次に考慮すべき領域は、ユーザー コミュニティをサポートするために必要なユニファイド メッセージング サーバーの数です。この数は、サイト固有のいくつかの要因によって決まります。
ユニファイド メッセージングのスケーラビリティは、サーバーがサポートできる同時通話 (テレフォニーの世界では "通話ポート") の数によって決まります。システムへの各通話は、ネットワーク、CPU、メモリ、およびディスク リソースを提供する専用のユニファイド メッセージング サーバーを必要とします。これらのリソースを追加することで、ユニファイド メッセージング サーバーが、より多くの同時通話をサポートできるようになります。これらのリソースは常に限られているため、ユニファイド メッセージング サーバーが一度に処理できる同時通話の数は、リソースが過負荷にならない範囲に制限されます。
ここでは詳しく説明しませんが、Erlang トラフィック分析計算を使用すると、サブスクライバの人数をサポートするために必要なポート数を特定できます。より簡単な方法は、既存のボイスメール システムで使用されているボイスメール ポートの数をテレフォニー管理者に尋ねることです。現場での経験から言うと、従来のボイスメール システムのポート要件とユニファイド ボイスメール システムのポート要件は、非常に似ています。
私は、基本的に 1 台のサーバーに 60 個を超えるポートは実装しないことを推奨しています。これは、ソフトウェアやハードウェアの制限とは関係ありません。この根拠は、ポートが 60 個あるサーバーでは、約 5,000 人のユーザーをサポートできるという事実です。このサーバーで障害が発生した場合、たった 1 台のサーバーの障害によって、(非常に大規模な) サブスクライバ ベース全体に影響を与えることになります。
ユニファイド メッセージング サーバーを実装するときは、N+1 の冗長性が確保されるようにアーキテクチャを設計するとよいでしょう。図 4 は、完全に冗長なサーバーと SIP ゲートウェイの設計を示しています。この設計を使用すると、ユニファイド メッセージング サーバー 1 で障害が発生した場合、SIP ゲートウェイ 1 からの通話は、自動的にユニファイド メッセージング サーバー 2 と通話をネゴシエートします。また、SIP ゲートウェイ間で均等に通話の負荷が分散されるように、PBX のプログラムを作成することもできます。たとえば、最初にシステムに着信した通話は、SIP ゲートウェイ 1 にルーティングされ、次にシステムに着信した通話は SIP ゲートウェイ 2 にルーティングされるようにすることができます。通話を複数のゲートウェイに交互にルーティングすることで、ユニファイド メッセージング サーバー間で通話が均等に分散され、負荷が共有されます。
図 4 サーバー間で通話を分散し、冗長性を確保する
図 4 サーバー間で通話を分散し、冗長性を確保する
Exchange Server 2007 ユニファイド メッセージング ソリューションでサポートされている SIP ゲートウェイ プロバイダは、現在 2 社あります。これらは、AudioCodes と Dialogic です。設計に SIP ゲートウェイを組み込む必要がある場合は、その設計に必要なセッション (ポート) の数がサポートされているものを購入してください。たとえば、設計で 32 個のポートが必要とされている場合は、少なくとも 32 セッションがサポートされているゲートウェイが必要です。
使用している PBX をユニファイド メッセージングに使用できるかどうかや、どのゲートウェイを使用すべきかについては、「ユニファイド メッセージングの関連情報」を参照してください。このセクションには、マイクロソフトから提供されている特定のガイダンスや、各組織の特定の要件を評価する際に役立つユニファイド メッセージング スペシャリストの一覧へのリンクが記載されています。私個人の経験から言えば、SIP ゲートウェイおよび Exchange ユニファイド メッセージングと連携させることができない PBX はそれほど多くありません。また、一部の PBX は SIP over TCP を使用してネイティブにユニファイド メッセージング サーバーと通信できます。
Exchange ユニファイド メッセージングでは、ボイスメール メッセージの保存用に 3 種類のオーディオ コーデックがサポートされています。これらは、G.711 PCM Linear、GSM 06.10、および Windows Media® Audio (WMA) です。PCM Linear WAV ファイルのサイズは、オーディオ 1 秒間あたり約 16 KB です。WMA は、ユニファイド メッセージングの既定のオーディオ コーデックです。WMA では、オーディオが 1 秒間あたり 1.1 キロビット (kb) に圧縮され、7 KB のヘッダーが付けられます。GSM 06.10 では、オーディオが 1 秒間あたり1.6 kb に圧縮されますが、ヘッダーのサイズは WMA エンコードよりも小さくなります。
WMA も GSM 06.10 エンコードも、ボイス メッセージングの品質としては合格です。WMA または GSM コーデックを使用した現場での経験から言うと、組織でどの程度ボイスメールが使用されているかによりますが、メールボックス ストアのサイズが 10 ～ 20% 増加することが予想されます。
環境で使用するオーディオ コーデックを決める際は、エンド ユーザーのモバイル デバイスやその他のオペレーティング システムを考慮してください。このトピックに関するほとんどの問題は、ユーザーが所有している Windows Mobile® デバイスでボイスメールを使用できるかどうかに関係しています。その他のオペレーティング システムも考慮する必要があります。おそらく、WMA ファイルを再生できない可能性がある Linux コンピュータが多数展開されていると思います。状況はさまざまだと思いますが、これらの要因が存在する場合、該当するユーザーのトレーニングに必要なヘルプ デスクのリソースは増加します。

構成とテスト
ユニファイド メッセージング アーキテクチャが集中型であるか分散型であるかにかかわらず、ユニファイド メッセージングを組織に展開する前に考慮する必要があるボイスメールの要件は多数あります。プロジェクト チームで話し合う必要があるトピックの詳細な一覧については、「ユニファイド メッセージングのチェックリスト」を参照してください。ユニファイド メッセージングの実装を考えているサイトごとに、すべてのトピックの情報を収集してください。これらのトピックについて話し合う際は、IT チームと通信チームの両方が協力する必要があることを忘れないでください。
システムを設計し、構成を完了したら、テスト システムを運用して設計を検証します。複数のサイトを使用する設計の場合、少なくとも 2 つのサイトをテストして、概念を実証し、設計が正しく機能するかどうかを検証します。
構成要件を基に機能テストの計画を作成した後、テストを実施します。機能テストの計画には、サブスクライバのアクセス方法 (電話、Outlook 2007、および Outlook Web Access)、管理方法、およびハードウェア障害とネットワーク障害を含める必要があります。
テストが完了し、ユニファイド メッセージングが従来のボイスメール システムの機能を再現していること、または再現できない構成や機能をサポートする代替ソリューションが設計されていることを全員が認めた段階で、ユーザーのパイロット グループを選抜して、システムをテストします。パイロット グループを用意することで、従来のボイスメール システムからユニファイド メッセージングにサブスクライバを移行 (テレフォニー用語では "カットオーバー") するために、各環境で必要になる手順を実際に確認できます。一般に、サブスクライバのカットオーバーに必要な手順は次のとおりです。
  1. 既存のボイスメール システムのサブスクライバを無効にします。
  2. Exchange 管理コンソールを使用して、Active Directory でこのサブスクライバのユニファイド メッセージングを有効にします。
  3. 電話のカバレッジ パスをユニファイド メッセージングのパイロット番号に変更します。
既存のボイスメール システムのサブスクライバを無効にして、古いメールボックスにメッセージが送信されないようにすることが重要です。
パイロット フェーズ中に、システムの機能に関する疑問点をサブスクライバから収集します。これらの詳細を記録することで、トレーニング フェーズ中によく発生する問題に対処できます。
カットオーバーを成功させるためには、トレーニングが非常に重要です。ユーザーは、電話から特定のユーザー インターフェイスを使用してボイスメールにアクセスすることに慣れています。たとえば、あるボイスメール システムでは、5 を押すとメッセージを聞くことができます。Exchange ユニファイド メッセージングでは、1 を押すか "ボイスメール" と言う (または Outlook 2007 か Outlook Web Access を使用して音声メッセージを再生する) 必要があります。ユニファイド メッセージングのサブスクライバ向けのトレーニングでは、テレフォニー ユーザー インターフェイス、Outlook Voice Access、および Outlook または Outlook Web Access の操作をすべて説明するようにします。
Exchange 2007 ユニファイド メッセージングでは、口頭で操作を指示できる機能が Outlook Voice Access に組み込まれます。ユーザーの中にはシステムの新機能をとても気に入り、そのことが別のユーザー インターフェイスへの移行を後押しすることがあります。
Exchange ユニファイド メッセージングでは、あるユーザーを有効にしたときに、そのユーザーにカスタムのテキスト電子メール メッセージを送信する機能が提供されます。このカスタム メッセージを使用して、よく寄せられる質問 (FAQ)、サブスクライバ向けのドキュメント、ヘルプ デスクの電話番号など、役立つ Web リンクを提供することができます。また、ボイスメール システムへのアクセス方法や、サブスクライバ固有のパスワードといった情報を提供することもできます。これは、エンド ユーザーを有効にする際に利用できる、最も強力な機能の 1 つです。

ユーザーを移行する
ユニファイド メッセージングのチェックリスト
ここでは、ユニファイド メッセージング システムのいくつかの基本要素と、Exchange Server 2007 ユニファイド メッセージングの展開と構成に備えて決定する必要がある項目を示します。展開計画を作成する際のチェックリストとして使用してください。
ダイヤル プラン ユニファイド メッセージングのダイヤル プランは、PBX および関連付けられている内線番号に論理的に対応しています。ダイヤル プランについて、あらかじめ検討する必要がある項目を次に示します。
  • 内線番号は何桁にするか。
  • ユニファイド メッセージング システムのパイロット番号は何番にするか。
  • ユーザーが外線にダイヤルするには、何が必要か。
  • メッセージにどのオーディオ コーデックを使用するか。
  • 社内のオペレータの内線番号は何番にするか。
ハント グループとパイロット番号 ハント グループは、特定の順序で通話を受信するように構成された一連の内線番号です。パイロット番号は、ハント グループにアクセスするためにダイヤルする主内線番号です。ハント グループのメンバの内線番号と、設計内のボイスメール ポートの番号には、同じものを使用する必要があります。
メールボックス ポリシー ボイスメール メールボックスのポリシーと Exchange メールボックスのポリシーとの間には、あまり違いはありません。考慮する必要があるいくつかのポリシーを次に示します。
  • ボイスメールを削除せずに保持しておく日数。
  • ボイスメールのパスワードの再設定を要求する頻度。
  • ボイスメールのバックアップ ポリシー。
  • パスワードの最低文字数。
  • メールボックスをロックするログオンの失敗回数。
自動応答 (AA) 自動応答は、特定のサブスクライバ宛てではない着信通話に応答します。自動応答は、情報を提供し、組織内の場所に発信者を案内します。Exchange ユニファイド メッセージングの AA 案内では、DTMF 機能と音声認識機能が提供されます。考慮事項を次に示します。
  • 日中、夜間、および休日に異なる AA メッセージを使用するか (メッセージは文書化し記録する必要があります)。
  • どのユーザーに AA メニューからのダイヤルを許可するか。
  • AA を使用した場合に音声案内機能を使用できるか。
  • AA を使用するために複数の言語が必要になるか。
汎用または夜間メールボックス 一部の組織では、汎用または夜間メールボックスを用意して、発信者が一般的な配信メッセージを残すことができるようにしています。企業でこのようなメールボックスを導入している場合は、Exchange メールボックスを作成し、ユニファイド メッセージングを有効にする必要があります。
Message Waiting Indication (MWI) Message Waiting Indication は、メールボックス内にまだ再生されていないボイス メッセージがあることを知らせる電話機上のライトです。電話機の Message Waiting Indication が展開の要件に含まれるかどうかを検討します。
複数の内線番号のサポート 多くの組織には、複数の電話を使用している従業員がいます。このようなユーザーをユニファイド メッセージングのサブスクライバとして有効にする場合は、その時点のユーザーの内線番号をすべて関連付ける必要があります。作業を開始する前に、複数の内線番号を使用している従業員の一覧を作成してください。
音声自動応答装置 (IVR) のサポート 従来のボイスメール システムの中には、ユニファイド メッセージングでは再現できない IVR アプリケーションがサポートされているものもあります。置き換えられるシステムに、このようなアプリケーションが関連付けられていないかどうかを確認してください。このようなアプリケーションは、既存のシステムに残すことができる場合もあれば、代わりの IVR アプリケーションで置き換えなければならない場合もあります。
ボイスメール ネットワーク ボイスメール ネットワークでは、異種システム間でメッセージを送信するための手段が提供されます。たとえば、大規模な企業では、CEO が組織全体にボイス メッセージを送信したり、消防訓練についての案内など、一般的な情報を通知する場合があります。ボイスメール ネットワークがあれば、CEO がボイス メッセージを一度録音したら、どのボイスメール システムに所属しているかに関係なく、全従業員にそのボイス メッセージを送信できます。現時点では、Exchange ユニファイド メッセージングと他の従来のボイスメール システムを接続するネットワークを構築することはできません。
FAX のサポート 従来のボイスメール プラットフォームの中には、FAX の受信をサポートし、ボイスメールと受信 FAX に同じ電話番号を使用できるものもあります。Exchange Server 2007 ユニファイド メッセージングでは FAX の受信がサポートされているため、この機能を置き換えることができます。これは一方向の機能であり、FAX の送信機能はサポートされていません。この機能が必要な場合は、この機能がサポートされているサードパーティ製品の使用を検討してください。

システムを完全な運用に移行する方法に関しては、さまざまな見方があります。主な 2 つの方法論は、段階的な移行とフラッシュ カットです。どちらを使用するにしても、パイロット グループから収集して記録した一般的な質問に対処できるように、ヘルプ デスク スタッフを教育します。また、ユーザーを有効にする方法、ユーザーが有効になっていることを確認する方法、およびパスワードを変更する方法についても指導します。
古いボイスメール システムからユニファイド メッセージングにユーザーを移行する作業は非常に簡単ですが、1 つ注意が必要なことがあります。それは、ボイスメール ネットワークです。電子メール システムで他の電子メール ユーザーやシステムに電子メールを送信、転送、および返信できるように、ボイスメール システムでも他のボイスメール ユーザーやシステムにボイスメールを送信、転送、および返信できます。
たとえば、古いボイスメール システム上で Alice と Brian というユーザーが管理されているシナリオについて考えてみましょう。Brian はユニファイド メッセージングに移行され、古いボイスメール システム上の Alice にメッセージを送信したいとします。この 2 人のユーザーは別のシステムに所属しているため、ボイスメール メッセージを送信、転送、または返信し合うことができなくなり、残念なことですがボイスメールの孤島が生まれます。
従来のボイスメール システムでこの問題を解決する方法は、異種システムどうしをネットワーク経由で接続できるネットワーク プロトコル コンバータを使用することでした。ただし、現時点では、Exchange Server 2007 ユニファイド メッセージングと異種システムをネットワーク経由で接続できるネットワーク プロトコル コンバータはありません。これは皆さんの組織にとって重要でない場合もありますが、ユーザーを少しずつ移行する場合は注意が必要な問題です。
個人的には、サイト規模ですべてのユーザーを移行するフラッシュ カットがお気に入りです。フラッシュ カットは、あるシステムから別のシステムに一斉に移行する方法です。通常、この作業は週末に行われ、金曜日にユーザーが帰宅してから、月曜日に出社するまでの間に、新しいボイスメール システムに移行します。管理者の中には、フラッシュ カットは、小規模な企業ユーザーやリモート サイトのみに使用すべきだとする方もいます。私はそうは思いません。1 か所で 7,000 人のユーザーという大規模なフラッシュ カットに関わったことがありますが、サポートを必要としてヘルプ デスクに問い合わせた従業員は 1％ 未満でした。プロジェクトの他のすべてのフェーズが問題なく計画および実行されているのであれば、完全な運用システムへのカットオーバーはスムーズに進むでしょう。
ただし、複数のサイトを完全な運用システムにカットオーバーする場合は、小規模なリモート サイトから大規模なサイトへと 1 つずつカットオーバーすることを検討してください。小規模なサイトでの作業で学んだことを見直して、必要な変更をプロジェクトの計画に組み込むようにします。
通常、システムをカットオーバーして運用を開始する前に、すべてのユーザーのトレーニングを完了し、すべてのユーザーのユニファイド メッセージングを有効にする必要があります。ボイスメール システムのフラッシュ カットを準備するための手順を次に示します。
まず、ユニファイド メッセージング システムのインストール、構成、およびテストが完了していることを確認します。
少人数のグループでトレーニングを実施します。参加しているユーザーに、システムの運用を開始する前にメールボックスが有効になることを説明します。また、メールボックスにログインし、パスワードの変更と応答メッセージの録音を行ってメールボックスを初期化することを推奨します。トレーニングが完了したら、直ちにユーザーを有効にして、ユーザーが各自のメールボックスをカットオーバー前に初期化できるようにします。
最後に、すべてのトレーニングが完了したら、週末に古いボイスメール システムのすべてのユーザーを無効にし、ユーザーの電話を Exchange ユニファイド メッセージングに転送します。これで、月曜日の朝には組織内のすべてのユーザーが新システムを使用できるようになります。

カットオーバーを実施する
1 つのサイトをサポートする場合でも、大規模な複数のサイトを所有する組織をサポートする場合でも、この記事の情報は役立つと思います。複数のサイトを所有する組織では、設計がより複雑になる可能性はありますが、ユーザーの数が 50 人であっても 5,000 人であっても、基本的な要件は変わりません。
ユニファイド メッセージング ソリューションの展開時には、IT チームと通信チームが協力し合うことが非常に重要です。私の経験では、ユニファイド メッセージング プロジェクトを脱線させかねないことの中でも、IT チームと通信チームとの間の不和や、ソリューションに関する意見の不一致が発生した場合、展開が失敗する可能性があります。テクノロジの集中化はそれほど難しくありませんが、IT と通信の両方を理解し、両チームをまとめたり、プロジェクトの展開を成功に導く計画の作成をサポートしたりできる社外の協力者が必要になる場合もあります。

Jeff Goodwin は、The VIA Group のシニア テクノロジストです。専門分野は、Exchange とユニファイド メッセージングの設計と展開です。彼の連絡先は、jgoodwin@theviagroup.com (英語のみ) です。


 セキュリティ: 基本的なコンピュータ フォレンジック ガイド
セキュリティ Tom Cloward and Frank Simorjay

基本的なコンピュータ フォレンジック ガイド
概要:
  • Windows 向けの基本的なコンピュータ調査ガイド
  • マルウェアの削除スタート キット
  • Windows PE を使用して調査キットを作成する
  • フォレンジック分析の情報を保存する

悪意のある人物がコンピュータを使用して違法行為を行う方法は、システムのハッキング、企業秘密の漏えい、新種のウイルスの蔓延、フィッシング メッセージを使用した個人情報の盗難など、無数にあります。また、新たな攻撃や手口についてのニュースが
次々と流れています。しかし、コンピュータを使用してこのような行為を調査できる方法があることは、あまり知られていません。
高度な訓練を受けた専門家が高価なツールと複雑な手法を駆使して行う調査もありますが、基本的な調査と分析に使用できる簡単で費用もかからない方法があります。この記事では、一般の管理者が利用できるコンピュータ フォレンジックの手法について説明します。
ここでは、無償でダウンロードできる 2 つのソリューション アクセラレータを利用します。1 つは「Windows 向けの基本的なコンピュータ調査ガイド」(go.microsoft.com/fwlink/?LinkId=80344) で、もう 1 つはマルウェアの削除スタート キット (go.microsoft.com/fwlink/?LinkId=93103) です。この記事では、これら 2 つのソリューションを組み合わせて起動可能な Windows® PE 環境を構築することによって、効率的に調査を実施し、レポートと分析のために結果を保存できるようにする方法について説明します。ただし、ここで説明する方法は、暗号化されているか、RAID ボリュームの一部であるハード ドライブの調査には使用できません。また、ハード ドライブに障害がある場合は、あらかじめドライブの状態を復元する作業を行っておく必要があります。
ここでは、Windows ベースのコンピュータから証拠を簡単に収集する方法について説明しますが、これは基本的なその場限りの方法にすぎません。ここで説明する作業をはるかに効率的な方法で行うことができる、他の高度なソリューションもいくつか市販されています。
また、ここで説明する手法は、保証された規範的なソリューションでもなく、The International Society of Forensic Computer Examiners によって認定されているソリューションでもありません。調査を始める前に、ハード ドライブ上の証拠が法的要件の 1 つになる可能性があるかどうかを検討してください。その可能性がある場合は、資格を持つコンピュータ検査の専門家に調査を依頼するようにしてください。考えられる法的手続きの性質によっては、調査内容を司法当局に直接提出する必要があるかどうかも検討する必要があります。詳細については、「Windows 向けの基本的なコンピュータ調査ガイド」を参照してください。

ソリューション アクセラレータについて
「Windows 向けの基本的なコンピュータ調査ガイド」には、社内のコンピュータ調査で使用できるプロセスとツールに関する説明が記載されています。このガイドでは、コンピュータ調査モデルの 4 つのフェーズが概説されています。4 つのフェーズとは、評価、取得、分析、およびレポートです。これは、重要な調査結果が保存される形で IT プロフェッショナルが調査を実施できる便利なモデルです。
このガイドでは、どのような場合に司法当局の協力が必要になるかについても取り上げられています。この判断を行う際は、法律顧問に相談してください。また、コンピュータ関連犯罪への対応方法、適切な司法機関への連絡方法、および Windows Sysinternals をはじめ、調査を行う際に役立つその他の Windows ツールに関する情報も記載されています。
この記事で取り上げるもう 1 つのソリューション アクセラレータは、マルウェアの削除スタート キットです。このガイドには、起動可能な Windows PE CD-ROM を作成し、その CD-ROM を使用してコンピュータからマルウェアを削除する方法が記載されています。また、脅威の一覧と、各脅威が組織に与える影響を軽減するための対策もいくつか紹介されています。さらに、マルウェア攻撃の疑いがある場合に実施する問題対応の計画を作成することの重要性も強調されています。マルウェアの削除スタート キットには、4 つの段階から成る方法が記載されています。この方法を使用すると、IT プロフェッショナルは、問題のマルウェアの性質を特定し、蔓延を食い止めて可能であればこれを削除し、削除されたことを確認して、必要と思われる次の手順を実行することができます。

Windows PE CD-ROM
このような調査を実施する場合、必要になるものが 2 つあります。1 つは Windows PE CD-ROM、もう 1 つは USB フラッシュ ドライブなどの外付け記憶装置です。
警察官が犯罪現場の状態を保全することは、おそらくテレビを観てご存知だと思います。それと同じ理由で、調査対象のハード ドライブに格納されているデータも変更しないようにします。ここで作成する起動可能な Windows PE ディスクでは、マルウェアの削除スタート キット ディスクとは異なり、ハード ドライブのデータがまったく変更されない方法でツールが実行されます。
Windows PE ディスクを使用すると、制限された Windows 環境を使用してシステムが起動されます。この起動可能な CD を作成する際、特定の用途に合わせてあらかじめ構成されたツール (マルウェアの削除スタート キットなど) を組み込むことができます。また、コンピュータには 512 MB 以上の RAM が搭載されている必要があります (これは Windows PE の要件です)。
Windows PE CD-ROM は、非常に簡単に作成できます。マルウェアの削除スタート キットにこの手順の詳しい説明が記載されています。この起動可能ディスクを構築する前に、Windows 自動インストール キット (AIK) と Sysinternals Suite (microsoft.com/technet/sysinternals/utilities/sysinternalssuite.mspx からダウンロードできます) をインストールし、マルウェアの削除スタート キットに記載されている作業 2 の手順に従って Sysinternals ツールをツール一覧に追加した後、その他のマルウェア スキャン ツールとユーティリティをインストールする必要があります。起動可能ディスクの作成手順については、マルウェアの削除スタート キットの説明を参照してください。

外付け USB ドライブ
このプロセスでは調査対象のドライブが変更されないため、USB ドライブなどの外付けハード ドライブを用意して、生成される出力ファイルを保存できるようにする必要があります (Windows PE は USB デバイスを自動的にマウントできるため、USB ドライブを使用することをお勧めします)。また、外付けハード ドライブを使用して、元のハード ドライブのイメージを保存することもできます。このような要件や選択肢をすべて踏まえて、調査で必要になるディスク容量の合計をあらかじめ把握しておくことが非常に重要です。
確実にキットをクリーンな状態にしてから調査を開始する必要があるため、調査ファイルの保存に使用する外付けディスク ドライブに格納されている既存のデータはすべて削除する必要があります。この作業は、書き込み可能なドライブ全体を上書きするディスク ワイプ ユーティリティを使用すると簡単に実行できます。その後、外付けディスクをフォーマットして、必要であれば調査用であることを示すラベルを付けます。この事前処理によって、調査で収集した証拠を台無しにする可能性のあるファイルがデバイスに含まれていないことが保証されます。
また、処理過程を管理するためのフォームを組み込み、このコンピュータで調査を実施した人物に関する情報が記載された公式なドキュメントを残すこともできます。「Windows 向けの基本的なコンピュータ調査ガイド」では、サンプルの処理過程管理フォームが提供されています。キット (必要な起動可能 Windows PE ディスク、外付け記憶装置、および処理過程管理フォーム) が用意できたら、次に進みます。

調査を実施する
いよいよ、調査の実施に移ります。まず、Windows PE ディスクを使用して問題のシステムを起動します。コンピュータの起動順序で CD-ROM ドライブが最初に検出される起動デバイスとして指定されていることを確認してから、この操作を行ってください。メッセージが表示されたら、任意のキーを押して CD-ROM からの起動を完了します。これで、ディスクにインストールされているツールにアクセスできるようになります。
ここでは、作成したキットをサンプル コンピュータ (Testbox1) で使用して、コンピュータから情報を収集する方法について説明します。Testbox1 の CD ドライブは X:\ に割り当てられています。このため、マルウェアの削除スタート キットのツールが格納されている既定の場所は X:\tools になります。キット内のツールにアクセスするには、「cd \tools」と入力します。
コンピュータにマウントされている調査対象のドライブを識別できるツールがいくつかあります。Sysinternals のツール ディレクトリで提供されている Bginfo.exe を使用すると、この情報を確認することができます。この情報はデスクトップの背景に表示されるため、簡単に参照することができます。また、Drive Manager を使用すると、調査対象のハード ディスク ドライブや外付け USB デバイスを含む、コンピュータ上のすべてのドライブを識別できます。図 1 は、Testbox1 のディスク情報を示しています。起動ドライブは X:\、調査対象のハード ドライブは C:\、そして外付け USB ドライブは F:\ です。
図 1 Drive Manager に表示されたディスク情報
図 1 Drive Manager に表示されたディスク情報

マルウェアの有無を確認する
調査を開始する前に、マルウェア対策ツールを実行して、ウイルスや他の悪意のあるコードによって調査が影響を受けないようにする必要があります。マルウェア対策ツールによって生成されたレポートは、必要であれば証拠として使用できます。ただし、コンピュータにマルウェアが存在するかどうかを確認しなかった場合、調査が台無しになるだけでなく、調査者が徹底的かつ正確に調査を行ったかどうかを疑われる可能性があります。このため、提供されているマルウェア対策ツールを読み取り専用モードまたはレポート モードで実行することをお勧めします。
マルウェアの削除スタート キットでは、悪意のあるソフトウェアの削除ツールや McAfee AVERT Stinger など、さまざまな推奨ツールが紹介されています。悪意のあるソフトウェアの削除ツールを実行する際は、必ず次のようにコマンド ライン オプション /N を指定してください。これにより、マルウェアは削除されず、マルウェアのレポートのみが実行されます。
x:\tools\windows-KB890830-v1.29.exe /N
結果のレポート ファイルは %windir%\debug\mrt.log として保存されます。
同様に、McAfee AVERT Stinger を実行する場合は、設定を [Report only] (レポートのみ) に変更してください (図 2 参照)。これにより、ハード ドライブは変更されず、コンピュータのスキャンのみが実行されます。スキャンが完了したら、ツールからレポートの保存を実行します。
図 2 McAfee AVERT Stinger の Report only (レポートのみ) モードの使用
図 2 McAfee AVERT Stinger の Report only (レポートのみ) モードの使用

重要なファイルを保存する
調査を開始する前にディスク全体をバックアップしなかった場合は、少なくとも重要なユーザー ファイルをバックアップします。構成情報は、再調査が必要になった場合に使用できます。まず、レジストリ ファイルと設定を収集します。これらのデータには、コンピュータがどのように使用されたか、およびどのようなソフトウェアがシステムにインストールされているかに関する情報がすべて含まれています。
Testbox1 のレジストリ ハイブを保存するには、まず次のコマンドを使用して、取り外し可能な F:\ ドライブにフォルダを作成し、調査を開始した日付と時刻を記録します。
f: Mkdir f:\evidence_files Date /t >> f:\evidence_files\Evidence_start.txt Time /t >> f:\evidence_files\Evidence_start.txt
次に、レジストリ ハイブを保存します。xcopy コマンドを使用して、構成ディレクトリ全体とその内容をコピーします。目的のレジストリ ファイルは、%windows%\system32\config にあります。この例では、次のコマンドを実行します。
xcopy c:\windows\system32\config\*.* f:\registrybkup /s /e /k /v
このコマンドを実行すると、config フォルダに格納されているすべての構成情報がコピーされます。Textbox1 の config フォルダには、約 95 MB の情報が格納されています。
次は、ユーザー データをバックアップします。ユーザー データは、ハード ディスク上の決まった場所にあるわけではありません。この例では、c:\HR というディレクトリのデータのみをコピーします。完全にデータを収集するには、次の xcopy コマンドを使用して、HR ディレクトリとそのサブディレクトリに格納されているすべてのデータをコピーします。
Mkdir f:\evidence_files\HR_Evidence Mkdir f:\evidence_files\documents_and_settings Mkdir f:\evidence_files\users xcopy c:\HR\*.* f:\evidence_files\HR_Evidence /s /e /k /v
次に、個人用フォルダの情報をバックアップします。この場合も、該当するフォルダとそのサブディレクトリに格納されているすべてのデータをコピーします。これを行うには、次のコマンドを使用します。
Xcopy c:\documents and settings\*.* f:\evidence_files\documents_and_settings /s /e /k /v

Xcopy c:\users\*.* f:\evidence_files\users /s /e /k /v
この例では、約 500 MB のデータが収集されました。このデータは必要に応じて分析できます。このように、収集するデータは、特にオーディオ ファイル、ビデオ、写真が含まれる場合、膨大な量になる可能性があります。それでも、調査では、物理的に証拠を収集するだけではなく、その情報が収集中に変更されていないことを保証しなければならない場合もあるため、元のデータをできるだけ多く保存しておくことが重要です。調査対象のディスク全体のイメージを保存することが理想的ですが、サイズの制約によって困難になる場合があります。これで、調査に必要な記憶域の容量をあらかじめ予想しておくことが重要である理由がおわかりいただけたと思います。

その他の情報を収集する
システム ファイルも有用な証拠として収集できる場合があります。ただし、これらのファイルは常に同じ場所に格納されているとは限らないため、このデータを収集する場合は、調査対象のコンピュータ内をある程度調べなければならないかもしれません。しかし、特定の種類のファイルから有用な情報が得られる可能性もあるため、調べるだけの価値はあります。たとえば、スワップ ファイルには、メモリがアクセスしたファイルに関する情報が含まれています。また、使用状況の詳細が含まれている場合もあります。同様に、Web ブラウザ データと Cookie からは、閲覧操作や閲覧パターンに関する情報が得られます。
このデータを見つけるには、特にユーザーが既定以外の場所にデータを保存するように構成を変更していた場合、コンピュータ内をある程度調べなければならないかもしれません。重要なファイルの検索に役立つ Sysinternals ツールがいくつかあります。図 3 は、5 つの便利なアプリケーションと、これらがどのように調査に役立つかを示した一覧です。
Figure 3 Tools to locate files and data of interest (Close Figure 3)

アプリケーション | 説明
AccessChk | 指定したユーザーまたはグループに与えられている、ファイル、レジストリ キー、および Windows サービスへのアクセス権を表示します。
AccessEnum | コンピュータ上の各ディレクトリ、ファイル、およびレジストリ キーにアクセスできるユーザーを表示します。この情報を使用して、アクセス許可が正しく適用されていない箇所を特定できます。
Du | ディレクトリごとのディスク使用状況を表示します。
PsInfo | コンピュータに関する情報を表示します。
Strings | バイナリ イメージから ANSI および UNICODE 文字列を検索します。

Tom Cloward (CCE、CISSP) は、マイクロソフトのプログラム マネージャで、IT プロフェッショナル向けのセキュリティおよび法令順守ソリューション アクセラレータを担当しています。15 年以上にわたりソフトウェアおよび IT 業界に身を置き、IT セキュリティ、フォレンジック、および法令順守に関連した業務に情熱を持って取り組んでいます。
Frank Simorjay (CISSP、CET) は、テクニカル プログラム マネージャで、マイクロソフト ソリューション アクセラレータのセキュリティおよび法令順守グループにおいて、セキュリティを担当しています。彼は、マイクロソフトの顧客向けのセキュリティ ソリューションを設計しています。彼が最近手がけた仕事には、現在 Microsoft TechNet で提供されているマルウェアの削除スタート キットがあります。


 ネットワーク: Microsoft Security Intelligence Report
ネットワーク Tim Rains

Microsoft Security Intelligence Report
概要:
  • ソフトウェアの脆弱性の発見、悪用、およびマルウェアに関する傾向
  • Windows の各バージョンが受けた脅威の影響
  • 世界で最も感染の割合が高い地域と低い地域

マイクロソフトは、インターネットに接続している数千万台のシステムや、世界で最も利用されているいくつかのオンライン サービスから収集されたデータを利用して、現在インターネット ユーザーが直面しているセキュリティの脅威に関して独自の視点を得ることができます。
マイクロソフトでは、このデータを年に 2 回、Security Intelligence Report (SIR) として公開しています。このレポートは、Microsoft® Malware Protection Center (MMPC)、Microsoft Security Response Center (MSRC)、Trustworthy Computing (TwC) グループをはじめ、さまざまな製品グループの協力を得て作成されています。SIR では、ソフトウェアの脆弱性の発見や、悪意のあるソフトウェアと望ましくないソフトウェア (スパイウェアやアドウェアなど) に関する最近の傾向が詳しく説明されています。また、Windows オペレーティング システムの各バージョンが現在発生している脅威にどのように対処しているかや、世界で最もマルウェアやその他の侵入型ソフトウェアの感染率が高い地域についても取り上げています。2007 年前半の傾向に焦点を当てているこのレポートの最新版では、ソフトウェアの脆弱性の悪用に関する新しいセクションが追加されています。コンピュータのセキュリティを担当している方や、セキュリティに興味がある方は、インターネット関連の脅威について知ることができる SIR を一読されるとよいでしょう。
最新の SIR では、あらゆるベンダのソフトウェアで脆弱性が次々と見つかっていることが明らかにされています。実際、2007 年前半だけで、3,400 件以上のソフトウェアの脆弱性が新たに発見されています。しかし、このような状況でありながら、全体的に見て、オペレーティング システムの脆弱性が発見される割合は低下しています。
これはどういうことでしょうか。1 つ考えられることは、オペレーティング システムのセキュリティは継続的に改善されているため、セキュリティの調査対象としてアプリケーションに比重が置かれるようになった可能性があります。また、新しいアプリケーションの数は、新しいオペレーティング システムの数よりも多いため、アプリケーションの相次ぐリリースが、この最近の脆弱性発見の傾向を後押ししていると考えられます。
2006 年は、マイクロソフト製品に存在する既知の脆弱性の 29.3% について、エクスプロイト コードが公開されましたが、2007 年 8 月 1 日現在では、エクスプロイト コードが公開されている既知の脆弱性は 20.9% しかありません。脆弱性の数は増え続けていても、エクスプロイト コードの公開率は、変わらないかわずかに減少しています。新製品のエクスプロイト コードを見つけることは困難です。マイクロソフトが実施した製品ごとの比較調査では、新しいバージョンの方が、市場により長く存在しているバージョンよりもリスクが低いことがわかっています。平均して、製品の存続期間が長くなるにつれて悪用される可能性は低くなっていきます。つまり、大半の製品では、バージョンが更新され新しくなるほど悪用されにくいと言えます。このことは、Windows と Microsoft Office System 製品において最も顕著です。両製品の新しいバージョン (Windows Server® 2003、Windows Vista®、Office 2003、および 2007 Office system) は、製品の存続期間が長くなるほど脆弱性の数が明らかに減少することを示しています。
SIR は、悪意のあるソフトウェア (マルウェア) の傾向についても価値ある洞察を提供しています。これらの傾向は、現在ユーザーの攻撃に使用されている方法を示しています。マイクロソフトは、Microsoft Exchange Hosted Services (EHS)、Windows Live® OneCare と Windows Live OneCare セーフティ、Windows 悪意のあるソフトウェアの削除ツール (MSRT)、Windows Defender など、いくつかの重要なサービスやツールから収集されたデータを分析することで、脅威に関する状況をいくつかの独自の視点から把握することができます。
マルウェアの配信においてソーシャル エンジニアリングが果たす役割が拡大しています。多くの場合、このような攻撃は、セキュリティ メカニズムの効果を損ねるような行動を取るようにユーザーを仕向ける際に効果を発揮します。EHS から収集したデータによると、2006 年前半は、従来の電子メール ワームが電子メールによる最大の脅威であり、電子メール内で検出されたマルウェアの 95% を占めていました。2006 年後半に入ると、この数字は 49％ にまで落ち込み、2007 年前半までこの割合は変わっていません (図 1 参照)。フィッシング詐欺と悪意のある IFrame を組み込んだ電子メールによる攻撃が、電子メール内のマルウェア検出全体に占める割合は、2006 年後半には 27％ でしたが、2007 年前半には 37％ に上昇しています。電子メールを媒体とするダウンローダ型のトロイの木馬が占める割合は、2006 年後半のピーク時は 20％ でしたが、2007 年前半では 7％ に減少しています。
図 1 2007 年前半に感染が確認された電子メールの内訳
図 1 2007 年前半に感染が確認された電子メールの内訳
Windows Live OneCare と Windows Live OneCare セーフティ (safety.live.com) によって収集された遠隔測定データによると、ウイルス、バックドア、パスワード窃盗プログラム、およびデータ漏えいにつながるトロイの木馬の感染率が 2007 年前半に増加しています。
MSRT は、既に蔓延したマルウェアをユーザーのコンピュータから検出し、削除するためのツールです。このツールは当初、Windows Update (WU)、Microsoft Update (MU)、および自動更新 (AU) で提供される重要な更新プログラムとしてリリースされました。過去 2 年間で、MSRT は全世界で 2050 万台のコンピュータから 5030 万件の感染を除去しました。現在までのところ、MSRT が実行された回数は、合計で 740 億回を超えています。そのうち、2007 年前半に実行された回数は 190 億回です。
MSRT は、マイクロソフトとそのユーザーにとって、素晴らしい情報源です。MSRT によって検出された感染の割合は、Windows Vista と Windows XP SP2 システムの方が、それより前の Windows オペレーティング システムと比べて格段に低くなっています (図 2 参照)。MSRT がマルウェアを削除した Windows Vista コンピュータの数は、Windows XP SP2 コンピュータと比べると 60％、Service Pack が適用されていない Windows XP コンピュータと比べると 91.5% も少なくなっています。興味深いことに、コンピュータ 1 台あたりの除去された感染数は、時間が経過しても変化は見られず、平均して 1 台あたり 2.2 件の感染が除去されています。
図 2 2007 年前半に MSRT によって感染が除去された OS バージョンの割合
図 2 2007 年前半に MSRT によって感染が除去された OS バージョンの割合
一般に、MSRT によって検出されたマルウェア数は、発展途上国の方が先進国を上回っています。たとえば、ヨーロッパで最も感染が多い国はアルバニアとトルコで、最も感染が少ない国はイタリアとフィンランドです。アジア太平洋地域では、最も感染が多い国はモンゴルとタイで、最も感染が少ない国はニュージーランドと日本です。米国は、南北アメリカのほとんどの国と地域に比べて感染が少なく、米国の感染率は世界平均とほぼ同じです。2007 年前半には、平均して 216 台のコンピュータにつき 1 台の割合で MSRT によって感染が除去されました。
Windows Defender は、Windows Vista、Windows XP、および Windows Server 2003 に対応しています。2007 年前半には、望ましくないソフトウェアが合計 5070 万点検出されました。このうち、Windows Vista コンピュータ上で検出された数は、Windows XP SP2 コンピュータで検出された数を 2.8 倍も下回っています。同様に、Windows Vista コンピュータ上で検出された望ましくないソフトウェアの数は、Windows Server 2003 コンピュータ上で検出された数の半分でした。
ここまで読んだ皆さんは、上記で紹介した統計情報に興味を持つと同時に、これらを自分自身や自分の環境を保護するためにどのように役立てることができるかについて、考えていらっしゃるでしょう。最新の SIR は、各セクションの最初にそのセクションの概要が記載されており、続いて戦略、対策、および対処方法が記載されているという構成になっています。これらの一覧を使用することで、レポートの各セクションに記載されている重要な調査結果をすばやく確認できます。
また、SIR のデータ、洞察、およびガイダンスを使用して、変わり続ける脅威の状況と照らし合わせて現在のセキュリティ体制を評価し、改善することもできます。重要な調査結果を基にした戦略、対策、および対処方法が記載されている完全なレポートは、microsoft.com/sir からダウンロードできます。

Tim Rains は、Microsoft Malware Protection Center (MMPC) のプロダクト マネージャです。彼は、Microsoft Security Intelligence Report (SIR) の製作を管理しています。SIR を執筆しているのは、Jeff Jones (ディレクタ、Microsoft Trustworthy Computing Group)、Jeff Williams (ディレクタ、MMPC)、Mike Reavey (グループ マネージャ、Microsoft Security Response Center)、および Ziv Mador (シニア プログラム マネージャ兼レスポンス コーディネータ、MMPC) です。


 ネットワーク: 特定しにくいネットワークの問題を突き止める
ネットワーク Christopher Stoneff

特定しにくいネットワークの問題を突き止める
概要:
  • ネットワークの問題の一般的な原因
  • 明らかな原因の先を見る
  • トラブルシューティング ツールが役に立たないとき
  • なぜ接続制限を構成する必要があるのか

コンピュータが他のコンピュータと通信できなくなったが、その原因がわからないという事態には何度も遭遇したことがあるでしょう。管理システムは、ルーティング ネットワークの 1 つのセグメントにあり、ルーティング ネットワークは Microsoft Internet Security and Acceleration (ISA) Server や
別のハードウェア デバイスによって、その他のネットワーク セグメントに接続されています。数十個から 100 個までのシステムであれば、管理する際に問題は発生しませんが、500 個のシステムを管理しようとすると、コンピュータでは、既に接続が開いているコンピュータ以外とはネットワークを介しての通信ができないという状況が発生することがあります。他のあらゆるシステムと通信できず、インターネットにも接続できないのに、(あなたのコンピュータが存在しているセグメント上を含め) ネットワーク上で、同じ現象が発生しているコンピュータは 1 台もありません。このような場合には、まずどこを確認したらいいでしょうか。

問題を診断する
この状況で最も一般的な原因として考えられるのは、管理ソフトウェアに問題があるということです。多くの積極的な管理ツールはシステムに接続して、システムを管理しますが、そういったツール自体が、原因を突き止めようとしている問題の根源だという合があります。積極的な管理ツールは、管理機能の向上という名目で、デバイスで何千もの接続を確立することがあります。Windows® では、接続がアイドル状態の場合でも、ツール、アプリケーション、またはサービスが接続を長い時間維持しようとしない限りは、そういった接続を既定で 2 分間開いたままにします。これは、つまり、管理システムが 2 分間どのコンピュータにアクセスしていなくても、1,000 個以上の接続が開いている可能性があるということです (コマンド プロンプトで NETSTAT を実行すると、開いている接続を確認することができます。NETSTAT コマンドは、システムで開いている接続、保留中の接続、および終了中の接続すべてを表示します。ステータス メッセージの説明については、RFC 793 (tools.ietf.org/html/rfc793) を参照してください。)
誤作動している管理ソフトウェアを問題の原因の候補から除外するには、リモート システムに接続を確立するバッチ ファイルを作成します。バッチ ファイルを実行したときにも同じ問題が発生した場合は、管理ソフトウェアとそのスレッドが問題の原因ではないということが特定できます。このバッチ ファイルには、次のような内容が記載されている必要があります。
Net use \\system01\ipc$ Net use \\system02\ipc$ Net use ...
問題の管理プログラムが、独自のネットワークと認証スタックを実装している場合は、それが原因である可能性があります。しかし、そういったほとんどの管理パッケージのようにエージェントを使用しないソリューションでは、ツールはオペレーティング システムのネットワークと認証スタックを使用してネットワーク操作を実行しています。障害を起こさずにできるだけ多くのネットワーク接続を確立するバッチ ファイルを使用すると、(バッチ ファイルでも OS のネットワークおよび認証スタックを使用しているので) プログラムでオペレーティング システムのネットワークおよび認証スタックを使用していることが原因で問題が発生したのではないことがわかります。

役に立たないログとエラー メッセージ
接続が確立できなくなり始めたとき、適切ではないエラーに関する情報が表示されることはご存知でしょう。たとえば、"エラー 53 ネットワーク パスが見つかりません"、"エラー 64 ネットワーク名は削除されました"、"エラー 1203 指定されたネットワーク パスはどのネットワーク プロバイダによっても受け付けられませんでした" などのような情報が表示されます。通常、これらの情報は、名前解決に関する問題を示すものですが、他のすべてのコンピュータでは、名前解決や同じシステムへの接続では問題が発生していません。コンピュータの設定が間違っていないことを確認するには、ipconfig を実行して設定が正しいことを確認します。
この現象の原因が管理システムにあることが特定できたら、イベント ログを確認する必要があります。アプリケーション ログを検索しても意味はありませんが、システム ログを検索すると、接続の最大数に達したことを示す、イベント ソースが TCP/IP の警告イベント 4226 が見つかります (図 1 参照)。
図 1 TCP 接続が制限に達したことを示すイベント
図 1 TCP 接続が制限に達したことを示すイベント
HKLM\System\CurrentControlSet\Services\TCPIP で、いくつかのレジストリ エントリを調整し、前述の要因を制御することができます。TcpNumConnections は TCP が同時に開くことのできる接続の最大数 (既定値は 10) を設定し、TCPTimedWaitDelay は接続が終了中のときの TIME_WAIT 状態の時間を設定します。既定の半減期は 120 秒です。これは基本的に接続が 4 分間使用されるということです。また、MaxFreeTcbs の設定も接続の最大数に影響します。すべての TCP 制御ブロックが使用されている場合、TCPTimedWaitDelay に設定されている時間が経過していなくても、TCP は TIME_WAIT 状態になっている接続を開放し、より多くの接続を作成できるようにする必要があります。TCPTimedWaitDelay に設定できる値の範囲は 30 ~ 300 秒 (0x1E ～ 0x12C) です。
シナリオによっては、これらのレジストリに変更を加えることで全体のパフォーマンスにわずかな改善が見られることがあります。別の解決策として、TCPIP.sys ファイルを修正して、この制限を取り除くこともできます。ただし、この方法で状況を改善できるのは P2P アプリケーションに限られます。

ネットワーク キャプチャ
接続の問題を解決できずにあれこれ試した後、問題に関連のあるコンピュータのネットワーク キャプチャを撮ることが有望な解決策であると思いました。Microsoft ネットワーク モニタ (Netmon) を実行すると、管理ツールとテスト スクリプトで発生していたのとまったく同じ結果が表示されるキャプチャが作成されました。それは、問題なく動作していたのに、突然、問題が発生して詳細なエラー情報が提示されないという状況です。
図 2 は Netmon を実行した結果を示すもので、最初のいくつかのシステム間で通信が正常に行われていることを示しています。この図では、RPC 要求の承認を得ていることが確認でき、これが望ましい正常な双方向の通信の状態です。
図 2 Netmon での正常な通信状態
図 2 Netmon での正常な通信状態
次に、エラー 53 とエラー 1203 が発生する思われる管理システムとリモート コンピュータのネットワーク キャプチャを確認する必要があります。ご想像のとおり、コンピュータでは通信が行われていないので、画面上には何も表示されません。図 3 のネットワーク キャプチャでは、管理システムが IP アドレスを解決し、ポート 445 (Microsoft SMB ポート) を使用してシステムに接続しようとしていますが、応答がありません。
図 3 ポート 445 を使用してシステムへの接続を試行しているが応答がない状態
図 3 ポート 445 を使用してシステムへの接続を試行しているが応答がない状態
現在コンピュータで接続できる以上のスレッドがある場合に表示されるエラーには一貫性がありません。たとえば、ソース システムから、名前解決は行われたが、IP アドレスが見つからないということを示す、エラー 53 が返されることがあります。これは、DNS が接続できないアドレスを提供していることを示しています。また、要求した名前または IP アドレスに対応するコンピュータがないことを表す、エラー 1203 が返されることがあります。この場合、エラー 1203 は DNS が使用できないことを示しています。nslookup を実行した場合にはこういうことが起こります。
この時点でおそらくストレスを感じているでしょうが、検討すべきオプションはまだあります。ほとんどのユーザーは、この問題が発生している状況から、接続元のインフラストラクチャを確認しようとは思わないでしょう。つまり、ネットワークに接続できないのが、あなたのコンピュータだけで、イベント ログにはコンピュータが許可された最大接続数に達したことを示すイベントが記録されているので、アーキテクチャの性質上の問題ではないように思う人が多いのです。
管理ソリューションが同時に何千もの接続を確立しないとしても、転送の keep-alive と接続のタイムアウトにより、想像以上に多くの接続が同時に開かれている可能性があります。そのため、ネットワークを接続するシステムについても調べる必要があります。
これについて説明しましょう。既に説明したように、ネットワーク トラフィックがネットワークを通過するときは、スイッチやルーター (場合によってはファイアウォール) を通過します。このようなデバイスのいずれか (通常ルーターまたはファイアウォール) には、侵入検出システムが存在します。また、管理されたスイッチやルーターでもトラフィックのフィルタリングが行われています。そのため、ログにエラーと警告が記録されていないかどうかを確認する必要があります (または、デバイスの管理者に、その作業を依頼する必要があります)。通信の問題は、このようなシステム自体にある場合が往々にしてあります。
内部システムから他の内部システムに接続しているので、警告が発生していないことがあります。それはデバイスが警告を発生させるように構成されていないこと、または問題が侵入またはサービス拒否 (DOS) 攻撃と見なされないことが原因です。繰り返しになりますが、まずログを確認する必要があります。例として ISA Server を使用すると、このようなログは ISA Server の管理コンソールの "アレイ\<ArrayName>\監視\ログ" にあります。
問題となっているのが特定のポリシーである場合は、(ISA Server の場合は) 送信元の IP アドレスが管理コンピュータのアドレスである、次の結果コードがあるかどうかを確認します。
  • 0xc0040037 FWX_E_TCP_RATE_QUOTA_EXCEEDED_DROPPED
  • 0xc004000d FWX_E_POLICY_RULES_DENIED
  • 0xc0040017 FWX_E_TXP_SYN_PACKET_DROPPED
このような結果コードが記録されていた場合は、接続の問題の原因を特定できたことになります。

解決策を実装する
問題の原因を特定できたら、解決策は簡単です。しかし、部門の方針によっては、解決策の実装が困難になることもあります。ファイアウォール、ルーター、および侵入検出システムでセキュリティ構成の除外を作成することは常に許可されているとは限らないので、変更を加える前に、適切な権限があることを確認してください。
ここでも、例として ISA Server を使用して、 ネットワーク上にある特定のホスト コンピュータまたはすべてのコンピュータの接続の最大数を増やす手順を説明します (図 4 参照)。ISA Server の管理コンソールを開き、"アレイ\<ArrayName>\構成\全般\フラッド防止設定の構成" に移動します。
図 4 ISA Server を使用して特定のホスト コンピュータまたはすべてのコンピュータの接続の最大数を増やす
図 4 ISA Server を使用して特定のホスト コンピュータまたはすべてのコンピュータの接続の最大数を増やす
重要なのは、[IP アドレスごとの同時 TCP 接続の最大数] と [分単位、IP アドレスごとの TCP 接続要求の最大数] という 2 つの設定です。通常、[IP アドレスごとの同時 TCP 接続の最大数] には、積極的な管理が行われない (つまり、1 台のコンピュータが他の何千台ものコンピュータとアクティブな状態で接続されることがない) 場合に十分な値が設定されています。ISA Server では、同時 TCP 接続の最大数の既定値は 160 です。[分単位、IP アドレスごとの TCP 接続要求の最大数] はネットワークのスキャンによる損傷や可視性を制限するように設計されています。この TCP 接続要求の最大数の既定値は 600 です。
既に説明したように、Windows は、接続を長い時間維持するようにするものがなければ、既定の 2 分間接続を維持します。これには接続が使用されていない場合も含まれます。つまり、コンピュータを適切に管理し終えて通信する必要がなくても、接続はアクティブなままになるということです。この開いている接続は、許可されている接続の総数に加えられます。接続を削除しないでこのプロセスを 160 回繰り返すと、ルーターによってすべての接続の試行が拒否されます。管理プログラムが積極的にセッションを停止しても、Windows では、接続を TIME_WAIT 状態のままにし、接続しているコンピュータがセッションの切断を許可するまで待機します。
まず、問題の原因として最も可能性が高いと思われる [IP アドレスごとの同時 TCP 接続の最大数] の設定を調整します。この設定の値は、管理コンピュータが、アクセス拒否されることなく、システムを管理するのに必要なすべての接続を作成できる数にします。この設定の隣にある [編集] をクリックして、値を変更します。
次に表示されるダイアログ ボックス (図 5 参照) には、すべてのクライアントに適用される既定の制限を表す [制限] ボックスがあります。[カスタム制限] ボックスの値は、[フラッド防止] ダイアログ ボックスの [IP 例外] タブで指定されているすべてのコンピュータ、ネットワークなどに適用されます。すべてのコンピュータでより多くの接続を作成できるようにする必要がある場合は、[制限] ボックスの値を変更します。管理コンピュータ専用の例外を構成するには、[カスタム制限] ボックスの値を調整し、[IP 例外] タブに当該の管理コンピュータを追加します。一般的に、自分のコンピュータだけで例外を許可するのが適切です。
図 5 既定の接続の制限とカスタム接続の制限
図 5 既定の接続の制限とカスタム接続の制限
カスタム制限を使用して、特定のシステムについてだけ、この値を変更する必要がある場合は、[カスタム制限] ボックスの値を変更し、[OK] をクリックします。その後、[フラッド防止] ダイアログ ボックスの [IP 例外] タブに当該コンピュータを追加します。例外の一覧にコンピュータを 1 台追加するには、[IP 例外] タブで [追加] をクリックし、[コンピュータ セット] ダイアログ ボックスを開きます。例外を適用するコンピュータを含むネットワーク セットがまだ存在していない場合は、[新規作成] をクリックして、このようなコンピュータを含むネットワーク セットを作成します。このネットワーク セットを選択し、[追加] をクリックして "内部ネットワーク" ネットワーク セットを追加し、[閉じる] をクリックします。もう一度、内部ネットワーク ネットワーク セットを選択し、[編集] をクリックします。これにより、[内部ネットワークのプロパティ] ダイアログ ボックスが開きます (図 6 参照)。このダイアログ ボックスで [追加] をクリックすると、コンピュータ、アドレス範囲、サブネットを追加して、コンピュータを選択できるサブメニューが表示されます。このエントリを後で見た人があなたのシステムを削除しないように、エントリを特定できるような名前、コンピュータの IP アドレス、説明を入力します (図 7 参照)。[OK] をクリックしてシステムを追加し、もう一度 [OK] をクリックして例外を追加します。設定を変更したら、変更内容を適用する必要があります。
図 6 内部ネットワークのプロパティの設定
図 6 内部ネットワークのプロパティの設定
図 7 コンピュータ名、IP アドレス、説明を入力してシステムが消去されないようにする
図 7 コンピュータ名、IP アドレス、説明を入力してシステムが消去されないようにする
もう一度、積極的な管理ツールを使用してみると、パフォーマンスが大幅に向上し、少なくともネットワーク トラフィックが原因で、接続が失敗することはありません。結局、管理ソフトウェアが確立した接続の数が問題なのではなく、接続を確立できないという状況を引き起こした接続に対して適切な計画が立てられていなかったことが問題だったということがわかりました。

得られた教訓
IT における最も大きな頭痛の種の 1 つは、本当に特定しにくい問題に直面し、それを解決しなければならないということです。その問題はエンド ユーザーが作り出したものではなく、サーバー チームに原因があるものでもなく、ヘルプ デスクが認識していないものです。そして残念なことに、それを解決するのが IT プロフェッショナルの役割です。このような問題のトラブルシューティング、分離、および解決に利用できるツールは多数ありますが、そのツールでも十分でないときがあります。ツールも間違いを犯すことがあるので、ときにはツールよりも賢くなる必要があります。
今後、明らかな原因がないのに、ネットワーク上にある複数台のコンピュータと接続を確立できなくなったときは、このコラムで説明した手順を試してみてください。ここで紹介した手順に従い、管理ソフトウェアを詳しく見て、適切な最大接続数を設定すれば、高い確率で問題を解決できるでしょう。

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


 編集長から: 会話を始める
編集長から
会話を始める
Joshua Hoffman

今までに起こった 重要な出来事のほとんどは、会話から始まりました。
「私は世界が平らだとは思いません。確かめてみた方がよいと思いませんか。」
「人を月に送り出してみませんか。」
「これらの新しいパソコンについてアイデアがあるのですが、お話できますか。」
「会ってコーヒーでも飲みましょう。」
(最後の会話はあまり重要な出来事ではありませんね。単に私がコーヒー好きなだけです。でも、一緒にコーヒーを飲んでいる間に重要なアイデアを思いつくかもしれません。)
いずれにせよ、今月は、重要なすべての出来事はいつも会話から始まるという考えが、2 つの側面からも正しいようだということをお話しましょう。1 つは、現在、ブログで、廊下で、さらには今月号の TechNet Magazine (91 ページの Romi Mahajan によるフィールド ノートのコラムを参照) でも実際に交わされている会話に関連します。それは、一般消費者向けの IT についてです。これは、私たちは単に仕事上だけでの IT プロフェッショナルではない、という考えによるものです。実際、日常生活で行っていること (チャリティ活動のボランティア、カラオケ、Xbox で遊ぶことなどすべて) が、私たちの仕事やプロフェッショナルとしての判断に影響を与えます。このことについては、ラスベガスで開催される Windows Connections カンファレンスのパネル ディスカッション「代替可能な未来」でも、Romi と共に数人の特別ゲストを招いて引き続きお話するつもりです。ぜひ、カンファレンスに直接参加するか、Web サイト (WeWantToKnow.net) をチェックしてください。また、blogs.technet.com/tnmag のブログでの会話に自由に加わってください。皆さまからのご意見をお待ちしています。
もう 1 つの側面は、こうした会話を可能にするテクノロジです。今月号の TechNet Magazine では、Exchange Server の重要な強化機能ついて検証します。この強化機能により、廊下や別の国にいても、これまで以上に簡単に Exchange Server との接続を維持できます。スタンバイ連続レプリケーションによる障害回復計画の大幅な強化、Windows Server 2008 による Exchange Server プラットフォームの強化、ユニファイド メッセージングによる会話の向上などがどのように実現されるかを含め、Exchange Server 2007 SP1 の強化点について説明します。今月の紙媒体の TechNet Magazine では、編集者の Astrid McClean と Martin McClean が用意した非常に人気のある一連のポスターの最新版を特典として提供しています。彼らが作成したすばらしい Active Directory コンポーネントのジグソー ポスターや Windows Server 2008 のポスターは、以前ご紹介したので、彼らの作品をご覧になったことがあるかもしれません。今月は Exchange Server のポスターです。では、会話を始めましょう。 —Joshua Hoffman

次のマイクロソフト技術支援スタッフに心より感謝します。Ed Banti、Anah Cameron、Chun Yong Chua、Cliff Didcock、Jeremy Kelly、Michael Murgolo、Jon Orton、Jeff Ressler、Kevin Sullivan、Jim Truher、Scot Vidican、Michael Wilson

Joshua Hoffman


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

PageDefrag ユーティリティ
2007 年 9 月号で紹介されていた SysInternals の PageDefrag ユーティリティを実行しようとしたのですが、Windows Vista® x64 では実行に失敗し、"Make sure that you are an administrator. Error loading PageDefrag driver." (管理者であることを確認してください。PageDefrag ドライバの読み込み中にエラーが発生しました。) というエラー メッセージが表示されました。
—Alex D

現時点では、PageDefrag ユーティリティは Windows Vista ではサポートされていません。このユーティリティが動作するオペレーティング システムは、Windows NT® 4.0、Windows® 2000、Windows XP、および Windows Server® 2003 のみです。9 月号の記事にこのことが明記されていなかったことをお詫びいたします。

バックアップ スケジューラ
2007 年 9 月号の記事「Windows Vista バックアップ テクノロジ ガイド」を非常に興味深く読ませていただきましたが、いくつか質問があります。この記事の図 2 の画面には次回のバックアップ日時が表示されていますが、バックアップ ツールに独自のスケジューラが含まれていない場合、次回のスケジュールは設定できないのではないでしょうか。
また、バックアップするデータはディスク ブロックへの変更に基づいて決定されるとのことですが、ディスクの最適化が実行された場合はどうなるのか教えてください。最適化によってブロックが移動または変更されるため、大量のデータがバックアップされるのでしょうか。さらにもう 1 つ、復元操作によってブロックが元の場所に復元される場合、その操作がディスクの最適化から受ける影響についてもご説明をお願いします。
—Bruce G

この情報の提供者 (著者の Christine Fok) に確認したところ、次のように説明する必要があったそうです。
図 2 の画面には次回のファイルとフォルダのバックアップ日時が表示されていますが、Complete PC バックアップでは前回のバックアップ日時しか表示されません。ファイルとフォルダ レベルのバックアップのスケジュールは設定できますが、ご指摘のとおり、Complete PC バックアップには独自のスケジューラが用意されていません。
また、ご質問にあったとおり、Complete PC バックアップを実行した後に、最適化を実行してから次の Complete PC バックアップを実行すると、前回のものよりもバックアップのサイズが大きくなる可能性があります。さらに、最適化後の復元についても、おっしゃるとおりです。Complete PC はファイル システム レベルよりも下のボリューム レベルで動作します。復元操作では、すべてのブロックをバックアップ時とまったく同じ状態に復元します。つまり、バックアップ後に最適化が実行されたかどうかにかかわらず、ブロックをディスク上のまったく同じ場所に復元します。このため、復元の完了後に再度ボリュームのバックアップが必要になる場合があります。

BGInfo ツール
2007 年 8 月号のユーティリティ スポットライト コラムを非常に楽しく読ませていただきました。特に興味深かったのは、CPU とネットワークに関する重要な情報を収集する SysInternals の BGInfo ツールです。私は、新しい製品、ユーティリティ、プログラム、またはアプリケーションの開発者に関する説明も楽しみに読んでいます。Cogswell 氏がマイクロソフトのために開発したソフトウェア製品は他にもありますか。
—Daryl B

BGInfo ユーティリティがお役に立ったようで何よりです。Bryce Cogswell は便利なユーティリティを多数開発しており、そのほとんどは Mark Russinovich と共同で開発したものです。幸運なことに、マイクロソフトは 2006 年に Sysinternals を買収したため、現在は Cogswell と Russinovich もマイクロソフトの一員です。彼らが開発したユーティリティは、すべて Sysinternals Web サイト (microsoft.com/technet/sysinternals) で提供されています。

RPC とファイアウォール
2007 年 7 月号の記事「RPC エラーのトラブルシューティング」は非常に役立ちましたが、1 つ重要なことが記載されていませんでした。それは、Windows ファイアウォールが原因で RPC エラーが発生することもあるということです。PING 要求を許可するが、不要な受信メッセージを拒否するように Windows ファイアウォールを構成している場合、コンピュータをリモートで管理しようとすると必ず失敗します。Windows リソース キットの RPCPING.exe を実行した場合、エラー 1722 ("RPC サーバーを利用できません。") が返されます。
この場合、ファイアウォールは想定どおりの動作を行います。つまり、外部のユーザーがそのシステムにアクセスできないようにします。残念なことに、管理者が企業ネットワーク上のコンピュータを管理する目的で試行したアクセスも拒否されます。
—Aaron M

RPC エラーが発生する可能性がある状況を他にもご指摘いただきありがとうございます。この記事で説明したツールが問題のトラブルシューティングに役立つことを願っています。

Windows XP のライセンス
2007 年 10 月号のフィールド ノート コラムに、Windows XP のライセンスをわずか 5 米ドルで購入できるという話がありました。私の会社は非営利目的で運営している出版社ですが、これらのライセンスを購入するにはどうすればよいでしょうか。電話か電子メールで購入できると助かります。私の環境では電子メールのやり取りはできますが、インターネットにはアクセスできません。
—Ernest B

MAR の管理パートナーである TechSoup にご連絡ください。電話 (+1-800-659-3579、内線 350) または電子メール (communitymar@techsoup.org、英語のみ) をご利用いただけます。郵送でのご連絡は、Community MAR Administrator, TechSoup Stock, 435 Brannan Street #100, San Francisco, CA 94107, United States までお願いいたします。


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

ネットワーク システムを監視する
ActiveXperts Network Monitor
activexperts.com
システム管理者であれば、ユーザーが驚いたプレーリー ドッグのように各自のパーティションから飛び出してくる前に、問題が発生したことを把握できるのが望ましいでしょう。サービスの監視は、インフラストラクチャを積極的に管理するのに重要なツールです。ActiveXperts Network Monitor は、さまざまなチェック機能を含む堅牢なソリューションです。このチェックは、LAN と WAN のどちらに対しても行うことが可能で、Windows®、Novell、および *NIX (UNIX など) サーバーに対して実行し、ユーザーから問題の報告を受ける前に問題を把握することができます。
ActiveXperts Network Monitor は、監視ステーションとして指定したコンピュータ上で、サービスとして実行される Windows ベースのアプリケーションです。このコンピュータのオペレーティング システムとしては、Windows 2000、Windows Server® 2003、Windows XP、または Windows Vista® のいずれかを実行できます。インストール後、簡単な構成ウィザードの指示に従って、電子メール通知、SMS 通知、および既定のスキャンの頻度や障害のしきい値を設定できます。また、一連のサンプル チェックを追加して、構成のサンプルとして利用できます。このサンプルにより、すぐにツールを実行し始めることができ、環境のニーズに合わせて、アプリケーションのさまざまな機能を構成する基本的な方法を学習できます。
このアプリケーションは 3 つのコンポーネントに分けることができます。Network Monitor Engine は、継続的に監視タスクを実行する Windows サービスです。Network Monitor Manager は、現在の監視状況を確認し、タスクの結果を参照して、構成を変更できる Windows アプリケーションです。また、Web インターフェイスを使用すると、タスクとタスクの結果に読み取り専用でアクセスできます。
Network Monitor Engine では、監視チェックを実行するだけでなく、通知、チェック結果により発生した動作、およびアプリケーションのログを処理します。また、マルチスレッドで実行できるので、環境に合わせて拡張できます。このサービスには、監視チェックを実行するのにエンドポイントのエージェントは必要ありませんが、リモートの Windows サーバーやワークステーションを監視するには管理者の資格情報が必要です。さいわい、複数の資格情報を指定できるので、ドメインやセキュリティ コンテキストが異なるものを監視する場合でも、監視ソリューションを実行するために全面的な権限のある単一のアカウントを用意する必要はありません。
最もよく使用するのは、おそらく Network Monitor Manager でしょう。このアプリケーションを使用すると、すべての機能と構成設定をきめ細かく制御できます。また、監視タスクをツリー形式のフォルダ構造に編成できるので、現在の UI ビューをフィルタして特定の監視タスクを簡単に調べるのに役立つだけでなく、大規模な環境ですばやく必要な項目を探し出すのにも役立ちます。
新しい監視チェックは簡単に追加できます。Network Monitor には、IP とプロトコル (ICMP、LDAP、SMTP、HTTP など) のチェック、Windows のチェック (CPU、プロセス、メモリ、ターミナル サーバーのチェックなど)、ODBC 接続、Oracle TnsPing、OLEDB クエリ ベースのデータベース チェック、Novell メンバシップのチェック、および *NIX RSH のチェックなど、約 40 個のチェック機能が組み込まれています。さらに、SensaTronics 社の環境モニタをネットワークで使うと、詳細な環境情報 （温度、湿度、水漏れなど) を監視することもできます。
このアプリケーションでは、カスタムの VBScript や Remote Shell スクリプトをサポートするので、監視タスクを必要に応じて調整することができます。このアプリケーションには、ウイルス対策プログラム、Microsoft® ISA Server、XML クエリなど、さまざまなサービスを監視する VBScript テンプレートが用意されているので、独自の監視タスクを作成する場合も、ゼロからスクリプトを記述する必要はありません。
タスクごとにチェックの頻度と障害のしきい値を設定できます。ログの記録タスクや IIS アプリケーション プールのリセットのような、他の実行中のプロセスの結果を検証する場合など、必要に応じて、特定の日時にチェックを実行するようスケジュールできます。また、指定したサービスを再起動するだけでなく、チェックが失敗したとき、または回復したときに実行する実行可能ファイル、スクリプト、およびバッチ ジョブを指定することもできます。最後に、Web インターフェイスを使用して、XSL で変換された XML 形式の結果データを表示できます。スタイルシートは、簡単に変更して、ネットワーク運用センター (NOC) やモバイル デバイス用のカスタム ビューを作成できます。また、データが XML 形式なので、他のアプリケーションや情報集約システムでも簡単に使用することができます。

価格 : 直販、5 サーバー ライセンス 395 ドル～
すぐに開始できるサンプル チェックが用意された ActiveXperts Network Monitor
すぐに開始できるサンプル チェックが用意された ActiveXperts Network Monitor

ブック レビュー
『Windows Vista Resource Kit』
microsoft.com/mspress/books/9536.aspx
Windows Vista クライアントをインフラストラクチャに導入し始める組織はますます増加しています。これに伴い、IT プロフェッショナルは、この新しいオペレーティング システムで利用できるツールを把握する必要があります。新しく出版された『Windows Vista Resource Kit』(Microsoft Press®、2007) では、企業で Windows Vista クライアントを適切に実装するのに必要な情報やツールの大部分を提供しています。インストールの自動化とボリューム ライセンス認証から、デスクトップの管理と保守、および IPv6 ネットワークとリモート アシスタンスまでのあらゆる項目を網羅しています。1,568 ページの本文に加えて、この書籍にはサポート DVD が付属しています。この DVD には、管理と展開のための 100 を超えるスクリプト、一連のデバッグ ツール、Solution Accelerator for Business Desktop Deployment (BDD)、およびその他の便利なツールが収録されています。
この書籍では、冒頭で Windows Vista の新機能を簡単に説明した後、ユーザー アカウント制御 (UAC)、BitLocker ドライブ暗号化、データ実行防止 (DEP) など、セキュリティの強化について詳しく説明しています。また、サービスのセキュリティ強化機能とカーネル修正の保護の概念についても説明しています。その後、Windows の展開に話題を移して、プロセスの自動化に役立ち、自在に使える多数のツールについて紹介します。たとえば、Windows PE 2.0 のプレインストール環境と回復環境の構成を取り上げ、企業での Windows Vista の計画と展開に関するガイドを提供する BDD 2007 について詳しく説明しています。さらに、ディスク イメージの作成と構成に関するベスト プラクティスや、Windows 転送ツールとユーザー状態移行ツールを使ってユーザー データを移行する方法に関する詳しい説明もあります。
次に、グループ ポリシーを使用したデスクトップ環境の管理について詳しく説明し、新しい XML ベースの管理用テンプレート ファイル (ADMX) についても説明しています。また、ディスクやファイル システムの管理について説明し、Windows Vista の新しい ReadyBoost と BitLocker の機能強化についても取り上げています。以前のバージョン、シャドウ コピー、およびディスク クォータのしくみを説明し、続いて、ワークグループ、ドメイン、およびアドホック ワイヤレス環境での Windows ミーティング スペースの展開方法についても説明しています。
「Desktop Maintenance」セクションでは、タスク、Windows エラー報告、パフォーマンスの監視、および Windows イベントを取り上げています。また、ヘルプ デスクでのリモート アシスタンスの使用方法も紹介しています。続いて、ソフトウェアの更新、バックグラウンド インテリジェント転送サービス (BITS)、Windows Update、および監査ツールについても説明しています。
「Networking」セクションでは、Windows ファイアウォールのしくみを詳しく紹介し、ネットワーク スタックの新しく強化された点を説明しています。また、リモート デスクトップと VPN 接続を使用して、リモート ユーザーとネットワークを構成する方法についても紹介しています。
最後に、起動、ネットワーク、ドライバのエラー、デバイスの問題など、幅広い問題のトラブルシューティングを取り上げています。マーケティング用語が多少使用されている感じはありますが、決して、つまらない話が 1,500 ページ以上続いているわけではありません。この書籍では、Windows Vista、そのツール、および Vista の管理について詳しくかつ総合的に説明しています。

価格 : 59.99 ドル (直販)

HTTP トラフィックを分析する
Charles Web Debugging Proxy
xk72.com/charles
アプリケーション、ワークステーション、サーバー、およびインターネットの間で膨大な量の HTTP ベースの通信が行われていることを考えると、優れた HTTP トラフィックの分析ツールはシステム管理者にとって非常に便利です。このようなツールは、プロキシの問題、セキュリティ上の問題、接続エラー、構成上の問題、およびアプリケーション間の通信に関する問題を特定するのに役立ちます。その 1 つが、Karl von Randow の Java ベースのアプリケーション、Charles Web Debugging Proxy です。
このアプリケーションは、他のデバッグ プロキシと同様にある種の "中間者" (man-in-the-middle) として設定されます。つまり、エンドポイント アプリケーションの間に介在し、検出したトラフィックをインターセプトして解釈します。この構成によって、暗号化された HTTP トラフィックを、復号化されたテキスト形式で参照することができます。UI では、記録されたセッションがわかりやすくまとめて表示されるので、ページ、画像、スクリプト、スタイルシートなどの基本的な要求から、サイズ、待ち時間、タイミングなどの詳細まで、さまざまな情報を確認できます。また、要求ごとに送受信されている Cookie やその内容を確認でき、すべての Cookie をブロックすることもできます。
Charles Web Debugging Proxy を使用して、要求のキャッシュに関する問題をトラブルシューティングすることができます。これは、"304 Not Modified" という応答の最新更新日を検証するか、または関連する要求や応答がこのアプリケーションを通過する際に、そこからキャッシュに関するヘッダーを削除してキャッシュを無効にすることで実行できます。このアプリケーションの書き換え設定を利用して、要求や応答がこのアプリケーションを通過する際に、さまざまな HTTP ヘッダーや本文の内容を書き換える一連のルールを定義することができます。また、DNS のスプーフィング設定を使用すると、ホストの IP アドレスを上書きして、DNS に登録されていない可能性があるアイテムに対する要求をテストすることもできます。この機能はテストで役に立ちます。たとえば、新しい Web サーバーを実際に運用する前に、そのサーバーがホスト ヘッダーを適切にリッスンして、応答しているかどうか確認できます。
また、このツールを使用して、AJAX の要求と応答をデバッグして、要求に含まれる生の XML データを確認することもできます。さらに、UI には、要求と応答の生データがテキストで表示されるので、おかしなヘッダーを見つけることができます。
このツールには、データ トランザクションを実際に確認できる Summary (概要) テーブルと Chart (グラフ) テーブルという 2 つのすばらしいデータ レイアウトが用意されています。Summary (概要) テーブルでは、要求と応答のデータをすばやくスキャンして、ヘッダーのサイズ、本文のサイズ、応答時間、応答コード、MIME の種類、およびリソースを表示できます。一方、Chart (グラフ) テーブルでは、視覚的なライフサイクル タイムラインが提供され、要求と応答のデータが発生したシーケンスの位置と、トランザクションにかかった時間が表示されるようになります。
記録セッションを保存して、後で再生したり、分析したりすることができます。この機能は、散発的な通信エラーを引き起こす、複雑な要求や応答のフローをキャプチャするのに役立ちます。キャプチャしたフローは再現できます。さらに、CSV 形式または HTTP トレース形式で、現在のセッションをエクスポートできるだけでなく、HTTP トレース ファイルを新しいセッションにインポートすることもできます。
企業のネットワークでは要求が成功するのに 56k モデムの回線では失敗する理由を探る場合など、低帯域幅での要求をシミュレーションできるように、このアプリケーションには調整機能も用意されています。この機能では、一般的な一連の初期設定から選んだり、4 つの調整点 (帯域幅、使用率、ラウンドトリップの待ち時間、および最大転送ユニット) を基に新しい初期設定を定義したりすることができます。また、デバッグ プロキシを構成して、リバース プロキシまたはポート フォワーダとして利用することもできます。このように構成すると、ローカル ポートがリモート エンドポイント (およびポート) にバインドされ、そのポートに送信されるトラフィックはすべてリモートのアドレスにリダイレクトされます。

価格 : 直販、1 ユーザー ライセンス 50 ドル～
HTTP トラフィックを分析する Charles Web Debugging Proxy
HTTP トラフィックを分析する Charles Web Debugging Proxy

不要なファイルを削除する
Wise Disk Cleaner 2
wisecleaner.com
ハード ディスクは家に似ています。時間とともに、本当は要らない物がたまっていきます。ときどき、少し時間をとって、このがらくたの大掃除をするのは良い考えでしょう。ハード ディスクの整理には、システム ツールのディスク クリーンアップ、検索機能など、組み込みの Windows ツールを使った一般的な方法があります。しかし、すばやく簡単に使えるユーティリティが適していることもあります。特に、無償で入手できる場合はそうでしょう。そのようなツールの 1 つが Wise Disk Cleaner 2 で、このツールは、ハードディスクにある厄介なファイルを探し出し、システムから安全に削除できるごみを収集します。
このツールで私がとても気に入っている点は、検出されたすべてのファイルが UI に表示されるので、潜在的な問題を簡単に突き止めることができる点です。もう 1 つの優れた機能は、確認や削除の対象にするファイルのパターンを簡単に追加できることです。また、Wise Disk Cleaner では、必要に応じてインターネット一時ファイルを削除したり、Cookie を維持するようにして Cookie に含まれているサイトの設定が失われないようにしたりすることもできます。Windows Update の更新元、最近使ったファイル、Windows およびユーザーの一時フォルダを削除できるだけでなく、Windows Update のアンインストール ファイルを削除することもできます。さらに、項目を完全に削除するか、単にごみ箱に移動するかどうかを設定して、このアプリケーションを自動実行できます。アプリケーションの活動はログに記録されるので、後で確認できます。無償ツールにしては上出来です。

価格 : 無償
安全に削除できるファイルを検出する Wise Disk Cleaner 2
安全に削除できるファイルを検出する Wise Disk Cleaner 2

ネットワーク デバイスを管理する
iReasoning Networks MIB Browser Personal Edition
ireasoning.com/mibbrowser.shtml
簡易ネットワーク管理プロトコル (SNMP) 対応のネットワーク デバイス、アプリケーション、またはシステムが、インフラストラクチャにある場合、iReasoning Networks MIB Browser を使用すれば、一連の管理情報ベース (MIB) ファイルを読み込んで、階層構造をエクスプローラと同じようなビューで参照することができます。このビューでは、オブジェクト識別子 (OID)、構文、読み取りや書き込みのアクセス権、説明など、選択したオブジェクトの詳細を確認できます。
また、UI を使用して簡単に SNMP 要求を発行して、ネットワーク デバイスからデータを取得できます。必要な作業は、デバイスの IP アドレスを入力し、MIB オブジェクトを選択して、[Go] (検索) をクリックするだけです。必要に応じて、ポート、SNMP 要求のバージョン、および読み取りと書き込みのコミュニティ文字列を設定することもできます。エージェントに変更を加えるのも同じくらい簡単です (ただし、デバイスで変更が可能な場合に限ります)。OID、データ型、および値を選択し、[OK] (OK) をクリックするだけです。さらに、トラップを発行してトラップの活動を監視できる、Trap Sender と Trap Receiver というユーティリティが組み込まれています。このトラップには、フィルタを適用して、特定のデバイスの状態を簡単に確認できます。
iReasoning Networks MIB Browser Personal Edition は無償ですが、SNMPv3 をサポートせず、同時に読み込める MIB は 5 つまでに限られます。Personal Edition の機能がニーズを満たさない場合は、追加機能が含まれ、SNMPv3、ネットワーク探索、およびデバイスの比較をサポートする Professional Edition (直販、1 ライセンスあたり 269 ドル) の購入を検討することをお勧めします。

価格 : 無償
iReasoning Networks MIB Browser
iReasoning Networks MIB Browser

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


 SQL に関する Q&amp;A: メモリの構成、パフォーマンスのプロファイル、FILL FACTOR の設定など
SQL に関する Q&A
メモリの構成、パフォーマンスのプロファイル、FILL FACTOR の設定など
Nancy Michell

メモリを構成する
ヒント : 簡略化されたプロファイル
パフォーマンス モニタを SQL Server 2005 の SQL Server Profiler と関連付けられることをご存知でしたか。
おそらく、SQL Server コンピュータのパフォーマンス モニタで、CPU 使用率の急上昇、過剰なメモリの消費、または全体的なパフォーマンスの低下に気付いて、このようなパフォーマンス異常の原因を考えたことがあるでしょう。SQL Server 2005 以前では、パフォーマンス モニタのログをキャプチャするには、まず、Profiler でトレースをキャプチャし、Enterprise Manager で sysprocesses を確認する必要がありました (もちろん、パフォーマンス モニタのログをキャプチャするには、パフォーマンス モニタを起動する必要がありました)。このような作業が必要であったにもかかわらず、パフォーマンス低下の原因を解明するには、ツール間でイベントを手動で調整する必要がありました。つまり、各ログを 1 つずつ確認する必要がありました。楽しい作業ではありませんが、パフォーマンスの問題の原因を特定するには必要な作業でした。
SQL Server 2005 では、依然としてトレースをキャプチャしてパフォーマンス モニタのログを検討する必要がありますが、Profiler でログを関連付けることができるようになりました。T-SQL ステートメントをスクロールすると、Profiler では、発生した事象が視覚的かつ自動的に表示されます。Profiler でパフォーマンス モニタのユーザー インターフェイスをクリックすると、そのタイムスタンプに関連するステートメントに移動します。この機能により、SQL Server 環境のトラブルシューティングにかかる時間を大幅に短縮できます。
パフォーマンス モニタのログを Profiler に関連付ける方法を説明します。
  1. パフォーマンス モニタを起動して、データベース サーバーの情報のキャプチャを開始します。
  2. [パフォーマンス ログと警告] ノードの下に新しいカウンタ ログを作成し、新しいログの名前を入力します。
  3. 新しいカウンタ (% Processor Time など) を追加します。[スケジュール] タブでは、手動または定期的にログ記録を開始するよう設定することもできます。
  4. [OK] をクリックします。手動オプションを選択した場合は、必ずログ記録を開始します。
  5. Profiler で SQL Server のトレースを設定します。これには、[ファイル] メニューの [新しいトレース] をクリックします。トレースには StartTime と EndTime を含めます。次に、トレースに名前を付け、ファイルに保存するよう設定します。最後に、サーバーを稼動してトランザクション処理のシミュレーションを行ってから、パフォーマンス モニタと Profiler の両方でデータのキャプチャを停止します。
  6. Profiler で、[ファイル] メニューの [パフォーマンス データのインポート] をクリックします。次に、パフォーマンス モニタのログを保存した場所を選び、[File] (ファイル) の [Open] (開く) をクリックして [Trace] (トレース) を選択します。Profiler のトレースを保存した場所を選択します。
この作業を完了すると、特定の SQL ステートメントが処理時間に及ぼした影響を簡単に把握できるようになったことを実感できるでしょう。

質問 - SQL Server™ コンピュータに最適なメモリ構成を検討しています。私の前任の管理者は、SQL Server 2000 の 2 ノード クラスタ上に 12GB の RAM を搭載した各コンピュータの Boot.ini で、/PAE は有効、/3GB は無効 (SQL Server で AWE を有効にしない) という設定をしていました。12 GB の RAM が利用できるので、Boot.ini の /3GB スイッチを削除して、AWE を有効にし、12 GB のうち約 10 GB を SQL Server に割り当てる必要があるでしょうか。コンピュータには SQL Server 以外に実行するものはなく、他のアプリケーションでメモリが必要になることはありません。
回答 - はい。Address Windowing Extensions (AWE) を有効にして、SQL Server の RAM の上限を事前に割り当てる必要があります。12 GB のメモリを搭載した SQL Server 専用のコンピュータであれば、10 GB は適切でしょう (事前割り当ては SQL Server 2000 でのみ有効で、SQL Server 2005 以降では、AWE の使用は固定的ではなくなり、その場で変更されることがあります)。/3GB スイッチと /PAE スイッチの両方を使うのか、/PAE スイッチだけで十分なのかという問題は、常に議論の的になってきました。実は /PAE スイッチを設定して AWE を有効にするだけでも十分ですが、次のような点を考慮して、両方のスイッチを利用することをお勧めします。
結局のところ、/3GB スイッチを使用するかどうかは、状況によって異なります。仮想アドレス空間の最初の 2 ～ 3 GB にあるメモリの MemToLeave 領域が不足していないかどうか。スイッチを使用した場合、オペレーション システムのメモリが不足していないかどうか (詳細については、support.microsoft.com/kb/316739 を参照してください)。クラスタを使用している場合、/3GB スイッチを一方のノードに設定し、もう一方のノードには設定しないという構成にすることができます。このような構成にすると、/3GB スイッチのテストで問題が発生した場合は、インスタンスをすぐにもう一方のノードにフェールオーバーすることができます。16 GB 以上の RAM を搭載している場合、/3GB スイッチはサポートされないことに注意してください。
/3GB スイッチを使用すると、仮想アドレス空間 (VAS) が 50% 増加するので、データ キャッシュだけでなく、VAS にメモリ負荷をかけるアプリケーションにも大きな効果があります。さいわい、IA64 と x64 の両方の 64 ビット サーバーでは、この誤解されている要因を無視します。OS のメモリ不足に関する問題は、SQL Server 専用のコンピュータの場合は当てはまりません。OS に 2 GB を割り当てるのは少々行き過ぎです。サーバーを SQL Server 専用サーバーとして使用していて、標準的な最小限の OS のサービスだけを実行している場合、サーバーに約 1.3 GB の空きメモリがあるので、SQL Server で利用できるメモリの量を 1 GB 増加できます。まず 10 GB から始めて、パフォーマンス モニタで使用可能なメモリを長期間監視して、使用されていないメモリの量を確認し、適切な値に調整します。SQL Server 2000 の AWE は SQL Server 2005 の AWE ほど動的ではないので、過剰なコミットを行うと、スワップが発生することに注意してください。/3GB スイッチを使用するかどうかを判断する鍵は、個々の環境で /3GB スイッチを使用してテストを行うことです。

レプリケーションのインスタンス名
質問 - レプリケートするインスタンスを指定する際に、SQL Server 2005 のレプリケーションでサーバーの IP アドレスを使用することはできますか。「[HOWTO] 信頼されていないドメイン間またはインターネット経由で SQL Server を実行しているコンピュータ間のレプリケート方法」(support.microsoft.com/kb/321822) によると、SQL Server 2000 では、このような操作を行うとエラーが発生するそうですが、SQL Server 2005 でも同様でしょうか。
回答 - レプリケーションに参加するサーバーのインスタンスを指定する場合は、SQL Server に登録されているインスタンス名を指定する必要があります。たとえば、コマンドラインで、レプリケーション ストアド プロシージャやレプリケーション エージェントの接続設定に対して、Publisher または Subscriber パラメータを指定する場合は、SQL Server インスタンス名を使用する必要があります。SQL Server インスタンスのネットワーク名が SQL Server に登録されているインスタンス名と異なる場合、エージェントのレプリケーション接続は失敗します。
インスタンスのネットワーク名と SQL Server のインスタンス名が異なる場合は、SQL Server のインスタンス名を有効なネットワーク名として追加することを検討してください。代替ネットワーク名を設定する 1 つの方法として、その名前をローカル ホスト ファイルに追加することができます。ローカル ホスト ファイルは、既定では、WINDOWS\system32\drivers\etc または WINNT\system32\drivers\etc にあります。たとえば、コンピュータ名が comp1、そのコンピュータの IP アドレスが 10.193.17.129、インスタンス名が inst1/instname の場合は、ホスト ファイルに次のエントリを追加します。
10.193.17.129 inst1

SQL Server Integration Services
質問 - SQL Server 2005 のアクティブ/アクティブ クラスタ (2 台のサーバーで 64 ビット Enterprise Edition を実行) のインストール中で、SQL Server 2005 のインスタンスは全部で 4 つになる予定です。すべてのインスタンスに SQL Server Integration Services (SSIS) が必要です。SSIS のクラスタ化とメンテナンス プランへの影響に関して、注意する点はありますか。
回答 - SSIS サービスをクラスタ化することはできますが、クラスタ化する必要はありません。しかも、クラスタ化により、委任がサポートされない (msdn2.microsoft.com/aa337083 参照)、複数インスタンスがサポートされない (1 つのノードで同時に実行できるインスタンスは 1 つだけ) など、さまざまな問題が発生することがあります。
以前は、メンテナンス プラン ウィザードを実行するには、SSIS をインストールする必要がありました (ただし、実行する必要はなく、単にインストールする必要がありました)。しかし、SQL Server 2005 SP1 では、この要件はなくなりました。SSIS を実行していない場合、メンテナンス プランは SQL Server エージェントで実行できます。
SSIS をクラスタ化するのではなく、SSIS をスタンドアロン サービスとして実行し、すべての実行中のインスタンスを指定するように MsDtsSrvr.ini.xml を編集することをお勧めします。このようにすると、サービスのクラスタ化に関する問題が発生することなく、あらゆるノードからパッケージを管理することが可能で、ほとんどのユーザーから期待されている高可用性を実現できます。
メンテナンス プランを作成できない場合の詳細については、サポート技術情報の記事 (support.microsoft.com/kb/909036) を参照してください。

奇妙な実行時間
質問 - SQL Server 2005 SP1 コンピュータの負荷テスト中に、SQL Server Profiler でストアド プロシージャ (SP) の実行時間に負の値が多く記録され、終了時刻から開始時刻を引いた値と一致しない SP の実行時間もありました。
回答 - SQL Server Profiler による SP の実行時間や他のパフォーマンスに関する時間のレポートは、多くの要素の影響を受けます。SQL Server 2005 では実行時間をミリ秒単位で測定します。測定単位を変更するテクノロジを利用している場合、レポート結果に矛盾が生じたり、計算の合わない実行時間が記録されたりすることがあります。
たとえば、他の電源設定、CPU ステップ実行、または AMD の Cool 'n Quiet テクノロジを使用すると、CPU の周波数が変更されるので、SQL Server Profiler で実行時間を計算した場合の値と一致しません。
この問題に関する現象、さまざまな原因、および解決策については、サポート技術情報の記事 (support.microsoft.com/kb/931279) を参照してください。
ヒント : FILL FACTOR を確認する
いっぱいまで水を入れたコップがあって、このコップにさらに水を注ごうとすると、何が起こるでしょうか。水があふれます。
SQL Server の場合も同じ現象が起こります。インデックスがいっぱいになったページに新しい行を追加すると、新しい行を挿入する領域を確保するために、SQL Server では半数の行が新しいページに移動されます。これをページ分割と呼びます。ページ分割では新しいレコード用の領域が確保されますが、この処理は、時間がかかり、多くのリソースを消費します。また、断片化を引き起こし、I/O 処理のパフォーマンスが低下することがあります。 それでは、ページ分割を回避するにはどうすればよいでしょうか。
このような状況を回避するには、FILL FACTOR の値を事前に決定する必要があります。インデックスが作成または再構築されると、FILL FACTOR の値によって各リーフ レベルのページのデータを格納する領域の割合が決まり、それ以外の領域は、今後のインデックスの増加に備えて予約されます。たとえば、FILL FACTOR の値を 60 にすると、基になるテーブルにデータが追加されるときにインデックスを拡張するための領域として、各リーフ レベルのページの 40% は空き領域として確保されます。
FILL FACTOR の既定値は常に 0 ですが、多くの場合は、これで問題ありません。基本的に、FILL FACTOR の値を 0 に設定すると、リーフ レベルのページは、ほぼ全領域がデータの格納に使用されますが、少なくともインデックスを 1 行追加するだけの領域は残されます (FILL FACTOR の値 0 と 100 は同じことです)。
CREATE INDEX ステートメントまたは ALTER INDEX ステートメントでは、FILL FACTOR の値をインデックスごとに設定できます。また、サーバー レベルで FILL FACTOR の値を直接構成して、新しく作成したインデックスで既定値が使用されるようにすることもできます。
次の例では、今後のインデックスの拡張に備えて 30% の空き領域を確保するように、サーバー レベルで FILL FACTOR の値を 70 に設定します。もちろん、このオプションは、運用環境で実装する前に、慎重にテストする必要があります。
USE Master; GO SP_Configure 'show advanced options',1; GO SP_Configure 'Fill Factor', 70; GO -- 変更を有効にするには、SQL Server エンジンを再起動する必要があります。
インデックス レベルごとに FILL FACTOR の値を設定する必要がある場合はどうでしょうか。次のようなテーブルを作成中で、Col_A という列に FILL FACTOR の値が 70 の一意のインデックスを作成する場合のコマンドは、次のようになります。
-- Item テーブルを作成します。USE Item_DB; GO CREATE TABLE ITEM (Col_A Varchar(100),Col_b Varchar(200)); GO;

-- Item テーブルの Col_A 列に FILL FACTOR の値が 70 の一意のインデックスを作成します。CREATE UNIQUE INDEX AK_Index ON Item (Col_A) WITH (FillFactor = 70); GO
各インデックスの FILL FACTOR の値を特定するにはどうすればよいでしょうか。その場合は、次のように sys.Indexes をクエリして、データベースのすべてのインデックスに設定されている FILL FACTOR の値を取得できます。
USE Item_DB; GO SELECT Fill_Factor FROM Sys.Indexes WHERE Object_id=object_id('item') AND name IS NOT NULL; GO


 ユーティリティ スポットライト: Microsoft Security Assessment Tool
ユーティリティ スポットライト
Microsoft Security Assessment Tool
Lance Whitney
この記事で使用しているコードのダウンロード: Microsoft Security Assessment Tool 3.0 (英語版のみ) (10547.2KB)

ネットワーク セキュリティ の問題をトレースするのは難しく、時間がかかるものです。セキュリティ リスクを特定して解決するのに役立つツールの 1 つに Microsoft® Security Assessment Tool (MSAT) があります。このツールは無償で利用できるユーティリティで、必要な作業は、このユーティリティが提供する電子アンケートに、ご使用のセキュリティ環境について入力するだけです。MSAT は、50 ～ 500 台のコンピュータを所有している中規模組織向けに設計され、カテゴリごとに分類された 172 の質問を提示して、ご使用の環境の分析と改善方法を提案します。
MSAT で提示される最初の質問は、ビジネス モデルに関するものです。この情報は、ご使用の環境のセキュリティ リスクを同業他社と比較して評価するビジネス リスク プロファイルの作成に使用します。このアンケートの記入には通常 2 時間ほどかかりますが、途中で中断して再開することも可能です。たとえば、次のようなカテゴリと質問があります。
基本情報 何台のクライアントとサーバーを所有していますか。
インフラストラクチャのセキュリティ リモートでアクセスする従業員はいますか。外部の契約社員はネットワークにアクセスしますか。
アプリケーションのセキュリティ アプリケーションの開発を行っていますか。開発されたアプリケーションで処理された機密データを、そのアプリケーションで保存しますか。
運用上のセキュリティ 社内ネットワークは外部のネットワークと接していますか。サードパーティからのデータの入力を受けていますか。
人材に関するセキュリティ コンピュータのメンテナンスを外部委託していますか。従業員は会社にかかわる機密データを各自のワークステーションにダウンロードできますか。
環境 従業員は何人ですか。IT 部門の離職率は高いですか。
次に、ご使用の環境で採用しているセキュリティ プロセスに着目した、多層防御インデックス (DiDI) と呼ばれる評価基準による評価を行います。ここでも同様のカテゴリが使用され、一般的な質問には以下のようなものがあります。ロケーションごとにファイアウォールを設置していますか。Microsoft Office アプリケーションでカスタム マクロを使用していますか。ユーザーはワークステーションに対して管理者権限を持っていますか。PC への修正プログラムや更新プログラムの展開に関する方針はありますか。
これらの質問への回答に対して、MSAT では 3 つのレポートを提供します。Summary Report (サマリ レポート) では結果が棒グラフで表示されます。BRP のスコアが高ければリスクが大きく、また DiDI のスコアが高ければより安全であることを示しています。MSAT で示されるように、BRP のスコアが低く DiDI のスコアが高いのが望ましい状態ですが、各カテゴリを調査することの方が重要です。そのため、Complete Report (完全なレポート) では、それぞれのカテゴリについて、ベスト プラクティスを実施しているのか、改善が必要なのか、またはひどく問題があるのかが指摘されます (図 1 参照)。
図 1 Complete Report (完全なレポート)
図 1 Complete Report (完全なレポート)
3 つ目の、Comparison Report (比較レポート) では、セキュリティで保護されている MSAT の Web サイトに結果を匿名でアップロードすることが求められます。この Web サイトに結果をアップロードすると、他社の結果をご使用の環境の結果と比べることができます。
このツールは、Microsoft Security Guidance Web サイト (securityguidance.com) または TechNet Magazine Web サイト (technetmagazine.com/code07.aspx) からダウンロードできます。

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


 The Cable Guy: ネットワーク ポリシー サーバー
The Cable Guy
ネットワーク ポリシー サーバー
Joseph Davies
このコラムは、Windows Server 2008 のプレリリース版に基づいています。記載されている内容は変更されることがあります。

Windows Server 2008 のネットワーク ポリシー サーバー (NPS) サービスは、Windows Server 2003 のインターネット認証サービス (IAS) の後継サービスです。NPS を使用すると、Windows Server 2008 を実行しているコンピュータは、リモート認証ダイヤルイン ユーザー サービス (RADIUS) サーバーおよびプロキシとしての役割を果たすことができます。RADIUS は、インターネット技術標準化
委員会 (IETF) が RFC 2865 と RFC 2866 で規定したプロトコルで、ワイヤレス アクセス ポイントなどのネットワーク アクセス デバイスの認証、承認、およびアカウンティング (AAA) の一元管理を行えるようにするものです。RADIUS サーバーはネットワーク アクセス デバイスの AAA を行い、RADIUS プロキシは、RADIUS クライアント (ネットワーク アクセス デバイス) と RADIUS サーバー間で RADIUS メッセージを転送します。
NPS には認証されたネットワーク アクセスの展開を活用したり、サードパーティ コンポーネントを拡張できるようにしたり、最新のネットワーク テクノロジやプラットフォームをサポートしたりするための、多くの機能強化が施されています。新しい NPS スナップインは、図 1 のようになります。
図 1 新しい NPS スナップイン
図 1 新しい NPS スナップイン

ネットワーク ポリシー サーバーの機能
今月のコラムでは、以前のバージョンの Windows® では提供されていない NPS の機能を紹介します。まず、ネットワーク アクセス保護 (NAP) が、ネットワークの正常性の要件を義務付けるうえでどう役立つのかを説明してから、管理、構成、IPv6 など他の要素について説明します。また、新しい NPS スナップインの機能についても紹介します。
ネットワーク アクセス保護 NAP は、Windows Server® 2008 で導入された、コンピュータの正常性の要件への準拠を義務付けるのに役立つ一連の新しいテクノロジです。このテクノロジにより、イントラネットの保護を強化できます。たとえば、正常性ポリシーでは、ネットワークに接続するすべてのクライアントに、ファイアウォールがインストールされ有効になっていることと、オペレーティング システムの最新の更新プログラムがインストールされていることを必須条件とすることができます。NAP を使用すると、カスタマイズしたポリシーを作成して、ネットワーク アクセスや通信を許可する前にコンピュータの正常性の要件を確認したり、現行のポリシーに準拠するようにコンピュータを自動的に更新したり、ポリシーに準拠していないコンピュータは、要件に準拠するまで、アクセスできる範囲を制限されたネットワークに限定したりすることができます。詳細については、microsoft.com/nap を参照してください。
NAP 展開では、NPS サーバーは、NAP 正常性ポリシー サーバーの役割を果たし、正常性登録機関 (HRA)、802.1X アクセス ポイント、仮想プライベート ネットワーク (VPN) サーバー、動的ホスト構成プロトコル (DHCP) サーバーなどの、NAP 強制ポイントに代わって NAP クライアントの正常性を評価します。また、NPS サーバーでは、クライアントに、イントラネットへのフル アクセスを与えるのか、または制限付きのアクセスを与えるのかを判断します。NPS による正常性の評価の動作は、ネットワーク ポリシー、正常性ポリシー、および NAP 設定によって異なります。
EAPHost と EAP ポリシーのサポート NPS では、拡張認証プロトコル (EAP) 認証方法の新しいアーキテクチャである EAPHost がサポートされています。この新しいアーキテクチャにより、EAP メソッドを採用しているベンダは、クライアント コンピュータと NPS サーバーの両方で、802.1X またはポイントツーポイント プロトコル (PPP) ベースの認証に対応した新しい EAP メソッドを簡単に開発して実装できます。
EAPHost は、EAP レジストリ (www.iana.org/assignments/eap-numbers) に登録されているすべての EAP メソッド、および Cisco Systems が提供している Lightweight EAP (LEAP) などの一般的なその他の認証方法のインストールと使用をサポートします。EAPHost では、同じ EAP メソッドの複数の実装が同時に共存できます。たとえば、マイクロソフトが提供している保護された EAP (PEAP) と Cisco Systems が提供している PEAP の両方をインストールして使用することができます。
EAP メソッド ベンダのために、EAPHost では、Windows XP と Windows Server 2003 向けに開発された EAP メソッドをサポートしています。また、Windows Vista® と Windows Server 2008 向けに新しい EAP メソッドを開発するための簡単な方法もサポートしています。インストール後には、ネットワーク ポリシーで、特定のネットワーク アクセス シナリオ用に必要な EAP メソッドを構成することができます。NPS のネットワーク ポリシーは、IAS のリモート アクセス ポリシーと同様です。
EAPHost アーキテクチャの詳細については、technetmagazine.com/issues/2007/05/CableGuy を参照してください。
XML 形式で保存される構成 IAS では、構成情報は Jet データベースに保存されていましたが、NPS では、構成情報が XML 形式で保存されます。つまり、ある NPS サーバーの構成情報をエクスポートして、別のサーバーにインポートするという作業が簡略化されます。構成ファイルのエクスポートとインポートは、フォールト トレラントな構成で複数の NPS サーバーの構成を同期する方法の 1 つです。NPS サーバーの構成は、netsh nps export コマンドを使用してエクスポートし、netsh nps import コマンドを使用してインポートできます。
Common Engineering Criteria への準拠 NPS には、Microsoft® Common Engineering Criteria (CEC) に準拠する必要がある環境での展開をサポートするように変更が加えられました。詳細については、microsoft.com/windowsserversystem/cer/allcriteria.mspx を参照してください。
堅牢な NPS の拡張 DLL NPS サービスは、拡張 DLL や承認 DLL を使用して拡張することができます。IAS とは異なり、このようなサードパーティ コンポーネントは NPS から隔離されています。そのため、DLL でエラーが発生しても、NPS サービスの運用や実行に影響はありません。
IPv6 のサポート NPS では、IPv6 とネイティブまたはトンネリングされた IPv6 環境での展開がサポートされています。RADIUS クライアントまたはリモート RADIUS サーバーの IPv6 アドレスを構成し、NPS サービスで、Active Directory® ドメイン サービス アカウントの認証や承認を IPv6 経由で行うことができます。
IAS と NPS の比較
Windows Server 2003 の IAS スナップインを使い慣れている場合は、NPS スナップインに加えられた以下の変更を高く評価していただけると思います。
  • リモート アクセス ポリシーが、ネットワーク ポリシーになり、[ポリシー] ノードの下に移動されました。
  • [RADIUS クライアント] ノードは、[RADIUS クライアントとサーバー] ノードの下に移動されました。
  • [接続要求の処理] ノードがなくなりました。[接続要求ポリシー] ノードが、[ポリシー] ノードの下に移動され、[リモート RADIUS サーバー グループ] ノードは [RADIUS クライアントとサーバー] ノードの下に移動されました。
  • リモート アクセス ポリシーの条件とプロファイルの設定は、ネットワーク ポリシーのプロパティの [概要]、[条件]、および [設定] タブに再編成されました。
  • 接続要求ポリシーの条件とプロファイルの設定は、接続要求ポリシーのプロパティの [概要]、[条件]、および [設定] タブに再編成されました。
  • リモート アクセスのログ フォルダは、アカウンティングという名前のノードに変更され、[ローカル ファイル] ノードや [SQL ServerTM] ノードはなくなりました。

強力な RADIUS 共通シークレットの自動生成 RADIUS 共通シークレットは、RADIUS メッセージが、同じ共通シークレットを使用して構成された RADIUS クライアント、サーバー、またはプロキシから送信されたこと確認するために使用します。共通シークレットは、パスワードや暗号化キーなど、機密性の高い RADIUS 属性の暗号化にも使用されます。強力な RADIUS 共通シークレットは、22 文字を超える、長い一連の無作為な文字、数字、および句読点で構成された文字列です。
NPS スナップインを使用すると、RADIUS クライアントの追加または変更時には、自動的に強力な RADIUS 共通シークレットが生成されるようにすることができます。この強力な共通シークレットは、メモ帳などのテキスト エディタにコピーすることができるので、同じ共通シークレットを使用してネットワーク アクセス デバイスや NAP 強制ポイントを構成することができます。
サーバー マネージャとの統合 NPS は、初期構成タスクまたはサーバー マネージャ ツールを使用してインストールできます。どちらの場合も、NPS は、ネットワーク ポリシーとアクセス サービスの役割と共にインストールします。NPS をインストールするには、[このサーバーのカスタマイズ] にある初期構成タスク ツールで、[役割の追加] をクリックします。サーバー マネージャ ツールを使用する場合は、役割の概要ヘルプを表示し、[役割の追加] をクリックします。
NPS をインストールしたら、サーバー マネージャのコンソール ツリーで [役割] ノードの下にある [ネットワーク ポリシーとアクセス サービス] をクリックして、NPS サービスの状態を確認したり、24 時間以内に発生したエラー イベントを確認したりすることができます。コンソールで [ネットワーク ポリシーとアクセス サービス] ノードを展開すると、NPS スナップインを使用して NPS を構成できます。
Netsh サポートの強化 Windows Server 2003 では、IAS の構成に使用できる AAA コンテキストの netsh コマンドは多くありませんでしたが、Windows Server 2008 の新しい netsh nps コンテキストには、コマンド ラインまたはスクリプトで NPS を構成するための多数のコマンドが用意されています。Windows Server 2008 では、netsh nps コマンドを使用して、RADIUS クライアントやリモート RADIUS サーバー、ネットワーク ポリシー、およびログを構成できるようになりました。また NAP の場合は、正常性ポリシー、システム正常性検証ツール、および修復サーバー グループを構成できるようになりました。netsh nps コンテキストのコマンドで構成されているスクリプトは、フォールト トレラントな構成で複数の NPS サーバーの設定を同期する新たな方法となります。
ネットワーク ポリシーを分離するソース タグ ネットワーク ポリシーは、特定の種類のネットワーク アクセス サーバーまたは NAP 強制ポイント (DHCP サーバーや HRA など) ごとに構成できます。これはネットワーク ポリシーを分類するソース タグになります。Windows Server 2008 ベースのアクセス サーバーと NAP 強制ポイントについては、その RADIUS メッセージにソース タグが含まれます。アクセスを要求する RADIUS メッセージを受信すると、NPS サービスは、受信したメッセージと同じソース タグを持つネットワーク ポリシーの検出を試みます。一致するポリシーがない場合、NPS サービスは、ソース タグが指定されていないポリシーの中から一致するネットワーク ポリシーの検出を試みます。
ネットワーク ポリシーと受信した RADIUS メッセージのソース タグを使用することで、異なる種類のネットワーク ポリシーを互いに分離することができます。たとえば、DHCP サーバーのネットワーク ポリシーは VPN 接続には使用されません。
Cisco ネットワーク アクセス制御との統合 NPS では、Cisco ハードウェアとネットワーク アクセス制御 (NAC) を使用する環境との統合性を強化するための機能がサポートされています。このような機能には、Host Credential Authorization Protocol (HCAP) や HCAP 条件、ポリシーの有効期限に関する条件、ネットワーク ポリシーのネットワーク アクセス保護の設定の拡張状態のサポートなどがあります。
新しいネットワーク ポリシーの条件 NPS のネットワーク ポリシーには、新しい条件が導入されました。この条件は、コンピュータ グループ、ユーザー グループ、許可されている EAP の種類、クライアントとアクセス サーバーの IPv6 アドレスを指定することを目的としています。HCAP のサポートに関しては、ロケーション グループとユーザー グループという新しい条件が導入されました。また、NAP のサポートに関しては、ID の種類、正常性ポリシー、NAP 対応のコンピュータ、オペレーティング システム、およびポリシーの有効期限という新しい条件が導入されました。
NPS スナップイン 新しい NPS スナップインでは大幅な機能強化が施されました。その結果、RADIUS クライアントやリモート RADIUS サーバー、一般的なネットワーク アクセス シナリオにおけるネットワーク ポリシー、NAP シナリオにおける正常性ポリシーと NAP の設定、およびログ設定の作成と管理が簡単に行えるようになりました。
[RADIUS クライアントとサーバー] ノードでは、RADIUS クライアント (NPS が RADIUS サーバーの役割を果たしている場合は、ネットワーク アクセス サーバー、NAP 強制ポイント、他の RADIUS プロキシ) とリモート RADIUS サーバー グループ (NPS が RADIUS プロキシの役割を果たしている場合は他の RADIUS サーバー) を構成できます。
[ポリシー] ノードでは、接続要求ポリシー (NPS サービスが RADIUS サーバー/プロキシの役割を持つかどうか)、ネットワーク ポリシー (NPS サービスが RADIUS サーバーとしての役割を果たしている場合の承認と接続に関する設定や制限)、および正常性ポリシー (NAP クライアントのシステム正常性) を構成できます。詳細ウィンドウで、接続要求ポリシーまたはネットワーク ポリシーを選択すると、NPS スナップインでは、ポリシーの条件と設定が表示されます。図 2 は、この状態を示しています。
図 2 強化された NPS スナップインの表示
図 2 強化された NPS スナップインの表示
[ネットワーク アクセス保護] ノードの [システム正常性検証ツール] ノードを使用すると、NAP 正常性要件を構成できます。また、[修復サーバー グループ] ノードを使用すると、制限を受けている NAP クライアントが VPN や DHCP NAP の強制方法を使用してアクセスできる一連のサーバーを構成できます。そして、[アカウンティング] ノードでは、NPS のアカウンティング情報の格納方法を構成できます。
NPS スナップイン には、NAP の強制方法、ダイヤルアップ接続や VPN ベースの接続、802.1X で認証されたワイヤレス接続や有線接続に必要なポリシーや RADIUS クライアントの初期構成を自動化する多数のウィザードが用意されています。NAP の強制方法については、NAP ウィザードにより、接続要求ポリシー、ネットワーク ポリシー、および正常性ポリシーがすべて自動的に構成されます。
このような一連の新しいウィザードは、NPS スナップインで NPS ノードをクリックして利用できます。NAP の強制方法のポリシーと設定を構成するには、[標準構成] ボックスの一覧の [ネットワーク アクセス保護] をクリックし、[NAP を構成する] をクリックします。VPN またはダイヤルアップ アクセスのポリシーと設定を構成するには、[標準構成] ボックスの一覧の [ダイヤルアップ接続または VPN 接続用の RADIUS サーバー] をクリックし、[VPN またはダイヤルアップを構成する] をクリックします。802.1X ワイヤレス接続または有線接続のポリシーと設定を構成するには、[標準構成] ボックスの一覧の [802.1X ワイヤレス接続またはワイヤード (有線) 接続用の RADIUS サーバー] をクリックし、[802.1X を構成する] をクリックします。
これらのウィザードでは、画面の指示に従って、選択したシナリオにおける最も一般的な構成要素を構成できます。NAP の強制方法のウィザードは特に便利なウィザードです。VPN の強制方法用の NAP ウィザードでは、接続要求ポリシーを 1 つ、ネットワーク ポリシーを 3 つ （準拠している NAP クライアント用、非準拠の NAP クライアント用、NAP 未対応のクライアント用）、正常性ポリシーを 2 つ (準拠している NAP クライアント用、非準拠の NAP クライアント用) 作成します。
新しい NAP ウィザードと RADIUS クライアント、リモート RADIUS サーバー グループ、接続要求ポリシー、およびネットワーク ポリシーを作成するための他のウィザードは、さまざまなネットワーク アクセス シナリオにおいて、NPS の構成作業を簡略化するのに役立ちます。

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


 Windows PowerShell: 各コマンドレットについて掘り下げる
Windows PowerShell
各コマンドレットについて掘り下げる
Don Jones

Windows PowerShell には、多くの管理者によって見過ごされている機能が多数あります。詳しく調査することで、驚くようなすばらしい機能を発見することができます。実際、私自身も、既に十分理解していると思っていたコマンドレットに関連した新しい機能に出会うことがあります。
私が講師を務めている Windows PowerShellTM のクラスでは、市販の「今日の格言」カレンダーにちなんで「今日のコマンドレット」というカレンダーを作成することを管理者の方々に勧めています。このようにすると、平日は毎朝 （週末はお休みです）、特定のコマンドレットの機能について学習する時間を持つことができます。Windows PowerShell には 130 個のコマンドレットが用意されています。つまり、このスケジュールに従えば、約半年で Windows PowerShell 博士になれるということです。Windows PowerShell コマンドレットについて詳しくなったら、次は Exchange Server 2007 コマンドレットについて学習することができます。
今月のコラムでは、数分の時間を費やして、さまざまなコマンドレットの詳しい機能を調査するだけで、コマンドレットについてどのようなことを発見して、何を行えるようになるのかをご紹介します。

洗練された HTML 形式のレポート
あまり知られていないコマンドレットの 1 つに ConvertTo-HTML があります。この優れたコマンドレットでは、入力オブジェクトのコレクションを受け取り、HTML 形式のテーブルに変換します。対応しているオブジェクトは、サービス、プロセス、Windows® Management Instrumentation (WMI) オブジェクトなど、基本的にすべてのオブジェクトです。この HTML を Out-File コマンドレットにパイプすると、イントラネット Web サーバーに公開できる HTML ページを入手することができます。たとえば、次のコード行を毎朝実行するようにスケジュールしたとしましょう。
Gwmi Win32_Service | Where { $_.StartMode –eq "Auto" –and $_.State –ne "Running" } | ConvertTo-HTML | Out-File C:\ServiceAlert.html
このコードにより、自動的に実行される必要があるサービスのうち実行されていないものをリストする、図 1 に示すような HTML 形式のレポートが作成されます。
図 1 実行されていないサービスに関する HTML 形式のレポート
図 1 実行されていないサービスに関する HTML 形式のレポート
もちろん、より洗練されたレポートを作成することも可能です。さいわい、ConvertTo-HTML コマンドレットでは、クリーンな HTML ファイルが生成されます。つまり、作成された HTML コードには書式を設定するタグは含まれていません。HTML の規則に従い、HTML ページには、書式設定は設定しないのが得策です (少なくとも書式設定は最低限に抑えるべきです)。書式設定が必要な場合は、外部のカスケード スタイル シート (CSS) で設定し、その CSS を HTML ファイルにリンクすることをお勧めします。このリンクも ConvertTo-HTML コマンドレットを使用して作成できます。
CSS は、HTML ファイルの <HEAD> セクションにリンクされます。ConvertTo-HTML コマンドレットのヘルプを参照すると、このコマンドレットの構文には、皆さんが見過ごしている可能性のあるパラメータがあることを確認できます。
ConvertTo-Html [[-property] <Object[]>] [-inputObject <psobject>] [-body <string[]>] [-head <string[]>] [-title <string>] [<CommonParameters>]
–head パラメータを使用すると、スクリプトの <HEAD> セクションに追加の HTML コードを指定できます。次のコマンドを実行すると、簡単にワンンライナーを変更して、HTML ファイルのテーブルに適用する書式設定を含む既存の CSS ファイルにリンクすることができます。
Gwmi Win32_Service | Where { $_.StartMode –eq "Auto" –and $_.State –ne "Running" } | ConvertTo-HTML -title "Services" -head "<link rel='stylesheet' href='styles.css' type='text/ css' />" | Out-File C:\ServiceAlert.html
ここでは、–head パラメータを使用して、HTML 出力ファイルと同じフォルダにある CSS ファイルへのリンクを挿入しました。また、–title パラメータを使用して、Web ページのタイトルを設定しました。このコマンドを実行すると、結果の HTML ファイルは図 2 のようになります。Style.CSS ファイルでは、次のような情報が指定されています。
図 2 CSS ファイルで書式設定された HTML 形式のレポート
図 2 CSS ファイルで書式設定された HTML 形式のレポート
body { background-color:#EEEEEE; } body,table,td,th { font-family:Tahoma; color:Black; Font-Size:10pt } th { font-weight:bold; background-color:#CCCCCC; } td { background-color:white; }

簡単なフィルタ処理
今月のコマンドレット
今月は、Start-Transcript と Stop-Transcript というコマンドレットのペアをご紹介します。どちらも Windows PowerShell トランスクリプトのログ記録に関連するもので、コンソール ウィンドウに表示される情報を指定のテキストに書き込むためのコマンドレットです。これは、とても単純です。処理を開始するのに必要な作業は、Start-Transcript コマンドレットを実行し、ファイル名を指定するだけです。そして、ログ記録を終了して、ファイルを閉じるのに必要な作業は、Stop-Transcript コマンドレットを実行するだけです。このコマンドレットは、アドホックなシェルの使用から正規のスクリプトまで、幅広い用途に使用できます。シェルでコマンドラインを実行したら、作成したトランスクリプト ファイルから結果をコピーして、貼り付けることができます。もちろん、トランスクリプトを編集して、その中身を実行されたスクリプトだけにすることも可能です。同僚の MVP 受賞者である Jeffery Hicks は、トランスクリプトを解析して、Windows PowerShell PS1 ファイルに変換するスクリプトを作成しました。このスクリプトは、blog.sapien.com/current/2006/11/28/powershell-transcripts.html で公開されています。

次は、Get-WMIObject コマンドレットを見てみましょう。Windows PowerShell の組み込みのヘルプに記載されている、このコマンドレットの構文は、あまり知られていない機能を示唆しています。
Get-WmiObject [-class] <string> [[-property] <string[]>] [-namespace <string>] [-computerName <string[]>] [-filter <string>] [-credential <PSCredential>] [<CommonParameters>]
Windows PowerShell を使い慣れていないユーザーには、WIM コマンドを次のように発行するというミスがよく見られます。
Gwmi Win32_NTLogEvent –comp Server2
このコマンドは、Server2 のイベント ログからすべてのイベント ログ エントリを取得します。この作業は、Server2 で処理をしてデータを転送するのにしばらく時間がかかります。また、Windows PowerShell では、非常に大きなコレクションに対して何か処理を行う際には時間がかかります。
より適切なアプローチは、必要なデータを Server2 が検索して送信するようにすることです。もちろん、この処理は、WIM Query Language (WQL) クエリを使用して行うことも可能です。このクエリの構文が難しいと感じる方もいらっしゃいますが、Windows PowerShell では、次のように –filter パラメータを使用して、WQL クエリのフィルタ処理の部分を指定することができます。
Gwmi Win32_NTLogEvent –comp Server2 –filter "EventIdentifier=1024"
このコマンドは、任意のログから、イベント ID が 1024 のすべてのイベントを取得します。フィルタの条件では、比較演算子として Windows PowerShell の –eq 演算子ではなく、= を使用していることに注意してください。フィルタの条件は、単に処理されるためにリモート コンピュータの WMI サービスに渡されているので、条件は Windows PowerShell の構文ではなく WMI 構文で指定する必要があります。
Get-ChildItem コマンドレット、Dir や Ls というエイリアスのコマンドレットなど、他のコマンドレットには –filter パラメータがあります。ほとんどの場合、-filter パラメータは、フィルタ条件を、基礎となるテクノロジに直接渡しています (私は、これを "ソース フィルタリング" と呼んでいます)。この処理は、すべてのオブジェクトを取得してから、Where-Object コマンドレットを使用してすべてのオブジェクトを確認して、不要なオブジェクトを除外するよりも、早いことが多いです。

見過ごされがちなコマンドレット
「今日のコマンドレット」というコマンドレットについて学習するアプローチは、既に知っていると思っていたコマンドレットについての理解を深めるのに効果的であるのは言うまでもありません。しかし、「今日のコマンドレット」カレンダーを推奨する別の理由は、このアプローチを使用しなければ知り得なかったコマンドレットについて学習できるからです。多くのユーザーに知られていないコマンドレットで、私が気に入っているコマンドレットに Resolve-Path というコマンドレットがあります。このコマンドレットにワイルドカードを使用したパスを指定すると、そのパスに一致する一連のファイル名とフォルダ名を返します。これは、Get-ChildItem コマンドレット (つまり、おなじみの Dir エイリアスや Ls エイリアス) と似ていますが、このコマンドレットでは、ファイル オブジェクトやフォルダ オブジェクト全体を返すのではなく、他のコマンドレットにパイプして、さらにフィルタ処理や処理を行える単純な文字列としてファイル名やフォルダ名を返します。使い方は次に示すように簡単です。
Resolve-Path C:\P*
この単純なコード行を実行すると、C:\Program Files や C:\Processes.txt のようなパスが返されます。図 3 に、このコマンドレットの使用例を 2 つ示します。
図 3 見過ごされがちな便利な Resolve-Path コマンドレットの使用例
図 3 見過ごされがちな便利な Resolve-Path コマンドレットの使用例

まずはオーソドックスなものから
「今日のコマンドレット」に取り掛かる準備ができたら、Get-Command のエイリアスである Gcm を実行してください。このコマンドレットを実行すると、Exchange Server 2007 管理シェルや PoweShell Community Extensions などのスナップインから追加したものを含め、PowerShell で認識されているすべてのコマンドレットの一覧が返されます。この一覧の先頭にあるコマンドレットを選択して、そのヘルプを確認してください (ちなみに、私の環境では、一覧の先頭にあるのは Add-Content コマンドレットで、このコマンドレットのヘルプを表示するには、次のコマンドを実行します)。
Help Add-Content –full
簡単な既定のヘルプではなく、詳細なヘルプが必要でしょう。詳細なヘルプでは、各パラメータの詳細な説明や、コマンドレットの使用例、他の情報を入手できます。少し時間を取って「今日のコマンドレット」を試してみてください (実稼働環境に影響を与えないよう、バーチャル マシンを使用することをお勧めします)。また、この作業が習慣になるように、毎日同じ時間に 10 分ほど時間を取ることをお勧めします。これが習慣になれば、あっという間に、Windows PowerShell が提供するすべての機能についての理解を深めることができるでしょう。

Don Jones は SAPIEN Technologies のリード スクリプト グルであり、『Windows PowerShell: TFM』(SAPIEN Press、2007年) の共著者でもあります。連絡先については、www.ScriptingAnswers.com にアクセスしてください。


 Hey, Scripting Guy!: 帰ってきた WinRM
Hey, Scripting Guy!
帰ってきた WinRM
Microsoft Scripting Guys

Scripting Guys が Windows® Remote Management (WinRM) についての 2 部構成のコラムの執筆に取り掛かったとき、セキュリティという 1 つの大きな問題に直面しました。私たち Scripting Guys もハリー ポッター シリーズの最終章の販売に伴う問題については知っています。先行予約された本が、うっかり早く発送されて、正式な発売日の前に配達されてしまったという問題です (結局それは問題になったのでしょうか。もちろんそんなことはなく、出版社は「発売日まで本を読まないでください」とお願いしただけでした)。
ただし、話はここからです。この最終章の発売前に、この本とシリーズの結末が漏れていました (この本をまだ読んでいないのなら、ここで結末をお教えましょう。なんとハリー ポッターは魔法使いのようなものだったんです)。さらに、本の内容をスキャンしたものが、すぐにインターネットで入手可能になり、ときには著者 J・K・ローリングもまだ書いていないページさえありました。結局のところ、これはちょっとしたセキュリティの大失敗で、Scripting Guys は自分たちの身に同じようなことが起らないようにしようと心に決めました。とにかく、もしハリー ポッター シリーズの最終章の結末をばらしてやろうと固く決意したとした人が、Scripting Guys がお届けする 2 部構成の最終回の結末を入手するのに採る手段を考えてみてください。
さいわいにも、Scripting Guys は取り締りをしっかりして、秘密を守ることができました。確かに、このコラムの締め切りをとっくに過ぎるまで、実はこのシリーズの第 2 部をまだ書いていなかったというのがそもそもの原因です。けれども、このコラムを執筆している Scripting Guy は 8 月は休暇を取っていました。彼はマイクロソフトの社員の大多数と違って、休暇中には、コンピュータを使うことはおろか、決して見向きもしないのです。
そうですね。彼は休暇中でなくても、コンピュータを使うことはおろか、めったに見向きもしません。でも、それはまた別の話です。
とにかく、この 4 週間、多くの人が WinRM の冒険談がどんな結末を迎えるのか、心配でひっきりなしに寝返りを打って眠れなかったことでしょう。しかし、そんな眠れなかった長いつらい日々とも今日でお別れです。史上初、これが Scripting Guys がお届けする WinRM に関する 2 部構成コラムのエキサイティングな結末です。ええと、結末は、こちらの図 1 を参照してください。
Figure 1 結末 (Close Figure 1)
strComputer = "atl-fs-01.fabrikam.com"

Set objWRM = CreateObject("WSMan.Automation") Set objSession = objWRM.CreateSession("http://" & strComputer)

strDialect = "http://schemas.microsoft.com/wbem/wsman/1/WQL" strResource = "http://schemas.microsoft.com/wbem/wsman/1/wmi/root/cimv2/*" strFilter = "Select Name, DisplayName From Win32_Service Where State = 'Running'"

Set objResponse = objSession.Enumerate(strResource, strFilter, strDialect)

Do Until objResponse.AtEndOfStream strXML = objResponse.ReadItem

    Set objXMLDoc = CreateObject("Microsoft.XMLDom") objXMLDoc.async=False objXMLDoc.loadXML(strXML)

    Set objElement = objXMLDoc.documentElement Wscript.Echo "Name: " & objElement.ChildNodes(0).ChildNodes(0).NodeValue Wscript.Echo "Display Name: " &  objElement.ChildNodes(1).ChildNodes(0).NodeValue Wscript.Echo Loop
ええ、わかっています。この見事なプロットの展開には、背筋がゾクゾクしますね。objElement.ChildNodes(0).ChildNodes(0).NodeValue ですよ。だれが、このような結末を予想したでしょうか。もちろん、これはセキュリティ規制の一環ですが、Scripting Guys 本人たちでさえ、このシリーズの結末をまったく知らなかったわけですから。しかし、今からその秘密が解き明かされます。
話を進める前に、第 1 部を読むことができなかった方のために、このシリーズ全体の内容を簡単に振り返っておきましょう (第 1 部は technetmagazine.com/issues/2007/11/HeyScriptingGuy で参照できます)。第 1 部では、ファイアウォールが有効な場合でも、インターネット経由でのコンピュータの管理を簡略化する新しいテクノロジである WinRM をご紹介しました。このテクノロジは、Windows Server® 2003 R2、Windows Vista®、および Windows Server 2008 で導入されています。確かに Windows Management Instrumentation (WMI) を使用してコンピュータをリモートで管理することは可能ですが、WMI はリモート管理技術として分散 COM (DCOM) に依存しています。そのこと自体には問題はありませんが、多くのファイアウォールの既定の設定では、DCOM トラフィックがブロックされます。もちろん、適切なポートを開いて、DCOM トラフィックを許可することは可能です。ただし、DCOM トラフィックを許可すると、あらゆる悪質なトラフィックに対してもポートを開くことになってしまうことが懸念されるので、ほとんどのネットワーク管理者は、そのような設定にすることを好みません。
WinRM は、WS-Management プロトコルのマイクロソフト実装です。WS-Management プロトコルは、さまざまなベンダが提供するハードウェアやオペレーティング システムの相互運用を可能にする標準的なファイアウォールに対応した SOAP ベースのプロトコルです。というのは大袈裟な言い方ですが、WinRM により、HTTP や HTTPS などの標準的なインターネット プロトコルを使用してコンピュータをリモート管理できるようになります。
先月のコラムでもお知らせしたとおり、WinRM を使用すると、リモート コンピュータに接続したり、リモート コンピュータから WMI 情報を取得したりする作業が簡単に行えるようになります。では、WinRM は、完璧なテクノロジということでしょうか。いえ、そうとは言い切れません。既に説明したように、WinRM が呼び出し元のスクリプトにデータを返すときのデータ形式は XML です。言うまでもなく、XML は、特に XML に関して経験が浅いシステム管理者にとっては、解析して活用するのが少々困難な場合があります。そのため、WinRM には、返されたデータを読みやすい形式に変換する XSL 変換が同梱されています。
それはいいのですが、XSL 変換を使用すると、出力が常に次のような形式になってしまいます。
Win32_Service AcceptPause = false AcceptStop = true Caption = User Profile Service CheckPoint = 0 CreationClassName = Win32_Service
出力が常にコマンド ウィンドウに表示されるという点を除けば、これは必ずしも悪いことではありません。ただ、既定では、データを簡単にテキスト ファイルに保存したり、データベースや Microsoft® Excel® ワークシートに保存したりすることができず、単に画面に情報を表示することしかできないということです。これでは不十分です。
それに加えて、(ネットワーク トラフィックを減らす目的などで) WMI クラスの特定のプロパティだけを返すようにしたい場合、この問題は深刻なものになります。クラスのすべてのプロパティではなく、いくつかのプロパティだけを操作する場合は、次のような情報が出力されます。
XmlFragment DisplayName = Windows Event Log Name = EventLog

XmlFragment DisplayName = COM+ Event System Name = EventSystem
面白いとは思いますが、これまで見たことがある出力の中で最も美的センスに優れているとは言えません (特に出力結果の至るところに現れる XMLFragment という見出しは美しいものではありませんね)。
では、どうしたらよいのでしょう。返された XML データを解析して書式を設定するカスタム コードを記述したらよいのでしょうか。でも、それは、システム管理のスクリプト作成者がしそうなことではなさそうです。違いますか。

重要なことは他人任せにしない
WinRM から返される XML データをそのまま使うのは、想像以上に難しい作業であることがわかりました。今月は XML データを解析して書式を設定する簡単な方法を 1 つご紹介しましょう。この方法は決して XML を処理する唯一の方法ではありません。ここでは、XSLT 変換に頼る必要がないことを説明することを目的としているので、1 つの方法を紹介すればよいのです。基本的な考え方が理解できたら、WinRM データを使ってできることに際限はありません。
ただ、問題が 1 つあります。このコラムを与えられたスペースに収めるには、図 1 に示したスクリプトの大半の説明を省略しなくてはならないのです。しかし、スクリプトの最初の 3 分の 2 については先月のコラムで詳しく説明したので、たいした問題にはならないはずです。今月は、返された値を実際に処理しているスクリプトの最後の 3 分の 1 に重点を置いて説明します。
ご覧のとおり、今月の WinRM の冒険談のエピソードは WSMan.Automation オブジェクトのインスタンスを作成し、リモート コンピュータ (ここでは atl-fs-01.fabrikam.com) をクエリし、そのコンピュータで実行中のすべてのサービスについての情報を受け取った後についてです。つまり、返された XML データを読み込んで処理する Do Until ループがあるスクリプト行からということです。このループ処理は、読み込んで処理するものがなくなるまで繰り返されます (つまり、いかにもわかったようなことを言うと、このループ処理は XML ファイルの AtEndOfStream プロパティが True になるまで続くということです)。
ここで説明しているのは次のコード行で、今月のお話はここから始まります。
Do Until objResponse.AtEndOfStream
このループでは、まず、ReadItem メソッドを使用して、返された XML データの最初のセクションを読み取ります (WinRM を使ってサービス情報を取得しているので、この最初のセクションには、コレクション内の最初のサービスに関する全データが含まれています)。このデータ (繰り返しになりますが、XML 形式のデータです) を strXML という名前の変数に格納したら、Microsoft.XMLDom オブジェクトのインスタンスを作成します。要するに、次のコード行により空の XML ドキュメントが利用できるようになったわけです。
Set objXMLDoc = _ CreateObject("Microsoft.XMLDom")
空のドキュメントが用意できたら、すぐに Async プロパティの値を False に設定し、loadXML メソッドを呼び出します。
そうすると。え、何か言いましたか。なぜ Async プロパティの値を False に設定するのかですって。それになぜ loadXML メソッドを呼び出すのか、という質問ですか。自作自演とはいえ、よい質問ですよね。
まず、Async プロパティは、スクリプトが XML 情報を非同期でダウンロードするのを許可するかどうか指示するものです。このプロパティの値が True の場合、ダウンロードが始まると、ダウンロードが完了していなくても、すぐに制御がスクリプトに返されます。確かに、とてもよい処理のように思えます。しかし、残念ながら、スクリプトは必要な情報がすべて揃ったものとして、処理を続行します。必要な情報がすべて揃っていないのに処理が続行された場合は、困ったことになります。ですから Async プロパティの値は False に設定しておくのです。
注 : そうですね、スクリプトが早すぎる段階で終了しないように、定期的にダウンロードの状況を監視するコードを記述することは可能です。それで問題を解決することはできますが、単に Async プロパティの値を False にする方が断然簡単です。そうすると、スクリプトはダウンロードが完了するまでブロックされます。つまり、ダウンロードが始まると、スクリプトはダウンロードが終わるまで気長に他の処理を行うのを待つわけです。
loadXML メソッドの処理については、ほぼ名前のとおりです。このメソッドは、整形式の XML ドキュメント (またはドキュメントの一部) を空のドキュメントに読み込みます。後は、loadXML メソッドを呼び出し、strXML 変数をメソッドの唯一のパラメータとして渡すだけです。
objXMLDoc.loadXML(strXML)
最終結果を見てみましょう。WinRM データを仮想の XML ドキュメントに変換しました。ということは、標準的な XML メソッドを使用して、この仮想ドキュメントを解析できるということです。
それには、次のコード行を使用して、XML のルート要素のオブジェクト参照を作成する必要があります。
Set objElement = objXMLDoc.documentElement
これで、お楽しみの準備ができました (もちろん、皆さんが XML ファイルの解析が楽しいことだと思えばですが。私たち Scripting Guys にとって XML の解析は間違いなく楽しいことです)。
覚えているかもしれませんが、WMI Query Language (WQL) のクエリ (または WinRM 用語で言うと "フィルタ") は次のようになります。
strFilter = "Select Name, DisplayName " & _ "From Win32_Service Where State = 'Running'"
ご覧のとおり、Win32_Service クラスの Name と DisplayName という 2 つのプロパティを要求しています (また、戻り値を実行中のサービスに限定する Where 句を含めました。しかし、これについては特に気にする必要はありません)。要求したプロパティが 2 つだということは重要でしょうか。また、要求した順序は重要でしょうか。重要かもしれません。しかし、どうしたらそんなことがわかると言うのでしょうか。
おっしゃるとおりです。おそらく、このコラムの執筆者としては、本当はこのような質問には答えられるべきでしょう。それでかまいません。結局、どちらの質問に対する答えも「はい」だとわかりましたから。WQL クエリでプロパティを 2 つ要求したことは重要でしょうか。はい、何しろ、この 2 つのプロパティ値が返される値のすべてですから (クラスのすべてのプロパティ値を返す Select * From クエリを実行するのとは対照的です)。
それでは、その 2 つのプロパティの順序も重要でしょうか。当然です。プロパティ名は指定した順序で返されます。これは、各プロパティ値がルート要素の子ノード (またはセクション) として返されるので重要です。どのプロパティ値が最初の子ノードとして返されるのでしょうか。これは簡単な質問です。この場合、最初の子ノードは、WQL クエリで最初に指定されている Name プロパティになります。では、どのプロパティ値が 2 つ目の子ノードとして返されるのでしょうか。そうです。クエリで 2 番目に指定されている DisplayName プロパティです。
ちょっと待ってください。これは自力で解決できましたか。それともだれかが、このコラムの予定原稿の内容をばらしたのでしょうか。ふうむ...。
いずれにしても、これにより、Name プロパティの値をエコー バックしやすくなります。ここで必要な作業は、次のように、最初の ChildNodes (アイテム 0) コレクションの最初のアイテム (アイテム 0) の NodeValue を参照するだけです。
Wscript.Echo "Name: " & _ objElement.ChildNodes(0).ChildNodes(0).NodeValue
では、DisplayName プロパティの値はどうやって参照するのでしょうか。この場合は、次のように 2 番目の ChildNodes (アイテム 1) コレクションの最初のアイテムの NodeValue を参照します。
Wscript.Echo "Display Name: " & _ objElement.ChildNodes(1).ChildNodes(0).NodeValue
また、WQL クエリで 3 番目のプロパティ (たとえば Status など) がある場合はどうしたらいいのでしょうか。その場合には、次のように、単に 3 番目の ChildNodes (アイテム 2) コレクションの最初のアイテムの NodeValue を参照するだけです。
Wscript.Echo "Status: " & _ objElement.ChildNodes(2).ChildNodes(0).NodeValue
最後のプロパティに至るまで同様です。
スクリプトからの出力はどのようになるのでしょうか。これは、次のようになります。
Display Name: Windows Event Log Name: EventLog

Display Name: COM+ Event System Name: EventSystem
確かに WinRM の既定の出力とそれほど変わらないようにも見えます (あの見苦しい XmlFragment の見出しは取り除きましたが)。違うのは、個々のプロパティ値を取り扱うことで、既定の書式設定に縛られる必要がないこと (ここでは、DisplayName ではなく Display Name というラベルを使用していることに注意してください)、情報の出力先がコマンド ウィンドウに限定されないことです。
Excel ワークシートにデータを書き込む方がよいですか。それは簡単です。まず、次のコード ブロックを、WinRM スクリプトの Enumerate メソッドを呼び出す行の直後に挿入します (このコード ブロックでは新しい Excel ワークシートを作成して構成します)。
Set objExcel = _ CreateObject("Excel.Application") objExcel.Visible = True Set objWorkbook = objExcel.Workbooks.Add() Set objWorksheet = objWorkbook.Worksheets(1)

i = 2 objWorksheet.Cells(1,1) = "Name" objWorksheet.Cells(1,2) = "Display Name"
そして、もともとあった Do Until ループを図 2 の Do Until ループに置き替えます。試してみて結果をご覧ください。
Figure 2 新しい Do Until ループ (Close Figure 2)
Do Until objResponse.AtEndOfStream strXML = objResponse.ReadItem

  Set objXMLDoc = CreateObject("Microsoft.XMLDom") objXMLDoc.async=False objXMLDoc.loadXML(strXML)

  Set objElement = objXMLDoc.documentElement objExcel.Cells(i, 1) = objElement.ChildNodes(0).ChildNodes(0).NodeValue objExcel.Cells(i, 2) = objElement.ChildNodes(1).ChildNodes(0).NodeValue i = i + 1 Loop

WinRM シリーズに第 3 部はあるのか
今月のコラムと先月のコラムの間に、WinRM に取り掛かる時間は十分あったことと思います。また、そうであったと願っています。WinRM は、コンピュータのリモート管理を大幅に簡略化する魅力的な新しいテクノロジです (また、作業を簡略化するだけでなく、安全性とセキュリティが確保されます)。この特徴により、皆さんの脳裏にはある疑問が浮かんでいることでしょう。WinRM の冒険談には第 3 部があるのか、という疑問です。
大変申し訳ありませんが、その情報はお教えできません。セキュリティ上の問題があるからではなく、単に Scripting Guys の相変わらずの企画立案と意思決定プロセスのせいで、WinRM の他の側面について何かを書くのかどうかについては、まったくわからないのです。でも、よく言いますよね、チャンネルはそのままでって。
Dr. Scripto のスクリプト パズル
Dr. Scripto はちょっとしたアクシデントに見舞われていました。彼が作成したスクリプトの 1 つを放置していたら (優秀なスクリプト作成者なら片付けているのでしょうが)、うっかりつまずいて、スクリプトの断片をあちこちにばらまいてしまったのです。変数、キーワード、記号などは、なんとかすべて見つかり、きちんとアルファベット順に並べるところまではできたのですが、スクリプトを 1 から組み立て直さなくてはなりません。この作業にはしばらく時間がかかると思いますが、彼は来月の TechNet Magazine の発行日までには、答えを用意しておくつもりのようです。それまでに、よかったら、この一見ばらばらなスクリプト要素を 1 つの完全なスクリプトに並べ替えてみてください。健闘をお祈りします。
ヒント : 少しだけお教えしましょう。最終的なスクリプトは、指定の日付より古い日付のファイルをローカル コンピュータからすべて削除します。

Dr. Scripto のスクリプト パズル
解答 : 「不器用な Doctor Scripto」、2007 年 12 月
Dr. Scripto はスクリプトを元どおりに組み立てることができました。次のスクリプトが、彼が再構築した、指定された日付より古い日付のファイルをローカル コンピュータからすべて削除するスクリプトです。
strDate = "20060102000000.000000+000"

strComputer = "."
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")
Set colFiles = objWMIService.ExecQuery("Select * From CIM_DataFile Where CreationDate < '" & strDate & "'")
For Each objFile in colFiles
    Wscript.Echo objFile.Name
Next

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


 セキュリティ ウォッチ: Windows ドメインのパスワード ポリシー
セキュリティ ウォッチ
Windows ドメインのパスワード ポリシー
Derek Melber

Windows ドメインの管理者であれば、ドメイン ユーザー アカウントのパスワード ポリシーの制限について十二分に知っていると思います。しかし、Windows Server 2008 の到来によって、そういった制限のうちのいくつかはなくなるでしょう。この記事では、複数のパスワード ポリシーを実装できないという問題が、この新しい OS によってどのように解決されるかについて説明します。
現在の Windows® ドメインのバージョン (Windows NT®、Windows 2000 Active Directory®、および Windows Server® 2003 Active Directory) では、1 つのドメインに適用できるパスワード ポリシーは 1 つに制限されます。実際には、パスワード ポリシーだけでなく、アカウント ポリシーに該当する、より広範囲の設定が制限されます。図 1 は、これらのポリシーと設定を示しています。
Figure 1 アカウント ポリシー (Close Figure 1)

パスワード ポリシー
パスワード履歴を記録する
パスワードの有効期間
パスワードの変更禁止期間
パスワードの長さ
パスワードは、複雑さの要件を満たす必要がある
暗号化を元に戻せる状態でパスワードを保存する
アカウント ロックアウトのポリシー
ロックアウト期間
アカウントのロックアウトのしきい値
ロックアウト カウンタのリセット
Kerberos ポリシー
ユーザー ログオンの制限を強制する
サービス チケットの最長有効期間
チケットの最長有効期間
ユーザー チケットを更新できる最長有効期間
コンピュータの時計の同期の最長トレランス
既定では、これらのポリシー設定は、ドメインに関連付けられたすべてのドメイン ユーザー アカウントに適用されます。これは、グループ ポリシーが Active Directory 構造の下の階層へと継承されていくためです。これらのポリシーがドメイン ユーザー アカウントとローカル ユーザー アカウントに与える影響を理解するには、これらのポリシーが設定される場所と、グループ ポリシーの継承がさまざまな種類のユーザー アカウントに与える影響を理解することが重要です (Kerberos のポリシー設定はドメイン ユーザー アカウントのみに適用されることに注意してください。これは、ドメイン ユーザー アカウントのみが認証に Kerberos を使用するためです。ローカル ユーザー アカウントは、認証に NTLMv2、NTLM、または LM を使用します)。

アカウント ポリシーを設定する
Active Directory 内では、グループ ポリシーによってドメイン全体のアカウント ポリシーが設定および制御されます。ポリシーは、Active Directory ドメインを最初にインストールしたときに、Active Directory のドメイン ノードにリンクされた既定のグループ ポリシー オブジェクト (GPO) によって適用されます。既定のドメイン ポリシーという名前のこの GPO には、アカウント ポリシーの 3 つのセクションに含まれているすべての構成の既定値が格納されています。図 2 は、Windows Server 2003 ドメインで適用されるパスワード ポリシーのすべての項目の初期設定を示しています。
図 2 Windows Server 2003 ドメインの既定のパスワード ポリシー
図 2 Windows Server 2003 ドメインの既定のパスワード ポリシー
この GPO の設定により、すべてのドメイン ユーザー アカウントと、すべてのドメイン コンピュータのアカウント ポリシーが制御されます。すべてのドメイン コンピュータ (デスクトップとサーバー) には、ローカル セキュリティ アカウント マネージャ (SAM) があります。既定の GPO の設定によって制御されるのは、この SAM です。もちろん、ローカル SAM には各コンピュータのローカル ユーザー アカウントが格納されています。
GPO が Active Directory 構造の下の階層に正しく継承されていくことで、既定のドメイン ポリシーの設定がすべてのドメイン コンピュータに適用されます。この GPO はドメイン ノードにリンクされているため、ドメイン内のすべてのコンピュータ アカウントにこの GPO の設定が適用されます。

現在のパスワード ポリシーでは不可能な操作
現在の Active Directory (Windows Server 2003) の実装でのパスワードの制御に関しては、さまざまな誤解があります。しかし、この実装は何年もかけて綿密にテストされたものであり、そのような誤解が正しいことを示す証拠もありません。ポリシーが設計以上の動作をしないことは明らかであり、またそうでなければなりません。
とはいえ、多くの管理者は同じドメインでユーザーに複数のパスワード ポリシーを適用することができると思っています。GPO を作成して、組織単位 (OU) にリンクさせることができると考えているのです。つまり、ユーザー アカウントをその OU に移動すれば、GPO の設定がそれらのオブジェクトに適用されるという考え方です。彼らは GPO 内のアカウント ポリシーを変更 (たとえば、最大文字数を 14 文字に設定) し、より高度なセキュリティで保護されたパスワード ポリシーを作成します。しかし、いくつかの理由により、この構成では目的の結果を得ることはできません。まず、パスワード ポリシーの設定はユーザー ベースのポリシーではなくコンピュータ ベースのポリシーです。このことを踏まえれば、これらの設定がユーザー アカウントに適用されないことは明らかです。2 つ目に、ドメインにリンクされた GPO 内の設定を変更しなければ、ドメイン ユーザー アカウントに適用するアカウント ポリシーの設定を変更することはできません。アカウント ポリシーの設定を変更するように構成された GPO が OU にリンクされた場合、その OU またはサブ OU 内のコンピュータのローカル SAM が変更されます。
2 つ目の誤解は、ルート ドメイン (Active Directory フォレストの最初のドメイン) に適用されたアカウント ポリシーの設定が、フォレストの子ドメインまで伝達または継承されるというものです。これも事実ではなく、アカウント ポリシーの設定をこのように動作させることはできません。GPO がリンクされているドメインがルート ドメインだとしても、ドメインとドメイン内の OU にリンクされている GPO の設定は、別のドメインのオブジェクトには適用されません。GPO の設定を異なるドメインのオブジェクトに適用する唯一の方法は、GPO を Active Directory サイトにリンクすることです。

パスワードに関する新機能
先ほど説明したように、Windows の現在のバージョンでは、ユーザー アカウントのパスワードが非常に単純な方法で処理されています。たとえば、すべてのドメイン アカウントにパスワードに関するルールを 1 種類だけ適用することや、Active Directory のドメイン ノードにリンクされたグループ ポリシー オブジェクトを使用してアカウント ポリシーを管理することなどが当てはまります。Windows Server 2008 では、これらの方法はまったく使用されません。
Windows Server 2008 および付属の Active Directory インフラストラクチャでは、異なる方法が使用されます。アカウント ポリシーを GPO 内で管理する (つまり、すべてのドメイン ユーザー アカウントに設定できるポリシーが 1 つだけである) のではなく、Active Directory のより深い階層で管理します。さらに、アカウント ポリシーはコンピュータ アカウントに基づいて適用されなくなります。個々のユーザーまたはユーザー グループを対象にして、パスワードの制限を制御できるようになったのです。アカウント ポリシーは、長年の間コンピュータ アカウントに基づいて管理されてきたため、Windows 管理者にとってこれはまったく新しい考え方です。

Windows Server 2008 のアカウント ポリシー
Windows Server 2008 では、アカウント ポリシーの設定に既定のドメイン ポリシーを使用しません。もっと言えば、ドメイン ユーザー アカウントのアカウント ポリシーの作成に GPO を使用しません。Windows Server 2008 では、Active Directory データベースに直接変更を加えます。具体的には、ADSIEdit などのツールを使用して、Active Directory オブジェクトとそれに関連する属性を変更します。
このように変更された理由は、同じドメイン内で複数のパスワードを保持するという機能にグループ ポリシーの設計が対応していないためです。Windows Server 2008 では、1 つのドメイン内で複数のパスワードを実装できるという素晴らしい機能が提供されますが、まだまだ皆さんに気に入っていただけるほど使い勝手はよくありません。しかし、いずれ設定を構成するインターフェイスへのアクセスは容易になっていくでしょう。今のところは、ヘルメットをかぶって Active Directory データベースに侵入し、必要な変更をシステムに加える必要があります。
他の方法でアカウント ポリシーを変更したい場合は、ADSIEdit を使用する必要はありません。Active Directory データベースに変更を加えることができる他の LDAP 編集ツールを使用したり、スクリプトを使用したりすることもできます。Windows Server 2008 では、パスワード ポリシーを実装する際に、今までとはまったく異なる方法を使用する必要があります。また、この新機能の導入により、どのユーザーとグループにどのパスワードの設定を適用するかを考慮することが必要になりました。
パスワードの長さだけでなく、変更禁止期間と有効期間、履歴など、パスワード ポリシーの設定に付随するその他の制限についても考慮する必要があります。他の考慮事項には、ユーザーのロックアウト ポリシーや Kerberos に関する設定の制御方法などがあります。現在のアカウント ポリシーの設定と Windows Server 2008 の Active Directory データベースに格納されるアカウント ポリシーの設定は一対一で対応していますが、ポリシーの各設定は Active Directory オブジェクトと Active Directory 属性になるため、名前が変わります。
新しいパスワードの設定を実装するには、msDS-PasswordSettings という名前のパスワード設定オブジェクト (PSO) を [Password Settings] (パスワード設定) コンテナ (LDAP パスは "cn=Password Settings,cn=System,dc=domainname,dc=com") の下に作成する必要があります。作業しているドメインのドメイン機能レベルを Windows Server 2008 に設定する必要があることに注意してください。この新しいオブジェクトのいくつかの属性 (図 3 参照) に情報を指定します。
Figure 3 Active Directory のパスワード属性 (Close Figure 3)

Active Directory 属性の名前 | 属性の説明
msDS-PasswordSettingsPrecedence | 異なるパスワード ポリシーが適用された複数のグループにユーザーが属している場合に優先される設定を指定します。
msDS-PasswordReversibleEncryptionEnabled | 暗号化の復元が有効か無効かを切り替えます。
msDS-PasswordHistoryLength | 他の一意のパスワードに何回変更されたらそのパスワードを再利用できるかを指定します。
msDS-PasswordComplexityEnabled | 指定された文字数と文字の種類をパスワードに使用することを要求します。
msDS-MinimumPasswordLength | パスワードの最短の長さを指定します。
msDS-MinimumPasswordAge | パスワードを変更する前に、ユーザーがそのパスワードを使用しなくてはならない期間を指定します。
msDS-MaximumPasswordAge | パスワードの変更を要求される前に、ユーザーがそのパスワードを使用できる期間を指定します。
msDS-LockoutThreshold | ユーザー アカウントがロックアウトされるまでに誤ったパスワードを入力できる回数を指定します。
msDS-LockoutObservationWindow | 無効なパスワード カウンタがリセットされるまでの時間を指定します。
msDS-LockoutDuration | 誤ったパスワードの入力回数がしきい値を超えた場合にアカウントがロックアウトされる期間を指定します。
ご覧のとおり、アカウント ポリシーの設定に関連するすべてのグループ ポリシー設定に対応する属性が用意されています。優先順位の設定があることにも注意してください。この設定は、同じドメインに複数のパスワードを実装するためには不可欠です。理由は、複数のパスワードを実装すると、必ず競合が発生し、これを処理するためのメカニズムが必要になるためです。

アカウント ポリシーの設定の適用先を決定する
作成したオブジェクトごとに属性の値をすべて指定して、各ユーザーに適用するアカウント ポリシーを作成する必要があります。新しい属性の 1 つである msDS-PSOAppliesTo には、一連のポリシー設定を適用するオブジェクトを指定します。これは、特定の設定を特定のユーザーに適用できるすばらしい属性です。この属性の値には、ユーザーまたはグループのどちらを指定することもできますが、アクセス制御リストを作成する場合と同様に、ユーザーではなくグループを指定することをお勧めします。これは、グループの方が安定性が高く、確認しやすく、一般的にずっと扱いやすいためです。

立ち上がって喝采を送りましょう
長年にわたって、同じ Active Directory ドメイン内で複数のパスワードを使用できるようになることが望まれてきましたが、それが今実現されました。パスワードに関しては、ドメイン全体のすべてのユーザーに同じレベルのセキュリティを適用する必要はなくなります。たとえば、通常のユーザーには 8 文字のパスワードを割り当て、(管理者特権を持つ) IT プロフェッショナルには、より複雑な 14 文字のパスワードを割り当てることができます。
Active Directory データベースを編集することによってアカウント ポリシーの設定を構成または変更する作業に慣れるには、しばらく時間がかかるでしょう。しかし幸運にも、新しい設定は、皆さんが既に使い慣れている設定に似ています。Windows Server 2008 を手に入れたらすぐにこの新しい設定を探してみてください。これらの設定は、最初の構成を行う際に見つけることができるはずです。

Derek Melber は、MCSE、CISM、および MVP の資格を持つ独立コンサルタントであり、トレーナーでもあります。Active Directory、グループ ポリシー、セキュリティ、デスクトップ管理などに重点を置いた、マイクロソフト テクノロジの教育および普及活動を行っています。Derek は、『Microsoft Windows Group Policy Guide (Microsoft Press、2005)』など、IT に関連するいくつかの書籍の執筆にも携わっています。彼の連絡先は derekm@braincore.net (英語のみ) です。


 デスクトップ ファイル: 仮想世界で Windows を展開する
デスクトップ ファイル
仮想世界で Windows を展開する
Wes Miller

仮想コンピューティングは至るところで利用されています。まだ利用していないとしたら、利用すべきです。仮想化を使用すると、実質的には専用のハードウェア アブストラクション レイヤが作成され、1 つ以上のゲスト システム (Windows Server オペレーティング システムや Windows クライアント オペレーティング システムなど) をホスト システム間で移動できるようになるため、ハードウェアへの依存が軽減されます。
もちろん、仮想化はゲストのプロセッサを模倣しないため、エミュレーションとは異なります。仮想化では、単に、ゲスト システムからホスト システムのリソースにアクセスできるようになるだけです。このため、ホスト システムはゲストに対して汎用的になります。一般に、ある OEM によって構築されたシステムから別の OEM によって構築されたシステムに仮想ゲストを移動できます。通常、ホストのハードウェアは問題になりません。ただし、注意しなければならないことがあります。たとえば、ある CPU ベンダ (AMD など) のプロセッサが搭載されたハードウェアから別の CPU ベンダ (Intel など) のプロセッサが搭載されたハードウェアにゲストを移動する場合、(使用している仮想化テクノロジによっては) 問題が発生することがあります。これは、仮想コンピューティング テクノロジではホストとゲストが情報のみを受け渡しするためです。(たとえば、古いバージョンの PowerPC ベースの Macintosh 上で実行されている Microsoft® Virtual PC で行っていたように) ゲストの特定の CPU のエミュレーションが行われることはありません。
ただし、仮想化では、ゲストに対して主要なハードウェア コンポーネントのエミュレーションが行われます。ほとんどの場合、このようにエミュレーションが行われるハードウェア コンポーネントは、ネットワーク、ビデオ (通常、高度な GPU はエミュレーションが行われないため、デバイスの機能は大きく制限されます)、および大容量記憶装置に限定されます。これらのコンポーネントはすべて、ソフトウェアによってエミュレーションが行われる 1 種類以上のデバイスをゲストに提供することによって動作します。私のコラムを何回かお読みになっていれば、今挙げたデバイスは Windows® PE でサポートされているデバイスと同じであることにお気付きになるでしょう。仮想化された Windows を実際に動作させる場合も、これらの種類のデバイスが必要です。さらに、あらゆる仮想化テクノロジでは BIOS のエミュレーションを行う必要があります。仮想化テクノロジでは、拡張ファームウェア インターフェイス (EFI) のエミュレーションを行うこともできますが、現在、EFI ベースのオペレーティング システムは限られているため、EFI のエミュレーションを行うという方法はあまり使用されません。こうしたエミュレーションをすべて行うことにより、仮想ゲストを起動することができるようになります。BIOS と各デバイスはソフトウェアで実際のデバイスのエミュレーションを行うことで、そのデバイスをゲストに提供します。したがって、実際のデバイスに必要なドライバ (Windows によって提供されるドライバとは限りません) と同じドライバが必要になります。これは重要な考え方であるため、覚えておいてください。
一部の仮想化テクノロジでは USB (USB 2.0) デバイスとインターフェイスを取ることができるものもありますが、ここでそれらのテクノロジを詳しく説明するつもりはありません。ドライバ (プリンタ、USB ワイヤレス NIC など) や特定の DirectX® のサポート (ほとんどの仮想化テクノロジでは提供されません) を必要とするものを除けば、USB デバイスを動作させるために必要な作業は、あまり多くありません。当然ながら、USB デバイスやエミュレーションが行われない他のデバイスがサポートされているかどうかは、使用している仮想化テクノロジによって異なることに注意してください。新しいデバイスを仮想化製品で使用する際は、その仮想化製品の制限事項 ("鋭い刃"、とでも呼ぶことにします) を知っておくようにしてください。
現在、Windows で使用できる仮想化テクノロジの主要なベンダとしては、マイクロソフトと VMware (vmware.com) の 2 社があります。この他にも、Parallels (parallels.com) など、成長が期待できるベンダがあります。
ここまでの説明で、仮想化の概要をご理解いただけたと思います。このコラムの残りの部分では、仮想システムの設定方法、よく発生する問題の回避方法、および使用中の環境で複数のコンピュータに仮想システムを展開する方法について説明します。

仮想システムの展開
仮想システムの展開と物理システムの展開に違いがあるべきではありません。しかし、後で説明しますが、異なる展開になる十分な理由があるのです。
Windows NT® の発売当初は、セットアップを使用して展開を行う必要がありました。この操作はスクリプトを使用して行うこともできましたが、すべてのプロセスを実行する必要がありました。セットアップが完了しても、そのイメージを複数のシステムにコピーすることは (便利な考え方ですが) できませんでした。
しかし、マイクロソフトは最終的に、ディスク複製される ("クローン化される") Windows NT システムをサポートすることが理にかなっていると判断しました。そのため現在では、物理システムを展開する場合に使用できる方法はすべて、仮想システムの展開でも使用できます。Winnt32 (Windows Vista® や Windows Server® 2008 の場合は setup.exe) や Windows PE (以前のコラムで説明したように、展開するクライアントに応じて 1.x または 2.x のいずれかを使用します) を使用できます。また、リモート インストール サービス (RIS)、Windows 展開サービス (WDS)、または Sysprep (Windows NT 4.0 で導入された、展開用のシステム準備ツール) も使用できます。さらに、お好みのディスク複製テクノロジ (ImageX など) を使用することもできます。
当然ながら、これを行う必要があるのは、特定の OS を最初に展開するときだけです。その後は、単に作成したイメージをコピーするだけで済みます。しかし、今説明したようなディスク ベースの複製方法には問題があります。

Sysprep を使用する
最初にマイクロソフトがディスク ベースの複製をサポートしないことを決めた主な理由は、Windows NT のセキュリティ識別子 (SID) でした。さいわい、Sysprep を使用すれば、この問題を解決することができます。しかし、まずはこれがどのような問題であるかを見ておきましょう。support.microsoft.com/kb/314828 で説明されているように、SID の構成要素の 1 つは、Windows ベースの個々のコンピュータを識別する、SID 構造体のリビジョン番号 (通常はグローバル一意識別子 (GUID) と呼ばれます) です。このリビジョン番号を基に、すべてのローカル アカウントの識別子が生成されます。各ローカル アカウントは、相対識別子 (RID) と呼ばれる一意の識別子を持っています。RID は、SID の末尾に付加されるアカウント ID です。したがって、2 つを組み合わせるとローカル アカウントの識別子になります。
では、Administrator の SID である S-1-5-21-191058668-193157475-1542849698-500 を使用して、なぜこれが問題なのかを考えてみましょう。この例の S-1-5 は、これが SID であることを示す記述子 (S はすべての SID のテキスト表現に使用されます) で、1 と 5 はそれぞれ、Windows NT SID のリビジョン番号と権限識別子の値 (この例では Windows セキュリティ) を表します。残りの部分 (500 を含む) は実際の SID であり、この部分から、これが既知の SID (Windows Administrator アカウント) であることが特定できます。すべての Windows インストールで既定で作成される Administrator アカウント (削除することはできません) の SID は、末尾が 500 です。インストール後に Windows に追加されたローカル ユーザー アカウントは、末尾が 1000 以上になります。
Windows Sysinternals (私が以前書いた、PSTools についてのコラム technetmagazine.com/issues/2007/03/DesktopFiles で言及しました) から入手できる PsGetSid を使用すると、システムに登録されている特定のユーザーの SID や、システムの SID を一覧に表示することができます。図 1 は PsGetSid の出力を示しており、私の仮想システムの SID、および私のユーザー アカウント 1003 の SID が表示されています。
図 1 PsGetSid の出力 (仮想システムの SID とユーザー アカウント 1003 の SID)
図 1 PsGetSid の出力 (仮想システムの SID とユーザー アカウント 1003 の SID)
ローカル アカウントの RID はこの SID に基づいているので、システムのディスク複製や単なるバーチャル マシン イメージのコピーを実行したときに発生する問題は、比較的わかりやすいと思います。SID を変更しないと、各 Windows システムの一意性を維持する主要なコンポーネントのコピーをそのまま使用することになります (Sysprep のタスクは他にもありますが、SID の変更は Sysprep の主要なタスクです)。システム A とシステム B の Administrator の SID が同じである場合、まったく同じユーザーが各システムに正当に存在することになります。システム B のローカル アカウントがシステム A に対して認証を行う場合、およびその逆の場合も、同じことが当てはまります。さらに悪いことに、これらのシステムの SID は、まったく同じものとして Active Directory® で認識されます。そのため、システム A にドメイン リソースへのアクセスを許可し、システム B には許可しなかった場合、矛盾が生じます。B を拒否するように設定すると、実際は A も拒否されます。
したがって、特に仮想システムのシナリオでは、あまりにも簡単にシステム イメージを展開できてしまうため、必ず Sysprep を使用してシステム上の SID を再生成する必要があります。また、サードパーティ製の SID 変更ツールは使用せず、Sysprep を使用するようにしてください。Sysprep は、マイクロソフトが設計、テスト、およびサポートを行っている、システム (仮想システムを含む) を複製用に準備するためのツールです。図 2 は、システム上の SID を変更する前の Sysprep の画面の例を示しています。次の手順としてシステムの複製の準備を行う場合、必ず [セキュリティ識別子を再作成しない] チェック ボックスをオフにしてください。
図 2 複製の準備を行う場合は [セキュリティ識別子を再作成しない] チェック ボックスをオフにする
図 2 複製の準備を行う場合は [セキュリティ識別子を再作成しない] チェック ボックスをオフにする
Sysprep を使用すると、SID が新しい ID に更新されるだけでなく、Sysprep が認識したすべてのプライベート データ ストアに SID とコンピュータ名の変更が反映されます。また、暗号化も新しい SID で機能するように変更されます。たとえば、スケジュールが設定されたタスクのデータ ストア、IIS メタベース内の値 (IIS がインストールされている場合) などが変更されます。
また、Sysprep を実行すると、システム上のすべての NIC とその NIC 用のネットワーク構成データも強制的に削除されます。ネットワーク構成はレジストリ内の NIC に "ぶら下がった" 階層にあり、この NIC の関係 (仮想システム間の移動でなければ壊れることが多い) は NIC のハードウェア ID に基づいているため、Sysprep を実行すると、従来は残ったままになっていたこのデータが削除されます。
また、Sysprep を実行すると、システムから Active Directory のメンバシップに関する情報がすべて削除されます。したがって、Sysprep を実行すると、処理の一環として、システムは強制的にドメインから削除されます。これにより、SID が新しくなったシステムは、安全にドメインに参加できます。一部の SID 変更ユーティリティでは、コンピュータをドメインから削除することなくコンピュータの SID を変更できますが、この方法は信頼性と安全性に欠けています。やむを得ず、ドメインに参加しているコンピュータで Sysprep を実行する必要がある場合は、Sysprep を実行する前にこのコンピュータをドメインから削除するか、Sysprep を実行してこの作業を行います。
これに関連しますが、ドメイン コントローラ (DC) を仮想化する場合は、DC に昇格しておらず、ドメインにも参加していない、スタンドアロンのサーバー システムを複製する必要があります。Windows Server 2003 Small Business Server Edition を除き、DC を安全にディスク複製することはできません。新しい DC を安全に作成するには、ドメインに参加して DC に昇格する準備が整っているサーバーのディスク イメージを作成する必要があります。Sysprep を使用しても、DC 上の SID が安全に変更されない可能性があります (単一フォレストで単一サーバーという非常に特殊な SBS インスタンスの場合を除きます)。
最後に、Sysprep を実行すると、SID が変更され、コンピュータがドメインから削除されるだけでなく、コンピュータの名前も変更されます。
仮想システムのイメージを作成する場合は (または、単に仮想システムをコピーする場合でも) 上記の作業をすべて実行する必要があると言うと、過酷に思われるかもしれません。しかし、特にこれらのシステムをネットワーク上で他の物理システムや仮想システムと共に使用したり、ドメインで使用したり、ネットワーク上でこれらのシステム自体のコピーと共に使用する場合、上記の作業は不可欠です。
仮想システムの複製に Sysprep を使用しなかった場合、ほぼ確実に、言わずと知れたいくつかの問題 (Active Directory ネットワークやその他のネットワークでの競合) や、多くの予期しない問題が発生するでしょう。たとえば、仮想イメージはハッキングの被害を非常に受けやすいという特徴があります。これは、1 つの仮想イメージのハッキングに成功した場合、他の仮想イメージにもアクセスできるようになるためです。

ドライバとハードウェア アブストラクション レイヤ
仮想イメージに含まれる仮想デバイスのドライバが Windows に付属していない場合もあるということは既に説明しました。異なる記憶域バス ドライバを使用するコンピュータに仮想イメージを移動すると、物理ハードウェアを扱うときと同じように、非常に簡単に恐怖の 0x0000007B ドライバ エラーが発生するため、展開を行う (Sysprep を使用してディスク イメージを展開する) 際は、使用しているデバイス用のドライバを用意しておいてください。同じことが NIC にも当てはまります。ほとんどの仮想化製品は、ある程度汎用的な仮想デバイスを提供するように設計されていますが、追加のドライバが必要になる場合もあります。
また、厄介なハードウェア アブストラクション レイヤ (HAL) も無視することはできません。使用している仮想化テクノロジでサポートされている場合は、Advanced Configuration and Power Interface (ACPI) マルチプロセッサ (intel.com/technology/iapc/acpi を参照してください) がサポートされているバーチャル マシンを作成することが理想的です。通常、HAL 間での変換はサポートされていません (詳細については、support.microsoft.com/kb/309283 を参照してください)。しかし、一部の仮想化テクノロジでは (さらに重要なことに、多くの移動テクノロジでは)、ACPI に対応していない Windows インストールを ACPI に対応しているインストールに安全に移動でき、その逆も可能であることを保証しています。これは真実ではありません。さらに、このようにして移動した Windows インストールで問題が発生した場合、マイクロソフトによるサポートを受けることはできません。つい先ほど紹介したサポート Web ページで説明されている制限は、仮想化されたシステムにも当てはまります。図 3 は、私のバーチャル マシン (この例では ACPI ユニプロセッサ HAL を使用して実行されています) のデバイス マネージャで HAL を確認したときの画面を示しています。ここではユニプロセッサ HAL を使用していますが、マルチプロセッサ HAL に変更することもできます。
図 3 バーチャル マシンのデバイス マネージャで確認した HAL
図 3 バーチャル マシンのデバイス マネージャで確認した HAL

その他の変更点
変更できるものは変更し、変更できないものは受け入れる
物理システムから仮想システムへの移動、またはその逆の作業を検討する場合、変更できるものとできないものを念頭に置いておく必要があります。Windows インストールの変更できる側面を次に示します。
  • HAL (ただし、ユニプロセッサ システムからマルチプロセッサ システム、またはその逆の移動を行う場合のみであり、さらに両者が同じ電源構成に基づいている必要があります)。
  • 大容量記憶域コントローラ (これは簡単なことではありませんが、物理システムから仮想システムへの移動を行う多くのソリューションは、既にこの操作の実現を試みています)。ほとんどのベンダは、IDE 記憶域と SCSI 記憶域用のソリューションを提供しています。IDE から SCSI に、または SCSI から IDE に変更する作業はあまり簡単ではないため、展開を行う際にはどちらかを適切に選択してください。通常、SCSI を選択する方が、デバイスの信頼性は高くなります (これは、ほとんどのベンダの SCSI デバイス エミュレーションの実装に当てはまります)。
  • ネットワーク コントローラ (ただし通常、仮想システムから仮想システムへの移動を行う場合、特定のベンダが提供するテクノロジ内では同じものが使用されます)。
Windows インストールの変更できない側面を次に示します。
  • HAL (同じ電源構成が使用されており、前述の状況に当てはまる場合を除きます)。この HAL を変更する移動ソリューションを使用した場合、Windows インストールの安定性や信頼性は保証されないと考えてください (さらに重要なことには、このような Windows インストールはマイクロソフトによってサポートされません)。

SID とコンピュータ名を変更するだけでなく、使用している仮想コンピューティング テクノロジに固有の値も変更する必要があります。特に、MAC アドレス (ネットワーク デバイスの一意の ID) を変更する必要があります。また、多くの仮想アプリケーションも、それぞれ一意の識別子を持っています。ほとんどの場合、これらの識別子は、それぞれのコンピュータの構成ファイルに格納されているため、これらのエントリを編集する方法 (および有効性を維持する方法) を知っておくとよいでしょう。Pre-Boot Execution Environment (PXE) がサポートされている多くの仮想化製品では、それぞれの一意の ID に基づいて SMBIOS UUID を指定し、ドメインに参加する場合にこの ID を変更する (または、使用している仮想化ソフトウェアで変更できる場合はそのソフトウェアを使用して変更する) ことの必要性が強調されています。変更しなかった場合、(GUID が競合して) WDS クライアント システムまたは RIS クライアント システムを管理できなくなる可能性があります。私が使用したことがあるほとんどの仮想化ソリューションでは、MAC アドレスが重複した場合、深刻なネットワークの問題が発生しました。このため、単にバーチャル マシンを移動するだけでない場合、仮想化ソフトウェアによって MAC アドレスが変更されないときは、自分で変更することが非常に重要です。
仮想システムを展開用に準備する際に注意が必要なその他のコンポーネントは、リンクされているディスクやスナップショットです。使用している仮想化ソリューションによっては、これらが差分ディスクと見なされたり、別の名前が付けられる場合もあります。しかし、Sysprep を実行してシステムを準備し、その仮想システムのスナップショット (または元に戻すことが可能な状態のその他のファイル) を作成した場合、イメージの複製時にイメージの安全性、信頼性、およびセキュリティを維持するには、それらのスナップショットを破棄する必要があります。スナップショットまたはその他の "ディスクの変更を取り消す" 機能を使用するテクノロジでは、あるバーチャル マシンから作成されたシステムを特定のスナップショットが適用される前の状態に戻すと、同じバーチャル マシンから作成された複数のシステムと競合する可能性があります。また、元のバーチャル マシンの状態が戻された場合は、元のバーチャル マシンとも競合する可能性があります。このため、スナップショットや差分ディスクの関係がすべて反映されたシステムに対して Sysprep を実行しておく必要があります。

最適化
ほとんどの仮想化テクノロジには、ホストからゲストを操作する際のパフォーマンスとエクスペリエンスが強化される、バーチャル マシン追加機能またはツールが含まれています。多くの場合、マウスとキーボードによる入力の最適化などのパフォーマンスを向上させる機能や、コピーと貼り付け操作 (またはホストからゲストに対して実行するその他の操作) を強化する機能などが提供されます。仮想システムを展開する前に、これらのツールの最新バージョンをインストールするようにしてください。
また、クライアントのメモリはゲスト OS に最も適した構成にする必要がありますが、展開先のホストのことも考慮する必要があります。最も避けた方がよいことは、1 GB の RAM を使用するように設定した Windows XP イメージを、最初から RAM が 1 GB も搭載されていないホスト システムに展開することです。
また、現在のほとんどの仮想テクノロジに適用される制限も覚えておいてください。ユーザーは、仮想システムに接続されている周辺機器の操作方法だけでなく、ゲスト OS 上で動作するアプリケーションと動作しないアプリケーションを認識しておく必要があります (たとえば、ほとんどの仮想テクノロジでは、DirectX 9 や DirectX 10 がサポートされていないか、古いバージョンが制限付きでサポートされています)。ユーザーは、この制限が何を意味するのか、またはどのような状況で発生するのかを知らない場合があります (このような障害に適切に対処できないアプリケーションもあります)。

ホストについての考慮事項
通常、ゲストで実行されているのが完全なオペレーティング システムであるか、ハードウェアのすぐ上のレイヤで実行されるタイプ 1 ハイパーバイザであるかにかかわらず、仮想化テクノロジを実行しているホスト PC について気にする必要はほとんどありません。ほとんどの仮想化テクノロジは、ゲスト OS がホストについてまったく (またはほとんど) 知らなくてもよいように設計されています。ただし、あるホストから別のホストに移動したゲストで問題が発生した場合は、使用しているホストが何であるかを知っておいてください。また、使用している仮想化ベンダの製品に特定のプラットフォームで適用される制限も知っておいてください。あるプラットフォームから別のプラットフォームに移動することはできても、その過程で、ホスト OS のタイプ 2 ハイパーバイザ (仮想化アプリケーション) で提供される特定の機能が失われたり、使用できるようになったりすることがあります。

その他の展開メカニズム
Sysprep の関連リンク
Sysprep の詳細については、次のドキュメントを参照してください。
  • Sysprep を使用したイメージ ベースのインストールを設計する
  • Sysprep ツールを使用して Windows XP の展開を自動化する方法
  • システム準備ツール (Sysprep.exe) を使用してディスクの複製を実行する方法
  • 異種コンピュータでシステム準備ツールを使用する

仮想システムの展開方法としてすぐ思い浮かぶ選択肢は Sysprep やディスク複製の使用 (または単に Sysprep を実行し、バーチャル マシンをコピーするという方法) ですが、他にも選択肢はあります。Windows PE を使用する場合、イメージングとセットアップのどちらを使用するにしても、物理コンピュータよりも仮想化を利用した方が作業が簡単になる可能性があります。これは、物理的な CD-ROM ではなく ISO ファイルを使用して作業するためです。一部の仮想化テクノロジでは DVD メディアを適切に処理できないので、サポートされているかどうかを仮想化ベンダに確認してください。winnt32 または setup.exe (Windows Vista または Windows Server 2008 の場合) を使用することもできますが、特にメリットはありません。Automated Deployment Services など、その他のマイクロソフトの展開テクノロジを使用すると、仮想化テクノロジで PXE がサポートされ、RIS や WDS を利用しているかのようにネットワーク ベースの展開を開始することができます。

移行
最後に、実際に PC 全体を移動することに加えて、ユーザー状態移行ツール (USMT) を実行することも忘れないでください。USMT を使用すると、物理クライアントから新しいバーチャル システムに、ユーザーの設定を簡単に移行することができます。このため、ユーザーが古いデータや設定を新しいバーチャル マシンに移行する必要がある場合、管理者は、ファイルや設定を Windows XP から取得し、それを UNC 共有に格納し、新しいバーチャル マシンに格納する、といった手順で簡単に移行することができます。

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


 フィールド ノート: 代替可能な未来
フィールド ノート
代替可能な未来
Romi Mahajan

哲学者であり 経済学者でもあったカール マルクスは、著書の中で「すべての固体は気化する」として、19 世紀のヨーロッパの工業化と資本主義の台頭により、社会的カテゴリ間の関係が移り変わりつつあることを強調しました。区分やカテゴリは完全に固定されることはないというこの強力な考えは、現在でもさまざまな形や文脈で使われています。特に、変わらないものといえば変わることだけという言葉は、テクノロジの世界では頻繁に引用されています。
この移り変わりの激しい業界では、コンシューマ主導型テクノロジの台頭ほど、変化の速度を示す (また、そのために私たちが直面している課題の) 例としてわかりやすいものはありません。実際、IT は "コンシューマ主導型" となり、変化の主な指標は完全に個人の世界に同調し、仕事とプライベートの両方に大きな影響を与えています。この現象は、さまざまな形で現れています。
  1. Web 2.0 は、インターネットの読み取りとインターネットへの書き込みの世界です。インターネットに書き込むという行為は、まさに書き手がコンシューマとしての役割を果たしていると言えるでしょう。
  2. コンシューマ アプリケーションおよびテクノロジは、ビジネスの "ハロー効果" を生んでいます。
  3. インターネットの中核設備は、コンシューマ主導型の IT を前提として計画とテストが進められています。
  4. ヘルプ デスクなどの IT 部門は、家庭用テクノロジと業務用テクノロジの境界線があいまいになっていることを踏まえて、計画、対処、および学習を行う必要があります。
  5. 決定を下すのは人々であり、この人々はコンシューマであると同時に職業人でもあります。
  6. 個人の "お気に入り" のテクノロジは、常にコンシューマ製品であり、ビジネス製品ではありません。
これらが持つ意味は非常に重要で、ほんの一握りの例からもわかるように、各カテゴリは互いに置き換えが可能です。テクノロジ企業に勤める私の友人が言っていましたが、彼の会社ではヘルプ デスクへの問い合わせのうち 8％ は、iTunes の更新プログラムによるものだそうです。Cisco のホワイト ペーパー「The Exabyte Era」では、冒頭で 2 つのことが述べられています。それは、インターネットはストリーミング ビデオの重量に押し潰されてなどいないこと、および YouTube はまだその第一歩を踏み出したにすぎないことです。NDP Group のレポートによると、Apple Corporation は、2007 年 3 月の小売ラップトップ市場で約 10％ のシェアを占めています。これは、職場での iPod の使用が生んだハロー効果です。マイクロソフトは、ゲーム、音楽、デジタル写真、ビデオ ホスティングなどの領域に、多大な投資を行っています。また、最近では企業が会議を Second Life 内で開催することもあります。
さらに、テクノロジ ブランドはその地位と人気を高め、人々の間に定着しています。人々は何かを "ググ" ったり、iPod の話題でもちきりだったり、"マイスペース" を利用したり、"Xbox®" をプレイしたりしています。人とテクノロジの間に感情的なつながりが築かれており、このつながりの持つ影響は、職場から家庭へ、さらに家庭から職場、そしてそのデバイス、アプリケーション、Web サイト、コミュニティを生み出した企業に対する好意へと波及しています。私たちは良い、悪い、どちらでもないといった認識を確立すると、プライベートの世界でも仕事の世界でもその認識と共に生きていきます。
したがって、個人に関係することは、複雑な問題なのです。そして、企業が、自分たちが発信するメッセージを調整し、親しみを示し、顧客を気にかけるという同時発生的な課題に対処しようとするのであれば、根本的なカルチャー シフトが必要です。役割の専門化が進む前の時代では、すべての人々を対象としたメッセージがマーケティングの本質でした。一方、最近では、"的を絞った" メッセージの発信が盛んに行われています。レーザー並みの精度で、役職、オーディエンス セグメント、会社の規模、特定のテクノロジなどのカテゴリを絞り込んでいきます。しかし、ここで抜け落ちているのは、すべての固体は気化するという事実です。人々の個人またはコンシューマとしての側面に訴えかけることが、つながりを築き、時代の先を行く道 (唯一の道) なのです。
代替可能であるということは、互いに置き換えが可能であり、カテゴリ間に厳密な区別がないことを意味します。つまり、コンシューマ テクノロジとビジネス テクノロジという概念の間に、もはや壁を築くことはできません。コンシューマ主導型の IT の時代が到来しました。これからは、まさに代替可能な時代になっていくでしょう。

Romi Mahajan は、マイクロソフトのテクニカル オーディエンスおよびプラットフォーム マーケティング チームを率いるマーケティング ディレクタです。政治、環境問題、テクノロジ、社会学などさまざまな分野で考えを発表しています。


 Windows 秘話: ジョイスティックは電子レンジである必要はない
Windows 秘話
ジョイスティックは電子レンジである必要はない
Raymond Chen

最近、 同僚のブログ「The Audio Fool」の投稿を読んでいて、今でも頭を悩ませている数年前の失敗について思い出しました。それは DirectInput® フォース フィードバック ジョイスティック インターフェイスの開発が進められているときで、提案中のインターフェイスの詳細について話し合い、各社のフィードバック (だじゃれではありません) を得るために、ジョイスティック メーカー各社をワシントン州レドモンドにあるマイクロソフトのオフィスに招いたときのことでした。
会議中、さまざまな問題が徹底的な討議によって解決されましたが、今でも私の頭から離れないことが 1 つあります。それは周期的フォースを間隔として表現するか、周波数として表現するかに関する意見の相違でした。あるベンダの代表者は、彼の会社では既に周期的フォースを周波数で指定するドライバを作成しており、このドライバを変更することは受け入れがたいと騒ぎ立てていました。これが、新しいインターフェイスの詳細について討議し、意見をまとめるための会議だったことを考えると、自社のドライバを変更しないでも済む状態で会議を後にできると期待する方が無理な話ではないでしょうか。
しかし、このベンダがあまりに騒ぐので、私たちもついに折れて、周期的フォースの指定単位に間隔ではなく周波数を使用することで同意しました。結局、どちらになっても大きな問題ではなかったのです。周波数で 1 秒間に 10 回と表現されるフォースは、間隔で表現すると 1/10 秒に 1 回となります。つまり、間隔と周波数は単純な反比例の関係にあるということです。
おっと、これは必ずしもそうとは限りません。間隔はミリ秒で表され、ダイナミック レンジは 1 ミリ秒から 50 日までです。人間の時間の尺度からすると 50 日というのは短い期間であり、1 ミリ秒にいたってはあまりに短いため、周期現象としては記録されず、音として知覚されます。
一方、周波数はヘルツで表され、ダイナミック レンジは 1 秒につき 1 ヘルツから 400 億ヘルツまでです。ジョイスティックから音楽が再生されるのは違和感がありますか。電子レンジの周波数帯にまで届くフォースを生成すると考えてください。
問題は、周波数範囲の上限の周波数を表現する事実上使い物にならない力は、下限の周波数を犠牲にすることで実現されているということです。フライト シミュレータでは、比較的長い間隔での周期的フォースがよく使われているそうです。その物理学的な背景はわかりませんが、パイロットが対処しなければならない現象の 1 つは、操縦桿におよそ数分間という長い間隔で周期的にかかる力だと聞いています。飛行機は性質上、非常にゆっくりと垂直方向の正弦波形を描いて飛行する傾向があるため、パイロットは水平飛行を維持できるよう、この傾向に対処する必要があります。周期フォースが間隔で表現されるのであれば、フライト シミュレータ プログラムでは 120,000 ミリ秒と指定できます。しかし、周波数の場合は 0.0083 ヘルツとなり、ドライバ インターフェイスで表現できる最も遅い周波数 (1 ヘルツ) よりも大幅に遅くなります。したがって、フライト シミュレータが要求できる最も遅いフォースは 1 秒間に 1 回発生するフォースであり、フライト シミュレータが再現しようとする物理的な現象と比べると依然としてかなり短い間隔です。
この問題は、ここ数年にわたり私を悩ませ続けているので、フォース フィードバックに関するドキュメントを最近見直してみました。驚いたことに、DIPERIODIC 構造体は、周期的エフェクトの表現に、周波数ではなく間隔を使用しているようなのです (しかも、マイクロ秒を使用していますから、音楽を再生できるだけでなく、飛行機も操縦できることになります)。誤りが修正されたのか、もうろくしてしまい自分の記憶にいたずらされたのでしょう。いずれにしても、この問題について私はもう頭を悩ませる必要はなくなりました。将来、まかり間違ってこんなことが起こったとしても。

Raymond Chen は自分の Web サイト「The Old New Thing」および同じタイトルの書籍 (Addison-Wesley、2007 年) で、Windows の歴史と Win32 プログラミングについて扱っています。あの色は彼に似合っていますね。