I stumbled across an interesting difference between the Enterprise and Professional level plans of Office 365 recently. If you subscribe to a Microsoft Office for professionals and small businesses plan (Plan P) then any non-admin user added to SharePoint online automatically has Enhanced Contributor permission in all your sites. But if you subscribe to one of the midsize businesses and enterprises plans (E plans) then adding users gives them no rights in SharePoint online. You must add the users to SharePoint online sites just like you would add users to an on-premise SharePoint site. Since most administrators only have access to one Office 365 plan this difference often goes un-noticed.
But the more important question is how do you change the default behavior in the professional level plan. Its actually quite simple once you know what to look for. In your Office 365 admin page there is a link to change permissions on your Team sites and documents (see screenshot below)
Clicking on that link will take you to the Site permissions page for you default Team Site.
NOTE: Another difference between the two levels is that in the professional version you only get one Team site collection and one public website. In Enterprise you can create multiple internal site collections but you are still limited to one public website.
On the site permissions page you will see a Domain Group named Tenant_Users (see screenshot below). This is the group that contains ALL the users you create in Office 365. You can see that the group is given the Enhanced Contribute permission level. So every user that you create and assign a license to is automatically given permission to log on to your SharePoint online site. This is very convenient, but causes a problem if you want most of your users to be limited to Read Only access to the site.
But once you recognize that this default group exists the solution is fairly simple.
- Select the checkbox next to the group
- Click the Edit User Permissions button in the ribbon.
- In the dialog that appears clear the check box next to Enhanced Contribute and select the check box next to either Read or View Only depending on how limited you want the average user’s permissions to be. (see screenshot below)
- Click OK
User’s will now default to either Read Only or View Only access to the site. If you want to give them more permissions than that you’ll need to add them to an appropriate group or assign them rights individually.
I’m sure there are other differences between the different plan levels that aren’t well documented. This is just the first one I ran into.
Next week I’ll be headed for Denver to speak at the Denver SharePoint Saturday event. I will be presenting two sessions. One will be an overview for users, admins, and developers who are just getting started on SharePoint online in Office 365. The other is a more in depth talk for developers and admins on managing the various places that SharePoint stores user information. I’ve reprinted the abstracts for my talks below:
Intro to Developing for SharePoint Online: What Tools Can I Use? – The introduction of Office 365 drastically changed the SharePoint development landscape. As a managed online service the rules for developing customizations for SharePoint Office 365 are radically different from the ones for an “on-premise” installation. They are also slightly different than developing sandbox solutions. In addition many companies who currently use dedicated SharePoint installations are beginning to consider eventual migration to the Office 365 cloud environment. That means even current “on-premise” development is often constrained in new ways. No matter what kind of development you currently do you need to know how to develop for Office 365. In this workshop/session we’ll cover the following topics:
- Setting up an Office 365 development environment
- Developing sandbox solutions for SharePoint Online
- Building reusable workflows in SharePoint Designer 2010
- Why the Client Object Model is even more important in Office 365
Users, Profiles, and MySites: Managing a Changing SharePoint User population – Every company has some level of employee change and turnover. The question is how do you manage the graceful removal or modification of user information from SharePoint? If everything is perfectly aligned SharePoint will automatically process and delete the user account, permissions, profile, and MySite for users that are deleted from Active Directory. Updates to user information are also automatic in many cases. But most SharePoint installations don’t have all the necessary components aligned for automated removal of old users and some profile properties refuse to update. In this session we will examine the underlying processes controlling user accounts, permissions, profiles and MySites and how they interact. We’ll look at what works, what doesn’t work, and how to work around it. Along the way we’ll recommend Best Practices for managing users, their profiles, and MySites in a SharePoint environment.
I’ve done programming in a variety of environments over the years. Case sensitivity was one of the things that was the most difficult for me to get used to when I moved from VB to C# a number of years ago. In fact if it weren’t for Intellisense I would probably still be swearing at C# on a regular basis. I’ve learned to live with, and even make use of, case sensitivity in my C# programs over the years. But it doesn’t come naturally. I still tend to think in a case insensitive fashion.
As a result I was somewhat surprised to run into someone having an issue recently when trying to add SharePoint Managed Metadata terms to a user profile programmatically. They reported that SharePoint wasn’t consistent when adding terms to the Ask me About profile field programmatically. It turns out that the real problem was that they had duplicate fields where the only difference was the case of the first character of the abbreviation. After some investigation here’s what I discovered.
- SharePoint won’t let you add two metadata terms under the same parent if the only thing that differs is the case sensitivity of the term. The image below shows what happens if you try to add “ABC” as a term when “Abc” already exists under the same parent term.
- You can add (but probably shouldn’t) a term that differs only based on case sensitivity if you also change the hierarchy that the term inherits from. The image below shows the same “ABC” term added to a different parent. This time the addition is successful.
- When you try to add any combination that starts with abc to a managed metadata column you get both terms. You can of course choose the one you actually want, but that’s based on the hierarchy of the term, not its case sensitivity.
The lesson here is that unlike some things like C#, the Managed Metadata service is NOT case sensitive. You should try to avoid adding terms to the service that differ only based on case sensitivity. This is particularly true if you intend to add managed metadata to fields programmatically.
Please join Dave Milner and me for the webinar entitled Best Practices for SharePoint 2010 Upgrade & Configuration, where we will outline various critical considerations and best practice strategies for the planning and conducting an upgrade from SharePoint 2007 to SharePoint 2010.
The webinar will include live demonstrations and discussion of the following points:
- Who should upgrade, why & when
- How to assess existing SharePoint deployments and identify upgrade risks and opportunities
- Specific tasks that need to be done to prepare for SharePoint 2010
- How to identify and upgrade existing 2007 customizations
- Best Practices for supporting parallel environments, migration & preserving the investment in your existing SharePoint deployment
- Avoiding Upgrade & Migration Pitfalls
If you are considering upgrading to SharePoint 2010 from a previous version, you will gain an understanding of how to effectively upgrade SharePoint 2010 in accordance with best practices and gain insights into approaches, techniques, and tools that mitigate the effort and risk associated with upgrades.
Sign-Up for the Seminar here:
The SharePoint product team released Service Pack 1 for SharePoint 2010 yesterday, along with service packs for a lot of related Office products. In the past its been a good idea to patch SharePoint and your client applications at the same time to maintain the highest level of integration between SharePoint and the desktop. I would recommend continuing to follow that procedure.
But this SP1 is more than just a bug fix. It includes some new features and functionality for SharePoint, including:
- A Site Recycle Bin – Recover accidentally deleted SharePoint Sites and Site Collections.
- Shallow Copy – The ability to move site collections containing Remote Blob Storage (RBS) elements from one content database to another without having to physically move the RBS Blobs.
- StorMan.aspx – The return of a Storage Allocation page where you can see how much storage is being used by major portions of your farm.
You can find links to the all the Office related service packs, including SharePoint here:
You can find a shorter list of just the service packs related to SharePoint here:
Make sure you remember to apply SP1 for all the products you have installed!