If you are like me, you tend to deal with strange development nuances in the SharePoint environment.  One of those nuances is trying to delete a content type that is in use.   When I’m developing a solution that requires the creation of content types within the feature, I typically create that content type through code.  That will work on the first deployment of the feature since it does not exist yet.  On subsequent deployments, you will get an error that either the content type is in use (if you are trying to delete it before adding) or the content type already exists.  One thing I do is disable the deletion/creation of the content type if I’m not making any changes to it on subsequent deployments.  That will save a bit of development time.  The second problem I get every so often is the “content type still in use” error when trying to delete a content type.  I find this to happen if I am careless with removing items from a list, especially workflow tasks that are associated with a content type. 

I found a decent SQL Script (below) on the interweb that displays all the instances of my content type in the SharePoint databases.  In some cases, this will tell me where the “remnant” of the content type is and I can remove it.  Other times, it will display something that I already removed and I’m stuck.  If that happens, I first blow away the list where the content type was associated.  If the list removal doesn’t work, I will delete the site collection and build a new one.  (That is a luxury of having my own development VM.) I found that course of action to be quicker than trying to go through the database structure to find where to delete all instances of that content type.

Sources: 1

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!