Archive for July, 2011

Everything’s not tickity-boo … at least on my sql server.

July 14, 2011

The Sitch:

None of the SharePoint applications from my development or test environment (which share a SQL server) are responding (errors below).

Exception Details: Microsoft.SharePoint.WebPartPages.WebPartPageUserException: Cannot connect to the configuration database.

+

Exception Details: System.Data.SqlClient.SqlException: Cannot generate SSPI context.

What’s going on under the hood:

Turns out the SQL server’s time service had gotten wildly out of sync with the rest of the SharePoint application servers. This was causing all the transactions with the SQL server to fails as the server is configured to only accept transactions that occur within a small time window of it’s own system time.

Action:

– Tried diagnosing connection to database
 – Ping successful between the two servers
 – Unable to find the MSQLService refered to in the article.
 – Problem seems to have kicked in from about 0850 this morning (according to the event logs).

– Ended up reporting the issue to our System Admins while I continued to investigate.

Result:

Once the System Admin reset the time on the sqlServer everything in SharePoint world was Tickety-boo. They continue to search for the root cause of the time de-syncing (I’ll be interested to know what they discover).

Learnings:

Modern network communications often rely on server’s sharing a common date/time. This helps to avoid replay attacks (amongst other things).
Notes:

References:

http://support.microsoft.com/kb/823287 – series of diagnostics to test connectivity from the SharePoint application server to the SQL Server.

http://sharepointmadeeasy.blogspot.com/2009/07/event-id-5586-cannot-generate-sspi.html – someone experience same issue as us.

http://en.wikipedia.org/wiki/Replay_attack – wikipedia article on Replay attacks (hence the need for TimeStamping).

One of these servers is not like the others …

July 13, 2011

The Sitch:

One of the servers in my test farm suddenly stopped serving search results and displayed the message

‘Your licence for Office Server Search has expired’

 

 

 

What’s going on under the hood:

Not sure, but it seems like it might be to do with a bug in SP2 that sets the licences expiry date incorrectly. I can only assume that this bug somehow was applied to the patching of our second server but not the the first ?? Doesn’t feel quite right to me, but the issue is resolved.

Action:

1. Checked the administration site for conversion licence (URL -> http://<your server>:10000/_admin/Conversion.aspx
 

  • This implied that we were using a trial licence (which was weird since all our other environments were using a standard licence CAL). 
  • Looked up our licence key and reapplied it. 
  • Licence type converted from Trial Licence to Standard Client Access Licence (text on the administration page). 
  • This didn’t immediately resolve the issue (no search results and same ol’ error message. 
  • Restarted IIS on the server that reported the expired licence issue. 
  • That seemed to do the trick.

Result:

Search is working again on both servers as expected.

Notes:

Research links:

http://social.technet.microsoft.com/Forums/en-US/sharepointsearch/thread/96bde6cd-578c-4e72-b81f-af3e9b905415/ Tanzil Malek suggested checking the
licence status in Central Administration.

http://sebastianatar.wordpress.com/2009/12/02/your-licence-for-office-server-search-has-expired/ – mentioned the ‘Licence Synchronizer Job’ which might be important.

http://support.microsoft.com/kb/971620/en-us – Microsoft Hotfix that indicates the issue maybe something to do with a bug in the SP2 installation.