Wednesday, May 21, 2014

Connection Timeout Expired. The timeout period elapsed during the post-login phase.

I recently installed SharePoint 2013 on a server, and I started receiving these error messages in the Windows Event Log:

Cannot connect to SQL Server.  <database server> not found.  Additional error information from SQL Server is included below.

Connectino Timeout Expired.  The timeout period elapsed during the post-login phase. The connection could have timed out while waiting for server to complete the login process and respond; Or it could have timed out while attempting to create multiple active connections.  The duration spent while attempting to connect to this server was - [Pre-Login] initialization=3; handshake=12; [Login] initialization=0; authentication=0; [Post-Login] complete=14006;

After searching for some additional information on the Internet, it was recommended that I change the database connection timeout using the stsadm tool:  http://technet.microsoft.com/en-us/library/cc263314.aspx

Unfortunately, when I ran the command initially (without the Url), I got the following error message:

stsadm -o setproperty -pn database-connection-timeout -pv 45

Object reference not set to an instance of an object.

When I subsequently ran the command with the Url switch, I now got the following error message:
  
stsadm -o setproperty -pn database-connection-timeout -pv 45 -url http://sharepoint.contoso.com

This operation can be performed only on a computer that is joined to a server farm by users who have permissions in SQL Server to read from the configuration database.  To connect this server to the server farm, use the SharePoint Products Configuration Wizard, located on the Start menu in Microsoft SharePoint 2010 Products.

Well, I knew that the server was part of the server farm already, so I did a bit more digging on the Internet and found this article: http://mysharepointwork.blogspot.com/2010/02/cannot-connect-to-sql-server-sqlserver.html

Well, I did not think of looking at the IIS Application Pools earlier, so I decided to take a look.

Everything looked to be in order, EXCEPT that the SharePoint Web Services Root Application Pool was STOPPED!

So, out of curiosity, I decided to Start the SharePoint Web Services Root Application Pool.

I then re-ran the stsadm command and believe it or not, I got this response:
Operation completed successfully.

Yay! 

So, in order to make sure that stsadm commands run correctly, ALWAYS make sure that the SharePoint Web Services Root Application Pool is started.

1 comment:

  1. Thank you for your great article. If you are looking for asp.net hosting feel free to visit my asp.net hosting review site at http://cheaphostingasp.net.

    ReplyDelete