Edge on TMG (TMG と Exchange エッジ トランスポートの共存環境) を Exchange 2010 SP1 で構築するための方法をまとめてみたいと思います。

今回は以前構築した Exchange 2010 RU4 + TMG 2010 SP1 の環境を使用しいます。

 

■エッジ トランスポートに Exchange Server 2010 SP1 を適用

まずは、Exchange Server 2010 SP1 を適用してます。

1. Exchange Server 2010 SP1 を実行します。
   
2. [アップグレード用 Exchange 言語オプションの選択] をクリックして、言語オプションを選択します。
   
   言語オプションの選択ですが、[DVD に含まれる言語のみをアップグレードする] を選択してアップグレードをしようとすると以下のメッセージが表示され、失敗となります。
   
   

   言語パックは、現在のサーバーにインストールされており、Exchange バイナリでアップグレードする必要があります。 アップグレード操作で言語バンドルを指定してください。 ヘルプを参照するにはここをクリックしてください… http://technet.microsoft.com/ja-JP/library/ms.exch.err.default(EXCHG.141).aspx?v=14.1.218.11&e=ms.exch.err.Ex28883C&l=0&cl=cp

   アップグレードの場合、[DVD に含まれる～] は使えないようですので以下のURL から言語パックバンドルをダウンロードして、[言語バンドルからすべての言語をアップグレードする] を使用して、言語オプションを指定するようにします。
   Microsoft Exchange Server 2010 SP1 言語パック バンドル

   

3. 言語オプションの選択が終了したら、[Microsoft Exchange Server アップグレードのインストール] をクリックします。
   
4. [次へ] をクリックします。
   
5. [使用許諾契約書に同意します。] を選択して、[次へ] をクリックします。
   
6. 前提条件のチェックが実行されます。
   エッジ トランスポートと TMG が共存している場合、以下のエラーが発生します。
   
   

   ‘IsaManagedCtrl’ () プロセス (ID: 3256) で開かれているファイルがあるため、アップグレードを続行できません。 プロセスを閉じてセットアップを再起動してください。 ヘルプを参照するにはここをクリックしてください… http://technet.microsoft.com/ja-JP/library/ms.exch.err.default(EXCHG.141).aspx?v=14.1.218.11&e=ms.exch.err.Ex28883C&l=0&cl=cp

   [IsaManagedCtrl] ですが、[Microsoft Forefront TMG Managed Control] サービスになります。
   インストール時にはこのサービスを停止した状態にしておきます。
   

   サービスが停止した状態であれば、前提条件のチェックはすべて完了します。
   

7. [アップグレード] をクリックしてアップグレードを実行します。
   
8. アップグレードが完了したら、[終了] をクリックします。
9. 再起動後に、[Microsoft Forefront TMG Managed Control] サービスを開始しようとしたところ以下のエラーが発生してしまい、サービスを起動することができませんでした…。
   

   サーバーを再起動しても状況は変わらず、TMG 2010 の管理コンソールを確認すると、[電子メール ポリシー] でエラーが発生してしまっています。
   

 

TMG 2010 SP1 ですが、Exchange 2010 SP1 には対応していないバージョンとなっています。
Exchange 2010 SP1 に対応させるためには TMG 2010 SP1 RU1 を適用する必要があります。

Forefront TMG 2010 Service Pack 1 用のソフトウェア更新プログラム 1

■TMG 2010 SP1 RU1 の適用

TMG 2010 SP1 RU1 をダウンロードして適用し、Exchange 2010 SP1 に対応させてみたいと思います。

1. TMG 2010 SP1 RU1 を実行してインストーラーを起動します。
2. [次へ] をクリックします。
   
3. [使用許諾契約書に同意します] を選択し、[次へ] をクリックします。
   
4. [次へ] をクリックします。
   # 今回は TMG の管理者としてログオンしているので、ログオンユーザーで接続が可能です。
   
5. [インストール] をクリックして、SP1 RU1 を適用します。
   
   
6. [完了] をクリックします。
   
7. [はい] をクリックしてサーバーを再起動します。
   

以上で SP1 RU1 の適用は完了です。

 

[Microsoft Forefront TMG Managed Control] サービスも起動して、[電子メール ポリシー] のエラーも出力されなくなっています。
# [Microsoft Forefront TMG Managed Control] サービスは手動起動しないとちょっと調子悪かったりしましたが…。

Exchange 2010 の現時点の最新版は Exchange 2010 SP1 RU1 ですが、このバージョンでも [電子メール ポリシー] は起動しました。
Exchange Server 2010 Service Pack 1 用の更新プログラムのロールアップ 1 (KB2407028)

 

Edge on TMG を Exchange 2010 SP1 で構築する場合、TMG を SP1 RU1 にしないと正常に機能が起動しないので注意する必要がありそうです。

SQL Server 2008 はスリップストリームインストールで Service Pack と Cumulative Update を同時にインストールすることが可能です。

ただし、SP1 最新のSQL Server 2008 SP1 CU8 をスリップストリームインストールしようとすると以下のエラーが発生します。

この情報については、以下の技術情報に記載されています。
SQL Server 2008 のインストールを更新またはスリップストリームする方法

この技術情報の中に、[必要な属性 ‘Path’ が見つかりません。] のエラーが表示された場合の対処方法が記載されています。
# このエラーの発生は、[累積的な更新プログラム パッケージ 8 以降] となっていますが、これは SP1 RU8 以降が対象となります。

回避方法としては以下の方法が記載されています。

方法 1 累積的な更新プログラム パッケージを抽出した場所 CU8<CPU>setupsqlsupport.msi から、特定のアーキテクチャに対する SQL サポート .msi ファイルを手動でインストールします。 方法 2 ローカル フォルダーからセットアップを開始する前に、オプション 2 の手順 4. で示されているファイルに加えて、次の手順で示されているファイルをコピーする必要があります。ファイルをコピーするには、以下の手順を実行します。 Microsoft.SQL.Chainer.Package.dll ファイルを、RTM フォルダーから、<メディア><アーキテクチャ フォルダー> フォルダーのローカル コピーにコピーします。 Sqlsupport.msi ファイルをコピーします。次の最初の場所から、2 番目の場所のローカル コピーに、ファイルをコピーします。 C:<kb_number_of_hotfix package><アーキテクチャ>setupSqlsupport.msi <メディア><アーキテクチャ フォルダー>setup

簡単に書いてしまうと CU8 のインストーラーに同梱されているサポートツールをインストールしてから、スリップストリームインストールを実行するということが書かれています。

サポートツールは [Setup] ディレクトリ内に各言語別に用意されているのですが、CU8 のインストーラーには 1041 (日本語) のセットアップツールが含まれていません…。
# 1031 は英語用のディレクトリになります。

英語用のディレクトリ内にある、[sqlsupport.msi] をインストールすれば、SP1 CU8 をスリップストリームインストールできるようになるのですが、セットアップが英語になってしまいます…。

英語のサポートツールをインストールしても、インストールされる SQL Server の LCID は [1041] で、[SqlCharSetName] は [cp932] となっているのですが。

 

日本語のセットアップツールを使ってスリップストリームインストールしたい場合は、現状は SP2 のサポートツールをインストールしてからスリップストリームインストールすることでエラーが発生しなくなります。

まずは、SP2 のインストールモジュールを展開します。
展開に使用するコマンドは以下のような形式になります。

c:tempSP2SQLServer2008SP2-KB2285068-x64-JPN.exe /extract:c:SP2

展開が終わったら、 [x64setup1041sqlsupport.msi] を実行して SP2 のサポートツールをインストールします。

 

サポートツールのインストールが終了したら通常のスリップストリームインストールの方法と同じ形式でコマンドを実行してインストールを行います。

setup.exe /PCUSource="C:SP1" /CUSource="C:SP1CU8"

SP2 のサポートツールであれば、SP1 CU8 をスリップストリームインストールすることが可能です。

SP2 は最近リリースされたものなので、この方法も最近になって使えるようになったものですが…。
SP2 がリリースされている状態で SP1 CU8 を新規にインストールする機会は少ないかもしれませんがメモとして。

2010/10/3 追記

CU には以前から英語のセットアップサポートツールしか含まれていないですね。
全言語用のサポートツール入れていたらかなりのサイズになってしまうので、現在のモジュール構成は納得。

Exchange Server 2010 のエッジ トランスポートサーバーと Threat Management Gateway (TMG) 2010 は共存することが可能になっています。

TMG 2010 では [電子メール ポリシー] という設定があります。

上記のダイアログにも表示されているようにこの機能を使用するためには Forefront Protection 2010 for Exchange (FPE) と Exchange のエッジ トランスポートサーバーをインストールしている必要があります。

この構成は以下の 3 種類のソフトで構成されます。

1. Exchange Server 2010 エッジ トランスポート
2. Forefront Protection 2010 for Exchange Server
3. Forefront Threat Management Gateway 2010

 

自宅の検証環境にも TMG とエッジ トランスポートは構築されているのですが、常時起動しているサーバーで起動するにはリソースが足りていないので、複数の物理サーバーで実行しています。

検証環境のサーバー増強で一台でTMG とエッジを実行できる環境を構築できそうなので、この環境の構築方法をまとめてみたいと思います。
# メモリが 2GB はないと検証環境として動かすのも少し厳しいかと。 AD LDS が 2 インスタンス、SQL Server Express、TMG、Exchange 2010 が動作しますので。

 

FPE に関してはオプションではなく必須コンポーネントとなっています。
エッジ トランスポート + TMG の構成で電子メール アドレスポリシーを設定しようとしても以下のエラーとなり、電子メール ポリシーが動作しません。

■Exchange 2010 エッジ トランスポートのインストール

まずは、エッジ トランスポートをインストールします。
Exchange 2010 の現時点の最新版は、[Exchange Server 2010 SP1] となっています。

最近、[TMG 2010 SP1 Software Update 1] の提供が開始されました。
Software Update 1 for Microsoft Forefront Threat Management Gateway (TMG) 2010 Service Pack 1

こちらの Overview に以下の記載があります。

• Support for Exchange 2010 SP1

あまり意識していなかったのですが、 Update 1 から Exchange 2010 SP1 をサポートとなっています。
Update 1 に関しては、現時点では日本語版の提供がされていません。

そのためエッジ トランスポートに関しては Exchange 2010 RU4 で構築をしています。

エッジ トランスポートのインストールに関しては通常のインストールと変わりませんのでインストール手順の概要のみ記載しておきます。

1. システムのプロパティを開き、[このコンピューターのプライマリ DNS サフィックス] を設定します。
   
2. コマンドプロンプトで以下のコマンドを実行して必要となる機能をインストールして、再起動します。
   
   

   ServerManagerCmd ?ip D:ScriptsExchange-Edge.xml

3. Exchange 2010 のセットアップを起動してエッジ トランスポートの役割をインストールします。
   
   
4. Exchange 2010 RU4 をインストールします。
   Exchange Server 2010 用の更新プログラムのロールアップ 4 (KB982639)
   
   

 

■Forefront Protection 2010 for Exchange のインストール

 

次に FPE をインストールします。
Exchange 2010 のインストーラーを起動すると FPE 2010 のインストールというメニューがあります。

これをクリックすると、Download Center の FPE のダウンロードサイトが開きます。

TMG のインストーラーにも FPE のインストールメニューがあります。

こちらをクリックすると、FPE のインストールが開始されます。

TMG のインストーラーには FPE のインストールモジュールが含まれていますので、FPE をインストールする場合にはこちらを使った方が楽かと。

FPE のインストールも通常のインストールと同じですので概要を。

1. FPE のインストールを実行します。
   
   

 

 

■Threat Management Gateway 2010 のインストール

 

最後に TMG をインストールします。

こちらもインストールの概要を。

1. [準備ツールの実行] をクリックして、TMG に必要な役割/機能をインストールします。
   
   

   今回はアレイ構成ではないので、[Forefront TMG のサービスと管理] を選択しています。
   

2. TMG のインストールを開始します。
   
   
   
   
3. TMG 2010 SP1 をインストールします。
   Microsoft Forefront Threat Management Gateway (TMG) 2010 Service Pack 1
   
   

以上で、Exchange 2010 のエッジトランスポートと TMG の共存環境の構築は完了です。

インストールですが、

1. Forefront Threat Management Gateway 2010
2. Exchange Server 2010 エッジ トランスポート
3. Forefront Protection 2010 for Exchange Server

の順番でも構築することは可能です。

FPE は、Exchange を保護するものになりますので、エッジ トランスポート導入後にインストールする必要がありますが。

 

 

通常であればエッジトランスポートの受信/送信コネクタは [Exchange Management Console] から作成することになりますが共存環境で電子メール ポリシーを有効にすると、TMG の管理コンソールで設定をすることになるようです。

電子メールのゲートウェイとして使用できるようにするための設定は別の投稿でまとめたいと思います。

ちょっと検証で、SQL Server 2008 R2 の環境を作ったり壊したりしていました。

GUI からセットアップするのもちょっと面倒なので、コマンドでインストールするためのコマンドラインを。

 

■SQL Server 2008 R2 をコマンドでインストール

SQL Server 2008 R2 をコマンドでインストールするためにはコマンドプロンプトから [Setup.exe] を実行します。
インストールのオプションに関しては、[Setup.exe /?] か Books Online で [コマンド プロンプトから SQL Server 2008 R2 をインストールする方法] を検索すると調べることが可能です。

コマンドプロンプトからのインストールはシステム データベースの再構築でも使うのですが、普段はそれほど実行する機会はないですよね…。

以下のコマンドで、SQL Server のデータベースエンジン部をインストールすることが可能です。
# WordPress だと改行が微妙なので、オプション単位で改行していますが一行で。

setup.exe  /QS /IACCEPTSQLSERVERLICENSETERMS /INSTANCENAME=SQL2008R2 /ACTION=INSTALL /FEATURES=SQL /SQLSVCACCOUNT="SYSTEM" /SQLSYSADMINACCOUNTS="Administrators" /AGTSVCACCOUNT="SYSTEM" /SQLCOLLATION="Japanese_XJIS_100_CI_AS" /SQLUSERDBDIR="F:Data" /SQLUSERDBLOGDIR="G:Log" /SQLTEMPDBDIR="E:Data" /SQLTEMPDBLOGDIR="E:Log" /AGTSVCSTARTUPTYPE="Automatic"

 

SQL Server のインストールは構成ファイルでも実行することができるので、以下のような構成ファイルからも実行できます。

[SQLSERVER2008] IACCEPTSQLSERVERLICENSETERMS=TRUE INSTANCENAME=SQL2008R2 ACTION=INSTALL FEATURES=SQL SQLSVCACCOUNT="SYSTEM" SQLSYSADMINACCOUNTS="Administrators" AGTSVCACCOUNT="SYSTEM" SQLCOLLATION="Japanese_XJIS_100_CI_AS" SQLUSERDBDIR="F:Data" SQLUSERDBLOGDIR="G:Log" SQLTEMPDBDIR="E:Data" SQLTEMPDBLOGDIR="E:Log" AGTSVCSTARTUPTYPE="Automatic"

 

この構成ファイルを使うようにセットアップを実行すると、インストールを自動化することができます。
構成ファイルを使う場合、セットアップは以下の形式で実行します。

setup.exe /QS /ConfigurationFile="H:InstallConfigConfig.ini"

 

構成ファイルに関しては GUI のインストールでも使用できます。
セットアップの [詳細設定] で [構成ファイルに基づくインストール] をクリックして構成ファイルを選択することで使用可能です。

ただし、GUI から構成ファイルを使用したセットアップでは自動化されません。
構成ファイルに設定した内容がデフォルトで選択された状態になってインストールをすることができます。

検証で環境を作り直したりする場合は、コマンドで実行するのが楽でよいですね。

ドメイン環境の Windows にはログオンキャッシュがあり、設定に関してはグループポリシーで設定することが可能になっています。
デフォルトの状態では、[ローカル セキュリティ ポリシー] で 10 ログオン分保存されるようになっています。

このログオンキャッシュがどこに保存されているんだろうと思って少し調べてみました。

■ログオンキャッシュの保存先を検証

ログオンキャッシュですが、[LSA : ローカル セキュリティ 機関] に保存されているようです。

Windows のレジストリの、[HKLMSECURITY] ですが、デフォルトの状態では Administrators グループのユーザーでもレジストリを展開できないようになっています。

これは、[SECURITY] のキーのアクセス許可で [Administrators グループ] には読み取りの権限がついていないため、このような表示となっています。
# デフォルトでは、SYSTEM にフルコントロール、Administrators グループは特殊なアクセス許可となっています。

[読み取り] または、[フル コントロール] のアクセス許可を明示的に設定することで、レジストリにアクセスすることが可能です。
# 試すときは自己責任でお願いいたします。

SECURITY キーが展開になると、[Cache] というキーが確認できます。

上の画像では、[NL$3] に値が設定されていることが確認できます。 
# ちょっと強引に値を消したりした環境なので、[NL$1] から始まって居ません…。

ここで、ネットワークに接続されていない状態にして、

一度ログオフして、ドメインユーザーでログオンしてみます。

ネットワークに接続されていない状態ですが、ログオンキャッシュを使ってログオンが可能な状態となっています。

こちらのブログで書かれている、[whoami /fqdn] でログオンキャッシュが使われているかを確認してみます。
# いつも参考にさせていただいている、Always on the clock というブログになります。

参考）
キャッシュされたログオン

ネットワークに接続していないため、ログオンキャッシュが使われエラーとなっていることが確認できます。

このことから現在は、ログオン情報がキャッシュとして残っていることが確認できました。

それでは、先ほどの [NL$3] の情報を [0 でクリア] してみたいと思います。
# 初期の状態と合わせ、一度内容を消して [00A7] まで 0 クリアしています。

[クリア前]

[クリア後]

0 クリアしたら再度ログオフ→ログオンをしてみます。

ログオンすることができなくなっていることが確認できます。

ログオンキャッシュについては [HKLMSECURITYCache] に保存されているみたいですね。

ちょっと気になったので簡単ではありますが調べてみました。
# 通常、手動でアクセスする必要のない [SECURITY] キーにアクセスをしていますので本内容を自分でも試してみようと思われた方は自己責任でお願いいたします。