mylifeinaminute.com

When upgrading from a standard SKU to an Enterprise SKU in SharePoint (MOSS 2007), things can (and do) go wrong. Come to think of it, I’ve never seen one complete successfully without some type of manual intervention. Fortunately, the majority of errors that are experienced are recoverable. Take for instance:

An existing request to enable the Enterprise feature is in progress. To check the status of this request, go to the Timer Job Status page in Central Administration Operations and check the status of the Office Server Enterprise Features Upgrade Job.

When you find the job in the Timer Job Status page, you will see that it needs to run on all servers in your farm. Chances are it has failed on one (or more) servers. The quick fix? Restart (or start if stopped) the Windows SharePoint Services Timer service on the server where the upgrade job failed. After the job has completed, return to Central Administration to verify that your farm has been upgraded.

One of my pain points as a SharePoint “administrator” is having to deal with deployments of solution packages to my environment without the best change management. This means that I often see packages making their way in to the environment without any thought given to keeping the package in case it needs to be reapplied at a later time (Note: I’m not the only one who controls what goes into the environment).

The solution? I whipped up a Windows application so download one, several, or all of the solution packages currently stored in the farm configuration database.

I have posted the application to CodePlex @ http://spsolutiondownloader.codeplex.com/.

The application must be run in the context of a Farm Administrator (i.e. right-click, Run As…) on a server in the farm for which you wish to download the solution package(s) from and requires the .NET Framework 3.5.

I would love some feedback from the community as to whether or not this useful. I have some other little apps in mind I could put together with the proper motivation.

I’ve found that working with InfoPath is becoming more and more of a chore.  A form I’ve been working on has had its promoted columns changed a number of times (Side note: I would just love to have a defined specification).

Today when I attempted to completely retract my form (inlcuding manually deleting the content type associated with the form), I was presented with the always helpful error “The content type is in use“.  This is by far one of the more helpful errors you will ever see from SharePoint.  Unfortunately it isn’t clear how to discover where the content type is actually in use.  A quick trip to the content database for the site collection you are working in can show us:

DECLARE @ContentTypeName nvarchar(128)

SET @ContentTypeName='Content Type Name Here'

SELECT w.Title AS [Web Site], w.FullUrl AS [Web Url], al.tp_Title AS [List Title],
	ct2.*
FROM ContentTypes ct1
	JOIN ContentTypes ct2 ON LEFT(ct2.ContentTypeId, Len(ct1.ContentTypeId))=ct1.ContentTypeId
	LEFT OUTER JOIN dbo.ContentTypeUsage ctu ON LEFT(ctu.ContentTypeId, Len(ct2.ContentTypeId)) = ct2.ContentTypeId
	LEFT OUTER JOIN dbo.AllLists al ON ctu.ListId = al.tp_Id AND ctu.WebId=al.tp_WebId
	LEFT OUTER JOIN dbo.Webs w ON al.tp_WebId = w.Id WHERE ct1.ResourceDir=@ContentTypeName

[Credit to Curtis Ruppe]

Once we know where the content type is in use, deleting it through the GUI is a trivial matter.

MSDN Magazine has a SharePoint focused article this month titled 10 Best Practices For Building SharePoint Solutions. If you’re trying to wrap your head around the scope and depth of developing solutions on top of SharePoint, the article makes for a good primer.