How To Bulk Publish in SharePoint (without using Site Content and Structure)

Photo by Bank Phrom on Unsplash

Back in June 2018, Microsoft announced that they were removing SharePoint Online's Site Content and Structure page in October 2018.  This had some useful features in it, some of which are being replaced, some of which are not.  

One of Site Content and Structure's popular features is the ability to bulk publish all of the documents in a library to a major version.  This is particularly useful if you only allow people with edit rights to see minor versions, and you want to publish a large number of documents at the same time, for example on the launch date of something.

How can this be done once Site Content and Structure is no longer available?

Let's go through the steps.

1. Create a view that filters items based on "Version contains .1" OR Version contains .2 OR [all the way up to] "Version contains .9":
   
2. Open the list, select this view and click Return to classic experience.
3. Select all of the items in the list, open the Files tab and click Check Out.
4. Select all of the items in the list, open the Files tab and click Check in.
5. In the Check in panel that opens, select the Major version (publish) radio button and click OK

Once you've created this view you can use it whenever it's needed.  

You might think it would be easier to just create a view that says "Version does not contain .0", and you'd be right.  Unfortunately, SharePoint views don't support "does not contain", so you have to create this filter the long way round, so to speak.   If this is a common requirement for your users you can add this view to the libraries in your site template so you don't have to keep reproducing it by hand every time whenever you create a new site.

Some Word Articles for Those Hot Sunny Evenings

Thanks to the World Cup (turned out it wasn't coming home, but it was brilliant nonetheless) and a summer heatwave, my output on AgileDocumentation from June through to August hasn't been high.  But I've still been writing, just not here.  

The fine folks over at How-To-Geek asked me to write some articles on Office 365 for them and I'm only too happy to oblige.  They've got a much bigger readership than this little old blog and long time readers will know I like to spread the O365 love, especially about Word.  I've got a few SharePoint articles planned for the coming weeks, but in the meantime here's some articles from How-To-Geek to keep your whistles whetted:

• How to Control Line and Paragraph Spacing in Microsoft Word
• How to Wrap Text Around Pictures and Other Illustrations in Microsoft Word
• How to Position Images and Other Objects in Microsoft Word
• How to Reduce the Size of a Microsoft Word Document

SharePoint Permissions Part 5 - External Sharing

Photo by bruce mars on Unsplash

In part 1 we looked at how permissions inherit and cascade, and using SharePoint groups to avoid inheritance problems. In part 2 we covered using mail-enabled security groups in O365 to make your permissions more consistent. Part 3 focused on reducing your maintenance burden by using dynamic security group membership, and part 4 was all about the creation of a permissions strategy and accompanying design guide.

This has all been very internal user-focused.  What if you want to allow external users to access your site?  Or, perhaps more importantly, what if you want to make sure that only some things (or even nothing) can be shared with external users?  It's time to talk about external access.

External access is controlled at 2 levels: the tenant, and the site collection. 

Unlike site permissions, which cascade down and can be changed to be less or more restrictive at each of the site collection, site, library/list, folder and document levels, external sharing cannot be made less restrictive at the site collection level.  So your site collections cannot allow more external sharing rights than the tenant allows.  On the other hand, you can make your site collections more restrictive than the tenant, so if external access is allowed at the tenant level, you can prevent it at the site collection level if you want. (For reasons which will become obvious quite soon, this is probably the setup you'll want to use.)  But these are the only 2 levels at which you can change the external access settings - all of the sites, libraries/lists, folders and documents under a site collection will get their external permission settings from the site collection.

Let's start with preventing any external access to your SharePoint instance, because this is the easy part.  

To do this, you just need to turn off external access in the tenant settings by going to O365 Admin > SharePoint > Sharing and selecting the Don't allow sharing outside your organisation radio button.

If you do this then no-one will be able to share a document from a SharePoint site, nor will adding an external user to a site give them access (because when you add a user to a site, even as an administrator, you are actually sharing the site with them).  But there is a big caveat:

Turning off external sharing at the tenant level stops users sharing externally from OneDrive as well.

Now, that might be fine for you, in which case congratulations, you're done here, don't bother reading the rest of this article.

But if you want your users to be able to share externally from OneDrive, or need to allow one or more teams to share externally from SharePoint, then this won't work for you.  If you're wondering why this affects OneDrive, it's because OneDrive is a series of SharePoint sites, one for each of your users.  If you go to O365 Admin > OneDrive > Sharing, you'll see a note under External sharing that says "Your sharing settings for OneDrive can't be more permissive than your setting for SharePoint".  Hence, if you turn off external sharing for SharePoint, you're also turning it off for OneDrive.

In a scenario where even a single user needs to be able to share externally from OneDrive or SharePoint, you'll need to turn external sharing on at the tenant level.  Your options are as follows:

The options are described in detail by Microsoft here, where you'll also find an explanation of the other parameters that limit which external users can be shared with, and what those external users can do with their shared files.

One section of the parameters not covered by that Microsoft page is the sharing by security groups section:

This is known more formally - and unintuitively - as "per-group sharing".  It allows you to chose which security groups are allowed to share externally (the second option will only appear if you've chosen to allow users to share anonymous links) and you can find out more about it from Microsoft here.  Note that it also affects OneDrive, so it gives you a little more control there too.

But whatever parameters you've set, once you've allowed external sharing at the tenant level you now need to set up your site collections appropriately as well.

First things first, lets look at how you allow or not allow external sharing in a site collection.  Go to O365 Admin > SharePoint > and the SharePoint admin portal will open in the Site Collections option.  Select the site using the checkbox next to it on the left hand side and click Sharing from the toolbar at the top:

If you don't want your site collection to allow external sharing, select the Don't allow sharing outside your organization radio button, click Save, and you're done: 

If your permissions strategy doesn't generally allow external sharing, set this in your template site and it will be copied through to any sites that use that template.  

If you do want to allow external sharing the full explanation of what each of these options will and will not allow can be found on this Microsoft page.  The first thing to note is that the Sharing outside your company options are missing some options that are in the tenant level options.  At the tenant level you could decide if anonymous links expire, and if so after how long, and also whether anonymous links allow anonymous users to view or edit.  You can't change this at the site collection level.  These are tenant-wide settings that every site collection will inherit.  

You can then choose the Default link type and Default link permission, both of which by default will inherit from the default organisation setting, but can be changed.

You've then got the ability to whitelist, or blacklist, domains which people can share with:

You can either whitelist certain domains (users can only share externally with users who have an email address in a whitelisted domain) or blacklist certain domains (users can share with any external users except those with an email address in a blacklisted domain).  You can't do both at the site collection level, although you can have a blacklist at tenant level and a whitelist at the site collection level.

The blacklisting is a rather odd option, in that a user from a blacklisted domain could simply create a free email address from a service that isn't blacklisted, and use that. So there would be no point blacklisting a competitor service when a user who really wanted to share with a competitor could just tell the competitor to create a new email address from a common service like gmail or outlook.com.  This is especially true when the blacklist must be filled in by hand, rather than syncing automatically with, for example, the untrusted site list used by a security program.  The use case for blacklisting therefore seems a bit lacking at the moment.

The whitelisting make perfect sense, however.  One site collection can only share with your external regulator, for example, while another site collection can only share with your parent company, and so on.  This gives the administrators a way to allow sharing with trusted organisations without worrying about people sharing things with whomever they want.

These lists can also be setup at the tenant level as part of the additional settings I mentioned.  If you've set this up at the tenant level, then this Microsoft page details the priorities, which I'll list here for ease:

• In the case of conflicts, the tenant-level configuration takes precedence over the site collection configuration.
• If a tenant-level allow list is configured, then you can only configure an allow list at the site collection level. The site collection allow list must be a subset of the tenant allow list.
  
• If a tenant-level deny list is configured, then you can configure either an allow list or a deny list at the site collection level.
  
• For individual OneDrive for Business site collections, you can only configure this setting by using the Set-SPOSiteWindows PowerShell cmdlet.

Note that the logic outlined above means that if a domain is blacklisted at the tenant level, this will overrule that same domain being whitelisted at the site collection level. You can list up to 1000 domains at the tenant level, but only 60 at the site collection level.  

Following on from this, you've also go the option to prevent users from sharing with external users without owner approval:

You'll have to decide if you want to change the default from allowing users to share freely, to requiring site owner approval to share.  This applies to ALL sites in the site collection and ALL sharing, whether it's internal or external.  If your permissions strategy has the administrators as site owners, this will create a lot of work, and you'd need to consider giving an information owner enhanced rights to handle this workload.

Once you've set the permissions for your site collection appropriate, click Save.

If you want to know what's being shared externally (which can often be a good way to tell if your permissions are correct) you can search for content that's been shared externally in the Security & Compliance Centre.

And that's the mechanics of external sharing.  Hopefully this series on SharePoint Permissions has been useful for you.  If there's a permissions issue you want to me to cover, drop a comment below and I'll do my best to oblige.

[Update: I was planning to write a 6th installment on SharePoint and AIP (Azure Information Protection) but there's a lot of new work going on there at the moment.  Luckily the World Cup was on, so I could spend a month watching that, but we're still waiting for some new SharePoint-related AIP functions, so I'll come back to this topic another time.]

SharePoint Permissions Part 4 - Creating a Permissions Strategy and Design Guide

Photo by rawpixel on Unsplash

In part 1 we looked at how permissions inherit and cascade, and using SharePoint groups to avoid inheritance problems. In part 2 we covered using mail-enabled security groups in O365 to make your permissions more consistent. In part 3 we looked at reducing your maintenance burden by using dynamic security group membership.

These 3 articles covered the technical side of setting up permissions that don't break the permission inheritance rules, adding a user to a single security group so they automatically get permissions to many sites at once, and how to add users to security groups automatically by setting up dynamic group membership in AAD.

This is the how of setting up permissions, but it's also important to understand the why of setting up permissions. If you don't understand why you're setting your permissions up the way you are, you'll just be providing permissions on an ad hoc basis without any structure. This will store up problems for the future because your permissions scheme won't be consistent, and the rationale for any given permissions can only be explained by the person who set them up. Why is Joe Bloggs in this security group when he's not a member of that department? Why does Jane Bloggs have Edit rights to this library when everyone else has Contribute rights? What's this security group used for? Why does every site have different permission levels to all the other sites? These kind of questions should not come up - and if they do come up, they should be easy to answer - if you have a permissions strategy.

As always when creating a strategy, the first question to ask is "What do we want to achieve?" Are you looking for minimal admin burden? The removal of data silos? Highly restrictive permissions to protect sensitive information? The chances are you want all of these things, but in different areas. So your strategy should lay down some general principles that guide you towards the most important goal for a particular site, but also ensure a consistent, structured approach to permissions.

Some useful principles:

• Only restrict a site if necessary.  Most of your sites can be open, that is, everyone in your organisation has read access to the site.  You might have a library restricted to a particular team, but otherwise the site is readable (and importantly, searchable) to the whole organisation.  This helps breakdown data silos and reduces the admin burden.  A few sites will be closed, that is, only those people who need access will be given it, and this is done where there is sensitive data.
• The higher the permission level, the less people should have it.  This means the group with the highest permission level - Full Control - should also be the group with the fewest members.  Normally this is your System Admin group, commonly the people responsible for maintaining the structure and security of your SharePoint instance.  Conversely, the group with Read access will be the group with the largest membership (normally the built-in "Everyone except external users" group).
• Minimal complexity for maximum performance.  The more unique permissions you have in a library, the lower the performance.  This is not such a big deal for small libraries, but in larger libraries where each individual document could have unique permissions provided by users sharing things, it can cause a drop off in performance.  There's a good discussion of this problem here, and although the article is talking about SharePoint 2010 on-premise, the basic elements of load-balancers, web servers, databases and CPUs haven't changed significantly.  The performance can depreciate on both the indexing crawl and the site performance itself.
• Breaking inheritance is the last resort, not the first.  If you have sensitive information in several folders across different libraries and you need to restrict access to these, but the rest of your libraries and documents can be read by anyone, you'll have to break inheritance for all of those folders.  That's the easy way to "fix" the access immediately, but in the long run it's just more maintenance complication and potential access problems to troubleshoot.  When you're designing the site take these issues in mind and create a single library for sensitive information.  This will make the permissions much simpler and correspondingly easier to maintain.
• Security by design, not by accident.  Your organisation has to comply with a regulatory framework, whether that be industry- specific (e.g. Sarbanes-Oxley) country-specific (e.g. local data protection laws) or trading-bloc specific (e.g. GDPR).  A logical, well thought out permissions strategy can help prevent breaches, and, in case of a breach, also demonstrate that you incorporated sensible security measures into your design from the outset, which can help lower penalties and maintain your organisation's reputation.
• All permissions are documented. Out of all the principles, this is probably the most important.  It's certainly the most useful, because even if you have no other principles to follow then at least you've got information about what permissions have been applied and why.  In the design document for each site - you've got a design document for each site, right? - set aside a standard section explaining what SharePoint groups you've used with what permission level you've applied, which security groups are in each SharePoint group, and an explanation of any unusual or unique permissions, and any deviations from your standards.  This information will be invaluable in a whole host of different future scenarios.

A permissions strategy is part of the governance of your SharePoint implementation.  It should be written down and accessible to the whole organisation.  All administrators who are able to add or amend permissions from the library level up should be familiar with it, and no site collection or site design should be applied to a site unless it meets the requirements of the strategy.

But whilst writing it and making it accessible is important, it's not enough.  What doesn't often get talked about is the need to convert your strategy into practical actions.  It can be difficult to understand how the strategy should be applied in day-to-day work, especially for people more used to solving technical problems than creating and interpreting policy.

So the strategy document should also have an accompanying permissions design guide that translates the strategy into concrete actions and requirements.  The guide should include what default SharePoint groups are in your site template and why, under what circumstances it's acceptable to deviate from these groups, naming conventions for security groups, and so on.  

The contents of your permissions design guide will vary according to your strategy (e.g. you may prioritise accessibility over security, or vice versa) and the overarching design decisions you've made (e.g. what your naming conventions will be, what default SharePoint groups you use, etc), so just as there is no "correct" strategy, there is no "correct" design guide.  The design guide is there to provide your designers with the practical information they need to implement your strategy.  Think of it as a tactical handbook which, if followed by everyone, will allow you to realise your strategy successfully.

A design guide takes a long time to write and is a living document.  As new functionality is added to SharePoint, the design guide will change and grow.  It would be nice to say "don't build anything until your design guide is finished!" but that's unrealistic in a production environment.  Instead, start by working out your strategic principles and getting all of the stakeholders on board.  Then at least you're all working from the same starting point.  This is doubly important if you're well into a SharePoint implementation or you've got a mature implementation you want to improve (and realistically most people reading this will be in these positions).  

The further into your implementation you are, the more potential work there will be to implement a strategy and corresponding design guide on your pre-existing sites, so don't expect to make sweeping changes.  An incremental approach that gradually improves things has a better chance of success than a radical redrawing of your permissions to fit a new strategy.  Start by creating a strategy and corresponding design guide that can be used for any new sites from now on, and when it's stable and well-understood you can look to implement it in existing sites over time.

The technical work of creating and implementing the permissions strategy is part of the admin's role.  In the next article we'll take a look at user sharing, how to modify the out of the box settings (both at tenant and site level) and what you can and can't stop your users doing.

SharePoint Permissions Part 3 - Setting up Dynamic Security Group Membership

Photo by Henry Be on Unsplash

In part 1 we looked at how permissions inherit and cascade, and using SharePoint groups to avoid inheritance problems.  In part 2 we covered using mail-enabled security groups in O365 to make your permissions more consistent.  Now it's time to look at reducing your maintenance burden by using dynamic security group membership.

This sounds quite complicated, but in reality it simply means letting Azure Active Directory (AAD) handle group membership based on attributes like department or role.

If you set this up then when people join, move, or leave they will automatically be added to or removed from security groups.  If you're using security groups in SharePoint, this will lower your maintenance burden considerably.  It also allows you to set up a permissions strategy that doesn't require everyone who deals with user accounts to know the ins and outs of what permissions any given user requires. Dynamic security group membership is a "set it and forget it" system where AAD will handle putting people in whichever security groups are appropriate based on their user profile attributes.

This doesn't mean it doesn't need management, as you'll need to add the dynamic membership requirements to new groups, and change the requirements for existing groups if/when your organisation's structure changes.  But, after you've set it up for the existing groups, that's all you'll have to do in the future.

Here's how to add dynamic membership to a group.

1. Open AAD and find your security group:
   
   
   
   
   
   (If you've not done this before, open the O365 Admin portal, select Azure Active Directory in the left hand launch panel, and there is a "Find a group" option in the default dashboard view.)
   
   
   
2. Click on the group to select it.  The menu on the left hand side will display the options for that specific group. Click Properties:
   
   
   
   
   
3. The Membership type of your group will be displayed:
   
   
   
   
   
4. Change the Membership type from "Assigned" to "Dynamic User".  A confirmation dialogue will pop up; click Yes on this:
   
   WARNING: Doing this will remove existing users from your group.
   
   
   
   
   
5. Click the new Add dynamic query option that has appeared at the bottom of the Properties panel, and create your rule from the dropdowns:
   
   
   
   
   
6. Click Add query at the bottom of the panel to add the query to your group.  AAD will then populate the group membership with all users who match your query.

If you want to add more than one query (e.g. department = Sales AND Location = New York) then instead of adding the query through the dropdowns you'll need to click on the Advanced rule tab.  This provides a code window for you to enter a more complicated query.  

Microsoft have provided a thorough overview of the syntax and valid terms for advanced queries which I encourage you to work through.  It might appear intimidating initially (especially if you're not used to command line or PowerShell scripting) but it's really quite simple once you understand the logic.  Being able to write multi-part queries will significantly increase your options for dynamic membership, especially if you have situations where some, but not all, members of a team need to be in a group.

Once you've added the appropriate membership rule to a group, you've finished.  Your group now has a dynamic membership that will change automatically based on user attributes.

Between SharePoint groups, security groups, and dynamic group membership, you've got all the tools you need to make sure that the right users have the right access to the right SharePoint areas, all done automatically based on their user attributes.  However, knowing how to do this is just the technical side of permissions.  You also need to understand who should have access to what, and why.  This is the function of a permissions strategy, which we'll look at next.

SharePoint Permissions Part 2 - Using Security Groups

Photo by Alex Block on Unsplash

In Part 1 of this series we looked at user groups in SharePoint sites, and how they allow you to add member permissions without breaking inheritance. Now we're going to take this a step further and look at adding groups of users to your SharePoint groups, rather than individual members.

Firstly, why would you want to give permissions to a group of users all at once, rather than individuals?  There are a number of reasons:

1. It cuts down on your work by allowing you to add/amend permissions for multiple users at once.
2. You can provide role-based security, which means giving permissions to users based on their role, by using 1 group for each role.
3. Your permissions will be more consistent, as everyone in a group will have exactly the same permissions.
4. A group can be given permission to more than one site, which means adding a new user is as simple as adding them to a group, which then gives them permissions to multiple sites.
5. Security groups can also be used to give users access to shared mailboxes, and Yammer and O365 groups, have specific permissions for documents labelled through Azure Information Protection, and various other elements of the O365 family.

A simple example is having an Administrators group, which your SharePoint administrators are a member of.  If you add this group to the Owners group in your site template, then every time an admin creates a new site using that template, all of the administrators will be in the Owners group for the new site. (I'll cover creating and deploying a site template in a future article).

How do you practically create one of these groups?  O365 allows admins to create security groups, and these security groups can then be added to SharePoint sites as if they were users.  Security groups are created in the O365 Admin portal and contain whichever users you choose.  They can then be given permissions to a SharePoint site collection (or site, list, library, folder or document).  So if you create a security group called Administrators, you can then select this security group when adding a user to the Owners group in your SharePoint site.

When you create a security group in O365, you have an option of selecting either "security group" or "mail-enabled security group".  There is no difference between these, except that you can send email to a mail-enabled security group and it will be sent to the members, which you can't do with a security group.  I haven't yet come across a SharePoint permissions use case where this has made a functional difference, unless you want to be able to send a mail to the group when you change their permissions.  But I still recommend mail-enabled security groups, because it future-proofs your implementation in case you hit a use case where you do need to mail the group.

Make sure that when you create your mail-enabled security group you turn OFF the "Allow people outside of my organization to send email to this Mail-Enabled security group" setting.  This setting is on by default for mail-enabled security groups, distribution lists, and O365 groups, presumably because Microsoft feel the majority of use cases call for this functionality.  There are pros and cons of this for distribution lists and O365 groups, but why would you want people outside your organisation to a) know your security group names (which could be useful information for someone trying to breach your security), and b) send that security group an email? Unless you've got a good answer to these 2 questions, turn this option off.

At the time of writing the O365 Admin portal doesn't distinguish between different types of group very well.  So when you're looking in the Groups option there is no way to tell if "Administrators" is a security group, a mail-enabled security group, or just a plain old O365 group, unless you set the right filter.  This doesn't seem like a big deal, but when you spend a lot of time working with groups, and your users create lots of O365 groups for collaborating, it gets rather frustrating looking through the Groups list and not knowing what type most of them are.  There's also no way to tell what a security group is used for unless you open it and look at the description, which you and your colleagues probably aren't as fastidious about filling in as you should be (I'm not judging, I forget to do it just as often as the next admin).  

To combat this problem you should use naming conventions for your security groups.  Something like "SG-[role name]" will work fine, assuming you're doing role-based security.  You can also/instead incorporate a team name, a function name, or whatever works for you.  But do this up front, and get your admins to stick to it as much as possible.  It'll make your work a lot easier over the years, especially if you have a lot of joiners/leavers/movers, or you regularly have to create new sites.  There's also - currently - no way to tell where a security group is used unless you're willing to use PowerShell, so good naming conventions and descriptions will help you keep track of your security groups.

Now that you're using security groups to add users to SharePoint groups, the next step is to look at reducing your maintenance overhead by introducing dynamic group membership.  We'll look at this in the next article.

SharePoint Permissions Part 1 - Understanding Inheritance and Cascading

Photo by Jon Moore on Unsplash

SharePoint permissions are a common source of confusion and frustration.  This isn't because adding permissions for a new user is particularly difficult for an admin (although I'll cover one way to do that below), and nor is it because sharing a document with someone is particularly difficult for a user (although I'll cover that in a future article).  It's because it's very common to find yourself in a situation where you've given the correct permissions to a user, but they still can't see what you expect them to see.

Fear not though, because once you understand how permissions work you'll be able to fix your problems and prevent them happening in the future.  (Note: we'll be going through permissions for team sites - sites with lists and libraries - not Communications sites or the recently introduced Hub sites.  That's for a different time.)

To understand how SharePoint permissions work, you need to understand the hierarchy of objects, as well as inheritance and cascading.  

The hierarchy of objects in SharePoint is the equivalent of a family tree.  You have a node at the top (the parents), with nodes underneath (the children), nodes underneath them (the grandchildren), and so on. In SharePoint the hierarchy is:

The permissions for each of these nodes are inherited from the node above (the parent).  The Document node inherits permissions from the Folder node, which inherits from the Library node, and so on up to the Site Collection node. (If you're not using Folders then the Document node will inherit from the Library node.)

The converse of inheritance is cascading, that is, the permissions cascade down from the node above to the node below.  When you give a user permission to view a site, that permission cascades down to the library, then cascades down to the folder, then down to the individual documents.

Ok, so far so good: You create a site collection, give permission to people to view it, and they'll be able to view every site, list, library, folder and document underneath that site collection.

But that is the simplest possible option, and assumes a) that you don't need to give specific permissions to any particular object, b) that you won't give anyone else permissions to a specific object in the future and c) that no user will share a folder or document with anyone.  If any of those things happen then you'll find that the permissions aren't doing what you expected.

The reason for this is quite simple, and is at the heart of understanding SharePoint permissions: Giving unique permissions to an object breaks the inheritance.  

This means that if you, for example, give permissions to a user to see a specific library, the inheritance is broken.  So when you change the permissions in the site or the site collection, those changes won't cascade down to the library that has unique permissions.  Let's work through an example.

You create a site collection with yourself as Primary Site Collection Administrator.  Your site collection has one site, and 3 libraries called TestLib1, TestLib2, and TestLib3.  Each library has a folder called TestFolder1, TestFolder2, and TestFolder3 respectively, and each folder has a document called TestDoc1, TestDoc2 and TestDoc3 respectively.  Diagrammatically:

You give Alice and Bob edit permissions at the site level.  This cascades down to the nodes below, shown here as green nodes:

Alice and Bob have edit permissions to all of the green nodes.  If they - or you - add additional libraries, folders or documents then all 3 of you will be able to see the new objects, because the permissions will cascade down to those objects from the site.  

Now you decide to allow Charlotte to have access, but only to TestLib3.  This permission cascades down to the folder and document.  Charlotte's permissions are shown here as orange nodes:

Now Alice, Bob and Charlotte can all see TestLib3 and the folder and document underneath it, but only Alice and Bob can see TestLib1 and TestLib2.  

Now you give permission to Dave to the whole site - in other words, you want him to have the same access as Alice and Bob.  So you give him permission to see the site, and.....he can only see TestLib1 and TestLib2, and the folders and documents contained within them, shown in red below:

Why?  

Because by giving TestLib3 unique permissions - for Charlotte - you broke the inheritance, so permission changes at the site level will not cascade down to TestLib3.

Now imagine that Dave shared TestFolder1 with someone else in the organisation.  You give Ellie permission to the site, and her permissions are shown in purple:

Because Dave shared a folder (a very common action for users to perform), the inheritance for that folder is broken, and permission to it (and the document it contains) no longer cascades down.

To make matters more confusing, the inheritance that is working means that if Dave adds TestFolder1a to TestLib1, Ellie will be able to see it, because TestFolder1a will inherit permissions from its parent, TestLib1:

The situation now is that:

• Alice and Bob can see the site, all 3 TestLibs and the folders and documents contained in them.
• Charlotte can only see TestLib3 and the folder and document within it.
• Dave can only see TestLib1 and TestLib2, and the folders and documents within them.
• Ellie can see TestLib2, along with the folder and document in it, as well as TestLib1 and TestFolder1a, but not TestFolder1 and the document in it. 

Oh, and if you remove Alice's permissions by mistake, then give her those exact same permissions back....she'll have the same permissions as Ellie, because of all the breaks in inheritance.

It should be easy to see how complicated this can get.  At this stage you're already in a mess, and if you have an organisation with hundreds of users and a few sites, it's almost impossible not to get in this mess.  

However, there is a simple solution to stop this mess happening: Groups

If you give access to a group, then you can add and remove users from that group without breaking inheritance because the group always has permissions.  

To take a simple example, you might create a group that has Admin rights to the site and a group that has Edit rights to the site.  These permissions will cascade, and all lists, libraries, folders and documents will inherit those rights.  

In the example shown in the diagrams, you would be in the Admin group and Alice and Bob would be in the Edit group.  If you give Charlotte edit rights to just TestLib3, and then add Dave to the Edit group, he will now have access to all 3 libraries because he is a member of a group that already has access to them.  After Dave shares TestFolder 1, you add Ellie to the Edit group, and again she has access to all 3 libraries and all of the folders and documents in them because she is a member of a group that already has access to them.  

But if you then gave Frank edit permissions to the site as an individual, rather than adding him to the Edit group, he wouldn't be able to see TestLib3 (because you broke the inheritance when you gave Charlotte edit rights to it), nor would he be able to see TestFolder1 or the document in it (because Dave broke the inheritance when he shared TestFolder1).

So groups allow you to maintain your intended permissions no matter which user you add to them or in what order the users are added.  To add a group, go to Site Settings > Site Permissions and click Create Group in the ribbon.  However, you'll find that there are already a number of default groups there, as per this list from Microsoft, and you may find the the ones you want are already there.  You can delete any you don't need, or create any that you do.

It's common to just use the Owners, Members and Visitors groups, with Full Control, Edit and Read rights respectively.  This is something that Microsoft suggests, but it's by no means required.  Set up whatever groups you need!  If you want to know more about each of the default groups and what permissions they provide, there is a full list here, under the Default Permission Levels dropdown.

Next time we'll talk about using security groups to make your security both more robust and more manageable.

Something-As-A-Service in the Cloud

Source: Pexels

I'm going to be writing quite a bit about Azure, Office 365 and SharePoint over the next few months.  The initialisms IAAS, PAAS and SAAS will come up from time to time, so it would be helpful to explain these terms in advance:

• IAAS - Infrastructure As A Service
• PAAS - Platform As A Service
• SAAS - Software As A Service

Before we talk about the Infrastructure, Platform, and Software parts, let's talk about the as-a-service part.  What does this mean?

To understand as-a-service, you need to know what cloud computing is.  This has been a buzzword for a good few years now, and it's the backbone of as-a-service.  Wikipedia provides a good definition:

"Cloud computing is an information technology paradigm that enables ubiquitous access to shared pools of configurable system resources and higher-level services that can be rapidly provisioned with minimal management effort, often over the Internet. Cloud computing relies on sharing of resources to achieve coherence and economies of scale, similar to a public utility."

In less technical terms, cloud computing providers have huge racks of servers loaded with useful tools like databases, storage, load-balancers, web servers, and software.  They then lease space on these servers to remote users, along with access to the (usually pre-configured) tools.  This is referred to as AAS, or As A Service.  It's important to understand that cloud computing is a service provision model, not a generic term to refer to remote computers, which it's often misunderstood to mean.  Cloud computing is what's used to deliver AAS.

AAS is in contrast to "on-premise" where the servers, databases, storage, etc are all physically located within a company.  It's much cheaper to lease space on a server with access to the tools you need than it is to buy, configure and mantain all the servers and tools yourself, especially if you only need access for a short or ill-defined period of time.  Think of AAS as the digital equivalent of hiring a van - they buy the van, service it, clean it and repair it, and different people hire the van as and when they need it, then return it.  The van leasing company has the costs but makes a profit once the hiring fees have covered those costs, and you get the van you need for a relatively small outlay without any of the hassle and cost of having to actually buy a van.     

So, cloud computing providers lease space and tools as a service, but different users want different services.  Therefore there are different service models of AAS, of which the 3 standard ones are IAAS, PAAS and SAAS.  These service models are defined by the National Institute of Standards and Technology (an agency of the American Department of Commerce) in their NIST Definition of Cloud Computing (link to PDF).  This is a surprisingly readable 7-page document which is a model of economy and information, and if you're at all interested in cloud computing or AAS then I encourage you to spend a few minutes reading it.

In short, the service models explain which parts of the tech stack the vendor is responsible for, with the obvious correlation that the customer is responsible for the other parts.  Here's a diagram showing how IAAS, PAAS and SAAS divide up the responsibilities between the vendor and the customer, with On-Premise included for comparison:

Reproduced from Kevin Remde's Technet blog

With On-Premise, you manage all of the hardware and all of the software in the tech stack.

With IAAS, the vendor manages the hardware, but you choose the operating system and everything above it.  This is typically used for things like web hosting and data centres.

With PAAS, the vendor manages everything except the application and the data.  This is commonly used by software companies as a base for developing an application.

With SAAS the vendor manages everything.  A good example of this would be GMail, where every part of the tech stack is managed by Google. 

With both IAAS and PAAS the customer can choose how many resources to use as and when they need them (this is why cloud computing is often called "computing on demand").  The billing is usually dynamic and depends on the resources that have been consumed during the billing period.  It's typical to buy IAAS/PAAS capabilities and spin up additional virtual servers as required (a virtual server is a software representation of a real server), then apply a template that provides standard O/S, Middleware and Runtime.  With IAAS the customer maintains the template and with PAAS the vendor provides one or more templates to choose from.  The customer pays for every server they use.  With SAAS you're getting access to a piece of software and usually the price is determined by the number of user licences you buy.

As an example of how this works, consider the following scenario:

• Vendor A buys, configures and maintains networking, storage, servers and virtualisation to sell as IAAS.
• Web hosting company B buys IAAS from vendor A, then configures several templates for O/S, Middleware and Runtime that will appeal to different customers.  They then sell this as PAAS.
• Software development company C buys PAAS from company B, picks a template and a number of servers, then develops a piece of software on it.  
• Finally, company C sells their software as a SAAS offering to customers around the world, running on company B's PAAS, which runs on company A's IAAS.

It's not uncommon for a vendor to offer at least 2 of the 3 service models, although normally this would be IAAS/PAAS or PAAS/SAAS.  It wouldn't make a lot of sense to offer IAAS and SAAS without PAAS, because if the vendor has the capability to offer both infrastructure and software services then they've got the capability to offer a platform service.  

That covers cloud computing and as-a-service to the level that I'll be using it over the new few months.  There might be cause to look into deployment models (also covered in the NIST Definition of Cloud Computing), in which case there'll be a separate article, but that can wait until it's needed...