none
DPM error with externally trusted DC installed as untrusted

    Question

  • DPM Fails with error ID: 316 which points to a firewall error.

    However no traffic is being blocked on any of the firewalls, and the same firewall settings work fine with non-dc computers on the same domains.

    From the PS server log a dcom error is indicated (error code: 0x80070005). I tried various methods I found for solving the dcom error with no success.

    3 Different domains experience exactly the same behaviour. All are trusted with two-way external trust and clients installed with the untrusted computer method which works fine for member servers.

    The agent attaches ok with success at the end, but the status gives "error" with the error ID 316 as stated in the beginning.

    Somehow the DC does not seem to get the dcom access to DPM server (in my opinion) even though the domain user created for dpm agent is in all the correct groups. 

     

    Thanks for any ideas.

     

    -Reima

    Thursday, October 14, 2010 1:27 PM

Answers

  • Reima,

    DPM does not require its accounts to be administrators to function. If you have to put such accounts in the Administrators group to function that usually indicates the default group memberships or user rights are not configured as expected.

    Ensure the local Users group on the protected server contains Authenticated Users. Also make sur the DPM accounts are in the Distribured COM Users group.


    Steve L [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights.
    Thursday, October 28, 2010 9:59 AM
    Moderator

All replies

  • Reima,

    Is there an error code in the ID 316 error? Also let's test various connectivity between the DPM server and protected server. We'll need to test basic connectivity, SMB, RPC, and WMI/DCOM.

    The commands below need to be run from an administrative command prompt. It is a good idea to test from both the DPM server and the protected server. The account used should be an administrative account on both servers.

    Basic connectivity is tested by using ping. If ICMP traffic is blocked ping commands will fail but that is OK.
      ping <protected server name>

    Next test SMB (file sharing).
      net view \\<protected server name>

    Now test RPC and connectivity to Service Control Manager (SCM). This displays a list of services on the remote server when successful.
      Sc \\<protected server name> query

    Lastly test WMI/DCOM. When successful this command lists some basic information about the remote server.
      Wmic /node:"<protected server name>" OS list brief

    If any of the tests after ping fail that may be where the problem is.

    /Steve


    Steve L [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights.
    Friday, October 15, 2010 1:07 PM
    Moderator
  • I will try to test the connections soon. Obviously I have to login to servers with the created ms dpm account which does not by default allow user logon.

    Tests with basic administrative account (note that some of these should not work as domain administrator accounts are not added to foreign domain administrative groups).

    from DPM server:

    Ping ok

    net view ok

    sc not ok

    wmic not ok

    From PS :

    ping ok

    net view ok

    sc not ok

    wmic not ok

    Error code is : Internal error code: 0x8099090E

     

    I will redo the tests with appropriate accounts when I get the time to do so.

    Monday, October 25, 2010 12:48 PM
  • We'll need to see the results when using the appropriate accounts. If you don't use an account that is an administrator on the remote box then the wmic command will fail.

    DPM and the protected server will need to those two failing accesses to work in order for protection to work.

    /Steve


    Steve L [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights.
    Monday, October 25, 2010 5:42 PM
    Moderator
  • Ok, problem is now "solved".

    As I started testing, I had to add the dpm created account in other domain to dpm server local administrators group (over trust). That made it work.

    I first tried to add the mentioned account to dpmradmtrustedmachines and msdpmtrustedmachines groups (where the other accounts reside that are made for other domain machines that are not domain controllers and work fine) but that did nothing.

    I must say I dont like the idea that I have to put an account made for dpm that is in other domain to my backup servers local administrators group.

    Any idea what lesser group or access would be enough?

    -Reima

    Wednesday, October 27, 2010 8:30 AM
  • Well it was not quite as solved as I hoped. Win 2003 DC works now fine, but win2008r2 dc gives the following :

    Affected area: Computer\System Protection
    Occurred since: 28.10.2010 10:50:44
    Description: The replica of System Protection Computer\System Protection on xxx.yyy.fi is inconsistent with the protected data source. All protection activities for data source will fail until the replica is synchronized with consistency check. You can recover data from existing recovery points, but new recovery points cannot be created until the replica is consistent.

    For SharePoint farm, recovery points will continue getting created with the databases that are consistent. To backup inconsistent databases, run a consistency check on the farm. (ID 3106)
     DPM cannot create a backup because Windows Server Backup (WSB) on the protected computer encountered an error (WSB Event ID: 517, WSB Error Code:  0x8078001D). (ID 30229 Details: Internal error code: 0x809909FB)
     More information
    Recommended action: For resolution actions and more information on the WSB error, go to http://technet.microsoft.com/en-us/library/cc734488(WS.10).aspx.
     Synchronize with consistency check.
     Run a synchronization job with consistency check...
    Resolution: To dismiss the alert, click below
     Inactivate alert

    Synchronization with consistency check takes a long time and is no help.

    -Reima

    Thursday, October 28, 2010 8:45 AM
  • Reima,

    DPM does not require its accounts to be administrators to function. If you have to put such accounts in the Administrators group to function that usually indicates the default group memberships or user rights are not configured as expected.

    Ensure the local Users group on the protected server contains Authenticated Users. Also make sur the DPM accounts are in the Distribured COM Users group.


    Steve L [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights.
    Thursday, October 28, 2010 9:59 AM
    Moderator
  • If you are getting a WSB errors then I gather you are trying to do System State backups in your protection group. System State protection relies upon the WSB functionality on the protected server. Hence WSB issues need to be troubleshot on the protected server.

    Check the event logs on the protected server for errors. Also spin this thread off to a new question on the DPM System State forum.

    /Steve


    Steve L [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights.
    Thursday, October 28, 2010 10:03 AM
    Moderator
  • Hello

    I have decided not to pursue solutions for these problems. W2008 DCs will not be supported for dpm backups except in our primary domain. The required W2003 DCs will have their backup account in DPM server administrators group.

    This problem is easily enough replicated for hopefully the DPM folks to solve. I do not have the time to do the endless troubleshooting DPM requires when the computers are not in the same domain. Actually there are enough issues with WSB / BMR backups with computers on the same domain to keep me busy.

    Thank you for your help.

    PS. Local users group does contain authenticated users, and dpm accounts are in distributed com users group. Problem goes deeper than that.

    -Reima

     

    Wednesday, November 10, 2010 12:28 PM
  • Closing the thread. If the issue is not resolved please re-open the thread.
    Thanks, Praveen D [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights.
    Saturday, November 20, 2010 6:08 PM
    Owner