SharePoint Dragons

Nikander & Margriet on SharePoint

Monthly Archives: March 2013

Getting the right set of permissions when creating a custom permission level in PowerShell

Despite all its power and flexibility, developing PowerShell scripts feels like a dev experience that could be had 15 years ago. Often, we find ourselves creating prototypes in VS.NET first, before diving into the murky waters of visual PowerShell editors. Having that off our chest, suppose you’re creating a PS script that creates a new SharePoint permission level. The code is not too hard, something like:

$CustomPermissions = New-Object Microsoft.SharePoint.SPRoleDefinition
$CustomPermissions.Name = “TheName”
$CustomPermissions.Description=”A Descr”
$CustomPermissions.BasePermissions=”ViewListItems, AddListItems, EditListItems, OpenItems, ViewVersions, ManagePersonalViews, ViewFormPages, Open, ViewPages, CreateSSCSite, etc., etc.”

Now, what’s the easiest way to get to the permission mask you want? We do this:

  1. Create it first via the SharePoint UI (Site Actions > Site Settings > Site Permissions > Permission Levels).
  2. Create a C# program in Visual Studio that loops thru all permission levels until you find the one you created.
  3. Add the object holding the permission level to the QuickWatch window.
  4. Open the XML property using the XML visualizer.
  5. Copy the value of the BasePermissions attribute and use that string value in your PS script.

The C# code (run from a C# Console Application) looks like this:

using (SPSite site = new SPSite(“http://moon”))
  using (var web = site.OpenWeb())
    foreach (SPRoleDefinition roleDef in web.RoleDefinitions)


SharePoint Flavored WebLog Reader (SFWR) 1.4 is released!

We just released SFWR 1.4 at

What does it do?

“The IIS logs are an invaluable way to get to know your web application and your end users once it’s in production. Therefore, having a tool to analyze IIS logs is in invaluable asset in your bag of tricks. Especially if this tool has a certain SharePoint flavor added to it…”

What’s new?

5-2-2013 UPDATE Released SFWR V1.4

– Did some bug fixes (the slowest reports ordered by alphabet, instead of by number, duh!)

– Clarified up some reports, as there were some questions surrounding the time units in the reports. It should all be clear now.

SharePoint 2010: Problem Adding Term Sets with ‘&’ in their name

We were working on a PowerShell script that reads an XML file and uses that as the basis for adding new terms to SharePoint. Some of the term names in XML contained & which eventually gets replaced by the ampersand (&) character. Now, something strange happens, SharePoint converts this to the 65286 character (or 0xFF06 in Hex). This is an ampersand (&) character, but not the same as the normal ampersand (&) 38 character. But, PowerShell converts the ampersand (&) character to the normal 38 character, and then you’re in limbo land. What happens is this:

  1. We check if a term exists.
  2. If it’s not, we add it.
  3. We commit all changes.

Once we were committing, an error occurs stating that we were trying to add a term that already exists. Why is that happening?

  1. In PowerShell, we check for a term that contains & (= char 38). It’s not present in the SharePoint term store, there’s just the term containing & (= char 65286).
  2. We add a new term containing char 38.
  3. SharePoint converts char 38 to char 65286, but that one is already present.
  4. An error occurs.

This problem took some time to diagnose, the solution is simpler. Make sure the index name you’re using contains char 65286, instead of char 38. In PowerShell, the code looks like this:

#Please Note:
# This is a tricky piece of code, as SharePoint converts & to a special & sign (char 65286 or 0xff06 in HEX).
# Within PS, this special & sign gets converted and equals the normal & sign (char 38).
# Therefore, a normal equality test of a string in PS NEVER matches the Terms index name in SharePoint,
# because & (value 65286) is not identical to & (value 38)
# To solve this issue, & (38) needs to be replaced by & (65286)           

$IndexName = $TermNode.Name.Replace(([char] 38), ([char] 0xff06))
$Term = $Termsetitem.Terms[$IndexName]

We must have won the lottery, because by mistake we also included term names containing two consecutive spaces. SharePoint tries to help out by replacing them with a single space. Now this happens:

  1. We check for a term that contains double spaces.
  2. The term store only has a term with single spaces, so the new term is added.
  3. SharePoint converts double spaces to a single space, adds the term, but that one is already present.
  4. An error occurs.

We could do another replace, but decided that this is more of a configuration mistake. So, we’re not handling that one in code, but fixed the XML config file and then things worked like a charm.

The final question is this: is SharePoint right in replacing double consecutive spaces to a single one?  We decided the answer is no. Fixing term spelling makes the mechanism unpredictable and arbitrary (since SharePoint only seems to care about & and double spaces). Besides, it’s not SharePoint that has to decide on the name, it’s the term store administrator/end user who needs to decide. It reminds us of years ago. We were writing a technical design document and correcting the spelling of business terms that were used in a functional document written by the customer. At that time, we had a mentor who said: “Leave it be, you may not agree, but it’s the customer who decides on the business terms”. We thought this was a wise advise.

Cross-origin communication

The JavaScript window.postmessage seems to be just what we were looking for when looking for a mechanism for SharePoint Apps to talk to each other:

The Super Secret Wiki Ninja Secret

Margriet’s Wiki Ninja post called “The Super Secret Wiki Ninja Secret” can be found here: