Introduction (Implementing Common Desktop Management Scenarios with the Group Policy Management Console)

Applies To: Windows Server 2003 with SP1

Group Policy Overview

The IntelliMirror® management technologies provide Active Directory-based change and configuration management of user and computer settings on computers running a member of the Microsoft® Windows® Server 2003 or Microsoft Windows® 2000 families of operating systems, or the Microsoft® Windows® XP Professional operating system. Group Policy provides the infrastructure for IntelliMirror by allowing you to specify settings for registry-based policy, security, software installation, scripts, folder redirection, Remote Installation Services, and Internet Explorer maintenance.

The Group Policy settings that you create are contained in a Group Policy object (GPO). By linking a GPO to selected Active Directory Service containers – sites, domains, and organizational units (OUs) – you can apply these settings to the users and computers in those Active Directory containers. Group Policy inheritance and precedence determine where and how you link GPOs. By default, options set in GPOs linked to higher levels of Active Directory containers – sites, domains and OUs – are inherited by all containers at lower levels, though inheritance does not occur across domains. Because lower-level GPOs apply last, they override higher-level GPOs and can provide lower-level OUs with a different set of Group Policy settings.

To manage GPOs, you use the Group Policy Management Console (GPMC) or its scripting interfaces. GPMC is a new tool, released at the launch of Windows Server 2003. It is important to note, however, that GPMC is a very effective tool for managing Group Policy in Windows 2000 domains and, with the exception of a few new features, does not require Windows Server 2003 to be running in your environment.

It is assumed that the reader of this white paper has an understanding of basic Group Policy principles.

About the Common Desktop Scenarios

Group Policy is a rich and flexible technology providing the capability to efficiently manage a large number of computer and user accounts through a centralized, “one-to-many” model. With this flexibility comes the potential for complexity. For example, Group Policy in Windows Server 2003 exposes almost 1,000 configurable settings. This can initially appear a daunting task – how does the administrator assess the relative importance of these settings, and what features enabled by Group Policy might be considered when deploying a solution?

This Common Desktop Scenarios white paper provides a structured, tested, and consistent set of pre-packaged GPOs and associated documentation, with the goal of lowering the “barrier of entry” for those assessing Group Policy.

The scenarios described in this white paper provide a good starting point from which you can begin evaluating and understanding Group Policy. By implementing these scenarios in a test environment, you should be able to:

  • Quickly understand the scope of Group Policy and consider how to use a wide number of settings.

  • List some of the important solutions enabled by Group Policy.

  • Gain familiarity with some of the new functionality introduced with GPMC, particularly the backup/import of GPOs and Group Policy reports.

  • Reach conclusions about how to implement Group Policy in your production environment.


The approach taken in this white paper has significant differences to previously released versions. These differences primarily reflect the new features available in GPMC and are described fully later in this document.

How to Use the Common Desktop Scenarios

The GPOs provided with this white paper were created using the Backup capability of GPMC. This new tool provides a single entry point for management of Group Policy in your environment and can manage both Windows 2000 and Windows Server 2003 domains. You can download the Group Policy Management Console (GPMC) from the Microsoft Web site ( You can import these GPOs into your environment as a first step toward implementing the common scenarios. The details of each scenario are described in this document and further documented in a spreadsheet, as well as in HTML-based reports generated using the Group Policy Reports capability of GPMC for each of the GPOs.

In many cases, a scenario might deliver a specific computer/user configuration that is close to the required environment for your production environment and might not need significant changes. In other cases, it might be necessary to substantially modify the GPOs provided to ensure alignment with your business goals.

The GPOs can be implemented and validated in a test environment, modified (where necessary) to map to your specific needs, and – after appropriate testing – copied or imported into a production environment.

The mere act of importing the scenario GPOs into your domain has no immediate impact on computers or users. To affect target accounts, the GPOs must be linked to an appropriate Scope of Management (SOM) – a site, domain, or OU which you want to manage using these GPOs. This means that the reader with limited test resources might choose to import the GPOs into a production environment and – before applying to a set of computer or user accounts – link to a SOM that has a more limited number of accounts, effectively forming a controlled pilot program. After completing the pilot program and testing any required changes, the GPOs can be linked to broader SOMs. This approach is most effective when computers and users are targeted through OUs, and the majority of this white paper assumes that this is the targeting mechanism used (unless noted otherwise).


You can download the CommonScenarios.msi installation package, which includes this document and supporting files, from the Microsoft Download Center.

Overview of the Scenarios

The following is a list of the scenarios along with typical examples.

Lightly Managed

Use this scenario for power users or developers who require considerable control over their computer. You can also use this scenario in an organization where tightly managed desktops are not acceptable to users or where desktop management is highly delegated. Along with the other scenarios, the Lightly Managed scenario supports increased security and promotes consistency of user experience, both of which can be beneficial even where a tightly managed desktop is not appropriate.

The Lightly Managed scenario has the following characteristics:

  • Is the least managed of all of the scenarios.

  • Allows users to customize most settings that affect them but prevents them from making harmful system changes.

  • Includes settings that reduce help desk costs and user downtime.

  • Supports free-seating, which means users can sit down at any computer and access all their resources, applications, and data as if they were sitting at their own computer. This also simplifies your file-backup scenarios, because users’ files are all stored on designated file servers.

  • Typically has a core set of applications assigned to either the user or the computer, which are always available. Users can also install applications that have been published for them, which they can choose to install.


The Mobile scenario is relevant to mobile/laptop computers and their users. This scenario pays particular attention to the disconnected user who frequently needs to work offline and occasionally resynchronize with the corporate network.

The Mobile scenario has the following characteristics:

  • Can be used by users who are away from the office most of the time, who log on using low-speed, dial-up links, but who also occasionally log on using high-speed network links.

  • Can also be used by users who are away from the office only occasionally and who log on by using remote access or remote network links.

  • Allows users continuous access to their data and configuration settings whether the computer is connected to or disconnected from the network.

  • Partially supports free-seating (can optionally support full free-seating) to facilitate centralized data backup and to enable users to access important data and settings from additional computers.

  • Allows users to disconnect from the network without logging off or shutting down.


Use this scenario in a university computer laboratory or library where users can save some customizations, such as desktop wallpaper and color scheme preferences, but are not allowed to change hardware or connection settings.

The Multi-User scenario has the following characteristics:

  • Allows basic customization of the desktop environment. Users can save desktop configurations, but they cannot customize network, hardware, and system settings.

  • Supports free-seating; users can log onto any computer and get their data and settings. No cached state is maintained on the computer when they leave.

  • Users have restricted write access to the local computer and can only write data to their user profile and to redirected folders.

  • Has a set of applications that are always available (assigned), as well as applications that can be installed and removed as necessary (published).

  • Is highly secure.


The AppStation scenario is used when you require highly restricted configurations with only a few applications. Use this scenario in vertical applications such as marketing, claims and loan processing, and customer-service scenarios.

The AppStation scenario has the following characteristics:

  • Allows minimal customization by the user.

  • Allows users to access a small number of applications appropriate to their job role.

  • Does not allow users to add or remove applications.

  • Supports free-seating.

  • Provides a simplified desktop and Start menu.

  • Users have restricted write access to the local computer and can only write data to their user profile and to redirected folders.

  • Is highly secure.


Use the TaskStation scenario when you need the computer dedicated to running a single application, such as on a manufacturing floor, as an entry terminal for orders, or in a call center.

The TaskStation scenario is similar to the AppStation scenario, with the following changes:

  • It has only one application installed, which automatically starts when the user logs on.

  • No desktop or Start menu is present.


Use this scenario in a public area, such as in an airport where passengers check in and view their flight information. Because the computer is normally unattended, it needs to be highly secure.

The Kiosk scenario has the following characteristics:

  • Is a public workstation.

  • Runs only one application.

  • Uses only one user account and automatically logs on. The system automatically resets to a default state at the start of each session.

  • Runs unattended.

  • Is highly secure.

  • Is simple to operate, with no logon procedure.

  • Does not allow users to make changes to the default user or system settings.

  • Does not save data to the disk.

  • Is always on (the user cannot log off or shut down the computer).

A workstation that uses the Kiosk scenario is similar to a TaskStation, but users are anonymous in that they all share a single user account that automatically logs on at computer startup. This is achieved by modifying the Kiosk machine in a manner described later in this document. Users cannot customize their environment and user states are not preserved.

Although user sessions are usually anonymous, a user can log on to an application-specific account, such as to a Web-based application through Internet Explorer (assuming Internet Explorer is the “kiosk application” launched at startup).

The dedicated application could be a Line of Business (LOB) application, an application hosted in Internet Explorer, or another application, such as one available in Microsoft Office. The default application should not be Windows Explorer or any other shell-like application. Windows Explorer allows more access to the computer than is appropriate for a Kiosk computer. Be sure the command prompt is disabled and Windows Explorer cannot be accessed from any application you use for this purpose.

Applications used for kiosk scenarios should be carefully checked to ensure they do not contain “back doors” that allow users to circumvent system policies. For example, they should not allow users access to applications that access the file system. Ideally, you should only use applications that comply with The Application Specification for Windows 2000, are Certified for Windows, and that check for Group Policy settings before giving users access to prohibited features. For more information, see the “The Application Specification for Windows 2000” at the Microsoft Web site ( Older applications will not normally be Group Policy-aware, so try to disable any features that allow users to bypass administrative policy.

The registry entries Run and RunOnce are disabled in the Kiosk scenario through associated policy settings.


Applications that use the RunOnce entry to finish an installation or upgrade will fail when the Do not process the Run Once list Group Policy setting is enabled.

Please see the “Scenario Comparison” table in Appendix A for a comparison of features across scenarios.