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”
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”
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
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”