Invalid or loopback address when configuring SharePoint against a SQL Server
I was presented with a connectivity issue when trying to configure SharePoint 2013 using a CTP build of SQL 2014. They got the following error when they were it was trying to create the Configuration Database.
Exception: System.ArgumentException: myserver,50000 is an invalid or loopback address. Specify a valid server address.
at Microsoft.SharePoint.Administration.SPServer.ValidateAddress(String address)
at Microsoft.SharePoint.Administration.SPServer..ctor(String address, SPFarm farm, Guid id)
at Microsoft.SharePoint.Administration.SPConfigurationDatabase.RegisterDefaultDatabaseServices(SqlConnectionStringBuilder connectionString)
at Microsoft.SharePoint.Administration.SPConfigurationDatabase.Provision(SqlConnectionStringBuilder connectionString)
at Microsoft.SharePoint.Administration.SPFarm.Create(SqlConnectionStringBuilder configurationDatabase, SqlConnectionStringBuilder administrationContentDatabase, IdentityType identityType, String farmUser, SecureString farmPassword, SecureString masterPassphrase)
at Microsoft.SharePoint.Administration.SPFarm.Create(SqlConnectionStringBuilder configurationDatabase, SqlConnectionStringBuilder administrationContentDatabase, String farmUser, SecureString farmPassword, SecureString masterPassphrase)
at Microsoft.SharePoint.PostSetupConfiguration.ConfigurationDatabaseTask.CreateOrConnectConfigDb()
at Microsoft.SharePoint.PostSetupConfiguration.ConfigurationDatabaseTask.Run()
at Microsoft.SharePoint.PostSetupConfiguration.TaskThread.ExecuteTask()
They had indicated that they had hit this before, and they worked around it by creating a SQL Alias. However this time it was not working. It was presented to me as a possible issue with using SQL 2014 and I was asked to have a look to see if this would affect other customers using SQL 2014.
I found some references regarding the error, and the majority of comments indicated to have SQL Server use the default port of 1433. Also some that said create an Alias. Some of the SharePoint documentation even shows how to change the SQL Port, and they also show how to create an Alias, but none really explained why this was necessary, or what SharePoint what actually looking for.
For this issue, it has nothing to do with SQL 2014 specifically and could happen with any version of SQL. The issue is what SharePoint is looking for. Whatever you put in for the Server name needs to be a valid DNS name. For a non-default port (1433), you would need to create a SQL Alias. If you create a SQL Alias, the name should be resolvable and not a made up name that doesn’t exist in DNS. Otherwise, you will get the same error.
Techie Details
I started by looking at the error first. Of note, this is a SharePoint specific error and not a SQL error.
Exception: System.ArgumentException: myserver,50000 is an invalid or loopback address. Specify a valid server address.
at Microsoft.SharePoint.Administration.SPServer.ValidateAddress(String address)
This was an ArgumentException when SPServer.ValidateAddress was called. I’m going to assume that the string being passed in is whatever we entered for the database server. In my case it would be “myserver,50000”. I’ve seen this type of behavior before, here is one example. My first question was, what is ValidateAddress actually doing? I had an assumption based on the behavior that it was doing a name lookup on what was being passed in, but I don’t like assumptions, so I wanted to verify.
Enter JustDecompile! This is a create tool if you want to see what .NET Assemblies are really doing. The trick sometimes is to figure out what the actual assembly is. I know SharePoint 2013 using the .NET 4.0 Framework, so the assemblies that are GAC’d will be in C:\Windows\Microsoft.NET\assembly\GAC_MSIL. After that, I go off of the namespace as assemblies are typically aligned to the namespaces that are within it. I didn’t see an assembly for Microsoft.SharePoint.Administration, so I grabbed the Microsoft.SharePoint assembly within C:\Windows\Microsoft.NET\assembly\GAC_MSIL\Microsoft.SharePoint\v4.0_15.0.0.0__71e9bce111e9429c. This prompted me to load a few others, but it told me which ones to go get.
Within the Microsoft.SharePoint assembly, we can see that we have the Administration namespace.
So, now we want the SPServer object and the ValidateAddress method.
internal static void ValidateAddress(string address)
{
Uri uri;
if (address == null)
{throw new ArgumentNullException("address");
}
UriHostNameType uriHostNameType = Uri.CheckHostName(address); <-- This is what gets us into trouble
if (uriHostNameType == UriHostNameType.Unknown)
{
object[] objArray = new object[] { address };
throw new ArgumentException(SPResource.GetString("InvalidServerAddress", objArray)); <-- The exception will be thrown here
}uri = (uriHostNameType != UriHostNameType.IPv6 ||
address.Length <= 0 ||
address[0] == '[' ||
address[address.Length - 1] == ']' ?
new Uri(string.Concat("https://", address)) : new Uri(string.Concat("https://[", address, "]")));
if (uri.IsLoopback)
{object[] objArray1 = new object[] { address };
throw new ArgumentException(SPResource.GetString("InvalidServerAddress", objArray1));
}
}
Uri.CheckHostName Method
https://msdn.microsoft.com/en-us/library/system.uri.checkhostname.aspxDetermines whether the specified host name is a valid DNS name.
So, if the string we pass in cannot be resolved via DNS, it will fail. We never get to the point where we actually hit SQL itself.
Adam W. Saxton | Microsoft Escalation Services
https://twitter.com/awsaxton
Comments
Anonymous
October 08, 2013
The comment has been removedAnonymous
January 14, 2014
Is there a workaround for this? I am receiving this after upgrading to SSRS 2012 in SharePoint Integrated mode. We are hosting the databases on a non default port. Aliases aren't working. Machine,port isn't working. Is there a host file entry we can make? In our case it would need to be machine specific so it can be applied to our three environments. I am hoping there is a way to get around having to enable the SQL Browser service in order to specify the instance name.Anonymous
January 19, 2014
An alias should be a valid workaround for this. That is really the only workaround available if you want to use a non-standard port for a default instance. SharePoint will use the .NET SqlClient to connect and it should look for an alias if one is available. If the SharePoint process is x64, make sure the Alias is x64 as well (from a registry perspective).Anonymous
April 23, 2015
The comment has been removedAnonymous
April 23, 2015
Forgot to mention: The default SQL instance name is MSSQLServer Hence the connection was: SQLAvailabilityGroupMSSQLServer,Portname