Posted by liquidpooled on May 20, 2010
Restoring site collections with stsadm is normally a straightforward affair, requiring little to no manual intervention to get things back up and running. That is of course, unless you are restoring sites based on the Publishing Site template.
I recently wanted to take an existing site collection, make a copy of it in the same web application under a newly created managed path and have it reside in a new content database. The backup went smooth, utilizing stsadm -o backup. The creation of the new managed path went off without a hitch. The creation of a new content database and the restoration of the site collection into that database also occurred with no issues.
Browsing the site however told a different story. I was immediately greeted with a standard error page stating “File Not Found”. Browsing to other pages within the site (eg. “/_layouts/settings.aspx“) yielded the same result. After turning on the callstack/debugging and disabling the custom error page, I was greeted with the following:
The problem? Each publishing page points to an incorrect page layout after the restoration. One would think that the restore via stsadm would recognize this and fix it, but it does not.
The fix? The stsadm extensions published by Gary Lapointe. The package built by Gary offers a command call gl-fixpublishingpagespagelayouturl. Verbose? Yes. Does it work? Absolutely.
After running the command and executing an iisreset, the site was once again able to be browsed and appears to be intact.
Reference
Posted by liquidpooled on October 2, 2009
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.
Posted by liquidpooled on August 21, 2009
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.
Posted by liquidpooled on March 17, 2009
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.
