Spike on SharePoint

Getting SharePoint in Sync: Matching Versions and Permission Controls

Here's how to determine which SharePoint version is right for individual machines and how to make sure they play nicely with different versions.

• By Spike Xavier
• 01/27/2014

One of my clients was debating whether to go with SharePoint 2010 or SharePoint 2013. There were many factors to consider. Some of their staff had some previous experience with SharePoint 2010, and all of them were skilled with Office 2010.

I am a big fan of using matching versions of Microsoft products whenever I can, so I felt compelled to encourage them to go with SharePoint 2010, but did some research first. Here's how I like to synch up my products. For my SharePoint 2010 farms, on the servers I like to use:

• SQL Server 2008 R2
• Windows Server 2008 R2
• SharePoint 2010

And on the clients, I use:

• Office 2010
• InfoPath 2010
• SharePoint Designer 2010
• Windows 7

With SharePoint 2013 farms, on the servers I like to use:

• SQL Server 2012
• Windows Server 2012
• SharePoint 2013

And then on the clients I use:

• Office 2013
• InfoPath 2013
• SharePoint Designer 2013
• Windows 7 or Windows 8

The best way to determine the optimal option for this client was to set up a test environment with both versions to compare and contrast. I set up two different farms in my development environment and created the same Web Applications on both. Then I created my first test site collection and began to create a classroom management sitecollection in each farm to see the differences between the two versions in this particular situation.

During this process, I noticed the SharePoint group members who got the "contribute permission" level in SharePoint 2010 had been assigned the "edit permission" level. It wasn't obvious that this change happened. I went back and created another new site collection to ensure I hadn't missed something and lo and behold same thing.

Since I used central administration the first two times, I created a new site collection using the team site template for the third time. This time I used the SharePoint 2013 management shell.

When you create new site collections using the management shell, you have to run the CreateDefaultAssociatedGroups method on the top-level site to create the out of the box groups and permission levels. I did all that and sure enough got the same result. To be honest, it took me a minute to process what I was seeing. I now make it a habit to check new books on SharePoint 2013 and I've noticed that some of them didn't notice this fairly significant change either.

Here's a look at the out-of-the-box security groups and their permission levels when I created a new site collection using a team site as the top level site template (see Figure 1). I set the name of the site collection to "ClassroomDemo."

As you can see, the ClassDemo members were created and the default contribute permission level was assigned. When I did the same thing in SharePoint 2013 using the team site as the template for the top level site of a new site collection, the same SharePoint Security Groups were created. They now call the viewers "Excel Services Viewers." SharePoint 2013 has assigned the edit permission level to the ClassroomDemo members group (see Figure 2).

My first thought was, what the heck is the edit permission level? Did they change the contribute permission level name to edit? So I took a look at the permission levels between the two versions of SharePoint to see if I could find the answer.

When I look at the SharePoint 2010 permission levels there is no edit (see Figure 3). I was at this point expecting to look at the SharePoint 2013 permission levels and find no contribute, but instead edit, but I was wrong. Let's take a look at the SharePoint 2013 permission levels (see Figure 4).

Edit is a new permission level and contribute is still there. This was cause for a pause. I immediately sought to find the differences between edit and contribute. The best way I could figure to do this was to look at the individual micro-permission settings for each permission level side by side (see Figure 5). I opened two instances of Internet Explorer, one looking at the edit permission level and one looking at the contribute permission level to find the difference.

I opened the edit permission level page of the contribute permission level by right clicking the link and choosing open in new window from the context menu (context menu not shown). I went ahead and just clicked the edit link to open the edit permission level page for the edit permission level.

I put the browser windows side by side and compared the permission levels. I noticed only one difference -- the contribute permission level had the manage lists permission unchecked and the edit permission level had it checked.

When that is checked, it means the user can do whatever that particular permission says, so if someone is operating with the edit permission level they can manage lists. If they are operating with the contribute permission level, they can't manage lists.

The descriptions pretty much say it all. The edit permission lets you add, edit and delete lists; and view, add, update and delete list items and documents. The contribute permission lets you view, add, update, and delete list items and documents (see Figure 6).

So in SharePoint 2013 the members group has the edit permission level and they can now add, edit and delete lists as well as list items. That is not a minor difference.

I am a big fan of not changing the out-of-the-box permission levels or SharePoint group permission level assignments. Otherwise I would probably just assign the contribute Permission level to the member groups so it worked like before.

Instead I will opt to create a custom SharePoint group called "Contributing Members" and assign the contribute permission level to it. Actually I will approach it deployment by deployment, but it is something you want to make sure you don't miss.