I think our Production SharePoint 2010 system might be haunted. Here's the deal. I noted that a certain text field in record centre site were not being indexed correctly after metadata had been updated. It appeared the old value was still indexed for the text field.

I noted the problem only occurred for msg files - other types of documents were all fine. After doing some research I noted here on SharePoint StackExchange that ParserEnabled might need to be set to $true (ours was set to $false). After setting it to $true. I made some manual test changes to a single msg for the field in question and lo and behold it appeared to work once a incremental crawl was run.

After a getting a hug of approval from a colleague every thing went pear shaped from there just as I was preparing my pitch for a well earned raise. All of a sudden all the msgs in the folder started going berserk and changing metadata.

Each time I refreshed I could see more and more msgs being changed. The strange part was that I had not touched those msgs. Even more strange it was putting the wrong managed metadata in the wrong managed metadata fields. I quickly made ParserEnabled $false again and the process stopped. I'm wondering if anyone has seen this behaviour before.

I always thought from reading about property promotion that the promotion would only occur when you saved/uploaded an item - not items that hadn't been touched. If I hadn't stopped it probably would have corrupted the metadata of every single msg in the site. The weird part is where was it getting the metadata from. I download one of the MSGs and looked at its properties and could only see valid metadata not the rubbish that SharePoint started putting in.

Can anyone shed some light on what has happened here. I'm way too scared to try setting ParserEnabled back to $true but as things stand the indexing isn't right so I'm in a bit of a bind.

1 Answer 1


I have subsequently learnt there is a reason why Microsoft has ParserEnabled set to false in Record Centre sites by default.

The issue with the rogue behavior described above is the result of the Taxonomy Update timer job doing its jobs and attempting to sync with the taxonomy hidden list. The problem was setting the parserEnabled to True compounded the problem because there appears to be no consistency with term IDs in the hidden list in different sites.

Hence it was throwing up the wrong values in wrong metadata fields. What a mess!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.