Tech Tips, News and Tribal Knowledge

After installing SharePoint using the least privileged model, you will undoubtedly find your event logs filled with errors. You will see dozens of 10016, 7888, 6482 and 6398 events all with red the “X”, but don’t despair, you haven’t done anything wrong. If you have followed SharePoint best practices, the accounts you have used for your farm, shared services provider, default content access and application pools are all domain user accounts with no special rights or privileges. When installing MOSS under the least privileged model, these errors are expected. In order to eliminate the errors and finish your install, you need to complete three basic permissioning tasks before calling it a day.

SharePoint relies heavily on DCOM and as such, requires additional access rights to several DCOM objects. Microsoft makes no assumptions about your SharePoint security model and only provides default access to DCOM objects for administrators, system, and a few select user and group accounts. The SharePoint install will add the farm account to some of the DCOM objects, but unless you’ve used that account for all your SharePoint services and made that account a server administrator, SharePoint will not have the necessary permissions to operate properly.

If you didn’t follow best practice and used a single account for all SharePoint services, you could easily eliminate all these errors by making your SharePoint account a local administrator. That, however, would be considered a most privileged model installation which is not advisable for several reasons, the primary being security. If you run your web server under an account with administrator privileges and your IIS server is compromised, any malware that a hacker could get onto your machine would run under the security context of the account running the web application pool. This is especially bad if the account running IIS is also the farm account. The hacker could now potentially gain access not only to your server, but to your SQL databases as well. It’s easy to see why running your MOSS install under non-privileged accounts is a good idea.

To complete your install and eliminate DCOM errors, you will need to make several security changes to two DCOM objects and two permission changes in your shared service provider. As I stated before, simply making the accounts in question local administrators will solve the issue, but as you now know, that’s not a good idea. We want to grant the minimum object permissions possible and still have a functioning system.

If you are experiencing Event ID: 10016 and Event ID: 7888 DCOM errors you will see these entries in your event logs:

Event Type:      Error
Event Source:     DCOM
Event Category: None
Event ID:     10016
User:          NT AUTHORITY\NETWORK SERVICE
Description:
The application-specific permission settings do not grant Local Activation permission for the COM Server application with CLSID{61738644-F196-11D0-9953-00C04FD919C1} to the user NT AUTHORITY\NETWORK SERVICE SID (S-1-5-20).  This security permission can be modified using the Component Services administrative tool.

Event Type:     Error
Event Source:     Office SharePoint Server
Event Category: Office Server General
Event ID:     7888
User:          N/A
Description:
A runtime exception was detected. Details follow.
Message: Retrieving the COM class factory for component with CLSID {61738644-F196-11D0-9953-00C04FD919C1} failed due to the following error: 80070005.

These errors occur when the application pool accounts do not have sufficient privileges to the IIS WAMREG admin service. To correct the errors, add local launch and local activation permissions for all application pools to the IIS WAMREG object.

You may also receive this error for:
CSLID {3D42CCB1-4665-4620-92A3-478F47389230} which is the OSearch object that is discussed below.

To permission the IIS WAMREG object, open “Start/Settings/Control Panel/Admin Tools” and double-click on “Component Services.” Navigate to “DCOM Config” under “My Computer” and right-click on the “IIS WAMREG admin Service” object and select “Properties.”

Next, select the security tab and edit “Launch and Activation Permissions.” Make sure that your farm account (account that accesses your SQL database) and all your application pool accounts are granted both local launch and local activation rights. Select “OK” then “OK” again when finished.

If you are experiencing Event ID: 6398 and Event ID: 6482 errors you will see these entries in your event logs:

Event Type: Error
Event Source: Windows SharePoint Services 3
Event Category: Timer
Event ID: 6398
Date: 01/01/2008
Time: 00:00:00
User: N/A
Computer: XXX
Description:
The Execute method of job definition Microsoft.Office.Server.Search.Administration.IndexingScheduleJobDefinition (ID d2784cd2-20cf-466f-b5f0-365e65cdf542) threw an exception. More information is included below. Retrieving the COM class factory for component with CLSID {3D42CCB1-4665-4620-92A3-478F47389230} failed due to the following error: 8007000e.

Event Type: Error
Event Source: Office SharePoint Server
Event Category: Office Server Shared Services
Event ID: 6482
Date: 01/01/2008
Time: 00:00:00
User: N/A
Computer: XXX
Description:
Application Server Administration job failed for service instance Microsoft.Office.Server.Search.Administration.SearchServiceInstance (3ede7ca8-f6f6-432a-bd4b-cd8478ab6810).

These errors occur when your default content access account (account used for search and indexing) and your shared service provider service account do not have sufficient launch, activation and configuration permissions to the OSearch DCOM object. Referring back to the images above, locate the OSearch object and apply the following permissions:

1. Grant local launch and activation rights to your farm, default content access and shared service provider service accounts.
2. Grant full control to the configuration permissions to your farm and default content access accounts.

Finally, there is one other issue related to profile imports that some installations experience. This issue is solved through SharePoint permissioning in the SSP.

If you are experiencing Event ID: 7888 runtime exception errors you will see these entries in your event logs:

Event Type:    Error
Event Source:    Office SharePoint Server
Event Category: Office Server General
Event ID:    7888
Date:        01/01/2008
Time:        00:00:00 AM
User:        N/A
Computer:    XXX
Description:
A runtime exception was detected. Details follow.
Message: Access Denied! Only site admin can access Data Source object from user profile DB.
Techinal Details:
System.UnauthorizedAccessException: Access Denied! Only site admin can access Data Source object from user profile DB.

This error is caused by insufficient SharePoint permissions for your default content access account. This problem is corrected in Central Administration under your shared service providers “Personalization Service Permissions.” Open your Central Administration site and navigate to: “Shared Services Administration: Primary SSP > Manage Permissions.”  (Note: your SSP may be named differently)

Give your default content access account and your search service account “Manage User Profiles” rights. In my case, I use the same account for the search service as well as the default content access account. If you use different accounts, add permissions for both.

This concludes the basic permission granting tasks required for DCOM objects under a least privileged MOSS install. Depending on the particulars of your install, you may be required to troubleshoot additional DCOM issues. The basic troubleshooting methods include identifying the object in question and identifying the actual error. Keep in mind, the event ID is not the error; it’s the event the error triggered. For our IIS WAMREG and OSearch issues above, the actual error was “80070005.” This is an access denied error and one of the most common DCOM issues. If you are seeing 8007005 errors listed in your events, you can be sure it’s permissions related. Unfortunately, Microsoft doesn’t tell you right off what object is causing the trouble. Instead you are given a CSLID identifier and it’s up to you to figure out what it is.

Luckily, the human readable names of CSLIDs are easy to identify. Simply select the CSLID, including the {}’s, open the registry editor and search for it. If you carefully poke around, you will eventually be able to associate the CSLID with the name of the DCOM object.

If you have any additional questions about this article or about the least privileged model in general, please leave a comment or post to our forum. I will attempt to answer your questions as soon as possible.