I'm currently working on migrating a big company's data from DropBox to SharePoint and i can't quite decide on how to structure the whole SharePoint environment.
So as you may know DropBox has an admin section where you add your members, groups and content to share and it is pretty straightforward on how to implement simple things and by that, i mean that you get your members on some groups and then you share specific folders (from your content) to that group directly.
As of SharePoint now, i found out that it has more or less the same functionality but it really gets pretty inconvenient on how to implement this. I created a new site, then i created my groups and added some users to them, then i created as many document libraries as my shared folders were on DropBox, i stopped inheritance from the site and added groups directly to the document libraries. All that, took me quite a while, more than 8 hours, for 30 document libraries and 20 groups mostly due to the back and forth i had to go through settings, permissions, libraries etc.
Would it be, let's say, more practical or rather make more sense to create a new site for every shared folder i have on DropBox and add members directly from the site's homepage?
What would you do for such a case?
Thanks in advance
PS. The migration tool that SharePoint admin center provides it comes pretty handy and it works good, but transfers data quite slowly.
TLDR: Use sites, not libraries, for different user groups.
SharePoint makes the following things easy:
Sharing a whole site (by inviting people as members (edit) or visiors (read))
Sharing a single file (with a person that you don't want to have access to the other stuff on the site)
SharePoint makes the following very hard:
sharing specific libraries with distinct groups of people. This requires a lot of setup work and is a maintenance nightmare. You also need to be an administrator of the each site and know where in the depth of the SharePoint settings you can find the switch to break permissions and invite other people to a library.
It is not recommended practice to share libraries like that.
In your scenario, you would be served better with individual team sites using O365 groups. Then add members via the home page sharing button. The site should be the permission boundaries and these permissions should not be broken for any site content.
If the need arises to break permissions for certain content, it's time to move that content to a separate site with its own membership groups.
Using O365 groups, any site membership can then be viewed, managed and audited in the SharePoint admin portal and the M365 admin portal. No SharePoint knowledge or SharPoint site access is required for admins to manage membership. Membership assignment can also be automated with various tools like PowerShell or Power Automate.
Users can see only the sites they have access to, and will not suffer the bad user experience of clicking a library, only to get an error message for "You do not have access".
Related
I'm trying to setup an Azure project page. An issue that I am running into is that the users I have do not have access to do a lot of the maintanence related items on the Sprint Boards and they also do not have the ability to add/edit in the Wiki pages. Some examples of things that users need on the sprint board are: adding new tags, and deleting work items. I've tried granting access levels to all users both individually and under their team, but that doesn't seem to work.
I've even went as far as adding a user to the Project Admin group (which should give them full access) and they still cannot even add/edit a Wiki page or do any of the maintenance on the sprint board. I'm the owner of the project and have all of this access. What settings/permissions do I need to do to get this to work?
If users having the Contributors role in Azure DevOps Projects, then they can edit the wiki pages by default.
This Contributors group/role will provide write and read access to the repositories, pipelines, work tracking, etc.
Check the restrictions to the users and groups by going to this path and modify according to your requirement:
Refer to the Azure DevOps Wiki Permissions Official Doc and this AzureDevOps-Permissions&AccessLevelManagement for more information.
We are using Harmom.ie for Outlook to save e-mails and documents in SharePoint sites. Recently we started to use the Planner and Groups and we want to use Harmon.ie to save documents and emails into group sites. In Harmon.ie there is an option to enable groups sites. We have done that. When doing this an Office 365 Global admin must give consent. We also done that. However when a user try to access they are not allowed to access. According to the documentation something need to be set up on Azure giving the add proper Graph access.
The question is. How do we do this??? has anyone else got this to work? When we access the app on Azure there is not much we can do?
We are stock! any help will be much appreciated.
There are different ways to solve this. Harmon.ie also allows you to connect to teams & groups - and I suppose this is what you tried to do. We also did this. It was a little bit complex - but after some communication with the harmon.ie support, we got it working.
However, I am proposing a different way to solve your problem. Why? Currently, the problem with this teams and groups connection is, that you are not getting all the functionality of normal site connection (if you connect a SharePoint site to: https://www.harmon.ie). You are only going to see the documents library of your office group - and nothing else. But as an office group just uses a normal SharePoint Site, you could also have other libraries created.
What you can do is, get
1. get the site url (every office group has a SharePoint-Site behind)
2. and book it into harmon.ie manually
You will than have access to the document libraries.
for this solution, you do not need any additional configuration of teams and groups access.
I'm developing a document management based on the crm sharepoint integrations at the moment. It is realy a nice way to take advantage of the sharepoint document capabilities inside crm 2011.
BUT!:
I see a huge drawback with this attempt, because the sharepoint security model differs from the crm security model. This way, even if a user has no acces to a account entity, for example, it is possible for him to go to the sharepoint site and look at the documents of this entity, because he got permissions on the list for his own account entities.
Why the heck there is no thread about this big security problem? Is there maybe a simple solution to get around this problem?
I hope someone is able to help me.
Best regards,
Gerrit
There exists a commercial out-of-the-box solution solving this problem from Connection Software company (http://connecting-software.com/index.php/en/solutions/products/cb-dynamics-crm-privileges-to-sharepoint-permissions-replicator).
Basically they deploy tiny plugin into CRM that collects all the event that can possibly require change of permissions. There is a extra service that is processing these events and writes folder-level permissions into SharePoint accordingly.
Eugh. Sharepoint.
In my opinion there is no easy way around this and there are other problems with the way it integrates.
I was on a project where we discussed options around this very issue but was moved on before we came to a conclusion.
My suggestion was to use the Sharepoint Security APIs to assign permissions on SP based on roles/events in CRM. All users start with no permissions in SP.
e.g.
User is assigned as owner in CRM - use plugin to call SP API to give permissions to that specific folder. Previous owner has permissions removed.
Opportunity is created. Use SP security API to give permissions to owner of Opportunity to the folder associated with the opportunity.
And etc etc and so on.
It isn't too pretty and depending on requirements could become particular pain to maintain and test, but I didn't see many other options.
But there are plenty of problems with SP integration I think I was lucky that I was moved on to another project!
Here's the scenareio:
I have a single site collection, with the publishing infrastucture feature activated. Seveal levels below this I have a publishing site with the publishing features turned on. I also have unique permissions for this site.
The problem is that no one except site collection administrators can "Create Page". I have given the individuals everything including full control, and they still can not create pages. They can edit pages, but not create.
Am I doing something wrong? What is the proper way to set up the taxonomy of a site? I am trying to create a hierarcy to match my organization and mostly am using unique permissions on each site/subsite. This is working ok, until i needed a publishing site, but I don't want him to be a site collection admin. I would appreciate any help or ideas with how to make the publishing site work as I have it, or guide me on the proper way to lay out the site.
The fact that you are using Publishing features shouldn't have an effect on permissions. Publishing (for the most part) really has more of an effect on how edits are handled - i.e. immediately deployed or checked in and published at a later point. That's oversimplifying it - but back to your question.
Most likely - what is happening is that you have not given the user permission to the library where the template is that they need access to in order to create the page. I'm 99% sure that is what is happening here. Makes sense - they have the rights to the site - and permissions to edit the pages that exist - but creating a page requires them to access a new file - in a different library. If they don't have permissions to that template library - you get the access denied error.
When your user tries to create a page, they get an access denied error page correct? Copy the URL of that page, and examine it closely. It should reveal the location of the template folder they are trying to access but don't have permissions for. Read-only access to that template library should get your user the access they need.
One other recommendation - check out the access checker web part in Codeplex. http://accesschecker.codeplex.com/. This web part is loaded as a solution and allows you to display a hierarchical list of the sites that a specific user has permissions to. VERY helpful in confirming that you have given the permissions you thought you had.
Finally - in terms of permissions best practices - I think you are doing fine. You've gotten a little frustrated because you took a different path on a site (i.e. publishing) and it's behaving differently. But nothing is wrong. I've been there:) You really have two options w/ SP permissions - SP based groups (visitors, members, owners etc) or pulling in AD groups. Either way, you'll be making the same decision regarding unique or inherited permissions. You either use the same permissions as the parent site - or use unique permissions. HTH
In Moss 2007 you have the ability to set the target audience for each individual web part within a page. Is there a way to preview how the page will look to another user without logging in as that user? What I am looking for is a way for someone with full control/design permissions on a site to be able to preview how the site will be displayed to another user. Any suggestions?
I have a few test accounts that our IS department uses to preview pages, however we do not allow non-IS departamental staff to use those accounts. Those staff members only have access to their one account. So, if a user makes changes the target audience on a web part on one of their pages, right now they have no way to preview how the page will look to someone else other than asking someone else to login & watching over their shoulder. I can't give out the account information for the test accounts, nor can I create new test accounts.
Thanks!
Edit: I have the ability to preview. The problem is that other users with full control of a site can't preview the page. Here's a scenarios: In my school division each school has a site. The principal has full control of his school's site. On the landing page, he wants all the school announcements to be visible. However, some should only be visible to teaching staff, while others need to be visible to the students. He uses audience targetting but cannot preview to see at a glance that the targetting is correct. A lot of the users are not computer savy so things need to be as simple as possible. Also, that was just one scenario, there are other scenarios that are not divided by school. There are many users with full control of a site with different requirements - so it's not feasible to create test accounts for all scenarios.
First I don't think it is possible to have a preview feature if you are using NT security. Maybe it is something you can do with forms authentication but I never used it.
On that subject. I think when you are developing new features or integrating stuff on a MOSS/WSS server you need a little flexibility.
With what I see you have to following things you can do. It is surely more cost effective than developing a custom solution. I assume you are using NT Security.
User accounts : Ask your domain administrator to have dedicated user accounts to play with.
Virtual Machines : Ask to have some virual machines to be able to play with that server combined with tests accounts
Sandboxed environment : Ask your IT dept to create a sandboxed MOSS environment to have to possibility to replicate your actual MOSS environment and create custom user scenarios.
Edit: After re-reading the question I released that you want the users to be able to preview a page. I think you will need to look into writing a preview control that uses Impersonation to load the page. Not sure how feasible this is, but surely someone has created a preview feature. Sounds like a pretty common scenario to me.
Old Answer:
Could you not fire up a non MS browser such as Firefox, which will prompt for the username and password.
You can then just clear the session cookies to be prompted to log in as someone else.
This is the technique I used for an ASP.Net site that used authentication against the domain in a similar manner to SharePoint.
Alternatively, you can create a control/webpart that hooks into the audiences for the site and displays the audience membership to the user (maybe from the GetMembership call). This does not preview the site, but it will give your editors a heads up on who is in each audience. Something that will help them get the audiences correct.
We have made a similar webpart for security group membership.
I think there are two approaches you can take:
Do make use of test accounts to preview the pages. You can ease the "pain" to log in as another user by making use of the RUNAS command (http://technet.microsoft.com/en-us/library/bb490994.aspx). So it's possible to just create a shortcut on the desktop that opens a browser making use of another account's credentials. Only that browser instance will work with the test account.
Make a copy (or more copies) of the page that you want to preview, store it in a secured site (so it's only accessible for the principal for example), and tweak the Audience Targetting properties of the web parts on that page/pages.
For previewing target audiences only, the only way to do it is to create a target audience that runs based on a properties in the SSP User Profile Properties.
You can then have a control that allows the editor to change the value stored thier profile, re-compile the profiles and voila (for some description of voila) the user will have change thier audience targetting values to something else.
This would need quite a bit of coding and some thought put into the rules for the audience targetting.
At the end of the day, the most cost effective way is to push back to your infrastructure guys for an account solution that will allow you to have an "reader" account people can use for this function.