SharePoint 2010: The application-specific permission settings do not grant local activation permission

Article
1/17/2024

Problem

While performing a routine check of the logs of the machine hosting the SharePoint Server 2010 farm Central Administration, I saw the following error in the machine's System log:

Log Name:      System
Source:        Microsoft-Windows-DistributedCOM
Date:          [Date/time]
Event ID:      10016
Task Category: None
Level:         Error
Keywords:      Classic
User:          [DOMAIN\ServiceAccount]
Computer:      [computerName]
Description:
The application-specific permission settings do not grant Local Activation permission for the COM Server application with CLSID 
{61738644-F196-11D0-9953-00C04FD919C1}
 and APPID 
{61738644-F196-11D0-9953-00C04FD919C1}
 to the user [DOMAIN\ServiceAccount]SID (S-1-5-21-3888717925-1584238209-2724737031-1111) from address LocalHost (Using LRPC). This security permission can be modified using the Component Services administrative tool...

I was familiar with this error, having encountered it previously in SharePoint Server 2007 farms and having written about it previously as well. However, this was the first time I had seen error 10016 in a 2010 farm. I found that resolving it for a 2010 farm was a bit more involved than previously and involved a confusing series of layered and dependent permissions. Given the complexity of the resolution, I thought my resolution steps might be useful to share with other SharePoint Server 2010 administrators. Below are my findings and resolution steps.

Discussion

I found that resolving this problem involved the following SharePoint Server 2010 and Windows Server 2008 R2 components:

Active Directory:
- [DOMAIN\myAdministrativeAccount] - the account I decided to use in order to access components and make modifications.
SharePoint Server 2010 application service accounts:
- [DOMAIN\accountname] - the account originally generating the error.
Local Services:
- IIS Admin Service
Component Services:
- IIS WAMREG admin Service
Registry Keys:
- HKEY_CLASSES_ROOT\CLSID\61738644-F196-11D0-9953-00C04FD919C1}
- HKEY_CLASSES_ROOT\Wow6432Node\CLSID\61738644-F196-11D0-9953-00C04FD919C1}
- HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\61738644-F196-11D0-9953-00C04FD919C1}
- HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Wow6432Node\CLSID\61738644-F196-11D0-9953-00C04FD919C1}
- HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Classes\CLSID\61738644-F196-11D0-9953-00C04FD919C1}

Resolution Steps

Identify which account you want to use in order to modify the permissions of machine level services, components and registry keys. For this posting, the local administrator account was used.
Go: Start > Administrative Tools > Component Services. The Component Services control panel appears.
In the console tree, expand: Console Root > Component Services > Computer > My Computer > DCOM Config:.
Search for IIS WAMREG admin Service.
Right-click on this component, and then select Properties. The IIS WAMREG admin Service Properties dialog appears, with the General tab selected by default.
If the Authentication Level dropdown displayed on this tab is disabled, continue to the next step. Otherwise, skip to step 16, below.
Close the Properties dialog and close the Component Services console.
Launch RegEdit.
Save a backup of the current hive.
Look for and verify the existence of each of the following keys:
1. HKCR\CLSID\61738644-F196-11D0-9953-00C04FD919C1}
2. HKCR\Wow6432Node\CLSID\61738644-F196-11D0-9953-00C04FD919C1}
3. HKLM\SOFTWARE\Classes\CLSID\61738644-F196-11D0-9953-00C04FD919C1}
4. HKLM\SOFTWARE\Classes\Wow6432Node\CLSID\61738644-F196-11D0-9953-00C04FD919C1}
5. HKLM\SOFTWARE\Wow6432Node\Classes\CLSID\61738644-F196-11D0-9953-00C04FD919C1}
For each key, perform the following procedure:
1. Right-click on the key, and then choose Permissions. The Permissions for {61738... dialog will appear:.
2. Verify that the desired access account (as discussed in Step 1) is listed. If it is not, add it.
3. Grant this account Full Control.
4. If you are not able to change its permissions, click the Advanced button to open the Advanced Security Settings for {61738... dialog. Select the Owner tab, and then take ownership of the registry key. Then repeat he previous step.
Exit RegEdit.
Stop and restart IIS Admin Service.
Open the Component Services console, and then expand the console tree to find the IIS WAMREG admin Service component.
Right-click on this component, and then Properties. The IIS WAMREG admin Service Properties dialog appears.
Select the Security tab, and then click the Edit button in the Launch and Activation Permissions group. The Launch and Activation Permissions dialog appears.
Add the account referred to by the error message, and grant it both Local Launch and Local Activation permissions.
Click OK. The Launch and Activation Permissions dialog closes.
Click OK again. The WAMREG admin Service Properties dialog closes.
Close the Component Services console.
Stop and restart IIS.

References

Notes

Step 1: It doesn't matter what type of account it is, only that it is important to use the same account for all modifications that you are about to make.
Step 8: HKCR = HKEY_CLASSES_ROOT, HKLM = HKEY_LOCAL_MACHINE.
Step 10: these are the paths to the keys, but you can also find them just as easily by searching for IIS WAMREG admin Service.
Step 10: I only modified the permissions for the first three of these. The other two were modified automatically it seemed.
Acknowledgements: Thanks to Wictor Wilen's article for originally guiding me down the solution path, and to his article commenters Blair and Angus, who alerted me to the possibility that there may be more than one registry key involved. In fact, for my instance, I found more keys than were identified in the article or by the commenters, and I had to modify permissions for the first three of the keys listed above.

Share via