I occasionally encounter errors when trying to install a software package on Windows with the less than helpful message that the Windows Installer Service could not be accessed.

A typical search will return lots of results about reinstalling the MSI Installer service, changing registry entries, and otherwise tinkering with low-level Windows components, but the problem is actually much simpler. The user trying to run the MSI Installer has been denied rights to run it.

The MSI Installer – the Windows Installer service – is a COM (Component Object Model) component. Windows uses a large number of COM comments for the operating system. Like files, users are granted permissions to access and run COM comments. This normally is not an issue. At least it wasn’t until Windows 10/Windows Server 2016. But a bug appears to have crept into Windows that will randomly revoke a user’s permission to run one or more COM objects, the MSI Installer being one of them. Antivirus programs seems to aggravate this, but I’ve encountered the problem on systems with only Windows (or Microsoft) Defender Antivirus.

This shows up in the System Event Log as errors or warnings with Event ID 10016. The APPID identifies the COM component to which permissions have been denied. APPID 000C101C-0000-0000-C000-000000000046 is the MSI Installer, which means the user was not able to install a software package. And as this error shows, not even the SYSTEM user is immune.

Fixing permissions for a COM component usually involves wading through the hundreds of components in the Component Services MMC. And since not every component has a friendly name – some only use their application ID – this can be a daunting task. Thankfully, PowerShell makes this rather easy.

Some years ago, Tony Pombo wrote the module DCOMPermissions to repair a user’s permissions for a COM component. This was originally posted to the TechNet Gallery which disappeared when Microsoft shut it down. For a while it was only available through Internet Archive’s Wayback site, but recently it has been posed to the PowerShell Gallery and now has GitHub page as well.

DCOMPermissions: PowerShell Gallery
DCOMPermissions: GitHub

This module made it easier to fix the permission errors, but I got tired of having to search the System Event Log to find the users and components whose permissions needed to be fixed. So I wrote a PowerShell script – Fix-DCOMPermissions – that searches the last six weeks of events in the System Event Log looking for Event ID 10016 events and then fixes any permission errors using the DCOMPermissions module. The module can either be installed from the PowerShell Gallery or available as a .psm1 file. The script checks to see if it’s already installed, and if if not, looks for the module file in directory specified by the ModulePath parameter. This is optional, and if not provided, it looks in the directory where the script is located (using the $PSScriptRoot variable).

When you run the script, it displays the application ID and user for the permissions it fixed. Since there can be multiple entries in the System Event Log for the same application ID and user, it fixes each only once. This is what the output looks like.

PS C:\Fix-DCOMPermissions> .\Fix-DCOMPermissions.ps1
Found module "C:\Fix-DCOMPermissions\DCOMPermissions.psm1" ... importing ...
Fixing DCOM permissions: APPID = {316CDED5-E4AE-4B15-9113-7055D84DCC97}, User = NT AUTHORITY\SYSTEM
Fixing DCOM permissions: APPID = {316CDED5-E4AE-4B15-9113-7055D84DCC97}, User = PROXIMA\Charles
Fixing DCOM permissions: APPID = {15C20B67-12E7-4BB6-92BB-7AFF07997402}, User = PROXIMA\Charles

I’ve packaged the Fix-DCOMPermissions script and DCOMPermissions module in a zip file so you don’t need to install the module from the PowerShell Gallery unless desired. (The module is distributed under the terms of the GNU Lesser General Public License Version 2.1.)

Fix-DCOMPermissions Package