Tag: DCOM

Failed Detection of PeopleILM Components and User Profile Synchronisation Service DCOM 10016 Errors

In my last post, I described some of the security considerations that influence an administrator’s response to event log clutter generated by DCOM errors. There are known remedial steps for most of these errors, but the impact of fixing them is often poorly understood, so I tried to clear some of that up. In this post, I’ll review how I’ve responded to the User Profile Synchronisation Service’s DCOM 10016 errors and the corollary MsiInstaller warnings with these security considerations in mind.

Failed Detection of PeopleILM Components

According to Microsoft KB article 2473430, these events occur, “while attempting to manage a User Profile Service Application”. To be more specific, the symptoms are described as:

When you attempt to manage the User Profile Service Application via Central Admin on a SharePoint Server 2010 with the User Profile Synchronization service started after an IISReset, the following warnings are logged in the application log of the SharePoint server…

Personally, I’ve never been able to pin down a firm cause of these events, so I’m happy to go with this Microsoft description, although I struggled to replicate this recently. Regardless, I’ve certainly seen the events in a large number, if not all User Profile Synchronisation Service instances I’ve encountered/built. One thing I find interesting is that these MsiInstaller warnings are accompanied by DCOM 10016 errors on the Windows Installer Service (DCOM component {000C101C-0000-0000-C000-000000000046}) and a few MsiInstaller warnings that closely resemble the Product Version Job DCOM permission errors I’ve spoken to before. This is what we’re looking at:

Continue reading “Failed Detection of PeopleILM Components and User Profile Synchronisation Service DCOM 10016 Errors”

DCOM Security for SharePoint Administrators

In a server administrator’s never-ending battle with log clutter, DCOM errors have proven to be some of the most persistent and poorly-understood events – especially with SharePoint. Our community has been building up remedial practices for the most common of these errors, but changes to the number and complexity of these fixes over the last few years call for a deeper look at what we’re changing, and the effects of these changes beyond a reduction in red and yellow icons in the event logs. In this post I’ll talk about some of the fundamental concepts from a Systems dude’s perspective and along the way I hope to convey a better understanding of Windows itself.

Continue reading “DCOM Security for SharePoint Administrators”

Testing Manage Patch Status

In my last post I discussed how the Product Version Job timer job uses the Windows Installer Service to query the installed state of SharePoint 2010 servers and how the Manage Patch Status page in Central Administration displays this information. I also touched on my reservations about what we can infer from this data. In this post, I’m diving a bit deeper in to that question.
Continue reading “Testing Manage Patch Status”

Inside Manage Patch Status

Back in August, I stumbled across a new type of DCOM 10016 error in SharePoint 2010, caused by the Product Version Job timer job. When I found the error, I was primarily concerned with keeping my event logs clean. Since then, the inelegance of my original work-around and the incomplete picture I contented myself with at the time began to nag at me, but I only recently started digging deeper, prompted largely by the fact that this topic has generated more traffic to my blog in the last quarter than any other.

Continue reading “Inside Manage Patch Status”

Product Version Job: DCOM 10016 strikes again

For some time now, IT professionals have been modifying DCOM activation rights in order to keep their System event logs clean. In SharePoint 2010, that fix became slightly trickier, as permissions to modify the DCOM permissions had to be granted through the registry for the IIS WAM REG admin service and oSearch14 DCOM applications. Having made these fixes, I’ve noticed a new breed of DCOM 10016 error.

The machine-default permission settings do not grant Local Activation permission for the COM Server application with CLSID
{000C101C-0000-0000-C000-000000000046}
and APPID
{000C101C-0000-0000-C000-000000000046}
to the user <FARM ACCOUNT> SID (S-1-5-21-xxxxxxx….) from address LocalHost (Using LRPC). This security permission can be modified using the Component Services administrative tool.

The CLSID for this COM Server Application is MSIServer, used to activate the Windows Installer Service. You can find this by navigating to HKCRAppId and examining the details there:

Continue reading “Product Version Job: DCOM 10016 strikes again”

Building a SharePoint 2007/2010 development environment – Part V: Guest Build

In the first four parts of this series I covered the project objectives and the system design, then turned my attention to the Hyper-V host image build and automated deployment. In this post I describe a SharePoint 2007 virtual machine build.

Where’s the SharePoint 2010 build?

In short, we’re working on it. I’ve produced a new SharePoint 2010 beta virtual machine for this environment but we’re not yet ready to publish build guidance. Stay tuned. Additionally… Continue reading “Building a SharePoint 2007/2010 development environment — Part V: Guest Build”

DCOM IIS WAMREG error 10016 with SharePoint 2010 on Windows Server 2008 R2

Taking a quick break from the SharePoint development series (I hope to finish part IV tonight), Matt Groves has a fix for a slightly more perturbing version of the DCOM IIS WAMREG 10016 error with SharePoint 2010 on Windows Server 2008 R2. His fix works a treat, but I’d recommend granting rights to the WSS_WPG and WSS_ADMIN_WPG local groups in order to make this a permanent fix.