 TechNet Magazine May 2008

TechNet Magazine May 2008

Windows の管理: Windows Server 2008 における Active Directory のバックアップと復元

Windows Server 2008 と新しい Windows Server バックアップ ユーティリティでは、さまざまなバックアップ関連の変更が施され、その機能が強化されています。この記事では、Windows Server 2008 における Active Directory のバックアップと復元について詳しく説明します。

Gil Kirkpatrick Windows の管理: 機能する OU 構造を設計する

多くの管理者は、適切な組織単位構造を設計することの重要性を軽視しています。この記事では、適切な OU 設計の方針を計画することが重要である理由について説明し、各自の組織に最も適した OU 構造を検討します。

Ken St. Cyr Windows の管理: Active Directory スキーマを拡張する

Active Directory を使用する多くのアプリケーションでは、Active Directory スキーマへの変更が独自に定義されていますが、これらの変更が他のアプリケーションに影響を与えないようにすることは重要です。この記事では、classSchema オブジェクトと attributeSchema オブジェクトを使用した Active Directory の拡張について概説します。

Vikas Malhotra System Center: System Center Mobile Device Manager の概要

新しい System Center Mobile Device Manager には、MMC スナップインまたは Windows PowerShell を使用して Windows Mobile デバイスを管理するためのツール一式が用意されています。この記事では、この重要なツールを使用して、モバイル デバイスの管理、セキュリティの強化、およびモバイル VPN 機能の提供を実現する方法を紹介します。

Matt Fontaine System Center: System Center Essentials SP1 の新機能

System Center Essentials 2007 Service Pack 1 では、大幅な機能強化が施されています。この記事では、ユーザー エクスペリエンスを向上し、管理を簡略化する主な変更のいくつかについて説明します。

Pete Zerger 編集長から: 新コラム「SharePoint の内部」の誕生を祝して

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

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

Greg Steen Exchange Queue & A: Exchange Server 2007 SP1 の展開

今月の記事では、Exchange Server 2007 SP1 に関する質問に回答します。

Nino Bilic ユーティリティ スポットライト: SharePoint の容量計画

この記事では、SharePoint Capacity Planning Tool について説明します。また、SharePoint を展開するためのトポロジを設計し、負荷と使用状況のシミュレーションを実行した後、そのトポロジを変更する方法についても説明します。

Peter Skjøtt Larsen and Satish Mathew SharePoint の内部: SharePoint インフラストラクチャを構築する

SharePoint は強力な製品ですが複雑なので、展開は非常に困難な場合があります。そのような場合は、この新しく始まる SharePoint コラムが役に立つでしょう。第 1 回である今回は、SharePoint アーキテクチャの概要を紹介し、WSS 3.0 を使用して基本的な SharePoint インフラストラクチャを構築する方法について説明します。

Pav Cherny Windows PowerShell: ディレクトリの管理を自動化する

Windows PowerShell の Version 1 で提供されている Active Directory の管理機能は、あまり優れているとは言えません。この記事では、アドインを使用して強力な機能を入手し、それらの機能を使用して Windows PowerShell 内で Active Directory オブジェクトを操作する方法について説明します。

Don Jones Hey, Scripting Guy!: 正規表現に眉をひそめる

Scripting Guys がルーブルを訪れて芸術批評を行います。また、スクリプト内で正規表現を使用して検索と置換を実行する方法について説明します。

The Microsoft Scripting Guys セキュリティ ウォッチ: 量子セキュリティの原理

ハイゼンベルグの不確定性原理とその他の量子物理学の理論が、どのようにしてセキュリティ戦略の進化に役立つかについて説明します (注 : この記事の執筆中に危害を加えられた猫はいません)。

Jesper M. Johansson デスクトップ ファイル: 管理者から卒業する

なぜだれもが管理者としてシステムを実行するのでしょうか。この記事では、Wes Miller が、管理者としてシステムを実行することの危険性と、ユーザー (および皆さん自身) が管理者ではなくユーザーとしてシステムを実行することのメリットについて説明します。

Wes Miller フィールド ノート: 1 台のパソコンに複数のマウス

クラスで使用できるコンピュータの台数よりも生徒の数の方が多い場合はどうしたらいいでしょうか。Microsoft Research India は、1 台のコンピュータで複数のマウスを同時に操作できる、MultiPoint と呼ばれる解決策を考案しました。

Kentaro Toyama Windows 秘話: 時代遅れの 16 ビット アイコン

今月の記事では、Windows Vista で 16 ビット アイコンがサポートされていないことについて解説します。また、そのことに気付いた人がいるかどうかについても言及しています。

Raymond Chen


 Windows の管理: Windows Server 2008 における Active Directory のバックアップと復元
Windows の管理 Gil Kirkpatrick

Windows Server 2008 における Active Directory のバックアップと復元
概要:
  • NTBACKUP と Windows Server バックアップの比較
  • バックアップに関するツールとオプション
  • 回復に関するツールとオプション
  • 適切な Active Directory バックアップ戦略を立てるためのポイント

Active Directory ドメイン サービス (ADDS) が Windows インフラストラクチャのミッション クリティカルなコンポーネントであることは、皆さんご存知だと思います。Active Directory が停止すると、ネットワークは基本的に使い物にならなくなります。したがって、Active Directory のバックアップおよび回復計画を立てることは、
セキュリティとビジネスの継続性を確保し、法令遵守を徹底するうえで非常に重要です。
Windows Server® 2008 では、Active Directory® のさまざまな新機能が追加されていますが、バックアップおよび回復計画に大きく影響するのはそのうちの 2 つで、新しい Windows Server バックアップ ユーティリティと、Active Directory のボリューム シャドウ コピー サービス スナップショットを作成および操作できる機能です。この記事では、これらの機能強化がもたらす変更点と、これらを利用して Active Directory のバックアップに関連する作業を合理化する方法について説明します。

NTBACKUP と Windows Server バックアップの比較
グループ ポリシー設定
Windows Server バックアップでは、サーバーでのバックアップ動作をある程度まで制御できるグループ ポリシー設定がいくつか提供されます。これらのバックアップ ポリシーを使用すると、アクセス権が与えられていないデータにアクセスするために実行される、不正なバックアップに関連するリスクの一部を緩和できます。これらのポリシー設定は、次のとおりです。
Allow Only System Backup (システムのバックアップのみを許可する) この設定を有効にすると、Windows Server バックアップで、重要なシステム ボリュームのバックアップのみが許可されます。ボリューム バックアップは実行できません。
Disallow Locally Attached Storage as Backup Target (ローカルに接続された記憶域へのバックアップを許可しない) この設定を有効にすると、ローカルに接続されたドライブへのバックアップを実行できなくなります。つまり、ネットワーク共有へのバックアップのみが許可されます。
Disallow Network as Backup Target (ネットワークへのバックアップを許可しない) この設定を有効にすると、ネットワーク共有へのバックアップを実行できなくなります。
Disallow Optical Media as Backup Target (光学メディアへのバックアップを許可しない) この設定を有効にすると、Windows Server バックアップで、光学デバイス (書き込み可能な DVD ドライブなど) へのバックアップを実行できなくなります。
Disallow Run-Once Backups (1 回実行バックアップを許可しない) この設定を有効にすると、Windows Server バックアップで、スケジュールされていない 1 回限りのバックアップを実行できなくなります。Windows Server バックアップ MMC スナップインからスケジュールしたバックアップのみが許可されます。

Windows NT® 3.5 から皆さんに愛用され続けてきた NTBACKUP は提供されなくなりました。これに代わる機能が Windows Server バックアップです。この新しいツールは、単に NTBACKUP に変更が加えられただけではなく、システムのバックアップ方法を考え直さなければならなくなるような、まったく新しいテクノロジです。
Windows® Server バックアップは、Windows Server 2008 に付属している唯一のバックアップ ソリューションですが、単にその機能を NTBACKUP から置き換えただけのソリューションではありません。Windows Server バックアップと NTBACKUP の最大の違いは、Windows Server バックアップがディスクからディスクへのバックアップ ソリューションであることです。Windows Server バックアップでは、テープへのバックアップはサポートされていません。バックアップ イメージは、直接接続されたディスク ボリュームやネットワーク共有だけでなく、外付け USB ハード ドライブやマルチボリュームでの書き込みが可能な DVD にも作成できますが、テープには作成できません。ただし、Windows Server 2008 サーバーにテープ ドライブを接続し、Windows Server バックアップによって生成されたバックアップ イメージをコピーすることは可能です。この場合は、サードパーティ製のソフトウェアを使用する必要があります。
NTBACKUP はファイル ベースのバックアップおよび復元ツールですが、Windows Server バックアップはボリュームおよびブロック ベースのツールです。Windows Server バックアップでは、バックアップ ソースがボリュームのセットとして扱われ、各ボリュームはディスク ブロックの集合として扱われます。これにより、ファイル システムを介してファイルをバックアップするよりも、はるかに効率が向上します。ブロック ベースでバックアップが行われるので、ボリューム シャドウ コピー サービスのスナップショットを活用したブロック レベルの増分バックアップが可能になります。また、ターゲット ボリュームにスナップショットが作成されるので、複数のバックアップが扱いやすくなります (さらに、これらのバックアップによって使用される領域が減少します)。
Windows Server バックアップでは、完全バックアップを実行する場合でも、ターゲット ディスク上の領域が非常に効率よく使用されます。たとえば、同じボリュームの完全バックアップを複数回実行するとします。Windows Server バックアップでは、ターゲット ディスクに格納されているボリューム シャドウ コピー サービスのスナップショットにバックアップ イメージが保存されるので、変更されたブロックのみがこれらのスナップショットに保存されます。このため、複数の完全バックアップによって使用される領域が大幅に減少します。また、増分バックアップを回復する際に、複数の復元操作を行う必要がなくなります。スナップショットには各バックアップの差分のみが保存されますが、ボリューム シャドウ コピー サービスによって、これらのバックアップは完全バックアップとして提供されます。
ただし、ターゲット ディスクに格納されているボリューム シャドウ コピー サービスのスナップショットを活用できるのは、ローカル ハード ディスクへのバックアップを実行する場合のみです。Windows Server バックアップは、DVD やネットワーク共有に格納されているバックアップに対しては、ボリューム シャドウ コピー サービスの操作を実行できません。
さらに便利なことに、Windows Server バックアップでは、バックアップ イメージが Microsoft® バーチャル ハード ディスク (VHD) 形式で保存されます。実際、作成したバックアップ イメージを、Microsoft Virtual Server 2005 で実行されているバーチャル マシンのボリュームとしてマウントできます。このため、テープ バックアップを試験的に復元して、どのバックアップに目的のファイルが含まれているかを確認する必要なく、VHD ファイルをバーチャル マシンにマウントして、特定のファイルを参照できます (ただし、バックアップ イメージからはバーチャル マシンを起動できないことに注意してください。バックアップ イメージのハードウェア構成はバーチャル マシンの構成に対応していないので、Windows Server バックアップを物理コンピュータからバーチャル マシンへの移行ツールとして使用することはできません)。
Windows Server バックアップがボリュームおよびブロック ベースのツールであることによってもたらされるデメリットもあります。Windows Server バックアップでは、ボリュームとブロックのセットがバックアップ ソースと見なされるので、選択したファイルのみをバックアップすることはできません。このため、ボリューム全体をバックアップする必要があります。さらに、既定では、バックアップしようとしているボリュームの 1 つにバックアップ イメージを保存することはできません (この問題は、何とおりかの構成変更を行うことによって回避できます。詳細については、support.microsoft.com/kb/944530 を参照してください)。詳細は後述しますが、このことはシステム状態のバックアップに大きな影響を与えます。

Windows Server バックアップをインストールする
Windows Server バックアップは、Windows Server 2008 で提供される "機能" の 1 つですが、既定ではインストールされません。Windows Server バックアップを使用してバックアップを実行するには、サーバー マネージャを使用するか、次のように SERVERMANAGERCMD コマンド ライン ユーティリティを使用して、この機能をインストールする必要があります。
C:\> servermanagercmd -install Backup-Features
Windows Server バックアップは、Windows Server バックアップとコマンド ライン ツールという 2 つのサブ機能で構成されています。このコマンド ライン ツールは、WBADMIN .EXE コマンド ライン ツールではなく、一連の Windows PowerShellTM コマンドレットのことを指しています。したがって、両方のサブ機能をインストールする場合は、Windows PowerShell をインストールする必要があります。
Windows Server バックアップをインストールすると、Microsoft 管理コンソール (MMC) スナップインが、サーバー マネージャの [記憶域] ノードと、[管理ツール] のメニューに追加されます。Windows Server バックアップを Windows Server 2008 の Server Core インストールにインストールする場合は、次のように OCSETUP コマンドを使用します (OCSETUP コマンドでは大文字と小文字が区別されます)。
C:\> ocsetup WindowsServerBackup
インストール手順の詳細な説明については、go.microsoft.com/fwlink/?LinkId=113146 を参照してください。
Windows Server バックアップでは、NTBACKUP を使用して作成されたイメージを復元することはできません。このような作業が必要になることはあまりありませんが、必要になった場合は、マイクロソフト Web サイトから Windows Server 2008 用の NTBACKUP をダウンロードして使用できます (go.microsoft.com/fwlink/?LinkId=113147 を参照してください)。

Windows Server バックアップのコンポーネント
Windows Server バックアップ アプリケーションのアーキテクチャは、NTBACKUP から大幅に変更されています。この新しいバックアップ ソリューションは、次の 4 つのコンポーネントで構成されます。
  • MMC ユーザー インターフェイス (WBADMIN.MCS)
  • コマンド ライン インターフェイス
(WBADMIN.EXE)
  • バックアップ サービス (WBENGINE.EXE)
  • Windows PowerShell コマンドレットのセット
アプリケーションをクライアントとサービスに分割することによって、いくつかのメリットが得られます。最大のメリットは、信頼性が強化されることです。バックアップを MMC クライアントとコマンド ライン インターフェイスのどちらから開始しても、複雑な処理を実行するのは WBENGINE サービスです。クライアント プログラムが担当するのは、バックアップの状態の報告のみです。したがって、クライアント プログラムを終了しても、バックアップが途中で終了することはありません。クライアントは停止しますが、サービスによって処理が続行され、バックアップは完了します。もちろん、バックアップを停止することもできますが、その場合は明示的に停止する必要があります。
このクライアントとサービスが分割されたアーキテクチャのもう 1 つのメリットは、クライアントを使用してリモート コンピュータ上のバックアップを管理できることです。これは、特に複数の Windows Server 2008 Server Core コンピュータをバックアップする必要がある場合に役立ちます。
Windows Server バックアップでは、Windows 回復環境 (WinRE) を使用したベアメタル復元がサポートされています。WinRE は Windows Server 2008 のインストール メディアに含まれています。WinRE を使用すると、簡単に一からサーバーを回復させることができます。ベアメタル復元の実行については、後ほど詳しく説明します。また、Windows Server バックアップでは、バックアップの管理に使用されるいくつかのグループ ポリシー設定がサポートされています (これらの設定については、補足記事「グループ ポリシー設定」を参照してください)。

ボリューム シャドウ コピー サービス
Windows Server バックアップでは、ボリューム シャドウ コピー サービスが 3 とおりの方法で使用されます。Windows Server 2008 で完全バックアップを開始すると、まずソース ボリュームのすべてのシャドウ コピーが作成されます。この処理により、Windows Server バックアップで一貫性のあるファイル システムを処理できるようになります (NTBACKUP でも同様の処理が実行されていました)。次に、ソース ボリュームのブロックが (1 つずつ) バックアップ ターゲットにコピーされ、バックアップされるソース ボリュームごとに VHD イメージが作成されます。
また、設定を変更しない限り、ソース ボリュームのスナップショットも作成されます。これは、ボリューム シャドウ コピー サービスによって、ボリューム上の変更されたブロックがすべて追跡されるようにすることを目的としています。これにより、ソース ボリューム上の変更されたブロックの読み取りのみを必要とする、ブロック レベルの増分バックアップを実行できるようになります。つまり、ファイル内の 1 ビットが変更されたためにファイル全体の読み取りと書き込みを実行するのではなく、変更されたブロックのみを読み取り、書き込むことができます。
これにより、非常に効率的な増分バックアップが可能になりますが、ソース ボリュームへの書き込み操作を行う際に、余分なディスク I/O が発生します。特にアクセスの多いボリュームや、パフォーマンスが重視されているボリュームをバックアップする場合は、[パフォーマンス設定の構成] を選択して、そのボリュームの増分バックアップを無効にします (図 1 参照)。
Figure 1 Disable incremental backups on busy volumes
Figure 1 Disable incremental backups on busy volumes
バックアップが完了すると、ターゲット ボリュームのスナップショットが作成されます (ローカルに接続されたハード ディスクへのバックアップを実行している場合)。次回のバックアップ時に、ターゲットの VHD ファイルは上書きされます。ただし、ボリューム シャドウ コピー サービスによってターゲット ボリュームのシャドウ コピーが維持されているので、実質的には、それぞれの完全バックアップに対応する VHD ファイルの複数のバージョンが存在することになります。つまり、1 つの完全バックアップと変更されたブロックによって、複数の完全バックアップが維持されます。

ネットワーク共有へのバックアップを実行する
ネットワーク共有へのバックアップは、ローカル ボリュームへのバックアップと同じぐらい簡単です。大きな違いは、リモート ボリュームでボリューム シャドウ コピー サービスのスナップショットを作成できないことです。したがって、それぞれの完全バックアップによって前回の完全バックアップが上書きされるので、ネットワーク共有上では各サーバーの最新の完全バックアップ イメージのみが保持されます。この制限のために、Windows Server バックアップのスケジューラを使用して、ネットワーク共有へのバックアップをスケジュールすることはできません。ただし、Windows タスク スケジューラを使用して WBADMIN コマンド ライン プログラムを実行すると、ネットワーク共有への完全バックアップを実行できます。WBADMIN を使用してネットワーク共有への完全バックアップをスケジュールする場合は、実行するバックアップごとにターゲット フォルダを変更して、前回のバックアップが上書きされないようにします。

書き込み可能な DVD へのバックアップを実行する
Windows Server バックアップでは、書き込み可能な DVD などの光学式メディアへのバックアップもサポートされています。また、複数のボリュームにまたがるバックアップ セットを作成することもできます。Windows Server バックアップでは、DVD へのバックアップを実行する場合、必ずバックアップが圧縮されるので、DVD からの復元を実行する際は、システム全体またはボリューム全体の復元のみを実行できます。Windows Server バックアップでは、DVD を使用した、システム状態のバックアップと復元またはファイル レベルのバックアップと復元はサポートされていません。また、DVD へのバックアップをスケジュールすることもできません。

システム状態のバックアップと復元
システム状態のバックアップは、(ボリューム全体ではなく) 選択したファイルと一部のアプリケーション データベースのみが含まれる、非常に重要になることが多い、便利なバックアップです。ただし、Windows Server 2008 の初期ビルドでは、システム状態のバックアップと復元はサポートされておらず、重要なシステム ボリューム (OS と主要なアプリケーションの回復と再起動に必要なボリューム) のバックアップのみがサポートされていました。これらの重要なシステム ボリュームのバックアップは、システム状態のバックアップがボリューム ベースで作成されたものです。
マイクロソフトは、ユーザーからのフィードバックを踏まえて、Windows Server バックアップにシステム状態のバックアップおよび復元機能を追加しました。システム状態データをホストするボリュームごとに複数の VHD ファイルが作成されますが、VHD には必要なファイルとデータベースのみがコピーされます。また、別の問題として挙げられるのは、システム状態のバックアップを実行したときに、通常のバックアップ処理とは異なり、ターゲット ボリュームのスナップショットが作成されないことです。システム状態のバックアップを実行するたびに、まったく新しい VHD ファイルのセットが作成されます。つまり、スナップショット ベースのボリューム バックアップのように、領域を効率よく使用することはできません。
システム状態のバックアップは MMC スナップインからは実行できず、WBADMIN.EXE コマンド ライン プログラムを使用する必要があります。システム状態のバックアップを実行するには、次のコマンドを使用します。
C:\> wbadmin start systemstatebackup
–backuptarget:e:
このコマンドを実行すると、重要なシステム ファイルとアプリケーション データベースが、システム状態のバックアップ用に確保された、ターゲット ボリューム上のフォルダにバックアップされます。既定のディレクトリ情報ツリー (DIT) を使用している 32 ビットの Windows Server 2008 ドメイン コントローラ (DC) のシステム状態をバックアップする場合、6 GB をやや超える領域が使用されます。使用される領域は Windows Server 2003 の場合よりも 5 GB 増加しますが、この理由の 1 つとして、Windows Server バックアップでは NTBACKUP によってキャプチャされなかったコア OS ファイルがキャプチャされることが挙げられます。
ご想像のとおり、システム状態のバックアップにかかる時間も長くなります。ただし、当然これらの結果は、Windows Server 2008 のプレリリース版に基づいて導き出されたものです。各自の環境でも必ずテストを実施する必要がありますが、Windows Server 2008 にドメイン コントローラを移行する場合は、システム状態のバックアップに使用される領域 (と時間) をさらに多く見積もる必要があるでしょう。

MMC を使用してサーバーをバックアップする
MMC で Windows Server バックアップを実行した場合、バックアップ スケジュールを設定するか、1 回限りのバックアップを直ちに実行できます (図 2 参照)。ここでは、[1 回だけバックアップ] を選択して、直ちにバックアップを実行します。
Figure 2 Windows Server Backup MMC
Figure 2 Windows Server Backup MMC
図 3 からわかるように、サーバー上のすべてのボリュームをバックアップするか、選択した特定のボリュームのみをバックアップするかを指定できます。[サーバー全体] を選択すると、マウントされているすべてのボリュームがバックアップされますが、マウントされているハード ドライブへのバックアップを実行することはできません。このため、書き込み可能な DVD かネットワーク共有へのバックアップを実行する必要があります。
Figure 3 Using the backup configuration dialog to specify all or select volumes
Figure 3 Using the backup configuration dialog to specify all or select volumes
この例では、ローカル ハード ドライブへのバックアップを実行するので、[カスタム] を選択します。次のダイアログ ボックスでは、バックアップするボリュームを選択します (図 4 参照)。既定では、[システム回復を有効にする] チェック ボックスがオンになっています。この場合、ブート ボリューム、OS ボリューム、および重要なシステム ファイルとアプリケーション データベースが格納されているボリュームが選択されます。DC では、SYSVOL をホストするボリューム、Active Directory DIT、および Active Directory ログがこれに含まれます。つまり、バックアップするボリュームはシステム状態のバックアップと同じですが、重要なボリューム上の重要なファイルだけでなく、それらのボリューム全体がバックアップされます。また、システム回復バックアップ セットから、システム状態の回復を実行することもできます。
Figure 4 Selecting specific volumes to back up
Figure 4 Selecting specific volumes to back up
バックアップ先の種類 (ローカル ドライブまたはネットワーク共有) とバックアップ先を指定すると、"VSS コピー" バックアップと "VSS 完全" バックアップのいずれかを選択するように求められます。どちらのオプションでも選択したボリューム全体がバックアップされるので、言葉の使い方はやや紛らわしいと思いますが、この 2 つの違いは、Windows Server バックアップによってバックアップ後のソース ファイルがどのように処理されるかです。"VSS コピー" を選択すると、バックアップ後のファイルはそのまま残されます。"VSS 完全" を選択すると、このアーカイブはリセットされます。

コマンド ラインからサーバーをバックアップする
バックアップ プロセスをスクリプト化したり、Server Core インストールでサーバーをバックアップしたりする場合は、WBADMIN.EXE コマンド ライン プログラムを使用できます。WBADMIN では、バックアップ スケジュールの管理など、基本的に MMC スナップインと同じ操作を実行できる、包括的なオプションのセットが提供されます。
たとえば、WBENGINE サービスを開始して、バックアップ プロセスを実行する必要があるとします。この処理は、次のコマンドを入力するだけで実行できます。
C:\> wbadmin start backup –include:c:,d:
–backuptarget:e:
また、すべての重要なシステム ボリュームをバックアップする場合は、次のコマンドを入力します。
C:\> wbadmin start backup -allcritical
–backuptarget:e:
バックアップが開始された後も WBADMIN は引き続き実行され、バックアップの進捗状況が表示されます。WBADMIN を終了しても、バックアップはバックグラウンドで引き続き実行されます。その後、再び WBADMIN を実行中のバックアップに関連付けるには、次のコマンドを使用します。
C:\> wbadmin get status
実行中のバックアップを終了する場合は、次のコマンドを入力します。
C:\> wbadmin stop job

MMC を使用してバックアップをスケジュールする
Windows Server バックアップに統合されたバックアップ スケジューラの目的は 1 つで、毎日実行されるローカル ディスク ボリュームへのファイル システムのバックアップを容易にスケジュールできるようにすることです。この組み込みのスケジューラを使用して、自動的に複数のターゲット ボリュームがローテーション形式でバックアップされるように設定できます。簡単に取り外しができるハード ドライブを所有している (または USB 接続型ハード ドライブを使用している) 場合、この機能を使用すれば、バックアップ ディスクを取り外して別の場所に保管し、最も古いバックアップ ディスクをサーバーに再び取り付けて次回のバックアップに使用するというローテーションを組むことができます。
Windows Server バックアップのスケジューラでは、毎日必ず実行されるバックアップのみをスケジュールできます。たとえば、月曜日、水曜日、金曜日に実行されるバックアップをスケジュールすることはできません。したがって、スケジュールされたバックアップを毎日実行しない場合は、直接 Windows タスク スケジューラで作業を行う必要があります。
スケジュールされたローカル ディスクへのバックアップを構成すると、Windows Server バックアップによって、ディスクに関連する処理 (フォーマット、特定のフォルダ構造の設定、エクスプローラによって認識されないターゲット ディスクの作成) が実行されます。ターゲット ディスクはベーシック ボリュームである必要があります。Windows Server バックアップでは、ダイナミック ボリュームとして構成されているディスクへのバックアップは実行できません。
MMC スナップインを使用すると、非常に簡単にバックアップをスケジュールできます。この記事の例では、[バックアップ スケジュール] を選択し、バックアップの種類とバックアップするボリュームを指定すると、[バックアップの時間の指定] ダイアログ ボックスが表示されます (図 5 参照)。
Figure 5 Specifying when daily backups should occur
Figure 5 Specifying when daily backups should occur
バックアップを実行する時刻を選択したら、バックアップ先のボリュームを選択できます。ここでは、ボリューム E: を選択します (図 6 参照)。Windows Server バックアップによって、適切なターゲット ボリュームの候補が表示されますが、バックアップ先に使用したいディスクが表示されていない場合は、[すべての使用可能なディスクを表示] をクリックして、接続されているディスク デバイスをすべて表示できます。いくつかの "確認" ダイアログに表示された内容を確認し、次に進んでいくと、Windows Server バックアップによってターゲット ボリュームがフォーマットされ、Windows タスク スケジューラを使用してバックアップ タスクがスケジュールされます。
Figure 6 Specifying the destination disk for a scheduled backup
Figure 6 Specifying the destination disk for a scheduled backup
スケジュールされたバックアップが完了するたびに、Windows Server バックアップによってターゲット ボリュームのスナップショットが作成されます。また、7 日ごとに新しい基本イメージが作成されます。処理内容は、Microsoft/Backup/Operational ログに記録されます。このログを参照して、バックアップが正常に完了したかどうかを確認できます。また、電子メール メッセージの送信などのタスクを成功または失敗イベントに関連付けて、スケジュールされたバックアップの状態を常に把握できるようにすることもできます。

コマンド ラインを使用してバックアップをスケジュールする
Server Core インストールのバックアップをスケジュールしたり、バックアップ プロセスをスクリプト化したりする場合は、WBADMIN.EXE コマンド ラインを使用してバックアップ スケジュールを管理できます。スケジュールされたバックアップを追加するには、次のように WBADMIN ENABLE BACKUP コマンドを使用して、ターゲット、ソース、およびバックアップを実行する時刻を指定します。
C:\> wbadmin enable backup –addtarget:e:
-include:c:,d: -schedule:06:00,12:00,18:00
このコマンドでは、1 日に 3 回 (午前 6 時、午後 0 時、午後 6 時) C: ドライブと D: ドライブが E: ドライブにバックアップされます (どの時刻も 24 時間形式で指定します)。すべての重要なシステム ボリューム (ベアメタル復元やシステム状態の復元に使用できます) をバックアップするには、–include スイッチの代わりに –allcritical スイッチを指定します。
また、次のように WBADMIN を使用すると、すべてのスケジュールされたバックアップを無効にすることができます。
C:\> wbadmin disable backup
このコマンドを実行すると、Windows Server バックアップのスケジューラによって作成された、すべてのスケジュールされたバックアップ ジョブが削除された後、バックアップのターゲット ボリュームが解放され、通常の操作に使用できるようになります。また、WBADMIN MMC スナップインを使用すると、いつでも Server Core サーバーのバックアップおよび復元操作をリモートで管理できます。

ドメイン コントローラのベアメタル回復
バックアップと回復に関する最も魅力的な機能強化は、インストール プロセスに組み込まれた WinRE の動作です。インストール メディアから Windows Server 2008 を起動すると、[コンピュータを修復する] というオプションが表示されます (図 7 参照)。このオプションは意識的に探さなければ見落としがちなので、ここで指摘しておきます。
Figure 7 The Repair your computer option is available on the installation screen
Figure 7 The Repair your computer option is available on the installation screen
インストール画面でこの修復オプションを選択すると、回復オプションを選択する画面が表示されます (図 8 参照)。ここでは、[Windows Complete PC 復元] を選択して、Windows 回復環境を起動します。
Figure 8 Specifying system recovery options
Figure 8 Specifying system recovery options
修復するオペレーティング システムを選択したら (通常、選択肢は 1 つのみです)、復元に使用するバックアップを選択します。既定では、WinRE によって最新の完全なシステム バックアップが選択されていますが、ローカル ディスクに保存されている他のバックアップを指定することも、ネットワークから他のサーバー上のファイル共有に保存されているバックアップを検索することもできます。
ここでは、最新の完全なシステム バックアップを選択します。次のダイアログ ボックスでは、復元に先立ち、すべてのディスクのフォーマットと再パーティション分割を実行できます (図 9 参照)。これは、ディスク エラーが原因で発生した障害からの回復を行う場合や、サーバー内の 1 つ以上のディスク ドライブを置き換えた場合に適しています。
Figure 9 You can easily format and repartition disks before they're restored
Figure 9 You can easily format and repartition disks before they're restored
いくつかの確認ダイアログ ボックスに表示された内容を確認し、次に進んでいくと、WinRE によって復元処理が開始され、サーバーが再起動します。この方法を使用すると、非常に簡単にサーバーのベアメタル回復を実行できます。

ドメイン コントローラのシステム状態を回復する
Active Directory 関連の障害から回復する (たとえば、削除された OU をバックアップから回復する) 必要がある場合は、システム全体を復元するのではなく、Active Directory ドメイン サービス (ADDS) データベースを以前の状態に復元します。Windows Server 2008 では、ADDS を 1 つのサービスとして停止させることができますが、ドメイン コントローラ上でシステム状態の復元を実行する場合は、ディレクトリ サービス復元モード (DSRM) でサーバーを起動する必要があります。
Windows Server 2008 が DSRM で起動するようにブート オプションを変更する作業は、以前ほど簡単ではありません。Windows のブート環境は、新しい拡張ファームウェア インターフェイス (EFI) をサポートするために、全面的に再設計されており、以前の boot.ini ファイルは使用されなくなりました。Windows Server 2008 では、ブート構成データ (BCD) を使用してブート プロセスが制御されます。
最も簡単に BCD を管理する方法は、BCDEDIT コマンド ライン プログラムを使用することです。BCDEDIT のコマンドとオプションをすべて紹介するには、さらに 1 回分の記事が必要になるので、ここではいくつかの便利な例を紹介します。
Windows Server 2008 DC を DSRM で再起動するには、次のコマンドを使用します。
C:\> bcdedit /set safeboot dsrepair
このコマンドを実行すると、既定のブート ローダー エントリにセーフ ブートが設定されます。Windows Server 2008 の新規インストールでは、WINLOAD.EXE というブート ローダー エントリのみが設定されています。セーフ ブート オプションを削除し、通常モードで再起動するには、次のコマンドを使用します。
C:\> bcdedit /deletevalue safeboot
通常ブートと DSRM ブートを提供するための 2 つのブート ローダー エントリを DC に構成すると、作業が多少楽になります。この構成を行うことによって、[システム設定] から起動できる [起動と回復] ダイアログ ボックスを使用して、ブート オプションを変更できるようになります。新しいブート ローダー エントリを追加するには、次のコマンドを使用します。
C:\> bcdedit /copy {default}
/d "Directory Service Repair Mode"
これにより、既定のブート ローダー エントリがコピーされ、新しいブート ローダー エントリが作成されます。BCDEDIT によって、次のようなメッセージが表示されます。
The entry was successfully copied to
{c50d4710-a1f0-11dc-9580-0003ff402ae9}.
この GUID は、新しいエントリを示しています。続いて次のコマンドを使用して、この BCD の新しいブート ローダー エントリにセーフ ブートを設定します。
C:\> bcdedit /set {<GUID for new entry>}
safeboot dsrepair
これで、[起動と回復] ダイアログ ボックスの設定を使用して、ブート モードを通常モードから DSRM モードに切り替えられるようになりました (図 10 参照)。
Figure 10 Disable incremental backups on busy volumes
Figure 10 Disable incremental backups on busy volumes
WBADMIN を使用してシステム状態の復元を開始する前に、復元に使用するバックアップを指定する必要があります。WBADMIN では、完全なシステム バックアップ、重要なシステム ボリュームのみを含むバックアップ、またはシステム状態のバックアップを使用して、システム状態の復元を実行できます。いずれの場合も、使用するバックアップのバージョンを指定する必要があります。使用できるバックアップのバージョンを最も簡単に確認するには、次の WBADMIN コマンドを使用します。
C:\> wbadmin get versions
このコマンドを実行すると、WBADMIN によって、図 11 のような形式でバックアップのバージョンが表示されます。各バックアップが保持している情報には、バックアップ時刻、バックアップ ターゲット、バージョン ID (世界標準時で表されたバックアップの開始時刻)、そのバックアップでサポートされている回復操作の種類などがあります。
Figure 11 回復に使用できるバックアップを特定する (Close Figure 11)
wbadmin 1.0 - Backup command-line tool
(C) Copyright 2004 Microsoft Corp.
Backup time: 11/30/2007 3:47 PM
Backup target: Fixed Disk labeled E:
Version identifier: 11/30/2007-22:47
Can Recover: Application(s), System State
Backup time: 12/1/2007 10:46 PM
Backup target: Fixed Disk labeled Backup(E:)
Version identifier: 12/02/2007-05:46
Can Recover: Volume(s), File(s), Application(s), Bare Metal Recovery, System State
Backup time: 12/2/2007 5:58 PM
Backup target: Fixed Disk labeled Backup(E:)
Version identifier: 12/03/2007-00:58
Can Recover: Volume(s), File(s), Application(s), Bare Metal Recovery, System State
Backup time: 12/3/2007 11:25 AM
Backup target: Fixed Disk labeled E:
Version identifier: 12/03/2007-18:25
Can Recover: Application(s), System State
ここでは、次の WBADMIN コマンドを使用して、最新のバックアップを選択し、システム状態の復元を実行します。
C:\> wbadmin start systemstaterecovery
–version:12/03/2007-18:25
このコマンドでは、権限のない復元が実行されます。SYSVOL の権限のある復元を実行する場合は、WBADMIN コマンドに authsysvol オプションを追加して、復元する SYSVOL レプリカに権限のある状態を指定できます。この手順の詳細については、go.microsoft.com/fwlink/?linkid=113152 を参照してください。

Active Directory のスナップショットを作成する
Active Directory のバックアップに関する最も魅力的な変更の 1 つは、Windows Server バックアップとはまったく関連していません。Windows Server 2008 では、Active Directory で提供されているボリューム シャドウ コピー サービスのスナップショットを活用できます。これらのスナップショットは、特定の時点で作成された、非常にサイズの小さい実行中の Active Directory サービスのバックアップです。さらに良いことに、作成には数秒しかかかりません。これらのスナップショットをマウントし、LDP ツールなどの一般的な LDAP ベースのユーティリティを使用して、スナップショットにアクセスできます。
ADDS または Active Directory ライトウェイト ディレクトリ サービス (ADLDS) のスナップショットを作成するには、次の NTDSUTIL コマンドを使用します。
ntdsutil: snapshot
snapshot: activate instance ntds
Active instance set to "ntds".
snapshot: create
Creating snapshot...
Snapshot set {42c44414-c099-4f1e-8bd8-4453ef2534a4} generated successfully.
snapshot: quit
ntdsutil: quit
この一連の NTDSUTIL コマンドを実行すると、Active Directory DIT、ログ、および SYSVOL が格納されているボリュームのスナップショットがボリューム シャドウ コピー サービスによって作成されます。ボリューム シャドウ コピー サービスでは、コピー オン ライト メカニズムが使用されるので、Active Directory の更新中でも、作成したスナップショットは適切に維持されます。これらのスナップショットは DIT の完全なコピーではないことに注意してください。これらは、スナップショットの作成後に変更された、DIT のディスク ブロックのコレクションであるにすぎません。VSS では、DIT の現在のコピーとこれらのブロックを組み合わせることによって、スナップショットを作成した時点の Active Directory DIT を表現します。図 12 は、古いまたは不要なスナップショットを削除する方法を示しています。
Figure 12 不要なスナップショットを削除する (Close Figure 12)
C:\> ntdsutil
ntdsutil: snapshot
snapshot: list all
 1: 2007/12/03:23:18 {42c44414-c099-4f1e-8bd8-4453ef2534a4}
 2:   C: {c0dd71ba-5bcd-4daf-9fbb-5cfbdd168022}
 3:   D: {2bbd739f-905a-431b-9449-11fba01f9931}
snapshot: delete 1
Snapshot {c0dd71ba-5bcd-4daf-9fbb-5cfbdd168022} mounted as C:\$SNAP_200712032318_VOLUMEC$\
Snapshot {2bbd739f-905a-431b-9449-11fba01f9931} mounted as C:\$SNAP_200712032318_VOLUMED$\
snapshot: quit
ntdsutil: quit
C:\>

Active Directory のスナップショットをマウントする
Active Directory のスナップショットを使用するには、まずファイル システムでこのスナップショットを利用できるように、ボリューム シャドウ コピー サービスに指示する必要があります。これを行うには、ntdsutil コマンドを使用して、利用可能なスナップショットの一覧を取得した後、目的のスナップショットをマウントします (図 13 参照)。
Figure 13 ntdsutil を使用してスナップショットをマウントする (Close Figure 13)
C:\> ntdsutil
ntdsutil: snapshot
snapshot: list all
 1: 2007/12/03:23:18 {42c44414-c099-4f1e-8bd8-4453ef2534a4}
 2:   C: {c0dd71ba-5bcd-4daf-9fbb-5cfbdd168022}
 3:   D: {2bbd739f-905a-431b-9449-11fba01f9931}
snapshot: mount 1
Snapshot {c0dd71ba-5bcd-4daf-9fbb-5cfbdd168022} mounted as C:\$SNAP_200712032318_VOLUMEC$\
Snapshot {2bbd739f-905a-431b-9449-11fba01f9931} mounted as C:\$SNAP_200712032318_VOLUMED$\
snapshot: quit
ntdsutil: quit
C:\>
list all コマンドでは、現在ボリューム シャドウ コピー サービスによって維持されている利用可能な Active Directory スナップショットをすべて表示しています。mount 1 コマンドでは、選択された Active Directory DIT とログ ボリュームのスナップショットをマウントし、これらのスナップショットをファイル システムで利用できるようにしています。これらのスナップショットは、C:\$SNAP_200712032318_VOLUMEC$\ と C:\$SNAP_200712032318_VOLUMED$\ に格納されています。
これらのフォルダを参照すると、スナップショットを作成した時点でボリュームに格納されていたすべてのコンテンツを確認できます。ただし、マウントされたスナップショットは読み取り専用なので、これらのスナップショット内のファイルを変更することはできません。

Active Directory のスナップショットからデータを回復する
Active Directory が格納されたボリュームのスナップショットをマウントする作業は、なんだか手品のように思えます。これらのスナップショットに格納されている Active Directory のデータを取得するには、どうすればよいでしょうか。その秘密の答えは、DSAMAIN コマンドです。これは、ADLDS を実行する実行可能ファイルであり、実質的には、ほぼすべてのコードを ADDS と共有する、スタンドアロンの LDAP サーバーです。DSAMAIN を使用すると、マウントされたスナップショットを、そのスナップショットを作成した時点の Active Directory データが格納された、読み取り専用の LDAP サーバーのように扱うことができます。
では、次のコマンドについて考えてみましょう。
C:\> dsamain –dbpath
c:\$snap_200712032318_volumed$\ntds\dit
\ntds.dit -ldapport 10000
このコマンドでは、c:\$snap_200712032318_volumed$\ntds\dit フォルダにある ntds.dit ファイルをマウントし、TCP ポート 10000 (または指定した任意の開いているポート) 上の LDAP 操作で使用できるようにしています。指定したポート番号に 1 を足したポート (この例では 10001) 上で LDAPS ポート (LDAP over Secure Sockets Layer 用のポート) が開かれ、2 を足したポート (10002) 上で GC ポート (グローバル接続用のポート) が開かれます。同様に、3 を足したポート (10003) 上で GCS (Global Catalog over Secure Sockets Layer) ポートが開かれます。
指定したポートを経由して、マウントされた DIT にアクセスする場合、任意の LDAP プログラム (LDP など) を使用できます。ただし、Windows Server 2008 の Active Directory ユーザーとコンピュータ (ADUC)、Active Directory サイトとサービス、Active Directory ドメインと信頼関係、および ADSIEDIT は、DSAMAIN を使用して、マウントされた DIT に接続できるように変更されています。ADUC のナビゲーション ウィンドウの最上位にあるノードを右クリックし、[ドメイン コントローラの変更] をクリックすると、図 14 のようなダイアログ ボックスが表示されます。マウントされたスナップショットをホストしているサーバーの名前か IP アドレス、およびポート (この例では localhost:10000) を入力するだけで、マウントされたスナップショットに ADUC が接続され、スナップショットを作成した時点のディレクトリ コンテンツを参照できるようになります。とても簡単ですね。
Figure 14 Connecting Active Directory users and computers to a mounted snapshot
Figure 14 Connecting Active Directory users and computers to a mounted snapshot
このような方法でディレクトリ データにアクセスすることによって、これまでよりも簡単に、さまざまなデータ回復作業を行うことができます。たとえば、削除されたオブジェクトをバックアップから回復する場合、以前は、既存の DC 上でそのバックアップの権限のない復元を実行してから、削除されたオブジェクトの権限のある復元を実行する必要がありました。復元したバックアップに正しいデータが格納されていなかった場合、別のバックアップを使用してこの操作を最初からやり直す必要がありました。現在では、廃棄済みオブジェクトの復元とスナップショットを使用して、削除されたデータをすばやく検索および回復できるようになりました。この操作を行うためにドメイン コントローラをオフラインにする必要もありません。
ただし、いくつか制限があります。たとえば、アクティブなスナップショットが 1 つ増加するたびに、ディレクトリへの書き込み操作に伴うディスク I/O が増加するので、運用 DC 上では、同時にアクティブにするスナップショットは 1 つまたは 2 つにした方がよいでしょう。また、スナップショットをアクティブにしている時間が長いほど、ボリューム シャドウ コピー サービスの差分ストアが増大し、パフォーマンスに悪影響を与える可能性があります。さらに、当然のことですが、削除されたオブジェクトの復元自体は、回復の第一歩にすぎません。おそらく、そのオブジェクトに関連付けられている属性 (グループのメンバシップなど) も回復する必要があるでしょう。ただし、この場合も、スナップショットを使用して、削除されたオブジェクトが所属していたすべてのグループを特定できます。

Active Directory の適切なバックアップおよび回復戦略
Windows Server 2008 では、まったく新しいバックアップおよび回復システムが導入されています。最初のうちは歓迎されない変更もあるかもしれませんが、一度これらの変更を受け入れて、新しいバックアップ テクノロジを日常の業務に組み込めば、より効果的なバックアップおよび回復ソリューションを実装できます。
Windows Server 2008 では、サーバーのバックアップ方法が大幅に変更されていますが、Active Directory のバックアップと回復に関する基本的な戦略は、実際にはそれほど変わっていません。したがって、戦略を立てるときは、次のベスト プラクティスに留意してください。
  • 定期的に実行される完全なシステム バックアップをスケジュールし、ハードウェア障害が発生した後に DC を回復できるようにします。DC の完全バックアップの頻度を決定する際は、データの更新頻度、ダウンタイムやデータ損失の許容範囲、一から DC を再構築する場合にかかる手間を考慮してください。
  • システム状態のバックアップを頻繁に実行し、Active Directory の変更をバックアップするようにします。システム状態のバックアップの頻度は、Active Directory データの損失をどの程度許容できるかによって決まります。ただし、少なくとも 1 日に 1 回は実行することをお勧めします。ハードウェアを所有している場合は、システム状態のバックアップを少なくとも 1 つまたは 2 つローカル ディスクに保存し、古いバージョンのシステム状態のバックアップを DVD またはネットワーク共有にコピーします。
  • 各ドメインの 2 台以上の DC でシステム状態のバックアップを実行します。これにより、いずれかのバックアップが利用できない場合や、その状態に問題がある場合でも、ある程度の保障が提供されます。
アプリケーション パーティションのレプリカが定義されている DC をバックアップする場合は、それらのレプリカもバックアップするようにします。また、重要なシステム ドライブで障害が発生した場合に、すばやく WinRE を起動できるように、DC に Windows 回復環境パーティションを作成することも検討してください。

Gil Kirkpatrick は、NetPro 社の最高技術責任者であり、1996 年以来 Active Directory 用ソフトウェアの開発に取り組んできました。彼が HP 社の Guido Grillenmeier と共同で行う Active Directory 障害回復ワークショップは好評です。また、彼は Directory Experts Conference (www.dec2008.com) の発起人でもあります。
© 2007 Microsoft Corporation and CMP Media, LLC.All rights reserved; 許可なしに一部または全体を複製することは禁止されています.


 Windows の管理: 機能する OU 構造を設計する
Windows の管理 Ken St. Cyr

機能する OU 構造を設計する
概要:
  • 適切な OU 設計の基本原則
  • 一般的な OU 設計モデル
  • OU 設計を文書化する

適切な組織単位 (OU) 構造を設計することの重要性と複雑さを過小評価しないでください。多くの IT 部門は、次のいずれかの方向に向かう傾向があります。
OU 構造を過度に重視するか、OU 構造が十分に考慮されないという 2 つのいずれかです。どちらの場合も、Active Directory® モデルに関する問題を引き起こす可能性があります。
OU 構造を過度に重視すると、Active Directory 設計以外の領域 (サイト トポロジの計画、ドメイン コントローラのサイズの検討など) が十分に考慮されないことがあります。また、OU 計画を後回しにすると、グループ ポリシー機能と委任機能が有効活用されません。
適切な OU 構造が設計されない理由の 1 つとしてよく挙げられるのは、OU 構造には柔軟性があるため適切でない場合は後から変更できる、というものです。確かに、OU 構造には柔軟性があります。しかし、多くの管理者は、OU 構造を後から変更することが、当初予想していたよりも難しいことに気付きます。新しい OU を追加することはできますが、古い OU を削除するのは容易な作業ではありません。
適切に計画されていない OU 構造は、独り歩きする傾向があります。新しいオブジェクトがディレクトリに作成されたときに、管理者がそのオブジェクトを配置する OU 構造の場所を把握していない場合、その管理者は、新しい OU を作成するか、不適切な場所にそのオブジェクトを配置することになります。いずれの場合にも、危険が伴います。新しい OU の作成は簡単に行うことができますが、このように対応すると、長期の運用において OU の管理が困難になります。過剰な OU の作成により、OU 構造が無秩序状態になり、ディレクトリに不正侵入されやすくなります。また、オブジェクトを、そのオブジェクトが実際には属さない既存の OU に追加すると、新しいオブジェクトに不適切なポリシーが適用されたり、そのオブジェクトへのアクセス許可が意図しないユーザーに委任されたりする場合があります。
OU 構造を設計する際には、"簡潔さ + 適応性 = 安定性" という基本的な方程式を念頭に置いておく必要があります。設計が簡潔すぎると、その設計には柔軟性が欠けることがあり、設計を頻繁に変更することが必要となります。設計に適応性がありすぎると、すべてが区分化されるため、その設計は複雑になりすぎます。
グループ ポリシー、委任、およびオブジェクト管理に関して、設計上の方針の指針となる 3 つの基本原則があります。これらの原則は、次の 3 つの質問に置き換えることができます。これらの質問を自問することで、作成している OU 構造に、長期運用と組織変更への適応性があることを確認できます。
  1. この OU は、固有のグループ ポリシー オブジェクト (GPO) を適用できるように作成される必要がありますか。
  2. 特定の管理者グループが、この OU 内のオブジェクトへのアクセス許可を持つ必要がありますか。
  3. この新しい OU によって、この OU 内のオブジェクトの管理が容易になりますか。
上記のいずれかの質問の答えが "はい" の場合には、OU を作成することをお勧めします。3 つすべての質問の答えが "いいえ" の場合には、設計を再考し、より適切な別の設計を検討する必要があります。この 3 つの基本原則の適用方法を詳しく説明する前に、まず、これらの原則が重要である理由を説明します。

原則 1: グループ ポリシー
OU 設計の 1 つ目の原則は、OU に適用されるグループ ポリシー オブジェクトを考慮することです。GPO を使用すると、ユーザーとコンピュータの設定を、強制可能な形で構成できます。Active Directory では複数の GPO を定義し、それらの GPO をドメイン全体、さまざまな OU、またはドメイン内のサイトにも適用できます。GPO は、ユーザーとコンピュータという 2 つのカテゴリに分類されます。
コンピュータ ポリシーとユーザー ポリシーの両方を 1 つの GPO で定義できます。GPO のユーザーの構成のセクションでは、主に、ログイン時のユーザー操作が定義されます。このような設定は、コンピュータの構成のセクションにも存在しますが、このセクションには、コンピュータにローカルでログオンできるユーザーや、データの暗号化方法など、コンピュータのセキュリティに関する設定がより多く含まれます。
GPO をサポートするように OU を定義する際に留意する基本事項を挙げておきます。まず、ユーザー ポリシーとコンピュータ ポリシーの両方を 1 つの GPO で定義できますが、ユーザー オブジェクトとコンピュータ オブジェクトを同じ OU に配置することが適切であるというわけではありません。このように 2 種類のポリシーを 1 つの GPO で定義すると、GPO の適用に関するトラブルシューティングが困難になります。これは、ループバック ポリシーが有効になっている場合により顕著に現れます。
次に、忘れられがちなことですが、GPO はサイト レベルで適用できるため、GPO を適用するためにサイト構造をモデル化して OU 構造を設計できます。これは、OU 設計の一般的なモデルであり、地理的モデルと呼ばれます。このモデルについては、この後すぐに詳しく説明します。地理的モデルが OU 設計において適切な役割を持っていることは認めざるを得ませんが、後述するように、このモデルを実装する最大の理由は GPO を適用するためだけとは限りません。
また、GPO の観点では、OU 構造を検討する際の最終的な目標は、複雑さの軽減です。OU で GPO の継承をブロックしないようにしてください。OU に、他のサーバーと同じポリシーを必要とするサーバーが含まれる場合、これらのコンピュータ オブジェクトを上位の "サーバー" OU に配置し、"サーバー" OU の下に、サーバーの種類ごとに複数の OU を作成することを検討してください (図 1 参照)。この構成により、下位 OU 内の各コンピュータ オブジェクトには、"サーバー" OU に設定されているポリシーと、各サーバーの種類固有の他のポリシーを適用できるため、ポリシーの適用を簡略化できます。
Figure 1 Creating multiple OUs for different server types
Figure 1 Creating multiple OUs for different server types
もう 1 つの基本事項は、複数の GPO を不必要に作成したりリンクしないようにすることです。1 つの GPO では、1 つのポリシーを作成し、作成したポリシーを複数の OU に適用できます。これは、役立つ場合もありますが、悪影響を及ぼす場合もあります。GPO の設定を変更する必要があるときに、複数の GPO がリンクされた過度に複雑なシステムである場合、変更を誤って不適切なオブジェクトに適用してしまう可能性があります。リンクを作成すればするほど、ポリシーの適用範囲を把握するのが困難になります。また、他のポリシーと同じ設定を持つポリシーを新たに作成しないようにすることをお勧めします。同じ設定のポリシーを何度も作成している場合は、新しい GPO 継承モデルを適用できるように OU 構造を変更することを検討してください。
最後に、ほとんどの場合、ユーザー オブジェクトとコンピュータ オブジェクト用に新しい OU を作成する必要があります。既定では、ユーザー オブジェクトとコンピュータ オブジェクトはコンテナに配置されますが、コンテナでは、オブジェクトに直接 GPO をリンクすることはできません。GPO は、ドメインの "ユーザー" コンテナと "コンピュータ" コンテナに適用できますが、継承をどこかでブロックしない限り、GPO はドメイン内のすべてのユーザーとコンピュータに適用されます。Windows Server® 2003 では、rediruser.exe ツールと redircomp.exe ツールを使用して、ユーザー オブジェクトおよびコンピュータ オブジェクトの既定の場所を、各オブジェクト用に作成した OU に変更できます。

原則 2: 委任
OU 構造は、ドメインでアクセス許可が委任される方法と整合性の取れた方法で作成することが重要です。Active Directory でアクセス許可が委任されるとき、アクセス許可の変更は、オブジェクトのみに対して加えられることに注意してください。そのため、ユーザーに特定のコンピュータ オブジェクトのフル コントロールのアクセス許可を与えた場合、そのユーザーは、そのオブジェクトの属性を変更することはできますが、コンピュータ自体の管理者特権は持ちません。
次に、委任に関して、OU 構造の設計時に推奨するいくつかの方法を示します。
アクセス許可の継承を考慮して設計する たとえば、第 1 層の管理者が、大部分のアカウントのパスワードを変更できるようにする必要があるとします。特別なユーザー グループがあり、そのパスワードについては、管理者が再設定できないようにする必要がありますが、そのアカウントの表示名については、管理者が変更できるようにすることが必要です。
この場合、2 つの選択肢があります。1 つは、類似した 2 つの OU を個別に作成し、特別なユーザーと一般ユーザーを分けることができます。しかし、この方法では、すべてのユーザーに対する委任の設定を変更する場合、アクセス許可を 2 つの異なる場所で変更する必要があります。また、この方法は複数のポリシーを不必要にリンクしないという基本事項に相反します (図 2 参照)。
Figure 2 Maintaining two separate parallel OUs
Figure 2 Maintaining two separate parallel OUs
もう 1 つの選択肢は、入れ子になった OU を作成して、特別なユーザーが含まれる OU でアクセス許可を明示的に拒否する方法です。委任について詳しい知識がある人は、明示的な拒否を設定することを推奨しません。しかし、この場合には、推奨されないものの中からより適切な方を選択する必要があります (図 3 参照)。類似した 2 つの OU を個別に作成して設定を別々に管理するか、OU の 1 つでアクセス許可を明示的に拒否する、といういずれかの方法を選択できます。実際の長期的な方針としては、明示的な拒否の方がより適切です。
Figure 3 Using an explicit deny permission
Figure 3 Using an explicit deny permission
AdminSDHolder に注意する この例は、すべての特別なユーザーが、管理グループのいずれか (Domain Admins、Schema Admins、Enterprise Admins、または Administrators) に属している場合を除いて有効です。これらのグループに属するアカウントのアクセス許可は異なる方法で処理されます。誤ってだれかに管理者アカウントへのアクセス許可を与えないようにする必要があります。
管理者用に個別の OU を作成すると、委任されたアクセス許可が失われていることがあります。これは、アクセス制御リストを指定の間隔ですべての管理者アカウントに適用する、特別なコンテナである AdminSDHolder による現象です。したがって、管理者アカウントに対して行った委任の変更は、AdminSDHolder コンテナに対しても同じ変更を行わないと、元に戻されます。そのため、委任のために、管理者アカウントとその他のアカウントを分けないようにする必要があります。ただし、グループ ポリシーの観点では管理者アカウントと一般ユーザー アカウントを分けることをお勧めします。これは、特に、複数のパスワード ポリシーを設定できる Windows Server 2008 に当てはまります。

原則 3: オブジェクト管理
OU により、オブジェクトの管理が容易になります。多くの場合、オブジェクトを同じ OU にグループ化することで、一括変更をより簡単に実行できるようになります。Active Directory ユーザーとコンピュータ スナップインを使用すると、複数のオブジェクトを選択して、その特定の属性を編集できます。したがって、あるオブジェクト グループの属性を定期的に変更する必要がある場合、すべてのオブジェクトが同じ OU に属していると変更作業が楽になります。
これは、スクリプトを使用して更新を行う場合に特に役立ちます。スクリプト言語を使用すると、OU 内のすべてのオブジェクトを列挙して、オブジェクトを 1 つずつ処理する作業が非常に簡単になります。また、各オブジェクトを個別に検索および変更する作業も簡単に行えます。管理目的で、オブジェクトを同じ OU に配置するだけで、一部の作業が不要になり、毎週何時間もの時間を節約できる場合があります。
オブジェクト管理に役立つ別の方法は、オブジェクトを種類ごとに異なる OU に分けることです。プリンタ オブジェクトや公開済みの共有用に個別の OU を作成すると、OU 内の他のオブジェクトを管理するときに、これらのオブジェクトを除外する必要がなくなります。この方法は、ユーザー アカウントとコンピュータ アカウントを同じ OU にまとめてグループ化しないという基本事項に従っています。

モデルを選択する
OU 設計の原則の説明が終わったところで、次に、いくつかの一般的な設計モデルについて詳しく見てみましょう。ここで取り上げるモデル以外にも多くのモデルがあることに注意してください。また、選択できるモデルは 1 つだけではありません。各モデルから必要な要素を選択し、特定のニーズに対応する独自の複合型モデルを構築できます。
どのモデルも、小規模企業では適切に利用することができます。しかし、企業が拡大するにつれ、環境の管理能力は低下します。そのため、まず、適切なラボ環境でモデルを徹底的にテストするようにしてください。また、OU 構造は、最初のうちは簡単に変更できますが、実装期間が長くなるほど変更が困難になることを忘れないでください。

浅部モデル
浅部モデルという名称は、その構造がほぼフラットであることに由来しています。このモデルでは、少数の上位レベルの OU に、大部分のオブジェクトが含まれます (図 4 参照)。このモデルは、多くの場合、IT 部門が小規模な企業、部門数が少ない企業、または各人が複数の任務を担う傾向にある企業など、小規模企業で使用されます。通常、私は、OU の階層構造でサブ OU が 10 個を超える深さにならないようにすることを推奨していますが、マイクロソフトが推奨するパフォーマンスの低下を防ぐためのサブ OU の制限は 15 です。
Figure 4 The Shallow Model has a few high-level OUs that contain the majority of objects
Figure 4 The Shallow Model has a few high-level OUs that contain the majority of objects
人事担当者が給与管理も担当している場合、人事用と給与管理用に 2 つの異なる OU を作成することに意味はありません。浅部モデルでは、すべてのユーザー オブジェクトを、1 つの大きな "アカウント" OU にグループ化するか、既定の "ユーザー" コンテナに配置できます。少なくとも、ユーザー オブジェクトとコンピュータ オブジェクトを分ける必要があります。
このモデルでは、一歩先まで踏み込んで、ワークステーションとサーバーを分けることもお勧めします。このような構成にすると、少なくとも、Windows® Management Instrumentation (WMI) クエリを使用して、ワークステーションまたはサーバーをフィルタで除外する GPO を定義することなく、ワークステーションとサーバーに異なるグループ ポリシーを適用することができます。
OU 構造に深さではなく幅を持たせるメリットの 1 つは、Active Directory 検索を高速化できる点です。通常、私は、サブ OU が 10 個を超える深さにならないようにすることを推奨しています。このモデルでは、あまりきめ細かくオブジェクトを制御することはできませんが、小規模企業でオブジェクトを管理している場合には、それほどきめ細かい制御は必要ありません。つまり、このモデルは、大企業での使用には適していませんが、小規模企業での使用には最適なモデルだと言えます。

地理的モデル
地理的モデルでは、地域ごとに個別の OU を作成します。このモデルは、分散型の IT 部門を持つ企業で、複数ドメインの運用に伴うコストの発生を望まない場合に最適です (図 5 参照)。
Figure 5 The Geographic Model separates OUs by geographical region
Figure 5 The Geographic Model separates OUs by geographical region
たとえば、アトランタ、ボルティモア、およびシアトルに支社があるとします。各拠点でそれぞれのユーザーとコンピュータを管理している場合、委任の観点から、このモデルが最適な場合があります。しかし、シアトル支社のユーザーが研修のためにボルティモア支社に行き、自分のアカウントをロックアウトした場合はどうなるでしょうか。ボルティモア支社の IT スタッフは、このユーザーのアカウントへのアクセス許可が委任されていない場合、このユーザーをサポートできない可能性があります。ボルティモアが午前 8 時であるとすると、シアトルは午前 5 時です。つまり、ユーザーは、シアトル支社のスタッフのサポートを得るまで数時間待たなければなりません。
一部の世界的企業では、"太陽追従" モデルを使用しています。その場合、ヘルプ デスクへの問い合わせは、その時点で、通常の業務時間中であるタイム ゾーン内の拠点に転送されます。つまり、企業は、各拠点のヘルプ デスクを 24 時間対応にしなくても、業務時間外でも必要なときに従業員にサポート (アカウントのロック解除など) を提供できます。
このような場合、地域ごとに個別の OU を作成することは、運用上のニーズに最も適した方法ではないでしょう。各地域の "ユーザー" OU に対する個別のアクセス許可を各地域のヘルプ デスクに委任する必要があります。しかし、各拠点に独立した IT 部門がある場合は、地理的モデルがその企業に適したモデルであることがあります。
また、地理的モデルは、ドメインの運用方法の性質上、単一のドメインでの利用は困難です。単一のドメインを運用している場合、他の複数のドメインを運用している場合とは異なるセキュリティ モデルを採用している傾向があります。これは、Microsoft® Exchange Server などの全社規模のアプリケーションを見るとより明らかです。
アトランタ支社で運用している Exchange Server で異なるメッセージ ポリシーを定義することは可能ですが、企業内のすべての Exchange Server には、おそらく同じ GPO が適用されています。この場合、地域ごとに Exchange Server を個別の OU に配置すると、同じ GPO が複数の OU に不必要にリンクされる原因となります。委任の観点から、Exchange Server の管理者が本当に Exchange Server のコンピュータ オブジェクトへの固有のアクセス許可を必要としているかどうかを確認する必要があります。ほとんどの場合、コンピュータ オブジェクトが地域ごとの OU に分けられるのは、委任のためではなく、グループ ポリシーのためです。

種類ベース モデル
種類ベース モデルでは、オブジェクトを目的ごとに分類します (図 6 参照)。前回ユーザー オブジェクトを作成したとき、それは、一般ユーザー アカウント、管理者アカウント、またはサービス アカウントのうち、どのアカウントとして作成したものでしょうか。種類ベース モデルでは、これらのオブジェクトの処理がそれぞれ異なります。
Figure 6 The Type-Based Model groups objects according to their functions
Figure 6 The Type-Based Model groups objects according to their functions
通常、ポリシーを適用するには、ユーザー オブジェクトの分類を識別する必要があります。ほとんどの場合、ポリシーはユーザー アカウントの種類によって異なります。たとえば、ユーザーがサービス アカウントを使用してコンピュータにログオンできるようにすることは、業務上、一般的に適切ではありません。通常、サービス アカウントのパスワードは、多数のユーザー間で共有されるので、サービス アカウントを使用してログオンすると、そのユーザーは匿名ユーザーになります。何か問題が発生した場合、イベントの発生時にログインしていたユーザーの特定が困難になります。この例では、サービス アカウントに、対話型ログオンを防ぐポリシーを設定する必要があります。これは、図 3 の階層モデルに適しています。
ここで、GPO の継承を活用できます。たとえば、すべてのユーザー オブジェクトに設定されるポリシーを参照する、全ユーザー用ポリシーを適用できます。また、全ユーザー用ポリシーをベースに作成した、サービス アカウント用の個別の異なるポリシーを適用できます。この方法によって、サービス アカウントには、その他すべてのアカウントと同じ一連の基本ポリシーと、特定のログオンの制限を適用できます。
この方法は、GPO の継承ではなく、アクセス許可の継承を使用している委任でも有効です。たとえば、第 2 層の管理者が、第 3 層の管理者アカウントを除く、すべてのアカウントのパスワードを再設定できるようにする必要があるとします。フラットな OU 構造では、ユーザー アカウントが含まれる各 OU にアクセス許可を委任する必要があります。しかし、階層構造を持つ種類ベース モデルでは、第 2 層のグループに "アカウント" OU に対する "パスワードの再設定" アクセス許可を付与してから、第 3 層の OU で、単純にアクセス許可を継承しないようにするか、第 2 層に対してパスワードの再設定を明示的に拒否できます。
これは、コンピュータ オブジェクトの場合にも有効です。異なるポリシーを適用できるように、サーバーとワークステーションを分けることができます。さらに、"サーバー" OU を機能ごとに細分化できます (図 1 参照)。この設計では、すべてのサーバーに適用する上位レベルのポリシーを "サーバー" OU に設定して、下位レベルの OU ごとに個別のポリシーを設定できます。
たとえば、Microsoft Operations Manager (MOM) サービス アカウントがあるとします。この階層化モデルを使用すると、MOM 用の GPO を作成し、それを MOM OU に適用できます。そして、MOM 用の GPO で、サービスとしてログオンするための権限を MOM サービス アカウントに付与できます。この GPO は、MOM OU 内の MOM サーバーにのみ適用されます。MOM サーバーには、上位レベルの "サーバー" OU の全サーバー用ポリシーが適用されるだけでなく、MOM OU にリンクされている特別な MOM 用の GPO も適用されます。

設計を文書化する
Active Directory 環境で発生する多くの変更に対応できる OU 構造を設計することには、非常に大きな価値があります。しかし、動的な OU の特性を追跡する手段が必要です。追跡する手段がないと、すぐに環境を管理できなくなります。変更事項が発生し、OU の追加または削除が必要になったときには、処理方法に関する明確な指針が必要です。その指針によって、モデルが、3 つの基本原則を満たしながら継続して設計モデルに従うようにします。そのため、適切な解説が記載された設計書が必要です。
マイクロソフトは、Windows Server リソース キットで文書化のガイドを提供しています。このガイドは、あまり多くの変更が行われないことが予想される、安定した枠組みを持つ構造では有効です。しかし、ほとんどの企業で実装する構造は、頻繁に変更される非常に動的なものです。そこで、次に、OU 構造が適切に文書化され、動的な環境をサポートできることを確認するための、いくつかの重要なヒントを紹介します。
すべての情報が適切な情報であることを確認する 目的を持った文書には必ず価値があります。実務で使用する多くの文書には、余分な情報が大量に含まれているため、重要な情報を見つけるのが困難です。文書化の過程で、文書化という目的だけに固執して、本来の目的を忘れないようにしてください。各 OU に含まれるオブジェクトの数や、OU のアクセス制御リストのアクセス制御エントリ (ACE) の数などを記載する必要はありません。通常、OU の文書には、次の情報が含まれていれば十分です。
  • OU 名
  • 簡単な説明
  • 作成者 (または詳細や変更に関する問い合わせ先)
  • 作成日時
更新を困難にしない 複雑な Microsoft Word 文書を頻繁に更新する必要があるときによくある傾向は、更新作業を先延ばしにすることです。直近で大幅な更新作業をまとめて行うことがわかっているときに、小さな変更作業を留保することは問題ありません。残念ながら、多くの場合、そうした小さな変更は忘れられたり、いつまでも先延ばしにされて変更作業はまったく完了しません。したがって、先延ばしにされることがないよう、文書の更新は非常に簡単な作業である必要があります。通常は、列が数列ある単純な Microsoft Excel® スプレッドシートで問題ありません。
オブジェクト自体にコメントを作成する OU オブジェクトには、コメントを入力できる "説明" 属性があります。他のユーザーが OU の目的をすぐに認識できるように、コメントは、設計文書に記述するのではなく、"説明" 属性に追加することを検討してください。詳しい説明を含める必要がある場合には、簡単な説明を "説明" 属性に追加し、詳細を OU の文書に記述します。
文書化を自動化する スクリプトを記述して、OU 構造の内容をテキスト ファイル、Excel スプレッドシート、または HTML ファイルにダンプすることができます。このスクリプトは、スケジュール タスクとして毎晩実行できます。これは、コメントを OU の "説明" フィールドに追加している場合に非常に役立ちます。その場合、単に "説明" 属性をファイルにダンプするだけで、OU 構造の詳細な文書が自動的に作成され、この文書は常に最新の状態が保たれます。既存の文書を上書きするのではなく、スクリプトを実行するたびに新しいファイルを作成すると、時間の経過に伴う OU 構造の変更に関する履歴レコードを作成することができます。
残念ながら、多くの管理者が OU 構造を適切に文書化することの重要性を認識するのは、そのような文書が本当に必要になったときです。そのときは、たいてい真夜中で、復元を実行せずに、誤って削除された他の OU を特定することはほぼ不可能です。
こうした問題が発生する前に、対応策を講じてください。積極的に OU の文書化に取り組み、すぐに OU 設計の文書化を開始して、文書の更新担当者を任命することを強くお勧めします。文書を更新しやすくするという規則に従えば、更新作業が滞らないようにするのは非常に簡単な作業です。

Ken St. Cyr は、IT 業界での経験が 10 年ある、マイクロソフトのコンサルタントです。Active Directory の誕生以来、Active Directory ベースのディレクトリ ソリューションを設計および実装してきました。


 Windows の管理: Active Directory スキーマを拡張する
Windows の管理 Vikas Malhotra

Active Directory スキーマを拡張する
概要:
  • 既定の Active Directory スキーマを理解する
  • classSchema または attributeSchema オブジェクトを追加する
  • オブジェクト識別子を取得して使用する
  • .ldif ファイルを使用してスキーマを拡張する
この記事で使用しているコードのダウンロード: Schema2008_05.exe (151KB)

Windows 2000 のリリースで Active Directory が導入されて以来、マイクロソフトでは、Active Directory を実装するための基本的なスキーマ定義を提供しています。
Active Directory® によって、Windows® を基盤とする多くのアプリケーションの作成および実装方法も転換を遂げました。Active Directory が導入されるまで、Microsoft® Exchange 5.5 などのアプリケーションを構築する際は、独自のディレクトリ構造が実装されていました。Active Directory を利用できるようになったことで、開発者は、多くのアプリケーション (マイクロソフト製および他社製) の開発時に、独自のスキーマをゼロから構築するのではなく、Active Directory によって提供される構造を基盤として活用するようになりました。
このようなアプリケーションを開発する際は、まず Active Directory によって提供される基本的なアーキテクチャを使用し、必要に応じてそれを拡張しました。たとえば、Microsoft Exchange 2000 では、メッセージングの実装に Active Directory が利用され、この実装によって、その後のマイクロソフトのメッセージング アーキテクチャが定義されました。
現在、Active Directory 環境で動作するように作成された多くのアプリケーションでは、Active Directory のスキーマが基盤として使用されており、そこに追加する形で、要件に応じた独自の変更がスキーマに定義されています。後述しますが、当然この変更を実装するには、拡張可能なスキーマが必要です。さらに、非常に多くのアプリケーションが Active Directory の基本的な定義に依存しているので、コア スキーマの継続的な安定性が提供されることは非常に重要です。また、多くのアプリケーションを同じ Active Directory 内で同時に実行する必要があるので、いずれかのアプリケーションが変更されたときに、他のアプリケーションにその影響が及ばないようにする必要があります。

スキーマとは
多くのユーザーにとって、Active Directory スキーマはブラック ボックスのようなものなので、スキーマを独自に変更するという考えには抵抗があるかもしれません。もちろん、Active Directory スキーマの拡張は、毎日発生する作業ではありませんが、特定のアプリケーションやビジネスで必要になる場合があります。したがって、スキーマの定義と内容を理解することは非常に重要です。Active Directory は、多くの組織にとって重要な資産なので、不適切な更新が原因で Active Directory が正常に機能しなくなった場合、重大な影響が発生する可能性があります。
多くの組織では、1 つの戦略として、Active Directory スキーマを拡張するのではなく、Windows Server® 2008 の Active Directory ライトウェイト ディレクトリ サービス (ADLDS) や Windows Server 2003 の Active Directory Application Mode (ADAM) を使用してテストを実行したり、カスタマイズされたスキーマ定義を直接実装したりすることが検討されています。
スキーマは、ディレクトリ サービスの構成を提供する、基盤となる構造です。Active Directory スキーマでは、Active Directory ドメイン サービス (ADDS) で使用されるオブジェクトのクラスと属性が定義されます。コア スキーマでは、多くの既知のクラス (user、computer、organizationalUnit など) と属性 (telephoneNumber、objectSID など) の定義が提供されます。コア スキーマ定義に含まれているオブジェクトはカテゴリ 1 のオブジェクトと呼ばれ、追加されるオブジェクトはカテゴリ 2 のオブジェクトと呼ばれます。
Active Directory スキーマは、cn=Schema, cn=Configuration,dc=X (X は Active Directory フォレストの名前空間です) というパスに定義されたコンテナに格納されています。Active Directory フォレストに格納されるスキーマは 1 つであることに注意してください。フォレスト内のスキーマ定義に変更を加えると、そのフォレスト内のすべてのドメインが変更の影響を受けます。図 1 は、Windows Server の各バージョンの Active Directory スキーマで追加されるクラスと属性の数を示しています。
Figure 1 クラスと属性の数 (Close Figure 1)

バージョン | 追加される属性の数 | 追加されるクラスの数 | スキーマ拡張ファイル
Windows Server 2003 | 208 | 49 | sch14.ldf ～ sch30.ldf
Windows Server 2003 R2 | 81 | 29 | sch31.ldf
Windows Server 2008 | 136 | 10 | sch32.ldf ～ sch44.ldf
各バージョンでスキーマの更新を行う際は、Adprep という名前のユーティリティを使用します。Windows Server 2003 R2 で更新を行うと、スキーマのバージョンは 31 に変更され、Windows Server 2008 で更新を行うと、スキーマのバージョンは 44 に変更されます。
このバージョンを確認するには、ADSIEdit などのツールを使用して、Active Directory の cn=Schema,cn=Configuration,dc=X に格納されている objectVersion 属性の値を調べます。Exchange Server や System Management Server (SMS) など、Active Directory に依存する一部のアプリケーションは、必要に応じてスキーマを変更する場合があることに注意してください。

基盤となる要素
Active Directory は、classSchema (略してクラス) と attributeSchema (略して属性) という 2 種類のオブジェクトから構成されます。通常、Active Directory スキーマの拡張が組織で検討されるのは、既存のスキーマで提供されていない特定の属性にデータを格納する必要がある場合です。Active Directory スキーマの属性を作成するには、まずスキーマ コンテナ内の attributeSchema オブジェクトを指定してから、その新しいオブジェクトに必要なプロパティを定義します。
attributeSchema オブジェクトのプロパティの一覧と、これらのプロパティの詳細については、go.microsoft.com/fwlink/?LinkId=110445 を参照してください。ご覧になっていただければわかりますが、attributeSchema オブジェクトに定義できるプロパティは多数あります。これらの多くは必須のプロパティです。
スキーマには、通常の属性以外にも、ペアで実装され、前方リンクと後方リンクを提供する、リンクされた属性が含まれています。例として、Active Directory のグループ メンバシップについて考えてみましょう。グループ (たとえば、John Doe という名前のメンバを含む ContosoEmployees という名前のグループ) の member 属性は前方リンクで、対応するメンバ オブジェクトの memberOf 属性は後方リンクです (つまり、John Doe の memberOf 属性が照会されると、ContosoEmployees グループの識別名 (DN) が算出されます)。
前方リンクの機能は、他の属性とほぼ同じで、1 つ以上の値を指定できます (member 属性と同様、グループのメンバとして複数のオブジェクトを含めることができます)。これらの値は、親オブジェクトと共にディレクトリに格納されます。
一方、後方リンクは、参照整合性を維持するために、システムによって管理されます。後方リンク属性の値を照会すると、対応するすべての前方リンクの値から結果が算出されます。後方リンクでは、常に複数の値が保持されます。
ADDS の各オブジェクト クラスは、スキーマ コンテナ内の classSchema オブジェクトによって定義されます。classSchema オブジェクトを正しく定義するうえで重要な属性の一覧については、go.microsoft.com/fwlink/?LinkId=110445 を参照してください。
指定できるクラスは、構造型、抽象型、および補助型の 3 種類です。これらのクラスは、objectClassCategory 属性の値によって定義されます (88 と呼ばれる 4 番目のカテゴリには、X.500 1993 規格よりも前に定義されたクラスが含まれます。この種類のクラスを定義するには、objectClassCategory 属性に 0 を指定します。ただし、この種類のクラスは、今後定義しないことをお勧めします)。

識別子を取得して使用する
ディレクトリの classSchema オブジェクトと attributeSchema オブジェクトの ID は、必須のオブジェクト識別子 (OID) を使用して定義されます。classSchema オブジェクトの OID は governsID に対して定義され、attributeSchema オブジェクトの OID は attributeID に対して定義されます。これらの ID は、オブジェクトを識別するために、特定の発行機関によって提供される一意の数値です。数値の形式は、LDAP プロトコルの定義 (RFC 2251) で規定されています。Active Directory スキーマの OID には、国際標準化機構 (ISO) によって発行されるものや、マイクロソフトによって発行されるものがあります。OID は、ディレクトリ内のオブジェクトごとに一意である必要があります。
OID は、1.2.840.113556.1.y.z などの一連の数値です (図 2 参照)。たとえば、ユーザーの classSchema オブジェクトの場合は 1.2.840.113556.1.5.9 です。
Figure 2 ユーザー オブジェクトの識別子 (Close Figure 2)

値 | 意味 | 説明
1 | ISO | ルート機関を表します。
2 | ANSI | ISO によって団体に割り当てられた番号です。
840 | 米国 | 団体によって国または地域に割り当てられた番号です。
113556 | マイクロソフト | 国や地域によって組織に割り当てられた番号です。
1 | Active Directory | 組織によって割り当てられた番号です (この場合はマイクロソフト)。
Y | オブジェクトの種類 | classSchema や attributeSchema など、さまざまなオブジェクトの種類 (カテゴリ) を定義する番号です。たとえば、5 はオブジェクト クラスを表します。
Z | オブジェクト | カテゴリ内の特定のオブジェクトを識別する番号です。たとえば、ユーザー クラスには 9 が割り当てられます。
組織でスキーマを拡張する際は、一意の OID を使用できるように、独自の OID ルート番号を取得します。その後、取得した番号を枝分けして、組織でオブジェクトの新しいクラスと属性を作成したときに、一意の ID を提供します。OID ルート番号は、ISO の National Registration Authority (NRA) から直接取得できます。米国の NRA は米国規格協会 (ANSI) です。
OID ルート番号の取得手順とその料金体系については、ansi.org を参照してください。米国以外の地域については、該当する ISO の加盟組織にお問い合わせください。ISO から加盟組織の一覧が提供されています (iso.org/iso/about/iso_members.htm)。
以前は、組織から schemreg@microsoft.com (英語のみ) に電子メールを送信することで、マイクロソフトから OID を取得できましたが、現在は、電子メールを送信すると、VBScript (go.microsoft.com/fwlink/?LinkId=110453) をダウンロードして実行するよう依頼者に要求するメッセージが自動的に返信されます。
マイクロソフトによって発行される OID には、1.2.840.113556.1.8000.x など、マイクロソフトの OID 番号空間に属する番号が割り当てられます (x は組織に割り当てられる一意の番号です)。組織では、これらの OID をさらに枝分けして、オブジェクトを指定できます。したがって、組織では、たとえば新しい classSchema オブジェクトに 1.2.840.113556.1.8000.x.1.y を使用し、attributeSchema オブジェクトに 1.2.840.113556.1.8000.x.2.z を使用できます (x は組織の一意の番号を表し、y と z はそれぞれ特定の classSchema オブジェクトと attributeSchema オブジェクトに割り当てられた番号を表しています)。また、これらのオブジェクトの名前に組織固有のプレフィックスを使用して、オブジェクトを区別することをお勧めします。

リンクされた属性を定義する
前方リンクの attributeSyntax の値が 2.5.5.1、2.5.5.7 または 2.5.5.14 であることは重要です。これらの値は、Object (DS-DN) 構文など、識別名を含む構文に対応しています。
後方リンクの attributeSyntax の値は、2.5.5.1 である必要があります。この値は Object (DS-DN) 構文に対応しています。原則として、後方リンク属性は、top 抽象型クラスの mayContain の値に追加されます。これにより、後方リンク属性をあらゆるクラスのオブジェクトから読み取ることができるようになります。この理由は、後方リンク属性は、実際にはオブジェクトと共に格納されているのではなく、前方リンクの値に基づいて計算されるからです。
Windows Server 2003 では、組織でスキーマ内の 2 つのオブジェクトをリンクさせるために使用できる、linkID の自動生成という機能が導入されました。この機能によって、新しくリンクされた属性の linkID 属性が 1.2.840.113556.1.2.50 に設定されたときに、その属性の linkID がシステムによって自動的に生成されるようになりました。対応する後方リンクを作成するには、linkID を前方リンクの attributeId または ldapDisplayName に設定します。前方リンクが作成された後、後方リンクが作成される前に、スキーマ キャッシュを再度読み込む必要があります。このタイミングでスキーマ キャッシュが読み込まれなかった場合、後方リンクの作成時に、前方リンクの attributeId または ldapDisplayName が見つからなくなります。スキーマ キャッシュは、スキーマが変更されてから数分後、またはドメイン コントローラの再起動時に、要求に応じて再度読み込まれます。
Active Directory のレベルが Windows 2000 の場合は、schemreg@microsoft.com (英語のみ) に電子メールを送信してマイクロソフトに linkID を要求する必要があります。自動的に返信されるメッセージには、schemreg@microsoft.com に送信された電子メールが処理されるのは、古い環境用の linkID の登録に関連している場合のみであることが記載されています。このため、電子メールには会社名、連絡先、電子メール アドレス、電話番号、登録したプレフィックス (該当する場合)、登録した OID (該当する場合) などの情報を記入するようにしてください。

スキーマを拡張する準備を行う
Active Directory スキーマを拡張することになったとします。分析の結果、ADLDS (または Windows Server 2003 の ADAM) を使用して実装された代替のディレクトリでは要件を満たすことができず、この方法の使用を断念した結果、スキーマの拡張が選択されたものと思われます。次に、スキーマに追加する新しい attributeSchema オブジェクトを決定し、これらの新しいオブジェクトを指定するために必要な値 (cn や ldapDisplayName など) をすべて定義しました。さらに、オブジェクトの属性値を定義するときに、マイクロソフトまたは別の機関から OID を取得しました。これらの情報は重要なので、ビジネス要件と技術仕様として文書化しました。そして、現在の Active Directory を再現したテスト用のラボ環境も実装しました。
実際に、多くの組織では、このような変更を承認し、変更の実装手順を決定するための委員会が設置されます。Active Directory は、信頼できる情報源として多くの組織で使用されるので、このような抑制と均衡を図ることは不可欠です。また、変更後も Active Directory を継続的に稼動させることが非常に重要です。
変更作業を進めていくことが決定したら、このプロジェクトのテストと実装の計画を定義する必要があります。スキーマを拡張するには、Microsoft 管理コンソール (MMC) 内で Active Directory スキーマ スナップインを使用して新しいオブジェクトを追加するか、スキーマを拡張するためのプログラム (またはそれに近い方法) を使用します。たとえば、LDIFDE による .ldif ファイルのインポート、CSVDE による .csv ファイルのインポート、Active Directory サービス インターフェイス (ADSI) スクリプトの使用などが考えられます。
どの方法を使用する場合でも、スキーマの拡張は、Active Directory フォレスト内に存在するスキーマ マスタのフレキシブル シングル マスタ操作 (FSMO) の役割が割り当てられているサーバー、またはそのサーバーに接続されているサーバーで行う必要があります。また、スキーマの更新に使用するアカウントには、更新を行うための管理者特権が与えられている必要があるので、そのアカウントを Schema Administrators グループに追加します。最後に、フォレストのスキーマを更新する操作を有効にする必要があります (既定では無効になっています)。
変更は、非常に簡単なものでない限り、自動化された方法で行う必要があります。これにより、テスト環境と実稼動環境を同じ方法で実装し、手動で手順を実行した場合に発生する可能性のある問題を回避できます。たとえば、LDIFDE を使用して変更を実装するとします。スキーマの拡張時に更新を適用するには、新しい属性とクラスを追加し、新しい属性をクラスに追加した後、キャッシュを再度読み込みます。では、いくつかのシナリオについて考えてみましょう。

属性を追加する
これは説明のみを目的としたシナリオですが、たとえば Contoso という名前の組織で、各従業員の靴のサイズを識別する属性を Active Directory に追加するとします。Active Directory フォレスト内には、contoso.com と employees.contoso.com という 2 つのドメインが存在します。ユーザー クラス定義を使用して作成されたすべてのオブジェクトに、この新しい属性が含まれるようにする必要があります。
2 つのドメインは同じフォレスト内に存在するので、スキーマの変更が両方のドメインに影響を与えることを考慮する必要があります。この例では、マイクロソフトから 1.2.840.113556.8000.9999 という OID を取得し、それをさらに枝分けして、Contoso の classSchema オブジェクトに 1.2.840.113556.8000.9999.1、attributeSchema オブジェクトに 1.2.840.113556.8000.9999.2 をそれぞれ使用します。次に、この新しいオブジェクトのすべての属性値を定義します (図 3 参照)。
Figure 3 contosoEmpShoe 属性の定義 (Close Figure 3)

属性 | 値 | 説明
Cn | contosoEmpShoe |
lDAPDisplayName | contosoEmpShoe |
adminDisplayName | contosoEmpShoe |
attributeSyntax | 2.5.5.12 | Unicode 文字列を指定します。
oMSyntax | 64 | Unicode 文字列を示します。
objectClass | top、attributeSchema |
attributeID | 1.2.840.113556.8000.9999.2.1 | 組織によって定義されます。
isSingleValued | TRUE | 靴のサイズを表す値を 1 つのみ格納できます。
searchFlags | 1 | 分析によって、この属性にインデックスを作成する必要があることがわかりました。このストレス テストによる分析は、ラボ環境で行われます。
isMemberOfPartialAttributeSet | TRUE | この属性をグローバル カタログで使用できるようにする必要があります。
また、contosoEmpShoe 属性は、ユーザー クラス オブジェクトとして作成されたすべてのオブジェクトに含まれる必要があるので、ユーザー クラスの既定の定義は変更しないことをお勧めします。その代わりに、contosoUser という名前の補助型クラスを定義し、mayContain の値に contosoEmpShoe を指定します (図 4 参照)。その後、contosoUser 補助型クラス用に定義された属性を、ユーザー クラスに追加します。
Figure 4 contosoUser クラスの定義 (Close Figure 4)

属性 | 値
Cn | contosoUser
lDAPDisplayName | contosoUser
adminDisplayName | contosoUser
governsID | 1.2.840.113556.8000.9999.1.1 (組織によって定義されます)
mayContain | contosoEmpShoe
possSuperiors | organizationalUnit, container
objectClassCategory | 3 (補助型クラスを表します)
分析を行い、値を定義したところで、次は .ldif ファイルを作成します。図 5 は、この .ldif ファイルのコードを示しています。図 5 の内容をメモ帳にコピーし、そのファイルを contosoUser.ldif として保存します (このコードは、technetmagazine.com のコード サンプルにも含まれています)。
Figure 5 .スキーマの拡張に使用する ldif ファイル (Close Figure 5)
#Attribute definition for contosoEmpShoe

dn: CN=contosoEmpShoe,CN=Schema,CN=Configuration,DC=X
changetype: ntdsschemaadd
objectClass: top
objectClass: attributeSchema
cn: contosoEmpShoe
attributeID: 1.2.840.113556.1.8000.9999.2.1
attributeSyntax: 2.5.5.12
isSingleValued: TRUE
adminDisplayName: contosoEmpShoe
adminDescription: contosoEmpShoe
oMSyntax: 64
searchFlags: 1
lDAPDisplayName: contosoEmpShoe
systemOnly: FALSE

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
-

# Classes

dn: CN=contosoUser,CN=Schema,CN=Configuration,DC=X
changetype: ntdsschemaadd
objectClass: top
objectClass: classSchema
cn: contosoUser
governsID: 1.2.840.113556.1.8000.9999.1.1
mayContain: contosoEmpShoe
rDNAttID: cn
adminDisplayName: contosoUser
adminDescription: contosoUser
objectClassCategory: 3
lDAPDisplayName: contosoUser
name: contosoUser
systemOnly: FALSE

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
-

dn: CN=User,CN=Schema,CN=Configuration,DC=X
changetype: ntdsschemamodify
add: auxiliaryClass
auxiliaryClass: contosoUser
-

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
.ldif ファイルを生成したら、ラボ環境で実装を徹底的にテストし、ドメインとフォレストのエンド ツー エンドのレプリケーションを検証した後、フォレスト内のスキーマの更新を有効にします。その後、スキーマ管理者の特権が与えられたアカウントを使用してログインします。スキーマ マスタ (変更を実行するサーバー) で出力方向のレプリケーションを無効にしてから、次のコマンドを実行して .ldif ファイルをインポートします。
ldifde –i –f <Path>\contosoUser.ldif –b
<username> <domain> <password> -k –j. –c
"CN=schema,CN=Configuration,DC=X"
#schemaNamingContext
変更を実装したら、スキーマ マスタで出力方向のレプリケーションを有効にし、すべてのドメイン コントローラへのレプリケーションが発生したかどうかを確認します。
深呼吸してください。これで作業は完了です。ユーザー クラス (つまりユーザー アカウント) を使用して作成されたオブジェクトに関連付けられる新しい属性をスキーマに定義できました。
変更が加えられたことを確認するには、Active Directory ユーザーとコンピュータを起動して employees.contoso.com ドメインに接続し、Users 組織単位 (OU) を参照して、ContosoTestUser という名前の新しいユーザー アカウントを作成します。次に、adsiedit.msc コンソールを開き、ドメイン パーティション dc=employees,dc=contoso,dc=com に接続して Users OU を展開し、[ContosoTestUser] を右クリックしてプロパティ ページを開きます。このページで、contosoEmpShoe 属性を探してみてください。値を入力してこの属性を編集できます。また、Ldp.exe ユーティリティを使用して、これらの属性を確認および変更することもできます。
次に、2 つの属性を定義し、リンクさせる例を見てみましょう。Contoso で従業員の靴のサイズが重要視され、社内で靴のサイズを測定する人物の年間の実績を追跡する必要があるとします。なんだか妙な感じがしますね。さらに、Contoso では、1 つの属性を照会するだけで、従業員の靴のサイズを測定した人物の名前だけでなく、その人物がサイズを測定した従業員の名前と人数を把握できるようにする必要があります (このデータはデータベース テーブルに格納した方が適切であると思われたかもしれませんが、ここでの目的は単に前方リンクと後方リンクの機能を説明することです)。
当然、まずは前述の例のように、分析を行います。ただし、ここでは説明を省略して先に進み、linkids1.ldif と linkids2.ldif という .ldif ファイルを生成します (図 6 参照)。その後、次のコマンドを実行して .ldif ファイルをインポートします。
Figure 6 前方リンクと後方リンクの .ldif ファイル (Close Figure 6)

#linkids1.ldif
#Attribute definition for Forward Link Attribute

dn: CN=ContosoShoeSizeTaker,CN=Schema,CN=Configuration,DC=X
changetype: ntdsschemaadd
objectClass: top
objectClass: attributeSchema
cn: ContosoShoeSizeTaker
attributeID: 1.2.840.113556.1.8000.9999.2.2
LinkID: 1.2.840.113556.1.2.50
attributeSyntax: 2.5.5.1
isSingleValued: TRUE
adminDisplayName: ContosoShoeSizeTaker
adminDescription: ContosoShoeSizeTaker
oMSyntax: 64
searchFlags: 1
lDAPDisplayName: ContosoShoeSizeTaker
systemOnly: FALSE

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
-

#Reload schema

#linkids2.ldif

#Attribute definition for Backward Link Attribute

dn: CN=ContosoShoeSizesTakenByMe,CN=Schema,CN=Configuration,DC=X
changetype: ntdsschemaadd
objectClass: top
objectClass: attributeSchema
cn: ContosoShoeSizesTakenByMe
attributeID: 1.2.840.113556.1.8000.9999.2.3
LinkID: 1.2.840.113556.8000.9999.2.2
attributeSyntax: 2.5.5.1
isSingleValued: FALSE
adminDisplayName: ContosoShoeSizesTakenByMe
adminDescription: ContosoShoeSizesTakenByMe
oMSyntax: 64
searchFlags: 1
lDAPDisplayName: ContosoShoeSizesTakenByMe
systemOnly: FALSE

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
-

#Add ContosoShoeSizeTaker and ContosoShoeSizesTakenByMe Attribute as MayContain in
#contosoUser class

dn: CN= contosoUser,CN=Schema,CN=Configuration,DC=X
changetype: ntdsschemamodify
add: mayContain
mayContain: ContosoShoeSizeTaker
mayContain: ContosoShoeSizesTakenByMe

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
-

#Add Backward Link Attribute as MayContain in Top

dn: CN=Top,CN=Schema,CN=Configuration,DC=X
changetype: ntdsschemamodify
add: mayContain
mayContain: ContosoShoeSizesTakenByMe

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1

ldifde –i –f <Path>\linkedids<>.ldif –b
<username> <domain> <password> -k –j. –c
"CN=schema,CN=Configuration,DC=X"
#schemaNamingContext
これで、ユーザー オブジェクトが作成されたときに、その属性として ContosoShoeSizeTaker と ContosoShoeSizesTakenByMe が含まれるようになります。たとえば、John というユーザー オブジェクトを作成すると、靴のサイズを測った Frank という人物の DN が ContosoShoeSizeTaker 属性に格納されます。次に、Frank のユーザー オブジェクトのプロパティにアクセスし、ContosoShoeSizesTakenByMe 属性を照会すると、John の DN と、Frank が靴のサイズを測定した他のすべての従業員の DN を確認できます。これで、たとえば経営管理者は、Frank のユーザー アカウントの ContosoShoeSizesTakenByMe 属性に格納されている DN の数に基づいて、Frank に報酬を与えることができます。

システムの抑制と均衡
スキーマの変更などの重要な更新を行う場合は、必ずその変更がアーキテクチャの要件を満たしているかどうかを確認する必要があります。Active Directory では、このような整合性と安全性の確認が実行され、Active Directory スキーマに対する追加や変更が発生するたびに、それらの変更が原因で不整合などの問題が発生しないかどうかが検証されます。
まず、各クラスの governsID の値は、スキーマ内で一意である必要があります。また、schemaClass オブジェクトを定義する場合、systemMayContain、mayContain、systemMustContain、および mustContain のリストで定義されているすべての属性が既に存在している必要があります。同時に、subClassOf、systemAuxiliaryClass、auxiliaryClass、systemPossSuperiors、および possSuperiors のリストで定義されているすべてのクラスも既に存在している必要があります。
さらに、systemAuxiliaryClass と auxiliaryClass のリストに含まれているすべてのクラスの objectClassCategory に、88 クラスまたは補助型クラスを示す値が指定されている必要があります。同様に、systemPossSuperiors と possSuperiors のリストに含まれているすべてのクラスの objectClassCategory には、88 クラスまたは構造型クラスを示す値が指定されている必要があります。
さまざまなクラスが定義されていますが、抽象型クラスは他の抽象型クラスのみを継承できます。また、補助型クラスは構造型クラスを継承できず、構造型クラスは補助型クラスを継承できません。さらに、rDNAttID 属性に指定される属性には、Unicode 文字列から成る 1 つの値が指定されている必要があります。
以上が classSchema オブジェクトに関連するいくつかの規則です。では、attributeSchema オブジェクトについてはどうでしょうか。クラスの governsID の値と同様、attributeID の値は一意である必要があります。また、mAPIID (存在する場合) の値も一意である必要があります。さらに、rangeLower と rangeUpper が存在する場合、rangeLower には rangeUpper よりも小さい値が指定されている必要があります。attributeSyntax の値と oMSyntax の値は一致している必要があります。属性にオブジェクト構文が使用される場合 (oMSyntax = 127) は、この属性に適切な oMObjectClass が指定されている必要があります。linkID (存在する場合) は一意である必要があります。また、後方リンクに対応する前方リンクが存在する必要があります。

失敗したときの対策
新しいオブジェクト (クラスと属性) を使用してスキーマを拡張した後、それらのオブジェクトを削除することはできません。ただし、スキーマ オブジェクトの属性 isDefunct を TRUE に設定することによって、クラスまたは属性を非アクティブにすることができます。Active Directory に付属している既定のスキーマの一部であるスキーマ オブジェクト (カテゴリ 1 のオブジェクト) を非アクティブにすることはできません。非アクティブにすることができるのは、既定のスキーマに追加されたオブジェクトのみです。つまり、カテゴリ 2 のオブジェクトのみを無効にすることができます。また、既存のアクティブなクラスの subClassOf、auxiliaryClass、または possSuperiors のリストで使用されていないことが Active Directory によって確認されているクラスのみを無効にすることができます。
属性の非アクティブ化を試行すると、Active Directory によって、その属性が既存のアクティブなクラスの mustContain または mayContain で使用されていないかどうかが確認されます。無効になったオブジェクトは、属性 isDefunct を FALSE に設定することで再度有効にすることができます。Active Directory が Windows Server 2003 レベルの場合は、無効になったオブジェクトの ldapDisplayName、schemaIdGuid、OID、および mapiID の値を再利用できます。

まとめ
スキーマ内のクラスまたは属性の定義を追加または変更する場合、対応する classSchema オブジェクトまたは attributeSchema オブジェクトも追加または変更する必要があります。このプロセスは、Active Directory のオブジェクトを追加または変更する場合と同様です。ただし異なる点が 1 つあり、実装した変更が原因で、後から不整合などの問題がスキーマで発生しないように、追加で確認処理が実行されます。
Active Directory スキーマの変更作業は単純ですが、変更を実装する場合は、スキーマの構造と機能を理解することが重要です。運用環境の Active Directory スキーマを変更する場合は、綿密な計画を立て、慎重に実装する必要があります。また、新しいオブジェクト用のビジネス要件と技術仕様を定義し、ラボで徹底的にテストすることが重要です。変更によって大きな影響がもたらされる可能性があるので、絶対に必要な場合のみ Active Directory スキーマを拡張することをお勧めします。

Vikas Malhotra は、Microsoft Consulting Services (ニューヨーク) に勤務しています。12 年間にわたる在籍期間の中で、多くの大規模および中規模企業内の IT 組織と関わり、それらの企業のインフラストラクチャで使用されるアーキテクチャの要件 (ディレクトリ、メッセージング、セキュリティ、データ ネットワークなど) に対処する業務に従事してきました。彼は、電子工学と電気通信の工学士号、および電気通信 (技術) 管理の理学修士号を取得しています。連絡先は、vikasmal@microsoft.com (英語のみ) です。


 System Center: System Center Mobile Device Manager の概要
System Center Matt Fontaine

System Center Mobile Device Manager の概要
概要:
  • Mobile Device Manager の典型的なシステム
  • Active Directory を Windows Mobile に拡張する
  • Windows Mobile デバイスの登録、プロビジョニング、およびインベントリ

Microsoft System Center Mobile Device Manager 2008 のリリースは、社内ネットワークで使用している Windows Mobile デバイスを管理する IT プロフェッショナルにとって魅力的な製品です。1 つの製品でデバイス管理、セキュリティ管理、モバイル仮想プライベート ネットワーク (VPN)
の機能が提供されるので、この新製品は、モバイル デバイスの利用に関する管理作業の負担を軽減し、投資収益率 (ROI) の向上を促進するのに役立ちます。
Mobile Device Manager を使用すると、IT プロフェッショナルは、デバイス設定を適用する際に、既存の Active Directory® とグループ ポリシーのインフラストラクチャを使用できます。また、Over-The-Air (OTA) デバイス管理機能を使用すると、更新プログラムやアプリケーションをデバイスに簡単に配布できるだけでなく、OTA セルフ プロビジョニングにより、より簡単に展開することが可能になり、展開のスケーラビリティが向上します。モバイル VPN を使用すると、エンド ユーザーはファイアウォールの内側にあるデータやアプリケーションにアクセスできるようになり、管理者には、展開されたデバイスを制御できるように常時接続が提供されます。Mobile Device Manager は、このような機能が拡張およびカスタマイズ可能な 1 つの製品に備わっている現在の IT プロフェッショナルに必須のツールです。

管理の必要性
モバイル ユーザーは、今後も急増することが予想されます。従来、モバイル デバイスは、その可動性により、他のネットワーク機器よりも管理が困難でした。モバイル デバイスは、さまざまな方法でネットワークに接続するため、他のデバイスほどセキュリティがしっかりしていないものがあります。たとえば、ファイアウォールの外側で使用されたり、クライアント コンピュータとは異なるオペレーティング システムを使用したり、小さいので簡単に置き忘れたり紛失したりする場合があります。
現在のモバイル デバイスでの拡張された機能には、企業とエンド ユーザーの両者にとって魅力的なメリットがありますが、こうしたデバイスのサポートはより複雑になります。特に、このようなモバイル デバイスを使用して重要な基幹業務 (LOB) アプリケーションや顧客データにアクセスしている場合は、企業のデータとネットワークがセキュリティ上の危険にさらされる可能性が高くなります。このようなモバイル デバイスが紛失や盗難に遭ったり、不適切に使用された場合には、セキュリティ上の緊急事態を引き起こすことがあります。
モバイル デバイスと従来のネットワーク クライアントとの機能の格差が縮まったため、モバイル デバイスをラップトップ コンピュータやデスクトップ コンピュータと同じように管理するニーズが高まっています。Mobile Device Manager は、このニーズに対応するために開発された製品です。Windows Mobile® プラットフォームはビジネス ユーザーの間で普及が進んでいるため、Mobile Device Manager は、Windows® ベースの IT 管理システムにおいて不可欠な要素になります。
Mobile Device Manager は、ネットワークに接続された PC やラップトップ PC と同様に、Windows Mobile デバイスをエンド ツー エンドで簡単に管理できるようにデザインされています。Mobile Device Manager の主要機能は次の 3 つです。
デバイス管理 Windows Mobile デバイスのプロビジョニング、監視、および管理を行うための集中管理された機能で、1 台のサーバーにつき数万人のユーザーまで対応できます。
セキュリティ管理 機密データの保護とデバイスの追跡のためのメカニズムを強化します。
モバイル VPN 常時接続機能を使用して、ファイアウォールの内側にあるデータやアプリケーションへのアクセスを強化します。
Mobile Device Manage は、デスクトップ コンピュータやラップトップ コンピュータと同様、企業資産を最重要資産として管理するためのツールを IT プロフェッショナルに提供するという System Center 全体の方針に準拠しています。また、Mobile Device Manager では、他の System Center 製品を既に使用している IT プロフェッショナルが使い慣れているユーザー インターフェイスが採用されています。
つまり、Mobile Device Manager は、既存の Windows ベースのインフラストラクチャと適切に連携するように設計されています。たとえば、Mobile Device Manager は、Active Directory とグループ ポリシーを使用したり、マイクロソフトが提供している既存の分析ツールやレポート作成ツール (SQL Server® など) と連携したり、Microsoft® 管理コンソール スナップインや Windows PowerShellTM コマンドレットを使用して拡張できます。

Mobile Device Manager のシステム
Mobile Device Manager は、拡張性が高いため、1 つのインスタンスで複数の構成オプションに加え、何万台ものデバイスをサポートできます。一般的に、Mobile Device Manager のサーバー側コンポーネントとしては、ゲートウェイ サーバー、デバイス管理サーバー、登録サーバー、SQL Server データベースという 4 つの主なシステム コンポーネントがあります (図 1 参照)。
Figure 1 Typical Mobile Device Manager system
Figure 1 Typical Mobile Device Manager system
通常、ゲートウェイ サーバーは、境界ネットワーク内に設置されます。デバイスのネットワーク接続端末として機能し、着信したデバイス接続を認証して、デバイスに静的 IP アドレスを提供します。また、デバイスやネットワーク接続に関連するその他の機能も実行します。
デバイス管理サーバーは、グループ ポリシーの実装、OTA ソフトウェアの配布、デバイス ワイプなど、デバイス管理の中核となり、既存のドメイン コントローラと連携します。また、Windows Mobile デバイスの代理ネットワーク クライアントとして機能するので、Windows Mobile デバイスは他のシステムと通信できるようになります。
登録サーバーは、ドメイン コントローラにモバイル デバイスを表す Active Directory ドメイン サービスのオブジェクトを作成し、モバイル デバイスを他のドメイン メンバと同様に管理できるようにします。また、モバイル デバイスに対する証明書の要求と取得に対応します。登録サーバーでは、登録証明書を受付または発行する前に、デバイスを認証する際の基盤として Active Directory を使用します。SQL Server データベースは、デバイスの構成、タスク、状態設定などに関連するすべての情報のリポジトリを提供します。
インフラストラクチャの準備が整うと、Mobile Device Manager は、モバイル デバイスと 3 種類の対話処理 (デバイスの登録、モバイル VPN 接続の確立、およびデバイス管理) を行います。デバイスの登録は、デバイスが Active Directory ドメインに参加する際に発生する処理です。Mobile Device Manager では、"共有シークレット" (期限付きワンタイム パスワード) を使用することで、セキュリティで保護されていない接続経由でデバイスを登録できます。デバイスは登録されると、ゲートウェイ サーバーへのモバイル VPN 接続を確立できます。デバイスからのネットワーク トラフィックは、このサーバーを経由してルーティングされます。モバイル VPN 接続を使用すると、管理者やシステムは、デバイス管理を実行し、ソフトウェアや設定をデバイスに展開できるようになります。

Active Directory を Windows Mobile に拡張する
複数の IT セキュリティ手法を組み合わせたり、その場限りの IT セキュリティ手法を使用すると、セキュリティ モデルに完全に統合された手法を使用するより、リスクが高くなります。Mobile Device Manager は、Windows PC などのモバイル デバイスを既存の Active Directory ドメイン サービス インフラストラクチャを使用して管理する方法を提供することで、こうしたリスクを軽減できるようにデザインされています。その結果、ID とアクセスの管理が合理化され、適用するポリシーの一貫性が高まり、1 つの場所でセキュリティを構成することができます。
PC やサーバーと同様に、Windows Mobile デバイスに関連するグループ ポリシー オブジェクトは、組織単位 (OU)、セキュリティ グループ、および Windows Management Instrumentation (WMI) フィルタに割り当てることができます。また、特定のデバイスにグループ ポリシーの設定が適用されないようにすることもできます。
130 を超える Windows Mobile デバイス対応の設定やポリシーがあり、さまざまな機能をきめ細かく制御することができます。次に例を示します。
  • パスワードの設定では、パスワード要件、種類と最小文字数、パスワードの有効期限、および指定された回数失敗した後のローカル デバイス ワイプの実行 (残りの回数に関するユーザーへの通知を含む) などを指定できます。
  • プラットフォームのロックダウン設定を使用すると、カメラ、ワイヤレス LAN、Bluetooth、リムーバブル記憶域など、デバイスの特定の機能を有効または無効にすることができます。Post Office Protocol (POP)、インターネット メッセージ アクセス プロトコル (IMAP)、ショート メッセージ サービス (SMS)、およびマルチメディア メッセージング サービス (MMS) のメール機能はすべて無効にすることができます。また、Windows Mobile 用 Windows Update も無効にすることができます。
  • Mobile Device Manager では、アプリケーションをきめ細かく制御できます。Mobile Device Manager は、デバイスで未署名のアプリケーションや承認されていない署名の付いたアプリケーションを実行できないようにしたり、管理者の裁量で特定の未署名のアプリケーションの実行を許可したりすることができます。
  • データを保護するために、リムーバブル メモリ カード上に作成されたファイルを (デバイスに関連付けられた暗号化キーを使用して) 強制的に暗号化することができます。デバイスの暗号化は、デバイスに格納されている機密データの保護にも使用できます。また、既定で保護されているファイルに加えて、暗号化するファイルを追加で指定できます。
  • モバイル VPN 設定では、ユーザーがデバイスの VPN 接続をどの程度制御できるかを指定したり、データの暗号化レベルを設定したりすることができます。
  • ActiveSync® の設定では、メッセージの形式、電子メールの期間フィルタ、サイズ制限、同期設定などを設定できます。
  • S/MIME 設定では、メッセージの署名、メッセージの暗号化、または特定のアルゴリズムの使用を要件として設定できます。
上記の設定をはじめとした、Windows Mobile 対応の設定では、さまざまなシナリオがサポートされています。このような設定により、IT プロフェッショナルは、デバイスごとに実行できるアプリケーションを指定することができます。ハードウェア機能は、OTA で有効または無効にすることができます。たとえば、カメラを無効にして、機密情報が事故または故意で危険にさらされるのを防ぐことができます。データの暗号化は、デバイスまたはリムーバブル メモリ カード、あるいはその両方に適用して、紛失または盗難に遭ったデバイスやカードから、所有するデータが許可されていない人の手に渡る可能性を軽減することができます。
Mobile Device Manager には、他のセキュリティ管理ツールも用意されています。Windows Mobile デバイスで使用できるアプリケーションは多数あるので、管理者がインストールできるアプリケーションとインストールできないアプリケーションを制御する必要があるのは明らかです。Mobile Device Manager を使用すると、それだけの目的で、アプリケーションの許可リストや禁止リストを作成して適用できます。また、Mobile Device Manager には、強力なリモート ワイプ機能も用意されています。デバイスへの VPN 接続は常時確立されているので、デバイスがネットワークに接続して同期されるのを待機することなく、すぐにデバイスをワイプできます。デバイスはリモートでワイプされると、ドメイン コントローラから削除され、そのデバイスの証明書は失効します。このようなデバイスを後日復旧する場合は、新しいワンタイム パスワードを使用して再登録すると、ドメインに再度参加するようにデバイスを設定できます。

モバイル デバイスを抑制する
Mobile Device Manager は、OTA プロビジョニング、OTA ソフトウェアと更新プログラムの配布、インベントリの包括的な一元管理など、1 つのソリューションで完全なデバイス管理機能を提供することで、ネットワーク上の Windows Mobile デバイスをできる限り簡単に管理できるようにデザインされています。
OTA の自動登録は、忙しい IT プロフェッショナルやエンド ユーザーに重宝される可能性が高い機能です。ユーザーが Windows Mobile 6.1 デバイスで電子メール アドレスを入力すると、デバイスにより、指定された電子メール アドレスに基づいてモバイル デバイスの管理サーバーが検出されます。サーバーが見つからない場合、ユーザーは、管理サーバーのアドレスを手動で入力するよう求められます。サーバーが検出され、登録できることが確認されると、ユーザーは、管理者が事前に生成したワンタイム パスワードを入力するよう求められます。
電子メール アドレスとパスコードは、ユーザーの認証と、管理サーバーへのデバイスの登録に使用されます。この処理が完了すると、管理者が定義した設定やポリシーがデバイスに適用されます。自動登録という手法は、Windows Mobile デバイスの展開のスケーラビリティを向上し、こうしたデバイスを稼動させるのに必要な時間とコストを削減するようにデザインされています。
Mobile Device Manager の OTA ソフトウェア配布機能は、世界中の多くの IT プロフェッショナルが既に使用しているソフトウェア更新ツールキットである Windows Software Update Services (WSUS) 3.0 に基づいています。WSUS 3.0 では、複雑な IT ニーズに必要なターゲット機能やアプリケーションのパッケージ化機能を提供しています (図 2 参照)。ソフトウェアは、管理者が設定したルールやポリシーに基づいて、適切なデバイスに自動的に配布できます。サーバーやクライアントの更新プログラムと同様に、WSUS 3.0 を使用すると、モバイル デバイスの更新プログラムや修正プログラムの配布を自動化できます。展開の計画およびテスト時に自動更新を無効にできることも重要な点です。
Figure 2 Software distribution wizard
Figure 2 Software distribution wizard
ある程度の規模で展開されているモバイル デバイスの管理における最も大きな課題の 1 つは、すべてを追跡することです。Mobile Device Manager は、インベントリ情報を一元管理し、SQL Server 2005 に基づいてカスタマイズ可能で柔軟性のあるレポートを提供しています。このような場面でも、多くのユーザーが既にインストールしていて使い慣れているソフトウェアを使用します。管理者は、100 を超えるアイテムのインベントリ情報を収集できます。これには、オペレーティング システムとバージョン、デバイス モデル、インストール済みのアプリケーション、セキュリティ ポリシーなどが含まれますが、これらに限定されるわけではありません。インベントリは拡張可能なので、管理者はアイテムやレジストリの設定を追加できます。
グラフィカル ユーザー インターフェイスをお好みの場合は Microsoft 管理コンソール スナップイン (図 3 参照)、コマンド ラインをお好みの場合は Windows PowerShell コンソールを使用すると、さらに柔軟に Mobile Device Manager を制御できます。どちらの方法を使用しても、システムは拡張およびカスタマイズ可能です。これは、ソフトウェアを組織に合わせて調整する必要がある企業ユーザーに必要な特性です。
Figure 3 Mobile Device Manager Console
Figure 3 Mobile Device Manager Console

モバイル VPN
インフォメーション ワーカーは、何年もの間、モバイル デバイスを使用して電子メールやメッセージを送受信しています。現在、モバイル デバイス テクノロジにおける最も便利な進化の 1 つは、ファイアウォールの内側にあるビジネス データやアプリケーションにアクセスする機能が提供されるようになったことです。アクセス数の増加に伴い、新しいセキュリティ リスクが発生するため、追加機能は慎重に管理して、脆弱性を防ぐ必要があります。Mobile Device Manager は最先端のモバイル VPN 機能を提供するため、ユーザーは、Microsoft DynamicsTM Customer Relationship Management (CRM) から SAP や Siebel に至るまで、さまざまなイントラネット データにアクセスできるようになります。このモデルは、デスクトップ コンピュータやラップトップ コンピュータに対する既存のリモート アクセス戦略に対応するように構築されています (図 4 参照)。
Figure 4 Mobile VPN settings
Figure 4 Mobile VPN settings
モバイル VPN では、ダブル エンベロープ セキュリティ機能を使用してデバイスをゲートウェイ サーバーに接続し、データは、IPsec で暗号化されたトンネルを経由して SSL 暗号化形式で転送されます。デバイスが認証されると、ユーザーは、リソース固有のポリシーの条件とユーザーの資格情報に基づいてリソースにアクセスできます。
Mobile Device Manager で使用されているモバイル VPN テクノロジにより、常時接続を確立できます。これにより、ユーザーのアクセスが向上するだけでなく、IT プロフェッショナルが最新のポリシーや設定を使用してデバイスを常に最新の状態にし、デバイスの紛失または盗難時にはすぐにそのデバイスをワイプできるようになります。セッションが中断された場合でも、高速な再接続機能により、デバイス セッションは再認証の必要なく処理を続行できます。Mobile Device Manager を使用すると、接続を維持しながら、Wi-Fi ネットワークと移動体通信ネットワーク間の移行をスムーズに行えます。
Mobile Device Manager のモバイル VPN で使用されているセキュリティ テクノロジは、Open Mobile Alliance for Device Management (OMA DM)、インターネット キー交換 (IKE) Version 2、OMA Software Component Management Object (SCOMO) などの業界標準に基づいています。そのため、複雑な環境で作業している IT プロフェッショナルが直面した特定の状況に応じて、システムをさらに拡張およびカスタマイズすることができます。

まとめ
Mobile Device Manager には、1 つのインターフェイスからアクセスできる、Windows Mobile デバイスを管理するためのツール一式が用意されています。Mobile Device Manager は、データ、デバイス、およびネットワークを保護するセキュリティ ツールを提供するために Active Directory とグループ ポリシーを利用しています。デバイス管理は、OTA の登録、プロビジョニング、および更新に加え、強力なインベントリ ツールにより簡略化されます。また、モバイル VPN は、セキュリティを損なうことなく、企業やユーザーが必要とする機能を提供するようにデザインされています。
これはすべて、ネットワーク上のモバイル デバイスを重要なリソースとして管理できるようにして IT プロフェッショナルの仕事を簡略化するという目的には必要不可欠です。Mobile Device Manager を使用することで、IT プロフェッショナルは、エンド ユーザーの優れた操作性の提供、管理オーバーヘッドの削減、管理作業の ROI の向上を実現できます。これは、特筆に価する同製品の導入により得られるメリットです。
この記事の執筆に協力してくれた Brian Hoskins、Derek Snyder、Prithvi Raj、Lax Madapaty、および Katharine Holdsworth に感謝します。

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


 System Center: System Center Essentials SP1 の新機能
System Center Pete Zerger

System Center Essentials SP1 の新機能
概要:
  • 統合インストーラ パッケージによるインストールの簡略化
  • 詳細な設定が可能な管理パックの上書きの強化
  • ワークグループのサポート
  • 新しい正常性の状態の再計算タスク

2007 年 7 月の System Center Essentials 2007 のリリースにより、マイクロソフトは中規模企業に対する公約を果たし、高価で複雑なエンタープライズ ツールとシェアウェア ソリューションの溝を埋めて、
IT 運用の統一された管理ソリューションを提供できるようにしました。Essentials 2007 は、さまざまな作業を実行しなければならない中小企業の IT プロフェッショナルが抱える課題に対応することを目的としています。
Essentials は簡単にインストールおよび構成できるので、クライアントとサーバーの能動的な監視と管理だけでなく、ハードウェアとソフトウェアの資産管理を行うことができます。アプリケーションや IT サービスの監視、クライアント ソフトウェアとサーバー ソフトウェアの展開、デスクトップ コンピュータに関する問題のトラブルシューティングなど、従来複雑な作業の簡略化を目的にしています。
初期リリース以来、マイクロソフトは現場で既に Essentials を使用して IT インフラストラクチャを管理しているユーザーからのフィードバックを収集し、この情報を同製品の SP1 に取り入れました。SP1 では、単に修正プログラムを提供するだけでなく、さまざまな展開シナリオにおけるユーザーのニーズに柔軟に対応できる大幅な機能強化が施されています。また、パフォーマンス強化によって、格段にユーザー エクスペリエンスが向上し、管理作業が簡略化されています。
この記事では、Essentials 2007 SP1 が提供する重要な機能強化について説明します。また、環境の管理の簡略化に、これらの機能強化がどのように役立つかについても説明します。

インストールの簡略化
SP1 の統合インストーラ パッケージでは、これまでにリリースされた Essentials のすべての修正プログラムがまとめられているので、数回のクリック操作で簡単にインストールできるようにしています。また、Essentials サーバーが 32 ビットの Windows Server® 2003 インスタンス上で実行されていても、リモートの 64 ビット SQL Server® 2005 インスタンスを使用するように Essentials を構成できるようになりました。これにより、分散 Essentials 展開トポロジの環境において、既存のサーバー インフラストラクチャを非常に柔軟に利用できます。また、Windows Server 2008 が、Essentials 2007 SP1 サーバー、コンソール、およびエージェントのプラットフォームとしてサポートされます。Windows Server 2008 は、同 OS が製造工程に向けてリリースされたすぐ後に完全にサポートされる予定です。

コンソールのパフォーマンス向上
Essentials 2007 の RTM リリースと比べて、SP1 では Essentials コンソール インターフェイスの応答が劇的に向上しています。また、アラート、イベント、パフォーマンス、状態、タスクの状態の各ビューのパフォーマンスも向上しています。たとえば、すべてのアラート ビューでは、データ フェッチ (取得) が変更されると、これまでより 3 倍早くアラート データが選択されます。アクションとレポートはバックグラウンドでフェッチされるようになったので、UI のパフォーマンスがさらに向上しています。同様に、(オペレーション コンソールの右側にある操作ウィンドウに表示される) コンテキストベースのタスクとレポートもバックグラウンドで読み込まれるため、よりすばやく選択項目に応じてビューの状態が更新されるようになっています。
[アラートの詳細] ウィンドウに表示されるアラートのナレッジは、[Show Knowledge] (ナレッジの表示) または [Hide Knowledge] (ナレッジの非表示) リンクをクリックするだけで、ユーザーの好みに合わせて表示または非表示に設定できるようになりました (図 1 参照)。このユーザー設定は、将来アラートを参照する場合も有効です。また、標準のキーボード ショートカット (Ctrl + C や Ctrl + V など) を使用して、アラートの詳細をコピーして貼り付けられるようにもなりました。
Figure 1 Alert Details pane with Show/Hide Knowledge links
Figure 1 Alert Details pane with Show/Hide Knowledge links

上書きの強化
上書きは管理パックの調整に使用され、不要なルールとモニタを無効にするなど、さまざまなしきい値を微調整します。環境に合わせたルールとモニタの調整を簡略化するだけでなく、Essentials 環境内の既存の上書きの確認機能を向上する上書き関連の重要な機能強化がいくつか施されています。その結果、カスタム ルールを作成しなければならない場合が少なくなり、環境内の既存の上書きを特定するのにかかる時間が短縮されます。
たとえば、管理パック オブジェクトの上書きを作成すると、[上書きの概要] ボックスでそのオブジェクトに対する上書きの概要を確認できるようになりました。Essentials 2007 SP1 では、上書きターゲットの説明が確実に指定されるようにします。たとえば、Server 1 の C:\ ドライブに対する論理ディスク空き領域用の上書きを作成すると、概要に server1/c: と表示されます。例を見ると、この変更の重要性がわかりやすいかもしれません。
図 2 は、Essentials 2007 の RTM リリースで表示される Windows Server 2003 の論理ディスク空き領域の [上書きの概要] ダイアログ ボックスです。この画面からは、上書きターゲットである C:\ ドライブ インスタンスがどのコンピュータにあるかを確認できません。Essentials SP1 では、この [上書きの概要] ダイアログ ボックスの [名前] 列に、ターゲットのドライブ インスタンスだけでなく、そのドライブをホストしているコンピュータの情報も表示されます (図 3 参照)。
Figure 2 Overrides Summary in Essentials 2007 RTM
Figure 2 Overrides Summary in Essentials 2007 RTM
Figure 3 The same Overrides Summary in Essentials 2007 SP1
Figure 3 The same Overrides Summary in Essentials 2007 SP1
アラートの重要度は、管理者が収集するアラートのトラフィック量に大きく影響します。これまでは、ルールの上書きでアラートの重要度と優先度は公開されていなかったため、シールされた管理パックの Essentials ルールが、一部のサーバーでは重大ではないことについて、重大なアラートを生成するように構成されていた場合、この設定を調整することはできませんでした。この唯一の次善策は、一部のコンピュータで当該ルールを無効にする上書きを作成し、次にアラートに関するパラメータを操作できるシールされていない管理パックでルールを作成し直すという非常に手間のかかる作業を行うことでした。これは、管理者にとっては明らかに理想的な状況ではありません。
この問題は SP1 では適切に処理され、すべてのシールされた管理パックのルールで、アラートの重要度と優先度が上書きのパラメータとして公開されます (図 4 参照)。そのため、上書きを作成することで Essentials 2007 のルールにより生成されるアラートの重要度と優先度をすばやく簡単に調整できます。
Figure 4 Alert severity and priority rule overrides
Figure 4 Alert severity and priority rule overrides
また、図 4 を見て、Essentials の RTM リリースのコンソール インターフェイスにはなかった [Enforced] (適用) チェック ボックスにお気付きになったかもしれません。あるオブジェクトに対して複数の上書きが有効になっている場合、[Enforced] (適用) のチェック ボックスがオンになっている上書きが優先されます。これは、同じ上書きが 2 つのオブジェクト グループに設定されていて、一部のオブジェクトがこの両方のグループのメンバである場合に便利なオプションです。優先させる上書きに [Enforced] (適用) オプションを設定することで、適用される上書き設定を正確に制御できます。
新しい管理パックをより簡単に作成できるように、Essentials 2007 SP1 では、既存の管理パックのビューをシールされていない管理パックにコピーする機能が導入されています。このコピー操作は、すべてのビュー (イベント、アラート、パフォーマンス、ダッシュボード、ダイアグラムなど) で利用でき、監視領域から実行できます。たとえば、Active Directory® の上書き用の管理パックを作成し、この Active Directory の上書き管理パックの Active Directory 管理パック ビューの 1 つを使用する場合は、目的のビューを選択し、このビューをコピーして監視領域のナビゲーション ペインで目的のカスタム管理パック フォルダに貼り付けることができます。

新しい上書きのレポート機能
また、Essentials コンソールのレポート ペインにある Microsoft® Generic Reporting Library に、新たに追加された上書きのレポートも特筆に価する機能です。このレポートを使用すると、上書きが格納されている管理パックまたは上書きが適用される管理パックを基準に上書きの説明を提供できます (図 5 参照)。ユーザーはレポート パラメータを設定して、レポートにシールされた管理パックの上書きの情報が含まれないようにすることができます。マイクロソフトや他社が提供するシールされた管理パックには、実際の環境で発生した変更をレポートするときに不要な上書きの情報が多数含まれているので、これは重要なフィルタ オプションと言えます。
Figure 5 Overrides Report parameters
Figure 5 Overrides Report parameters
シールされた管理パックごとに個別のカスタム管理パックを作成するというマイクロソフトのベスト プラクティスに従うと (Active Directory 管理パック用に 1 つ、Exchange 管理パック用に 1 つなど)、レポートの範囲をより効果的に絞り込んで、特定の管理パックに適用される上書きを確認できます。
適切なシールされていない管理パックをシールすると、図 6 のような結果を示すレポートを実行できます。このレポートでは、モニタについてインストールおよび削除された日時のほか、上書きが適用されるルールやモニタが明示され ([Affected element] (影響を受ける要素) 列) ています。ここから、上書きのレポートがアクティブな上書きを列挙するだけでなく、上書きの構成の変更履歴のレポートとしても使用できることがわかります。
Figure 6 Overrides Report detail
Figure 6 Overrides Report detail
また、影響を受ける各ルールやモニタの詳細情報ビュー下部には、[Rule configuration view] (ルールの構成ビュー) というハイパーリンクがあります。このリンクをクリックすると、影響を受けるオブジェクトの種類に関する情報のみを表示するルール ビューまたはモニタ ビューが別ウィンドウとして開かれます。たとえば、図 6 に表示されている上書き (Active Directory Domain Controller Server 2003 コンピュータの役割をターゲットとするルールの上書き) の [Rule configuration view] (ルールの構成ビュー) リンクをクリックして表示されたルール ビューには、このオブジェクトの種類をターゲットとするルールだけが表示されます。

ワークグループ コンピュータのサポート
ユーザー フィードバックの中で重要なポイントの 1 つは、ワークグループ構成のサーバーとワークステーションの管理の必要性に関するものでした。多くの環境では、ドメインに参加していない境界ネットワークまたはブランチ オフィスに配置されているサーバーが少なくとも 1 台あります。Essentials では、Essentials サーバーとエージェントで管理されているコンピュータ間の相互認証が必要なため、Essentials サーバーの信頼境界外にあるワークグループ コンピュータは、Essentials エージェント展開の範囲外にあると見なされていました。これは、多くの環境で、インフラストラクチャの重要なコンポーネントが、監視や Essentials の修正プログラム管理プロセスの対象外になる可能性があることを意味しています。このようなコンピュータを安全に管理するにはどうしたらよいでしょうか。
SP1 では、Active Directory と Kerberos 認証が利用できない場合に、証明書ベースの認証が利用できるようになりました。この認証機能を利用するには、Essentials サーバーとエージェントで管理されているコンピュータの両方に X.509 デジタル証明書がインストールされている必要があります。このデジタル証明書は、Windows® のスタンドアロンまたはエンタープライズ ルート証明機関から発行できます。現在 Windows の証明機関が環境にない場合は、Essentials サーバーも含め、環境内の任意のドメイン コントローラかメンバ サーバーでプログラムの追加と削除ユーティリティを使用して、この機能をインストールできます。Windows Server 2003 の証明書サービスと公開キー基盤 (PKI) の詳細については、microsoft.com/windowsserver2003/technologies/pki を参照してください。
Essentials で証明書ベースの認証を構成するには、まず証明書を要求し、Essentials サーバーと管理対象のコンピュータの両方に対して証明書を発行します。この要求は、証明機関として機能するサーバー上の Web サイトから実行できます。
証明書を発行およびインストールしたら、MOMCertImport コマンド ライン ユーティリティを使用して、Essentials で使用するように証明書を登録する必要があります。証明書の構成を完了するには、証明書をファイル (.pfx 形式) にエクスポートし、ローカル コンピュータで次の構文を使用して、MOMCertImport コマンド ライン ユーティリティを実行します。
MOMCertImport.exe <cert path \ name>
Essentials サーバーと管理対象のコンピュータ上で以上の手順をすべて実行すると、相互に認証を行い、暗号化チャネルを介してデータを安全に交換できるようになります。エージェント展開プロセスを完了するには、ターゲット コンピュータ上で Essentials エージェントを手動でインストールします。

ネットワークとデバイスの監視
Essentials 2007 には、多くの SNMP 対応ネットワーク デバイスの一般的な属性を検出できるネットワーク デバイス監視機能が用意されています。現在最も普及しているのは SNMP バージョン 2c (SNMPv2c) ですが、すべてのネットワーク デバイスの仕様が同じというわけではありません。それを踏まえて、SP1 では SNMP バージョン 1 (SNMPv1) をサポートし、SNMPv2c に対応していない一部の UPS、ルーター、プリンタ サーバーなど、さまざまな古いネットワーク デバイスを監視できるようにしています。コンピュータとデバイスの管理ウィザードに追加されたドロップダウン リストを使用して、Essentials の監視で使用する SNMP のバージョンを指定できるようになりました (図 7 参照)。
Figure 7 Enhanced interface for network device discovery
Figure 7 Enhanced interface for network device discovery

更新管理の強化
SP1 では、更新管理も大幅に強化されています。Windows Server Update Services (WSUS) 3.0 の自動承認ルールを使用すると、Microsoft Word の定義更新ファイルの自動承認など、製品と更新プログラムの種類を指定できます。
複数の自動承認ルールのサポートが追加され、Essentials は WSUS 3.0 プラットフォームと同程度の機能を提供できるようになりました (図 8 参照)。これにより、Windows Vista® の重要な更新プログラムや 2007 Office system のサービス パックなど、複数の種類の更新用に自動承認を作成できます。自動承認のルールは、WSUS サーバー上に現在あるすべての更新に適用されます。したがって、[自動承認] ダイアログ ボックスで [Run Rule(s) Now] (すぐにルールを実行) タスクをクリックすると、Essentials コンソールに表示されている既存の更新に直ちに変更を適用できます。
Figure 8 Auto-Approvals in Update Management
Figure 8 Auto-Approvals in Update Management
ワークグループ構成のコンピュータにエージェントを展開することがサポートされるようになったので、Essentials コンソールから環境全体の更新管理を制御できるようになります。

オブジェクトの正常性状態の再計算
これまでは、正常性エクスプローラでモニタの状態を参照する場合、回復や他の修正操作が成功したかどうかを確認するには、モニタの状態の定期的な更新が行われるまで待つ必要がありました。SP1 の正常性エクスプローラには、正常性の再計算タスクが追加され、モニタの正常性の再計算をオンデマンドで実行できるようになりました (図 9 参照)。これは、1 つの修正操作を完了してから次の修正操作に取り掛かるまでにかかる、モニタの状態が正常に戻ったかどうかを確認する時間を短縮できるため、トラブルシューティング プロセスをより効率よく実行できます。
Figure 9 Recalculate Health Task in Health Explorer
Figure 9 Recalculate Health Task in Health Explorer
同様に正常性のリセット タスク (RTM 時点で実装済み) にも重要な機能強化が施され、すべてのモニタが実際に正常性状態を正常 (緑) にリセットする要求に応答できるようになりました。RTM リリースでは Essentials サーバー自体にリセット要求を実行した場合に応答しないことがありましたが、このような場合もリセット要求に応答するようになります。

診断のスクリプト化
診断は Essentials 2007 に新しく追加された特殊なインライン タスクで、アラートが発生したときにデータ収集タスクを自動またはオンデマンドで実行できます。自動診断は、モニタがエラー状態になるたびに実行されるように構成された診断です。診断の結果は、正常性エクスプローラの [状態変更イベント] タブの [詳細] ペインに表示されます。オンデマンド診断は、同じ領域にハイパーリンクとして表示され、このリンクをクリックすると実行できます。結果は、ローカル コンピュータ上でポップアップ ウィンドウに表示されます。
RTM リリースでは、診断機能はコマンド ラインからの操作のみがサポートされていましたが、SP1 では診断機能が拡張され、診断タスクでスクリプトが使用できるようになりました (図 10 参照)。これにより、エラー状態が発生した場合に、より高度でバラエティに富んだ自動データ収集を実行できるようになります。これらの診断タスクでは、VBScript と JScript® の両方を利用できます。
Figure 10 Alert Details pane with Show/Hide Knowledge links
Figure 10 Alert Details pane with Show/Hide Knowledge links

Visio へのエクスポート
SP1 の新機能として、ダイアグラムを Microsoft Visio® 2007 形式でエクスポートする機能がサポートされました。ダイアグラム ビューを選択すると、ツール バーにこの機能のボタンが表示されます。これは、非常に便利なドキュメント作成支援機能です。Active Directory と Exchange Server 2003 管理パックには、詳細なトポロジ ダイアグラムが既定で含まれているため、管理者がドキュメント作成に費やす時間を節約できます。また、ダイアグラムのレイアウトのユーザー設定は保存できます。保存されたユーザー設定は、Essentials コンソールで次に同じダイアグラム ビューを選択したときにも適用されます。

バックアップと回復のガイダンスの向上
Essentials 2007 SP1 のインストールが完了すると、インストール ウィザードに、Essentials 管理サーバーの暗号化キーをバックアップするオプションが自動的に表示されるようになりました (図 11 参照)。このキー ペアは、Essentials サーバーによって、オペレーション データベース内の Run As Credentials のセキュリティで保護された記憶域内で使用されます。これらのキーは、Essentials サーバーをバックアップから復元する場合にも必要です。このキー ペアがないと、Essentials を再インストールし、最初から構成し直す必要があります。
Figure 11 Essentials encryption key backup
Figure 11 Essentials encryption key backup

管理パックの質の向上
Essentials SP1 でのさまざまな機能強化のほかに、Essentials 製品チームは、より多様な厳しいテストを実行したり、さまざまな製品チームやアプリケーションの有識者との意見交換をより活発に行ったりすることで、Essentials プラットフォームの管理パックの大幅な品質向上を図っています。結果として、自己調整しきい値、分散アプリケーション モデルを使用したサービス指向の監視や、強力なレポート エンジンなど、このマイクロソフト監視プラットフォームの新機能を利用する管理パックが新たにリリースされることになります。
マイクロソフトでは、Essentials の新機能を利用するネイティブな管理パックのリリースを 2008 年から始める予定です。Essentials 2007 の管理パックは、System Center 管理パック カタログ (go.microsoft.com/fwlink/?LinkId=112399) からダウンロードできます。

試してみよう
System Center Essentials 2007 SP1 では、同製品が中規模企業の IT インフラストラクチャの管理に最適な投資となるためのパフォーマンス強化が施されています。既に Essentials 2007 を環境に導入している場合は、SP1 をダウンロードして、その機能とパフォーマンスの強化を実際に体験してください。Essentials 2007 の導入がまだで、Essentials 2007 SP1 の機能を試してみたい場合は、SP1 の統合インストーラ パッケージをダウンロードできます。これらのパッケージと追加の製品情報については、Essentials 2007 のホームページ (microsoft.com/systemcenter/essentials) を参照してください。

Pete Zerger は AKOS Technology Services のコンサルティング パートナーであり、IT 業界で 9 年間の経験があります。専門は、エンタープライズ向けの運用管理、ディレクトリ サービス、メッセージング ソリューションの設計と展開です。MCSE for Messaging と MCTS for SQL Server 2005 の認定資格を取得しており、Microsoft MVP for Microsoft Operations Manager でもあります。また、Essentials 2007 と System Center Suite を話題とする人気のコミュニティ サイト systemcenterforum.org の設立者です。


 編集長から: 新コラム「SharePoint の内部」の誕生を祝して
編集長から
新コラム「SharePoint の内部」の誕生を祝して

先月の「編集長から」の内容は覚えておられるかと思いますが、「The Cable Guy」が最終回を迎えたことを受けて、今月号の TechNet Magazine では、新しいコラムの連載がスタートします。IT プロフェッショナルが SharePoint インフラストラクチャの設計、展開、セキュリティ保護、保守、およびサポートを行うのに必要なあらゆる情報を提供する新しい月刊コラム「SharePoint の内部」を歓迎していただければさいわいです。お約束どおり、今月は、Pav Cherny が、初心に返って、柔軟性のある SharePoint のインフラストラクチャの主要要素を概説します。来月は、SharePoint サイトの管理についての情報を提供する予定です。引き続き、皆さんからのご意見をお待ちしております。このコラムで取り上げてほしい SharePoint 関連のトピックがある場合は、tnmag@microsoft.com (英語のみ) までご連絡ください。
また、今月号では、Gil Kirkpatrick が Windows Server 2008 における Active Directory のバックアップと復元に関する詳細かつ総合的なコラムをお届けします。すべてのネットワークではないにしても、Windows を採用している多くのネットワークでは、Active Directory は ID とアクセスに関する情報の信頼できるソースです (これに関しては、皆さんの同意を得られると思っていますが、非常に重要です)。また、Exchange Server、SharePoint、Configuration Manager などの展開における主要なインフラストラクチャ要素でもあります。先月、シカゴで開催された Directory Experts Conference で Gil が主催したセッションの 1 つに参加した際、彼が参加者に総合的な Active Directory の障害回復計画を所有している人がいるかどうかをたずねたところ、挙手した人の数は片手で数えられるほどの少なさでした。ですから、Gil のコラムをご覧になることをお勧めします。
Active Directory が専門分野ではない方がいらっしゃるかもしれませんが、心配ありません。そのような方を対象にしたコラムも多数ご用意しています。Matt Fontaine が Windows Mobile デバイスを管理している人のマストアイテムになる新しいテクノロジである System Center Mobile Device Manager を紹介するコラムを、Pete Zerger が System Center Essentials SP1 の新機能を紹介するコラムを、そして Jesper Johansson がハイゼンベルグの不確定性原理を IT セキュリティに適用するというコラムを執筆しました。お馴染みの Scripting Guys のコラムもありますし、Exhange Queue & A が再登場したりするなど、今月号も盛りだくさんでお届けします。
最後になりますが、TechNet Magazine の新しく魅力的な Web サイトを構築するプロジェクトは進行中です (この新しい Web サイトには、technetmagazine.com からアクセスできます)。一部の記事では、How-To スクリーンキャストをご用意しています。このスクリーンキャストは、オンラインで公開している記事に付随するもので、コンテンツをステップ バイ ステップで確認することができるビデオです。このスクリーンキャストで取り上げてほしいトピックやテクノロジについてのご意見をお寄せください。私の連絡先は tnmag@microsoft.com (英語のみ) です。よろしくお願いします。 —Joshua Hoffman


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

Windows クラスタ
Windows® Compute Cluster Server と従来の Windows クラスタの違いについて教えてください。
—blogs.technet.com/tnmag より

これは非常によく寄せられる質問です。Windows Compute Cluster Server (CCS) の話をするとき、可用性クラスタリング (フェールオーバー クラスタリング) に関する多くの質問を受けますが、計算クラスタは、システム間でサービスのフェールオーバーを提供する "可用性クラスタ" とは異なります。
計算クラスタは、ジョブ キューやスケジューラを使用して、タスクをクラスタ内のさまざまなシステムに割り当てます。スケジューラ (クラスタのヘッド ノードで実行されます) は、ジョブのスケジュール要求を受け取った後、クラスタ内の他のノードに作業を割り当てます。簡単に言うと、CCS が作業を複数のコンピュータに分散するのに対し、可用性クラスタリングはサービスが中断されないようにすることを目的としています。
—John Kelbley (シニア テクニカル プロダクト マネージャ)

Robocopy GUI
2006 年 11 月号の Robocopy GUI に関するコラム (technetmagazine.com/issues/2006/11/UtilitySpotlight) を拝見させていただきました。このツールによって Robocopy が使いやすくなりました。また、タブによって機能がグループ化されるので、多くのコマンド ライン オプションを理解しやすくなりました。
—Biff M

フィードバックをお寄せいただき、ありがとうございます。このツールがお役に立ったようで何よりです。他にも、TechNet Magazine で取り上げてほしいツールがありましたら、tntools@microsoft.com (英語のみ) までご連絡ください。

デバイス ドライバ
特定のデバイス ドライバに関連付けられているすべてのファイルを確認する方法はありますか。
—T.P.

特定のドライバのインストールに使用されるすべてのファイルを確認しようとしているのであれば、残念ながら、完全な解決策はありません。最も確実なのは、目的のドライバに付属している INF ファイルの内容を確認することです。特に、通常は *.copyfiles と記述されている、ドライバのプラグ アンド プレイ ID (PnPID) に関連するセクションに注目してください。このセクションには、ドライバのインストール中にコピーされるファイルの名前が記述されています。
ただし、ドライバの一部として "共通インストーラ" (CoInstallers) を呼び出すドライバに関しては、この確認作業は困難です。これらのドライバは、さらに他のファイルを抽出またはインストールする場合があります。とはいえ、ほとんどの場合、CopyFiles セクションを解析すれば大部分のファイルは確認できます。INF ファイルの中身を注意深く確認し、その内容を理解するようにしてください。
—Wes Miller (コラムニスト、「デスクトップ ファイル」担当)

Windows 認証
Windows 認証に関する情報が記載された記事やホワイト ペーパーを探しています。特に、インターネット認証サービス (IAS) を使用した、Windows 2000 Active Directory® ドメインでのワイヤレス接続について学習したいと思っています。この情報が記載された記事があれば教えてください。
—Brett M

このトピックについて最も詳しい情報が提供されているのは、TechNet の IAS TechCenter (technet.microsoft.com/network/bb643123) でしょう。このページには、IAS を使用した認証に関する多くの記事とホワイト ペーパーへのリンクが記載されています。
また、質問を投稿できるオンライン フォーラムとしてお勧めしたいのは、Windows 2000 Server のセキュリティに関するニュースグループ (microsoft.com/technet/community/newsgroups/dgbrowser/en-us/default.mspx?dg=microsoft.public.win2000.security) です。

読者からの感謝の言葉
2007 年 12 月号の「基本的なコンピュータ フォレンジック ガイド」(technetmagazine.com/issues/2007/12/Forensics) を楽しく拝見させていただきました。まず、このような重要な情報を提供してくださったことに感謝しています。また、セキュリティ分野でのすばらしい経験を活かしてくださった、マイクロソフトのプログラム マネージャである Tom Cloward 氏、およびマイクロソフトのテクニカル プログラム マネージャであり、セキュリティ関連の業務も担当しておられる Frank Simorjay 氏という執筆者のお二人にも感謝しています。Simorjay 氏はセキュリティ分野の業務に携わっておられますが、ご自身のセキュリティ分野に関する豊富な知識を活かし、インターネットのセキュリティを狙った攻撃によって発生した問題の解決に協力していただくことに同意してくださいました。このことは高い称賛に値し、大変感謝しています。
—Mr. S.

Mr. S さん、お便りありがとうございます。おっしゃるとおり、このトピックは非常に重要です。今後の TechNet Magazine でも、これに関連する情報を取り上げていく予定ですので、ご期待ください。改めて、ご意見ありがとうございました。


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

ディスク領域を分析する
FolderSizes
foldersizes.com
クライアント コンピュータ上の領域を占有しているファイルを特定するにはどうすればよいでしょうか。ディスク領域モニタを使用すれば、コンピュータのディスクの空き領域が少なくなったときに通知を受け取ることができますが、ディスク上の不要なファイルを削除し、空き領域を正常な割合に戻す方法を判断するのは、厄介な作業になる場合があります。ディスク領域を占有しているファイルを特定するときに役立つユーティリティの 1 つに、Key Metric Software の FolderSizes があります。
このアプリケーションを初めて起動すると、アプリケーションの UI に関する簡単な説明が表示されるので、その後の作業に役立ちます (ただし、このアプリケーションの構造は非常に単純です)。ドライブまたはフォルダを分析するには、階層構造になっている [Folder Browser] (フォルダ ブラウザ) パネル内のドライブまたはフォルダをダブルクリックするだけです。FolderSizes によって対象がスキャンされた後、ディスクの使用状況を表すグラフと、フォルダ ビューが表示されます。フォルダ ビューには、各親フォルダ内のファイルが占有している領域のサイズが表示されます。1 回のクリックで、フォルダの内容を表すグラフの形式を円グラフと棒グラフの間で切り替え、領域を使用しているファイルの内訳を把握できます。個人的には、大量の兄弟ディレクトリの内容を表示する場合は棒グラフの方が便利だと思います。
棒グラフ、円グラフ、またはフォルダをダブルクリックすると、サブフォルダに移動します。このような方法で移動することによって、潜在的な問題点 (ユーザーが "販売プレゼンテーション" という名前を付けた MP3 ファイルの "隠し" ディレクトリなど) をすばやく簡単に確認できます。また、ユーザーが何もかもを各自のコンピュータに保存して、ディスクがドキュメントであふれ返ってしまう場合は、最終更新日に基づいてファイルを並べ替え、長期間アクセスされていないファイルを確認することもできます。これにより、ユーザーが十分納得したうえでファイルを CD にアーカイブしたり、問題を発生させることなくファイルを完全に削除したりできます。
もう 1 つの優れた特徴は、グラフに表示されるフォルダのレベルをカスタマイズできることです。たとえば、ドライブ上のすべてのフォルダをサイズの降順に並べ替えて一度にグラフに表示し、問題となっているフォルダを特定することもできます。フォルダを特定したら、そのフォルダを右クリックし、[command prompt from here] (コマンド プロンプトを起動してこのフォルダに移動する) または [explore this folder] (このフォルダを調べる) をクリックします。その後、必要なその他のユーティリティやチェックを実行できます。
FolderSizes にはレポート生成プログラムも組み込まれており、別のビューに対象のファイル システムの内容を出力できます。これにより、システムに格納されている特定の種類のファイルの中で最もサイズの大きいファイルや最も古いファイル、一時ファイルや重複しているファイル、すべての読み取り専用ファイル、ファイル サーバー上に格納されている、特定の所有者を持つファイルなどを確認できます。確認できるファイルの種類は、他にも多数あります。レポートが生成されたら、ビューにフィルタをかけたり、レポートを印刷したり、結果を XML、HTML、または CSV にエクスポートしたりできます。
これまでに説明したことに加え、FolderSizes では簡単にバックアップを実行できる優れた方法も提供され、アーカイブする必要があるファイルだけを取得できます。また、アプリケーションのコマンド ライン インターフェイスを使用してスクリプトを記述し、クライアントまたはサーバー システムのチェックを自動化することもできます。サーバーまたはクライアント コンピュータで、どのファイルがディスク領域を占有しているかを簡単に特定できる方法をお探しの場合は、FolderSizes の使用を検討してみてください。
価格 : 1 ユーザー ライセンスあたり 50 ドル～
FolderSizes offers chart visualization of system folders
FolderSizes offers chart visualization of system folders

ユーザー アカウントを管理する
Inactive Users Tracker
netwrix.com/inactive_users_tracker_freeware.html
組織の規模が大きくなればなるほど、非アクティブなユーザー アカウントを見逃しやすくなります。セキュリティの観点から、こういった非アクティブなユーザー アカウントを簡単に検出し、無効にするか削除することによって、潜在的なセキュリティ ホールを排除できる方法を用意しておくことをお勧めします。NetWrix Corporation から提供されているフリーウェア ユーティリティの Inactive Users Tracker を使用すると、非アクティブなユーザー アカウントを簡単に管理できます。
このツールは Active Directory® ドメインを定期的にスキャンして非アクティブなユーザー アカウントを検出し、任意の管理者の電子メール アドレスに、それらの非アクティブなアカウントの一覧を電子メールで送信します。管理対象のドメインを指定できるだけでなく、Active Directory 内の非アクティブなアカウントの検出操作をどのアカウントに許可するかを指定できます。また、特定の日数を設定し、その日数が経過したアカウントを非アクティブとして "分類" し、通知の電子メール内の一覧に追加できます。もちろん、処理の開始時間をスケジュールすることもできます。
それ以外にも、通知の電子メールを管理者のアドレスに中継するように SMTP サーバーを構成したり、名前フィルタを使用して、非アクティブなユーザー アカウントを自動的にフィルタ選択する (コンサルタントに割り当てられているすべてのアカウントが "c_" で始まる場合など) かどうかを指定したりできます。
また、有償バージョンも提供されています (製品を購入するユーザーの環境に応じた内容および価格で提供されます)。このバージョンでは、ユーザーに送信される電子メール メッセージをカスタマイズする機能、非アクティブなユーザー アカウントを自動的に無効にする機能、技術サポートなどが提供されます。
価格 : 無償
Inactive Users Tracker notifies you about inactive users
Inactive Users Tracker notifies you about inactive users

電子メール通信を強化する
Exclaimer Mail Utilities 2007
exclaimer.com/MailUtilities2007.aspx
訴訟や規制の数がますます増加している現在、組織の電子メール通信を保護することは非常に重要です。また組織は、一貫性のある通信とブランドの認識によって、通信相手とのより良い関係を築くことができます。Exclaimer Mail Utilities 2007 は、展開済みの Exchange Server 2007 と連携するように設計されており、この 2 つのことを実現するのに役立ちます。
このアプリケーションでは、免責、ブランド、および署名という 3 種類の基本的な機能が提供され、これらを利用して、組織の電子メール通信を一元管理および保護することができます。また、スパム対策やウイルス対策に役立つモジュールを追加することもできます。
免責に関しては、Exclaimer Mail Utilities を使用して、カスタマイズしたメッセージ (電子メール本文の先頭または末尾に表示されます) を組織から送信されるすべてのメッセージに追加することにより、組織が訴訟の対象になる可能性を低減し、医療保険の携行性と責任に関する法律 (HIPAA) や Circular 230 などの法規制への準拠を強化できます。ブランドに関しては、すべての送信メッセージに画像とブランド タグを簡単に追加して、顧客ベースとの通信に一貫性を持たせることができます。署名に関しては、スマート デバイス、Microsoft® Outlook® Web Access、および標準的な Outlook クライアントのいずれからメッセージが送信されるかにかかわらず、すべてのメッセージに自動署名を適用できます。署名は、既に Active Directory ツリーに格納されているデータから動的に生成されます。さまざまな要因 (電子メールが内部の人物と外部の人物のどちらに送信されたか、送信者、受信者、メッセージの件名に含まれている文字列など) に基づいてこれらの署名をカスタマイズするように、ツールを構成できます。
Exclaimer Mail Utilities 2007 の価格はユーザー数に基づいて設定されており、25 ユーザー ライセンスあたり 245 ドルから販売されています。ユーザー数が増えるごとに、割引率は高くなります。また、スパム対策モジュール、ウイルス対策モジュール、および技術サポートは別料金で提供されます。最初の 1 年間のサポートは必ず購入内容に含まれ、25 ユーザー ライセンスあたり 55 ドルかかります。パフォーマンス上の理由から、Exclaimer Mail Utilities 2007 を実行するには、64 ビットの Windows Server® 2003 または Windows Server 2008 を実行しているコンピュータを使用する必要があります。この要件を満たすことができるとしても、まだ Exchange Server 2003 を実行している場合は、これ以外のバージョンも利用できます。
価格 : 25 ユーザー ライセンスあたり 245 ドル～

ブック レビュー
How to Cheat at Securing SQL Server 2005
syngress.com
IT プロフェッショナルは、インフラストラクチャの実装においてセキュリティが最大の懸念事項であることを認識しています。今日の相互接続された環境を取り巻く状況、およびシステムに格納されている機密情報の多さについて考えてみてください。特に考慮する必要があるのは、SQL Server® インスタンスのセキュリティです。なぜかと言えば、SQL Server インスタンスで機密情報が一元管理される傾向があるからです。また、なんらかの方法で機密情報が不正に利用された場合は、サーベンス オクスリー法や HIPAA といった、人々のプライバシーを保護するために策定された法規制によって、組織が法律上および財務上の問題を抱えることになる可能性があります。
SQL Server 2005 インスタンスをセキュリティで保護する作業を行う場合は、『How to Cheat at Securing SQL Server 2005』を参考にすることをお勧めします。少し誤解されやすいタイトルですが、この書籍には "Cheat (うまくごまかす方法)" ではなく、展開済みの SQL Server 2005 に制限を実装する方法が順を追って説明されています。この書籍の内容は、ビジネス要件を満たすために必要な操作だけを許可し、他の操作はすべて許可しないという "最小限のアクセス" の基本原則に従っています。
まず序文の後に、セキュリティ構成ツールを使用して SQL Server 2005 インスタンスが攻撃を受ける確率を低減する方法が記載されています。ここでは、SQL Server 2005 をインストールしたときに既定で提供されるサービスとそれらのスタートアップの種類 (手動、自動、または無効) など、役に立つ情報を得ることができます。次の章には、SQL Server ロールの説明、およびこれらを使用して管理作業をどれぐらい大幅に単純化できるかに関する説明が記載されています。たとえば、ロールを Windows® グループに関連付ける方法が記載されており、この方法を使用すると、新しいユーザーをグループに追加したときに、ロールに許可されているリソースへのアクセスが、自動的にそのユーザーにも許可されます。
認証ときめ細かいアクセスに関する章には、Windows ログインと SQL Server ログインの説明、およびそれぞれの利点と欠点が記載されています。また、認証に関するマイクロソフトのベスト プラクティスも提供されています。その後、承認の説明に移り、インスタンスに対してユーザーが実行できる操作 (つまり、データベースで言うところの、セキュリティで保護可能なリソースに対する権限) を調整するためのオプションについて説明しています。また、専用管理者接続 (DAC) についても学習できます。DAC はローカルで管理者のみに提供される接続であり、この接続を使用すると、クエリやプロセスがすべてのリソースを使い果たし、サーバーが応答しなくなった場合に、インスタンスにアクセスできます。これは、SQL Server 2005 よりも前のバージョンでは提供されなかった便利な機能です。
SQL Server 2005 では、スキーマとユーザーが分離され、別々のエンティティになりました。この書籍には、T-SQL と SQL Server Management Studio を使用したスキーマの定義、更新、および削除に関する説明が記載されている章があります。この章には、いくつかの役立つヒントも含まれています。たとえば、新しいスキーマを作成する場合以外は、SQL Server 2005 で sp_adduser ストアド プロシージャを使用して新しいユーザーを作成しない方がよいこと、その代わりに T-SQL の CREATE USER ステートメントを使用すれば、ユーザー以外のオブジェクトが作成されないことが記載されています。
SQL Server インスタンスをセキュリティで保護するためのもう 1 つの重要な要素は、もちろんパスワードです。次の章では、すべてのアカウントに適用されるセキュリティのレベルを均一化するのに役立つパスワード ポリシーの詳しい説明が記載されています。実装に関するさまざまなシナリオが紹介されているので、ユーザーは自分の環境に最も適したポリシーとポリシーの種類を選択できます。その後、データ定義言語 (DDL) トリガの説明に移り、この機能を使用して、意図していない構造上の変更からインスタンスを保護したり、サーバー ログインに対する変更の監査記録を提供したりできることが説明されています。
次の章には、データとスキーマを暗号化して機密情報を保護するために、SQL Server 2005 によって提供されるさまざまな方法が記載されています。最後に、SQL Reporting Services、SQL Analysis Services、および SQL Server Integration Services (SSIS) の概要と、セキュリティ関連のベスト プラクティスのガイドラインが提供されています。この 2 つの付録には、SQL Server 2005 に関連するグループ ポリシーと Active Directory の実装方法、およびそれらをセキュリティで保護する方法が記載されているので、非常に役立ちます。
この書籍全体を通して提供されている 2 つのセクションは、特に便利だと思います。まず、章ごとに "ソリューションの概要" を示すセクションがあり、その章で取り上げている要素の特徴、事実、およびベスト プラクティスが箇条書きの概要として提供されます。もう 1 つの "よく寄せられる質問" が記載されたセクションでは、SQL Server 2005 インスタンスの管理に関する疑問への簡単な回答が提供されます。SQL Server 2005 のセキュリティ管理に必要な情報を簡単に入手したい場合は、『How to Cheat at Securing SQL Server 2005』をお勧めします。
価格 : 電子書籍は 19.98 ドル、紙の書籍は 49.95 ドル

強力な画面キャプチャ機能
ScreenHunter 5 Pro
wisdom-soft.com/products/screenhunter_pro.htm
画面のキャプチャ機能は、ユーザー向けの手順を文書化したり、アプリケーション内で発生したエラー メッセージを例示したり、機能に関する簡単なプレゼンテーションを作成したりする場合に、非常に役立ちます。もちろん、Windows でも組み込みの画面キャプチャ機能が提供されます (画面全体をキャプチャする場合は PrintScreen キーを押し、アクティブなウィンドウだけをキャプチャする際は Alt キーを押しながら PrintScreen キーを押します) が、OS に組み込まれている機能は限られています。キャプチャの対象やスケジュールをさらにきめ細かく制御する必要がある場合、または再生中のムービーから画面をキャプチャする必要がある場合は、それらの作業に役立つサードパーティ製の画面キャプチャ ユーティリティの使用を検討することをお勧めします。このようなツールの 1 つに、Wisdom Software から提供されている ScreenHunter Pro があります。この手頃な価格のユーティリティには、便利な機能が数多く含まれており、より要件に合った画面キャプチャを作成できます。
このユーティリティの UI は単純です。画面のキャプチャ元を選択し、キャプチャした画面の保存先を指定するには、これにふさわしい名前が付いた [From] (キャプチャ元) タブと [To] (保存先) タブを使用します。また、このアプリケーションでは、さまざまな対象をキャプチャできます。例としては、調整可能または固定された四角形の領域、特定のオブジェクトやウィンドウ、アクティブなウィンドウ、アクティブなウィンドウの特定の部分、画面全体、DirectX® やスクリーンセーバーのソース、再生中のムービー、さらに複雑な図形 (手書きの図形、楕円、定義した多角形の領域) などが挙げられます。また、複数のウィンドウのオブジェクトやメッセージ ボックスを同時にキャプチャすることもできます (これは、アクティブなアプリケーションのダイアログやその他のウィンドウ インターフェイスのみを取得する場合に役立ちます)。その後、作成した画面キャプチャをクリップボード、指定したビューア、エディタ、プリンタ、またはファイルに出力できます。また、画面キャプチャを電子メール アドレスに送信することもできます。
キャプチャしたイメージは、さまざまな画質の BMP、PNG、JPEG、または TIFF ファイルとして保存できます。また、キャプチャしたイメージのサイズを自動的に調整したり、罫線や透かしを追加することで、キャプチャ後のイメージに対して行う作業の量を減らすことができます。指定した間隔で自動的に画面をキャプチャする (実質的には、コンピュータ上で行われた操作を記録する) ようにアプリケーションを設定することもできます。
ScreenHunter Pro で提供されるもう 1 つの便利な機能は、自動スクロール機能のサポートです。この機能により、たとえば、画面に表示できる範囲を超える、大きな Web ページをキャプチャできます。また、私は多くの IT プロフェッショナルと同じように複数のモニタを使用しているので、複数のモニタでのキャプチャのサポート、つまり 1 回のキャプチャで複数の画面に表示されているすべての情報を取得できる機能も気に入っています。
さらに、このユーティリティには組み込みのイメージ エディタが含まれているので、同じアプリケーション内でイメージの調整を行うこともできます。電子メールの自動送信、スケジュールに基づいたキャプチャの実行、透かし、複数のモニタでのキャプチャなど、一部の高度な機能を使用する必要がない場合は、少し安価なバージョンの ScreenHunter Plus をお勧めします。また、必要最低限の機能だけが提供されるバージョンは、無償で入手できます。
価格 : 29.95 ドル (ScreenHunter Pro)
ScreenHunter Pro lets you specify when and what you capture
ScreenHunter Pro lets you specify when and what you capture

Greg Steen


 Exchange Queue &amp; A: Exchange Server 2007 SP1 の展開
Exchange Queue & A
Exchange Server 2007 SP1 の展開
Nino Bilic

質問 - Exchange Server 2007 SP1 は 64 ビット版しか提供されないのでしょうか。32 ビット版も提供されている場合、その 32 ビット版は運用環境で使用できますか。
回答 - これに関しては、Exchange 2007 の最初のバージョン (RTM) と SP1 との間に違いはありません。SP1 には、32 ビット版と 64 ビット版があります。ただし、RTM と同様、運用環境でのサーバーの役割のインストールがサポートされるのは 64 ビット版のみです。32 ビット版の SP1 は、RTM と同様、さまざまな /prepare セットアップ スイッチを実行したり、64 ビット サーバーを管理したりする目的で使用できます。

質問 - Exchange 2007 SP1 サーバーを準備する場合、Exchange 2007 RTM の完全インストールを実行してから SP1 を適用しなければならないのでしょうか。
回答 - これは Exchange 2007 SP1 の特徴であり、以前のバージョンの Exchange 用に提供されたサービス パックと比較した場合、大きく異なります。SP1 を入手した場合、実質的には SP1 が組み込まれた RTM を入手したことになります。つまり、Exchange Server 2007 SP1 を新しくインストールするときに、RTM の DVD を使用する必要はありません。
このため、SP1 のみを使用して、新しい Exchange 2007 SP1 サーバーを準備できます。たとえば、Exchange 2007 を初めて Exchange Server 2003 組織に参加させる場合でも、SP1 を使用して準備を開始できます。
質問 - ある Windows Server® 2003 サーバーで Exchange 2007 RTM を実行しており、現在そのコンピュータに Exchange 2007 SP1 をインストールしています。マイクロソフトによると、Exchange 2007 SP1 は Windows Server 2008 でサポートされるとのことなので、後から Windows Server 2008 へのインプレース アップグレードを行う予定です。この計画についてどう思われますか。
回答 - 残念ながら、これは良い考えではありません。Exchange 2007 RTM または SP1 がインストールされている Windows Server 2003 サーバーから Windows Server 2008 へのインプレース アップグレードを行うことはできません。これには複数の技術的な理由があります。また、このようなインプレース アップグレードを行った場合に、既にインストールされている Exchange が機能しなくなることを理解してください。
詳細については、「不可能なミッション : Microsoft® Exchange Server 2007 を Windows Server 2003 から Windows Server 2008 にインプレース アップグレードする」(msexchangeteam.com/archive/2007/10/04/447188.aspx) を参照してください。

質問 - ラボに設置されている何台かのサーバーで、プロダクト ID を入力していません。そのため、Exchange 管理コンソールを起動すると、残りの日数が "0 日" であることを示す警告がポップアップ表示されます。このようなサーバーで、プロダクト キーを入力せずに、Exchange 2007 SP1 へのアップグレードを行うことはできますか。
回答 – はい、できます。Exchange 2007 SP1 のセットアップ (スクリーンショットを参照) では、既にインストールされたサーバーの試用期間の長さを確認することはできません。このため、ご質問のシナリオでは、アップグレードはブロックされません。

質問 - メールボックス サーバーに Exchange 2007 SP1 をインストールしました。このサーバーにクライアント アクセス サーバーの役割を追加したいと考えています。Exchange 2007 RTM と新しい Exchange 2007 SP1 のどちらを使用すればよいでしょうか。
回答 - Exchange 2007 SP1 が適用された後に、サーバーの役割を追加でインストールするには、Exchange 2007 SP1 を使用する必要があります。既に説明したように、Exchange 2007 SP1 は、Exchange 2007 の実行に必要なすべてのファイルが含まれた、単独で動作する製品です。そのため、SP1 が正常にインストールされれば、Exchange 2007 RTM は不要になります。
当然ながら、Exchange 2007 SP1 にアップグレードしているサーバーに複数のサーバーの役割がインストールされている場合は、SP1 を適用すると、インストールされているすべての役割が自動的にアップグレードされます。同じ物理サーバー上の一部の役割にのみ SP1 を適用することはできません。

質問 - Exchange 組織に複数の Exchange 2007 サーバーが存在し、そのいくつかのサーバーにサーバーの役割が分散されています。どのサーバーの役割を最初にアップグレードすればよいでしょうか。
回答 - まず最初に、Exchange 2007 SP1 のリリース ノート (go.microsoft.com/fwlink/?LinkId=112364) をダウンロードし、内容を確認してください。このリリース ノートには、既存のインストールへの SP1 の適用に関する重要な情報が記載されています。
ここでは、すぐに解答にたどり着けるように、SP1 のリリース ノートから、まさにこの質問に該当する部分を抜粋し、以下に示します。

「クライアント アクセス、ユニファイド メッセージング、ハブ トランスポート、またはエッジ トランスポート サーバーの役割を実行しているサーバーをアップグレードしてから、メールボックス サーバーの役割を実行しているサーバーをアップグレードすることをお勧めします。この順にサーバーをアップグレードすることで、サービス中断の可能性を回避できます (この順で役割をアップグレードすると、メールボックスの機能に "依存している" サーバーがメールボックス サーバーと通信したときに、その通信が中断されることがなくなるので、より多くの機能が提供されるバックエンド サーバーと通信したときに問題が発生せずに済みます)。また、インターネットに直接接続しているサイト内のクライアント アクセス サーバーをアップグレードしてから、インターネットに接続していないサイト内のクライアント アクセス サーバーをアップグレードすることもお勧めします。
Exchange 組織内でエッジ トランスポート サーバーの役割を実行していて、エッジ サブスクリプションを作成した場合、EdgeSync プロセスに参加するすべてのトランスポート サーバーで同じバージョンの Exchange 2007 を実行している必要があります。エッジ サブスクリプション プロセスに参加する任意のトランスポート サーバーを初めて Exchange Server 2007 SP1 にアップグレードしてから 15 日以内に、エッジ トランスポート サーバーが購読する Active Directory® サイト内のすべての購読済みエッジ トランスポート サーバーとハブ トランスポート サーバーをアップグレードする必要があります」

質問 - Exchange 2007 RTM サーバーに ForefrontTM Security for Exchange Server をインストールしました。Exchange 2007 SP1 にアップグレードする前に、特別な作業を行う必要はありますか。
回答 - Forefront Security for Exchange Server RTM には、Exchange 2007 SP1 との互換性がありません。アップグレードを行う前に、Forefront Security for Exchange Server を削除するか、最新版にアップグレードする必要があります。詳細については、SP1 のリリース ノートを参照してください。
ちなみに、Exchange 2007 SP1 のセットアップでは、新しい前提条件の確認が実行され、このような状況でアップグレードを試みたときに、上記のことを示す警告が表示されます。

質問 - RTM のリリース後に公開された更新プログラムのロールアップ (RU) を Exchange 2007 RTM にインストールしました。Exchange 2007 SP1 を適用する前に、この RU を削除する必要はありますか。
回答 - Exchange 2007 SP1 をインストールする前に、あえて更新プログラムのロールアップを手動で削除する必要はありません。削除した方がよい更新プログラムは、Exchange 2007 SP1 のセットアップによって、SP1 がコンピュータに適用される前に削除されます。

Nino Bilic は、Exchange Server のサポータビリティ プログラム マネージャです。彼は、銀河を探索して巨万の富を手にし、大声を上げながら悪者を追い詰めています。Mass Effect というゲームの中での話ですが。


 ユーティリティ スポットライト: SharePoint の容量計画
ユーティリティ スポットライト
SharePoint の容量計画
Peter Skjøtt Larsen and Satish Mathew

大規模な Microsoft® Windows® SharePoint® Services (WSS) と Microsoft Office SharePoint Server (MOSS) のインストールを計画する場合、作業が複雑になることがあります。最もコスト効率のよいトポロジ、ハードウェア、および帯域幅を判断するには、さまざまな要因を考慮する必要があります。また、システムの用途に応じて、さまざまな構成オプションを検討する必要があります。多くの場合、管理者や計画者は、システムのサイズ決定に役立つ経験則程度しか持ち合わせていません。
さいわい、マイクロソフトから、次世代の Microsoft System Center Capacity Planner (SCCP) 2007 がリリースされました。これは、さまざまなアプリケーションのモデルと、特定の展開におけるアプリケーションの動作を予測できるシミュレータが統合された汎用的なツールです。今回のリリースでは、新しい SharePoint Capacity Planning Tool が導入され、WSS 3.0 と MOSS 2007 用の 2 つのモデルが、このエンジンに追加されました。
SharePoint Capacity Planning Tool と SCCP 2007 は、Microsoft ダウンロード センター (microsoft.com/systemcenter/sccp/default.mspx) から無償で入手できます。
SharePoint Capacity Planning Tool では、予想される用途と運用条件に関する質問の回答に基づいて、組織の要件を集約します。準備段階の設計を生成する際は、ウィザードを使用して、実装する構造と予想される SharePoint の要件に関する情報を入力します。これらの情報には、ユーザーの数と種類 (認証済みまたは匿名)、ネットワーク パラメータ、ハードウェアの構成、使用パターン (発行やグループ作業など)、ストレージ要件、インデックスとクエリの要件などがあります。
Results of a simulation in the SharePoint Capacity Planning Tool
Results of a simulation in the SharePoint Capacity Planning Tool
その後、構成に固有の名前が付けられた、基準となる推奨トポロジが生成されます。生成されたこのトポロジに対して負荷と使用状況のシミュレーションを実行し、提示されたインストールがさまざまな条件下でどのように動作するかを確認します。
この初期トポロジは、モデル エディタを使用して変更できます。また、さまざまな条件を想定したシナリオを実行することにより、使用量の増加、企業のブランチ オフィスの拡大、ハードウェアの追加、および帯域幅の拡大が発生した場合に、このトポロジが受ける影響のシミュレーションを実行できます。スクリーンショットが示しているように、このシミュレーションでは、予測されるサーバーの負荷とユーザー エクスペリエンスを報告するレポートが生成されます。この情報を使用し、コスト、パフォーマンス、使用できるハードウェアなどのパラメータに基づいて構成の最適化を開始できます。また、詳細レポートや概要レポートを Excel® ワークシートにエクスポートしたり、トポロジ ダイアグラムを Visio® ファイルにエクスポートしたりできます。
SharePoint Capacity Planning Tool を使用すると、さまざまな状況をテストして適切な初期構成を実装できるので、新規の展開時に発生する負担を軽減できます。また、既存のトポロジをモデル化し、さまざまな条件を想定したシナリオを実行できるので、既存の展開を変更した場合の影響を調査する際にも役立ちます。

Peter Skjøtt Larsen は、Microsoft Solution Accelerator チームのシニア プロダクト マネージャです。マイクロソフトに 4 年間勤務し、UNIX の移行、およびコミュニケーションとコラボレーションに関連する業務に携わってきました。
Satish Mathew は、Microsoft Solution Accelerator チームのプログラム マネージャです。マイクロソフトに約 5 年間勤務し、現在のチームに移る前は、Windows PowerShell チームに所属していました。


 SharePoint の内部: SharePoint インフラストラクチャを構築する
SharePoint の内部
SharePoint インフラストラクチャを構築する
Pav Cherny
この記事で使用しているコードのダウンロード: SharePoint2008_05.exe (412KB)

電子メール メッセージングによってビジネス コミュニケーションが変わったのと同様に、Web ベースのコラボレーションによって、共同作業や情報共有の方法も変化しています。その一例として、SharePoint テクノロジで提供されるものを見てみましょう。Microsoft Windows SharePoint Services (WSS) 3.0 と Microsoft Office SharePoint Server
(MOSS) 2007 を使用すると、チーム サイト、ポータル、Web コンテンツ管理ソリューション、ドキュメント ライブラリ、および検索センターを作成することができます。また、2007 Microsoft® Office system との統合、XML ベースのフォーム、ワークフロー、モビリティなどがサポートされているのは言うまでもありません。
しかし、SharePoint® の導入は必ずしも簡単とは限りません。用語がわかりにくかったり、システム アーキテクチャが複雑だったりすることがあります。また、SharePoint を使用する場合、IIS、Microsoft .NET Framework、SQL Server®、そして場合によっては他のテクノロジ (たとえば、ビジネス インテリジェンス、InfoPath® Forms Services、Rights Management Services (RMS)、Exchange Server、ForefrontTM Security) などの複数のコンポーネントを扱う必要があります。
SharePoint ソリューションを作成する方法は (組み込みのユーザー インターフェイスを使用して作成するにしろ、プログラムで作成するにしろ) たくさんあるので、統合やカスタマイズを行う際には、すぐに、どうすればよいかがわからなくなってしまう可能性があります。また、SharePoint アプリケーションが機能しない場合、トラブルシューティングは複雑なことがあります。多くの場合、構成要素を理解し、それらの要素がどのように連携するかを理解するには、アプリケーション開発者と同じような思考回路が必要です。このような課題がある中で、堅牢でスケーラブルで管理しやすい SharePoint インフラストラクチャを構築するには、どのような作業から着手すればよいのでしょうか。
このコラムでは、まずアーキテクチャの概要を説明して土台を築き、次に WSS の展開 (ブランド設定に関する非常に基本的なカスタマイズを含む) について説明して、どのように作業を開始すればよいかを示します。WSS 3.0 が提供する、Self-Service Site の管理機能を使用すると、SharePoint インフラストラクチャに対する管理者レベルの集中型制御を維持しながら、SharePoint サイトの作成と管理を行う権限を個々のユーザーに委任する方法がわかります。
最初に SharePoint アーキテクチャを説明することにより、柔軟でスケーラブルなインフラストラクチャを実装するのに必要な展開手順と構成手順が理解しやすくなります。では、まず依存関係を見てから、WSS 3.0 の展開について説明しましょう。展開に関する詳細な指示については、付属リソースを参照してください。このリソースは、TechNet Magazine Web サイト (technetmagazine.com) のダウンロード セクションで提供しています。

SharePoint アーキテクチャ
SharePoint テクノロジに関しては、システム アーキテクトの視点から考えるのが有効です。具体的な全詳細を知る必要はありませんが、SharePoint アーキテクチャに起因する全般的な依存関係を理解しておくと、何を構成する必要があり、その理由は何であるかをより早く予測することができるので、より早く解決策を導き出すことができます。
SharePoint は、Web アプリケーションと Web サイトを提供するテクノロジです。SharePoint は IIS ベースの Web サイト ソリューションで、ASP.NET を使用して IIS と統合され、バックエンドでは構成データとコンテンツの格納に SQL Server データベースが使用されます。つまり、SharePoint の中核は、3 つの異なるアーキテクチャ (IIS、.NET、および SQL Server) を組み合わせたものです (図 1 参照)。
Figure 1 WSS 3.0 architecture based on IIS 6.0 and ASP.NET 3.0
Figure 1 WSS 3.0 architecture based on IIS 6.0 and ASP.NET 3.0
この図を見て及び腰にならないでください。構成要素の数だけを考えると、アーキテクチャは手に負えないものに見えるかもしれません。しかし、これらの構成要素はすべて、論理的なフレームワークに収まっているので、このフレームワークを体系的に観察すると、構成要素の依存関係を理解することができます。
この図が示しているように、SharePoint では、IIS と ASP.NET を使用して HTTP 要求と HTTP 応答を処理します。つまり、要求が ASP.NET ISAPI フィルタ (aspnet_isapi.dll) に着信するまでは、HTTP カーネル モード ドライバ (http.sys) やワーカー プロセス (w3wp.exe) などの標準的な IIS コンポーネントによって、要求のキューへの格納や要求の転送が行われます。.NET Framework をインストールすると、セットアップ処理の一環として、次のように aspnet_isapi.dll が IIS メタベース (C:\Windows\System32\Inetsrv\metabase.xml) に登録されます。
InProcessIsapiApps="C:\WINDOWS\system32\inetsrv\httpext.dll
C:\WINDOWS\system32\inetsrv\httpodbc.dll
C:\WINDOWS\system32\inetsrv\ssinc.dll
C:\WINDOWS\system32\msw3prt.dll
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll"
IIS で ASP.NET ISAPI フィルタが読み込まれると、Web サイトに着信する要求はすべて ASP.NET に渡すことができます。SharePoint では、どこかの時点で ASP.NET を使用してこのような要求を受信する必要があるので、これは重要です。これを実現するために、SharePoint は、ワイルドカード アプリケーション マップを追加して、特定の Web サイトの構成を拡張します。ワイルドカード アプリケーション マップを使用すると、ファイル名拡張子にかかわらず、すべての着信要求が ASP.NET ISAPI フィルタに転送されます。
ワイルドカード アプリケーション マップは、基本インストール オプションを使用して WSS 3.0 をインストールすると IIS マネージャで確認できます。WSS のセットアップ処理の一環として、サーバー上に既に存在する既定の IIS Web サイトが非アクティブになり、ASP.NET ワイルドカード アプリケーション マップが定義されている (図 2 参照) 新しい既定の Web サイトがポート 80 に作成されます。
Figure 2 Wildcard application map for ASP.NET ISAPI filter
Figure 2 Wildcard application map for ASP.NET ISAPI filter
ASP.NET から SharePoint に要求を渡すには、SharePoint はカスタムの HttpApplication オブジェクトによって HTTP 要求パイプラインも拡張する必要があります。このオブジェクトは、Microsoft.SharePoint アセンブリの SPHttpApplication というクラスによって実装されます。このカスタム アプリケーション オブジェクトは、ASP.NET アプリケーション ファイル (global.asax) に定義されます。このファイルは、SharePoint で拡張された Web サイトのルート フォルダのファイル システム内にあります。次のコードは、このような global.asax ファイルの内容を示したものです。
<%@ Assembly Name="Microsoft.SharePoint"%>
<%@ Application Language="C#" Inherits="Microsoft.SharePoint.ApplicationRuntime.SPHttpApplication" %>
このファイルは ASP.NET によって動的に解析およびコンパイルされ、SharePoint アプリケーション オブジェクトのインスタンスが作成されます。
受信した要求ごとに、BeginRequest、AuthenticateRequest、ProcessRequest、EndRequest など、Web アプリケーションが処理できる一連のイベントがトリガされます。イベント処理の詳細は SharePoint の展開と管理という範囲を超えていますが、global.asax で SPHttpApplication クラスが指定されるだけでなく、SharePoint ではサイトの web.config ファイルで定義されたカスタムの HTTP ハンドラと HTTP モジュールを実装する、ということを知っておくことは重要です。たとえば、SharePoint では、SPRequestModule クラスに基づいた HTTP モジュールを使用します。このモジュールは、標準的な ASP.NET モジュールよりも前に最初の HTTP モジュールとして登録されます。SPRequestModule クラスでは、ASP.NET で SPVirtualPathProvider コンポーネントを登録することなどによって、SharePoint のランタイム環境を初期化します。SPRequestModule は SharePoint 内部で使用するクラスですが、SharePoint ソリューション開発者は、web.config ファイルを変更して、カスタムの HTTP ハンドラと HTTP モジュールなどの追加コンポーネントを登録することができます。SharePoint では、カスタムの HTTP モジュールと標準的な HTTP モジュールの両方を使用して、SharePoint アプリケーションへのすべての要求に対する厳格な制御を維持しながら ASP.NET を利用します。
SharePoint 3.0 サーバーの全体管理サイトを使用して Web アプリケーションを作成すると、特定の IIS Web サイトに ASP.NET ワイルドカード アプリケーション マップが追加され、global.asax ファイルと web.config ファイルが Web サイトのルート フォルダに作成されます。各 Web アプリケーションには、そのアプリケーションのルート フォルダにある専用の global.asax ファイルと web.config ファイルを使用します。
要求を処理して意味のある情報をブラウザに返すために、WSS 3.0 と MOSS 2007 では、標準的な ASP.NET ページ パーサーを使用します。このパーサーは、要求された ASP.NET ページをコンパイルするか、コンパイルを行わないモードで処理します。しかし、SharePoint から ASP.NET パーサーに渡される ASP.NET ページは、必ずしも想定される場所にあるとは限りません。たとえば、SharePoint で拡張された Web サイト (SharePoint 3.0 サーバーの全体管理サイトなど) のルート フォルダには default.aspx ファイルは存在しませんが、Web サイトのホーム ページを表示する際に開かれるのは default.aspx です。ページのコンテンツをローカル ファイル システムまたは SQL Server コンテンツ データベースから読み込んで仮想ファイルとして ASP.NET ページ パーサーに渡し、環境を仮想化するのは、SPVirtualPathProvider コンポーネントです。サーバーの全体管理サイトを表示する際、SharePoint では C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\TEMPLATE\SiteTemplates\CentralAdmin フォルダにある default.aspx ファイルを読み込んでいます。
ホーム ページと他のほとんどの SharePoint サイト ページは、メニューとナビゲーション コントロールの共通レイアウトが実装されている ASP.NET マスタ ページ (default.master) にリンクされています。default.master ページは C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\Template\Global フォルダ内にあります。このページには、ローカル ファイル システムまたは SQL Server コンテンツ データベースにも登録できる追加のコンテンツ ページに使用できる名前の付いたプレースホルダが含まれています。重要なのは、Web ブラウザで SharePoint サイトを開くと、一連のコンテンツ ページから取得した情報が表示され、これらのページは必ずしもローカル Web サーバー上に存在するとは限らず、マスタ ページで定義されたレイアウトに従って並んでいる、ということです。
原則として、変更されていないページ (SharePoint 用語では、カスタマイズされていないページ) はページ テンプレートとしてすべての SharePoint サーバーのローカル ファイル システムに存在しますが、カスタマイズされたページは、Web ファーム内のすべての SharePoint サーバーが同じ一連のページにアクセスできるように、コンテンツ データベースに書き込まれます (図 3 参照)。カスタマイズされていないページは、Web ファーム内のすべてのサーバーとサイトで同じであることが想定されています。しかし、Office SharePoint Designer 2007 などを使用して、SharePoint サイトのコンテンツ ページやマスタ ページをカスタマイズすると、カスタマイズされたページは自動的にコンテンツ データベースに格納されます。
Figure 3 Uncustomized and customized ASP.NET pages in a SharePoint application
Figure 3 Uncustomized and customized ASP.NET pages in a SharePoint application
カスタマイズされたページや他の Web サイト コンテンツだけでなく、構成データも SQL Server データベースに格納されます。構成データは本質的にグローバルで、コンテンツは個々の Web アプリケーションやサイト コレクションに固有のものであるので、構成データはコンテンツとは別個に格納されます。したがって、1 つの Web ファームに用意できる構成データベースは 1 つだけですが、コンテンツ データベースは複数用意することができます。
Web ファーム内のすべての WSS サーバーでは、同じ構成データベースを使用して、メタデータ、構成設定、および Web ファーム内の SharePoint で拡張されたすべての IIS Web サイトに関する情報を共有します。一方、個々の Web アプリケーションは、1 つまたは複数のコンテンツ データベースと関連付けることができます (ただし、各コンテンツ データベースは 1 つの Web アプリケーションとしか関連付けることができません)。
IIS Web サイト、Web アプリケーション、サイト コレクション、サイト、およびコンテンツ データベースの関係は、わかりにくいことがあります。SharePoint 用語では、SharePoint で拡張された IIS Web サイトを Web アプリケーションと呼びます。Web アプリケーションには複数のサイト コレクションを含めることが可能で、各サイト コレクションには同じ構成設定を共有するトップレベル サイトとサブレベル サイトを含めることができます。
特に重要なのは、複数のサイト コレクションを作成すると、サイト コレクションの管理をさまざまなユーザーやグループに委任できるということです。1 つのサイト コレクションで複数のコンテンツ データベースを使用することはできませんが、複数のサイト コレクションがある場合、Web アプリケーションでは複数のコンテンツ データベースを使用することで、スケーラビリティを向上させ、他の SharePoint サイトで大量のデータベース処理を発生させる大規模なサイトが与えるパフォーマンス上の影響を軽減することができます。ただし、すべての SharePoint サイトを独自のサイト コレクションに配置すると、クロスサイト機能が制限されるので、このような展開はお勧めしません。
WSS 3.0 では、複数のサイト コレクションを対象としたコンテンツ検索はサポートされていません。このような検索を行うには、MOSS 2007 または Microsoft Search Server 2008 を使用する必要があります。たとえば、ファーム管理者は http://contoso 用の Web アプリケーションとトップレベル サイトを作成することができます。その後、サイト コレクション管理者は、SharePoint ユーザー インターフェイスを使用して、http://contoso/info、http://contoso/events などのサブレベル サイトを作成することができます。これらのサイトはすべて、同じサイト コレクションに属するので、同じコンテンツ データベースに格納されます。
ファーム管理者は、/sites などの管理パスを使用して、追加のサイト コレクション (http://contoso/sites/IT、http://contoso/sites/HR など) を SharePoint 3.0 サーバーの全体管理で定義することもできます。この 3 つのサイト コレクション (http://contoso、http://contoso/sites/IT、および http://contoso/sites/HR) には、異なるサイト コレクション管理者、構成設定、およびコンテンツ データベースを採用することができますが、3 つとも同じ IIS Web サイト (http://contoso) を通じてアクセスされ、Web アプリケーションのアプリケーション プール ID も同じものを使用します。
もちろん、詳細は他にもいろいろありますが、SharePoint に慣れるには、この IIS、ASP.NET、および SQL Server の関係を理解することが特に重要です。SharePoint アーキテクチャの詳細については、Ted Pattison が執筆した MSDN® Magazine の記事「SharePoint Services における開発作業の大幅な強化について」(msdn.microsoft.com/msdnmag/issues/06/07/WSS30Preview) を参照することをお勧めします。

SharePoint インフラストラクチャの構成要素
では、アーキテクチャについての簡単な説明から、柔軟な SharePoint インフラストラクチャについての説明に移りましょう。既にお気付きのことと思いますが、必要なのは、Windows Server®、IIS、.NET Framework 3.0 (ASP.NET と Windows® Workflow Foundation が必要なため)、WSS 3.0 と MOSS 2007 のどちらか、および SQL Server です。Windows Server 2008 で IIS 7.0 を使用することを期待していらっしゃるかもしれませんが、ここでは、この記事を執筆している時点で最もよく展開されているバージョンである Windows Server 2003 と IIS 6.0 を使用します。また、初めて SharePoint のパイロット展開を行う際には MOSS 2007 固有の機能は必要ないので、引き続き WSS 3.0 を使用します。
必要最低限の機能を実現するには、WSS 3.0 と必要なすべてのコンポーネントを 1 台のコンピュータにインストールします (このコラムの付属リソースに含まれている WSS 3.0 on a single computer.pdf 参照)。ラボ サーバーや小規模なワークグループ環境の場合は、これで十分です。しかし、柔軟な SharePoint インフラストラクチャが必要な場合、運用環境ではスタンドアロンの展開を使用しないことをお勧めします。可用性と将来のスケーラビリティを確保するには、多層インフラストラクチャを導入して、必要に応じてサーバーを追加することをお勧めします。
図 4 は、簡単で柔軟なシステム構成が必要な方にお勧めの SharePoint インフラストラクチャを示しています。このインフラストラクチャには、2 台の SharePoint サーバーで構成される Web ファームと、SQL Server を実行している別の 1 台のコンピュータが含まれています。この構成を使用すると、Web サーバーのデータベース処理オーバーヘッドが解消され、可用性とスケーラビリティが向上し、システムのメンテナンスが容易になります。Active Directory® が必要なことに注意してください。Active Directory は、WSS 3.0 を Web ファームで展開する場合のソフトウェア要件です。展開に関する一連の手順については、付属リソースに含まれている Basic SharePoint Infrastructure.pdf ファイルを参照してください。
Figure 4 Basic SharePoint infrastructure that can accommodate future growth
Figure 4 Basic SharePoint infrastructure that can accommodate future growth
SharePoint をこのような形で展開するのに使用するドメイン アカウントは、Web サーバーのローカル管理者の権限を持っている必要があります。また、このアカウントを SQL Server ロールの dbcreator と securityadmin に追加し、SQL Server 2005 の master データベースのデータベース ロール db_owner にも追加する必要があります (Basic SharePoint Infrastructure.pdf 参照)。その後、WSS 3.0 のインストール中に SharePoint 製品とテクノロジ構成ウィザードを使用して、Web サーバー ファームに必要な構成データベースと SharePoint 3.0 サーバーの全体管理サイト用のコンテンツ データベースを作成することができます。これらのデータベースをインストール時に作成しなかった場合は、SQL Server 管理者がこれらのデータベースを用意して WSS システム アカウントを db_owner ロールに追加する必要があります。
SharePoint をインストールする際に使用するユーザー アカウントは、SharePoint がサーバーの全体管理サイトの構成データベースやコンテンツ データベースにアクセスする際に使用するアカウントではないということを覚えておいてください。SharePoint がデータベースへのアクセス時に使用するのは、SharePoint 3.0 サーバーの全体管理サイトのアプリケーション プール ID として構成されたシステム アカウントです。
SharePoint 製品とテクノロジ構成ウィザードでは、アカウント情報の入力を求められます。CONTOSO\WssConfigAdmin など、専用のドメイン ユーザー アカウントを使用することをお勧めします。私は通常、後から追加で作成した Web アプリケーションごとに、別個の専用ユーザー アカウントを使用するようにしています。Web アプリケーションごとに別個のアプリケーション プールを使用することはプロセスを確実に分離するのに役立ち、アプリケーション プールごとに異なるユーザー アカウントを使用することはセキュリティの分離を維持するのに役立ちます。ただし、これは 1 つのやり方にすぎず、管理のしやすさと潜在的なパフォーマンス上の影響は、各自の環境要件やビジネス要件に基づいて評価する必要があることに注意してください。
ドメイン管理者が作成する必要があるもう 1 つの重要なシステム アカウントは、Search サービス アカウントです。サーバーの全体管理のアカウントを使用することもできますが、セキュリティを強化するには、管理者権限を持っておらずコンテンツを変更できない専用の Search サービス アカウント (CONTOSO\WssSearch など) を使用することをお勧めします。Search サービスはインデックスを作成するためにコンテンツをクロールしますが、検索データを別のデータベースに保存するので、コンテンツ データベースへの書き込み権限は必要ありません。
サーバー ファームで Web アプリケーションを作成する場合は、このコンテンツ データベースを検索サーバーと関連付けることができます。関連付けを行うと、検索サーバーによって、対応する Search サービス アカウントが Web アプリケーションの "すべて読み取り" ポリシーに暗黙的に追加されます。検索サーバーは、Windows SharePoint Services Search サービスを実行している SharePoint サーバーです。Basic SharePoint Infrastructure.pdf ファイルに記載されている一連の手順を実行すると、両方の Web サーバーが検索サーバーとして構成されるので、複数のコンテンツ データベースのクロールとインデックス作成による負荷を分散させることができます。ただし、クライアント接続がクロール処理の影響を受けないように、ネットワーク負荷分散やクライアント接続に使用しない Web ファームで専用の検索サーバーを構成することも可能です。

Self-Service Site の管理
基本的な SharePoint インフラストラクチャを使用すると、Active Directory、Web サーバー ファーム、または SQL Server データベースに対する管理者レベルの制御を分散させることなく、サイト コレクションやサイトの管理を個々の部門や個々のユーザーに委任できます。ファーム管理者は、Active Directory の管理者と SQL Server の管理者と協力して、Web アプリケーションで使用するアプリケーション プール アカウントやコンテンツ データベースを用意します。その後、このような Web アプリケーション内で、サイト コレクションを作成したり、サブレベル サイトを作成する権限を持ったサイト コレクション管理者を指定したりします。これにより、各部門のサイト コレクション管理者は、IT 部門の関与を最小限にとどめて SharePoint リソースを管理することができます (図 5 参照)。
Figure 5 Decentralized site administration in a centralized SharePoint infrastructure
Figure 5 Decentralized site administration in a centralized SharePoint infrastructure
また、ユーザーが管理パス (/sites というパスや、SharePoint 3.0 サーバーの全体管理で作成できる、ワイルドカードが含まれた管理パスなど) の下にサイト コレクションを作成できるようにすることもできます。Web アプリケーションで Self-Service Site の管理機能を有効にすると、ユーザーは、独自のサイト コレクションを作成したり、SharePoint ユーザー インターフェイスを使用してサイト グループや権限を管理したりすることができます。サブレベル サイトとは異なり、サイト コレクションは権限を親サイトから継承しません。
Self-Service Site の管理は、すべての SharePoint 環境に適しているわけではないので、既定では無効になっています。この機能を有効にすると、コンテンツ データベース内に、ほとんど使用しないサイト コレクションがたくさん作成されてしまう可能性があります。しかし、この機能を使用すると SharePoint の管理の柔軟性を鮮明に体感できるので、パイロット展開で試してみることをお勧めします (また、SharePoint には、非アクティブなサイトを必要に応じて削除できるように、非アクティブなサイトをユーザーと管理者の両方またはどちらか一方に通知するオプションがあります)。付属リソースに含まれている Enabling Self-Service Site Management.pdf ファイルで説明されているように、Web アプリケーションで Self-Service Site の管理機能を使用するには、明示的に有効にする必要があります。

SharePoint のカスタマイズとブランド設定
SharePoint の関連リソース
  • Windows SharePoint Services TechCenter
  • Windows SharePoint Services デベロッパー センター
  • Microsoft SharePoint 製品とテクノロジ チームのブログ
  • 論理アーキテクチャの構成要素
  • サーバー ファームとトポロジを設計する

この段階に至ると、企業のロゴ、企業名、および企業のイメージ カラーを SharePoint ユーザー インターフェイスに含めたくなるのは自然なことです。しかし、それは ASP.NET 開発者レベルの作業であることに注意してください。運用環境に影響を与えることなくカスタマイズを行い、その結果をテストできるようにするには、少なくとも、Microsoft Office SharePoint Designer 2007 がインストールされたスタンドアロンの WSS 3.0 サーバーなどの開発システムが必要です (付属リソースに含まれている SharePoint Designer Installation.pdf 参照)。また、Windows SharePoint Services デベロッパー センター (msdn2.microsoft.com/sharepoint) にアクセスして、SharePoint に用意されている豊富なカスタマイズ オプションについて学習する必要があります。
SharePoint 開発はこのコラムの対象範囲外ですが、考慮する必要がある点をいくつか挙げておきます。SharePoint では、カスタマイズされたページは対応するサイト コレクションのコンテンツ データベースに格納されます。つまり、SharePoint サイトのサイト ページ、アプリケーション ページ、マスタ ページ、スタイル シートなどに適用したカスタマイズは、サイト コレクション レベルまたはサイト レベルでしか適用されません。これは、SharePoint Designer 2007 を使用してサイトの外観を調整する個々のサイト コレクション管理者にとっては好都合ですが、Web ファーム内のすべての Web アプリケーション、サイト コレクション、およびサイトに企業独自の要素を適用する必要があるファーム管理者にとってはあまり好都合ではありません。
標準的な SharePoint テーマやサイト定義のコピーを基にして、カスタムのサイト テーマやカスタムのサイト定義を作成することができます。カスタムのマスタ ページを作成して、それをマスタ ページ ギャラリーに追加することもできます。ただし、Self-Service Site の管理が有効になっていると、サイト コレクションやサイトを作成する権限を持ったユーザーは、企業独自の要素が含まれていない標準的なサイト テンプレートを選択することができるので、これらの方法を使用しても Web ファーム全体でのブランド設定は実現されません。
Web ファーム全体でのブランド設定を実現するには、既定の SharePoint コンポーネントをカスタム コンポーネントに置き換えて、カスタム コンポーネントが既定のコンポーネントとして使用されるようにする必要があります。元のファイルを変更することなくこれを実現するためなら、開発者はどんな苦労も惜しみません。1 つの方法は、IIS マネージャの仮想ディレクトリの構成を変更して、カスタマイズされたファイルが格納されている新しいフォルダを参照するようにすることです。もう 1 つの方法は、特定の既定ページに対する要求をカスタマイズされたバージョンにリダイレクトするように URL を書き換えるカスタムの HTTP モジュールまたは ISAPI フィルタを実装することです。

まとめ
この記事では、WSS 3.0 を使用して SharePoint インフラストラクチャを構築する方法の要点を説明しました。これに関連しない機能 (ワークフロー、アンケート、メッセージングの統合、ウイルス対策など) や MOSS 2007 固有の機能 (ポータル、サイト ディレクトリ、ビジネス データ カタログなど) は取り上げませんでした。また、サイト管理や企業のブランド設定に関するカスタマイズについて説明しましたが、これは SharePoint が秘めている潜在能力の一端を紹介したにすぎません。Visual Studio® でカスタム アプリケーションを作成すると、WSS 3.0 をさらにカスタマイズすることができます。
SharePoint は堅牢なインフラストラクチャを備えているので、後から Web サーバーやデータベース サーバーを追加して、拡張することができます。また、少しカスタマイズしたパイロット版を展開すると、ユーザーは個々のサイトを作成することができ、一般に SharePoint について理解することができます。このようにして、ハードウェアやソフトウェアだけでなく、この重要なコンポーネントをユーザーに定着させることができます。また、パイロット展開は、変化に適応する柔軟性を備え、運用環境への本格的な展開を行うための基盤としての役割を果たします。

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


 Windows PowerShell: ディレクトリの管理を自動化する
Windows PowerShell
ディレクトリの管理を自動化する
Don Jones

Windows PowerShell の最初のバージョンに関して最も残念なことの 1 つは、リリースのタイミングです。Windows PowerShell チームは、製品を出荷しなければならないという一定のプレッシャーを常に感じていました (Exchange Server 2007 というちょっとした製品の発売があり、この製品が Windows PowerShell に依存していたからです)。
また、Active Directory チームは、当時多くの仕事を抱えていました (Windows Server® 2008 というもう 1 つのちょっとした製品の開発も進行中だったからです)。このため、Windows PowerShell は、Active Directory® を管理する機能の完成度が低い状態でリリースされました。
確かに、Windows PowerShell® で Active Directory の機能がまったく提供されていないわけではありません。実際 Windows PowerShell チームは、土壇場で、VBScript のユーザーに既によく知られている、スクリプトに適したテクノロジである Active Directory Services Interface (ADSI) を適切にサポートするというすばらしい仕事を成し遂げました。

ADSI の特徴
ADSI の動作は、Windows® Management Instrumentation (WMI) に似ており、特別な構文を使用して記述されたクエリを発行します。このクエリは、リモート コンピュータ (ドメイン コントローラなど) に転送されてから、実行されます。クエリを実行すると、Active Directory オブジェクトまたはオブジェクトのコレクション (ユーザーやグループなど) が作成され、そのオブジェクトへの参照が返されます。これにより、そのオブジェクトを操作できるようになります。オブジェクトのプロパティを変更したり、メソッドを実行して、変更の保存、新しいオブジェクトの作成、オブジェクトの削除などを実行したりできます。たとえば、ユーザーを作成するには、そのユーザーの作成先となる組織単位 (OU) またはコンテナに対してクエリを実行します。返されるオブジェクトには Create メソッドが含まれているので、このメソッドを使用してユーザーを作成できます。
非常に基本的なレベルでは、Windows PowerShell で ADSI を使用することは簡単であると思われます。たとえば、次のコマンドでは、ユーザーを取得し、そのユーザーの Company 属性を表示しています。
$user = [ADSI]"LDAP://cn=Ringo,ou=Singers,dc=company,dc=pri"
$user.Get("Company")
このユーザーを Get-Member に渡して、そのプロパティとメソッドを表示できます。残念ながら、これらのディレクトリ オブジェクトの実装に関して、Windows PowerShell 1.0 はあまり良い仕事をしているとは言えません。このシェルでは、オブジェクトのディレクトリ属性は列挙されず、オブジェクトのメソッド (私が使用した Get メソッドなど) も表示されません (図 1 参照)。
Figure 1 Piping the user to Get-Member to see its properties
Figure 1 Piping the user to Get-Member to see its properties
このサポートは Windows PowerShell 2.0 の Community Technology Preview (CTP) で若干強化されましたが、その程度は限られています。つまり、Microsoft® .NET Framework が基盤として使用されているので、管理者が目的の操作を行うことが難しくなっています。そもそも .NET Framework は、開発者用に設計された動作環境です。その他の問題として挙げられるのは、Windows PowerShell チームができることは限られており、優れた Active Directory のサポートを提供するにはディレクトリに詳しい人の手を借りる必要があるということです。ディレクトリに詳しい人とは、つまり Active Directory チームのことです。これはそのうち実現されると思いますが、結局のところ、Windows PowerShell はまだ成熟段階に達していません。では、当面はどうすればよいでしょうか。
2007 年 6 月号のこのコラム (technetmagazine.com/issues/2007/06/PowerShell) で説明した、Windows PowerShell に含まれている ADSI テクノロジのことを思い出してください。この "ネイティブ" の手法の詳細については、コラムを参照してください。今回は、その他のいくつかの方法を紹介します。

優れたエコシステム
Windows PowerShell のアーキテクトである Jeffrey Snover は、Windows PowerShell を取り巻く優れたエコシステムについてよく言及しています。これは、Windows PowerShell チームがすばらしい仕事を成し遂げた結果、マイクロソフト内のプログラマだけでなく、だれでも Windows PowerShell の機能を拡張できるようになったことを意味しています。多くの企業は、コマンド ラインから自社の製品を管理できるネイティブの Windows PowerShell コマンドレットを作成することにより、既にこの作業を行っています。たとえば、VMWare、IBM、Citrix、Foundry などの主要企業が挙げられます。
私が気に入っているこの優れたエコシステムの 1 つは、Quest のソフトウェアです。この企業は、Active Directory を管理するために設計された、一連の無償のコマンドレットを提供しています。これらのコマンドレットは、quest.com/powershell からダウンロードできます。Quest では、グラフィカルな UI を使用して Windows PowerShell を操作できる PowerGUI (powergui.org) も提供しています。このソフトウェアは、コマンド ラインをまだ完全に使いこなすことができない人を対象としており、無償で利用できます。PowerGUI を使用すると、Active Directory を管理するコマンドレットの使用方法をより簡単に学習できます。本当にこのツールは役立ちます。これらのコマンドレットにより、かつてないほど簡単で強力な Active Directory の管理が提供されます (PowerGUI の詳細については、technetmagazine.com/issues/2008/01/Toolbox で公開されている、2008 年 1 月号の「ツールボックス」コラムを参照してください)。

Windows PowerShell の特徴
コマンドレットに関するすべての要素は、Windows PowerShell に固有のものです。従来のようなスクリプトや特別なプログラミング オブジェクトを扱う必要はありません。ここで、私が世界で一番気に入っている 1 行のコマンド ラインを紹介します。このコマンド ラインでは、CSV ファイルをインポートし、そのファイル内の情報を使用して、何十個または何百個もの新しい Active Directory ユーザーを作成できます。
Import-CSV 'C:\provision1.csv' |
ForEach-Object {New-QADUser -organizationalUnit 'company.pri/Singers' -name ($_.'First Name' + '.' + $_.'Last Name')
-samAccountName $_.'Logon name' -city $_.city -title $_.'Job title' -department $_.department}
これは実に長いコマンドですが、非常に強力です。まず、シェルのネイティブ コマンドレットである Import-CSV を使用し、単純に CSV ファイルを読み取ってオブジェクトを返します。CSV ファイル内の各行は 1 つのオブジェクト、各列はそのオブジェクトのプロパティとして処理されます。私が作成した Provision1.csv ファイルでは、"Logon Name" や "First Name" などの列名が使用されています。興味深いことですが、これらの列名は Active Directory ユーザーの属性には直接マップされません。このようなファイルでは、Active Directory に固有の名前ではなく、今挙げたような聞き覚えのある列名を使用することが一般的です。このファイルを作成する人事部などの社員は、姓を表す Active Directory の属性が sn であることは知らないと思います。
CSV ファイル内のすべてのデータがインポートされ、オブジェクトに変換された後、これらのオブジェクトが ForEach-Object コマンドレットに渡されます。次に、コマンド ライン内のかっこで囲まれた部分のコードが各オブジェクトに対して実行されます。つまり、CSV ファイル内の各行に対して、このコードが 1 回実行されます。このコード内では、特殊な $_ 変数によって、現在のオブジェクト、つまり CSV ファイルの現在の行が参照されます。
ご覧のとおり、各オブジェクトに対して実行しているコマンドレットは、New-QADUser です。これは、Quest のアドインによって提供される数十個のコマンドレットのうちの 1 つです。QADUser という名前に注目してください。既におわかりかもしれませんが、Q は Quest を表しています。このような名前付け規則を適用した目的は、マイクロソフトの Active Directory チームが今後作成すると思われる New-ADUser コマンドレットとの競合を回避するためです。これにより、両方のコマンドレットが同時にシェルに読み込まれたとしても、人もシェルもこれらのコマンドレットを簡単に区別できるようになります。
コマンド ラインの残りの部分は、New-QADUser コマンドレットのパラメータで構成されます。まず、すべての新規ユーザーの作成先である organizationalUnit を指定しています。次は name 属性です。[First Name] 列の内容、ピリオド、[Last Name] 列の内容の順に指定しています。
最後にもう 1 つ興味深い事実を紹介します。city パラメータによって、Active Directory の l 属性 (つまり Locality-Name) が実際に変更されます。このコマンドレットには、l というパラメータを指定してもかまいません。ほとんどの場合、Active Directory の属性を参照するパラメータでは、Active Directory ユーザーとコンピュータ ツールで使用されている属性名やテキスト ラベルを使用できます。

その他の Windows PowerShell の特徴
Active Directory は階層的なストアです。Windows PowerShell の強みの 1 つは、任意の階層的なストアをディスク ドライブとして公開できることです。これによって、Dir、Del、Ren、Copy などの馴染みのあるコマンドを使用して、さまざまなストアを管理できるようになります。残念ながら、Windows PowerShell 1.0 には Active Directory 用の PSDrive プロバイダは含まれていません。つまり、このシェルでは Active Directory 自体をドライブとして公開することはできません。
さいわい、PowerShell Community Extensions を使用することで、優れたエコシステムが提供されるようになります。PowerShell Community Extensions は無償のオープンソース アドインであり、codeplex.com/powershellcx から入手できます。この拡張機能をインストールすると、シェルでドメイン名を指定して、ディレクトリがドライブであるかのように、ディレクトリを管理できるようになります。
CD COMPANY:
CD SINGERS
DIR
上記のコマンドでは、現在のディレクトリを COMPANY ドメインに変更し、Singers OU に変更した後、オブジェクトの一覧を表示しています (図 2 参照)。この後、Del コマンドを使用してユーザーを削除したり、Md コマンドを使用して新しい OU を作成したりできます。Community Extensions の PSDrive プロバイダには、いくつかの弱点があります。これらの弱点が原因で、実装されることが期待された機能が実質的には提供されません。この理由は、さまざまな要素が Active Directory 自体の動作にマップされないからです。また、十分に注意していただきたいのですが、現在のディレクトリをドメインのルートに変更して del * -recurse を実行すると、権限が与えられていれば、ドメイン内のすべてのオブジェクトが削除されます。既定では、削除するかどうかを確認するメッセージも表示されません。コマンド ラインは強力ですが、その強力さゆえに、スキルと慎重さに欠けるユーザーにとってはリスクがあります。
Figure 2 Using the PowerShell Community Extensions to direct the shell and manage the directory
Figure 2 Using the PowerShell Community Extensions to direct the shell and manage the directory

今すぐ Windows PowerShell を使用しましょう
私はいつも生徒から、現在 Windows PowerShell でどのような操作を行うことができるかを尋ねられます。結局のところ、すべてのマイクロソフト製品が Windows PowerShell を使用するように再設計されたわけではないので、まだ周りが Windows PowerShell の盛り上がりについてきていないのではないかと思われるかもしれません。
実際は、周りも既に盛り上がっています。マイクロソフトはまだコマンド ラインで管理できるように Active Directory を整備できていませんが、他の企業がそれに挑戦し、非常に大きな成果を挙げています。Windows PowerShell を使用すると、多くの管理作業を行うことができます。たとえば、大量の新規ユーザーの作成など、非常に手間のかかる面倒ないくつかの作業を自動化できます。効率化のヒントは、コミュニティが Windows PowerShell の利便性を向上させるために提供しているツールを入手することです (私も運営に携わっている、マイクロソフトとの共同サイトである PowerShellCommunity.org を参照してください)。適切なツールを Windows PowerShell に読み込むことによって、非常に手間のかかるいくつかの管理作業をスクリプト化し、より効果的および効率的な管理を実現できるようになります。

Don Jones は『Windows PowerShell: TFM, 2nd Edition』の共著者であり、『VBScript, WMI, and ADSI Unleashed』の著者です。また、PowerShellCommunity.org の責任者でもあります。


 Hey, Scripting Guy!: 正規表現に眉をひそめる
Hey, Scripting Guy!
正規表現に眉をひそめる
The Microsoft Scripting Guys
この記事で使用しているコードのダウンロード: HeyScriptingGuy2008_05.exe (150KB)

2007 年 11 月 、Scripting Guys はバルセロナで開催された Tech·Ed IT フォーラム カンファレンスに向かう途中、パリで 1 日を過ごすことになりました。この日、私たちはここぞとばかりに、この町の世界的に有名な美術館である、ルーブル美術館を訪れました。
Scripting Guys がルーブルにどう行ったか、ですか。簡単ですよ。ノートルダム寺院まで歩いていって、左に曲がりました。
ああ、すみません。聞き違えました。ルーブルに対してどういった印象を持ったか、ですね。ほとんどの部分については、おもしろいと思いました。唯一問題だったのは、ルーブルが多くの美術館と同様、"お手を触れずにご覧ください" 主義で運営されていたことです。モナリザに眉があったらずっとすてきに見えることはだれでも知っています。しかし、少しでも絵に手を加えようとすると、どういうわけかルーブルの管理者は激怒するのです。
注 : 実のところ、美術館に行った 2 人の Scripting Guys はモナリザが気に入りました。これはうれしい驚きでした。あれほど派手に宣伝され、売り込まれていたので、平凡な絵ではないかと心配していましたから。しかし平凡ではなく、とてもすばらしい絵でした (眉があればもっとよかったのですが)。しかし、興味深いことに、同じくらい派手に宣伝されていたミロのビーナスを見て、私たち 2 人はがっかりしました。2 人とも、この作品がそれほど見事だとは思いませんでした。また、このコラムを執筆している Scripting Guy は、ミロのビーナスの趣旨そのものに困惑しました。「腕のない女性の像だって。一体どうやって床をモップで掃除したり、皿を洗ったりするのだろう」と。
女性読者の皆さん (まだいるとして) への注 : 明らかに今の表現はタイプミスでした。本当は次のように言うつもりだったのです。「腕のない女性の像だって。それなのに男性の 2 倍の仕事をこなすことができて、おまけにその仕事の内容も正確ときたか」
最初の発言が招いた誤解について、お詫び申し上げます。
とにかく、ルーブルのすばらしい財産を目にしたとき、2 人の Scripting Guys はまったく同じことを考えました。それは、トイレはどこにあるのかということです。トイレを探している間、このコラムを執筆している Scripting Guy は別のことが頭に浮かびました。Scripting Guys は偽善者だということです。私たちは、モナリザに眉を書き加えることをルーブルが許可してくれなかったことに腹を立てています。ですが、私たちは同じような罪を犯していたのです。TechNet Magazine の 2008 年 1 月号で、私たちはスクリプト内で正規表現を使用することに関する記事を書きました。これこそ、"お手を触れずにご覧ください" の典型的な例です。私たちは正規表現を使用してテキスト ファイルの問題を特定する方法について説明しましたが、特定した問題を解決する方法については説明しませんでした。ああ、まったくもう。
注 : Scripting Guys が 2007 年の 11 月にルーブルに行ったとしたら、このコラムを執筆している Scripting Guy は、なぜ 2008 年 1 月まで公開されない TechNet Magazine の記事の内容に突然思い至ったのでしょうか。これは難問ですね。きっとレドモンドとパリの時差が関係しているのでしょう。
しかしさいわいにも、ルーブルの管理者と違って、Scripting Guys は進んで間違いを認めます。正規表現を使用して検索を実行する方法だけではなく、正規表現を使用して置換を実行する方法も説明する必要がありました。つまり、図 1 のようなスクリプトを紹介すればよかったのです。
Figure 1 検索と置換 (Close Figure 1)
      Set objRegEx = _
    CreateObject("VBScript.RegExp")

objRegEx.Global = True
objRegEx.IgnoreCase = True
objRegEx.Pattern = "Mona Lisa"

strSearchString = _
    "The Mona Lisa is in the Louvre."
strNewString = _
    objRegEx.Replace(strSearchString, _
                     "La Gioconda")

Wscript.Echo strNewString
さて、正直なところ、これは非常にありふれた正規表現の使い方です。ここでは、文字列値 Mona Lisa をすべて La Gioconda ("さて眉をどこに置いたかな" という意味のイタリア語) に置換しているだけです。確かに、VBScript の Replace 関数を使用すれば、ずっと簡単にこの置換を実行できたかもしれません。でも、心配しないでください。この単純で短いスクリプトを使用し、正規表現によって検索および置換処理を実行する方法について説明します。その説明が終わったら、正規表現を使用して実行できるさらに高度な処理をいくつか紹介します。
ご覧のとおり、実に単純なスクリプトです。まず、VBScript.RegExp オブジェクトのインスタンスを作成します。言うまでもありませんが、このオブジェクトによって、VBScript スクリプト内で正規表現を使用できるようになります。オブジェクトを作成したら、そのオブジェクトの次の 3 つのプロパティに値を割り当てます。
Global このプロパティを True に設定して、対象のテキスト内に存在するすべての Mona Lisa を検索 (および置換) するようスクリプトに指示します。Global プロパティが False (既定値) の場合、このスクリプトを実行すると、最初の Mona Lisa だけが検索および置換されます。
IgnoreCase IgnoreCase を True に設定することで、大文字と小文字を区別しない検索を実行するようスクリプトに指示します。つまり、mona lisa と Mona Lisa を同じ値として処理します。既定では、VBScript では大文字と小文字を区別した検索が実行されます。つまり、大文字と小文字が区別されることによって、mona lisa と Mona Lisa がまったく異なる値と見なされます。
Pattern Pattern プロパティには、検索する値を指定します。ここでは、Mona Lisa という単純な文字列値を検索しています。
次に、以下のように、検索するテキストを strSearchString という変数に代入します。
strSearchString = "The Mona Lisa is in the Louvre."
その後、正規表現メソッドの Replace を呼び出し、このメソッドに、検索するテキスト (変数 strSearchString) と置換するテキスト (La Gioconda) の 2 つをパラメータとして渡します。次のコードでこの処理を実行します。
strNewString = objRegEx.Replace(strSearchString, "La Gioconda")
これで処理は完了です。変更されたテキストは変数 strNewString に格納されます。ここで strNewString の値をエコー バックすると、次の文字列が返されます。
The La Gioconda is in the Louvre.
文法的には少々問題があるかもしれませんが、基本的な考え方はおわかりいただけたと思います。
先ほど説明したように、これはこれで問題ありませんが、確かにやりすぎです。次の数行のコードを使用しても、まったく同じ処理を実行できます (実際、必要であれば 1 行ですべての処理を実行することもできます)。
strSearchString = "The Mona Lisa is in the Louvre."
strNewString = Replace(strSearchString, "Mona Lisa", "La Gioconda")
Wscript.Echo strNewString
VBScript の Replace 関数では実行できないようなおもしろいことを、正規表現で実行できるかどうか考えてみてください。
だれも思い付きませんか。では、1 つ紹介します。しばしば Scripting Guys は、ある種類のドキュメントから別の種類のドキュメントにテキストをコピーする必要に迫られます。これは非常にうまくいくこともありますが、そうでないこともあります。うまくいかない場合、単語の間隔がおかしくなり、以下のようなテキストが出来上がることがよくあります。
Myer Ken, Vice President, Sales and Services
これは大変ですね。こんなに余分な空白があります。しかも、このような場合、Replace 関数はあまり役に立ちません。なぜかと言えば、一見したところ、余分な空白の数が決まっていないからです。単語の間に空白が 7 つある場合も、2 つある場合も、6 つある場合も考えられます。このため、Replace を使用して問題を解決することは困難です。たとえば、2 つの連続する空白を検索 (および 2 つの空白を 1 つの空白に置換) すると、以下のようなテキストになります。
Myer Ken, Vice President, Sales and  Services
見栄えは良くなりましたが、それほどではありません。この問題を解決する方法はありますが、その方法では、任意の数の空白 (たとえば 39 個) を検索して置換し、その数から 1 を引いて 38 個の空白を検索して置換し、その後も同様の処理を繰り返す必要があります。代わりに、以下のずっと単純な (しかも間違えにくい) 正規表現のスクリプトを使用できます。
Set objRegEx = CreateObject("VBScript.RegExp")

objRegEx.Global = True
objRegEx.Pattern = " {2,}"

strSearchString = _
"Myer Ken, Vice President, Sales and Services"
strNewString = objRegEx.Replace(strSearchString," ")

Wscript.Echo strNewString
このスクリプト (およびほとんどの正規表現のスクリプト) の重要な部分は、以下の Pattern です。
objRegEx.Pattern = " {2,}"
ここでは、2 つ (以上) の連続した空白を検索しています。この Pattern で 2 つ (以上) の空白を検索していることが、なぜわかるのでしょうか。二重引用符の内側には、1 つの空白に続いて {2,} という構文が記述されています。正規表現の構文では、これは直前の文字 (この場合は空白) の 2 つ以上の連続を検索することを表します。連続した空白が、3 個、4 個、または 937 個ある場合はどうでしょうか。問題ありません。このような空白もすべて取得できます (なんらかの理由で、2 つ以上 8 つ以下の空白を取得する場合は、{2,8} という構文を使用します。この 8 は一致の最大数を指定しています)。
つまり、2 つ以上の連続した空白が検出された場合は必ず、すべての連続した空白を取得して、1 つの空白に置換します。あれだけ余分な空白が含まれていた元の文字列値はどうなるでしょうか。次のようになります。
Myer Ken, Vice President, Sales and Services
どうですか。Scripting Guys には本当に物事を良い方向に変える力があります。ルーブルの管理者がモナリザに眉を書き加えるチャンスをくれれば申し分ないのですが。
よくある興味深いシナリオを紹介しましょう。企業に電話帳があり、すべての電話番号が次のような形式になっているとします。
555-123-4567
ここで、上司はすべての電話番号を次のような形式に変更することにしました。
(555) 123-4567
一体どうすればこのような電話番号の形式を変更できるでしょうか。私たちであれば、次のようなスクリプトを使用します。
Set objRegEx = CreateObject("VBScript.RegExp")

objRegEx.Global = True
objRegEx.Pattern = "(\d{3})-(\d{3})-(\d{4})"

strSearchString = "555-123-4567"
strNewString = objRegEx.Replace _
(strSearchString, "($1) $2-$3")

Wscript.Echo strNewString
ここでは、3 桁の数字 (\d{3})、ダッシュ、別の 3 桁の数字、ダッシュ、4 桁の数字の順に並んだ値を検索しています。つまり、次のような値です。この例では、それぞれの X は 0 から 9 までの数字を表しています。
XXX-XXX-XXXX
注 : では、なぜ私たちは、\d{3} が連続した 3 つの数字を探すようスクリプトに指示する構文であることを知っていたのでしょうか。覚えている限りでは、どこかで読んだのです。『ダ・ヴィンチ・コード』の衝撃的な最終章か、MSDN® オンラインの VBScript ランゲージ リファレンス (go.microsoft.com/fwlink/?LinkID=111387 を参照) のどちらかに載っていたはずです。
さて、正規表現を使用して任意の電話番号を検索できるのはとてもすばらしいことですが、まだ大きな問題が残っています。結局のところ、自由気ままに数字が並んだ電話番号を同じく自由気ままに数字が並んだ電話番号に置換することはできません。この場合、まったく同じ電話番号をやや形式が異なる電話番号に変更する必要があります。一体どのような方法を使用すればよいでしょうか。
次のような置換テキストを使用します。
"($1) $2-$3"
$1、$2、および $3 は、正規表現の "後方参照" の例です。後方参照は、単なる検出されたテキストの一部であり、保存して再利用できます。このスクリプトでは、次のような 3 つの "サブマッチ" を検索しています。
  • 3 桁の数字
  • 別の 3 桁の数字
  • 4 桁の数字
それぞれのサブマッチは自動的に後方参照に代入されます。最初のサブマッチは $1 に、次のサブマッチは $2 に代入され、同様に $9 まで処理されます。つまり、このスクリプトでは、電話番号の 3 つの部分が自動的に後方参照に代入されます (図 2 参照)。
Figure 2 電話番号の後方参照 (Close Figure 2)

番号部分 | 後方参照
555 | $1
123 | $2
4567 | $3
今回の置換テキストでは、これらの後方参照を使用して、正しい電話番号が再利用されるようにします。この置換テキストは、単に次のような処理を実行するよう指示しています。まず、最初の後方参照 ($1) を取得し、かっこで囲みます。次に空白を空けてから、2 つ目の後方参照 ($2) を挿入し、その後ろにダッシュを挿入します。最後に 3 つ目の後方参照 ($3) を挿入します。
この結果、どのようなデータが返されるでしょうか。次のような電話番号が返されます。
(555) 123-4567
なかなか悪くないでしょう。
では、電話番号のスクリプトの応用編を紹介します。組織に新しい電話体系が導入され、その移行の一環として、すべての電話番号に同じ局番が使用されるようになったとします。元の番号は 666、777、888 などから始まっていましたが、すべての番号が 333 から始まるようになります。この場合、電話番号の形式と局番を同時に変更できるでしょうか。もちろん、できます。
Set objRegEx = CreateObject("VBScript.RegExp")

objRegEx.Global = True
objRegEx.Pattern = "(\d{3})-(\d{3})-(\d{4})"

strSearchString = "555-123-4567"
strNewString = objRegEx.Replace _
(strSearchString,"($1) 333-$3")

Wscript.Echo strNewString
上記のスクリプトでは、どのような処理を実行しているのでしょうか。置換テキストで古い局番 (後方参照 $2) を削除し、その代わりに、現在の標準となった共通の局番である 333 に置き換えているだけです。この変更後のスクリプトを実行すると、555-123-4567 という電話番号はどのようになるでしょうか。次のようになります。
(555) 333-4567
後方参照の一般的な使い方をもう 1 つ紹介します。次のような文字列値があるとします。
Myer, Ken
2 つの単語を入れ替えて、次のように名前を表示する方法はあるでしょうか。
Ken Myer
もし何も方法がなかったら、私たちはかなり間抜けですよね。この操作を実行するスクリプトを次に示します。
Set objRegEx = CreateObject("VBScript.RegExp")

objRegEx.Global = True
objRegEx.Pattern = "(\S+), (\S+)"

strSearchString = "Myer, Ken"
strNewString = objRegEx.Replace _

strSearchString,"$2 $1")

Wscript.Echo strNewString
このスクリプトでは、単語 (\S+)、コンマ、空白、別の単語の順に並んだ値を検索しています (この場合、\S+ を使用して 1 つの単語を表しています)。\S+ という部分は、空白以外の文字の連続を意味します。つまり、文字、数字、記号を取得できます。実際、スペース、タブ、改行以外のあらゆる文字を取得できます。ご覧のとおり、ここでは 2 つのサブマッチが検出されます。一方は姓を表し ($1)、もう一方は名を表しています ($2)。このため、次の構文を使用して、ユーザー名を名、姓の順に表示します。
"$2 $1"
コンマはどこへ行ったのでしょうか。これは明らかに不要だったので、削除しました。
注 : おかしいですね。なぜか、編集者の顔が思い浮かびました。うーん。
今日の締めくくりに、もう 1 つスクリプトを紹介しましょう (そうですね、今月の締めくくりです)。このコラムのような初心者向けの記事をあまり複雑にしたくはありませんが、これはだれもが簡単に理解できるスクリプトではありません (正規表現は非常に複雑になりやすいという特徴があります)。いずれにせよ、以下のスクリプトを使用すると、ほとんどの場合、0000.34500044 などの値から先頭に付いているゼロをすべて削除できます。
Set objRegEx = CreateObject("VBScript.RegExp")

objRegEx.Global = True
objRegEx.Pattern = "\b0{1,}\."

strSearchString = _
"The final value was 0000.34500044."
strNewString = objRegEx.Replace _
strSearchString,".")

script.Echo strNewString
例によって、このスクリプトが機能する理由はただ 1 つ、"\b0{1,}\." というパターンが記述されているからです。まず、単語の境界 (\b) を検索します。これにより、100.546 などの値に含まれているゼロが削除されなくなります。次に、1 つ以上のゼロ (0{1,}) に続く小数点 (\.) を検索します。パターンが検出された場合は、検出されたゼロ (および小数点) を "." という 1 つの小数点に置換します。すべてが予定どおりに進めば、変換後の文字列は次のようになります。
The final value was .34500044.
今月の記事もそろそろ終わりです。最後にお伝えしておきますが、モナリザは絵の具も乾かないうちから大きな論争の的となりました。この謎めいた女性はだれだろう、なぜあのように微笑んでいるのだろう、なぜ眉がないのだろう、といったさまざまな疑問が出てきました。数人の美術史家は、モナリザは女性でさえなく、この絵はレオナルド ダ ヴィンチの自画像だという説を唱えています (それが事実なら、ダ ヴィンチは実際に新しい仕立て屋を見つけることができたでしょう)。一方、ユナリアス教育財団 (Unarius Educational Foundation) はさらに一歩踏み込んで、実はこの絵は "高等世界" にいるレオナルドの "双子の魂" を描いたもので、この双子の魂がレオナルドの手を導いたと主張しています。奇遇にも、今月の Hey, Scripting Guy! もまったく同じ方法で執筆されました。
ということで、すべての苦情は、もう 1 つのマイクロソフトでコラムを執筆している Scripting Guy の双子の魂 (the-twin-soul-of-the-scripting-guy-who-writes-that-column@the-other-microsoft.com) までお願いします。それでは。

Dr. Scripto のスクリプト パズル
パズルを解くスキルだけでなく、スクリプト作成スキルもテストする月に一度の課題です。

2008 年 5 月 : スクリプト版数独
今月は、少しひねりを加えた数独をお届けします。マス目には 1 から 9 までの数字ではなく、Windows PowerShell™ コマンドレットを構成する文字と記号が入ります。すべて解くと、横向きに読むことができる行の 1 つにコマンドレット名が現れます。
注 : 数独の解き方をまだ知らない場合は、インターネット上のおそらく何千もの Web サイトにルールが載っているので、ここでは説明を省略します。ご了承ください。

Dr. Scripto のスクリプト パズル
解答 : スクリプト版数独 (2008 年 5 月)

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


 セキュリティ ウォッチ: 量子セキュリティの原理
セキュリティ ウォッチ
量子セキュリティの原理
Jesper M. Johansson

予想もしていない話から価値が生まれると、話が非常に盛り上がることがあります。この記事では、ハイゼンベルグの不確定性原理を使用し、セキュリティの概念について説明します (私のユニコーンに関する話を聞いたことがある方は、私が他の原理の基本定理を持ち込んで物事を説明するのが好きなことをご存知でしょう)。奇妙に
思えるかもしれませんが、情報セキュリティの概念が、他の科学分野で使用されているいくつかの基本概念に結び付く場合があります。
ハイゼンベルグが主張した量子物理学の不確定性原理は、図 1 のような方程式に基づいています。この原理自体は、粒子の位置 (p) と粒子の運動量 (x) は、位置の計測精度を上げると、運動量の計測精度が下がるという点で関連していることを示しています。この 2 つの要素の精度の境界は、非常に小さいプランク定数を掛けた値で表されます。もう少しわかりやすく言うと、この原理は、ある粒子に関する複数の事実を同時に 100% 正確に観察できないことを主張しています。
Figure 1 Heisenberg Uncertainty Principle
Figure 1 Heisenberg Uncertainty Principle
これは不確定帯を予測することと直接関連しているので、実質的には、粒子に関するいくつかの事実の状態がどの程度不確定であるかを予測できることになります。この不確定帯を予測することは (まだ) できませんが、あるコンピュータ ネットワークに関する 2 つの可変事項がそのネットワークのセキュリティに与える影響を 100% 正確に予測することはできないという事実は重要です。
また、トレードオフも避けられません。情報セキュリティにはプランク定数による制限はないかもしれませんが、いくつかの制限があります。避けられないトレードオフのうちで最も顕著なものは、セキュリティとユーザビリティ (有用性) のバランスを取ることです。少しの間、可用性を無視して話を進めると (率直に言って、セキュリティ担当者は、サービス拒否攻撃を受けない限り、可用性に関しては責任がないと思います)、何かを保護するための最も簡単な方法は、その保護対象を停止することです。この方法を使用すれば、ハッキングされることはなくなりますが、有用性は急激に低下します。
同様に、コストは跳ね上がりますが、毎年 1 回、全従業員に電子メールでインスタント メッセージング アプリケーションを業務に使用しないよう通知するよりも、データ損失を防ぐための高価な製品を導入することで、機密データの漏洩をはるかに効果的に防ぐことができます。しかし、そのような製品を購入する意思が組織にあるでしょうか。皆さんが考えている以上に、量子物理学とセキュリティは関連し合っていることがおわかりいただけたと思います。

シュレディンガーの猫
関連するもう 1 つの量子物理学の概念は、シュレディンガーの猫に関するたとえの中で説明されます。20 世紀の著名な物理学者であるエルヴィン シュレディンガーは、アルバート アインシュタイン (20 世紀に活躍したもう 1 人の著名な物理学者です。この名前は耳にしたことがあるのではないでしょうか) と重ね合わせの概念に関する論争を延々と繰り広げたそうです。シュレディンガーは、2 つの状態が重ね合わさった中に、非常に道理に合わない要素が存在するという量子力学の領域を発見しました。
論旨を明確にするために、シュレディンガーはある思考実験を行いました。その実験は、1 匹の猫を密閉した箱に入れて行います。この箱の中にはもう 1 つ毒の入った容器があり、この毒の放出は、ある (架空の) 放射性素粒子によって制御されます。放射性素粒子が崩壊すると、毒が放出され、猫は死ぬことになります。
この素粒子は、量子力学の法則に基づいて考えると、状態の重ね合わせの中に存在しています。この明らかに原子的である猫も、その状態が完全に素粒子の状態に依存しているので、状態の重ね合わせの中に存在しています。実際に猫の状態を観察しない限り、その生死を特定することはできません。
もちろんシュレディンガーのこの思考実験の意図は、量子力学のいくつかの法則が、原子系に適用した場合にいかに道理に合わないかを指摘することです。しかし、このたとえは、いわゆる "観察者効果 (死の観察者)" と呼ばれ、高く評価されることがよくあります。観察者効果は、量子力学の関心の的である素粒子系には当てはまりませんが、セキュリティ専門家としては興味深い概念です。簡単に言うと、これは、何かを観察することで観察対象が変化するという考え方です。
観察者効果
もう少し説明を加えるために、1 杯の紅茶を例に考えてみましょう。紅茶の温度を確認する場合、温度計をカップに入れます。たとえば、温度計を入れた時点では紅茶は 80 ℃ で、温度計自体は 22 ℃ (室温) であったとします。温度計を紅茶に入れたとたん、温度計は紅茶の熱を吸収し始め、紅茶はその熱の一部を失い、温度計が温まります。最終的に、温度計と紅茶の温度は等しくなります。しかし、この温度は 80 ℃ でも 22 ℃ でもなく、その中間の温度になります。したがって、紅茶の温度を測定したことで、紅茶の状態が変化したことになります。
観察者効果も、情報セキュリティと関連しています。あるセキュリティ問題を緩和するためになんらかの対策を講じるたびに、システムに変更が加えられるので、セキュリティの状況が変化している可能性があります。私は、他に良い言葉がないので、これを "セキュリティ状況の流動効果" (SPFE: Security Posture Fluidity Effect) と呼んでいます。
この簡単な例としては、サービス アカウントの依存関係が存在する場合が挙げられます。『Protect Your Windows Network』(protectyourwindowsnetwork.com) の第 8 章に、システムに侵入検出サービス (IDS) をインストールして攻撃を検出する方法に関する説明が記載されていますが、IDS は集中管理システムにログオンし、監視対象のシステムに対する高いレベルの特権を持つアクセスを要求します。つまり、ほとんどの場合、このサービスは高いレベルの特権を持つサービス アカウントで実行されることになります。
これらのシステムの 1 つが攻撃された場合、攻撃者はサービス アカウントの資格情報にアクセスできるようになるので、IDS 自体を無効にするだけでなく、他のすべてのシステムにアクセスすることもできます。これは SPFE をよく表している例です。環境のセキュリティを強化するなんらかのプログラムをインストールすることで、セキュリティに関する潜在的な問題が新たに発生します。
SPFE の例は、他にも多数あります。Steve Riley は、ワイヤード ネットワークで 802.1x が問題になる理由を説明していますが (microsoft.com/technet/community/columns/secmgmt/sm0805.mspx)、これも良い例の 1 つです。当然、ホストベースのファイアウォールの使用は、多くの環境において非常に望ましいことです。ただし、802.1x と共に使用すると、それまで不可能であった攻撃が可能になります。この場合も、セキュリティ テクノロジによって環境内のセキュリティの状況が変化し、そのテクノロジが導入されなければ不可能であった攻撃が可能になっています。
これらの対策が本質的に役に立たないので、使用しない方がよいと言っているわけではありません。これらの例が表しているのは、セキュリティ全体を考慮して、実装する対策の影響を検討する必要があるということです。リスク管理を行うときは、自分の行動や対策が実際のリスクにどのような影響を与えるかについて検討してください。問題を緩和する場合、対策を実装してそれで終わりというわけにはいきません。本質的に、セキュリティは一連の過程です。多層防御戦略を使用する必要がありますが、防御策を実装することによってセキュリティの状況がどのように変化するか、およびその戦略を導入したことによって発生する新たな脅威にどのように対処していくかを検討するようにしてください。

成熟しつつあるセキュリティ強化テクノロジ
私は 10 年以上にわたって、セキュリティ強化ガイダンスの作成に取り組んできました。初めの頃に携わったいくつかのガイドを振り返ると、私と同僚が有効にすべきであると判断した設定が並んでいるだけでした。当時のセキュリティを支える一般的な戦略は未熟なものであり、基本的に、セキュリティを強化する手段があれば、それを実装していました。また、その実装を解除する正当な理由があるかどうかは、もともとあまり考慮されていませんでした。
最終的に私は、効果的にセキュリティを強化するには、強化対策をじっくり考え、システムがさらされている脅威について考慮する必要があることを学びました。この事実に気付いたことで、現在『Windows 2000 セキュリティ強化ガイド』(go.microsoft.com/fwlink/?LinkID=22380) に掲載されているシナリオを作成することができました。そこからの自然な流れで、このガイダンスがさまざまな脅威レベルに分割され、『Windows Server 2003 セキュリティ ガイド』(go.microsoft.com/fwlink/?linkid=14846) のような形式になりました。
この間ずっと、ある事実に悩まされ続けました。それは、すべてのガイダンスに目を通し、その内容に基づいて環境を実装しても、システムが侵害される可能性は残るということです。この理由として挙げられるのは、一部の修正プログラムが適用されないこと、一部の運用方法に問題があること、および安全でないサードパーティ製のソフトウェアがインストールされていることです。
上記の 2 つのガイドに記載されているセキュリティの強化対策は、全体的なセキュリティの強化にはそれほど役立たないことがわかりました。結局、これらはいくつかの重要な要素に絞り込まれました。実際、これまで構築した中で最も安全なシステム (msdn2.microsoft.com/library/aa302370) では、上記のセキュリティ ガイドに記載されている 4 つか 5 つの対策のみを実装しましたが、対象となる攻撃を実際に阻止したものはありませんでした。残念ながら、人々はシステムのセキュリティを自動的に強化する、魅力的な [今すぐセキュリティを強化する] ボタンのみを求めますが、セキュリティはそれほど単純ではありません。

リスクに対処する方法
(限定されたセキュリティではなく) 保護された状態を実現するには、理にかなった方法でリスクに対処する必要があります。どのようなリスクに直面しているかを理解し、緩和するリスクを特定したうえで、その方法を理解する必要があります。この作業は、単純にスイッチを入れるだけで完了することはまずありません。
一般に、上記のようなセキュリティ対策は、特定のシナリオに合わせて設計されているので、実際のシナリオに最適な構成が提供されるとは限りません。代わりに提供されるのは、基盤となる構成です。このようなセキュリティ対策が提供されている主な理由は、市場でこのような簡単なセキュリティ強化策の需要が高まっているからです。最近のソフトウェアでは、ほとんどの設定が既定で有効になっており、無効になっているものは、何か重大な副作用を引き起こす可能性があります。
また、未知の脅威を緩和するためにさまざまなスイッチを入れると、システムが不安定になり、必要な作業を行うことができなくなる可能性があります。SPFE と量子物理学から考えると、セキュリティ対策を実装した後には再分析を行う必要がありますが、多くの組織はこれを怠っています。実際、組織はそもそも脅威を分析できていません。実際に脅威を分析することから始めれば、本当に効果がある対策は、アカウント名の列挙に匿名の制限を適用したり、大規模なアクセス制御リストの変更を行うことではないことがわかるでしょう。
本当に効果がある対策は、システムで特定のサービスを提供する必要があるかどうか、および必要な場合はどのユーザーに提供するかを判断した後で、ポリシーを適用することです。また、絶対に通信する必要があるシステムとユーザーとの通信のみを許可するようにします。さらに、すべてのアプリケーションとユーザーが必要最小限の特権で実行されるようにすることも、効果があります。つまり、理にかなったセキュリティ対策を実装し、面倒な分析を行って、各システムがそれぞれのセキュリティを保証できるようにすることが重要です。
この理由から、現在のセキュリティ対策としては、サーバーとドメインの分離 (microsoft.com/sdisolation)、Windows Server® 製品で提供されるセキュリティの構成ウィザード、Windows Server 2008 の役割を管理するサーバー マネージャ ツールなどが使用されています。これらのツールを使用すると、サポートが必要なシナリオを理解するためのプロセスを実施したうえで、適切にシステムを保護できます。確かに、これらのツールによって、だれもが望む万能薬が提供されるわけではありませんが、特定のソフトウェアの購入動機となった機能を実行できるだけの構成は提供されます。

必要な場所にセキュリティを適用する
ここまでの説明から、他の手段や単純なセキュリティ対策には依存できないことがおわかりいただけたと思います。現在は "境界" や "内部ネットワーク" という概念が意味を成さなくなっているので、各資産が自らを保護できなければなりません。
組織のネットワークの大半は、扱いやすいとは言いがたい状態です。このことを理解し、お決まりのセキュリティ強化ガイダンスを頼みの綱として使用するのではなく、適切な手順を踏む必要があります。まずは、要件を把握します。その要件を理解している他の人の意見も聞くようにしてください。
最近、Web キャストのあるゲストが、小規模の企業に属するユーザーに、米国国土安全保障省のサイトから Internet Explorer® 用のセキュリティ強化ガイドをダウンロードするよう勧めていました。なぜ私たちは、軍と国家の安全を守ることが任務である政府機関が、小規模の企業で使用される Web ブラウザのセキュリティ対策について実用的なガイダンスを提供できると考えてしまうのでしょうか。これは、まだコンピュータ セキュリティの分野に陳腐な論理が蔓延していることを示す良い例です。立派な政府機関が発行したガイダンスなのだから、強力なセキュリティを実現できると考えてしまうのです。
通常は、2 つに 1 つの選択をしなければなりません。つまり、"強力なセキュリティ" か "脆弱なセキュリティ" のいずれかです。より適切な言い方をすると、"強力なセキュリティ" か "適切なセキュリティ" のいずれかです。セキュリティは、画一的なものではありません。
実際、すべての組織に強力なセキュリティが適しているわけではなく、通常ほとんどの組織にとって、強力なセキュリティは不要です。ここが目標とする最終地点ではありません。これは、攻撃を受けた場合に人命に危険が及ぶようなシステムを対象とした特殊な構成です。この構成が環境のリスク プロファイルと脅威モデルに該当する場合は、強力なセキュリティを使用してください。
該当しない場合は、もう少し適切な対策を使用する必要があります。おそらく、構成可能なセキュリティ対策は、既定で中程度のリスク プロファイルに適合するように、適切に設定されています。現在のほとんどのマイクロソフト製品で使用されている、この既定の状態によって、セキュリティと、ユーザビリティ、有用性、およびパフォーマンスとの間で適切なバランスが取れた構成が提供されます。セキュリティ強化に限って言えば、通常は既に必要な設定が構成されています。
次に、他のセキュリティ関連作業について検討する必要があります。まずは、TechNet セキュリティ センター (microsoft.com/technet/security) を参照するとよいでしょう。もちろん、『Windows Server 2008 Security Resource Kit』などの書籍を参考にしてもかまいません。

結局はリスク管理が重要
ここまでの内容から、どのような方向に話が展開されるか、もうおわかりかもしれません。つまり、重要なのは "リスク管理" です。ハイゼンベルグの不確定性原理で伝えたかった重要なメッセージは、トレードオフが存在するということです。この部分については、難しい理屈はありません。
ただし、シュレディンガーの猫の話で伝えようとしたメッセージは、ほとんどの人が考慮していません。問題のあらゆる側面を分析し、トレードオフを判断することだけが重要なのではなく、実装した対策がもたらす変化も考慮する必要があります。適切なリスク管理戦略を構築するには、実装した変更がシステムに与える影響と、その変更がリスク緩和戦略の一環として実装されたのか、それとも別の理由で実装されたのかを考慮することが重要です。

年次損失予測
リスクの定量化には、年次損失予測 (ALE) 式という手法がよく使用されます (図 2 参照)。この手法は、多くのセキュリティ認定講座で紹介されています。標準的な ALE は単純で、問題が発生する確率と、それぞれの問題が発生したときにかかるコストを特定し、これら 2 つの値を掛け合わせます。これにより、セキュリティに関する問題が発生した場合に必要になることが予想される費用を年単位で算出できます。リスクのコストが高い場合は、緩和策を実装します。
Figure 2 ALE is the probability of a loss, multiplied by the cost of the loss per incident
Figure 2 ALE is the probability of a loss, multiplied by the cost of the loss per incident
ただし、標準的な ALE では緩和策のコストを適切に評価できないという問題があります。緩和策自体にコストがかかるだけでなく、緩和策の多くは二次的な問題を引き起こすので、それに関連するコストも発生します。
最も一般的なセキュリティ対策の 1 つであるアカウント ロックアウトについて考えてみましょう。多くの組織はアカウント ロックアウトを展開し、表面上は攻撃者がパスワードを推測できないようにしています。攻撃者が 1 つのパスワードを推測できる確率は、数学的に計算できます。また、工夫すれば、攻撃者がパスワードを推測できた場合に発生する攻撃の平均的なコストも予測できます。多くの組織は、この 2 つの数値に基づいて ALE を算出し、現在の状態では危険であると判断して、アカウント ロックアウトを実装しています。
ただし、アカウント ロックアウトによってかかる特定のコストが考慮されていない可能性があります。もちろんアカウント ロックアウトの実装自体にもコストがかかりますが、このコストはそれほど大きくありません。正確には、アカウント ロックアウトに伴う二次的な問題のコストを含める必要があります。
まず、ユーザーのアカウントのロックを解除するヘルプ デスクのコストがかかります。アカウントがロックアウトされる期間が非常に短かった (15 分間など) としても、この間の生産性は失われます。これは、問題が発生するたびにかかるコストとして計上され、特定の期間内でその問題が発生する確率と掛け合わされます。この場合は、予想されるロックアウトの発生回数 (この数値はログで確認できる場合があります) とコストを掛け合わせます。
また、ユーザーのフラストレーションも考慮する必要があります。過去の事例から、ユーザーは、アカウント ロックアウトが適用された場合、入力ミスの可能性が低くなるように、より単純なパスワードを使用することがわかっています。したがって、この緩和策を実装しても、該当する問題が発生する確率が完全にゼロになることはありません。
また、緩和策を実装することによって、実装前は存在しなかった脆弱性がもたらされる可能性もあります。アカウント ロックアウトの例では、攻撃者がこの特性を利用して、誤ったパスワードの推測を繰り返すことで、ネットワーク内のすべてのアカウントを無効にすることが考えられます。この場合も、問題が発生する確率と共に、発生した場合のコストを考慮する必要があります。
すべての要素を考慮すると、損失予測式を変更する必要があることは明らかです。まず、問題が発生する確率を変更する必要があります。この確率は以前に比べて低くなりますが、上記のとおりゼロになることはないでしょう。それぞれの問題が発生したときにかかるコストも変化している可能性があります。そして、問題が発生する確率と問題のコストを掛け合わせた値に、緩和策自体のコストを足す必要があります。このコストは、実装にかかるコストと、すべての二次的な問題の年単位のコストの合計を足したものです。また、それぞれの年単位のコストは、二次的な問題が発生する確率と、それぞれの問題の発生時にかかるコストを掛け合わせたものです。方程式を少し単純に表すと、図 3 のような、より精度の高いリスク分析方程式が得られます。
手直しされた図 3 の方程式を使用すると、特定の問題に関するリスクをより正確に分析できます。既に多くの組織が、この方法でリスクを分析しています。しかし、依然として多くの組織は、単純な見方でしかリスクを捉えることができず、緩和策の影響を分析する必要性に対して十分に目を向けていません。図 3 のような ALE の方程式を使用することで、この必要性をしっかりと認識できるようになるでしょう。
Figure 3 Considering the additional costs of mitigation
Figure 3 Considering the additional costs of mitigation

まとめ
この記事を読んだ後に何か行うとすれば、それはセキュリティ戦略の基盤となっている従来の概念を疑うことです。情報セキュリティの分野では、変化が少ないステレオタイプの考え方に基づいて何かを行うことが非常によくあります。しかも、その前提の多くは、今となっては時代遅れです。
攻撃は変化しています。今や攻撃者は、金銭的な利益を得るため、国家を支配するため、そして自らの信条のために、プロとして活動しています。セキュリティを強化できないセキュリティ対策に、無駄な時間やお金を費やす余裕などありません。つまり、より高度な方法でリスク管理を行う必要があります。
まず、どのような対策にもトレードオフがあることを認識する必要があります。何かを 100% 知ることなどできません。
また、運用中のシステムには相互依存関係が存在することを理解する必要があります。セキュリティ上の変更をシステムに導入することで、システム自体に変更が加えられるので、システムを再度分析する必要があります。
可能であれば、この分析作業は、実際に変更を実装する前に行ってください。この理由は、変更後、効果的な結果ではなく損害をもたらすような重大な影響がシステムに与えられることが非常に多いからです。このような変更の分析を行うよう通知する優れた分析ツールを使用すれば、再分析を忘れることは少なくなるでしょう。
また、人的な要因も忘れないでください。情報セキュリティに関するどのような作業を行う場合でも、その目的は、企業と組織内のユーザーが、できるだけ安全に業務を進められるようにすることです。
最近行ったプレゼンテーションの中で、私はウイルス対策プログラムを実行するためにコンピュータを購入するユーザーなど 1 人もいないことを指摘しました。セキュリティは、その担当者にとっては最大の目標ですが、企業にとって最大の目標ではありません。組織は、セキュリティが目下最大の優先事項であるという理由で、とりあえず我慢してセキュリティに取り組んでいるにすぎません。情報セキュリティ グループが存在しているのは、ビジネスを支えるためであって、その逆ではないことを決して忘れないでください。この事実を無視すれば、ユーザーは自分が理解または同意していない場合でも、業務を遂行するために、あらゆる手段を使用してセキュリティ制御を回避するでしょう。

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


 デスクトップ ファイル: 管理者から卒業する
デスクトップ ファイル
管理者から卒業する
Wes Miller

今から 3 年以上も前の話ですが、私は通常使用している Windows システム上のユーザー アカウントを、ローカル管理者アカウントからローカル ユーザー アカウントに移行する作業を始めました。マイクロソフトでの勤務は 7 年以上になりますが、私は常に完全な特権が与えられた管理者としてシステムを実行してきました。確かに便利でしたが、この状態は恐ろしいほどセキュリティを欠いていたため、
私 (および皆さんの多く) は非常に運が良かったことになります。毎日管理者としてシステムを実行しても、それほど多くのシステムが、それほど頻繁に、それほど大きな影響を受けることはありませんでした。
このことに関する統計を取るための良い方法はないだろうかと思うことがよくありますが、私の感触や業界の状況から判断しても、現在非常に多くの組織が (そして IT プロフェッショナルでさえも) ローカル管理者としてシステムを実行しています。Winternals で、私がシステムを管理者ではなくユーザーとして実行するようにした目的は、生産者と消費者の両方の立場から、この方法でシステムを実行することの難点を学習し、Winternals の製品である Winternals Protection Manager が標準的な組織でどれほど役立つかを多少なりとも理解することでした。Winternals は、多くの組織の大部分のユーザーが、これまで管理者としてシステムを実行しており、現在もその状況が変化していないという前提に基づいて、管理者がユーザーとしてシステムを実行できるようにし、さらに移行が必要な部分 (少なくとも複雑な作業を伴う部分) をできる限り少なくすることを目標としました。組織でどのようなテクノロジを使用している場合でも、管理者からユーザーに移行する作業は簡単ではありませんが、この作業を完了することによって、組織が攻撃を受ける確率を最も効率的に低下させることができます。この実装は、システム内のファイアウォールと考えることができます。実際の機能は、ファイアウォールそのものです。

この考えに至った経緯
皆さんへのメッセージ : 痛みは必要です
まだ管理者からユーザーへの移行を考えたことがない場合は、この作業について考え始めるべきです。まずは自分で試してみることをお勧めします。予備のコンピュータでは適切なテストにならないので、毎日使用しているコンピュータでテストを行ってください。Windows Vista® を実行している場合は、ユーザー アカウント制御 (UAC) を使用しない場合のテストも行うことをお勧めします。組織内で、なんらかの変更を必要とする作業の実施を推進する場合は、まず自分から実施してみるのがよいでしょう。試してみると、管理者以外の役割としてシステムを実行することはそれほど難しくないことがわかると思います。また、セキュリティも強化されるので、実際に組織が攻撃を受ける確率も低下します。

ほとんどのユーザーが管理者としてシステムを実行するという現状は、Windows® の歴史に基づいています。Windows の初期のバージョン (Windows NT® 3.1 以前) では、対話形式でシステムを実行するすべてのユーザーに、機能上同じ権限が与えられたので、セキュリティはまったく存在しませんでした。これは、すべてのソフトウェアが同じ方法でインストールされることを意味していますが、家庭にとってはそれほど大きな問題ではありませんでした。当時は、ある人がコンピュータを所有している場合、そのコンピュータのすべてのユーザーが、インストールされているソフトウェアを使用できることが当たり前でした。
Windows NT は、登場した直後から (消費者はもちろん) 企業に支持されたわけではありません。32 ビットの Windows と Windows NT の間には Win32® の互換性が存在したので、ほとんどのアプリケーション ベンダは、Windows NT のセキュリティ インフラストラクチャに適合させるというだけの目的で、アプリケーションを再構築することはありませんでした。実際、Windows 2000 が登場するまで、多くの消費者指向の独立系ソフトウェア ベンダ (ISV) は、Windows NT には注目しませんでした。もちろん企業の決断を後押ししたのは、Windows 9x ファミリの時代を終息へと向かわせた Windows XP です。
しかし依然として、アプリケーションの開発は、システムのすべてのユーザーに、Program Files、およびレジストリ内の HKEY_LOCAL_MACHINE (HKLM) と HKEY_CLASSES_ROOT へのアクセス権が与えられていることを前提として行われました (ユーザーとして実行した場合、これらの権限は与えられません)。アクセス権を前提とする厄介なプログラムの 1 つとしてよく挙げられるのは、ゲームです。詳細については、Matt Clapham が執筆した記事 (technetmagazine.com/issues/2007/02/Gaming) を参照してください。
この前提が問題である理由は、さまざまなシステムで実行されるアプリケーションのほとんどが、ファイルやレジストリ設定を上記のような場所に格納するからです。つまり、これらの場所の読み取りおよび書き込み権限が与えられていなければ、アプリケーションをインストールすることはできません。残念ながら、インストール後にこれらのキーへの書き込みを要求するアプリケーションもあります。たとえば、私の娘は Flash ベースのゲームを持っていますが、このゲームは、実行するたびにカスタム プレーヤーをインストールしようとします。つまり、娘が管理者ではなくユーザーとして実行しようとした場合、アプリケーションは起動せず、致命的なエラーが発生します。これは極端な例であり、消費者向けアプリケーションの話ですが、実際のところ、消費者以外を対象としたアプリケーションも、管理者以外の役割として実行した場合、適切に動作しないことがあります。私のメッセージ (補足記事「皆さんへのメッセージ : 痛みは必要です」を参照) を実行に移してくだされば、Windows をユーザーとして実行することの不便さを理解していただけると思います。
図 1 は、Windows XP でユーザーとして IPConfig /release を実行したときの結果を示しています。これを図 2 と比較すると、Windows Vista で同じコマンドを実行した場合、あまりわかりやすい結果が表示されるとは言えませんが、少なくともコマンドが失敗した理由は表示されます。また、ネットワーク ツールも全体的に強化され、ユーザーが IP アドレスを更新できるようになりました。同様に、どちらのバージョンでも、ユーザーとして [コンピュータの管理] (compmgmt.msc) を実行したときに、一部のタスクを実行できるようになりました。ただし通常は、図 3 のように袋小路に入ってしまい、もどかしい思いをすることになります。Windows Vista の初期状態では、[コンピュータの管理] で提供されるツールの多くを実行できませんが、アクセスが拒否されたことを示すメッセージの内容はわかりやすくなっています。
Figure 1 Running as a user under Windows XP
Figure 1 Running as a user under Windows XP
Figure 2 Running as a user under Windows Vista
Figure 2 Running as a user under Windows Vista
Figure 3 Misleading message after running compmgmt.msc as a user on Windows XP
Figure 3 Misleading message after running compmgmt.msc as a user on Windows XP

移行が必要な理由
なぜ移行を検討する必要があるかと言えば、私たち IT プロフェッショナルは、最小限の特権が与えられたユーザーに適合するアプリケーションの開発を推進し、対話形式でシステムを実行しているユーザーがそのシステムの所有者であるという前提を排除していく必要があるからです。
残念ながら、管理者にレジストリ キーへの書き込みを許可するポリシーを適用すると、アクセス制御リスト (ACL) で明示的にアクセスを拒否されていないすべてのオブジェクトへの完全なアクセス権が、それらの管理者のユーザー コンテキストで実行されたすべてのマルウェアに与えられます。UNIX では、ルート (機能的には Windows の Administrator アカウントに相当します) としてシステムを実行しないという規則が守られています。この主な理由は、ソフトウェア エコシステムのセキュリティ モデルの限界点を広げるには、"最小" から "無" という概念に移行する必要があるからです。
ただし、今実施できる最善の対策は、このような考え方に従い、明らかに必要な場合のみ管理者としてシステムを実行するか、可能であれば個々のアプリケーションのみを管理者として実行することです。これにより、先ほど述べた "システム内のファイアウォール" を強化できます。また、マルウェアやスパイウェアが適切でない処理を実行しようとしても、その処理は失敗します。これは、実際にシステムに侵入する (サービスやドライバのインストール、すべてのユーザーを対象としたインストールなどを実行する) ために変更を加える必要があるレジストリやファイル システム上の場所にデータを書き込むことができないからです。さらに、マルウェア対策ソフトウェアが、システム全体を危険にさらす前に、認識したマルウェアの侵入を阻止できるようになります。
ただし、ユーザーが一切攻撃を受けないわけではありません。マルウェアが個々のユーザーのコンテキストを利用して、それらのユーザーのデータを破壊する可能性があります (このようなマルウェアは、まだそれほど広範には存在していません)。ただし、このようなソフトウェアの攻撃を受ける部分は限定されているので、Linux や Macintosh でもマルウェアの侵入率を抑えることができ (被害を受ける可能性がある部分が限定されるので、マルウェアの作成者にとって魅力的な対象ではなくなります)、今日のエンド ユーザーの一般的な安全性が保証されます。

Power Users の排除
Protection Manager の開発時、顧客から「すべてのユーザーが Windows XP を管理者ではなくパワー ユーザーとして実行しているので安全です」という話を聞いたことがあります。ただし実際には、パワー ユーザーと管理者の間にほとんど違いはありません。Windows XP には、少し手を加えるだけでパワー ユーザーを管理者に昇格できる潜在的な欠陥がいくつか存在します。実際、Windows Vista と Windows Server® 2008 では Power Users グループが削除され、Windows の以前のバージョンからアップグレードされたシステムでのみ、Power Users グループが提供されるようになりました。一般的に、Windows XP を使用している場合でも、Power Users グループは使用しないことをお勧めします。

損失を引き起こすアクセス許可
3 月号で Windows のシン クライアントに関する記事 (technetmagazine.com/issues/2008/03/DesktopFiles) をお読みいただいた皆さんは、私が Windows XP を軽量化して領域を節約しようとする傾向に反対していたことを覚えていらっしゃるでしょう。このときと状況は似ていますが、管理者をユーザーに移行する手段として、よく使用されている方法があります。この方法を使用することも検討する必要がありますが、実際に使用する場合は注意が必要です。この方法とは、レジストリとファイル システム上の ACL を調整し、通常は書き込みが許可されていない場所への書き込みをユーザーに許可することによって、問題のアプリケーションを実行できるようにすることです。
当然、最も良い選択肢は、このような変更を必要としないようにアプリケーションを更新することですが、それが常に可能であるとは限りません。アクセス許可を変更する (つまり削除する) 必要がある場合は、十分に注意して作業を行ってください。ユーザーと管理者の間のファイアウォールは、主にレジストリとファイル システムのアクセス許可によって定義されています。これらのアクセス許可を削除することによって、保護レベルが低下し、マルウェアの攻撃を受ける可能性が高くなるので、適切に変更を加えるようにしてください。

UAC について
管理者からユーザーへの移行を検討するときは、必ず Windows Vista のユーザー アカウント制御 (UAC) を考慮する必要があります。Mac OS X と似た機能が提供される UAC を使用すると、システムを危険にさらすことなく、"管理者として" 操作を実行できます。
それでは、UAC のしくみについて説明しましょう。図 4 は、Process Explorer で cmd.exe の情報を表示したときの状態を示しています。右側の cmd.exe のインスタンスは、昇格を行うことなく、最初から管理者として実行しました。このため、右側のユーザーと左側の (昇格を行って cmd.exe を実行した) ユーザーはまったく同じですが、アプリケーション自体 (およびそのインスタンスを実行するユーザー) には、管理者権限が必要なタスクを実行するための特権やトークンは含まれていません。UAC は、ユーザーの対話コンテキスト内で、攻撃を受ける可能性がある範囲を拡大することによって、特定の機能を実行できるようにします。唯一の問題は、なんらかの方法で、そのタスクに管理者特権が必要であること、およびそのタスクを完了するために必要な昇格がユーザーによって許可されたことを Windows に通知する必要があることです。
Figure 4 Two instances of cmd.exe with different privileges
Figure 4 Two instances of cmd.exe with different privileges
Windows Vista で表示される小さな盾は、昇格が必要なタスクを示しています (図 5 参照)。これらのタスクは、実行されるたびに昇格を必要とします。この動作は、Windows Vista の泣き所の 1 つとして、新聞や雑誌などで取り上げられています。この選択肢によって、資格情報はより "厄介" なものになり、セキュリティの脅威がもたらされ、システムが今までよりも簡単に攻撃される可能性があります。
Figure 5 Shields in Windows Vista indicate the need for elevation
Figure 5 Shields in Windows Vista indicate the need for elevation
UAC が有効になっており、単純にユーザーとしてシステムを実行している場合は、アプリケーションで管理者特権が必要になったとき、ユーザーに一連の管理者資格情報の入力が要求されます。この場合、アプリケーションは、runas や psexec を使用する場合と同じように、そのアプリケーションを起動したユーザーのコンテキスト内で実行されます。これは、UAC が有効になっており、管理者としてシステムを実行している場合とは異なる動作です。アプリケーションのタスクはユーザーのコンテキスト内で実行されますが、昇格した権限が使用されます。

Windows Vista をユーザーとして実行する
個人的には、Windows Vista を実行するときは、UAC を有効にした状態で管理者として実行するのではなく、実際にユーザーとして実行した方がよいと思います。一般的な企業では、依然としてこれが最善の方法です。ユーザーには各自のシステムに対する完全なアクセス権が与えられ、さらにマルウェアの攻撃を受ける確率が低下する可能性があります。
また、グループ ポリシー、ウイルス対策ソフトウェア、マルウェア対策ソフトウェアなどを使用してユーザーを管理する計画を立てており、実際に特定のタスクを実行または完了するかどうかを一元管理する必要がある場合は、エンド ユーザーが管理者ではないことを保証することが重要です。ユーザーが管理者である場合、それらのユーザーはサービスの停止、ドライバの追加、ドライバの削除など、あらゆる操作を行うことができます。もちろん、狡猾なエンド ユーザーは、ユーザーとしてシステムを実行する場合でも、Windows PE を使用して、セキュリティのハードルを越えてくる場合があります。BitLocker® を使用すると、この操作を困難にすることができます。ただし、コンピュータに物理的にアクセスできる場合、十分な時間、知識、および努力があれば、コンピュータにどのような変更を加えることも可能であることを覚えておいてください。
Windows Vista をユーザーとして実行することは、Windows XP をユーザーとして実行することとそれほど大差ないので、同じツール (PSExec、RunAs、および UAC) を使用し、必要に応じて管理者としてタスクを実行します。この方法のメリットは、管理者特権を必要とする Windows XP の多くのタスクで、この特権が要求されなくなることです。たとえば、Windows Vista ユーザーはローカル プリンタをインストールできます (Windows XP ユーザーはネットワーク プリンタをインストールできますが、ローカル プリンタをインストールするには管理者特権が必要です)。Windows Vista では、ユーザーが物理的にコンピュータにアクセスでき、プリンタ ドライバがドライバ ストアに格納されている場合、そのユーザーは、プリンタをインストールし、そのプリンタで印刷ジョブを管理できます (詳細については、go.microsoft.com/fwlink/?LinkId=111534 を参照してください)。この機能は、Windows Server 2008 では無効になりました。
Windows XP でユーザーとしてシステムを実行しているときに、時計機能 (非表示になっている場合もあります) を操作することがあります。ユーザーとして時計をダブルクリックしてみてください。この操作は、よく日付を確認するために行われます (そのような目的のために設計された動作ではないかもしれませんが)。この場合、当然図 6 のようなエラー メッセージが表示されますが、あまり親切な機能とは言えません。Windows XP では、ポリシーを変更してユーザーにこの操作を許可することができましたが、Windows Vista では、この操作を許可しないように動作が変更されました。このため、全体的に見て、Windows Vista では、Windows XP の場合と異なり、通常はユーザーとしてシステムを実行した方がよいでしょう (UAC を使用するか、正式なユーザーとして実行し、別のユーザーとして昇格します)。
Figure 6 In Windows XP, non-admins couldn't change the time
Figure 6 In Windows XP, non-admins couldn't change the time

制限を思い出す
ユーザーを管理者以外の役割に移行することによって、すべての問題が解決されるわけではありません。エンド ユーザーは依然として物理的に各自のコンピュータにアクセスできるので、特にポリシーやユーザー特権によって不都合が生じたり、作業を完了できなくなった場合、熱心なユーザーは懸命に方法を探し、そのコンピュータのシステムに変更を加える可能性があります。
ユーザーが管理者としてシステムを実行している場合、それほど多くの作業を行わなくても、適用されているグループ ポリシーを回避できます。もちろん、さらにもう少し手を加えれば、ユーザーは Windows PE を起動し、通常は特権が与えられていない、アクセス許可の変更操作を行うことができます。ただし、BitLocker や、その他のドライブ暗号化またはボリューム暗号化を使用すれば、このような操作を不可能にするか、少なくとも困難にすることができます。
組織でまだエンド ユーザーが管理者としてシステムを実行しており、管理者からユーザーへの移行を始めていない場合、最も大事なことは、皆さん自身と組織が、なぜ時間、資金、および労力を割いて、ユーザーが管理者としてシステムを実行しないようにする必要があるのかを理解することです。
もちろん、古いアプリケーションを手放すのはつらいかもしれませんが、ユーザーとして実行できないアプリケーションを保有しているのであれば、組織のセキュリティを犠牲にしてまでそれにしがみつくのは良い考えではありません。アプリケーションの仮想化を検討することをお勧めします。つまり、仮想化という言葉どおり、エンド ユーザーが管理者としてシステムを実行できる仮想マシンにアプリケーションを移行します。これにより、必要に応じてアプリケーションを使用できるだけでなく、管理者をユーザーに移行することによって、システムの残りの部分をセキュリティで保護できるようになります。
このコラム全体を通して、私は "ロックダウン" またはそれに似た言葉を使用しませんでした。多くの人は、管理者からユーザーへの移行と言えば、これらの言葉によって表される作業の 1 つだと考えてしまいます。私が心理学を勉強したからかもしれませんし、現在マーケティングに携わっているからかもしれませんが、特権が奪われる (動作的にはそうですが) ような印象をエンド ユーザーに与える言葉を使用しないことが重要だと思います。
その代わりに、組織のセキュリティにもたらされるメリットを強調し、特定のユーザーが絶対にユーザーとしてシステムを実行できない場合や、管理者特権を必要とする特定のタスクが存在する場合などの極端な状況に対処できるように、適切な計画を立てるようにしてください。以前に紹介した Run.vbs スクリプト (technetmagazine.com/issues/2007/03/DesktopFiles 参照) のような手動ツールを使用するか、移行に役立つ (エンド ユーザーが移行作業を意識することなく、すべてが問題なく動作するようになる) 市販のソリューションを使用するかにかかわらず、できるだけ早く、管理者以外の役割への移行を始めることが重要です。TechNet Magazine にもよく寄稿している Aaron Margosis は、管理者以外の役割としての実行を普及させる取り組みを行っています。彼のブログを読んだことがない皆さんは、blogs.msdn.com/aaron_margosis を参照してください。このトピックについて、どこよりも詳しい情報が記載されています。

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


 フィールド ノート: 1 台のパソコンに複数のマウス
フィールド ノート
1 台のパソコンに複数のマウス
Kentaro Toyama

現在のインドは 格差社会が問題となっている国です。世界のコンピュータ需要に対応するテクノロジを開発している教育水準が高い人材がそろう IT 大国ですが、国民の 70% はいまだに 1 日 2 ドル未満で生活しているという側面も持っています。このような両極の側面を持つ生徒たちが、資金の乏しい公立学校で不定期に開催されるコンピュータ教室に集まります。このような学校で用意できるのは、せいぜい数台のコンピュータです。通常、学校にはコンピュータを購入する予算がないため、こういったコンピュータは寄付でまかなわれています。
このような環境では、生徒の数は、ほぼ必ずコンピュータの数を上回ります。10 人くらいの子供が 1 台のパソコンの周りに集まっているのはありふれた光景で、通常、パソコンを占領しているのは地元のガキ大将と呼ばれる子供です。もちろん、パーソナル コンピュータの「パーソナル」という表現は、パソコンが 1 人で使用するために設計されていることに由来しています。Microsoft Research India では、より多くの子供たちがコンピュータを使用できるようにするにはどうしたらいいのか考えました。
解決策は驚くほど簡単なものでした。MultiPointTM を使用すると、複数の USB マウスを 1 台のコンピュータに接続し、各マウスを画面上のさまざまな色のカーソルに対応させることができます (research.microsoft.com/users/udaip/multipoint.htm)。MultiPoint により、ゲーム機のように複数人で操作できる環境が提供されるので、複数のマウスのパラダイムに対応するように記述された教育用のソフトウェアを使用すると、多くの子供たちが効率的に同時にパソコンを操作することができます。
大人は画面上が混乱状態に陥っていることを心配しますが、幼い生徒はすぐにこのパラダイムに慣れます。中学 1 年生の生徒を対象に、生徒 5 人で MultiPoint で構成されたパソコンを使用した場合と、生徒 1 人が 1 台のパソコンを使用した場合を比較する厳密な調査を行ったところ、調査員はいくつかの事柄を発見しました。まず、生徒各自がマウスを使用できる場合には、これが楽しさを増す要因であるかのように、より長い時間皆で一緒にパソコンを使用していました。また、徹底的な競争を促すのではなく、共同作業を支援するようなソフトウェア アプリケーションを設計することが重要だとわかりました。さもないと一部の生徒 (特に男子生徒) には、教育上の価値がほとんどない瞬間的な競争を行うという退行の機会を与えてしまいます。さらに、MultiPoint 対応のアプリケーションを使用した場合、共同作業が盛り込まれると、(少なくとも、簡単な単語を記憶する課題においては) 生徒は 1 台のパソコンを 1 人で占有した場合と同じぐらいの学習効果を発揮しました。この調査の詳細については、MultiPoint に関する上記のリンクを参照してください。
マウスは、大量に購入しても、1 個につき 2、3 ドルしかかかりません。つまり、学校に MultiPoint 対応の教育用アプリケーションを提供することで、コンピュータにかかる生徒 1 人あたりの費用を大幅に削減できます。たとえば、5 人の生徒が 5 ドルのマウスを使用して 500 ドルのパソコンを共有した場合は、生徒 1 人あたりの費用は 105 ドルになります。生徒 1 人あたりの費用を下げるものは、教育の予算を立てる人には歓迎されます。
マイクロソフトの Unlimited Potential グループ (microsoft.com/unlimitedpotential) と Education グループ (microsoft.com/education) では、リソースが不足している学校で MultiPoint を導入する価値を認識しています。これらのグループでは、MultiPoint の迅速かつ広範な導入を促進するために、ソフトウェア開発キット (SDK) をリリースしました。この SDK を使用すると、教育コンテンツの開発者は、この複数のマウスのパラダイムを C# アプリケーションに簡単に適用することができます。この SDK は無料でダウンロードおよび使用できます (microsoft.com/downloads)。また、MultiPoint 対応のアプリケーションは、Windows® ベースのすべてのコンピュータで実行できます。
Unlimited Potential の一環として実施しているプログラムの 1 つとして、この MultiPoint SDK は、できるだけ多くの生徒がパソコンの価値を体感できるようにすることを目標としています。これを行うには、皆さんの協力が必要です。MultiPoint を使用した教育用アプリケーションをお試しになりたい場合は、ご連絡ください。MultiPoint に関する厳選した Web サイトのリンクをご紹介します。
今後に関してですが、Microsoft Research India と Terminal Services 製品チームは、パソコンを共有するための新たな方法を検討しています。その方法は、分割画面です。この方法では、2 人のユーザーが 2 個のキーボードと 2 個のマウスを使用して、1 台のパソコンと 1 つのモニタを共有できるようにすることを目的としています。モニタの画面を中央で 2 つに分割することで、オペレーティング システムの個別のセッションをそれぞれの画面で実行することができるようになります。

Kentaro Toyama は、Microsoft Research India (research.microsoft.com/india) の取締役補佐を務めています。また、世界の経済的に貧しい国々のためにテクノロジを開発している Technology for Emerging Markets グループ (research.microsoft.com/research/tem) の主要調査員でもあります。


 Windows 秘話: 時代遅れの 16 ビット アイコン
Windows 秘話
時代遅れの 16 ビット アイコン
Raymond Chen

2008 年 2 月 の「Windows 秘話」コラムでご説明したように、Windows® では廃止される機能があります。機能の廃止は徐々に行われ、多くの場合いつの間にか行われています。ですが、製品チームでは、機能の廃止が決定するたびに、そのことを控えめに公表しています。32 ビット コードから 16 ビット モジュール (多くの場合は、16 ビットの EXE や DLL) に格納されているアイコンへのアクセスは、Windows Vista® で廃止された機能の一例です。
皆さんが心配しないようにお知らせしておきますが、16 ビット コードからは 16 ビット モジュールに格納されているアイコンに問題なくアクセスできます。この処理は、16 ビットのエミュレーション層で行われます。Windows Vista で廃止されたのは、32 ビット コードから 16 ビット モジュールに格納されているアイコンにアクセスする機能です。もっと具体的に説明すると、ExtractIcon 関数など、32 ビットの抽出関数で 16 ビット DLL に格納されている 16 ビット アイコンを読み込むことができなくなりました。
16 ビット モジュールに格納されているアイコンを抽出する 32 ビット コードでは、ファイル内のアイコンを特定する際に FindResouce 関数などのカーネル関数を使用することができません。このような 32 ビット コードでは、独自のミニローダーを実装する必要があり、それを使用して、16 ビット モジュールのヘッダーを解析し、リソース テーブルを検出し、リソース テーブルを解析して、必要なアイコン リソースを検出する必要があります。この一連の処理を行わなければ、32 ビット コードではピクセルをアイコンに変換できません。
ご想像のとおり、このような処理を行うコードは非常に旧式で脆弱です。バイナリ データは手違いまたは故意により破損していることがあり、バイナリ データの解析中にエラーが発生する可能性は十二分にあります。ファイルを開いたり、共有したりする方法が統一されていないと、ネットワークのキャッシュ機能にさまざまな影響を及ぼすので、ネットワーク パフォーマンスを向上するために、パフォーマンス チームから、ファイルを開く方法を変えるようにという要請があるでしょう。また信頼性チームからは、メモリ マップ ファイルを使用しないように、解析コードを書き直すようにという要請があるでしょう。このようなコードの保守にかかるコストが、コードの価値に見合わなくなるのは時間の問題です。と言うのも、今後、16 ビット プログラムを記述する人はいないからです。
16 ビットのエミュレーション層が存在する限り 16 ビット プログラムを実行することは可能です (64 ビット版の Windows Vista では 16 ビットのエミュレーション層はありませんが、これは Windows XP から後退したわけではなく、64 ビット版の Windows XP でも 16 ビットのエミュレーション層はありませんでした。この点に関しては Windows Vista では現状維持ということになります)。
Windows Vista で利用できなくなった機能は、32 ビット プログラムで ExtractIcon 関数を実行して、16 ビット DLL からアイコンを取得することだけです。[スタート] メニューに 16 ビット プログラムへのショートカットがある場合、エクスプローラでは、16 ビット プログラムのメイン .exe からアイコンを抽出できないので、そのショートカットのアイコンには、汎用的なプログラム アイコンが表示されます。これは、それほど大きな損失ではありませんが、この動作が問題になる場合は、当該ショートカットのプロパティを編集して、32 ビット モジュールのアイコンを指定できます。
この動作が問題になっているのを見たことは一度しかありません。それは、あるアイコン編集ツールを使用して作成したアイコン ライブラリです。どういうわけか、このプログラムでは、アイコンをリソースとして保存するとデフォルトで 16 ビットの DLL に格納されました。そのため、このプログラムで作成したアイコンには 32 ビット コードからアクセスできません。言うまでもないことですが、この問題の簡単な回避策は、アイコン ライブラリを 32 ビット DLL にリソースとして保存し直すことです。
今はなくても、今後、だれかが 16 ビット DLL のアイコンをすべて抽出し、そのアイコンを含む 32 ビット リソースのみで構成された DLL を作成する小さなプログラムを作成するのは間違いないと思います。このようなプログラムがあれば、16 ビット DLL に格納されている古いアイコンを [スタート] メニューのショートカットで使用できるようになります。しかし、正直なところ、このようなプログラムを記述しても、それを実際に必要とする人はおそらく存在しないでしょう。というのも、Windows ユーザー インターフェイス チームには、このようなプログラムを切望するユーザーからの声は 1 件も寄せられていませんから。

Raymond Chen は自分の Web サイト「The Old New Thing」および同じタイトルの書籍で、Windows の歴史と Win32 プログラミングについて扱っています。彼は扉から離れて立つことを心がけています。