The Story

Today was an interesting day, I was getting my morning coffee with dock and video cables in hand as I was about to help a colleague with a video issue when my developer walked in.

I could tell something was up when he walked in as he had a bit of a “catch his breathe” feel in his persona as he went about asking me how my morning was going. Sensing the tension in the conversation I ask him what’s going on. Then he gets right to the point, and it’s SharePoint related. Having had my gooooood amount of SharePoint experience doing majority of the SharePoint site migrations to 2016, however this time the issue revolved around the old 2010 site and server that was setup and configured before my time there.

Long story short, I took the correlation ID and searched the good old UNLS logs (C:\Program Files\Common Files\Microsoft Shared\Web Server Extentsions\14\LOGS). Nothing really stood out, a couple access denied due to a secure store permission for a web part, which I knew about due to the account I was using to test, and saw this webpart error out before hitting the error page on a web part edit (a different webpart that was actually working fine and failing on edit). There are other blog posts on dealing with access denied on the secure store front so I’ll leave those out of this as they were not of value to me. Continuing through the log till the very last match on the correlation ID brought up a exception halt with the line reading “Invalid field name.” along with a bunch of inner system method calls down a usual stacktrace. The stack strace wasn’t really of much relevance so I did the best thing I could, google the UNLS issue about the invalid field name, and sure enough I stumble upon a technet blog post by a Brendan Griffen.

Now you can go ahead and read more on his issue and store there, and he seems to really be hooked about “FormURN” but my case didn’t really have anything to do with that, and he does cover more the details as to the fact that certain tables that are used for content types somehow missing certain fields (ahem columns), as we all know you don’t mess with the DB directly when dealing with SharePoint. Now I don’t even get into the nitty gritty of the commands he used to verify the missing fields (thinking about that now it could have made for a more interesting blog post….. oh well) since he covers the solution to recover the missing fields with two SharePoint powershell commands, and well running those two fields in my test environment (since I was quickly able to duplicate the issue in my test) it sure beat doing that then digging endlessly through DB’s for columns I’m not sure I’m even missing, and for logs this was the last line in it so it was this or nothing…

The solution

Command 1:

Disable-SPFeature –identity "Fields" -URL RootWebURL

You will be asked if you are sure, select yes.

Command 2:

Enable-SPFeature –identity "Fields" -URL RootWebURL

that was it, just like magic (didn’t require a reboot or even a iisreset) my dev was able to edit the web part, and I was on my way to help a user with their monitor.

I’m going to soon have some SharePoint posts about orphaned items stay tuned! As well as some awesome scripts to clean up old 3rd party plugins!