I have started a MS Support call on this issue but i thought i would post it to the forum at the same time to see if anyone else has experienced a similar issue (and i will update with the results of the support call):

the symptoms of this issue are:

I have existing columns in multiple site collections are of type "managed metadata".

if you open up a document (in office 2010 or office 2013) of content type A which contains one of these columns, and try to update the column value in the document information panel, the following occurs,

it looks like the value has changed, you save the document.

when you open up sharepoint from the web browser and look at the properties of the document, the values do not change.  If you reopen the document from office, the value it shows in the document information panel is the changed value (which does not get propagated to sharepoint).

If i go to a completely different machine open up a document that i have changed the value in office, when i open up the document in office it will show the changed value however if i look at it in the sharepoint GUI it will show the original value...

Running a fiddler trace is see some errors like this

POST http://hub/lrc/landuse/sub/_vti_bin/cellstorage.svc/CellStorageService
400 Bad Request ()

POST http://hub/lrc/landuse/sub/_vti_bin/workflow.asmx
500 Internal Server Error (text/xml)

in the sharepoint logs i do get some errors like

Unable to open Lookup list '{7afe42cd-b22a-49d2-82fd-f57e5e6f74be}'.[Error was 0x81020026]

with the support engineer yesterday we noted that if we made a new column using the same termset as the old column everything worked perfectly, it was only for existing columns that we have this problem.

for the record here are the CU's that i ran after which i got into this bad state...

Feb 2012

Apr 2012

Aug2012

Oct 2012

these all ran successfully. Now i know that MS says that CU are well cumulative. But we did some testing and found that they were not indeed so that is why we ran each one to be sure we had all of the updates (we were a little behind). My bad i actually missed running the jun 2012 CU.

just an update to this issue.. had a call with the support tech and we discovered something more about this case.  If you look at the metadata column that is not updating, by going into word, advanced properties, on the custom tab, it shows that an additional column has been created.  The original column was called "Sub Document Category".  The new column is called "Subx0020Documentx0020Category".  When office saves the metadata it saves the metadata to the column "SUB_x0020..." , while the sharepoint GUI saves it to the column "Sub Document Category".  Not sure which CU broke this functionality, the support person is trying to replicate it...

further update, the support tech has replicated the problem on the latest february CU.  NOTE this only happens when you create a document from the new menu (throught the sharepont interface), for uploading documents it doesn't happen.  So others must be having this problem maybe they don't even know it because there is no error, the metadata just doesn't get saved for columns with spaces in them.. so this is impacting new or existing columms with spaces in their name... tried renaming the columns to remove the spaces but that didn't help, i think its based on their internal name... 

further update... this is a known issue apparently in 2010 & 2013.  No timeline on when this is going to be fixed and no workaround from support..! yikes

Just in case others find this thread, we hit something very similar.

It's worth noting that we did get the issue when we uploaded a document.

Our fix was to add and then remove a managed metadata column from all libraries in all our sites. I've chucked up a blog post with details on the fix here: http://alexbrassington.com/2013/04/29/managed-metadata-columns-fail-to-sync-between-sharepoint-and-client-applications/

yes i had to create a new column with no space in its name... and then i used a tool called sharegate to copy metadata from one column to another and i had to do this many times, it was ugly!... but maybe your fix is easier... i tried to go to your blog post but couldn't get to it, maybe your blog is down right now ?

update - i got to your blog site, i'll have to try your fix next time t

I have just realised we have exactly the same issue in our environment where a column was originally created with a space and pointing to a term set. I have tried renaming the column, testing different CU,s and Alex Brassignton fix has not worked for us. Kdude have you had any more feedback from MS on this issue? As the only resolution I can see here is what you mentioned about creating a new column with no space.

We work together for a year and you still don't bother spelling my name right ;)

I've got some scripts around here that should be useful for moving the metadata over to a new column if needed. Drop me a line if you want a copy.

Was it only a year?  it seemed a lot longer :)

Yes please, send them over and I will give them a try - do you remember my work address :)

i ended up creating the same column with no spaces in the name and then i used a tool (sharegate) to copy metadata from one column to another... i had to use the tool because i didn't want to change the last modified date or modified by of the documents (if i did it manually or with a script this might happen, maybe if you have a sophisticated enough script you can work around)

only yesterday i got a callback from my support engineer saying that it has NOT been fixed int the latest CU.  (i called her when i heard there was a new CU out)..  Appparently this is a problem in 2010 and 2013..!

You can use the .SystemUpdate() method to force the change through without modifying the 'modified' and 'modified by' values. Really handy.

My first take on the scripts pulled all the metadata out of the column into csv, removed the columns, published the content types, re-added the columns, re-published the content types and re-added the metadata. They were both beautiful and terrible and took 20 hours to run on a UAT environment.

I should be able to hack the export/import scripts to merely move the value over pretty quickly. Assuming someone hasn't already done that...

• Edited by Alex BrassingtonMicrosoft community contributor Friday, May 24, 2013 4:14 PM typo
• Proposed as answer by Ed Price - MSFTMicrosoft employee, Moderator Saturday, May 25, 2013 12:14 AM
• Unproposed as answer by Steven AndrewsEditor Monday, June 24, 2013 2:28 PM

Hi guys.....guess what?  I have just discovered that we have the identical issue!!! :-(

Question to kdube... Thanks for starting this thread but I would be grateful if can you post your MS case reference number.  I am going to log a call with MS for this same issue and if I can quote your reference number then it will give me a head start.  I figure the more people that log calls for this issue, then the quicker it will be fixed...hopefully.

case id is 113022110235123  still i have no update on this bug.....!

Sadly MS wouldn't provide me with any further details on when the hotfix will be made available.

In summary they said....

"This issue that you are currently facing has already been reported as BUG and after discussion with the backend team, they informed me that as of now there is no ETA on when this issue will be addressed but they informed me that its in the pipeline.".

Hello All

Just a note on this.  We ran into this bug starting back in December.  We have opened a case with MS and are pushing them for a fix.  However, based on their awful response so far, we are looking at Plan B.  I loved the blog posting above showing how to add the column but I have would appreciate if anyone has a script to copy the existing columns over.  We have hundreds of libraries with thousands and thousands of  documents that are all tagged with the wrong column ("Doc Type").  I need a script to automate the copy the values to the right column ("DocType").  Alex B would you be willing to share?  

Thx in advance

Dave

I followed the link to the blog:

http://alexbrassington.com/2013/04/29/managed-metadata-columns-fail-to-sync-between-sharepoint-and-client-applications/

And it has a Powershell script.  Looks very straigt forward.  If it works, you just need to add a loop arround it that reads in the list name from a text file and runs it for each one. 

Just in case others find this thread, we hit something very similar.

It's worth noting that we did get the issue when we uploaded a document.

Our fix was to add and then remove a managed metadata column from all libraries in all our sites. I've chucked up a blog post with details on the fix here [removed from quote since BrianMeek is a noob around here]

Hello folks,

Just adding my experience on this issue - I'm working as a consultant for a large company setting up an DITA-based "component content management" solution on a large pre-existing SharePoint 2010 farm.  At my direction, the IT department created a new Web Application for the team I'm working with and installed a commercial SharePoint solution package. My level of access is capped at site collection admin.

Anyway, a document library was created for storing "topics", modular chunks of content in either DITA XML format, or .docx files created in Microsoft Word.  For the latter, I created a few custom content types with corresponding Word templates and customized the DIP to include a few managed metadata fields. 

When users populated the managed metadata fields from the DIP, the values would not appear in the corresponding Site Columns.  I searched for a while before finding this thread, and tried Alex Brassington's "fix": I created a new Managed Metadata Site Column called "BogusMMColumn" while adding it to the Topic document library.  I went a step further and created a new document in the library with values applied to the BogusMMColumn.  I then accessed the library site columns and deleted BogusMMColumn. 

My next test of creating a new document (from the "New Document" menu of the document ribbon) and setting managed metadata values via the Document Information Panel was successful!  I was also successful in opening an existing document in Word, modifying a managed metadata value through the DIP, and seeing the update appear in the corresponding SharePoint Site Column.  Woo hoo!

It's nice when inexplicable glitches like this can be fixed in early testing :-).  I suspect the problem exists elsewhere on the farm, but my isolated Web Application is working as it should now.  Thanks Alex!

I tried Alex's fix but it didn't work for me. Maybe because we have published columns and content types from a "root" site. I have all the CUs up to December 2014 applied.

So, disappointingly, that's about 11 CUs since the problem was first reported and still no fix. What surprises me is that this is the kind of functionality (properly working integration between Office and SP with managed metadata) that corporates want, but MS seem to be focussing in on adding in cuddly social networking features instead. :-\

Thanks all for this discussion thread. This issue is still with us. I noted it's alive and well in SharePoint Online just last week :(