How to force deletion of a SSP stuck in unprovisioning state

Sometimes things go wrong with the SSP (life without it in SharePoint 2010 shall be interesting…) If you have one that will not delete, gets stuck in an “unprovisioning state”, cannot be opened or similar try this extra flag:

“Stsadm -o deletessp -title SSPNAME -force“.

The -force will normally delete the entry even if there are errors occurring.


IF you’ve worked with SharePoint for any amount of time you know that is not always the word one would use to describe your experiences. Sometimes that command just does not work and you end up with a lingering SSP. To resolve you need to identify the GUID for the problem SSP and use STSADM -o deleteconfigurationobject -id “id retrieved from object table” to remove this/these item/s from the configuration database.

What’s the GUID? Use the following procedure to identify the Shared Services GUID:

  1. Login to the SQL server.
  2. Open SQL Management Studio and expend Databases.
  3. Expand Configuration Database & Tables.
  4. Open table for dbo.object.
  5. Execute the following query in query analyzer: SELECT * FROM [SharePoint_Config].[dbo].[Objects]where name like ‘%SharedServices%’ The results should look like this:

    A2B1EC50-7134-40D1-9D97-0D54E129AE70   1AAB936C-E65C-4829-9683-5CCF5BAB90B0   3ACD71A5-B35A-44F1-B524-F90FFEA1AACE   SharedServices1_Search_DB

    7BB6D64A-E954-4E55-B7CE-15F9AA071748   FB6E9959-5209-44FB-83A4-0A51C31F7A02   3ACD71A5-B35A-44F1-B524-F90FFEA1AACE   SharedServices2_DB

    A9013685-0830-43A9-925A-7875A10DDA82   9D95E78B-FA6F-4349-AD9A-43BD3EF44E99   43DAD086-2C32-4ECF-B545-9FC63D80698B   SharedServices2

  6. Copy the ID of object referenced in objects table of configuration database.
  7. Open command prompt and changed directory to C:Program FilesCommon FilesMicrosoft Sharedweb server extensions12BIN> and executed following command to delete the Shared Services using the ID which was copied: Stsadm -o deleteconfigurationobject -id “id retrieved from object table”

SharePoint Disaster Recovery: A moment

Disk space is cheap. We all hear and see it but plenty of you out there seem to ignore this fact. Yes, there can be a cost associated with maintaining the extra volumes in your data plan, but does there rally have to be?

Let’s face it, the average hard disk has a stated MTBF that is just ridiculous. Oft misinterpreted, and more generally misunderstood the numbers range upward of 50+ years. They are sourced roughly with the following logic. If a drive has a MTBF rating for 300,000 hours and the service life is 5 years a group of these drives should provide 300,000 hours of service before one fails. Needless to say, the unknown unknowns can interfere… The key point here is that they as a standalone device are supposed to be, and typically are, rock solid and reliable. Paired with a drive of equal properties from a different manufacturer, or if the same, from a different production batch, your odds of failure are even more reduced. Right now an external 1TB drive with USB or Firewire will run you less than $150. Buy two and you’re still under $300. Total costs for electricity ~$50 a year? That’s cheap.

Now why don’t people just hook one of these to a server, networked would be a bonuus, and add it in as an additional backup location? Some do, but they are the exception, not the norm. More than once, though sometimes it took some “cajoling”, clients of mine have seen the merits of extra, cheap, storage that STSADM can dump data securely onto and be retrieved quickly and easily. I’m a firm believer in the more baskets you have, the fewer broken eggs you have.

Needless to say you can secure these drives with something like this…

WSS3.0: HowTo use STSADM.EXE

  • STSADM is the cmd line tool for SP Central Administration
  • PSCONFIG is the cmd line tool for SP Configuration Wizard

Each STSADM command line is using a shortcut to the program (shortcut to PSCONFIG, too):

@SET STSADM="%ProgramFiles%common filesmicrosoft sharedweb server extensions12binstsadm"
@SET PSCONFIG="%ProgramFiles%common filesmicrosoft sharedweb server extensions12binpsconfig"

HowTo rename a server (in a VPC):

  • Rename the server in Windows from the “My Computer” icon – Properties – Computer Name
  • Rename the server in WSS:
@SET oldServerName=youroldsrvname
@SET newServerName=yournewsrvname
@SET usr=sp-mosssetup
@SET psw=moss!
%STSADM% -o renameserver -oldservername %oldServerName% -newservername %newServerName%
%STSADM% -o updatefarmcredentials -userlogin %newServerName%%usr% -password %psw%

Response renameserver:

The server contains the configuration database. To complete this operation, you must rerun this command on all machines that are joined to the farm. A restart may also be required.
Operation completed successfully.
You may also need to update any alternate access mappings referring to .

Response updatefarmcredentials :

To ensure that all credential caches in IIS have updated, you must run the command “IISRESET /NOFORCE” on all servers in the farm. This should be done after all credential updates have been completed.
Operation completed successfully.

How solution deployment has changed development with SharePoint technologies


Anyone who is familiar with development & deployment of custom solutions on SharePoint Portal Server 2003 or Windows SharePoint Services will probably agree when I say there are certain areas lacking in the end to end process.

For example, here is a high level generic step by step process that usually happens:

  1. Spec written (some people seem to think this step is optional)
  2. Developer develops code etc… Usually on a stand-alone, single server SharePoint environment. (I personally use a VPC for all development these days)
  3. Developer packages code into an installer if you are lucky
  4. Testing
  5. Hand off to production people who go and install it on the server(s).

This would normally be really easy right? Well, in SharePoint land there are many areas where “things” need to be done during an installation. Some of these are (but not limited to):

  • Assembly deployment. GAC or BIN
  • Web.config changes. Additions to the safe controls list, CAS security policies,
  • Resource files like images,
  • Dwp files
  • Site definitions (list definitions etc…)

Depending on how your development team packaged these would depend on how much work you had to do to deploy them.

To make matters worse, depending on your physical SharePoint farm you might need to do install steps on each server. This brought in complexity around what servers had what versions at what time etc… A nightmare if you were managing a large farm with many servers.

How we make this better in MOSS and WSSv3:

In MOSS we have a good solution to all of this called the Solution Framework. Here is a little summary about what this is:

“The Windows SharePoint Services (WSS) solution framework provides a way to bundle together all of the components for extending SharePoint in a new file called a solution file (a CAB-based format with a WSP extension). A solution is a deployable, reusable package that can contain a set of features and site definitions, templates, Web Parts, and assemblies that you can apply to a site, and individually enable or disable.” – WSS SDK

Not only this but the Solution Framework takes care of deploying the solution to ALL front end web servers in the farm without the admin having to go to each box to do this manually!

You can:

  • Deploy the Solution package to the farm
  • Retract the Solutions package
  • When a new web server is added, automatically deploy the solution to it
  • Deploy new versions of the Solution

Practical example:

In the system I talked about in “Application Development on MOSS & WSSv3” we are using a Solution package to deploy:

  • A custom Site Definition
  • 6 Feature Definitions (another new MOSS technology) that are:
    • Custom Workflows x2
    • Timer Job
    • Content Type
    • Custom List definition
    • Custom Site Columns definition
  • Web part
    • SafeControls list entry

Note: I won’t talk about Features or how to create them; Todd has a good post on that subject here:

[Updated] This means when we want to deploy this solution to a new farm we simply use the STSADM -addsolution -filename to upload the solution to the farm. Once uploaded you can simply to into the “Solution management” section under the “Operations” tab in the Central Administration Site, and deploy that solution.

Once it is uploaded we can then choose to Deploy that solution.

This gives you options on when you want the deployment to take place and to what web applications. (In the shot above I had an assembly being deployed to the GAC, hence the warning)

Although all this will be/is documented in the WSS SDK, I thought I quickly go over how to make a solution file.

Consists of:

  • A CAB file containing
    • A Manifest.xml file
    • All the files for the Features etc… that make up your solution

Below is a cut down sample XML manifest.xml file for the example I used above (highlighted text is comments):

< ?xml version="1.0" encoding="utf-8" ?>
< xmlns="" solutionid="{79d1a62e-3627-11db-963e-00e08161165f}" resetwebserver="TRUE">

< deploymenttarget="GlobalAssemblyCache" location="Foo.Sharepoint.WebpartsFoo.SharePoint.WebParts.dll">
< assembly="Foo.Sharepoint.Webparts, Version=, Culture=Neutral, PublicKeyToken=63cce650e8605f5d" namespace="Foo.Sharepoint.Webparts" typename="*">
< /SafeControls>
< /Assembly>
< deploymenttarget="GlobalAssemblyCache" location="Foo.Sharepoint.Timer/Foo.Sharepoint.Timer.dll">
< /Assemblies>


< location="Foo.Sharepoint.TimerFeature.xml">

< location="Foo.CustomTypeFeature.xml">

< location="Foo.FooLibraryFeature.xml">

< location="Foo.ColumnsFeature.xml">

< location="Foo.Workflow.ProcessFooFeature.xml">

< location="Foo.Workflow.ProvisionFooFeature.xml">

< /FeatureManifests>

< location="FOO">
< location="1033XMLWEBTEMPFoo.XML">
< /SiteDefinitionManifest>
< /SiteDefinitionManifests>
< /Solution>

Then you package this up along with all your Feature files into a CAB file with a “.wsp” extension. In short each feature goes into a sub-dir in the CAB that matches the path you have in the Manifest.xml file. You can use cabmake.exe to do this, or any other tool you like.

Then you are ready to go and deploy!

Although this is probably a little more work to begin with, your deployment team will thank you for it immensely.

When did you last check your backups?

I am oft called “paranoid”, which I prefer to think of more as “highly aware”, when it comes to backups. The more baskets you have, the better your chances when you need to catch something. STSADM export function is your friend. Use it, test it, and do so frequently (I do it with virtual environments.) Because when the fan starts going chunka-chunka you do not want to be left wondering anything more than how many hours downtime are coming. Case in point, about not testing your backups not SharePoint / STSADM, Journal space literally evaporated this week…

Journalspace is no more.
DriveSavers called today to inform me that the data was unrecoverable.
Here is what happened: the server which held the journalspace data had two large drives in a RAID configuration. As data is written (such as saving an item to the database), it’s automatically copied to both drives, as a backup mechanism.
The value of such a setup is that if one drive fails, the server keeps running, using the remaining drive. Since the remaining drive has a copy of the data on the other drive, the data is intact. The administrator simply replaces the drive that’s gone bad, and the server is back to operating with two redundant drives.
But that’s not what happened here. There was no hardware failure. Both drives are operating fine; DriveSavers had no problem in making images of the drives. The data was simply gone. Overwritten.
The data server had only one purpose: maintaining the journalspace database. There were no other web sites or processes running on the server, and it would be impossible for a software bug in journalspace to overwrite the drives, sector by sector.
The list of potential causes for this disaster is a short one. It includes a catastrophic failure by the operating system (OS X Server, in case you’re interested), or a deliberate effort. A disgruntled member of the Lagomorphics team sabotaged some key servers several months ago after he was caught stealing from the company; as awful as the thought is, we can’t rule out the possibility of additional sabotage.
But, clearly, we failed to take the steps to prevent this from happening. And for that we are very sorry.
So, after nearly six years, journalspace is no more.
If you haven’t yet, visit
Dorrie’s Fun Forum; it’s operated by a long-time journalspace member. If you’re continuing your blog elsewhere, you can post the URL there so people can keep up with you.
We’re considering releasing the journalspace source code to the open source community. We may also sell the journalspace domain and trademarks. Follow us on twitter at for news.”