Windows Server 2016 の RDS（VDI/RemoteApp）環境で、Connection Broker／RD Web Access／RD Gateway を1台に集約していると、後から「Brokerを別サーバーへ移設したい」「接続先のDNS名も変えたい」という課題に直面します。再構築を避けつつ現実的に解決する方法を、HA（高可用性）移行の観点でまとめます。
状況整理：何の「DNS名」を変えたいのか
「RD Connection Broker の DNS 名を変えたい」と言っても、RDS では複数の “名前” が登場します。ここを整理しておくと、設計ミスや証明書の不一致を防げます。
| 呼び方 | 例 | どこで使われるか | 変更の影響 |
|---|---|---|---|
| サーバー名（ホスト名/FQDN） | old-rds01.contoso.local | OS・AD参加・管理接続 | リネームは影響大。RDSの構成要素にも波及しやすい |
| Connection Broker（単体時の参照先） | old-rds01.contoso.local | RDSデプロイの管理先 | 単体構成だとここが固定になりがち |
| Client Access Name（ブローカープール名） | rdcb-pool.contoso.local | クライアントがブローカーへ到達するための名前 | HA（高可用性）で“自由度が上がる”ポイント |
| RD Web Access（ポータルのURL/FQDN） | https://rdweb.contoso.com/RDWeb | ユーザーがブラウザでアクセス | 公開URL・証明書に直結 |
| RD Gateway（外部FQDN） | rdgw.contoso.com | 社外/分離ネットワークからの中継 | NAT/証明書/ファイアウォールに直結 |
今回の悩みは、過去に構築した Windows Server 2012 R2 ベースの RDS VDI 環境を 2016 にアップグレードし、Connection Broker / Web / Gateway を同一サーバーで運用しているケースでよく起きます。役割を分離したくなっても、単体ブローカーのままだと「ブローカーの接続名を自由に変えられない」「変えるなら再構築」といった情報に行き当たりがちです。
結論：サーバーのリネーム置き換えは避け、HA（高可用性）へ移行して解決する
まず結論です。既存サーバーをそのままリネームして置き換える方法は、運用上のリスクが大きくおすすめできません。一方で、RD Connection Broker を高可用性（High Availability / HA）構成へ移行する手順を使えば、別サーバーへ移しつつ「新しい DNS 名（Client Access Name）」を採用することは技術的に可能です。
要点はシンプルで、「ブローカーを“プール（クラスタ）”として扱える状態にしてから、段階的に新ブローカーへ寄せて、最後に旧ブローカーを外す」という発想です。HA 化すると、構成情報を SQL データベースへ寄せ、クライアントは Client Access Name（DNS名）経由でブローカー群へ到達する設計になります。
| やり方 | メリット | デメリット/注意 | おすすめ度 |
|---|---|---|---|
| 既存サーバーをリネームして置き換える | 見た目は簡単に見える | RDSデプロイ内部参照・証明書・アプリ依存・手戻りが出やすい | 低 |
| 新規にRDSを再構築 | 設計を一から最適化できる | 移行コストが高い（コレクション/VDI/証明書/公開URL/ユーザー周知） | 中（長期的には有効） |
| Broker を HA 構成へ移行して段階移設 | 再構築に比べて影響を抑えつつ、DNS名の自由度が上がる | SQL準備、DNS設計、周辺（証明書/公開URL）の整合が必要 | 高 |
単体 Broker だと “DNS名を自由に変えられない” と言われる理由
単体の RD Connection Broker 構成では、クライアントが参照する接続名（Client Access Name）に、ブローカー自身の FQDN を使う前提で設計されているため、好きな別名に差し替える余地が小さくなります。PowerShell の Set-RDClientAccessName も、単体ブローカーの場合はブローカーの FQDN を指定する説明になっています。
その結果、次のような“固定化”が起きやすいです。
- RDS デプロイが「特定サーバー名」を前提に構成され、後から変えると整合性が崩れる
- 証明書（RD Web / RD Gateway / Broker Publishing）の SAN/CN と合わなくなる
- 利用者側（RDP ファイルやフィード）が旧名を参照し続ける
つまり「変えられない」というより、無理に変えると壊れやすい、というのが実態です。
HA 化で “新しい DNS 名” を採用できる理由
HA 構成では、複数の RD Connection Broker を束ね、クライアントが接続する入口として Client Access Name（DNS ラウンドロビン名、またはロードバランサの名前）を使います。これにより、ブローカーの実体サーバー名と、クライアントに見せる接続名を分離できます。
また、HA 化の中核は「ブローカー構成情報を SQL データベースに集約する」ことです。単体ブローカーでサーバーに埋め込まれがちな設定を外へ出すことで、サーバーの入れ替え（追加・削除）を“運用作業”として扱えるようになります。
事前準備で失敗を減らすチェックリスト
HA 移行は “手順通りにやれば終わり” というより、周辺の整合を崩さないことが成功のポイントです。特に「DNS名を変える」場合、証明書・公開URL・クライアント設定のどこに影響が出るかを先に線引きしてください。
| チェック項目 | 確認内容 | メモ欄 |
|---|---|---|
| 現行の役割配置 | Broker / Web / Gateway / Session Host / Virtualization Host の配置を棚卸し（Server Manager または Get-RDServer） | |
| “変えたい名前”の対象 | Client Access Name を変えたいのか、RD Web / Gateway の公開URLまで変えたいのかを分ける | |
| 証明書 | 利用中の証明書（CN/SAN、期限、秘密鍵、pfx の有無） | |
| SQL の用意 | SQL サーバーの準備、接続方式（Windows 認証 or SQL 認証）、ODBC ドライバー | |
| 切替タイミング | ユーザー影響（ログオフ/切断）を許容できる時間帯、メンテ告知 | |
| 切り戻し | DNS を戻す/旧ブローカーを復帰させる/証明書ロールバック等の判断基準 |
構成の棚卸しは、PowerShell なら次のように行えます。
Import-Module RemoteDesktop
# デプロイに登録されているサーバー一覧を確認
Get-RDServer -ConnectionBroker "old-rds01.contoso.local"構成例：既存“全部入り”から Broker 専用サーバーへ
移設のイメージがつきやすいように、よくある構成例を表にします。Broker だけを分離し、Web/Gateway は後回しにしても構いません（ただし、将来的には役割分離した方が保守は楽になります）。
| 役割 | 現状（例） | 移行後（例） | コメント |
|---|---|---|---|
| RD Connection Broker | old-rds01 | rdcb01 + rdcb02（HA） | Client Access Name を rdcb-pool にする |
| RD Web Access | old-rds01 | old-rds01（現状維持） | まずは Broker 分離を優先 |
| RD Gateway | old-rds01 | old-rds01（現状維持） | 外部公開が絡む場合は後から慎重に |
| RD Session Host / VDI | 既存ホスト群 | 既存ホスト群 | コレクション自体は維持しやすい |
実現手順：HA（ブローカープール）へ移行して DNS 名を変える
ここからは実作業の流れです。GUI（Server Manager）のウィザードでも可能ですが、何が設定されているかを追いやすいため、PowerShell を併用することをおすすめします。
新しい RD Connection Broker サーバーを用意する
- Windows Server 2016 を用意（ドメイン参加、Windows Update 適用、時刻同期確認）
- 既存環境と同じドメイン内で名前解決できること（DNS）
- ファイアウォール/ネットワークで RDS 管理や SQL への通信が許可されていること
SQL データベースを準備する（HA の必須要件）
RD Connection Broker の HA 構成では、ブローカー構成情報を格納するためのデータベースが必要です。Microsoft Learn の手順でも、データベースと接続文字列、適切な ODBC ドライバーが前提として説明されています。
SQL 側で詰まりやすいのが権限です。HA ウィザードでエラーになる場合、ブローカー サーバー（またはブローカー用セキュリティグループ）に適切な SQL 権限が不足しているケースが多いです。たとえば Microsoft のトラブルシュートでは、ログインに dbcreator と public の確認手順が示されています。
| 項目 | 推奨の考え方 | 理由 |
|---|---|---|
| 認証方式 | 可能なら Windows 認証（ドメイン） | パスワード期限・保管の運用負荷を減らす |
| 権限付与先 | ブローカーサーバーのコンピューターアカウント、または専用 AD グループ | サーバー追加/削除に追従しやすい |
| SQL 側の権限 | DB 作成に必要な権限（例：dbcreator 等）を検討 | HA 設定時に DB 作成/更新が必要になる |
| 通信 | ブローカー→SQL の疎通（TCP/ポート、名前解決） | ここが詰まるとウィザードが進まない |
接続文字列（例）は次のような形式になります。環境に合わせて置き換えてください。
DRIVER=SQL Server Native Client 11.0;
SERVER=sql01.contoso.local;
Trusted_Connection=Yes;
APP=Remote Desktop Services Connection Broker;
Database=RemoteDesktopDeploymentブローカープール用の DNS 名（Client Access Name）を設計する
ここが “DNS 名を変える” の核心です。新しい名前を Client Access Name として用意し、そこから複数のブローカーへ到達できるようにします。Set-RDConnectionBrokerHighAvailability の説明でも、Client Access Name は「RD Connection Broker サーバー群の FQDN を含む DNS ラウンドロビン名」である旨が明記されています。
実装パターンは大きく 2 つです。
| 方式 | DNS 設定 | メリット | 注意点 |
|---|---|---|---|
| DNS ラウンドロビン | 同一ホスト名に A レコードを複数登録（rdcb-pool → rdcb01, rdcb02 の IP） | 追加コストが小さい | クライアントのキャッシュや TTL の影響を受ける。死活監視は自前で補う |
| ロードバランサ | Client Access Name → VIP（ロードバランサ） | ヘルスチェックで健全ノードへ誘導しやすい | 機器/設定の用意が必要 |
“まずは確実に移設したい” なら、DNS ラウンドロビンで開始し、後からロードバランサへ置き換える運用も現実的です。その場合でも、クライアントが見る名前（Client Access Name）を固定しておけば、後工程の影響を最小化できます。
既存デプロイを HA モードへ切り替える
ここで既存の単体ブローカーを「HA（ブローカープール）として扱える状態」にします。PowerShell なら Set-RDConnectionBrokerHighAvailability を使います。
Import-Module RemoteDesktop
# 既存ブローカー（今の管理サーバー）
$oldBroker = "old-rds01.contoso.local"
# 新しいブローカープール名（クライアントが見るDNS名）
$clientAccess = "rdcb-pool.contoso.local"
# SQL 接続文字列（例）
$connStr = "DRIVER=SQL Server Native Client 11.0;SERVER=sql01.contoso.local;Trusted_Connection=Yes;APP=Remote Desktop Services Connection Broker;Database=RemoteDesktopDeployment"
Set-RDConnectionBrokerHighAvailability -ConnectionBroker $oldBroker -DatabaseConnectionString $connStr -ClientAccessName $clientAccess実行後は、次のコマンドで「ClientAccessName が想定通りか」「ActiveManagementServer がどれか」を確認します。
Get-RDConnectionBrokerHighAvailability -ConnectionBroker $oldBroker新しいブローカーサーバーをデプロイに追加する
HA 化できたら、新しいサーバーを RD Connection Broker としてデプロイに追加します。GUI では Server Manager の RDS 画面から「Add RD Connection Broker Server」を使います。Microsoft Learn の手順にも同じ流れが記載されています。
PowerShell で行う場合は Add-RDServer を使います（Role に RDS-CONNECTION-BROKER を指定）。
$newBroker = "rdcb02.contoso.local"
Add-RDServer -Server $newBroker -Role "RDS-CONNECTION-BROKER" -ConnectionBroker $oldBroker追加したブローカーがデプロイに登録されたかは、次で確認できます。
Get-RDServer -ConnectionBroker $oldBroker -Role "RDS-CONNECTION-BROKER"Active Management Server を新ブローカーへ切り替える
HA では “管理サーバー（RDMS がアクティブなブローカー）” を切り替えられます。PowerShell の Set-RDActiveManagementServer は、アクティブな RD Connection Broker（管理サーバー）を設定する cmdlet として提供されています。
Set-RDActiveManagementServer -ManagementServer "rdcb01.contoso.local"切り替え後、Get-RDConnectionBrokerHighAvailability の ActiveManagementServer が想定通りになっていることを確認してください。
（必要に応じて）Client Access Name を明示的に設定する
HA 設定時に Client Access Name を指定していれば通常は足りますが、「後から名前を変えたくなった」「一度別名で作ってしまった」などのケースでは Set-RDClientAccessName で変更できます。cmdlet の説明でも、複数ブローカー（Active/Active クラスタ）の場合は DNS ラウンドロビン名を指定する想定になっています。
Set-RDClientAccessName -ConnectionBroker "rdcb01.contoso.local" -ClientAccessName "rdcb-pool.contoso.local"証明書の整合を取る（名前を変えるなら必須）
DNS 名を変えると、証明書の CN/SAN と一致しなくなることがあります。RDS では、RD Web / RD Connection Broker / RD Gateway などの役割で TLS 証明書が使われ、PowerShell の Set-RDCertificate で役割ごとに適用できます。
証明書の適用例（拇印で指定）は次のとおりです。実際の役割（RDPublishing/RDWebAccess/RDGateway など）と拇印は環境に合わせてください。
$thumb = "0123456789ABCDEF0123456789ABCDEF01234567"
Set-RDCertificate -Role RDPublishing -Thumbprint $thumb -ConnectionBroker "rdcb01.contoso.local" -Force
Set-RDCertificate -Role RDWebAccess -Thumbprint $thumb -ConnectionBroker "rdcb01.contoso.local" -Force
Set-RDCertificate -Role RDGateway -Thumbprint $thumb -ConnectionBroker "rdcb01.contoso.local" -Force特に “全部入りサーバー” から役割分離していく場合、RD Web / RD Gateway の外部 FQDN はそのままにして、まず Broker の Client Access Name だけを変える（内部名の整理から始める）と、影響範囲をコントロールしやすいです。
動作確認（切替前後で必ず実施）
- RD Web Access からのサインイン→RemoteApp/VDI 起動ができる
- 既存ユーザーの RDP アイコン（フィード）で接続できる
- RD Gateway 経由接続の場合、社外/別セグメントからも同様に接続できる
- イベントログ（TerminalServices-*）でブローカー関連エラーが増えていない
- ブローカー片系停止（RDMS サービス停止等）でも復旧できる（検証環境または計画停止で）
旧ブローカーを段階的に外す
新ブローカー側での運用が安定したら、旧ブローカーをデプロイから削除します。いきなりサーバーを落とすのではなく、デプロイ構成から外す→DNS レコード整理→監視の調整の順で進めると安全です。
旧ブローカーを外した後も、しばらくは以下を監視してください。
- クライアント側に旧名が残っていないか（RDP ファイル/キャッシュ）
- DNS キャッシュの影響で一時的に誤ったノードへ向いていないか
- SQL 側のバックアップが取得できているか
トラブルになりやすいポイントと対策
“DNS 名を変える” を含む HA 移行で詰まりやすい点を、症状別にまとめます。
| 症状 | よくある原因 | 対策の方向性 |
|---|---|---|
| HA ウィザード/コマンドで DB 関連エラー | SQL 側の権限不足、接続文字列の誤り、ODBC ドライバー不一致 | SQL のログイン権限（dbcreator 等）と疎通、接続文字列を再確認 |
| RD Web は開くが RemoteApp/VDI 起動で失敗 | 証明書の不一致、Client Access Name の解決先、ブローカー切替直後のキャッシュ | 証明書の CN/SAN、DNS レコード、Get-RDConnectionBrokerHighAvailability で状態確認 |
| 一部クライアントだけ繋がらない | DNS キャッシュ/TTL、古い RDP ファイルが旧名参照 | TTL 設計、RDP ファイル再配布、端末側のキャッシュクリアを検討 |
| フェイルオーバーで復旧しない | ActiveManagementServer 切替ができていない、片系のサービス不整合 | Set-RDActiveManagementServer で管理サーバーを明示的に切替 |
運用のコツ：最初から“最終形”を作り切らない
全部入りサーバーからの脱却は、技術だけでなく運用設計の問題でもあります。おすすめは、次の順番で “段階的に正す” ことです。
- Broker を HA 化して Client Access Name を確定（ここで DNS 名変更の目的を満たす）
- Broker の台数を 2 台にして、片系停止でも継続できる状態にする
- 必要に応じて RD Web / RD Gateway を別サーバーへ分離（外部公開が絡む場合はここが一番慎重に）
- 証明書更新やバックアップ（SQL を含む）を運用手順に落とし込む
先に “クライアントが見る名前（Client Access Name）” を固定しておくと、後からサーバーを入れ替えても利用者体験が揺れにくく、移行案件を小さく分割できます。
まとめ
Windows Server 2016 の RDS 環境で RD Connection Broker を別サーバーへ移設し、なおかつ DNS 名（接続先名）も変えたい場合、単体ブローカーを無理にリネームで置き換えるのではなく、RD Connection Broker を HA（高可用性）構成へ移行するのが現実的な解です。SQL・DNS・証明書という周辺要素の整合を押さえれば、段階的な移行でダウンタイムと手戻りを最小化できます。
コメント