After applying MOSS 2007 SP1 Event log error: Retrieving the COM class factory for component with CLSID {3D42CCB1-4665-4620-92A3-478F47389230} failed due to the following error: 80070005

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 NORTHAMERICAsrvspdev1 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_ROOTCLSID 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.

Regedit

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.

CLSID app ID

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.

Osearch Properties

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.

Osearch before

This is what the permissions looked like immediately following the binary install of MOSS SP1…Yikes!!

Osearch after MOSS SP1

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

 

2 Responses to “After applying MOSS 2007 SP1 Event log error: Retrieving the COM class factory for component with CLSID {3D42CCB1-4665-4620-92A3-478F47389230} failed due to the following error: 80070005”

  1. Jackie Johnson says:

    Hi, I seem to be having the same problem. Can you tell me what users/groups were removed by SP1? I can’t tell from this web page.

    Thanks,
    Jackie

Leave a Reply


After applying MOSS 2007 SP1 Event log error: Retrieving the COM class factory for component with CLSID {3D42CCB1-4665-4620-92A3-478F47389230} failed due to the following error: 80070005

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 NORTHAMERICAsrvspdev1 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_ROOTCLSID 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.

Regedit

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.

CLSID app ID

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.

Osearch Properties

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.

Osearch before

This is what the permissions looked like immediately following the binary install of MOSS SP1…Yikes!!

Osearch after MOSS SP1

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

 

Leave a Reply