Removing troublesome Shared Service Providers

Wow, it's been a looooong time since I've blogged here - a lot on my plate I guess. Anyway, on with the show.

I recently attended a customer, here in Sydney, with a number of SharePoint issues. One of these was an inability to delete old, defunct SSPs in Central Administration. For some reason, the IIS websites and the SQL Content databases had been removed (or lost during a recovery), and the SSPs couldn't be removed via the Central Admin UI.

"Hmmmm", thought I. "What can we do here?"

First port of call when the UI is behaving oddly? stsadm.exe.

Our command line tool can do pretty much everything the UI can do, and if it can't, then you can extend it yourself or use a third-party extension.On this occasion, though, it still failed, returning a "database not found" error.

 stsadm.exe -o deletessp -title "My Broken SSP"

Deleting an SSP, logically, includes some database work, so this seemed like the problem's heart - the databases were already long gone and we seemed to be in a catch-22. It may be possible to delete the SSP directly from the database using a whole boatload of painstaking care and attention, but that's an utterly unsupported operation which could render one's farm useless. So what's an engineer to do?

Well, it turns out that there is a command line switch which is not documented in stsadm's -help information.

 stsadm.exe -o deletessp -title "My Broken SSP"  -force

The force switch basically ploughed on ahead at the "database not found" error, assuming rightly that the database was already gone. It ignored the fact that the IIS sites were missing, and it successfully cleaned up our rogue SSPs. This was a triumph.