http://cs.thomsonreuters.com/resources/white-papers/PracticeCS_Best_Practices_for_Implementation.pdf
So when setting up a SQL database on SBS 2008 the best thing you can do is to not reuse the SQL that is already there.
This ensures that you are not accidentally stomping on top of what is there and ensures that it instance is separate for maintenance purposes.
Then you need to open up holes in the server firewall to handle the SQL. Now the instructions in the documentation said that I needed to open up the program for SQLbrowser, but I also found that I needed to open it up for SQLServer.exe Now why didn't I just do a UDP port 1434? Because the installer set up a dynamic tcp/ip SQL connection and opening it up for the application is a safer way to do so.
Go into the server, go to network connections, at the bottom the "see also" section and click on windows firewall. Set up an exclusion for the SQLserver
[location of the SQL] :\Program Files (x86)\Microsoft SQL Server\MSSQL.3\MSSQL\Binn\sqlservr.exe
And I also edited the scope so that it wasn't "Any computer (including those on the Internet)" but "My network (subnet) only" since we use RWW and we won't be entering time over a VPN connection.
When I was debugging what specifically to poke in the firewall, netstat -ano wasn't helpful as the number of DNS ports that the Win2k8 server randomizes meant that I couldn't see what the SQL for the instance was listening on. Using http://technet.microsoft.com/en-us/sysinternals/bb897437.aspx TCPview was a more efficient way to figure out where the box was listening at and why SQLbrowser wasn't cutting it and why I needed SQLserver.exe instead.
