I’ve been doing some work with dynamically populating a Managed Metadata term store using the API and data stored in a list.

The code was quite simple – check to see if a term existed, and if not, add it. The first pass of this routine would work fine, but then the second pass would crap out with an issue:

There is already a term with the same default label and parent term.

After a bit of debugging, I figured out it was falling over on a term that contained an & (ampersand) in the name. After a further bit of debugging (converting the character to HEX) it became apparent that it’s storing it as the wide (*pretty) rendition of the ampersand. And after some further research, it would appear that this is by design!

The name value will be normailized to trim consecutive spaces into one and replace the & character with the wide character version of the character (\uFF06). The leading and trailing spaces will be trimmed. It must be non-empty and cannot exceed 255 characters, and cannot contain any of the following characters ; “<>|&tab.

There are two approaches to resolving this, depending on your needs. For simple comparisons, you can use the TaxonomyItem.NormalizeName method to show you what your name will look like in the DB. You can also do some character replacements to convert the chars back. Check the links below for some code if you need it.

Thanks to Mike and Nick for the info.

Tripped over this issue today. This post explains exactly what’s going on – namely that when using the OfficialFile web service (for e.g., records management), the 50mb upload file size is in place, irrespective of any setting the Web Application General Settings.

Fix:

1. Make sure that you have set the max file size on the web application
   Central Admin –> Manage Web Applications –> Select the Web Application –> General Settings –> Maximum Upload Size
2. Open the following file and edit on each SharePoint server:
   C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\ISAPI\web.config
   Add the following section, then save and close

Didn’t even need to recycle the web services website/app pool. Perfect!

A while ago, I posted about an issue with deploying a custom SharePoint retention policy where activating a feature was failing due to a permissions issue.

I fell over this issue again recently, but despite following all the advice in that post, I still couldn’t get things to activate and I didn’t really want to start giving all known service accounts local admin and DBO on everything in sight. So instead, I used a quick Powershell workaround. This works because PS always runs in the context of the Farm Admin, so I assumed it must have the relevant permissions. This script will find the feature you want to activate, and then activate it. Success is no message returned!

Just ensure Get-SPFeature only returns a single feature.