I have recently been building out a few MOSS 2007 environments for a client with a big Ultima online fan Erik. We have decided in the build process of each environment to include SP1 because of all of the bug fixes that have been resolved in this service pack. We are building your classic environments POC, Test, UAT, Prod and while building our POC and Test environment we noticed an error in the event log immediately after applying MOSS 2007 SP1. The error that was showing up in the event viewer was:
Application Event log error:
Event Type: Error
Event Source: Office SharePoint Server
Event Category: Office Server Shared Services
Event ID: 6482
Date: 1/22/2008
Time: 12:40:03 PM
User: N/A
Computer: MOSS01
Description:
Application Server Administration job failed for service instance Microsoft.Office.Server.Search.Administration.SearchServiceInstance (a287d59e-47fa-4182-8eba-9b0f52f27f5b).
Reason: Retrieving the COM class factory for component with CLSID {3D42CCB1-4665-4620-92A3-478F47389230} failed due to the following error: 80070005.
Techinal Support Details:
System.UnauthorizedAccessException: Retrieving the COM class factory for component with CLSID {3D42CCB1-4665-4620-92A3-478F47389230} failed due to the following error: 80070005.
at System.Runtime.Remoting.RemotingServices.AllocateUninitializedObject(RuntimeType objectType)
at System.Runtime.Remoting.RemotingServices.AllocateUninitializedObject(Type objectType)
at System.Runtime.Remoting.Activation.ActivationServices.CreateInstance(Type serverType)
at System.Runtime.Remoting.Activation.ActivationServices.IsCurrentContextOK(Type serverType, Object[] props, Boolean bNewObj)
at Microsoft.Office.Server.Search.Administration.Gatherer.get_AdminObject()
at Microsoft.Office.Server.Search.Administration.Gatherer.ProvisionGlobalProperties()
at Microsoft.Office.Server.Search.Administration.SearchServiceInstance.Synchronize()
at Microsoft.Office.Server.Administration.ApplicationServerJob.ProvisionLocalSharedServiceInstances(Boolean isAdministrationServiceJob)
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
System Event log error:
Event Type: Error
Event Source: DCOM
Event Category: None
Event ID: 10016
Date: 1/23/2008
Time: 1:23:53 PM
User: <UserName>
Computer: <Computer Name>
Description:
The application-specific permission settings do not grant Local Activation permission for the COM Server application with CLSID
{3D42CCB1-4665-4620-92A3-478F47389230}
to the user NORTHAMERICA\srvspdev1 SID (S-1-5-21-6776287-1952083785-2110791508-434436). This security permission can be modified using the Component Services administrative tool.
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
So our first job was to identify the CLSID {3D42CCB1-4665-4620-92A3-478F47389230} which was the culprit causing the issue. I took a look in the registry by going to START>>RUN>>REGEDIT then navigated under HKEY_CLASSES_ROOT\CLSID and began searching for the app id above. Well I found it and did some digging in there and found a reg key called "App Id" this CLSID matched up to a CLSID that was located when I opened up the component services management console. Ah HA we found pay dirt! The Osearch COM object was to blame and for some reason the necessary accounts did not have the rights to access this object. My friend Erik had the great idea to compare the launch and activation rights on a server with SP1 applied to a non-SP1 server what a concept!
Registry Editor where I found the CLSID app ID.
Open up component services and locate the Osearch component. Right click on it and go to properties and check to match up the app Id with the Id shown in the Reg key.
Below is another screen shot with the security tab being displayed. Click the Edit button next to launch and activation permissions and that will display which accounts have what permissions to the specific component you have selected.
So the final test was to apply MOSS 2007 SP1 to the environment and see if applying the service pack would strip away those rights that were there previous to SP1. So we first applied the WSS SP1 to the server and the permissions were not changed. Finally we went and applied MOSS 2007 SP1 and immediately after the permissions on this COM object were gone!!! The figures below show the permissions on the Osearch Com object before and after SP1 was applied.
This is what the launch permissions looked like on our server pre-Sp1.
This is what the permissions looked like immediately following the binary install of MOSS SP1...Yikes!!
In order to solve this issue we simply copied the same rights that were on the MOSS 2007 server that didn't have SP1 and reapplied them to each of the servers in the server farm where the issue was occurring. After a quick reboot this solved all of the errors that were occurring in the event viewer. I have not completely validated that this is a known issue but we were definitely able to repro this issue in multiple medium farm environments where we have dedicated accounts for SSPadmin, Content Access Acount, Content Crawler account, App Pool Identity account, and a dedicated farm admin account.
One item to note is that this problem (DCOM errors in event viewer) did not seem to occur when we tried to reproduce in a small farm environment (1 server running everything but SQL) using one single account for all services. The account running all services was a local administrator on the box so this might be the reason why we did not see these errors on the single server box. As opposed to in our medium and large farm build out where the dedicated service accounts used were not granted local admin on the box.
So MOSS SP1 has been out for quite sometime now and I did not see barely anything that directly related to the issues that came about in my situation. So I hope this helps or saves some people some time in the future when applying MOSS SP1.
Cheers