The problem
You get the following error during SharePoint 2013 Products Configuration Wizard on the Specify Configuration Database Settings page:
Cannot connect to database master at sql server <Servername>. The database might not exist, or the current user does not have permission to connect to it.
Checklist
Your first move should be the following: Try it again, but this time mark the time between you press Next > and when the error message pops up.
Based on this:
- if its more than a few seconds, you have network connectivity issue or SQL server configuration problem (start from no 1)
- if it pops up almost instantly, you have permission problems on the SQL server instance (See no. 10 and 9)
Accounts
Let’s start with a little overview of the accounts. At this moment you have two important accounts to play with:
- setup/install account: you install SharePoint with this account, just use it to log on to the machines and start the prerequisite installer then SharePoint installer and finally the configuration wizard. It has to be an administrator on the SharePoint machines to perform these steps. Furthermore it provisions the databases on the SQL backend and needs to own the dbcreator and sysadmin roles.
- farm admin: it has no rights first, simply a domain user. SharePoint config wizard will grant everything for it, just submit its name and password during setup. You do not log in with it during install, you use the previous account for that and you do not grant anything for it, the wizard takes care of that.
The checklist
- Check you typed the SQL server’s name and you typed it correctly.
- If you use an instance other than the default, check that you specified its name
- Check you can resolve the SQL server’s name to the IP address (if your SQL has multiple interfaces, check it is the correct one)
- Check your SQL server service is running on your SQL box
- Check in SQL Server Configuration Manager that TCP/IP protocol is enabled
- Check TCP/IP protocol listening ports and IP addresses
- Check Windows Firewall (profile settings and rules)
- Test connectivity between your servers
- SQL server client alias configuration on the SharePoint server
- Your install account login and permission settings in the SQL instance
Sometimes you can gain useful information from various logfiles so it is always a good idea to have a look at them or at least know where they are:
- Event viewer on the SharePoint machine
- SharePoint Products Configuration Wizard’s logfile in C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\15\LOGS (by default and their name’s start with PSCDiagnostics_<date>_<SomeID>)
- Event viewer on the SQL server
- Windows firewall logfiles (you have to turn it on first though, see that part later)
1. Check you typed the correct name
Well, this is very straightforward but make sure you set up everything on the correct server and you typed that name here, also be careful with typos.
2. Check your instance name
Do you want to use a named instance other than the default one, submit it in the following order: Servername\instancename Make sure it has the same name on SQL server as well among services.
3. Name resolution check
Start a command prompt, ping your machine and review the IP address. Now check the IP addresses on your SQL machine with ipconfig or on the interfaces. If they are matching jump on the next point.
Otherwise try troubleshooting this name resolution problem. If your SQL server has multiple cards make sure DNS resolves it to the correct one. Review your records in DNS and correct them if necessary.
Also make sure that your SharePoint machine’s host file (C:\windows\system32\drivers\etc) does not contain invalid data.
4. SQL server service is running
It’s lame, I know, but I have seen this so just make sure your DB service of the correct instance is running:
5. TCP/IP protocol for SQL server is enabled
On the SQL box open SQL Server Configuration Manager and under Network Configuration node check that TCP/IP is enabled. (If you modify this don’t forget to restart the service)
6. Check listening ports and IP addresses
In SQL Server Configuration Manager open the Properties of the enabled TCP/IP protocol. Here you can specify the IP address and listening port of this instance. On the first tab if Listen All is enabled (Yes) the used port is in the IP Addresses tab’s last section, IPAll/TCP port. This means that the service listens on all interfaces on this port. Use netstat -ab to review this.
If it is not the default port (1433) you have to indicate this in your connection string (in Config Wizard’s database server parameter)
On the first tab if Listen All is disabled (No) you can set listening on individual ports and cards just don’t forget to enable at least one!
Wit this info in hand you should be able to telnet from the SharePoint machine to the specified port with the name to verify network connectivity.
If it does not work check firewall settings on the SQL box and between the servers.
7. Windows firewall
If windows firewall is enabled verify it blocks the connection or not. First enable logging here (do this on the profile you use): Windows Firewall with Advanced Security / Right click and select Properties / Click Customize in the Logging section:
- Log dropped packets : Yes
- Note the logfile’s path
Try to connect with telnet again from the SharePoint machine and review the content of the logfile.
To remediate this turn windows firewall off on the selected profile (or on all profiles) otherwise create an allow rule for this incoming connection, whichever suits your scenario.
8. Other connectivity check between your servers
If your telnet does not even reach the SQL server and there is nothing in the logfile maybe you have connectivity issues between your machines. Are there any firewalls between them? If yes, create firewall rules or ask your firewall team to do it.
9. SQL Server client alias setting
Type cliconfg on your SharePoint machine and review the alias tab. If there is any entry make sure it points to the correct server and you use the correct alias during configuration wizard.

My SQL alias points to server sql01 on port 1433 so I can use “sql5″ in configuration wizard to set up a connection
SQL alias has the advantage to change SQL server later easily (connection parameters) while the server name remains the same for SharePoint.
10. SQL permissions
On SQL server open the Application log in the event viewer and look for ID 18456, Category Logon. Don’t be fooled this won’t be marked as an error or warning, simple Information is the level.
Did you start the configuration wizard with your install account? If yes you have to check SQL Logins and assigned roles for your user with Management Studio (connect to your instance). Remember, your setup user needs a Login and have to be a securityadmin and a dbcreator! (http://technet.microsoft.com/en-us/library/ee662513.aspx)
If everything seems right you can always check the logs to gain more information, here they are again:
- Event viewer on the SharePoint machine
- SharePoint Products Configuration Wizard’s logfile in C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\15\LOGS (by default and their name’s start with PSCDiagnostics_<date>_<SomeID>)
- Event viewer on the SQL server
- Windows firewall logfiles
That’s all from me, if you miss something or you met with other problems, please let me know and I include it!
[Update]: 07.04.2013: Added Accounts section.
