Archive for January, 2017

While deploying a new solution to our test environment for my client the other day I found that I was unable to add existing site columns to content types within the SharePoint site I was working in.  No real reason given.  As you can see from the screenshot below the GUI wasn’t much help:

However, as always SharePoint provided the handy-dandy correlation id.  Using that I was able to get a great deal more information on the problem.

Specifically, the problem was: “No two choices should have the same ID“.  Looking at the stack trace you can see that it looks like SharePoint is looking at the fields that exist in the site.  This makes sense because it has to build that list for you to choose from doesn’t it?  I scanned through my list of site columns and noticed that for some reason I had two columns called “Hashtags”.  I am not entirely sure what this field is for, but I believe it is added with the Newsfeed.

So the next step?  Well let’s delete the extra column.  Attempting to delete via the GUI just resulted in a window that never provided a response, nor deleted the offending field.  Next onto PowerShell.  While getting the field object I found that the two fields actually existed with the exact same GUID.  So that’s where the error message above came from.  While deleting via PowerShell I got a bit further and received the message: “Site columns which are included in content types cannot be deleted“.   I didn’t have a content type sitting there with Hashtags within it, so ran a script to go through each content type and to look for the field.

There were two hidden, system content types Project Policy and System Media Collection that contained the site column.  I did a few things to try and remove the site column from the content types, but I am not going to outline here because I don’t want to give any of you ideas (they aren’t something you want to do in a production environment and they didn’t work anyways).  Needless to say, I did everything I could think of but I could not remove the extra field from the sites.

Placed a call with Microsoft to see if they had any suggestions.  Apparently, according to the support engineer I worked with, Microsoft has seen this before.  Nowhere in the vast interwebs did I find this information.  One reason for this post is for prosperity ;-).  The fix is actually really simple.

Removing the Extra Field

Microsoft provided me with the feature definition of the Hashtags field.  The solution was to install the feature into the farm, activate the feature on the sub sites that had the Hashtags field existing within (whether they had the double instance or not) and then disabling the feature within the site.  Finally, we removed the feature from the farm as well.  I will provide that feature definition in this post, but want to make something very clear.  I did not create this, nor do I provide any warranty or take any responsibility if applying the solution causes instability in your farm.

You can download the feature here.

To apply the feature to correct your farm, follow these steps.

1. Extract the zip file and place the MMSField folder in the directory: C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\15\TEMPLATE\FEATURES.
2. Open a SharePoint PowerShell window and run the following command:

3. After the feature is added to the farm run the following script to check each sub site within your site collection to add and remove the feature (this step will force the system to remove the field and re-add it properly).

4. Remove the solution from the farm by running the following command:

Once this is complete you will have removed the extra instances of the HashTags field and can now add site columns to your content types without issues.

Thanks for reading!