I recently encountered a DCOM error repeating numerous times in the event logs on a SharePoint server, which eventually led to a resolution I am about to explain. But DCOM errors are certainly not exclusive to SharePoint, and I have personally seen this error occur with a number of applications. The method presented here can be used to try and resolve similar issues regardless of the software involved.
I also need to say that much of this was drawn from a post by Søren Nielsen where he solved a SharePoint DCOM error. If you administer SharePoint, I highly recommend his blog, particularly for more advanced technical topics. He has a knack for tracking down the oddball things that are often found on SharePoint servers. Now, on to the solution to the problem…
The preceeding screenshot is what I was seeing in the event viewer. There are two things to note in this event, besides it being a DCOM error. First, the CLSID is a reference to the software component that generated the error. Second, the description indicates that the user – scrubbed out here – is lacking the “Local Activation” permissions. You can also see a hint as to where you fix the problem – using the “Component Services administrative tool”.
We are first going to search the registry to figure out the name of the software component generating the error. The CLSID is rather lengthy, so I recommend you select the string in the event viewer and press Ctrl-C to copy it to the clipboard. Open the registry editor (Start, Run, and enter regedit). Scroll the left-hand pane all the way to the top and select My Computer, then select Find under the Edit menu. Paste (or type if you must) the CLSID into the Find what textbox, and Keys should be checked under Look at. Click Find Next until the path to the key displayed on the status bar looks like My Computer\HKEY_CLASSES_ROOT\CLSID\yourCLSID and regedit looks something like this:
Take a look at the (Default) value for the name of the component. In some cases like the SharePoint component shown, you may have subkeys. If you do, also take a look at what values are in them. In this case, VersionIndependentProgID was helpful to me as it ultimately contained the name of the component as a prefix to the (Default) value.
We should now have enough information to fix the problem. Click Start, select Run, and enter dcomcnfg to open the Component Services administration snapin. Expand Component Services, then Computer, then My Computer, and finally DCOM Config. On a typical server, you will see many components are installed. Look for one with the name you found in the registry; in my case it was OSearch from the VersionIndependentProgID key as mentioned above. It is critical that you find the right component, otherwise none of the remaining steps are going to fix anything and you may inadvertenly cause other problems, or potentially even open a security hole.
Right-click the component, in my case OSearch, and select Properties, then select the Security tab. The Launch and Activation Permissions is where you fix the problem, so in that groupbox, select Customize if it isn’t already selected then click the Edit button. You should see something like the following:
The user identified in the event needs to be in the list of user names. If not, click Add and use the standard dialogs to add the user to the list. Highlight the user, then ensure that Local Launch and Local Activation are selected, then click OKs until you close all dialogs. That should fix the problem!
It always seems so simple after you know the solution… :)