locked
Cannot install DPM 2012 sp1 agent to TMG array RRS feed

  • Question

  • When attempting to install a DPM 2012 SP1 agent to either or both of the TMG servers (domain joined) I receive the following error.

     

    Install protection agent on server.domain failed:

    Error 400: The DPM server was unable to retrieve information about the remote system using the Windows Management Instrumentation (WMI) service on server.domain.

    Error details: The RPC server is unavailable

    Recommended action: From the command prompt, type DPMAgentInstaller.exe [dpmservername] to install the protection agent on the protected computer. Then attach the protection agent to the DPM server using the Protection Agent Installation Wizard.

    OR

    Verify the following:

    1) server.domain is online and remotely accessible from the DPM server.

    2)A firewall if enabled on server.domain is not blocking WMI requests from the DPM server.

    3) The WMI service on server.domain is running.

     

    Using TMG logging we can see that no traffic is blocked and we have disabled RPC strict enforcement on the rules for DPM communication inbound and outbound. I can validate that this is a Kerberos authentication issue as the DPM agent can be configured as a non-domain/workgroup agent with NTML auth enabled. In this scenario the agent communication is OK, however - I need to run BMR backup on this server for DR scenarios. I also cannot backup as VHD as this is a VMware environment.

     

    This is the Kerberos error logged in the event viewer.

     

    An account failed to log on.

    Subject:
     Security ID:  NULL SID
     Account Name:  -
     Account Domain:  -
     Logon ID:  0x0

    Logon Type:   3

    Account For Which Logon Failed:
     Security ID:  NULL SID
     Account Name:  account name
     Account Domain:  Domain

    Failure Information:
     Failure Reason:  An Error occured during Logon.
     Status:   0xc00002ee
     Sub Status:  0x0

    Process Information:
     Caller Process ID: 0x0
     Caller Process Name: -

    Network Information:
     Workstation Name: -
     Source Network Address: -
     Source Port:  -

    Detailed Authentication Information:
     Logon Process:  Kerberos
     Authentication Package: Kerberos
     Transited Services: -
     Package Name (NTLM only): -
     Key Length:  0

    This event is generated when a logon request fails. It is generated on the computer where access was attempted.

    The Subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.

    The Logon Type field indicates the kind of logon that was requested. The most common types are 2 (interactive) and 3 (network).

    The Process Information fields indicate which account and process on the system requested the logon.

    The Network Information fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.

    The authentication information fields provide detailed information about this specific logon request.
     - Transited services indicate which intermediate services have participated in this logon request.
     - Package name indicates which sub-protocol was used among the NTLM protocols.
     - Key length indicates the length of the generated session key. This will be 0 if no session key was requested.


    Thursday, May 9, 2013 10:07 PM

Answers

  • Opened a case with MS Support on this one and found that the issue was related to RPC filtering in the TMG rule. While we had a rule to allow all traffic between DPM and the TMG servers, we were still failing to communicate but TMG did not show any traffic blocked.

    Once we followed the setup document here http://technet.microsoft.com/en-us/library/cc512491%28v=ws.10%29.aspx for DPM (except for the part about limiting RPC traffic as this would limit ALL RPC traffic to TMG and we didn't want to do that), our DPM communication was OK but then all AD traffic failed (TMG had been set up as a domain member). The problem centred around this step in the documentation "Turn off RPC filtering for RPC (all interfaces). Under Protocols, click RPC (all interfaces), and then click Edit. Click the Parameters tab, under Application Filters clear the check box for RPC Filter, click OK, and then click Next.", which effectively killed all RPC communication to the domain controllers. So a rule in TMG at the top level to allow RPC filtering to the DC's and DPM rule not in the number 1 spot then gave us both AD an DPM communication.

    Ultimately TMG probably shouldn't be domain joined but if you come across a case where it is I hope this info will help.

    • Marked as answer by Danny Grasso Wednesday, May 22, 2013 11:13 PM
    Wednesday, May 22, 2013 11:12 PM

All replies

  • Hi,

    I guess you have tested RPC communications with WBEMTEST between both machines?

    Thursday, May 16, 2013 12:24 PM
  • Opened a case with MS Support on this one and found that the issue was related to RPC filtering in the TMG rule. While we had a rule to allow all traffic between DPM and the TMG servers, we were still failing to communicate but TMG did not show any traffic blocked.

    Once we followed the setup document here http://technet.microsoft.com/en-us/library/cc512491%28v=ws.10%29.aspx for DPM (except for the part about limiting RPC traffic as this would limit ALL RPC traffic to TMG and we didn't want to do that), our DPM communication was OK but then all AD traffic failed (TMG had been set up as a domain member). The problem centred around this step in the documentation "Turn off RPC filtering for RPC (all interfaces). Under Protocols, click RPC (all interfaces), and then click Edit. Click the Parameters tab, under Application Filters clear the check box for RPC Filter, click OK, and then click Next.", which effectively killed all RPC communication to the domain controllers. So a rule in TMG at the top level to allow RPC filtering to the DC's and DPM rule not in the number 1 spot then gave us both AD an DPM communication.

    Ultimately TMG probably shouldn't be domain joined but if you come across a case where it is I hope this info will help.

    • Marked as answer by Danny Grasso Wednesday, May 22, 2013 11:13 PM
    Wednesday, May 22, 2013 11:12 PM
  • RPC filtering (even though RPC traffic was allowed) was the problem Roberto so you were on the right track :)
    Wednesday, May 22, 2013 11:13 PM