Home > PowerShell, SharePoint 2010, SharePoint Administration > Removing a Corrupted Site Column in SharePoint 2010

Removing a Corrupted Site Column in SharePoint 2010

After migrating a Site Collections content data from our SP2007 environment to our SP2010 environment using Metalogix we ran into some problems with lists that did not allow us to open/update/edit/ or add new items.  We would receive this error: “Field type xxx is not installed properly. Go to the list settings page to delete this field.”

To determine what field is causing the error run this PowerShell script.  The PowerShell should terminate with an error, along with the name of the erroneous field.

$web = Get-SPWeb http://portal/site
$fields = $web.Fields
foreach ($field in $fields) {write-host $field.id}

This script will loop through all the field types.  You should receive an error similar to this:

For our case there was a problem with Visual Fusion and it was  a Field Type of VFSLayerParams that was corrupted.  So for our case instead of ‘Field type Bool is not installed properly’.  It read ‘Field type VFSLayerParams is not installed properly’.

There is no way (that i’ve found) to remove the corrupted column via PowerShell or through UI SharePoint Designer.

The only way to remove a corrupted column is through the unsupported Microsoft way by directly deleting the column using a TSQL query on the content database itself or by completely deleting the Site Collection and starting over.

Since directly doing any type of edits on a SharePoint content database especially on a production environment will result in a non supportive state from Microsoft the best approach is to immediately open up a case ticket with Microsoft to cover your tail.

There has already been a case opened up that touches on this issue (Case #111090871991452).  I opened up one myself just to be covered.

Once the case is opened and Microsoft is aware of you making direct modifications to the databases you can proceed, or if you simply don’t care if you lose Microsoft Premier Support then you can go ahead and edit the database without opening up a case.  It’s up to you.

Okay now onto the steps.  Before you Proceed. I’M NOT RESPONSIBLE FOR YOUR FARM, so follow at your own risk.


First you will need to determine the GUID ID for the corrupted column.  To do this you will run a PS script against the Site Collection to generate a report that lists all the fields, like so.

$web = Get-SPWeb http://portal/site
$web.AvailableFields.SchemaXml | Out-File c:\temp\fields.txt

Once done open up the fields.txt file and do a search for the corrupted column.  So for my case I searched for (VFSLayerParams).

Once you find the column name, usually to the left you will find the field type GUID.

Copy the GUID down i.e. (a7756826-0a2c-45cd-a8f0-d891f236b388).  Actually you only need the last part of the GUID (d891f236b288)

Next you need to determine the Content Database this site collection lives in.  To do this you can visit Central Administration.

Central Administration -> Application Management -> View All Site Collections

This will list the Site Collection and the database it resides in.

Now that you know the Database Name time to head over to the SQL Server.

Once on the SQL Server Open up SSMS.

1.  Open up SSMS and open up a new Query against the Content Database that has the corrupted column
2.  Next select all the corrupted columns by field id GUID by running this TSQL query

SELECT * FROM [ContentDBName].[dbo].[ContentTypes] WHERE Definition Like (%d891f236b288%)

3.  This list all the columns in the Site Collection that are corrupted with that GUID
4.  Next it’s time to delete, run the following TSQL query to delete the corrupted columns.

DELETE FROM [ContentDBName].[dbo].[ContentTypes] WHERE Definition Lilke (%d891f236b288%)

5.  Make sure the columns were deleted by re-running the Select statement, if no more records return the columns have been deleted, if more records return repeat step 4.
6.  Close out of SSMS and log off the SQL Server

Now when you try to open/update/edit/add an item to the List you should be able to with no errors.




  1. Bhanu
    April 16, 2013 at 8:11 am

    Thanks !!! This is very helpful and solved my problem…

  2. Behrouz Sedigh
    April 1, 2014 at 9:51 pm

    I think you should Fix your Script here :

    SELECT * FROM [Database Name].[dbo].[ContentTypes] WHERE Definition Like ‘%69d6ac683a32%’

    in Sharepoint 2010 , Database name was : WSS_Content

    • April 3, 2014 at 8:35 am

      Hi Behrouz, thanks but I don’t believe I need to do that. What I wrote makes perfect sense. In SharePoint 2010 you can name your content database whatever name you like so with me just using [ContentDatabase].[DBO].[ContentTypes] that makes more sense then me updating my script to use [WSS_Content].[dbo].[ContentTypes].

      In my case I don’t use the “OOTB” content database naming conventions, and i’m sure many others don’t as well.


  3. April 25, 2014 at 8:39 am

    Just FYI, manually deleting columns from SQL will render your DB unsupported. The only rollback is a restore – updates to the DB do if you don’t want support from Microsoft,

    • April 25, 2014 at 8:57 am

      Hi Sam, yes i’m very aware of this. If you read the blog I mention it in there already.

  4. June 12, 2014 at 1:32 pm

    Thanks man, valuable time saver article, this would have kept me busy for a while

  5. Don Williams
    August 21, 2014 at 8:35 pm

    God bless you sir… you saved my skin with this. Awesome stuff.

  6. October 9, 2015 at 3:30 pm

    Syntax error:

    $web = Get-SPWeb http://portal/site
    $fields = $web.Fields
    foreach ($field in $fields} < -Here {write-host $field.id}

    Should Be:

    $web = Get-SPWeb http://portal/site
    $fields = $web.Fields
    foreach ($field in $fields) {write-host $field.id}

    • October 9, 2015 at 3:33 pm

      Thanks for the catch. I fat finger a lot. I will make the modification.

  1. July 13, 2012 at 1:25 pm
  2. March 21, 2013 at 2:14 pm
  3. March 22, 2013 at 12:06 pm
  4. January 7, 2014 at 3:54 pm
  5. October 15, 2014 at 6:56 am
  6. May 17, 2016 at 2:41 pm

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s

%d bloggers like this: