Sie sind auf Seite 1von 132

Administrators Guide

Zero Administration Kit


Version 1.0
Microsoft Corporation
Information in this document is subject to change without notice. The names of
companies, products, people, characters, and/or data mentioned herein are fictitious
and are in no way intended to represent any real individual, company, product, or
event, unless otherwise noted. Complying with all applicable copyright laws is the
responsibility of the user. No part of this document may be reproduced or transmitted
in any form or by any means, electronic or mechanical, for any purpose, without the
express written permission of Microsoft Corporation. If, however, your only means of
access is electronic, permission to print one copy is hereby granted.
Microsoft may have patents, patent applications, trademarks, copyrights, or other
intellectual property rights covering subject matter in this document. Except as
expressly provided in any written license agreement from Microsoft, the furnishing of
this document does not give you any license to these patents, trademarks, copyrights,
or other intellectual property.
1985 - 1997 Microsoft Corporation. All rights reserved.
Microsoft, MS-DOS, MS, Windows, Windows NT, and ActiveX 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.
Printed in the United States of America.
3

Contents
Zero Administration at the Desktop
Overview of the Zero Administration Kit
The Task-Based Worker
TaskStation Mode
AppStation Mode
Evaluating ZAK for Your Corporate Environment
ZAK Methodologies
Planning for Client Desktop Functionality
Overview of User Profiles
Overview of System Policies
Customizing the Desktop
Unattended Installations
ZAK Custom Script Files
Customizing the Methodologies
CMD.EXE
Local Security Cacls.exe
Hiding the File System ATTRIB +H
System Policies
Updating Your Distribution Point
ZAK Setup
Prerequisites for Evaluating ZAK
Minimum Network Configuration
Minimum Server Requirements
Minimum Workstation Requirements
Other Requirements
Creating the ZAK Client Distribution Point
Preparing the Server for the Distribution Point
Installing the AppStation Option
Manual AppStation Setup
Installing the TaskStation Option
Manual TaskStation Setup
Organizing Files, Shares, and User Accounts on the Server
How to make a Digital Alpha AXP computer into a TaskStation client
System Policies
System Policies for Users or Groups
System Policies for Computers
System Policy Editor
Registry Mode
Zero Administration for the
Desktop

Policy Mode
Setting Policies
Creating System Policies
Creating Policies for Computers and Users
Creating Policies for Groups
Configuring System Policies
Policy Editor and Storing Paths in the Registry
Default Policies for Users
Default Policies for Computers
ZAK System Policies
Optional ZAK Policies
Policy Templates
System Policy Templates
Application Policy Templates
ZAK Custom Policy Template
Implementing System Policies on the Network
Automatic Download
Manual Download
Appendixes
Appendix A - Troubleshooting
Policy is not applied
Auditing and Using Event Viewer
Debug Userenv.dll
Replacing the Taskstation Shell with Cmd.exe
Appendix B - Utilities and Commands
Appendix C - More on System Policies
Policy Clashes
Function Calls
One of the major costs highlighted in recent reports on Total Cost of Ownership Two
of the main factors that contribute to lost productivity for end users are:
Inexperienced users with too much access to system configuration components.
Usually, in this case, the user makes a configuration change that results in a
support call.
Users being distracted from their work because they are exposed to system
components and user interface features that are not required to complete their
jobs. This can be something simple like the user spending too much time deciding
on their favorite text editor (for example, deciding between Edit, Notepad, Write,
WordPad, and Microsoft Word). But nevertheless it is lost productivity time.

Figuring out how to curb the cost associated with end-user operations is one of the
major challenges facing system administrators. Todays desktop operating systems are
designed to empower the user, which can be at odds with some of the control and
management requirements of large scale IT operations.
5

The Zero Administration Kit (ZAK) is designed to help you address some of the
issues and problems arising from end-user operations.
By way of example, ZAK provides a solution for installing Windows NT 4.0 and
Office 97 completely hands-free. However, setting up an environment for corporate-
wide deployment of Microsoft Windows NT and Microsoft Office is a task that needs
careful thought and thorough planning. ZAK should not take the place of the weeks
of planning that go into deploying these products.

Overview of the Zero Administration Kit


The Zero Administration Kit (ZAK) is a set of methodologies for deploying
Windows NT version 4.0 that greatly reduces the burden of individual desktop
management for task-based workers. By judicious use of forward planning, user
profiles, system policies, and security, ZAK can reduce some of the administrative
costs associated with managing Windows desktops for task-based workers.
ZAKs methodologies are based on the underlying technologies and capabilities of
Windows NT. It is anticipated that these techniques can readily be adapted to
accommodate a corporations specific computing requirements.

The Task-Based Worker


The average task-based worker usually has minimal-to-moderate computer
experience. Further, from the perspective of desktop computing environments, the
task-based worker can be considered to operate in one of two modes. For ease of
explanation, these modes have been defined here as TaskStation mode, where users
are running a single line-of-business application, and AppStation mode, where users
run a set of well-defined applications. ZAK deliberately targets the desktop of the
task-based worker because these desktops are quite vulnerable to the cost associated
with end-user operations.

TaskStation Mode
The TaskStation mode is for workers who meet the following criteria:
Minimal computing experience or Windows knowledge
Use highly task-specific applications

A typical scenario for this desktop environment is a worker who uses one or two
form-based applications. Typical environments for TaskStation mode are banks, call
centers, and data entry operations.

The TaskStation Solution


The ZAK TaskStation mode provides a simplified desktop-computing environment,
where the user interface is the users task-specific application. In this mode, the
normal Windows desktop interface is completely hidden from the user and the user
only has limited access to the local file system. When the user logs on, his or her
task-specific application is automatically launched. In TaskStation mode, you have
centralized control over which application is launched.

The TaskStation desktop with Internet Explorer running as the user interface

AppStation Mode
The AppStation mode is for workers who meet the following criteria:
Moderate computing experience, or Windows knowledge
Use a well-defined set of applications

A typical scenario for this desktop is a worker with access to a limited set of well-
defined applications, usually installed on a central server. If the user needs to save
data, it is written to the users private home folder on a central server. Typical
customer environments for AppStation mode are customers who perform multiple
administrative and clerical tasks, such as banks and insurance companies.

The AppStation Solution


As with the TaskStation mode, the AppStation mode uses a simplified desktop to
alleviate distractions. However, in AppStation, a few familiar elements of the
Windows desktop are exposed. When the user logs on, his or her desktop interface
contains only the Windows Start menu and taskbar. The AppStation Start menu is
simplified to contain only essential items for the users job, as shown in the following
figure. More importantly, you can centrally manage the items that appear in the
Programs group.
7

The AppStation desktop and Start menu

Evaluating ZAK for Your Corporate


Environment
Corporations can gain the most benefit from ZAK by first completing a thorough
evaluation on a pilot network. This approach gives you the opportunity to fully
understand the principles of ZAK in a controlled environment before applying these
principles to a production environment. The techniques highlighted in ZAK should
be seen as an augmentation to a corporations deployment techniques; not a
replacement of them.

ZAK Methodologies
The zero administration techniques in this guide are intended for managing desktops
of users that require a simplified environment with limited access to programs and
desktop user interface elements. Some software vendors have added facilities to help
corporations deploy and manage their applications in enterprise environments.
However, vendors providing these facilities are limited, and thefacilities can vary
widely from application to application. To a large extent, success toward approaching
zero administration at the desktop depends on the applications you deploy within
your organization.

Planning for Client Desktop Functionality


When planning the facilities and capabilities of your client desktops, you must
consider many factors, such as which user interface elements you want to expose. A
good place to start is with the principle of least privileges. For clients for whom you
want to provide least privileges, you would expose only the minimum amount of
desktop functionality required for users to do their jobs. ZAK provides this minimum
functionality in the TaskStation and AppStation implementations.

Overview of User Profiles


A user profile defines the Windows NT environment that is loaded when a user logs
on the user profile contains all user-defined settings for the computer, including
network connections, display settings, printer connections, and so on. To implement
ZAK effectively, you must have a strong understanding of user profiles. This section
covers the basics of user profiles, and discusses how ZAK implements them.
One of the primary goals of user profiles is to provide a vehicle by which a users
system and desktop customizations can roam with the user from computer to
computer with no maintenance between computers. This gives users who log on to a
multi-user computer consistency of their own settings, regardless of who else logs on
to the same computer. This also gives users who need to use multiple computers the
convenience of using the same recognizable interface regardless of which computer
they are using.
The Windows NT Registry is a database used to store computer-specific and user-
specific settings. Portions of the Registry can be saved as files, called hives, for
storage. Hives can then be reloaded at a later time for usage. Because user profiles
take advantage of this capability to give users mobility, the user profile consists of two
parts. The first part of the user profile is a Registry hive called Ntuser.dat, which
maintains the users environment preferences and, when the user is logged on, is the
HKEY_CURRENT_USER portion of the Registry. The second part of the user profile
is a series of folders on the hard drive, each of which serves a purpose in the users
environment. The Ntuser.dat Registry hive stores those settings that maintain
network connections, Control Panel configurations unique to the user (such as the
desktop color and mouse settings), and application-specific settings. The folder
structure stores shortcut links, desktop icons, startup applications, and so forth. This
combination of the Registry hive and the folders record all user-configurable settings
that can migrate from computer to computer.

User Profile Definitions


Local profiles are specific to a particular computer. A user who creates a local profile
on a specific computer can gain access to that profile only when logged on to that
computer.
9

Roaming profiles are profiles that can be accessed from any computer. A user who
creates a roaming profile can log on to any computer and access the profile.
Mandatory profiles are pre-configured, roaming profiles that cannot be modified by
the user. They are typically assigned to a person or a group of people for whom a
common interface is required.

Planning for User Profiles


Before creating user profiles, you should consider the following questions to better
prepare for implementation:
Will users be required to use a specific set of desktop folders and environment
settings?
Where will the profiles be stored, and is there enough drive space to store them?
How will shortcuts and links be displayed for the user?
Will the users be able to modify their profiles?
What is the speed of the links between the clients and the server storing the
profile?
How much of the users environment do you want to control? Would system
policies, either in conjunction with user profiles or by themselves, be a better
solution?
Which features are you implementing in user profilespersistent network
connections, custom icons, backgrounds, and so forth?
For roaming profiles, will the user be allowed to use the default profile from the
client workstation, or will a standardized server-based default profile be used
instead?
Where do existing users home folders reside?

When deciding when and how to use user profiles, you should consider the
experience of the users and the tasks that the users have to carry out. For example, a
set of inexperienced users hired to work with a specific set of applications may not
want to deal with the wide range of options and tools that a computer running
Windows NT Workstation provides. It can be beneficial to customize these users
working environments so that they are focused on the applications they use. However,
for more advanced users, you should consider using non-mandatory, roaming profiles.
This gives users the ability to change their own environments.
For task-based workers, you want to create a profile geared toward enhancing the
work environment for the set of applications that the workers need. This workstation
can have Help bookmarks already created, pointing toward known issues with the
programs they use. Furthermore, the workstations can have a customized desktop,
Start menu, Network Neighborhood, Printer settings, SendTo folder, and Programs
folder, all configured specifically for the set of applications that the users need to
complete their tasks. By doing this, you can hide the distracting and possibly
damaging options and controls that the users do not need to get their jobs done.
The implementations of the Zero Administration Kit described in this document use
policy-based management and local profiles to configure the users desktop
environment. However, either mandatory or roaming profiles can be used in place of
local profiles and may be desirable in many instances.

Overview of System Policies


Windows NT includes System Policy Editor, a tool that you can use to create a system
policy to control user work environments and actions, and to provide and enforce
system configuration for all computers running Windows NT. For example, you can
use system policies to restrict what users can do from their desktops, such as
restricting certain Control Panel options, or configuring network settings. To
implement ZAK effectively, you must understand system policies. This section covers
the basics of system policies, and discusses how ZAK implements them. For more
information about system policies, see System Policies later in this document.
Using the System Policy Editor provided with Windows NT 4.0 Server, you can create
a file that contains Registry settings. These Registry settings will be written to the
user or local computer portion of the Registry database of the client computer to
generate a desired environment for the user. User profile settings, specific to the user
that logs on to a given workstation or server, are located in the Registry under
HKEY_CURRENT_USER. Likewise, computer-specific settings are located in the
Registry under HKEY_LOCAL_MACHINE. When a system policy is applied, the
existing Registry settings are overwritten with the settings you have established in the
policy file, thus giving you the ability to set restrictions on the client computer and
end user. With a properly implemented policy, regardless of where a user logs on, the
users environment can be customized to your specification, despite the users
preferences. The settings available in the system policy can cover a variety of options
to manage the environment.
System Policy Editor is designed to utilize policy templates, which specify the
Registry settings that are available for modification through the System Policy Editor
interface. The policy template file consists of a hierarchy of categories and sub-
categories that define:
How policies are displayed through the administrative interface
Registry locations where the changes should be made
Options that accompany the policy
Restrictions to values that can be selected
Default value that should be used if the option is selected

Because policy template files are text-based, they can be created or modified using
any text editor such as Notepad.
To further ease administration, a policy file can correspond to multiple templates.
This way, if you want to create a custom template for a specific application, you can
just add it to the pool of existing policy templates, instead of having to add the entries
to one large .adm file. For more information on system policy templates, see Policy
Templates later in this document.
11

Planning for System Policies


Before creating system policies, you should consider the following questions to better
prepare for implementation:
Will administration be simplified by defining group settings as opposed to
creating settings for individual users?
From where will computers be configured to download the policy file? Does
geographic location have such an important part in your networks design that
computers from a certain locale would benefit from retrieving policy files from a
specific computer as opposed to a validating domain controller that may not be in
the clients location?
Will users at client computers be allowed to access locally installed common
group applications, or will this be overridden by administrator-defined program
groups, desktop icons, Start menu programs, and so forth?
What types of restrictions do you want to impose on users?
What other options are available if you simply want to restrict access to a specific
icon or file? Would modifying NTFS permissions be more effective?
Will you just be affecting computer-specific settings and not user settings?

System policies and user profiles can be used to configure much of the same data.
System policies, however, can configure a larger portion of the Registry. Furthermore,
system policies are easier to customize. When used in conjunction with the custom
templates that are provided with applications or created by an administrator, system
policies can configure application settings as well as a wider range of user settings.
The Zero Administration Kit takes advantage of the flexibility and power of system
policies. By using the default templates provided with the operating system,
Microsoft Office 97, and Internet Explorer, ZAK can create highly customized
desktops.

Bringing Order to the File System


If one of your requirements is to install hundreds, even thousands of task-based
desktops, providing conformity in the layout of the file system can help reduce
desktop administration costs. For example, if each desktop has paths that you
determine, you can use this information when setting policies for applications that are
not policy aware or do not support environment variables. For the client
implementations provided in ZAK, c:\winnt is used as the operating system
installation point.

Customizing the Desktop Interface


The standard Windows desktop interface can be customized using several different
techniques; ZAK uses policy-based management to simplify and customize desktops.
The AppStation and TaskStation implementations in ZAK hide certain functionality
from the user for two reasons:
To simplify the user interface
To focus the users attention on what he or she must do to get his or her job done
To successfully use policy-based management when customizing the desktop, it is
important to have an understanding of the granularity of control this method offers.
Next, this document describes the policy-based management techniques used in the
TaskStation and AppStation implementations of ZAK. For more information on the
specific policies used, see System Policies later in this document.

Desktop Appearance and Special Folders


The following figure shows one view of the Windows desktop after a standard
installation of Windows NT and Office 97. This desktop is not optimized for the
novice or task-based worker who requires less options.

Standard Windows NT Workstation desktop

For example, given the defined profile of the task-based worker it is unlikely this
worker needs My Briefcase, and, if Microsoft Outlook is the corporate mail client,
there is no requirement for the Inbox either.

Customizing the Desktop


Many visual elements of the desktop are governed by the contents of user interface
(called shell here) special folders. These folders have special meanings for the shell.
An application can use shell functions to retrieve the locations of these special folders
and to enable the user to browse for specific folders.
Note

13

Some special folders are virtual folders because they are not actual folders on any
storage device, local or remote. Virtual folders like desktop, My Computer, and
Network Neighborhood make a unified name space possible by serving as containers
for any number of storage devices and network resources. Other virtual folders
contain file objects, such as printers, that are not part of the file system.

User Profile Folders


The user profile folders are a subset of the shell special folders. These folders contain
links to various desktop items and, coupled with users Registry hive, make up the
users profile.
One of the most important things about the user profile folders is how they affect look
and feel of the desktop when a user logs on. The following table shows some user
profile folders and their contents.
User profile folders and their contents
Folder name Contents
Desktop File system directory used to physically store file objects on
the desktop.
Favorites File system directory containing shortcuts to favorite items.
NetHood File system directory containing objects that appear in the
Network Neighborhood.
Personal File system directory that serves as a common repository for
documents.
PrintHood Printers folder containing shortcuts to printers.
Recent File system directory that contains the users most recently
used documents.
SendTo File system directory that contains Send To menu items.
Start menu File system directory containing Start menu items.
Programs File system directory that contains the users program
groups (which are also file system directories).
StartUp File system directory that corresponds to the users Startup
program group.
Templates File system directory that serves as a common repository for
document templates.

Accessories is not a shell special folder.

The user profile folders have another special property because they can be redirected
to a different location. For example, one of the policy settings used in the AppStation
implementation redirects the users personal folder to the users home directory on a
server. The locations of special file system folders are stored in the Registry under the
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\
Shell Folders key.
Note

Applications should use the SHGetSpecialFolderLocation function to retrieve the


location of a special folder. This is critical for anyone contemplating building
manageable applications. For example, the Office 97 applications call
SHGetSpecialFolderLocation to retrieve the users Personal folder when attempting
to do any open or save operations. This means that you can redirect the users
Personal folder to a network folder with the associated benefits; less user-specific data
on the client, better backup of user documents, and so on.
The following example demonstrates how using the SHGetSpecialFolderLocation
function affects the users desktop. For more information on
SHGetSpecialFolderLocation, see Appendix C.
The shell restrictions policy, Hide all items on the desktop, has the effect of focusing
all user desktop operations to the Start button. This in itself is quite powerful in
removing general distractions and user mistakes.
The current design of the shell does not support hiding individual desktop icons on a
per-user or per-group basis.

There are two things to note about the Hide all items on the desktop policy. The first
is that hiding does not remove icons such as the Inbox or Briefcase from the desktop.
The desktop is made up of three windows stacked upon each other. Lowest in the
stack is the main desktop window. On top of this is a transparent window, which
contains the desktop icons and the topmost window is the tray window (the taskbar).
When you select the Hide all items on the desktop policy, the middle transparent
windows visible status is turned off. In reality the desktop icons are still on this
window but they are not visible to the user. Second, it is not possible to augment the
desktop with additional icons because the window containing these icons is invisible.

Control Panel and the Display icon


The Control Panel has many items not suitable for a task-based workers desktop. In
terms of applying restrictions to the Control Panel, user access to the Display icon is
controllable by system policies. You can use System Policy Editor to limit user access
to only the Background tab; users then cannot access any of the other features of the
Display icon. User access to this dialog box should be limited because many support
calls are the result of user actions in this dialog box.
Using system policies, you can expose functionality of the Display Properties dialog
box based on users computer competency. The resulting simplified user interface
with less exposed functionality means reduced support cost for the corporation. The
per-tab policy control on the Display Properties dialog box is an excellent example
of how applications should use policies. For more information, see Example of a
System Policy Template later.
Many of the other icons in the Control Panel do not allow a user with non-
administrative privileges to alter the system configuration, however. The icons are
still a distraction for users. For this reason, neither the AppStation or TaskStation
implementation of ZAK expose the Control Panel.

Start Menu
Even after hiding all items on the desktop, there are still many distractions for the
task-based worker. The default Start menu has many superfluous and distracting
15

links that the task-based worker simply doesn't need to do his or her job. The Start
menu in Windows is a pointer to a folder, usually containing shortcuts to items stored
elsewhere in the file system. The Start menu, like any other shell special folder, can
be redirected to point to any valid folder, including mapped drives and UNC paths.
The following figure shows the Start menu of a Windows desktop after a standard
installation of Windows NT Workstation and Office 97.

Standard Start menu of Windows NT Workstation

There are several policies provided with ZAK for controlling the contents of users
Start menus. You can use the Remove common program groups from the Start
menu policy to segment what each user or group sees by locking out the contents of
the All Users\Start menu\Programs folder, which is usually included by default in all
Start menus.
This policy does simplify the Start menu. However, it also locks a user out of
Office 97 because this policy stores its information in the All Users\Start
menu\Programs folder. However, the entire Start menu and Programs folder can be
redirected on a per-user or per-group basis through the use of system policies.
Provided that the redirected path set in the Custom Programs folder policy has
shortcuts to valid applications, access to programs can be controlled centrally.
All of the AppStation clients can be configured to point to the same remote folder.
Thus, instead of having to administer many Start menu folders, you only have to deal
with one, as shown in the following example.

Redirected and restricted Start menu and Programs folder

Installing Applications
The types of applications a corporation chooses to install depend on its business
needs. The location of installed applications depends on the environment within the
corporation and the functionality of the applications themselves. One way to reduce
the administrative costs of managing individual desktops is to install applications on
a central server and run them over the network, rather than installing them on the
client computers. Two issues you should consider when setting up such a system are:
User productivity becomes heavily reliant on the availability of the network. This
is fine, provided the network has a high mean-time between failures.
17

Not all applications provide adequate run-from-server support. If the applications


will be installed locally, then it is important to check their ability to be managed
remotely. Some applications provide the ability to customize which parts of the
application are installed on the server and which parts are installed on the client.
This can be a useful compromise between the two extremes.

For the AppStation client implementation in ZAK, the applications are installed
using the Office 97 run-from-server method1.

Unattended Installations
One of the driving forces behind the Zero Administration Kit is the need to reduce or
eliminate administrative visits to individual desktops. This idea is one that is taken
even to the initial configuration of the computer. Given the requirement to install a
computer with productivity applications, e-mail, remote printing, and a customized
desktop environment, the ideal situation is a single visit to the computer to configure
all of these features. This is exactly the implementation provided in the Zero
Administration Kit for the AppStation client.
Today, within most large corporations, there is some sort of assembly-line process for
getting new computers to users. Usually these tasks are similar to the following:
1. Receive computer and software from suppliers
2. Install hardware (can be done by supplier)
3. Install operating system
4. Install third-party applications
5. Install in-house line-of-business applications
6. Test configuration
7. Ship to user

The amount of automation and techniques used for steps 25 varies from corporation
to corporation. In almost all cases, however, the goal is to minimize the labor
necessary to arrive at step 6 to achieve the goal of a single visit to each client
computer. This goal is dependent upon the installation capabilities of Windows NT
and the applications that will be installed on the client computer. The following is a
discussion of steps 25 and what needs to be achieved in each step for a one-visit
installation.

Step 2 - Install Hardware


When choosing hardware, it is important to make sure that:
1. You have Windows NT drivers for the client hardware.
2. The drivers for the hardware support Windows NT unattended installation mode.

1
The minimum client footprint for Office 97 run from network (RNS) is
approximately 28 megabytes (MB). Of these 28 MB, approximately 7 MB are Office
97 files and the are system infrastructure files like MAPI and ODBC. For further
details see the Office 97 Resource Kit.
You should pay particular attention to network cards. For a complete list of network
cards that support Windows NT unattended installation mode, see the Windows NT
Deployment Guide, Automating Windows NT Setup.

Step 3 - Install Operating System


To do an unattended installation of Microsoft Windows NT Workstation, you need an
Unattend.txt file, which is an answer file you can use to bypass setup questions.
However, to achieve this functionality, the network card in the client computers must
be Unattendable. This means that the network cards must be configurable by an
Unattend.txt file. This is different than being detectable, which means that
Windows NT automatically detects it without any help from the Unattend.txt file. A
list of network cards that can be used with unattended Windows NT Setup is provided
in the Microsoft Windows NT Deployment Guide, Automating Windows NT Setup.
When completing multiple unattended installations with one Unattend.txt file, you
also must create a Uniqueness Database File (UDF) to store the information that is
unique to each computer. To read more about Unattend.txt and UDFs, see the
Microsoft Windows NT Deployment Guide, Automating Windows NT Setup.

Chaining the Service Pack Installation


This technique copies the service pack files to the client computer as part of the file
copying phase of Windows NT Setup.
1. Copy the Windows NT service pack source files to your network distribution
point, as shown in the following example:

copy d:\i386\*.* c:\dist\$oem$


copy d:\spcdrom.40 c:\dist\$oem$
copy d:\disk1 c:\dist\$oem$

Where d: is the CD-ROM drive letter, i386 is the name of the target platform, and
c:\dist is the root directory containing your Windows NT source files on the
distribution point.
2. Edit or create a Cmdlines.txt file with the following content. Save the file in the
$oem$ folder of your network distribution share.

[Commands]
".\update /u /z"

3. Edit or create your Window NT Setup script file (Unattend.txt) to ensure that it
contains the following line in the [Unattended] section:

[Unattended]
OemPreinstall = yes
19

ZAK Setup uses this method to install the service pack files. The graphical mode of
ZAK Setup prompts you for the location of Service Pack 3 or later, and then copies
the files into the $oem$ directory on the distribution share. ZAK Setup also
provides both Cmdlines.txt and Unattend.txt, which are modified appropriately.
For more information on Unattend.txt and Windows NT Unattended Setup, see the
Windows NT Deployment Guide, Automating Windows NT Setup.

Step 4 - Install Third Party Applications


The ideal situation is to have an application that supports unattended installation.
This can be either silent mode in which there is no output to the screen, or verbose
mode, which displays progress on the screen, but does not prompt the user for
information. If the applications you want to install do not support unattended
installation, there are a number of tools that use snap-shotting and differencing
technology to achieve the same goals. The implementation in ZAK uses unattended
application setup and differencing technology. Whichever method you decide to use,
it should work with or without a software distribution tool, like the system
management server.

Step 5 - Install In-House Line-of-Business


Applications
Of course, corporations can also build customized line-of-business applications using
all the best practices techniques that makes installation easy for corporate
deployments.

ZAK Custom Script Files


The Zero Administration Kit contains a number of custom script files used as part of
the overall process of configuring client computers for reduced administration. Most
of these files are used during the installation stage and the others are used during the
processing of logon scripts. The scripts that are used during installation are
diagrammed in the following chart.
21

The following table shows what each script is used for.


ZAK script files
Script file What it is used for
Cmdlines.txt Main file processed during the GUI mode portion of
Windows NT unattended setup.
Appcmds.cmd Called during Cmdlines.txt processing; used to make custom
Registry changes.
Zakboot1.cmd The main script that is processed on initial boot after the
operating system has been installed.
Zakb1wrk.cmd Called by Zakboot1 and handles installation of applications.
Off97.cmd Called by Zakb1wrk.cmd and handles installation of Office 97.
Cleanup.cmd Used to clean up the All Users Startup folder.
Acls.cmd Sets access controls on the file system.
Hide.cmd Changes the attributes on files and directories.
Applogon.cmd Logon script for AppStation clients.
Tsklogon.cmd Logon script for TaskStation clients.

Appcmds.cmd
This is the first file called during the processing of Cmdlines.txt.
@rem ******************
@rem Registry Changes/Additions
@rem ******************

The HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunO
nce Registry key is set to run the Zakboot1.cmd file. The RunOnce key is used to
execute a command for one time only after a computer restarts.
cmd /c %SystemRoot%\REGEDIT.EXE /S %SystemRoot%\zak\scripts\runonce.REG

In the
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlo
gon Registry key, the value Auto AdminLogon is set to 1, and the necessary
parameters, DefaultUserName, DefaultPassword, and DefaultDomain are all entered
based on the information provided during ZAK Setup. This is done so that when the
computer restarts at the end of setup, the setup account 2 is automatically logged on.
cmd /c %SystemRoot%\REGEDIT.EXE /S %SystemRoot%\zak\scripts\autolog.REG

In the
HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Net
work\Persistent Connections Registry key, the value SaveConnections is set to no.
This is so that any drives mapped during setup are not saved and displayed when the
2
The setup account is an account you create with administrative privileges and is
used in the setup of ZAK clients.
setup account logs on. You can map all of the shares that the user needs access to
either through the users logon scripts, or through the settings configured in User
Manager.
cmd /c %SystemRoot%\REGEDIT.EXE /S %SystemRoot%\zak\scripts\nosavcon.REG

@rem ******************
@rem Apply Service pack
@rem ******************

Install service pack, where /u runs the service pack update in quiet mode, /n prevents
the service pack update from creating the uninstall directory, and /z prevents setup
from restarting the computer. Instead, the computer restarts during the normal
Windows NT Setup restart.
cmd /c %SystemRoot%\sp\update /u /n /z

@rem ******************
@rem update system help files
@rem ******************

The standard Windows NT Help file exposes parts of the system most administrators
would rather not have their task-based workers exposed to. Also, the Help menu item
on the Start menu is not controllable through system policy. In both the AppStation
and TaskStation examples, the default Help file, Windows.hlp, is replaced by a stub
Help file called Zak.hlp. You can either skip this step or replace Zak.hlp with your
own custom Help file. If you want to give users access to Help files under
%SystemRoot%\, you must also edit Acls.cmd because it places security on these
files.
cmd /c copy %SystemRoot%\system32\windows.hlp %SystemRoot
%\system32\windadm.hlp
cmd /c copy %SystemRoot%\zak\scripts\zak.hlp %SystemRoot
%\system32\windows.hlp

Shortly after Appcmds.cmd runs, Windows NT Setup restarts the computer. When
this occurs, the setup account automatically logs on and the RunOnce key is
processed. Zakboot1.cmd runs and immediately calls Zakb1wrk.cmd.

Zakb1wrk.cmd
Zakb1wrk.cmd is called by Zakboot1.cmd.
The commands in Zakb1wrk.cmd for the AppStation can be broken down into the
categories:
Installation of programs
Removing installation files
Placing security on the local file system

Zakboot1.cmd starts by mapping the Netapps share and then installs Office 97 and
Internet Explorer. It then removes the service pack installation files copied during
23

Windows NT Setup and changes the Winlogon key, set during Appcmds.cmd for auto
logon, back to manual logon. Next, Zakb1wrk.cmd runs Floplock.exe, Acls.cmd, and
Hide.cmd to place security on the file system and floppy drives. Finally,
Zakb1wrk.cmd is deleted from the local drive by Zakboot1.cmd because it contains
administrative passwords.

Installation of programs
Zakb1wrk.cmd provides a line to execute the runsms.bat file located on your system
management server. To use this line, you must take the comments out and then
modify the computer name and share name to reflect the computer and share you are
using on your network.
@rem uncomment the following line if you want sms
@rem cmd /c \\server name>\sms_shr\runsms.bat

During setup, the clients need to access the Netapps3 share on the server to install
Microsoft Office.
net use O: \\server name>\NETAPPS /user:<domain>\<user> <password>

After you map the share to the O: drive, you are ready to install Microsoft Office. The
command, O:\Off97\msoffice\setup /b3 /qnt /gc %SystemDrive%\temp\offlog.txt
is stored in off97.cmd which is called from this script. A detailed list of all the
command line options is presented in the Microsoft Office 97 Resource Kit.
/b3 bypasses the Microsoft Office 97 Setup dialog box by automatically selecting the
Run from Network Server installation option.
/qnt suppresses all user interface elements and prevents the system from restarting.
/gc Generates a log file that records details of the Setup process including all calls
and returns from custom actions.
cmd /c %SystemRoot%\zak\scripts\off97.cmd

When Office 97 is installed, shortcuts to FindFast and the Office menu bar are placed
in the Startup folder for All Users. This will start these items regardless of who is
logged on. For the AppStation implementation, these items are not required for the
client desktop so they are removed as part of the client setup process. Office Menu bar
and the command, del /q %systemroot%\profiles\All Users\Start
Menu\Programs\Startup\*.* deletes the shortcut to the menu bar and everything
else from the Startup folder.
cmd /c %SystemRoot%\zak\scripts\cleanup.cmd

@rem uncomment the following line if you want sms


@rem cmd /c copy %SystemRoot%\zak\scripts\smsrun32.lnk %SystemRoot
%\"profiles\All Users\Start Menu\PROGRAMS\STARTUP"

ZAK setup installs Internet Explorer by using sysdiff and a difference file.
%SystemRoot%\zak\tools\sysdiff /apply /m %SystemRoot
%\zak\scripts\msie302.dif

3
Netapps is the default name chosen by ZAK Setup for the client installation of
Office 97.
Removing installation files
After the service pack is installed, Zakboot1.cmd runs this command to remove the
installation files that were copied with the Windows NT installation.
cmd /c rmdir /s /q %SystemRoot%\sp

Now that the system has rebooted and logged in as Administrator, the
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\W
inlogon key no longer needs to be set for auto logon, so change the key by using the
following command.
REGEDIT.EXE /S %SystemRoot%\zak\scripts\noautlog.REG

Placing security on the local file system


Floppylock is a utility provided with the Windows NT Server Resource Kit that
allows users to lock out floppy drives by placing Discretionary Access Control Lists
on the com ports used by floppy drives. To learn more about Floppylock, see
Appendix B.
%SystemRoot%\zak\tools\instsrv FloppyLocker %SystemRoot
%\system32\floplock.exe

Zakboot1.cmd now sets the password of the local administrator account to what you
specified during the automated portion of ZAK Setup.
net user administrator <password>

Acls.cmd is a file used to place Access Control Lists (ACLs) on the local file system.
This file is discussed in more detail later in this section.
cmd /c %SystemRoot%\zak\scripts\acls.cmd

After permissions are set on the local file system, Hide.cmd runs. This file hides most
files on the local computer.
cmd /c %SystemRoot%\zak\scripts\hide.cmd

ACLs.cmd
ZAK provides two versions of Acls.cmdAcls.app and Acls.tsk. When you choose
whether to install an AppStation or TaskStation distribution point, ZAK Setup copies
the appropriate file to the server and renames it Acls.cmd. Because Acls.tsk is just a
subset of Acls.app, Acls.app is described here.
Acls.cmd changes the access permissions on the local file system of the client
computers. Users are given either Read permission or no permission at all on files
that they do not need to access. Then, specific exceptions are made to the file system
because users and applications need access to certain folders and files to function
properly. You can place permissions on the local file system by using the command
Cacls.exe. Use this command to view or change access control lists on the local file
Note

25

system. An explanation of Cacls.exe as well as a list of its command line flags is


provided in Appendix B.
The Acls.cmd file supplied with ZAK sets security with some knowledge of how
Microsoft Office 97 and Microsoft Internet Explorer behave. Although the specific
ACLs set in this script file is not necessarily applicable to all applications, this file
can be used as a guide for working with other applications.

@rem This script will put more stringent security


@rem on a Windows NT 4.0 AppStation client
@rem

@rem
@rem SYSTEM DRIVE AND ALL FILES/DIRECTORIES ON SYSTEM DRIVE
@rem ======================================================
@rem
@rem NOTE THAT THIS FILE ONLY COVERS DIRECTORIES AND FILES WE KNOW
@rem ABOUT ON THE ZERO ADMINISTRATION CLIENT. IF YOU INSTALL ADDITIONAL
@rem APPLICATIONS ON THE ZERO ADMINISTRATION CLIENT THEN YOU
@rem NEED TO ADD LINES FOR THE FOLDERS YOU CREATE.

@rem
@rem SYSTEM DRIVE
@rem ============
@rem

First, everyone is given Read permission to all of the files and folders on the top level
of the system drive. Note that at this point, Cacls.exe does not recurse into the lower
folders.
pushd %SystemDrive%\
cacls.exe . /G administrators:f system:f everyone:r <%SystemRoot
%\zak\scripts\yesfile
cacls.exe * /C /G administrators:f system:f everyone:r <%SystemRoot
%\zak\scripts\yesfile

@rem
@rem BOOT FILES
@rem ==========
@rem only system and administrator need access to the boot files
@rem

Since users do not need any access to the boot files for Windows NT, all user
permissions for these files are removed.
cacls.exe boot.ini /G administrators:f system:f <%SystemRoot
%\zak\scripts\yesfile
cacls.exe ntbootdd.sys /G administrators:f system:f <%SystemRoot
%\zak\scripts\yesfile
cacls.exe ntdetect.com /G administrators:f system:f <%SystemRoot
%\zak\scripts\yesfile
cacls.exe ntldr /G administrators:f system:f <%SystemRoot
%\zak\scripts\yesfile

@rem
@rem PROGRAM FILES
@rem =============
@rem
@rem First recurse through and just give read access to everyone to
everything
@rem in the Program Files

In the first of the folders in the root of the system drive, the Programs Files folder,
Acls.cmd recurses through, giving users Read permission to everything. The next few
lines after this grant exceptions to the global rule.
cacls.exe "Program Files" /c /t /g administrators:f system:f everyone:r
<%SystemRoot%\zak\scripts\yesfile

@rem Remove ability to view or use anything under Windows NT accessory


@rem directory

Cacls.exe "Program Files\Windows NT" /c /t /g administrators:f system:f


<%SystemRoot%\zak\scripts\yesfile

@rem open the Office and Templates subfolders of Msoffice


@rem for new file additions
@rem
@rem For the Template folder on the Far East platform it is called
Template
@rem and on other platforms it is called Templates

Now the Office and Templates directories are opened to allow for new additions.
cacls.exe "Program Files\Microsoft Office\Office" /e /g everyone:c <
%SystemRoot%\zak\scripts\yesfile
cacls.exe "Program Files\Microsoft Office\Templates" /e /g everyone:c <
%SystemRoot%\zak\scripts\yesfile
cacls.exe "Program Files\Microsoft Office\Template" /e /g everyone:c <
%SystemRoot%\zak\scripts\yesfile

@rem
@rem TEMP DIRECTORY
@rem ==============
@rem change permission on Temp folder to allow additions...
@rem

Go back up to the root and give users Change permissions on the Temp folder. Many
programs write to the Temp folder and will not function properly if this permission is
not given. However, by giving Change permission to a folder, you give users the
ability to delete the folder. This can be prevented by putting a dummy file in the
folder and making sure that users do not have any permissions on it that allow them
to delete it.
27

cacls.exe Temp /c /t /g everyone:c administrators:f system:f <


%SystemRoot%\zak\scripts\yesfile

@rem Users have been given Change permission on the Temp folder. This
means, however, that users
@rem can delete the folder as well. Prevent this by copying a file here
@rem and denying delete access to this file. Without being able to
delete the
@rem file, the Temp folder can not be deleted

copy %SystemRoot%\zak\scripts\yesfile Temp\secure.dir


cacls.exe Temp\secure.dir /g administrators:f system:f <%systemroot
%\zak\scripts\yesfile
attrib +h Temp\secure.dir

@rem
@rem SMS DIRECTORIES
@rem ===============
@rem

For system management server to run properly, users need Change permission on the
following two folders.
cacls.exe ms /c /t /g everyone:c administrators:f system:f <%SystemRoot
%\zak\scripts\yesfile
cacls.exe ms\sms\bin /c /t /g everyone:r administrators:f system:f <
%SystemRoot%\zak\scripts\yesfile

@rem
@rem SYSTEM DIRECTORY
@rem ================

First, users are given Read permission on all of the files in the %SystemRoot% folder,
and given Change permission on the folder itself. Some applications write to this
folder. If users are not given Change permission, these applications will not function
normally in all situations.
cd %SystemRoot%
cacls.exe * /c /g administrators:f system:f everyone:r <%SystemRoot
%\zak\scripts\yesfile
cacls.exe . /g administrators:f system:f everyone:c <%SystemRoot
%\zak\scripts\yesfile

Now permissions are applied to the folders under %SystemRoot%. Because


permissions are applied on an individual basis, you can modify Acls.cmd later for
your own purposes. Also, the %SystemRoot%\profiles folder needs a special set of
permissions because it handles ACLs differently than most other folders. In the next
series of commands, permissions are applied recursively down through each of the
folders. Later, permissions on a few of the folders themselves are changed to allow for
full functionality of applications.
cacls.exe config /t /c /g administrators:f system:f everyone:r <
%SystemRoot%\zak\scripts\yesfile
cacls.exe cursors /t /c /g administrators:f system:f everyone:r <
%SystemRoot%\zak\scripts\yesfile
cacls.exe help /t /c /g administrators:f system:f everyone:r <
%SystemRoot%\zak\scripts\yesfile
cacls.exe forms /t /c /g administrators:f system:f everyone:r <
%SystemRoot%\zak\scripts\yesfile
cacls.exe inf /t /c /g administrators:f system:f everyone:r <
%SystemRoot%\zak\scripts\yesfile
cacls.exe java /t /c /g administrators:f system:f everyone:r <
%SystemRoot%\zak\scripts\yesfile
cacls.exe media /t /c /g administrators:f system:f everyone:r <
%SystemRoot%\zak\scripts\yesfile
cacls.exe ShellNew /t /c /g administrators:f system:f everyone:r <
%SystemRoot%\zak\scripts\yesfile
cacls.exe system /t /c /g administrators:f system:f everyone:r <
%SystemRoot%\zak\scripts\yesfile
cacls.exe system32 /t /c /g administrators:f system:f everyone:r <
%SystemRoot%\zak\scripts\yesfile
cacls.exe SendTo /t /c /g administrators:f system:f everyone:c <
%SystemRoot%\zak\scripts\yesfile

@rem everything under profiles is maintained


cacls.exe profiles /g administrators:f system:f everyone:c <%SystemRoot
%\zak\scripts\yesfile

Now, all user permissions are removed for the following file types located in the
%SystemRoot%\ directory. Later, users are given read permission to specific .exe, inf,
and .hlp files.
@rem Access is denied to .inf files, .exe files and .hlp files under
system
cacls.exe *.inf /t /g administrators:f system:f <%SystemRoot
%\zak\scripts\yesfile
cacls.exe *.exe /t /g administrators:f system:f <%SystemRoot
%\zak\scripts\yesfile
cacls.exe *.hlp /t /g administrators:f system:f <%SystemRoot
%\zak\scripts\yesfile
cacls.exe *.txt /t /g administrators:f system:f <%SystemRoot
%\zak\scripts\yesfile
cacls.exe *.com /t /g administrators:f system:f <%SystemRoot
%\zak\scripts\yesfile
cacls.exe *.cpl /t /g administrators:f system:f <%SystemRoot
%\zak\scripts\yesfile

@rem
@rem EXCEPTIONS IN SYSTEM DIRECTORY
@rem ==============================
@rem open up the exceptions
@rem
29

Here, exceptions to the folders in the %SystemRoot% tree are applied. You must
allow users access to folders like Cookies, History, Occache, and, later, Temporary
Internet Files so Internet Explorer functions correctly. Some applications write to
System32. If users are not given Change permission, these applications do not
function properly. When help files are used, temporary files are automatically written
to the %SystemRoot%\Help folder. Help will not function properly if users are not
given Change permission. Finally, users do not need access to %SystemRoot
%\Repair, so none is given.
cd %SystemRoot%
cacls.exe system32 /e /g everyone:c <%SystemRoot%\zak\scripts\yesfile
cacls.exe help /e /g everyone:c <%SystemRoot%\zak\scripts\yesfile
cacls.exe forms /e /g everyone:c <%SystemRoot%\zak\scripts\yesfile
cacls.exe cookies /t /c /g administrators:f system:f everyone:c <
%SystemRoot%\zak\scripts\yesfile
cacls.exe history /t /c /g administrators:f system:f everyone:c <
%SystemRoot%\zak\scripts\yesfile
cacls.exe occache /t /c /g administrators:f system:f everyone:c <
%SystemRoot%\zak\scripts\yesfile
cacls.exe repair /t /c /g administrators:f system:f <%SystemRoot
%\zak\scripts\yesfile
cacls.exe system32\viewers /t /c /e /g everyone:r <%SystemRoot
%\zak\scripts\yesfile

@rem
@rem do printers
@rem

For printing to work properly, users need Change permission on the following two
folders:
cacls.exe system32\spool\printers /t /c /e /g everyone:c <%SystemRoot
%\zak\scripts\yesfile
cacls.exe system32\spool\drivers /t /c /e /g everyone:c <%SystemRoot
%\zak\scripts\yesfile

@rem
@rem allow write in the "Temporary Internet Files"
@rem

cacls.exe "Temporary Internet Files" /t /c /e /g administrators:f


system:f everyone:c <%SystemRoot%\zak\scripts\yesfile

@rem
@rem OPEN UP SPECIFIC FILE EXCEPTIONS
@rem

Earlier in this script, all access to these files was removed. Users, however, need
access to some of these files so Office 97 and Windows NT Workstation function
properly.
cd %SystemDrive%\
cacls.exe explorer.exe /t /e /g everyone:r
cacls.exe iexplore.exe /t /e /g everyone:r
cacls.exe userinit.exe /t /e /g everyone:r
cacls.exe nddeagnt.exe /t /e /g everyone:r
cacls.exe systray.exe /t /e /g everyone:r
cacls.exe runapp.exe /t /e /g everyone:r
cacls.exe net.exe /t /e /g everyone:r
cacls.exe net1.exe /t /e /g everyone:r
cacls.exe mapisvc.inf /t /e /g everyone:r
cacls.exe mapisp32.exe /t /e /g everyone:r
cacls.exe newprof.exe /t /e /g everyone:r
cacls.exe con2prt.exe /t /e /g everyone:r
cacls.exe fixprf.exe /t /e /g everyone:r
cacls.exe winhlp32.exe /t /e /g everyone:r
cacls.exe mspaint.exe /t /e /g everyone:r
cacls.exe mplay32.exe /t /e /g everyone:r
cacls.exe sndrec32.exe /t /e /g everyone:r
cacls.exe wordpad.exe /t /e /g everyone:r
cacls.exe packager.exe /t /e /g everyone:r
cacls.exe windows.hlp /t /e /g everyone:r
cacls.exe taskmgr.exe /t /e /g everyone:r

@rem localized versions need access to internat.exe


cacls.exe internat.exe /t /e /g everyone:r

@rem so that logon scripts can be executed


cacls.exe cmd.exe /t /e /g everyone:r

@rem
@rem for 16 bit MS-DOS apps
@rem

These files are all necessary to run MS-DOS applications.


cacls.exe %SystemRoot%\system32\ntvdm.exe /e /g everyone:r <
%SystemRoot%\zak\scripts\yesfile
cacls.exe %SystemRoot%\system32\wowexec.exe /e /g everyone:r <
%SystemRoot%\zak\scripts\yesfile
cacls.exe %SystemRoot%\system32\command.com /e /g everyone:r <
%SystemRoot%\zak\scripts\yesfile

@rem Files Office tries to write to.

For Office to be fully functional, users must be given Change permission to the
following files.
cacls.exe %SystemRoot%\forms\frmcache.dat /e /g everyone:c
cacls.exe %SystemRoot%\forms\msforms.twd /e /g everyone:c
cacls.exe outlook.prf /t /e /g everyone:r
cacls.exe artgalry.cag /t /e /g everyone:c
cacls.exe %SystemRoot%\*.acl /c /e /g everyone:c <%SystemRoot
%\zak\scripts\yesfile
cacls.exe outlook.prt /t /e /g everyone:c
31

cacls.exe xl8galry.xls /t /e /g everyone:c


cacls.exe gr8galry.gra /t /e /g everyone:c
cacls.exe custom.dic /t /e /g everyone:c
cacls.exe mlcfg32.cpl /t /e /g everyone:r

@rem
@rem this will leave access to all dlls, etc. so users should
@rem be able to run IE (which is under Plus!) and load DLLs but
@rem will not be able to launch any applications
@rem

@rem lock everything related to zak. You should keep zak secure and
available in case
@rem you need to reapply some zak stuff during upgrades, etc

cacls.exe %SystemRoot%\zak /t /c /g system:f administrators:f <


%SystemRoot%\zak\scripts\yesfile
cacls.exe %SystemRoot%\zakboot1.cmd /g system:f administrators:f <
%SystemRoot%\zak\scripts\yesfile
cacls.exe %SystemDrive%\*.log /t /c /g system:f administrators:f <
%SystemRoot%\zak\scripts\yesfile

Hide.cmd
Now that Acls.cmd has placed more stringent security on the local file system,
Hide.cmd runs to hide the local file system.
REM
REM This is used to hide the files on the system
REM

First, Hide.cmd scans down the %SystemDrive%\ folder structure, making all of the
files and folders hidden. The For loop scans through the folder structure for each file,
i, and carries out the command attrib +h <filename>. This gives the hidden
attribute to all files on the System Drive.
attrib +h /s %SystemDrive%\*.*
For /R %SystemDrive%\ %%i in (.) do attrib +h "%%i"

Local user profiles must not be hidden.


attrib -h /s %SystemRoot%\profiles\*.*
For /R %SystemRoot%\profiles %%i in (.) do attrib -h "%%i"

REM
REM Some folders and files don't get the right permissions because
REM they have already been marked as system. These are covered here
REM

The attributes of all files are hidden only; you must give the system files their system
attributes again.
attrib +h +s %SystemRoot%\fonts
attrib +h +s %SystemRoot%\tasks
attrib +h +s %SystemRoot%\wintrust.hlp
attrib +h +s %SystemDrive%\boot.ini

REM unhide the zak\scripts folder files

Because batch files do not always run well when they are hidden, they are unhidden
here. Because user permissions were already removed from these files in Acls.cmd,
unhiding them provides little threat.
attrib -h %SystemRoot%\zak\scripts\*.*

REM
REM unhide the exchange.prf file in the c:\temp folder. This is in case
it
REM got left behind
REM

attrib -h %SystemDrive%\temp\exchange.prf

Customizing the Methodologies


Rarely does a situation present itself that corresponds directly to either the
AppStation or TaskStation preconfigured rules. Typically, the methods demonstrated
in the AppStation and TaskStation examples provided with ZAK should be modified
for your own individual purposes. Even now, you might be implementing some of
these methodologies on your network. For example, if you are using roaming profiles
or system policies to redirect a users data folder to a server, or if you have created a
net boot disk and run unattended installations of Windows NT onto client computers,
then you are already using zero administration methodologies. The possible
variations to the examples provided here are limitless. This section, however,
highlights some of the major methodologies and tools that can significantly change a
users and administrators experience.

CMD.EXE
The Acls.cmd places ACLs on Cmd.exe to allow execution of this file by everyone. If
you do not want task-based users to have execute permission to this file but you still
want to use batch files in the users logon scripts, you must provide remote access to
Cmd.exe at logon time. You can provide the full path to the remote Cmd.exe in the
users logon script line of their profile. Furthermore, you must update the user
accounts in User Manager to run the remote Cmd.exe when executing the logon
script.

Local Security Cacls.exe


Cacls.exe is used to view or change the access control lists on files. In both the
TaskStation and AppStation, Cacls.exe is used extensively in the ZAK custom batch
file, Acls.cmd, to place more stringent security on the local file system.
33

If, on your network, you want to install Office 97 and Internet Explorer, you can use
Acls.cmd as it is. If, however, you want to install a different set of applications, then
you must determine where the applications write information on the local file system,
and then create or modify Acls.cmd. Furthermore, if you decide that this type of
security is not necessary, then you are not required to use Acls.cmd at all.

Hiding the File System ATTRIB +H


Beyond placing local security on the files, the AppStation and TaskStation
installation scripts also hide the local file system. This is done in the ZAK custom
batch script, Hide.cmd. The MS-DOS command Attrib is used, which allows for the
viewing and changing of file attributes. This script globally changes every files
attributes to hidden. If you do not want the file system to be hidden, or feel that only
parts of it should be hidden, you can modify this script.

System Policies
The AppStation and TaskStation make use of several policies provided with
Windows NT, the Office 97 Resource Kit, the Internet Explorer Administration Kit,
and a few custom-built policies. All of these policies have been combined and are
provided to you with either the AppStation or TaskStation installation. Because the
AppStation is more complex, it makes use of more policies than the TaskStation. It is
likely that you will want to modify the policies provided with ZAK for your own
environment. Furthermore, you might want to create a few of your own system
policies, especially for any custom business applications. For more information on
configuring or creating system policies, see System Policies later in this document.

Updating Your Distribution Point


When there is a new release of a product, like a new service pack, Office 97, or
Internet Explorer, you might want to update your distribution point, replacing the old
files to include the new. Note that updating the distribution point files does not update
the clients.

Updating the Service Pack


If you ever want to update your ZAK distribution point to include a newer service
pack, you must delete the current service pack files and copy the new files into the
service pack folders. Doing this saves you the time of reinstalling the entire
distribution point merely to update the service pack. For details on where to copy the
new service pack files, see Chaining the Service Pack Installation.

Updating for new releases of Microsoft Office 97


If you want to replace your Office 97 distribution files with newer versions, you must
delete all files in the netapps\off97\msoffice and netaps\off97\msapps folders. Then
run the Office 97 administration installation program (setup/a) to copy the new Office
files into these folders.
Note

Updating Internet Explorer


Internet Explorer is installed as a difference file using the Sysdiff utility. The
difference file is stored in %SystemRoot%\zak\scripts and called Msie302.dif. To
update the Msie302.dif file, you must generate a new difference file on a reference
client. For details on Sysdiff, see the Guide to Automating Windows NT Setup.

ZAK Setup
This section lists the requirements for ZAK, and presents instructions for installing
the software, creating user groups, setting up user accounts, enabling the ZAK
policies, and creating software distribution points.

Prerequisites for Evaluating ZAK


The AppStation and TaskStation deployments are intended for a pilot network to
demonstrate the capabilities of system policies. The AppStation and TaskStation are
only examples of what you can do with ZAK. For more information, see ZAK
Methodologies.
The ZAK methodologies information is intended for experienced system
administrators. Knowledge of Microsoft Office is also required if you plan to
implement and administer Office installations.

Minimum Network Configuration


One computer running Windows NT Server version 4.0
Two computers capable of running Windows NT Workstation version 4.0
All computers must be running TCP/IP

Minimum Server Requirements


A Primary Domain Controller (PDC)
At least 1 GB of free hard drive space
At least 32 MB RAM (at least 64 if using Exchange)
CD-ROM drive
Windows NT Server version 4.0
File system should be NTFS
Note

35

Minimum Workstation Requirements


Hardware configurations should be as similar as possible
Network cards must be unattendable. Refer to the Windows NT Deployment
Guide Automating Windows NT Setup for a list of unattendable network cards.
486 or higher processor (recommended Pentium 90 or higher)
16 MB RAM or higher (recommended 32 MB or higher)
Clean hard drive with at least 300 MB of free space
MS-DOS network boot disk

Other Requirements
Zero Administration Kit compact disc
Service Pack 3 or later for Windows NT Server version 4.0
Windows NT Workstation version 4.0
Microsoft Office 97 (for AppStation only)
Microsoft Windows NT Workstation Deployment Guide Automating
Windows NT Setup
Windows NT Workstation Resource Kit
Office 97 Resource Kit
Microsoft Exchange Server 4.5 if you want to test the Microsoft Outlook client
with Exchange

Your copy of Windows NT 4.0 must be the full version. The Windows NT 4.0 upgrade
does not work with ZAK.

Creating the ZAK Client Distribution Point


ZAK Setup, provided with the ZAK compact disc, creates either a TaskStation or
AppStation distribution point on your server. These distribution points can then be
used for unattended installations of ZAK clients. To create this distribution point, you
need Windows NT Workstation version 4.0, the latest service pack, and, in the case of
AppStation, Office 97. This distribution point also includes the policy template files
and a pre-configured policy file. An overview of the entire setup process for both the
server and the clients is provided in the following picture.
The ZAK Setup process

Preparing the Server for the Distribution Point


Server setup has two major parts: automated and manual. ZAK Setup provides
instructions for both, as described in the following sections.

Installing the AppStation Option


To get started
1. Insert the CD labeled ZAK Setup in the CD ROM drive.
Note

37

2. Switch to the root of your CD ROM drive. Go to the folder of the platform of the
computer you are running Zaksetup.exe from. Double-click Zaksetup.exe.
You are presented with the Zero Administration Kit for Windows NT 4.0 Setup
dialog box.

3. Click Next to proceed.


If you agree to the terms of the End User License Agreement, the Choose Client
Computer Platform dialog box displays, prompting you to select one of the
following computer platforms:
Intel x86 Platform
Digital Alpha AXP Platform

What gets installed depends on the platform you select, and requires that you have
the appropriate versions of Windows NT, Service Pack, and Microsoft Office
software for the platform you specify.
4. In the Choose Client Computer Platform dialog box, select the appropriate
platform for your computer: either Intel x86, or certain localized versions of ZAK,
and click Next.

To select the type of install


Setup prompts you to install the Setup files for AppStation or TaskStation in the
following Configurations dialog box.
Note

39

In the Configurations dialog box, select AppStation, and click Next to proceed.

To specify the root of the distribution point

To provide security to control file access, you should use an NTFS drive for the ZAK
distribution point.
Note

In the Software Location dialog box, in Location, type a


<drive_letter>:\<directory_name> in which to store the files on the server, and
click Next. The default location is: C:\ZAKAppDist.
This path is the root of the distribution point. You can use a remote server by
clicking Browse and then clicking Network, or by typing the UNC path to a
network share. The server that you specify should be accessible to AppStation
users and preferably should be a member of the AppStation users domain.

To specify the server and share name for Office 97 installations

The folder you specify in this step must be shared to permit Everyone Full Access so
that users can write to their working folder.
Note

41

1. In the Network Applications Share dialog box, specify the following


information.
Network Application DirectoryType the complete path to the folder in which
you are installing applications that clients can run from the server. The default
location is c:\netapps. This should be an NTFS partition.
Network Applications Server NameType the name of the server that will host
the AppStation software.
Network Applications Share NameType the share name you want to use for
application installations.
Or
Click Browse to specify a different server location in the domain from which you
want clients to run applications.
AppStation clients use Microsoft Office in Run From Server mode. This means
that Office is installed on the server, and the clients must connect to the server to
run an Office application. You must provide ZAK Setup with the share name that
you create to allow the AppStation clients to connect to your server.

This share is not automatically created. Setup is gathering this information now
for use during client installation. During the manual portion of Setup, you will be
instructed to create this share.
2. Click Next to proceed.

3. Specify the drive letter used to connect to the network applications share, as
indicated in the Network Applications Drive dialog box. By default, the
AppStation clients use Office 97 as their network application. Office 97 can be
configure to use a drive letter or UNC names. The example policy file uses the
default drive letter O:.
4. Click Next to proceed.
At this point, the Install Microsoft Office as Network Application Suite dialog
box is displayed.
5. In the Install Microsoft Office as Network Application Suite dialog box, select
Install Microsoft Office as Network Application Suite if you plan to install
Microsoft Office, and click OK. If you are not installing Office, clear the check
box.

To specify where to copy the administrative files


43

In the ZAK Admin Files dialog box, in Location, specify where you want ZAK
Setup to copy the administrative files. The default location is C:\Zakadmin.
ZAK Setup creates the folder you specify and three sub-folders, Logon Scripts,
Policy Files, and Policy Templates. These files are required on the PDC, and Setup
recommends that you copy these files to a folder on your PDC.
To configure client setup
In the Domain Administrator Information dialog box, specify the following
information.
To complete Setup on the client, you need to provide a domain administrator
account to access the distribution servers to complete the unattended installation
of the clients. We recommend that Administrators create an account with Domain
Admin privileges to specifically handle this task.
Domain NameType the name of the domain that clients will log on to during
setup.
UsernameType a user account name.
PasswordType the user password.
Confirm PasswordType the same password you typed in Password.
45

To specify an administrator password to use on client computers


1. In the Local Administrator Information dialog box, in Password, type the
administrator password that will be used on the client computers. Then type the
same password in Confirm Password.
When Windows NT Workstation is installed, an administrator account is created
on the computer with a blank default password. You can use the preceding dialog
box to change this password to something more secure.
2. Click Next to proceed.
To configure printer connections
1. In the Printer Information dialog box, specify the following options.
Printer ServerType the print server name
Printer ShareType the share name of a printer
If you do not want to have a network printer, click Next.
2. Click Next to proceed.
ZAK Setup will only preconfigure Windows NT 4.0 to Windows NT 4.0 printing.
To add more printers, you can edit the user logon scripts created. Each additional
printer can be specified with /c \\<printserver>\<printshare> added to the line
executing Con2prt. See Appendix B for more information about Con2prt.
47

To configure AppStation clients for Exchange


If you dont have an exchange server, click Next to continue.

1. In the Exchange Information dialog box, type the name of your Exchange Server
in Exchange Server.
2. Click Next to proceed.
ZAK Setup now begins copying its own files to your server. This takes a couple of
minutes.
After ZAK Setup has finished processing its own files, it prompts you for the Zero
Administration Kit files.

To load the files onto your server


1. Type the complete path to the location of the Zero Administration files:
<drive_letter>:\<ZAK_directory_name>\<os_platform> . For example, type:
F:\ZAK\i386, and click OK.
Or
To locate the files on your network, click Browse.
2. Type the complete path to the location of the Windows NT Workstation Setup
program (for the appropriate platform); for example, J:\winnt\i386, and then
click OK.
Note

Or
To locate the files on your network, click Browse.
3. Type the complete path to the location of the Windows NT Service Pack 3 Setup
program (for the appropriate platform); for example, I:\ sp3\i386, and then click
OK.
Or
To locate the files on your network, click Browse.

To install a Microsoft Office network share


If you chose earlier to install Microsoft Office 97, you are now prompted for the
location of the Office files.

1. Type the complete path to the location of the Microsoft Office 97 files (for the
appropriate platform); for example, I:\Office97 and then click OK.
Or
To locate the files on your network, click Browse.
ZAK Setup then starts Microsoft Office 97 Setup. Before starting Office 97 Setup,
Setup searches for a previous installation of Office. If an Office installation is
found in the \netapps\off97 share, the Office Installation Exists on Target dialog
box appears. In this dialog box, you can keep the existing Office installation by
clicking Skip Installing Office, or reinstall Office by clicking Reinstall Office.

If you choose to reinstall Office 97, you need to delete the existing Office files and
Msapps files manually.

The Office 97 Admin Setup requires information related to choices made during
the setup of the Network Applications share. The information you entered is
provided again to assist with your setup of Office 97 in run-from-server mode.
Note

49

Before you proceed with Office setup, please make note of the location of the
Destination folder and the MSAPPS folder, and the Path and Drive indicated in
the Office Setup Instructions dialog box you will need this information
during Office Setup.

2. To proceed with Microsoft Office installation, click OK in the Office Setup


Instructions dialog box. You must step through the process of installing Office,
making sure to enter the appropriate data.

Given the choices in the previous example of setup, the following dialog boxes show
an example of an installation of Office in run-from-server mode.
Sample run-from-server Office installation
1. Click OK to install Microsoft Office in the folder shown.
51

2. Click OK to install the network files in the folder shown.


3. Select the O: drive.
The preconfigured policy file used for ZAK uses the O: drive by default to look for
the Office share on the server.
4. Select Drive Letter, and click Continue.
5. Select the server location of the shared files.

The automated portion of ZAK Setup for the AppStation distribution point is now
complete. To read about the rest of the steps required to create the ZAK distribution
point, see Organizing Files, Shares, and User Accounts on the Server.

Manual AppStation Setup


This section explains how to do the automated portion of ZAK Setup for the
AppStation manually.
To install Windows NT Workstation 4.0 and the latest service pack for
distribution
1. Create the Netapps, Zakadmin, and ZakAppDist folders in the root of the C: drive
on your server.
2. Under ZakAppDist, create a new folder and name it, Netsys.
3. Insert the Windows NT Workstation 4.0 CD into the servers CD-ROM drive.
4. From the CD, copy the folder containing the files specific to the client platform to
the Netsys folder. For example, if the clients were all x86 architecture and the CD
was inserted into drive E:, you would type:
xcopy /s E:\i386 c:\ZakAppDist\Netsys\i386

5. In the Netsys\<client platform> folder, build the $oem$ folder structure as


pictured next.
53

6. Insert the latest service pack CD and copy the service pack files to the appropriate
folders as described next.

xcopy /s e:\<client platform>\*.* c:\ZakAppDist\Netsys\<client


platform>\$oem$\$$\SP
xcopy /s e:\spcdrom.40 c:\ZakAppDist\Netsys\<client platform>\$oem$\$
$\SP
xcopy /s e:\disk1 c:\ZakAppDist\Netsys\<client platform>\$oem$\$$\SP

Configuring the ZAK-specific files on the server


Now, the custom batch files, Registry files, difference files, and .dlls used during
setup must be modified and moved to the appropriate folders.
To configure the ZAK-specific files on the server
1. Insert the ZAK CD into the CDROM drive of the server.
2. Copy the utilities used by ZAK Setup from <client platform>\tools to
ZAKAppDist\Netsys\<client platform>\$oem$\$$\ZAK\Tools. These tools are:
Instsrv.exe
Sysdiff.exe

3. Copy the Utilities used on the ZAK client from <client platform>\tools to
ZAKAppDist\Netsys\<client platform>\$oem$\$$\System32. These utilities are:
Con2prt.exe Runapp.exe
Floplock.exe Shutdown.exe
Fixprf.exe

4. From the CD, copy <client platform>\scripts\Cmdlines.app to


ZAKAppDist\Netsys\<client platform>\$oem$\Cmdlines.txt
5. From the CD copy <client platform>\scripts\ZakBoot1.cmd to
ZAKAppDist\Netsys\<client platform>\$oem$\$$ ZakBoot1.cmd.
Note

6. Copy files from the ZAK CD under <client platform>\scripts to


ZAKAppDist\Netsys\<client platform>\$oem$\$$\ZAK\Scripts. These files are:
Acls.app NewTemp.reg Yesfile
Appcmds.cmd NoAutolog.reg Zak.hlp
Autolog.reg Nosavcon.reg Zakb1wrk.app
Cleanup.cmd Off97.cmd
Hide.cmd Runonce.reg

You must modify some of these files for the AppStation clients to work properly.
7. Zakb1wrk.app, Autolog.reg, and Off97.cmd have instructions in them on how
they can be modified to work on your pilot network.

Notepad can occasionally leave hidden characters in files that stop batch scripts from
running. If you are experiencing problems, such as your batch scripts not fully
executing, you can use the MS-DOS Edit command instead of Notepad.

8. In ZAKAppDist\Netsys\<client platform>\$oem$\$$\Zak\Scripts, rename Acls.app


to Acls.cmd and Zakb1wrk.app to Zakb1wrk.cmd.
9. From the CD, copy <client platform>\diffs\msie302.dif to
C:\ZakAppDist\Netsys\<client platform>\$oem$\$$\zak\scripts\.
10. If you are using system management server, copy <client
platform>\links\smsrun32 to C:\ZakAppDist\Netsys\<client platform>\$oem$\$
$\zak\scripts\.

Setting up the Logon Scripts and Policy Files


You must also copy the logon script, Applogon.cmd, from the ZAK CD to the
appropriate place for your pilot network. If the domain only has one controller, copy
the Applogon.cmd file to the logon share of the PDC. This is usually %SystemRoot
%\System32\Repl\Import\Scripts. However, if the domain has multiple controllers
you must ensure that Applogon.cmd is in the logon share of each of the domain
controllers. The best way to do this is to place Applogon.cmd in %SystemRoot
%\System32\Repl\Export\scripts and configure directory replication to all other
domain controllers. Consult the Windows NT Server Resource Kit for information
about directory replication.
You will have to modify Applogon.cmd for your pilot network. Applogon.cmd has
instructions as to how to modify it.
To copy the Zakadmin files to the appropriate folders
1. In C:\Zakadmin, create the Logon scripts, Policy files and policy templates
folders.
2. From the ZAK CD, copy <client platform>\policies\*.adm to C:\Zakadmin\policy
templates.
3. Also, copy <client platform>\policies\ntconfig.pol to C:\Zakadmin\policy files\.
Change the attributes of ntconfig.pol, so that it is not Read Only.
Note

55

Installing Microsoft Office on the server for Client


Distribution
Finally, you must install Microsoft Office on the distribution point. On your pilot
network, it is fine if this distribution point is on the PDC. However, in a true
enterprise environment, you should distribute the load between servers more evenly,
and place this distribution point on a different server.
To install Microsoft Office on the server for client distribution
1. In the Netapps folder on your server, create the following folder structure.

2. From the ZAK CD copy <client platform>\links\explorer.lnk to C:\Netapps\start


menu\programs\
3. From the ZAK CD, copy <client platform>\scripts\exchange.prf to
C:\Netapps\exchgprf\
4. Remove the ZAK CD and insert the Microsoft Office 97 CD.
5. In the Microsoft Office CD, run Setup /a
6. During Setup, make sure that the MSOffice and MSApps folders are placed in
Netapps\off97\MSOffice and Netapps\off97\MSApps respectively and that the
shared files are stored on the server.
See the portion of Installing the AppStation Option that discusses Office 97
details.
7. Remove the Microsoft Office CD and reinsert the ZAK CD.
8. Rename C:\Netapps\off97\msoffice\off97_bb.dll to off97_bb.old.
9. From the ZAK CD, copy <client platform>\fixes\off97\off97_bb.dll to
C:\Netapps\off97\msoffice\.

Off97_bb.dll is a library file that Office uses. ZAK provides an updated version of this
library so that Office functions properly in a zero administration environment,
complete with hidden and secure files. If you are using a localized version of ZAK
that does not come with its own version of Off97_bb.dll, you can download
Off97_bb.dll from http:\\www.microsoft.com.
Note Note

To complete the ZAK distribution server setup, see Organizing Files, Shares, and
User Accounts on the Server.

Installing the TaskStation Option


To get started
1. Insert the CD labeled ZAK Setup in the CD-ROM drive.
2. Switch to the root of your CD-ROM drive. Go to the folder of the platform of the
computer you are running Zaksetup.exe from. Double-click Zaksetup.exe.
You are presented with the Zero Administration Kit for Windows NT 4.0 Setup
dialog box.
3. Click Next to proceed.
If you agree to the End User License Agreement, the Choose Client Computer
Platform dialog box appears, prompting you to select one of the following
computer platforms:
Intel x86 Platform(US)
NEC98 Platform (for Japanese version only)

What gets installed depends on the platform you select, and requires that you have
the appropriate versions of Windows NT Workstation, and service pack.

4. In the Choose Client Computer Platform dialog box, select the appropriate
platform for your computer: either Intel x86, or NEC98 (for Japanese version
only), and click Next.

To select the type of installation


Setup prompts you to install the Setup files for AppStation or TaskStation in the
Configurations dialog box.
In the Configurations dialog box, select TaskStation, and click Next to proceed.

To specify the root of the distribution point

To provide security to control file access, it is recommended that you use an NTFS
drive for the ZAK distribution point.

In the Software Location dialog box, in Location, type a


<drive_letter>:\<directory_name> in which to store the ZAK Client Setup files on
the server, and click Next. The default location is: C:\ZAKTaskDist.
This path is the root of the distribution point. You can use a remote server by
clicking Browse and then clicking Network, or by typing the UNC path to a
network share. The server that you specify should be accessible to TaskStation
users and preferably should be a member of the TaskStation users domain.
57

To specify where to copy the administrative files


In the ZAK Admin Files dialog box, in Location, specify where you want ZAK
Setup to copy the administrative files, and click Next. The default location is
C:\ZakAdmin.
Or
Click Browse to specify a different location on your network.
ZAK Setup creates the folder you specify and three sub-folders, Logon Scripts,
Policy Files, and Policy Templates. These files are required on the PDC, and Setup
recommends that you copy these files to a folder on your PDC.

To configure client setup


To complete Setup on the client, you must set up a domain administrator account to
access the distribution servers to complete the unattended installation.

In the Domain Administrator Information dialog box, specify the following


information.
Domain NameType the name of the domain that the clients will logon to
during setup.
UsernameType a user account name.
PasswordType the user password.
Confirm PasswordType the same password you typed in Password.

To specify an administrator password to use on client computers


When Windows NT 4.0 is installed, an administrator account is created on the
computer with a blank default password. You can use ZAK Setup to change this
password to something more secure by using the Local Administrator Information
dialog box.

1. In the Local Administrator Information dialog box, in Password, type the


administrator password that will be used on the client computers. Then type the
same password in Confirm Password.
2. Click Next to proceed.

To configure printer connections


1. In the Printer Information dialog box, specify the following options.
Printer ServerType the print server name.
Printer ShareType the share name of a printer.
2. Click Next to proceed.
ZAK Setup will only pre-configure Windows NT 4.0 to Windows NT 4.0 printing.
To add more printers, you can edit the user logon scripts created. Each additional
printer can be specified with /c\\<printserver>\<printshare> added to the line
executing Con2prt. See Appendix B for information about Con2prt.
ZAK Setup begins copying its own files to your server. This takes a couple of
minutes.

To load the files onto your server


1. Type the complete path to the location of the Windows NT Workstation files (for
the appropriate platform), for example; J:\winnt\winnt40.wks\i386, and then
click OK.
Or
To locate the files on your network, click Browse.
After the files are copied, Setup displays the Locate Source Files dialog box for
the Service Pack 3 (or later) software.
2. Type the complete path to the location of the Windows NT Service Pack 3 files
(for the appropriate platform); for example; I:\svcpack\sp3\i386, and then click
OK.
Or
To locate the files on your network, click Browse.
3. When the files are done copying, click Finish.

The automated portion of ZAK Setup for the TaskStation distribution point is now
complete. To read about the rest of the steps required to create the ZAK distribution
point, see Organizing Files, Shares, and User Accounts on the Server.

Manual TaskStation Setup


This section explains how to do the automated portion of ZAK Setup for the
TaskStation manually.
To install Windows NT Workstation 4.0 and the latest service pack for
distribution
1. Create the Zakadmin and ZakTaskDist folders in the root of the C: drive on your
server.
2. Under ZakTaskDist, create a new folder and name it, Netsys.
3. Insert the Windows NT Workstation 4.0 CD into the servers CD-ROM drive.
4. From the CD, copy the folder containing the files specific to the client platform to
the Netsys folder. For example, if the clients are all x86 architecture and the CD
is inserted into drive E:, you would type:
xcopy /s E:\i386 c:\ZakTaskDist\Netsys\<client platform>

5. In the Netsys\<client platform> folder, build the $oem$ folder structure as shown
next.
59

6. Copy the service pack files to the appropriate folders as described next.
xcopy /s e:\<client platform>\*.* c:\ZakTaskDist\Netsys\<client
platform>\$oem$\$$\SP
xcopy /s e:\spcdrom.40 c: c:\ZakTaskDist\Netsys\<client platform>\
$oem$\$$\SP
xcopy /s e:\disk1 c: c:\ZakTaskDist\Netsys\<client platform>\$oem$\$
$\SP

Configuring the ZAK-specific files on the server


Now, the custom batch files, Registry files, difference files, and .dlls used during
setup must be modified and moved to the appropriate folders.
To configure the ZAK-specific files on the server
1. Insert the ZAK CD into the CD-ROM drive of the server.
2. Copy the utilities used by ZAK Setup from <client platform>\tools to
ZAKTaskDist\Netsys\$oem$\$$\ZAK\Tools. These tools are:
Instsrv.exe
Sysdiff.exe

3. Copy the utilities used on the ZAK client from <client platform>\tools to
ZAKTaskDist\Netsys\$oem$\$$\System32. These utilities are:
Con2prt.exe Fixprf.exe
Floplock.exe Runapp.exe
Shutdown.exe

4. From the CD, copy <client platform>\scripts\Cmdlines.tsk to


ZAKTaskDist\Netsys\$oem$\Cmdlines.txt.
5. From the CD copy <client platform>\scripts\ZakBoot1.cmd to
ZAKTaskDist\Netsys\$oem$\$$ ZakBoot1.cmd.
6. Copy files from the ZAK CD under <client platform>\scripts to
ZAKTaskDist\netsys\$oem$\$$\ZAK\Scripts. These files are:
Note

ACLs.tsk NewTemp.reg Yesfile


Taskcmds.cmd NoAutolog.reg Zak.hlp
Autolog.reg Nosavcon.reg Zakb1wrk.tsk
Hide.cmd Runonce.reg

You must modify some of these files so the TaskStation clients work properly.
7. Zakb1wrk.tsk and Autolog.reg both have instructions on how they can be
modified to work on your pilot network.

Notepad can occasionally leave hidden characters in files that stop batch scripts from
running. If you are experiencing problems, such as your batch scripts not fully
executing, you can use the MS-DOS Edit command instead of Notepad.

8. In ZAKTaskDist\Netsys\$oem$\$$\ZAK\Scripts, rename Acls.tsk to Acls.cmd, and


Zakb1wrk.tsk to Zakb1wrk.cmd.
9. From the CD, copy <client platform>\difs\msie302.dif to
C:\ZakTaskDist\Netsys\<client platform>\$oem$\$$\zak\scripts\.
10. If you are using system management server, copy <client
platform>\links\smsrun32 to C:\ZakTaskDist\Netsys\<client platform>\$oem$\$
$\zak\scripts\.

Setting up the Logon Scripts and Policy Files


You must also copy the logon script, Tsklogon.cmd, from the ZAK CD to the
appropriate place for your pilot network. If the domain only has one controller, copy
the Tsklogon.cmd file to the logon share of the PDC. This is usually %SystemRoot
%\System32\Repl\Import\Scripts. However, if the domain has multiple controllers
you must ensure that Tsklogon.cmd is in the logon share of each of the domain
controllers. The best way to do this is to place Tsklogon.cmd in %SystemRoot
%\System32\Repl\Export\scripts and configure directory replication to all other
domain controllers. Consult the Windows NT Server Resource Kit for information
about directory replication.
You must modify Tsklogon.cmd for your pilot network. Tsklogon.cmd has
instructions as to how to modify it.
To copy the Zakadmin files to the appropriate folders
1. In C:\Zakadmin, create the Logon scripts, Policy files and Policy templates
folders.
2. From the ZAK CD, copy <client platform>\policies\*.adm to C:\Zakadmin\policy
templates.
3. Also, copy <client platform>\policies\ntconfig.pol to C:\Zakadmin\policy files\.
Change the attributes of Ntconfig.pol, so that it is not Read Only.

To complete the ZAK distribution server setup, see Organizing Files, Shares, and
User Accounts on the Server.
Note

61

Organizing Files, Shares, and User Accounts on


the Server
For the pilot network, you must create at least two groups and two user accounts.
These instructions assume that you have accepted all the defaults during Setup.
To create global groups for AppStation and TaskStation
1. Click Start, point to Programs, point to Administrative Tools, and click User
Manager for Domains.
2. Click User, and then click New Global Group.
The New Global Group dialog box is displayed.
3. In the New Global Group dialog box, in the Group Name text box, type
Appusers.
4. If any users or local groups appear in Members, select them and click Remove.
5. Click OK to add the group.
6. Repeat steps 2 through 5, but name the new group Taskusers.

The global group names must appear exactly as typed because they are referred to in
the predefined Zakconfig.pol policy file.

In User Manager for Domains, you must create user accounts to be added to the
Appusers or Taskusers global groups. However, before you create the user accounts,
you must create a users share on your server. When you create the user accounts, you
will configure them to use this share as their home folder.
To create the Users share
1. Create a folder called Users on the server.
2. Share this folder out, giving Everyone Full Control permission.

To create the user accounts


1. In User Manager for Domains, on the User menu, click New User.
2. Type the information required in the New User dialog box.
3. Click Profile.
4. In Logon Script Name type Applogon.cmd for AppStation clients and
Tsklogon.cmd for TaskStation clients.
5. In Connect, select U:
6. In To, type the path to the folder; for example \\<server name>\users\%username
%.
7. Click OK.
8. In the New User dialog box, click Groups.
9. Click either Appusers or Taskusers in Not Member of, and then click Add to add
the user to the group you created.
10. Click OK.
11. Click Add to add the new user to the domain.
12. Repeat this procedure.

After you create the user and group accounts, you must organize the files and shares
on the server. Assuming that you accepted all of the default file locations during
setup, ZAK has placed a set of folders on the root of your C: drive.
The Netapps folder is for the AppStation installation only. It stores all of the
Office 97 related information including the MSApps, MSOffice, and remote Start
menu folders.

The Netapps folder structure placed on the server during ZAK Setup

The Zakadmin folder contains all of the files used for administration on the server,
such as logon scripts, policy files, and policy templates. You will be instructed to
move these files to more appropriate locations below. The remaining folder,
ZAKAppDist or ZAKTaskDist, depending on which installation you choose, contains
the Windows NT Workstation files, the service pack files, the ZAK custom batch files,
as well as miscellaneous tools used during the installation process, such as Shutdown
and Sysdiff.
63

Zakadmin and ZakAppDist folder structures placed on the server during ZAK Setup

ZAK Setup has placed a logon scripts folder in a destination chosen by you during
Setup. By default this folder is located under Zakadmin\logon scripts.
To organize files and shares on the server
1. Domain Controllers
If your pilot network has one domain controller, copy all of the files that
Zakadmin\logon scripts contains to the netlogon share of the PDC (usually
%SystemRoot%\system32\Repl\import\scripts).
If your pilot network has multiple domain controllers, copy all of the files that
Zakadmin\logon scripts contains to %SystemRoot%\system32\Repl\export\scripts
and set up directory replication to all other domain controllers. See the
Windows NT Server Resource Kit for information on directory replication.
2. You must create the Netapps and Netsys shares on the server. Depending on the
choices you made during Setup, these shares can be located on the same server, or
on separate logon and distribution servers. Note that if you installed the
TaskStation, you do not have to create the Netapps share.
3. Share out the Netapps folder, giving Everyone Full Control on the share.
Note

4. Apply NTFS security to the Netapps folder and all subfolders. Give Everyone
Read permission, and give Domain Admins Full Control. Give Everyone Change
permission on the Netapps\off97\msoffice\Workdir folder.
5. Share out the ZakAppDist\Netsys folder, giving Domain Admins Read
permission. In the Access through Share Permissions dialog box, under Name,
remove the Everyone group from the permissions list..
6. Apply NTFS Security to this folder and all subfolders. Give Domain Admins Full
Control. In the Directory Permissions dialog box, under Name, remove the
Everyone group from the permissions list.

Netapps\off97\msapps\msinfo\MSInfo32.exe allows users to view system information


and will attempt to launch various administrative tools such as Control Panel and
Regedit. MSInfo32.exe is launched when a user clicks Help, clicks About <MS
Office Program Name>, and then clicks System Info. NTFS security should be
applied on this folder to give both Taskusers and Appusers No Access permissions.

To enable ZAK Policies


1. Click Start, point to Programs, point to Administrative Tools, and then click
System Policy Editor.
2. Click Options, and then click Policy Template.
3. Click all existing template files and then click Remove.
4. Click Add to add all the template files that were installed by ZAK Setup. The
template files are located in the Zakadmin\Policy Templates folder.
5. Click OK to close the Policy Template Options dialog box and load the
templates.
6. Open the Zakconfig.pol file in Policy Editor. Zakconfig.pol is located in the
Zakadmin\Policy files folder.
7. Double-click the Appusers policy.
8. In the Appusers Properties dialog box, click Zak Policies, click Windows NT,
click Drives, and then click Restrictions.
9. Make sure that Show only selected drives is selected.
10. Select Show only selected drives and from the drop down menu under Settings
for Show only selected drives select Only U:.
11. Click OK to close the Appusers Properties window.
12. If your test network has only one domain controller, save Zakconfig.pol to the
netlogon share of your PDC(usually %SystemRoot
%\system32\Repl\import\scripts) as Ntconfig.pol.
13. If your test network has multiple domain controllers, save Zakconfig.pol to
%SystemRoot%\system32\Repl\export\scripts and set up directory replication to
all other domain controllers. See the Windows NT Server Resource Kit for
information about directory replication.
14. Close System Policy Editor.
Note

65

You can verify your installation by viewing Netsys\i386\$OEM$\$


$\ZAK\scripts\Zakb1wrk.cmd in a text editor. This file is created by ZAK Setup based
on the information that you entered. Check each of the net use and net user
commands listed to make sure that their parameters, such as server names, shares,
account names and passwords are all accurate.
Opening a .cmd file will actually run it on your computer. To view a .cmd file, you
can right-click it and click Edit.

To build a reference client


1. Modify the sample Unattend.txt file that is on the ZAK CD in <platform>\scripts.
You must add the appropriate domain, an administrative account, and a password
for that domain. There are instructions provided in the file itself to help you. For
more information about Unattend.txt, see Guide to Automating Windows NT
Setup.
2. On the reference client, verify that you are installing onto a primary MS-DOS
partition, which is active.
3. Start your client with an MS-DOS network boot disk.
4. From the client, connect to the shared Netsys folder on the server.
5. Run <drive letter>:\<path to winnt.exe>\winnt.exe /u:<drive letter>:\<path to
unattend.txt>\unattend.txt /s:<drive letter>:\<path to winnt install files>. For
example, if you connected to the Netsys share with drive X: and your Unattend.txt
was on a floppy in drive A: you would type the following: x:\i386\winnt
/u:a:\unattend.txt /s:x:\i386.

To copy the Start menu


1. After Setup finishes, log on with the administrator account for the local computer
with the password that you supplied during setup.
2. Open Windows Explorer.
3. On the View menu, click Options, and then select Show all files.
4. Copy all of the .lnk files in %SystemRoot%\profiles\all users\start menu to the
Netapps\start menu folder located on the server.
5. Copy the .lnk files in %SystemRoot%\profiles\all users\start menu\programs to
the Netapps\start menu\programs folder located on the server.

You are now ready to install on the client computers.

How to make a Digital Alpha AXP computer into


a TaskStation client
To make a Digital Alpha AXP computer into a TaskStation client, you must set up
your logon servers and logon shares in your pilot network. If your pilot network has
more than one domain controller, you must set up directory replication so that the
policy file is replicated to all logon shares. If you are unfamiliar with directory
replication, consult the Windows NT Server Resource Kit.
To set up a Digital Alpha AXP TaskStation client
1. On your logon server, create a folder called ZAK Policy. From the ZAK CD, copy
files in Alpha\policies to this folder.
2. Open System Policy Editor.
3. Close any open policy files.
4. Click Options, then click Policy Template. In the Policy Template Options
dialog box, remove all existing policy templates.
5. Add all of the policy templates from the ZAK Policy folder that you created on the
server.
6. Click OK to close the Policy Template Options dialog box.
7. From the File menu, click Open and select the Ntconfig.pol file, also stored in
the ZAK Policy folder.
8. If your pilot network has only one domain controller, save Ntconfig.pol to the
logon share (usually Winnt\system32\Repl\Import\Scripts). If you have multiple
domain controllers, save Ntconfig.pol to Winnt\system32\Repl\Export\scripts and
configure directory replication for all domain controllers.

Next, you must create a distribution point on a server. You only need portions of the
ZAK files, so it is best to create a folder structure on your own, and then copy the
specified files.
To create a distribution point on the server
1. Create a folder for the root of the distribution point. Name it ZakAlphaDist.
2. In ZakAlphaDist, create a Scripts and a Tools folder.
3. From the ZAK CD, in the Alpha\Tools folder, copy the following files to
ZakAlphaDist\Tools:
Con2Prt.exe Runapp.exe
FlopLock.exe Shutdown.exe
Instsrv.exe Sysdiff.exe

4. From the ZAK CD, copy the following files from the Alpha\scripts folder to the
ZakAlphaDist\Scripts folder:
Acls.tsk Zak.hlp
Hide.cmd Zakb1wrk.tsk
Tskcmds.cmd Zakboot1.cmd
Yesfile

5. Rename *.tsk to *.cmd.


6. You must edit Zakb1wrk.cmd. You only need the lines that install Msie302.diff,
install the floppylock service, and the lines that call Acls.cmd and Hide.cmd.
67

7. Delete the lines that deal with Autolog.reg in Zakboot1.cmd.

Using Sysdiff, you must create a difference file to install IE. Sysdiff is located on the
Windows NT Workstation 4.0 CD in support\Deptools\Alpha\.
To create a difference file for Internet Explorer
1. On a computer with a clean installation of Windows NT Workstation 4.0 and
Service Pack 3, make sure all network connections are disconnected.
2. Click Start, click Run, and type sysdiff /snap msie302.snp.
3. Connect to the network share that has the Internet Explorer installation program
on it. Make sure that you do not select Reconnect at Logon when mapping a
drive to this share.
4. Install Internet Explorer.
5. Restart the computer.
6. Make sure that you are no longer connected to the share.
7. Click Start, click Run, and type sysdiff /diff msie302.snp msie302.dif.
8. Connect to the distribution point you have created.
9. Copy msie302.dif to the zak\scripts folder.

The client computer should only have a fresh installation of Windows NT 4.0
Workstation and the latest Service Pack.
To install on the Alpha AXP client
1. In the Winnt folder, create a folder called ZAK.
2. From the server, copy the ZakAlphaDist\Scripts folder to Winnt\ZAK\Scripts.
3. From the server, copy the ZakAlphaDist\Tools folder to Winnt\ZAK\Tools.
4. Move Winnt\ZAK\Scripts\Zakboot1.cmd to Winnt\Zakboot1.cmd.
5. Move The following files from Winnt\ZAK\Tools to Winnt\System32:
Con2Prt.exe Runapp.exe
Floplock.exe Shutdown.exe

Now you are ready to set up the local computer.


6. Run Zakboot1.cmd.

After the batch scripts have finished running, the computer should restart and be
ready for a TaskStation user to log on.

System Policies
This section describes how you can use system policies to simplify implementation of
a secure network.
A system policy is a file containing Registry configuration data for users, groups of
users, and specific computers. When a user logs on, logon server reads this file and
configures the local computers Registry accordingly, allowing the same local
computer to appear to function differently depending on the user. Because almost all
of the system and application configuration data is stored in the Registry, system
policies provide a powerful tool for customizing a users experience. System policies
are applied as part of the logon process, so they follow a user across the network.
Because of system policies, a user has the same desktop regardless of the actual
computer he or she is using.
You can use system policies to override Registry values for user or computer settings.
Policies are defined in a policy file, usually called Ntconfig.pol. When a user logs on
to the network, the logon server reads Ntconfig.pol, and the Registry is configured
accordingly.

System Policies for Users or Groups


Although you can use system policies to configure most user-configurable Registry
settings, the default options in System Policy Editor are more limited. Some of the
default policies for users and groups are described next. For a comprehensive table
listing all of the default policies for both users and computers, see Configuring
System Policies later in this section.
Some default policies you can set for users and groups are:
Control Panel
Restrict user activity in the Display tab in Control Panel or deny any access to the
Display tab.
Desktop
Use standard wallpaper and color schemes.
Shell
Restrict what appears on the desktop and restrict the use of the Run, Find, and
Shut Down commands. You can also disable the Shutdown command.
System
Disable the Windows NT Registry Editor (Regedt32.exe) and Windows 95
Registry Editor (Regedit.exe) so that users cannot edit the Registry files. You can
also provide a list of available Windows-based applications. Any application not
in the list is unavailable to users.
Windows NT Shell
Create a custom user interface instead of Explorer.exe. You can create custom
folders by entering paths to program items, desktop icons, startup items, Network
Neighborhood items, and Start menu items that you want to come from a location
other than user profile folders. You can also customize the entire Start menu.
Windows NT System
Select Parse Autoexec.bat to enable Windows NT to read the environment
variables from this file and merge them with the users environment variables.
You can also disable the Task Manager and set whether to show welcome tips at
logon.
69

The following example shows the system policies you can set for the default user,
specific named users, or groups of users. The settings for each of these categories are
described in Configuring System Policies later in this section.

Policy sheet for Default User

System Policies for Computers


A default system policy can be set up for a given computer, as well as for a user or
group of users. Computer policy complements user policy. However, if the policies
conflict, user policy overrides computer policy.
Computer settings in system policies prevent users from modifying the system
configuration settings for the operating system, ensuring that the operating system
starts in a predictable way. Some of the default policies for computers are described
next. For comprehensive tables listing all of the default policies for both users and
computers see Configuring System Policies later in this section.
Some default policies you can set for computers are:
Network
Provide remote update of system policies instead of updating from Ntconfig.pol on
domain controllers. By entering a path to a different policy file, you can enable
manual update of the policy file in a location other than the server location.
Load balancing enables computers running Windows 95 to take policies from
multiple logon servers. Enabling load balancing prevents bottlenecks on large
networks when many users try to access the same policy file.
In addition, you can configure the network to display error messages when a
policy cannot be applied.
System
Specify the contents of the Run entry, which is used to specify which applications
should run when the computer starts.
You can also change default Simple Network Management Protocol (SNMP)
configuration by adding or removing communities, managers, and public
community traps. The defaults for these settings are established when the SNMP
service is configured for the host.
Windows NT Network
Turn hidden drive sharing on or off for either Windows NT Workstation or
Windows NT Server.
Windows NT Printers
Disable the print spooler browse process that periodically sends information to
other print servers about which printers the server shares. Browsing consumes
CPU and network capacity, which might not be necessary for some print
operations.
You can change the priority of print job assignments to ports and also set the print
spooler to beep every 10 seconds if an error condition occurs for a remote print
job.
Windows NT Remote Access
Set a maximum number for unsuccessful authentication retries and a maximum
time limit for authentication. You can also set the time interval between call-back
attempts and a time limit for automatic disconnection from the server.
Windows NT Shell
Configure custom folders by entering paths to Start menu, Desktop, Startup, or
Programs folders. You can provide locations for custom desktop icons, provide
applications you want in the Startup folder, or even replace the entire Start menu.
If these policies are also set in a user policy, the user policy will override the
computer policy.
Windows NT System
System securitySet logon policy for user accounts, including creating a logon
banner and enabling or disabling automatic logon. Automatic logon allows the
user to bypass the CTRL+ALT+DELETE key combination and logon dialog when the
system is started.
71

Logon SecurityEnable or disable the Shut Down button in the Welcome dialog
box. By default this option is disabled for Windows NT Server and enabled for
Windows NT Workstation. Using a policy, you can either disable or enable the
button for all computers.
Windows NT User Profiles
Delete cached copies of roaming profiles and detect slow network connections.

The following example shows the system policies you can set for computers.

Policy Sheet for Default Computer

System Policy Editor


You can use the System Policy Editor to configure system policies for users, groups,
or computers.
Caution

System Policy Editor is installed with Windows NT Server version 4.0. If you want to
use it with Windows NT Workstation, you can copy Poledit.exe and any template files
(.adm files) that you want to use to the workstation. For more information on
template files, see Policy Templates later in this section. The default templates are
Common.adm, Windows.adm, and Winnt.adm.
Common.adm contains information about Registry settings that are common to both
Windows NT and Windows 95. Winnt.adm contains information about Registry
settings specific to Windows NT. Windows.adm contains information about Registry
settings specific to Windows 95.

System Policy Editor is a powerful tool. It should be restricted to network


administrators only. To avoid unauthorized use, do not install this tool on users
computers. Restrict access to the source files so that users cannot install this tool.

With System Policy Editor and its default templates, you can:
Set entries for the default computer and user policy entries. This creates a default
policy file for all users and computers, which is downloaded at logon.
Create entries for individual users, individual computers, or groups of users. By
default, these entries include the policy entries you defined for Default User and
Default Computer.
Specify if and how you want policies downloaded from a centralized server, or
whether you want to have policies downloaded from other specific locations for all
or certain types of users.

You can use System Policy Editor in the following modes:


In Registry mode, you can edit the Registry of the local or remote computer.
Using this mode, you directly edit the contents of the Registry and changes are
reflected immediately.
In Policy File mode, you can create and modify system policy files (.pol files) for
use on other computers. In this mode, the Registry is edited indirectly. Changes
are reflected only after the policy is downloaded at user logon. This is where
System Policy Editor is most powerful, as you can configure multiple users
Registries at one time.

Registry Mode
To use System Policy Editor in Registry mode
1. From the File menu in System Policy Editor, click Open Registry.
2. Double-click the appropriate User or Computer icon, depending on which part of
the Registry you want to edit.
3. Make your changes.
4. Shut down and restart the computer to activate the changes.
Important

73

The following example shows System Policy Editor in Registry mode. Notice that
Local Registry is displayed in the title bar.

System Policy Editor in Registry mode

Use Registry mode only when direct changes to the Registry are required. The
recommended method for changing most system settings is to use the Control Panel
icons and other tools provided with Windows NT Workstation, rather than directly
editing the Registry.

Policy Mode
To use System Policy Editor in Policy File mode
1. From the File menu in System Policy Editor, click New Policy to create a new
policy file, or click Open Policy to open an existing policy file.
2. Make your changes.

The following example shows System Policy Editor in Policy File mode. Notice that
the path appears in the title bar.
Caution

System Policy Editor in Policy File Mode

Policy File mode provides a graphical and organized way to change Registry settings
for specific users, global user groups, or computers. The configured Registry settings
are stored in a policy file named Ntconfig.pol. This file contains the settings for all of
the users, groups, and computers that you have configured. When a user logs on to a
Windows NT Workstation, the workstation automatically checks its logon share for
Ntconfig.pol and updates its local Registry accordingly.

Setting Policies
When you edit settings in Policy File mode, clicking a Registry option sets one of
three possible states: checked, cleared, or filled. Each time you click an option, the
display cycles to show the next state. This is different from clicking a standard check
box, which only toggles an option on or off.
The following table summarizes the three possible states for options in a policy file.
Option state Meaning
Checked = value added to the Registry
Checking the box means that this policy will be implemented. The
corresponding Registry entry is added to the local computers Registry
when the user logs on. If the option was checked the last time a user
logged on, Windows NT Workstation makes no changes.
Cleared = value deleted from the Registry
Clearing the box means that the corresponding Registry entry is
deleted from the local computers Registry when the user logs on.
Filled = value left unchanged in the Registry
Filling the box means the setting is unchanged from the last time a
user logged on. Windows NT Workstation makes no related
modifications to the system configuration.
The filled state ensures that Windows NT Workstation provides quick
processing at system startup, because it does not need to process each
entry each time a user logs on.

When you define policy options, make sure you have set the proper state for the
option. If you set an option by checking it, and then change your mind and clear the
option (rather than leaving it filled), you can inadvertently destroy the users previous
configuration.
If you decide not to set a particular policy option, make sure that option is filled , so
that the users previous configuration for that setting is used.

If a setting requires additional information, you can type that information in the
space provided at the bottom of the property sheet. For example, if Wallpaper is
checked in the Desktop settings, the following property sheet appears.
75

Setting the Wallpaper policy for Default User

Usually, if a policy had been checked, and you no longer want to enforce it, you
should clear the box to undo the policy. Some policies may not behave as expected if
the box is cleared. Some special cases are:
The policy setting contains a text box that must be completed (as opposed to a
simple check box)
The policy setting can also be set by users using Control Panel

For these policies, you should consider filling the check box when you no longer want
to enforce them, rather than clearing the check box.
The following is an example of how the Wallpaper policy behaves.
Wallpaper policy
Policy Behavior
Wallpaper Checking it forces the specified wallpaper to be used.
Clearing it removes the wallpaper (the users screen will not
Tip

have wallpaper).
Filling it means that whatever the last configuration was will
hold. It also allows the user to select the Wallpaper option in
the Display Properties dialog box in Control Panel. However, if
access to the Control Panel itself is removed, then the user
cannot change it.

Creating System Policies


This section describes how to create system policies. You cannot create new groups
using System Policy Editor. You can only create and edit policies for existing users,
computers, and groups on the Windows NT network.

Creating Policies for Computers and Users


To reduce the management load, minimize the number of specific user and specific
computer entries in system policy files. Consider first creating one standard system
policy for all users by editing default settings. Then create settings for individuals on
an exception basis.

To create system policies for a new computer


1. From the Edit menu in System Policy Editor, click Add Computer, and then type
the name of the computer you want to add.
2. Double-click the computers icon.
3. Check, clear, or fill policies by clicking the policy name.

To create system policies for a new user


1. From the Edit menu in System Policy Editor, click Add User.
2. If the user already exists, click Browse; otherwise, type the user name.
3. Select the users you want to add and click Add.
4. When done, click OK.
5. Double-click the users icon.
6. Check, clear, or fill policies by clicking the policy name.

An icon appears in System Policy Editor for each computer, user, or group that you
add to the policy file.
To edit existing system policies
1. In System Policy Editor, click the icon of the user or computer with policies you
want to edit.
2. Check, clear, or fill policies by clicking the policy name.
Important

77

Creating Policies for Groups


The process for creating policies for groups is similar to the process described earlier
for adding a new user.
For more information about creating groups, see Organizing Files, Shares and User
Accounts on the Server. To create a new group, use the tools provided with your
network administrative software.
To create system policies for groups
1. From the Edit menu in System Policy Editor, click Add Group. You can either
type the name of the group or click Browse to find the group.
2. Check, clear, or fill policies by clicking the policy name.

Group policies are downloaded in order from the lowest priority group to the highest
priority group. All groups are processed, meaning that if a user is a member of
multiple groups, each group will be processed sequentially upon logon. If two groups
configure the same Registry option, the second groups configuration overrides the
first. The group with the highest priority is processed last, so its settings are
guaranteed to be applied, even if a lower priority group has already configured the
same setting.
If a policy exists for a specific named user, then group policies are not applied for that
user.

To set priority levels for groups


1. Open Ntconfig.pol.
2. Add groups as appropriate, and specify the policy settings you want.
3. Select Options, and click Group Priority. Use the Move Up and Move Down
buttons to arrange the groups by relative priority as illustrated in the following
figure.
Setting group priority in System Policy Editor

Configuring System Policies


This section describes how to configure system policies. For an overview of system
policies, see Overview of System Policies earlier in this document.

Policy Editor and Storing Paths in the Registry


System policies are very powerful when applications are designed to take advantage
of their facilities. To give you the ability to configure policy settings once for
thousands of desktops on a per-user or per-group basis, applications must support
environment variables. This is particularly important for storing paths, but is also
applicable to other program items.
It is also important for any applications to utilize the REG_EXPAND_SZ Registry
type, and the %SystemRoot%, %windir%, and %SystemDrive% environment
variables. In particular, it is important that you do not hard code paths to the
Windows system root or to the drive containing Windows in the Registry since it is
possible to remap drives under Windows NT. For example:
Dont MyTemplatePath : REG_SZ : "C:\MyApp\MyTemplate"
Do MyTemplatePath : REG_EXPAND_SZ : "%SystemDrive
%\MyApp\MyTemplate"

When retrieving the path from the Registry, the Win32 ExpandEnvironmentStrings
function can then be used to get the updated path. See Appendix C for a description
of the ExpandEnvironmentStrings function.
79

With a policy for the MyTemplatePath value, it is possible to redirect


MyTemplatePath to any valid path on the local computer or network. The following
example shows a policy using environment variables.

Example of a policy using environment variables

The template used to create this example is as follows:


CLASS USER

CATEGORY !!TmpCatName
POLICY !!TmpPolName
KEYNAME Software\MyCompany\MyApp\Templates
PART !!TmpPolMsg EDITTEXT EXPANDABLETEXT
VALUENAME ""
REQUIRED
END PART
END POLICY
END CATEGORY

[Strings]
TmpCatName=My App
TMPPolName=Templates
TmpPolMsg=Enter path to templates folder

For a description of policy templates, see Policy Templates later in this section.

Default Policies for Users


The policies defined in Default User are applied whenever a user does not have a
specific policy defined. Thus, you can use Default User to define a global set of
policies that you can create for an entire domain. You can then create specific
exemptions on a per-user or per-group basis. The following tables describe system
policies for Default User defined by default in System Policy Editor.
The following table lists the system policy options that display when you click
Control Panel, click Display, and then click Restrict display.
Restrict Display Control Panel
Option Comment
Deny access to display icon Prevents access to the Display icon in Control Panel,
displaying an explanation in a dialog box.
Hide Background Tab Hides the Background property sheet of the Display
option in Control Panel.
Hide Screen Saver Tab Hides the Screen Saver property sheet of the Display
option in Control Panel.
Hide Appearance Tab Hides the Appearance property sheet of the Display option
in Control Panel.
Hide Settings Tab Hides the Settings property sheet of the Display option in
Control Panel.

The following table lists the system policy options that display when you click
Desktop, click Wallpaper, or click Color scheme.
Wallpaper and Color Scheme Settings
Option Comment
Wallpaper Name The user automatically receives the specified bitmap as
it is downloaded at logon.
Tile Wallpaper The wallpaper file is tiled in the background of the
desktop.
Scheme name The specified color scheme is automatically displayed on
the users computer.

The following table lists the system policy options that display when you click Shell,
and then click Restrictions.
Shell Restrictions
Option Comment
Remove Run command from Prevents access to the Run command from the Start
Start menu menu.
Remove folders from Prevents access to any item listed under Settings on the
Settings on Start menu Start menu.
Remove Taskbar from Prevents access to the Taskbar item listed under Settings
Settings on Start menu on the Start menu.
Remove Find command from Prevents access to any of the items listed under Find on
Start menu the Start menu.
Hide drives in My Computer Prevents access to My Computer.
Hide Network Neighborhood Prevents access to Network Neighborhood and disables
UNC connectivity.
No Entire Network in Prevents access to the Entire Network icon in Network
Network Neighborhood Neighborhood.
No Workgroup contents in Prevents workgroup contents from being displayed in
Network Neighborhood Network Neighborhood.
Hide all items on desktop Prevents access to all items on the desktop.
Disable Shut Down Prevents access to the Shut Down command on the Start
command menu.
Dont save settings at exit Prevents settings from being written to the file system.

The following table lists the system policy options that display when you click
System, and then click Restrictions.
81

Restricting Access to System Settings


Option Comment
Disable Registry editing tools Prevents access to Registry Editor; displays explanation in
a dialog box.
Run only allowed Windows Prevents users from running any Windows-based
applications applications except those that are listed. Click Show to
define the allowed applications.

The following table lists the system policy options that are displayed when you check
Custom User Interface.
Custom User Interface
Option Comment
Custom Shell Replaces Explorer.exe with a user interface of your
choosing.

The following table lists the system policy options that display when you click
Windows NT Shell, and then click Custom folders.
Custom Folders
Option Comment
Custom Programs folder Used to customize the contents of the
Programs folder. You must also type a path
for the folder containing complete files or
.lnk files that define the Programs folder
items.
Custom desktop icons Used to customize desktop icons. You must
also type a path for the folder containing
complete files or .lnk files that define the
desktop shortcuts.
Hide Start menu subfolders Used when you use a custom Programs
folder. Otherwise, two Programs folders
will appear on the users Start menu.
Custom Startup folder Used to customize the contents of the
Startup folder. You must also type a path for
the folder containing complete files or .lnk
files that define the Startup folder items.
Custom Network Neighborhood Used to customize the contents of Network
Neighborhood. You must also type a path
for the folder containing complete files or
.lnk files that define the Network
Neighborhood items.
Custom Start menu Used to customize what is listed on the
Start menu. You must also type a path for
the folder containing complete files or .lnk
files that define the Start menu items.

The following table lists the system policy options that display when you click
Windows NT Shell, and then click Restrictions.
Restrictions
Option Comment
Only use approved shell extensions
Remove File menu from Explorer
Remove common program groups from Does not load the All Users profile.
Start menu
Disable Context Menus for the Taskbar Removes the right-click option for the
taskbar.
Disable Explorers default context menu Removes the right-click options for the user
interface.
Remove the Map Network Drive and Prevents users from mapping or
Disconnect Network Drive options disconnecting network drives.
Disable link file tracking

The following table lists the system policy options that display when you click
Windows NT System.
Windows NT System
Option Comment
Parse Autoexec.bat Includes environment variables declared in Autoexec.bat
in users environment.
Run logon scripts System waits for logon scripts to complete before the
synchronously users user interface starts.
Disable Task Manager Prevents users from accessing Task Manager. Note that it
is difficult for users to end processes without access to
Task Manager.
Show welcome tips at logon If cleared, prevents the welcome tips screen from
appearing at logon.
83

Default Policies for Computers


The policies in Default Computer are implemented if the computer itself does not
have a specific policy. However, policies for users and groups have a higher priority.
Default Computer can be used to specify global policies that should be applied to
everyone in the domain. If the policies appear in users or groups, they can be left
filled, or, in special cases, modified for the specific group or user. This provides a
central point of administration for your global policies. The following tables describe
system policies for Default Computer defined by default in Common.adm or
Winnt.adm.
The following table lists the system policy options that display when you click
Network, click System policies update, and then click Remote Update.
Remote Update
Option Comment
Update mode Determines whether the computer will use the default
path (\\primary domain controller\netlogon\ntconfig.pol)
or a custom path.
Path for manual update Configures the custom path if the update mode is manual.
Display error messages Displays error messages on the target computer. Used for
debugging.

The following table lists the system policy options that display when you click
System and then click SNMP.
SNMP
Option Comment
Communities Specifies one or more groups of hosts to
which this computer belongs for purposes of
administration using the SNMP service.
These are the communities that are allowed
to query the SNMP agent.
Permitted managers Specifies IP or IPX addresses allowed to
obtain information from an SNMP agent. If
this policy is not checked, any SNMP
console can query the agent.
Traps for Public community Specifies Trap Destinations, or IP or IPX
addresses of hosts in the public community
to which you want the SNMP service to
send traps.
If you want to send traps to other
communities, see the SNMP documentation.
The following table lists the system policy option that displays when you click
System and then click RUN.
RUN
Option Comment
Items to run at startup Determines which files will be run at startup. Click the
Show button to display the list of items run at startup.

The following table lists the system policy options that display when you click
Windows NT Network and then click Sharing.
Windows NT Network Sharing restrictions
Option Comment
Create hidden drive shares Allows the <drive letter>$ and admin$ shares to be
(workstation) created when Windows NT Workstation loads.
Create hidden drive shares Allows the <drive letter>$ and admin$ shares to be
(server) created when Windows NT Server starts.

The following table lists the system policy options that display when you click
Windows NT Printers.
Windows NT Printers
Option Comment
Disable browse thread on this Configures spooler not to send shared printer information
computer to other print servers.
Scheduler priority Sets the scheduler priority to be either above or below
normal.
Beep for error enabled Sets the computer to beep every 10 seconds when a
remote job error occurs on a print server.

The following table lists the system policy options that display when you click
Windows NT Remote Access.
Windows NT Remote Access
Option Comment
Max number of unsuccessful Sets a limit (110) on the number of unsuccessful logons
authentication retries before disconnecting the remote user.
Max time limit for Sets the amount of time Windows NT will wait (20600
authentication seconds) during authentication before terminating the
connection.
Wait interval for callback Configures the time to wait (212 seconds) before dialing
the RAS client.
Auto Disconnect Configures a maximum amount of time in which a user
can be logged on.
Note

85

The following table lists the system policy options that display when you click
Windows NT Shell, and then click Custom shared folders.
Windows NT Shell
Option Comment
Custom shared programs Used to customize the contents of the Program folder. You
folder must also type a path for the folder containing complete
files or .lnk files that define the Programs folder items.
Custom shared desktop icons Used to customize desktop icons. You must also type a
path for the folder containing complete files or .lnk files
that define the desktop shortcuts.
Custom shared Start menu Used to customize what is listed on the Start menu. You
must also type a path for the folder containing complete
files or .lnk files that define the Start menu items.
Custom shared Startup folder Used to customize the contents of the Startup folder. You
must also type a path for the folder containing complete
files or .lnk files that define the Startup folder items.

The policies for Windows NT Shell can also be configured for groups and users. See
the paragraph at the beginning of this section for an explanation of where you should
configure them.

The following table lists the system policy options that display when you click
Windows NT System, and then click Logon.
Windows NT System
Option Comment
Logon banner Used to configure a caption and text to be displayed
during user login.
Enable shutdown from Used to enable/disable the shutdown button in the
Authentication dialog box Authentication dialog box displayed before logon.
Do not display last logged on Configures the user name entry to remain blank in the
user name Logon dialog box, instead of showing the user name of
the last person who logged on.
Run logon scripts Configures the Windows NT user interface to wait until
synchronously logon scripts have finished running before it starts.

The following table lists the system policy options that display when you click
Windows NT System, and then click File system.
File System
Option Comment
Do not create 8.3 file names
for long file names
Allow extended characters in Configures the display on a users computer to not display
8.3 file names extended characters.
Do not update last access Used to increase system performance by not updating a
time files access time if the file is being viewed.

The following table lists the system policy options that display when you click
Windows NT User Profiles.
Windows NT User Profiles
Option Comment
Logon
Delete cached copies of Used to delete local copies of roaming profiles after the
roaming profiles user logs off. This saves disk space.
Automatically detect slow
network connections
Slow network connection
timeout
Timeout for dialog boxes

ZAK System Policies


Besides using the Winnt.adm and Common.adm templates, both TaskStation and
AppStation use templates from the Internet Explorer Administration Kit and the
Office 97 Resource Kit. This section describes all of the policies used by ZAK in
either the AppStation or TaskStation examples. For more information on the
Winnt.adm and Common.adm templates, see Policy Templates later in this section.
To get a full list of policies defined in the Office 97 and Internet Explorer templates,
see the Office 97 Resource Kit and the Internet Explorer Administration Kit.

TaskStation System Policies


This section lists the system policies that have been set to restrict TaskStation users.
User interface restrictions The following user interface policies are in effect for
the TaskStation:
Remove the Run command.
Remove folders from settings on the Start menu.
Remove taskbar from settings on the Start menu.
Remove the Find command.
Hide drives in My Computer.
Hide Network Neighborhood.
87

Hide all items on desktop.


Disable the Shut Down command.
Dont save settings at exit.

Internet Explorer user interface restrictions The following Internet Explorer


user interface policies are in effect for the TaskStation:
Disable Controls for temporary Internet files.
Disable all check boxes at the bottom of the Advanced tab.
Disable all controls in the Cryptography Protocols dialog box.
Disable all controls in the Warnings dialog box.
Disable all controls in the Mail and News dialog box.
Disable all controls in the Viewers dialog box.
Disable the check box for controlling the default browser.
Disable all controls in the Dialing dialog box.
Disable all controls in the Proxy Server dialog box.
Disable all controls in the Customize dialog box.
Disable all controls in the History dialog box.
Disable all controls in the Properties dialog box (launched from the Font Settings
dialog box).
Disable Set Default and check box controls in the Font Settings dialog box.
Disable all controls in the Multimedia dialog box.
Disable all controls in the Toolbar dialog box.
Disable all controls in the Colors dialog box.
Disable all controls in the Links dialog box.
Disable all controls in the Ratings dialog box.
Disable all controls in the Active Controls dialog box.
Disable all controls in the Certificates dialog box.

Windows NT user interface The following Windows NT user interface policies


are in effect for the TaskStation:
Enable Custom Shell by running: runapp c:\program files\plus!\microsoft internet
explorer\iexplorer.exe -k
Remove File menu from Windows NT Explorer.
Remove Common program groups from Start menu.
Disable context menus for the taskbar.
Disable default context menu from Explorer.
Remove Map Network Drive and Disconnect Network Drive from the Tools menu
in Explorer.
Disable link file tracking from Explorer.

Windows NT system The following Windows NT system policies are in effect for
the TaskStation:
Disable Task Manager.
Disable show welcome tips at Logon.

ZAK Policies The following Windows NT system policies are in effect for the
TaskStation:
Show only selected drives: Dont show any drives.

AppStation System Policies


This section lists the system policies that have been set to restrict AppStation users.
User interface restrictions The following user interface policies are in effect for
the AppStation:
Remove the Run command.
Remove folders from Settings on the Start menu.
Remove taskbar from Settings on the Start menu.
Remove the Find command.
Hide drives in My Computer.
Hide Entire Network in Network Neighborhood.
Hide workgroup contents in Network Neighborhood.
Hide all items on the desktop.
Disable the Shut Down command.
Dont save settings on exit.

Internet Explorer user interface restrictions The following Internet Explorer


user interface policies are in effect for the AppStation:
Disable Controls for temporary Internet files.
Disable all check boxes at the bottom of the Advanced tab.
Disable all controls in the Cryptography Protocols dialog box.
Disable all controls in the Warnings dialog box.
Disable all controls in the Mail and News dialog box.
Disable all controls in the Viewers dialog box.
Disable the check box for controlling the default browser.
89

Disable all controls in the Dialing dialog box.


Disable all controls in the Proxy Server dialog box.
Disable all controls in the Customize dialog box.
Disable all controls in the History dialog box.
Disable all controls in the Properties dialog box (launched from the Font Settings
dialog box).
Disable Set Default and check box controls in the Font Settings dialog box.
Disable all controls in the Multimedia dialog box.
Disable all controls in the Toolbar dialog box.
Disable all controls in the Colors dialog box.
Disable all controls in the Links dialog box.
Disable all controls in the Ratings dialog box.
Disable all controls in the Active Controls dialog box.
Disable all controls in the Certificates dialog box.

Microsoft Office 97 The following Office 97 policies are in effect for the
AppStation:
Enable Personal Folder by running: \\<server name>\users\%username%
Enable User Templates by running: C:\Program files\Microsoft office\Templates
Enable Workgroup Templates by running: O:\Off97\Msoffice\Template

Microsoft Excel 97 The following Excel 97 policies are in effect for the
AppStation:
Chart Gallery: O:\Off97\Msoffice\Template

Windows NT user interface The following Windows NT user interface policies


are in effect for the AppStation:
Enable Custom Programs Folder by running:
O:\Off97\ClntRoot\Winnt\Profiles\all users\start menu\programs.
Hide Start menu subfolders.
Enable Custom Start menu by running: O:\Off97\ClntRoot\Winnt\Profiles\all
users\start menu.
Remove the File menu from Windows NT Explorer.
Remove common program groups from the Start menu.
Disable context menus for the taskbar.
Disable the default context menu in Explorer.
Note

Remove Map Network Drive and Disconnect Network Drive from the Tools menu
in Explorer.
Disable link file tracking.

Windows NT system The following Windows NT system policies are in effect for
the AppStation:
Run logon scripts synchronously.
Disable Task Manager.
Disable show welcome tips at logon.

ZAK Policies The following ZAK custom policies are in effect for the
AppStation:
Show only selected drives: Dont Show Any Drives

Optional ZAK Policies


The following are some ZAK policies that you should consider setting for AppStation
and TaskStation groups.

Show only Specified Drive Letters


Also in the custom ZAK Policies section, you can select which drive letters are
displayed on the local computer. You might consider changing this value from Show
no Drives to Show only U: so that users can easily navigate to their home folder.
For details about this policy, see ZAK Custom Policy Template.

Proxy Server
If you use a proxy server, you must configure the Windows, Internet Settings policy.
This is not the intuitive place to set the proxy server policy, especially because above
it there is a policy entitled Set the values for your proxy server. However, because
this policy falls below it, the Internet Settings policy is the one that is evaluated last,
and therefore it is the one which is used.

IE Start and Search Pages


You should also set the Start and Search pages for Internet Explorer. As with the
Proxy settings, this policy is listed twice, once in Definition of Start and Search
pages and later in Internet Explorer 3.0 (click View, click Options, and then click
Navigation). For the same reasons as listed above, you should set whichever policy is
listed last.
91

IE Security
In the custom ZAK Policies section, you are given options to configure the Internet
Security for Internet Explorer. For details about this policy, see ZAK Custom Policy
Template.

Replacing the User Interface


One of the policies in the Winnt.adm template gives you the ability to replace the user
interface program used by client computers. Normally, when a user logs in,
Explorer.exe is launched as the user interface program. However, you can replace
Windows NT Explorer with any line-of-business application to run as the user
interface. The users access to the local computer is limited to only what the user
interface program allows.
In the TaskStation, Internet Explorer is launched as the user interface. The following
example shows the custom user interface policy.

TaskStation Custom Shell policy


Note

Policy Templates
A template is a listing of the possible Registry keys that can be configured through
System Policy Editor. This section describes the use of policy templates.

System Policy Templates


The three templates that are opened by default are Common.adm, Winnt.adm, and
Windows.adm. Winnt.adm contains configuration data for Windows NT.
Windows.adm holds configuration data for Windows 95. It is not used with the Zero
Administration Kit. Templates can be modified or created with a text editor, giving
you almost full control over a given computer, user, or group.
If you want to define system policies for Windows NT applications, the applications
must use the Windows NT Registry.

Creating your own template is helpful when you want to define a specific set of
Registry settings in your system policies, including settings not definable by default
through System Policy Editor.
For example, it may be helpful to have system policy settings for corporate-specific
applications, such as an in-house database or a custom front end. After a template has
been customized, administrators can load the template and use it to set values in the
Registry.
To use a template other than the default template
1. In System Policy Editor, close all policy files.
2. From the Options menu, click Policy Template.
3. In the Policy Template Options dialog box, click Add.
4. In the Open Template File dialog box, specify the name of the .adm file to use as
a template to begin setting policies, and click Open.

You can create your own templates that can be read by System Policy Editor. Users
can then load your custom template to set values in the Registry.
To create a template
Use a text editor such as WordPad to edit or write an .adm file.

The following table briefly describes the keywords in system policy templates.
Following this table are detailed lists of the controls and values that can be defined in
templates.
System Policy Template Key Words
Template key word Description
CLASS Defines the key of the Registry that will be edited; the value
must be USER or MACHINE, corresponding to
HKEY_CURRENT_USER and HKEY_LOCAL_MACHINE,
respectively, in the Registry.
CATEGORY name Defines a category in the System Policy Editor. Category names
93

that contain spaces must be enclosed in quotes. A category


definition statement cannot appear more than once for the same
category name.
END CATEGORY Defines the end of a category and all of its policies.
POLICY name Defines a policy within a category that can be set. Policy names
that contain spaces must be enclosed in quotes.
END POLICY Defines the end of a policy and all its parts.
PART name Defines a control or controls that can be used to set the values
of a policy. Part names that contain spaces must be enclosed in
quotes. Policy part types and type-dependent data are discussed
later in this document.
END PART Defines the end of the control list.
VALUEON Setting to give the value when the policy is checked.
VALUEOFF Setting to give the value when it is not checked.
KEYNAME Specifies the full path of the Registry key name. This is an
optional Registry key name to use for the category or policy. If
there is a key name specified, this name is used by all
subordinate categories, policies, and parts, unless they
specifically provide a key name of their own.
VALUENAME Defines the Registry section value entry name.
VALUE Specifies the Registry value to set to a VALUENAME.
!! Indicates a string value.
[strings] Defines a section of string values.

The following is a skeleton example of the Template Key Words. Note that there can
be multiple policies per category and multiple parts per policy. There can also be
multiple categories per CLASS.
EXAMPLE
CLASS category_type (either USER or MACHINE)

CATEGORY name
[KEYNAME key_name]
POLICY Policy 1
[KEYNAME key_name]
PART Part_1 part_type
type-dependent data
[KEYNAME key_name ]
VALUENAME value_name
END PART
PART Part_N part_type
type-dependent data
[KEYNAME key_name ]
VALUENAME value_name
END PART
End Policy
POLICY Policy N
[KEYNAME key_name]
PART Part_1 part_type
type-dependent data
[KEYNAME key_name ]
VALUENAME value_name
END PART
PART Part_N part_type
type-dependent data
[KEYNAME key_name ]
VALUENAME value_name
END PART
End Policy
End Category

There are a number of different types of parts that a policy can use. The following
table lists all of the part control indicators you can use to control the look and feel of
the policy. Furthermore, the following tables list the series of type-specific modifiers
that you can apply to each part to control the default data, range of options, and
general actions of a policys individual parts.
System Policy Template Part Control Indicators
Part Control Indicator Description
CHECKBOX Displays a check box. The value is nonzero if checked by the
user, and its entry is deleted if it is unchecked.
NUMERIC Displays an edit field with an optional spin control that
accepts a numeric value.
EDITTEXT Displays an edit field that accepts alphanumeric text.
COMBOBOX Displays a combo box, which is an edit field plus a drop-
down list box for suggested values.
TEXT Displays a line of static (label) text. There is no associated
Registry value with this part type.
DROPDOWNLIST Displays a drop-down list control. The user can only choose
from one of the entries supplied. The main advantage of a
drop-down combo box is that, based on the users selection,
a number of extra arbitrary Registry edits can be performed.
LISTBOX Displays a list box with Add and Remove buttons. This is
the only part type that can be used to manage multiple
values under one key.

The following table describes the type-specific modifiers you can apply to the
CHECKBOX part control indicator.
95

System Policy Template Type-Specific Information


CHECKBOX Description
DEFCHECKED Causes the check box to be initially checked.
VALUEON If specified, overrides the default on behavior of the check
box. For example, VALUEON On writes On to the
Registry.
VALUEOFF If specified, overrides the default off behavior of the check
box. For example, VALUEOFF Off writes Off to the
Registry.
ACTIONLISTON Specifies optional action list to be taken if check box is on.
ACTIONLISTOFF Specifies optional action list to be taken if check box is off.

The following example is part of the Reminders policy taken from the Outlk97.adm
template provided with ZAK. This policy adds the PlaySound entry to
Software\Microsoft\Office\8.0\Outlook\Options\Reminders in
HKEY_CURRENT_USER, and will give a value of 1 if the check box is checked
and 0 if unchecked. In the following example, only the Play reminder sound
checkbox within the Reminder Options policy is configured.

Outlook 97 Reminder Options policy

EXAMPLE
PART !!OLPlayRemindSoundText CHECKBOX
VALUENAME PlaySound
VALUEON NUMERIC 1
VALUEOFF NUMERIC 0
END PART

[strings]
OLPlayRemindSoundText=Play Reminder Sound

The following table describes the type-specific modifiers you can apply to the
NUMERIC part control indicator.
System Policy Template Type-Specific Information
NUMERIC Description
DEFAULT value Specifies initial numeric value for the edit field. If this
statement is not specified, the edit box is initially empty.
MIN value Specifies minimum value for number. Default value is 0.
MAX value Specifies maximum value for number. Default value is 9999.
SPIN value Specifies increments to use for spin control. Specifying SPIN
0 removes the spin control. SPIN 1 is the default.
REQUIRED If specified, System Policy Editor does not allow a policy
containing this part to be enabled unless a value has been
entered for this part.
TXTCONVERT Writes values as REG_SZ strings (1,2,128) rather
than binary values.

The following example is taken from the Winnt.adm template provided with ZAK. It
is in the Windows NT Remote Access category and corresponds to the Max time limit
for authentication policy. You can use this policy to configure the default maximum
authentication time. You can choose any time between 20 and 600 seconds.

The Windows NT Remote Access Maximum time limit for authentication policy

EXAMPLE
PART !!RAS_Time NUMERIC REQUIRED
MIN 20 MAX 600 DEFAULT 120
VALUENAME AuthenticateTime
END PART

[strings]
RAS_Time=Length in seconds

The following table describes the type-specific modifiers you can apply to the
EDITTEXT part control indicator.
System Policy Template Type-Specific Information
EDITTEXT Description
DEFAULT value Specifies initial string to place in the edit box. If this is not
specified, the box is initially empty.
MAXLEN value Specifies maximum length of string. The string is limited to
this length in the edit box.
REQUIRED If specified, the System Policy Editor does not allow a policy
containing this part to be enabled unless a value has been
entered for this part.

The following example is taken from the Winnnt.adm template. It is in the Custom
Folders category and corresponds to the Custom Start menu policy.

Windows NT Shell Custom Start menu policy

EXAMPLE
PART !!CustomFolders_StartMenuPath EDITTEXT REQUIRED EXPANDABLETEXT
DEFAULT !!CustomFolders_StartMenuDefault
VALUENAME "Start Menu"
97

END PART

[strings]
CustomFolders_StartMenuPath=Path to location of Start menu items
CustomFolders_StartMenuDefault=%USERPROFILE%\Start Menu

The following table describes the type-specific modifiers you can apply to the
COMBOBOX part control indicator.
System Policy Template Type-Specific Information
COMBOBOX Description
Accepts the same keywords as EDITTEXT, as well as
SUGGESTIONS.
SUGGESTIONS Begins a list of suggestions to be placed in the drop-down
list. Suggestions are separated with spaces and can be
enclosed by quotes. The list is terminated with END
SUGGESTIONS. For example:
SUGGESTIONS
Alaska Alabama Mississippi New York
END SUGGESTIONS

The following example is taken from the Off97nt4.adm template included with ZAK.
It is in the Miscellaneous category and corresponds to the Time Format policy. You
can use this policy to configure the default time format for Microsoft Word by
selecting one of the suggested options, or by entering your own custom format.

Word 97 Time Format policy

EXAMPLE
PART !!WDTimeFormatText COMBOBOX
VALUENAME TIMEFORMAT
SUGGESTIONS
"h:mm am/pm"
"h:mm:ss am/pm"
"HH:mm"
"HH:mm:ss"
END SUGGESTIONS
REQUIRED
END PART

[strings]
WDTimeFormatText=Default time format

The following table describes the type-specific modifiers you can apply to the TEXT
part control indicator.
System Policy Template Type-Specific Information
TEXT Description
Contains no type-specific data.

The important thing to remember about the text configuration is that it is not
editable. Text is usually used to explain to an administrator what a particular policy is
used for. If you are writing custom templates you should include text to explain to
other administrators what the policy actually does.
The following example shows the Windows NT System Run logon scripts
synchronously policy, which uses the TEXT type-specific modifier to explain the
policies to the administrator.

Windows NT System Run logon scripts synchronously policy

EXAMPLE

POLICY !!Run_Logon_Script_Sync
KEYNAME "Software\Microsoft\Windows NT\CurrentVersion\Winlogon"
VALUENAME RunLogonScriptSync
PART !!Script_Tip1 TEXT END PART
PART !!Script_Tip2 TEXT END PART
PART !!Script_Tip3 TEXT END PART
END POLICY

[strings]
Run_Logon_Script_Sync=Settings for Run Logon Scripts synchronously
Script_Tip1=Wait for logon scripts to complete before starting
Script_Tip2=the users shell. If this value is set in the
Script_Tip3=User section, this value takes precedence.

The following table describes the type-specific modifiers you can apply to the
DROPDOWNLIST part control indicator.
System Policy Template Type-Specific Information
DROPDOWNLIST Description
REQUIRED If specified, the System Policy Editor does not allow a policy
containing this part to be enabled unless a value has been
entered for this part.
ITEMLIST Begins a list of the items in the drop-down list. The end of
the list must be terminated by END ITEMLIST. Each item in
the list is specified as follows:
NAME name VALUE value
[ACTIONLIST actionlist]

name is the text to be displayed in the drop-down list for this
99

item.
value is the value to be written for the parts value if this
item is selected. Values are assumed to be strings, unless
they are preceded by the keyword NUMERIC. For example:
VALUE Some value
VALUE NUMERIC 1
If the VALUE keyword is followed by the DELETE keyword
(that is, VALUE DELETE), then this Registry
value/valuename pair is deleted.
actionlist is an optional list to be used if this value is
selected.

The following example is taken from Off97nt4.adm. It is in the Save category and
corresponds to the Default Save policy. You can use it to configure the file types for
the default Save option in Microsoft Word.

Word 97 Default save policy

EXAMPLE
PART !!WDDefSave DROPDOWNLIST
VALUENAME "Default Format"
ITEMLIST
NAME !!Word8 VALUE ""
NAME !!Word6 VALUE "MSWord6Exp"
NAME !!Word2 VALUE "MSWordWin2"
NAME !!MacWord5 VALUE "MSWordMac5"
NAME !!MacWord51 VALUE "MSWordMac51"
NAME !!WP5x VALUE "WrdPrfctWin"
NAME !!WP51DOS VALUE "WrdPrfctDos51"
NAME !!Works3 VALUE "MSWorksWin3"
NAME !!Works4 VALUE "MSWorksWin4"
NAME !!HTML VALUE "HTML"
NAME !!RTF VALUE "RTF"
END ITEMLIST
REQUIRED
#if VERSION > 1
NOSORT
#endif
END PART

[strings]
WDDefSave="Save Word files as:"
Word8="Word 97 (*.doc)"
Word6="Word 6.0/95 (*.doc)"
Word2="Word 2.x for Windows (*.doc)"
MacWord5="Word 5.0 for Macintosh (*.mcw)"
MacWord51="Word 5.1 for Macintosh (*.mcw)"
WP5x="WordPerfect 5.x for Windows (*.doc)"
WP51DOS="WordPerfect 5.1 for DOS (*.doc)"
Works3="Works 3.0 for Windows (*.wps)"
Works4="Works 4.0 for Windows (*.wps)"
HTML="HTML Document"
RTF="Rich Text Format (*.rtf)"

The following table describes the type-specific modifiers you can apply to the
LISTBOX part control indicator.
System Policy Template Type-Specific Information
LISTBOX Description
VALUENAME Cannot be used with the list box type, because there is no
single value name associated with this type. By default, only
one column appears in the list box, and for each entry a value
is created with an identical value name and value data. For
instance, an entry List Entry in the list box creates a value
named List Entry containing List Entry as data.
VALUEPREFIX prefix Defines the prefix to be used in determining value names. If
a prefix is specified, then this prefix plus 1, 2, and so on
is used instead of the default value naming scheme listed
earlier in this table. The prefix can be empty (), which
causes the value names to be 1, 2, and so on. A prefix of
SomeName generates value names SomeName1,
SomeName2, and so on.
EXPLICITVALUE Requires the user to specify not only the value data, but also
the value name. The list box shows two columns for each
item, one for the name and one for the data. This keyword
cannot be used with the VALUEPREFIX keyword.
ADDITIVE If specified, values set in the list box are added to whatever
values exist in the target Registry. Existing values are not
deleted; the default, which is the content of the list boxes,
overrides whatever values are set in the target Registry.
Specifically, a control value is inserted in the policy file
which causes existing values to be deleted before the values
set in the policy file are merged.

You can use the list box to add a series of values and corresponding data. With the
following example taken from Common.adm, you can create a list of items to run at
startup.
The list box, which is in the System category and corresponds to the Run policy, is
shown in the following example. Click the Show button in the System/Run policy to
display the list box. To add an entry to the list box, click Add.
101

List box launched from the System Run policy

EXAMPLE
PART !!RunListbox LISTBOX EXPLICITVALUE
END PART

[strings]
RunListbox=Items to run at startup

The following table describes the type-specific modifiers you can apply to the Strings
part control indicator.
System Policy Template Type-Specific Information
Strings Description
!! Indicates a string value. For example:
!!StrConst
[strings] Defines a section of string values; the values are defined in
the following format:
var_name=string value
For example:
StrConst="Control Name"
Comments Can be added by preceding the line with a semicolon (;).

A string is a variable acting as a place holder for text that is defined in the [strings]
section at the bottom of the template. The following is an example of that section.
EXAMPLE
[strings]
StrConst1=This text will appear where the StrConst1 variable was
placed
StrConst2=This text will appear where the StrConst2 variable was
placed

Example of a System Policy Template


The following example is a selection from the Common.adm template. You can use
this template to determine how much access a user has to the Display icon in Control
Panel. You can use this template to change the behavior of the Registry entries that
correspond to the Display icon, which then changes the behavior of each tab in the
Display Properties dialog box. Note that the string place holders are defined at the
bottom of the template.
EXAMPLE
CLASS USER

CATEGORY !!ControlPanel
CATEGORY !!CPL_Display
POLICY !!CPL_Display_Restrict
KEYNAME
Software\Microsoft\Windows\CurrentVersion\Policies\System

PART !!CPL_Display_Disable CHECKBOX


VALUENAME NoDispCPL
END PART

PART !!CPL_Display_HideBkgnd CHECKBOX


VALUENAME NoDispBackgroundPage
END PART

PART !!CPL_Display_HideScrsav CHECKBOX


VALUENAME NoDispScrSavPage
END PART

PART !!CPL_Display_HideAppearance CHECKBOX


VALUENAME NoDispAppearancePage
END PART

PART !!CPL_Display_HideSettings CHECKBOX


VALUENAME NoDispSettingsPage
END PART
END POLICY
END CATEGORY ; Display

END CATEGORY ; Control Panel

[strings]
ControlPanel="Control Panel"
CPL_Display="Display"
CPL_Display_Restrict="Restrict display"
CPL_Display_Disable="Deny access to display icon"
CPL_Display_HideBkgnd="Hide Background tab"
CPL_Display_HideScrsav="Hide Screen Saver tab"
CPL_Display_HideAppearance="Hide Appearance tab"
CPL_Display_HideSettings="Hide Settings tab"

As applied in System Policy Editor, the preceding template is shown in the following
example.

Restrict display policy as defined in Common.adm

The Display policy, when configured this way, will remove the Screen Saver,
Appearance, and Settings tabs from the Display Properties dialog box. The user
will only have access to the Background tab as shown in the following example.
Note

103

Restricted Display Properties dialog box

Application Policy Templates


In addition to configuring system settings for a specific user, you can also customize
application interfaces and behavior. As applications have evolved, they have become
much more powerful and their interfaces have grown in complexity. These complex
interfaces can be overwhelming for novice users. To help minimize the confusion,
you can use the Registry to configure an application to show only certain menu bars
or pre-configured options.
Sometimes, applications provide custom templates. Templates are provided for
Office 97 and Internet Explorer. These templates are included with ZAK. See
System Policy Templates earlier in this document for examples of customizing
policies with these templates.

Creating your Own Policy Templates


Sometimes an application that you want to configure does not provide its own
template, or the template may not contain a setting that you need. In this case, you
must either modify an existing template or create your own. To do so requires
knowledge of the application and how the application uses the Registry to store
configuration data.
Windiff, provided in the Windows NT Server Resource Kit version 4.0, can compare
exported Registry files for differences. There is still a bit of guesswork involved
because you must identify the correct Registry key where the change takes place.
Policies cannot configure information stored in a binary key. If an application stores
data in one of these keys, that data cannot be configured through System Policy
Editor.

To create your own application template


1. Open the application.
2. Run Regedit and export the Registry hive.
3. Make the change in the application.
4. Close the application. This is usually when an application saves information to
the Registry.
5. Export the Registry hive again.
6. Run Windiff, comparing the two files.

You might have to repeat this process depending on how many options are configured
in the Registry key. For example, if one Registry setting records the display of all
toolbars and stores this information in a hexadecimal format, then you might want to
test a few configurations to understand which values represent various toolbar
configurations.
ZAK Custom Policy Template
ZAK provides its own custom template, called ZAKwinnt.adm, as well as the
templates from the Internet Explorer Administration Kit, the Office 97 Resource Kit,
and the default Windows NT templates. ZAKwinnt.adm provides three new
categories for you to use: roaming user profiles through system policies, Internet
Explorer security, and the ability to hide drive letters from users. Each of these
categories is described in more detail in the following section.

Roaming User Profiles through System Policies


ZAKwinnt.adm allows for some of the features of Roaming User Profiles without the
corresponding caveats that come with them. There are five policies, which you can
use to configure paths to the Application Data, Favorites, PrintHood, Recent, and
SendTo folders. These policies are part of user profiles. The following table lists the
user profile folders defined in this custom ZAK policy.
User Profiles through System Policies
User Profile Folder Contents
Application Data Application specific data, such as custom dictionary for
Microsoft Word. Application vendors decide which data to store
in this folder.
Favorites Shortcuts to program items and favorite locations.
PrintHood Shortcuts to printer folder items.
Recent Shortcuts to the most recently used items.
SendTo Shortcuts to document items, locations, or applications.

User profiles consist of other folders as well, but these folders are already defined for
system policies in other templates. Redefining them in the ZAKwinnt.adm policy
template would create conflicts that could produce confusing results. Because policies
are evaluated on a last writer wins strategy, if the same Registry key is configured
in two different policies, the policy closest to the bottom in System Policy Editor
overwrites the other. This is true even if the bottom policy has a grayed-in box.
The following tables show the other user profile folders and the policies in which
they are defined.
Windows NT User Interface / Custom Folders Policy
User Profile Folder Contents
Programs Shortcuts to applications. Used in Start menu.
Desktop Desktop items, including files and shortcuts.
NetHood Shortcuts to Network Neighborhood items.
Start menu Shortcuts to program items.
Note

105

Office 97 / Common Policy


User Profile Folder Contents
Personal Shortcuts to program items. Also a central store for any
documents created by the user. Applications must be written to
save files here by default.
Templates Shortcuts to template items.

Using these policies, you can achieve the functionality of Roaming Profiles without as
much network traffic. This is because all of the folders used in Roaming Profiles are
downloaded to the local computer each time a user logs on, and then uploaded back
to the logon server when a user logs off. This can be a time consuming task that
unnecessarily overburdens your network. Furthermore, this can result in an unstable
state. If a user is logged on to two computers at the same time and modifies his or her
profile at both computers, only one set of modifications is saved because whichever
computer the user logs off from last overwrites the previous configurations. You can
use system policies to configure a path to these folders that remain consistent between
computers and guarantee that the users are always using the same data.
At this point, there is no automated method for creating these folders except for
setting up user profiles. You must create a template set of folders and copy these for
each user. However, the benefits gained in the long run can outweigh the time it takes
to do this.

Internet Explorer Security


This category of ZAKWinnt.adm contains two system policies. The first, Enable
Active Content, configures the active content settings which you can reach by
clicking the View menu, clicking Options, and clicking the Security tab. The
following table lists the configurable settings for the Enable Active Content security
policy.
Enable Active Content
Policy Results
Allow downloading of active content If this is selected, no active content is
downloaded, regardless of what the other
settings are.
Enable ActiveX controls and plug-ins If you do not want controls downloaded,
select this.
Run ActiveX scripts If you do not want users to run ActiveX
scripts, select this.
Enable Java programs If you do not want users to run Java
programs, select this.

You can use the second policy to set the Internet Explorer security level. This is
equivalent to configuring the Safety Level dialog box which you can reach by
Note

clicking the View menu, clicking Options, clicking the Security tab, and clicking
the Safety Level button. The three settings are described in the following table.
Active Content Security Level
Security Level Results
High If Internet Explorer detects any active content, the user is notified and
not allowed to download it.
Medium If Internet Explorer detects any active content, the user is notified and
given the option to download it.
None If Internet Explorer detects any active content, it downloads the content
without notifying the user.

If you clear the Active Content Security Level policy, the Registry settings are deleted.
When Microsoft Internet Explorer searches for and does not find these entries, it
defaults to high security.

Hiding Drive Letters


You can also use ZAKwinnt.adm to hide specific drive letters from users. The policy
(called Drives) offers a few default combinations, but it can be configured to hide any
combination of drives you deem necessary. The template is currently configured to
show no drives, show only C, show only U, show C and U, or Show C, O, and U. You
might remember that ZAK maps O: to the netapps share and U: to the users\
%username% share. The following is an example of how you can configure
ZAKWinnt.adm to hide drive letters.
CATEGORY !!Drives
CATEGORY !!Restrictions
KEYNAME
Software\Microsoft\Windows\CurrentVersion\Policies\Explorer

POLICY !!HideDrives
PART !!HideDrivesOptions DROPDOWNLIST
VALUENAME "NoDrives"
ITEMLIST
Name !!HideDrives_all VALUE NUMERIC 67108863
NAME !!HideDrives_C VALUE NUMERIC 67108859
NAME !!HideDrives_U VALUE NUMERIC 66060287
NAME !!HideDrives_CU VALUE NUMERIC 66060283
NAME !!HideDrives_COU VALUE NUMERIC 66043899
END ITEMLIST
REQUIRED
END PART
PART !!DriveRestrictions_Tip1 TEXTEND PART
PART !!DriveRestrictions_Tip2 TEXTEND PART
END POLICY
END CATEGORY
END CATEGORY
Note

107

[strings]
Drives="Drives"
Restrictions="Restrictions"
HideDrives="Hide Drives"
HideDrivesOptions="Choose Drives that will not be hidden:"
HideDrives_all="Don't show any drives"
HideDrives_C="Only C:"
HideDrives_U="Only U:"
HideDrives_CU="Both C: and U:"
HideDrives_COU="Both C: O: and U:"
DriveRestrictions_Tip1="NOTE: This policy conflits with the
Shell\Restrictions\Hide Drives"
DriveRestrictions_Tip2="policy defined in common.adm"

The system policy works by entering a decimal number in the


Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\NoDrives Registry
key. This decimal number corresponds to a 26-bit-long binary string, where each bit
represents a drive letter. The pre-configured options already in the template are listed
in the following table. With this information, you can customize the ZAKwinnt.adm
template to hide any combination of drives.
Decimal value Binary value Drives shown
67108863 11111111111111111111111111 All
67108859 11111111111111111111111011 C
66060287 11111011111111111111111111 U
66060283 11111011111111111111111011 C and U
66043899 11111011111011111111111011 C, O, and U

This policy conflicts with the Shell\Restrictions\Hide Drives policy defined in


Common.adm. Because system policies are evaluated in a top-down manner, make
sure that ZAKwinnt.adm is loaded after Common.adm. Otherwise the policies
defined in Common.adm will take effect.

By using the MS-DOS Subst command, you can assign a drive letter to a specific
local path. Using the Subst command along with this policy, you can assign a drive
letter to all folders that a user needs, and have the folders all located directly at the
root of the folder structure, while simultaneously hiding the system and all other
extraneous drives.

Implementing System Policies on the


Network
This section provides more information about how to prepare for using system
policies on the network. System policies can be downloaded from the network in the
following two ways:
Note

Automatic download means Windows NT Workstation automatically searches the


Windows NT Netlogon share to locate the Ntconfig.pol file. The policy settings
from Ntconfig.pol are then downloaded in the Registry of the local computer at
logon.
Manual download is an option for network administrators to point Windows NT
Workstation to a special location from which to download a .pol file.

Automatic Download
If you created a .pol file, Windows NT Workstation automatically searches for it in
the Netlogon share on a Windows NT network.

Windows NT Workstation takes advantage of load balancing and searches out any
available logon server. If your evaluation network uses only one domain controller,
then save Ntconfig.pol to the domain controllers logon share, usually:
%systemroot%\system32\repl\import\scripts

If, however, you are using multiple domain controllers, then you must ensure that the
same Ntconfig.pol is saved to all domain controllers logon shares. The best way to do
this is to save Ntconfig.pol to the export directory:
%systemroot%\system32\repl\export\scripts

and then enable directory replication. See the Windows NT Server Resource Kit for
information about directory replication.

Manual Download
If you have a set of users who are using Remote Access over 50 percent of the time
that they are on your network, you might not want to have them download the entire
Ntconfig.pol each time they dial in. Instead you can create a smaller profile called
RASconfig.pol and then manually configure each of their computers to download that
policy file instead.
If you use the Remote Update policy, you can configure Windows NT Workstation to
manually download policy files (even when they are stored locally) by indicating a
separate network or local computer location. Manual download overrides automatic
download and gives you the flexibility to determine where a users policies should be
stored.
You must set up the individual computers to allow manual download of system
policies.
109

It is possible to set up each computer for manual download individually, but this is
time consuming. If possible, it is better to set up each computer for automatic
download, and then use the Remote Update policy to point specific computers to
other servers as appropriate for your environment and users. However, all computers
that do not have a policy will use the Default Computer policy and will be configured
to manually download the specified policy. It is generally better to use Ntconfig.pol so
that you can take advantage of multiple domain controllers and logon shares, instead
of forcing all computers to load their policies from one server. The following example
shows how to configure a computer to manually download policies.

Configuring a computer to manually download policies

On Windows NT networks where you are using automatic download of policies, you
can set a system policy to allow manual download. This option works only after
system policies have been downloaded automatically the first time after Windows NT
Workstation is installed. The first automatic download includes information in the
system policies that defines the location to be used subsequently for manual
download.
To define the location of policies for manual download
1. Create a Global Group for the users who will download a separate policy and add
the users to this group.
For more information about creating Global Groups, see Organizing Files,
Shares, and User Accounts on the Server.
2. Open Ntconfig.Pol in System Policy Editor.
3. From the Edit menu, click Add Group.
4. Click Browse to select the group that you have created, and then click OK.
5. Double-click the group to open it.
6. Click Network, and then click Update.

Windows NT Workstation automatically downloads system policies from the


Netlogon directory of a Windows NT Server. On large networks, when thousands of
users log on at the same time, all accessing the same policy file, you might
experience slow network performance.
On a large network with multiple domain controllers, Windows NT spreads the load
over all of the domain controllers. However, this means that Ntconfig.pol must be
replicated to the logon shares of all the domain controllers. See the Windows NT
Server Resource Kit for details on how to set up directory replication.

Appendixes

Appendix A - Troubleshooting
Although not meant to specifically point out problems and their solutions to you, this
section provides methods that will help you troubleshoot a variety of problems you
might have in a zero administration environment.

Policy is not applied


If policy is being set with System Policy Editor but when the user logs on, the policy
is not being applied, these are several steps that can be taken to track down the cause.

Viewing a Remote Registry


A change in policy will alter a Registry setting on the target computer. One step that
can be taken is to look at the Registry of the target computer. For example, lets say
you set the policy for background wallpaper to be CompLogo.bmp but when the user
logged on, their wallpaper (background) is blank with no company logo.
111

The wallpaper value in the Registry is located in the HKEY_CURRENT USER


(HKCU) hive at HKCU\Control Panel\Desktop\Wallpaper. With the user still logged
on, you can load the remote Registry and look at this value. Suppose you find that
this entry has a value CompLogo.bmp.
This would mean the policy has been applied but the shell does not have access to
CompLogo.bmp. Either because it does not have the right path to CompLogo.bmp or
the user does not have access to the bitmap.
Suppose now you tried to set a policy for the Start and Search page of Internet
Explorer to CompStart.htm and CompSearch.htm. However, when the user logged on
and launched Internet Explorer only the default blank.htm was shown.
113

The Registry entry for Start and Search page are located at
HKCU\Software\Microsoft\Internet Explorer\Main\Start Page and Search Page,
respectively. If you load the remote Registry while the user is logged on and see that
the settings for the users Start and Search page are empty. The empty values indicate
the policy is not being applied. This might mean something as simple as the policy
file was not saved after the setting was made. However, if the policy file was saved,
you should check the data in the Ntconfig.pol file.

Viewing Ntconfig.pol with a Registry Editor


Ntconfig.pol is just a Registry hive, and as such it can loaded into the Registry just
like any other hive.
1. Start regedt32.exe
2. Select the root of the HKUsers hive, and select Load Hive from the Registry
menu.
3. Browse to the location of your Ntconfig.pol file. Double-click the Ntconfig.pol file
or click Open.
4. When prompted for a key name type in a temporary key name like, TempDebug.

Once the hive is loaded, you can find the user or the group for which the policy has
been set. For example if the group in Policy Editor is Taskusers you will find a key
called Taskusers. Under the Taskusers key you will find all the policy settings for that
group in the form of a miniature hive. You need to locate the Start and Search page
values in this hive. You might find that the values in the Ntconfig.pol file do not
match what you have set using Policy Editor. The next two figures show Registry
entries for the Start and Search pages in Ntconfig.pol that do not match what was
previously set.

In the first case, the Registry setting that configures the Start and Search pages is
blank. This means that the current Registry settings on the users computer will not
be changed. This result occurs in Ntconfig.pol when the policy is grayed out, not
checked as in the previous sample.
115

In the second case, there is a **del in front of the Registry settings, meaning that they
will be deleted.
Both of these settings in the Ntconfig.pol file are probably a result of a policy conflict.
If multiple policies set the same Registry key, the policy listed last in System Policy
Editor is the one which will be set. It does not matter if the last policy is grayed,
checked or cleared; it will override any existing policy configuring the same Registry
key.
Policy conflict can occur when multiple template files configure the same setting.
Because many different templates were gathered for the Zero Administration Kit this
can happen. One instance of this is the Start and Search pages for Internet Explorer.
They can be set in the Definition of Home and Search pages policy or the Internet
Explorer 3.0, Options Navigation.

Because the Internet Explorer 3.0, Options_Navigation policy is below the


Definition of Home and Search Pages policy, it is the one that determines what is
actually entered into Ntconfig.pol
Note

Auditing and Using Event Viewer


If you think that applications might not be working properly because of the strict
security on the client, you can use auditing to monitor the reads and writes to the file
system in order to determine where the application is failing. You can turn on
auditing for a computer remotely from a server with any account that has Domain
Admin privileges.
1. Launch User Manager for Domains
2. In the User menu, select Select Domain
3. In the Select Domain dialog box, type \\<name of the remote computer>
4. In User Manager, on the Policies menu, click Audit.
5. In the Audit Policy dialog box, select Audit These Events, and then select the
events that you want to audit.

You must also configure the local file system on the ZAK client to audit events on a
per-user or per-group basis. To do this from a remote computer you must do the
following:
1. Map the remote drive
2. Select the files and folders that you want to audit.
3. On the File menu of Explorer, click Properties.
4. In the Properties dialog box, click the Security tab, and then click Auditing.
5. To add users or groups to audit, click Add.
6. In the Names dialog box, select all of the users and groups that you want to audit
and click Add.
7. Back in the Directory Auditing dialog box, select the events that you want
audited. You must do this separately for each user or group that is listed above.

Because the security log size is limited, select the events to be audited carefully, and
consider the amount of disk space that you are willing to devote to the security
log. The maximum size of the security log is defined in Event Viewer.

You can use Event Viewer to view Auditing results on the remote computer.
1. Load Event Viewer.
2. On the Log menu, click Select Computer.
3. In the Select Computer dialog box, type the computer name.
4. In the Event Viewer window, on the Log menu, click Security.

You will now see a list of all audited events on the ZAK client. To view one, simply
click it.

Debug Userenv.dll
The debugging version of Userenv.dll, which is the same as the retail version except
that it contains debugging flags that you can use to create a log file of what is
happening when user profiles and system policies are being loaded.
117

For more information on Userenv.dll, see the Windows NT Device Driver Kit and the
Windows NT 4.0 Profiles and Policies white paper.

Replacing the Taskstation Shell with Cmd.exe


A quick way to edit a Taskstation is to replace the normal Internet Explorer shell with
Cmd.exe. Remember, if you have placed security on Cmd.exe, point to either the
remote Cmd.exe that you have put on the server, or remove the security before
applying this policy.

Appendix B - Utilities and Commands

Attrib
Displays or changes file attributes.
ATTRIB [+R | -R] [+A | -A] [+S | -S] [+H | -H] [[drive:][path]filename] [/S]
+ Sets an attribute.
- Clears an attribute.
R Read-only file attribute.
A Archive file attribute.
S System file attribute.
H Hidden file attribute.
/S Processes files in all directories in the specified path.

CACLs
Displays or modifies access control lists (ACLs) of files.
Usage:
CACLS filename [/T] [/E] [/C] [/G user:perm] [/R user [...]]
[/P user:perm [...]] [/D user [...]]

filename Displays ACLs.

/T Changes ACLs of specified files in the current directory and all


subdirectories.
/E Edits ACL instead of replacing it.
/C Continues on access-denied errors.
G user:perm Grants specified user access rights.
Perm can be:
R Read
C Change (write)
F Full control
/R user Revokes specified user's access rights (only valid with /E).
/P user:perm Replaces specified user's access rights.
Perm can be:
N None
R Read
Note Hint

C Change (write)
F Full control
/D user Denies specified user access.
Wildcards can be used to specify more that one file in a command.
You can specify more than one user in a command.

Con2Prt
Con2Prt provides scriptable functionality to the Add Printer wizard, so that you can
simply write a script to add printers on client computers.
Con2Prt: Lets the user disconnect all existing connections to Windows NT printers
and connect to newly specified Windows NT printers.
Usage: CON2PRT [ /? | /h | /f |
[/c \\printserver\share | /cd \\printserver\share]+]
where:
/? - displays usage.
/h - displays usage.
/f - deletes all existing printer connections.
/c - connects to \\printserver\share printer.
/cd - connects to \\printserver\share printer and sets it as the default printer.
The /? and /h parameters can only be the first parameter and, if specified, further
interpretation of the command line is stopped. The /f parameter can also only be the
first parameter, however it doesn't stop further interpretation of the command line.
Any number of /c and /cd parameters can be specified, however only the first /cd sets
the printer specified as the default.

Use Net View \\printserver to determine available print shares.

FixPrf
A Microsoft Exchange client does not automatically load or create a profile for the
user who is currently logged on. Instead, Exchange prompts the user either for the
name of the profile or to create a new one. FixPrf automatically uses the user name of
the logged on user and creates or loads the profile automatically.
FIXPRF: Changes MailboxName, ProfileName, and HomeServer in an Exchange
PRF file. This PRF file is used to create a profile for use by mail.
Usage: FIXPRF <Fully Qualified Path to .PRF file> <MailboxName> <ProfileName>
<ExchangeServerName>

FloppyLock
If the FloppyLock service is configured to start automatically, the lock stays in place
even after the computer is restarted. You can use this service to prevent the
unauthorized installation of software or the introduction of viruses via the floppy
disks.
119

Currently, there is no way to put a lock on floppy drives or on the COM ports with
REGEDT32, or using the Control Panel or other part of the user interface. And there
is no way to use the Win32 API to lock floppy drives that survives restarting the
computer.
FloppyLock, however, uses Discretionary Access Control Lists (DACLs) to control
access to floppy drives. These DACLs survive users logging off and logging on. When
the service is started on Windows NT Workstation, only members of the
Administrators and Power Users groups can access the floppy drives. When the
service is started on Windows NT Server, only members of the Administrators group
can access the floppy drives.
To use the FloppyLock service, you must first install Floplock.exe as a service on
every computer where you want to lock the floppy drives. Then use Control Panel to
configure this service to start automatically.

INSTSRV
INSTSRV: Installs and removes system services from computers running
Windows NT
Usage: INSTSRV <service name> (<exe location> | REMOVE)
[-a <Account Name>] [-p <Account Password>]

Install service example:


INSTSRV MyService C:\\MyDir\\DiskService.Exe
-OR-
INSTSRV MyService C:\\mailsrv\\mailsrv.exe -a MYDOMAIN\\joebob -p myfile

Remove service example:


INSTSRV MyService REMOVE

RunApp
You can use RunApp in TaskStation mode to instantiate the user interface application
and automatically restart it in cases where it is accidentally closed. RunApp takes a
single parameter: The name of the .exe to automatically restart.

Shutdown
You can use this utility to restart a computer, either locally or remotely. ZAK Setup
uses the Shutdown command to restart the client computer in between the
Windows NT/Service Pack installation and the Office 97 installation.
\\computername specifies a remote computer to shut down. Note that if no name is
given but the utility is started with any of the other options, the local computer name
is used.
/l specifies a local shutdown.
/a aborts a system shutdown. This is only possible during the timeout period. If this
switch is used, all others are ignored.
/r specifies that the computer should reboot after shutdown.
/t:xx sets the timer for system shutdown in xx seconds. The default is 20 seconds.
Caution Note

"msg" specifies an additional message of a maximum of 127 characters, surrounded


by quotation marks.
/y answers all following questions with yes.
/c forces running applications to close.

If you use the /c parameter, Windows NT ignores the application's option to save data
that may have changed. The File Save dialog box does not display because
Windows NT forces the application to close. This results in a loss of all data not
previously saved.

/? (or shutdown without parameters) shows all command-line options.


To schedule Remote Shutdown for a specific time, use the AT command.

Appendix C - More on System Policies

Policy Clashes
A problem can arise when two templates try to configure the same Registry setting.
Whichever template is closest to the bottom in the System Policy Editor window will
be processed last, overwriting the Registry setting of the previous policy.
Some policies in ZAK exhibit this behavior. Both the Off97nt4.adm and Ieak.adm
have policies for Microsoft Internet Explorer, Start Page, Search Page, Proxy
Enabled, Proxy, and Proxy Override. However, the Off97nt4.adm entries appear lower
in the policy file when both templates are loaded , and because the policies are
evaluated top to bottom it is possible to accidentally override what you really want to
set.
The solution is to is to make backup copies of the original policy templates and then
edit them to remove the duplication. For detailed discussion on creating and
customizing policy templates see Overview of System Policies, earlier in this
document..

Function Calls
These functions are here as suggestions to programmers who are coding applications
that need to store and retrieve data on the local file system. Although this is not
intended as a guide for programmers, these functions can help you get started.

The ExpandEnvironmentStrings API


Whenever an application tries to access a folder, the application should be able to
expand environment strings such as %systemroot% or %Username%. The
ExpandEnvironmentStrings function expands environment-variable strings and
replaces them with their defined values. A program using this function gives you the
freedom and ability to store specific folders remotely or in their non-default positions
with only minor effort.
121

For further information on the ExpandEnvironmentStrings function, refer to the


Platform SDK.
DWORD ExpandEnvironmentStrings (
LPCTSTR lpSrc, // pointer to string with environment variables
LPTSTR lpDst, // pointer to string with expanded environment
variables
DWORD nSize // maximum characters in expanded string
);

Parameters
lpSrc
Points to a null-terminated string that might contain references to environment-
variable strings of the form:
%variableName%
For each such reference, the %variableName% portion is replaced with the
current value of that environment variable.
The replacement rules are the same as those used by the command interpreter.
Case is ignored when looking up the environment-variable name. If the name is
not found, the %variableName% portion is left undisturbed.
lpDst
Points to a buffer to receive a copy of the source buffer, after all environment-
variable name substitutions have been performed.
nSize
Specifies the maximum number of characters that can be stored in the buffer
pointed to by the lpDst parameter, including the terminating null character.

Return Values
If the function succeeds, the return value is the number of characters stored in the
destination buffer. If the number of characters is greater than the size of the
destination buffer, the return value is the size of the buffer required to hold the
expanded strings.
If the function fails, the return value is zero. To get extended error information, call
GetLastError.

SHGetSpecialFolderLocation
When applications must locate a special folder, such as the Programs folder or the
Personal folder, this function can be called to retrieve its location. A program that
uses this function gives you the freedom of placing special folders anywhere.
WINSHELLAPI HRESULT WINAPI SHGetSpecialFolderLocation(;
HWND hwndOwner,
int nFolder,
LPITEMIDLIST *ppidl
);
Parameters
hwndOwner
Handle of the owner window that the client should specify if it displays a dialog box
or message box.
nFolder
Value specifying the folder to retrieve the location of. This parameter can be one
of the following values:
CSIDL_BITBUCKET
Recycle bin file system directory containing file objects in the users recycle
bin. The location of this directory is not in the registry; it is marked with the
hidden and system attributes to prevent the user from moving or deleting it.
CSIDL_COMMON_DESKTOP
File system directory that contains files and folders that appear on the desktop
for all users.
CSIDL_COMMON_PROGRAMS
File system directory that contains the directories for the common program
groups that appear on the Start menu for all users.
CSIDL_COMMON_STARTMENU
File system directory that contains the programs and folders that appear on the
Start menu for all users.
CSIDL_COMMON_STARTUP
File system directory that contains the programs that appear in the Startup
folder for all users. The system starts these programs whenever any user logs
on to Windows NT or starts up Windows 95.
CSIDL_CONTROLS
Control Panel virtual folder containing icons for the control panel
applications.
CSIDL_DESKTOP
Windows desktop virtual folder at the root of the name space.
CSIDL_DESKTOPDIRECTORY
File system directory used to physically store file objects on the desktop (not to
be confused with the desktop folder itself).
CSIDL_DRIVES
My Computer virtual folder containing everything on the local computer:
storage devices, printers, and Control Panel. The folder may also contain
mapped network drives.
CSIDL_FONTS
Virtual folder containing fonts.
CSIDL_NETHOOD
File system directory containing objects that appear in the network
neighborhood.
123

CSIDL_NETWORK
Network Neighborhood virtual folder representing the top level of the
network hierarchy.
CSIDL_PERSONAL
File system directory that serves as a common repository for documents.
CSIDL_PRINTERS
Printers folder virtual folder containing installed printers.
CSIDL_PROGRAMS
File system directory that contains the users program groups (which are also
file system directories).
CSIDL_RECENT
File system directory that contains the users most recently used documents.
CSIDL_SENDTO
File system directory that contains Send To menu items.
CSIDL_STARTMENU
File system directory containing Start menu items.
CSIDL_STARTUP
File system directory that corresponds to the users Startup program group.
CSIDL_TEMPLATES
File system directory that serves as a common repository for document
templates.
ppidl
Address that receives a pointer to an item identifier list specifying the folders
location relative to the root of the name space (the desktop).

Return Values
Returns NOERROR if successful or an OLE-defined error result otherwise.
125
127
129
131