WSS 3.0 (x64) farm install problem - "Failed to connect to the database server or the database name does not exist"
-
Friday, January 30, 2009 6:47 PM
We are trying to install WSS 3.0 (x64) in a new farm using SQL on another machine (details are below), in accordance with the security hardening practice suggested by MS: http://technet.microsoft.com/en-us/library/cc288143.aspx. We get the “Failed to connect to the database server or the database name does not exist. Ensure the database server exists, is a Sql server, and that you have the appropriate permissions to access the database server. To diagnose the problem, review the extended error information located at C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\LOGS\PSCDiagnostics_1_29_2009_21_2_25_43_223458399.log. Please consult the SharePoint Products and Technologies Configuration Wizard help for additional information regarding database server security configuration and network access.” error.
Environment
Both machines on same domain - Windows Auth used; Account install is running under is a domain admin; administrative rights verified on DB Machine
WSS Machine:
· WSS 3.0 X64 install, creating a new server farm.
· W2K3 x64 R2;
· .NET 3.5 install
· IIS WSE ASP .NET v2.0.50727 Allowed
· SQL Alias to named instance on DBMachine – verified as functional via SQL Server manager
DB Machine:
· W2K3 X64 R2
· SQL Server 2005 Dev Edition X64 SP3 (manual install - not syspreped)
· SQL Named Instance (JHAPROFOLTP: fixed port 8246);
· SQL Service Area Configuration - Local and remote connections, both TCP/IP and named pipe settings;
· SQL Protocols TCP/IP, Named Pipes, and Shared Memory protocols are enabled;
· SQL account setup - centeral admin domain account added as login with dbcreator & security admin Server roles.
Results
Both psconfig and configuration wizard GUI report the same error:
“Failed to connect to the database server or the database name does not exist. Ensure the database server exists, is a Sql server, and that you have the appropriate permissions to access the database server. To diagnose the problem, review the extended error information located at C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\LOGS\PSCDiagnostics_1_29_2009_21_2_25_43_223458399.log. Please consult the SharePoint Products and Technologies Configuration Wizard help for additional information regarding database server security configuration and network access.”
Psconfig results:
C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\BIN>psconfig -cmd configdb -create -server <SQL Alias> -database SharePoint_Config -user jhadev\svc-ps-spsadmin -password <redacted>
SharePoint Products and Technologies Configuration Wizard version 12.0.4518.1016
Copyright (C) Microsoft Corporation 2005. All rights reserved.
The server parameter specified with the configdb command is invalid.
Failed to connect to the database server or the database name does not exist. Ensure the database server exists, is a Sql server, and that you have the appropriate permissions to access the database server. To diagnose the problem, review the extended error information located at C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\LOGS\PSCDiagnostics_1_29_2009_21_2_25_43_223458399.log. Please consult the SharePoint Products and Technologies Configuration Wizard help for additional information regarding database server security configuration and network access.
Pertinent Log Entries:
01/29/2009 21:02:40 1 ERR An exception of type System.Data.SqlClient.SqlException was thrown. Additional exception information: An error has occurred while establishing a connection to the server. When connecting to SQL Server 2005, this failure may be caused by the fact that under the default settings SQL Server does not allow remote connections. (provider: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server)
System.Data.SqlClient.SqlException: An error has occurred while establishing a connection to the server. When connecting to SQL Server 2005, this failure may be caused by the fact that under the default settings SQL Server does not allow remote connections. (provider: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server)
at System.Data.SqlClient.SqlInternalConnection.OnError(SqlException exception, Boolean breakConnection)
at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj)
at System.Data.SqlClient.TdsParser.Connect(ServerInfo serverInfo, SqlInternalConnectionTds connHandler, Boolean ignoreSniOpenTimeout, Int64 timerExpire, Boolean encrypt, Boolean trustServerCert, Boolean integratedSecurity, SqlConnection owningObject)
at System.Data.SqlClient.SqlInternalConnectionTds.AttemptOneLogin(ServerInfo serverInfo, String newPassword, Boolean ignoreSniOpenTimeout, Int64 timerExpire, SqlConnection owningObject)
at System.Data.SqlClient.SqlInternalConnectionTds.LoginNoFailover(String host, String newPassword, Boolean redirectedUserInstance, SqlConnection owningObject, SqlConnectionString connectionOptions, Int64 timerStart)
at System.Data.SqlClient.SqlInternalConnectionTds.OpenLoginEnlist(SqlConnection owningObject, SqlConnectionString connectionOptions, String newPassword, Boolean redirectedUserInstance)
at System.Data.SqlClient.SqlInternalConnectionTds..ctor(DbConnectionPoolIdentity identity, SqlConnectionString connectionOptions, Object providerInfo, String newPassword, SqlConnection owningObject, Boolean redirectedUserInstance)
at System.Data.SqlClient.SqlConnectionFactory.CreateConnection(DbConnectionOptions options, Object poolGroupProviderInfo, DbConnectionPool pool, DbConnection owningConnection)
at System.Data.ProviderBase.DbConnectionFactory.CreateNonPooledConnection(DbConnection owningConnection, DbConnectionPoolGroup poolGroup)
at System.Data.ProviderBase.DbConnectionFactory.GetConnection(DbConnection owningConnection)
at System.Data.ProviderBase.DbConnectionClosed.OpenConnection(DbConnection outerConnection, DbConnectionFactory connectionFactory)
at System.Data.SqlClient.SqlConnection.Open()
at Microsoft.SharePoint.PostSetupConfiguration.SqlSession.OpenConnection()
at Microsoft.SharePoint.PostSetupConfiguration.SqlSession.ExecuteNonQuery(SqlCommand command)
at Microsoft.SharePoint.PostSetupConfiguration.SqlServerHelper.DatabaseExists(String database)
at Microsoft.SharePoint.PostSetupConfiguration.ConfigurationDatabaseTask.EnsureDatabase(Parameter parameterDatabase)
1/29/2009 21:02:40 1 ERR An exception of type Microsoft.SharePoint.PostSetupConfiguration.PostSetupConfigurationTaskException was thrown. Additional exception information: The server parameter specified with the configdb command is invalid.
Failed to connect to the database server or the database name does not exist. Ensure the database server exists, is a Sql server, and that you have the appropriate permissions to access the database server. To diagnose the problem, review the extended error information located at C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\LOGS\PSCDiagnostics_1_29_2009_21_2_25_43_223458399.log. Please consult the SharePoint Products and Technologies Configuration Wizard help for additional information regarding database server security configuration and network access.
Microsoft.SharePoint.PostSetupConfiguration.PostSetupConfigurationTaskException: Exception of type 'Microsoft.SharePoint.PostSetupConfiguration.PostSetupConfigurationTaskException' was thrown.
at Microsoft.SharePoint.PostSetupConfiguration.ConfigurationDatabaseTask.EnsureDatabase(Parameter parameterDatabase)
at Microsoft.SharePoint.PostSetupConfiguration.ConfigurationDatabaseTask.EnsureConfigurationDatabaseConnection()
at Microsoft.SharePoint.PostSetupConfiguration.ConfigurationDatabaseTask.Validate(Int32 nextExecutionOrder)
at Microsoft.SharePoint.PostSetupConfiguration.TasksQueue.Validate(Boolean useDefaultExecutionOrder)
01/29/2009 21:02:40 1 ERR A PostSetupConfigurationTaskException was thrown: The server parameter specified with the configdb command is invalid.
Failed to connect to the database server or the database name does not exist. Ensure the database server exists, is a Sql server, and that you have the appropriate permissions to access the database server. To diagnose the problem, review the extended error information located at C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\LOGS\PSCDiagnostics_1_29_2009_21_2_25_43_223458399.log. Please consult the SharePoint Products and Technologies Configuration Wizard help for additional information regarding database server security configuration and network access.
Unsuccessful trouble shooting suggestions researched and attempted:
http://technet.microsoft.com/en-us/library/cc752945.aspx
Thank you in advance for your reply.
Answers
-
Monday, February 02, 2009 9:42 PM The professionals at MS tech support were able to solve this problem for us; hopefully this will save others some time.
If you follow the security hardening guidance, it will step you through creating a SQL Client alias using the SQL Server Configuration Manager. It does not mention, however, that it is also necessary to set up the same alias using cliconfg.exe [sic] (system 32). Given cliconfg.exe is the "SQL Server Client Utility Network", used for managing aliases and the same information must be set up as that in SQL Server Configuration Manager, one may have thought the SQL Server Configuration Manager would have performed this config (but it does not).- Marked As Answer by Joel Geyer Monday, February 02, 2009 9:42 PM
All Replies
-
Monday, February 02, 2009 9:42 PM The professionals at MS tech support were able to solve this problem for us; hopefully this will save others some time.
If you follow the security hardening guidance, it will step you through creating a SQL Client alias using the SQL Server Configuration Manager. It does not mention, however, that it is also necessary to set up the same alias using cliconfg.exe [sic] (system 32). Given cliconfg.exe is the "SQL Server Client Utility Network", used for managing aliases and the same information must be set up as that in SQL Server Configuration Manager, one may have thought the SQL Server Configuration Manager would have performed this config (but it does not).- Marked As Answer by Joel Geyer Monday, February 02, 2009 9:42 PM
-
Sunday, August 23, 2009 1:33 PMI am having EXACTLY the same problem.
Could someone provide alias name that needs to be used? -
Thursday, September 17, 2009 8:14 PM
I have been having the EXACT same problem for the past few days. I have literally read every article on the net regarding this issue and none of the fixes worked for me. There is no clear cut fix for this issue but ironically, the issue went away when I created an ODBC "test" connection on the WSS server and configured the connection to connect to the SQL database server. The connection was successful and I was then able to complete the SharePoint Configuration Wizard with no issues. I think it initialized once the test connection was successful. Try it if all else fails and you are certian that everything is configure properly in your environment.
Troubleshooting SharePoint Connection Problems to SQL ServerWhen creating a new SharePoint Farm using the SharePoint Products and Technologies Configuration Wizard, you are prompted to enter in a SQL Server name and the name of your configuration database. For a variety of reasons, you may be unable to connect to SQL Server to create the new farm database. The most common issues include:
1. The farm account is unable to login to the SQL Server.
2. Network protocols are not configured correctly on the SQL Server. For example, Named pipes, TCP/IP sockets, etc.
3. Your web front end (WFE) you are creating the farm from cannot resolve the SQL Server name.
4. A firewall in between the WFE and the SQL server is blocking packets.
5. The farm account has insufficient permissions in SQL Server to create the farm. (The account needs the securityadmin and dbcreator fixed server roles as a minimum.)
If the wizard encounters an error, it aborts and stores the progress it made in the log folder (C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\LOGS). And those without a strong SharePoint or SQL background may have time trying to wade through it to find the real problem.
Before I get into deeper troubleshooting discussion, please make sure rule out the two most obvious reasons: 1) Really make sure that the MSSQLSERVER (or whatever named instance you’re using) service is actually running. 2) Verify that you have enabled at least one network protocol in SQL Server Configuration Manager. By the way, Shared Memory does not count since this only works for connections from the same server.
So with that, I’d like to share a couple of the utilities that I use that can help quickly troubleshoot these types of problems. The first of these is the good, old-fashioned ODBC utility that’s been around for generations. You can find it in Administrative Tools –> Data Sources (ODBC). This is helpful as it allows you to verify if steps 1-4 above are the problem. Here’s a quick walk through how I use it:
To start, I log in to the WFE using the account designated as a farm admin. (Note: This is the same account that you specify as your database access account when you tried to create the farm.) Then, launch the ODBC utility and you’ll be greeted with this initial screen:From here, I click on Add and then choose the SQL Server from the list of drivers as shown below. Note, this may be listed on the bottom, and if you have installed the EN-US (English – United States) edition of SQL Server, it will be listed after all of the Spanish-sounding driver names. ?Habla Driver para o Microsoft Visual FoxPro? :)
After clicking Finish, you’ll be prompted with another wizard. It starts off looking like this
From here, I just type in anything for the name. For example “Test SQL”. For the Server, I usually enter in the NetBIOS name of the server. You can also enter in the fully-qualified domain name (e.g. sql.company.com). Testing it with the IP address will help you identify if it’s a name resolution problem (#3 in the problem list above). Click Next.
I then usually click Next since I use Windows NT authentication almost all the same (it’s definitely the easiest and most secure way). Note, this does assume that you’re physically logged into the WFE using an account that has a SQL login account. As I mentioned above, this is often the farm admin account.
If all is working you should see this screen above. Assuming there aren’t any routing or name resolution problems, it should also come up in a second or two. If you check the Change the default database to option and click the dropdown arrow for the list, you should see all the databases on the server. If you don’t see all databases, the login account is probably not a member of the securityadmin fixed server role.
So what if you cannot connect with the ODBC utility? Well, that takes us to the second tool, the SQL Server Client Network Utility. Unfortunately, there’s no shortcut in the Start Menu for this, so I always invoke by just going to Start –> Run and typing in cliconfg and hitting Enter as shown here:After this starts, you’ll be presented with the initial screen which looks like this
The purpose of this utility it to tell this workstation (which is the client) which network protocol it should use when establishing a connection to a SQL Server. As with any network communication, the client and the server must agree on a protocol. The idea is that you can create an alias and override the default settings. I do this by first clicking on the Alias tab. This gives me these options:
From here, I enter in the NetBIOS name (or whatever name I provide to the Products and Technologies Configuration Wizard) for the Server alias. I’ll then usually select Named Pipes as the Network library. The Connection parameters (i.e. the Server name and pipe name) are automatically filled in, and you rarely need to change these. Click OK to save this Alias. I then return back to the ODBC utility and try again. This time, ODBC will pick up the settings for the alias and try only Named Pipes. If that fails, I know there is a named pipes problem. I often then go back to the Client Network Utility and then try TCP/IP. With TCP/IP Sockets, it will default the port to 1433 (which along with 1434 are the default TCP ports that SQL Server uses…if you’ve configured a different port for SQL Server, you would need to change it here). When the modified Alias is saved, try again using ODBC.
Note: I recommend against using an alias as a permanent setting unless you really need it. Most of the time, I only use an alias to troubleshoot where a problem is and then remove it when I’m done and the problem is resolved.
.png){kind=spacer}
