Gwise.itwelzel.biz
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 98052-6399 • 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 6
Table 2 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 10
Table 3 Group Policy Settings to Customize for Your Environment 10
Step 6: Customize Optional Settings 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 Modifying Group Policy Settings for “Road Warriors” 48
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 51
Table 8 Strategy for Migrating Elements of Windows NT 4.0 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 62
Table 9 GartnerGroup Worker Types Mapped to the Group Policy Scenarios 63
Using Group Policy Settings to Hide Drives 64
Permissions Needed for Folder Redirection 65
Table 10 Permissions Needed for Folder Redirection 65
Additional Resources: Gartner Group References 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.
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.
• 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.
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
| | |Roaming User | | | | | |
| |Number of |Profile Support|User Data | | | | |
| |Users | |Saved |Folder Redirection|User Can Customize|Assigned |Published |
|Scenario | | | | | |Applications |Applications |
|Kiosk |1 |No |No |No |No |1 |No |
|TaskStation |Multiple |Yes |Yes |My Documents and |No |1 |No |
| | | | |Application Data | | | |
|AppStation |Multiple |Yes |Yes |My Documents and |No |up to 5 |No |
| | | | |Application Data | | | |
|PCE |Multiple |Yes |Yes |My Documents and |Some desktop |> 3 |Yes |
| | | | |Application Data |settings | | |
|Low TCO Desktop |Multiple |Yes |Yes |My Documents and |Almost all |> 3 |Yes |
| | | | |Application Data |settings | | |
|Laptop |1 |Yes |Yes |My Documents and |Some desktop and |> 3 |Yes |
| | | | |Application Data |configuration | | |
| | | | | |settings | | |
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.
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 |%ProgramFiles%\Group Policy Scenarios |
| |using the 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 |
|ScenarioName.xls |Microsoft Excel spreadsheets that list the Group Policy |%ProgramFiles%\Group Policy Scenarios\Docs |
| |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.
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.
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.
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 connection |\User Configuration |Defines the Internet Explorer connection settings for the|
|settings |\Windows Settings |client. Other settings in the Internet Explorer |
| |\Internet Explorer Maintenance |Maintenance snap-in should also be considered. |
| |\Connection | |
|Software settings |\Computer Configuration |Determines if applications are assigned or published. |
| |\Software Settings | |
| |and | |
| |\User Configuration | |
| |\Software Settings | |
|Scripts |\Computer Configuration |Defines scripts for Startup/Shutdown and Logon/Logoff. |
| |Windows Settings |Note: If the Command Prompt is disabled and Disable the |
| |\Scripts (Startup/Shutdown) |Command prompt script processing is enabled, no scripts |
| |and |can run. |
| |\User Configuration | |
| |\Windows Settings | |
| |\Scripts (Logon/Logoff) | |
|Folder redirection |\User Configuration |Redirects My Documents and Application Data. |
| |\Windows Settings | |
| |\Folder Redirection | |
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.
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.
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.
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.
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.
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.
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.
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.
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.
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:
sctoolset.asp
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 configured using policy mode, so you might need to create an additional GPO using preference mode for your environment.
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.
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.
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 pre-configured 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.
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 Stand-Alone 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 back-end 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.
• Enable the Group Policy settings shown in Table 5 on all servers and domain controllers that the Kiosk-based computer accesses:
Table 5 Group Policy Settings for a Kiosk-based Computer
| |
|Path |Policy Setting |Local Setting |
| |
|\Computer Configuration\Windows |Digitally sign server communication (always) |Enabled |
|Settings\Security Settings\Local | | |
|Policies\Security Options | | |
|\Computer Configuration\Windows |LAN Manager Authentication Level |Send NTLMv2 response only\refuse LM & |
|Settings\Security Settings\Local | |NTLM |
|Policies\Security Options | | |
|\Computer Configuration\Windows |Secure channel: Digitally encrypt or sign |Enabled |
|Settings\Security Settings\Local |secure channel data (always) | |
|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 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.
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.
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 1
DefaultUserName REG_SZ User name
DefaultPassword REG_SZ Password
DefaultDomainName REG_SZ 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.
TaskStation Scenario
A TaskStation-based computer shares the same characteristics as the Kiosk-based 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:
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 high-security workstation template. The key differences are:
• Administrator and guest account 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 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.
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 application-specific 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:
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 high-security workstation template. The key differences are:
• Administrator and Guest account 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, 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
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 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 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 high-security 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 \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 .msi-based 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.
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:
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:
• 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).
• 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.
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.
• 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:
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 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) 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|\Computer Configuration |Defines a slow connection for roaming user profiles. |
|user profiles |\Administrative Templates | |
| |\System\Logon | |
|Wait for remote user profile |\Computer Configuration |Directs the system to wait for the remote copy of the |
| |\Administrative Templates |roaming user profile to load, even when loading is |
| |\System\Logon |slow. |
|Prompt user when slow link is |\Computer Configuration |Notifies users when their roaming profile is slow to |
|detected |\Administrative Templates |load. |
| |\System\Logon | |
|Timeout for dialog boxes |\Computer Configuration |Determines how long the system waits for a user |
| |\Administrative Templates |response before it uses a default value. |
| |\System\Logon | |
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 |Click Enabled. |
| |\Administrative Templates \Windows | |
| |Components | |
| |\Windows Installer | |
|Always install with elevated privileges|\Computer Configuration |Click Enabled. |
| |\Administrative Templates | |
| |\Windows Components | |
| |\Windows Installer | |
|Hide the “Add a program from CD-ROM or |\User Configuration |Click Disabled or Not Configured. |
|floppy disk” option |\Administrative Templates | |
| |\Control Panel | |
| |\Add/Remove Programs | |
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.
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.
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).
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 |Migration Procedure |
| |
|Windows NT 4.0 Workstation Upgrade|Cleaning up System Policy settings |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.” |
|Zero Administration Kit |System Policy settings |Use Migpol.exe to migrate settings to Group |
|(ZAK)/System Policy settings | |Policy objects. |
|migration | |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. |
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.
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.
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 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.
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
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.
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:
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. 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.
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 process-driven. 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 location-independent to cover the "road warrior" and telecommuters for the location-dependent, 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-to-high 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).
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. |
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 DROPDOWNLIST NOSORT REQUIRED
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:"
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 Permissions Needed for Folder Redirection
|Folder Name |Default Permissions |Most Secure Permissions |
|Account | | |
| |
|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 |Full Control |
| |onto This folder, subfolders and |onto This folder, subfolders and |
| |files. |files. |
|Local Administrator |For this account, apply this |For this account, apply this |
| |permission |permission |
| |Full Control |Full Control |
| |onto This folder, subfolders and |onto This folder, subfolders and |
| |files. |files. |
|Everyone |For this account, apply this |For this account, apply these |
|This category should encompass all users who need |permission |permissions |
|to create folders in this share. You can |Full Control |List Folder/Read Data |
|substitute a more specific group for the Everyone |onto This folder, subfolders and |Create Files/Write Data |
|group; although Everyone is simplest to specify, |files. |Create Folders/Append Data |
|it might be too wide a definition for some | |onto This folder only. |
|organizations. | | |
|Local System |For this account, apply this |For this account, apply these |
| |permission |permissions |
| |Full Control |Traverse Folder/Execute File |
| |onto This folder, subfolders and |List Folder/Read Data |
| |files. |Read Attributes |
| | |Read Extended Attributes |
| | |Read Permissions |
| | |onto This folder, subfolders and |
| | |files. |
| |
|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 group, use a|
| |permission |security group that matches the users|
| |Full Control |who need to put data on the share. |
| | |For this account, apply this |
| | |permission |
| | |Change and Read |
| |
| folder: This is what the Folder Redirection code does when it creates a folder. |
| |For this account, apply this |For this account, apply this |
|Use care if the user is a local administrator on |permission |permission |
|the destination server. In such cases, the owner |Full Control |Full Control |
|of the folder is Builtin\Administrators. Ownership|onto This folder, subfolders and |onto This folder, subfolders and |
|needs to be done explicitly. |files. |files. |
|Local System |For this account, apply this |For this account, apply this |
| |permission |permission |
| |Full Control |Full Control |
| |onto This folder, subfolders and |onto This folder, subfolders and |
| |files. |files. |
|Everyone |For this account, apply these |For this account, apply no |
|The special access control entry (ACE) for |permissions |permissions. |
|Everyone is provided so that a user can share any |Traverse Folder/Execute File |Note: Do not use Deny because it |
|file or folder deep within the redirected folder |Read Attributes |prevents all access to the folder. |
|by merely granting another user Read access to |Read Extended Attributes | |
|that file. However, this ACE might not be |Read | |
|necessary because all users have the Traverse |onto This folder, subfolders and | |
|privilege by default, which achieves the same end.|files: | |
|Other items |Click to clear the Allow inheritable |Click to clear the Allow inheritable |
| |permissions from parent to propagate |permissions from parent to propagate |
| |to this object check box. |to this object check box. |
Additional Resources: Gartner Group References
For more information about the Gartner Group report, see the following resources:
•
• “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, SPA-09-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).
For More Information
For the latest information on Windows 2000 Server, check out our Web site at and the Windows 2000/NT Forum at .
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
Windows 2000 Resource Kit
Exploring Directory Services
................
................
In order to avoid copyright disputes, this page is only a partial summary.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.