Home > Data Protection Manager, Forefront TMG 2010 > Configuring Forefront TMG for Microsoft System Center Data Protection Manager (DPM) 2010

Configuring Forefront TMG for Microsoft System Center Data Protection Manager (DPM) 2010

December 21, 2010

Microsoft System Center Data Protection Manager (DPM) 2010 is a management product that provides data protection for Windows systems. More advanced than Windows Backup, DPM uses Protection Agents that provide advanced capabilities. Getting the DPM server to communicate with the Protection Agent installed on a Forefront TMG 2010 firewall can be challenging, however. DPM server-to-agent communication takes place over several non-standard ports, and it also relies on DCOM. Unfortunately the Forefront TMG RPC filter does not fully support DCOM , so we’ll need to employ a workaround to ensure that DPM communication works correctly.

[Note: Many resources that I found on the Internet detailing how to configure TMG for DPM were incorrect and didn’t work. Those that did work didn’t explain why, involved unnecessary steps, or included very broad rule sets that allowed more access to the TMG firewall than absolutely necessary. In this post I’ll provide a definitive and comprehensive guide to preparing the TMG firewall to work with DPM and its Protection Agent, while at the same time adhering to the principle of least privilege and maintaining the lowest possible attack surface.]

As stated, DPM uses Protection Agents installed on each system it manages and protects. This agent can be deployed remotely from the DPM console or installed manually and later ‘attached’. When installing the Protection Agent on a Forefront TMG 2010 firewall it is recommended that the agent be installed manually following the instructions here. Since there is no system policy access rule for DPM, we’ll need to configure access rules to allow the required communication to and from the Protection Agent on the TMG firewall and the DPM server. Begin by creating three new protocols as follows:

DPM Agent Coordinator – TCP 5718 outbound
DPM Protection Agent – TCP 5719 outbound
DPM Dynamic Ports – TCP 50000-50050 outbound

Create a Computer or a Computer Set network object that includes the IP address of your DPM server. DO NOT add the DPM server to the Enterprise Remote Management Computers or Remote Management Computers network objects.

Next, create an access rule called DPM [Inbound]. The action will be allow and the protocols will include the three new protocols you just created, along with Microsoft CIFS (TCP) and RPC (all interfaces). The source will be the DPM server and the destination will be Local Host for all users. Now right-click on the access rule and choose Configure RPC protocol.

Uncheck the box next to Enforce strict RPC compliance and choose Ok.

Create another access rule called DPM [Outbound]. The action will be allow and the protocols will include only DPM Agent Coordinator [5718] and DPM Dynamic Ports [50000-50050]. The source will be Local Host and the destination will be the DPM server for all users. Once complete the rule set should look like this:

Next, right-click the Firewall Policy node in the TMG management console navigation tree and select All Tasks | System Policy | Edit System Policy. Under the Authentication Services configuration group highlight Active Directory. Select the General tab and uncheck the box next to Enforce strict RPC compliance.

The last step required to allow the DPM server to communicate with a Protection Agent installed on the TMG firewall involves making registry changes to restrict RPC communication to a specific range of ports. This is necessary because, as I mentioned earlier, the TMG RPC filter does not fully support DCOM and is unable to manage the dynamic port assignments required for this communication. This change must be made to both the TMG firewall and the DPM server. To make this change, open the registry editor on each system and navigate to the HKLM\Software\Microsoft\Rpc\Internet key.

Create the following new keys:

Ports – REG_MULTI_SZ, 50000-50050
PortsInternetAvailable – REG_SZ, Y
UseInternetPorts – REG_SZ, Y

You can download a .reg file and the TMG access policies here.

Note: For this limited demonstration I have chosen to restrict the dynamic port range to 50 ports. In a real production environment, you may need to increase this limit. An excellent reference article that includes a formula to determine the number of ports required can be found here.

Once the registry changes have been made, the system will have to be restarted for the changes to take effect. After both systems are back online, install the Protection Agent manually on the TMG firewall and then attach the agent in the DPM management console. You can now manage TMG firewall protection in DPM just as you would any other Windows system.

  1. March 17, 2011 at 3:52 am

    Thanks very much. Very useful article. I would like to point out that the registry key is wrong though.

    You have to create HKLM\Software\Microsoft\RPC\Internet key and create Ports,PortsInternetAvailable and UseInternetPorts inside the Internet key (folder)

  2. March 17, 2011 at 6:39 am

    Thanks for bringing that to my attention! I’ve updated the post accordingly (the downloadable registry file was correct though).

  3. Chris Renault
    March 24, 2011 at 5:54 am

    Hello Richard, first of all I would like to say thanks for posting the guide and so many useful information. I followed the guide and registry modifications in order to allow my DPM server to attach the already installed DPM agent on my TMG.

    Despite all the rules and settings, DPM fail to attach the TMG server agent. It shows up an error logged as:

    Agent operation failed. (ID: 370)
    The server mytmgserver.mydomain.net could not be found in Active Directory. (ID: 31144)

    Server shows up in domain, no problems, fully updated and all.

    I’m stuck here. Any ideas ?

  4. March 29, 2011 at 1:33 pm

    I’ve done this a few times without issue, so it should work. Double-check and make certain you’ve completed all of the steps. The RPC compliance setting on TMG is key. If you’re confident you have everything right, check the TMG logs to see if anything is being denied by policy.

  5. Fahad Anis
    October 19, 2011 at 3:33 am

    Thanks sir . . After reading your blog i m able to protect TMG via DPM.

  6. October 19, 2011 at 4:11 pm

    Glad you found the post helpful! 🙂

  7. CTV
    November 3, 2011 at 1:14 am

    Question 1: Are there reasons why the dynamic ports range is set to start at 50000?
    Question 2: Are there reasons why the dynamic ports range is set to end at 50050 (50 ports)?

    Reason I am asking is that I found another article relating to setting a port range on a different calculation here: http://blogs.technet.com/b/dpm/archive/2011/06/28/how-to-limit-dynamic-rpc-ports-used-by-dpm-and-protected-servers.aspx

    Basically the calculation is as follows (extract from the article):

    “First pick the port range
    When determining the number of ports to use the recommended formula is as follows:

    Start with (minimum of 100 + (number PS * 10)) PS = Protected Servers.

    A DPM server protecting 10 servers needs 200 ports at a minimum. Note that all protected servers are included in the port calculation, not just the ones on the other side of the firewall. This configuration limits the ports for all dynamic RPC traffic on the DPM server.

    Implement the port range
    The example below allocates 200 ports starting at 50100. This is done on the DPM server and protected servers on the other side of the firewall.”

    Question 3: Why did he suggest to start at 50100 and not say 50000?
    Question 4: Is there merit in choosing the range based on his calculation?

    Thanks

  8. November 4, 2011 at 11:18 am

    Let me start by stating that I am not a System Center Data Protection Manager expert. My article was part of a proof-of-concept project I participated on with a customer who was deploying SCDPM and needed to protect their Forefront TMG 2010 firewalls. My configuration is based on a small virtual lab environment where we were attempting only to protect a single system. That said, let me answer your questions…

    #1: No, but this is the generally accepted range of ephemeral (high) ports that is typically not in use by other applications.
    #2: I chose to limit the dynamic port range for my test at 50 out of convenience. It certainly worked for my environment, but I certainly understand J.C.’s reasoning for having more ports open to support additional protected servers.
    #3: Again, this is just a preference, but based on generally accepted best practices for ephemeral port reservations for RPC.
    #4: Without question. J.C.’s article is an excellent reference…thanks for bringing that to my attention. I’ll be updating the post and using that as a reference.

  9. CTV
    November 6, 2011 at 10:33 pm

    Richard

    Many thanks for getting back to me. Your article was very insightful and was able to assist me by configuring out TMG server to work with DPM.

    Thank you again for all your help! Much appreciated

    CTV

  10. Marc
    March 21, 2012 at 2:45 am

    Thanx richard,
    helped me a lot.!! much appreciated .

    marc..

  1. January 13, 2012 at 9:39 am
  2. April 23, 2014 at 8:43 am
  3. July 13, 2014 at 8:36 pm
Comments are closed.