How to Remove Corrupted SharePoint Sites – Preparing for SharePoint 2010 Upgrade

From SharePoint Joel


SP2 had a number of enhancements designed around making it easier to upgrade to SharePoint 2010.  One such new feature that wasn’t popularized is your ability to find and remove corrupted, broken sites known as orphans.

As I’ve mentioned in the past, with SharePoint being split across multiple databases, it is quite possible that a site could be in either the content database OR the config database.

With service pack 2 there’s a new way to find orphaned sites.  In addition to running STSADM –o PreUpgradeCheck, one of my favorite tools along with TEST-SPContentDatabase with SharePoint 2010 you can identify these messed up corrupted sites.

You’ll run enumallwebs (STSADM reference on TechNet) to identify the orphaned sites, and use deletesite (STSADM reference on TechNet) to remove them.  Note this command is available in SP2, and was enhanced in the post SP2 October Cumulative update.  You really should consider that October update as the most significant release with upgrades since SP2, but also extremely relevant in getting ready for upgrade to SharePoint 2010.

Identifying Site Collections and Sites

Both Identify the sites missing from the Site Map and identify the GUID so it can be deleted.

STSADM –o EnumAllWebs


stsadm -o enumallwebs

-databasename <database name>

[-databaseserver <database server name>]

With STSADM –o EnumAllWebs you can get a list of all of the sites.  It may not seem very readable, but throw it into Excel or your favorite text editor or XML editor and clean it up.  Once you’ve got it in the editor you’re going to look at the data where InSiteMap=”False”.  Essentially what you’re looking at is a problem.  If it’s not in the site map then it doesn’t think it really fully exists.

Delete Corrupted Sites

Syntax from TechNet

For deleting a live site collection:

stsadm -o deletesite

-url <URL name>

[-deleteadaccounts {True | False}]


For deleting a orphaned site collection:



-siteid <site ID> (ID is listed in an output from EnumAllWebs)

-databasename <database name>

-databaseserver <database server name>

Delete Corrupted Webs

Syntax from TechNet

For deleting a live site within a site collection:

stsadm -o deleteweb

-url <URL name>

For deleting a site within an orphaned site collection or an orphaned site within a site collection:


-webid <Web ID> (ID Comes from EnumAllWebs)

-databasename <database name>

-databaseserver <database server name>

The real useful feature is the new –force parameter.  Essentially now you have the ability to add the –force when adding the URL of one of these orphaned sites.  Before you’d simply get an error if you were trying to delete one of these sites.  If you plan to use the –force parameter with your EnumAllWebs command you will need to provide the GUID which is the site id or web id.  By simply looking at the XML output you can tell wether you need to run web or site command.

<Sites Count="2">
  <Site Id="e2a23r5h-83c9-43t6-8wcf-3fesasefdsd234" OwnerLogin="Domain\username" InSiteMap="False">
    <Webs Count="1">
      <Web Id="0ae3237b-b349-4693-bd67-dsefcsabb36" Url="/sites/site_name" LanguageId="1033" TemplateName="STS#3" TemplateId="1" />
  <Site Id="fsdf32c4b8-79d9-32f6-87bf-4acreadcr3623" OwnerLogin="Domain\username" InSiteMap="True">
    <Webs Count="1">
      <Web Id="234c8e7b-c456-4693-bd67-efdegd3bf466" Url="/" LanguageId="1033" TemplateName="STS#0" TemplateId="1" />

If you find the results from enumallwebs too overwhelming you can trim down what you’re looking at to a specific database.  You can pass in the –database parameter and provide a specific database.  For example: stsadm -o enumallwebs -databasename sharepoint_content_db


Here’s the KB that refers to the old ways of cleaning up orphaned sites

Repair content databases in Windows SharePoint Services

If anyone ever tells you to simply disconnect and reconnect your databases, you need to be very serious about what that means.  It sounds very simple, and in simple environments that might be ok.  In other environments you’ll find there’s a lot of layers of configuration around databases and by simply disconnecting and reconnecting you’ll lose the association with alerts and other services, essentially much of the configuration in the SSP that relates to those sites loses it’s way.

If you’re seeing a lot of corruption you should refer to this post on how SharePoint site corruption is created to see if you can follow better practices to avoid creating corruption.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s