Connecting SharePoint to SQL Server the right way

When configuring or setting up SharePoint, there are some practices that I take for granted. One of those things is to always refer to SQL server with the hostname only. You might think that using a fully qualified domain name (FQDN) is always a good practice, but in this case it isn’t. Just to be sure what I’m talking about:


New-SPConfigurationDatabase –DatabaseServer host.domain.tld


New-SPConfigurationDatabase –DatabaseServer hostname

Of course, the same is true when connecting or creating a farm in the SharePoint Configuration Wizard – but real admins use the command line, right?

Information about this topic is not only difficult to find, but also ambivalent - even on TechNet. The last time I was faced with this problem was when setting up the user profile service in SharePoint 2010. Spencer Harbar has documented this issue on his blog. However, for some applications (like Data Protection Manager) it seems to be a problem when you don’t use a fully qualified domain name for SharePoint.

A good practice to connect SharePoint to SQL Server is to use a SQL Alias, I’ve already written about this in earlier blog posts.

Moving away from using a FQDN

The best way to change this is to rename the server object in the configuration database:

Rename-SPServer host.domain.tld -Name hostname

On SharePoint 2007 the following stsadm command does the same thing:

stsadm -o renameserver -oldservername host.domain.tld -newservername hostname

A more drastic way would be to detach all servers from your farm (which is nothing more than your configuration database), and attach them back while using the correct hostname.

Although the methods above will provide some relief, there is no way to prevent SharePoint from using the wrong entry somewhere else in your configuration. So not using them in the first place still stands.