Note, this blog entry demonstrates how to restore a shared service provider administration site. Before you get your hands dirty it would be a good idea to backup up your SharePoint databases, and to ensure you still have all the necessary databases for the SSP that is throwing the error below.
The other day I found a pretty strange error in the event log on one of our shared development machines. It sang a little to the tune of:
Event Source: Office SharePoint Server
Event Category: Office Server Shared Services
Event ID: 5290
Time: 9:02:01 PM
There is no administration site associated with the Shared Services Provider SharedServices1.
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
This is a pretty unfortunate error. I usually happens when someone accidentally deletes a Shared Service Provider administration site. People usually do it because they think it's a rogue site that no ones using and often the content database (for the admin site, not the SSP) gets deleted too.
What's a Shared Service Provider?
When you install a MOSS as a stand alone farm (all on one machine) a couple of web applications are created for you.
- A default site stubbed out with dummy content.
- The Central Administration Site (to administrate the farm).
- A Shared Service Provider which is hosted in a web application.
- An administration site to administer the default Shared Service Provider.
If you did an advanced install you probably ended up creating these items individually at some point during your more lengthy install process. But then again if you're savvy enough to set up a WSS/MOSS farm you're probably not the kind of character to accidentally delete an administration site.
Shared Service Providers (SSP) provide a lot of the extended functionality that is WSS/MOSS. SSP's are responsible for things like Search/indexing, My Site hosting, Profiles, Audiences (for content targeting), Portal Usage Reporting (enhanced Usage reports), Excel Services, and the Business Data Catalog. Most of that list is implemented only in MOSS.
Any ways you normally administer all these Shared Services with a series of SSP Administration Sites...but someone's gone and deleted one! Now before you go fire someone understand that it's kind of an understandable mistake, plus you can create a new one and hopefully not loose any data from your SSP. The SSP Admin Site looks like a random SharePoint site, something like http://ServerName:#####. The numbers are pseudo random, the one I went and deleted for these screen shots was at http://w2k3-tyler-virt:44778. It's of note that this may be more complicated for a farm scenario since services are usually spread over multiple SSPs which will have many content databases spread over (potentially) many machines. I would not recommend following the steps below to repair trouble in a farm. Stand alone installs only.
Recreating a Shared Service Provider and Admin Site
The easiest way out of this is to create a new admin Site. I'm going to naively assume that this is on a stand alone install, if it's in an enterprise farm you probably need a little more instruction than a blog entry given that you could have a lot more complexity in play.
- Open up the database instance for your WSS/MOSS instance. If you don't know what I'm talking about instructions can be found here. Ensure that you still have databases for the SSP that you deleted. If your Shared Service Provider was called SharedServices1 then you're looking for a database of the form (default names at least) SharedServices1_DB_[GUID] and SharedServices1_Search_DB_[GUID]. For example my databases were called: SharedServices1_DB_6c907a40-1cea-4599-bf83-13c3157f08d0 and SharedServices1_Search_DB_3de60ba5-022e-494b-8042-d6df471167b3. Rolls off the tongue huh?
- Open up the Central Administration Site and click on "Shared Services Administration". If you really have deleted the site the name of the Shared Services Provider (ie. SharedServices1) is probably a dead link.
- Click on New SSP to create a new one. We're going to do this so that we can set the new SSP to be the default and delete the old SSP (without deleting it's databases). Then we're going to restore the old SSP from it's content databases, make it the default SSP and finally assign the web applications back to it.
- Fill out all the fields (I named mine SharedServices2 in honor of it's fallen brother). Create a new Web Application to house this site, put it in it's own Application Pool. For some of the more background information on configuring an SSP and what the fields do there's this technet article. For a stand alone install I ended up using NT AUTHORITY\LOCAL SERVICE as a credential which I'm still not sure if it's the appropriate credential. I was a little scared that Network Service might not have enough mustard to get at all the content it needed. A lot of this won't matter until you need to do the restore and you'll have to put in values that you really care about. When creating the SSP at this step ignore the warnings and just familiarize yourself with the options.
- If this worked out we should see something like the picture below, two Shared Service Providers. Our now make SharedServices2 (or whatever you called it) the default SSP and delete SharedServices1 so we can restore it as a new SSP (that has an Administration site).
- Click on Shared Services Administration->Change Default SSP (from the Shared Services Administration) and choose your new SSP (SharedServices2).
- Delete the original SSP (SharedServices1) by choosing delete from it's context menu. DO NOT DELETE IT'S ASSOCIATED DATABASES! This might take a second to complete.
- Now there's just one SSP (SharedServices2), notice how SharePoint automatically assigns the web applications in the farm to use this SSP. Now we're going to click on Restore SSP and restore the original SSP with a brand new Administration site. Name it SharedServices1 and fill out fields similar to what you did in step 4. Create a new web application and when it comes time to fill out the fields for Search Database and but this time fill out the two databases for the SSP. This will include the databases that we identified in step 1. IE. SharedServices1_DB_6c907a40-1cea-4599-bf83-13c3157f08d0 and SharedServices1_Search_DB_3de60ba5-022e-494b-8042-d6df471167b3. This will ensure that you don't lose all your data from the SSP like Search Content Sources, Excel Services Settings, Audiences, BDC etc...
- No we should have two working SSPs, SharedServices1 and SharedServices2. Click Change Default SSP and change it back to SharedServices1. After that delete SharedServices2 (this might take a while). Don't feel guilty about deleting associated content databases either, there's no real important data in them anyways. SharePoint should make all your web applications use your newly restored SSP (SharedServices1). You should almost be good to go.
- When you're all done it should look like below. If you wait long enough everything should propagate but if you want immediate results I'd suggest rebooting the machine and making sure that the error is no longer in the event log AND all your settings are still kosher in the SSP (ShareServices1) admin site. I know there were quite a few steps but this was hard to break down and still provide any measure of detail.
That's it, hopefully that made a little bit of sense. I get the feeling that for anything more than 5 steps a screen cast is probably in order. I may start to get into that I heard that MS offers free Silverlight hosting for videos.