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 |
User-based |
Yes |
WDS 3.01 on |
Machine-based |
Yes |
Windows Vista |
Machine-based |
No |
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 |
X |
|
Prevent indexing files in Offline Files cache |
X |
|
Allow using diacritics |
X |
X |
Prevent displaying advanced indexing options in the Control Panel |
X |
X |
Prevent Indexing uncached Exchange folders |
X |
X |
Prevent Indexing Microsoft Office Outlook |
X |
X |
Prevent indexing e-mail attachments |
X |
X |
Prevent indexing public folders |
X |
X |
Indexer data location |
X |
X |
Control Rich Previews for Attachments |
X |
|
Add Primary Intranet Search Location |
X |
|
Add Secondary Intranet Search Locations |
X |
|
Preview Pane location |
X |
|
Set Large or Small Icon View in Desktop Search Results |
X |
|
Stop Indexing on Limited Hard Drive Space |
X |
|
Prevent Unwanted IFilters and Protocol Handlers |
X |
|
Do not allow web search |
X |
|
Prevent Indexing Certain Paths |
X |
|
Default Indexed Paths |
X |
|
Default Excluded Paths |
X |
|
Prevent Indexing of Certain File Types |
X |
Overview of Configuring WDS with Group Policy
The following is an overview of the steps required to configure WDS with Group Policy:
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.
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.
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.
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.
Note
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:
Start the Microsoft Management Console:
Click Start, and then Run.
In the Open field, enter mmc and then press ENTER.
Start the Group Policy Editor:
Click File and then click Add/Remove Snap-in.
Click Add.
Select Group Policy.
Click Add, click Finish, click Close, and then click OK.
Load the DesktopSearch30.adm file into the Group Policy Object Editor:
Under Console Root, click Computer Configuration.
Right-click the Administrative Templates folder, and then click Add/Remove Templates.
Click Add.
Locate and then click the DesktopSearch30.adm file.
Click Open, and then click Close.
Under Administrative Templates, expand the Windows Components node followed by the Windows Search node.
Save these settings for later use:
Click File.
Click Save As.
Enter DesktopSearch.msc.
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
Description |
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
Description |
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
Concepts
Policies for Windows Vista Policies for Windows XP and Windows Server 2003 WDS 3.01 Troubleshooting Guide