SharePoint Designer is no free lunch
Added By Shawn Shell at 6-Apr-2009 | Twitter: @shawnshell |
Microsoft recently announced that they are releasing SharePoint Designer (SPD) for free. This announcement has generally be heralded as a positive step for Redmond -- as SharePoint licenses grow, Microsoft can only help themselves and their clients by enabling SharePoint customization and usage. However, I've recently had two conversations with clients who were deeply concerned by the announcement. Taking that a step further, a company called Portalogiks, maker of the Virtual Training Center for SharePoint, released a newsletter with the title "SharePoint Designer Infection."
The Portalogiks newsletter asked both an implicit and explicit question: what if the average end-user downloaded, installed, and began using SharePoint Designer on their sites? Could this create a mess for the IT departments of these affected companies? The answer is: very probably. Even the clients I spoke with were nervous, without the benefit of seeing the Portalogiks newsletter.
As described in the SharePoint Report 2009, governance is a continual struggle for organizations large and small. In fact, SharePoint is famous (deservedly or not) for creating governance nightmares in enterprises that do control its use. Our research further describes how SPD can very deeply and irreversibly customize SharePoint sites. At least the for-fee license model prevented the casual SharePoint user gaining unfettered exposure to the tool; customers could simply limit access to SPD and thereby enforce some sort of governance over SharePoint customization. (Of course, as our research customers know, there are other governance challenges to address around browser-based configuration and Visual Studio-based customization as well.)
To make matters worse, there are few controls within SharePoint that would disable just SharePoint Designer access without disabling legitimate customization access. SharePoint's permission model works relatively well for content. However, security is not as granular as an administrator might want when facing the task of trying to disable SPD. Since SPD access uses the same mechanisms as the rest of Office, disabling SPD would disable the Office clients like Word, PowerPoint, and Excel. In addition, the ability to customize aspects of the SharePoint interface does not distinguish between SPD and the web client interface. It is true that administrators can limited customization access by user, but it's likely that organizations might want to enable certain customizations through the web interface, but limited SPD to the same community of users.
If you're the administrator of a SharePoint environment, I would recommend you get a handle on where SPD is currently installed and lock down the remaining workstations in your environment. Remember, you still have one remaining foothold on your environment: group policies through Active Directory. Beyond that, I would carefully review what permissions are granted to existing users; anyone who doesn't explicitly need to customize SharePoint should have their permissions trimmed as much as reasonable.
To be fair, this governance situation is not entirely Microsoft's to resolve. Enterprises need to take responsibility for their own governance program. They have to create, monitor, and evolve how, what and where SharePoint is used in their user community. This involves actually developing policies and enforcing them. However, where Microsoft has failed their licensees (and one continual weakness in SharePoint) is in not giving administrators the tools to properly control the SharePoint infrastructure.
Categories: Shawn Shell, Evaluating SharePoint, Implementation, Marketplace at Large, SharePoint
