Operating System
Using Group Policy Scenarios
White Paper
Abstract
Microsoft® Windows® 2000 introduces several new ways to manage computers and users in your
environment. When you use Windows 2000 Server with Windows 2000 Professional, you can use
Group Policy to control how a workstation functions and reduce the total cost of ownership (TCO)
of the workstations you support.
This white paper describes six scenarios for using Group Policy, one of the key Change and
Configuration Management technologies provided in Windows 2000. Administrators use Group Policy
to specify options for managed desktop configurations for groups of computers and users. Group
Policy includes options for registry-based policy settings, security settings, software installation,
scripts, folder redirection, Internet Explorer maintenance, and remote installation services.
This paper is intended for information technology managers and system administrators who are
interested in using Group Policy to manage users’ desktop environments
Note: These scenarios are intended to be starting points from which you can develop settings that
are tailored to your environment.
© 2000 Microsoft Corporation. All rights reserved.
The information contained in this document represents the current
view of Microsoft Corporation on the issues discussed as of the date
of publication. Because Microsoft must respond to changing market
conditions, it should not be interpreted to be a commitment on the
part of Microsoft, and Microsoft cannot guarantee the accuracy of
any information presented after the date of publication.
This white paper is for informational purposes only. MICROSOFT
MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS
DOCUMENT.
Microsoft, Windows, and Windows NT are either registered
trademarks or trademarks of Microsoft Corporation in the United
States and/or other countries.
Other product and company names mentioned herein may be the
trademarks of their respective owners.
Microsoft Corporation • One Microsoft Way • Redmond, WA 980526399 • USA
0200
Contents
Overview of the Scenarios ..................................................................... 1
Kiosk
1
TaskStation
2
AppStation
2
Public Computing Environment
2
Low TCO Desktop
2
Laptop
3
Features Available in Each Scenario
4
Table 1.
Comparison of Features Used in Each Scenario
4
Installing the Scenarios .......................................................................... 5
Step 1: Install the Scenario Files to a Local Workstation
Table 2
6
Files Installed by the Setup Wizard (Group Policy Scenarios.msi)
6
Step 2: Install the Scenario GPOs on the Domain Controller
8
Step 3: Create the OUs to Link to the Scenarios
9
Step 4: Create User and Computer Accounts for Each Scenario
9
Step 5: Define Environment-Specific Settings
Table 3
Group Policy Settings to Customize for Your Environment
Step 6: Customize Optional Settings
10
10
10
Advanced Installation Topics............................................................... 11
Removing the Scenarios from the Domain
11
Running Loadpol or Savepol a Second Time
12
Saving and Moving the Scenario GPOs to Another Domain
13
Ensuring Application Compatibility
14
Table 4. Set Permissions to Protect Files
15
Customizing Your Windows 2000 Setup
15
Using Group Policy Loopback Processing Mode
15
Redirecting Folders
16
Using Roaming User Profiles
17
Restricting Access to Drives
17
Working with Security Settings
18
Applying Security Templates
18
Configuring Security Settings
19
Configuring Internet Explorer Group Policy Settings
20
Using and Configuring Specific Scenarios ........................................ 22
Kiosk Scenario
22
Kiosk Settings
22
User Account Setup for Kiosk
23
Security Configuration for Kiosk
24
Optional Settings for Kiosk
26
Implementing the Kiosk Scenario
29
TaskStation Scenario
30
TaskStation Settings
30
User Account Setup for TaskStation
30
Security Configuration for TaskStation
31
Optional Settings for TaskStation
32
Implementing the TaskStation Scenario
32
AppStation Scenario
33
AppStation Settings
33
User Account Setup for AppStation
33
Security Configuration for AppStation
34
Optional Settings for AppStation
35
Implementing the AppStation Scenario
35
Public Computing Environment Scenario
36
Public Computing Environment Settings
36
User Account Setup for PCE
37
Security Configuration for PCE
38
Optional Settings for PCE
38
Implementing the PCE Scenario
39
Low TCO Desktop Scenario
40
Low TCO Desktop Settings
40
User Account Setup for Low TCO Desktop
40
Security Configuration for Low TCO Desktop
41
Optional Settings for Low TCO Desktop
42
Implementing the Low TCO Desktop Scenario
43
Laptop Scenario
44
Laptop Settings
45
User Account Setup for Laptop
45
Security Configuration for Laptop
47
Optional Settings for Laptop
47
Table 6
48
Modifying Group Policy Settings for “Road Warriors”
Policy Setting
48
Path
48
Comment
48
Table 7
Enabling Laptop Users to Install Applications
49
Policy Setting
49
Path
49
Comment
49
Implementing the Laptop Scenario
49
Special Topics ....................................................................................... 50
Upgrading Workstations that Use ZAK and Windows NT 4.0
Table 8
Strategy for Migrating Elements of Windows NT 4.0
51
52
Windows NT 4.0 Component
52
Migration Procedure
52
Known Issues Related to Using the Scenarios
55
Using the Kiosk Scenario on Stand-Alone Workstations
58
Supporting Utilities and Support Tools
60
Tools Shipped in the Installation .Msi File
60
Windows 2000 Server Core
60
Windows 2000 Support Tools
60
Windows 2000 Resource Kit
60
GartnerGroup Desktop Management Classifications
Table 9 GartnerGroup Worker Types Mapped to the Group Policy
Scenarios
Using Group Policy Settings to Hide Drives
62
63
64
Permissions Needed for Folder Redirection
Table 10
Permissions Needed for Folder Redirection
Additional Resources: Gartner Group References
65
65
69
For More Information ............................................................................ 70
Related Information and Resources
70
Overview of the
Scenarios
The following is a list of the six scenarios discussed in this document. Each
scenario includes an example of a typical workstation that uses the scenario:
Kiosk Use in a public area, such as in an airport where passengers check in
and view their flight information.
TaskStation Use on a manufacturing floor or as an entry terminal for orders.
AppStation Use in marketing or finance departments where users require a
small number of applications (up to five) to do their job.
Public Computing Environment (PCE) Use in a university lab 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.
Low TCO Desktop Use for power users or developers who require a lot of
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.
Laptop Use on mobile computers.
The characteristics of each scenario are listed in the subsections that follow. To
install a scenario, read "Installing the Scenarios" later in this document, and
then read “Configuring Specific Scenarios” for the scenario you want to install.
Note: These scenarios are intended to be starting points from which you can
develop settings that are tailored to your environment.
Kiosk
A workstation that uses the Kiosk scenario has the following characteristics:

Is a public workstation.

Runs only one application.

Uses only one logon account.

Runs unattended.

Has users who are unknown to the Kiosk owner.

Has users who do not need or have logon credentials.

Is highly secure.

Is simple to operate.

Allows users to make little or no changes to the default setting.

Does not save data to the disk.

Is always on.
Windows 2000 Server White Paper
1
TaskStation
A workstation that uses the TaskStation scenario shares the same
characteristics as the Kiosk scenario with the following exceptions:

Allows users to save data.

Allows users to save some personal settings.

Allows users to have unique accounts for logging on to the computer.

Does not allow applications to be added or removed.
AppStation
A workstation that uses the AppStation scenario shares the same
characteristics as the TaskStation scenario with the following exceptions:

Allows users to access multiple applications according to their job role.

Provides users with a framework (for example, a desktop, and icons) from
which to use applications.
Public Computing Environment
A workstation that uses the Public Computing Environment (PCE) scenario has
the following characteristics:

Provides more freedom than the previous scenarios.

Allows users to save desktop configurations.

Has a set of applications that are always available and that can be installed
and removed as necessary.

Is highly secure.
Low TCO Desktop
A workstation that uses the Low TCO Desktop scenario has the following
characteristics:

Is the least managed of all of the scenarios.

Has settings that make the desktop easier to use.

Has settings that reduce help desk costs and user downtime.
Windows 2000 Server White Paper
2

Allows users to install available applications.

Allows users to customize applications and the desktop.
Laptop
A laptop computer that uses the Laptop scenario has the following
characteristics:

Can be used by users who are away from the office most of the time and
who log on by using low-speed, dial-up links but who also occasionally log
on to high-speed network links.

Can also be used by users who are away from the office only occasionally
and who log on by using Routing and Remote Access service or remote
network links.

Allows users continuous access to data and user settings whether the
computer is connected to or disconnected from the network.

Allows users to log on to a laptop and a desktop computer simultaneously.

Allows users to disconnect from the network without logging off or shutting
down.
Windows 2000 Server White Paper
3
Features Available in Each Scenario
Table 1 compares the Windows 2000 features that are available with each
scenario. For more information about each feature, see Windows 2000 Server
Help or the Microsoft Windows 2000 Server Resource Kit.
Table 1.
Comparison of Features Used in Each Scenario
Scenario
Roaming
Number User
of
Profile
Users
Support
User
Data
Saved
Folder
Redirection
User Can
Customize
Assigned
Published
Applications Applications
Kiosk
1
No
No
No
No
1
No
TaskStation
Multiple
Yes
Yes
My
Documents
and
Application
Data
No
1
No
AppStation
Multiple
Yes
Yes
My
Documents
and
Application
Data
No
up to 5
No
PCE
Multiple
Yes
Yes
My
Documents
and
Application
Data
Some
desktop
settings
>3
Yes
Low TCO
Desktop
Multiple
Yes
Yes
My
Documents
and
Application
Data
Almost all
settings
>3
Yes
Laptop
1
Yes
Yes
My
Documents
and
Application
Data
Some
>3
desktop and
configuratio
n settings
Yes
Windows 2000 Server White Paper
4
Installing the Scenarios
Important:
Read this section and its subsections thoroughly before you install the
scenarios.
When you install the Group Policy scenarios, Group Policy objects (GPOs) are
installed on your domain controller. The Group Policy objects contain the
appropriate Group Policy settings for each scenario. When you install Group
Policy objects on a domain controller and then link one or more GPOs to a
container, such as a site, a domain, or an organizational unit (OU), the settings
apply to workstations and users associated with those containers.
For more information about Group Policy settings, including a complete
description of each setting, refer to the Group Policy Reference on the
Microsoft Windows 2000 Resource Kit companion CD.
Note:
These scenarios are intended to be starting points from which you can develop
settings that are tailored to your environment.
The procedures to install the scenarios are as follows:

Install the scenario files to your local workstation.

Install the GPOs on the domain controller.

Create the organizational units (OUs) to link to the scenarios.

Create user and computer accounts for each scenario.

Define environment-specific settings.

Customize settings for your environment.
The following subsections apply to all scenarios. Read this section thoroughly
and then refer to the instructions for the scenario you want to install.
Windows 2000 Server White Paper
5
Step 1: Install the Scenario Files to a Local Workstation
To install the scenario files to a local workstations

From a workstation connected to the domain controller where you want to
install the scenarios, run the Group Policy Scenarios.msi file, which starts
the Group Policy Scenarios Setup wizard.
When you run the Group Policy Scenarios Setup wizard, you have the option to
install the Complete Setup or the Custom Setup. It is recommended that you
choose the Complete Setup.
Table 2 lists the files that the wizard installs, describes their function, and
specifies the location where they are installed.
Table 2
Files Installed by the Setup Wizard (Group Policy Scenarios.msi)
File
Description
Installation Location
Loadpol.bat
Installs GPOs for the six scenarios.
%ProgramFiles%\Group Policy Scenarios
Savepol.bat
Saves changes to the scenario GPOs.
%ProgramFiles%\Group Policy Scenarios
Readme.txt
Contains the most current information about
installing and using the scenarios.
%ProgramFiles%\Group Policy Scenarios
Important: Read both the Readme.txt file and
this document thoroughly before installing the
scenarios.
Sed.exe
A support file used by the Loadpol.bat and
Savepol.bat files.
%ProgramFiles%\Group Policy Scenarios
Nltest.exe
A support file used by the Loadpol.bat and
Savepol.bat files.
%ProgramFiles%\Group Policy Scenarios
Gpbackup.bat
A support file used by the Loadpol.bat and
Savepol.bat files.
%ProgramFiles%\Group Policy Scenarios
Dsprop.vbs
A support file used by the Loadpol.bat and
Savepol.bat files.
%ProgramFiles%\Group Policy Scenarios
Editldif.vbs
A support file used by the Loadpol.bat and
Savepol.bat files.
%ProgramFiles%\Group Policy Scenarios
Windows 2000 Server White Paper
6
ScenarioName.xls Microsoft Excel spreadsheets that list the Group %ProgramFiles%\Group Policy Scenarios\Docs
Policy settings for each scenario, that specify
whether the settings are enabled or disabled,
and that describe any special circumstances to
note when the setting is applied.
You can use the spreadsheets to compare
settings between the scenarios and to track the
custom settings you implement.
GP-Scenarios.doc The document you are reading now.
%ProgramFiles%\Group Policy Scenarios\Docs
Note
At this point, you can use the Remove option in the Group Policy Scenarios
Setup wizard to delete all the scenario source files (including the
documentation) from the hard disk.
Windows 2000 Server White Paper
7
Step 2: Install the Scenario GPOs on the Domain Controller
After you run the Group Policy Scenarios Setup wizard on a computer in the
domain where you want to install the scenarios, you can install the Group
Policy objects (GPOs) on the domain controller.
Important
You must have the appropriate permissions to install the scenarios on the
domain controller.
Read through all the installation steps before you start the installation process.
After you run the Loadpol.bat file, you can no longer remove the GPOs from the
domain controller by using the Remove option; you must remove the GPOs
manually. For more information about manually removing the GPOs from the
domain controller, see “Removing the Scenarios from the Domain” later in this
document.
To install the GPOs on the domain controller

Run the Loadpol.bat file, which you can find in the same directory as the
installed .msi package (by default, that directory is %ProgramFiles%\Group
Policy Scenarios).
This batch file creates 12 GPOs (a user and computer object for each of the six
scenarios). The GPO names have the following format:
ScenarioName computer settings
ScenarioName user settings
(ScenarioName stands for the name of the actual scenario, such as Kiosk or
TaskStation.)
This batch file installs these GPOs on to the domain controller of the computer
that you are currently logged on to.
Windows 2000 Server White Paper
8
Step 3: Create the OUs to Link to the Scenarios
Create the organization unit (OU) structure you want to use for the scenarios.
For testing, you might want to create a separate OU for each scenario.
Using the Active Directory Users and Computers snap-in, open the Properties
dialog box for each OU and on the Group Policy tab, create links to the
relevant GPOs. Click the Add button and then click the All tab to view the
installed GPOs.
Computers and users in those OUs are now affected by the linked scenario
Group Policy settings.
Caution:
When the Group Policy objects (GPOs) for these scenarios are applied to the
affected clients, they rename the local built-in Administrator and Guest
accounts to %Admin!!! and %Guest!!!, however, the passwords remain
unchanged. Renaming is done to create an extra barrier to potential network
intruders. Renaming these well-known accounts forces the intruder to learn
both the account name and the password to gain access to the network.
After the GPOs are applied, you must use the new account name to log on to
the workstation as local administrator. Be sure to rename the accounts to ones
that are difficult to guess and unique to your environment.
Step 4: Create User and Computer Accounts for Each Scenario
The user and computer objects need to be placed in the newly created OUs
and customized for the specific scenario. For example, you might need to
create a home directory or specify the profile path.
Later in this document are specific instructions for each scenario. For more
information, refer to the “User Account Setup” section of the scenario you want
to install.
Windows 2000 Server White Paper
9
Step 5: Define Environment-Specific Settings
In each scenario, several Group Policy settings need to be customized for the
environment where they are installed. Use the Group Policy snap-in to access
the settings that are listed in Table 3:
Table 3
Group Policy Settings to Customize for Your Environment
Group Policy Setting Location
Comment
Internet Explorer
\User Configuration
connection settings \Windows Settings
\Internet Explorer Maintenance
\Connection
Defines the Internet Explorer connection
settings for the client. Other settings in the
Internet Explorer Maintenance snap-in
should also be considered.
Software settings
Determines if applications are assigned or
published.
\Computer Configuration
\Software Settings
and
\User Configuration
\Software Settings
Scripts
\Computer Configuration
Windows Settings
\Scripts (Startup/Shutdown)
and
\User Configuration
\Windows Settings
\Scripts (Logon/Logoff)
Folder redirection
\User Configuration
\Windows Settings
\Folder Redirection
Defines scripts for Startup/Shutdown and
Logon/Logoff.
Note: If the Command Prompt is disabled
and Disable the Command prompt script
processing is enabled, no scripts can run.
Redirects My Documents and Application
Data.
Step 6: Customize Optional Settings
You can customize other Group Policy settings, such as the ones described in
the "Optional Settings" section of each scenario.
Windows 2000 Server White Paper
10
Advanced Installation
Topics
The following sections apply to all scenarios and explain how to:

Remove the scenarios from the domain controller.

Use the Loadpol.bat and Savepol.bat files more than one time.

Save and move the scenarios to another domain.

Ensure that other applications run smoothly.

Customize your Windows 2000 Setup.

Use the Group Policy loopback processing mode.

Redirect folders to a network location.

Use roaming user profiles.

Restrict access to drives.

Use security settings.

Configure Internet Explorer Group Policy settings.
Removing the Scenarios from the Domain
To remove a scenario from the domain:
1. Open the Microsoft® Management Console (MMC) snap-in, Active
Directory Users and Computers.
2. In the console, right-click the organizational unit that the GPO is linked to.
3. Click Properties, and then click the Group Policy tab.
4. Right-click the GPO to delete, and then click Delete.
5. In the Delete dialog box, click Remove the link and delete the Group
Policy object permanently.
Windows 2000 Server White Paper
11
Running Loadpol or Savepol a Second Time
If you want to run the Loadpol.bat or Savepol.bat files more than once, you
must first delete the destination files and directories that the batch files write to.
For Loadpol.bat, you must delete the scenario GPOs in the directory. For
Savepol.bat, delete the local copy of the GPO template directories. Both batch
files fail if the destination already exists. This prevents you from accidentally
overwriting existing GPOs in Active Directory or deleting data that exists in the
local directories. For example, when using Loadpol.bat, if the GPO directories
in the SYSVOL directory exist, or in the case of Savepol.bat, if the local
directories exist, the batch files fail.
To run Loadpol.bat a second time, remove the installed scenario GPOs from
the domain. (See “Removing the Scenarios from the Domain” earlier in this
document.) You do not need to remove all the scenario GPOs: any that remain
are not overwritten and those that have been deleted are recreated from the
installation defaults. You might receive error messages about not being able to
recreate any scenario GPOs that have not been deleted, and you can safely
ignore these messages.
To run Savepol.bat a second time, first delete the globally unique identifier
(GUID) subfolders from the %Program Files%\Group Policy Scenarios\Policies
folder.
Note:
So that you can identify the GUIDs for each of the scenario GPOs, the default
friendly name is included in the comments alongside each GPO GUID in the
text of Loadpol.bat and Savepol.bat.
Alternatively, create a new folder containing the following files: Sed.exe,
Nltest.exe, Gpbackup.bat, Loadpol.bat, Dsprop.vbs, and Editldif.vbs. Do not
include the GUID subfolders and run Savepol.bat from the new folder to make
new file copies of the GPOs.
Caution:
Use only the Active Directory Users and Computers MMC snap-in to
permanently delete GPOs. Manually deleting files in the SYSVOL directory is
not supported because it leaves an orphaned Group Policy container object in
the directory and can lead to serious problems in Active Directory.
Windows 2000 Server White Paper
12
Saving and Moving the Scenario GPOs to Another Domain
You can use the Savepol.bat file to archive changes made to the scenario
Group Policy objects (GPOs) and to move the archived scenario GPOs to
another domain. When using Savepol.bat to save changes, remember these
points:

Savepol.bat saves the contents of the scenario GPO to the Policies
subdirectory of the local installation directory (by default, the directory is:
%ProgramFiles%\Group Policy Scenarios).

Savepol.bat does not overwrite any existing policy files in the destination
directory.
Note:
Savepol.bat and Loadpol.bat always identify the scenario GPOs by using the
GPO globally unique identifier (GUID), so the following procedures still work
even if you have renamed the GPOs. If the GPOs are renamed, however, you
will find it more difficult to match the GUIDs with the friendly name by using the
comments of Loadpol.bat and Savepol.bat. In such cases, look at the
properties of the GPO in the Active Directory Users and Computers console to
find the GPO GUID.
To copy modified scenarios
After you tailor the scenarios to your environment, you can save them to your
local workstation. Doing this saves them to the same location where you ran
the installation wizard.

Delete the contents of %ProgramFiles%\Group Policy Scenarios\Policies.
Note:
Savepol.bat uses the current directory to create the saved data (by default, the
current directory is: %ProgramFiles%\Group Policy Scenarios\Policies). This is
why you need to delete the contents of the Policies folder before Savepol.bat
copies the changed GPOs.
You might also want to move the scenarios to another domain. Knowing how to
move scenarios is especially useful for transferring customized scenarios from
a test lab to a production environment.
To move the scenarios to another domain
1.
Copy the saved directory structure to a workstation in the destination domain.
2.
Follow the instructions starting at "Step 2: Install the Scenario GPOs on the
Domain Controller" earlier in this document.
Windows 2000 Server White Paper
13
Ensuring Application Compatibility
If you use applications designed to run on Microsoft® Windows NT® version 4.0,
Microsoft® Windows® 95, or Microsoft Windows 98, you might need to modify
some security settings to allow these applications to run properly on
Windows 2000–based computers that use these scenarios. This is because the
security configurations and Group Policy restrictions in Windows 2000 are
much stricter than in previous versions of Microsoft Windows.
You need to test the applications you use before deploying them to users.
Examples of areas where you might need to modify security settings are as
follows:

Allow users Write/Create access in application directories because the
application saves data or user configuration information in its own
directories.

Allow Create and selective Write access to files in the %SystemRoot%
directory because the application might save user configuration information
to this directory.

Allow Write access to parts of the computer registry hive
(HKEY_LOCAL_MACHINE) because the application saves user
configuration information to the computer registry.
Caution
Avoid weakening access controls more than necessary, particularly in
environments that require higher security. Start with the most restrictive setting
and selectively remove restrictions file-by-file until the application works
properly.
Avoid giving Full Control permissions to users—especially on directories.
Change permission should be the maximum permission needed. Full Control
allows the user to change the permissions on the object, potentially removing
access for other valid users or granting access to a user who should not have
access. For example, if the user only needs to create, write to, and delete data
files in a directory, apply the permissions as they appear in Table 4.
Windows 2000 Server White Paper
14
Table 4. Set Permissions to Protect Files
Group
Permission
Users
Create Files
Creator-Owner
Change
Applying the preceding permissions prevents users from modifying or deleting
files that they did not create.
Customizing Your Windows 2000 Setup
This document does not address how to customize the installation of
Windows 2000 Professional. However, when you install Windows 2000
Professional in a highly managed environment, consider the answers to the
following questions:

Which accessories and system tools should you install?

Which language groups do you need to install?

Where should you locate the Documents & Settings (Profiles) folder?
For more information about installing, customizing, and automating the
installation of Windows 2000 Professional, see the Windows® 2000
Professional Resource Kit.
Using Group Policy Loopback Processing Mode
Loopback processing means that the Group Policy settings applied to the user
are taken from both the GPOs that apply to the computer and the GPOs that
apply to the user. This is useful for computers in public places, such as a
computer managed by the Kiosk scenario, where you want the same settings
applied to all users who log on to the computer.
Loopback processing has two modes, replace mode and merge mode:
Replace mode. Replaces the user settings contained in the GPOs that would
have applied to the user, with the user settings contained in the GPOs that
apply to the computer.
Merge mode. Causes the settings contained in the GPOs that apply to the
computer to be processed after the settings contained in the GPOs that apply
to the user. The two groups of settings are combined; however, the settings in
the computer GPOs take priority over the settings in the user GPOs.
Windows 2000 Server White Paper
15
Redirecting Folders
Folder Redirection allows the contents of a folder in the user’s profile to be
redirected to a location on the network. For example, you can move My
Documents, which is typically part of the user’s profile and cached on the local
drive, to a folder in the user’s home directory on the network. Enabling this
feature is useful because My Documents and Application Data often contain
large amounts of data. After Folder Redirection is enabled, these folders are
not copied with the rest of the user profile. This helps speed up log on and log
off time because the contents of these folders are not copied along with the rest
of the user profile.
When Folder Redirection takes place, the destination folders are automatically
created, and security is configured on the destination folders automatically. You
can create these destination folders beforehand (as part of a user creation
script for example) if you want more control over the folder security. What you
need to consider when pre-creating a folder depends on the security setting
configured for that redirected folder.
You can change the security of redirected folders by checking or clearing Grant
the user exclusive rights to foldername, which is located in this path: \User
Configuration\Windows Settings\Folder Redirection\foldername - Settings tab.
For example, if you redirect the My Documents folder to
\\Server1\Docs\%Username%, do not create the %Username% folder in
advance. If the folder exists in advance and the current user is not the owner of
the folder and its contents, the redirection process fails. If the folder does not
exist prior to folder redirection, however, it is created and the user made the
owner of that folder.
Important:
When you use folder redirection, the Best Practice is that you do not create the
network folder in advance.
If you must create the folder in advance, ensure that the user is the owner of
the folder and its contents. To change the ownership of a file or folder, use the
Subinacl.exe utility that is available on the Microsoft Windows 2000 Resource
Kit companion CD.
If Grant the user exclusive rights to foldername is not checked, you can
pre-create the folder. In this case, you need to grant the user Change (Read
and Write) access to the folder.
To learn about the permissions needed on the network directory and to learn
where the redirected folders are located, see "Permissions Needed for Folder
Redirection" later in this document.
Windows 2000 Server White Paper
16
Using Roaming User Profiles
Roaming user profiles should not be placed on network shares that are set for
Offline Files caching. Roaming user profiles have their own caching
mechanism, which can interfere with Offline Files synchronization and can lead
to unexpected behavior and loss of data.
Restricting Access to Drives
You can restrict access to drives by using the Group Policy setting Prevent
access to drives from My Computer. To find this setting, follow the Group
Policy snap-in to this path: \User Configuration\Administrative
Templates\Windows Components\Windows Explorer.
Important:
If the drive that contains the Documents and Settings folder or the
%Systemroot%\Profiles directory cannot be accessed, Windows Explorer
produces an error when the computer starts. The error occurs because
Windows Explorer cannot access the locally stored copy of the user profile. To
avoid this error, do not restrict access to the drive.
Alternately, if you must prevent access to the drive, you can change the
location of the Documents and Settings folder to another drive when you install
Windows 2000. Specify the new location in the Unattend.txt file.
You can use the Group Policy setting Hide these specified drives in My
Computer to hide the drives, which prevents users from viewing the drives, but
allows Windows Explorer to access the user profile files. For more information
about hiding drives by using Group Policy, see "Using Group Policy Settings to
Hide Drives " later in this document.
Windows 2000 Server White Paper
17
Working with Security Settings
Security Policy is a component of Group Policy and includes both computer and
user configurations. The settings are in the Windows Settings container of the
Group Policy snap-in.
Caution:
In all the scenarios, the local administrator and guest accounts are renamed. In
all except the Kiosk scenario, sample logon warnings are configured. Change
these settings as appropriate
Applying Security Templates
Security settings are configured in text files known as security templates.
Windows 2000 includes templates that are preconfigured with security settings
for specific systems, such as workstations, servers, and domain controllers,
and for different levels of security, such as basic, secure, and highly secure.
The templates are located in %Systemroot%\Security\Templates. The basic
templates (Basicwk.inf, Basicsv.inf, and Basicdc.inf) correspond to the default
security settings applied to a newly installed workstation, server, and domain
controller respectively.
You can apply security templates to computers in one of two ways: directly on
the computer or from the domain controller using GPOs. To apply the template
directly to a computer, use the Secedit.exe utility from the Microsoft ® Security
Configuration Tool Set at the command line of the computer.
Although you can configure security settings manually by using the Group
Policy snap-in, you can also import a preexisting template into a GPO.
Computers and users subject to that GPO are then affected by the settings in
the template. Security settings applied by a GPO always override settings
applied with the Secedit.exe utility.
Windows 2000 Server White Paper
18
Configuring Security Settings
The security settings in the scenarios are designed to protect the workstations
from accidental or malicious damage. They prevent unauthorized users from
accessing the system and limit the changes that an authorized user can make
to the system. Unlike the Zero Administration Kit (ZAK) security settings that
you might have used with Windows NT 4.0, these security settings are not
designed to reinforce desktop settings. The ZAK settings included access
controls that prevented user access to many system files and commands. In
these scenarios, however, users can run (if policies permit them to) most
commands and applications although the operating system security prevents
them from doing any damage with the commands.
The security settings for the Kiosk, TaskStation, AppStation, and PCE
scenarios are based on, but not identical to, the high security workstation
template (Hisecws.inf). The security settings for the Low TCO Desktop and
Laptop scenarios are based on the secure workstation template (Securews.inf).
The Low TCO Desktop and Laptop scenarios assume that the workstation is
already configured with the default security for Windows 2000 Professional.
This is the case on a newly installed system (rather than an upgrade), where
Setup configures the workstation with the default security settings contained in
the Basicwk.inf template.
Important
If a workstation that uses the Low TCO Desktop or Laptop scenario has been
upgraded from Windows NT 4.0, Windows 95, or Windows 98, or if its file
system was converted from a file allocation table (FAT) file system to the NTFS
file system, you must apply the default security settings in addition to the
settings contained in the scenario GPO. You can do this by importing the basic
workstation security settings into the computer GPO.
To import basic workstation security settings into the computer GPO
1.
Open the Group Policy snap-in, right-click the Security Settings container
and then click Import Policy.
2.
From the %Systemroot%\Security\Templates directory, click Basicwk.inf.
3.
To prevent the existing current security settings from being overwritten, click
to clear the Clear this database before importing check box.
For more information about using security policies and templates, see the
Security Configuration Tool Set white paper available at:
http://www.microsoft.com/windows2000/library/howitworks/security/
sctoolset.asp
Windows 2000 Server White Paper
19
Configuring Internet Explorer Group Policy Settings
The sample user interface for the Kiosk and TaskStation scenarios is
Microsoft® Internet Explorer version 5, however, you can replace it with another
application. In the other scenarios Internet Explorer 5 is the default browser.
Users are not allowed to run the Internet Explorer configuration wizard and in
most of the scenarios, they are not allowed to modify Internet Explorer settings.
Therefore, you must configure some of the settings in advance.
There are two types of Internet Explorer Group Policy settings, the standard
Windows registry settings and a collection of registry settings and files used to
configure Internet Explorer. The standard settings are located in \Administrative
Templates\Windows Components\Internet Explorer, and the configuration
settings are located in \User Configuration\Windows Settings\Internet Explorer
Maintenance in the Group Policy snap-in.
At a minimum you must configure, Connection Settings located in \User
Configuration\Windows Settings\Internet Explorer Maintenance\Connection in
the Group Policy snap-in.
The Internet Explorer Maintenance settings can be set in two modes: policy
mode or preference mode. Policy mode is enforced and automatically resets
any settings users might change (if they have the appropriate permissions)
when Group Policy is applied.
Note:
Like all registry-based Group Policy settings, Internet Explorer Maintenance
policy mode settings reapply only when the GPO changes.
Unlike most registry-based Group Policy settings, enabling an Internet Explorer
Maintenance setting does not prevent the user from changing that setting.
Preference mode sets initial default values that the user can change, subject to
other Group Policy settings that affect the user. The preference settings are
only applied again when the administrator makes changes to the preference
settings.
Note:
You should give users permissions to change Internet Explorer Group Policy
settings. To allow users to change these preferences, they must be able to
access Internet Options on the Tools menu. You allow users access by
configuring settings in Computer (or User) Configuration\Administrative
Templates\Windows Components\Internet Explorer.
You cannot use policy and preference modes together in a single GPO. If both
modes are needed, two separate GPOs must be used. The scenarios are
Windows 2000 Server White Paper
20
configured using policy mode, so you might need to create an additional GPO
using preference mode for your environment.
Windows 2000 Server White Paper
21
Using and Configuring
Specific Scenarios
The following sections describe how to configure each type of scenario. Refer
to the section describing the type of scenario you want to install.
Use the Excel spreadsheet for each scenario to view and compare the Group
Policy settings of each scenario. The spreadsheets are located in
%ProgramFiles%\Group Policy Scenarios \Docs.
Kiosk Scenario
You can use the Kiosk scenario in a public environment where the computer is
dedicated to running one application. For example, a Kiosk could be located at
an airport to allow passengers to check in and to allow visitors to view flight
departure and arrival times.
The Kiosk computer uses a single log on account and its users are anonymous
to the Kiosk owner. Because the computer is unattended, it is highly secure.
The user interface is simple to operate, with little or no logon procedure. The
user is restricted from changing user and system settings. The system may
automatically reset to a default state at the start of each session. User sessions
are usually anonymous, but the user can log on to an application-specific
account, such as to a Web server application through Internet Explorer.
The Kiosk user cannot save or write data directly to the hard disk. You can use
a disk quota to prevent temporary files from filling the disk and a scheduled
cleanup script to remove temporary files older than a specified number of days.
Kiosk Settings
The workstation is continuously logged on to one account. You can, however,
have a logon procedure for another application, such as logging on to an
MSN™ Hotmail™ account.
When the computer starts, the system automatically logs on by using the Kiosk
user account credentials and the Kiosk application starts automatically. The
Start menu or icons do not display on the desktop. Users cannot customize the
computer or save any data. Applications cannot be added or removed and the
user cannot start any other applications or access the file system.
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 for Windows®. 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.
Windows 2000 Server White Paper
22
LOB applications should not contain “backdoors” that allow users to circumvent
system policies. For example, they should not allow users access to the
command prompt or to applications that allow access to the file system. Ideally,
you should only use applications that adhere to Window 2000 Logo guidelines
and that check for Group Policy settings before giving users access to
prohibited features. You also need to check older applications and make
unavailable any features that allow users to bypass administrative policy.
This scenario uses the AutoLogon feature to automatically log on with a domain
user account. As a result, Kiosk users do not know the user account name or
password. Users are not allowed to change the password and screensavers
are not password protected.
The registry entries Run and RunOnce are disabled in the Kiosk scenario.
Important:
Applications that use the RunOnce entry to finish an installation or upgrade fail
when this Group Policy setting is enabled.
The user is also restricted from:

Viewing or modifying system settings.

Restarting or shutting down the system.

Changing the password of the account or locking the system.

Logging off (see the next section).
User Account Setup for Kiosk
Unless the Kiosk computer is a stand-alone computer, the user account usually
is a domain account. The user account has no special privileges and is a
member of the Domain Users group only.
User Data Settings
There is no requirement for a home directory or a roaming user profile
directory.
User Account Settings
Enable the following settings:

Password never expires.

User cannot change password.
Windows 2000 Server White Paper
23
Security Configuration for Kiosk
The security policies for the Kiosk scenario are based on the high-security
template. Some of the security settings are as follows:

Disables all guest account and anonymous access.

Uses file system access control lists (ACLs) to prohibit changes to files or
folders outside of the user’s profile folder.

Sets registry ACLs to restrict access to the computer registry hive, which
prohibits changes to settings and limits Read access.

Enables restrictive password and account lockout policy settings for the
local accounts.

Enables extensive security logging and system auditing.

Renames the local administrator and guest accounts.

Enables most of the C2 certification security options.

Contains more restrictive access controls in the root directory (Everyone –
Read).
Note:
If the Kiosk computer needs to communicate with computers running
Windows NT LAN Manager, Windows 95, Windows 98, and Windows NT 4.0
Workstation computers running versions earlier than Service Pack 4 (SP4), you
need to modify the following three settings to allow communications to occur.
See the Microsoft Windows 2000 Resource Kit Group Policy Reference for
more details.

Sets NTLM authentication to NTLMv2.

Always encrypts a secure channel (can log on only to domain controllers
running Windows NT 4.0 SP4 or later).

Always signs server message block (SMB) client and server traffic (can
communicate only with computers running Windows NT 4.0 SP4 or later).

Enables network traffic encryption. The computer is assigned the preconfigured policy: IPSec–Client (Respond Only). This encrypts all traffic to
computers requesting IPSec. For greater security, use the Secure Server
policy, which mandates that all network communication be encrypted.

When you use the Secure Server policy, the workstation only
communicates with computers that are IPSec-enabled and always encrypts
the traffic. To enable this setting, all servers with which the client
communicates must be able to negotiate an IPSec association.
Windows 2000 Server White Paper
24
Caution:
Domain Name System (DNS) servers are not ordinarily enabled for IPSec. If
you use the Secure Server IPSec policy, the workstation might be unable to
communicate to DNS servers, which could prevent communication with the
domain controller. If this happens, you cannot reverse the policy because the
new policy cannot be downloaded from the domain controller. To avoid this
situation, place an exclusion for DNS (and other nonencrypted services) in the
IPSec policy before you assign it.
IPSec communication requires that each computer in the IPSec
conversation be mutually authenticated. This means that all servers with which
the Kiosk communicates must be part of the same Active Directory forest as the
workstation, or both the workstation and the server must possess public key
certificates issued by a common certificate authority. This certificate authority
must be configured in the IPSec policy settings of all workstations and servers.
Security Environment for Kiosk
The Kiosk-based computer is typically connected to a network so that it can
access data services. A Kiosk-based computer could also have no network
connection and store all its information locally. For information about setting up
a stand-alone Kiosk-based computer, see "Using the Kiosk Scenario on StandAlone Computers" later in this document.
The Kiosk-based computer is unsupervised and receives infrequent
maintenance. The network connection can be part of a corporate wide area
network (WAN) or a virtual private network (VPN) that uses the Internet.
The recommended configuration for the Kiosk-based computer is as follows:

Configure Kiosk-based computers as members of an external
Windows 2000 domain that is not part of the internal corporate forest. To
simplify management of this domain, you can set up a one-way trust from
the external domain to an internal production domain, so that you can use
production accounts to administer the external domain. The internal
domains should not trust the external domain.

Separate the Kiosk network from the internal corporate network by a
firewall or use a virtual private network (VPN) to securely access the backend data services if you intend to host it on the Internet.

Make the Kiosk user account a domain account.

Securely set local workstation accounts so that only the local administrator
account is active.

Protect the local accounts database by using the System Key utility
(Syskey.exe) to encrypt the account credentials.
Windows 2000 Server White Paper
25

Enable the Group Policy settings shown in Table 5 on all servers and
domain controllers that the Kiosk-based computer accesses:
Table 5
Path
Group Policy Settings for a Kiosk-based Computer
Policy Setting
Local Setting
\Computer
Digitally sign server communication Enabled
Configuration\Windows
(always)
Settings\Security Settings\Local
Policies\Security Options
\Computer
LAN Manager Authentication Level Send NTLMv2 response
Configuration\Windows
only\refuse LM & NTLM
Settings\Security Settings\Local
Policies\Security Options
\Computer
Secure channel: Digitally encrypt or Enabled
Configuration\Windows
sign secure channel data (always)
Settings\Security Settings\Local
Policies\Security Options
Note:
If the Kiosk computer needs to communicate with computers running
Windows NT LAN Manager, Windows 95, Windows 98, and
Windows NT 4.0 Workstation computers running versions earlier than
Service Pack 4 (SP4), you need to modify the previous three Group Policy
settings to allow communications to occur.
Optional Settings for Kiosk
You can use the following optional settings on a Kiosk-based computer.
Reset the Kiosk Settings to the Default State
In some cases, you might want to reset the Kiosk environment to a known
state. Although Kiosk users are prevented from making most changes to a
Kiosk-based computer, a few application-specific settings cannot easily be
managed by using Group Policy settings. For example, if a user resizes the
Windows 2000 Server White Paper
26
Internet Explorer window, the window starts up in that size for all subsequent
users.
You can use a mandatory user profile to reset the Kiosk settings. To do this,
use the following procedure:
1.
Log on to the user account and configure the appropriate settings.
2.
Log off the user account and then log on as an Administrator.
3.
Copy the profile to a local or network directory and then rename the profile
root to OldName.man.
4.
Modify the user object and specify this directory as the profile path.
After you carry out the preceding procedure, if a Kiosk user logs on, the
computer settings reflect the settings defined in the mandatory profile.
By default, the Kiosk user cannot log off. To regularly reset the Kiosk-based
computer to the initial screen, enable the Group Policy setting Automatically
log off users when logon time expires. To find this setting, follow the Group
Policy snap-in to this path: \Computer Configuration\Windows Settings\Security
Settings\Local Policies\Security Options. Specify a time limit for which users
can be logged on. When the time expires, the computer logs off the user
account.
Note
There is a known bug 437647, that when Kerberos is used as the
authentication package, this domain-wide policy is ignored.
Alternatively, schedule a remote restart for the workstations. This forces the
system to reboot and automatically log on to the Kiosk account. The mandatory
profile overwrites any settings that have been changed.
Disk Maintenance
Applications used on a Kiosk-based computer can write data to the disk drive.
To prevent the disk drive from filling up, set a disk quota that leaves at least
100 megabytes free on the system disk.
An application installer package checks for available space based on the quota
limit. The installer cannot proceed if the disk space required is less than the
limit. Therefore, you need to use the disk quota in conjunction with a scheduled
script that removes older temporary files each night. If the Kiosk application
creates a lot of temporary files, the script might also need to execute a disk
defragmentation to maintain system performance.
Windows 2000 Server White Paper
27
Disabling Logoff Capability for Kiosk Users
Kiosk users cannot log off the Kiosk account by pressing Ctrl+Alt+Del or by
using the Start menu. When the computer starts up, it automatically logs on to
the Kiosk account.
Important
In the Kiosk scenario, Kiosk users are prevented from logging off; however in
the settings files that you receive with the Kiosk scenario, logoff capability is
enabled because it makes testing easier. Therefore, before deploying the
scenario, you need to disable the logoff feature.
A disadvantage of disabling the logoff feature is that an administrator cannot
easily log on to the computer because shutdown and restart are disabled: the
administrator cannot restart the computer from the console.
You can use one of the following solutions:
Solution 1:
1.
Restart the computer by doing one of the following:

Execute a remote restart.

Execute a shutdown by turning off the computer while you are still logged
on (this solution is not recommended).
2.
When the computer restarts, hold down the Shift key to bypass the automatic
logon feature and access the standard logon dialog box.
Solution 2:
In this option the logon feature remains enabled. The administrator logs off from
the Kiosk account and then holds down the Shift key to bypass the automatic
logon feature. The disadvantage to this method is that a sophisticated user
could do this, leaving the logon dialog box displayed and rendering the Kiosk
computer useless until it is restarted.
Preventing the Kiosk Application from Closing
If you use Internet Explorer for the user interface, enable the Group Policy
setting File menu: Disable closing the browser and Explorer windows. To
find this setting, follow the Group Policy snap-in to this path: \User
Configuration \Administrative Templates\Windows Components\Internet
Explorer\Browser menus. Using this setting prevents a user from closing
Internet Explorer.
Windows 2000 Server White Paper
28
If you use another application on the Kiosk computer and you cannot disable
the application's exit function, use the Runapp.exe tool that is available on the
Microsoft Windows 2000 Resource Kit companion CD to ensure that the
application automatically restarts if it closes.
Implementing the Kiosk Scenario
The Kiosk scenario is implemented by using the following two GPOs and by
enabling automatic logon as described below:
Kiosk Computer Settings Contains settings for Internet Explorer,
Windows Installer, and system settings.
Kiosk User Settings Contains settings that restrict Internet Explorer and user
settings.
Enabling Automatic Logon Use the following registry entries to implement
automatic logon:
HKEY_LOCAL_MACHINE\Software
\Microsoft
\Windows NT
\CurrentVersion
\Winlogon
AutoAdminLogon
REG_SZ
DefaultUserName
REG_SZ
User name
DefaultPassword
REG_SZ
Password
DefaultDomainName
REG_SZ
1
Domain name
Caution
Do not use a registry editor to edit the registry directly unless you have no
alternative. The registry editors bypass the standard safeguards provided by
administrative tools. These safeguards prevent you from entering conflicting
settings or settings that are likely to degrade performance or damage your
system. Editing the registry directly can have serious, unexpected
consequences that can prevent the system from starting and require that you
reinstall Windows 2000. To configure or customize Windows 2000, use the
programs in Control Panel or Microsoft Management Console (MMC) whenever
possible.
Windows 2000 Server White Paper
29
TaskStation Scenario
A TaskStation-based computer shares the same characteristics as the Kioskbased computer except that users have the ability to save data and some user
settings. TaskStation also allows users to have unique user accounts.
A TaskStation-based computer can be used on a manufacturing floor or as an
order-entry terminal. The computer is dedicated to running one application, and
users log on with unique user accounts.
Different functions may be available to the user through the application, for
example, Internet Explorer could access multiple Web applications or
Microsoft® Excel could run several spreadsheet applications.
The user cannot change most system and user settings. Settings users can
modify should not affect other users.
TaskStation Settings
The settings for this scenario are derived from the Kiosk scenario with the
following exceptions:

Uses roaming user profiles.

Redirects My Documents and Application Data.

Allows minor system changes.
Roaming user profiles are used with a size restriction because the user is
allowed to make changes to the system. My Documents and Application Data
are redirected to a network share. Roaming user profiles ensure that settings
are safely backed up and that they are available to users no matter where in
the network they are logged on.
The workstation uses a password-protected screen saver because the
computer is located in a semi-public location. Users are allowed to lock the
workstation.
User Account Setup for TaskStation
The TaskStation user account is a domain account, a member of the Domain
Users group only with no special privileges.
User Data Settings
Set up the user's home directories on a network server as follows:
Windows 2000 Server White Paper
30
UserID
CachedData
(shared as UserIDCached$)
My Documents
AppData
UncachedData
(shared as UserIDUncached$)
Profile

Replace UserID with the user account name. You can rename the share
and directory names to suit your environment.

Configure UserIDCached$ for automatic caching.

Configure UserIDUncached$ for no caching.
Do not create the network folder in advance. For example, if you plan to
redirect the My Documents folder to \\Server1\Docs\%Username%, do not
create the %Username% folder in advance. If the folder exists in advance and
the current user is not the owner of the folder and its contents, the redirection
process fails. For more information about folder redirection, see “Redirecting
Folders” earlier in this document.
If you must create the folder in advance, ensure that the user is the owner of
the folder and its contents. To set ownership, use the Subinacl.exe tool that is
available on the Microsoft Windows 2000 Resource Kit companion CD. Also
see “Permissions Needed for Folder Redirection” later in this document to learn
about the permissions needed on the server shares where the folders are
redirected.
User Account Settings
Set the user profile path to:
\\HomeServer.dom\UserIDUncached$\Profile.
Replace HomeServer.dom with the fully qualified name of the user’s home
server.
Security Configuration for TaskStation
The security policies are identical to the Kiosk scenario, which uses the highsecurity workstation template. The key differences are:

Administrator and guest account are renamed.

Logon message is enabled.
Windows 2000 Server White Paper
31

Mandatory digital signing of SMB traffic is disabled.

Mandatory encryption of secure channel communications is disabled.
LAN Manager Authentication Level is not specified.

More restrictive access controls are applied to the root directory (Everyone
– Read).
The latter three settings are configured for compatibility in case servers do not
support these settings. If all the servers used by the client are Windows NT 4.0
SP4 or later, you can enable these settings.
The security environment is different from the Kiosk scenario. TaskStation
computers are usually on company premises and connected to the internal
corporate network. Each user has a domain account.
Optional Settings for TaskStation
The default setting for the TaskStation is to remove cached profiles after users
log off. This improves system security and prevents old cached profiles from
consuming disk space, which is important if the workstation supports a large
number of users. You might have situations where it is better to keep cached
copies of profiles, such as where you have a small number of users using the
system, where there is poor network connectivity to the home directory file
server, or where security is not critical.
Implementing the TaskStation Scenario
The TaskStation scenario is implemented with two Group Policy objects:
TaskStation Computer Settings Contains settings for Internet Explorer,
Windows Installer and System settings.
TaskStation User Settings Contains settings that restrict Internet Explorer and
remaining user environment settings.
When Internet Explorer is used as the user interface, use the Group Policy
setting File menu: Disable closing the browser and Explorer windows to
prevent users from closing Internet Explorer. If you are using other applications
for the user interface, use the RunApp.exe utility, which you can obtain from the
Microsoft Windows 2000 Server Resource Kit companion CD, to prevent the
application from being closed.
Windows 2000 Server White Paper
32
AppStation Scenario
The AppStation configuration is identical to the TaskStation scenario except
that more applications are available to users. Usually, applications are allocated
to users based on their job role. An AppStation is typically found in a marketing
or finance department. In these areas, users require only a specific and limited
set of three to five productivity and in-house applications to do their job.
AppStation Settings
The AppStation scenario is very similar to the TaskStation scenario, but it has
multiple applications. The settings are still very restricted, but you can run more
than one application and a simplified Start menu is available. Users cannot
make extensive customizations, other than a limited number of applicationspecific settings, nor can they add or remove applications.
When the user logs on, applications assigned to the user are available. Shared
applications are assigned to the computer. Applications specific to a user are
assigned to individual users. ACLs on the GPOs are used to filter Group Policy
settings within the same OU.
Note:
Published applications are not supported in this scenario.
The user accounts are configured as standard roaming user profiles. The My
Documents and Application Data folders are redirected from the profile to
folders in the user’s home share. These folders are configured with automatic
caching for performance enhancement. AppStations are not usually shared by
a large number of users, so cached profiles are not removed each time a user
logs off. However, they have a fixed profile quota so that large amounts of data
can not accumulate in user profiles.
User Account Setup for AppStation
The AppStation user account is a domain account, a member of the Domain
Users group only with no special privileges.
User Data Settings
Set up the users’ home directories on a network server as follows:
Windows 2000 Server White Paper
33
UserID
CachedData
shared as UserIDCached$
My Documents
AppData
UncachedData
shared as UserIDUncached$
Profile

Replace UserID with the user account name. You can rename the share
and directory names to suit your environment.

Configure the UserIDCached$ for automatic caching.

Configure the UserIDUncached$ for no caching.
Do not create the network folder in advance. For example, if you plan to
redirect the My Documents folder to \\Server1\Docs\%Username%, do not
create the %Username% folder in advance. If the folder exists in advance and
the current user is not the owner of the folder and its contents, the redirection
process fails. For more information about folder redirection, see “Redirecting
Folders” earlier in this document.
If you must create the folder in advance, ensure that the user is the owner of
the folder and its contents. To set ownership, use the Subinacl.exe file, which is
available on the Microsoft Windows 2000 Resource Kit companion CD. Also
see “Permissions Needed for Folder Redirection” later in this document to learn
about the permissions needed on the server shares where the folders are
redirected.
User Account Settings
Set the user profile path to:
\\HomeServer.dom\UserIDUncached$\Profile
Replace HomeServer.dom with the fully qualified name of the user’s home
server.
Security Configuration for AppStation
The security policies are identical to the Kiosk scenario, which uses the highsecurity workstation template. The key differences are:

Administrator and Guest account are renamed.

Logon message is enabled.
Windows 2000 Server White Paper
34

Mandatory digital signing of SMB traffic is disabled.

Mandatory encryption of secure channel communications is disabled.

LAN Manager Authentication Level is not specified.

More restrictive access controls applied to the root directory (Everyone –
Read).
The latter three settings are configured for compatibility in case servers do not
support these settings. If all the servers used by the client are Windows NT 4.0
SP4 or later, you can enable these settings.
As with the TaskStation, computers are usually on company premises and
connected to the internal corporate network. Each user has a domain account.
Optional Settings for AppStation
The applications you make available determine how you configure the Start
menu. You might want to remove the Windows 2000 Accessories from the Start
menu when you install Windows 2000. You can configure this when you install
Windows 2000 or by customizing the Start menu and removing user Read and
Execute permissions from the application executable files.
You can choose to include or exclude Windows Accessories by customizing
your setup with an answer file (Unattend.txt) when you automatically install
Windows 2000. Remove or retain the entry for each accessory in the
[Components] section of the file. For more information about using an
Unattend.txt file, see the Microsoft Windows 2000 Professional Resource Kit.
Use a logon script, such as printer driver mappings and setting environment
variables, if your applications require additional per-user configuration settings.
If users have access to Internet Explorer as a standard browser, you might
need to add many defaults or mandatory settings, such as search pages,
Favorites, link bar, and custom toolbars. You configure these settings in the
Internet Explorer Maintenance section of the Group Policy snap-in.
Implementing the AppStation Scenario
The AppStation scenario is implemented as two different Group Policy objects:
AppStation Computer Settings Contains settings for Internet Explorer,
Windows Installer and System settings. Can also contain settings for assigned
applications.
AppStation User Settings Contains settings that restrict Internet Explorer and
remaining user settings. Can also contain settings for assigned applications
Windows 2000 Server White Paper
35
Public Computing Environment Scenario
The PCE scenario is designed for public shared access computers such as
those in a university library or laboratory. Public computing environments allow
users more freedom to modify settings and install applications than the
previous scenarios.
In a university lab, users need to customize some settings, such as the desktop
wallpaper and color scheme. They are not given permission to control or
configure hardware or connection settings. In this semipublic environment,
security is tightly controlled.
A specific set of applications is always installed on the computer, but users can
add applications from a select list when they need them. Preinstalled
applications can be word processor and spreadsheet applications, or a
development environment. Users can add additional applications, such as
computer-aided design (CAD) and statistics applications, or custom
applications that provide access to grades or class schedules. Students can
choose to add or remove these applications at any time.
Public Computing Environment Settings
In this scenario, the user is allowed more freedom to customize the computer.
For example:

The user can modify Internet Explorer and the desktop.

Control Panel is available with approved items.

The Run command from the Start menu and the Command Prompt are
disabled.

The user can run assigned or published applications.

Hardware devices cannot be added, removed, or modified.
Roaming user profiles are implemented with My Documents and Application
Data redirected to a network folder. In this environment, turnover is high and a
user is unlikely to return to the same computer day after day. Therefore, user
settings data that are cached on the computer are removed after the user logs
off (assuming the settings were saved to the user’s home directory on a file
server). Users can log on if their network profile is not available. In this case,
the user receives a new profile based on the default profile.
A wide variety of applications are available to be installed by using Group
Policy publishing or a similar mechanism. Due to the potential security risks,
users cannot install from a disk, CD ROM, or Internet location. To conserve
disk space on the workstation, most applications should be configured to run
Windows 2000 Server White Paper
36
from a network server. Start menu shortcuts and registry settings are
configured when the user selects an application to install, but most of the
application’s files remain on the server. The share(s) that stores the
applications can be configured for automatic caching so that application files
are cached at the workstation on first use.
A set of core applications are assigned to the computer and are available to all
users who log on. You can use other GPOs to publish or assign additional
applications by using organizational units and security group filtering to direct
the applications to the appropriate users and computers.
User Account Setup for PCE
The PCE user account is a domain account, a member of the Domain Users
group only with no special privileges.
User Data Settings
Set up the users’ home directories on a network server as follows:
UserID
CachedData
shared as UserIDCached$
My Documents
AppData
UncachedData
shared as UserIDUncached$
Profile

Replace UserID with the user account name. You can rename the share
and directory names to suit your environment.

Configure the UserIDCached$ for automatic caching.

Configure the UserIDUncached$ for no caching.
Do not create the network folder in advance. For example, if you plan to
redirect the My Documents folder to \\Server1\Docs\%Username%, do not
create the %Username% folder in advance. If the folder exists in advance and
the current user is not the owner of the folder and its contents, the redirection
process fails. For more information about folder redirection, see “Redirecting
Folders” earlier in this document.
If you must create the folder in advance, ensure that the user is the owner of
the folder and its contents. To set ownership, use the Subinacl.exe file, which is
available on the Microsoft Windows 2000 Resource Kit companion CD. Also
see “Permissions Needed for Folder Redirection” later in this document to learn
Windows 2000 Server White Paper
37
about the permissions needed on the server shares where the folders are
redirected.
User Account Settings
Set the user profile path to:
\\HomeServer.dom\UserIDUncached$\Profile
Replace HomeServer.dom with the fully qualified name of the user’s home
server.
Security Configuration for PCE
The security policies are identical to the Kiosk scenario, which uses the highsecurity workstation template. The key differences are:

Administrator and guest accounts are renamed.

Logon message is enabled.

Mandatory digital signing of SMB traffic is disabled.

Mandatory encryption of secure channel communications is disabled.

LAN Manager Authentication Level is not specified.

More restrictive access controls applied to the root directory (Everyone –
Read).
The latter three settings are configured for compatibility in case servers do not
support these settings. If all the servers used by the client are Windows NT 4.0
SP4 or later, you can enable these settings.
As with the TaskStation scenario, these computers are usually on company
premises and connected to the internal corporate network. Each user has a
domain account.
Optional Settings for PCE
If you need to, you can enable the Command Prompt and the Run command
for users. However, if you do this, the user can run any application on the
workstation by executing from Command Prompt even if the Run only allowed
Windows applications Group Policy setting is enabled.
By default, the user is restricted from installing applications that require
administrative rights on the local workstations (other than published and
assigned applications). Some users, however, might need to install .msi-based
applications from non-approved sources. You can allow this privilege by
enabling the Group Policy setting Always install with elevated privileges in
Windows 2000 Server White Paper
38
\Computer (and User) Configuration\Administrative Templates\Windows
Components\Windows Installer.
Enabling the policy elevates privileges to all .msi installations, including those
initiated by a user from CD or floppy disk. A user can then install any .msibased application without having administrator rights on the workstation.
Caution:
Use caution when enabling this setting because of the risk of introducing
viruses and of software license violation.
Implementing the PCE Scenario
The PCE scenario is implemented, as a minimum, in two different OU trees
with the following GPOs linked appropriately:
PCE Computer settings Contains settings for Internet Explorer, Windows
Installer and System settings. Can also contain assigned and published
applications.
PCE User settings Contains settings that restrict Internet Explorer and
remaining user settings. Can also contain assigned and published applications.
Windows 2000 Server White Paper
39
Low TCO Desktop Scenario
In any environment, including one that is very lightly managed, there is a select
list of settings and configurations that make it easier and simpler to manage the
desktop. These settings can contribute to reducing help desk costs and user
downtime. This configuration contains settings that you can use to lower the
TCO of a desktop for any level of user or application.
This scenario is a less-managed version of the AppStation scenario. The Low
TCO Desktop scenario would typically be used in an organization where a
tightly managed desktop was unacceptable to the user community or where the
management of desktops was highly delegated. The user is permitted to install
approved applications (made available by the administrator) and make
extensive customizations of applications and the desktop environment. Users
can be power users or developers who typically require a lot of control over
their computer.
Low TCO Desktop Settings
This scenario is the least restrictive scenario. These Group Policy settings
manage:
Potentially harmful configuration settings, such as the ability to add or disable
hardware devices.
System or user environment settings, such as the location of the My Documents
folder or the name of your Web home page.
The Low TCO Desktop scenario ensures that workstations allow users to
change most settings that affect them and prevents users from making harmful
system changes. Hence, using this scenario can reduce unnecessary support
calls.
User Account Setup for Low TCO Desktop
The user account is a domain account; it needs no special privileges and is a
member of the Domain Users group only.
User Data Settings
Set up the users’ home directories on a network server as follows:
Windows 2000 Server White Paper
40
UserID
CachedData
shared as UserIDCached$
My Documents
AppData
UncachedData
shared as UserIDUncached$
Profile

Replace UserID with the user’s account name. The names of the shares
and directories are not significant and can be renamed to suit local naming
conventions.

Configure the UserIDCached$ share for automatic caching.

Configure the UserIDUncached$ share for no caching.
Do not create the network folder in advance. For example, if you plan to
redirect the My Documents folder to \\Server1\Docs\%Username%, do not
create the %Username% folder in advance. If the folder exists in advance and
the current user is not the owner of the folder and its contents, the redirection
process fails. For more information about folder redirection, see “Redirecting
Folders” earlier in this document.
If you must create the folder in advance, ensure that the user is the owner of
the folder and its contents. To set ownership, use the Subinacl.exe file, which is
available on the Microsoft Windows 2000 Resource Kit companion CD. Also
see “Permissions Needed for Folder Redirection” later in this document to learn
about the permissions needed on the server shares where the folders are
redirected.
User Account Settings
Set the user profile path to:
\\HomeServer.dom\UserIDUncached$\Profile
Replace HomeServer.dom with the fully qualified name of the user’s home
server.
Security Configuration for Low TCO Desktop
The security policies are similar to the previous three scenarios but security has
been lowered slightly in favor of greater application compatibility and greater
user capability (if required). The settings are based on the high-security
workstation template. The key differences from this template are:
Windows 2000 Server White Paper
41

Administrator and guest account are renamed.

Logon message is enabled.

Users can install printer drivers.

Event log settings are configured for larger application and system logs.

More restrictive access controls are applied to the root directory (Everyone
– Read).
Part of the reason for using the Secure Workstation (Securews.inf) template
rather than the High Secure Workstation (Hisecws.inf), which is used in most of
the other scenarios, is that it gives greater privileges to the power users group
(although not significantly more to the users group). This means that if users
need larger amounts of control over the system, you can make them members
of the local power users group.
As with the previous scenarios, the workstations are usually on company
premises and connected by means of the internal corporate network. Each user
has an individual domain account.
Optional Settings for Low TCO Desktop
In the Low TCO Desktop scenario, users are restricted from installing
applications that require administrative rights on local workstations, such as
applications that the administrator has not published or assigned. Some users,
however, might need to install .msi-based applications from non-approved
sources. You can allow this privilege by enabling Always install with elevated
privileges. To configure this setting, follow the Group Policy snap-in to
\Computer (or User) Configuration\Administrative Templates\Windows
Components\Windows Installer.
Enabling the policy elevates privileges to all .msi files, even those initiated by a
user from a CD or floppy disk. A user can effectively install any .msi file without
having administrative rights to the workstation.
Caution:
Use caution when enabling this setting because of the risk of introducing
viruses and of software license violation.
Under usual circumstances, the user does not require access to Network and
Dial-up Connections, but you can optionally enable the settings that follow if
required:

Enable deletion of remote access Connections (belonging to the user).
Windows 2000 Server White Paper
42

Enable connecting and disconnecting a remote access connection.

Allow access to current user's remote access connection properties.

Enable renaming of connections belonging to the current user.

Display and enable the Network Connection wizard.
The administrator can also use the Preference mode of Internet Explorer
Maintenance to specify defaults but still allow users to make changes to those
preferences as they require (for example, Home and Search Pages).
Note:
You must grant users access to make their changes. To set user access, use
the Group Policy snap-in, and go to \ User Congfiguration \Administrative
Templates\Windows Components\Internet Explorer.
Implementing the Low TCO Desktop Scenario
The Low TCO scenario is implemented as two different Group Policy objects:
Low TCO Desktop Computer Settings Contains settings for Internet Explorer,
Windows Installer, and System settings. Can also contain assigned
applications.
Low TCO Desktop User Settings Contains settings that restrict Internet Explorer
and remaining user settings. Can also contain published applications.
Windows 2000 Server White Paper
43
Laptop Scenario
Laptop users fall into two main categories:

The first is the user who spends the majority of time away from the office
(or perhaps has no fixed office). This user (described as a “Road Warrior”
by GartnerGroup and others) usually connects over low-speed dial-up links
although the user might have occasional access to high-speed network
links to their logon server, and data and application delivery servers.

Those in the second user type spend most of their time in an office but
occasionally work at home or in another location. The majority of their
network access is at LAN-speed but they occasionally use Routing and
Remote Access service or remote network links.
Despite the apparent differences between these two types, you can
accommodate them with a single configuration.
Laptop users might log on to their computer while connected or disconnected
and still expect transparent access to all (or at least the most critical parts of)
their data and settings. They might also roam to desktop computers while their
laptop is in use, for example, to read mail while they are in a remote office.
Therefore, be sure the configuration does not conflict with this usage. Finally,
users frequently disconnect their computer from the network without logging off
and shutting down (this is more likely with Windows 2000 hibernate and
standby facilities).
Note:
If users are likely to disconnect from the network without logging off (by
hibernating, for example), it is recommended that you set Offline Files to
periodically synchronize in the background. If Offline Files is set to synchronize
only when users log off, users’ files might not be up-to-date.
The profile settings of laptop users are typically only used from their laptops.
Roaming user profiles are needed to give some measure of protection against
laptop failure or loss (at least some of their settings are saved on their home
network server) and to allow roaming to desktop computers. Users do not
typically roam between laptops other than when their computer has been
replaced.
Data can fall into three categories (usually all three categories are used):

Data that resides on a network server and that users want access to while
not connected to the network. This data is usually owned by users (for
example, their home directory) but shared data can also be stored on the
local computer.
Windows 2000 Server White Paper
44

Data that resides only on the network server (either not needed offline or
volatile shared data that is inappropriate for storing offline).

Data that resides only on the laptop local disk. Examples are policy
manuals or other read-only items or large document sets that are needed
offline by the user but the performance overhead of synchronizing
precludes storing them on a file server. (In this case, a suitable backup
mechanism is definitely needed.) Other examples might be large database
files or other data items that have their own synchronization mechanism,
such as the offline storage feature in Microsoft® Outlook®.
Laptop Settings
Laptop users are often expected to do much of their own computer support
because on-site support is not readily available. For this reason, they usually
have more privileges than equivalent users on a desktop computer (for
example, they can install printers).
Laptop users, however, must be restricted from making system changes that
might damage or disable their systems. For example, restrict laptop users from
altering certain Internet Explorer settings, modifying the Start menu, and adding
unapproved hardware devices. Although these users might need access to
some of the MMC administration snap-ins, make available only a restricted set.
Application installation (particularly for road warriors) is more likely to be
initiated by the user than pushed by the administrator because of the
unpredictability of when the user can connect to a high-speed network. For
users who regularly visit the office, administratively published applications can
be installed during the visit. Users who are in an office might infrequently need
special privileges to allow them to install applications from CD ROM. You can
allow this privilege by enabling Always install with elevated privileges, which
is in the Group Policy snap-in under \User (and Computer)
Configuration\Administrative Templates\Windows Components\Windows
Installer.
Laptop users can connect to and disconnect from remote access connections
as defined under Network and Dial-up Connections.
These are the minimum settings required for this scenario, but you can expand
them as mentioned in the optional settings.
User Account Setup for Laptop
The Laptop user account is a domain account; it needs no special privileges
and is a member of the Domain Users group only.
User Data Settings
Set up the users’ home directories on a network server as follows:
Windows 2000 Server White Paper
45
UserID
CachedData
shared as UserIDCached$
My Documents
AppData
UncachedData
shared as UserIDUncached$
Profile
Network Documents
(optional)

Replace UserID with the user’s account name. The names of the shares
and directories are not significant and can be renamed to suit local naming
conventions.

Configure the UserIDCached$ share for automatic caching.

Configure the UserIDUncached$ share for no caching.

On the local computer, create a folder to store any documents that do not
require backup or synchronization with a file server copy:
C:\Local Documents

Create shortcuts to the Network Documents (this shortcut is optional) and
Local Documents folders in the My Documents folder.
Note:
You can create shortcuts by using Windows Explorer and then copy them to
each user’s My Documents folder as part of the account setup, in a logon script
or by using an assigned .msi package. You can script the shortcut creation by
using the WshShell.CreateShortcut method in Windows Script Host.
The Network Documents folder is optional. Its purpose is to hold documents
that the user does not want to store on the local computer. This would typically
be archive data.
This data could also be held in the My Documents folder. In this case, the
caching procedure would only store the most recently used documents and
leave older documents on the server. In some cases it might be better to
separate the two data sets so that large, unwanted files are not accidentally
stored to the local computer (this might happen if the user selects Make
available offline for a whole folder tree in My Documents).
Do not create the network folder in advance. For example, if you plan to
redirect the My Documents folder to \\Server1\Docs\%Username%, do not
create the %Username% folder in advance. If the folder exists in advance and
Windows 2000 Server White Paper
46
the current user is not the owner of the folder and its contents, the redirection
process fails. For more information about folder redirection, see “Redirecting
Folders” earlier in this document.
If you must create the folder in advance, ensure that the user is the owner of
the folder and its contents. To set ownership, use the Subinacl.exe file, which is
available on the Microsoft Windows 2000 Resource Kit companion CD. Also
see “Permissions Needed for Folder Redirection” later in this document to learn
about the permissions needed on the server shares where the folders are
redirected.
User Account Settings
Set the user profile path to:
\\HomeServer.dom\UserIDUncached$\Profile
Replace HomeServer.dom with the fully qualified name of the user’s home
server.
Security Configuration for Laptop
The security configuration is almost identical to the Low TCO Desktop scenario.
It is based on the Secure Workstation (Securews.inf) template with the
following differences:

Administrator and guest accounts are renamed.

Logon message is enabled.

More restrictive access controls are applied to the root directory (Everyone
– Read).
Some laptop users who are away from the office for long periods of time might
be expected to be part-time administrators. In such cases, make these users
members of the local Power Users group. This allows them to write to parts of
the file system and gives them a number of extra privileges, such as creating
shares, doing backup and restore, and setting the system time.
In some cases, you might need to give these laptop users local administrator
privileges, although this should be done with caution because a local
administrator has the ability to circumvent Group Policy settings put in place by
the domain administrator.
Optional Settings for Laptop
Laptop users who usually work outside the office might require more flexibility
to configure their systems. This flexibility especially applies to connectivity
settings, as users might need to configure virtual private network (VPN)
Windows 2000 Server White Paper
47
connections by using an Internet service provider (ISP). If such requirements
exist, enable the following settings:

Enable deletion of remote access connections (belonging to the user).

Enable renaming of connections belonging to the current user.

Display and enable the Network Connection wizard.

Allow access to the current user's remote access connection properties.

Enable access to the properties of the components of a local area network
(LAN) connection.

Enable access to the properties of the components of a remote access
connection.

Display and enable the Network Connection wizard.

Enable status statistics for an active connection.

Enable the Dial-up Preferences item on the Advanced menu.
In the Laptop scenario, consider using a separate Group Policy object for
“Road Warriors” (as described previously) and modify the settings as shown in
Table 6:
Table 6
Modifying Group Policy Settings for “Road Warriors”
Policy Setting
Path
Comment
Slow network connection
timeout for user profiles
\Computer Configuration
\Administrative Templates
\System\Logon
Defines a slow connection for roaming
user profiles.
Wait for remote user profile \Computer Configuration
\Administrative Templates
\System\Logon
Directs the system to wait for the remote
copy of the roaming user profile to load,
even when loading is slow.
Prompt user when slow
link is detected
\Computer Configuration
\Administrative Templates
\System\Logon
Notifies users when their roaming profile
is slow to load.
Timeout for dialog boxes
\Computer Configuration
\Administrative Templates
\System\Logon
Determines how long the system waits for
a user response before it uses a default
value.
Windows 2000 Server White Paper
48
If users are expected to install or reinstall applications while they are away from
the office, you might need to give them additional privileges. The Group Policy
settings to configure are shown in Table 7.
Table 7
Enabling Laptop Users to Install Applications
Policy Setting
Path
Comment
Always install with elevated
privileges
\User Configuration
\Administrative Templates
\Windows Components
\Windows Installer
Click Enabled.
Always install with elevated
privileges
\Computer Configuration
\Administrative Templates
\Windows Components
\Windows Installer
Click Enabled.
Hide the “Add a program from \User Configuration
CD-ROM or floppy disk”
\Administrative Templates
option
\Control Panel
\Add/Remove Programs
Click Disabled or Not Configured.
If laptop users must back up their system locally, you need to give them the
rights to do so. You can make them members of the Backup Operators or
Power Users Group. Although much of their data is synchronized with a
network server (by means of Offline Files), this is not a sufficient backup
solution. Users might have data and configuration information stored locally that
is not synchronized, for example, a database application that stores its
database in the application folder in Program Files.
Implementing the Laptop Scenario
The Laptop scenario is implemented as two different Group Policy objects:
Laptop Computer Settings Contains settings for Internet Explorer,
Windows Installer, system settings, and assigned applications.
Laptop User Settings Contains settings that restrict Internet Explorer and
remaining user settings.
Windows 2000 Server White Paper
49
Special Topics
Use the following sections to learn more about:

Upgrading to Windows 2000 from Windows NT 4.0–based workstations
that use the Zero Administration Kit (ZAK).

Known issues related to using the scenarios.

Using the Kiosk scenario on stand-alone workstations (setting up the Kiosk
Scenario on computers that are not connected to a Windows 2000 Server–
based network).

Utilities and support tools.

Desktop management classifications defined by the GartnerGroup.

Procedures used to hide drives with Group Policy settings.

Permissions used for Folder Redirection.
Windows 2000 Server White Paper
50
Upgrading Workstations that Use ZAK and Windows NT 4.0
Upgrading Windows NT 4.0–based workstations to Windows 2000 requires
special considerations if you have used system policies. This is the case if you
used a Zero Administration Kit (ZAK) for Windows NT 4.0.
There are three main components of migration from a Windows NT 4.0 Zero
Administration Kit environment:

Workstation upgrade.

User settings migration.

System policy settings migration.
Workstation Upgrade
If you currently use system policies and you want to upgrade a
Windows NT 4.0–based computer to Windows 2000 (rather than do a clean
install), be aware of these potential issues:

System policy “tattooing” of settings in the computer registry hive.

Nonstandard access controls on the file system and registry.
User Migration
If you are migrating a user’s Windows NT 4.0 profile to a Windows 2000
environment, there are a number of potential issues. Profile migration is
probably more likely if you are using roaming user profiles. The considerations
here are:

System policy “tattooing” of settings in the user registry hive.

Nonstandard access controls on the user registry (although this is less
common than custom ACLs being set on the computer registry).
System Policy Settings Migration
You can migrate the customized ZAK policy settings to a Windows 2000 Group
Policy-based environment. Although it is strongly recommended that you set
new policy settings, it is possible to migrate some or all settings into a
Windows 2000 domain. The considerations here are:

Migrating the NTconfig.pol settings to one or more Group Policy objects.

Migrating other configuration settings (for example, file system access
controls in a script).
Windows 2000 Server White Paper
51
Note:
File system access controls might have been customized for certain
applications. If you plan to use these applications with Windows 2000, you
need to migrate the access control settings into the Windows 2000 Group
Policy security settings. Table 8 provides an outline for doing this, however, this
table provides only a suggested strategy. The implementation details for these
procedures are outside the scope of this paper.
Not all these options are required in most cases. It might be simpler to set new
Group Policy settings rather than attempt to migrate them.
Table 8 provides a strategy for migrating different elements of Windows NT 4.0.
Table 8
Strategy for Migrating Elements of Windows NT 4.0
Windows NT 4.0 Component
Windows NT 4.0
Workstation Upgrade
Cleaning up System Policy
settings
Migration Procedure
Analyze settings contained in
NTconfig.pol.
Create a registry import file to remove
settings applicable to that computer.
Import the registry import file to the
computer registry during the upgrade
process.
Cleaning up access control lists
(ACLs)
Use Secedit.exe to apply a default
security template to system.
– or –
Apply the scenario policies, which
overwrite previous ACLs for most of
the file system (%Systemroot%,
Program Files, and others).
Windows NT 4.0 User
Migration
Cleaning up System Policy
settings
Follow the same procedure that is
shown for “Windows NT 4.0
Workstation upgrade - Cleaning up
System Policy settings.”
Windows 2000 Server White Paper
52
Zero Administration Kit System Policy settings
(ZAK)/System Policy
settings migration
Use Migpol.exe to migrate settings to
Group Policy objects.
Create OUs or Group Policy filtering
groups to replace the
Windows NT 4.0 System Policy
groups that were used to filter policy
settings.
Other settings – file system ACLs. Use the Windows NT 4.0 ZAK
Acls.cmd script to apply security to a
system (or use a modified version if
you have customized this script).
Use the Security Configuration and
Analysis MMC snap-in to analyze the
security settings.
Save these settings as a template
file.
If necessary, edit this template file to
remove unwanted settings.
Import the template into a Group
Policy object.
Windows 2000 Server White Paper
53
Consider using one of the registry tools, Reg.exe or Regini.exe, which allow a
scripted approach to writing registry entries. They are available on the Microsoft
Windows 2000 operating system CD and the Microsoft Windows 2000
Resource Kit companion CD respectively.
Caution:
Do not use this registry tool to edit the registry unless you have no alternative.
The registry editors bypass the standard safeguards provided by administrative
tools. These safeguards prevent you from entering conflicting settings or
settings that are likely to degrade performance or damage your system. Editing
the registry directly can have serious, unexpected consequences that can
prevent the system from starting and require that you reinstall Windows 2000.
To configure or customize Windows 2000, use the programs in Control Panel or
Microsoft Management Console (MMC) whenever possible.
Windows 2000 Server White Paper
54
Known Issues Related to Using the Scenarios
The following known issues and workarounds exist with regard to creating
these scenarios:
Cannot Specify a Screen Saver Time-out
There is currently no Group Policy setting to specify a screen saver time-out.
To define one, use one of the following methods:

Create a custom screen saver that has the time-out hard-coded into the
.scr file.

Set the screen saver time-out in the user’s registry. You can set this in the
default user profile for users who do not yet have a profile by using a logon
script or by using a Windows NT 4.0 preference setting (you need to create
a custom .adm template file to set this). Set the value of the following
registry entry:
HKEY_CURRENT_USER\Control Panel\Desktop\ ScreenSaveTimeOut
(REG_SZ) = Time in seconds
Note:
Unlike standard policy settings, this setting is not secure and can be changed
by the user with the appropriate tools. To prevent the user from changing the
setting, be sure to enable the Hide Screen Saver setting in User\Control
Panel\Display. The user can still change it, however, by editing the registry. If
this setting is set by using Group Policy, those settings persist after the GPO
containing the setting is no longer in scope for the targeted user.
Cannot Restrict Accessibility Options
There are currently no Group Policy settings for restricting Accessibility options.
Workaround: Modify the Start menu or use a custom shell, such as
Internet Explorer.
Cannot Restrict System Tools
There are currently no Group Policy settings to restrict System Tools, such as
Disk Cleanup. Workaround: Modify the Start menu or use a custom shell (like
Internet Explorer).
Cannot Hide Synchronization Manager
Synchronization Manager (in the Accessories menu) is visible even when the
Group Policy setting prevents the configuration of offline folders. Workaround:
Modify the Start menu or use a custom shell, such as Internet Explorer.
Windows 2000 Server White Paper
55
Cannot Disable Folder Options
There is currently no Group Policy setting to disable Folder Options in the
Windows Explorer View menu. Workaround: None known.
Cannot Restrict Changes to Sounds and Multimedia
Changes are allowed on Sounds and Multimedia when users select the
Speaker icon in System Tray. Workaround: Disable the speaker from System
Tray to prevent access to this page.
Cannot Set Internet Explorer Caching Size/Disabling Caching
No Group Policy setting exists for setting the Internet Explorer caching
size/disabling caching. Workaround: Remove page caching as a preference in
the Microsoft® Internet Explorer Administration Kit (IEAK).
Cannot Remove Internet Explorer History
No Group Policy setting exists for removing Internet Explorer history; however,
a workaround exists. To completely prevent history saving (for example, when
using the Kiosk scenario, to prevent users from seeing the pages visited by
other users), change permissions on the history folders in the user’s profile.
Specifically, deny access to a security group that contains the Kiosk user in the
following directories:
%userprofilepath%\Local Settings\History
%userprofilepath%\LocalSettings\History.IE5
If you intend to use Group Policy to apply this access control setting, you need
to consider the following points:

The History directory must exist on the computer that you use to create the
security Group Policy setting (\Computer Configuration\Windows
Settings\Security Settings\File System). This is because the local file
system is used to find the directory that you want to set access controls on.

File system security settings are configured as computer settings. This
setting must be made in a GPO that applies to the computer that you are
trying to configure.

Because this is a computer setting, the %UserprofilePath% environment
variable is not correctly set when the policy is applied. For that reason, you
must create the settings with explicit paths to the History directory. This is
an option for the Kiosk scenario only. Because only one user account logs
on to the Kiosk, you can predict what the path to the profile directories will
be. This is obviously much more difficult with a normal workstation.

To activate this change, the Kiosk user must log on once and then the
computer must be restarted. When the user logs on for the first time, the
directory is created. Restarting the computer then applies the file system
Windows 2000 Server White Paper
56
restriction as Group Policy is reapplied.
Note:
This workaround does not prevent users from viewing what other users have
typed into the Address bar.
Cannot Hide Address Bar History
No Group Policy setting exists to hide the list of URLs that are typed into the
Internet Explorer Address bar. Workaround: None known.
Avoid Changing the Default Settings for Folder Redirection
When Group Policy Folder Redirection settings go out of scope, by default, they
leave the redirection in place. The Settings tab has an option that allows you to
redirect the folders to the local computer, however, avoid using this option. The
default setting is the safest because no data is moved when a Folder
Redirection policy falls out of scope. Any new Folder Redirection policy then
redirects as appropriate.
Cannot Restrict Use of Certain Control Panel Items
Even though Group Policy restricts certain Control Panel items, users can
access them from Run by typing the file name of the Control Panel item, such
as Desk.cpl. Workaround: Use file system ACLs to restrict the use of Control
Panel items.
Windows 2000 Server White Paper
57
Using the Kiosk Scenario on Stand-Alone Workstations
You can implement the Kiosk scenario on a stand-alone workstation. Because
a stand-alone workstation has no domain, you need to implement Group Policy
settings in the local Group Policy object.
To insert the Kiosk Group Policy settings into the local Group Policy object,
complete the following steps:
Step 1: Identify the GUIDs of the Kiosk GPOs
Identify the GUIDs of the Group Policy objects that are needed for the Kiosk
scenario. Look in Loadpol.bat to see the mappings between the GPO GUIDs
and the scenario names.
Step 2: Copy the Files
Copy the contents of the Kiosk computer GPO, which contains the user policy
files, to the local Group Policy directory
(%systemroot%\system32\GroupPolicy). Copy all the contents of the Group
Policy template to the local Group Policy directory. For example:
Xcopy {5CFDADF0-170C-4D78-8F35-42255241BF73}\* /s
%systemroot%\system32\GroupPolicy
Step 3: Edit the Gpt.ini
Edit the Gpt.ini to define which Group Policy extensions are used in the GPO.
You can copy these extension GUIDs from the GPO (by using the ADSI Edit
snap-in) or from the Container.ldif file in the root of the relevant Group Policy
object folder. The extension GUID lists are located within the following
attributes of the Group Policy container object:
gpcMachineExtensionNames
gpcUserExtensionNames
Edit the Gpt.ini to include the attributes that appear in the [General] section
(see the following example). Substitute GUIDList for the extension GUIDs
obtained earlier in this step. Do not change the other parameters.
GPT.INI
[General]
Version=686
gPCMachineExtensionNames=GUIDList
gPCUserExtensionNames=GUIDList
gPCFunctionalityVersion=2
Windows 2000 Server White Paper
58
Step 4: Apply ACLs
Local Group Policy objects cannot apply file system and registry ACLs. To
apply these ACLs, copy the security template file (GptTmpl.inf) from the
required scenario GPO. (You can find it in the
{GUID}\Machine\Microsoft\Windows NT\SecEdit subfolder of the GPO
template.) Then run the following command on the Kiosk workstation:
Secedit /configure /DB secedit.db /CFG [Path]GptTmpl.inf /overwrite [/log
logpath] [/verbose]
The /log and /verbose options are optional.
One problem with using the local Group Policy object is that the user Group
Policy settings affect all users who log on to the computer, which can make this
scenario difficult to administer. For example, most MMC snap-ins and Control
Panel icons are disabled. You can work around this problem by setting up an
account from which an administrator can log on to the workstation and place
Deny access rights for this account on all local Group Policy settings. Doing
this prevents the policy from loading for that user. When you are logged on as
that user, the Run As command can be used to start Administration Tools or to
run a command prompt as an administrator.
Important:
Do not set the Deny ACEs on the Group Policy settings for the administrator
because doing so prevents the administrator from modifying the Group Policy
setting.
Another issue is that the password and account lockout policies apply to both
administrators and the Kiosk account. You need to use strong security policies
for all accounts in this scenario. Set the Kiosk user account so that the
password never expires and the user cannot change the password.
Note:
Some Group Policy settings (for example, Internet Explorer Maintenance
settings) are not available in local Group Policy mode.
Windows 2000 Server White Paper
59
Supporting Utilities and Support Tools
When installing and using these scenarios, you must have the tools that are
shown as required in the following list. The others are optional and potentially
useful tools when working with Group Policy. This section describes where they
come from.
Tools Shipped in the Installation .Msi File
Sed.exe (Required) Required by scenario installation scripts (used to modify
installation files with the names of the current domain and forest). This is
included in the .msi package and it is also shipped in the Microsoft
Windows Services for Unix 2.0, which you can find at:
http://www.microsoft.com/ntserver/nts/downloads/previews/ntsfu/sfusites.asp
Windows 2000 Server Core
Ldifde.Exe (Required) Import and export Active Directory data. Is installed on
Windows 2000 Server in the %SystemDir%\System32 directory but is not
automatically installed with Windows 2000 Professional, even on a computer
that has Windows 2000 Administrative Tools installed. Therefore, if you are
running the installation batch file Loadpol.bat on a Windows 2000 Professional–
based computer, copy this file from a computer running Windows 2000 Server
to the directory where you have the Loadpol.bat file.
Windows 2000 Support Tools
Nltest.exe (Required) Required by scenario installation scripts (used to
determine the root domain of the current forest). Install the support tools from
the \support directory of the Windows 2000 Server installation CD.
GPolMig.exe Migrates Windows NT 4.0 System Policy settings to Group Policy
settings.
Windows 2000 Resource Kit
GPResult.exe Group Policy object troubleshooting tool that allows you to view
system information about the Group Policy objects applied to the current user
and computer, including a detailed list of the resultant Group Policy settings
that are being applied.
GPOTool.exe Group Policy object troubleshooting and administration tool.
Windows 2000 Server White Paper
60
Allows you to perform various command line operations, such as creating and
deleting GPOs in the directory and checking for GPO/SYSVOL replication
status.
Floplock.exe Locks the floppy disk drive of a computer so that only members of
the Administrators and PowerUsers groups can access it.
Con2prt.exe Utility to configure printer connections from a batch script. (This
tool has been included for backward compatibility with the Zero Administration
Kit, which you might have used with Windows NT 4.0.)
Note:
If you did not use the Zero Administration Kit with Windows NT 4.0, use the
Microsoft® Visual Basic® Scripting Edition (VBScript) file Prncfg.vbs instead.
The VB script is a better option because users can modify it and include it in
their own scripts.
Runapp.exe Utility that starts an application, and if the application is closed,
automatically restarts the application. This tool, which is used in the Kiosk and
TaskStation environment, is useful when an application cannot be configured
(by policy or other means) to block application shutdown.
Subinacl.exe Allows ownership of files and folders to be set from the command
line.
Windows 2000 Server White Paper
61
GartnerGroup Desktop Management Classifications
In a 1998 GartnerGroup report (see “TCO: A Critical Tool for Managing IT” by
B. Redman, B. Kirwin, T. Berg), the authors proposed a set of end-user
classifications that can help organizations quantify and manage their computing
costs. The GartnerGroup report provides the following descriptions of the
different end-user or worker types:
High Performance
Uses IT to create product. High integration of technology and job function. Adds
considerable value to product by using technology. May be project- or processdriven. Highly specialized applications, high productivity and business cost of
downtime. High investment in capital costs (e.g., engineer, graphic artist or
stockbroker).
Knowledge Worker
Uses IT to collect data from many sources, adds considerable value to that
data converting it into information and communicates information creating
knowledge in support of a decision-making transaction. Usually project-driven.
Mix of personal productivity and specialized applications. Moderate integration
of technology and work function. Moderate investment in capital costs.
Moderate personal and low business cost of downtime (e.g., executive-staff
work, research, financial analyst, consultant or reporter).
Mobile Worker
Typically, a knowledge worker that is location-independent. Higher investment
in capital costs and higher indirect costs due to self support. Moderate to high
integration of IT and job function. Moderate personal productivity and high
business cost of downtime (e.g., knowledge worker or sales person). It has
become clear that mobile computing is more platform-defined than worker-type
defined. Future GartnerGroup work will define worker types as locationindependent to cover the "road warrior" and telecommuters for the locationdependent, out-of-office worker.
Process Worker
Uses IT to add value in a process. Highly repeatable process-driven task work.
Mix of personal productivity and enterprise applications (e.g., claims processing
and accounts payable). Moderate to high integration of IT and job function.
Moderate to low investment in capital costs. Low personal and moderate-tohigh business cost of downtime (e.g., customer service representative, claims
processing and loan processing).
Data Entry
Uses IT to transcribe data from one media to another. Uses IT to add value to
data by making it available for other uses. High integration of IT and job
function. Low investment in capital costs. Low cost of personal downtime; high
cost of business downtime (e.g., airline reservations, order entry, shop floor and
transcriptionists).
Windows 2000 Server White Paper
62
Table 9 provides approximate mappings between the six Group Policy
scenarios and the user classifications described in the GartnerGroup report.
Table 9 GartnerGroup Worker Types Mapped to the Group Policy
Scenarios
GartnerGroup Worker
Types
Group Policy Scenarios
Notes
High Performance
Low TCO Desktop
User is a member of the local Power User’s
group.
Knowledge Worker
Low TCO Desktop
Mobile Worker
Laptop
Data Entry
TaskStation
Process Worker
AppStation
N/A
Public Computing
Environment
Special role – not usually found in a
corporate environment.
N/A
Kiosk
Special role – not usually used internally in
a corporate environment.
Windows 2000 Server White Paper
63
Using Group Policy Settings to Hide Drives
You can restrict or change access to drives by using the Group Policy settings
Hide these specified drives in My Computer and Prevent access to drives
from My Computer. To alter these settings, follow the Group Policy snap-in to
this path: \User Settings\Administrative Templates\Windows
Components\Windows Explorer.
For example, to add an option to hide all drives but drive C (typically the system
drive), edit the System.adm file as follows:
POLICY !!NoDrives
EXPLAIN !!NoDrives_Help
PART !!NoDrivesDropdown
REQUIRED
DROPDOWNLIST NOSORT
VALUENAME "NoDrives"
ITEMLIST
NAME !!AllButC
VALUE NUMERIC
67108859
NAME !!ABOnly
VALUE NUMERIC
3
NAME !!Conly
VALUE NUMERIC
4
NAME !!Donly
VALUE NUMERIC
8
NAME !!ABConly
VALUE NUMERIC
7
NAME !!ABCDOnly
VALUE NUMERIC
15
NAME !!ALLDrives
VALUE NUMERIC
67108863
DEFAULT
; low 26 bits on (1 bit per drive)
NAME !!RestNoDrives
VALUE NUMERIC
0
END ITEMLIST
END PART
END POLICY
[strings]
AllButC="All Drives except C:"
Windows 2000 Server White Paper
64
The value for the policy setting is specified as a decimal number. The binary
equivalent of this number is a bitmap, where each bitmap corresponds to a
drive (lowest bit = A: drive). Setting the bitmap hides the drive. For example, to
hide drives C and A:
00000000000000000000000101 (= decimal 5)
To hide all drives but C:
11111111111111111111111011 (= decimal 67108859)
Permissions Needed for Folder Redirection
By default, the Folder Redirection policy subsystem automatically sets the
required permissions. If you pre-create the destination directories, they must
have, at a minimum, the default permissions. Optionally, you can modify the
permissions to make them more secure. (See the column labeled Most Secure
Permissions.)
Table 10 shows the permissions that are needed for folder redirection.
Table 10
Folder Name
Account
Permissions Needed for Folder Redirection
Default Permissions
Most Secure Permissions
Server Root Folder (NTFS ACL): Use the defaults of folder creation.
Creator/Owner
For this account, apply this For this account, apply this
permission
permission

Full Control
onto This folder,
subfolders and files.
Local Administrator

Full Control
onto This folder,
subfolders and files.
For this account, apply this For this account, apply this
permission
permission

Full Control
onto This folder,
subfolders and files.

Full Control
onto This folder,
subfolders and files.
Windows 2000 Server White Paper
65
Everyone
For this account, apply this
This category should encompass all permission
users who need to create folders in
 Full Control
this share. You can substitute a more
specific group for the Everyone group; onto This folder,
although Everyone is simplest to
subfolders and files.
specify, it might be too wide a
definition for some organizations.
For this account, apply
these permissions

List Folder/Read Data

Create Files/Write
Data

Create
Folders/Append Data
onto This folder only.
Local System
For this account, apply this For this account, apply
permission
these permissions

Full Control

onto This folder,
subfolders and files.
Traverse
Folder/Execute File

List Folder/Read Data

Read Attributes

Read Extended
Attributes

Read Permissions
onto This folder,
subfolders and files.
Windows 2000 Server White Paper
66
Server Root Share (SMB ACL): Use the defaults of share creation.
Best Practice for managing shares is to grant access to the share point to everyone and
manage security by means of NTFS.
Everyone
For this account, apply this In place of the Everyone
permission
group, use a security group
that matches the users who
 Full Control
need to put data on the
share.
For this account, apply this
permission

Change and Read
<username> folder: This is what the Folder Redirection code does when it creates a folder.
<username>
Use care if the user is a local
administrator on the destination
server. In such cases, the owner of
the folder is Builtin\Administrators.
Ownership needs to be done
explicitly.
For this account, apply this For this account, apply this
permission
permission
Local System
For this account, apply this For this account, apply this
permission
permission

Full Control
onto This folder,
subfolders and files.

Full Control
onto This folder,
subfolders and files.

Full Control
onto This folder,
subfolders and files.

Full Control
onto This folder,
subfolders and files.
Windows 2000 Server White Paper
67
Everyone
For this account, apply
The special access control entry
these permissions
(ACE) for Everyone is provided so that
 Traverse
a user can share any file or folder
Folder/Execute File
deep within the redirected folder by
merely granting another user Read
 Read Attributes
access to that file. However, this ACE
 Read Extended
might not be necessary because all
Attributes
users have the Traverse privilege by
default, which achieves the same end.  Read
For this account, apply no
permissions.
Note: Do not use Deny
because it prevents all
access to the folder.
onto This folder,
subfolders and files:
Other items
Click to clear the Allow
inheritable permissions
from parent to propagate
to this object check box.
Click to clear the Allow
inheritable permissions
from parent to propagate
to this object check box.
Windows 2000 Server White Paper
68
Additional Resources: Gartner Group References
For more information about the Gartner Group report, see the following
resources:

Http://www.gartner.com

“TCO: A Critical Tool for Managing IT” by B. Redman, B. Kirwin, T. Berg, 12
October 1998, Gartner Strategic Analysis Report (Report, R-06-1697)

“Classifying End Users for Desktop Lockdown” by T. Kirk and R. Colville,
16 Aug. 1999, Gartner Advisory Research Note (Tutorials, TU-08-8279).

See also these related Research Notes by GartnerGroup:

“IntelliMirror Savings: Need Philosophy, Not Just Technology” by M. Silver,
15 Nov. 1999, Gartner Advisory Research Note (Strategic Planning, SPA09-3450).

“Collisions on the PC: Integration Anarchy Cripples Users” by M.
Margevicius, 24 Aug. 1999, Gartner Advisory Research Note (Tactical
Guidelines, TG-08-2241).

“Initiating a Process Approach to Desktop Lockdown” by T. Kirk and R.
Colville, 16 July 1999, Gartner Advisory Research Note (Decision
Framework, DF-08-6056).

“Desktop Lock-Down Reduces Help Desk Calls” by R. Colville and T. Kirk,
20 July 1999, Gartner Advisory Research Note (Case Studies, CS-08-5047.

“W2K IntelliMirror Alone: Insufficient for the Enterprise” by M. Silver, R.
Colville, M. Gartenberg, 23 April 1999, Gartner Advisory Research Note
(Technology, T-07-5879).
Windows 2000 Server White Paper
69
For More Information
For the latest information on Windows 2000 Server, check out our Web site at
http://www.microsoft.com/windows2000 and the Windows 2000/NT Forum at
http://computingcentral.msn.com/topics/windowsnt.
Related Information and Resources
For more information about deploying Windows 2000 Server and
Windows 2000 Professional, setting up Active Directory and using Group
Policy, see the following resources:
Windows 2000 Planning and Deployment Guide
http://www.microsoft.com/windows2000/library/planning/default.asp
Windows 2000 Resource Kit
http://www.microsoft.com/windows2000/library/resources/reskit/dpg/default.asp
Exploring Directory Services
http://www.microsoft.com/windows2000/guide/server/features/activedirectory.asp
Windows 2000 Server White Paper
70