I don’t mean to imply that a lot of SharePoint deployments become shelfware. Nor do I intend that this post will be an exhaustive list of the reasons SharePoint is or isn’t used.
But, based on my experience, I know why a lot of SharePoint deployments go stale. Groups. Groups are a good and bad thing. When utilized, they are efficient and powerful; access can be granted to the correct users easily and quickly. When done right, groups are fantastic.
But, quite often, SharePoint is deployed, access rights are granted by groups (usually SharePoint groups) and then content is created and maintained. Then the groups go stale, nobody manages the membership and it becomes an incredible hassle to update. Users have access to material from their previous position int the company and not their current one. New users don’t have access so everybody goes back to emailing spreadsheets.
And SharePoint goes stale.
It’s a horrible cycle and pretty inevitable if you don’t have a plan for how to manage the group access right from the beginning. Based on most research, organizations are using Active Directory groups to manage SharePoint access more often than SP groups.
Those Active Directory groups are used for so many other access and communications functions that it is absurd not to keep the membership accurate (not that everybody does, but at least I have an answer for how to do it!).
Here’s what I recommend: dynamic Active Directory groups. Not QBDL’s, those do nothing. But manage membership in an actual Active Directory group dynamically. Imanami offers GroupID Automate which does it with a few clicks (see our post The three most common dynamic Active Directory groups). As users change departments, locations, job titles, managers, GroupID reads Active Directory or any other data source and moves their group membership automatically. These groups can then be used to grant access to SharePoint and always be accurate.
Some groups can’t be dynamically maintained. There is no data that says you, me and Bob from down the hall are working on the next top secret product. So I can create a group using Active Directory self service and manage the membership as the project expands/contracts. There is even a way to launch that particular group from within SharePoint!
The biggest caution for statically manage groups like that? Group glut. When that project ends, so should the group. So, GroupID has built-in group expiration. The group will expire every so often unless the group owner(s) renews it. I get the notification that the group is expiring and I no longer need it? Just let GroupID delete it. No group glut.
SharePoint projects are complex, no need to go through all of that work just to let the group access mechanism scuttle it. It isn’t hard or expensive to keep these groups maintained properly with the correct tools. Don’t let SharePoint become shelfware, maintain your Active Directory groups!
Let us demonstrate how to solve your SharePoint group woes.
Jonathan Blackwell
View ProfileSince 2012, Jonathan Blackwell, an engineer and innovator, has provided engineering leadership that has put GroupID at the forefront of group and user management for Active Directory and Azure AD environments. His experience in development, marketing, and sales allows Jonathan to fully understand the Identity market and how buyers think.