WDS Group Policy

Applies To: Windows Server 2008

Windows Desktop Search fully supports registry-based Group Policy. Administrators can use Group Policy to apply preferred configurations or policy settings to a set of targeted computers within an Active Directory service environment. WDS 3.01 only supports per-machine group policy.

This section covers the following topics:

  • Differences in Group Policy between Versions

  • Overview of Configuring WDS with Group Policy

  • Getting the WDS Administrative Template

  • Windows Search Policy Registry Location

  • General Policy Setting Behavior

  • Adhering to System Policies

Differences in Group Policy between Versions

Group Policy settings vary between different versions of WDS and different versions of Windows operating systems.

Differences in Group Policy between WDS Versions

Version Types of Policies Requires Administrative template?

WDS 2.6.6



WDS 3.01 on
Windows XP / Server 2003



Windows Vista



The WDS 3.01 Administrative template is meant to control functionality on Windows XP and Windows Server 2003. Some of these policies are also included by default in the Windows Vista group policy settings. The primary difference in the policies is that the Windows Vista UI is different from the WDS UI.

The policy structures between WDS 3.01 and WDS 2.66 are different, and 2.66 policies do not apply to 3.01 or vice versa. There was a major architecture change between 2.x and 3.x platforms. WDS 3.01 is the first effort at taking the policies that were implemented in WDS 2.66 and moving them forward to the new WDS 3.x platform. To manage an environment that has both WDS 3.01 and WDS 2.66, you need to use both ADM templates.

Differences in Group Policy between OS Versions

The following table lists the Group Policies available for WDS 3.01 on Windows XP/Windows Server 2003 and Windows Vista.

Policy Windows XP/ Server 2003 Windows Vista

Allow Indexing of encrypted files


Prevent indexing files in Offline Files cache


Allow using diacritics



Prevent displaying advanced indexing options in the Control Panel



Prevent Indexing uncached Exchange folders



Prevent Indexing Microsoft Office Outlook



Prevent indexing e-mail attachments



Prevent indexing public folders



Indexer data location



Control Rich Previews for Attachments


Add Primary Intranet Search Location


Add Secondary Intranet Search Locations


Preview Pane location


Set Large or Small Icon View in Desktop Search Results


Stop Indexing on Limited Hard Drive Space


Prevent Unwanted IFilters and Protocol Handlers


Do not allow web search


Prevent Indexing Certain Paths


Default Indexed Paths


Default Excluded Paths


Prevent Indexing of Certain File Types


Overview of Configuring WDS with Group Policy

The following is an overview of the steps required to configure WDS with Group Policy:

  1. Create an environment that supports the efficient application of Group Policy.

    This step concerns the design of the Active Directory domain, sites, and organizational units. Precisely how you implement this step depends on the administrative structure of your company and the kinds of policies you want to set.

  2. Create a Group Policy object (GPO) that contains the appropriate policy settings.

    Using the Active Directory management console or the Group Policy Management Console (GPMC), you can create a GPO that contains one or more policy settings for WDS and other applications that use Group Policy. At this stage, no users or computers are affected by the GPO.

  3. Scope the GPO to the desired set of computers.

    You can fine tune which computers are affected by your GPO in the GPMC using security filtering, or you can use Windows Management Instrumentation (WMI) filtering to select a wide range of client-side criteria to decide whether the GPO should be applied.

  4. Link a GPO to a Scope of Management.

    A Scope of Management (SOM) is an Active Directory domain, site, or organizational unit. As soon you link the GPO to an SOM, the GPO affects all computers and users in that SOM.

For more information about Group Policy, visit Information about Group Policy on Microsoft TechNet Web site.


Once forced, Group Policy can take up to 10 minutes to deploy across your organization. Updates to policies related to the WDS UI can be delayed for up to the amount of time it takes for policy to deploy.

Getting the WDS Administrative Template

Windows Vista Vista already has Group Policy support for desktop search, and you do not need to add a template. The search policies are located under Computer configuration->Administrative templates->Windows components->Search.

Windows XP or Windows Server 2003 To get the WDS Administrative template (.adm) file, extract the contents of the WDS 03.01 package using the package extract command (/extract) and locate the file in the Update subfolder at the location where the package was extracted to.

To import the .adm file into the Microsoft Management Console (MMC), follow these steps:

  1. Start the Microsoft Management Console:

    1. Click Start, and then Run.

    2. In the Open field, enter mmc and then press ENTER.

  2. Start the Group Policy Editor:

    1. Click File and then click Add/Remove Snap-in.

    2. Click Add.

    3. Select Group Policy.

    4. Click Add, click Finish, click Close, and then click OK.

  3. Load the DesktopSearch30.adm file into the Group Policy Object Editor:

    1. Under Console Root, click Computer Configuration.

    2. Right-click the Administrative Templates folder, and then click Add/Remove Templates.

    3. Click Add.

    4. Locate and then click the DesktopSearch30.adm file.

    5. Click Open, and then click Close.

    6. Under Administrative Templates, expand the Windows Components node followed by the Windows Search node.

  4. Save these settings for later use:

    1. Click File.

    2. Click Save As.

    3. Enter DesktopSearch.msc.

    4. Click Save.

Windows Search Policy Registry Location

As stated earlier, WDS supports registry-based Group Policies. All policies are created under the following section of the registry:

HKLM\Software\Policies\Microsoft\Windows\Windows Search

Windows Search adds a sub-key only when a policy is applied. Therefore, if no policies are applied, the sub-key is not present.

General Policy Setting Behavior

WDS policies fall into three categories:

  • Setup and configuration

  • Include certain information, paths, or types of data

  • Exclude certain information, paths, or types of data

Furthermore, some of these policies force settings on users and some define defaults that users can override. The forced “prevent” policies (like preventing WDS from indexing certain paths) take precedence over user overrides, which in turn take precedence over the defaults. Because of this precedence, some policies and combinations of policies and user preferences may conflict. For example, a “Prevent Indexing Certain Paths” policy will prevent users from setting WDS to index a specific network share. Suppose some users need to index a path on that share, so you add a “Default Indexed Paths” policy for that path. If the users that need to index that path are also covered by the “Prevent” policy, they will be blocked from indexing the needed path.

Therefore, administrators must take the time to think through and test their Group Policy scenarios, along with the user options they want to allow, before they deploy the policies to end users.

While all Windows Search policy settings are described in detail later in this document, WDS policies generally share the following attributes:

  • Real-time refresh. Once notified that a new policy is applied, WDS automatically refreshes to enforce the setting. For most policy settings, the user does not need to exit or restart the application or log on to Windows again for the new policy to take effect. However, for indexing-related settings, WDS may not remove or add data in the index until the next user logon or the next indexing session.

  • Index purges for most indexing-related policy settings. If you enable policies to prevent the indexing of certain content, the index is automatically purged and rebuilt at the next startup of the computer or related application. For example, if you decide to prevent indexing Outlook items, WDS purges its index of any existing Outlook data after you apply the policy and restart Outlook (or the computer). The only exceptions are for policies that specify file types to index as text and to exclude from indexing. If you subsequently modify such policies, any content that had already been indexed is not purged.

Adhering to System Policies

WDS is built on common Windows components. Therefore, WDS adheres to system-level policies that your organization may have already enabled. There are two specific system-level policies that affect the Windows Deskbar on Windows XP and Windows Server 2003.

Remove the Run command from Start menu


The system removes the Run command from the Start menu. It also prevents users from opening the Run dialog box by pressing the Windows logo key and the R key.

Application behavior

Applications must disable any functionality that lets a user start a program by typing its name and path in a dialog box.

WDS behavior

Automatically turns off the alias feature in Windows Deskbar.

Automatically turns off run operation (=operation) in Windows Deskbar.

Automatically removes the My Deskbar Shortcuts section from Deskbar.

Run only allowed Windows-based applications


The system prevents users from running applications that are not listed under the RestrictRun value.

Application behavior

Applications must not start any application that is not on the RestrictRun list. However, this does not apply when you start applications using COM. If you use the ShellExecuteEx function, the system performs this check automatically.

WDS behavior

Windows Deskbar starts only those applications that are on the RestrictRun list.

See Also


Policies for Windows Vista
Policies for Windows XP and Windows Server 2003
WDS 3.01 Troubleshooting Guide

Other Resources

Information about Group Policy on Microsoft TechNet