Use Group Policy to Control SharePoint Installations

Ever since Windows SharePoint Services 2.0, organizations have fought the proliferation of unmanaged SharePoint servers and farms. But when SharePoint 2010 was introduced, Microsoft added a lesser-known feature called a "deployment blocker" that prevents SharePoint from being installed.

The deployment blocker is a simple registry value, called DisableInstall, in the following registry path:

HKLMSoftwarePoliciesMicrosoftShared ToolsWeb Server Extensions15.0SharePoint

Not surprisingly, this applies to SharePoint 2013 (v 15.0). If you change the 15.0 to 14.0, it applies to SharePoint 2010.

The DWORD value is checked by SharePoint's setup.exe. If the registry value exists and is set to 1, setup.exe will not progress.

By deploying this registry value to all servers as a default, you can establish a policy that unapproved SharePoint servers and farms are not allowed. Then, for servers on which SharePoint is allowed, you can simply delete the registry value.

The registry entry could be configured as part of an image of your corporate, baseline installation of Windows Server. Alternatively, you can deploy the registry value using Group Policy.

Group Policy—a feature of Windows and Active Directory (AD)—allows you to centrally manage configuration for users and computers. In a nutshell, a Group Policy setting is a centrally defined configuration. One or more Group Policy settings are contained in a Group Policy Object (GPO). So you can think of a GPO as a container of configuration settings.

A GPO is then applied to a scope of users or computers. The most commonly used scope is a domain or an organizational unit (OU) in AD. By linking a GPO to a domain or OU, you are specifying that settings in that GPO should apply to all users and computers within that scope.

To manage a setting such as the SharePoint deployment blocker, you can use a Group Policy setting called a registry preference to configure the registry value. I recommend that you scope that setting to the entire domain, to establish a baseline policy that disallows SharePoint installations.

Then, within the OU that contains SharePoint servers, create another policy that deletes the registry value. Servers within the OU will actually apply both the domain-wide policy that disallows SharePoint and the OU policy that allows it. But because GPOs are applied in that order—domain first, then OU-scoped GPOs—the OU-scoped policy will "win," and the result will be that servers within the SharePoint server OU can successfully install SharePoint.

Creating GPOs requires delegation in AD. Most typically, your administrative account would be added to the Group Policy Managers group. However, you might need to ask for help from your AD team if you are not familiar with creating or managing GPOs.

The broad-stroke steps for the process are as follows:

1. Create a GPO called, for example, SharePoint Installation Block. This GPO will be scoped (linked) to the domain. So if you already have GPO scoped to the domain, you can skip this step and just add the registry preference directly to that GPO. However, it is not recommended to modify the default GPO called Default Domain. Instead, create or modify a custom GPO. Edit the SharePoint Installation Block GPO and, within the Computer Settings node, navigate through Preferences to Registry. Create a new registry preference with the following parameters:

2. Create a GPO called, for example, SharePoint Installation Allow. This GPO will be scoped to an OU—for example, the SharePoint OU within your Servers OU. Again, if you already have a custom GPO scoped to the same servers, you can modify that GPO.

3. Edit the SharePoint Allow GPO and, within the Computer Settings node, navigate through Preferences to Registry. Create a new registry preference with the following parameters:

Group Policy settings are applied when a computer is restarted and approximately every 90-120 minutes thereafter. You'll know the policy has been applied by looking at the value directly, using regedit.exe.

You can verify the functionality of the setting by trying to run SharePoint's setup.exe application. In the SharePoint OU, installation will proceed. In all other OUs and containers, setup.exe will fail.

To summarize, this is the SharePoint deployment block registry value:

Key: HKLMSoftwarePoliciesMicrosoftShared ToolsWeb Server Extensions15.0SharePoint
Value: DisableInstall (REG_DWORD)
Data: 00000001

Just one caveat—this approach is not rock-solid. It is possible for a local administrator on the server to go around the policy, due to the inherent nature of registry preferences. But the admin would have to know what was happening, as well as have the knowledge to find and delete the deployment blocker. So although the deployment blocker is a 95% solution, it's not a guarantee against unapproved SharePoint servers. But I nevertheless recommend that every organization consider structuring and managing its SharePoint policies in this way.

In a future article, I will share a PowerShell script that automates the creation of the GPOs I've described here. Until then, much aloha from Las Vegas!