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 <DPM Server name>
for example,
SetDPMServer 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