Fixing SharePoint DCOM errors the easy way


Tagline: Fix your SharePoint DCOM issues with a single click !
Update 8/05/2014: Scripts were revised to work with Windows Server 2008 R2 and Windows Server 2012 with User Account Control enabled.
Revised post: Fixing SharePoint DCOM errors the easy way - revised
Direct download: DCOMFIX-revised.zip

Problem

The dreaded DCOM error (10016, DistributedCOM, Local Activation, IIS WAMREG admin Service) has seen the light ever since SharePoint 2007. It carried over to SharePoint 2010 and now it seems to SharePoint 2013 as well.

image

Fixing it wasn’t all that hard. You had to identifiy the DCOM app based on the GUID, identify the user(s) affected and then modify the Local Activation permissions accordingly.

Windows Server 2008 R2 and higher made that a bit harder. You first have to set the permissions of the DCOM app in the registry, but that requires changing the owner, granting permissions on the registry key, granting local activation, and then undoing your permission and owner change on the registry key (keep things tidy, you know).

image

Automation

Quite some manual steps to take so I decided to automate them.

At first I decided to PowerShell it, but I’m not a PoSH hero and decided to use some ready available tools, along with a bit of batch scripting.

The two tools required are:

DComPerm

This tool is provided as sample source code by Microsoft, but I’ve included a compiled version in the download. It takes various parameters to list, set or remove permissions on various DCOM objects.

DevxExec

This tool allows you to run a process from different credentials, including TrustedInstaller which will make our life a lot easier.

» Link: DevxExec

image

This tool eliminates the need to change the permissions in the registry, since our TrustedInstaller account already has them and we’re impersonating that account!

Putting it together

I have two scripts using the dcomperm tool; one for displaying the current permissions, one for setting the permissions. Note that the APPID and USER (can be user or group) in both files are currently configured for the IIS WAMREG admin Service and the IIS_IUSRS builtin group. You can change these if you want.

GET:

@echo off

set appid={61738644-F196-11D0-9953-00C04FD919C1}

dcomperm -al %appid% list

echo Done
pause

SET:

@echo off
set appid={61738644-F196-11D0-9953-00C04FD919C1}
set user=IIS_IUSRS
pause
dcomperm -al %appid% set %user% permit level:la
pause

Then I have a corresponding batch file that will run each in elevated mode as TrustedInstaller using devxexec.

devxexec /user:TrustedInstaller get_dcom_perms.cmd

Outcome

The outcome is that we can just run the run_set_elevated script, which will impersonate the TrustedInstaller account and grant local activation permissions to our IIS_IUSRS group for the DCOM app.

image

Download

 


Links to this post

Comments

Tuesday, 5 Sep 2017 04:53 by Gman
Hope you allow for few questions. While browsing to find a easier solution to change file permissions found Subinacl and setACL (cmd line) then ICacls context menu script. Each not having a suggestion on how to change file permission back to Trusted Installer. I'm sure it's simpler than I see. The question is many post are to resolve a DCOM issue by adding SYSTEM to the APPID DCOM launch settings. Could you suggest how this packaged script can be altered to only make this change. Do not see here how the script is adding both the Administrator and NT\SYSTEM (set=). Also would like to exclude from adding "user" to Activation priviledge. Is there any reason this would not apply to Windows 10? Lost a simple PS script that based upon inserting AppID and User name would make the permission change and provide to revert back to Trusted Installer after modified the DCOM launch permissions, not able to locate it. Your considerations are appreciated along with your shared solutions. Please excuse my posting questions.

Wednesday, 6 Sep 2017 01:22 by Steven Van de Craen
Hi Gman, I composed the script by trial and error but am no expert with the toolset. I'm not setting the TrustedInstaller in the script, instead I'm running it *as* TrustedInstaller using the devexec tool. Also, did you check out the update blog post mentioned on top? Cheers, Steven

CAPTCHA Image Validation