The application-specific permission settings do not grant Local Activation permission for the COM Server application with CLSID
The Error
Event ID: 10016 Source: DistributedCOM
The application-specific permission settings do not grant Local Activation permission for the COM Server application with CLSID
{FDC3723D-1588-4BA3-92D4-42C430735D7D}
and APPID
{83B33982-693D-4824-B42E-7196AE61BB05}
to the user Domain\S-sqlservices SID (S-1-5-21-682003330-1454471165-725345543-8056) from address LocalHost (Using LRPC) running in the application container Unavailable SID (Unavailable). This security permission can be modified using the Component Services administrative tool.
Log Name: System
Source: Microsoft-Windows-DistributedCOM
Date: 7/7/2014 9:00:00 PM
Event ID: 10016
Task Category: None
Level: Error
Keywords: Classic
User: DOMAIN\S-sqlservices
Computer: server.Domain.com
Description:
The application-specific permission settings do not grant Local Activation permission for the COM Server application with CLSID
{FDC3723D-1588-4BA3-92D4-42C430735D7D}
and APPID
{83B33982-693D-4824-B42E-7196AE61BB05}
to the user DOMAIN\S-sqlservices SID (S-1-5-21-682003330-1454471165-725345543-8056) from address LocalHost (Using LRPC) running in the application container Unavailable SID (Unavailable). This security permission can be modified using the Component Services administrative tool.
Solution
I searched in the regedit I found the app id but couldn’t find the CLSID
App ID is for the SQl server integrated manager
To find it go to
So, a quick look at the listed components; and the CLSID can’t be found. That’s okay. Components can be listed in a variety of ways. The CLSID is only used as a last ditch effort if a more readable name is not stored for the component. To find the name for the component, I need to look it up in the registry under HKCR\CLSID, which gives me something much more useful.
Now, all COM security is configured from a little utility named dcomcnfg.exe. More specifically, the permissions I need to deal with are handled under the “DCOM Config” branch of the tree displayed in dcomcnfg.
Console Root -> Component Services -> Computers -> My Computer -> DCOM Config
Now I know that the COM+ server is named Microsoft.SqlServer.Dts.Server.DtsServer, and I know that this is definitely related to SQL Server – Data Transformation Services by the name. Switching back to dcomcnfg, the Microsoft.SqlServer.Dts.Server.DtsServer component is not listed either.
The process listed here is a Windows Service named MsDtsServer110, which is the short name for the SQL Server Integration Services 11.0service. Switching back to dcomcnfg, the SQL Server Integration Services 11.0 component is listed. Perfect. Now all I have to do is configure it.
Fixing the Permissions
The steps listed here are very specific to my error but can easily be adapted to whatever component you need by replacing SQL Server Integration Services 11.0 with the appropriate application name, AppID or CLSID and replacing Network Service with the appropriate Windows user.
-
In dcomcnfg, right-click on SQL Server Integration Services 11.0 and click on Properties.
-
Change to the Security tab.
-
Under Launch and Activation Permissions select Customize.
-
Click [Edit] to display the Launch and Activation Permissions window.
-
Click [Add] to open the Select Users or Groups window.
-
Enter USERNAME.
-
Click [Check Names].
-
Click [OK] to close the Select Users or Groups window.
-
Select USERNAME in the Group or user names list.
-
Check the Local Launch and Local Activation permissions.
-
Click [OK] to close the Launch and Activation Permissions window.
The error should now be resolved. For me, all I have to do is wait 15 minutes to see if the error is logged again. If your error can be duplicated another way, repeat those steps to see if you are still getting the error.
How did I get here?
Perhaps more important than all of this is, “why did I get this error in the first place?” The answer to that, in my case, is that I installed SQL Server 2012 and selected Network Service as the logon account for all the Windows services created by the installer. This is contrary to recommended practices, especially since the SQL Server 2012 installer has the ability to configure Windows accounts specifically for use by the Windows services it creates.
Ref: http://klonkers.blogspot.com/2013/09/sql-server-2012-integration-services.html
Like this:
Like Loading...
