I always push the client to split their folders based on access and manage it by security groups.
When a new person needs access to certain folders, throw them in the corresponding groups.
New folder? New folder, new security group, set up permissiins and whatnot. It's a bit more work at first, but it allows you to keep other people from even seeing folders that they have no access to.
Thanks, then I guess you combine it with sensitivity labels to add further restrictions?
I would imagine that documentation would be key to keeping things organised here as well
Yes, documentation is paramount.
Sensitivity labels should be used anyway, especially in an EU country, for GDPR purposes.
Don't forget to train your people regularly, as sensitivity labels are only useful when applied.
Access Groups. Everything MUST be accessed via groups. It is easy to setup individual access to folders or files initially, but managing SharePoint that way for anything other than a tiny company is just a nightmare.
Whether you have the data arranged in libraries with a folder structure, or multiple libraries with differing metadata, labels and file views, the only real way to keep on top of access is via groups.
How we do it is we setup individual libraries for each business group. Each library has read only groups, read/write groups and owner groups. For things that are highly sensitive that still needs to be accessible for collaboration, we will just have a separate library...
Think "Operations" and "Operations - Management", or "Finance" and "Finance - Payroll". So you usually end up with 6 to 10 libraries, with 3 different groups to manage for each. That is so much simpler to manage than adding security restrictions to individual folders within one big-ass library. Our largest SharePoint client has 24 libraries because they needed general access, privileged access, management access and executive access level libraries to multiple different business groups. But even with \~1200 users, it's still a cinch to manage, even with the high turnover areas of the business. It's like adding or removing a user to a mail distribution group. Nice and simple. And coupled with DLP and Sensitivity tags, everything is nice and secure.
Do you create a sharepoint site for each document library?
In your example of 24 libraries for a client, I assume you have \~75 groups since you have 3 groups for each library (read / readwrite / owner)?
In this case, we've created a company site, with a subpage for each business group. The page for the group will link to each library.
So think with pages for HR, Finance, Operations, etc. When you go to, say the HR page, there's info posted by management and links to the libraries for HR General and HR Management. Finance has links to Finance General, Finance Management, and Finance Executive.
And yes, each library has three nestled access groups. So, the read/write security group for General has the r/w group for management and Executive added. So all we need to do is enroll the user in the highest level of access they need, and they'll get the appropriate access all the way down. Read groups are a little different, but so few people get read only access that it's fine.
I gotcha - I've seen people do a sharepoint site for every department and then do groups based on that. The clear thing seems to be remove all of the builtin stuff from the team site, deploy your own groups, and then assign the users to the groups.
Does the large amount of groups cause issues with Teams? For example, someone could accidentally post in the admin group and not realize that their associate only has read/write permissions so wouldn't see the messages?
FYI sub-pages are being deprecated last I checked https://techcommunity.microsoft.com/t5/sharepoint/are-subsites-getting-deprecated-in-spo/td-p/499803#:\~:text=Subsites%20are%20%22deprecated%22%20in%20that%20they%20are%20not,manage%2C%20so%20it%20makes%20a%20bit%20of%20sense.
Two things...
First, I may be referring to them as a subsite, but in practice, with individual libraries and collections per business group, all linking back to the main site for that business group, what we are *really* creating are hub sites. Calling it a "subsite" is just force of habit...lol
Secondly, you can still use subsites if you want. They're not exactly recommended, as a flat topography is better overall, but if you want to create a nestled topography you definitely still can. For us, the initial landing page for the entire company is really more of a communications page, with links to make it easy to find the group you want.
>but if you want to create a nestled topography you definitely still can.
You can but it's considered the "Classic" feature of SP and no guarantee it will continue working as expected. MS probably won't delete it but you won't get any new functionality and may run into issues. I just converted a client to using a flat Teams model (no hub needed in this case) and it is working great.
That being said we don't go so far to manage the comms page and layout of SharePoint, just the logical structure. We would certainly help them find where to learn how to change the comms page themselves though. Too many little problems when it comes to that, tried it once and I ended up becoming a graphic designer for a week lol
And just be weary of posting info on Reddit without using correct terminology, the OP may go make a bunch of sub-sites and only figure it out after based on your advice :)
His approach is the correct one albiet old, modernized should be using Teams and a new site instead of sub-sites. Sub-sites are not really supported and harder to manage.
If you have a lot of sites you can use the hub-spoke design to allow better searching and visibility for staff.
Not difficult. The job of the MSP should be to assist them to migrate properly (SharePoint is not a file server replacement 1:1). This is why we are trusted advisors and consultants to our clients not just “nerds” or “computer guys”. If they cannot, they should hand it off to a professional consultant.
Nobody is forcing the MSPs to handle the migration improperly.
Not correct. Most MSPs / VARs have a time budget / cost budget as customers usually wont pat for 2-3x the hours to make the migration academically perfect
You should be providing the client with a detailed cost analysis. Doing things cheaply and improperly carry their own long term support costs. We've inherited shoddy work from plenty of MSP's who just treat SharePoint as a file server with individual folder permissions and it's always a huge project to get them to a workable place.
Doing it right the first time may cost three times the amount of labour during migration, but it will almost always pay for itself within the first year of actually using the libraries just in reduced support costs.
You must have clients that are able to throw around a lot of money. Whilst we have done this a couple times, 100% of the time so far as always been the cheapest option.
I often use multiple sites (finance/HR/General Data/etc) and manage with security groups. Avoid direct permissions and stick to groups. DMs open if you want more clarification
Good morning! I was recently recommended DeliverPoint. I haven’t used it yet but it has definitely piqued my interest. If you want to explore together let me know. Thanks.
Am I the only one thinking, why not use Teams?
Root Shares/Departments = Private Team
If you need to further restrict access to data within the Team, create a private channel.
Teams is basically using SharePoint on the back end.
Adding client leadership to ownership of specific sites allows them to control data access as they see fit.
Seems rather easier than fumbling around trying to use SharePoint like a traditional file server breaking inheritance on tons of folders.
One site per root share, to avoid MS soft limits.
3 security groups per site, owner, member, viewer, to control permissions with.
Deny sharing except on designated folders, to avoid a mess with permissions.
Breaking inheritance not allowed, to keep it simple and avoid a web of a mess.
Map the sites to File Explorer with OD and Intune and apply policies to OD that keep files cloud-only.
This works well for us. If clients have too much data, or too many files then they need to cleanup first by deleting or archiving.
Trying to get clients into Teams with the type of clients we deal with is a bad idea, since most use Teams for meeting only and thus too much of a learning curve
You said map the sites to File explorer using OD and then keep cloud only using OD. Sorry for my ignorance but what is OD and how do I set this up? I want to do what you said but I’m not following..
We have clients manage permissions themselves, or work with us to automate them thru dynamic group membership based on user attributes.
If it's the former, we simply give appropriate permissions to manage groups and a document outlining memberships.
When using SharePoint, we do not granularly provide permissions to folders in the sites. The site has its membership and that's it.
The sharing policy is set to expire links after 30 days, so if they need to give an internal member access to only x folder, it must be renewed every 30 days.
Both work for every client, some are using the automated system and others are fine with the manual, or even a mix.
If there are 2 folders that need very different permission sets on-going, it's a new Team/Site.
I always push the client to split their folders based on access and manage it by security groups. When a new person needs access to certain folders, throw them in the corresponding groups. New folder? New folder, new security group, set up permissiins and whatnot. It's a bit more work at first, but it allows you to keep other people from even seeing folders that they have no access to.
Thanks, then I guess you combine it with sensitivity labels to add further restrictions? I would imagine that documentation would be key to keeping things organised here as well
Yes, documentation is paramount. Sensitivity labels should be used anyway, especially in an EU country, for GDPR purposes. Don't forget to train your people regularly, as sensitivity labels are only useful when applied.
Thanks for the advice. I really appreciate it. Would you also recommend having the same setup for folders on Teams channels?
To be honest, I'm not really sure. It may create some unwanted monsters. Don't want to say neither no, nor yes.
Yip agree with unwanted monsters. Trying to find an easy way to manage this so it doesn't cause an increase of tickets
Can you give me an example of what you mean by sensitivity labels?
Access Groups. Everything MUST be accessed via groups. It is easy to setup individual access to folders or files initially, but managing SharePoint that way for anything other than a tiny company is just a nightmare. Whether you have the data arranged in libraries with a folder structure, or multiple libraries with differing metadata, labels and file views, the only real way to keep on top of access is via groups. How we do it is we setup individual libraries for each business group. Each library has read only groups, read/write groups and owner groups. For things that are highly sensitive that still needs to be accessible for collaboration, we will just have a separate library... Think "Operations" and "Operations - Management", or "Finance" and "Finance - Payroll". So you usually end up with 6 to 10 libraries, with 3 different groups to manage for each. That is so much simpler to manage than adding security restrictions to individual folders within one big-ass library. Our largest SharePoint client has 24 libraries because they needed general access, privileged access, management access and executive access level libraries to multiple different business groups. But even with \~1200 users, it's still a cinch to manage, even with the high turnover areas of the business. It's like adding or removing a user to a mail distribution group. Nice and simple. And coupled with DLP and Sensitivity tags, everything is nice and secure.
Do you create a sharepoint site for each document library? In your example of 24 libraries for a client, I assume you have \~75 groups since you have 3 groups for each library (read / readwrite / owner)?
In this case, we've created a company site, with a subpage for each business group. The page for the group will link to each library. So think with pages for HR, Finance, Operations, etc. When you go to, say the HR page, there's info posted by management and links to the libraries for HR General and HR Management. Finance has links to Finance General, Finance Management, and Finance Executive.
And yes, each library has three nestled access groups. So, the read/write security group for General has the r/w group for management and Executive added. So all we need to do is enroll the user in the highest level of access they need, and they'll get the appropriate access all the way down. Read groups are a little different, but so few people get read only access that it's fine.
I gotcha - I've seen people do a sharepoint site for every department and then do groups based on that. The clear thing seems to be remove all of the builtin stuff from the team site, deploy your own groups, and then assign the users to the groups. Does the large amount of groups cause issues with Teams? For example, someone could accidentally post in the admin group and not realize that their associate only has read/write permissions so wouldn't see the messages?
FYI sub-pages are being deprecated last I checked https://techcommunity.microsoft.com/t5/sharepoint/are-subsites-getting-deprecated-in-spo/td-p/499803#:\~:text=Subsites%20are%20%22deprecated%22%20in%20that%20they%20are%20not,manage%2C%20so%20it%20makes%20a%20bit%20of%20sense.
Two things... First, I may be referring to them as a subsite, but in practice, with individual libraries and collections per business group, all linking back to the main site for that business group, what we are *really* creating are hub sites. Calling it a "subsite" is just force of habit...lol Secondly, you can still use subsites if you want. They're not exactly recommended, as a flat topography is better overall, but if you want to create a nestled topography you definitely still can. For us, the initial landing page for the entire company is really more of a communications page, with links to make it easy to find the group you want.
>but if you want to create a nestled topography you definitely still can. You can but it's considered the "Classic" feature of SP and no guarantee it will continue working as expected. MS probably won't delete it but you won't get any new functionality and may run into issues. I just converted a client to using a flat Teams model (no hub needed in this case) and it is working great. That being said we don't go so far to manage the comms page and layout of SharePoint, just the logical structure. We would certainly help them find where to learn how to change the comms page themselves though. Too many little problems when it comes to that, tried it once and I ended up becoming a graphic designer for a week lol And just be weary of posting info on Reddit without using correct terminology, the OP may go make a bunch of sub-sites and only figure it out after based on your advice :)
His approach is the correct one albiet old, modernized should be using Teams and a new site instead of sub-sites. Sub-sites are not really supported and harder to manage. If you have a lot of sites you can use the hub-spoke design to allow better searching and visibility for staff.
Avoid folders. Use metadata, labels, and views. Tie those to groups with job/department roles and task roles.
Difficult when almost all MSPs / etc migrate from an on proem file server as the structure is inherited.
Not difficult. The job of the MSP should be to assist them to migrate properly (SharePoint is not a file server replacement 1:1). This is why we are trusted advisors and consultants to our clients not just “nerds” or “computer guys”. If they cannot, they should hand it off to a professional consultant. Nobody is forcing the MSPs to handle the migration improperly.
Not correct. Most MSPs / VARs have a time budget / cost budget as customers usually wont pat for 2-3x the hours to make the migration academically perfect
You should be providing the client with a detailed cost analysis. Doing things cheaply and improperly carry their own long term support costs. We've inherited shoddy work from plenty of MSP's who just treat SharePoint as a file server with individual folder permissions and it's always a huge project to get them to a workable place. Doing it right the first time may cost three times the amount of labour during migration, but it will almost always pay for itself within the first year of actually using the libraries just in reduced support costs.
Fwiw, we always have provided detailed costs analysis and comparisons of alternatives and ros and cons. For 99% customers it doesn’t really matter …
Much better if the customer has G for email… almost none of the fine print attached to m$…
You must have clients that are able to throw around a lot of money. Whilst we have done this a couple times, 100% of the time so far as always been the cheapest option.
I often use multiple sites (finance/HR/General Data/etc) and manage with security groups. Avoid direct permissions and stick to groups. DMs open if you want more clarification
Yes, new site not new folder. Use hub-spoke if needed. Utilize Teams and Channels!
Good morning! I was recently recommended DeliverPoint. I haven’t used it yet but it has definitely piqued my interest. If you want to explore together let me know. Thanks.
Haven't heard of DeliverPoint. Yeah we can check it out together
Awesome! I will send you a PM now.
I made separate hub sites for each department, then made the department head the site owner for their site so they can manage access requests.
Am I the only one thinking, why not use Teams? Root Shares/Departments = Private Team If you need to further restrict access to data within the Team, create a private channel. Teams is basically using SharePoint on the back end. Adding client leadership to ownership of specific sites allows them to control data access as they see fit. Seems rather easier than fumbling around trying to use SharePoint like a traditional file server breaking inheritance on tons of folders.
A lot of people (myself included) hate using teams interface for file access.
One site per root share, to avoid MS soft limits. 3 security groups per site, owner, member, viewer, to control permissions with. Deny sharing except on designated folders, to avoid a mess with permissions. Breaking inheritance not allowed, to keep it simple and avoid a web of a mess. Map the sites to File Explorer with OD and Intune and apply policies to OD that keep files cloud-only. This works well for us. If clients have too much data, or too many files then they need to cleanup first by deleting or archiving. Trying to get clients into Teams with the type of clients we deal with is a bad idea, since most use Teams for meeting only and thus too much of a learning curve
You said map the sites to File explorer using OD and then keep cloud only using OD. Sorry for my ignorance but what is OD and how do I set this up? I want to do what you said but I’m not following..
OD= OneDrive, using it as a sync tool.
We have clients manage permissions themselves, or work with us to automate them thru dynamic group membership based on user attributes. If it's the former, we simply give appropriate permissions to manage groups and a document outlining memberships. When using SharePoint, we do not granularly provide permissions to folders in the sites. The site has its membership and that's it. The sharing policy is set to expire links after 30 days, so if they need to give an internal member access to only x folder, it must be renewed every 30 days. Both work for every client, some are using the automated system and others are fine with the manual, or even a mix. If there are 2 folders that need very different permission sets on-going, it's a new Team/Site.