SharePoint may be the most flexible and most powerful application that Microsoft has ever created. But it has been...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
said that with great power comes great responsibility. Unless the proper governance is put into place, SharePoint can quickly spiral out of control. Learn which factors can lead to SharePoint sprawl and how you can regain control of your SharePoint deployment.
To understand why SharePoint sprawl happens, you have to move beyond the idea that SharePoint is simply an application for developing websites and think of it as a collaboration tool. Sure, a lot of organizations use SharePoint to create their corporate intranet, but there are several other types of sites that organizations can also create.
Team sites are probably the most widely used type of SharePoint site. A team site is a dedicated SharePoint site that allows a team, department or workgroup to collaborate on a project. Team members can use the site to store documents, share contact information, display data or share news related to a project.
Although team sites can be extremely useful, they can also be a major source of SharePoint sprawl. Team sites can become quite unwieldy because in an uncontrolled environment, team members may create any number of sub sites. Each of these sub sites can contain multiple document libraries, meeting workspaces and so on.
The reality is that SharePoint contains built-in templates for creating a huge variety of site types, and any of these sites have the potential to spiral out of control if left unchecked.
Why is SharePoint sprawl a problem?
The consequences of SharePoint sprawl can vary depending on the type of organization in which the sprawl is occurring. For example, the most immediate effect in a small organization might be the excessive use of disk space on the server that is hosting the SharePoint database. At first, this may not sound so bad because disk space has become inexpensive. But there are at least a couple of other related side effects that need to be considered.
One side effect is that is having a rapidly growing SharePoint database can throw a kink into your backup efforts. Your users will expect you to backup their SharePoint data on a regular basis. Because of that, you may find that you have to invest in a higher capacity tape drive. Or you might have to devise a backup strategy that allows you to back up an ever-expanding data set within your allotted backup window.
Another side effect to uncontrolled SharePoint sprawl may not manifest itself for quite some time. If you have ever worked through a SharePoint upgrade, then you know how much work is involved in the planning process and in the post-upgrade testing.
Any time that you allow SharePoint data to expand uncontrollably, you complicate future upgrades or migrations to new versions of SharePoint because each SharePoint site requires planning and testing. The worst part is that you may end up wasting time planning for the migration of SharePoint sites that haven’t even been used for quite some time. Also keep in mind that it’s better to prevent excessive SharePoint sprawl from occurring in the first place than to try to deal with the consequences down the road.
Finally, SharePoint sprawl can be especially problematic in regulated organizations. Think about it for a moment: SharePoint sprawl is caused by the unplanned -- and often undocumented -- creation of SharePoint sites. The problem is that any one of these sites could potentially contain data that is subject to regulatory requirements. Furthermore, if users are creating sites in a chaotic manner, then you can bet that there has been no regard for retention policies, metadata or taxonomies.
Ways to avoid SharePoint sprawl
To protect your organization from the negative effects of SharePoint sprawl, it’s a good idea to put controls in place long before you ever make SharePoint accessible to your end users. I recently heard about one organization, for example, who involved its compliance team during every step of its SharePoint deployment.
By doing that, the organization was able to ensure that its SharePoint platform would be designed in such a way that would force data to be stored in a consistent manner. It was also able to put all of the necessary retention policies in place before users began storing any data within SharePoint document libraries.
But what if you have inherited an existing deployment, and SharePoint sprawl has already occurred? In this type of situation, the first thing that you must do is to take steps to prevent the sprawl from getting any worse. After that, you can focus on reducing the sprawl that has already occurred.
There are two critical steps to controlling SharePoint sprawl. First, you need to implement controls to prohibit users from randomly creating SharePoint sites. That way, whenever users need to create SharePoint sites, they will have to go through a central point of contact.
The idea setting up a central approval process isn’t to have a corporate bureaucrat deciding which employees are worthy of having their requests granted. If a user needs a SharePoint site, he or she should be allowed to have a site. The reason for having someone to oversee site creation is that it makes it a lot easier to track site creation and usage.
As part of the process, any users who are requesting SharePoint sites should be required to provide certain information along with their requests. Some of the essential information might include the following:
- The name of the user who is making the request
- The requesting department
- The name and contact information of the user’s supervisor
- The user’s telephone number
- The user’s email address
The second step is to perform a periodic check to see which sites are still being used. I once had a client ask me to help him with a SharePoint sprawl problem. After taking an inventory of the SharePoint sites that existed within the organization, we set out to determine which sites were still being used. To make a long story short, we couldn’t even figure out who some of the sites belonged to. Many of the sites that were identifiable belonged to employees who had left the company or changed departments.
Collecting user information gives you an easy way of identifying the owner of each site. That way, you can check every six months or so to see if the site is still being used.
If the user who requested the site leaves the company, then you also have the contact information for that person’s supervisor, and you can ask him or her whether or not the site is still in use.
How to solve document library sprawl
Another type of SharePoint sprawl that can cause problems for organizations is what I call document library sprawl.
SharePoint document libraries are linked to a powerful search engine, and they can also be configured to support the retention of multiple versions of documents. Because of that, some organizations are beginning to copy frequently used data from file servers to SharePoint document libraries.
Don’t get me wrong -- there is nothing wrong with using SharePoint as a file server. In fact, it might eventually become the norm. The problem is that many organizations also leave a copy of their data in the original location on the file server. This results in having two separate versions of a file stored in two different locations. This can lead to excessive disk usage as well as user confusion.
One easy solution is to establish a clear governance policy that dictates how SharePoint document libraries should and should not be used. That way, you can prevent the problems that come from having multiple versions of the same file scattered across your network.
ABOUT THE AUTHOR
Brien M. Posey has received Microsoft’s Most Valuable Professional award seven times for his work with Windows Server, IIS, file systems/storage and Exchange Server. He has served as CIO for a nationwide chain of hospitals and healthcare facilities and was once a network administrator for Fort Knox.