XP モードといえば Windows Virtual PC の仮想アプリケーションの公開機能を使用して、Windows 7 上で XP で
動作するアプリケーションを実行する機能になります。

この機能、ゲスト OS として Windows Vista を使っている場合でも動作します。
でも Vista モードとは言わないでんしょうね。

■仮想アプリケーションの公開機能が使用できるゲスト OS

Tech Ed の資料によると以下の OS をゲスト OS として使用した場合、仮想アプリケーションの公開機能を使用することができるそうです。

• Windows XP SP3 Professional
• Windows Vista Enterprise / Ultimate
• Windows 7 Enterprise / Ultimate

今回は Vista Enterprise Editon SP2 の環境を使用して検証したいと思います。

■統合コンポーネントをインストール

仮想アプリケーションを公開するためには Windows Virtual PC の統合コンポーネントをゲスト OS にインストールする必要があります。
実際に統合コンポーネントをインストールする際に表示される画面が以下になります。

Tech Ed の資料に記載されている OS が記載されていますね。
残念ながら Windows 2000 は統合コンポーネントがインストールできませんので、仮想アプリケーションの公開機能は
使用することができません。

■更新プログラムのインストール

統合コンポーネントのインストールが終わると以下の画面が表示されます。

[完了] をクリックすると以下の URL にアクセスされます。

RemoteApp? を有効にするための WindowsR Vista SP1 以降用の更新プログラム

統合コンポーネントだけでなく、更新プログラムの適用が必要になるようですね。
この更新プログラムをダウンロードしてインストールします。

■仮想アプリケーションの公開

統合コンポーネントと更新プログラムのインストールが終了したら再起動し、いよいよ仮想アプリケーションの公開です。
上記 2 つのインストールが完了すると、自動公開が有効になります。

Vista の場合は
– [C:ProgramDataMicrosoftWindowsStart Menu]
にショートカットを配置することで、インストールしなくても仮想アプリケーションとして公開することができます。

今回は IE を公開してみました。

なんとなく Windows Vista Mode というゲスト OS 名にしています。
Internet Explorer が表示されていることが確認できます。
他のものに関しては、明示的に追加したものではないのですが、自動公開を有効にしたタイミングで表示されたものになります。

IE を起動すると Vista の IE7 が起動します。

?

■自動ログオンの設定

必要に応じて自動ログオンの設定を。
自動ログオンを有効にして仮想アプリケーション使用時のダイアログは消せなかったんですよね。

自動ログオンを有効するには、以下の技術情報の操作を行います。
自動ログオンを有効にする

[control userpasswords2] を実行して、[ユーザーがこのコンピュータを使うには、ユーザー名とパスワードの入力が必要] を
無効にします。
?
あとは自動ログオンに使用するユーザー情報を設定します。

?

現在、MED-V のクラスターモードの検証中なのですが息抜きに Vista の仮想アプリケーション公開を試してみました。

MED-V の企業利用を想定し設定を検討した内容を投稿していきたいと思います。

初回はエンタープライズ向けの製品を利用する場合の必須検討項目である冗長構成について調べてみました。
# Twitter でつぶやいたきりまとめていなかったので。

本当は実際に冗長化の構成まで組んでみたいのですが、明日 MCP を受験するためこれから追い込みで
勉強しなくてはいけないので今回は冗長化構成の検討までで。

TechNet に MED-V の冗長化について記載されています。
Configuring the MED-V Server in Cluster Mode

■MED-V の構成情報について

MED-V の構成情報ですがデータベースやバイナリデータではなく、XML ファイルが使用されています。

XML ファイルは

– [C:Program FilesMicrosoft Enterprise Desktop VirtualizationServers]
– [C:Program FilesMicrosoft Enterprise Desktop VirtualizationServersConfigurationServer]

の 2 個所に格納されています。

[Servers] 直下の XML ファイルが MED-V サーバーの構成、[ConfigurationServer] の XML ファイルがワークスペースの
設定情報になるようです。

ワークスペース用の設定情報の格納場所に関しては、[ServerConfiguration.xml] の [StorePath] に指定がされており、
デフォルトではインストールディレクトリ内の [Configuration] ディレクトリが設定されています。

この設定を共有ディレクトリに変更することで、ワークスペースの設定情報を複数のサーバーで共有できるようになります。

MED-V の構成情報や、ゲスト OS のイメージは暗号化されている個所があるようなので、冗長構成をとる各サーバーで、
同一の [KeyPair.xml] を使用する必要もあるようですね。
KeyPair.xml の内容が正しくないと、[MEDV Server] サービスが起動できないようです。

この xml はファイルが存在していない場合、サービスの起動時に自動生成されるようなのですが、一度リネームをして
とっておいたファイルをサービスの起動時に生成されたファイルと置き換えたらサービスが起動できなくなりました…。

MED-V で実行されるゲスト OS の仮想ハードディスクですが、[VHD] ではなく [EVHD] というファイルになるんですよね。

[Encrypted Virtual Hard Disk] という暗号化された VHD が使用されているのですがこの復号化と KeyPair.xml の
関連性も気になります。

■MED-V の冗長構成

MED-V の冗長構成は WSFC ではなく NLB で実現することになりそうです。
レポート用のデータベースの配置場所が悩ましいところですが。

冗長化を考えると以下のような構成になると思います。

 

MED-V で使用されるイメージファイル (ゲスト OS のイメージ) も共有ディレクトリに配置させる必要があるかと。
IIS で UNC 共有を使用した仮想ディレクトリを使用する必要があるのかなと考えています。

実際の冗長化された構成の構築に関しては次回検証したいと思います。

MED-V の企業利用を想定し設定を検討した内容を投稿していきたいと思います。

初回はエンタープライズ向けの製品を利用する場合の必須検討項目である冗長構成について調べてみました。
# Twitter でつぶやいたきりまとめていなかったので。

本当は実際に冗長化の構成まで組んでみたいのですが、明日 MCP を受験するためこれから追い込みで
勉強しなくてはいけないので今回は冗長化構成の検討までで。

TechNet に MED-V の冗長化について記載されています。
Configuring the MED-V Server in Cluster Mode

■MED-V の構成情報について

MED-V の構成情報ですがデータベースやバイナリデータではなく、XML ファイルが使用されています。

XML ファイルは

– [C:Program FilesMicrosoft Enterprise Desktop VirtualizationServers]
– [C:Program FilesMicrosoft Enterprise Desktop VirtualizationServersConfigurationServer]

の 2 個所に格納されています。

[Servers] 直下の XML ファイルが MED-V サーバーの構成、[ConfigurationServer] の XML ファイルがワークスペースの
設定情報になるようです。

ワークスペース用の設定情報の格納場所に関しては、[ServerConfiguration.xml] の [StorePath] に指定がされており、
デフォルトではインストールディレクトリ内の [Configuration] ディレクトリが設定されています。

この設定を共有ディレクトリに変更することで、ワークスペースの設定情報を複数のサーバーで共有できるようになります。

MED-V の構成情報や、ゲスト OS のイメージは暗号化されている個所があるようなので、冗長構成をとる各サーバーで、
同一の [KeyPair.xml] を使用する必要もあるようですね。
KeyPair.xml の内容が正しくないと、[MEDV Server] サービスが起動できないようです。

この xml はファイルが存在していない場合、サービスの起動時に自動生成されるようなのですが、一度リネームをして
とっておいたファイルをサービスの起動時に生成されたファイルと置き換えたらサービスが起動できなくなりました…。

MED-V で実行されるゲスト OS の仮想ハードディスクですが、[VHD] ではなく [EVHD] というファイルになるんですよね。

[Encrypted Virtual Hard Disk] という暗号化された VHD が使用されているのですがこの復号化と KeyPair.xml の
関連性も気になります。

■MED-V の冗長構成

MED-V の冗長構成は WSFC ではなく NLB で実現することになりそうです。
レポート用のデータベースの配置場所が悩ましいところですが。

冗長化を考えると以下のような構成になると思います。

?

MED-V で使用されるイメージファイル (ゲスト OS のイメージ) も共有ディレクトリに配置させる必要があるかと。
IIS で UNC 共有を使用した仮想ディレクトリを使用する必要があるのかなと考えています。

実際の冗長化された構成の構築に関しては次回検証したいと思います。

MED-V で確認したいことがあり、Windows Server 2008 R2 に MED-V の環境を構築しています。

■Windows Server 2008 R2 に MED-V をインストール

IIS と SQL Server の導入も終わり、いざインストールしようとしたところ以下の画面が…。

Windows Server 2008 R2 では MED-V サーバーのインストールできませんか…。

ひとまず互換モードでインストーラーを起動してみました。

最初のバージョンチェックを回避し、インストールが完了しました。

ぱっと見は MED-V サーバーが動作しているようです。

?

■クライアントで稼働確認

ひとまずサーバーは準備できたのでクライアントで稼働確認です。

MED-V クライアント (Vista) からワークスペースのダウンロードもできました。

管理コンソールも起動可能です。

MED-V サーバーにイメージのアップロードもできました。
?

ダウロードもできます。
?

本題のアプリケーションの実行も大丈夫そうですね。

?

今まで MED-V は Windows 7 への対応ばかり気にしていたのですが、Windows Server 2008 R2 への対応も
気にしないといけなかったのですね。

MED-V は Beta が出てから 1 年近くたっているのですが日本語の情報ってあまりないですよね。
# 私が見落としているだけかも。

検証環境も再構築できたので、これでようやく確認したかったことの検証ができます。

冗長化構成の最後としてセルフサービスポータルの冗長化を。
セルフサービスポータルは Web サーバーですので NLB で冗長化が可能です。

■使用した環境

今回使用する環境は前回の環境のフロントとして、NLB 構成のセルフサービスポータルを追加します。

私の検証環境は TMG 2010 が構築してあるので、NLB 構成とは別にサーバーファーム構成でセルフサービスポータルを
冗長構成する構成も作ってみたいと思います。

TMG 2010 だと以下の構成になります。
 

TMG 2010 の環境は HTTPS のリスナが設定されているので、HTTPS で受けて内部的には HTTP で通信する構成にしています。

■セルフサービスポータルのインストール

セルフサービスポータルのインストールでは冗長構成の設定はありません。
セルフサービスポータルと SCVMM サーバーを分割してインストールする時と同じ方法で構築します。

[Virtual Machine Manager サーバー] に VMM サーバーの役割をインストールしているサーバーを指定します。
TMG 2010 のサーバーファームを使う際にホストヘッダーが必要になるので、適当なヘッダー名を指定しています。

VMM サーバーのファイアウォールに関しては VMM サーバーインストール時に 8100 に対してアクセス許可を自動的に
設定しているようなので、明示的に設定をする必要はないようです。

 

■NLB の設定

NLB の設定も通常の Web サーバーの NLB 設定と同じです。
NLB は DHCP による IP 割り当てでは設定ができませんので適当な固定 IP を割り当ててから作業をします。

[ネットワーク負荷分散] の機能をセルフサービスポータルの各サーバーに追加します。

今回は Hyper-V 上に構築しているので [MAC アドレスのスプーフィングを有効にする] も忘れずに。

IP は塗りつぶしていますが、できた環境がこちらです。
03 / 04 の 2 台構成で NLB を設定しています。

インストール時に指定したホストヘッダーでアクセスし、正常にセルフサービスポータルが表示されています。
HTTP 経由のアクセスなので、警告文が表示されていますね。
 

セルフサービスポータルも正常に使用できます。

通常の NLB 設定と同じなので特有の設定はありませんでした。

■冗長構成のテスト

片側の NLB を停止させながら冗長構成のテストをします。

両方が停止している状態はエラーとなりますが、片側が生きていれば正常にアクセスができる状態となっています。

■TMG 2010 で冗長化

TMG 2010 ではサーバーファームという機能があります。(ISA 2006 でもあります。)
# Web サーバー側で冗長構成を設定しなくても TMG 側で冗長構成を設定できる機能です。

  
サーバーファームとして冗長構成をしたいサーバーの IP または コンピュータ名を指定します。

サーバーファームには [接続検証] とい機能があり、NLB とは異なり死活監視で HTTP アクセスが可能かを調べることができます。
NLB の冗長化では、サーバーが生きていて IIS が死んでいる場合でも負荷分散対象となり、要求が振られたはずですが、
サーバーファームでは HTTP アクセスができない (IIS が死んでいる) 場合は負荷分散対象外とすることができます。

後はこのサーバーファームを使用する [Web 公開ルール] を作成すると TMG 経由で公開することができます。

TMG のルールでは [内部サイト名] を入力する必要があります。
各 セルフサービスポータルには内部サイト名でアクセスがされますので、インストール時に指定したホスト ヘッダーの値を設定します。

設定を進めると使用するサーバーファームを選択する画面になります。
ここで先ほど作成したサーバーファームを選択します。

あとはウィザードを進めてルールの作成を完了させます。

TMG 2010 はインターネット経由でアクセスできる環境にしてあるので、外部からアクセスしてみます。
 

外部からは HTTPS でアクセスしているのですが、セルフサービスポータルでは HTTP で受けているので、
NLB のテストの時と同様警告が表示されています。
セルフサービスポータルを HTTPS で構成しないと警告を消せないみたいですね。

あとはインターネット経由の場合はセルフサービスポータルでコンソールが開けませんでした。
接続する際にホスト OS を DNS で解決できる必要があるようで、エラーとなってしまいました。
 

セルフサービスポータルはイントラネット向けなのでしょうか…。
この辺は要調査です。

 

VMM サーバー / データベースサーバー / セルフサービスポータルの 3 回に分けて冗長構成を実験してみました。
データベースサーバーとセルフサービスポータルの冗長化は一般的な手法で構成できますが、VMM サーバーの冗長化だけ、
これといった案が導き出せませんでした。

SCVMM を複数台構成にするとなかなか奥が深いものですね。

SCVMM 冗長構成第 2 弾としてデータベースの冗長化について。
クラスタは通常のインスタンスと変わらないので、今回はミラーリングされているデータベースを使用する実験を。

?

■使用した環境

今回は以下の構成を使用しています。

SCVMM サーバーは前回使用した SQL Server のクライアントコンポーネントをインストールした環境を。

データベースに関してはミラーリングした SQL Server 2008 R2 Nov CTP を 3 台用意して、自動フェールオーバーの
ミラーリングの設定をしています。

■接続設定の変更

SCVMM サーバーは前回の環境を使用しているので参照先データベースの設定が前回の状態となっています。
まずはデータベースの参照先の設定変更が必要となります。

SCVMM の管理コンソールに [データベース接続] という管理項目があるのですが、この項目で確認できるデータベースの
接続先の情報は読み取り専用のため、変更することができません。

?
?
接続先データベースの変更はレジストリを修正する必要があります。
# データベースに接続できないと管理コンソール開けないはずですので、レジストリを修正する形になっているのかと。

レジストリの修正箇所に関しては前回の投稿で書いた場所になるのですが、試してみたところ少し情報が足りなさそうでしたので、
今回の投稿でまとめてみました。

TechNet では以下の情報でデータベースの変更について記載されています。
VMM 2008 用 SQL Server のリモート インスタンスの構成

コマンドラインからのセットアップの情報も参考になりそうです。
コマンド ラインからの VMM コンポーネントのインストール

データベースの接続関連の設定は以下のキーに格納されています。

レジストリのキー

HKEY_LOCAL_MACHINESOFTWAREMicrosoftMicrosoft System Center Virtual Machine Manager ServerSettingsSql

?

正式な情報が見つからなかったので、今回の検証の結果からの内容になりますが各設定項目は以下のようになっているようです。

名前	種類	設定値
ConnectionString	REG_SZ	SCVMM で使用するデータベースの接続文字列
CreateNewInstance	REG_DWORD	0:既定のインスタンスを使用 1:SQL Server Express を使用してローカルにインスタンスを作成 セットアップ時の選択内容が設定されているようです。
DatabaseName	REG_SZ	接続先のデータベース名
InstanceName	REG_SZ	接続先のインスタンス名 ブランクの時は既定のインスタンスが使用されるようです。
MachineFQN	REG_SZ	接続先のデータベースサーバーの FQN ここに設定されている内容が SVMM の管理コンソール表示されます。 ロカールインスタンスを使用するようにセットアップをした場合は この項目は存在しません。 接続で使用されるのは [ConnectionString] の設定なのでこの項目は ラベル的な意味合いかもしれないです。
MachineName	REG_SZ	接続先のデータベースサーバーのサーバー名 ロカールインスタンスを使用するようにセットアップをした場合は この項目は存在しません。 接続で使用されるのは [ConnectionString] の設定なのでこの項目は ラベル的な意味合いかもしれないです。
OnRemoteServer	REG_SZ	0:ローカルインスタンスを使用 1:リモートインスタンスを使用

?

今回はミラーリング環境ですので、[ConnectionString] をミラーリング用に変更する必要があります。
接続先のサーバーを指定する部分を以下のように変更します。

[変更前] Server=データベースサーバー名 [変更後] Server=プリンシパルサーバー名;Failover Partner=ミラーサーバー名 [設定例] Server=2008R2-DBM-01;Failover Partner=2008R2-DBM-02

今まで、ローカルサーバーを使用していた場合は、[OnRemoteServer] の値も [1] に変更しておきます。

?

■接続先のデータベースに必要となる権限

SCVMM サーバーはデータベースサーバーの [sysadmin] 権限が必要となます。

SCVMM サーバー → データベースサーバーの接続に使用されるログインアカウントですが、

• [Virtual Machine Manager] サービスをローカルシステムアカウントで実行している場合
  コンピュータアカウントで接続
• [Virtual Machine Manager] サービスを任意のユーザーアカウントで実行している場合
  サービスの起動アカウントで接続

となりますのでサービスの実行アカウントの設定状態によって変更する必要があります。

コンピュータアカウントを SQL Server のログインとして設定する場合ですが、SQL Server Management Studio (SSMS) の
GUI を使用して設定ができなかったので、SQL を実行してログインを追加する必要がありました。

SSMS からだとオブジェクトの種類で [コンピュータ] が選択できないんですよね。
$ 付きでコンピュータアカウントを指定しても検索ができなかったので SQL で追加してしまいました。

以下はコンピュータアカウントのログインを作成するための SQL の一例です。

USE [master] GO — コンピュータアカウントのログインを作成 CREATE LOGIN [<ドメイン名><SCVMM サーバー名>$] FROM WINDOWS WITH DEFAULT DATABASE = [<SCVMM で使用するデータベース名] GO — 作成したログインに [sysadmin] 権限を付与 EXEC [master]..[sp_addsrvrolemember] @loginname=N’<ドメイン名><SCVMM サーバー名>$’, @rolename = N’sysadmin’ GO

?

■設定の反映

これでミラーリングされたデータベースを使用する準備は完了です。

[Virtual Machine Manager] サービスを再起動し、設定内容を反映させます。

再起動後に開始できないようでしたらレジストリの設定値が間違っている可能性があります。
# データベースに接続ができなくてもサービスは起動します。
開始できない場合はスペルミスがないか見直した方がよいかと思います。

?

■テストの実施

プリンシパルサーバーのサービスの停止または、手動フェールオーバーでデータベースをプリンシパル → ミラーに
フェールオーバーさせてテストを実施します。
?
?

SCVMM サーバーのデータベースの参照状態に依存するとは思うのですが、フェールオーバー中に必ず切断されるということは
ありませんでした。
# フェールオーバー時の復旧に時間がかかると切断されてしまうことがありましたが。

100% 接続を維持できるということはミラーリングの使用上難しい (アプリケーション側の再接続のロジックとの兼ね合い) ですが、
フェールオーバークラスタより、フェールオーバー時の停止時間は短いと思います。

残るはセルフサービスポータルの冗長化ですね。
これは今から検証環境を準備して次回投稿したいと思います。
# 私が普段使っている検証環境にセルフサービスポータルが入っていないことに今気付きました…。

SCVMM 2008 R2 の冗長構成はどうするのだろうと少し調べていました。

Twitter で呟いてみたところ、
– [既存の SCVMM のデータベースを別の SCVMM のデータベースに関連付けできないか]
というフォローを頂くことができました。

なるほど。面白そうな構成だな～。と思い実験してみました。

用意した環境がこちら。

現在使用している検証環境の SCVMM のデータベースを新規に構築した SCVMM も参照する構成で実験をしています。
専用 SQL Serverを用意するときれいな環境だったのですが面倒だったもので…。
# SCVMM #1 のファイアウォールで SQL Server のポートに対して着信許可を設定しています。

■SCVMM #2 のインストール

まずは上記の構成を作るために新規サーバーに SCVMM をインストールします。
インストールは通常の方法と変わらないのですが、SCVMM で使用するデータベースを新規データベースではなく、
既存のデータベースに設定します。

# サーバー名とインスタンス名は塗りつぶしていますが、図の [SCVMM #1] を指定しています。

無事にインストール完了です。

最初試したところ、ロックされているジョブがありますといったエラーが表示されインストールできないことがありました。
その場合は、SCVMM 用のデータベースの [dbo].[tbl_VMM_Lock] テーブルの内容を削除するとインストールができました。
# 実験なので問答無用で上記のテーブルを Truncate してしまいました。

■ホスト OS のグループにコンピュータアカウントを追加

通常はインストールが終了したら、各ホスト OS にエージェントをインストールします。
今回は各ホスト OS は SCVMM #1 で管理されているのでエージェントの再導入は避けたいです。

そこで、ホスト OS の以下のローカルグループにコンピュータアカウントを手動で追加します。

• Administrators
• Virtual Machine Manager Servers

これらのグループに SCVMM のコンピュータアカウントを追加しないと SCVMM 上でホスト OS の状態を取得できず、
仮想環境の管理をすることができません。

?

構築し終わった環境がこちら。

左が [SCVMM #1]、右が [SCVMM #2] になります。

同一のデータベースを参照しているのでバーチャルマシンの登録状況は一緒ですね。
SCVMM #2 のジョブでエラーが結構出力されているのと、両方の SCVMM サーバーのサービスが起動していると
管理コンソールが切断されることが多くなっているのが気になります。
# 私の SCVMM の環境は管理コンソールが切断されることがしばしばあるのですが、両サーバーを起動していると
　 切断される頻度が高くなった気がします。
コールドスタンバイ環境とするのであれば実用的かも。

PRO 機能との連携もどうなるのか気になるところですね。

SCVMM のバックアップはデータベースがきちんと取得できていれば再構築はさほど面倒ではないので、
サーバー冗長化ではなく、バックアップ + 再構築の手順を確立することで障害発生時に備えるという考えでも
いいのかもしれないですね。

予備機を作っておいて、以下のレジストリを変更し参照先 DB を変更してからエージェント再導入といった考えもあるかも。
VMM 2008 用 SQL Server のリモート インスタンスの構成

Exchange 2007 ではメールボックスの復旧をする際に使用する [回復ストレージグループ] を EMC の
[データベース回復管理] から作成することが可能でした。

Exchange 2010 では、[データベース回復管理] がなくなっています。

また、Exchange 2010 ではストレージグループがなくなっていますので、[回復ストレージグループ] ではなく、
[回復用データベース] となっています。

回復用データベースの使用は、EMC からではなく、EMS を使用してコマンドでデータベースの作成を行います。
New-MailboxDatabase

回復用データベースを使用したメールボックス回復の一連の作業としては、

New-MailboxDatabase ?Recovery ?EdbFilePath “<EDB ファイルパス>” ?LogFolderPath “<ログフォルダパス>” ?Server “<サーバー名>” ?Name “<回復用データベース名>” ESEUTIL /R データベースの識別子 /d”<EDB フォルダパス>” /l"<ログフォルダパス>” Mount-Database “<回復用データベース名>” Restore-Mailbox ?Identity “<対象のユーザー>” ?RecoveryDatabase “<回復用データベース名>” Dismount-Database “<回復用データベース名>” Remove-MailboxDatabase “<回復用データベース名>”

というようにコマンドベースで回復を行っていきます。

サードパーティーのバックアップソフトを使わなくてもOS 標準の Windows Server バックアップ + 回復用データベースで
ある程度は復旧ができますよね。

一度メモを残しておくと便利そうでしたので投稿しておきたいと思います。

Exchange Server 2007 では Standard Edition ではクラスタを使用することができませんでした。
Exchange Server 2007 のエディションおよびクライアント アクセス ライセンス

そのため、Standard Editoin では [シングル コピー クラスタ] と [クラスタ連続レプリケーション] はサポートなしとなっています。

クラスタの構成がされている評価版 (Standard Evaluation) で Standard Edition のプロダクトキーを設定すると、
以下のエラーが発生し、プロダクトキーを確定することができません。

Exchange Server 2010 の場合はエディションによる機能比較は以下の情報ぐらいしか見当たりませんでした。
Exchange 2010: Editions and Versions

Exchange 2010 でも作成できるメールボックスデータベース数には差があるのですが、機能面に関しては特に言及されていません。
試しに DAG が設定されている評価版 (Standard Evaluation) で Standard Edition のプロダクトキーを設定してみました。

Exchange 2010 では Standard Edition で DAG (クラスタ構成の Exchange) を構成することが可能です。
# 海外のブログで Standard Edition + DAG について書かれているものがいくつかあります。

機能面に関しては、Standard CAL または Enterprise CAL のどちらを使用するかで変わるようですね。
Exchange Server 2010 Standard Edition + Enterprise CAL という組み合わせもできたはずです。
この辺の情報はパートナー向けの Exchange 2010 の販売ガイドが記載されています。

Windows Server 2008 R2 Enterprise Edition + Exchange Server 2010 Standard Edition で冗長構成を持った
メールボックスサーバーが構築できるのはコストを抑えられて良いですね。

Exchange 2010 で承認済みドメインを変更しながら、メールフローの確認をしていました。
[電子メールアドレスポリシー] の [Default Policy] で設定されている承認済みドメインを [外部の中継ドメイン] に
変更しようとしたところ、以下のエラーが発生しました。

電子メールアドレスポリシーで設定されているドメインに関しては、[外部の中継ドメイン] に設定できないようでしたので、
[Default Policy] から該当のドメインを削除しようとしたところ、以下のエラーが発生してしまい EMS からは変更できませんでした。

既定の電子メール アドレス ポリシーでは、この操作を実行できません。

既定の電子メール アドレス ポリシーは EMC ではなく EMS (Exchange Management Shell) で変更する必要があります。
既定の電子メール アドレス ポリシーでは、[-EnabledEmailAddressTemplates] と [-Identity] 以外は指定できないのが原因のようです。

EMS で以下のようなコマンドを実行することで既定の電子メール アドレス ポリシーを変更することが可能です。

set-EmailAddressPolicy ?EnabledEmailAddressTemplates ‘<メールアドレス>’ ?Identity ‘Default Policy’

Exchange 2007 で既定の電子メール アドレス ポリシーを設定し、Exchange 2010 に移行していたため、ポリシーを
操作する機会がなく、今までエラーが発生することに気づきませんでした。