A certificate validation operation took nnn milliseconds and has exceeded the execution time threshold

After installing a new SharePoint 2013 farm, I noticed a few messages in the Windows event log:

A certificate validation operation took 14988.6926 milliseconds and has exceeded the execution time threshold. If this continues to occur, it may represent a configuration issue. Please see http://go.microsoft.com/fwlink/?LinkId=246987 for more details.
Source:	SharePoint Foundation
Event ID:	8321
Level:	Critical

As Microsoft states in their knowlege base article KB2625048:

The SharePoint server does not have access to the Internet, or the server is protected by a firewall that has limited ports open. In this situation, users intermittently experience long delays when they perform certain operations, such as logging in to the site or performing a search. Users may also encounter HTTP timeouts when they perform these operations.

The mean you must either let your server access the internet, what most of the time won't be possible due to policy reasons, or we need a other solution. Good for us that the knowlege base article offers two possible solutions.

SharePoint HRESULT: 0x80131904 list error

Recently a customer of mine had a problem creating new entries in SharePoint lists. Everytime he tried to add a new entry to a list, SharePoint returned an error with HRESULT: 0x80131904

After some research in the windows logs, it became quite clear that the SQL server transaction logs have exhausted the entire disk space on the SQL server. So we cleared the transactions by backup, shrunk the size afterwards and the errors were gone.

Trickshots: Testing a SQL connection quick and easy

Did you ever need to test a SQL connection? As a SharePoint Pro you probably have. I found a nice little trick on Steve Rachui's Blog today I’d like to share with you.

Create a new text file on the desktop of the machine you will try to connect to the SQL server. Name the file whatever you like, but rename the file into UDL. Double click on the file and a dialog pops up with SQL connection settings. Enter your connection settings and use the Test Connection button in the lower end of the dialog.

If you need to test a different SQL server port (not 1433), simply create a SQL alias on the machine and test against the alias.

Log Parser Studio 2.2

Log files are a hassle. Too many entries and bad formatting make it a challenge to work with logs. So if you are already familiar with Microsofts LogParser, you’ll love to hear that there is an even better way to work with Log files.

Log Parser Studio is a Windows Tool that uses LogParser and gives you a GUI to work with. This way it's easier to create adhoc reports of your logfiles. You can export the query as a script and then automate your tasks.
http://gallery.technet.microsoft.com/office/Log-Parser-Studio-cd458765

LogParser
http://www.microsoft.com/en-us/download/details.aspx?displaylang=en&id=24659

Getting Started with the Log Parser Studio
http://blogs.technet.com/b/karywa/archive/2013/04/21/getting-started-with-log-parser-studio.aspx

Opening Word file from SharePoint 2010 causes Office to crash

Today I wasn’t able to open a Word file from the SharePoint Server. Every time I opened the document from the server, Word crashed. Saving the file to disk and opening it then worked just fine. What made it even worse was that SharePoint thought the file was opened exclusive for my user account and I couldn’t do any action on the file on the server e.g. deleting. Bugs! I don’t like them, but it’s always a good feeling when you found out how to get rid of ‘em.

How to identify which w3wp.exe process belongs to which Application Pool in IIS

I received an e-mail today, where I was asked how to identify the IIS Application Pool and the corresponding w3wp.exe process. Actually it doesn’t need much and no extra tools are needed.

1. Open the Windows Task Manager by right clicking on the Taskbar and selecting Start Task Manager
2. In the Menu, open View / Select Columns…
3. Search the list for Command Line and enable the check box



4. Look for the w3wp.exe processes and expand the column for the command line

As you can see, the process is started with the name of the Application Pool in the IIS management console

This post is

Service Pack 1 for SharePoint 2013 has been retracted

Microsoft has retracted the Service Pack 1 for SharePoint Server 2013, SharePoint Foundation 2013, SharePoint Designer 2013 and Office Web Apps Server 2013. The reason for this move is stated by Microsoft in the knowlege base article:

We have recently uncovered an issue with this Service Pack 1 package that may prevent customers who have Service Pack 1 from deploying future public or cumulative updates.

If you have already downloaded the Service Pack 1 for SharePoint 2013, it is recommended you wait with the installation for an updated version of the Service Pack 1.

If you have already installed the Service Pack 1, you should not expect any problems. However Microsoft will release a patch to fix the problem in your Service Pack 1 version. It is recommended to wait for this fix before your install any other patches. Bill Baer has a post that covers this issue.

SharePoint 2013 with SP1 also known as Slipstream installations are not affected by this issue.

Removing a corrupted search service from SharePoint 2010

Removing the SharePoint 2010 Search Service can become quite a pain. Especially when the removal hasn’t work out the way it should have. So what do you do when the removal failed and your attempts to reinstall the search service are failing as well? I suffered from the same pains and therefor I’ll go thru the step I took to get my search service back online in this blog article.

Keine Verbindung mit dem SharePoint Administration Service - Windows Event ID 6398

Das Leben mit SharePoint ist immer spannend und abwechslungsreich. Das merkt man vor allem daran, dass man bei der Arbeit immer wieder mit Fehlern konfrontiert wird, welche man so noch nicht kannte. Vor allem dann, wenn die Fehlerbeschreibung einen erst einmal auf die falsche Fährte lockt.
Bei einem meiner Kunden habe ich im Windows Event Log folgenden Fehler vorgefunden:

Log Name:	Application
Source:	Microsoft-SharePoint Products-SharePoint Foundation
Date:	16.04.2013 05:10:30
Event ID:	6398
Task Category:	Timer
Level:	Critical
Keywords:
User:	Farm account
Computer:	Only for me to know ;)
Description:	The Execute method of job definition Microsoft.SharePoint.Administration.SPTimerRecycleJobDefinition (ID dd6757f2-1684-4834-b419-8dafc87cdffc) threw an exception. More information is included below. This operation uses the SharePoint Administration service (spadminV4), which could not be contacted.  If the service is stopped or disabled, start it and try the operation again.

Wie sich herausstellte, wurden auf dem SharePoint Server, auf dem auch der Microsoft Project Server installiert wurde, die Content Datenbanken und die Project Server Datenbanken, mittels des SQL Servers, wieder hergestellt. Dabei wurden die Datenbanken in die Farm eingespielt, ohne vorher den SharePoint Timer Service anzuhalten.

Nach einigem Suchen, habe ich schließlich ein Beitrag im Microsoft Forum gefunden, welcher genau mein Problem beschrieben hat. Leider gibt es im Netz eine Vielzahl verschiedener Ursachen für den Event Eintrag 6398. In meinem Fall hat es sich herausgestellt, dass durch das Wiederherstellen des Backups ein Timer Job zurückgeblieben ist, welches die Probleme verursachte. Mit folgendem Powershell Skript konnte ich schließlich den Timer Job isolieren und löschen.

PS C:\> $job = Get-SPTimerJob | where {$_.DisplayName -eq $null} PS C:\> $job Name                 Schedule             Last Run ----                 --------             -------- PWASSP_bd110576-8... daily between 00:... 01.01.0001 00:00:00 PS C:\> $job.Description Project Server Shared Timer Job PS C:\> $job.Delete()

Nachdem ich den alten Timer Job gelöscht hatte, konnte ich wieder auf die Liste der Timer Job zugreifen und die Fehler sind nicht mehr im Windows Event Log aufgetreten.

Der w3wp.exe Prozess von SharePoint nutzt 100% der Netzwerkbandbreite

Neulich hatte ich ein etwas seltsames Problem mit SharePoint. Der Server selbst war verfügbar, allerdings wurden die Seiten nicht mehr so schnell im Browser geladen. Auch das öffnen im SharePoint Designer war sehr langsam.

Ein Blick in den Task-Manager auf dem SharePoint Server genügte um zu sehen, dass die Netzwerkschnittstelle auf fast 100% der Bandbreite belastet ist. Also in den Ressourcen-Manger wechsel und den Prozess isolieren der die Bandbreite beansprucht. In meinem Fall hat einer der w3wp.exe Prozesse die ganze Bandbreite auf dem Loopback beansprucht.

An dieser Stelle wäre es sicherlich notwendig, dem Problem auf den Grund zu gehen und zu prüfen welche Komponente dieses Problem verursacht. In meinem Fall war aber nur die schnelle Beseitigung des Incidents notwendig.

Daher mit dem Task-Manager kurz prüfen welche WebApplication Instanz dem w3wp.exe Prozess zugeordnet ist. Dann im IIS Manager den Application Pool mittels recycle neu starten. Jetzt sollte man im Task-Manager sofort sehen, dass die Bandbreite auf der Netzwerkschnittstelle freigegeben wird.

Die SharePoint 2010 cmdlet's funktionieren nicht mehr nachdem die Powershell 3 installiert wurde

Seit kurzem wird mittels des Windows Updates, eine neue version des Windows-Management Framework 3.0 (KB2506143) verteilt. In diesem Update ist auch die neue Powershell 3.0 enthalten.

Nachdem die neue Powershell auf einem SharePoint 2010 server installiert wurde, gibt es aber Probleme mit den cmdlet's in der Management Shell. Die alten Befehle vertragen sich nicht mit der neuen Version der Powershell. Zum Glück lässt sich das Problem aber sehr schnell aus der Welt schaffen, indem man der Powershell beim Starten mitteilt mit welcher Version gestartet werden soll.

Am einfachsten geht dies indem man in der Shell eine neue Powershell startet mit

powershell.exe -v 2

Möchte man dies nachhaltig ändern muss man die Verknüpfungen im Startmenü ändern.

Fehlermeldung "This SharePoint farm currently has pending upgrades using New-SPConfigurationDatabase" bei der Installation mit AutoSPInstaller

Während der Installation eines neuen SharePoint 2010 Servers mit AutoSPInstaller, wurde nach dem kopieren der Dateien, das Skript mit einer Exception beendet. Der Fehler "This SharePoint farm currently has pending upgrades using New-SPConfigurationDatabase" ist ziemlich verwirrend, denn zu diesem Zeitpunkt der Installation habe ich noch keine Datenbanken angelegt und somit gibt es nichts was ein Upgrade bennötigen könnte.

Nach ein paar Minuten mit Bing habe ich einen Hinweis darauf gefunden woran es liegt. Bei meiner Installation habe ich auch die Office Web Apps in das Script eingebunden. Leider hat das Setup von Office Web Apps wohl einen Fehler der dazu führt, dass der PowerShell Befehl 'New-SPConfigurationDatabase' der Meinung ist das die Datenbank vorher ein Update benötigt. Dies kann mit folgendem Befehl in einer Befehlszeile behoben werden:

c:\> PSCONFIG.EXE -cmd upgrade -wait -force -inplace b2b

Hinweis: Starten Sie die Befehlseingabe mit erweiterten Administrationsrechten.

Hinweis: Geben Sie den Befehl genau wie oben abgebildet ein! Die Reihenfolge der Parameter spielen beim Befehl PSCONFIG.EXE eine Rolle.

Aber auch hier ist leider nicht alles in Ordnung, den dieser Befehl wird auch mit einer Fehlermeldung quittiert. Allerdings wird die Fehlermeldung angezeigt, weil es keine Datenbank gibt auf die das Update angewendet werden kann. Gleichzeitig wird aber das Problem das wir hatten behoben. Wir beheben also eine Fehlermeldung mit einer Fehlermeldung. Anschließend kann AutoSPInstaller nochmal ausgeführt werden und jetzt sollte alles so funktionieren wie erwartet.