How to delete the default SSP

I somehow mucked up the provisioning of a default SSP in a clean dev environment and figured this would be a good opportunity to figure out how to delete a default SSP using stsadm; the Delete option on the context menu in Central Administration was greyed out (most likely because this was the default SSP but conceivably because provisioning failed) and simply editing the SSP properties was not an option as SharePoint was complaining about empty strings or some such stupidity associated with the underlying problem (a database login issue). Of course the “normal” way to do this would be create a new SSP and pull across any sites before marking it as the new default SSP.

As usual, where the Central Admin UI is somewhat limited and incomplete, stsadm saves the day with the deletessp operation. Simply provide the SSP title (enclosed in double-quotes if it contains spaces). In my case I also wanted to cleanup the databases so I supplied the –deletedatabases parameter.

stsadm -o deletessp -title "Default SSP" -deletedatabases

The operation failed with an error message about dependent objects.

An object in the SharePoint administrative framework, "SharedResourceProvider Name=Default SSP parent=SPFarm Name=SharePoint_Config_dev-moss-mh6", could not be deleted because other objects depend on it.  Update all of these dependants to point to null or different objects and retry this operation.  The dependant objects are as follows:
SPWebApplication Name=x Parent=SPWebService SPWebApplication Name=y Parent=SPWebService

Not surprisingly there are posts out there detailing the use of the stsadm deleteconfigurationobject operation to force disconnection but this involves retrieving GUIDs from the configuration database and others have suggested additional mess will need to be cleaned up in the same way. Instead, just use the –force parameter on the deletessp command.

Once complete, you should see an Operation completed successfully message.

Access is denied. Check that the Default Content Access Account has access to this content

I ran into this error in the crawl log for the Local Office SharePoint Server sites content source:

Access is denied. Check that the Default Content Access Account has access to this content, or add a crawl rule to crawl this content.

I had configured the default content access account within the search administration and granted Full Read access to the same account from Central Admin\Application Management\Policy for Web application; the site to be crawled also had an include crawl rule configured. As a test, I also added the default content access account to the [SiteName] Visitors group with no effect. Oddly enough, some of the site content was being crawled (well a single document anyway) but I just don’t like error messages ;-)

The environment in question is a Windows 2003 SP1 machine with MOSS 2007 SP2 and .NET 3.5 SP1. It’s a dev environment and it’s also configured with the Active Directory and DNS roles and runs SQL Server 2005 SP2. Site-wise, MOSS is hosting a single test site configured to use a host header on port 80 with a DNS A record pointing to 127.0.0.1. And therein lay the problem…

Apparently Windows 2003 SP1 introduces a “loopback check security feature […] designed to help prevent reflection attacks.”

http://support.microsoft.com/kb/896861

The KB article also describes two work arounds for the problem, the first being to list the host names mapped to the loopback address (127.0.0.1) and the second disabling the security check.

Method 1: Specify host names

Specify the host names that are mapped to the loopback address:

• Click Start, click Run, type regedit, and then click OK.
• In Registry Editor, locate and then click the following registry key:
  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0
• Right-click MSV1_0, point to New, and then click Multi-String Value.
• Type BackConnectionHostNames, and then press ENTER.
• Right-click BackConnectionHostNames, and then click Modify.
• In the Value data box, type the host name or the host names for the sites that are on the local computer, and then click OK.
• Quit Registry Editor, and then restart the IISAdmin service.

Method 2: Disable the loopback check

• Click Start, click Run, type regedit, and then click OK.
• In Registry Editor, locate and then click the following registry key:
  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
• Right-click Lsa, point to New, and then click DWORD Value.
• Type DisableLoopbackCheck, and then press ENTER.
• Right-click DisableLoopbackCheck, and then click Modify.
• In the Value data box, type 1, and then click OK.
• Quit Registry Editor, and then restart your computer.

Note: In my case this took effect without resetting the server; although other suggestions recommended restarting IIS, I didn’t have to do that either.

SSP Access Denied

It's quite easy to be faced with an Access Denied screen after creating a Shared Service Provider (SSP) but it's not always so easy to fix the problem.

In most cases, treat your SSP admin sites like any other SharePoint site and ensure the correct users have been granted the necessary access permissions (yoursite/ssp/admin/_layouts/settings.aspx and then People and Groups). You'll generally want to access the SSP site to configure these permissions using the account used to create the SSP in the first place; if that fails, try the account used to run the IIS app pool of the SSP admin site. If that fails, read on...

Before diving in I want to mention this issue has been covered before in various places with the most notable items being Faraz Khan's post; the post includes a plausible explanation of the problem provided by "Scott" in the post's comments. A social.technet thread also points to the same post and some some additional solutions are reported. When I encountered this problem I found both sources cumbersome to wade through and difficult to decipher so I'm summarising the steps I took to fix the problem.

Also, a disclaimer of sorts. SharePoint and MOSS are finicky beasts so while the solution described below may seem to work, I expect a better solution would be to delete the problem SSP after creating a replacement and making it the default SSP (see below to find out what’s causing the problem before you recreate). I’m not certain the solution described won’t introduce new problems (but so far so good in the proof-of-concept environment I’ve built).

To setup, let's assume the following:

• You've created a new SSP named Default SSP
• As part of the SSP provisioning process, you've created a new SSP admin site with an app pool named Default SSP
• The app pool of the SSP admin site account is configured to use the SSP_APP account
• The SSP itself is configured to run as the SSP_SVC account
• When you try to access the site using the account used to create the SSP, the SSP_APP app pool account, or the SSP_SVC service account, you receive an Access Denied error; you can however access /ssp/admin/_layouts/settings.aspx as the SSP creator
• Inspecting the Default SSP app pool, you find the identity is set to run as SSP_SVC instead of SSP_APP as specified above. Changing the identity back to SSP_APP sticks for a few seconds but quickly reverts to SSP_SVC.
• Nothing is reported in the event logs

According to legendary "Scott", the problem occurs because the application pool configured for use by the SSP's admin web application has the same name as the SSP itself (Default SSP). Apparently MOSS independently creates another app pool named after the SSP and running with the SSP credentials (SSP_SVC) for use by the “Office Search site”. The Office Server Web Services web site does have a child web application named Default SSP that is also configured to use the Default SSP app pool. It makes sense that since an app pool with the same name already exists, MOSS either recreates it or magically updates it on a scheduled basis.

To resolve the problem:

• From IIS Manager, right-click the app pool intended for use by the SSP admin site (eg. Default SSP)
• All Tasks -> Save Configuration to a File… and specify a location where you can easily find the output file
• Open the saved .xml file in notepad and change the two references to “Default SSP” (or whatever you’ve named your SSP/SSP admin site account):
  1. The Location attribute of the IISApplicationPool element - change Default SSP to Default SSP App
  2. The Location attribute of the IISInheritedProperties element - change Default SSP to Default SSP App
• Save the file
• Right-click on the Application Pools folder in IIS Manager
• New -> Application Pool (from file)...
• Locate and select the file, click the Read File button, select the configuration, Ok
• Configure the Default SSP web site to use the new app pool (Properties -> Home Directory tab, Application pool drop down)
• Repeat for the /images and /inc applications below the _layouts child site (Default SSP/_layouts/Images, inc)
• Reset IIS for good measure

You’ll now have two application pools, Default SSP and Default SSP App. Don’t delete the original as it’s still in use by Office Server Web Services web site and may get recreated anyway.