 TechNet Magazine May 2007

TechNet Magazine May 2007

通信: Exchange Server 2007 の新しいモバイル メッセージング機能について学習する

モバイル メッセージングにより、人々の仕事の進め方が変化しました。そして、この変化のために、モバイル デバイスのセキュリティが大きな問題になっています。この記事では、Exchange Server 2007 により、どのようにユーザー エクスペリエンスが向上し、モバイル化が進むユーザーの管理が支援されるかを概説します。

Yee-Chen Tjie 通信: Exchange Server 2007 を使用して規制遵守を強化する

企業資産を保護し、規制遵守を保証する必要が生じたことで、IT 部門には大きな負担がかかっています。この記事では、Exchange Server 2007 の新機能が、データの保護と規制遵守の維持にどのように役立つかについて説明します。

Alan Maddison ID 管理: シングル ステップのプロビジョニング ワークフローを構築する

Web ベースのプロビジョニング システムをお探しですか。この記事では、MIISWorkflow を使用して、Microsoft Identity Lifecycle Manager 2007 に基づいたシングル ステップの自動ユーザー プロビジョニング システムを構築する方法について説明します。

Aung Oo Windows の管理: Windows PowerShell を使用してグループ ポリシーの管理を簡素化する

Windows PowerShell により、管理者の作業が大幅に簡素化されます。この記事では、Windows Scripting Host 言語向けに記述された GPMC API を Windows PowerShell から直接使用して、グループ ポリシーの管理を大幅に簡素化する方法について説明します。

Thorbjörn Sjövold Windows の管理: ターミナル サービス展開ガイド

組織のアプリケーションを一元的に実行することにはさまざまなメリットがあるため、現在では驚くほど簡単に実現できるようになりました。ここでは、Windows Server 2003 でターミナル サービスを有効にし、組織全体にターミナル サービスを実装するために、理解しておくべき情報を提供します。

James D. Silliman 編集者から: セキュリティのテイクアウト

Joshua Trupin レター: 質問への回答

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

Greg Steen SQL に関する Q&A: Best Practices Analyzer、マルチコア プロセッサなど

Edited by Nancy Michell ユーティリティ スポットライト: SharePoint サイトおよびテンプレート用のアップグレード ツールキット

Luis Câmara Manoel and Peter Skjøtt Larsen ビジネスにおける IT: ビジネス計画を練る

Stephen Ibaraki The Cable Guy: Windows の EAPHost

Joseph Davies Windows PowerShell: WMI との関係

Don Jones Hey, Scripting Guy!: 花が咲き、ダイアログが開き、春が来た

The Microsoft Scripting Guys Exchange Queue & A: OWA のタイムアウト、コマンドレットに関するトラブルシューティングなど

KC Lemson and Nino Bilic セキュリティ ウォッチ: ネットワーク アクセス保護

John Morello デスクトップ ファイル: Windows Deployment Services 再考

Wes Miller フィールド ノート: 遅れをとらないために

Joshua Hoffman Windows 秘話: よく使用するプログラムを決定する

Raymond Chen


 通信: Exchange Server 2007 の新しいモバイル メッセージング機能について学習する
通信 Yee-Chen Tjie

Exchange Server 2007 の新しいモバイル メッセージング機能について学習する
概要:
  • モバイル デバイスの構成
  • ポリシーの適用
  • 高度なメッセージング
  • モバイルでのファイル アクセス

ほんの数年前まで、デスクトップ コンピュータから離れた場所にいる場合に会社の電子メールにアクセスすることは、めったに行われることのない複雑な作業でした。今や、リモートから電子メールにアクセスできて当然と考えられるようになっただけでなく、
近所のコーヒー ショップでモバイル メッセージング デバイスを使っている人を目にすることも当たり前のようになりました。モバイル メッセージングにより、人々の仕事の進め方が変わりました。移動の多い従業員が、オフィスを離れている間も、より効率よく仕事を片付けられるようになりました。
しかし、このように近年のモバイル メッセージング テクノロジが発達したことで、モバイル デバイスのセキュリティが問題になっています。企業では、モバイル デバイス上にある機密性の高いビジネス データを保護するより良い方法を探しています。
Exchange Server 2003 と Exchange ActiveSync® と呼ばれるテクノロジが登場したことで、Windows Mobile® デバイス (Pocket PC Phone や Smartphone) から、HTTPS を使用して安全に Exchange Server 2003 に接続できるようになりました。ただし、モバイル デバイスの管理機能は欠けていました。Exchange Server 2003 Service Pack 2 (SP2) と Messaging and Security Feature Pack (MSFP) for Windows Mobile 5.0 のリリースにより、Exchange Server に接続するすべての Windows Mobile デバイスに適用されるグローバル ポリシーを設定できるようになりました。このポリシーを利用して、指定された文字数の PIN の指定を必須にしたり、操作が一定期間行われないとタイムアウトして PIN の入力を求めたり、PIN の入力が指定された回数失敗するとデバイス ワイプを実行したりできます。
Exchange Server 2003 SP2 では、Microsoft Exchange ActiveSync Mobile Administration Web ツール (図 1 参照) によるリモート ワイプ機能も追加されました。このツールを使用すると、紛失した Windows Mobile デバイスに対してワイプ コマンドを発行できます。このようなデバイスが Exchange Server に次に接続した時点で、ハード リセットが実行され、デバイスのメモリ内にあるすべてのデータが消去されます。
図 1 Microsoft Exchange ActiveSync Mobile Administration Web ツールのデバイス ワイプ機能
図 1 Microsoft Exchange ActiveSync Mobile Administration Web ツールのデバイス ワイプ機能
これは、モバイル デバイスの管理とセキュリティの第一歩としては有効でしたが、対応すべきセキュリティ要件はまだ多数残されていました。Exchange Server 2007 は、このような未対応の要件に対応するのに役立ちます。

デバイスの構成と適用
Exchange Server 2007 では、Exchange ActiveSync は、既定ですべてのメールボックス ユーザーに対して有効になります。この機能を一部のユーザーに対してのみ有効にする場合は、まずすべてのユーザーに対してこの機能を無効にします。Exchange 管理コンソールでは一部のユーザーに対して ActiveSync を無効にすることはできませんが、次のような Exchange 管理シェル コマンドを使用すると簡単にこの処理を実行できます。
Get-mailbox –server <servername> | Set-CASMailbox –ActiveSyncEnabled $false
このコマンドでは、Exchange Server 2007 サーバー上のすべてのメールボックスを取得し、パイプ文字の後の Set-CASMailbox コマンドにより、既存のすべてのメールボックスに対して ActiveSync を無効にしています。
次は、各自の組織に合わせて Exchange ActiveSync メールボックス ポリシーを作成します。作成するポリシーの数は、その組織のユーザーのセキュリティ プロファイルの多様性によって決まります。たとえば、財務関係の機密情報を電子メールで受け取る財務アナリストには、一般ユーザーよりも厳しいセキュリティ デバイス ポリシーが必要になるでしょう。
ActiveSync ポリシーを構成するには、Exchange 管理コンソールのナビゲーション ツリーで、[組織の構成] コンテナの [クライアント アクセス] を選択します。操作ウィンドウで、[Exchange ActiveSync メールボックス ポリシーの新規作成] を選択します。
[Exchange ActiveSync メールボックス ポリシーの新規作成] ダイアログ ボックスでは、添付ファイルのデバイスへのダウンロードを許可するかどうか、サポートしていないデバイスのアクセスを許可するかどうかを制御するための設定を使用して、柔軟なポリシーを作成できます (図 2 参照)。サポートされるデバイスとは、指定されたポリシーを適用および強制できる Windows Mobile デバイスです。サポートされないデバイスとは、ポリシーの一部 (またはすべて) が適用できないデバイスを指します。
図 2 Exchange Server 2007 ActiveSync メールボックス ポリシー
図 2 Exchange Server 2007 ActiveSync メールボックス ポリシー
他には、暗号化とパスワード回復の設定を構成する機能もあります。[デバイスでの暗号化を要求する] チェック ボックスをオンにすると、デバイスのメモリ カード上のすべてのファイルが暗号化されます。[パスワードの回復を有効にする] チェック ボックスをオンにすると、ユーザーがデバイスの PIN を Outlook® Web Access 2007 から取得できます。
デバイスのパスワード ポリシーは、適用する前に慎重に検討するようにしてください。文字数が多く複雑な PIN であればセキュリティは強化されますが、デバイスが使いにくくなる可能性もあります。パスワードの強度と PIN を要求するまでのタイムアウトの長さを決める上では、セキュリティとユーザービリティのバランスを取ることが重要です。[パスワードの有効期限 (日)] および [パスワード履歴を強制する] を指定することでも、セキュリティが強化されますが、パスワードと PIN の管理があまりに複雑になるとユーザーが負担に思う可能性があります。
Exchange Server 2007 ActiveSync メールボックス ポリシーは、デバイスのセキュリティ強化に有効ですが、この機能の一部は (本稿執筆時点でリリースされたばかりの) Windows Mobile 6.0 のみを対象としています。図 2 にある機能のうち、[デバイスでの暗号化を要求する]、[パスワード履歴を強制する]、および [パスワードの有効期限 (日)] は、いずれもこの新バージョンが必要です。ただし、Windows Mobile 5.0 をインストールしているデバイスのユーザーにも、新しい Exchange Server 2007 の柔軟なポリシーは利用できます。
ポリシーを定義したら、これをユーザーに適用できます。Exchange 管理コンソールで、[受信者の構成] の [メールボックス] を選択します。ActiveSync ポリシーを有効にするメールボックス ユーザーを選択し、操作ウィンドウで [プロパティ] を選択します。[メールボックスの機能] タブを表示し、[Exchange ActiveSync] をダブルクリックします。[Exchange ActiveSync プロパティ] ダイアログ ボックスで、[参照] ボタンをクリックし、ユーザーに適用する ActiveSync ポリシーを選択します (図 3 参照)。同じ手順を繰り返して、各ユーザーに別のポリシーを適用するか、以下の Exchange 管理シェル コマンドを使用して、任意のポリシーを複数のユーザーにまとめて適用できます。
図 3 ActiveSync メールボックス ポリシーの適用
図 3 ActiveSync メールボックス ポリシーの適用
Set-CASMailbox –Activesyncmailpolicy
最後に、エンド ユーザーとヘルプ デスクに説明を行います。エンド ユーザーに、Exchange Server 2007 に接続するときは、指定された文字数の PIN が必要になることを連絡します (図 4 参照)。ユーザーに対し適用されるセキュリティ ポリシーについて説明し、この変更がユーザーの日常業務に対する障害と見なされないようにします。
図 4 ActiveSync メールボックス ポリシーによる PIN の要求
図 4 ActiveSync メールボックス ポリシーによる PIN の要求
また、Exchange Server 2007 の新機能である Outlook Web Access 2007 を使用したユーザー自身によるリモート ワイプ機能についても、周知を図るとよいでしょう。ユーザーがデバイスを紛失した場合、ヘルプ デスクに連絡しなくても自分で Outlook Web Access の [オプション] リンクからデバイスのワイプを実行できます (図 5 参照)。これは、通常の業務時間外にデバイスを紛失した場合に、特に有用です。
図 5 Outlook Web Access を利用したデバイスの管理
図 5 Outlook Web Access を利用したデバイスの管理
また、ヘルプ デスクに、デバイスのリモート ワイプの操作方法を説明します。操作は簡単で、Exchange 管理コンソールを開き、[受信者の構成] の [メールボックス] を選択するだけです。そこから、ワイプの実行対象となるユーザーを選択して、操作ウィンドウの [モバイル デバイスの管理] を選択します。図 6 は、[モバイル デバイスの管理] インターフェイスです。ユーザーは Exchange Server 2007 に接続する複数の Windows Mobile デバイスを所有している場合があるので、ワイプを実行するときは、正しいデバイスを選択するよう十分に注意してください。
図 6 リモートからのユーザーのデバイスのワイプ
図 6 リモートからのユーザーのデバイスのワイプ

電子メールの処理と検索
Windows Mobile 6.0 では、HTML 形式の電子メールの表示や、不在メッセージの設定 (図 7 参照)、および電子メール メッセージのフラグ設定が可能です。Windows Mobile 6.0 デバイスでフラグを設定した電子メール メッセージは、Outlook で電子メールにフラグを設定したときと同じように扱われます。後で読み返すよう電子メール メッセージを未読に設定する代わりに、フラグを設定して、デスクに戻った時に Outlook の高度な機能を使用して処理できるようになりました。HTML 形式の電子メールを表示できることは、モバイル デバイス ユーザーだけでなく、その電子メール スレッドの他のユーザーにとってもメリットがあります。Windows Mobile 6.0 を使用して電子メールに返信すると、その電子メールはテキスト形式に変換されないため、Outlook を使用している他の電子メール受信者のエクスペリエンスも向上することになります。
図 7 不在時メッセージ
図 7 不在時メッセージ
Windows Mobile 6.0 の予定表には、大幅な機能強化が施されています。任意の予定表アイテムの転送、返信、または全員へ返信が可能なほか、すべての招待者の受諾状態を確認できるようになりました。
Windows Mobile 6.0 を Exchange Server 2007 と連携して使用する場合、検索およびモバイルでのドキュメント アクセスに関する 2 つの新機能を利用できます。モバイル デバイスの使用に伴う課題の 1 つは、記憶域容量が限られていることです。このために、ユーザーの多くは 1 ～ 3 日しか電子メールをデバイス上に保持していません。また、受信トレイ中の 1 フォルダの電子メール メッセージしか取得しないようにしている場合も多くあります。このような必要最低限の利用方法では、古いメッセージや、メールボックスの別のフォルダに格納されているメッセージにアクセスする必要があるときに、問題になる可能性があります。
Windows Mobile 6.0 では、Exchange Server 2007 の検索とインデックスのエンジンを利用して、メールボックス全体の検索をモバイルで実行できます。電子メール検索は、キーワードを基に複数のフォルダに対して実行されます (図 8 参照)。その後、検索結果から電子メール メッセージがリアルタイムで取得されます。
図 8 モバイルでの電子メール検索
図 8 モバイルでの電子メール検索

モバイルでのドキュメント アクセス
SharePoint® などのドキュメント コラボレーション ソフトウェアの発達と、転送可能な電子メールの最大サイズの制限のために、ユーザーは電子メールへのドキュメントの添付を避けて、ファイル共有や SharePoint サイトへのリンクを送るようになっています。仮想プライベート ネットワーク (VPN) を利用して社内ネットワークにアクセスできないと、モバイル デバイスからこのようなドキュメントにアクセスすることは不可能に思えます。移動の多いユーザーにとって、これは業務上の障害になる可能性があります。
Windows Mobile 6.0 と Exchange Server 2007 を利用すると、ユーザーは UNC ファイル共有または SharePoint サイトを使用して、読み取り専用モードでデータにアクセスすることができます。Exchange Server 2007 は、このようなドキュメントに対する要求を Windows Mobile デバイスの代理で処理できます (図 9 参照)。社内ネットワークへの VPN 接続がない場合でも、ユーザーは電子メール メッセージに添付されたドキュメントだけでなく、ファイル共有や SharePoint サイト内のドキュメントにアクセスすることができます。
図 9 UNC リンクによるドキュメント アクセス
図 9 UNC リンクによるドキュメント アクセス
モバイルでのドキュメント アクセスを管理するには、Exchange 管理コンソールを開き、ナビゲーション ツリーで [サーバーの構成] の [クライアント アクセス] を選択します。[Exchange ActiveSync] タブで、[Microsoft-Server-ActiveSync] オブジェクトを選択し、操作ウィンドウで [プロパティ] をクリックします。[リモート ファイル サーバー] タブでは、各 SharePoint サイトやファイル サーバーのホスト名ごとに、許可リストや禁止リストを構成できます。
ファイル共有] チェック ボックスと [Windows SharePoint Services] チェック ボックスがオンになっていることを確認します (図 10 参照)。
図 10 ドキュメント アクセスの有効化
図 10 ドキュメント アクセスの有効化
すべての Windows Mobile デバイス ユーザーによりよいドキュメント アクセスを提供できるよう、以上の情報をお役立てください。

まとめ
現在のリモート ワーカーの世界において、Windows Mobile デバイスは時と場所を選ばずに情報にアクセスできる強力な手段を提供しています。モバイル デバイスのセキュリティと管理は、IT 部門にとって大きな課題となっています。Exchange Server 2007 と Windows Mobile 6.0 を合わせて利用することで、課題の軽減だけでなく、リモート ワーカー向けの新機能の基盤作りにも役立つ、Windows Mobile デバイス用のポリシーを容易に作成および適用できます。
Windows Mobile の関連情報
Exchange Server 2007 の展開および Windows Mobile メッセージングの詳細については、さまざまなリソースを利用できます。
  • Exchange Server TechCenter
  • Exchange 2007 に対するモバイル アクセスの基礎知識
  • Exchange ActiveSync の管理
  • Windows Mobile バーチャル ラボ
  • Windows Mobile 6 SDK

Yee-Chen Tjie は、ニュー イングランド地区担当のマイクロソフトのテクノロジ スペシャリストです。専門は、モビリティと統合通信ソリューションです。
© 2007 Microsoft Corporation and CMP Media, LLC. All rights reserved; 許可なしに一部または全体を複製することは禁止されています.


 通信: Exchange Server 2007 を使用して規制遵守を強化する
通信 Alan Maddison

Exchange Server 2007 を使用して規制遵守を強化する
概要:
  • 管理フォルダ
  • トランスポート ルール
  • メッセージ分類
  • ジャーナリング

アナリストの予測によると、企業の文書の 75% は電子メールで作成および伝達されています。おそらく、組織の知的財産のかなりの部分が、メッセージング サーバーに依存しています。
このため、メッセージング サーバーの管理者には、多くの責任が委ねられるようになりました。これは、メッセージング サーバーに企業の重要なデータの大半が格納されるようになったためです。さらに、企業データの保存に関する要件が指定された、連邦規制または地方規制の数が (米国でもその他の国でも) 増加しているため、この仕事の複雑さと重要度は高まっています。
企業資産を保護し、規制遵守を保証する必要が生じたことで、IT 部門には大きな負担がかかっています。Exchange Server 2007 の設計に際しては、Exchange の規制遵守機能を大幅に強化すると同時に、実際の管理作業を簡略化するための多くの変更や新機能が実装されました。この記事では、規制遵守に役立つ Exchange Server 2007 の主要な変更点について説明します。

規制遵守について
Exchange Server 2007 について説明する前に、対処する規制遵守要件について述べておく必要があります。通常、規制遵守要件は、情報の保存、アクセス制御、データの整合性という 3 つの大まかな分野に分かれています。たとえば米国の SEC 規則 17A-4 では、証券取引所の特定の構成員、ブローカー、およびディーラーを対象とした、データの保存に関する方針が規定されています。この規則は、電子メールのキャプチャ、インデックス付け、アーカイブ、検索、および取得を実行できる環境を用意することを金融機関に求めています。データへのアクセスの制御は、医療保険の携行性と責任に関する法律 (HIPAA)、グラム リーチ ブライリー法 (GLB Act)、およびカリフォルニア州上院法案 1386 (SB 1386) など、多くの有名な法律で規定されています。HIPAA と GLB Act は、個人データのセキュリティと機密保持について規定しており、SB 1386 では、コンピュータが機密データに関連するセキュリティ侵害を受けた場合、その内容を一般公開することを義務付けています。
さらに、データの整合性に関する要件は、サーベンス オクスリー法 (SOX)、米国愛国者法、およびバーゼル II など、その他の重要な法律で規定されています。しかし、このような知名度の高い規制は、氷山の一角にすぎません。世界中で施行されている規制の数は 35,000 件を超えるという予測もあります。このため、企業が、情報の保存、データへのアクセスの制御、およびデータの整合性の保証に関連するリスクを管理する必要があることは明らかです。では管理者として、このリスクを管理し、これらすべての規制を遵守する義務を果たすにはどうすればよいでしょうか。
まずは、規制遵守とデータ保存に関するポリシーを文書化します。次に、これらのポリシーを実装し、継続的に管理します。Exchange Server 2007 では、管理フォルダ、トランスポート ルール エージェント、メッセージ分類、およびジャーナリング エージェントを使用して、これらのポリシーを制定できます。

管理フォルダ
データの保存 (またはレコードの管理) は、規制遵守フレームワークの重要な部分です。Exchange Server 2007 では、管理者がデータを管理するための方法が大幅に強化されました。Exchange Server 2007 のレコードの管理は、古いメッセージは削除する、必要なメッセージは保存する、ユーザーは各自でメッセージを分類する責任がある、という 3 原則に基づいて行われます。
ほとんどの Exchange 管理者にとって馴染みがあるのは、メールボックスに適用できる、Exchange Server 2003 メールボックス マネージャのポリシーです。Exchange Server 2007 の管理フォルダを使用すると、移動や名前の変更ができず、ほとんどの場合は削除もできない、新しい既定のフォルダやカスタム フォルダの作成と展開を一元的に行うことができます。また、SDK を使用すると、メールボックスに追加するフォルダをユーザーが選択できる、Web ベースのセルフサービス アプリケーションを作成することもできます。
図 1 に示されているように、Exchange 管理コンソールには、フォルダを作成するためのウィザードが用意されています (この操作は、Exchange 管理シェルで New-ManagedFolder コマンドレットを使用して実行することもできます)。
図 1 Exchange 管理コンソールを使用した新しいフォルダの作成
図 1 Exchange 管理コンソールを使用した新しいフォルダの作成
図 1 の操作を行うと、図 2 のようなウィザードが起動します。フォルダの作成手順は非常に簡単です。フォルダの名前と説明を入力して、[新規作成] をクリックするだけです。フォルダの作成が完了すると、確認画面が表示されます。
図 2 新しい管理フォルダを簡単に作成できる直感的なウィザード
図 2 新しい管理フォルダを簡単に作成できる直感的なウィザード
データの保存ポリシーが用意できたら、ユーザーにメッセージの並べ替えと保存を行うための単純な方法を提供し、データが組織の要件に従って保存されるようにする必要があります。たとえば、ユーザーが 3 年間保存するメール、5 年間保存するメール、および 7 年間保存するメールを区別できるように、3 つのカスタム フォルダを展開することが考えられます。管理フォルダを作成したら、次は各フォルダにコンテンツの設定を適用します。これを行うには、管理コンテンツの設定の新規作成ウィザードを使用します。
メッセージング管理者は、コンテンツの有効期間 (日数で計算されます) の設定、および有効期限が切れた際にコンテンツに対して実行されるアクションの設定を管理します。実行できるアクションには、次の 5 つがあります。
  • 削除して回復を許可する
  • 保存期限経過としてマークする
  • 管理されたカスタム フォルダに移動する
  • 削除済みアイテム フォルダに移動する
  • 完全に削除する
これらの設定を構成する際に、特に細心の注意を払う必要があるパラメータが 3 つあります。1 つ目はメッセージの有効期間の値です。この値は日数で計算されるため、うるう年を考慮する必要があります。企業の経営陣 (裁判官は言うまでもありません) は、予定よりたった 1 日早くコンテンツが削除されただけでも困惑します。2 つ目のパラメータは有効期間の開始日です。通常、法務部門から特別に指示がない限り、メッセージがメールボックスに配信された日を開始日にします。3 つ目のパラメータは、コンテンツの有効期限が切れた際にコンテンツに対して実行されるアクションです。推奨されるアクションは、コンテンツを完全に削除することです。コンテンツの設定を使用すると、メッセージを SMTP アドレスに転送することによって、メッセージのジャーナルを作成することもできます。
管理フォルダの適用は、管理フォルダ メールボックス ポリシーを使用して行います。Exchange 管理コンソールでは、これらのポリシーを作成するためのウィザードが別に用意されています。管理フォルダ メールボックス ポリシーを使用すると、複数のフォルダを選択してグループ化することができます。これにより、複数のフォルダを 1 つのポリシーに関連付けることができます。
通常は、メールボックスの作成時に管理フォルダ メールボックス ポリシーを適用します。または、Exchange 管理シェルで Set-Mailbox コマンドレットを使用して、既存のメールボックスにポリシーを適用することもできます。たとえば、"retention" (保存) という名前の管理フォルダ メールボックス ポリシーを、USER1 というエイリアスを持つ電子メール アカウントに適用するとします。これを行うには、次のコマンドを実行します。
Set-Mailbox –Identity USER1
–ManagedFolderMailboxPolicy “retention”
管理フォルダ、および対応するコンテンツの設定により、保存および規制遵守プロセスを管理するための強力なメカニズムが提供されます。ユーザーは、このメカニズムを使用すると、関連する電子メールを並べ替えたり、一元管理されたフォルダにデータを保存したりできるだけでなく、これらのアイテムのジャーナルを作成し、情報の開示要求や保全命令が出された場合に簡単に裁判所の要求に応じることができるようになります。

トランスポート ルール
Exchange Server 2007 には、2 つのトランスポート ルール エージェントがあります。ただし、規制遵守に関係があるのは、ハブ トランスポート サーバー上で動作するエージェントだけです。このエージェントを使用すると、Exchange 組織内を流れるメッセージにポリシー ベースの規制遵守ルールを適用できます (一方、エッジ トランスポート サーバーのルール エージェントは、組織をスパムやウイルスから保護するのに役立ちます)。
管理者が実装する必要がある一般的な規制遵守の要件には、以下のようなものがあります。
  • 異なるグループに属する送信者と受信者の間の通信を制限すること
  • 不適切なコンテンツが企業に入り込んだり企業から流出したりするのを防ぐこと
  • 機密情報をフィルタ処理すること
  • 特定のユーザーやグループに送信されたメッセージ、および特定のユーザーやグループから受信したメッセージの追跡やアーカイブを行うこと
  • 受信メッセージと送信メッセージをリダイレクトし、配信前に検査すること
  • 免責事項を適用すること
ハブ トランスポート サーバーは、Exchange 2007 トポロジでこのサーバーが果たす役割から、トランスポート ルール エージェントとして選択されました。Exchange 2007 ではトポロジに大幅な変更が加えられ、その結果、Exchange がさらに密接に Active Directory® トポロジと統合されました。組織内を流れるメールは、ある時点で必ずハブ トランスポート サーバーによって処理されます。ハブ トランスポート サーバーは Active Directory に現在のトランスポート ルールの構成を照会し、処理するすべてのメッセージにそのルールを適用します。
あるハブ トランスポート サーバーで構成されたすべてのトランスポート ルールは、Active Directory サービスによって他のすべてのハブ トランスポート サーバーにレプリケートされます。このため、管理しているサイトとトポロジがレプリケーションに与える影響、および組織規模のルールの展開にかかる時間を知っておく必要があります。
また、ハブ トランスポート サーバーでは、受信者や配布リストの参照のために受信者のキャッシュが保持されることも覚えておく必要があります。さらに、更新間隔 (既定では 4 時間) が、メッセージにルールが適用されるタイミングに影響を与えることにも注意してください。
ハブ トランスポート サーバーのトランスポート ルールは、認証されたユーザー間で送信された、会議出席依頼、通常のメッセージ、暗号化されたメッセージ、および権限が保護されたメッセージをすべて評価します。また、匿名で送信された電子メール メッセージは、メッセージの種類、送信者、受信者にかかわらず、すべて評価されます。
各トランスポート ルールは、条件、例外、およびアクションという要素から構成されます。条件は、メッセージの識別処理に使用するメッセージ属性 (ヘッダー、受信者、送信者など) を指定するために使用されます。メッセージが特定のルールの条件をすべて満たした場合、そのメッセージが構成済みの例外に該当しない限り、アクションが適用されます。例外は構成しなくてもかまいません。例外を構成した場合、トランスポート ルールは、その例外基準のいずれかを満たしたメッセージの処理を停止します。アクションは、各トランスポート ルールで必ず構成する必要があります。アクションにより、メッセージの処理方法が指定されます。図 3 は、ハブ トランスポート サーバーで構成されたトランスポート ルールに基づいて適用できるアクションの一覧です。
Figure 3 ハブ サーバーのトランスポート ルールで実行できるアクション (Close Figure 3)

アクション | アクション名 | 説明
メッセージに関するイベントをログに記録する | LogEvent | ローカル コンピュータのアプリケーション ログにイベントを追加します。
件名の先頭に文字列を追加する | PrependSubject | メッセージの "件名" フィールドの先頭に文字列を追加します。
メッセージ分類を適用する | ApplyClassification | メッセージにメッセージ分類を適用します。
免責事項を追加する | ApplyDisclaimer | メッセージに免責事項を適用します。
値に Spam Confidence Level を設定する | SetScl | メッセージに Spam Confidence Level (SCL) を設定します。
ヘッダーに値を設定する | SetHeader | 新しいメッセージ ヘッダー フィールドを作成するか、既存のメッセージ ヘッダー フィールドを変更します。
ヘッダーを削除する | RemoveHeader | 指定したメッセージ ヘッダー フィールドをメッセージから削除します。
"宛先" フィールドのアドレスに受信者を追加する | AddToRecipient | メッセージの "宛先" フィールドのアドレス一覧に 1 人以上の受信者を追加します。元の受信者は追加のアドレスを見ることができます。
メッセージをアドレスにコピーする | CopyTo | メッセージの CC (カーボン コピー) フィールドに 1 人以上の受信者を追加します。元の受信者は元のアドレスを見ることができます。
メッセージをアドレスにブラインド コピーする | BlindCopyTo | メッセージの BCC (ブラインド カーボン コピー) フィールドのアドレス一覧に 1 人以上の受信者を追加します。
メッセージをアドレスにリダイレクトする | RedirectMessage | 管理者が指定した 1 人以上の受信者にメッセージをリダイレクトします。メッセージは元の受信者には配信されず、受信者や送信者には通知が送信されません。
拡張状態コードを付けて送信者にバウンス メッセージを送信する | RejectMessage | メッセージを削除し、送信者に配信不能レポートを送信します。受信者は、メッセージまたは通知を受信しません。
メッセージを確認なしで削除する | DeleteMessage | メッセージを削除します。受信者や送信者には、通知は送信されません。
トランスポート ルールを作成するには、Exchange 管理コンソールから、トランスポート ルールの新規作成ウィザードを実行します (図 4 を参照)。または、Exchange 管理シェルからスクリプトを実行してルールを作成することもできます。
図 4 ハブ トランスポート サーバーのトランスポート ルールを構成できる、トランスポート ルールの新規作成ウィザードの起動操作
図 4 ハブ トランスポート サーバーのトランスポート ルールを構成できる、トランスポート ルールの新規作成ウィザードの起動操作
また、SDK を使用して、Exchange 内の SMTP イベントに基づいてメッセージを処理するトランスポート エージェントを独自に記述することもできます。ただし、これはそれほど単純な作業ではありません。

メッセージ分類
新しいメッセージ分類ツールは、メタデータによって特定のメッセージの使用目的や対象者を説明するために使用します。クライアント側では、このメタデータを Outlook® Web Access (OWA) や Outlook 2007 で使用して、ユーザーが読める形式で分類の説明を表示することができます。サーバー側では、トランスポート ルール エージェントがメッセージ分類に基づいてメッセージを処理することができます。
Exchange Server 2007 に含まれている既定のメッセージ分類は、A/C 特権 (弁護士/クライアント特権)、添付ファイル削除済み、企業秘密、および企業内部です。しかし、多くの組織では独自の分類を作成することが必要になる場合があります。新しい分類を作成するには、Exchange 管理シェルで new-MessageClassification コマンドレットを実行します。たとえば、財務データへのアクセスを制限する必要がある場合は、次のコマンドを実行して、"Financial - Confidential" (財務 - 機密事項) というメッセージ分類を作成することができます。
new-MessageClassification –Name finance –DisplayName “Financial—Confidential”
-RecipientDescription “This message contains confidential financial data.”
–SenderDescription “Restricts recipients of messages that contain confidential financial data”
必須のパラメータは Name、DisplayName、SenderDescription の 3 つだけですが、基本的な機能を実装するには、少なくとも RecipientDescription を追加する必要があります。図 5 は、OWA インターフェイスに表示された、この新しい分類を示しています。
図 5 新しく作成した "Financial - Confidential" が含まれたメッセージ分類の一覧
図 5 新しく作成した "Financial - Confidential" が含まれたメッセージ分類の一覧
このコマンドではロケール パラメータを使用しないため、Exchange 組織内の全ロケールにこのコマンドが適用されます。世界規模での運用をサポートしている場合は、ロケール別のメッセージ分類を作成する必要が生じることがあります。
また、分類にアクセス許可を正しく設定する必要があります。既定では、新しく作成されたすべてのメッセージ分類に関して、認証されたユーザーに読み取りアクセス許可が与えられます。ただし、ユーザーが各自の役割に適したメッセージ分類だけにアクセスできるように、作成した複数のメッセージ分類を分割する必要があります。また、各分類には、他のメッセージ分類に対する相対優先順位を指定することができます。この優先順位により、記述の順序が指定され、転送されるメッセージや返信されるメッセージに関連付けられる分類が決定されます。
必要な分類を作成したら、次は、それらの分類を使用するトランスポート ルールを作成します (もちろん、これらのメッセージ分類にアクションを関連付けず、単に情報を提供するためだけに使用してもかまいません)。図 6 に示されているように、メッセージ分類をトランスポート ルールと組み合わせる際には多くのオプションを使用できます。ここでは、"Financial" (財務) と分類されたメッセージがあるかどうかを監視するトランスポート ルールを作成しました。メッセージが "Financial" と分類された場合、トランスポート ルール エージェントによってそのメッセージの受信者が調べられます。受信者の中に "Financial Dept" (財務部門) 配布グループに属していないユーザーが存在した場合、メッセージは、カスタムの配信不能メッセージと共に送信者に返送されます。
図 6 Financial と分類されたメッセージに適用するトランスポート ルールの作成
図 6 Financial と分類されたメッセージに適用するトランスポート ルールの作成
メッセージ分類を使用すると、組織内に "倫理的境界" を設けることもできます。たとえば、特定の個人間や部門間の通信を制限することが必要になる場合があります。メッセージ分類を使用して、この操作を行うことができます。

ジャーナリング エージェント
規制遵守を保証する際、ジャーナリングが強力な (しかし時として複雑な) 手段となる場合があります。さいわい、Exchange Server 2007 には、柔軟性が大幅に向上したジャーナリング機能が用意されています。Exchange Server 2007 では、標準ジャーナリング (メールボックス データベースごと) と新しいプレミアム ジャーナリング (受信者ごと) の両方がサポートされています。プレミアム ジャーナリングを使用すると、個々のユーザーや配布グループのジャーナルを作成できます。これにより、要求 (保持要求や、裁判所から出された保全命令など) を遵守するための手順がはるかに単純になります。また、ジャーナリングが記憶域やパフォーマンスに与える影響をより細かく制御できるようになります。
新しいジャーナリング機能の中で、最も柔軟性が高いものの 1 つは、動的配布グループに基づいたジャーナリングのサポートです。たとえば、組織で、特定の個人の電子メール メッセージを継続的に保持しておく必要があるとします。これは、組織内の人事調査または訴訟を目的とした場合などが考えられます。管理者は、動的配布グループを使用すると、既にジャーナルが作成されている設定済みのグループにユーザーを追加したり、このグループからユーザーを削除したりすることができます。これにより、その場に応じたジャーナリングをすばやく簡単に提供できます。
Exchange 管理コンソールと、動的配布グループの新規作成ウィザードを使用すると、ユーザー コンテナを選択し、特定の Active Directory 属性の値に基づいて、配布グループに含めるメールボックスをフィルタ処理できます (図 7 を参照)。管理者は、いずれかのカスタム属性 (図 7 を参照) を選択し、この属性の値を追加または削除することにより、どのユーザーのジャーナルを作成するかを制御できます。
図 7 動的配布グループの新規作成ウィザードを使用したジャーナリング ルールの構成
図 7 動的配布グループの新規作成ウィザードを使用したジャーナリング ルールの構成
Exchange 2007 のジャーナリングに関する詳細な説明については、2006 年 12 月号の David Strome による記事「Exchange 2007 の強化されたジャーナリング」を参照してください。その他の情報については、「ジャーナリングの概要」を参照してください。

Alan Maddisonは、MTI Technology Corporation でマイクロソフト テクノロジの導入支援を担当しているシニア コンサルタントです。主な担当分野は、Active Directory、Exchange Server、および仮想化です。


 ID 管理: シングル ステップのプロビジョニング ワークフローを構築する
ID 管理 Aung Oo

シングル ステップのプロビジョニング ワークフローを構築する
概要:
  • MIISWorkflow を使用する
  • 実装と構成
  • MIISWorkflow を拡張する

アカウントの要求と承認を行うための Web ベースのインターフェイスを探していて、組織で Microsoft Identity Lifecycle Manager 2007 (ILM 2007、以前は Microsoft Identity Integration Server 2003) を使用している場合、MIISWorkflow アプリケーションにより、単純かつ効率的な解決策が提供される可能性があります。
MIISWorkflow は MIIS 2003 Resource Tool Kit 2.0 に含まれており、2004 年 12 月から提供されています。このアプリケーションは、すべての環境にとって必ずしも最適な解決策ではありませんが、組織のニーズに合ったカスタム アプリケーションを構築するための基盤として適しています。
MIISWorkflow は、Web アプリケーションを統合することにより、承認ベースのプロビジョニング機能を ILM 2007 に提供します。このアプリケーションは、ユーザーからの要求を受け取り、特定の要求に関する判断を下す権限を持つ承認者 (通常は管理者) に中継する、ワークフロー主導のシングル ステップのプロビジョニング システムです。ILM は、この承認者の判断に基づき、ILM で定義されたビジネス ルールを使用して、接続されたディレクトリでユーザー アカウントのプロビジョニングを実行します。
このアプリケーションによって効率化できるのは、シングル ステップのワークフローのみです。複数のパスを持つマルチ ステップの承認プロセスや、グラフィカル インターフェイスを使用するワークフロー プロセスなど、複雑なワークフロー機能を作成することはできません。組織でこのような複雑なワークフロー機能を使用する必要がない場合は、MIIS Resource Tool Kit で提供される MIISWorkflow サンプルを使用して、ソリューションを実装できます。
この記事では、架空の会社の人事部門のシナリオについて考えてみます。一般に、人事システムは、組織内のすべての従業員情報が格納された、信頼できるデータ ソースとしての役割を果たしています。しかし、通常これらのシステムには、正社員の詳細なデータは格納されていますが、契約社員やインターンの学生などの臨時職員に関する情報は格納されていないことがよくあります。人事システムに格納されているデータでは、ユーザー アカウント情報など、ユーザーがアクセスできるシステムについての情報が追跡できない場合があります。ここでは、組織内の臨時職員を追跡するための単純なシステムを構築する方法について説明します。

MIISWorkflow を基にアプリケーションを構築する
組織で MIISWorkflow を活用する方法の 1 つは、既存の人事システムと組み合わせて使用できるアプリケーションを作成することです。新しい従業員を雇用すると、ユーザー情報が人事システムに追加されます。その情報を MIISWorkflow データベースに送信し、ワークフロー アプリケーションを使用して承認者に中継した後、ILM が接続されたディレクトリでアカウントのプロビジョニングを行うように、ILM のフローを設計できます。
組織で臨時職員の追跡に人事システムを使用していない場合は、MIISWorkflow アプリケーションを信頼できるデータ ソースとして使用することにより、企業ディレクトリ内で臨時職員のアカウントを管理できます。ワークフロー アプリケーションにより、承認を得るための紙ベースの管理作業が減少するため、ユーザーはディレクトリやアプリケーションのアカウントにアクセスするために何日も待つ必要がなくなります。また、MIISWorkflow を使用すると速やかにアクセスを失効させることもできるため、組織のセキュリティが強化されます。
MIISWorkflow は、ユーザーがアクセスできるシステムの数、各アカウントを要求および削除した日付、および各アカウントの要求者と承認者を追跡するための監査ツールとしても使用できます。このアプリケーションでは、アカウントの詳細な履歴が記載されたレポートを生成できるため、組織で SOX 法や HIPAA などの法規制を順守しているかどうかを確認するのに役立ちます。
MIISWorkflow アプリケーションは IIS 上で実行され、ILM 2007 のディレクトリ統合機能とプロビジョニング機能を使用して、接続されたディレクトリでアカウントのプロビジョニングとデプロビジョニングを実行します。このワークフロー アプリケーションのコンポーネントには、ASP.NET Web ページのコレクション、SQL Server™ データベース、管理エージェント、および承認ポリシー ストアが含まれています (図 1 を参照)。このアプリケーションでは、データ ストレージに SQL Server を使用し、認証に Active Directory® を使用し、承認に Windows® 承認マネージャ (AzMan として一般に知られています) のポリシー ストアを使用します。
図 1 MIISWorkflow アプリケーションのアーキテクチャ
図 1 MIISWorkflow アプリケーションのアーキテクチャ
このアプリケーションは、C# と ASP.NET を使用して拡張およびカスタマイズできます。MIISWorkflow は、ContractorApproval、ContractorHistory、ContractorRequest、ContractorStatus、および ContractorUpdate という 5 つの .aspx ページから構成されています。管理者はこれらのページを使用して、システム内の各ユーザー アカウントの状態を要求、更新、承認、および追跡できます。既定では、MIISWorkflow アプリケーションは、Kerberos を利用する IIS 統合 Windows 認証を使用するように設定されていることに注意してください。
ワークフロー アプリケーションが承認者の操作に基づいて ILM を起動した後、ILM が定義済みのルールを使用して、接続されたディレクトリでユーザー アカウントのプロビジョニングまたはデプロビジョニングを実行します。ワークフロー アプリケーションは、要求に対して操作が行われた直後に ILM を起動するため、接続されたディレクトリで要求のプロビジョニングとデプロビジョニングを実行するために、次回の ILM の同期サイクルが発生するのを待つ必要はありません。
ワークフロー アプリケーションでは、MIISWorkflow データベースにユーザーのアカウント情報を格納する必要があります。このデータベースは ILM がメタバース情報を格納するデータベースとは異なりますが、同一の SQL Server インスタンス上で構成されます。権限を与えられたユーザーがワークフロー アプリケーションを使用してアカウントを要求すると、MIISWorkflow によってそのアカウント情報が保存されます。この情報は、その後、承認者用の ASP.NET Web ページに表示されます。MIISWorkflow では、操作の履歴や、アカウントに関するその他の情報もデータベースに保存されます。ILM は、アプリケーションに付属している SQL Server 管理エージェントを使用して、MIISWorkflow データベースからその情報をインポートし、要件に合わせてそのアカウントのプロビジョニングまたはデプロビジョニングを実行します。
MIISWorkflow が承認に使用する AzMan では、ユーザーがアプリケーションで実行できるタスクを、それらのユーザーに割り当てられた役割に応じて管理する、役割ベースのアクセス制御 (RBAC) が提供されます (RBAC の詳細については、go.microsoft.com/fwlink/?LinkId=85825を参照してください)。ユーザーが Active Directory で認証された (つまりアクセスを許可された) 後、ワークフロー アプリケーションは AzMan の承認ストアで定義されている役割を確認して、ユーザーが実行できる操作を承認します。このアプリケーションには、"contractor requestor (契約者の要求者)" と "contractor approver (契約者の承認者)" という 2 つの定義済みの役割が用意されています。"契約者の要求者" の役割を与えられたユーザーまたはグループは、このアプリケーションで要求を作成することしかできませんが、"契約者の承認者" の役割を与えられたユーザーまたはグループは、要求の作成と、要求の承認または拒否を行うことができます。
MIISWorkflow アプリケーションの承認ポリシーは、XML ファイルに格納されます。定義済みの役割を割り当てることができるのは、Windows ユーザーおよびグループ、またはアプリケーション グループのいずれかです。アプリケーション グループを使用すると、LDAP クエリによって、アプリケーションの実行時にユーザーの Active Directory または Active Directory Application Mode (ADAM) アカウント オブジェクトを属性の値に基づいて検索できます。たとえば、ユーザーが特定のグループに属している (department=‘marketing’) かどうかを検索し、true を返したりすることができます。

アプリケーションのウォークスルー
アプリケーションの管理者は、AzMan を使用してアプリケーションへのアクセスを制御します。組織でこのアプリケーションをどのように利用するかに応じて、"契約者の要求者" の役割をすべてのドメイン ユーザーか、または選択されたグループのみに割り当てることができます。"契約者の承認者" の役割は、要求を承認または拒否する権限を持ったユーザーおよびグループのみに割り当てる必要があります。通常は、特定の人事管理者や、システムおよびグループ管理者にこの役割を割り当てます。既定では、MIISWorkflow アプリケーションは IIS 統合 Windows 認証を使用して認証を行うため、Windows のデスクトップ ログオン資格情報を使用してユーザーを認証します。このため、ユーザーはアプリケーションに対して認証を行うために再度資格情報を要求されることはありません。
"契約者の要求者" の役割を与えられたユーザーは、ブラウザ内でアプリケーションの契約者の要求ページに移動し、契約者の情報を入力して、その契約者のアカウントを要求することができます。図 2 は、契約者の要求ページを示しています。
図 2 [New Contractor Request] (新しい契約者の要求) ページ
図 2 [New Contractor Request] (新しい契約者の要求) ページ
要求者の役割を与えられたユーザーは、契約者に関する適切な情報を入力し、要求を送信します。このページには、要求を承認するためのリンクと状態を確認するためのリンクも含まれていますが、要求者は "契約者の承認者" の役割も与えられていない限り、承認者用のページにアクセスすることはできません。要求者は [Contractor Status] (契約者の状態) リンクをクリックすると、自分が送信した要求の状態を表示することができますが、他の要求者が送信した要求の状態を表示することはできません。
アプリケーション内の契約者の承認ページにアクセスできるのは、契約者の承認者のみです。承認者はこのページで、要求に関する情報を確認した後、その要求を承認または拒否できます。図 3 は、[Contractor Approval] (契約者の承認) ページのインターフェイスを示しています。
図 3 [Contractor Approval] (契約者の承認) ページ
図 3 [Contractor Approval] (契約者の承認) ページ
契約者の承認者は、すべての要求者が送信した要求を表示できます。どの承認者でも要求を承認することができ、承認または拒否操作を 1 回行うだけで、要求を次の段階に進めることができます。承認者が承認または拒否操作を行うと、その要求は契約者の承認ページに表示されなくなります。このため、承認者が行う余分な操作が最低限に抑えられます。
このアプリケーションには、承認者に新しい要求やバックログがあることを通知するメカニズムがないため、承認者は、新しい要求を確認したり、組織の要件に基づいて保留中の要求に対する操作を行ったりするために、定期的に契約者の承認ページにアクセスする必要があります。このページから承認者が要求を承認または拒否した直後、アプリケーションは ILM を起動し、接続されたディレクトリで、承認者の操作に基づいてアカウントのプロビジョニングまたはデプロビジョニングを実行します。
図 4 契約者の状態ページ
図 4 契約者の状態ページ
契約者の状態ページ (図 4 を参照) では、保留中の要求の状態と、操作が完了した要求の履歴を追跡できます。要求者はこのページでいくつかの操作を実行できます。たとえば、従業員 ID、姓、名、部門、状態、最終更新日時など、自分が送信した要求に関する情報を表示できます。また、既存の情報を編集したり、履歴を表示したり、契約者のアカウントを失効させたりすることもできます。さらに、氏名と部門に関する情報を変更し、その情報を承認用に再送信することもできます。そして、[Contractor History] (契約者の履歴) ページ (図 5 を参照) から、要求に対して行った操作と、その操作を行った日時を表示することもできます。
図 5 [Contractor History] (契約者の履歴) ページ
図 5 [Contractor History] (契約者の履歴) ページ
MIISWorkflow アプリケーションでは、要求者が契約者の状態ページから契約者のアカウントを失効させることができるため、アカウントの失効操作をシームレスに実行できます。要求者は [Terminate] (失効) リンクをクリックすることにより、接続されたディレクトリで、速やかに契約者のアカウントを無効にしたり削除したりすることができます。このようにワークフロー アプリケーションから契約者のアカウントを失効させることができるため、システム管理者は、各ディレクトリでその契約者のアカウントを見つけて手動で削除する必要がなくなります。MIISWorkflow アプリケーションは、即時に ILM をトリガして、接続されたディレクトリでこれらのアカウントのデプロビジョニングを実行するため、失効操作を行ってからアカウントが削除されるまでの時間のずれがありません。

アプリケーションを構成する
MIISWorkflow アプリケーションの構成では、サービス アカウントの設定、アプリケーションが使用するデータベースの設定、ILM をワークフロー アプリケーションと連携させるための構成、IIS の構成、およびポリシー ストアの構成を行います。このアプリケーションには、このプロセスを単純化できる構築済みのスクリプトと構成ファイルが含まれています。
MIISWorkflow アプリケーションには、MIISWorkflow データベースの作成を容易に実行できる T-SQL クエリ ファイルが含まれています。このクエリ ファイルをクエリ アナライザに読み込み、クエリを実行すると、データベースを自動的に作成できます。
IIS の構成では、ASP.NET ページをホストするために、新しい IIS アプリケーション プールと仮想ディレクトリの作成、および認証とアクセス制御の設定を行います。このアプリケーションには、承認ポリシー ストアを構成するための定義済みの役割が記述された XML ファイルも含まれています。AzMan MMC を使用すると、ユーザーとグループを既存の役割に割り当てたり、新しい役割を作成したりすることができます。
最後に、ILM の管理エージェントを構成して、MIISWorkflow データベースから ILM にデータをインポートします。これを行うには、XML ファイルに記述された管理エージェントの構成をインポートし、SQL Server 管理エージェント用の構築済み拡張ファイルをコピーします。この XML ファイルと管理エージェント拡張ファイルは、いずれもアプリケーションと共に提供されます。Readme ファイルには、各構成作業に関する順を追った説明が記載されています。

アプリケーションの拡張
MIISWorkflow アプリケーションによって、MIIS と統合された単純なワークフローを開発するための基盤が提供されますが、このアプリケーションの一部をカスタマイズして拡張することが必要になる場合があります。Web ページの変更などの単純な変更だけでなく、他にも多くの方法でこのアプリケーションを拡張できます。
たとえば、通知機能を追加すると、保留中の要求があるときに承認者が電子メール メッセージを受信できるようにすることができます。さらに、指定された期間内に要求に対して操作が行われなかった場合、承認者に通知メッセージを送信することもできます。既定のページで提供されるユーザー情報よりも詳細な情報が必要な場合は、契約者の要求ページと契約者の更新ページの両方にフィールドを追加できます。アプリケーションに他の役割を追加することもできます。たとえば、自分が送信した要求だけでなく、すべての要求の履歴を表示できる監査担当者の役割などが考えられます。
マルチ ステップのワークフローや、グラフィカル デザイナを使用したワークフローの設計などの複雑なワークフロー機能は、このアプリケーションで実現することはできません。ただし、Windows Workflow Foundation を使用すると、複雑なワークフロー機能を使用して、より堅牢なアプリケーションを開発することができます。
MIIS Resource Tool Kit は、go.microsoft.com/fwlink/?LinkId=85829 で入手できます。今すぐダウンロードして、独自の ID ワークフロー ソリューションの構築を始めましょう。

Aung Ooは、Microsoft Consulting Services (MCS) で ID 管理に関する業務を専門に担当しています。Aung は、Microsoft Identity Management の初回リリース以降、営利企業と政府機関の両方の顧客を対象とした、企業規模のディレクトリおよび ID 管理ソリューションを設計、開発、および展開してきました。


 Windows の管理: Windows PowerShell を使用してグループ ポリシーの管理を簡素化する
Windows の管理 Thorbjörn Sjövold

Windows PowerShell を使用してグループ ポリシーの管理を簡素化する
概要:
  • Windows PowerShell とは
  • 以前の GPO の管理方法
  • スクリプトを Windows PowerShell に移行する

マイクロソフトのグループ ポリシー テクノロジは、すぐには定着しませんでした。これは、やや理解するのが難しかったこと、および当時の標準であったアカウントとリソースを使用したドメインとはまったく異なる新しいサービスである Active Directory を導入する必要があったからだと思います。
しかし今や、グループ ポリシーは Windows® インフラストラクチャを使用するほぼすべての組織の管理において重要な要素になりました。マイクロソフトの最新の管理テクノロジである Windows PowerShell™ についても同じことが起こる気がします。実際、Windows PowerShell により、グループ ポリシー管理者の作業は大幅に簡素化される可能性があります。
この記事では、VBScript (および一般的な COM ベースのスクリプト言語) などの Windows Scripting Host 言語向けに記述された Microsoft® グループ ポリシー管理コンソール (GPMC) API を Windows PowerShell から直接使用して、現在の環境で行っているグループ ポリシーの管理を簡素化する方法について説明します。

グループ ポリシーに関するタスクをスクリプト化する
数年前にマイクロソフトが GPMC をリリースしたとき、グループ ポリシー管理者は突如として、自由に使用できるたくさんの便利な機能を手に入れました。グループ ポリシー専用の MMC スナップインが提供されたことは、特にそれまで Active Directory® ユーザーとコンピュータを使用していたことを考えると、グループ ポリシーの管理にとって大きな前進であったと言えます。さらに、管理者がグループ ポリシー オブジェクト (GPO) のバックアップと復元、ドメイン間での GPO の移動、GPO とリンクに対するセキュリティ設定の構成、レポートの作成などのグループ ポリシーの管理タスクを、VBScript などの COM ベースの言語を使用して実行できる新しい API も提供されました。
残念なことに、GPMC では、グループ ポリシー オブジェクト内の構成済みの設定を編集することはできませんでした。つまり、GPO のバージョンの読み取り、変更日の読み取り、新しい GPO の作成、異なるドメインからの GPO のバックアップと復元、異なるドメインからの GPO のインポートなどの操作を GPO コンテナに対して実行することはできましたが、新しいリダイレクト フォルダや新しいソフトウェアのインストールの追加など、GPO の内容をプログラムから追加または変更することはできませんでした。このため、通常は GPO を作成し、グループ ポリシー オブジェクト エディタを使用してすべての設定を手動で構成した後、その GPO をバックアップしてテスト環境にインポートするという一連の作業を代わりに行っていました。そして、すべての設定を検証し、正常に機能していることを確認できたら、その GPO を運用環境にインポートしていました。上記のような機能の欠如はありましたが、手動による操作の代わりに GPMC API を使用したスクリプトを実行することにより、日々のグループ ポリシーの管理にかかる時間、作業、およびエラーが大幅に減少しました。

次のレベルへ
Windows PowerShell は、VBScript などのスクリプト言語とはどのように異なるのでしょうか。まず、Windows PowerShell はシェルです。また、少なくともここでの説明においては、シェルはコマンド ライン インタプリタと考えていただいてかまいません。VBScript はコマンド ラインから実行できますが、VBScript ファイルを 1 行ずつ実行することはできません。これとは対照的に、Windows PowerShell スクリプトは、その場で一連のコマンドとして作成できます。また、Windows PowerShell には、VBScript のサブルーチンとほぼ同じように動作し、Windows PowerShell コマンド プロンプトでリアルタイムに作成できる関数が用意されています。
さらに、VBScript は古い COM テクノロジに依存していますが、Windows PowerShell は Microsoft .NET Framework を基に構築されています。これは、今日開発されている大量の .NET コードを Windows PowerShell 内から直接使用できることを意味しています。
まとめると、Windows PowerShell により、スクリプトの完全なサポートと対話モードが 1 つのパッケージで提供されるということになります。ここで紹介する例はすべてコマンド ライン入力であるため、そのままコマンド ラインに入力することができますが、これらを Windows PowerShell スクリプト ファイルに保存して実行しても、同じように正しく機能します。

Windows PowerShell を使用して古いスクリプトを作り変える
新しいテクノロジの使用を開始するときに最も避けたいことは、過去の作業をすべて捨て去ることです。GPMC API から COM オブジェクトにアクセスするために使用できる方法は 3 つあります。基本的に、これらは古い VBScript を再利用するために使用することもできます。次にこれら 3 つの方法を示します。
  • C# やマネージ C++ などのプログラミング言語を使用して、Windows PowerShell コマンドレットを作成する。
  • Windows PowerShell を使用して MSScript.ocx の ScriptControl にアクセスし、古いスクリプトをラップする。
  • 再利用可能な Windows PowerShell 関数に COM 呼び出しをラップするか、COM オブジェクトを直接呼び出す。
主に重点を置いて説明するのは 3 つ目の方法ですが、最初にすべての方法について簡単に説明します。

Windows PowerShell コマンドレットを作成する
Windows PowerShell には、ファイルのコピー、出力の書式設定、日時の取得などを実行できる大量のコマンドレットが含まれていますが、独自のコマンドレットを作成することもできます。この作成プロセスは msdn2.microsoft.com/ms714598.aspx にすべて記載されています。要約すると、次のような手順を実行します。
  • C# などの .NET プログラミング言語で、クラス ライブラリ DLL を作成する。
  • 新しいクラスを基本クラスのコマンドレットから継承して作成する。
  • 名前、使用方法、入力パラメータなどを決定する属性を設定し、独自のコードを追加する。
Windows PowerShell は .NET Framework に基づいて構築されているため、文字列型やオブジェクト型など、コード内でパラメータとして返されたり渡されたりしている型は、Windows PowerShell でもまったく同じように使用できるため、特殊な型変換は必要ありません。
Windows PowerShell の最大の利点は、完全なプログラミング言語を自在に使用できることです。

MSScript.ocx の ScriptControl オブジェクトを使用して古いスクリプトをラップする
VBScript ファイルを実行するには、当然 VBScript エンジンが必要です。しかし、VBScript エンジンは COM オブジェクトであり、また COM オブジェクトは Windows PowerShell から使用できるため、VBScript エンジンを呼び出すことは可能です。次のようなコードを使用します。
$scriptControl = New-Object -ComObject ScriptControl
$scriptControl.Language = ‘VBScript’
$scriptControl.AddCode(
    ‘Function ShowMessage(messageToDisplay)
    MsgBox messageToDisplay
    End Function’)
$scriptControl.ExecuteStatement(‘ShowMessage
    “Hello World”’)
上記のコードを Windows PowerShell コマンド ライン インターフェイス (CLI) に入力すると、パラメータが指定された VBScript 関数 ShowMessage が呼び出されて実行され、メッセージ ボックスに "Hello World" というテキストが表示されます。
何人かの読者の皆さんは、"これで Windows PowerShell から COM を使用する方法をマスターできたから、この記事をもう読まなくても、古い GPMC スクリプト群を ScriptControl オブジェクトに詰め込めばいいだろう" と考えたかもしれませんが、残念ながらそれはお勧めできません。この方法では、スクリプトが長くなると、すぐにコードが複雑になり、デバッグが難しくなります。

COM オブジェクトをラップする
このため、3 つ目の方法を使用するのが最も適切です。この方法では、再利用可能な Windows PowerShell 関数に COM 呼び出しをラップすることにより、COM オブジェクトを GPMC API で使用できるようにします。次のコードは、Windows PowerShell で直接 .NET オブジェクトを作成する方法を示しています。このコードでは、FileInfo オブジェクトを使用してファイルのサイズを取得します。
$netObject = New-Object System.IO.FileInfo(
“C:\boot.ini”) # Create an instance of FileInfo
               # representing c:\boot.ini
Windows PowerShell では、コード内のコメントに # を使用することに注意してください。この新しくインスタンス化した FileInfo オブジェクトを使用すると、次のコードを入力するだけで boot.ini のサイズを容易に取得できます。
$netObject.Length # Display the size in bytes of the
                  # file in the command line interface
ちょっと待ってください。COM オブジェクトと VBScript の変換について説明する予定だったのではないでしょうか。だいじょうぶです、ちゃんと説明しますから、次のコマンドを見てください。
$comFileSystemObject = New-Object –ComObject Scripting.FileSystemObject
構文は、基本的に上記で .NET Framework からネイティブ オブジェクトを作成するときに使用したものと同じです。異なる箇所は次の 2 つです。1 つ目は、.NET オブジェクトではなく COM オブジェクトを作成することを Windows PowerShell に指定する –ComObject スイッチが追加されています。2 つ目は、.NET コンストラクタの代わりに COM ProgID (ここでは Scripting.FileSystemObject) が使用されています。この ProgID は、皆さんがいつも使用してきたものと同じ名前を指定できます。対応する VBScript のコードを次に示します。
Set comFileSystemObject = CreateObject(
    “Scripting.FileSystemObject”)
VBScript を使用してファイルのサイズを取得するには、上記のコードと共に、次のコードをファイルに追加します。
Set comFileObject = comFileSystemObject.GetFile(
    “C:\Boot.ini”)
WScript.Echo comFileObject.Size
その後、Cscript.exe などを使用して、作成したファイルを実行します。Windows PowerShell では、次のコードによって同じ処理を実行できます (Windows PowerShell コマンド ラインから直接実行することもできます)。
$comFileObject = $comFileSystemObject.GetFile(
    “C:\boot.ini”)
$comFileObject.Size
もちろん、ファイルのサイズを読み取る VBScript を変換するために、ドライブ内のオブジェクトを管理する Windows PowerShell コマンドレットを使用することもできましたが、Windows PowerShell から COM へのアクセスが容易であることを示すために上記のコードを使用しました。Windows PowerShell には COM オブジェクトを作成することを指定しましたが、ここで実際に作成される $comFileSystemObject は、COM オブジェクトをラップし、そのオブジェクトのインターフェイスを公開する .NET オブジェクトであることに注意してください。ただしこの記事では、このことはあまり重要ではありません。

Windows PowerShell の実際の使用例
Windows PowerShell から COM にアクセスする方法について理解したところで、次はグループ ポリシーに焦点を当てます。ここで示す例は、Windows PowerShell から GPMC API を使用する方法について説明するための短いコード スニペットですが、technetmagazine.com/code07.aspx からダウンロードできる、この記事の関連コードには、グループ ポリシーを管理するための Window PowerShell 関数一式が含まれています。図 1 は、この関連コードに含まれる関数の一覧を示しています。
Figure 1 この記事の関連コードに含まれているカスタム関数 (Close Figure 1)

関数名 | 説明
BackupAllGpos | ドメイン内のすべての GPO をバックアップします。
BackupGpo | 1 つの GPO をバックアップします。
RestoreAllGpos | バックアップからすべての GPO をドメインに復元します。
RestoreGpo | バックアップから 1 つの GPO を復元します。
GetAllBackedUpGpos | 特定のパスから GPO の最新のバックアップを取得します。
CopyGpo | GPO の設定を別の GPO にコピーします。
CreateGpo | 新しい空の GPO を作成します。
DeleteGpo | GPO を削除します。
FindDisabledGpos | ユーザーとコンピュータの部分が両方無効になっているすべての GPO を返します。
FindUnlinkedGpos | リンクが含まれていないすべての GPO を返します。
CreateReportForGpo | ドメイン内の 1 つの GPO に関する XML レポートを作成します。
CreateReportForAllGpos | ドメイン内の各 GPO に関する XML レポートを個別に作成します。
GetGpoByNameOrID | GPO を表示名または GPO ID で検索します。
GetBackupByNameOrId | GPO のバックアップを表示名または GPO ID で検索します。
GetAllGposInDomain | ドメイン内のすべての GPO を返します。
このセクションを読みながら、Windows PowerShell コマンド ラインを起動し、コマンドを入力してもかまいません。ただし、一部のコマンドは、その前に実行したコマンドに依存していることに注意してください。つまり、最初に作成した一部のオブジェクトは後で使用するため、途中で Windows PowerShell セッションを終了しないようにする必要があります。セッションを終了した場合、最初からやり直すことになるため、すべてのコマンドを再入力する必要があります。
では、Windows PowerShell を使用した新しい GPO の作成を開始しましょう。マイクロソフトのグループ ポリシー チームは、GPMC と的確に連携して動作し、作業の効率化に役立つ、多数の VBScript サンプルを作成しました。これらのサンプルは、%ProgramFiles%\GPMC\Scripts ディレクトリにあります。このディレクトリには、GPMC API に関するドキュメントが含まれた gpmc.chm ファイルも格納されています。では、CreateGPO.wsf スクリプトを細かく分析して、動作の中身を見ていきましょう。
ファイルの先頭付近に次のようなコードがあります。
Dim GPM
Set GPM = CreateObject(“GPMgmt.GPM”)
基本的に、上記のコードがすべてのグループ ポリシー管理セッションまたはスクリプトの開始点になります。ここで GPMgmt.GPM クラスのインスタンスを作成することにより、ほとんどの GPMC の機能にアクセスできるようになります。この操作を Windows PowerShell から実行する場合、次のコードを使用します。
$gpm = New-Object -ComObject GPMgmt.GPM
これでグループ ポリシーの管理を行うための準備ができたので、次はこのオブジェクトを使用して実行できる操作を確認します。通常、このような情報を得るにはドキュメントを参照しますが、Windows PowerShell には非常に優れた機能が用意されています。次のコードを入力すると、図 2 のような出力が得られます。
図 2 Get-Member の出力
図 2 Get-Member の出力
$gpm | gm
すばらしいですね。Get-Member (または gm) コマンドレットを使用すると、オブジェクトでサポートされているプロパティとメソッドを直接コマンド ラインから確認できます。もちろん、ドキュメントを読む場合とは異なりますが、使い慣れているオブジェクトのパラメータの数やオブジェクト名などを正確に思い出せない場合には役立ちます。ここで注意すべき重要なことがあります。GPMC のドキュメントに表示されているツリー形式の一覧では、GPM オブジェクトと他のすべてのクラスの前に I という文字が付いていますが、これは COM の内部構造によるものであり、この記事の内容には影響しません。これはネイティブ COM コードを記述する C++ プログラマが参照するためのものであり、インターフェイスと、それを実装するクラスを区別しています。また、GPMC API を使用する際に、上記のような方法で作成するオブジェクトは GPMgmt.GPM だけです。他のすべてのオブジェクトは、この GPM オブジェクトを起点としたメソッドを使用して作成されます。
次に、新しい GPO を作成しましょう。
図 3 は、GPO の作成が非常に容易であることを示しています。エラー処理 (たとえば、GPO の作成を許可されていない場合の処理) など、一部のコードを省略し、ドメイン名をハードコードしてありますが、だいたいの方法はおわかりいただけると思います。
Figure 3 GPO を作成する (Close Figure 3)
$gpmConstants = $gpm.GetConstants()
# This is the GPMC way to retrieve all
# constants
$gpmDomain =$gpm.GetDomain(“Mydomain.local”, “”, $gpmConstants.UseAnyDC)
# Connects to the domain where the GPO should
# be created, replace Mydomain.local with the
# name of the domain to connect to.
$gpmNewGpo = $gpmDomain.CreateGPO()
# Create the GPO
$gpmNewGpo.DisplayName = “My New Windows PowerShell GPO”
# Set the name of the GPO
GPO の作成方法について理解したら、次は既存の GPO を開いてみましょう。ドメインへの参照である $gpmDomain が残っているので、次のコードを入力します。
$gpmExistingGpo = $gpmDomain.GetGPO(
  “{31B2F340-016D-11D2-945F-00C04FB984F9}”)
# Open an existing GPO based on its GUID,
# in this case the Default Domain Policy.
$gpmExistingGpo.DisplayName
# Show the display name of the GPO, it
# should say Default Domain Policy
$gpmExistingGpo.GenerateReportToFile($gpmConstants.ReportHTML, “.\DefaultDomainPolicyReport.html”
上記の場合は、既定のドメイン ポリシーの設定がすべて記載された HTML レポートが生成されますが、当然どのメソッドとプロパティを使用してもかまいません。たとえば、GPO が最後に変更された時間を示す ModificationTime を使用すると、GPO の設定がいつ変更されたかを確認できます。
これは非常に役立ちます。たとえば、よくユーザーからコンピュータの動作がおかしいという問い合わせが殺到することがあります。この場合、GPO の設定が変更、追加、または削除されたことが原因ではないかと疑っても、どの GPO を調べればよいかがわかりません。そんなとき、Windows PowerShell が救いの手を差し伸べてくれます。図 4 のようなスクリプトを Windows PowerShell コマンド ラインに入力すると、過去 24 時間以内に変更されたすべての GPO を確認できます。
Figure 4 変更された GPO を検出する (Close Figure 4)
$gpmSearchCriteria = $gpm.CreateSearchCriteria()
# We want all GPOs so no search criteria will be specified
$gpmAllGpos = $gpmDomain.SearchGPOs($gpmSearchCriteria)
# Find all GPOs in the domain
foreach ($gpmGpo in $gpmAllGpos)
{
if ($gpmGpo.ModificationTime -ge (get-date).AddDays(-1)) {$gpmGpo.DisplayName}
# Check if the GPO has been modified less than 24 hours from now
}
"以上" を意味する –ge 演算子に注意してください。他のスクリプト言語やプログラミング言語の < および > 演算子に慣れている場合、この演算子は奇妙に見えるかもしれません。しかし、皆さんが見慣れているそれらの演算子はリダイレクト (ファイルへの出力のリダイレクトなど) に使用されるため、Windows PowerShell で比較演算子として使用することはできません。

まとめ
図 5 には、ある GPO の設定を別の GPO にコピーするためのスクリプトのコードがすべて記載されています。ここまでの説明で、この新しいテクノロジをグループ ポリシーと共に使用し、COM オブジェクトや、COM オブジェクトを使用する VBScript コードを再利用する方法についておわかりいただけたと思います。
Figure 5 ある GPO の設定を別の GPO にコピーする (Close Figure 5)
###########################################################################
# Function  : CopyGpo
# Description: Copies the settings in a GPO to another GPO
# Parameters : $sourceGpo     - The GPO name or GPO ID of the GPO to copy
#           : $sourceDomain   - The dns name, such as microsoft.com, of the domain where the original GPO is located
#           : $targetGpo      - The GPO name of the GPO to add
#           : $targetDomain   - The dns name, such as microsoft.com, of the domain where the copy should be put
#           : $migrationTable - The path to an optional Migration table to use when copying the GPO
# Returns   : N/A
# Dependencies: Uses GetGpoByNameOrID, found in article download
###########################################################################
function CopyGpo(
 [string] $sourceGpo=$(throw ‘$sourceGpo is required’),
 [string] $sourceDomain=$(throw ‘$sourceDomain is required’),
 [string] $targetGpo=$(throw ‘$targetGpo is required’),
 [string] $targetDomain=$(throw ‘$targetDomain is required’),
 [string] $migrationTable=$(“”),
 [switch] $copyAcl)
{

 $gpm = New-Object -ComObject GPMgmt.GPM # Create the GPMC Main object
 $gpmConstants = $gpm.GetConstants() # Load the GPMC constants
 $gpmSourceDomain = $gpm.GetDomain($sourceDomain, “”, $gpmConstants.UseAnyDC) # Connect to the domain passed
                                                                              # using any DC
 $gpmSourceGpo = GetGpoByNameOrID $sourceGpo $gpmSourceDomain
 # Handle situations where no or multiple GPOs was found
 switch ($gpmSourceGpo.Count)
 {
   {$_ -eq 0} {throw ‘No GPO named $gpoName found’; return}
   {$_ -gt 1} {throw ‘More than one GPO named $gpoName found’; return}
 }
 if ($migrationTable)
 {
   $gpmMigrationTable = $gpm.GetMigrationTable($migrationTable)
 }

 $gpmTargetDomain = $gpm.GetDomain($targetDomain, “”, $gpmConstants.UseAnyDC) # Connect to the domain passed
                                                                              # using any DC

 $copyFlags = 0
 if ($copyAcl)
 {
   $copyFlags = Constants.ProcessSecurity
 }
 $gpmResult = $gpmSourceGpo.CopyTo($copyFlags, $gpmTargetDomain, $targetGpo)
 [void] $gpmResult.OverallStatus

}
Windows PowerShell は、既にグループ ポリシーがそうであるように、Windows 管理環境になくてはならない要素になるでしょう。しかし、移行または維持する必要がある VBScript コードは無数にあります。このチュートリアルがそれらの作業の役に立つことを願っています。
グループ ポリシーの管理や、以前は VBScript を使用していたその他の作業を強化するために使用できるリソースは多数用意されています。たとえば、ダウンロード可能なこの記事の関連コードに含まれている Windows PowerShell 関数や、TechNet Web サイトで提供されている、VBScript から Windows PowerShell への変換に役立つガイドなどがあります。このガイドには、VBScript で行っていた一般的な作業を Windows PowerShell で実行する方法に関するヒントが記載されています。このガイドは、microsoft.com/technet/scriptcenter/topics/winpsh/convert から参照できます。
また、GPMC API はすべてドキュメント化されており、グループ ポリシー サイト (microsoft.com/grouppolicy) からダウンロードできます。
大事なことを言い忘れていましたが、Windows PowerShell がインストールされていなければ、何も始まりません。microsoft.com/powershell からダウンロードしましょう。それでは Windows PowerShell をお楽しみください。

Thorbjörn Sjövoldは、グループ ポリシーをベースにしたシステム管理およびセキュリティ強化製品を提供する Special Operations Software (www.specopssoft.com) の CTO および創立者です。彼の連絡先は thorbjorn.sjovold@specopssoft.com (英語のみ) です。


 Windows の管理: ターミナル サービス展開ガイド
Windows の管理 James D. Silliman

ターミナル サービス展開ガイド
概要:
  • 簡単な数ステップでターミナル サービスを展開する
  • TS 環境で Office をカスタマイズする
  • TS を使用してユーザーを効率的に管理する

1998 年を思い起こしてみましょう。マイクロソフトは、この年 Windows NT 4.0 Terminal Server Edition (コードネーム "Hydra") をリリースしました。
マイクロソフトは、Citrix Systems からテクノロジのライセンス供与を受けて、初のシン クライアント/サーバー製品を作成しました。システム管理者にとって、"Hydra" の展開は困難でした。それから数年を経て、ターミナル サービスは劇的に変化しました。完全にカーネルに統合され、組み込みのインストール ウィザードによりセットアップが容易になり、別の CD-ROM やインターネットからのダウンロードが不要になりました。インストールが比較的容易になったことを考えると、ターミナル サービスを組織に展開することが有意義な理由は多数あります。最も直接的なメリットは、すべてのアプリケーションを中央のサーバーに配置することで、クライアントのアーキテクチャやハードウェアが問題にならなくなることです。エンド ユーザーには、中央サーバーに接続するためのリモート デスクトップ プロトコル (RDP) クライアントしか必要になりません。さいわい、RDP クライアントは、現在の大半のアーキテクチャで使用できます。
この記事では、既存の Windows Server® 2003 インストール上でターミナル サービスを有効にする方法、ターミナル サービスのグループ ポリシーの適用方法、およびカスタム インストール ウィザードを使用して Microsoft® Outlook® のプロファイル設定を自動化する方法を説明します。これらを完了すれば、アプリケーション サービスをユーザーに提供できるターミナル サーバーが完全に展開できるようになります。

はじめに
ターミナル サービスをセットアップするには、まず、Windows Server 2003 の [管理ツール] から組み込みの "サーバーの構成ウィザード" を起動します。[ターミナル サーバー] を選択し、[次へ] を繰り返しクリックして、ウィザードを完了します。インストール プログラムにより、変更を有効にするためにコンピュータが自動的に再起動されることを示す警告が表示されます。再起動されると、サーバーはターミナル サーバー モードで実行されます。
なお、作業を開始する前に、ターミナル サービス クライアント アクセス ライセンス (CAL) を取得していることを確認してください。CAL がないと、展開が無事に完了してもユーザーはサーバーに接続できません。ここで、ターミナル サービスを実行するコンピュータを Active Directory® ドメインに参加させ、Domain Admins 特権のあるアカウントを使用してログインします。ドメイン上で作業していない場合、グループ ポリシーを適用できないため、作業を続行することは困難です。ここでは、ターミナル サービスをインストールするサーバーの名前を TS01 とします。
次に、[管理ツール] から "Active Directory ユーザーとコンピュータ" を起動し、ターミナル サーバーを配置する新しい組織単位 (OU) を作成します。説明をわかりやすくするため、この OU の名前を Terminal Servers としましょう。ターミナル サーバー TS01 を探し、これを新しい OU の Terminal Servers に移動します。
次に、グループ ポリシー管理コンソール (GPMC) を microsoft.com/windowsserver2003/gpmc からダウンロードします。この管理ユーティリティを使用すると、新しいグループ ポリシーのセットアップ、グループ ポリシーへのアクセス許可の割り当て、ポリシーの編集などを行うことができ、接続するユーザーに対してアプリケーション ポリシー設定を必要に応じて有効または無効にできます。GPMC は、ターミナル サービス展開にとって非常に重要なツールです。これにはモデル作成ウィザードが含まれており、このウィザードを使用すると、ユーザーに適用済みのポリシーと未適用のポリシーを直ちに確認できます。
[管理ツール] から GPMC コンソールを起動し、[グループ ポリシーの管理] ダイアログ ボックスの左側のウィンドウで、作成した新しい OU Terminal Servers を参照します。この OU を右クリックし、[Create and Link a GPO Here] (ここに GPO を作成およびリンク) をクリックして (図 1 参照)、これに実用的な名前 (Terminal Server Policy #1 など) を付けます。
図 1 新しい GPO の作成およびリンク
図 1 新しい GPO の作成およびリンク
GPMC の右側のウィンドウの [セキュリティ フィルタ処理] ボックスに、Authenticated Users グループがいつの間にか表示されています。このグループは、既定ですべてのグループ ポリシー オブジェクト (GPO) に追加されます。このグループをクリックし、[削除] をクリックします。ユーザーが TS01 にログオンしたときに GPO を適用する Active Directory ツリーには、代わりに Terminal Services グループをセットアップします。ここでは、その Terminal Services グループに BottleWashers という名前を付けることにします。管理ツールの "Active Directory ユーザーとコンピュータ" を使用して、これを Active Directory 構造に追加します。また、TS01 や他にインストールするターミナル サーバーの Remote Desktop Users グループにも、BottleWashers を追加する必要があります。
[スコープ] タブで作業していることを確認します。[セキュリティ フィルタ処理] ボックスの [追加] をクリックし、BottleWashers をグループとして追加します。BottleWashers には、自動的に Terminal Server Policy #1 に対する読み取り権利とグループ ポリシーの適用権利が許可されます。これら 2 つのアクセス許可は、既定のグループ ポリシーの権利であり、どのポリシーであってもオブジェクトに適用する場合に必要な権利です。
次に、サーバー TS01 も [セキュリティ フィルタ処理] ボックスに追加します。この操作には、追加の作業があります。まず、[追加] をクリックし、[オブジェクトの種類] の [コンピュータ] タブにチェックマークが付いていることを確認します。そうでないと、GPMC が Active Directory 内の TS01 を見つけることができません。最終的には、図 2 のようになります。
図 2 [セキュリティ フィルタ処理] への TS01 の追加
図 2 [セキュリティ フィルタ処理] への TS01 の追加
TS01 を [セキュリティ フィルタ処理] に追加すると、同様に適切なポリシーの権利が TS01 に自動的に適用されます。この時点で、右側の GPMC 画面の上部で [委任] タブをクリックして、Domain Admins を参照しておきましょう (Domain Admins も新しいポリシーに既定で追加されます)。画面右下隅にある [詳細設定] をクリックします。
グループ ポリシー オブジェクトのセキュリティ設定が表示されます。Domain Admins が選択されていることを確認し、下部にある [グループ ポリシーの適用] 設定を参照します。右側の [拒否] チェック ボックスをオンにします。[OK] をクリックすると、拒否アクセス許可を設定したときに必ず表示される標準の警告メッセージが表示されます。この処理により、新しい TS ポリシーが Domain Admins に不適切に適用されないようにします。
最初に、Microsoft CAL を用意しておくことについて注意しました。ライセンスの契約の書類を見直し、どのようなターミナル サービス CAL を購入しているかを確認してください。ターミナル サーバー用の CAL は 2 種類あります。ユーザー CAL とデバイス CAL の 2 つです。ライセンスの詳細については、microsoft.com/windowsserver2003/howtobuy/licensing/ts2003.mspx を参照してください。
基本的に、ユーザー単位のライセンスでは、1 ユーザーにつき 1 ターミナル サーバー ライセンスしか必要ありません。これは、そのユーザーが接続に使用するデバイス (PC) の数には関係しません。
ドメインにターミナル サーバー ライセンス サーバーがない場合は、この役割を実行できるメンバ サーバーを特定します。サポートはされていますが、TS01 をライセンス サーバーにはしないようにしてください。後で組織にターミナル サーバーを追加する場合に、インフラストラクチャのフォールト トレランスを十分に確保できないためです。ライセンス サーバーにするコンピュータのコントロール パネルを開きます。[プログラムの追加と削除] を開き、[Windows コンポーネント] の [ターミナル サーバー ライセンス] をクリックします。指示に従って、ライセンス サーバーを有効にします。これが完了したら、[スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックして、次のように入力します。
tscc.msc
これにより、[ターミナル サービス構成] の [サーバー設定] ツリーが表示されます。ここで、[サーバー設定] の [ライセンス] をクリックし、[接続ユーザー数] または [接続デバイス数] を選択します。既定値は [接続デバイス数] です。既にドメインにターミナル サーバー ライセンス サーバーがある場合は、ライセンス サーバーの役割を担っているサーバーを示す設定が、Terminal Server Policy #1 にあります。この作業が完了したら、再び [スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックして、次のように入力します。
licmgr.exe
ここで CAL のライセンス認証を行い、ユーザーが接続できるようにします。さいわい、これは電話または Web から実行できます。これでユーザーはターミナル サーバーに接続できるようになりますが、適用されているポリシーがないため、いくつか重要なものを設定しましょう。マイクロソフトの推奨は、サポート技術情報「Windows Server 2003 または Windows 2000 ターミナル サーバー セッションをロックダウンする方法」で紹介されています。

ポリシーを有効にする
各ポリシーの内容を正確に把握せずに、手当たりしだいにポリシーを有効にしないように、くれぐれも注意してください。このようなことをすれば、望ましくない結果を招く可能性があります。まず、いくつか非常に重要なポリシーを適用し、ラボ環境でポリシーの広範なテストを行うようにすることをお勧めします。
おそらく最初に適用する必要があるポリシーは、ループバック ポリシーです。これを有効にするには、GPMC を起動します。Terminal Server Policy #1 を探し、これを右クリックして、[編集] をクリックします。"コンピュータの構成\管理用テンプレート\システム\グループ ポリシー" を参照し、[ユーザー グループ ポリシー ループバックの処理モード] を有効にします。このポリシーを有効にしたら、このモードの値 ([置換] または [結合]) を設定します。ターミナル サービスの場合は、[置換] を選択すると最善の結果が得られます。
他に有効にするターミナル サーバー設定は、[Administrators セキュリティ グループを移動ユーザー プロファイルに追加する] です。これは、"コンピュータの構成\管理用テンプレート\システム\ユーザー プロファイル" 以下にあります。この設定は、管理者が常にユーザー プロファイル フォルダを完全に制御できるようにします。ユーザーの初回のログイン後にフォルダが作成されるとこの設定を適用できなくなるため、できるだけ早い時点で設定する必要があります (図 3 参照)。
図 3 [Administrators セキュリティ グループを移動ユーザー プロファイルに追加する] を有効化
図 3 [Administrators セキュリティ グループを移動ユーザー プロファイルに追加する] を有効化
"コンピュータの構成\管理用テンプレート\Windows コンポーネント\ターミナル サービス" に、適用される全ポリシーが表示されます。以下のポリシーを有効にすることを検討してください。
  • ターミナル サービス ユーザーに対してリモート セッションを 1 つに制限する
  • TS 移動プロファイルのパスを指定する
  • TS ユーザーのホーム ディレクトリ
ただし、ターミナル サービス ユーザーが 1 リモート セッションしか利用できないように制限しても、ユーザーが複数回ログインできなくなるわけではありません。ユーザーが別のターミナル サービス セッションを開始した場合は、単純に元のログオン セッションが継承されます。
移動プロファイルは、適切なターミナル サーバー運用には不可欠な要素です。既定では、ユーザーがターミナル サーバーにログオンすると、ユーザーに対しては C: ドライブを非表示にしていても、ターミナル サーバーの C: ドライブにローカル プロファイルが作成されます。移動プロファイルの既定の動作では、ユーザーのログオフ時に、ネットワーク上の移動プロファイル共有とローカル プロファイルを同期します。ユーザーのログオフ時に、このローカル プロファイルが削除されるようにグループ ポリシーを設定することもできます。
上記の下 2 つのターミナル サーバー ポリシー、"TS 移動プロファイルのパスを指定する" と "TS ユーザーのホーム ディレクトリ" は、移動プロファイルに関係しています。これらの設定は、Active Directory ユーザーのターミナル サービス プロファイルのパス設定にハードコーディングされることがよくあります。ターミナル サーバーのパスは、グループ ポリシーを使用して設定する方が、はるかに簡単で望ましい方法です。"Active Directory のユーザーとコンピュータ" のターミナル サーバー プロファイルのパスでは、新しいユーザーをセットアップするか、既存のユーザーをコピーする場合、毎回手動で TS サーバー プロファイルのパス情報を設定しなければならず、非常に面倒です。このようなパスはネットワーク共有に設定し、GPO を使用して構成する方がはるかに便利です。

フォルダ リダイレクト
次に、また別の重要なターミナル サーバーの要素であるフォルダ リダイレクトを簡単に取り上げます。これは、必要以上に時間のかかるログオンやログオフを防いで、TS の操作性を最適化します。リダイレクトできるフォルダは、Application Data、デスクトップ、My Documents、およびスタート メニューです。この 4 つのフォルダは、ネットワーク共有上に存在している必要があり、特定のアクセス制御リスト (ACL) を必要とします。このトピックの詳細については、サポート技術情報の「Windows 2000 および Windows Server 2003 でフォルダ リダイレクトを使用して、セキュリティが強化されたリダイレクト フォルダを動的に作成する方法」を参照してください。
フォルダ リダイレクトのメリットは、ユーザー プロファイル全体をユーザーがログオンまたはログオフするたびにコピーしなくてもよいことです。ターミナル サービスは、これらのフォルダがネットワーク上にあることを認識し、基本的にこれらに対するポインタのみを提供します。
移動プロファイルとフォルダ リダイレクトを使用する場合は、分散ファイル システム (DFS) について調べ、ネットワーク共有のメンテナンスを簡素化することをお勧めします。スペースの制約上、この記事では DFS について説明しませんが、詳細については DFS リソース センターを参照してください。
フォルダ リダイレクトの設定は、"ユーザー構成\Windows 設定\フォルダ リダイレクト" で行います (図 4 参照)。[フォルダ リダイレクト] フォルダの値は、簡潔明瞭です。各フォルダ リダイレクトの設定で [ユーザーに <フォルダ名> に対して排他的な権限を与える] というチェック ボックスはオフにすることをお勧めします。オフにしないと、管理者がそのフォルダにアクセスできなくなります。
図 4 フォルダ リダイレクトの設定の場所
図 4 フォルダ リダイレクトの設定の場所

Microsoft Office をインストールする
必須のポリシーを適用できたところで、今度は Microsoft Office 2003 または 2007 Microsoft Office system のインストールの準備にかかりましょう。Microsoft Office はターミナル サービス向けに最適化されているため、インストール中に変更が必要なことはあまりありません。Office スイートに含まれる帯域幅を多く消費するコンポーネントは、既定では無効にされています。この時点で、グループ ポリシーの管理用テンプレート ファイル (ADM ファイル) をダウンロードおよびインストールして、Office スイート内のポリシーを制御できるようにする必要があります。
必要な ADM ファイルは、microsoft.com/office/orkarchive/2003ddl.htm から入手できます。この記事でダウンロードが必要になるのは 2 ファイルのみです。Office テンプレート ファイル (ORKSP2AT.exe) と カスタム インストール ウィザード の 2 つです。ただし、2 番目のファイルが必要になるのは、Office 2003 を展開する場合のみです。2007 Office system ではこのウィザードは使用しません。[スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックして、「Setup /a」と入力するだけで、自動的に起動します。
1 番目のファイル ORKSP2AT.exe を展開すると、多くのファイルが作成されます。ここで必要なファイルは office11.adm と outlk11.adm です (図 5 参照)。
図 5 Office テンプレート ファイル
図 5 Office テンプレート ファイル
エクスプローラを起動し、この 2 つのファイルを %systemroot%\inf にコピーします。再び GPMC コンソールを起動します。[グループ ポリシー オブジェクト] の Terminal Server Profile #1 を参照し、これを右クリックして [編集] をクリックします。定義したポリシーの [コンピュータの構成] の [管理用テンプレート] に移動します。[管理用テンプレート] を右クリックし、[テンプレートの追加と削除] をクリックします (図 6 参照)。
図 6 管理用テンプレートを GPO に追加
図 6 管理用テンプレートを GPO に追加
これで、必要な 2 つのファイルが使用できるようになりました。これらのファイルは 1 度に 1 ファイルずつ追加してください。この 2 つのテンプレート ファイルは、"ユーザーの構成\管理用テンプレート\Microsoft Office 2003" および "ユーザーの構成\管理用テンプレート\Microsoft Outlook 2003" に表示されます。これらのテンプレート設定を参照して、必要に応じて有効または無効にすることができます。
ここでは多くの設定について説明しませんが、Office アシスタントと Outlook の古いアイテムの整理の 2 つの設定は削除した方がよい場合があります。Exchange キャッシュ モードや迷惑メール フィルタなどの一部の設定は、ターミナル サービスでは既定で無効であるため、これらのポリシーについては無効にする必要はありません。
詳細については、「ターミナル サービスでは無効にされる Outlook 機能」を参照してください。Office アシスタントは、"ユーザーの構成\管理用テンプレート\Microsoft Office 2003\アシスタント\オプション" を選択するだけで、無効にできます。
ターミナル サービス環境では、何度もユーザーに確認を求めない方がよい操作があります。特にわずらわしい確認の例としては、Outlook の古いアイテムの整理の設定に関するものです。グループ ポリシー内でこの設定が無視されている場合、一定の間隔でユーザーに対して古いアイテムを整理するかどうかが確認されます。この設定を無効にすると、Outlook の基本設定のメニューからこの設定が完全に削除されます。もちろん、古いアイテムの整理を使用する場合は、"ユーザーの構成\管理用テンプレート\Microsoft Office Outlook 2003\ツール\オプション\古いアイテムの整理" ポリシーで設定を調整できます。
ターミナル サービスの展開を成功させるために必要な次の作業は、Outlook PRF ファイルをセットアップし、ユーザーに対して Outlook 設定を手動で構成するように求めるメッセージが表示されないようにすることです。これはとても難しい作業のように思えるかもしれませんが、実際はそうではありません。この作業では、OrkTools をインストールし、カスタム インストール ウィザード (CIW) を使用して Outlook のセットアップ ウィザードの動作を指示する PRF ファイルを作成します。2007 Office system では、別のメカニズムがあるためこのプロセスは不要ですが、2007 Office system でも必要に応じて PRF ファイルを使用できます。
では、CIW を使用して Outlook PRF ファイルをセットアップしましょう。実際には CIW ルーチン全体を実行するのではなく、変更した PRF ファイルのエクスポートに必要な部分のみを実行します。少しの操作だけで済みます。
まず、以前ダウンロードした 2 番目のファイル (カスタム インストール ウィザード) を起動して展開します。[スタート] ボタンをクリックし、[プログラム] をポイントします。次に [Microsoft Office 2003 Resource Kit](Microsoft Office 2003 リソース キット) をクリックして、ウィザードを起動すると、Office 2003 MSI ファイルの場所を指定するよう求められます。Office 2003 のディスクを挿入し、MSI ファイルの名前とパスを指定します。
CIW の他の操作を省いて PRF ファイルの作成のみを行えるように、CIW の最初のページを飛ばして 17/24 ページを表示します。17 ページ目で、[新しいプロファイル] を選択し、新しいプロファイルに Outlook などの名前を付けて、[次へ] をクリックします。Exchange Server を指定できる画面が表示されます (図 7 参照)。Exchange Server の名前を入力し、[次へ] をクリックして次に進みます。
図 7 Exchange Server 接続の構成
図 7 Exchange Server 接続の構成
作成するプロファイルには Outlook アドレス帳を追加すると便利です。こうすることで、ユーザーが新しいメッセージを作成するときに連絡先を選択できるようになります。この作業だけで、今後必要になる手作業を大幅に省くことができます。また、[追加] をクリックすると、追加のカスタマイズ機能をここで構成できます。では [次へ] をクリックし、PRF ファイルのエクスポートに必要な残りの作業を行いましょう。
この段階では、バッチ ファイルを作成して、これを TS01 ではなく、ドメイン コントローラの Netlogon 共有に保存します。このバッチ ファイルにより、必要なマッピングを起動し、展開に使用する PRF ファイルをセットアップします。読者の作業が楽になるよう、WMI スクリプトを作成しました。ただし、これらのスクリプトはあくまでも参考として使用し、状況に合わせて適切な情報を追加してください。好みに合わせて、KiXTart など、他のスクリプト プロセッサを使用することもできます。
バッチ ファイル (logon.bat) には、次のコードを含めます。
REM Logon.bat
@echo off
wscript %0\..\clean.vbs
wscript %0\..\outlook.vbs
Clean.vbs ファイルは、First-Run レジストリ キーを削除して、Outlook が PRF ファイルを処理するようにします。
' Clean.vbs
Const HKEY_CURRENT_USER = &H80000001
sComputer = "."
Set oRegistry=GetObject("winmgmts:\\" & _
    sComputer & "\root\default:StdRegProv")
sKeyPath = "Software\Microsoft\Office\11.0\
    Outlook\Setup"
sValueName = "First-Run"
oRegistry.DeleteValue HKEY_CURRENT_USER, sKeyPath, _
    sValueName
Outlook.vbs は、適切な Outlook セットアップ キーを各ターミナル サーバー ユーザーのレジストリに追加します。SValue= の設定には任意のパスを指定します。また、忘れずに、カスタマイズした実際の PRF ファイルを実際のネットワーク ディレクトリに追加してください。
sValue = \\Serv01\PRF\Outlook.prf
このパスを変更して、実際の Outlook.prf に書き換えます。
' Outlook.vbs
Const HKEY_CURRENT_USER = &H80000001
sComputer = "."
Set oRegistry=GetObject("winmgmts:\\" & _
  sComputer & "\root\default:StdRegProv")
sKeyPath = "Software\Microsoft\Office\11.0\Outlook\
    Setup"
oRegistry.CreateKey HKEY_CURRENT_USER, sKeyPath
sValue = "\\Serv01\PRF\Outlook.prf"
sValueName = "ImportPRF"
oRegistry.SetStringValue HKEY_CURRENT_USER, _
    sKeyPath, sValueName, sValue
展開プロセスの次の作業は、Office 2003 または 2007 Microsoft Office system を TS01 にインストールすることです。前述のとおり、Microsoft Office はターミナル サービス環境向けに最適化されています。カスタム変換を作成する必要はなくなりました。既に選択されているもの以外の Office 機能を無効にすることもできますが、これは必須ではありません。逆に、機能を有効にすることもできますが、その場合は帯域幅に好ましくない影響がある可能性があります。有効にする機能は、運用環境に展開する前に、ラボ環境で必ずテストしてください。
Microsoft Office のどちらかのバージョンをインストールする前に、TS01 のモードを適切なユーザー モードにしてください。使用できるモードは、インストール モードまたは実行モードの 2 つです。ソフトウェアのインストールを実行する場合は、事前にインストール モードにします。TS01 をインストール モードにするには、コマンド プロンプトに次のように入力します。
C:>change user /install
インストールが完了したら、次のように入力して TS01 を実行モードに戻します。
C:>change user /execute
TS01 上で Setup.exe または Install.exe ファイルを実行した場合は、自動的にインストール モードになります。すべての Microsoft 製品に、この 2 種類の起動ファイルがあります。ただし、一部のアプリケーションでは一方が用意されていない場合があるため、念のため Change コマンドを使用してください。現在のモードがドのモードかわからなくなった場合は、次のコマンドを実行すると、モードを確認できます。
C:>change user /query
ここまで来れば、もう大丈夫です。Windows クライアント ワークステーションで、[スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックして、次のコマンドを入力します。
mstsc
Windows 2000 を使用している場合は、Microsoft ターミナル サービス クライアント (Mstsc) ユーティリティ をダウンロードできます。
リモート デスクトップ接続の画面が表示されます。ターミナル サーバーの名前または IP アドレスを入力して、接続します。[オプション] をクリックすると、ローカル ドライブに接続するかプリンタに接続するかを指定したり、画面の解像度を変更したりするなど、さまざまなオプションが表示されます。[オプション] 領域に TS01 をハードコーディングし、RDP プロファイルをデスクトップに保存することもできます。既定の RDP プロファイルの名前は、Default.RDP です。

管理作業
TS01 で何らかの管理作業を行う必要がある場合は、コンソールから物理的に操作しているかのようにシミュレーションを実行できるため、次のコマンドを使用すると便利です。
Mstsc /console
複数のターミナル サーバーを管理している場合は、管理ツールのリモート デスクトップ ユーティリティを使用すると、すべてのリモートのターミナル サーバーを 1 つのツリー形式にまとめて管理できるため、便利です。
覚えておくと便利な最後のコマンドは、Tsadmin です。これは、どのユーザーがターミナル サーバーに接続しているか、およびユーザーが開いている Windows プロセスはどれかを確認できます。また、ユーザーを追跡できることも、管理者にとってとても便利です。ただし、TSadmin をワークステーションから起動した場合は、ユーザーを追跡できないことに注意してください。この場合は接続しか表示できません。ユーザーの追跡、ユーザーへのメッセージ送信、またはユーザーのログオフを行うには、TS01 に直接ログインする必要があります。

まとめ
これで、ターミナル サービスについて十分な知識が得られたので、実際のターミナル サーバーの展開も簡単に実行できると思います。グループ ポリシーの設定や DFS など、さらに知識が必要なトピックも多数ありますが、GPO を設定するときはやみくもに適用しないようにする、ユーザーに適用する前には十分にテストを実施するなど、基本を覚えておけば、とてもよいスタートを切ることができるでしょう。

James D. Silliman は、MCSE 保持者で、DirectApps, Inc. のシニア システム エンジニアを務める、ターミナル サーバー展開の専門家です。DirectApps では、.NET ソリューションを構築するほか、ホスティングや ASP サービスを提供しています。彼の連絡先は James@directapps.com (英語のみ) です。


 編集者から: セキュリティのテイクアウト
編集者から
セキュリティのテイクアウト
Joshua Trupin

仕事場は 場所を選ばなくなりました。ここ 10 年の間に、"どこでも仕事ができる" という概念が普及しました。仕事をするのに職場の席にいる必要はありません。モバイル テクノロジにより、出張先でも、自宅でも、電車の中でも、また赤信号待ちの車の中でも生産性を維持することが可能になりました (ただし、車の中で仕事をする場合にはご注意ください)。本当にすばらしい世界になったものです。ただし、これまでにないような大きな課題を抱える IT プロフェッショナルにとっては事情が異なります。IT プロフェッショナルは、どこへでも持ち運べるデバイスをセキュリティで保護したり、管理したりする必要があります。
1980 年代、セキュリティとは、ユーザーに各自が所有しているフロッピー ディスクをビニール袋に入れて他人と共有しないように通知することで、新しいウイルスの報告に対処することでした (冗談かと思われるかもしれませんが、本当のことで、以前の職場で、この方法を採用したところ、コンピュータがウイルスに感染することはありませんでした)。悪意のあるプログラムがコンピュータに潜入しても、だれかがウイルスに感染したフロッピー ディスクを別のコンピュータで使用しない限り、職場でウイルスが蔓延することはありませんでした。また、IT プロフェッショナルが昼休みの間に各従業員のコンピュータから、こっそり 5.25 インチ ドライブを取り払ってしまうのも、それほど難しいことではありませんでした。運がよければ、フロッピー ドライブの代わりに 10 MB のハード ディスクを手に入れることができました。
1990 年代になると、ユーザーは Web を介してウイルスに感染するようになったため、ウイルスに感染したコンピュータを見つけるのが難しくなりました。10 年前とは異なり、絶大な効果をもたらすアナログな方法でユーザーのコンピュータからディスクを取り外して、コンピュータを保護することができなくなりました。
最近では、IT プロフェッショナルが企業全体のセキュリティ保護、グループ ポリシーの施行、ファイアウォール、検疫、チェックポイントの設定などの管理作業を行うようになりました。今後は、どのような管理作業に迫られるのでしょうか。前述のように、仕事場は場所を選ばなくなってきています。外出先でも、もちろんセキュリティの課題は存在します。このような状況には、どう対処したらよいでしょうか。
現在の IT の動向に対応するには、事務所にある資産をセキュリティで保護するだけでは、問題の半分を解決したに過ぎません。組織のセキュリティ強度は、その最弱の点で決まります。従業員が企業ネットワークに接続しているモバイル デバイスやノートパソコンを使用して社外で作業している場合は、そこから問題が生じる可能性があります。今月のトップ記事では、お疲れモードの IT プロフェッショナルのみなさんが安眠できるようにモバイル デバイスのセキュリティを確保する方法を紹介します。
もちろん、この問題について語ることは山ほどあります。今月は Exchange Server を使用した法令遵守の管理、ネットワーク アクセスの保護、ターミナル サービス、Windows PowerShell、SQL Server の展開について紹介します。すべてのトピックについて説明するとなると、1 ページを使い果たしてしまうでしょう (目次によると、厳密には 2 ページですが)。
これまでに発生したセキュリティに関する最も異常な事態について教えてください。TechNet Magazine のブログ (blogs.technet.com/tnmag) にアクセスして、ぜひ会話に参加してください。編集者がお待ちしています。—Joshua Trupin

次のマイクロソフト技術支援スタッフに心より感謝します。Alex Balcanquall、Tad Brockway、Anah Cameron、Jeroen de Borst、Michael Higashi、Ryan Hurst、Paul Limont、Sherman Lovell、Michael Murgolo、Shivakumar Seetharaman、John Speare、David Strome、Jim Truher

Joshua Trupin


 レター: 質問への回答
レター
質問への回答

イメージを作成する
記事「Windows® PE の概要」(2006 年 9 月号) で、Wes Miller が mkimg.cmd ついて説明しています。使用している Windows Vista™ システムには、このコマンド ファイルがありません。ちなみに、この Windows Vista™ システムには Windows 自動インストール キット (WAIK) と BDD (Business Desktop Deployment Solution Accelerator) 2007 が両方共インストールされています。現状の配布物としては、mkimg_pe2004.cmd と mkimg_pe2005.cmd があります。この 2 ファイルでは bldini.cmd ファイルを呼び出しますが、このファイルも存在しないようです。mkimg.cmd ファイルや bldini.cmd ファイルはどこにあるのでしょうか。
—Jim A.

この記事が公開されたのは Windows Vista のリリース前なので、Windows XP と Windows Server® 2003 で使用できる Windows PE のバージョン (Windows PE 1.6) に特化した内容になっています。後に公開された 2006 年 11 月号の記事で、Windows PE 2.0 という Windows Vista で使用できるバージョンについて説明しています。この記事は、Web サイトにあります。
Windows PE 2.0 イメージは、WAIK に含まれているツールを使用して構築およびカスタマイズできます。特に、"mkimg" コマンドは "peimg" コマンドに置き換わっています。WAIK オンライン ドキュメントで Windows PE 2.0 イメージを構築するためのチュートリアルを確認できます。

セキュリティの通説
複雑なパスワードよりも長いパスワードの方が好ましいという推奨事項 (2006 年 5 月、6 月合併号の「一般的なセキュリティ通説の解剖」に記載されています) を踏まえて、必要なときに長いパスワードを取得できるようにするための最善の方法について提案はありますか。長いパスワードを個人の記憶だけに頼るのは困難ではないでしょうか。また、アクセスが必要なシステムごとに別のパスワードを使用するようにも推奨されていますが、この場合も記憶と取得に関して同様の問題が発生するでしょう。
— Ian R.

これについて、良き友人であり寄稿者でもある Steve Riley がすぐに答えてくれたので、以下に紹介します。
"記憶からの取得可能性" というのは興味深い考え方です (ええ、この用語は今作ったものです)。複雑なパスワードに含まれる規則性のない文字の集まりを覚えるよりも、使用する文をパスフレーズとして覚える方が簡単ではないでしょうか。また、マッピング方式を採用すれば、多くのパスフレーズを覚えることができます。たとえば、Hotmail® のパスフレーズを「My dog and I got the mail.」とします。対象のサイト (電子メール サイト) との関連性 (メールを取得する) があるため、簡単に覚えることができます。マッピング方式を採用すると、eBay のパスフレーズには「My dog and I went shopping.」、企業のドメイン アカウントのパスフレーズには「My dog and I went to work.」、お気に入りの絵画サイトのパスフレーズには「My dog and I admired some art.」を設定できます。
パスフレーズの出所には、ほとんど制限がありません。中には、モンティ パイソンの映画から引用している人もいます。また、各語がキーボード上に並んだ文字で始まる 5 個の語で構成されるフレーズのみを使用する人もいます (たとえば、「Queen willie eats rancid turnips.」というフレーズの各語の先頭文字は QWERT になり、キーボード上に並んでいます)。ちょっとした創造力があれば、パスフレーズを使用することで、身元の証明に使用する秘密を強化すると同時に、パスワードに関する問題を減らすことができます。

「一般的なセキュリティ通説の解剖」はすばらしい記事です。この記事によって、私の仮説が少し崩れてきました。しかし、ソフトウェアによって個別のプログラムに一意の文字セット (Webdings® にある文字セットではなく、これまでに見たことがないもの) の生成と使用が可能だとしたら、考えられる一意の文字がすべて含まれる完全なセットをだれも持っていないのと、ユーザーだけがどの文字が生成および使用されているのかを知っているという理由から、複雑さに重点を置くことになるのではないでしょうか。私は、自分の USB キーを失くしたとしたら、「War and Peace」と入力するよりも、こうした文字で構成される短い行を再作成しようと考えるでしょう。
—H.D.

おもしろい考えですが、これまでに見たこともない一意の文字をどうすれば覚えることができるのでしょうか。その方法がよくわかりません。あなたがかつてプリンスと呼ばれたアーティストであれば別ですが。

Sysprep
記事「デスクトップ イメージの作成を簡略化する技法」(2006 年 5 月、6 月合併号) で、Shelly Bird は、Sysprep フォルダを構築するときは「プロセスは基本ハードウェアを備えたレガシ システム上にマスタ イメージを構築することから始まる」と説明しています。正確にはどういうことなのでしょうか。現在 BDD を参照していますが、1 つのイメージで展開することを提案する内容が見つかりません。この情報の入手方法を教えてください。
— Jon S.

あなたが参照している記事の中で著者が説明しているのは、イメージとしてキャプチャして他のコンピュータに再展開できる、標準化された参照構成の作成に関してです。つまり、(多くの状況に対応できるように) 環境には最もシンプルなハードウェアを使用し、Windows をインストールして基本的な仕様で構成します (組織全体に展開する必要がある変更事項も反映します)。その後、必要なアプリケーションをインストールし、Sysprep ツールを使用して展開の準備を行います (Sysprep ツールは、ハードウェア固有の情報を削除するので、イメージを新しいハードウェアに再展開できます)。
このプロセスの最善のガイダンスは、BDD に含まれている「コンピュータ イメージング システム機能チーム ガイド」にあります。BDD のコンピュータ イメージング システム コンポーネントには、イメージをカスタマイズおよび準備するのに役立つダウンロード可能なツールが含まれています。詳細については、microsoft.com/technet/desktopdeployment/bdd/standard/ComImgFea.mspx をご覧ください。

認証方法を変更する
仕事で SQL Server™ 2005 を使用しています。認証方法を Windows 認証から SQL Server 認証 (sa ログインを使用) に変更する方法を教えてください。
— Sara J.

SQL Server Books Online のトピック (msdn2.microsoft.com/ms188670.aspx) を参照すると、この問題を解決できます。ただし、(特にパスワードを使用せずに) sa を使用するとセキュリティに影響が出るため、Windows 認証を使用することを強くお勧めします。このため、コード サンプルでは sa (パスワードなし) は使用していません。

大げさな賞賛
毎月 TechNet Magazine を非常に楽しく読んでいます。とても楽しいので、何冊かをかばんや車に入れ、どこに行くときでも持ち歩いています。そのため、仕事中でも在宅時でも、どこにいても読むことができます。全部の号を Tablet PC か Pocket PC Phone のどちらかに入れて持ち歩きたいと考えています。MP3 プレーヤーでコンテンツのオーディオ バージョンを見たいのです。このマガジンは全体的にすばらしいので、好きで好きでたまらないのです。同僚全員にこのマガジンのことを話しており、必読書であると伝えています。
— Erasmo M.

オーディオ コンテンツをご希望なのですね。ご存知のとおり、TechNet Magazine のポッドキャストを毎月提供しています。TechNet Magazine サイト (www.technetmagazine.com) にアクセスして、左側のポッドキャスト リンクをクリックするだけです。ぜひご利用ください。

ジグソー ポスター
2006 年 3 月、4 月合併号に掲載された「Active Directory® コンポーネントのジグソー ポスター」では、Windows Server 2003 で Active Directory が動作するしくみについて、これまで見た中で最高のグラフィック描写が提供されます。私は、世界規模の組織を把握するために Windows 2000 と Active Directory でプロジェクトを管理していました。そのため、この種のポスターによって携わっているすべての作業が非常に容易になりました。それでも、我が社の企業の管理者がこのポスターで明確に説明されているコンポーネントに必ずしも同意しているわけではありませんが、この種の情報にアクセスすれば、こうしたコンポーネントをより一層のまとまりと一貫性を持って動作させるのに非常に役立ちます。このポスターはダウンロードできるのでしょうか。
— Mike C.

このポスターについてどれほど多くのリクエストを受けたかわかりません。世の中の多くの人々があなたと同じ質問を持っているようです。このポスターは go.microsoft.com/fwlink/?LinkID=80428 からダウンロードできるようになっていますが、レター サイズの用紙には印刷しないでください。大きすぎるので。

Outlook の電子メール署名を設定する
私は会社のシステム管理者です。現在、ドメイン内のすべてのユーザーの Outlook® 署名を標準化するスクリプトを作成しています。コラム「Outlook の電子メール署名を設定する」(2006 年 10 月) のサンプル コードを使用しています。ところが、小さな問題が発生しています。次のコードを使用して署名のフォントの色をカスタマイズして設定しようとしても、フォントの色が黒のまま変わりません。
objSelection.Font.Color = wdRed
フォントとフォント サイズは変更できますが、フォントの色を変更できません。
— Edison P.

どうしてフォントの色を変更できないのか、Scripting Guys に聞いてみました (私たちは Scripting Guys に直接つながる特別な赤い電話を持っています)。すると、Scripting Guys は次のように答えました。
フォントの色を変更するには、wdColor 列挙値を使用する必要があると思います。次のスクリプトを試してみてください。
  • スクリプトでこの定数を定義します。
wdColorRed = 255
  • 次のコードを使用して色を割り当てます。
objSelection.Font.Color = wdColorRed
これでうまくいきます。

Windows PE を入手する
我が社では Microsoft® Select ライセンス契約を所有しています。組織用に第 5 世代の Windows PE を入手する場合の連絡先を教えてください。特に、USB フラッシュ ドライブからブートする機能を使用したいと考えています。
— Thom S.

Windows PE はソフトウェア アシュアランスの特典サービスとして入手できます。ご利用のライセンス プログラムにこの特典が含まれているかどうかは、特典の比較表を参照することで確認できます。この特典が含まれていれば、組織の Microsoft Volume License Services アカウントを使用して Windows PE をダウンロードできます (https://licensing.microsoft.com からログインできます)。この Web サイトへのアクセスについてサポートが必要な場合は、組織のライセンス コーディネータまたはマイクロソフトのライセンス担当者に問い合わせることをお勧めします。


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

HTTP トラフィックを分析する
HttpWatch Professional Edition
httpwatch.com

HTTP は、ブラウザを使用した Web サイト通信の基盤となる、非常に便利な第 7 層のプロトコルです。さらに、Web サービスの出現により、多くの Windows® フォーム アプリケーションは、プログラムの更新をダウンロードしたり、自宅に電話して検証を行ったりするために HTTP を使用するようになりました。アプリケーション間で HTTP を使用した通信を行う場合、それに関する問題の発見、パフォーマンス チューニング、セキュリティの検証などが困難になる場合がありますが、HttpWatch Professional Edition は、Web とブラウザとの間の通信に関する問題のトラブルシューティングを行う際に役立ちます。
HttpWatch によって表示される Web 要求の詳細
HttpWatch によって表示される Web 要求の詳細
HttpWatch Professional は Internet Explorer® 6.0 や Internet Explorer 7 と統合されており、ブラウザの一番下に表示されるか、スタンドアロン ツールとしてブラウザの横に表示されます。HttpWatch の [Record] (記録) ボタンをクリックすると、すぐにトラフィックのキャプチャと記録が始まり、Web 要求の詳細がすべて表示されます。未処理の HTTP ストリーム、ページ要求に対して発生したリダイレクト、要求に関連付けられたクエリ文字列のキーと値のペア、HTTP メソッド、HTTP 圧縮の情報、およびチャンクされたエンコード情報を表示できます。また、要求に関連付けられた Cookie の詳細情報 (Cookie のパス、ドメイン、有効期限、および値) も表示されます。このアプリケーションは
Internet Explorer のプラグインとして動作するので、復号化された HTTPS 要求の詳細もすべて表示することができます。
HttpWatch を使用すると、ミリ秒単位の応答時間、DNS 参照、TCP 接続、IP アドレス情報、ポート、およびブラウザで送受信されたバイト数が表示されるので、要求のパフォーマンスに関するネットワーク レベルの詳細なデータを確認できます。各要求を構成している要素はどれだけあると思いますか。1 つの HTML ページに対する 1 回の要求を構成する要素の多さには、いつも驚かされます。さいわい、HttpWatch では、コンテンツの種類、応答コード、URL、ヘッダー、またはコンテンツに含まれる特定の文字列でフィルタをかけることができます。これによって、照会範囲を限定し、目的の情報だけをすばやく表示できるようになります。
製品の Web サイトでは、顧客が抱える問題のトラブルシューティングを行う手段として、このツールを勧めています。このアプリケーションを使用すると、要求に関する情報を保存できるので、問題のある要求に関する情報を顧客から送信してもらうことができます。この情報は、トラブルシューティングに役立つ可能性があります。顧客は、数回のクリックだけで、専用の HWL 形式のファイルを電子メールで送信することができます。顧客からこのファイルを受け取ったら、インストール パッケージに含まれているスタンドアロンのログ ファイル ビューアを使用して表示することができます。また、要求に関するデータを CSV 形式や XML 形式のファイルにエクスポートして、他のアプリケーションで使用することもできます。
HttpWatch 用のオートメーション API も公開されているため、テスト中に HTTP レベルの情報を記録して、パフォーマンスのボトルネックの発見に役立てることができます。パッケージをインストールすると、この API の使用方法を示した 3 つのサンプル (C 言語で相互運用ライブラリを使用する 1 つのサンプルと、JavaScript と Ruby で COM を使用する 2 つのサンプル) がインストールされます。テストの目的で Ruby と Watir を併用する場合は、製品の Web サイトで、HttpWatch をテスト用プラットフォームに統合する方法に関するチュートリアルを参照してください。
価格 : 249 ドル (1 ユーザー ライセンスごと)

ブック レビュー
『Microsoft Solutions Framework Essentials』
microsoft.com/mspress

企業で優れたテクノロジ ソリューションを提供するには、効果的なプロセスと明確なコミュニケーション手段が必要です。Michael S. V. Turner の著書『Microsoft Solutions Framework Essentials』 (Microsoft Press、2006) には、Microsoft® Solutions Framework (MSF) Version 4.0 の基本要素に関する説明と、これらを使用して、テストされたプロセスやコミュニケーション プラクティスを開発および実装する方法が記載されています。
Turner はこの書籍の冒頭で、現在のプロセスや組織構造に、MSF で提供されるガイドラインやプラクティスを一度にすべて適用するべきではないと述べています。彼は、MSF の一部を製品開発やプロジェクト開発に実装し、その成否を評価することを勧めています。評価が完了し、良い結果が出たら、プロジェクトに合った別の MSF のガイドラインやプラクティスを選択し、通常のプロジェクト サイクルに取り入れます。これにより、使用中の環境に MSF を適合させることができるだけでなく、変更によって予期しない問題が発生する可能性を低減することができます。
この書籍は、テクノロジ ソリューションの提供に関与するすべての人 (技術者であるかどうかを問わず) を対象としています。「MSF チームを構成する」という章では、優れたソリューションを提供するために、技術者とそれ以外のメンバの両方が行うことができる作業、および行うべき作業が記載されています。ただし、これは日常業務の変更を伴うため、MSF の中では実装が比較的難しい部分であることが警告されています。
構造の変更において重要なのは、各メンバが異なる視点を持つピア (対等な関係を持つメンバ) としての役割を担い、プロセス全体の利点を積み重ねていく、アドボカシー グループからチームを形成するという考え方です (もちろん、これは、権限のある意思決定者が必要ないという意味ではありません)。書籍の中で説明されているように、MSF のアドボカシー グループは、製品管理、プログラム管理、アーキテクチャ、開発、テスト、ユーザー エクスペリエンス、およびリリースと運用の 7 つに分かれており、それぞれに固有の構成および責任があります。この書籍では、大規模なグループを持つ組織向けに、アドボカシー グループの考え方を拡張して、大規模なチームやグループをサポートする方法に関するアドバイスが提供されています。
リスクはどんなプロジェクトにも常に存在します。この書籍には、プロジェクトの再編成に関する多くのヒントが記載されているので、効果的にリスクに対処できます。プロジェクトのリスクを最小限に抑えることは重要であり、これを実現するために、6 つの手順に分かれたリスク管理プロセスを実行します。6 つの手順とは、識別、分析と優先順位付け、計画とスケジュール設定、追跡とレポート、変更の管理、および過去の経験からの学習です。また、プロジェクト サイクル全体にわたって、リスクを評価し続ける必要があります。このセクションに記載されている説明は、プロジェクトが失敗する可能性を低減することに大きく役立ちます。
この書籍には、ソリューションの提供に関する基本事項が詳しく記載されています。たとえば、ソリューションの構想、計画、構築、安定化、および展開を行うと共に、これらの各段階でそれぞれのアドボカシー グループが担う役割を定義するために使用する遂行トラックが記載されています。この説明では、ソリューションの提供ライフサイクルの各トラックを詳細に表した MSF ガバナンス モデルが紹介されます。MSF ガバナンス モデルは、構想、計画、構築、安定化、展開、およびガバナンス (ソリューションの提供に関する指針を提供すること) というトラックから構成されます。
この書籍で説明されているツールやプロセスは、組織内で読者が担っている役割には必要ないと感じられる場合もあるかもしれませんが、この書籍を読むことにより、現在のプロセスに対して新たな理解を得ることができます。これは、担当している役割が運用、開発、プロジェクト管理のいずれの場合にも言えることです。担当している仕事がソフトウェア開発に関連していない場合でも、この書籍の内容を基にして、組織内で効率を向上させたり、コミュニケーション手段を強化したりすることができます。
価格 : 44.99 ドル

ファイルを編集する
UltraEdit
ultraedit.com

IT プロフェッショナルとして本格的な作業を行っている開発者は皆、強力なエディタを必要としています。私が考える必携エディタの 1 つは、IDM Computer Solutions の UltraEdit です。このエディタは、ASCII 文字の挿入、マクロ、正規表現による検索と置換、外部アプリケーションの起動、UTF のサポート、大量のテキスト ファイルの高速処理など、優れたテキスト エディタが標準的に備えている機能をすべてサポートしています。また、いくつかの特殊な機能が用意されており、それらも非常に役立ちます。
基本的な編集に関しては、複数の言語が統合された 100,000 語のスペル チェック、オートコンプリート、C# などの標準的な言語のコード構文の強調表示などの機能が用意されています。また、指定した列に強制改行を挿入し、自動的に右端で折り返されるように設定することができます。この機能は、テキストベースの電子メールの書式を、各行が特定の長さより短くなるように設定する場合に役立ちます。書式を設定した後、UltraEdit でマウスを数回クリックするだけで、その電子メールを送信できます。このアプリケーションはエクスプローラと統合されているので、編集用にファイルを開くには、右クリックの後に左クリックを行うだけで済みます。
UltraEdit でのコード構文の強調表示
UltraEdit で処理できるのはテキスト ファイルだけではありません。このエディタはバイナリ ファイルも適切に処理することができるので、16 進値、行の参照、一般的な ASCII 値などを、標準的な 16 進エディタと同じように表示できます。16 進編集モードでは、標準的な検索や置換だけでなく、値の切り取り、コピー、および貼り付けも行うことができます。UltraEdit には、FTP 接続と SFTP 接続の両方をサポートする FTP クライアントが組み込まれています。また、標準的な Secure Shell (SSH) 接続や Telnet 接続も開くことができます。
このアプリケーションには、Web 開発者向けに、Web ページをチェックするための HTML 検証ツールが組み込まれています。また、テキストベースのデータベース ファイルや区切り記号付きログ ファイルを処理するための列モードも用意されています。このモードを使用すると、データ間の移動、データの合計、およびデータの編集を簡単に行うことができます。UltraEdit では、複数のファイルを 1 つのプロジェクトやワークスペースにグループ化して、関連する一連のファイルを 1 回のクリックで開くこともできます。全体的に見て、UltraEdit には、IT に関する作業を簡略化および効率化できる多くの機能が用意されていると言えます。
価格 : 49.95 ドル (直販、1 ユーザー ライセンスごと)

モバイル構成を管理する
Net-Switch
net-switch.com

よくある問題に、ノートパソコンを持って、ある環境から別の環境に (たとえば、データセンターの建物から品質監査環境などに) 移動する際に、ノートパソコンの静的 IP アドレスと既定のプリンタを、そのたびに割り当て直さなければならないというものがあります。もし身に覚えがあるとしたら、Net-Switch を試してみることをお勧めします。この便利なユーティリティを使用すると、複数のネットワーク構成を設定および保存することができます。それぞれの構成に対して既定のプリンタを割り当てることができるので、ある環境から別の環境に移動するたびに、プリンタ番号を思い出したり入力したりする必要はありません。
ノートパソコンの設定を構成する Net-Switch
これは非常に使いやすいアプリケーションです。必要な操作は、構成の名前を指定し、ネットワーク アダプタを選択し、静的 IP アドレスと関連するサブネット マスク、ゲートウェイ、および DNS サーバーを割り当て (または DHCP を選択し)、既定のプリンタを設定することだけです。費用をそれほどかけることなく、日常の面倒をなくすことができます。
価格 : 19.95 ドル (直販)

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

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


 SQL に関する Q&amp;A: Best Practices Analyzer、マルチコア プロセッサなど
SQL に関する Q&A
Best Practices Analyzer、マルチコア プロセッサなど
Nancy Michell

質問 – スキーマ修飾テーブルとスキーマ修飾ビューの使用に関する Best Practices Analyzer (BPA) のルールについていくつか質問があります。BPA のドキュメントによると、このルールでは一時テーブルでのスキーマ修飾がチェックされません。BPA レポートでは、ストアド プロシージャ内で作成された一時テーブルへの参照にフラグが設定されます。これらは修飾されるべきではないでしょうか。この場合、どのようなスキーマで修飾されますか。他のテーブルと同様に、一時テーブルもその所有者で修飾されるのではないかと思うのですが。
回答 – スキーマ修飾テーブルとスキーマ修飾ビューの参照についての BPA による推奨は、SQL Server™ 2005 では完全には当てはまりません。これ以前のバージョンではスキーマ修飾が必要になっていた問題が、SQL Server 2005 ではユーザーとスキーマの分離により解決されているためです。SQL Server 2000 では、既定のスキーマが異なる別のユーザーがクエリ プランを再利用できるようにするために、スキーマ修飾が必要でした。修飾なしで dbo オブジェクトを使用することもできましたが、SQL Server はまずオブジェクトの既定のスキーマをチェックしなければならず、これがクエリ プランの再利用を妨げていました。ユーザーとスキーマが分離されたことにより、他のユーザーが既定のスキーマを共有できるようになったため、一般的にはすべてのデータベース ユーザーが各ユーザーの既定のスキーマのオブジェクトにアクセスできるようにするために、修飾されていないテーブル名とビュー名を使用するアドホック プランが、通常ユーザー間で共有および再利用されます。ストアド プロシージャ内の修飾されていないテーブル名やビュー名は、そもそもこの問題の影響を受けることはなく、このことからもこの処理の必要性は低くなります。SQL Server 2005 の BPA には、T-SQL パーサーがないため、このようなルールは含まれない予定です。代わりに、不適切な構成やセキュリティ設定がないかがチェックされます。

質問 – SQL Server 2005 SP1 で奇妙な動作が見られます。同じテーブルに対してテーブルの行の削除と挿入を同時に行うと、削除のトランザクションがコミットされるまで挿入がロックされます。何がブロックしているのかを確認する方法はありますか。
回答 – はい、あります。図 1 の動的管理ビュー (DMV) スクリプトを実行して、ロックおよびブロックしている処理を確認できます。
Figure 1 ブロックしている処理とロックの検出 (Close Figure 1)
-- script to show blocking and locks
SELECT
  t1.request_session_id AS spid,
  t1.resource_type AS type,
  t1.resource_database_id AS dbid,
  (case resource_type
   WHEN ‘OBJECT’ THEN object_name(t1.resource_associated_entity_id)
   WHEN ‘DATABASE’ THEN ‘ ‘
   ELSE (SELECT object_name(object_id)
      FROM sys.partitions
      WHERE hobt_id=resource_associated_entity_id)
  END) AS objname,
  t1.resource_description AS description,
  t1.request_mode AS mode,
  t1.request_status AS status,
   t2.blocking_session_id
FROM sys.dm_tran_locks AS t1 LEFT OUTER JOIN sys.dm_os_waiting_tasks AS t2
ON t1.lock_owner_address = t2.resource_address
GO

質問 – ハイパースレッドやデュアルコア テクノロジだけでなく、さらに多くのコア (4 コア、8 コアなど) を搭載したプロセッサのリリースが始まっています。現在、SQL Server 2005 Standard Edition の展開を行うために、マルチコア プロセッサを搭載した新しいサーバーの購入を検討していますが、4 コアのプロセッサを使用する場合、実際に使用できるのは 1 基の物理 CPU のみになるのでしょうか (Standard Edition でサポートされるのは最高で 4 CPU のため)。
回答 – ライセンスやエディションでの CPU のサポート数について、SQL Server ではプロセッサのコア数とは無関係に、物理ソケット (CPU) 数のみが考慮されます。したがって、たとえば SQL Server 2005 Standard Edition が最高で 4 CPU をサポートするという場合、CPU のコア数とは無関係に、4 つの物理 CPU ソケットをサポートすることになります (つまり、4 コアの物理 CPU が 4 基ある場合、展開した Standard Edition が使用できる論理 CPU 数は 16 になります)。また、コア (論理 CPU) 数は 16 でも、必要になるライセンス費用は 16 コア分ではなく、4 物理 CPU 分のみです。SQL Server およびマルチコアの詳細については、microsoft.com/sql/howtobuy/multicore.mspx を参照してください。

質問 – 新しいデータベース サーバーの購入を検討しています。64 ビット版を購入すべきでしょうか。それとも、テスト済みの 32 ビット版を購入すべきでしょうか。
回答 – 状況によって異なります。x86 から x64 へのハードウェアの移行が進んでいるため、最近よくこのような質問を受けます。まず、データベース サーバーのメモリ負荷がどの程度になるかを確認する必要があります。ハードウェアの運用期間中 (通常 3 年間) に SQL Server インスタンスが使用する RAM が 3 GB 未満の場合、他のサーバー (ドメイン コントローラ、DNS サーバー、アプリケーション サーバー、Web サーバー、メール サーバー) で 32 ビット x86 が使用されているのであれば、32 ビット x86 が妥当です。SQL Server インスタンスが 16 GB 以上を使用するか、1 サーバー (またはクラスタ) に複数のインスタンスが存在する場合は、64 ビット テクノロジへの移行をお勧めします。8 プロセッサを超える場合は、IA64 が標準の推奨です。ただし、4 コアと 8 コアの x64 CPU が市場へ多量に供給され始めているため、コスト面から IA64 ではなく x64 の方がメリットがある場合もあります。
x64 (または IA64) に移行する際、最初のコストの見積もりでは、開発環境、テスト環境、パフォーマンス環境で同じアーキテクチャを展開することは考慮されていない場合があります。しかし、ハードウェア ライフサイクルの途中までは古いテクノロジを使用するかどうかについても考慮する必要があります。18 か月後には、純粋な x86 ハードウェアはほぼ調達できなくなるでしょう。この種のソリューションを現時点で選択した場合、今後 1 ～ 2 年のうちにアップグレードを行うと、完全なリプレースとなるため、コストが高くなると思われます。現時点で 64 ビット ハードウェアを選択しておけば、今後数年間で使用できる選択肢が多くなります。
そのため、64 ビットへ移行するタイミングとしては、新しいハードウェアの購入時、主要アプリケーションのリリース サイクルの開始時、または SQL Server 2000 から SQL Server 2005 へのアップグレード時が適しています。

質問 – 2 台のサーバー間でログ配布を有効にしています。週末にプライマリ サーバーでハードウェア障害が発生し、ログ配布が停止しました。ログ配布の監視を再開したところ、数時間ダウンタイムがあったにもかかわらず、LS_backup_dbname は適切に実行されていました。
しかし、セカンダリ サーバーでは、コピー ジョブは適切に機能しているようですが、復元ジョブではファイルがスキップされ、最終的に失敗を繰り返しているようです。実行はされているのですが、すべてのファイルがスキップされ、失敗します。そのため、最後の復元から、849 分が経過しています。以前同じような状況では、単純に配布構成をもう一度初期化しました。つまり、配布を一度無効にしてから再び有効にして、セカンダリ サーバーに新しいバックアップがコピーおよび復元されるようにして、ログ配布を再開しました。このような状況の対応として、他に良い方法はあるでしょうか。
回答 – おそらくこれは、バックアップ ファイルが失われていることによる影響です。ご存じのとおり、ログ配布では、バックアップ ジョブ、コピー ジョブ、および復元ジョブが個別に実行されます。コピー先の古いバックアップ ファイルも、指定されたスケジュールに従って削除されます。復元ジョブが実行されない期間があった場合、スケジュール設定された期間を過ぎてしまい、バックアップ ファイルが失われることがあります。ログ配布の復元ジョブには、別の操作上の状態に起因するこれ以外の問題からの復元を試みるロジックがあります。これは基本的に、エラーが発生した際にファイルをスキャンし、適切なバックアップ ファイルの検出を試みるものです。適切なバックアップ ファイルが見つからない場合は、何らかの理由で必要なファイルが削除されたか、ログ配布のバックアップの部分が再構成されたと考えられます。
解決策としては、他のバックアップ ジョブにより何らかの事情で作成されているトランザクション ログ バックアップ ファイルを使用して手動で復元することです。これをログ配布用のコピー先に単にコピーした場合問題になるのは、ログ配布が認識する命名規則です。ただし、その時点から手動で復元できれば、通常の復元が再び機能するようになります。

質問 – T-SQL を使用して物理メモリの合計容量と空き容量を調べる方法を教えてください。この情報を取得する簡単な方法はありますか。
回答 – 図 2 のクエリを実行すれば、必要なデータを取得できます。
Figure 2 メモリの取得 (Close Figure 2)
With VASummary(Size,Reserved,Free) AS
(SELECT
  Size = VaDump.Size,
  Reserved = SUM(CASE(CONVERT(INT, VaDump.Base)^0)
  WHEN 0 THEN 0 ELSE 1 END),
  Free = SUM(CASE(CONVERT(INT, VaDump.Base)^0)
  WHEN 0 THEN 1 ELSE 0 END)
FROM
(
  SELECT CONVERT(VARBINARY, SUM(region_size_in_bytes))
    AS Size,
    region_allocation_base_address AS Base
  FROM sys.dm_os_virtual_address_dump
  WHERE region_allocation_base_address <> 0x0
  GROUP BY region_allocation_base_address
  UNION
  SELECT CONVERT(VARBINARY, region_size_in_bytes),
    region_allocation_base_address
  FROM sys.dm_os_virtual_address_dump
  WHERE region_allocation_base_address = 0x0
)
AS VaDump
GROUP BY Size)

SELECT SUM(Size*Free)/1024 AS [Total avail mem, KB] ,CAST(MAX(Size) AS INT)/1024
    AS [Max free size, KB]
FROM VASummary
WHERE Free <> 0

質問 – 対称キーを使って暗号化されたファイルに sa (システム管理者) パスワードを保存して、アプリケーションから簡単にデータベースを作成できるようにしたいのですが、これは可能でしょうか。
回答 – まず何より、sa は決してアプリケーションから使用しないでください。また、SQL Server 認証ではなく、Windows 認証を使用してください。
高いレベルの特権が必要な操作を実行する必要がある場合は、次のように処理してください。目的の操作の実行に必要最低限の権限を定義します。このような権限を含むデータベース ロールを定義します。このロールにユーザーを割り当てます。目的の機能を実行する Execute As 句を指定したストアド プロシージャを作成します。Execute As 句の説明については、msdn2.microsoft.com/ms188354.aspx を参照してください。
もちろん、問題のアカウントが sa アカウントであるかどうかにかかわらず、また Windows 認証が常に利用できるとは限らないことを考慮した場合に、より基本的な問題となるのは、SQL Server のログイン アカウントのパスワードを、このパスワードを使用する必要があるアプリケーションからはアクセスでき、権限のないユーザーやアプリケーションからはアクセスできないような形で、安全に保存するにはどうしたらよいかということです。
パスワードの暗号化は、方向性は正しくても、問題がパスワードの保護から暗号化キーの保護に代わっただけのことです。
これが Microsoft® .NET Framework ベースのアプリケーションの場合は、エンタープライズ ライブラリ (msdn2.microsoft.com/aa480453.aspx) および MSDN® の「パターンとプラクティス」(msdn.microsoft.com/practices) を参照してください。エンタープライズ ライブラリには、構成用のブロック、暗号化用のブロック、データ アクセス用のブロックなど、役立ちそうなアプリケーション ブロックがいくつかあります。これらは、(少なくとも) 安全にパスワードを保存するうえで有用なだけでなく、データ アクセス全般の管理にも役立ちます。
エンタープライズ ライブラリを使用できない場合 (.NET Framework を使用していない場合など) は、CryptoAPI (msdn2.microsoft.com/aa380255.aspx) を参照してください。この記事では、OS に組み込まれている中核となる暗号化機能について説明しています。この暗号化機能を使用すると、暗号化キーと、ユーザー プリンシパルやコンピュータを関連付けることができるため、(パスワードを暗号化した場合に問題となる) キーの管理が容易になります。

質問 – SQL Server 2000 ベースの 2 ノードのクラスタ サーバー (アクティブ/アクティブ構成、64 ビット ハードウェアを使用) を、同じフォレスト内のドメイン A からドメイン B に移行する必要があります。SQL Server データベースは、SAN 内に配置されています。Active Directory® アーキテクチャでは、空のルート ドメインの下に、2 つの子ドメイン (ドメイン A とドメイン B) を配置する必要があります。ドメイン B が、すべてのインフラストラクチャ コンポーネントの配置先となるドメインです。Windows Server® 2003 Enterprise 環境で、Windows 2000 を実行するドメイン コントローラが他にあります。
SQL Server クラスタ サーバーのメンバシップをドメイン A からドメイン B に変更することは可能でしょうか。
回答 – まず、「SQL Server 2000 フェールオーバー クラスタのドメインを変更する方法」および「Windows クラスタ サーバーをあるドメインから別のドメインに移動する方法」を参照してください。複数インスタンスのクラスタにも、同じプロセスを利用できます。唯一の違いは、必要に応じてインスタンスごとに手順を繰り返し実行しなければならないことです。クラスタのドメインの変更は、複雑な処理が必要になるため "推奨" されていませんが、頻繁に行われています。これ以外の方法としては、ご指摘のように、新しいインスタンスをサイド バイ サイドで構築し直して、データを移行する方法しかありません。
プロジェクトはそれぞれ異なり、実際のドメイン レベルの変更を行うためにはさまざまなツールが使用されます (セキュリティ上の考慮事項、アカウントの移行、SID マッピングなど)。変更自体よりも、プロセスのこの部分が最も難しくなることが多くあります。

次の Microsoft IT 技術支援スタッフに心より感謝します。Sunil Agarwal、Laurent Banon、Steve Bloom、Chad Boyd、Matt Burr、Shaun Cox、Cindy Gross、Bobby Gulati、Matt Hollingsworth、Arnost Kobylka、Mikhail Shir、Fernando Pessoa Sousa、Stephen Strong、Ramu Veeraraghavan。


 ユーティリティ スポットライト: SharePoint サイトおよびテンプレート用のアップグレード ツールキット
ユーティリティ スポットライト
SharePoint サイトおよびテンプレート用のアップグレード ツールキット
Luis Câmara Manoel and Peter Skjøtt Larsen
この記事で使用しているコードのダウンロード: Upgrade Toolkit for Windows SharePoint Services Sites and Templates (699KB)

最近 Windows SharePoint Services (WSS) 3.0 がリリースされたことにより、多くの管理者は既存の WSS 2.0 サイトおよびデータを新しい WSS 3.0 環境にアップグレードする作業に直面しています。
WSS 3.0 では、サイトのデータの移行およびサイトの構造のアップグレードを適切に行うための豊富なツールが提供されますが、カスタマイズされたサイトやサイト テンプレートの構造をアップグレードするには、追加の作業が必要になる場合があります。
幸運にも、Microsoft® ソリューション アクセラレータ チームにより、この作業に関するガイダンスとツールが含まれた、Windows® SharePoint® Services サイトおよびテンプレート用のアップグレード ツールキットがリリースされました (補足記事「WSS の関連情報」を参照してください)。このコラムでは、カスタマイズされたサイトを WSS 3.0 環境にアップグレードする作業に関するいくつかの問題と、それらに関連するソリューションについて重点的に説明します。まずは、補足記事「WSS に関する用語」でよく使われる用語の定義を確認してください。

アップグレード プロセス
アップグレードをお勧めする理由について説明しましょう。WSS 3.0 には、アップグレードに対するサイト所有者の興味を引く、次のような多くの新機能が用意されています。
  • ごみ箱 - ユーザーは、誤って削除したドキュメントを復元できるようになります。
  • フォルダ項目レベルのセキュリティ - サイトの管理者は、フォルダにアクセスできるユーザーやグループを制御できるようになります。
  • リストへの電子メールの送信 - SharePoint サイトにあるリスト (ブログの投稿リストなど) に、電子メールでコンテンツを送信できるようになります。
  • [サイトの操作] ボタン - ユーザーは、サイトとページの作成、ページの編集、およびサイトの設定の管理を容易に行うことができるようになります。
  • 階層リンク - ユーザーは、サイト内の現在位置をひとめで把握できるようになります。
  • モバイル ビュー - モバイル ユーザーは、便利なオフライン同期機能を活用できるようになります。
  • RSS フィード - Internet Explorer 7.0 や Outlook® 2007 などの RSS 対応プログラムで、リストから情報を取得できるようになります。
  • ドキュメント ライブラリでのバージョン管理 - マイナー バージョンを管理したり、編集前のドキュメントのチェックアウトを制御したりできるようになります。
サイトとテンプレートのアップグレード プロセスが成功するかどうかは、実際にサーバーを WSS 3.0 にアップグレードする前とアップグレードした後に実行する特定の手順 (図 1 を参照) によって決まるため、サイトとテンプレートのアップグレード要件を定義することは、WSS 3.0 のアップグレード戦略全体の中でも重要な手順です。サイトの所有者とサーバーの管理者は協力して、どのサイトとテンプレートをインスタンス化して WSS 3.0 環境にアップグレードする必要があるかを決定する必要があります。アップグレードするカスタム サイトを選択したら、アップグレード作業を開始できます。
図 1 WSS サイトとサイト テンプレートのアップグレード ワークフロー
図 1 WSS サイトとサイト テンプレートのアップグレード ワークフロー

カスタマイズされたサイト テンプレートを特定する
サイトがカスタマイズされているかどうかを確認するにはどうすればよいでしょうか。WSS 3.0 で提供される、アップグレード前のスキャン ツールを実行すると、ファーム全体のサイト テンプレートに加えられた変更に関するレポートが生成されます。移行を開始する前にこのツールを実行して、特に注意が必要なサイト テンプレートを特定する必要があります。
このツールを実行すると、図 2 のような XML 形式のレポートが提供されます。unghostedPage 要素は、サイトがカスタマイズされていることを示しています。
Figure 2 サイト テンプレートに加えられた変更に関して、アップグレード前のスキャン ツールから提供されるレポート (Close Figure 2)
<?xml version=”1.0” encoding=”utf-8”?>
<summary>
  <sites>
    <site url=”http://mscc-shr-v3-01” storage=”172767226”>
      <webs>
        <web url=”http://mscc-shr-v3-01/Board of Directors-Basic”>
          <unghostedPage url=”http://mscc-shr-v3-01/Board of Directors-Basic/Board Information/
                Forms/default.aspx” />
          <unghostedPage url=”http://mscc-shr-v3-01/Board of Directors-Basic/Board Information/
                Forms/AllItems.aspx” />
          <unghostedPage url=”http://mscc-shr-v3-01/Board of Directors-Basic/Board Information/
                Forms/DispForm.aspx” />
          <unghostedPage url=”http://mscc-shr-v3-01/Board of Directors-Basic/Board Information/
                Forms/EditForm.aspx” />
          <unghostedPage url=”http://mscc-shr-v3-01/Board of Directors-Basic/Board Information/
                Forms/Upload.aspx” />
          <unghostedPage url=”http://mscc-shr-v3-01/Board of Directors-Basic/Board Information/
                Forms/WebFldr.aspx” />
          <unghostedPage url=”http://mscc-shr-v3-01/Board of Directors-Basic/Company Finance and
                Business Planning/Forms/AllItems.aspx” />
          <unghostedPage url=”http://mscc-shr-v3-01/Board of Directors-Basic/Company Finance and
                Business Planning/Forms/DispForm.aspx” />
          <unghostedPage url=”http://mscc-shr-v3-01/Board of Directors-Basic/Company Finance and
                Business Planning/Forms/EditForm.aspx” />

カスタム サイト定義
アップグレードするほとんどのカスタマイズされた WSS 2.0 サイトは、おそらく標準の WSS サイト定義から作成されたテンプレートを基に構築されています。しかし、カスタマイズされたサイト テンプレートの中には、カスタマイズされたサイトの定義を基に構築されたものもあります。カスタマイズされたサイト定義を組織内の開発者が作成した場合や、カスタマイズされたサイト定義を基に構築されたサードパーティ製のアプリケーションまたはテンプレートを購入した場合は、このようなサイト テンプレートが存在する可能性があります。このコラムでは、標準のサイト定義のシナリオのみについて説明します。カスタム サイト テンプレートのシナリオの詳細については、補足記事「WSS の関連情報」を参照してください。
.stp ファイルとサイトが標準のサイト定義を基に構築された (これは、アップグレード サイト定義が WSS 3.0 に存在することを意味します) かどうかを確認したら、サイトのインストールとインスタンス化を開始できます。
特定の WSS 2.0 サイト テンプレートをアップグレードするには、最初にこれらのテンプレートを WSS 2.0 サーバーにインストールする必要があります (図 1 の段階 1 を参照)。次に、インストールされた各テンプレートを基にサイトを作成する必要があります。
このソリューション アクセラレータには、Stsadm.exe コマンドを使用したスクリプトのセットが用意されています (補足記事「ソリューション スクリプト」を参照してください)。これらのスクリプトを使用すると、複数の .stp ファイルのインストール、複数のサイトのインスタンス化、およびアップグレード プロセスが完了したサーバーの一時ファイルの削除を行うプロセスを効率化できます。Stsadm.exe は、SharePoint サーバーおよびサイトを管理するためのあらゆる WSS 操作を提供するコマンド ライン アプリケーションです。このソリューション スクリプトを使用すると、インストールとインスタンス化を一括で行うか、各作業を順番に行うことにより、このプロセスを自動化できます。インストールする .stp ファイルとインスタンス化するサイトが多い場合、大幅に時間を短縮できる可能性があります。
ソリューション スクリプト
このインストールおよびサイト作成プロセスでは、Stsadm.exe を実行する 2 つのスクリプトを使用します。
  • MigInstStp.cmd では、Stsadm.exe の addtemplate 操作を使用してサイト テンプレートをインストールします。この操作には、_SOURCEFILELOCATION、_SOURCEFILENAME、および _FILETITLE パラメータを指定します。
  • MigMakeSite_1.cmd では、新しいサイトを作成します。このスクリプトでは、Stsadm.exe の createweb 操作を実行します。この操作には、_SERVERURL、_SITENAME、_SITETEMPLATENAME、および _SITETITLE パラメータを指定します。
ローカルの WSS 2.0 サーバーで、サイト テンプレート (.stp) ファイルが保存されている場所にアクセスできることを確認してから、これらのスクリプトを実行します。これらのスクリプトを実行するには、サーバーのローカル Administrators グループのメンバであるか、サイトの作成権限を持つ WSS 管理者グループのメンバである必要があります。Windows SharePoint Services サイトおよびテンプレート用のアップグレード ツールキットに付属のガイドには、これらのスクリプトを最大限に活用する方法が詳しく記載されています。.stp ファイルをインストールし、サイトをインスタンス化したら、サーバーのアップグレードを開始できます。WSS 3.0 へのアップグレード方法は、「Windows SharePoint Services 3.0 へのアップグレード」に詳しく記載されています (補足記事「WSS の関連情報」に記載されているリンクから参照できます)。

WSS に関する用語
Windows SharePoint Services では、独特の用語が使用されます。一般的に使用される用語の簡単な説明を次に示します。
サイト定義 - 特定のサイトの種類を定義するファイルのセットです。サイト定義は、フロントエンド Web サーバー上の特定のフォルダに保存されている .xml ファイル、.aspx ファイル、.ascx ファイル、マスタ ページ ファイル、リスト テンプレート ファイル、およびコンテンツ ファイルから構成されます。WSS では、チーム サイト、空のサイト、およびドキュメント ワークスペースが含まれた標準のサイト定義のセットが既定で提供されます。初期状態では、これらのサイト テンプレートのみがサイト テンプレート ギャラリーに保存されており、[新しい SharePoint サイト] の [テンプレートの選択] の一覧から選択できます。
サイト テンプレート - SharePoint サイトのインスタンス化方法を定義します。新しい SharePoint サイトを作成するには、そのサイトの基になるサイト テンプレートを選択する必要があります。たとえば、標準の "空のサイト" テンプレートを基にして "取締役会" という名前の新しいサイトを作成できます。その後、インスタンス化したサイトにリスト、ライブラリ、Web パーツ、およびその他のカスタマイズを追加できます。これらのカスタマイズを他のユーザーが使用できるようにするには、"Blank Site" (空のサイト) サイト定義を基にした "取締役会" という名前のテンプレートとしてこのサイトを保存します。WSS により、そのカスタマイズされたサイト テンプレートは .stp (サイト テンプレート) ファイルとして保存され、サイト テンプレート ギャラリーに配置され、[新しい SharePoint サイト] ページの [テンプレートの選択] の一覧に表示されるため、ユーザーは後からそのテンプレートを基にして新しいサイトを作成できます。サイト テンプレートは、1 つの .stp ファイルに圧縮された、.xml ファイル、.aspx ファイル、画像ファイルなどの一連のサイト構成ファイルです (.stp ファイルの機能は .cab ファイルの機能に似ています)。これらのファイルの中で最も重要なのは Manifest.xml です。このファイルには、サイトの構造とナビゲーション、リストとライブラリ、Web パーツの配置、カスタム リスト定義、カスタマイズされたサイト テンプレートの基になったサイト定義などの重要な情報が含まれています。
アプリケーション テンプレート - 特定のビジネス プロセスや作業の要件を満たすために開発された Windows SharePoint Services サイト テンプレートです。これらのテンプレートはマイクロソフトによって公開されており、WSS ユーザーはそれらを無償でダウンロードできます。
カスタマイズされたサイト - ユーザー インターフェイスが変更された SharePoint サイトです。
マスタ ページ - サイト全体のインターフェイスに一貫性を持たせるために、バナー、ナビゲーション コントロール、その他のメニューなどの既定のレイアウト情報を保存できる領域です。
ゴースト ページ - コンテンツが WSS コンテンツ データベースに保存されず、サイト定義ファイルから読み取られるページです。ゴースト ページはカスタマイズされていません。
非ゴースト ページ - サイト定義ファイルの状態から変更されており、コンテンツが WSS コンテンツ データベースに保存されるページです。

サーバーのアップグレード後に行うサイトの検査
アップグレード ワークフロー (上記の図 1 を参照) の段階 2 に到達しました。この段階で行う手順を次に示します。
  1. アップグレードしたサイトを開いて検証します。
  2. 既定のマスタ ページを適用します。
  3. 新しいサイトの機能とレイアウトに関する問題を解決します。
  4. 修正後のサイトを新しい WSS 3.0 サイト テンプレートとして保存します。
  5. 新しい WSS 3.0 サイト テンプレートをサーバーに再展開します。
  6. 再展開したサイト テンプレートからサイトを作成します。
  7. 新しいサイトを開いて、サイトが期待どおりに機能するかどうかを確認します。
  8. クリーンアップ プロセスを開始します。

サイト定義へのリセット
アップグレードしたサイトを初めて開いたときの外観は、まだ WSS 2.0 サイトに非常に似ています。サイトの外観を WSS 3.0 サイトの外観に近付けるには、まず新しい WSS 3.0 サイトのサイト定義にリセットする必要があります。これにより、レイアウトに関するほとんどの問題が解決されます。また、Web パーツに対して行われたカスタマイズも、これらの Web パーツがサイト定義ページの [Web パーツ] の領域に表示されていれば、リセット後に失われることはありません。また、この操作により、サイトのすべてのページに既定のマスタ ページが適用されます。
マスタ ページは、その名のとおり、一貫性のある外観を提供するために、バナー、ナビゲーション コントロール、その他のメニューなどの既定のレイアウト情報を保存できる領域です。このため、マスタ ページのデザインを変更し、その変更をサイト全体に反映できるようになります。マスタ ページを適用することにより、WSS 3.0 に固有のすべての機能がアップグレード後のサイトで有効になります。
これでサイトの外観と機能はネイティブの WSS 3.0 サイトとほぼ同じになりましたが、ディスカッション掲示板、カスタマイズされた Web パーツ、ハイパーリンク、テーマなど、まだいくつか問題が見つかる可能性があります。

問題の解決
アップグレードおよびカスタマイズされたサイト テンプレートには、さまざまな問題が存在する可能性があります。最も一般的ないくつかの問題と、それらの解決方法に関する簡単な説明を次に示します。
引き続きサイトに WSS 2.0 の既定のスタイル シートが適用されている。 SharePoint Designer で古いスタイル シートを削除します。
Web パーツが存在しないか正しくない場所に配置されている。 SharePoint Designer を使用して Web パーツを移動または挿入します。
Web パーツが正しく機能しない。 WSS 3.0 と互換性がない Web パーツを削除し、対応する Web パーツが WSS 3.0 環境用に構築されているかどうかを Web パーツの開発者に問い合わせます。
カスタマイズされたリストとライブラリが正しく表示されない。 既存のデータを保存してから、カスタマイズされたリストやライブラリを再作成し、保存したデータをインポートします。
有効になった WSS 3.0 の機能を使用できない。 [サイトの機能] で、チームのグループ作業を明示的に有効にすることが必要になる場合があります。
ハイパーリンクが機能しなくなった。 ハードコードされたハイパーリンクは、手動で更新することが必要になる場合があります。
テーマが変更された。 適切な WSS テーマを適用します。

完了間近
プロセスが終わりに近付き、問題もすべて解決されたので、サイトの最終検証を実行しましょう。修正後のサイトを WSS 3.0 サイト テンプレートとして保存し、新しい .stp ファイルのインストールと新しいサイトのインスタンス化 (ここでも、この資料で紹介した便利なスクリプトを使用できます) を行った後、サイトを開いて、すべての問題が解決されたことと、アップグレードされたサイトと .stp ファイルを作業環境内で再配布できる状態になったことを確認する必要があります。

その他のアップグレード方法
この記事で説明した、自動化されたツールやプロセスを使用したテンプレートのアップグレードが必ずしも最適ではないことがあります。大幅にカスタマイズされたサードパーティ製のテンプレートを使用している場合、自力でテンプレートをアップグレードすることは非常に難しく、そのテンプレートの新しいバージョンが開発されるまで待った方がよいこともあります。その他の場合は、WSS 3.0 でまったく新しいテンプレートを作成した後、古いテンプレートの機能を実装することが最善の方法になるでしょう。

アプリケーション テンプレート
マイクロソフトでは、WSS 2.0 と WSS 3.0 用に開発されたアプリケーション テンプレートのセットを提供しています。新しい WSS 3.0 用のテンプレート セットには、WSS 2.0 用のいくつかのアプリケーション テンプレートをアップグレードしたものが含まれています。該当するテンプレートを使用している場合は、WSS 3.0 用にアップグレードされたテンプレートを、使用中の WSS 3.0 環境にアップロードできます。
まだ WSS 3.0 用にアップグレードされていない WSS 2.0 用のアプリケーション テンプレートを使用している場合は、このソリューション アクセラレータで提供される、WSS 3.0 環境で機能するようにアップグレードされた、WSS 2.0 用のアプリケーション テンプレートのセットを使用できます。

まとめ
Windows SharePoint Services サイトおよびテンプレート用のアップグレード ツールキットは、使用中の 2.0 テンプレート、サイト、およびカスタマイズを 3.0 環境でも使用する場合に非常に役立ちます。このトピックの追加情報と、このツールキットの入手方法については、補足記事「WSS の関連情報」に記載されているサイトを参照してください。
このコラムとソリューション アクセラレータの製作に重要な貢献を果たしてくれた Betty Houser に感謝します。
WSS の関連情報
  • アップグレード前のスキャン ツール
  • Windows SharePoint Services サイトおよびテンプレート用のアップグレード ツールキット
  • Windows SharePoint Services Version 3.0 へのアップグレード (Windows SharePoint Services 3.0 テクニカル ライブラリ)
  • アップグレード定義ファイルと新しいサイト定義の展開

Luis Câmara Manoelは、Microsoft ソリューション アクセラレータ グループのプログラム マネージャです。彼はマイクロソフトに勤務し始めて 1 年になります。以前は、ユタ州プロボにある Novell Inc および Volera で、プロジェクト マネージャとプログラム マネージャを務めていました。Luis の連絡先は、luiscam@microsoft.com (英語のみ) です。
Peter Skjøtt Larsenは、Microsoft ソリューション アクセラレータ グループの製品マネージャです。彼はマイクロソフトで 4 年間、開発とマーケティングを担当しています。以前は、金融、エンジニアリング、および通信業界用のクライアントおよびサーバー ソフトウェアを開発していました。Peter の連絡先は、petela@microsoft.com (英語のみ) です。


 ビジネスにおける IT: ビジネス計画を練る
ビジネスにおける IT
ビジネス計画を練る
Stephen Ibaraki

多くの読者にとってはおそらく周知のことでしょうが、最近は、正当な理由がなければ IT 関連の商品の購入や IT への投資を行うことができません。最新のコンピュータ技術を導入するという理由だけでは、投資する正当な理由にはなりません。自由で無計画なテクノロジの導入は、かつては市場での優位性と成長につながる手段と考えられていましたが、
この考え方は IT バブルの崩壊と共に終わりを告げ、IT への投資が制限されるようになりました。現在、IT プロジェクトは、ビジネスに真の価値をもたらす必要があります。
予算が厳しくなる状況で、IT 投資を正当化するには、ビジネス ケース (投資対効果検討書) に総合的な統合テクノロジ ソリューションを組み込む必要があります。具体的にはどのような内容を含めるのでしょうか。ビジネス ケースを作成するために不可欠な要素は何でしょうか。IT プロジェクトを正当化するためには、どのような方法でビジネス計画モデルを採用したらよいのでしょうか。ビジネス ケースに適切なテクノロジ ソリューションを統合する際に、何を想定する必要があるのでしょうか。この記事では、ビジネス ケースの作成のためのヒントを紹介します。

ビジネスの発展
成功を収めている企業や組織は、従業員、顧客、パートナー、サプライヤ、所有者などの利害関係者に数値化できる価値をもたらしています。この価値は、さらに高めるために継続的に調整を行い、明確に定義および評価される必要があります。
しだいにつながりが強まる世界において、企業は社内ネットワークおよび社外ネットワークと効果的に連携できるようにして、相互の関係をリアルタイムで最大限に活用できるようにする必要があります。サービス、問い合わせに対する回答、製品の出荷を待ったり、コミュニケーションの断絶が原因でプロジェクトが遅延したり、無活動状態が生じたりすることを望むユーザーはいないでしょう。インターネットの出現と加速し続けるグローバル化により、競合他社は近隣諸国の企業だけでなく、遠いところにある企業も含まれるようになりました。そのため、この競争の激しい環境で生き残るためには、差別化を図る必要があります。どのように他社との差別化を図ればよいでしょうか。
さらに、ビジネスには俊敏性が必要です。常に内部と外部の環境を意識し、多くの選択肢の中からビジネスの決定事項を選び出して実行できるようになる必要があります。その際には、強みは生かし、弱みは克服して、新しいビジネス チャンスをつかみます。このようなチャンスによって、企業は新しい市場や新しい顧客を獲得したり、新しい製品や新しいサービスを提供したりすることで成長することができます。また、競争力の強い企業などの脅威を見極め、その脅威を抑制する必要もあります。このことはすべて、運用上のコストとリスクを管理しながら、生産性や効率の向上を重視して行います。
テクノロジへの投資は、開発期間の短縮、顧客のニーズへのすばやい対応、競争上の脅威の予測、生産性の向上、効率化、および運用上のコストとリスクの削減につながり、また俊敏性を促進するものである必要があります。
ここまでは、ビジネスの成功の背景にある原動力、および IT によってこれらの原動力を支える方法について説明しました。このような支援が行われないと、IT コストはその存在を正当化できない無駄な経費となってしまいます。ビジネス計画の戦略を立てることで、確実に成功するビジネス ケースを作成することができ、結果として IT の成功につながります。

ビジネス計画を練る
IT 投資は、差別化、コストの削減、市場の焦点、コラボレーション、革新など、より高いビジネス価値と関連付けることが不可欠です。ビジネス計画を練ることで、この要件を満たすことができます。
IT ビジネス計画の基本要素の概要は図 1 のとおりです。計画の目標は何でしょうか。ミッションやビジョンに関する記述では、現在の業務内容と今後の展望を説明します。必ず、IT プロジェクトでこの総合的な目標を達成する方法を明確に説明する必要があります。IT 投資とビジネス目標の関連性 (具体的には、IT 目標によってビジネスの戦略的な方向性をサポートする方法) を詳しく説明する必要があります。つまり、IT 投資とビジネス戦略の間には関連性が必要です。
Figure 1 ビジネス計画の要素 (Close Figure 1)

要素 | 説明
目的 | 投資とビジネス目標との関連の概要。
ビジョン | ビジネスの成果、および IT によってこの目標を支援する方法。
ミッション | 現在のビジネス、および IT によってこのビジネスのミッションを促進する方法。
ビジネス チャンス | 主導権を握るべき市場とビジネスに対する価値。
ビジネス モデル | ビジネス チャンスをつかむために IT によって提供される製品またはサービス。
目標市場 | サービスの提供対象となる顧客 (または潜在的な顧客)。
IT 統合 | テクノロジ リソースによる製品およびサービスの支援。
競合分析 | 競合他社がその強みおよび弱みと共に記載された一覧。
SWOT 分析 | 強み (Strength)、弱み (Weakness)、機会 (Opportunity)、脅威 (Threat)。
リソース分析 | 必要な既存のインフラストラクチャおよび投入するリソース。
IT の成功の測定基準 | 評価対象となる計画の側面。
財務予測 | 投資収益率を測定する期間。
ビジネス チャンスに関する記述では、IT によって新しいビジネス チャンスを実現したり支援したりする方法と、IT によってもたらされる価値を説明する必要があります。具体的にはどのようなビジネス モデルがあるでしょうか。収益を上げるために、ビジネスでは、どのような製品やサービスを提供しますか。潜在的な市場の規模はどのくらいでしょうか。また、IT を強化すると、どれだけの成果を得られますか。IT によって、このビジネス モデルはどのくらい発展しますか。IT 投資により、提示したビジネス モデル内でワークフローとビジネス プロセスをどれだけ強化できるか (運用性の向上、コストの削減、効率化、連携の実現、コミュニケーションの強化、スケジュール設定、情報伝達など) を説明する必要があります。これらの強化点すべてが、コスト削減や生産性の向上につながります。IT によって達成できるビジネス運営における革新を主張することを忘れないでください。
また、目標市場について話し合う必要があります。IT 計画によって、ビジネスが既存の目標市場または新しい市場に浸透する方法を検討し、製品およびサービスに使用している配布システムと、IT による支援でより良いサービスと配布システムをこれらの市場に提供する方法について議論してください。
このような話し合いを行うことは、ビジネスで提供している製品またはサービスを IT テクノロジと統合する方法を検討することに直結します。具体的には、どのような製品やサービスが統合および統一されたテクノロジ プラットフォームに適していますか。これらの製品やサービスを IT によってどのように支援しますか。これはビジネス目標とどのように関連付けられますか。この問題提起は、IT によってサービスの管理、プロジェクトの提供、および社内外の関係を強化する方法を提案するための出発点です。IT は、サービス レベルの水準を向上し、効果的な管理、優先順位付け、法令遵守、プライバシー保護、セキュリティ強化などを行い、ビジネスに変化をもたらすことができます。これらの強化点は、すべてビジネス計画で説明する必要があります。
競合分析によって、ビジネスの競合状況を把握できます。競合他社はどの企業ですか。それらの企業の強みと弱みは何ですか。競合他社がどのようにテクノロジを採用しているのか、また市場での地位をどのように高めたのかに注目します。IT によって、競合他社に対して優位に立つことができるでしょうか。IT によって、ビジネスの俊敏性の向上、成長の促進、新しい市場へのすばやい参入、新しい顧客の確保、既存の顧客に対するサービスの強化などを実現する方法を説明します。テクノロジの導入によって、競合他社とどのように差別化し、ビジネスにメリットを提供しますか。IT は、競合他社の市場参入に対する障壁をどのように強化しますか。
SWOT 分析を行うと、ビジネスに関する強み (Strength)、弱み (Weakness)、機会 (Opportunity)、脅威 (Threat) について形式化された一覧が提供されます。ビジネスには、どのような外部の機会や脅威がありますか。IT は、新しい外部の機会を利用するために、どのようにビジネスの内部の利点を強化しますか。どのように内部の弱点を克服し、このような取り組みの結果として、企業が新しい機会を利用できるようなポジションを確立するのでしょうか。また、どの程度外部からの脅威が削減または軽減されますか。
IT 投資を行う際には、その実装前、実装中、および実装後のそれぞれの段階で必要なリソースを考慮する必要があります。リソースには、人員、ハードウェア、インフラストラクチャなどがあります。既存の知識やインフラストラクチャで利用できるものは何ですか。また、予算を組む必要があるものは何ですか。新しいトレーニングや設備にかかるコストを回収するのにどのくらいの期間がかかりますか。新しい投資によるメリットで、具体的に記述したビジネス計画に記載されていないものがある場合は、それらについても記載するようにします。
ビジネス計画が期待どおりのものであるかどうかを確認するには、成功の測定基準を事前に明確にしておく必要があります。どの側面で計画を評価しますか。どのくらいの頻度で成功に対する評価を行いますか。また、目標が効果的に達成されそうにない場合はどのように対処しますか。予期せず破壊的な影響を受けた場合に備えて、どのようなバックアップ計画を立てますか。
ビジネス計画には財務予測が必要不可欠です。総保有コストはどのくらいで、そのコストは新しいビジネス チャンスにおいてどのように正当化されるでしょうか。また、新しいビジネス チャンスの価値はどのくらいありますか。ビジネスで成功を収めた場合、投資収益率はどこでどのように現れますか。投資収益率の測定期間はどのくらいですか。IT は、収益および採算率の向上とコストの削減によって、どのようにビジネスの財務目標を高めますか。

今後の展望
計画が実際にうまくいくという保証はありません。ただし、ビジネス計画を練り、それを発展させるように努めることにより、主導権を握ることができます。この作業により、発生する可能性のあるすべての問題を検討し、計画を見直すか、または不測の事態の概要をまとめたりするようになります。また、計画を進めない場合のコストも含め、関連するコストと利益についての明確な考えを持てるようになります。最後に、評価のためのなんらかの基準がないと、成功したのか、無残にも失敗したのかを確認することができません。このような測定基準は、ボーナスの査定時期に、自分の計画がビジネスにとってどれほど重要であるかを上司に伝えるのにも役立ちます。
IT のビジネスに関する継続的なディスカッションについては、「IT Managers Connection」(blogs.technet.com/cdnitmanagers) を参照することをお勧めします。マイクロソフト Web サイトでは、リソース関連のビジネス計画についての記事を参照することもできます。Small Business Center (microsoft.com/smallbusiness/resources/startups/business_plans_ entities/how_to_write_a_business_plan.mspx) では、ビジネス計画の記述に関するチュートリアルが提供されています。また、Office Online (office .microsoft.com/en-us/templates) には、2007 Microsoft Office system で提供されるテンプレートに加え、多数のビジネス計画のテンプレートが用意されています。

Stephen Ibaraki は、ビジネスとテクノロジの分野において受賞歴のある大学教授であり、ビジネスと IT に携わって 35 年以上になるベテランです。彼は現在 Network Professional Association (NPA) の副会長を務めています。Stephen の連絡先については、www.StephenIbaraki.com (英語) を参照してください。


 The Cable Guy: Windows の EAPHost
The Cable Guy
Windows の EAPHost
Joseph Davies
このコラムには、Windows Server "Longhorn" のプレリリース情報が含まれています。この情報は変更される可能性があります。

アクセス クライアントが保護ネットワークに接続する場合、認証サーバーによる検証のために、ネゴシエート済みの認証方法を使用する必要があります。たとえば、アクセス クライアントと認証サーバーは、特定のパスワード認証プロトコル (Microsoft チャレンジ ハンドシェイク認証
プロトコル バージョン 2 (MS-CHAP v2) など) を使用することで同意します。ただし、アクセス クライアントと認証サーバーが、組み込みのハードコーディングされた認証方法を使用する場合、新しいプロトコルを追加することは困難です。
拡張認証プロトコル (EAP) は、IEEE 802.1X ベースのワイヤレス ネットワーク、ダイアルアップや VPN などのポイント ツー ポイント (PPP) 接続など、一般に使用される保護ネットワーク アクセス テクノロジの認証方法を拡張するための認証フレームワークです。EAP は、MS-CHAP v2 のような認証方法ではなく、アクセス クライアントと認証サーバー上のフレームワークで、ネットワーク ベンダが EAP メソッドと呼ばれる新しい認証方法を開発し、容易にインストールできるようにするものです。EAP の詳細については、マイクロソフトの EAP Web ページ (microsoft.com/eap) を参照してください。
EAP は Windows 2000 以降の Microsoft® Windows® でサポートされていますが、Windows XP と Windows Server® 2003 の EAP アーキテクチャには、EAP メソッドとサプリカント (特定の種類のリンク層上で EAP を使用できるソフトウェア コンポーネント) の拡張性に制限がありました。Windows Vista™ と Windows Server の次期バージョン (コードネーム "Longhorn") の EAPHost アーキテクチャではこうした制限が解消され、サードパーティのネットワーク ベンダが新しいサプリカントや EAP メソッドを追加して Windows をこれまでよりも容易に拡張できるようになります。

Windows Server 2003 と Windows XP での EAP サポート
Windows Server 2003 と Windows XP では、802.1X により認証を行うワイヤレス接続または有線接続、ダイアルアップや VPN ベースのリモート アクセスまたはサイト間接続などの PPP 接続に、EAP を使用しています。具体的には、これらのオペレーティング システムには、RFC 2284 準拠の EAP 実装と、IEEE 802.1X および PPP サプリカントが含まれています。図 1 は、Windows XP と Windows Server 2003 の EAP とサプリカントのアーキテクチャを示しています。ただし、Windows XP Service Pack 2 (SP2) と Windows Server 2003 SP1 の EAP 実装は、RFC 3748 (EAP の現在のインターネット標準) などの EAP RFC をサポートしていないことに注意してください。
図 1 Windows XP と Windows Server 2003 の EAP とサプリカントのアーキテクチャ
図 1 Windows XP と Windows Server 2003 の EAP とサプリカントのアーキテクチャ
EAP API は、Windows XP と Windos Server 2003 の認証を拡張する手段を提供します。サードパーティのベンダは、新しい EAP メソッドを開発して、インストールできますが、組み込みの PPP と 802.1X サプリカントはインストールされる EAP メソッドをすべて使用できるわけではません。たとえば、あるベンダが新しい指紋スキャン EAP 認証方法を開発しても、この方法はワイヤレス接続では使用できないと考えられます。
組み込みのサプリカントには制限があるため、一部のサードパーティのソフトウェア ベンダやハードウェア ベンダは、独自のサプリカントを開発しています。このようなサプリカントは、通常、組み込みのサプリカントと EAP アーキテクチャ全体を置き換えて無効にします。ただし、こうした代替措置には、いくつか問題があります。まず、組み込みのサプリカントと EAP アーキテクチャを置き換える場合は、開発コストがかかるため、作業が遅れる原因になります。また、企業ユーザーでは、独自のサプリカントを開発しないため、サードパーティ製品のライセンスを取得し、インストールするために、接続クライアント数を基準とするライセンス コストが必要になる可能性があります。

EAPHost の機能
EAPHost には、以下の新機能があります。
追加の EAP メソッドのサポート EAPHost は、EAP レジストリ (www.iana.org/assignments/eap-numbers) に登録されているすべての EAP メソッド、および Cisco Systems, Inc. が開発および提供している Lightweight EAP (LEAP) などの一般的なその他の認証方法のインストールと使用をサポートします。
ネットワーク探索 EAPHost は、RFC 4284 で規定されているネットワーク探索をサポートします。
RFC 3748 準拠 EAPHost は EAP ステート マシンに準拠しており、RFC 3748 で指摘されているさまざまなセキュリティの脆弱性に対応しています。以前は、サプリカントが独自のステート マシンを実装しなければなりませんでした。また、EAPHost は拡張 EAP タイプ (ベンダ固有の EAP メソッドを含む) などの機能をサポートします。
EAP メソッドの共存 EAPHost では、同じ EAP メソッドの複数の実装が同時に共存できます。たとえば、マイクロソフトの保護された EAP (PEAP) と Cisco Systems, Inc. の PEAP をインストールし、いずれかを選択できます。
モジュール型のサプリカント アーキテクチャ EAPHost は、モジュール型のサプリカント アーキテクチャをサポートします。このアーキテクチャにより、以前のバージョンのように EAP 実装全体を置き換えることなく、新しいサプリカントを容易に追加できます。
EAP メソッド ベンダにとっての EAPHost のメリットは、Windows XP と Windows Server 2003 用に既に開発した EAP メソッドがサポートされることと、Windows Vista と Windows Server "Longhorn" 向けに新しい EAP メソッドを容易に開発できることです。また、EAPHost では、EAP タイプのより細かい分類が可能なため、組み込みの IEEE 802.1X サプリカントもこれらを使用できます。
サプリカント ベンダにとっての EAPHost のメリットは、新しいリンク層用のサプリカントが新たにサポートされることです。EAPHost がネットワーク アクセス保護 (NAP) に統合されるため、新しいサプリカントは NAP に対応している必要はありません。新しいサプリカントは、接続識別子と、再認証のためにサプリカントに情報を提供するコールバック関数を登録するだけで、NAP に参加できます。NAP の詳細については、今月号の TechNet Magazine の John Morello による「セキュリティ ウォッチ」コラムと、NAP の Web ページ (microsoft.com/nap) を参照してください。EAPHost 用の EAP メソッドまたはサプリカントの開発方法の詳細については、拡張認証プロトコル ホスト (msdn2.microsoft.com/aa364249.aspx) を参照してください。

EAPHost と EAP インフラストラクチャのアーキテクチャ
EAPHost のアーキテクチャは、EAPHost 用の EAP インフラストラクチャ、EAP ピア (認証クライアント) 側の EAPHost アーキテクチャ、および認証サーバー側の EAPHost アーキテクチャから構成されます。図 2 は、Windows Vista または Windows Server "Longhorn" を実行するコンピュータ上の EAPHost 用の EAP インフラストラクチャ アーキテクチャのコンポーネントを示しています。これらのオペレーティング システムでは、EAP ピアに、サプリカント (組み込みの 802.1X サプリカントなど) の層、EAP ピア用の新しい EAPHost アーキテクチャ (サプリカントと EAP メソッドの通信と管理を容易にするアーキテクチャ)、および認証を実行する EAP メソッドの層があります。
図 2 EAPHost 用の EAP インフラストラクチャ アーキテクチャ
図 2 EAPHost 用の EAP インフラストラクチャ アーキテクチャ
Windows Server "Longhorn" 用の認証サーバーには、ネットワーク ポリシー サーバー (NPS)、認証サーバー用の新しい EAPHost アーキテクチャ、および EAP メソッドの層があります。NPS は、以前 Windows Server 2003 でインターネット認証サービス (IAS) と呼ばれていたものであり、リモート認証ダイヤルイン ユーザー サービス (RADIUS) サーバーおよびプロキシと、NAP のポリシー サーバーとなります。
EAP ピア上のサプリカントは、PPP や 802.1X などのリンク層テクノロジを使用して、リンク上で EAP ピアとパススルー認証システム (ワイヤレス アクセス ポイントやリモート アクセス サーバーなどのネットワーク アクセス サーバー) 間での EAP メッセージの送受信を行います。認証サーバー上のパススルー認証システムと NPS は、RADIUS を使用して、IP ベースのネットワーク上でパススルー認証システムと NPS 間での EAP メッセージの送受信を行います。
EAP ピアと認証サーバーが特定の EAP メソッドの使用をネゴシエートすると、その後の論理通信は、EAP ピアと EAP サーバー上のネゴシエートされた EAP メソッド間で送信される EAP メッセージによって行われます。
図 3 は、Windows Vista または Windows Server "Longhorn" を実行する EAP ピアの EAPHost アーキテクチャを示しています。このアーキテクチャは、サプリカント、EAPHost コンポーネント、EAP メソッド管理コンポーネント、および NAP コンポーネントから構成されます。
図 3 EAP ピアの EAPHost アーキテクチャ
図 3 EAP ピアの EAPHost アーキテクチャ
Windows Vista と Windows Server "Longhorn" には、802.1X ベースのワイヤレス接続と有線接続用の 802.1X サプリカントが付属しています。ダイヤルアップや VPN ベースのリモート アクセス、またはサイト間接続用の PPP サプリカントは、これら 2 つのオペレーティング システムを将来更新する際に提供できるかどうかを現在検討しています。サードパーティが開発したその他のサプリカントも追加できます。EAPHost API により、サプリカントが接続に EAP を使用できるようにしています。詳細については、msdn2.microsoft.com/aa364249.aspx の記事を参照してください。
EAPHost コンポーネントには、EAP クライアント ステート マシン/プロトコル検証ツールが含まれています。これは、EAP ピアのステート マシン (RFC 3748 を参照) を管理し、EAP メッセージを検証します。他にも EAP メソッド マネージャが含まれています。これは EAPHost に対応しているかどうかにかかわらず、さまざまな EAP メソッドを管理し、アプリケーションやサービスが EAP メソッドを使用できるよう支援します。また、EAP メソッド ライブラリのロードとアンロードを容易にする EAPHost ライブラリ マネージャもあります。
EAP メソッドには、以下のコンポーネントがあります。
組み込みの EAP メソッド PEAP、EAP - トランスポート層セキュリティ (TLS)、EAP-MS-CHAP-V2 があります。
2 つのホスト API EAPHost 未対応 EAP メソッドをホストする API (従来の EAP API) とサードパーティの EAPHost 対応 EAP メソッドをホストする API (EAPHost メソッド API) です。
従来の変換メソッド 従来の EAP API 用に作成された EAPHost 未対応 EAP メソッドと EAPHost メソッド API 間の変換を行います。
EAP メソッド プロキシ マネージャ EAPHost に対応しているかどうかにかかわらず、サードパーティの EAP メソッドをホストします。
EAP メソッド API は、EAPHost 対応 EAP メソッド用の新しい API です。EAP メソッドは、EAP メソッド API で定義されている API をエクスポートします。EAPHost は、EAP メソッドを読み込み、エクスポートされた API 関数を呼び出します。
NAP コンポーネントには、次の項目があります。
EAP NAP EC メッセンジャー EAPHost NAP 実施クライアント (EC) と EAPHost の他のコンポーネント間の NAP 関連データ (正常性ステートメントやイベントなど) の通信を支援します。
EAPHost NAP EC 他の NAP コンポーネントと通信し、802.1X 認証接続が NAP のシステム正常性要件を満たしていない場合に、正常性の検証とアクセス制限の適用を行います。
NAP エージェント クライアントの現在の正常性状態を管理し、インストールされている NAP EC とシステム正常性エージェント (SHA) 間の通信を支援します。各 SHA は、1 つ以上のシステム正常性要件に定義されます。
図 3 に示すように、サードパーティ ベンダは、新しいサプリカントと新しい EAPHost 対応の EAP メソッドを開発できます。また、Windows Server 2003 または Windows XP 用に開発された既存の EAP メソッドも使用できます。
図 4 は、Windows Server "Longhorn" および NPS を実行する認証サーバーの EAPHost アーキテクチャを示しています。このアーキテクチャは、EAP メソッドをサポートする EAP ピアのアーキテクチャと同じです。認証サーバーでは、サプリカントの代わりに NPS があります。NPS は EAPHost API を使用して EAP メソッドを使用および構成します。EAP コンポーネント内では、EAP サーバー ステート マシン/プロトコル検証ツールにより、EAP 認証サーバー ステート マシンの管理と、受信 EAP メッセージの検証を行います。
図 4 認証サーバーの EAPHost アーキテクチャ
図 4 認証サーバーの EAPHost アーキテクチャ
認証サーバーの EAPHost は、サードパーティ ソフトウェア ベンダによる新しい EAPHost 対応 EAP メソッドの開発とインストールを可能にするほか、Windows XP や Windows Server 2003 用に既に開発されている EAP メソッドをサポートします。
EAP ピアでも認証サーバーでも、EAPHost には EAPHost UI プロキシ API (図 3 と 4 には記載されていません) が用意されています。EAPHost 対応メソッドは、この API を使用してユーザーの操作を必要とするダイアログ ボックスを表示できます。また、サードパーティ ベンダは、EAPHost UI プロキシ API を使用することで、独自のダイアログ ボックスを追加し、さらにシームレスなユーザー エクスペリエンスを実現できます。

まとめ
Windows Server "Longhorn" および Windows Vista の EAPHost では、最新のインターネット標準に合わせて Windows の EAP 実装を更新し、EAP 認証方法とサプリカントによって Windows を拡張できるモジュール型の新しいアーキテクチャを提供しています。ネットワーク ベンダは、Windows EAP 実装全体を置き換えることなく、EAPHost API 向けに作成した新しいサプリカントと、EAPHost メソッド API 向けに作成した新しい認証方法を開発することで、Windows の既存のユーザー エクスペリエンスを拡張できます。また、EAPHost では、Windows Server 2003 と Windows XP 用に開発された既存の EAP メソッドもサポートします。
Windows XP 用の EAPHost
マイクロソフトでは、EAPHost アーキテクチャ、RFC 3748 のサポート、および有線 802.1X 接続用の EAPHost サプリカントを含む Windows XP SP2 向け更新プログラムをリリースする予定です。この更新プログラムを適用すると、Windows Vista 用に開発された EAPHost サプリカントも Windows XP SP2 上で使用できるようになります。この更新プログラムの詳細については、NAP 製品チームのブログ blogs.technet.com/nap を参照してください。

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


 Windows PowerShell: WMI との関係
Windows PowerShell
WMI との関係
Don Jones

これまで VBScript を扱う際に全面的に頼りにしていたテクノロジの 1 つが WMI (Windows Management Instrumentation) でした。興味深いことに、Windows PowerShell は WMI と密接な関係があります。これは技術的な意味だけではありません。Windows PowerShell を設計した Jeffrey Snover は、Wmic.exe の作成においても中心的存在でした。
Wmic.exe は、Windows Server® 2003 時代のコマンド ライン ツールであり、WMI の操作に使用します。Wmic.exe は、多くの点で Windows PowerShell™ の前身であり、ほぼ同じように機能します (WMIC の詳細については、TechNet Magazine 2006 年 9 月号の John Kelbley の記事 (microsoft.com/technet/technetmag/issues/2006/09/WMIData) を参照してください)。
Windows PowerShell は WMI をサポートします。WMI のサポートは、シェルの他の機能と同様に、オブジェクト ベースの一貫した方法で提供されます。そのため、WMI は VBScript などの以前のテクノロジに比べて非常に簡単に習得および使用できます。特に、特定の問題について習得や使用を行う場合はその傾向が顕著です。

WMI 入門
スクリプト関連の書籍や記事を読むと、WMI に関する記載がないことはまずありません。ただし、実際の WMI を使用することに夢中になりすぎ、WMI が内部的にどのように構築されたかを忘れがちです。WMI の構造は、Windows PowerShell における WMI の機能にとって特に重要です。
WMI は、主に、Windows® オペレーティング システムや、その他の Windows ベースのハードウェア製品やソフトウェア製品の管理情報を表すクラスを編成した 1 つのシステムです。実際に、クラスは、ある特定のソフトウェア コンポーネントやハードウェア コンポーネントが保持するプロパティや機能を抽象的に表したものにすぎません。たとえば、論理ディスクのクラスは、シリアル番号、一定の記憶域容量、使用可能な容量などを持ったデバイスを表します。一方、Windows サービスを表すクラスは、そのサービスに名前が付いていること、そのサービスを開始または停止できること、その現在状態などを示します。
WMI のクラスは、WMI で管理できるすべての内容を表します。クラスがないものについては、WMI ではそのコンポーネントを管理できません。マイクロソフトでは、主要な Windows WMI クラス (msdn2.microsoft.com/aa394554.aspx) のドキュメントを用意しています。また、インターネット インフォメーション サービスや SQL Server™ などの製品では、個別に WMI クラスのドキュメントが作成されています。
あまりにも多くのクラスが存在するため、WMI では、こうしたクラスが名前空間の階層にまとめられています。たとえば、主要な Windows OS クラスを格納している名前空間は root\cimv2 という名前です。それに対して、Microsoft IIS 6.0 はそのクラスを root\MicrosoftIISv2 に格納します。都合のいいことに、root\cimv2 名前空間は WMI の既定の名前空間です。そのためこの名前空間の設定は Windows PowerShell で共有されるため、こうした主要クラスを簡単に使用できるようになっています。
"インスタンス" は、クラスの実体です。たとえば、コンピュータに論理ディスクが 2 台搭載されている場合は、Win32_LogicalDisk クラスのインスタンスが 2 つ存在します。コンピュータ上で 50 個のサービスが実行されていれば、WMI では Win32_Service クラスのインスタンスが 50 個確認されます。WMI の操作とは、基本的には、1 つ以上のインスタンスの提供を WMI にリクエストした後に、インスタンスのプロパティを調べて必要な管理情報を探したり、インスタンスのメソッドを実行して管理上の変更 (サービスの開始や停止など) を行ったりすることです。
WMI は、クライアント サーバー アーキテクチャを使用します。Windows 2000 以降の Windows の各バージョンには、WMI ビルトイン (バージョンが新しいほど、使用可能なクラスの数が増えています) が付属しています。つまり、WMI クライアントと WMI サーバーのどちらのソフトウェアも使用可能です。WMI を使用する場合、実際には、対象のコンピュータ上で実行されている WMI サービスに要求を送信します。その WMI サービスが、指定された WMI インスタンスを取得して返すため、ユーザーはそのインスタンスを操作できます。Windows PowerShell ではこの部分を取り扱います。そのため、インスタンスを要求、取得、および操作するプロセスが簡略化されます。

WMI オブジェクトの取得
WMI クラス インスタンスは大ざっぱに "オブジェクト" と呼ばれているため、こうしたインスタンスを Windows PowerShell で取得する方法が Get-WMIObject コマンドレットであることは不思議ではありません。このコマンドレットには、便利なエイリアス gwmi が用意されており、この記事のほとんどの例に使用します。最も単純な形式は、取得する WMI クラス名を指定して結果を参照するだけです (図 1 参照)。gwmi win32_service を実行すると、Windows PowerShell は、(別のコンピュータを指定していないため) ローカル コンピュータ上の WMI サービスに接続し、(他の名前空間を指定していないため) root\cimv2 名前空間に接続します。Windows PowerShell は、指定したクラスのすべてのインスタンスを取得しました。これらのインスタンスについて特に何も指示しなかったため、インスタンスがテキスト表現に変換されます。つまり、Windows PowerShell は、このようなオブジェクトを取得し、人間である私にわかるようにテキストを生成したのです。
図 1 gwmi win32_service を実行すると、Windows PowerShell は、指定したクラスのすべてのインスタンスを読みやすいテキスト形式で返す
図 1 gwmi win32_service を実行すると、Windows PowerShell は、指定したクラスのすべてのインスタンスを読みやすいテキスト形式で返す
具体的には、Windows PowerShell は、選択したクラスのプロパティの名前と値を読み取って表示することで、WMI オブジェクトをテキストに変換します。Win32_Service クラスの場合、6 つのプロパティのセットが選択されます。
実際、Windows PowerShell は、この方法で任意のオブジェクトをテキストに変換します。表示されているプロパティの大部分は、Windows PowerShell インストール フォルダにある一連の .format.ps1xml ファイルで定義されています。このような書式定義ファイルは、マイクロソフトによってデジタル署名されています。独自の書式設定ファイルを提供することもできますが、これらのファイルは変更しないことをお勧めします (このトピックについては、今後のコラムで詳しく説明する予定です)。
gwmi コマンドレットを使用すると、コンピュータを調べて、使用できるクラスを見つけることができます。たとえば、gwmi –namespace "root\cimv2" –list を実行すると、その名前空間にあるクラスの全一覧が表示されます。ただし、ローカル コンピュータのクラスが関連するのは、そのコンピュータを管理している場合のみであることに注意してください。リモート コンピュータを管理している場合は、そのシステム上で使用できるクラスについて調べる必要があります。このため、リモート コンピュータに接続するには、gwmi の –computer パラメータを使用します。たとえば、gwmi –namespace "root\cimv2" –list –computer ServerA では、ServerA というリモート コンピュータ上の root\cimv2 名前空間にあるクラスの全一覧が表示されます。

リモート WMI
Windows PowerShell バージョン 1.0 では、gwmi がリモート管理を直接サポートするほぼ唯一のコマンドレットです。これは、主に、リモート コントロールが基になる WMI アーキテクチャに組み込まれているためです。Windows PowerShell は、単にその既存のアーキテクチャを使用しているだけなので、そのアーキテクチャのセキュリティ機能の対象となります。次に例を示します。
C:\> gwmi -namespace “root\cimv2” -computer
mediaserver -list
Get-WmiObject : Access is denied. (Exception
from HRESULT: 0x80070005 (E_ACCESSDENIED))
At line:1 char:5
+ gwmi <<<< -namespace “root\cimv2” -computer
mediaserver -list
PS C:\>
この例では、アクセス許可のない MediaServer というリモート コンピュータへの接続を試みました。管理者にはこのコンピュータの WMI サービスを操作するアクセス許可が必要であり、ローカル ワークステーションの資格情報では不十分であると考えられます。たとえば、信頼関係のない別のドメインにログオンする場合もあれば、権限の低いアカウントを使用してログオンする場合もあります。さいわい、gwmi が –credential パラメータをサポートしているため、WMI 接続には、代わりのユーザー資格情報のセットを指定することができます。次に、非常に簡単な例を示します。
gwmi win32_service –credential mydomain\administrator –computer mediaserver
資格情報 (具体的にはユーザー名) は、"ドメイン\ユーザー名" 形式で指定します。
パスワードを入力する場所がないことに注意してください。パスワードは、Windows PowerShell から要求されます。Windows PowerShell には、コマンド ラインでパスワードを入力する方法が意図的に用意されていません。この方法が用意されていると、スクリプト ファイル内にパスワードをハードコーディングできるようになるためです。これは、確実にセキュリティ上のリスクになります。ただし、この –credential パラメータを使用した別の方法もあります。この方法では、PSCredential という資格情報オブジェクトを前もって作成しておきます。重要なのは、Get-Credential コマンドレットです。
$cred = get-credential mydomain\administrator
これを実行しても、パスワードの確認が求められます。ただし、この場合、作成した資格情報オブジェクトが $cred 変数に格納されます。$cred の内容を確認すると、ユーザー名はわかりますが、パスワードはわかりません。
PS C:\> $cred

UserName
--------
mydomain\adminstrator
その後、その資格情報オブジェクトを何回でも再利用できます。
gwmi win32_service –credential $cred –computer mediaserver
この結果、再利用可能な資格情報オブジェクトを事前に定義することで、リモート コンピュータに対して繰り返し行われる WMI 接続が簡略化されます。ただし、Get-WMIObject コマンドレットでは、現在のところ、認証レベルの指定 (偽装とも呼ばれる) が VBScript と同じ方法ではサポートされていません。詳細については、msdn2.microsoft.com/aa389290.aspx を参照してください。

自動探索
私が Windows PowerShell について気に入っている点の 1 つは、機能に関する安易な妥協がないことです。ここまでは、照会する Win32_Service クラスのプロパティ セットのみを Windows PowerShell がどのように選択するかということだけを示してきました。ところが、シェルではすべてのプロパティにアクセスでき、どのようなプロパティがあるかを示すこともできます。これを行うには、図 2 に示すように、オブジェクトを Get-Member コマンドレット (またはそのエイリアス gm) にパイプ処理するだけです。
図 2 オブジェクトを Get-Member コマンドレットにパイプ処理すると、アクセス可能なメソッドやプロパティが示される
図 2 オブジェクトを Get-Member コマンドレットにパイプ処理すると、アクセス可能なメソッドやプロパティが示される
シェルでは、プロパティだけでなく、使用可能なメソッドの一覧も表示されます。つまり、クラスで実行できることを調べるために、必ずしもドキュメントが必要ではありません。クラス自体に、インスタンスの構成の変更、サービスの一時停止、サービスの停止などを行う手段が用意されていることがわかります。
これらのメソッドを使用したり、他のプロパティを表示したりするには、多くの場合、インスタンスを変数に格納するのが最も簡単です。
$server = gwmi win32_operatingsystem
$server.reboot()
このサンプルでは、Win32_OperatingSystem クラスの使用可能なインスタンスのみを取得し (このクラスには、コンピュータごとにインスタンスが 1 つだけあります)、$server 変数に保存します。その後、$server 変数を使用してインスタンスの Reboot メソッドにアクセスし、コンピュータを再起動します。この操作には十分注意してください。

豊富なクエリ言語
VBScript などのテクノロジで WMI を使用したことがあれば、おそらく、WQL (WMI Query Language) で記述したクエリを使用して WMI クラス インスタンスを取得することには慣れているでしょう。構文が SQL に似ているため、指定したクラスのすべてのインスタンスではなく、特定のインスタンス (特定のサービスなど) を簡単に取得できます。さいわい、gwmi を使用すれば、次のようにクエリを指定することもできます。
gwmi –query “select * from win32_service where name=’alerter’”
(Windows PowerShell が正式にリリースされる直前に追加された) この gwmi の構文は非常に便利で、他の目的で開発した複雑な WMI クエリが実に簡単に移行できるようになります。また、通常どおり、Windows PowerShell は、独自のプロパティとメソッドを持つ豊富なオブジェクトを返して、WMI の管理機能に完全にアクセスできるようにします。

今後の WMI
WMI は、今後のバージョンの Windows に向けて開発が継続されるため、新しいクラスや機能が追加されます。また、マイクロソフトの新製品にも引き続き追加されます。ほとんどのマイクロソフト製品では、Windows PowerShell を具体的に対象としたバージョンがまだリリースされていませんが、WMI に接続する機能は大きなメリットの 1 つであり、現在の Windows PowerShell を有益にしている理由の 1 つです。
ここでは、WMI でできることをほんの少し取り上げたにすぎません。それでも、Windows PowerShell について調べて、使用可能な機能を自分で探す気になっていただけたらさいわいです。

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


 Hey, Scripting Guy!: 花が咲き、ダイアログが開き、春が来た
Hey, Scripting Guy!
花が咲き、ダイアログが開き、春が来た
Microsoft Scripting Guys

春が来ました。 かつてないほどの喜びです。記録的な雨量、アイス ストーム、雪嵐、暴風雨に見舞われた冬を経て、ついに春がやってきました (ある嵐では、大木が Scripting Guys の 1 人の裏庭に倒れ込みました。ぎりぎりのところで家屋に被害はありませんでしたが、Scripting Dog はソファーの後ろに逃げ込みました)。今は、ひんやりとした雨を楽しんでいます。これが過ぎると、夏の太平洋岸北西地区の温かい雨に変わります。
外の小雨を眺めているとき、スクリプトでちょっとした冒険をして、HTML アプリケーション (HTA) を見てみるいい機会だと思いました。冒険というからには、そのとおり本気で冒険します。ここでは初歩的な説明はしません。読者が HTA とは何かや、HTA の作成方法を既に理解していることを前提にします。このような知識をお持ちでなければ、スクリプト センターの HTA Developers Center を参照してください。特に、「初心者向け HTA」の 2 つの記事を一読することをお勧めします。それさえ済めば、必要な知識が揃い、この記事をお読みいただけます。
今回のコラムでは、ダイアログ ボックスの作成方法を説明します。さらに、メインの HTA とダイアログ ボックス間で情報をやりとりする方法についても説明します。本当に春のすがすがしい空気の中で、野心的になっていますね。今のうちに楽しんでおきましょう。
ご存じかもしれませんが、ダイアログ ボックスには 2 種類あります。モーダルとモードレスです。違いは、モーダル ダイアログ ボックスを開くと、そのダイアログ ボックスを閉じるまで、ダイアログ ボックスを開いたメイン ウィンドウに戻ることができません。モードレス ダイアログ ボックスを開いた場合は、ウィンドウ間を移動できます。ただし、メイン ウィンドウを閉じると、モードレス ダイアログ ボックスも閉じられます。
モーダル ダイアログ ボックスとモードレス ダイアログ ボックスの作成方法はまったく同じです。唯一の違いは、モーダル ダイアログ ボックスを作成する場合は ShowModalDialog 関数を呼び出し、モードレス ダイアログ ボックスを作成する場合は ShowModelessDialog 関数を呼び出すことだけです。どちらの関数も、同じパラメータを受け取ります。まず、モーダル ダイアログ ボックスを開く簡単な HTA を見てみましょう (図 1 参照)。
Figure 1 出発点となる簡単なダイアログ (Close Figure 1)
<html>
<head>
<title>Modal Example</title>
<HTA:APPLICATION
  APPLICATIONNAME=”MainModal”>
</head>

<script language=”VBScript”>
Sub ShowDialog
 intReturn = _
    ShowModalDialog(“modaldialog.hta”)
 textbox.Value = intReturn
End Sub
</script>

<body>
<button onclick=”ShowDialog”>
 Show Dialog Box</button> <p>
<input type=”text” name=”textbox”>
</body>
</html>
ここでは、"Modal Example" という名前の HTA を作成しました。HTA の <body> 領域には、2 つの要素を追加しています。"Show Dialog Box" というラベルのボタンと、textbox という名前のテキスト ボックスです。これらについては、図 2 を参照してください。ボタンをクリックすると、ShowDialog サブルーチンが実行されます。
図 2 実際の HTA モーダル ダイアログ
図 2 実際の HTA モーダル ダイアログ
ShowDialog サブルーチンは、実に単純です。ShowModalDialog 関数を呼び出し、モーダル ダイアログ ボックスとして表示する HTA ファイル名 (ここでは modaldialog.hta) をパラメータとして渡しています (modaldialog.hta は、この HTA と同じフォルダにあると仮定しています。違う場合は、ここに完全なファイル パスを含める必要があります)。
また、ShowModalDialog からの戻り値 (intReturn) をキャプチャしています。この値をテキスト ボックスに表示します。この戻り値を取得する方法については、この後すぐに説明します。重要な点は、モーダル ダイアログ ボックスが閉じられるまで、ShowModalDialog への呼び出しから戻らないことです。つまり、ダイアログ ボックスが閉じられないと、戻り値がテキスト ボックスに割り当てられません。
では、modaldialog.hta を見てみましょう。これは、呼び出し元の HTA によって開かれるダイアログ ボックスです (図 3 参照)。この HTA では、2 つの要素を作成しました。listbox という名前のリスト ボックスと、"OK" というラベルのボタンです (図 4 参照)。リスト ボックスには、"Option 1"、"Option 2" のようにラベルを付けた項目を 4 項目追加し、項目ごとに対応する値 (1 ～ 4) を関連付けました。[OK] ボタンをクリックすると、CloseWindow サブルーチンが実行されます。
Figure 3 modaldialog.hta (Close Figure 3)
<html>
<head>
<title>Modal Dialog Box</title>
<HTA:APPLICATION
  APPLICATIONNAME=”ModalDialog”>
</head>

<script language=”VBScript”>
Sub CloseWindow
  window.returnValue = listbox.Value
  window.Close
End Sub
</script>

<body>
<select size=”3” name=”listbox”>
 <option value=”1”>Option 1</option>
 <option value=”2”>Option 2</option>
 <option value=”3”>Option 3</option>
 <option value=”4”>Option 4</option>
</select>
<p>
<input type=”button” id=”idBtn” value=”OK” onclick=”CloseWindow”>
</body>
</html>
図 4 モーダル ダイアログ ボックスを表す HTA
図 4 モーダル ダイアログ ボックスを表す HTA
CloseWindow サブルーチンも、実に単純です。まず、選択されたリスト ボックス内の項目の値を読み取り、この値を window.returnValue プロパティに割り当てています。たとえば、ユーザー が [Option 2] を選択すると、値 2 が window.returnValue に割り当てられます。その後、window.Close メソッドを呼び出して、ダイアログ ボックスを閉じます。
この時点で、制御がメインの HTA に戻ります。ShowModalDialog への呼び出しを再度見てみましょう。
intReturn = _
  ShowModalDialog(“modaldialog.hta”)
intReturn に割り当てられる戻り値は、ダイアログ ボックス HTA で window.returnValue に割り当てた値です。したがって、ダイアログ ボックスで [Option 2] を選択すると、値 2 が window.returnValue に割り当てられるため、intReturn は 2 になり、その後のコードによってこの値がテキスト ボックスに表示されます。
textbox.Value = intReturn
ダイアログ ボックスから値を取得する方法を説明したので、次はダイアログ ボックスに値を渡す方法について説明します。今度は、モードレス ダイアログ ボックス (図 5 参照) を使用しますが、モーダルでもモードレスでも機能は同じなので、モーダル ダイアログ ボックスでも同じプロセスを使用します。
Figure 5 モードレスに挑戦 (Close Figure 5)
<html>
<head>
<title>Modeless Example</title>
<HTA:APPLICATION
  APPLICATIONNAME=”ModelessMain”>
</head>

<script language=”VBScript”>
Sub ShowDialog
  intReturn = _
    window.ShowModelessDialog _
    (“modelessdialog.hta”, _
    lstServers.Value, _
    “dialogHeight:400px;dialogWidth:300px”)
End Sub
</script>

<body>
<select size=”1” name=”lstServers”>
 <option value=”server1”>Server1</option>
 <option value=”server2”>Server2</option>
 <option value=”server3”>Server3</option>
 <option value=”server4”>Server4</option>
</select>
<p>
<input type=”button” value=”Retrieve Processes” onclick=”ShowDialog”>
</body>
</html>
図 7 モードレス ダイアログに渡されるデータ
図 7 モードレス ダイアログに渡されるデータ
ここでは、lstServers という名前のドロップダウン リスト ボックスを作成しています (サイズが 1 なのでドロップダウンであることがわかります)。また、"Retrieve Processe" というラベルのボタンもあります。このボタンをクリックすると、ShowDialog サブルーチンが実行されます。ShowDialog サブルーチンは、以下に示すように、window.ShowModelessDialog 関数への呼び出しの 1 行のみです。
intReturn = _
  window.ShowModelessDialog _
  (“modelessdialog.hta”, _
  lstServers.Value, _
  “dialogHeight:400px;dialogWidth:300px”)
この関数に渡す最初のパラメータは、ダイアログ ボックスで実行する HTA の名前であり、ここでは modelessdialog.hta です。2 番目のパラメータは、リスト ボックスの Value プロパティです。もうおわかりのように、Value プロパティには、リスト ボックス内で選択した値が保持されます。したがって、ユーザーがリストボックスから [Server2] を選択すると、Value は "server2" になります。このパラメータは、ダイアログ ボックスにどのように情報を渡すかを示しています (複数の値を渡す場合は、配列またはコレクションとしてこのパラメータに渡すことができます)。
ダイアログ ボックスがこのパラメータ値をどのように受け取るかについては、すぐに説明します。しかし、まず、3 番目のパラメータを用意していることに注目してください。
“dialogHeight:400px;dialogWidth:300px”
このパラメータは、ダイアログ ボックスの高さと幅を指定する文字列を保持します。この場合は、高さを 400 ピクセル (400px)、幅を 300 ピクセルに指定しています。モーダルの例で説明したように、このパラメータは空のままにすることもでき、その場合はコンピュータの既定のサイズでダイアログ ボックスが表示されます。
では、modelessdialog.hta (図 6) に移り、このダイアログ ボックスが、渡された値をどのように読み取るかを見てみましょう。
Figure 6 modelessdialog.hta (Close Figure 6)
<html>
<head>
<title>Modeless Dialog</title>
<HTA:APPLICATION
  APPLICATIONNAME=”Processes”>
</head>

<script language=”VBScript”>
Sub window_onLoad
  strComputer = window.dialogArguments
  Set objWMIService = GetObject(“winmgmts:” _
    & “{impersonationLevel=impersonate}!\\” _
    & strComputer & “\root\cimv2”)
  Set colProcesses = objWMIService.ExecQuery   _
    (“Select * from Win32_Process”)

  strHTML = “<h1>” & strComputer & “</h1><p>”
  For Each objProcess in colProcesses
    strHTML = strHTML & objProcess.Name & _
       “<br>”
  Next

  DataArea.InnerHTML = strHTML
End Sub
</script>

<body>
<span id=”DataArea”></span>
</body>
</html>
この HTA で指定している唯一の要素はスパンであり、これはダイアログ ボックスの全領域を保持します。ここでのスクリプト セクションでは、window_onLoad サブルーチンを定義しています。このサブルーチンは、(ここでは ShowModelessDialog への呼び出しにより) HTA が開かれるとすぐに実行されます。このサブルーチンの 1 行目を見てください。
strComputer = window.dialogArguments
変数 strComputer にプロパティ window.dialogArguments の内容を代入しています。さて、このプロパティは何だと思いますか。ほら、読者の皆さんも春と共にお目覚めのようですね。そうです、これは ShowModelessDialog への呼び出しの 2 番目のパラメータに渡された値です。メイン ウィンドウで [Server2] が選択されると、値 "server2" が strComputer に保持されます。
このサブルーチンの残りの部分では、単に strComputer からすべてのプロセスを取得し、これらをスパン領域に表示しています。この操作の結果は図 7 のようになります。
これでめでたく、この夏は HTA ダイアログ ボックスで遊べるようになりました。といっても、もちろん、南半球にお住まいでなければの話ですが。南半球では冬が近づいていますね。こちらでこの冬経験したように、停電が多発するようなことになれば、冬場は大変な思いをされるかもしれません。

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


 Exchange Queue &amp; A: OWA のタイムアウト、コマンドレットに関するトラブルシューティングなど
Exchange Queue & A
OWA のタイムアウト、コマンドレットに関するトラブルシューティングなど
KC Lemson and Nino Bilic

質問 - 最近 Exchange Server 2003 を Exchange Server 2007 に移行しましたが、Restricted Users グループのユーザーが Outlook® Web Access (OWA) 2007 にログオンするときに [これは個人のコンピュータです] オプションを選択すると、タイムアウトが発生するという苦情が寄せられています。個人のコンピュータのタイムアウトを確認するには、どの Exchange 管理シェル コマンドを使用すればよいですか。
回答 - 少し話を戻しましょう。まず、個人のコンピュータと公共のコンピュータという異なる選択肢 (図 1 を参照) が提供される理由について説明してから、それぞれの動作について説明します。これらの選択肢を提供する目的は、ユーザーが空港のパブリック キオスクなどから OWA にログオンしているのか、自宅のコンピュータを使用してログオンしているのかを選択することにより、必要なセキュリティ レベルを Exchange に指定できるようにすることです。Exchange 管理者は、それぞれのセッションの種類に異なる動作を設定できます。たとえば、個人のコンピュータでは、認証されたセッションのタイムアウトを最大 3 日に設定し、公共のコンピュータでは、それよりも短い時間 (数分など) に設定したりすることができます。また、他の設定も、ユーザーの選択内容に応じて変更されるように構成することができます。たとえば、個人のコンピュータからのログオンのみに対して、SharePoint® ドキュメント ライブラリと Windows® ファイル共有へのアクセスを許可したりすることができます。もちろん、この設定が役立つのは、ユーザーが正しいオプションを指定した場合のみです。管理者は、ユーザーの判断を信頼できない場合、どちらを選択した場合にも同じタイムアウト値とその他の構成オプションが提供されるように設定することができます。
図 1 異なるタイムアウト設定とその他の構成オプションを提供できる、公共のコンピュータ用および自宅のコンピュータ用のセッション
図 1 異なるタイムアウト設定とその他の構成オプションを提供できる、公共のコンピュータ用および自宅のコンピュータ用のセッション
問題となっているオプションは、OWA に初めてフォーム ベース認証が導入された Exchange 2003 から引き継がれたオプションです (歴史に関する注 : フォーム ベース認証の最初の実装の一部は、すばらしいプログラム マネージャによって設計されました。名前までは明らかにしませんが、彼女は後に隔月の TechNet Magazine コラムの執筆で名声と富を得ました)。
実際にこのオプションの設定が格納されているのはレジストリですが、Windows PowerShell™ にこのレジストリを更新するためのインターフェイスが用意されているため、Exchange 管理シェルを使用してこの設定を構成できます。次の例では、ユーザーがログオン中に [これは個人のコンピュータです] オプションを選択したときのタイムアウトを 1440 分 (1 日) に設定します。
set-ItemProperty ‘HKLM:\SYSTEM\CurrentControlSet\Services\
MSExchangeOWA’ -name TrustedClientTimeout
-value 1440 -type dword
もちろん、この設定はレジストリに格納されているため、regedit を使用して手動でキーを更新することもできます。その場合は、次の方法を選択します。
#include <standard disclaimer about mucking
   with the registry.h>
#include <musing from author about when as a
   company we will ever be able to stop making
   that standard disclaimer about mucking with
   the registry.h>
どちらの方法を使用した場合でも、OWA が新しい設定を取得できるように、IIS を再起動する必要があります。IIS を再起動するには、[スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックした後、iisreset /noforce を実行します。

質問 - 職場で完全版の MAPI Outlook クライアントを使用しているすべてのユーザーに、今すぐ必要でないアイテムはすべて個人用フォルダ (.pst) ファイルにアーカイブするように呼びかけています。しかし、それらのアーカイブされたアイテムは、ユーザーが自宅から Outlook Web Access にログインすると表示できません。これらの .pst ファイルを OWA インターフェイスから表示するにはどうすればよいですか。
回答 - 残念ですが、OWA では .pst ファイルへのアクセスはサポートされていません。OWA は、始めからオンライン専用クライアントとして使用することを想定して構築されました。中でも、ローカル コンピュータ上に個人データを一切残さないようにすることに力が注がれました。たとえば、Exchange 2003 から導入された、セキュリティで保護されたログオフ メカニズムや、Exchange 2007 で導入された、添付ファイルのキャッシュされたコピーがハード ドライブ上に残らないようにする WebReady ドキュメント表示などの機能がその一例です。このため、OWA から .pst ファイルにアクセスするということは、OWA を展開しやすいオンライン専用クライアントにするという目的に合っていません。
そうは言うものの、一般的な .pst ファイルの使用方法は、議論してみたい興味深いシナリオの 1 つです。昨年の秋に会ったある顧客の環境では、ユーザーに与えられているメールボックス クォータのサイズが約 200 MB で、すべてのユーザーが 1 つ以上の .pst ファイルを持っていました。この組織には、ユーザー コンピュータを入れ替える際の作業を最小限に抑えるという方針があったため、すべてのユーザーは各自の .pst ファイルをネットワーク共有に格納する必要がありました。その代わり、このネットワーク共有は、中央のシステムによってバックアップされていました。
まず、ネットワーク共有からの .pst ファイルへのアクセスに関しては、既知の問題がいくつかあります。OWA が初めからオンライン専用クライアントとして設計されたのと同様に、.pst ファイルはもともとローカル コンピュータに格納するものとして設計されました。また、どんなに優れたネットワーク環境でも、待ち時間やその他の問題の影響を受けるため (さらに複数のユーザーが同時に特定のコンピュータにアクセスする必要があるため)、リモート コンピュータにデータを格納することは厄介な作業になる可能性があります。
2 番目に、この組織では、すべてのメール データを Exchange に格納したくないということ、およびこれらのデータを後からバックアップするということを理由に、やや小さいメールボックス クォータを使用していました (確かに会社のメールボックスのサイズが約 2 GB もあるという現在のような状況はぜいたくなのですが)。しかし、ユーザーは、バックアップされるネットワーク共有上の .pst ファイルにデータを格納しているため、管理者の作業はあまり軽減されていません。実際は、さまざまな要因によって作業が増加している可能性もあります。たとえば、複数の .pst ファイルを格納する単一のストレージ インスタンスがないこと、.pst ファイルの問題 (パスワードを忘れたユーザー、一般的なネットワークの問題など) に関連するヘルプデスクのコストがかかること、ウイルス攻撃後に .pst ファイル内のメッセージを消去しにくいこと、法的な問題が発生したときに .pst ファイル内のメッセージを検索しにくいこと、異なるバックアップ システムの管理オーバーヘッドが発生することなどが考えられます。
このため、構成に関連するすべての要素にかかるコストを考慮することを強くお勧めします。コストが積み重なり、別の構成を使用した方が最終的には良い結果が出る場合もあります。

質問 - Exchange 管理シェル コマンドのことで悩んでいます。コマンドが動作しません。どこに問題があるのでしょうか。
回答 - その質問に答えることはできませんが、どのような問題が発生しているかにかかわらず、解決に役立つ最善の方法は、start-transcript という Windows PowerShell の組み込みのコマンドレットを使用して、実行したコマンドとその結果を記録することです。このコマンドを実行することにより、記録されたコマンドの詳細をコピーして、電子メール メッセージ、ブログの投稿、フォーラムでの質問などに貼り付けて使用することができます。
Exchange 管理シェル セッションを開き、図 2 のように「start-transcript」と入力します。これにより、以降のコマンドが、Exchange 管理シェルによって図 3 のようなテキスト ファイルに自動的に記録されるようになります (心配は要りません、このテキスト ファイルの場所はアプリケーションによって表示されます)。記録を停止するには、「stop-transcript」と入力するだけです。
図 2 実行したコマンドとその結果を記録できる start-transcript コマンドレット
図 2 実行したコマンドとその結果を記録できる start-transcript コマンドレット
図 3 Windows PowerShell によってテキスト ファイルとして保存されたコマンドのコピー
図 3 Windows PowerShell によってテキスト ファイルとして保存されたコマンドのコピー
使用したコマンドと返された結果がすべて記載された一覧は、どの担当者が問題のトラブルシューティングを行う場合でも非常に役立ちます。ただし、知らないユーザーや信頼していないユーザーとログを共有する場合は、機密データが含まれていないかどうかを事前に確認する必要があります。

質問 - Exchange 2007 セットアップでは、ルート ドメインに Microsoft Exchange Security Groups という新しい組織単位 (OU) が作成され、この組織単位には 5 つの新しい Exchange 2007 セキュリティ グループが含まれるそうですが、これらのグループを他の OU やドメインに移動することはできますか。
回答 - これは、Active Directory の準備段階でルート ドメインに作成される 5 つのユニバーサル セキュリティ グループ (USG) のことですね。この 5 つを次に示します。
  • Exchange Organization Administrators
  • Exchange Recipient Administrators
  • Exchange View-Only Administrators
  • Exchange Servers
  • ExchangeLegacyInterop
Exchange 2000 と Exchange 2003 では、既定のセキュリティ グループ (Exchange Domain Servers と Exchange Enterprise Servers) の移動に関する制限がありました。もう少しわかりやすく言うと、移動することはできましたが、移動すると問題が発生しました (この問題の詳細については、support.microsoft.com/kb/260914 を参照してください)。このため、非常に制限されていたと言えます。
Exchange 2007 では、この動作が変更されました。既定の 5 つのグループは移動することができます。これらのグループは、同じドメイン内の異なる OU や、異なるドメインに移動することができます。
これら 5 つのグループを見失い、どこに移動したか (つまりどの OU またはドメインに移動したか) がわからなくなった場合は、次のコンテナにある otherWellKnownObjects 属性の値で場所を確認できます。
CN=MicrosoftExchange,CN=Services,
CN=Configuration,DC=<DomainName>,DC=com
グループが移動されると、対応するこの属性の値も更新されるため、常にグループの場所を確認できます。すてきでしょう?

質問 - ドメイン内に Exchange Install Domain Servers というグローバル セキュリティ グループを見つけました。このグループの目的について教えてください。
回答 - 管理している Active Directory® について非常によく把握していますね。実際に、Exchange 2007 サーバーがインストールされているすべてのドメインには、Exchange Install Domain Servers というグループがあります。このグループは、Microsoft Exchange システム オブジェクト (MESO) OU 内に作成されます。このグループを確認すると、ユニバーサル セキュリティ グループである、ルート ドメインの Exchange Servers グループのメンバになっていることがわかります。
簡単に言うと、Exchange Install Domain Servers グループは、いずれかの子ドメインで Exchange 2007 セットアップを実行した場合に Active Directory のレプリケーション サイクルにかかる時間が長くなるという問題を回避するために使用されます。たとえば、Root というルート ドメイン、Child という子ドメイン、および Grandchild という Child の子ドメインがあるとします (ええ、この名前付け方式は素晴らしいですね。パスワードも想像がつくのではないでしょうか)。
この組織で Exchange 2007 のセットアップを開始するには、まずスキーマを拡張し、Root ドメインを準備する必要があります。これにより、1 つ前の回答で説明した、最初の 5 つの USG が作成されます。
次に、Grandchild ドメインでセットアップを実行する必要があるとしましょう。セットアップは、ローカル ドメインで Exchange 2007 サービスを開始できるようにするために、Root ドメインにある Exchange 2007 コンピュータのコンピュータ アカウントを Exchange Servers グループに配置します。しかし、現在は Grandchild ドメインで操作を行っているため、Exchange Servers グループのメンバシップがレプリケートされるまでにしばらく時間がかかる場合があります。
Exchange Servers はユニバーサル グループであるため、このグループのメンバシップはフォレスト全体にレプリケートされます。レプリケーションでは待ち時間が発生する可能性があるため、Grandchild ドメインで実行されたセットアップが完了するまでにアクセス許可がレプリケートされず、セットアップがサービスを開始できない場合があります。この理由から、ドメインで最初の Exchange 2007 サーバーがセットアップされたときに、そのローカル ドメイン内に Exchange Install Domain Servers グループが作成されます。
この Exchange サーバーのコンピュータ アカウントは、セットアップ処理によって、このグループのメンバとして配置されます。このグループのメンバには、セットアップの終了時に Exchange Servers グループのメンバシップが Root ドメインからまだレプリケートされていなくてもサービスを開始できるアクセス許可が与えられます。通常は、ローカル ドメインのレプリケーションの方がドメイン間のレプリケーションよりも時間がかからないことに注意してください。

質問 - Exchange 2007 のドキュメントには、Exchange 2007 用にスキーマを拡張する前でも、/PrepareLegacyExchangePermissions スイッチを指定してセットアップを実行する必要があると記載されていましたが、この理由を教えてください (また、このスイッチの名前はもっと長くなる可能性はあったのでしょうか)。
回答 - セットアップの実行前にこのドキュメントを読んでいただき、ありがとうございます。参考になったでしょうか。
正確に言うと、/PrepareLegacyExchangePermissions (省略形は /pl) は、Exchange 2000 と Exchange 2003 の受信者更新サービス (RUS) に、Exchange Information および Personal Information プロパティ セットへの書き込みを行うためのアクセス許可を与えるスイッチです。Exchange 2007 用にスキーマを拡張する処理を実行すると、いくつかの属性 (プロキシ アドレスなど) が Active Directory のパブリック インフォメーション プロパティ セットから Exchange Information プロパティ セットに移動されます。既定では、Exchange 2000 と Exchange 2003 の RUS は、Exchange Information プロパティ セットに書き込むための権限を与えられていません。これは、実際の環境で、最初に Exchange 2007 用にスキーマを拡張する処理を実行した場合、Exchange 2000 と Exchange 2003 RUS が新しい受信者をスタンプできなくなるため、これらのサービスで問題が発生することを意味します (これらのプロパティ セットの詳細については、msexchangeteam.com にある私たちのブログをご覧ください)。
このため、スキーマを Exchange 2007 用に拡張する前に /pl スイッチを実行することは非常に重要です。また、この変更が Exchange 2000 または Exchange 2003 受信者が属する (つまり、RUS が存在する) すべてのドメインにレプリケートされるようにする必要があります。後から新しいドメインをフォレストに追加し、Exchange 2000 または Exchange 2003 の RUS をそれらのドメインに追加する必要が生じた場合、それらのドメインでも /pl スイッチを実行する必要があります。
それに関連した話ですが、初めて /pl スイッチを実行する場合、Enterprise Admins グループのアカウントを使用してこのスイッチを実行すると役立ちます。このアカウントを使用した場合、ルート ドメインで実行されたセットアップは、/pl を実行する必要があるドメインを識別し、それらのすべてのドメインで /pl スイッチを実行します。Enterprise Admins グループのアカウントを使用していない場合は、Domain Admins グループのアカウントを使用して、ドメインごとに /pl スイッチを実行する必要があります。幸運にも、Exchange 2007 のドキュメントには、アクセス許可の要件がすべて記載されています。
最後に、このスイッチの名前がもっと長くなる可能性はあったかという質問がありましたね。/PrepareLegacyExchangePermissions と早口で 3 回言ってみましょう。
PrepareLegacyExchangePermissions
PrepareLegacyExchangePermissions
PrepareLegacyExchangePermissions
/Prepare-LegacyExchangePermissionsWOWThisIsaReallyLongname という名前にしようかとも思いましたが、短くてわかりやすい /PrepareLegacyExchangePermissions を採用しました。
そうです、この話は今作りました。しかし、省略形の /pl を使用できるという話は本当です。これは本当です。絶対に本当ですから。

KC Lemsonは、Exchange Server のユーザー エクスペリエンス マネージャです。暇な時間は、子供の大学進学資金をどのように投資したらよいかが書かれた電子メールが届くのを待っています。
Nino Bilicは Exchange Server のテクニカル リードです。彼は、通常の勤務時間中は Halo を何回プレイできたかを確認することに追われています。


 セキュリティ ウォッチ: ネットワーク アクセス保護
セキュリティ ウォッチ
ネットワーク アクセス保護
John Morello
このコラムには、Windows Server "Longhorn" のプレリリース情報が含まれています。この情報は変更される可能性があります。

現在、あらゆる規模の組織が直面しているセキュリティの最大の脅威の 1 つは、ネットワーク境界の内側にある問題のあるデバイスです。どれほど企業がインターネットからの外部の脅威に対して優れた保護を確立していても、善良な従業員が意図せずに
ワームやトロイの木馬によってマルウェアの媒体となってしまうと、セキュリティが危うくなります。このことは、中小規模の組織の IT 環境に特に当てはまります。中小規模の企業では、スタッフ メンバの個人用ノートパソコンと仕事用ノートパソコンの区別がなかったり、ネットワーク アクセス制御テクノロジが高価で複雑すぎるために展開できなかったりします。ただし、ダウンタイムの影響が大きいのも、まさに中小規模の組織であることが多いため、このような脅威に対する保護は非常に重要です。
マイクロソフトのネットワーク アクセス保護 (NAP) テクノロジは、あらゆる規模の組織で、コンピュータがネットワークに参加する際に、コンピュータの状態を積極的に確認し、接続中も常に正常な状態が保たれるようにするためのテクノロジです。NAP は、従業員、ベンダ、訪問者がネットワークへの接続要件を満たしていないコンピュータを意図的または意図せずに使用してしまうことから組織を保護するための、柔軟なポリシー ベースのアーキテクチャを提供します。NAP は、ポリシーの検証、分離、修復、継続的な遵守の主要な 4 サービスから成り立っています。

NAP の概要
NAP が提供する 1 つ目の主要なサービスは、ポリシーの検証です。ポリシーの検証は、管理者が定義したルールを基準に NAP がシステムを評価し、システムの状態を分類するプロセスです。
IT 管理者は、コンピュータがネットワークへの接続を試みたときに、NAP が比較対象として使用する一連のポリシー要素を指定します。このポリシー要素を満たしているコンピュータは正常であると見なされ、(管理者によって定義された) チェックに 1 つでも合格しなかったコンピュータは問題があると見なされます。このポリシーでは、ウイルス対策ソフトウェアやスパイウェア対策ソフトウェアがインストールされているかどうか、ホスト ファイアウォールが有効であるか、コンピュータにセキュリティ更新プログラムがすべてインストールされているかなどを確認できます。また、NAP は拡張可能な構成であるため、独立系ソフトウェア ベンダは、アプリケーション固有のチェックを実施できる独自の NAP プラグインを作成できます。
NAP が提供するもう 1 つの主要サービスは、ネットワーク接続の制限です。NAP では、管理者が定義したポリシーを基に、コンピュータのネットワークへの接続状態を変更できます。たとえば、緊急のセキュリティ更新プログラムがインストールされていないために、コンピュータに問題があると見なされた場合、NAP はこのコンピュータを検疫ネットワークに隔離し、正常な状態になるまでこのコンピュータを環境内の他の部分から分離できます。NAP を導入しなければ、問題のあるクライアントが組織のネットワークに無制限にアクセスできることになります。更新プログラムを適用しておけば解決されていたセキュリティ ホールを悪用してマルウェアがこのコンピュータに侵入した場合、残りのネットワークにも感染を広げる活動を許すことになります。図 1 は、NAP の基本アーキテクチャを示します。
図 1 NAP の基本アーキテクチャ
図 1 NAP の基本アーキテクチャ
ただし、単順に接続を制限するだけでは、問題のあるコンピュータを扱う効率的な方法とはいえません (やはり、ユーザーも仕事をする必要がありますから)。したがって、NAP では、問題があり検疫処理されたコンピュータが、管理者の介入なしにそれぞれの問題を修正できる修復サービスも用意しています。先ほどの例では、ネットワークを限定し、問題のあるコンピュータには必要な更新プログラムをインストールするために必要な特定のネットワーク リソース (Windows Server® Update Services (WSUS) コンピュータなど) へのアクセスのみを許可します。つまり、NAP を展開している場合、問題のあるコンピュータがアクセスできるのは、このコンピュータを正常に修復できるネットワーク リソースのみで、正常な状態になるまでは残りのネットワークにトラフィックを送信できません。
NAP の最後の主要サービスは、継続的な遵守です。これは、初回接続時だけでなく、コンピュータがネットワークに接続されている間、常に、正常性ポリシーが適用されるようにするサービスです。先ほどの例を使用して、コンピュータが自動修復されて正常状態に戻った (したがって無制限のネットワーク アクセスが許可された) 後、どのようなことが起こるかを考えてみましょう。このコンピュータが、たとえば Windows ファイアウォールが無効にされたために、ポリシーを遵守していない状態になった場合、NAP は自動的にこのコンピュータに対して再度検疫処理を行います。また、NAP では管理者が自動修復を構成して、最初のネットワーク接続が完了してから長時間経過している場合に、ユーザーが新たに介入しなくても、非遵守状態が自動的に修正されるようにできます。
NAP では、ネットワーク アクセスの制御に、複数の手法を使用できます。管理されたネットワーク スイッチを導入している組織では、802.1X を使用して、ネットワーク ハードウェア層でポート ベースのアクセス制御を提供できます。NAP はまた、物理ネットワーク層上での IPsec の関連付けにより、セキュリティが確保されたネットワークを作成し、IPsec ベースでの適用を使用できる機能も提供します。IPsec ベースの適用を使用する場合、NAP は IPsec エンジンが使用する証明書を動的に作成および削除することで、セキュリティが確保されたゾーンへのアクセスを制御します。また、NAP では DHCP ベースの適用も行うことができます。この場合、DHCP サーバーから問題のあるクライアントに、制限付きのプールの IP リースを提供します。このリースは、別の DNS サフィックスと IP ルートを使用して、制限付きのクライアントがアクセスできるリソースを制御します。
NAP サーバー コンポーネントは、Windows Server の次期バージョン (コードネーム "Longhorn") を基盤にしており、具体的にはインターネット認証サービスの後継機能として大幅に機能強化された新しいネットワーク ポリシー サーバー (NPS) に組み込まれています。802.1X ベースの適用を使用する組織の場合は、ネットワーク ハードウェアが 802.1X 認証と動的 VLAN 機能をサポートしている必要があります (特定のハードウェア ベンダの詳細については、「NAP の関連情報」で紹介している NAP のパートナー サイトを参照してください)。DHCP ベースの適用の場合は、Windows Server "Longhorn" が提供しているサービスなど、NAP 対応 DHCP サービスが必要です。クライアント側の NAP サポートは、Windows Vista™ に組み込まれています。NAP サポートは、Windows XP での 802.1X 適用を実現する 802.1X サプリカントと合わせて、Windows® XP のアドオンとしても提供する予定です。
また、NAP は Windows セキュリティ センターやサードパーティの正常性エージェントと統合して、正常性情報をレポートできます。このため、NAP では、ポリシーの検証時に、セキュリティ センターによって公開されるデータを基に判定を行うことができます
NAP は、高機能なエンタープライズ レベルのポリシー管理ソリューションなので、すべての機能と展開方針を 1 つの記事でカバーすることはできません。したがって、この記事では、既に IT スタッフの時間に余裕がなく、NAP 展開を合理化して展開に要する投資に対する効果を短期間で実現できる、中小規模組織での展開について取り上げます。ただし、ここで学習することや一般的なガイドラインの多くは、どのような規模の組織の NAP デザインにも当てはまります。この記事の例は、ステップ バイ ステップのセットアップ ガイドではなく、DHCP ベースの NAP 展開を成功させるうえで重要な点の説明を目的としたものです。より詳細なセットアップ ガイドへのリンクについては、「NAP の関連情報」を参照してください。

例 : Contoso における問題
中小規模組織特有のニーズに NAP がどのように対応できるかを詳しく説明するため、ここでは例として Contoso, Inc. を使用します。Contoso 社は、3 か所の主要な事業所に 250 台のコンピュータを備える架空の中規模組織です。従業員のモバイル作業を行う比率は高く、ユーザーの多くが自宅または客先からリモートで事業所に接続します。そのため、同社のコンピュータの約半数がノートパソコンと Tablet PC です。Contoso では、多くの組織と同様に、従業員のモバイル化が進むにつれて、セキュリティの問題の拡大に直面しています。モバイル コンピュータを使用しているユーザーの一部が、客先や自宅でマルウェアに感染し、感染したコンピュータが Contoso の社内ネットワークに持ち込まれたことがあります。
また、Contoso では、このようなリモート コンピュータを最新状態に保つことに苦慮しています。ユーザーが客先での長期作業を終えた後に、Contoso の事業所に戻ってくることがよくあります。このような場合、ユーザーのコンピュータは数か月分もセキュリティ更新プログラムが適用されていないことが多く、Contoso ネットワーク内の他のコンピュータに対するリスクが全体的に高くなります。Contoso では、リモートであれ、ローカルであれ、社内ネットワークに接続するすべてのコンピュータが、必ず安全で正常な状態であるように保つソリューションを必要としています。
Contoso の目標を実現するために、NAP をどのように利用できるでしょうか。NAP の主要サービスを思い出してみましょう。NAP のポリシーの検証を使用すれば、Contoso のネットワークに接続するすべてのコンピュータの正常性を確認できます。ポリシーの検証では、コンピュータに適切にウイルス対策ソフトウェアの定義ファイルがインストールされているか、およびすべてのセキュリティ更新プログラムが適用されているかを確認できます。NAP ポリシーの検証ルーチンがコンピュータに問題があると判断した場合、問題のあるコンピュータを扱うホストに、ネットワーク接続を限定できます。これにより、オフサイトで使われ、マルウェアに感染したコンピュータが、ネットワークの他の部分に問題を拡大することがなくなります。問題のあるコンピュータは NAP により接続が制限され、Contoso の IT 管理者が定めた修復リソースにしかアクセスできません。たとえば、問題のあるコンピュータは、Contoso の WSUS サーバーとウイルス対策ソフトウェアの定義ファイルをホストしているサーバーへのアクセスが許可されます。また、NAP により、コンピュータが正常になった後も、正常な状態が継続して保たれるようにすることもできます。この例では、問題のあるホストが在宅勤務者により VPN 経由で使用され、このホストのファイアウォールが無効にされた場合、NAP は自動的に問題を修復します。ファイアウォールが無効にされると、直ちに NAP インフラストラクチャは問題のコンピュータを検疫処理し、ファイアウォールを再度有効にして、コンピュータの正常性を再評価し、コンピュータが正常であると判断した後に、コンピュータを制限されていないネットワークに戻します。NAP の 4 つの主要サービスは、まさに Contoso の動的でモバイル化が進んでいるコンピューティング環境の重要なセキュリティ要件に対応できます。

NAP デザイン
多くの中小規模組織にとって最も短期間で簡単に実装できる方法は、DHCP ベースの NAP の適用です。これは、DHCP での適用では、ネットワークを変更する必要がなく、DHCP と NPS 以外のサービスを追加する必要がないためです。IPsec での適用および 802.1X での適用では、柔軟性が高まりますが、ネットワークの変更と新しいサービスの展開が必要です。それほど複雑でない環境では、DHCP を利用することで、実装コストを大幅に抑え、運用の手間も比較的かけずに、NAP の主なメリットを得られます。
Contoso の環境では、Windows Server "Longhorn" を実行するコンピュータを NAP 展開の中核に使用しています。NAP には Windows Server "Longhorn" NPS が必要なため、以前のバージョンの Windows Server には NAP を展開できません。DHCP ベースの NAP の適用には、Windows Server "Longhorn" DHCP サーバーも必要です。サービスを統合する場合は、NPS と DHCP を同じサーバー上に展開できます。NPS と DHCP は共存させても問題ありません。したがって、Contoso の基本の NAP サーバー インフラストラクチャは極めてシンプルで、Windows Server "Longhorn" コンピュータ 1 台で、ポリシー コンポーネントとポリシー適用コンポーネントの両方を実行しています。
Contoso のクライアント側の Windows Vista を実行するコンピュータには、NAP のサポートに必要な機能が既に組み込まれています。クライアント側の Windows Vista を実行するコンピュータに唯一必要な変更は、NAP 機能を有効にすることです。これは、グループ ポリシーを使用して行うことができます。Contoso の Windows XP を実行しているコンピュータについては、NAP クライアント パッケージを別途インストールする必要があります。既定では、ドメインに参加している Windows XP コンピュータは、Windows セキュリティ センター機能が無効にされています。NAP ポリシーがコンピュータの正常性評価にセキュリティ センターの状態情報を使用する場合は、NAP が適切に機能するよう、セキュリティ センターが稼働している必要があります。したがって、Contoso の Windows XP コンピュータでは、管理者がグループ ポリシーを使用してセキュリティ センターを有効にしました。クライアント側で NAP をサポートするために、これ以外に必要な変更はありません。

Contoso の NAP の展開
前述のグループ ポリシーによる必要な変更ができたら、Contoso の NAP 展開の次のステップは、Windows Server "Longhorn" のインストールです。Windows Server "Longhorn" のどのバージョンにも NAP コンポーネントは含まれているので、Contoso のニーズに合わせて最適なエディションを使用できます。インストールが完了したら、IT 管理者がサーバー マネージャ ツールを使用して、新しい役割をコンピュータに追加します。Contoso が使用する DHCP ベースの適用の場合、必要な役割はネットワーク アクセス サービスと DHCP サーバーです。役割の追加ウィザードを使用して、依存関係の処理や必要な機能をサーバーに追加できます。役割を追加できたら、NAP の構成に着手します。
Contoso の管理者は、サーバー マネージャ ツールを使用して、Microsoft 管理コンソール (MMC) の DHCP スナップインにアクセスし、新しいスコープを追加します。Windows Server "Longhorn" DHCP サーバーを構成すると、このサーバーがサービスを提供している IP セグメント上のすべての既存の DHCP サービスが置き換えられます。スコープを作成し、Contoso のネットワークを基に適切なオプションを設定できたら、このスコープに対して NAP を有効にします。この処理は、[スコープのプロパティ] ダイアログ ボックスの [ネットワーク アクセス保護] タブで行います (図 2 参照)。
図 2 NAP の有効化
図 2 NAP の有効化
NAP は、新しい NAP ユーザー クラス スコープ オプションを使用して、同じスコープ内で制限されたネットワーク アクセスと制限されていないネットワーク アクセス間でコンピュータを切り替えます。この特殊なスコープ オプションのセット (DNS サーバー、既定の DNS サフィックスなど) は、問題のあるクライアントにリースが提供されたときに使用されます。たとえば、正常なクライアントには既定の DNS サフィックス "contoso.com" が提供されるところを、問題のあるクライアントには "restricted.contoso.com" というサフィックスが提供されます (図 3 参照)。DHCP スコープ オプションを構成できたら、ネットワーク ポリシー サーバーをセットアップし、ルールを作成します。
図 3 アクセスの制限
図 3 アクセスの制限
NPS ポリシーは次の 4 つの主要コンポーネントで構成されます。システム正常性検証ツール (SHV) は、コンピュータの正常性を確認するために、どのようなチェックを実行するかを定義します。修復サーバー グループは、正常な状態になるために問題のあるコンピュータにアクセスが許可されるシステム (WSUS など) の一覧を保持します。システム正常性検証ツール テンプレート コンポーネントは、実際の正常性状態の定義に使用されます。たとえば、Contoso では、ウイルス対策ベンダが提供する別の SHV チェックに合格しなくても、Windows セキュリティ SHV のチェックに合格しているコンピュータは "遵守" コンピュータであると見なすことができます。これらのコンポーネントは、各コンピュータの状態に応じて処理方法を決定するロジックを含む、ネットワーク ポリシーのセットにまとめられます。
システム正常性検証ツールは、NAP エージェントがチェックし、NPS に状態をレポートする項目の一覧です。既定の NAP 展開には、Windows SHV が含まれます。これは、Windows セキュリティ センターに統合し、NAP がセキュリティ センターを通じてレポートされるすべてのセキュリティ コンポーネントの状態を確認できるようにするものです。これには、ファイアウォール、ウイルス対策、自動更新、スパイウェア対策コンポーネントなどがあります。
NAP は拡張可能であり、サードパーティが独自の SHV を作成して個々のコンポーネントのより詳細なチェックを提供できたことを思い出してください (詳細については、microsoft.com/windowsserver2003/partners/nappartners.mspx を参照してください)。たとえば、Windows セキュリティ SHV は、NAP によりウイルス対策コンポーネントが有効で最新であるかを確認できるようにします。ただし、Windows セキュリティ SHV は、コンピュータがスキャンされる頻度やその他のアプリケーション固有のオプションなど、ウイルス対策アプリケーションについてさらに詳細なチェックは実行できません。しかし、ウイルス対策ベンダは、各社のアプリケーションとより密接に統合される独自の SHV を作成し、既定の Windows SHV よりも詳しくアプリケーション固有のチェックを実行できます。この SHV を Windows SHV やその他の SHV と連携させ、NAP 展開で複数の SHV を同時に使用することもできます (図 4 参照)。
図 4 Windows セキュリティ SHV
図 4 Windows セキュリティ SHV
修復サーバー グループは、問題のあるコンピュータがアクセスできるリソースの指定に使用されます。多くの場合、このグループには、WSUS または Systems Management Server (SMS) サーバーと、ウイルス対策ソフトウェアの更新サーバーが含まれます。このようなサーバーだけでなく、これらのサーバーの検索にクライアントが使用する名前解決サーバーも含める必要があります。Contoso のクライアントは、グループ ポリシーを使用して自動更新用のサーバー wsus.contoso.com を使用するよう構成されるため、修復サーバー グループには、WSUS サーバーの IP アドレスだけでなく、クライアントが完全修飾ドメイン名 (FQDN) を数字で表される IP アドレスに変換するために使用する DNS サーバーの IP アドレスも指定する必要があります。このような名前解決リソース (クライアントの構成により、DNS と WINS の両方になる場合があります) へのアクセスを許可しないと、クライアントは修復リソースの IP アドレスを解決できないため、修復リソースにアクセスできません。図 5 は、この例の DNS 設定と IP 設定を示しています。
図 5 DNS 名と IP アドレス
図 5 DNS 名と IP アドレス
システム正常性検証ツール テンプレートは、正常なコンピュータの条件定義に使用されます。検証ツール テンプレートは、SHV チェックの結果と、1 つまたは複数の SHV チェックの合否を基にコンピュータが正常かどうかの状態を受け取ります (図 6 参照)。
図 6 遵守状態のチェック
図 6 遵守状態のチェック
Contoso 環境では (多くの中小規模の展開と同様に)、定義されている状態は 2 種類のみです。正常なコンピュータは、すべての SHV チェックに合格したコンピュータです。非遵守コンピュータは、1 つ以上の SHV チェックで不合格になったコンピュータです。必要に応じて、さらに複雑なロジックを実装することもできます (ユーザーの職務、部門、場所などを基準に異なる遵守標準を作成するなど)。ただし、その場合は、問題の特定とトラブルシューティングがより難しく、時間がかかることに注意してください。
上記のコンポーネントはすべて、ネットワーク ポリシーに含まれます。ネットワーク ポリシーは、管理者によって定義され、コンピュータをその正常性状態を基にどのように扱うかを NPS に指示します。これらのポリシーは、上から下へ順番に (NPS の UI の表示どおり) 評価され、ポリシーのルールに適合した場合、処理はそこで中止されます。
また、Contoso ネットワークでは簡潔を目標としているため、わずかなポリシーしか必要ありません。1 つ目は、Compliant-Full-Access ポリシーです。このポリシーでは、すべての SHV チェックに合格したコンピュータには、無制限のネットワーク アクセスが許可されることを示します。具体的には、コンピュータの正常性が評価され、すべてのチェックに合格すると、このコンピュータに "正常" スコープ オプションの IP リースを提供するように、NPS が DHCP サーバーに指示します。この Compliant-Full-Access ポリシーは、通常、チェック時に大半のコンピュータがポリシーを遵守しているため、処理の実行順一覧の最初に置かれます。このポリシーを一覧の最初に置くことで、NPS の処理負荷と時間を削減します。
次に使われるポリシーは、Noncompliant-Restricted です。Contoso 環境では、1 つ以上の SHV チェックに不合格になった (したがって、非遵守システム正常性検証ツール テンプレートに一致した) コンピュータが、このポリシーに対応します。このポリシーに一致すると、クライアントに特殊な NAP "制限" スコープ オプションを提供するように NPS が DHCP サーバーに指示します。これにより、非遵守コンピュータが、Contoso の修復サーバー グループで定義されているリソースにしかアクセスできないようにします。
3 つ目のポリシーは旧バージョンとの互換性のためのものです。既定では、NAP サポートは Windows XP 以降のオペレーティング システムで使用できました (ただし、独立系ソフトウェア ベンダが、これより古いバージョンの Windows や Windows 以外のオペレーティング システム用に NAP クライアントを開発している可能性もあります)。Contoso で Windows 2000 がまだ運用されていた場合、(DHCP サーバーにより既定のスコープ オプションを提供して) NAP に対応していないコンピュータがネットワークに通常どおりアクセスできるようにするルール (この記事の例では Downlevel-Full-Access) を作成できます。このポリシーは、最後に評価します。また、旧バージョンのコンピュータがネットワーク アクセスを必要とする場合しか、作成および有効化する必要はありません (図 7 参照)。
図 7 下位コンピュータ用のアクセス設定
図 7 下位コンピュータ用のアクセス設定
プリンタやその他のハードウェアなど、NAP に対応することがないリソースが Contoso にある場合はどうなるでしょうか。また、NAP には対応していても、完全にまたは一時的にポリシー チェックの対象外とする必要があるコンピュータが Contoso にある場合はどうなるでしょうか。このようなコンピュータを除外する簡単な方法は、MAC アドレスを使用することです。Contoso の管理者は、このようなコンピュータに NAP チェックのバイパスを提供し、完全なネットワーク アクセスを許可する新しいポリシー (Exempt by MAC) を作成できます。このポリシーは、RADIUS クライアント プロパティのコーリング ステーション ID が、NAP のバイパスが必要なデバイスの MAC アドレスと一致する場合の条件ステートメントを使用します。NPS は、コンピュータがこのポリシー ステートメントに一致した場合、"正常" スコープ オプションのリースを提供するように DHCP に指示します。このポリシーは、評価の一覧の最初に置き、全体の処理時間と NPS の負荷を削減するようにします。このポリシーに一致したコンピュータは、SHV の評価を必要としないため、NPS がこれらをチェックするサイクルに含めても意味がありません (図 8 参照)。
図 8 特定のコンピュータを無視
図 8 特定のコンピュータを無視
これらのポリシーを組み合わせることで、Contoso の NPS がネットワークに接続するコンピュータを短時間で正確に評価できるようにします。また、古いコンピュータやデバイス、または NAP 対応デバイスに一時的なバイパスが必要な場合に、これらをチェックから除外することができます。

まとめ
NAP は、さまざまなテクノロジを包括しているため、特に複雑なシナリオでは、十分な計画とテストが必要です。ここでは、比較的複雑でないシナリオを扱いましたが、NAP Web サイトにはすべての規模の展開の詳細ガイダンスが公開されています。この Web サイトには、一般にエンタープライズ環境では DHCP ベースの適用よりも適している 802.1X および IPsec ベースの適用テクノロジの計画に役立つ情報もあります。
NAP は、ネットワークに接続するコンピュータの正常性を評価できる拡張可能なプラットフォームを提供します。中小規模組織では、DHCP ベースの適用を採用することで、安価な実装コストと管理コストで多くのメリットが得られます。NAP は、Windows Server "Longhorn" の主要機能であり、組織がセキュリティや法令遵守の強化を行ううえで有用です。
NAP の関連情報
  • ネットワーク アクセス保護
  • テスト ラボで動的ホスト構成プロトコルのネットワーク アクセス保護適用をセットアップする
  • ネットワーク アクセス保護のパートナー
  • 「ネットワーク アクセス保護の概要」ホワイト ペーパー Web キャスト

John Morelloは、これまでマイクロソフトで 6 年間さまざまな任務を果たしてきました。シニア コンサルタントとして、フォーチュン 100 企業や、連邦政府の民生向けおよび国防向けのセキュリティ ソリューションの設計に携わってきました。現在は、Windows Server グループのシニア プログラム マネージャとして、あらゆる場所からのアクセスを実現するテクノロジに取り組んでいます。


 デスクトップ ファイル: Windows Deployment Services 再考
デスクトップ ファイル
Windows Deployment Services 再考
Wes Miller

ここ数回のコラムでは、Windows Vista と次期バージョンの Windows Server "Longhorn" に関連する展開テクノロジについて取り上げてきました。しかし、ソフトウェアには変更がつきものです。そこで、今回は Windows Deployment Services (WDS) に関して、Windows Server® "Longhorn" での更新についていくつか取り上げます。
また、読者からの質問や、ここ数か月に参加したディスカッションで受けた質問が少し手元にたまりましたので、今回のコラムの一部を割いて、ImageX、WDS、および Windows® PE に関連する質問にもお答えします。

新機能と機能強化
本来 WDS が企画された時点では、Windows Server 2003 へのアドオンとして出荷された機能と、後に Windows Server "Longhorn" で出荷されることになるバージョンの機能は、ほぼ同等になる予定でした。しかし、Windows Server "Longhorn" 向けに WDS を開発しているチームは、リリース予定のサーバー プラットフォーム専用に機能する 3 つの主要新機能に熱心に取り組みました。
これらの新機能とは、マルチキャスト展開、TFTP ダウンロード パフォーマンスの向上、および x64 システム用 EFI (拡張ファームウェア インターフェイス) ネットワーク ブートのサポートです。こうした機能は WDS ユーザーや管理者にとっては大きなメリットがあるため、これらの新機能をそれぞれ調べていくことにしましょう。ただし、Windows Server 2003 向けの WDS の今後バージョンには、これらの機能が含められる予定がないことに注意することが重要です。

マルチキャスト
マルチキャストは、筆者が Windows チームに参加するずっと以前から最もよく議論されていた機能の 1 つであり、リモート インストール サービス (RIS) だけでなく、Windows 展開にさえ一般に求められていた機能です。サードパーティの展開テクノロジを使用したことがあるユーザーは、マルチキャスト展開で何が可能になるのかを認識していました。マイクロソフト内の少数のシナリオに固有の展開テクノロジ、特に ADS (Automated Deployment Services) ではマルチキャストを実装していましたが、OEM や企業向けに提供されたものはなく、OEM ユーザーや企業ユーザーと展開について話し合うたびに、この機能を頻繁に要求されたものでした。
マルチキャストの主なメリットは、複数のコンピュータが通信を同時に受信できることです。つまり、送信側 (この場合は WDS サーバー) は通信を行うために情報を 1 回しか送信しません。各クライアントは、エンド ツー エンドで受信するために全通信をリッスンする必要があります。すべてのクライアントが特定の 1 つのネットワーク アドレスをリッスンするため、次の 2 つのメリットが生じます。まず、複数のクライアントが同じタスクを実行することによりネットワークが過密状態になることが少なくなるため、展開速度が向上します。次に、各クライアントが 1 つのストリームをリッスンするため、ネットワークが飽和状態になることが少なくなります。
マルチキャストの欠点は、歴史的に見て、まさにマルチキャストのインフラストラクチャそのものにあります。多くの人が子供のころ遊んだことのある "伝言" ゲームを想像してください。おそらく、次のようなゲームだったと思います。
  1. あなたから隣の人にあるフレーズを話します。
  2. 隣の人がそのフレーズを聞き取ります。
  3. 隣の人は 3 番目の人に同じフレーズを繰り返して伝えます。
  4. ゲームに参加しているすべての人にこれを繰り返します。
ここで、マルチキャストの本質的な問題は、4 人の人に全フレーズを話すためには、全員が部屋の中にいて、同時に聞き取る必要がある点です。5 人目の人が部屋に入ってきた場合、すぐに聞き取ることができなければ、全フレーズを再度繰り返す必要があります。
マルチキャストは、ほぼ同じ方法で機能します。まず、ネットワーク経由でバイナリ イメージ (通常は、セクタ ベースのディスク イメージ) を送信します。通常、このイメージを受信する必要のあるすべてのクライアントは、イメージが最初にブロードキャストされた時点ですぐに準備が整わない場合、キューで受信を待機する必要があります。さらに面倒なことに、ネットワークの問題やネットワークのパフォーマンスが原因でクライアントが多くのデータを受け取れなかった場合は、(全ディスク イメージを受信できたかどうか確認できないため) 通信キュー全体を削除するか、問題が発生したクライアントのニーズを満たすことのできるレベルまでグループ全体がネットワークの速度を遅くする必要があります。何百ものシステムに同時に展開するようなシナリオでマルチキャスト システムを設計する場合は、すべてのシステムが同時に起動され、あるシステムの速度の遅さが他のシステムに影響しないことを確認することに多くの時間を割くことになります。
WDS チームでは新しいマルチキャスト エンジンを提供することでこれらすべてを変更しました。このエンジンは、非常に独特の機能をいくつか可能にするファイルベースの WIM (Windows Imaging Format) インフラストラクチャを利用しています。ほとんどのサードパーティのマルチキャスト ソフトウェアで可能な段階的なマルチキャスト シナリオを実行できますが、WDS のマルチキャスト ソリューションはこうしたソフトウェアをはるかに上回る機能を提供します。
まず、クライアント コンピュータは任意の時点で転送に参加できます。マルチキャストのブロードキャストでは、ファイル ストリームのブロードキャストが "ラウンド ロビン方式" で行われ、すべてのクライアント コンピュータのニーズが満たされるまで、ブロードキャストが続行されます。このため、クライアントがオンラインになるタイミングは問題になりません。クライアントは WDS サーバーをリッスンし、サーバーはイメージ ファイルのブロードキャストを完了した時点で、最初からブロードキャストを始めます。クライアントがあるファイルを受け取れなかったとしても、そのファイルが再度送信されるのを待機するだけです (回転木馬の木馬を想像してください)。
次に、プロトコルがまったく新しくなり、過密状態の制御やフロー制御を備えています。つまり、既存のネットワーク通信に影響を与えずに、運用ネットワークで適切に機能します。あるマルチキャスト ソリューションが妥当であると評価したネットワーク管理者共通の懸念は、実際には通信効率を高めようと試みているときに、そのソリューションを有効にすることで皮肉にもネットワークがトラフィックであふれかえってしまうということです。
第 3 に、このソリューションは WDS および Active Directory® とは無関係にデザインされました。つまり、このソリューションを利用するのに、Active Directory もアクティブな WDS 実装も必要ありません。ImageX マルチキャストは単独で実行することができるため、多くのシナリオに適しています。マルチキャスト クライアントは、Windows Server "Longhorn" (および Windows PE の関連リリース)、Windows Vista™、Windows XP Service Pack 2 (SP2)、または Windows Server 2003 SP2 で実行できるコマンドライン アプリケーションです。
WDS MMC と WDSUtil アプリケーションには、マルチキャストのセットアップと構成を行うための新しい管理タスクがあります。また、WDS クライアントのユーザー インターフェイスにも、マルチキャストが使用されていることを示す変更が加えられています。
管理者は WDS 管理ツールを使用して、クライアントへの転送の進行状況を (クライアントの転送からの削除を含めて) リアルタイムに監視できます。管理ツールには完全なログ記録やレポート処理も用意され、RIS ではまったく利用できなかった、インストールのログを記録する方法が管理者に提供されます。
Windows Server "Longhorn" 向けの WDS のマルチキャストは、これまで私が耳にした発表の中では最も魅力的な機能の 1 つです。WDS チームが、これまで多くユーザーが求めてきた機能を OEM ユーザーや企業ユーザーにとって適切な方法で提供できたのはすばらしいことです。

TFTP ダウンロードのパフォーマンスの向上
簡易ファイル転送プロトコル (TFTP) は、PXE (Pre-boot eXecution Environment) の重要なコンポーネントであり、PXE 自体は RIS と現在の WDS のバックボーンです。TFTP が選択されたのは、そのネットワーク効率や堅牢性だけでなく、極めて小さなプロトコル (ステートレスで、セキュリティが考慮されず、UDP ベースである) であることが大きな理由です。このため、ネットワークから PXE ブートされるシステムに必要なブート ROM へのカプセル化に適しています。
Windows Server "Longhorn" では、TFTP ダウンロード時間を大幅に短縮できる方法で TFTP デーモン (TFTPD) が完全に書き直されました (大きな強化点は、すべての WDS 展開が RAM イメージからの Windows PE ブートに基づくようになったことです)。Windows Server 2003 で RIS や WDS から Windows PE をダウンロードする際のパフォーマンスの向上を希望していたユーザーにとっては朗報です。
PC を取り巻く環境が普遍的な BIOS (現状の x86 PC のバックボーン) から EFI に移行し始めたとき、マイクロソフトでは WDS が 新しく利用可能になる x64 サーバー システムで機能するように準備しました。こうした x64 サーバー システムは、BIOS ではなく EFI を使用して起動されます。搭載された機能により、x64 クライアント システムは WDS サーバーから PXE ブートすることができます。

質問
WDS の更新の説明を行うと同時に、コラムの残りの部分を使っていくつかの質問に回答しようと考えています。ここでは、電子メールで受け取ったり、最近オンラインのディスカッションで見かけたものの中から、このコラムの読者にも興味深いと思われる質問を取り上げました。

質問 - DHCP を使用していない環境で WDS を使用することはできますか。利用しているネットワークでは DHCP トラフィックや PXE トラフィックが許可されません。
回答 - はい、おそらく、DHCP を使用しない環境でも WDS を使用することはできますが、サポート対象のインストールごとに、それぞれ一意な IP アドレスを持つ、一意な CD メディアを作成する必要があるため、ソリューションに拡張性はありません。多分、インストールには DVD メディアを使用するほうが有効でしょう。DHCP を使用しないで WDS からインストールしなければならない場合は、次の手順を実行します。
  1. サーバーを静的に定義して WDS 検出イメージを作成します (このサーバーは、インストール元となる具体的な WDS サーバーを指します)。
  2. このインストール元 WDS サーバーのポート 4011 で DHCP トラフィックを許可します。DHCP を使用していない場合でも、WDS クライアントがサーバーと通信できるようにこの許可が必要です。
  3. DHCP の代わりに静的 IP アドレスを指定して、一意な Windows PE メディアを作成します。
IP アドレスの衝突を避けるためにクライアント メディアを一意にする必要があり、ネットワーク上の特定の WDS サーバーを示す必要があるため、このソリューションには手間がかかることに注意してください。PXE (これ自体が DHCP に基づきます) が WDS のバックボーンとなるため、環境内で DCHP を許可している方が WDS が適切に機能することがわかります。

質問 - WDS 以外の PXE サーバーから Windows PE 2.0 を PXE ブートすることを考えています。このような方法はありますか。
回答 - WDS PXE サーバー以外から Windows PE 2.0 を機能させる場合はサポート技術情報の記事 (support.microsoft.com/kb/926172) が参考になりますが、この方法に関するマイクロソフトからのサポートには制限があることに注意してください。

質問 - BDD とは何ですか。Windows 自動インストール キット (WAIK) はその一部ですか。
回答 - BDD (実際には、Business Desktop Deployment ソリューション アクセラレータ) は、Windows 展開ツール (WAIK など) を管理可能かつ再現可能な方法で使用するためのガイダンスとなるフレームワークです。WAIK は BDD に直接含まれているわけではありませんが、BDD はインストールに必要な WAIK などのツール (まだインストールされていない場合) をすべてまとめます。そのため、厳密には BDD には WAIK は含まれていませんが、BDD が機能するには WAIK が必要です。BDD の詳細については、TechNet デスクトップ展開を参照してください。

質問 - Windows Server 2003 向けの WDS はどこで入手できますか。
WDS は WDS ディレクトリ (go.microsoft.com/fwlink/?LinkId=85377 参照) の WAIK ダウンロードの一部として入手できます。

質問 - Windows PE 2.0 を構成して、静的 IP アドレスでブートし、DNS 構成をサポートすることはできますか。
回答 - 静的 IP を構成するには、図 1 の unattend.xml サンプルを使用し、このファイルが選択されるように、CD、USB フラッシュ ドライブなどのブート可能なメディアのルートに配置します。さらに、DNS サポートを構成する場合は、次のコマンドも実行する必要があります。
Figure 1 図 1 unattend.xml (Close Figure 1)
<?xml version="1.0" encoding="utf-8"?>
<unattend xmlns="urn:schemas-microsoft-com:unattend">
 <settings pass="windowsPE">
  <component
   name="Microsoft-Windows-TCPIP"
   processorArchitecture="x86"
   publicKeyToken="31bf3856ad364e35"
   language="neutral"
   versionScope="nonSxS"
   xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
   <Interfaces>
    <Interface wcm:action="add">
     <Ipv4Settings>
      <DhcpEnabled>false</DhcpEnabled>
     </Ipv4Settings>
     <UnicastIpAddresses>
      <IpAddress wcm:action="add" wcm:keyValue="1">
       192.168.0.1</IpAddress>
     </UnicastIpAddresses>
     <Identifier>Local Area Connection</Identifier>
    </Interface>
   </Interfaces>
  </component>
 </settings>
<cpi:offlineImage
 cpi:source="wim:c:/simtest/winpe.wim#Microsoft Windows Vista PE (X86)"
 xmlns:cpi="urn:schemas-microsoft-com:cpi" />
</unattend>

net start "DNS Client"
netsh interface ipv4 add dnsserver "Local Area Connection" 192.168.2.10 index=1

質問 - ファイバ チャネル コントローラから Windows PE をブートできますか。
回答 - できます。提供されているファイバ チャネル HBA では Int13 を使用してブート ボリュームの登録をサポートするため、Windows PE 用にブート可能なボリュームとして BIOS に表示されます。製品に付属する他の記憶域コントローラ ドライバを使用することになる場合は、ファイバ チャネル コントローラのドライバを追加することも必要です。

質問 - Windows PE 2.0 は常に RAM ディスクからブートされます。使用しているシステムの中にはこの方法でブートするための RAM が不足しているものもあります。RAM ディスクを使用しないで Windows PE 2.0 をブートすることはできますか。
回答 - できます。特に、システムに装備されている RAM が 256 MB 未満の場合は、Windows PE のブートに RAM ディスク以外の実装が必要になることがあります。マイクロソフトでは、この方法を記載したサポート資料を執筆中です。この方法には重要な注意事項が 2 点あります。RAM ディスクとは異なり、メディアを切り替えることはできません。この方法を採用した場合は、RAM ディスクベースのバージョンの Windows PE 2.0 のブートよりも低速になります。

質問 - DVD 以外のメディアから Windows PE 2004 と Windows PE 2005 (1.5 または 1.6) をブートし、DVD からイメージ (またはその他のデータ) のコピーを試みました。DVD からブートしないで、データを DVD からコピーするだけなのですが、機能しません。Windows の完全版がインストールされていると DVD は読み取り可能ですが、Windows PE ではそのボリュームが破損しているか読み取り可能ではないことを示すエラーが発生します。この問題を解決できますか。
回答 - できます。Windows PE 1.x は、既定では UDF でフォーマットされたメディアをサポートしません。定義によれば、DVD は ISO ブリッジ サポート (ISO と UDF のデュアル フォーマット) でフォーマットされているか、単に UDF でフォーマットされているかのいずれかです。これを機能させるには、Windows PE のインストールに UDF ドライバを追加する必要があります。ドライバが既に存在している場合は、インストールされていないだけです。ドライバをインストールするには、次の手順を実行します。
  1. メモ帳を使って、I386 (Windows PE のハードディスク インストールの場合は MiniNT) ディレクトリにある txtsetup.sif ファイルを開きます。
  2. [CdRomDrivers.Load] セクションに移動し、cdfs.sys というドライバを含む行を探します。その行の下に、udfs = udfs.sys という行を追加します。エントリは次のようになります。
[CdRomDrivers.Load]
cdfs = cdfs.sys
udfs = udfs.sys
3. [CdRomDrivers] セクションに移動し、cdfs を含む行を探します。その行の下に、udfs = "Universal Disk File System" という行を追加します。エントリは次のようになります。
[CdRomDrivers]
cdfs = "CD-ROM File System"
udfs = "Universal Disk File System"
4. txtsetup.sif を保存して終了し、必要に応じて Windows PE イメージを作り直します。これで、Windows PE 内から UDF でフォーマットされた DVD メディアを読み取れるようになります。

質問 - 使用しているシステムの中に Windows XP を実行しており、ACPI をサポートしない古いシステムが数多く含まれています。こうしたシステムを Windows Vista に移行するため、場合によっては Windows XP を再インストールするために、これらのシステムで Windows PE 2.0 を使用できますか。
回答 - できません。Windows PE 2.0 は、ACPI (Advanced Configuration and Power Interface) 準拠のシステムしかサポートしないため、質問にあったシステムではブートできません。こうしたシステムで Windows PE を使用する必要がある場合は、Windows PE 1.6 以前を使用してください。

質問 - Windows PE (1.x または 2.0) で実行する予定で独自のアプリケーションを Visual Studio® 2005 で作成しました。このアプリケーションは機能しますか。
回答 - これはアプリケーションを作成した方法によって異なります。アンマネージ C++ を使用していれば、アプリケーションは機能します。いずれかのマネージ コード言語 (C# や J# など) を使用しているか、マネージ C++ コードを作成した場合は、機能しません。Microsoft® .NET Framework (全バージョン) は Windows PE では使用できないため、マネージ コードは実行できません。

質問 - Windows PE 2.0 で使用するための独自のアプリケーションを作成しており、何らかの支援が必要です。どこで情報を探すのが最適ですか。
回答 - Windows PE デベロッパーズ ガイド ホワイトペーパーから始めることをお勧めします。

質問 - CD から数回 Windows PE 2.0 をブートしましたが、ドライブ文字 (RAM ディスク) は常に X です。ブート元の実際のドライブ文字を調べる方法はありますか。
回答 - レジストリを調べると、Windows PE が最初にブートされた実際のドライブ文字が次のキーに反映されています。
HKEY_LOCAL_MACHINE\SYSTEM\Setup\SystemPartition
Windows PE 内でサードパーティのシェルが使用されているためこのキーが設定されていない場合は、次のコマンドを実行すると、ドライブ文字が正しい値に更新されます。
start /w wpeinit UpdateBootInfo

質問 - ImageX ファイルと WIM ファイルを使用してシステムをバックアップすることはできますか。
回答 - 理論的には可能ですが、お勧めしません。ImageX では、本来のバックアップ ツールとは異なり、ロックされているファイルや開かれているファイルをバックアップすることができません。開かれているファイルやロックされているファイルを保護できる、本来のバックアップ ユーティリティを引き続き使用することをお勧めします。

質問 - 圧縮されていない WIM ファイルをキャプチャすれば、同じボリューム イメージが圧縮されている場合に比べて高速に展開できますか。
回答 - いいえ、大差ありません。圧縮されていることにより、キャプチャには時間がかかります。ただし、対象システムへのイメージの適用は、使用している圧縮の種類 (なし、 XPress、または LZX) とは関係なく、それほど時間はかかりません。イメージ サイズの実際のニーズとキャプチャにかけられる時間を基に圧縮の種類を選択することをお勧めします。

質問 - WIM イメージの適用を計画している場合、ディスクを再度パーティション分割して、フォーマットする必要がありますか。
回答 - 実行する必要があります。クリーンなイメージのシステムを実行するためには、まず、diskpart ツールを使用してボリュームをクリーンな状態にする (または、対象のパーティションを削除して再作成する) 必要があります。また、適用前にボリュームを完全にフォーマットすることもできます。
さらに、Windows Vista よりも前のバージョンの Windows では使用するブート セクタが異なっていることを覚えておく必要があります。そのため、Windows Server 2003 以前の展開に Windows PE 2.0 を使用している場合は、Windows のセットアップや WIM の適用を始める前に、Windows PE 内から次のコマンドを実行して、Windows Server 2003 以前をブートできるブート セクタを設定する必要があります。
bootsect /nt52 sys C: /force

まとめ
WDS にどのような更新が行われたかがわかり、関連する質問への回答が役に立ち、興味深いものであればさいわいです。読者から頂いたすべての質問に感謝します。今後もコラムのスペースに余裕があれば、こうした質問に回答するよう全力を尽くします。筆者の紹介に記載した電子メール アドレスに、これからもメールをお寄せください。
Windows Vista Harware Assessment
Baldwin Ng

朗報です。数か月前から行っている提案に、マネージャが最終的な答えを出します。どうやら、マネージャは Windows Vista を組織全体に展開するという提案を真剣に検討し、1 つのオペレーティング システムを管理することのメリットとコスト削減を考え始めたようです。しかし、Windows Vista をインストールするためにすべての PC をリプレースすることに財務上の合理性があるかどうかについて完全に納得しているわけではありません。そのため、どの PC が Windows Vista に現状のまま適切に移行でき、どの PC が移行に伴いシステム メモリやハードディスク領域の追加などのわずかなアップグレードを必要とするかについて、明確かつ詳細な情報を求めています。さらに、この回答を週末までに提出するように求めています。では、どこから作業を始めましょう。組織に最新の資産やネットワーク管理ツールがないときに、どうすれば数日間で回答を得られるでしょうか。さらに悪いことに、前任者は既存のネットワーク資産に関して十分な情報を残していません。
マイクロソフトでは、Windows Vista に対する組織の対応状況を判断する際に役立つソリューション アクセラレータとして Windows Vista Hardware Assessment をリリースしました (microsoft.com/technet/wvha 参照)。このツールは、ネットワーク上の PC をすばやく評価し、ハードウェアやデバイスの互換性に関する詳細な対応状況レポートを生成します。大半の中規模組織ではこの処理に数時間しか必要とせず、ネットワークに接続されている PC にどのようなソフトウェア エージェントもインストールする必要がまったくありません。
Windows Vista Hardware Assessment は、以前に Microsoft ADS (Assessment and Deployment Solution) 向けに開発された優れたインベントリ コレクションとレポート処理テクノロジを基に構築され、次の 3 ステップのプロセスで一連の対応状況レポートを作成します。

1. ハードウェア インベントリ
このツールは WMI (Windows Management Instrumentation)、Active Directory®、および NetServerEnum などのその他の Windows ネットワーク プロトコルを使用して、ワークグループ コンピュータだけでなく、ドメイン上のコンピュータを探索します。インベントリが完了すると、すべてのシステム リソースとデバイス情報が SQL Server™ 2005 Express データベースに格納されます。このツールの現リリースでは、最高 5,000 台までのコンピュータのネットワーク探索をサポートします。今後のリリースでは、さらに大規模なネットワークに拡張する予定です。

2. 互換性の分析
Windows チームから提供されたデバイスと BIOS の最新のデータベースを使用して、各PC のハードウェアとデバイスの Windows Vista に対する互換性に関する対応状況を分析します。また、ツールを実行するたびに最新の情報が得られるように、定期更新 Web サービスを使用してドライバ情報を取得します。

3. 対応状況レポート
最後の手順では、一連の対応状況レポートを Microsoft Word 文書と Excel® ワークシートの形式で自動生成します。これらのレポートでは、PC ごとに対応状況とアップグレードの推奨が提供されます。
他にも、Windows Vista Hardware Assessment を補完する Windows Vista ソリューション アクセラレータとして、Business Desktop Deployment 2007 や Windows Vista Security Guide などがあります。詳細については、ソリューション アクセラレータのホーム ページを参照してください。

Baldwin Ng は Microsoft Solution Accelerators チームのプロダクト マネージャで、ユーザーやコンサルタントが迅速かつ効果的な方法で Microsoft ソフトウェアを採用する際に役立つソフトウェアの自動化ツールの作成に取り組んでいます。連絡先は、Baldwin.Ng@microsoft.com (英語のみ) です。

Wes Miller は、テキサス州オースティンにある Pluck 社 (www.pluck.com) の開発マネージャです。以前はオースティンにある Winternals Software 社に勤務し、その後はマイクロソフトで Windows のプログラム マネージャ兼プロダクト マネージャとして働いていました。Wes の連絡先は、technet@getwired.com (英語のみ) です。Wes は、今回のコラムの WDS の新機能について執筆する際に、マイクロソフトの Windows Deployment Services 担当のプログラム マネージャである Scott Dickens から受けたアドバイスに感謝しています。


 フィールド ノート: 遅れをとらないために
フィールド ノート
遅れをとらないために
Joshua Hoffman

ああ、現場。 以前は現場のことがよくわかっていました。現職 (このすばらしい雑誌のテクニカル エディター) に就いて約 2 年になりますが、それ以前は現場で活躍する IT プロフェッショナルでした。Microsoft Consulting Services で 5 年間、Fortune 100 に名を連ねるさまざまな企業の IT 部門で数年間にわたり、現場に携わってきました。その後、現在の仕事に魅かれて移りました。別に不満を言っているのではありません。ここではすばらしいスタッフに恵まれていますし、読者の皆さんすべてに関わることができるのですから。それに、もう二度と月曜の朝 6:00 に飛行機に乗らなくてもよいのであれば、これも言うことありません。
しかし、新しい仕事には不利な面もあります。IT プロフェッショナルの多くは、この職種で新しいことを学ぶ (そして常に遅れをとらない) 一番の方法は、実際に作業することだと言うでしょう。実際に自ら作業することは、強力な教育ツールです。しかし、出世し、職務が変わると、突然管理すべきシステムやインフラストラクチャを持たない IT プロフェッショナルになっていることに気付きます。そして、ものごとは非常に速いスピードで変化します。この新しい仕事に就いて以来、新しい展開フレームワーク、新しいセキュリティ インフラストラクチャ、新しいネットワーク スタックなどの機能を備えた新しいバージョンの Windows® が登場しました。そう、Office も新しいバージョンになりました。それから、Exchange Server も。SQL Server™ も。Microsoft® Operations Manager も。また、新しいツールもいくつか登場しました。Windows PowerShell™、MMC 3.0、Windows 自動インストール キットなどです。見落としていなければよいのですが。
結果として、2 年間もあれば実に多くの変化があることがわかりました。では、学習の一番の方法が実践であり、現在の仕事にその "実践" の部分がなくなってしまったとしたら、どのようにして遅れをとらずにいられるのでしょうか。
もちろん、こうした記事がお役に立てばよいと思います。実際、私には役立っています。専門分野に精通した優れた執筆者を多数擁し、常に彼らの専門知識から恩恵を受けています。とはいえ、実践がどうしても必要になることもあります。私は、通常、まず Virtual PC (または Virtual Server) を使用します。どちらの製品も Microsoft Web サイト (TechNet Web サイトのダウンロード セクションにリンクがあります) から、無償でダウンロードできます。仮想化テクノロジを利用することで、ノートパソコン上に短時間で独自の Active Directory® を構築したり、Windows Vista™ の展開をカスタマイズしたりできます。ハードウェアを追加する必要はありません。何かのしくみを理解する場合、実際に自分で作業を行うことで、大きな違いが出ます。
Virtual PC の唯一の難点は、仮想環境を実際に構築しなければならない (OS をインストールし、すべてを適切に構成するなど) ことです。このような作業が調査の対象であれば、問題ではありません。しかし、ある製品の特定の機能のみを調べる場合はどうでしょうか。たとえば、Exchange Server 2007 の新しい法令順守機能を調査するとしたらどうでしょう。Windows Server®、Active Directory、および Exchange Server を最初からインストールして構成することは、かなりの作業に思えます。TechNet のバーチャル ラボにアクセスしてみてください。私見ですが、バーチャル ラボは、まれに見る最高のトレーニング リソースの 1 つです。面倒な部分は、バーチャル ラボ チームが既に対応しています。つまり、20 を超える製品のさまざまな組み合わせに対応した、インストールと構成が完了したバーチャル マシンが 180 以上も用意されています。各バーチャル マシンには、一般的な作業と新機能を知るうえで役立つ一連の演習も用意されています。特に便利なのは、プロセス全体をブラウザ環境で実行できることです。これはマイクロソフトが管理しているサーバーによりホストされているため、ユーザーがハードウェア リソースを用意する必要がありません。
ですから、現場の第一線を退いている場合、遅れをとらずにいることは難しくなるにしても、不可能ではありません。ここでは、気に入っているリソースをいくつかご紹介しました。また、友人の Edward Dake がこのコラムで数か月前に指摘したように、利用できる最高のリソースの 1 つは、仲間です。いつでも、助けを求めることができます。

Joshua Hoffman は、TechNet Magazine の技術面と買い付けを担当する編集者です。


 Windows 秘話: よく使用するプログラムを決定する
Windows 秘話
よく使用するプログラムを決定する
Raymond Chen

[スタート] ボタンをクリックすると、 [スタート] メニューが表示されます。左側にはプログラムの一覧が表示されます。このプログラムの一覧は、どのように決められるのでしょうか。原則としては、最近頻繁に実行したプログラムが、[スタート] メニューの最初の領域に表示されるようになります。ただし、この原則を踏まえて、いくらか調整を行う必要があることがすぐにわかりました。
基本ルールでは、プログラムが起動されるたびに、そのプログラムがポイントを獲得します。反対に、プログラムが起動されない期間が長くなるほど、ポイントが減っていきます。[スタート] メニューには、ポイント数の最も多いプログラムから表示されます。簡単ですね。これは、わかりにくい選択アルゴリズムではありません。この基本ルールを適用したうえで調整を行いますが、この調整が非常にわかりにくい部分です。
調整の前に、基本ルールについてもう少し詳しく説明しておきます。このルールでは、ショートカットではなく、プログラムの起動が対象になっていることに注意してください。プログラムの中には複数のショートカットをインストールするものがありますが、プログラムの起動にどのショートカットを使用したかは問題になりません。どれも同じ実行ファイルを指しているのであれば、そのプログラムは異なるショートカットが使われてもポイントを累積できます。
[スタート] メニュー
これは、[スタート] メニューから実行されなかった場合でも、エクスプローラから実行している限り、プログラムがポイントを獲得することを意味します。フォルダを開き、実行可能ファイルをダブルクリックして、プログラムを手動で実行した場合も、プログラムはポイントを獲得し、結果として [スタート] メニューの最初の領域に表示されるようになる可能性があります。
さて、[スタート] メニューの最初の領域に表示されるだけの十分なポイントをプログラムが獲得できたら、Windows® はそのプログラムを指しているショートカットが複数ある場合にどのショートカット アイコンを表示するかを決めなければなりません。この場合は、順当に、最も頻繁に使用されたショートカットが表示されます。
調整の一環として、一部のプログラムがこの一覧から除外されます。たとえば、[スタート] メニューに常に表示するように登録済みのプログラムは、同じプログラムのアイコンを 2 つ表示しても意味がないので除外します。結局、そのプログラムは、頻繁に実行するため [スタート] メニューに登録しているのですから。
別の調整ステップでは、"ノイズ" を除外します。メモ帳やワードパッドなど、一般的なヘルパー プログラムへのショートカット (Readme ファイルを表示するためのショートカットなど) になっているため、表示されていたプログラムが多数ありました。このようなショートカットは除外します。つまり、メモ帳のショートカットは対象から除外する必要がありました。なお、アプリケーションのレジストリに NoStartPage 値を作成することで、プログラムが [スタート] メニューの最初の領域に含まれないように登録することもできます。
基本ルールでは、一度起動したら実行し続けたままになるプログラムについても考慮されていませんでした。基本ルールの厳密な解釈に従うと、このプログラムは起動時にポイントを獲得しても、時間が経過するとこのポイントを失うことになります (この場合の "頻繁に" は、"ものすごく長い時間" のかなり控え目ないい方です)。そこで、もう 1 つ次のようなルールを追加しました。プログラムが連続して実行されている日数だけ、プログラムはポイントを獲得します。このルールは、このようなプログラムがポイント獲得競争からはじきだされることなく、実際によく起動される他のプログラムを圧倒しない程度のルールです。結局、そのプログラムを常時実行しているのであれば、これを頻繁に起動する必要はありません。
Windows Vista™ では、さらにいくつか調整ルールが追加されました。たとえば、[スタート] メニューから実行されたことがないプログラムのショートカットを、複数のショートカットの中から選択して表示する場合、コマンド ライン パラメータのないショートカットを優先するようになりました。また、一番最近に実行したプログラムは、そのポイント数に関係なく、必ず一覧に表示されるようになりました。

Raymond Chen は自分の Web サイト The Old New Thing および同じタイトルの書籍 (Addison-Wesley、2007) で、Windows の歴史と Win32 プログラミングについて扱っています。皆様からのご意見を大切にしており、受け取った順番に回答しています。