RDS環境で、すでに削除したサーバーが原因と思われる各種エラーが発生すると、システム管理者にとっては不安要素となります。そこで本記事では、重複参照の発見から削除、そして関連する環境設定の見直しまで、具体的な対策方法をご紹介します。
リモートデスクトップサービス（RDS）環境の全体像
RDS（リモートデスクトップサービス）は、複数のWindowsサーバーを連携させながらユーザーに仮想的なデスクトップを提供する仕組みです。代表的な役割としては、RDセッションホスト、RD接続ブローカー、RDライセンス、RDゲートウェイ、RD Web Accessなどがあります。これらが連携することで、ユーザーはインターネット経由や社内ネットワーク経由で安全かつ快適なリモート接続を行うことができます。しかし、一度サーバーを削除したあとに何らかの設定やレジストリ、DNSなどに情報が残っていると、DCOMエラーやRDWebAccessの警告などが発生し続ける場合があります。
なぜ削除済みサーバーが原因になるのか
削除済みのサーバー情報が残存すると、RDS環境のさまざまなコンポーネントが依然としてそのサーバーへ通信を試みるからです。たとえば、RD Web Accessが表示するリモートアプリやデスクトップの一覧が古いホストを参照していたり、DNSに不要なAレコードが残っている場合、利用者やシステム管理者の目には見えないバックグラウンド通信が継続的に失敗し、イベントログにエラーが蓄積されます。その結果、DCOMエラーやIISのログに原因不明の警告が残り、システム監視上のノイズとして扱われるだけでなく、実際の障害の発見を遅らせる原因となります。
よくある残存参照の例
- サーバーマネージャー上のRDS構成情報
- Active Directoryドメインサービス上のコンピューターアカウント
- DNSサーバーの静的レコードまたは動的レコード
- IIS（RD Web Access）サイト構成ファイル
- レジストリ内の各種サービス設定
こうした残存参照は、運用中には気付きにくいものです。次の章では、代表的なエラー例や原因、そしてその解決策を詳しく見ていきましょう。
代表的なエラーメッセージと原因
削除済みサーバーが原因で発生するエラーメッセージは多岐にわたります。以下に、代表的なエラーメッセージと考えられる原因をまとめた表を示します。
| エラーメッセージ例 | 原因 |
|---|---|
| DCOMはコンピューター「XXX」にあるサーバーに通信できません | RDS構成やサービスが削除済みサーバーへの通信を試みている |
| RD Web Access構成から「XXX」を読み込めません | IISでホストするRD Webのアプリケーション構成に古いホストが登録されたまま |
| イベントID 10006 (DCOM) 「サーバーに接続できませんでした」 | Active Directory上やDNS上に古いエントリが残存している |
| イベントID 802 (RemoteAppとDesktop Connection) 「RD Web Accessでリソースが見つかりません」 | RD Web Accessの公開リストに削除済みサーバーのリソースが残存 |
これらのメッセージの多くは、システムやサービスが「存在しないはずのサーバー」に対して通信を試みて失敗することで生じます。次の章では、具体的な対処策を順を追って解説します。
問題を解決するためのステップ
ステップ1: RDSの構成から削除済みサーバーが完全に外れているか確認
まずは、サーバーマネージャー上の「リモートデスクトップサービス」タブや、PowerShellコマンドなどを用いて、当該サーバーがRDS構成からきちんと削除されているかを確認します。
- サーバーマネージャーの確認
- 「サーバーマネージャー」を開き、「リモートデスクトップサービス」または「RDSの展開」などのメニューを選択。
- 展開されたサーバーの一覧に、既に削除したサーバーが含まれていないか確認。
- もし含まれている場合は右クリックなどの操作で除去を試みる。
- PowerShellを使った削除
RDS構成からサーバーを取り除くには、以下のようなPowerShellコマンドが使用されます。
# RDS展開環境で不要なサーバーを削除する例
$ServerToRemove = "旧サーバーのホスト名"
Remove-RDServer -Server $ServerToRemove -Role RDS-RD-SERVER -ConnectionBroker "RD接続ブローカーのホスト名"このコマンドによって、RDSの展開情報から指定したサーバーが削除されます。ただし、サーバーの役割によって-Roleパラメーターの値は適宜変更が必要です。
ステップ2: DNSレコードの確認と削除
RDS構成からの削除が完了しても、DNSサーバーに古いAレコードやCNAMEレコードが残っている場合があります。特に、ローカルのDNSやActive Directory統合DNSを使用している環境では要注意です。
- DNSサーバー管理ツールを開く
- WindowsサーバーでDNS Managerを起動。
- 該当のフォワード ルックアップ ゾーン（例:
example.local）を開き、不要なホスト(A)レコードやCNAMEレコードが残っていないか確認。
- レコード削除
- 削除済みサーバーのホスト名やIPアドレスでレコードが残っている場合は、手動で削除。
- 動的更新を設定している場合でも、何らかの理由で古いレコードが自動削除されないケースがあるため、定期的なチェックが必要。
- DNSキャッシュのクリア
- クライアント、サーバー問わずDNSキャッシュが残っていると、同様のエラーが続く場合がある。
- 次のコマンドでクライアントやサーバーのキャッシュをクリアできる。
ipconfig /flushdnsステップ3: IIS(RD Web Access)での参照をチェック
RD Web AccessはIIS上で動作し、構成情報はIISマネージャーやapplicationhost.configなどに記載されます。とくにリモートアプリの公開やデスクトップの公開リストに古いサーバー情報が残っていると、ユーザーがアクセスした際に不要な問い合わせが走り、エラーを引き起こします。
- IISマネージャーでの確認
- 「IISマネージャー」を起動し、RDWeb関連のサイトやアプリケーションプールを探す。
- サイトの[コンテンツビュー]や[設定]を開き、古いサーバー名が残っていないかをチェック。
- applicationhost.configの確認
C:\Windows\System32\inetsrv\config\applicationhost.configファイルにリモートアプリのリストや接続先サーバーに関する情報が残存している場合があるため、バックアップを取得したうえでテキストエディターで検索し、不要なエントリを手動で削除することを検討する。 - RemoteApp Manager (旧ツール) やRemote Desktopの公開設定
古いサーバーのRemoteAppを削除せず残したままの場合、RD Webから参照されてエラーとなる場合がある。必ず管理コンソール上から削除を実施し、設定情報を最新化しておくことが重要。
ステップ4: Active Directoryのサイトとサービスでの参照削除
Active Directory上のコンピューターアカウントや、サイトとサービスの設定に削除済みサーバーが登録されていることがあります。RDSだけでなく、AD DS上にサーバーオブジェクトとして存在すると様々なトラブルの原因となりえます。
- Active Directoryユーザーとコンピューターから確認
- 「コンピューター」OUまたは該当のOUに、不要なマシンアカウントが残存していないか確認。
- 見つかった場合は右クリックで「削除」を実行。
- Active Directoryサイトとサービス（Sites and Services）
- ドメイン コントローラーやサイトが配置されているツリー内に、削除したはずのサーバー名が残っていないかチェック。
- もし存在する場合は、該当するNTDS Settingsオブジェクトなども含めて削除。
- フェールオーバークラスタやレプリケーション設定の確認
- RDSとは直接関係ないように見えても、クラスター環境やADレプリケーション構成で古いサーバーの参照が残っている場合、DCOMエラーの原因にもなり得る。
- サーバー削除後は、関連するクラスタ構成やレプリケーションリンクも再度点検すると安心。
ステップ5: レジストリやファイルでの手動参照確認
上述した箇所をすべて確認しても問題が解決しない場合、最後の手段としてレジストリエディターや構成ファイル内を直接検索する方法があります。ただし、レジストリを編集する場合は必ず事前にバックアップを取得し、慎重に作業を行ってください。
- レジストリ検索の例
- 「regedit」を起動。
- [編集] → [検索] から、削除済みサーバーのホスト名やIPアドレスを入力して検索。
- 該当箇所が見つかった場合は、内容を確認してから削除または値の修正を実施。
- 設定ファイル、構成ファイルの検索
- IISの
applicationhost.config以外に、アプリケーションによってはXMLファイルやINIファイルで接続先サーバーを設定している場合がある。 - 名前がわからない設定ファイルでも、OSドライブ全体を検索対象にしてサーバー名で全文検索を行うことで発見できる場合がある。
定期的なメンテナンスと監視の重要性
問題を解決できたあとも、RDS環境の構成を変更するたびに不要なデータが残るリスクはつきまといます。以下のようなメンテナンスや監視を継続的に実施することで、余計なトラブルを防ぐことが可能です。
1. 適切なドキュメント管理
サーバーの追加や削除を行う際は、作業手順や手順書を整備し、変更点を共有しておくことが大切です。ドキュメントがあれば、削除後にどこを確認すればよいかの目安になります。
2. イベントログや監視ツールの活用
- イベントビューアー
RDSやDCOMに関連するログを定期的に見直し、エラーや警告が増えていないかチェックします。 - 監視ツール
System Centerなどの監視ツールを活用して、特定のイベントIDが多発した場合にアラートを発する仕組みを導入すると、早期発見につながります。
3. バックアップ戦略とテスト環境の活用
レジストリや設定ファイルを直接編集する際は、必ずバックアップを取得してから実行するようにしましょう。可能であればテスト環境（ステージング環境）で検証を行い、本番環境に反映することで安全性を高められます。
運用効率化とトラブル未然防止のポイント
最後に、RDS環境を安定運用するためのポイントをいくつか挙げます。
権限管理の見直し
RDS環境はさまざまな権限やロールが組み合わさるため、適切に権限を設定しないとトラブルシューティング時に混乱を招きます。サーバーの削除権限やDNSレコードへのアクセス権が誰に与えられているか確認し、必要最低限の権限設定に絞っておきましょう。
PowerShellスクリプトでの一括管理
大規模環境では、手動での確認や削除に時間がかかりミスも起きやすいです。PowerShellスクリプトを活用することで、以下のような作業を自動化できます。
- RDS構成の一括確認と不要サーバーの削除
- DNSレコードの一覧取得と、削除対象のフィルタリング
- Active Directoryサイトとサービスにおけるサーバーオブジェクトの検出と削除
たとえば、次のようなコード例でDNSレコードを一覧取得できます。
# PowerShellを使用してDNSレコード一覧を取得する例
# DnsServerモジュールが必要です
Import-Module DnsServer
$ZoneName = "example.local"
Get-DnsServerResourceRecord -ZoneName $ZoneName -ComputerName "DNSサーバー名" |
Where-Object { $_.RecordType -eq "A" } |
Select-Object HostName, RecordType, @{Name="IPAddress";Expression={$_.RecordData.IPv4Address}}こうしたスクリプトを活用すれば、環境全体を俯瞰しながら不要なレコードやサーバーを定期的に洗い出して削除できます。
定期的なキャパシティプランニング
RDS環境はユーザー数の増減やアプリケーションの追加など、環境変化が発生しやすい基盤です。キャパシティプランニングを怠ると、新たにサーバーを導入したり、逆に削除したときにトラブルが発生しやすくなります。将来的にどの程度のサーバーが必要になるのかを見越し、スムーズなスケールアップ／スケールダウンを行えるよう計画しておきましょう。
まとめ
削除済みサーバーが原因で発生するDCOMエラーやRD Web Accessの警告は、一見すると小さな問題のようでいて、実はRDS環境全体の安定性を揺るがす要因にもなりかねません。特に大規模環境では残存参照が複数にわたることもあり、DNSやActive Directory、IIS構成ファイルなど多岐にわたる調査が必要となります。
本記事で紹介した手順やポイントを押さえておくことで、日頃からRDS環境を綺麗に保ち、障害発生時の原因特定をスピーディーに行いやすくなります。また、PowerShellや監視ツールを活用して定期的に環境をスキャンすることで、運用負荷を大幅に下げることも可能です。削除したサーバーの情報はすべて痕跡を消し去り、クリーンなRDS環境を保つことが、長期的な運用コスト削減とトラブル未然防止の大きなカギとなるでしょう。
コメント