Posting this here because I really think this should have been easier than it turned out.
I was having repeated Event Log errors from source “DistributedCOM” with ID 10016.
The application-specific permission settings do not grant Local Activation permission for the COM Server application with CLSID
{D63B10C5-BB46-4990-A94F-E40B9D520160}
and APPID
{9CA88EE3-ACB7-47C8-AFC4-AB702511C276}
to the user NT AUTHORITY\LOCAL SERVICE SID (S-1-5-19) 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.
In this case, it’s the DCOM AppID for “RunTimeBroker”. This issue is reported commonly enough that it seems to be a pretty widespread issue. Depending on where you check, the fix is either to ignore it (Microsoft) or change DCOM permissions using DCOMCNFG.EXE.
Problem is, the registry keys involved are owned by TrustedInstaller and cannot be modified (not by Administrators, not by LocalSystem).
The first step to changing the permissions is to take ownership of the Registry key affected. That turned out to be more difficult than I expected - the tools I am accustomed to using (regini, subinacl) are all deprecated, difficult to find, and don’t work well with native x64 registry paths.
The solution I ended up with is based on a PowerShell script I found in the Microsoft gallery, with a few of my own additions and some Relevance to wrap it. I’ve uploaded this to bigfix.me in the hopes it may help someone else. The Task there has some useful bits on escalating a PowerShell script’s privilege by adjusting its security token (to include SeTakeOwnershipPrivilege and SeRestorePrivilege), changing ownership of a Registry key, and retrieving and updating ACL rules on a Registry key.
After all that, changing the REG_BINARY values for AccessPermission and LaunchPermission on a DCOM AppID is almost trivial.
https://www.bigfix.me/fixlet/details/25565
Oh yeah, there’s also a useful bit on “relevance-generating-relevance” in the Description tab. I wanted to make it easy to copy this to handle other DCOM Apps that might be giving me trouble, where each app may need a different set of permissions applied, so I built a statement to generate the relevance from a known-good machine. The result of the following relevance statement should be used in the Fixlet Relevance
q: ("exists keys %22" & pathname of it & "%22 whose (not exists values %22AccessPermission%22 whose (it as string = %22" & value "AccessPermission" of it as string & "%22) of it OR not exists values %22LaunchPermission%22 whose (it as string = %22" & value "LaunchPermission" of it as string & "%22 ) of it) of native registry") of keys "HKEY_LOCAL_MACHINE\SOFTWARE\Classes\AppID\{9CA88EE3-ACB7-47c8-AFC4-AB702511C276}" of native registry
A: exists keys "HKEY_LOCAL_MACHINE\SOFTWARE\Classes\AppID\{9CA88EE3-ACB7-47c8-AFC4-AB702511C276}" whose (not exists values "AccessPermission" whose (it as string = "01001480bc000000c80000001400000034000000020020000100000011001400040000000101000000000010001000000000000002008800060000000000180003000000010200000000000520000000200200000000180003000000010200000000000f0200000001000000000014000300000001010000000000050a000000000014000300000001010000000000051200000000001400030000000101000000000005130000000000140003000000010100000000000514000000010100000000000512000000010100000000000512000000") of it OR not exists values "LaunchPermission" whose (it as string = "01001480a8000000b4000000140000003400000002002000010000001100140004000000010100000000001000100000000000000200740005000000000018000b00000001020000000000052000000020020000000018000b000000010200000000000f0200000001000000000014000b000000010100000000000504000000000014000b00000001010000000000050a000000000014000b000000010100000000000512000000010100000000000512000000010100000000000512000000" ) of it) of native registry