Disclaimer : This post is written from the perspective of a developer setting up a dev/test system. For production purposes you need to thoroughly understand the security implications of all the setting listed below. But you knew that already.

Back in the good ol days you never had any trouble getting apps connecting to SQL Sever. Username “sa” and a blank password and you were good to go Things are a bit more difficult now…

This particular example walks through installing Windows SharePoint Services on one server (a virtual server, but it makes no difference) connecting to a SQL Server 2008 Express database Instance on another server.

Both servers are using the same domain. This kb 932376 should help if you are running SharePoint and a Database on servers in different domains or no domain at all.

Firstly, install SQL Server on its own instance (lets assume the machine is called SQL2008EXP and the instance is called SharePoint). There’s a whole big process here that involves what is possibly the worlds most complex installer that inexplicably leaves you manually hunting for all the pre-requisites (Windows Installer 4.5, NET 3.5 SP1, Powershell – but that’s all out of the scope of this post). Seriously Microsofties, you have outdone yourselves with this installer!

Grumbling aside – setup a Domain Account (A) that the SharePoint services will use. As usual for service account make it ‘password never expires’ and uncheck ‘user must change password on first login’.

Start Microsoft SQL Server Management Studio and go to Security > Logins, right click and select New Login. Enter your DOMAIN\UserName (A) that you created above. Select Server Roles and check dbcreator and securityadmin.

Install WSSv3 (SP1 or above) – select Advanced and then “Web Front End” as we want to use SQL Server not MSDE.

The SharePoint Products and Technologies Configuration Wizard should start automatically

Select “No, I want to create a new server farm”

Fill in the account details that you setup earlier (A)

Get the follwoing error

Now its time to waste 2 hours of your life pinging servers, checking names, passwords, permissions and event logs. Or feel free to skip this step and carry on below :-

SQL 2008 installs in a state that will stop you connecting from a remote server.

This is not done out of badness, but for security.

Start SQL Server Configuration Manager

Expand the SQL Server Network Configuration node and find the Protocols for your Instance

Right click on TCP/IP and click Enabled - do the same with Named Pipes

Right click on TCP/IP and click Properties. Select the IP Address tab and make a note (B) of the TCP Dynamic Port

Restart the SQL server service

When you connect to a SQL Server instance via TCP/IP the connection attempt will query the SQL Server Browser service (on port 1434) and find out which port a specific instance is set to listen on. However by default the SQL Server Browser service is disabled. You can now either start it or use the Port number (B) you found earlier to connect directly.

Confusingly the syntax is different to what you may expect – no semi-colons here, use a comma

ServerName\InstanceName,PORT

(If you are using a default instance then the connection will happen on port 1433 by default and you won’t have to enter the port number or worry about the SQL Browser service)

If you have a firewall running you will also have to open up this port number for incoming TCP connections. See Windows Firewall or the Firewall guide for SQL Server 2005

Further reading SQL Server 2005 Remove Connectivity Issue Troubleshooting (most steps applicable to 2008)