Life is Just a Bowl of SharePoint – Part 9: Post Installation Event Log Warnings and Errors

Guest Author: Joan Resnick Ehrlich

Before proceeding with the next step in the TechNet article Configure Kerberos authentication (SharePoint 2010), configuring Search, I opened Event Viewer and reviewed the Application and System event logs for errors and warnings. I also reviewed the Operational log that SharePoint adds to Event Viewer. This log, highlighted in the screenshot below, can be found under Applications and Services Logs:

The Applications and Services Logs is a new category of logs beginning with Windows 2008 and Vista. Also new is the Custom Views category of logs. The revamped Event Viewer makes it easy to create a permanent custom view of filtered events and these are stored under the Custom Views section. Here is the Create Custom View dialog box:

One custom view is provided by default; this is Administrative Events, which a view of “Critical, Error and Warning events from all administrative logs”. In addition, when a server role is installed a related custom view is added under the Server Roles section of the Custom Views category; at least this has been my experience. I have found too that the logs for some server roles, though not all, will also appear under Applications and Services Logs category; that is, in both sections. For example, on my domain controllers, the DNS and Active Directory Services logs appear under both sections.

I found several warnings and errors, outlined below:

System Event Log:

Only a few and familiar errors:

• Event ID 5048 (Source: WAS) about the invalid AppPoolID for the Security Token service web application pool appeared as expected and as described in Part 7 of this article series.
• There was also Event ID 10016 (Source: DCOM), another error I was familiar with:


Not only has this error occurred with every SharePoint 2010 Beta install that I’ve done, it also occurred on our WSS 3.0 server oh-so-long ago.  In fact there is a KB about it: Microsoft KB 920783.The fix was straightforward: use the Registry to identify the application with the CLSID cited in the Event, by searching for the CLSID in HKLM (HKey_Local_Machine). Then find the application in the Component Services MMC snap-in and grant Local Activation permission to the user account cited in the Event. Windows Server 2008 R2 threw a bit of a wrench into it, though. On Windows Server 2003 my domain admin account sufficed to change Local Activation permissions. On Windows Server 2008 R2 the DCOM controls were greyed out (not editable). An Internet search turned up the answer: due to increased security even domain admins do not have permissions to perform certain functions; editing DCOM permissions is one such function. The search also provided the solution, which SharePoint MVP Wictor Wilen describes in his blog post Fix the SharePoint DCOM 10016 error on Windows Server 2008 R2.

The solution changes the Owner on the CLSID registry key. I was uncomfortable leaving the change so once I had completed the fix I reset the Owner back, though not without some Laurel and Hardy moments.  The original Owner is TrustedInstaller. This is a local account and the proper account name is NT SERVICE\TrustedIntaller.  To make a long story short, I had to manually type in NT SERVICE\TrustedInstaller as shown in the screenshot below rather than use the Advanced… button to search for the account. The account won’t show up in a query.

Application Log

There were also some warnings and errors in the Application Event Log:

• Event ID 8059 (Source: SharePoint Foundation) about configuring alternate access mappings (AAM) for the Central Admin site:



Adding AAMs is done via Central Admin, System Settings, Configure Alternate Access mappings. I clicked the Central Admin site, then clicked “Edit Public URLs” and added the FQDN URL for Intranet zone mapping:




After which the AAM list for Central Admin showed:



• Event ID 7043 (Source: SharePoint Foundation) for the Taxonomy Picker web control. This error has occurred with all SharePoint 2010 installs I’ve done and is a known issue in the Beta:



And for the Scenario Navigation web control, which also has repeated with each installation:




I recently came across the reasons for the two errors in a forum thread: http://social.technet.microsoft.com/Forums/en/sharepoint2010setup/thread/c894d98c-24ab-416c-aca9-ae57644deb5e. Look for the reply by Koen van der Linden which relates directly to these errors. Apparently, the errors are caused by code errors.

• Event 7362 (Source: Web Content Management)



I have not done this yet for the new install but did so at work for the original install. This necessitated yet another domain user account (the list keeps getting longer), which I named portalsufull.

• Event 5586 (Source: SharePoint Foundation)



Followed by two of:




This repeated once immediately in succession but not again.

• Event  8193 (Source: VSS)



The full error details show the error is related to SPSearch4 VSS Writer. This error has repeated intermittently days apart but I do not see a pattern. I will wait to see if the error repeats in the RTM.

One error I did not get but had gotten previously at home (pre-reformat) and at work the day after installation was a dreaded “Server Error in ‘/’ Application” when trying to open Central Admin:

At first I panicked and rebooted, and that worked. But the next day the error returned. So, reacting a bit more calmly this time I followed the instructions in the error message to turn customErrors mode to Off. Rather than edit the original web.config file, I made a copy to another location and edited the copy. I then renamed the original web.config file, moved the copy and used it. I use this method because when I first started with WSS I had an ugly experience editing the WSS web.config file on our test server – WSS got hosed – and reversing the changes did not undo the damage. Perhaps the file got corrupted. Fortunately I had first made a copy and so was able to use the copy.

With customErrors off, launching Central Admin brought up an error I could research:

Doing so led me to the solution: SharePoint 2010 beta error: Retrieving the COM class factory for component with CLSID {BDEADF26-C265-11D0-BCED-00A0C90AB50F} failed due to the following error: 800703fa by Microsoft Consultant Bassem Georgi.  So I went into IIS, selected the Central Admin web application pool, Advanced settings and set Load User Profile to True:

With none of the errors fatal, I proceeded to configure Search, which I will step through in Part 10.

Guest Author: Joan Resnick Ehrlich

Joan Resnick Ehrlich has been in the IT industry for 15 years and is Corporate IT Administrator for a mid-sized company on Long Island, NY. Prior to entering the industry Joan was a business researcher, and she enjoys combining her research skills with IT work. In addition to SharePoint, her primary responsibilities include Windows Server, Active Directory, Exchange Server, and SQL Server.