ブログの下書をのぞいていたところ本投稿がお蔵入りとなって残っていました。
破棄するのももったいないかな～と思い、一応ブログにアップしておくことにしました。

複数サーバー構成についてはきちんとブログでまとめたいと思います。

■SCCM 2007 のバージョン

2010/1/15 時点では SCCM 2007 R2 SP2 が最新のバージョンとなります。
SCCM 2007 R2 は SCCM 2007 SP1 以降のバージョンに追加モジュールとしてインストールをするため、
単体ではインストールすることができません。

SP2 を適用しても R2 を別途インストールしないと SCCM 2007 R2 にはなりません。

TechNet サブスクリプションで提供されている SP2 のメディアは差分アップデートではなく、インストールイメージも
含まれているので 2007 RTM → SP1 → SP2 という順でインストーしなくても SP2 のメディアからインストールすれば、
With SP2 の状態でインストールされます。

SP2 → R2 の順でインストールすることで最新の状態となります。

■Windows Server 2008 R2 への対応状況

SCCM 2007 SP2 以降で Windows Server 2008 R2 に対応します。
Configuration Manager 2007 SP2 がサポートする構成

SCCM 2007 のサーバーコンポーネントは x86 のみとなっているため、Windows Server 2008 R2 では
WOW64 での動作となります。

■SQL Server 2008 への対応状況

SCCM 2007 SP1 以降で SQL Server 2008 に対応します。
Configuration Manager 2007 SP1 がサポートする構成

SCCM 2007 + SQL Server 2008 の組み合わせでは、以下の KB の更新プログラムを適用したほうがよいようです。

■SCCM の基本的な構成

SCCM はサイトという階層構成で管理がされます。
サイトには 3 種類あります。

?

SCCM クライアントは各サイトに関連付けられて管理されることになります。

1 つのサイトには複数のサーバーを配置することができます。
サーバーを複数配置し、役割を分散させることで負荷を低減させることができます。

各サイトで提供される機能はサイトシステムで構成されます。
サイトシステムには以下の役割があります。

■SCCM 2007 の冗長化

検証用だと 1 台で構築してしまいますが企業向けだと冗長構成の必要性を考慮する必要があります。
SCCM 2007 の冗長構成はクラスタではなく、複数のサーバーに同一の役割をインストールすることで構成します。
一部の役割では NLB で負荷分散ができるようです。

■Active Directory のスキーマ拡張の必要性

SCCM 2007 の自習書を読むと Active Directory のスキーマ拡張の作業が書かれています。
Active Directory のスキーマ拡張は、SCCM クライアントで [サイトコードの自動探索] をするために必要となります。
スキーマ拡張をすることで、管理ポイントの情報を Active Directory に格納することができます。
スキーマ拡張をしない場合は、SCCM で [サーバーロケータポイント] の役割が必要となります。

スキーマ拡張により、AD 上に SCCM の管理ポイントの情報を保持するためのクラス / 属性が作成されます。
# [msSMS～] とついているものが拡張により作成されるもののようです。

この拡張した属性を使用することで管理ポイントの情報が AD のドメインパーティション上に作成できるようになります。
自習書で [System Management] というコンテナを作成している個所が、管理ポイント用のコンテナを作成している個所になります。

このコンテナに対して、サイトサーバーのコンピュータアカウントの [フルコントロール] を許可することで、SCCM の
サイトサーバーが管理ポイントの情報を AD 上に格納できるようになります。
SCCM 2007 のコンピュータアカウントを含めるグループを作成して、そのグループにコ
ンピュータアカウントを追加して、
グループに対してフルコントロールを設定するのが管理上便利だと思います。

■動作モードの種類

SCCM には以下の 2 種類の動作モードがあります。

?

■WSUS のインストール有無

SCCM では、[ソフトウェアの更新ポイント] の役割を持つサーバーを構築する場合、WSUS がインストールされた
サーバーが必要となります。

[ソフトウェアの更新ポイント] の役割をローカルではなくリモートに持つ場合は、WSUS 本体ではなく、
WSUS 管理コンソールをインストールしておきます。
# WSUS or WSUS 管理コンソールのどちらかが必須コンポーネントとなります。
WSUS の管理コンソールは WSUS のインストーラーからインストールすることができます。

Windows Server 2008 R2 で WSUS を使用するためには WSUS 3.0 SP2 が必要となります。

WSUS の管理 UI を使用するためには、[Microsoft Report Viewer 2008 再頒布可能] が必要となります。
Microsoft Report Viewer 2008 SP1 Redistributable – 日本語
Microsoft Report Viewer 再頒布可能パッケージ 2008 SP1 Language Pack – 日本語

■サイト システムの追加

SCCM のサイトにサーバーを追加する場合は、サイトに対してサイトシステムを追加します。
# 追加するサーバーでインストーラーを起動するという方法ではありません。

?
サイトシステムのインストールはコンピュータアカウントまたは、使用するアカウントを指定することができます。
使用するアカウントをローカルの Administrators グループに入れておけばインストールはできるかと。
ファイアウォールでドメインネットワークに [ファイルとプリンタの共有] は許可になっている必要がありそうです。

追加する際に、どの役割を持たせるかを選択します。

サイトシステムの追加をすると、追加するサーバーに対してコンポーネントのインストールが実行されます。
役割を一つも選択しない状態だと、追加サーバー側に対してコンポーネントのインストールは実行されないようです。
# SCCM の構成上登録はされるのですが、追加したサーバーに対して処理はされていないように見受けられます。

コンポーネントのインストール状況は、[コンポーネントのステータス] の [SMS_SITE_COMPONENT_MANAGER] の
メッセージで確認することができます。
?

インストールの状況は追加するサーバーの [イベントビューア] の [アプリケーション] でも確認することができます。

今回は保護エージェントのアンインストール編です。

インストールと同様、アンインストールも以下の 2 種類の方法があります。

■管理コンソールからアンインストール

保護エージェントは管理コンソールをトリガーとしてアンインストールすることも可能です。
# 手動でアンインストールした時に管理コンソール側で実行している操作だけでアンインストールすることもできます。

インストールの時と同様、保護エージェントをインストールしたコンピューターで High-Port のポリシーが許可されていないと
エラーとなってしまうようです。
# インストール / アンインストールともにネットワークモニターでは、保護エージェントがインストールされている
　 コンピューターの 40000 番台のポートが使用されているようなので、[1024 ～ 65535] でなく、[49152 ～ 65535] の
　 許可だけでもインストール / アンインストールができるかもしれないですね。

1. [DPM 2010 管理者コンソール] を実行します。
   ?
2. 保護エージェントをアンインストールしたいコンピューターを右クリックして、[アンインストール] をクリックします。
   
3. [エージェントのアンインストール] をクリックします。
   
4. エージェントをアンインストールするコンピュータの管理者権限のアカウント情報を入力して、[OK] をクリックします。
   
5. エージェントのアンインストールが実行されます。
   　

エージェントのアンインストールが完了します。

?

手動 / 管理コンソールからのアンインストールともに、保護エージェントをインストールしていたコンピューターの
[DPMRA_DCOM_135] のファイアウォールのルールは削除されないので、必要に応じて手動で削除します。

インストール / アンインストールともに管理コンソールで操作する場合は、ファイアウォールの設定がポイントになるようですね。
さて、これから DPM の操作方法を覚えていかなくては。

そろそろ SCDPM も触ってみたいと思い、SCDPM 2010 RC 環境を構築しています。
SCDPM でバックアップを取得する対象にはエージェントを導入する必要があります。

エージェントの導入方法には 2 種類あります。

• 手動インストール
• プッシュインストール

?

[エージェントのインストール] がプッシュインストール、[エージェントの接続] が手動インストールになります。

■手動インストール

1. 保護対象のコンピューターにエージェントプログラムをインストール
   
   1. まずは、保護対象のコンピューターにエージェントプログラムを手動でインストールします。

      エージェントプログラムはサーバーの以下のディレクトリに格納されています。
      [C:Program FilesMicrosoft DPMDPMProtectionAgentsRA]
      今回の環境ではディレクトリ内に一つのバージョンしかありませんが、数字が大きいものが最新となるようです。
      ?

      DPM 2007 の時とはエージェントのディレクトリの場所が変わっているようですね。
      System Center Data Protection Manager 2007 で [DPM 2007 管理者コンソール] からの保護エージェントのリモート インストール、またはアップデートに失敗する

      x64 / x86 用のディレクトリに分かれてエージェントが格納されていますので、保護対象の OS にあったエージェントを
      保護対象のサーバーにコピーします。
      # 今回は x64 版を使用しています。

   2. コピーしたディレクトリ内に [DPMAgentInstaller_x64.exe] がありますので、このプログラムをコマンドプロンプトから、
      以下の形式で実行します。
      ?
      <
      

      DPMAgentInstaller_x64.exe <DPM サーバー名> 例) DPMAgentInstaller_x64.exe 2008R2-DPM-01

      ?

      プログラムの実行が完了するとエージェントプログラムの導入がされた状態となります。
      

      続いて、保護対象コンピューターを DPM サーバーで認識させます。

2. 保護対象コンピュータの追加
   
   こちらの作業は DPM サーバーで実施します。

   1. DPM 2010 管理者コンソール を開きます。
      ?
   2. [管理] → [インストール] をクリックします。
      
   3. [エージェントの接続] を選択し、[次へ] をクリックします。
      今回は AD 内のサーバーに対してエージェントを導入します。
      
   4. コンピュータアカウントが表示されますので、エージェントの手動インストールをしたコンピュータを
      [追加] して、[次へ] をクリックします。
      ?
   5. エージェントをインストールしたコンピューターの管理者アカウントを入力し、[次へ] をクリックします。
      今回は、AD 内のコンピューターに対しての処理を選択していますので、ユーザーはドメインユーザーの
      必要があります。
      事前に、保護対象のコンピューターの [Administrators] グループにドメインユーザーを追加しておきます。
      ?
   6. [接続] をクリックします。
      
   7. 結果が [成功] になっていれば、処理は完了です。
      

保護エージェントがインストールされたコンピューターとして認識されていることが確認できます。
?

今回はクラスタの環境を追加しています。
クラスタを
形成しているもう一つのノードにはプッシュインストールでエージェントをインストールしてみたいと思います。

■プッシュインストール

それではエージェントをプッシュインストールしてみます。
この方法を昨日、Twitter で呟きながらいろいろと検証していました。
# Twitter でフォローしてくださった方、本当にありがとうございます。

1. DPM 2010 管理者コンソール を開きます。
2. [管理] → [インストール] をクリックします。
3. [エージェントのインストール] を選択し、[次へ] をクリックします。
   
4. プッシュインストールをするコンピューターを選択し、[次へ] をクリックします。
   プッシュインストールの場合は、AD に参加しているコンピューターが前提みたいですね。
   
5. エージェントをインストールしたコンピューターの管理者アカウントを入力し、[次へ] をクリックします。
   プッシュインストールの場合はドメインユーザーを指定する必要があります。
   
6. OS によっては再起動が必要になるものがあります。
   今回は 2008 R2 にインストールをしますので、[いいえ。～] を選択して、[次へ] をクリックします。
   
7. [インストール] をクリックします。
   ?
8. 通常の状態でインストールをするとプッシュインストールは失敗します。
   　
   エラーメッセージにも表示されているように保護対象コンピューターのファイアウォールでブロックされているため、
   エージェントのプッシュインストールが失敗してしまいます。

   ファイアウォールを無効にするとインストールが可能なのですが、それだとセキュリティ的にいかがなものだろうということで、
   昨日、いろいろと試していました。
   

   検証した結果、保護対象コンピュータで High-Port (1024-65535) の受信を許可するとプッシュインストールができました。
   # RPC 動的ポートの許可では駄目だったんですよね。

   必要となるファイアウォールの技術情報は以下になるようです。
   Configuring Firewalls

9. コマンドプロンプトで以下のコマンドを実行します。
   

   netsh advfirewall firewall add rule name="High-Port" protocol=TCP dir=in localport=1024-65535 action=allow remoteip=<DPM サーバーの IP> 例) netsh advfirewall firewall add rule name="High-Port" protocol=TCP dir=in localport=1024-65535 action=allow remoteip=192.168.0.1

   # ネットワークモニタを眺めていると、TCP 135/445 辺りも必要になるかと思ったのですが、
   　 何回かインストールを試してみたところ、High-Port だけでインストールができました。

10. ファイアウォールのルールを作ってからプッシュインストールを再度実行してみると正常に成功します。
    ?

正常に認識ができていますね。
?

管理コンソールから [アンインストール] をすることもできるのですが、この場合も [1024-65535] を許可していないと、
エラーとなってしまいました。
?

アンインストールに関しても手動と管理コンソールからの操作の 2 種類がありますのでこれに関しては次回の投稿でまとめたいと思います。

昨日の事なのですが、自宅の検証環境の SCVMM を起動したら以下のような状態になっていました。

すべてのサーバーがきれいに[要注意] となっています…。実際に数台は起動していないのですが常時起動のものまで注意になってしまっています。
私の使っている SCVMM はゲスト OS で sysprep を実行しようとしたら間違って SCVMM で実行してしまったというミスをして、
OS の再導入をせずに SCVMM のデータベース以外を再インストールしている環境となっています。

それが原因かな～と思ったのですが、昨日は朝方にサーバーが再起動していたことに気付きました。
昨日の朝は Windows Update のパッチ自動適用の日でした。

そこで、更新履歴を表示してみたところ、以下のパッチが適用されていました。
?
システム センター Virtual Machine Manager 2008 R2 の修正プログラム ロールアップ パッケージの説明: 2010 2 月 9日

SCVMM のロールアップが適用されたみたいですね。
ホストのプロパティをみるとエージェントのバージョンだけ、警告アイコンになっていました。

現在のエージェントのバージョンは、[2.0.4271.0] です。

エージェントのインストールはプッシュインストールで行うことができ、インストーラーは SCVMM が持っています。
[C:Program FilesMicrosoft System Center Virtual Machine Manager 2008 R2agentsamd64] に x64 用のインストーラーがあり、
Hyper-V は x64 専用なのでこの場所からインストーラーが配布されるのですが、[2.0.4273.0] というバージョンが増えていました。
?
今回のロールアップでエージェントの更新もされたようですね。

エージェントの更新は SCVMM から実施することができます。
対象のホスト OS を右クリックすると、[エージェントの更新] がありますのでこれを実行します。
?

クリックするとエージェントのインストールに使用するアカウントの入力画面が出ますので、管理者権限を持つユーザー情報を入力します。

そうするとエージェント更新ジョブが実行されますのでしばらく待ちます。

ジョブが完了すると以下のような表示になります。

ホストのプロパティを確認するとエージェントもバージョンアップされ、状態もすべて正常のアイコンになっています。
?

一斉にホスト OS が注意の状態になったので少し驚いてしまいました。

SCVMM のセルフサービスポータルをインターネット経由で公開できないかなといろいろと検証していました。
インターネット経由だと VPN か Direct Access 辺りを使用しないと厳しそうなのですが、調べたことを投稿しておきたいと思います。

今回の検証をするにあたり、Tech Fielders のライトニングトークの [ここまではできる SCVMM セルフサービスポータル] を
参考にさせていただきました。
Tech Fielders セミナー これまでのライトニングトーク登壇者
# ライトニングトークの内容を自分で検証してみたという投稿になっているかと。

SCVMM のセルフサービスポータルにログインした後のゲスト OS の接続には 2 種類の接続方法が用意されています。

1. VM に接続
2. リモート デスクトップ

どちらを使うかによってアクセスの経路が変わります。

■VM に接続

VM に接続は SCVMM の管理コンソールの [バーチャル マシンに接続] と同じ機能になります。
SCVMM の管理コンソールで接続した場合は、以下のように表示されます。
?

これをセルフサービスポータルで表示すると以下のように表示されます。

ゲスト OS のコンソールを直接開く機能ですね。

この機能ですが以下の接続がされているようです。
ポート 2179 で直接ホストに接続しているみたいですね。
SCVMM の管理コンソールのバーチャルマシンに接続で実行される [VirtualMachineViewer.exe] も、ポート 2179 で接続が
されているので、セルフサービスポータルの ActiveX も同様の動作になるんですね。

SCVMM がホスト OS にアクセスして表示しているのではなく、クライアントがホスト OS に接続をしているようです。
そのためクライアントが直接ホスト OS にアクセスできないといけないようです。

また、ホスト OS に接続をする関係上、ホスト OS を名前解決できないと接続ができません。
ホスト OS の名前解決ができないと以下の画面になってしまい接続ができません。

■リモートデスクトップ

リモートデスクトップですがこちらはゲスト OS のリモートデスクトップに接続をします。
そのため、ゲスト OS でリモートデスクトップを設定する必要があります。

私の環境の問題のような気もするのですが、[ネットワーク レベル認証で～] にしてリモートデスクトップを設定していると
セルフサービスポータルで接続することができませんでした。

[リモート デスクトップを実行している～] だと接続ができました。

リモートデスクトップだと以下の接続になるようですね。
直接ゲスト OS にリモートデスクトップのデフォルトポート 3389 で接続されます。
そのため、ゲスト OS でリモートデスクトップのポートを 3389 から変更すると接続できませんでした…。

こちらも直接接続していますので、ゲスト OS の名前解決ができないとエラーになります。

?

SCVMM のセルフサービスポータルからコンソールを開く場合は、ホストまたはゲスト OS に直接接続できる必要があるので、
インターネット経由での接続は簡単にはできなさそうですね。

インストールマニアックス 3 の VPS コースでは DotNetPanel という Web 管理ツールが提供されているのですが、
こちらはコンソールを操作する機能は提供されていないんですよね。

Hyper-V + SCVMM で IaaS の環境が作れれば面白いな～と思ったのですが、コンソールの利用を考えるとなかなか難しいですね。

冗長化構成の最後としてセルフサービスポータルの冗長化を。
セルフサービスポータルは 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 コンポーネントのインストール

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

?

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

?

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

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

?

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

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

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

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

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

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

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

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

?

■設定の反映

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

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

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

?

■テストの実施

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

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

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

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