3

We have an issue that has been solved, but I am trying to find an explanation. Our Sharepoint 2013 was working fine connected to a SQL 2012/Windows 2012 machine via a SQL Server Alias. We had to rename the database server, which we did, and then updated the SQL Server configuration there as directed by Microsoft. http://technet.microsoft.com/en-us/library/ms143799.aspx

We stopped the SharePoint services, and updated the SQL Server alias to point to the new server/instance name. Everything worked fine...for a few days. Then, when trying to open any SharePoint site or Central Administration, we got the error "Server Error in '/' Application". Event Viewer showed:

A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: SQL Network Interfaces, error: 26 - Error Locating Server/Instance Specified)

The SQL Server was up and running. We were able to connect from the Sharepoint Server to the SQL Server via SQL Server Management Studio using an identical alias I created in the 32-Bit SQL Server Native Client configuration (since SSMS is 32-bit, this was required). The SharePoint server was then disconnected and reconnected to the farm. All sites were then accessible EXCEPT Central Administration. When trying to connect to that, we got the error:

A connection was successfully established with the server, but then an error occurred during the pre-login handshake. (provider: SSL Provider, error: 0 - The handle specified is invalid)

Steps taken:

  • Removed and rejoined both servers to the domain
  • Restarted both servers
  • Deleted and recreated the SQL Server Aliases (both 32 and 64 bit)
  • Reviewed error logs on SharePoint machine (no good errors other than above)
  • Reviewed error logs on SQL Server machine - nothing good
  • Ran a Windows "Repair" of SharePoint in the Add/Remove Programs menu

Central Admin was still not working at this point. We finally ran this in the Sharepoint Management Shell:

 psconfig.exe -cmd adminvs -provision

Suddenly, Central Administration was then accessible!

Does anyone know what happened in this scenario? Was the issue caused by the SQL Server name change? If so, why was Sharepoint working okay for days with the new database connection? Could there have been an Active Directory trust issue between the machines after the rename?

Improve this question
1
  • Just in case anyone else ends up here with the same pre-login handshake error after working fine for a long time without reason or change we developed a network trust issue and taking SomeGuy's lead leaving and rejoining the domain on both TFS and SQL servers and repairing the TFS installation resolved the error mentioned.
    – 9swampy
    Commented Feb 2, 2015 at 14:24

2 Answers 2

Reset to default
1

It's very hard to know what actually happened during the process of renaming the SQL Server. Still, I will try to make a few suggestions of the steps that should have happened, but (from your post) didn't.

Renaming a SQL Server with alias is close related to moving databases to another server with the same alias, but not actually moving anything. The prerequisites are (as you did) to stop the SharePoint Services:

  • SharePoint 2013 Administration
  • SharePoint 2013 Timer
  • SharePoint 2013 Tracing
  • SharePoint 2013 User Code Host
  • SharePoint 2013 VSS Writer
  • World Wide Web Publishing Service
  • SharePoint Server Search

When this is done, you should have stopped the IIS, running the command 

iisreset /stop

But this didn't happen, and since IIS holds the connection of the Web Applications through the application pools, the SharePoint Farm was still running, even if all the services was stopped. The resolution was to provision a new web application, with a new app pool. I guess you now have two Web Applications for the SharePoint Farm in your IIS?

[-provision] Provisions the SharePoint Central Administration Web application on this server. Provisioning creates a new SharePoint Central Administration Web application and an application pool running under the server farm administrator's account.

Improve this answer
2
  • I hope you find some of this answer useful, even if it didn't answer all of your questions.
    – Benny Skogberg ♦
    Commented Nov 16, 2013 at 6:45
  • That is the exact process I followed before renaming the database server, so I'm not sure how this continued to work on the new instance for a while after starting the SharePoint services back up.
    – SomeGuy
    Commented Nov 18, 2013 at 13:24
-1

I have faced the same issue regarding handshake with sql server and restarting the WMI service helped me.

Follow the steps below.

Got to Start --> Run --> Services.msc --> Windows Management Instrumentation --> Restart the service..

It's possible that you may face the same issue after iisrest. Then you may have to restart the WMI service again and it will fix the issue.

Thanks, Ankit

Improve this answer
0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.