다음을 통해 공유


DPM エージェント (DPMRA.exe) の使用するポートが埋まっており、正常に起動しない事象のトラブルシュート

 

こんにちは。System Center サポート部の石井です。

 

DPM エージェント (DPMRA.exe) が使用するポートが枯渇して正常に起動せず、不正終了してしまう事象についてのトラブルシュートをご紹介します。

 

- 事象発生時のイベント

 

DPMRA が、特定の保護対象にて起動出来なくなり、以下イベントが記録される事があります。

----------------------------

ログの名前: System

イベント ID: 7024

レベル: エラー

説明:

DPMRA サービスは、サービス固有エラー 通常、各ソケット アドレスに対してプロトコル、ネットワーク アドレス、またはポートのどれか 1 つのみを使用できます。 で終了しました。

----------------------------

 

当該事象は、DPM 2007 においては、以下の技術情報にて紹介されている内容ですが、DPM 2010 でも同様の手順で実現可能です。(手順は本記事において、後述いたします。)

 

参考資料:

The DPM protection agent service cannot start in System Center Data Protection Manager 2007

https://support.microsoft.com/kb/947682/en-us (英語)

https://support.microsoft.com/kb/947682/ja (日本語機械翻訳版)

 

考え方は DPM 2007 も 2010 も同じですので、以下を参照いただければと存じますが、最後の SetAgentCfg.exe ツール実行時のみ、DPM 2007、2010 共に、KB 947682 の手順とコマンドが若干違いますのでご注意下さい。

 

- 事象の発生理由

 

DPM エージェント (DPMRA.exe) は、ポート 5718/TCP を使用します。しかしながら、本ポートを他のアプリケーションが既にバインドしてしまっている場合、DPMRA の起動処理時にエラーとなり、サービスが起動できません。

 

この事象は、OS によって異なる、一時ポート (※注) の範囲に DPMRA が使うポート 5718 が存在するかどうかが影響します。

※注: 一時ポートは、ハイポート(high port)、動的ポート (dynamic port)、エフェメラルポート (Ephemeral port) といった呼ばれ方もします。

 

例えば、Windows XP や Windows Server 2003 だと一時ポートの範囲は 1024 から 65535 までの範囲、

Windows Vista や Windows Server 2008 以降の Windows では、一時ポートが 49152 から 65535 までの範囲が既定で割り当てられます。

 

ここまでの話で考えると、確かに Windows XP や Windows Server 2003 だと、DPMRA が使用するポート5718 が偶然、一時ポートに割り当てられてしまうと DPMRA が起動してこないという事象になる点についてはご理解いただけるかと思います。

 

では、何故 Windows Vista や Windows Server 2008 以降の Windows でも当該事象が発生するのか。

 

理由としては、インストールされているアプリケーションに依存して、一時ポートの範囲が変化する場合があるからです。

例えば、弊社製品で Exchange が導入されている場合、当該一時ポートは 1025 ~ 60000 に変化します。

この場合、Exchange のコンポーネントがポート 5718 を偶然バインドしてしまうと、しばらくの間、DPMRA は起動不可能になってしまいます。

 

参考資料:

Windows Server 2003 または Windows 2000 Server を実行しているコンピューター上のエフェメラル ポートの範囲を予約する方法

https://support.microsoft.com/kb/812873/ja

 

Windows Vista および Windows Server 2008 では TCP/IP の既定の動的ポート範囲が変更されている

https://support.microsoft.com/kb/929851/ja

 

Exchange Server の静的ポートの割り当て

https://support.microsoft.com/kb/270836

 

Exchange ネットワーク ポートのリファレンス

https://technet.microsoft.com/ja-jp/library/bb331973.aspx

 

 

- 回避策

 

これを避けるために、DPM 2010 では保護対象のサーバーにて、以下コマンドを実行してポートを既定の 5718 からその他のものに変更します。

 

この際、変更後のポートは、必ず、該当のサーバー上の一時ポートの範囲 “外” に設定いただくことをお勧めいたします。

まずは、どのポートが DPMRA にとって安全に使用出来るか、という点の確認です。

 

1. Windows XP、Windows Server 2003 の場合:

 

Windows XP や Windows Server 2003 の場合、以下の参考情報をご参考いただき、まずは一時ポートの範囲を限定します。その後、一時ポート以外の範囲を確認します。

 

Windows Server 2003 または Windows 2000 Server を実行しているコンピューター上のエフェメラル ポートの範囲を予約する方法

https://support.microsoft.com/kb/812873/ja

※ 一時ポートの範囲を制限しすぎると、ポート枯渇が発生し、ネットワーク通信が一部不能となってしまいますのでご注意下さい。

 

 

2. Windows Vista、Windows Server 2008 以降の場合:

 

Windows Vista、Windows Server 2008 以降の場合、コマンドプロンプトを “管理者として実行” し、以下コマンドを入力して、該当のシステム上の一時ポートの範囲を確認します。

 

> netsh interface ipv4 show dyna tcp

 

出力結果例:

===========================

プロトコル tcp の動的ポートの範囲

---------------------------------

開始ポート : 1025

ポート数 : 58976

===========================

上記の場合、ポート 1025 から 60000 までが使われている、ということを示します。Exchange のメールボックスサーバーにて典型的な出力結果です。

 

上記例だと、ポート 60001 以降、上限となる 65535 までは自由に使えるはず、ということが分かります。

念のため、この 60001 ~ 65535 の範囲においても、その他アプリケーションが使用していないか、ということを確認する必要があります。

 

この際には以下コマンドを使用します。

 

> netstat -ano

 

本コマンドにて、どのポートを、どのアプリケーションがリッスンしているか、という点について確認可能です。

ポート 60001 ~ 65535 の範囲で、何かアプリケーションが使っていないかということは、該当のシステム上で何度か上記コマンドを実行し、統計的に確認いただくことをお勧めします。

(一般的に、一時ポート以外の範囲のポートは、システム上に存在するアプリケーションにより自由にバインド可能ですが、えてして常時稼働しているサービスが決めうちで使用するポートとなり、一定のものとなる場合が多いです。)

 

例えば、以下出力結果が記録されたとします。ポート番号はあくまでも例です。

--------------

TCP [::]:64330 [::]:0 LISTENING 3603

--------------

 

この場合、プロセス ID 3603 に該当するプロセス名は以下コマンドで確認可能です。

 

> tasklist

 

--------------

test.exe 3603 TestApplication

--------------

 

test.exe というプロセスは、このシステムでは 64330 をバインドする、ということが確認出来ます。

例えば、test.exe はサービスとして常時起動しており、常時この 64330 のみをバインドしている、ということを、時間をわけて何度か netstat –ano コマンドを実行し、裏を取ります。

 

このように、一時ポートの確認と、一時ポート以外で特定のアプリケーションが特定のポートを使っていないか確認いただき、それ以外のポートに対して DPMRA のポートを設定します。

 

- DPMRA のポート変更手順

 

さて、DPMRA のポート変更の方法ですが、以下の通り、KB 947682 と比べて若干コマンドが変更されています。(コマンドの引数に 2 つのポート番号を記載するよう、KB には紹介されておりますが、実際には変更先のポート番号 1 つを指定する方法が正しいものとなります。)

 
保護対象側のコマンド:

> SetAgentCfg e dpmra < 代替ポート番号>

※ SetAgentCfg.exe ツールは、DPM サーバーの "Program Files\Microsoft DPM\DPM\Setup" 配下にありますので、事前に保護対象にコピーします。

尚、ポート 5719 は DPMRA ではなく、DPM エージェント インストール時に必要となる DPM エージェント コーディネーターと呼ばれるコンポーネントが使用するものですので、通常、特に気にする必要はありません。

 

上記実行にて、保護対象側の設定は完了です。DPMRA サービスを再起動していただき、”netstat –ano” コマンドを実行することで、該当のポートが LISTENING 状態となることを確認して下さい。

続いて、DPM サーバー側でも、上記反映を行う為、SetAgentCfg コマンドを実行する必要があります。(

DPM サーバー側からのデータ リストア時に保護対象でのポート変更を行った旨を知らせる、という目的です。)

DPM サーバー側のコマンド:
> SetAgentCfg s < 保護対象のFQDN> <変更後のポート番号>

ご注意いただきたい点としては、DPM 2007、2010 の両方において、最新のロールアップ修正プログラムの適用が必要である点です。
古いバージョンですと、SetAgentCfg に "s" オプションが存在しない場合がありますので、SetAgentCfg /? と入力し、"s" オプションが存在するかご確認下さい。

最後に、DPM サーバー上でも、DPMRA サービスを再起動いただき、設定を反映させます。(DPM サーバーでの DPMRA サービスの再起動の際には、現在進行中のバックアップやリストア ジョブが無いことをご確認下さい。)

ご参考:

DPM 2010 の最新ロールアップ
https://blogs.technet.com/b/systemcenterjp/archive/2011/03/07/dpm-2010-2-2011-3.aspx

DPM 2007 の最新のロールアップ
https://blogs.technet.com/b/systemcenterjp/archive/2010/10/22/dpm-2007-sp1-2010-10-9.aspx

- 補足 DPM 2012/DPM 2012 R2 について

本問題については、System Center 2012 Data Protection Manager (DPM 2012) および System Center 2012 R2 Data Protection Manager (DPM 2012 R2) でも発生します。

ただし、DPM 2012 および、DPM 2012 R2 環境では、本機能が未搭載となっております。

(2014.9.30 追記)
DPM 2012 SP1 については UR7 を、DPM 2012 R2 については、UR3 を適用することで、本機能を利用することができます。
なお、適用に際して保護対象サーバーの再起動が必要となります。

Update Rollup 7 for System Center 2012 Data Protection Manager SP1
https://support.microsoft.com/kb/2966012/ja

Update Rollup 3 for System Center 2012 R2 Data Protection Manager
https://support.microsoft.com/kb/2966014/ja

 

 

以下の参考情報内の Resolution 2 にて、5718, 5719 ポートを事前に予約し DPM からのみ使用できる構成にて利用することも可能です。

 

DPM Support Tip: ID 41 Details: No connection could be made because the target machine actively refused it (0x8007274D)

https://blogs.technet.com/b/dpm/archive/2012/10/15/dpm-support-tip-id-41-details-no-connection-could-be-made-because-the-target-machine-actively-refused-it-0x8007274d.aspx