SE の雑記

以前、Twitter でつぶやいた内容をブログとしてまとめてみました。

私の家の検証環境は ThinkPad で 3 ノードクラスターを構築している環境があります。

ThinkPad では、CPU としては Intel の Core 2 Duo が使用されています。

それとは別に AMD の Phenom 9950 を使用している ML115 G5 もあります。
?

同一のベンダーの CPU であれば、プロセッサ バージョンが異なった場合でも、ゲスト OS の設定で CPU の機能制限をすることで、
Live Migration / Quick Migration を実行することができます。
?

この動作を全く別のベンダーの CPU で実行するとどうなるんだろうというのが今回の検証です。

私の検証環境に Intel のマシンとして、ML110 G5 がありこちらは Xeon を使用しているのですが、Core 2 Duo とさほど
機能的には変わらなかったので、ThinkPad と ML115 G5 間でゲスト OS を移行させてみたいと思います。

参考となりますが、Xeon の CPU 情報はこちらとなります。

?

[クラスターを構築]

Live Migration / Quick Migration をするためにはまずは、クラスターを構築しなくてはいけません。
ThinkPad は T60 と T61 を使って 3 ノード構成のクラスターを構築しているので、ここに ML115 G5 を追加させたいと思います。
# ML115 G5 は共有ディスクに接続済みです。

?

クラスターにノードを追加する前に [ノードの検証] を実行します。
すでにクラスターを構築しているノードと今回使用する ML115 G5 を選択して検証を実行してみます。

テスト項目としては全テストを実施するようにしています。

テストが終了するとレポートを表示することができるので、今回は CPU についてのレポートを確認してみたいと思います。
CPU については [同じプロセッサ アーキテクチャの検証] というテストで確認されるのですが、このテストではベンダーの
確認はしていないようです。
?

そのため、異なるベンダーの CPU を使っていてもクラスターを構築することは可能です。

SCVMM でも 4 ノードクラスターとして認識できています。
# クラスターとしてノード追加した後に追加したサーバーを最新の状態に更新すれば自動的にクラスター配下の
　 サーバーとして認識されます。

それでは、Live Migration と Quick Migration を実行していきたいと思います。

?

[SCVMM で Live Migration を実行]

Live Migration ですが、SCVMM とフェールオーバークラスターマネージャーで実行することができます。
まずは SCVMM で Live Migration を実行したいと思います。

• 今回、[2008R2-OWA-01] というゲスト OS を CSV 上に配置していますので、このゲスト OS であれば
  Live Migration をすることができます。
  # このゲスト OS は Intel の CPU の T61 で実行されています。
  対象のゲスト OS を右クリックして、[移行] をクリックします。
  ?
• T61 から ML115 に移行をしようとすると、異なる CPU ということで移行対象として選択することができないようになっています。
  [t61-01] に監視ては単純にメモリが足りていないので移行ができないのですが、[t61-02] に
  関しては Live Migration で
  移行可能なサーバーとして選択ができるようになっていますね。
  

SCVMM を使用している場合、異なるベンダーの CPU のホスト OS には移行ができないように制御がされていますね。

?

[フェールオーバー クラスター マネージャーで Live Migration を実行]

つづいて、クラスターの管理ツールで Live Migration を実行してみたいと思います。

• 管理ツールで ML115 に Live Migration を実行してみます。
  ?
• クラスターの管理ツールでも同様にエラーとなりますね。
  メッセージとしてはこちらの方がわかりやすい気がします。
  ?

異なるベンダーの CPU 間では Live Migration の実行はできないようですね。
続いて Quick Migration を試してみたいと思います。

?

[フェールオーバー クラスター マネージャーで Quick Migration を実行]

Quick Migration の実行ですが、Live Migration が可能な場合は SCVMM からは実行できないようです。
# ライブ移行しかできないようです。

Live Migration が実行できる環境で、Quick Migration を実行するためにはクラスターの管理ツールで実行する必要があります。

• ML115 に [クイック移行] をしてみます。
  
• 異なるベンダーの CPU を使用しているホスト間で Quick Migration を実行すると以下のエラーになります。
  Quick Migration は [保存→移動→開始] という流れになるのですが、この方法は使用できないようですね。
  [はい、仮想マシンをシャットダウンして移動します] をクリックするこちで [シャットダウン→移動→開始] という形で
  クラスターのノード間でゲスト OS を移行することが可能です。
  
• [はい、～] をクリックするとシャットダウンが開始され
  
• 他のノードに移動がされます。
  ?
• ここまでの操作は、[クイック移行] で試してみましたが、[仮想マシンの移動] を実行することでも、Quick Migration を
  実行することができます。
  
• 移動をするとゲスト OS が保存され、移動先として指定したノードに移動がされます。
  
• 保存された状態を復元するのですが、失敗します。
  
  

@IT の以下の記事では Quick Migration が成功することもあるということが書かれているのですが、私の環境では NG でした。
Hyper-V実践サーバ統合術 第4回

保存されたままでは、元のノードでしか起動できませんのでこの状態で他のノードで起動したい場合は、[保存された状態を破棄する] で
保存状態を破棄して、解除する必要があります。

異なるベンダーの CPU 間でゲスト OS を Live Migration / Quick Migration を実行することはできないみたいですね。
ゲスト OS の CPU に関してはこのような技術情報もあるようで
す。
Partition Properties

今回は GUI から実行してみましたが、Live Migration / Quick Migration はコマンドでも実行することができます。
次の投稿でコマンドから Live Migration / Quick Misgration を実行する方法をまとめてみたいと思います。

続いてはワークグループ環境でエンタープライズ アレイを構築する方法になります。

以下の環境が構築済みです。

[TMG-EMS-01] を EMS として構築しますので、このサーバーでは準備ツールを実行して、EMS に必要となる
役割 / 機能はインストール済みです。

今回もサーバー認証証明書とルート証明書が必要となります。

サーバー認証証明書は EMS にインストールをしますので、発行先を [TMG-EMS-01] として設定した証明書を作成済みです。
[TMG-EMS-01] にはルート証明書をインポートして、[TMG-01] [TMG-02] [TMG-03] の HOSTS には以下の設定がしてあります。
# サーバー認証証明書の作成、ルート証明書のインポート手順はスタンドアロン アレイと同じですので記載は省略しています。
　 ルート証明書に関しては、[TMG-01] [TMG-02] にもファイルコピー済みです。

[EMS のインストール]

セットアップウィザードを起動して、EMS のインストールを行います。

• [次へ] をクリックします。
  
• [使用許諾契約書に同意します] を選択し、[次へ] をクリックします。
  
• [次へ] をクリックします。
  ?
• [次へ] をクリックします。
  
• [この EMS に新しいエンタープライズ構成を作成] を選択し、[次へ] をクリックします。
  
• [次へ] をクリックします。
  
• エンタープライズ名を入力して、[次へ] をクリックします。
  
• [ワークグループ内に展開] を選択して、発行先を EMS のサーバー名にしたサーバー認証証明書を選択し、[次へ] をクリックします。
  パスワードは証明書のエクスポート時に指定したパスワードを入力します。
  # 発行先が EMS をインストールしているサーバー名でない証明書を使おうとするとエラーになることがありました。
  　 ならないこともあったのですが…。
  
• [インストール] をクリックします。
  
  
• [完了] をクリックします。
  

以上で、ワークグループ環境の EMS のインストールは完了です。

ISA 2006 でも同様の仕様だったのですが、ワークグループ環境では EMS のレプリカは設定することができません。

EMS を冗長構成で構築する場合はドメイン環境が必須になりますね。

[アレイに参加]

続いてエンタープライズにアレイ メンバーとしてサーバーを参加させます。
まずは、[TMG-01] をアレイに参加させたいと思います。操作は、[TMG-01] で実施します。

• [Forefront TMG の管理] を実行します。
• [Forefront TMG
  (<サーバー名>)] を右クリックして、[アレイへの参加] をクリックします。
  
• [次へ] をクリックします。
  
• [EMS サーバーによって管理されるアレイに参加します。] を選択して、[次へ] をクリックします。
  
• EMS のサーバー名を入力し、[ログオンしているユーザーの資格情報を使って接続する] を選択し、[次へ] をクリックします。
  今回も [Administrator] をミラーアカウントとして使用しています。
  
• ルート証明書を選択し、[次へ] をクリックします。
  
• [次へ] をクリックします。
  
• アレイの情報を入力して、[次へ] をクリックします。
  
• [完了] をクリックします。
  
• [OK] をクリックします。

同様の手順を [TMG-02] でも実施し、アレイに参加させます。

?

[アレイ内の資格情報の変更]

ワークグループ環境のスタンドアロン アレイと同様に、アレイ内の資格情報の変更を実施します。
手順はワークグループ環境の時と同じですね。

アレイを右クリックして、[プロパティ] を開いて設定を変更します。

?

システムポリシーの [ローカルの構成保管サーバーへのアクセス] に関しては有効にしないでも、サーバーの認識には問題は
なさそうでしたが、うまく認識できない場合はこのシステムポリシーを有効にすると解消できるかもしれません。

今回構築した環境の最終的な構成は以下のようになります。

考え方としてはスタンドアロン アレイと同じですので一度ワークグループ環境でスタンドアロン アレイが組めてしまえば、
それほど迷わずに構築できそうですね。

これで TMG を構築する際の基本的なパターンは大体構築することができたかと思います。
TMG では CSS をどうするかを考えるのが構築する際のポイントとなりそうですね。

証明書が作成できたのでスタンドアロン アレイを構築していきたいと思います。

今回はこの環境を作りたいと思います。

?

• アレイ マネージャーにはサーバー認証証明書と、ルート証明書。
• アレイメンバーにはルート証明書

が必要となりますので先ほどエクスポートしたファイルをコピーしておきます。

また、今回はサーバーの IP を DNS に登録していませんので、HOSTS で解決できるよう以下の設定をしています。
# IP は塗りつぶしています。

[アレイ マネージャーにルート証明書をインポート]

まずはアレイマネージャーにルート証明書をインポートします。

• ファイル名を指定して実行で [mmc] を実行します。
  
  
• [スナップインの追加と削除] で [証明書] を追加します。
  
  
• [コンピュータ アカウント] を選択して、スナップインを追加します。
  
  
• [信頼されたルート証明機関] を右クリックして、[すべてのタスク] → [インポート] をクリックします。
  
  
• [次へ] をクリックします。
  
  
• コピーしたルート証明書を選択し、[次へ] をクリックします。
  
  
• 証明書をすべて次のストアに配置するが [信頼されたルート証明機関] になっていることを確認し、[次へ] をクリックします。
  
  
• [完了] をクリックします。
  
  
• [OK] をクリックします。
  

これでルート証明書のインポートは完了です。

[アレイ マネージャーにサーバー認証証明書をインポート]

サーバー認証証明書は TMG の管理コンソールからインポートします。

• [Forefront TMG の管理] を実行します。
  
  
• [システム] でサーバーを選択し、[サーバー証明書のインストール] をクリックします。
  この操作をすることでアレイ マネージャーにするサーバーにサーバー認証証明書をインストーすることができます。
  
  
• コピーしたサーバー認証証明書を選択し、証明書のパスワードを入力します。
  今回はルート証明書は手動でインポートしているため、[このアレイ マネージャーに～] のチェックは外しています。
  # 証明書チェーンを使ってルート証明書ごとインストール方法がいまいちわかっていないですよね。
  

これでアレイ マネージャーの準備は完了です。

?

[アレイ メンバーをアレイに参加]

今回は [TMG-02] をメンバーにしていますので、[TMG-02] で参加させるための操作を実行します。
HOSTS の設定と、ルート証明書のファイルとしてのコピーは実施済みです。

ルート証明書のインポートはアレイを参加させる操作の中で実施できますので、手動でインポートする必要はありません。

• [Forefront TMG の管理] を実行します。
  
• [Forefront TMG (<サーバー名>)] を右クリックして、[アレイへの参加] をクリックします。
  
  
• [次へ] をクリックします。
  
  
• [指定したアレイ メンバー ～] を選択して、[次へ] をクリックします。
  
  
• アレイ マネージャーのサーバー名を入力して、[ログ尾インしているユーザーの資格情報を使って接続する] を選択し、
  [次へ] をクリックします。
  今回は [Administrator] のミラーアカウント (同一ユーザー名 / パスワード) のユーザーで作業をしていますので、
  この設定で認証することができます。
  今回は DNS に登録がないので、HOSTS ファイルに設定をしていないとサーバーに接続することができません。
  
  
• ルート証明書のファイルを選択して、[次へ] をクリックします。
  
  
• [完了] をクリックします。
  
  
• [OK] をクリックします。
  

これでスタンドアロン アレイの構成の基本部分は完了です。

?

[アレイ内の資格情報の変更]

最後にアレイ内の資格情報を変更します。

• [Forefront TMG の管理] を実行します。
  
• [Forefornt TMG (<アレイ名>)] を右クリックして、[プロパティ] をクリックします。
  
  
• [アレイ内の資格情報] タブを選択し、[次のアカウントを使用して認証する] を選択して、[アカウントの] をクリックします。
  ?
  
• 今回は、[Administrator] を設定しています。
  
  
• 後は TMG で設定を適用します。
  

以上で設定は完了です。

これでワークグループ環境でスタンドアロン アレイを構築することができます。

サーバー認証証明書の発行先がアレイ マネージャーのサーバー名になっていない場合、構成がエラーとなったままになります。
?

[警告] に [上位方向へのチェーン構成の資格情報] のエラー、[Forefront TMG で構成保管サーバーに接続できません。] の警告が
出力されていてエラーとなったまま場合、アレイマネージャーにインストールしたサーバー認証証明書の発行先を確認したほうが
よいかと思います。

最終的な構成はこのような形になっています。

証明書の作成さえできればそれほど構築は難しくないみたいですね。
私は証明書が苦手なのでここまで来るのに結構時間がかかってしまいましたが…。

ISA 2006 のワークグループ環境もこのような方法で構築ができるはずです。
# ワークグループ環境は証明書を使って構築するはずだったので。

証明書を使用するとワークグループ環境で EMS を使用したエンタープライズ アレイを構築することも可能です。

エンタープライズ アレイに関しては次の投稿でまとめてみたいと思います。

ワークグループ環境の TMG のアレイ構成の構築方法が大体わかってきましたのでまとめてみたいと思います。

ワークグループ環境でも [スタンドアロン アレイ] / [エンタープライズ アレイ] を構築することが可能です。
ただし、ドメイン環境と異なり [証明書] が必要となります。

証明書は

• サーバー認証証明書
• ルート証明書 (サーバー認証証明書に署名した証明機関の証明書)

の 2 種類が必要となります。

サーバー認証証明書はアレイ マネージャーに、ルート証明書はアレイに参加するメンバーサーバーに導入します。
# ルート証明書はアレイ マネージャーにもインストールする必要があります。

これらの証明書は Active Directory 証明書サービス (AD CS) で作成することができますので、検証には AD CS で
発行された証明書を使うのが楽だと思います。

その 1 として証明書の作成手順をまとめていきたいと思います。
この証明書の作成手順ですが、ワークグループ環境のエンタープライズ アレイでも同様の方法を利用することができます。

[AD CS のインストール]

• AD CS のインストールは、[サーバー マネージャー] で [Active Directory 証明書サービス] をインストールします。
  
  
• 証明書の要求をするため、[証明機関 Web 登録] の役割を追加して機能をインストールしておきます。
  
  
• 今回はワークグループ環境ですので、[スタンドアロン] のみ選択ができるようになっています。
  
  
• あとは、[ルート CA] として設定し、それ以降の設定はデフォルトのままインストールをします。
  
  

これで以下の環境が構築できた状態になっています。
# 実際のサーバー名もこちらの図の内容となっています。

インストールが終わったら、[証明機関 Web 登録] でサーバー認証証明書を発行できるように IIS を設定します。

[IIS の設定]

Web ベースで証明書を発行するため、IIS で SSL の設定を行います。
HTTP 経由で証明書発行用のサイトにアクセスすると以下のメッセージが表示され、証明書要求を発行することができません。

IIS 7.0 以降は自己署名証明書が簡単に作れるので、この機能を使って SSL が使用できるようにします。

• まずは、[IIS マネージャー] を実行します。
  
  
• サーバー名を選択し、[サーバー証明書] をダブルクリックします。
  
  
• [自己署名入り証明書の作成] をクリックします。
  # 一番上に表示されている証明書はルート証明書になりますがこちらは使うことができません。
  ?
  
• 証明書のフレンドリ名を入力して、[OK] をクリックします。
  
  
• 自己署名証明書が作成されていることが確認できますね。
  
  
• あとは、証明機関 Web 登録で使用しているサイトで SSL を有効にします。
  [Default Web Site] を選択して、[バインド] をクリックします。
  
  
• [追加] をクリックします。
  
  
• 種類で [https] を選択し、[SSL 証明書] で先ほど作成した、自己署名証明書を選択して、[OK] をクリックします。
  

以上で SSL の設定は完了です。

[https://localhost/certsrv] にアクセスして証明機関 Web 登録にアクセスします。

?

[サーバー認証証明書の作成]

• 自己署名証明書のため、URL にアクセスするとセキュリティ警告が発生しますが、[このサイトの閲覧を続行する] をクリックして
  サイトを開きます。
  
  
• [証明書を要求する] をクリックします。
  
  
• [証明書の要求の詳細設定] をクリックします。
  
  
• [この CA への要求を作成し送信する。] をクリックします。
  ?
  
• メッセージボックスが表示されたら、[はい] をクリックします。
  
  
• 後は証明書に必要な情報を入力します。
  

  最低限必要なのは [名前] と [証明書の種類] と [エクスポート可能なキーとしてマークする] の 3 つの設定です。
  各項目は以下のように設定します。

  • 名前
    アレイマネージャーとして設定するサーバー名を入力します。
    今回の場合は、[TMG-01] と設定しています。
    
  • 証明書の種類
    サーバー認証証明書を選択します。
    
  • エクスポート可能なキーとしてマークする
    チェックを有効にしてエクスポートができるようにします。
• 入力が終わったら [送信] をクリックします。
  
• 証明書を発行するため、[管理ツール] → [証明機関] をクリックします。
  
  
• [保留中の要求] を選択すると先ほど送信した証明書がありますので、[すべてのタスク] → [発行] をクリックします。
  
  
• ブラウザに戻ってトップページの [保留中の証明書の要求の状態] をクリックします。
  
  
• [サーバー認証証明書] をクリックします。
  
  
• [はい] をクリックします。
  
  
• [この証明書のインストール] をクリックします。
  

これでサーバー内にサーバー認証証明書がインストールされました。
あとは、このサーバー認証証明書とルート証明書をアレイ マネージャー / アレイ メンバーで使用できるようにエクスポートします。

[サーバー認証証明書のエクスポート]

インストールしたサーバー認証証明書は [ユーザー アカウント] の [個人] ストアに格納されています。
この証明書をエクスポートして他のサーバーで使用できるようにします。

• ファイル名を指定して実行から [mmc] を実行します。
  
  
• [スナップインの追加と削除] で [証明書] を追加します。
  
  
• ? [ユーザー アカウント] を選択して、[完了] をクリックします。
  
  
• スナップインを追加して、[OK] をクリックすると、証明書ストアが表示されます。
  先ほどインストールした証明書が [個人] → [証明書] の下にありますので、右クリックして [すべてのタスク] → [エクスポート] を
  クリックします。
  
  
• [次へ] をクリックします。
  
  
• [はい、秘密キーをエクスポートします] を選択して、[次へ] をクリックします。
  
  
• [次へ] をクリックします。
  
  
• パスワードを設定して、[次へ] をクリックします。
  
  
• エクスポートする場所を選択して、[次へ] をクリックします。
  
  
• [完了] をクリックします。
  
  
• [OK] をクリックします。
  

以上でサーバー認証証明書のエクスポートは完了です。

証明書作成の最後の手順としてルート証明書をエクスポートします。

?

[ルート証明書のエクスポート]

最後の手順はルート証明書のエクスポートです。

• [管理ツール] → [証明機関] をクリックします。
  
• 証明機関を右クリックして、[プロパティ] をクリックします。
  
  
• CA 証明書の [証明書の表示] をクリックします。
  
  
• [詳細] タブの [ファイルにコピー] をクリックします。
  
  
• [次へ] をクリックします。
  
  
• [次へ] をクリックします。
  
  
• エクスポートする場所を設定し、[次へ] をクリックします。
  
  
• [完了] をクリックします。
  
  
• [OK] をクリックします。
  

以上で、証明書の作成は完了です。

次はこの証明書を使ってスタンドアロン アレイを構築したいと思います。

続いて作成した EMS に TMG サーバーをアレイを作成して参加させます。

現在は、以下のような環境になっているので、まずは、[TMG-01] をアレイに参加させたいと思います。

[アレイに参加]

TMG-01 に EMS サーバーの [ローカル Administrators グループ] に登録されているドメインユーザーでログオンした状態で
作業を開始しています。

1. [Forefront TMG の管理] を実行します。
   
2. [Forefornt TMG (<サーバー名>)] を右クリックして、[アレイへの参加 ]をクリックします。
   
3. [次へ] をクリックします。
   
4. [EMS サーバーによって管理されるアレイに参加します。] を選択し、[次へ] をクリックします。
   
5. EMS のサーバー名を入力し、[次へ] をクリックします。
   今回はドメインユーザーでログオンしているので、[ログオンしているユーザーの資格情報を使って接続する] を選択しています。
   
6. まだ、アレイを作成していないので [EMS で管理れされる新しいアレイを作成します。] を選択して、[次へ] をクリックします。
   アレイにかんしては参加のウィザード内または、EMS で TMG の管理コンソールを実行して事前に作っておくことも可能です。
   
7. 作成するアレイの [アレイ名 ]と [DNS 名] を入力して、[次へ] をクリックします。
   # [アレイ名] [DNS 名] はあとで変更することが可能です。
   
8. [完了] をクリックします。
   
   完了をクリックするとアレイが作成され、作成後にアレイにサーバーが参加されます。
   
   
9. [OK] をクリックします。
   

以上で、アレイの作成と参加が完了です。
同様の作業を [TMG-02] でも実施し、アレイにサーバーを参加させます。

1 台目と 2 台目のインストールの違いというと、すでにアレイが作成されている状態ですので、既存のアレイに参加するという形で
導入ができるというところだけで後の操作は 1 台目と同じです。

?

[アレイ参加後の環境]

アレイ参加後のサーバーの状態を確認してみます。

アレイが作成され、参加した TMG サーバーが正常に稼働していることが確認できますね。
# 新規に参加させた TMG サーバーの状態が変わらない場合、一度 TMG の管理コ
ンソールを起動しなおすと状態が変わることがあります。

構成としては以下のような状態となっています。
?
アレイに参加したサーバーでは AD LDS が停止されるので、ディレクトリのマークが消えています。

エンタープライズ アレイの構成では、EMS が CSS を持つようになるので EMS 以外役割のサーバーでは参加したタイミングで
AD LDS が停止された状態となります。

[エンタープライズ アレイ構築後の設定変更]

エンタープライズ アレイ構築後にいくつか設定変更が必要となりますので、それらをまとめてみたいと思います。

1. [代替構成保管サーバー] の設定
   今回の環境では、EMS が 2 台構築された状態となっています。
   EMS の環境では構成保管サーバーの冗長化として、[代替構成保管サーバー] というものが設定できます。

   代替構成保管サーバーは [Forefront TMG (<アレイ名>)] を右クリックして、[プロパティ] を開くことで設定できます。
   # アレイの名称や、DNS 名もこのプロパティから変更できます。
   

   デフォルトの状態では、代替構成保管サーバーがブランクになっていますので、2 台目の EMS を設定します。
   
   

   TMG も ISA 同様、変更は適宜適用する必要があります。
   # 今回の手順では一つの作業を終わるごとに適用しています。
   

2. [構成保管サーバーのレプリケーション] の設定
   今回の EMS は 2 台構成になっています。
   今までの画面は、[TMG-EMS-01] で表示していたものなので、[TMG-EMS-02] でも管理ツールを開いてみたいと思います。

   [構成] と [システム] でアレイ内のサーバーがうまく認識できていないですね。
   ?
   

   この状態ですが、[システム ポリシー] の設定が影響しているようです。
   [システム ポリシー] ですが、[ファイアウォール ポリシー] を右クリックすることで表示することが可能です。
   ?

   システム ポリシーの中に、[構成保管サーバーのレプリケーション] というポリシーがあり、デフォルトでは有効になっていません。
   ?

   このポリシーを有効にします。
   ?

   [宛先] のタブを見ると、[構成保管サーバーのレプリケーション] という宛先があるので、これを [編集] で開いてみます。
   

   デフォルトでは何も設定がされていません。
   ?

   [追加] をクリックして、EMS サーバーを登録します。
   # 今回は [コンピューター] で各 EMS サーバーを登録しています。
   

   設定が終わったら適用をします。
   各サーバーに構成の反映が終わったタイミングで、[TMG-EMS-02] の管理コンソールでサーバーの状態を確認します。
   

   [構成保管サーバーのレプリケーション] を設定することで、追加した EMS サーバーの [システム] の [サーバー] の状態が
   確認できるようになります。
   ?

3. [ローカル構成保管サーバーへのアクセス] の設定
   追加した EMS サーバーで、[サーバー] の状態は確認できるようになったのですが、[構成] の情報に関しては、
   エラーが表示されています。
   ?

   この状態を回避するためには、[システム ポリシー] で [ローカル構成保管サーバーへのアクセス] を有効にします。
   デフォルトではこのポリシーは無効になっています。
   ?

   ポリシーを有効にして適用します。
   

   この設定をすることで、追加した EMS サーバーで構成を正常に確認することができるようになります。
   

以上でエンタープライズ アレイの構築は完了です。

構成としては ISA 2006 の CSS をレプリカした構成と同じなのですが、ISA 2006 とは異なり構成をレプリカするためには、
EMS が必要となりますので、単一障害点をなくすためには都合 4 台のサーバーが必要となりそうです。

TMG 2010 になって大きく変わった点だと思うのですが、情報があまりなく今回の投稿をまとめるのにも一苦労でした…。