When specifying the SQL server, Configuration Database name and account for SharePoint you may see the following error
Failed to connect to the database server or the database name does not exist. Ensure the database server is a SQL server, and that you have 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 <DATETIME>.log. Please consult the SharePoint Products and Technologies Configuration Wizards for help or additional information regarding the databse server security configuration and network access.
When you look at the log you will probably see some kind of timeout exception at the bottom, right before it all exploded.
LOTS of things could be causing this. Below is a list of item that I have seen in my travels.
SQL Server Problems
- SQL Server was OFF,
- the SQL Server service was stopped,
- the remote TCP/IP connections were not configured for SQL 2005
- SQL was sysprepped and the name was changed and it was just generally messed up and had to be rebuilt (Life Lesson: Just install SQL normally, perhaps record an unattended, but don't bring an image of a Sysprepped SQL and try to rename the computer [regardless if it has domain membership] )
- Router was melted,
- firewall was blocking access,
- logged in account really did not have the right permissions on the SQL server (see technet for details of required access),
- Cluster name was wrong
- Cluster was offline
- Account was local (not domain)
- Recent DNS/IP change, needed to flushdns on SharePoint server
- Admin password was changed while logged on, needed AD refresh between DCs
This is not likely a bad username/password problem. You will see a different message for that.
The server farm account is used to access your configuration database. It also acts as the application pool identity for the SharePoint Central Administration application pool, and it is the account under which the Windows SharePoint Services Timer service runs. The SharePoint Products and Technologies Configuration Wizard adds this account to the SQL Server Logins, the SQL Server Database Creator server role, and the SQL Server Security Administrators server role. The user account that you specify as the service account must be a domain user account, but it does not need to be a member of any specific security group on your Web servers or your back-end database servers. We recommend that you follow the principle of least privilege, and specify a user account that is not a member of the Administrators group on your Web servers or your back-end servers.
Try this to help diagnose
- Ping SQL/Cluster name
- Browse to \\ClusterName\C$ (this will tell you if your logged in account has admin permissions on that box)
- If SQL is a cluster, be sure which node is active
- Open the SQL server in SQL Management Studio
- Check for AV or firewall software on SQL server blocking the access
- Try user name as domain\username (NOT username@domain)
- Check the lists of all the stuff that can go wrong (above) and be sure you are not having those problems.
- If all else fails, just call PSS or your Microsoft Technical Account Manager (if you have one)