Hello, Mike Jacquet here, and today I would like to discuss some additional configuration steps that need to be performed on Windows Server 2008 R2 Core servers during installation of the Data Protection Manager (DPM) agent.
When pushing the DPM agent from the DPM console to a Windows Server 2008 R2 Core server it may fail. A manual install of the agent may succeed but the DPM server cannot communicate with the agent on the core server. This is because activation and launch permissions for the DCOM application are not configured properly on Windows 2008 R2 Core servers.
The following error may be logged in the DPM console:
Data Protection Manager Error ID: 270
The agent operation failed on <protected server FQDN> because DPM could not communicate with the DPM protection agent. The computer may be protected by another DPM server, or the protection agent may have been uninstalled on the protected computer.
The following error event may be logged on the Windows Server 2008 Core server:
Log Name: System
Source: Microsoft-Windows-DistributedCOM
Date:
Event ID: 10016
Task Category: None
Level: Error
Keywords: Classic
User:
Computer:
Description:
The machine-default permission settings do not grant Remote Activation permission for the COM Server application with CLSID
{DA6AA17A-D61C-4E9C-8CEA-DB25DEA52A95}
and APPID
{2DF31D97-33CC-4966-8FF9-F47C90F7D0F3}
to the user FOURTHCOFFEE\SLIGHT-DPM01$ SID (S-1-5-21-xxxxxxxxxx-xxxxxxxx-xxxxxxxxxx-xxxx) from address 192.168.1.21. This security permission can be modified using the Component Services administrative tool.
There are a few steps to do before configuring the Windows Server 2008 Core DCOM application settings.
Configure group memberships. There are the three groups we need to check. The DPM Server *must* be a member of the following groups.
- Distributed COM Users
- DPMRADCOMTrustedMachines
- DPMRADmTrustedMachines
Do a manual install of the agent on core server. Follow the DPM 2010 steps from TechNet with the following changes:
a. Do use the most recent version of the RA from the DPM server
DPM 2007 +qfe go to \Program Files\Microsoft DPM\DPM\Agents\RA\2.0.xxxx.0\AMD or i386.
DPM 2010 +qfe go to \Program Files\Microsoft DPM\DPM\agents\RA\3.0.xxxx.0\AMD or i386.
DPM 2012 RTM go to \Program Files\Microsoft System Center 2012\DPM\DPM\ProtectionAgents\RA...
b. Do not worry about passing the DPM server name in during the install.
c. Do not reboot at the finish of the install if prompted.
Run setdpmserver.exe on protected core server using the following command:
setdpmserver -dpmservername <DPM server netBIOS name>
NOTE The executable is located in C:\Program Files\Microsoft Data Protection Manager\DPM\bin\
If you get errors running the above command ignore them for now.
Reboot the Windows 2008 R2 core server.
Run Attach-ProductionServer on the DPM server. In the DPM Management Shell, run Attach-ProductionServer.ps1 as follows:
Attach-ProductionServer.ps1 <DPM server name> <production server name> <user name> <password> <domain>
Once the above steps are completed you may receive the errors in the Symptoms section above.
To configure the DCOM permissions you can build DCOMPERM from the SDK sample or you can download the executable from here.
Typically DCOMCNFG run from a remote server against the Windows Server Core server was the method to manage the Core server’s DCOM settings, however in Windows Server 2008 R2, DCOMCNFG.exe is not able to connect remotely to manage these.
Once you have obtained DCOMPERM.exe the following steps are used to find the application ID for the DPM RA service, view the existing permissions, and edit the settings as needed.
List the DCOM application ID for the DPM RA service:
wmic dcomapp |findstr /i dpm
{2DF31D97-33CC-4966-8FF9-F47C90F7D0F3} DPM RA Service DPM RA Service DPM RA Service
View applicaiton access permissions:
dcomperm -aa {2DF31D97-33CC-4966-8FF9-F47C90F7D0F3} list
Access permission list for AppID {2DF31D97-33CC-4966-8FF9-F47C90F7D0F3}:
<Using Default Permissions>
View application launch permissions:
dcomperm -al {2DF31D97-33CC-4966-8FF9-F47C90F7D0F3} list
Launch permission list for AppID {2DF31D97-33CC-4966-8FF9-F47C90F7D0F3}:
<Using Default Permissions>
Set application launch permissions for DPMRA app:
dcomperm -al {2DF31D97-33CC-4966-8FF9-F47C90F7D0F3} set fourthcoffee\slight-dpm01$ permit level:ll,rl,la,ra
Successfully set the Application Launch ACL.
Remote and Local launch permitted to NT AUTHORITY\SYSTEM.
Remote and Local activation permitted to NT AUTHORITY\SYSTEM.
Remote and Local launch permitted to BUILTIN\Administrators.
Remote and Local activation permitted to BUILTIN\Administrators.
Remote and Local launch permitted to NT AUTHORITY\INTERACTIVE.
Remote and Local activation permitted to NT AUTHORITY\INTERACTIVE.
Remote and Local launch permitted to FOURTHCOFFEE\SLIGHT-DPM01$.
Remote and Local activation permitted to FOURTHCOFFEE\SLIGHT-DPM01$.
Now see if agent communications is working correctly, if not, perform these additional steps.
- Copy the C:\Program Files\Microsoft DPM\DPM\Setup\SetAgentCfg.exe utility on the DPM Server to the Protected server.
- Run the following command:
SetAgentCfg.exe a DPMRA <DPMservername> DPMRADCOMTrustedMachines DPMRADmTrustedMachines
Mike Jacquet | Senior Support Escalation Engineer
Get the latest System Center news on Facebook and Twitter:
App-V Team blog: http://blogs.technet.com/appv/
ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/
DPM Team blog: http://blogs.technet.com/dpm/
MED-V Team blog: http://blogs.technet.com/medv/
Orchestrator Support Team blog: http://blogs.technet.com/b/orchestrator/
Operations Manager Team blog: http://blogs.technet.com/momteam/
SCVMM Team blog: http://blogs.technet.com/scvmm
Server App-V Team blog: http://blogs.technet.com/b/serverappv
Service Manager Team blog: http://blogs.technet.com/b/servicemanager
System Center Essentials Team blog: http://blogs.technet.com/b/systemcenteressentials
WSUS Support Team blog: http://blogs.technet.com/sus/
The Forefront Server Protection blog: http://blogs.technet.com/b/fss/
The Forefront Endpoint Security blog : http://blogs.technet.com/b/clientsecurity/
The Forefront Identity Manager blog : http://blogs.msdn.com/b/ms-identity-support/
The Forefront TMG blog: http://blogs.technet.com/b/isablog/
The Forefront UAG blog: http://blogs.technet.com/b/edgeaccessblog/