Tip #1 – There are two easy ways to tell which build of SQL Server you are running:

1.  
   1. In SQL Server Management Studio, right click on the Server connection and click on Properties:
   2. Run this query: SELECT SERVERPROPERTY(‘productversion’), SERVERPROPERTY (‘productlevel’), SERVERPROPERTY (‘edition’)

Tip #2 – At the time of this posting, this link contains the patches for all SQL Server builds.  Found this very helpful when trying to get my SQL Server 2008 ready for SharePoint 2010, which required Cumulative Update 2 for SP1.

While installing and configuring SharePoint Server 2010 in a extranet QA environment, I encountered an exception when running the SharePoint Configuration Wizard, which generates the SharePoint Config database among other things.  A dialog displayed an error of type System.ArgumentNullException… Parameter name: errorData:

This wasn’t very helpful, so I checked the SharePoint Log files under the 14 hive.  Again, nothing interesting.  Finally checked the event log and found a SQL exception error was occurring with SharePoint Foundation.  The error text from the event log was as follows:

Unknown SQL Exception 53 occurred. Additional error information from SQL Server is included below.

A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: Named Pipes Provider, error: 40 – Could not open a connection to SQL Server)

It would appear that there was a problem connecting to the database server (SQL Server 2008 SP1) from the server that SharePoint was being installed.  Working with the Database and Networking administrator, we found a few things that were not quite up to snuff.  It would be nice to say that one or a combination of the fixes that we executed resulted in fixing this problem, but it is not that clear.  Safe to say none of these tasks listed below were detrimental to the systems or the network.  Here is a run down of those tasks that enabled the configuration wizard to work:

1. Alias – We found that the SQL alias that was defined, which we use in place of the actual SQL server name, was not setup properly in the SQL Server settings.  Rather, it was completely missing.  We added that back.

2. SID – Ran NewSID on the new SharePoint 2010 server as it was spun up using VMWare tools.

3. DNS – The DNS servers assigned to the SharePoint Server 2010 were two domain controllers for the extranet domain. The two DC’s did not have access to the internet and thus could not resolve DNS queries for external domains (i.e. www.microsoft.com,  www.google.com, etc), which means any clients configured to use these servers for DNS resolution would also not be able to access the internet. For this reason, Windows update would not run on the SharePoint 2010 server, against the Microsoft update servers on the internet. The DNS configuration on the SharePoint server was temporarily changed to point to a DNS server which was able to resolve external domains, and Windows updates were run.  But we had forgotten to change the DNS configuration back to the original DC. This resulted in the SharePoint 2010 server not authenticating to the domain. Additionally, in this configuration, the server would not have been able to resolve the FQDN of the SQL server.

4. Time – The local time on the database server was off, because it wasn’t authenticating to the extranet domain properly and getting it’s time set by the domain controller.

5. FQDN Server Name – We were entering the database server name in the Wizard without the fully qualified domain name.  We added the “.domain.com” to the server name, ran the SharePoint Configuration Wizard and were able to make a connection to the database server, create the databases and complete the configuration.

Shout out to Chris Ryan for his assistance getting this resolved!