Fixing missing server side dependencies: [MissingFeature]

Have you ever seen this while looking through the SharePoint Health Analyzer on your farm?

[MissingFeature] Database [Z_PRODRESTORE] has reference(s) to a missing feature: Id = [20e9ecab-2d22-41eb-892d-933afc32793e]. The feature with Id 20e9ecab-2d22-41eb-892d-933afc32793e is referenced in the database [Z_PRODRESTORE], but is not installed on the current farm. The missing feature may cause upgrade to fail. Please install any solution which contains the feature and restart upgrade if necessary.

It is certainly a bit cryptic.  SharePoint has a reference to a feature that doesn’t exist anymore, and its not too keen to give you any clues about it. But if you were to click here, you’d certainly find a melange of professional who’d be willing to tell you how you can get that feature.

This tends to happen when a feature has been removed from the farm, but not deactivated from the sites that may have been using it.  I encountered this recently with five of these such errors, and here is my approach:

Try and work out what the feature is

This doesn’t work in every case, but you can give it a shot, run this PowerShell command:

(Get-SPSite http://site ).Features

You may get some information out of the Properties property.  This helped me identify two InfoPath forms that I had removed from Central Admin, but hadn’t deactivated on a site collection.  Simply re-adding the forms, then deactivating the forms in the offending site collection made two of these errors go away.

The problem with this approach is that there may not be information available in the Properties property, and you may need to check every site collection to find the missing feature.

Solution 1 – the easy way

Thankfully there is a nice, elegant solution put together by Phil Childs:  Removing features from a content database in SharePoint 2010 using PowerShell.

Phil’s script will check all of the sites in a content database and programmatically remove the feature references – I’ve run this and it works as advertised.  If you can, run this on a non-production environment first!

Solution 2 – the hard way

I also found another way of achieving the same result and inspired by a comment left on a forum somewhere (and I cannot find the link!).  Essentially their suggestion was to create a feature with the same feature ID as per the error, install it onto the farm, deactivate the feature, and remove the dummy feature from the farm.

I tested this approach and I must say this did work!  Chapter 13 of Professional SharePoint 2010 Administration gave an excellent example on how to create a dummy feature and solution package.  Same note as above about running this on a test system before trying it on production.

Overall

If you can’t work out the missing feature and fix it easily, then go with Phil’s method per Solution 1.  If anyone is crazy enough to want to know more information about how to achieve Solution 2 and more info on the purest forskolin , drop me a comment below.

The Perfect SharePoint Upgrade

Upgrading WSS or MOSS to SharePoint 2010 at times can be an interesting challenge.  Microsoft gives plenty of guidance on how to perform an upgrade, either in-place or with a database attach method.  Having done a few upgrades now for different clients, I’ve recently completed one that could be described as the perfect upgrade, and thought I’d my experience.

The client already had a SharePoint 2010 environment, and a number of other legacy WSS and MOSS installations.  One of their WSS sites had previously been attempted by someone else but had failed when they tried to go live.  This meant that there was already some negative notions from the business that trying this again could be a problem. 

The only way forward was to start afresh.  Not knowing all the details from the previous attempt meant that I would need to get back to basics.  I decided that the best way to cover off all the issues would be to complete a trial upgrade, and have it thoroughly tested before attempting it for real.

We also managed to get great business buy-in to help us ensure they were happy that everything was working as expected.  The business representative even devised a very comprehensive test plan.

From performing the trial upgrade, we found a whole heap of problems, including:

  • Network communication problems
  • Authentication issues
  • Problems around search
  • Excel service issues
  • Absolute URLs
  • User understanding

Methodically, I worked through all of the issues and one-by-one solved these such that the business was happy to sign-off of the trial upgrade.  Surprisingly, there were not any problems with the actual SharePoint upgrade process itself!

I was very confident that the upgrade would be fairly smooth sailing.  I had made notes with every single step I performed to get the site ready for acceptance.  I had even made some timing notes so I could expect when things were happening. 

When it came time to perform the upgrade for real and go-live, everything worked perfectly.  There were only a handful of minor issues raised after the upgrade, all cosmetic and easily fixed.

There are some takeaways from this particular project:

  1. Have a good relationship with your client, and set their expectations that this is going to be a potentially complex process.
  2. Perform a dry run, and get business buy in for testing – including test plans.
  3. Generate a procedure document as part of the dry run, and document everything you do to make the dry run successful.  Having a re-executable plan should make the upgrade process a no-brainer.
  4. Communicate to everyone involved and keep them in the loop when appropriate.
  5. Be available after the upgrade to assist with any problems that may arise..

Reflecting on this, it is clear that process over technology is what helped make this a perfect SharePoint upgrade.

InfoPath: The SOAP message cannot be parsed.

A client wanted to use SSL across their SharePoint 2010 platform internally.  As part of that work, all of the InfoPath forms need to be updated.  There were three environments – Development, Test and Production.

The Production environment worked fine, but whenever I updated the data connections in Development or Test, I received the message:  “Unable to connect to the SharePoint site.  The SOAP message cannot be parsed.”

InfoPath_SOAP1

I struggled with this for awhile, and couldn’t work out what the problem was.  Whenever I reverted to non-SSL, I did not have any problems.  I initially thought that InfoPath did not like the self-signed certificates on Dev or Test, and I even tried domain trusted certificates similar to the Production environment, but to no avail.

I turned up full diagnostic logging on SharePoint, and it stood out that for some reason it was making requests to the non-SSL URL.  Whenever I tried it directly (eg http://xxtest01.xxx.internal/_vti_bin/Webs.asmx) I was redirected to HTTPS and received a valid response.

InfoPath_SOAP2

Finally, I took a look at the alternate access mappings, and discovered the problem – the public URL was not set to use HTTPS on Dev or Test, but was set to use HTTPS on Production.

InfoPath_SOAP3

As soon as I changed the public URL to https://xxtest01.xxx.internal, my problems in InfoPath disappeared and I was able to setup the data connections with SSL.

Converting SharePoint 2007 document library templates for SharePoint 2010

Following my previous article on Converting SharePoint 2007 list templates for SharePoint 2010, I received a comment last week on how to achieve this with document libraries, and more improtantly, how to do this with content.  It just so happens, I came across this very same scenrio a few months ago!
 
Essentially, the major difference is that instead of there being a single file involved to convert a list template, there are lots of files that need to be packaged back up – ie the binary files.
 
Now be warned, there is a 10 MB limit for exporting a document library with content, so do not reply on this as part of a migration strategy!
 
Here is the PowerShell script:
#Script:  UpgradeSharePointDocLibs
#Author:  Peter Heydon (www.heyweb.net)
#Date:	  03 June2011
#Purpose: This script will convert a SharePoint 2007 document library template with content to be SharePoint 2010 compatible.
#
#	WARNING: There is a 10MB limit on creating document library templates
#
#Credit for defining the conversion process:  http://tom-dw.blogspot.com/2010/06/importing-sharepoint-2007-list.html
#Credit for calling 7-Zip from Powershell: http://mats.gardstad.se/matscodemix/2009/02/05/calling-7-zip-from-powershell/
#Everything else cobbled together from Microsoft TechNet
#
#Requirements:
#	Three folders:	input		(SharePoint 2007 list templates)
#			output		(SharePoint 2010 compatible list templates)
#			processed	(SharePoint 2007 list templates that have been processed)
#	7z.exe (from 7-Zip installation: http://www.7-zip.org/)
#	makecab.exe (should be in your WINDOWS installation folder)
#
#WARNINGS:  There is zero error handling, so don't expect the script to be gracefull.  The script is supplied
#		'as is' and should be tested thoroughly before using in a production environment.  
 
### DEFINITIONS
$RootDir = "C:\temp\ps\"	#Ensure it has a trailing backslash ('\')
Set-Alias sz ("C:\Program Files\7-Zip\7z.exe")
Set-Alias mcab ("C:\windows\system32\makecab.exe")
 
#  Get list of all STP files
$InputDir = get-childitem ($RootDir + "input") 
 
foreach ($item in $InputDir | where {$_.extension -eq ".stp"})
{
	$targetFile = ($RootDir + "input\" +$item.name)
	$extractPath = $targetFile.substring(0,$targetFile.length-4)
 
	"Processing: " + $targetFile  
 
	#Create directory
	New-Item $extractPath -type directory
 
	#Expand STP File
	$extractPathOption = ("-o" + $extractPath)
	sz x $extractPathOption $targetFile
 
	#Start-Sleep -s 5
 
	#Replace files
	$manifestFileIn = $extractPath + "\manifest.xml"
	$manifestFileOut = $extractPath + "\manifestOut.xml"
 
	(Get-Content $manifestFileIn | ForEach-Object {$_ -Replace "<ProductVersion>3","<ProductVersion>4"} | Set-Content $manifestFileOut)
 
	#Cleanup files
	Remove-Item $manifestFileIn
	Rename-Item $manifestFileOut $manifestFileIn
 
	#Recompress (MakeCab)
	$cabFolder = $extractPath
	$filesToCab = get-childitem ($cabFolder)
	$itemNoExtension = $item.name.substring(0,$item.name.length-4)
	$NewSTPFileName =  ($RootDir + "output\" + $itemNoExtension  + ".stp")
	$ddfFile = New-Item ($cabFolder + "\~makecab.ddf") -type file
 
	Add-Content $ddfFile ".OPTION EXPLICIT"
	Add-Content $ddfFile (".Set CabinetNameTemplate=" + $itemNoExtension + ".stp")
	Add-Content $ddfFile ".Set Cabinet=on"
	Add-Content $ddfFile ".Set CompressionType=MSZIP"
	Add-Content $ddfFile (".Set DiskDirectory1=" + $cabFolder)
	Add-Content $ddfFile ".Set DiskDirectoryTemplate=CDROM"
 
	foreach ($item in $filesToCab)
	{
		Add-Content $ddfFile ("`"" + $cabFolder + "\" + $item.name + "`"")
	}
 
	mcab /f $ddfFile
 
	#Rename cab, and move to output folder
	Move-Item ($cabFolder + "\" + $itemNoExtension + ".stp" ) ($RootDir + 'output')
 
	foreach ($item in $filesToCab)
	{
		Remove-Item ($cabFolder + "\" + $item.name)
	}
	Remove-Item $ddfFile
	Remove-Item $extractPath
 
	#Move original file to processed folder
	Move-Item $targetFile ($RootDir + 'processed')
 
}

I haven’t tested this since I wrote it in February, and I don’t have a SharePoint 2007 environment handy at the point of this blog post.  Please leave a comment if it works or not. 

The SharePoint Pro’s Delivery Toolkit

I’ve been thinking about the applications I use regulary at work to help support the delivery of SharePoint projects.  I thought it would be a worthwhile exercise and list these out and to share what I use.

You will be surprised to find that this list has little to do with the SharePoint product, and more about the supporting tools that help me get on with my job.  They probably apply to many more cases than specifically a SharePoint Pro.  Here they are in no particular order:

  • Fiddler – a web debugger that is very useful for tracking many issues around SharePoint including authentiation (ie Kerberos), latency and proxy problems.
  • Lightscreen – My number one tool within the PortableApps suite, and just find it very quick and simple to use.  Great for grabbing that nasty error and to fill in documentation.
  • Password Safe – Perfect for keeping all the passwords in an organised fashion readily available.
  • Grindstone – Keeping track of time is a must for my role, and GrindStone makes it simple for me to keep track of my hours against projects.
  • Evernote – I ran my own wiki (Foswiki) for about a year running back to a PC at home, but I kept having problems with network connectivity, and just found the setup too unreliable (Foswiki itself was great for what I needed at the time).  Evernote is like a personal wiki on steroids, and great mobility options.
  • Putty – So what does an SSH client have to do with delivering SharePoint?  I can use it in the absence of telnet on a locked-down workstation or server for some rudimentary network tests, and I can in some cases use it to bypass proxy restrictions.

There are probably a few other, non-Microsoft tools that I use fairly regularly, but these are probably the main stable.  In all cases, these tools are also free to use, an added bonus.

What tools do you use?