Sharegate to the Rescue – Getting Rid of Weird Taxonomy (Managed Metadata) Columns

3 minute read

Yet another entry for the “Things that make you go ‘Huh?’ in SharePoint” file.

We’ve got a Document Library in SharePoint Online (Office 365) that contains Document Sets. As per usual, each Document Set can contain several different Content Types, as we’ve defined. It’s nothing out of the ordinary, really. We’re using SharePoint capabilities the way they are intended, and it’s all “out of the box”.

One day last week, we started to see odd things when we looked at the documents using the list forms. Fields we didn’t create were showing up in between those we did. For example, we saw Sector_0 above the field Sector, ServiceArea_0 above Service Area, and a new field called Taxonomy Catch All Column. Obviously something was amiss. None of those red boxed fields should be there.

Weird Taxonomy (Managed Metadata) Columns

Turning to them InterWebz, I found a number of posts about this happening in SharePoint 2010 when the content was moved around using the Content and Structure UI. That was a long time ago, plus we were pretty sure we hadn’t used the Content and Structure page for anything. Even if we had, this was weird.

It turns out the fields are part of the [poorly built – please give it some love, Microsoft] Managed Metadata infrastructure. The fields are supposed to be there when you are using Managed Metadata columns, but you should never see them. The solution back in the SharePoint 2010 days was to use Powershell to hide the fields again.

Ok, so we didn’t know why or how this had happened, but Powershell seemed like a good bet to fix it. I headed on over to Gary Lapointe’s (@glapointe) most excellent SharePoint Online Custom Cmdlets, installed them (I don’t so a lot of Powershell – but perhaps I should do more), and adapted the old 2010-era Powershell examples from the forums for SharePoint Online. Here’s the important part:

Basically, connect to SPO, find the list, and then loop through the fields which should be hidden and hide them again.

But that wasn’t getting me there. When I looked at the weird fields, I saw they were already hidden. Here’s the info about the ServiceArea_0 field, which I got by looking at $fieldname in the foreach loop. As you can see, Hidden is already set to True. Yet the field was showing up in the forms nonetheless.

So Powershell wasn’t going to solve it for us. What else could I try?

Well, Sharegate is definitely my Swiss Army Knife for SharePoint. (Yes, CEWPs and DVWPs are also Swiss Army Knives for me – I like great tools.) I use it just about daily for many things, most of which have nothing to do with migration. I looked in the main Sharegate app, wondering if there were some other settings for the fields I could look at. Great functionality from Sharegate, but I couldn’t find anything.

Then I wondered if simply copying the content into a new library might fix things. I set up a new Document Library named – aptly – Temp, and copied over one Document Set. Yay – everything looked fine!

Then I copied all of the other content from Proposals over to Temp, deleted Proposals, and then copied the Temp library to Proposals again, so I’d have the same URL.

Suffice it to say, all is well in Proposal land now. When I look at any of the documents, I see what we’d expect, which is certainly prettier and more useful.

Whew - Back to Normal!

Sharegate: it’s not just a migration tool.


This is blog post 1000 for me! I considered making some big deal or some special post out of it, but I decided I should just keep chugging along posting stuff that might help people. It’s just a number and today is just another day. If you want to, go out and celebrate for me.

Image from




  1. AFAIK, you could have changed the url from “Temp” to “Proposals” without doing a second Sharegate copy operation, by going into SharePoint Designer, navigating to All Files, right clicking on the Temp library and renaming it. I figure you already knew that, but since you were already in Sharegate, it was just as quick to just start another copy operation and let it run, yes?

  2. It’s great how many little things you can find out when working with SharePoint… Would have been interesting what the CanToggleHidden value of the fields was. If it is set to false you can’t just change the hidden state like you tried and it might have influenced the visibility in some quirky way… Good thing you found a workaround.

    Congrats on the 1000!


Have a thought or opinion?