In the previous article in this blog post series, I discussed the fact that even though advanced permissions options were one of the key reasons for the success of SharePoint, centralized, automated permissions management in SharePoint is virtually nonexistent. There are two ways out of this permissions management problem: writing PowerShell scripts, or using third party products that can close the gap. This blog series is about <\/em>SPDocKit<\/em><\/a>, a tool which – IMHO – closes that gap in the best possible way. This article is about automatized batch permissions management across multiple web applications and site collections in SharePoint farm.<\/em><\/p>\n

Part 1: SharePoint admin\u2019s dream: Centralized permissions management<\/a>
\nPart 2: Batch permissions management with SPDocKit<\/a>
\nPart 3: On-the-fly permissions management with SPDocKit<\/a>
\nPart 4: Permissions reporting and forensics with SPDocKit<\/a><\/p>\n

<\/p>\n

One of the most common use cases in permissions management is batch permissions management. Think about adding a new audience (users) to existing SharePoint content: it is a fairly easy task to do when you have to deal with a few site collections, but what happens when you have hundreds, or thousands of them?<\/p>\n

This was exactly the use case that we faced with a customer: over 20,000 SharePoint site collections – one site collection per customer project – were automatically provisioned. All the site collections were almost identical in their structures: the same lists and libraries, an identical predefined folder structure in the libraries, a complex permissions structure. So we are speaking about, altogether, 24 SharePoint groups per site collection, times 20,000.<\/p>\n

At one point, there was an auditing process going on, and we were required to give external auditors permissions to review the documents in certain libraries that were present in all 20,000 site collections. Auditors were not to have access to any other content in the SharePoint farm, except for those libraries.<\/p>\n

Basically, the process included:<\/p>\n

\n
• Breaking permissions inheritance for the \u201dReports” libraries,<\/li>\n
• Creating the permission level “Auditing Permissions”,<\/li>\n
• Creating a SharePoint group for auditors,<\/li>\n
• Adding users to that group, and<\/li>\n
• Giving “Auditing Permissions” to the “Auditors” group for the “Reports” library.<\/li>\n<\/ul>\n

  This had to be done for all 20,000 site collections.<\/p>\n

  Clearly, this was not a task that one could do manually, and using PowerShell meant opening the door to a possibly huge error margin. That is the reason why our tool of choice to implement these requirements was SPDocKit<\/a>.<\/p>\n

  SPDocKit<\/a> has a wizard-style interface for executing permissions-related batch operations. You can find everything there you would expect – breaking and restoring permission inheritance on multiple levels, batch creating\/editing\/deleting SharePoint groups and permissions levels, managing group membership, assigning or revoking rights for principals on different securable objects\u2026all working in an intuitive way, which does not leave much room for mistakes. Before any batch operations are executed, SPDocKit<\/a> will conveniently show a preview of the results, so that the administrator can decide whether to proceed with the operation, or cancel it.<\/p>\n

  For our use case above, we started with the \u201cPermission Inheritance Wizard\u201d, which allowed us to break permissions at all 20,000 instances of the “reports” library (one in each site collection):<\/p>\n

  <\/a><\/p>\n

  SPDocKit<\/a> permissions wizard asked us to review and confirm breaking the inheritance.<\/p>\n

  <\/a><\/p>\n

  Once that change was confirmed and applied, SPDocKit<\/a> iterated through the site collections, and actually executed the command.<\/p>\n

  In the next step, the SharePoint administrator proceeded to create the new permission level for auditors. Therefore, the next wizard – “Permission Levels Wizard” – was used. The administrator needed to choose the name for each new permission level, and its base permissions. After review and confirmation, every site collection received the new permission level: “Auditing Permissions.”<\/p>\n

  <\/a><\/p>\n

  <\/a><\/p>\n

  Using the “Group Management Wizard”, our SharePoint administrator followed the same procedure to create a new SharePoint group (“Auditors”). After setting the group name, description, and owner, and reviewing the changes, the “Auditors” group was created in all site collections.<\/p>\n

  <\/a><\/p>\n

  What needed to be done next was assigning the “Auditing Permissions” level to the “Auditors” group on the “Reports” document library, for all 20,000 site collections. As you can imagine, there is a wizard for that: the “Manage Permissions Wizard” was our hero here.<\/p>\n

  <\/a><\/p>\n

  <\/a><\/p>\n

  Now we had a document library named “Reports” with broken permissions inheritance in all site collections, and a SharePoint group named “Auditors,” with the assigned custom permission level “Auditing permissions” for that library.<\/p>\n

  Of course, at first, all 20,000 “Auditors” SharePoint groups (one per site collection) were empty. By using SPDocKit<\/a> “Group Membership Wizard,” we were able to easily populate the groups with standard auditors.<\/p>\n

  <\/a><\/p>\n

  <\/a><\/p>\n

  A few minutes and five wizards later, we had broken permissions inheritance on 20,000 document libraries, created 20,000 SharePoint groups and custom permission levels, assigned necessary custom permissions on those libraries, and populated the newly created SharePoint groups. SPDocKit<\/a> made this job much easier, since writing custom PowerShell scripts would have taken considerably more time, and the process would have been more prone to errors. Executing those tasks manually through the SharePoint interface would not have been an option at all. In all the wizards mentioned above, all site collections from a web application were selected, but that is not a limit: admins can only use some of them. If – for example – auditing needs to be done only on 100 projects, and not on all 20,000, admins will select the 100 projects for which it is required.<\/p>\n

  With SPDocKit<\/a> batch permission wizards, it is possible to do much more. It is possible to revoke permissions, or change them. It is possible to change the base permissions set for the permission level. It is possible to add or remove members from SharePoint groups. Essentially, whenever and wherever there is a huge set of lookalike SharePoint site collections and sites, and there is a need for a permissions change on all (or some!) of them, SPDocKit<\/a> permission wizards are your best friend. And this is the case in all scenarios in which site provisioning is involved: it doesn\u2019t matter if it is a matter of self-service site provisioning, or site provisioning through a business work flow. Those kinds of sites (project sites, team sites, meeting sites\u2026) are usually identical, or at least very similar to each other in structure, and there are usually plenty of such sites (SharePoint is a collaboration platform, after all).<\/p>\n

  \n\t\t\t

  \n\t\t\t <\/div><\/div>\n\t\t