SQL Server tips helpful when installing SharePoint 2010

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

    1. In SQL Server Management Studio, right click on the Server connection and click on Properties:sql_server_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.

1 Comment

SharePoint Configuration Wizard failing with SQL Exception – A number of possible fixes

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.comwww.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!


1 Comment

Running SQL Management Studio as alternate user

At times, you may want to run SQL Server Management Studio as a different user than the AD account that you are logged into Windows.  This command run from the command line will let you do just that (your path to the location of ssms.exe may be different). Change the domain\admin_user to the user you’d like to “run as”:

runas /noprofile /netonly /user:domain\admin_user “C:\Program Files (x86)\Microsoft SQL Server\100\Tools\Binn\VSShell\Common7\IDE\ssms.exe”

Note! If you are running this command locally, leave off the “/netonly” property – Thanks DCON!


Three blogs in One: 1. How to get the PublicKeyToken of your assembly. 2. Where are the .Net utilities for VS 2008 SP1 / Windows Server 2008? and 3. Fixing the WinSDK Configuration Tool

As I was building a custom SharePoint feature in a newly built VM image (consisting of Win Server 2008, MOSS 2007, VS 2008 SP1), I tried to access the PublicKeyToken of an assembly I had just built in order to update the Manifest file of the solution.  I typically use the Strong Name tool (SN.EXE ) with the –T (notice the capital T for an assembly) option to display that publickeytoken for the assembly.  Generally, the .net utilities are located in the .Net Framework path.  But, when I checked that path, there were no files at all. 

Little did I know where that small task would lead me…

Initial research suggested installing the Windows SDK for Windows Server 2008 and .NET Framework 3.5, which I did install.  It took a little bit of searching on the file system to find the SDK tools, but I found it under C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin.  Great, I’ll just run my strong name tool and all will be well.  But, when I looked at the new path, I noticed there were two versions: v6.0A and v6.1.  Curious about the difference between the two, I looked at the original SDK download page closer and noticed that I had overlooked an important comment on the download page ”Installing the newly released Microsoft Windows SDK for Windows 7 and .NET Framework 3.5 SP1 instead of this release is recommended. If you do go ahead and install this SDK after VS2008 SP1, please ensure the patch described in Knowledge Base 974479 is applied. See Overview section for more information.”

As it turned out, the introduction of the bug really occurred when I installed Visual Studio 2008 Service Pack 1.  By installing the Microsoft Windows SDK for Windows 7 and .NET Framework 3.5 SP1, this fixed the problem with the SDK Configuration Tool (which I set to 7.0) and I could now run the sn –T assembly.dll.  By the way, the location of the SDK .Net utilities after the correct SDK installation is under C:\Program Files\Microsoft SDKs\Windows\v7.0\bin

Sources: 1

, ,

Leave a comment

How to find the version level of SharePoint you are running?

An excellent blog article with details on SharePoint versions

To find out the SharePoint 2007 version within Central Admin, navigate to “Central Administration > Operations > Servers in Farm”

For SharePoint 2010,  go to Central Administration, under Upgrade and Migration, click Check product and patch installation status to view version numbers


Leave a comment

Backup and Restore SharePoint from Windows Internal Database

I was presented with an instance of SharePoint (WSS 3.0) that was installed on a single server that utilized SQL Server 2005 Embedded Edition or as it is now called “Windows Internal Database.”  This instance of WSS was being used internally be a select group of savvy users to “test” out the functionality of SharePoint before the roll out to the rest of the company.

We had reached a point in the process where we wanted to sunset the test instance and move the content that had been generated over several months to the production server.  The next step was to backup the web application containing that content.  The backup through Central Admin went fine, but the restore on the production server did not work.  The problem was that the service account that was restoring the database in production did not have rights to the instance that was backed up on the single server.  My first thought was, fine, I’ll just add the production service account to the security login for that content database on the single server in SQL Management Studio…  I’ll just connect to it from there.  It was then that I realized this was a “Windows Internal Database.”  How do I connect to the database?  After a little research, I found that the best way was to install SQL Server Express on the single server and connect to it using a somewhat odd connection string: “\\.\pipe\MSSQL$MICROSOFT##SSEE\sql\query”   I installed SQL Service Express, added the production service account and gave it dbcreator and securityadmin server roles in SQL Server.  The import was successful after that change. 

Sources: 1 2


Leave a comment