Troubleshooting Agent Deployment in Data Protection Manager 2007
Microsoft’s Data Protection Manager (DPM) version 2007 must have an agent installed on any server or workstation that it is going to protect. The installation of the DPM agent requires contact with many different components both locally and across the network. In this and the next two blogs, we will try to cover as thoroughly as possible, all of the local and remote contingencies that must be met in order for the DPM agent to be installed successfully and establish communication with the DPM Server.
These will include the specifics regarding Manual Agent Installation, Local Security on the DPM Agent, Network configuration, WBEMTEST, and DCOM configuration settings in a attempt to provide you with the most common causes of why DPM Agents either will not install or are not able to communicate with the DPM Server after installation. In this blog we'll cover:
- Manual Agent Installation
- Local Security on the DPM Agent
- Domain Controller requirements
Manual Agent Installation: When working on a DPM Agent Installation issue, consider some of the following tests to see where the problem may reside.
1. Try installing the agent manually on the server to be protected and try pushing it from the DPM Server. Do both error out or does one succeed when the other doesn't? If the manual agent installation succeeds and the push fails, then there is likely a problem on the network or with network communication between the DPM Server and the Protected Server or some necessary configuration in the environment with AD or Name Resolution (DNS) that is missing.
2. Try to add the agent server to the DPM Server using both SetDPMServer* as well as the PowerShell script (Attach-ProductionServer.ps1) on the DPM Server.
The SetDPMServer’s syntax is a follows:
SetDPMServer –dpmServerName <DPM Server name>
for example,
SetDPMServer –dpmServerName DPM_Server_01
*Note: The SetDPMServer tool is found on a DPM Agent under the ?:\Program Files\Microsoft Data Protection Manager\DPM\bin\ folder and it is run locally on the system.
The PowerShell script’s syntax below is followed by an example command.
Syntax:
Attach-ProductionServer.ps1 <DPM server name> <production server name> <user name > <password > < domain>
Example:
Attach-ProductionServer.ps1 dpmserver SQLProd1 Admin_VR P@ssw0rd1! Contoso
Use the above power shell script to attach a manually installed agent on a protected server to the DPM Server. Once complete, refresh the agent display in the DPM Console to see if the agent is showing healthy or if an error appears.
3. Disable everything non-essential using MSConfig to see if this will get around the installation issue. This would include anything 3rd party under the ‘Services’ or ‘Startup’ tabs. Clean the agent off of the server and attempt the installation again after the server is rebooted. The agent should be uninstalled using Add\Remove Programs.
4. Remove leftover DPM keys in the registry after removing DPM client using Add\Remove programs. Primarily, the DPMRA keys should be removed. A simple search through the registry should reveal the following locations:
HKLM\Software\Microsoft\Microsoft Data Protection Manager
HKLM\System\CurrentControlSet\Services\DPM** (DPMRA, DPMLA, DpmWriter)
After cleaning up the registry, also delete the "DPMRADmTrustedMachines" and "DPMRADCOMTrustedMachines" groups and remove the DPM server's machine name from the "Distributed COM Users" group. These groups are created during the DPM Agent installation and the DPM Server’s machine account is added to the "Distributed COM Users" group during the agent’s installation. If the local groups cannot be created or any of the three groups populated with the DPM Server’s machine account, then the agent cannot be managed by the DPM Server.
Local Security: In this section of the DPM Agent installation, we discuss the local security modifications that need to take place in order for the DPM agent’s installation to complete successfully and allow the DPM Server to manage the agent. We will discuss the local security settings on non-Domain Controllers first as this is the foundation from which we will make our modifications when discussing how the agent installation is different on Domain Controllers and Failover Cluster nodes.
Non-Domain Controllers:
The DPM Agent installation adds the following locally to the system.
1. DPMRADCOMTrustedMachines local group with the DPM Server’s machine account as the only member.
2. DPMRADmTrustedMachines local group with the DPM Server’s machine account as the only member.
3. The DPM Server’s machine account is added to the Distributed COM Users group.
Check the following settings on the machine where the DPM agent is being installed.
4. The ADMIN$ share on the Protected Machine must be accessible from the DPM Server using the account that you are planning to install the agent with.
5. Make sure that the Local Policy "Access this computer from the network" includes the <DPM Server Machine Account> account and\or "Authenticated Users"
This user right determines which users and groups are allowed to connect to the computer over the network. Terminal Services are not affected by this user right.
Default:
On workstations and servers:
Administrators
Backup Operators
Power Users
Users
Contoso\DPMServer < - - Must be added manually
On domain controllers:
Administrators
Authenticated Users
Contoso\DPMServer < - - Must be added manually
6. Make sure that the Local Policy "Deny access to this computer from the network" does not include the DPM Server's machine account, Everyone, Administrators, or Authenticated Users as these will prevent the DPM Server from connecting.
7. Delete, if it already exists, the leftover ‘Microsoft Data Protection Manager’ folder under C:\Program Files. If you cannot delete the folder, use a tool like Handle.exe or Process Explorer to see what has it locked.
8. Confirm that the PageFile is on the C:\ drive. Not a DPM requirement but has been seen on problem machines. For example, the agent install logs might show that the installation is trying to run on another drive on the system like D:\. After each failed attempt, there is a folder left behind with an alpha-numeric string but no indication that it is DPM related until you browse it’s contents.
9. Run the ‘Set’ command to see if the machine is logged into the domain. Log into the domain if you are not already. Specifically, check the ‘USERDOMAIN=’ value to confirm it contains a domain name and not the local system’s name.
Domain Controllers
Since there are no local accounts or groups on Domain Controllers, the location of the 'Distributed COM Users' group is found under 'Active Directory Users and Computers' snap-in. Look under the 'Built-in' node for this group. At the domain level, the machine account for the DPM Server must be added in order for the agent to be installed on Domain Controllers.
DPMRADCOMTrustedMachines and DPMRADmTrustedMachines local groups cannot exist on any Domain Controllers because they don't have a local accounts database. Manually create these groups in the domain with a "Domain Local\Security Group" context and add the machine accounts for any DPM Servers that will manage the agents. It is recommended to only specify 1 DPM Server and have that DPM server protect all Domain Controllers to avoid agent issues.
NOTE: The default when you create these groups will be to use a Global "Group Scope". The "Group Scope" must be changed to Domain local for this.
Next, we'll discuss troubleshooting Networking and WBEMTEST followed by DCOM.
Author:
Victor Reavis
Support Engineer
Microsoft Enterprise Support
Technorati Tags: DPM,Data Protection Manager
Comments
Anonymous
June 10, 2009
i had the dpm server up and running relatively error free for months. i have about thirty servers setup with four different protection jobs. last week the dpm server could no longer communicate with any agents. i backed up the dpm database and uninstalled and reinstalled dpm, restored the db. and everything was happy. i came in again this morning, the dpm service was 'stopping', i rebooted everything started up o.k. but the dpm server is no longer communicating with the agents. any help appreciated. i have a no-functioning dpm server.Anonymous
September 02, 2009
Could someone from MS please shed some light on the failure of the DPMRA service to start on Win2k8 DCs (in a domain upgraded from 2003). The DPMRA service fails to start with an 1168 error code. We've done all the uninstall/reinstall, manual agent configuration, etc. that we can stand, at this point. I have seen/read nothing on this except for this obscure note. Can we get some more clarification. Surely this issue has been brought to Microsoft's attention already.... *** Problem Description *** In a 2003 domain that is upgraded to a 2008 domain (native mode) DPM agents on the 2008 domain controllers will never communicate to the DPM server. The agent in DPM will show a red x on it. You can remove the agent and then reinstall the agent with the same results. *** Resolution *** DPM requires access to AD keys that only have the Builtin “Users” with permissions on them. During the upgrade of the domain, it removes the NT Authority “Authenticated Users” group from the Builtin “Users” group and thus breaks the DPM server from getting access to these keys. To fix this problem, add the NT Authority “Authenticated Users” group to the Builtin “Users” group in Active Directory Users and Computers and wait for replication to occur (in the event of DPM in a remote site), refresh the DPM agent information in the DPM console and you should be green and good.Anonymous
November 03, 2009
hi i have some windows2003 servers which are not a member of my primary or any other domain controller.is it possible to install dpm agent on these non-domain server. is there any sort of workaround for this ....