SharePoint 2010 Log Warnings and Errors

Nach meinen gestrigen Vorarbeiten zur Migration eines Kunden Portals auf Basis MOSS 2007 steht heute die Nachbereitung an. Dazu sollten zur Fehlersuche und Behebung die Eventlogs des SharePoints sowie des Systems herangezogen werden. Bei meinen Recherchen zu den verschiedenen EventIDs bin ich, der Community um sei Dank, auf einen interessanten Artikel zur Fehleranalyse gestoßen. Anbei wie immer der Artikel:


Author: Joan Resnick Ehrlich

This entry is part of a series, Joan Resnick Ehrlich – Life is Just a Bowl of SharePoint» Entries in this series:

  1. Life is Just a Bowl of SharePoint – Part 1: Introduction
  2. Life is Just a Bowl of SharePoint – Part 2: Setting up the Hardware, OS and Service Accounts
  3. Life is Just a Bowl of SharePoint – Part 3: SQL Server Database Engine and Management Tools Installation
  4. Life is Just a Bowl of SharePoint – Part 4: Configuring Ports and Protocols
  5. Life is Just a Bowl of SharePoint – Part 5: Installing SQL Server Reporting Services and Configuring for SharePoint Integrated Mode
  6. Life is Just a Bowl of SharePoint – Part 6: Installing SQL Server Analysis Services
  7. Life is Just a Bowl of SharePoint – Part 7: Installing SharePoint 2010 Beta Take 1
  8. Life is Just a Bowl of SharePoint – Part 8: Installing SharePoint 2010 Beta with Kerberos
  9. Life is Just a Bowl of SharePoint – Part 9: Post Installation Event Log Warnings and Errors
  10. Life is Just a Bowl of SharePoint – Part 10: Configuring Search (Kerberos cont’d)
  11. Life is Just a Bowl of SharePoint – Part 11: Creating Web Applications and Site Collections

Powered by Hackadelic Sliding Notes 1.6.4

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: 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.


HowTo: Fehler im User Profile Sync Setup in SharePoint Server 2010 Beta beheben

Aus aktuellem Anlass: wir haben im Projekt grad eine Problem mit der User Profil Synchronisierung im SharePoint 2010. Der Workaround zur Problemlösung wurde ausführlich auf Jie Li´s Geek World beschrieben – die Kollegen von liefern einen Workaround dazu in deutsch.


Author: Christoph Müller

Einer meiner ärgerlichsten Beta-Fehler im SharePoint Server 2010 Beta 2 sind die fehlenden MySites. Um diesen Fehler zu beheben braucht es aber zwei Schritte. Ersten muss ein Fehler im Profilimport behoben werden und danach ein Fehler in der MySite-Einstellung. Da es dazu einige Schritte braucht, habe ich die beiden Schritte aufgeteilt. Dieser Blogpost beschäftigt sich mit dem Fehler im User Profile Import und Sync.

Alle, mit denen ich gesprochen habe,  die SharePoint Server 2010 Beta installiert haben, haben während dem Einrichten von SharePoint 2010 Server eine Fehlermeldung bezüglich dem „User Profile Service Application“ bekommen.

Um dieses Problem zu lösen hat Jie Li von Microsoft einen guten Artikel geschrieben. Hier die Schritte wie man dieses Problem löst.

1: In der Central Administration navigiert man System Settings – Manage Services on server und startet dort den „Microsoft SharePoint Foundation User Code Service„.

Wenn die gesamte Installation auf einem Domänen Controller läuft muss man zusätzlich sicherstellen, dass der „User Code Service“ die richtigen Rechte besitzt. Jie Li hat hierzu ein kleines PowerShell-Script bereitgestellt:

$acl = Get-Acl HKLM:\System\CurrentControlSet\Control\ComputerName
$person = [System.Security.Principal.NTAccount]“Users“
$access = [System.Security.AccessControl.RegistryRights]::FullControl
$inheritance = [System.Security.AccessControl.InheritanceFlags]“ContainerInherit, ObjectInherit“
$propagation = [System.Security.AccessControl.PropagationFlags]::None
$type = [System.Security.AccessControl.AccessControlType]::Allow
$rule = New-Object System.Security.AccessControl.RegistryAccessRule($person, $access, $inheritance, $propagation, $type)
Set-Acl HKLM:\System\CurrentControlSet\Control\ComputerName $acl

2: Danach startet man den „User Profile Synchronization Service“.

Wenn der „User Profile Synchronization Service“ gestartet wurde, geht der Status auf „Starting“.

Bis der Service gestartet ist vergehen einige Minuten. Ob der Service richtig und ohne Fehler gestartet wird kann man nun in der neuen Übersicht von SharePoint Server 2010 überwachen. Versteckt ist es unter: Monitoring – Check job status
Dort sollte man seinen Service „ProfileSynchronizationSetupJob“ finden.

Wenn der Job erledigt ist, sollte der „User Profile Synchronization Service“ als gestartet angezeigt werden (unter System Settings – Manage Services on server).

3: Jetzt muss die Verbindung zum Active Directory eingerichtet werden. Dazu klickt man auf Application Management – Manage service applications. Dort sucht man nach dem „User Profile Service Application“ Service und klickt darauf.

4: Nun klickt man Configure Synchronization Connections. Vermutlich wird jetzt der Fehler „An error has occurred while accessing the SQL Server database or the SharePoint Server Search Service. If this is the first time you have seen this message, try again later. If this problem persists, contact your administrator.“ angezeigt. Diesen Fehler behebt man in dem man jetzt ein „iisreset“ durchführt und die Seite neu lädt (refresh).

5: Sobald die Seite wieder geladen ist, klickt man auf Create New Connection.
!!!!!!! Bitte zuerst lesen!!!!!!! Hier darf man keine Fehler machen, da die Connections weder gelöscht noch editiert werden können. Ist halt noch Beta. Nun füllt man also seine AD-Informationen aus. Wichtig: Hier darf man beim Abschnitt „Container“ nicht vergessen seine OU einzutragen, auch wenn man die gesamte OU einlesen möchte. Siehe die beiden Bilder unten:

6: Nun geht man zurück zu User Profile Service Application. Auf der rechten Seite sollte jetzt Anzahl der Properties stehen, aber noch keine Profile. Die werden aber jetzt gleich importiert.

7: Um die Profile zu importieren klickt man auf „Start Profile Synchronization now“. Nach einer Weile erscheinen dann auch die ersten Profile.
Wenn User Profile angezeigt werden, hat man alles richtig gemacht. Allerdings wird die MySite immer noch nicht angezeigt. Jedoch kann man den Import überprüfen indem man unter People – Manage User Profiles nach einem Benutzer im AD sucht.

Wie man nun die My Sites zum funktinieren bringt, kann man in diesem Artikel lesen.