Zero Administration Kit: The Answer to Your TCO Woes?

ZAK can improve administrative desktop control—and the bottom line

Microsoft has spent a lot of marketing time and money in the past year to emphasize the importance of lowering total cost of ownership (TCO) in a Windows-based environment. First, Microsoft announced its Zero Administration for Windows (ZAW) initiative, a set of core technologies for lowering the TCO of PCs. (ZAW is a sequence of recommended steps for lowering TCO, rather than one product release; for details, see Mark Minasi, "Zero Administration for Windows," December 1997.) Then, ZAW kicked off in earnest with Microsoft's release of Zero Administration Kit (ZAK) 1.0 for Windows NT 4.0 and Windows 95. ZAK is a set of system policies and policy templates, scripts, and methodologies that make Windows-based computers easier to manage by performing three functions: centralizing configuration, eliminating local access to the desktop computer, and allowing storage of applications and data on the network server. ZAK is a first step toward lower TCO, but is it a step in the right direction? To answer that question, I'll explain ZAK and show how to install it and take full advantage of its strengths.

On its Web site, Microsoft cautions that ZAK is for a pilot network, so that systems administrators can get an idea of ZAK's capabilities. But I will show you how you can use some of ZAK's components right now to begin lowering your company's TCO. To start, download a free copy of ZAK from Microsoft's Web site at http://www.microsoft.com/windows/zak.

In the Mode
The driving force behind ZAK is Microsoft's idea of defining workstation and user configurations by the roles they perform on the job. ZAK comes with configuration options for two predefined modes, TaskStation and AppStation. TaskStation mode is for task-oriented workers, such as order entry clerks. These are people who require access to only one business application. AppStation mode is for knowledge workers: those people who run three or four business applications but don't need to access system configuration options or install other applications.

TaskStation, the configuration for single-function workstations, boots directly into Internet Explorer (IE) or any business application a systems administrator specifies. TaskStation relies on a set of system policies and file permission scripts to provide a complete lockdown of the desktop. (File permission scripts deny users access to, or change the default access for, parts of the local file system that might get them into trouble: for instance, Program Files and %systemroot%.) This configuration disables the Windows user interface to prevent the user from accessing additional applications, including the Start button, Taskbar, Task Manager, Control Panel, and the file system.

AppStation, like TaskStation, is a relatively restricted configuration, but it gives users more freedom on the desktop than TaskStation does. AppStation has more relaxed system policies and file permissions. AppStation boots the desktop into the Windows user interface to let users access only the business applications they need: Users cannot access Control Panel or the file system. Users run applications and access documents from the server. Although most of your users will not fit precisely into the AppStation profile, the AppStation mode can nevertheless provide a useful base from which you can build a more customized managed desktop. If you use the standard NT 4.0 unattended setup process and some other well-known install features, such as the RunOnce option, you can customize an AppStation configuration to meet your specific application needs.

A Percentage of Control
Although ZAK has interesting potential, it also has limitations. ZAK is a good first attempt by Microsoft to help systems administrators reduce the cost of maintaining a large number of desktops in an enterprise environment. Microsoft's approach is: The less trouble users can get into with their workstations, the lower support costs will be. An NT desktop presents a large number of potential problems. The challenge is to balance desktop control with user functionality. The AppStation and TaskStation modes may not provide viable options for all enterprises, but most systems administrators will agree that open desktops are an invitation to disaster.

I estimate that ZAK will give you between 50 percent and 75 percent of the control you want on the user's desktop, which is a big improvement over the control you have without ZAK. However, several holes in this program are still potential trouble-causers.

Case in point: When you're in AppStation mode, system policies let you disable right-clicking of desktop elements, but a user can still press Alt and Enter and get the same properties dialog box as with right-clicking. Then all the user has to do is use the Find Target button to navigate a potentially large file tree on a server. Make sure your NTFS permissions are in place! The same Alt and Enter will bring up the My Computer icon, which brings up the System Control Panel applet for a user's manipulation. Use the policy that disables access to folders in Settings on the Start menu to prevent access to Control Panel. Unfortunately, this policy also disables access to the Printers Wizard, and ZAK provides no granularity for disabling only one or the other. (You can overcome some backdoor manipulations by curious users through a combination of Registry tweaks and file permissions, or by using utilities such as PowerToys, but incorporating all these configurations into your workstation install process can be a challenge.)

Then you face the fact that, although you can disable the Run option from the Start menu, the version of File Manager that ships with NT 4.0 doesn't respect that restriction. Sure, you can set file access control lists (ACLs) on winfile.exe, but if some users need access to the Run option and some don't, you've got an ACL-management nightmare on your hands. You'll also have to contend with the problems that arise when users who can access certain utilities email those utilities as attachments to users who can't access them.

A final example: The acls.cmd script that ships with ZAK provides overly restrictive file system controls. I've found problems with it in an environment using Systems Management Server (SMS), even though ZAK specifically tries to account for the trouble this script causes in SMS. In some cases, by restricting C:/Recycler, the script prevents the Recycle Bin from functioning properly.

You'll find other problems like these as you go through the desktop with ZAK. My advice: Don't take ZAK and its rather limiting AppStation and TaskStation modes at face value. Instead, take advantage of specific components and concepts in AppStation and TaskStation. (See the sidebar, "Hidden Treasures in ZAK," for information on some nifty utilities in ZAK.) Let's begin by installing ZAK.

Basic ZAK Installation
ZAK isn't just a set of scripts and policy files. It builds an unattended setup distribution that creates server shares for installation of an NT 4.0 (or Win95) workstation complete with Service Pack (SP) 3. (You'll need a lot of disk space on the server where you install ZAK.) The setup program tells you that you need 500MB of free disk space to install a TaskStation and 1GB to install an AppStation. This requirement is because you'll be copying the contents of the NT platform distribution source directory (e.g., i386), SP3, and, for an AppStation, Microsoft Office 97 to your server. Before you run the installation, make sure you have your NT Workstation 4.0 and SP3 CD-ROMs (and your Office 97 installation CD-ROMs, if you want to install AppStation mode). A comprehensive list of system requirements is available on Microsoft's Web site.

Once you download and expand the zak.exe file, run zaksetup.exe from the platform folder of your choice (e.g., i386) to begin installing ZAK source. Note that you are specifying the platform for your intended ZAK clients, not for the server where the files are installed: Microsoft includes source files for both Intel- and Alpha-based systems. After you choose the platform, you must select which mode you want to install. I'll describe how to install the AppStation. After you're familiar with how ZAK works, you can easily perform a TaskStation installation.

As you follow the setup wizard through the installation of an AppStation, you will create several folders on a distribution server you will use to install ZAK clients. ZAK setup will first copy all scripts, policies, and tools to a folder on the distribution server. You will be asked to provide information about Exchange servers, if you're using Exchange, and also to provide a path to a shared printer. (ZAK uses information about the printer path to create a customized logon script that connects users to the printer at logon time.) Then you will be prompted for the NT Workstation 4.0 setup CD-ROM, your SP3 CD-ROM, and finally your Office 97 CD-ROM, if you're installing an AppStation. ZAK setup assumes you'll run Office 97 from the server and performs a server-based install (setup /a) of the Office 97 binaries.

When ZAK setup is complete, you will see the following three folders on your server. (ZAK provides these file names as defaults. You can change them during the client installation.)

NETAPPS. This folder contains the Office 97 server-based binaries; an Exchange .prf file, which provides a template for configuring your user's Exchange/Outlook client profile; and a server-based Start Menu folder. You can use the NETAPPS folder and your own shared policy-based system folders to distribute custom Start menu items to ZAK clients within your environment.

ZAKADMIN. This folder contains the logon scripts, system policy file, and policy templates ZAK uses to map drives and printers and enforce desktop controls.

ZAKAPPDIST. This folder contains the NETSYS subfolder, which contains the i386 bits for installation of an NT 4.0 workstation. The i386 directory structure also contains the $OEM$ directory, a special directory the unattended setup script uses to copy files to the workstation and perform setup tasks (see Christa Anderson, "Designing Unattended NT Installations," March 1997).

Manual Setup Tasks
You've completed ZAK basic installation. Now you must perform some manual tasks before you can go forward with a ZAK client install.

Step 1: Set up the shares. You must share two of the folders the setup created so that your client machines can access them: the NETAPPS folder and the NETSYS subfolder. You must share the NETAPPS folder as NETAPPS, because ZAK logon scripts in the ZAKADMINLogon Scripts folder refer to that name. You can call the NETSYS share by any name, because setup references it only as you download the operating system (OS) to your client machine.

Step 2: Create the user groups. ZAK uses NT system policies to enforce desktop control of AppStation and TaskStation users. To apply these policies within your authentication domain, you must create two global groups that the policy file will use. Screen 1, page 160. shows the ZAK policy file and the two groups (AppUsers and TaskUsers) you must create.

Step 3: Copy required files to the Netlogon share. If you use NT's directory replication to replicate logon scripts, you must copy a couple of files from ZAK to your replication source, which is usually in %systemroot%system32replexportscripts. First, in ZAKADMINPolicy Files, copy zakconfig.pol (the system policy file) to Netlogon, and rename it ntconfig.pol. This file name is the default system-policy file name for NT machines, and it will let NT clients find the policy file automatically. Second, copy the logon script for your ZAK client to Netlogon. This logon script file is in ZAKADMINLogon Scripts and is named applogon.cmd (or tasklogon.cmd for TaskStation workstations). This script performs the basic drive mappings, printer connections, and Exchange setup you specify during ZAK setup. Double-check this file before copying it to your replication server to ensure that the correct server names are used to connect to the correct drives. By default, AppStation defines the O: drive as the connection to NETAPPS and the U: drive as the connection to the user's home directory.

Step 4: Modify unattend.txt file. For some reason, ZAK setup doesn't copy a modified unattend.txt file to the i386 directory, so you must customize this file and move it to ZAKAPPDISTNETSYSi386. An annotated version of unattend.txt is in ZAK setup source folders under ZAKscripts. Screen 2 shows the contents of the unattend.txt file in an edit window. A good idea is to use edit.com or another basic text editor to edit this file. Using Notepad to edit the file saves unwanted control characters that can prevent the unattended setup script from being read correctly.

Installing the First Client
Now you're ready to install your first ZAK reference client, from which you'll build your ZAK AppStations. This installation involves a process you may already be familiar with: using NT 4.0's unattended setup scripts. From a computer connected to your network, use the Microsoft DOS TCP/IP (or NetBEUI) client to connect to the NETSYS share on your ZAK server. Then, using the winnt command, begin an NT 4.0 workstation installation with the unattend.txt file you just modified in Step 4. As an example, the following command uses the unattended setup script to install NT from a drive mapped to NETSYS at P:

P: winnt /u:p:unattend.txt /s:p:i386

The first workstation is installed. Now you must copy default shortcuts from the workstation's All Users profile to the NETAPPSStart Menu folder. ZAK system policy uses these shortcuts to deliver shared folders to the AppStation user's Start menu.

First copy the shortcuts (and only the shortcuts) located in %systemroot%profilesAll UsersStart Menu to the NETAPPSStart Menu folder. Next, copy all the shortcuts in %systemroot%profilesAll UsersStart MenuPrograms to NETAPPSStart MenuPrograms.

You need to copy these shortcuts to the server share only once. After the shortcuts are copied and in place, the policy file will use them to build a custom Start menu for your ZAK users.

After you have copied these default shortcuts to the appropriate folders, the next workstation you install from ZAK shares will be a fully functional AppStation. If you log on now using an ID from the AppUsers global group, you will see how ZAK restricts access to desktop elements while providing Office 97 and Internet Explorer from the Start menu.

Behind the Scenes in ZAK
Now that you've installed your first ZAK client, you might be wondering what really happened during the setup procedure and how the AppStation desktop is enforced. You'll find the answers to your questions, and the keys to ZAK's power, in the following three areas:

Let's take a quick look at these scripts and files to see how they work.

The cmdlines.txt file. The cmdlines.txt file runs from the NT 4.0 Unattended Setup when you specify OEMPreinstall=Yes in unattend.txt. The cmdlines.txt script calls %systemroot%zakscripts
appcmds.cmd, which performs Registry changes to

Next, to prevent an automatic reboot, the /z parameter is used to apply the service pack to the workstation. Finally, the default Help file is renamed, and a ZAK Help file takes its place. Replacing the default Help file prevents users from accessing the full Windows Help, which contains operating information you might not want to expose. At this point, setup is complete and the system reboots.

The zakb1wrk.cmd script. After the reboot, the automatic logon function that the cmdlines.txt file enabled logs on the workstation, using the local Administrator account. The zakboot1.cmd script is then executed and calls zakb1wrk.cmd from %systemroot%zakscripts. The zakb1wrk.cmd script performs most of the application installation and customization work. This script also includes steps that you may want to comment out, depending on your environment. For example, you would install an SMS client only if you use SMS. Tasks zakb1wrk.cmd script performs include

The zakconfig.pol file. Finally, zakconfig.pol, the system policy file, enforces many desktop controls once a user logs on to the system. ZAK provides policy template files (*.adm) in addition to the policy template files NT includes. Specifically, several templates control each of the products in Office 97 and IE. One ZAK template file, zakwinnt.adm, provides additional control over users' profiles and what drives they can see. Screen 3 gives an example of some restrictions ZAK system policy applies to AppUsers—in this case, restriction on the behavior of the Explorer shell. Screen 4 shows how the policy folders are delivered to an AppUser's Start menu (the content of O:Start MenuPrograms is delivered to the Start menu under the Programs item). It's important that you flag server-based policy folders as read-only files. Otherwise, users who accidentally delete these files will affect all other users who point to this folder.

Getting the Most from ZAK
As you were taking this in-depth look at ZAK and going through the installation process, you might have said to yourself, "I'd never use a ZAK configuration in my enterprise." I hope I've shown you that you can take advantage of many elements of ZAK without employing a full AppStation or TaskStation configuration. For example, you may have seen that the system policy templates can help you build the kind of desktop restrictions you need when you offer your users Office 97 or IE. The unattended setup may trigger ideas you can put to work in your installation process. And you may be able to use one or more of the utilities described in the sidebar to adjust your system of desktop control to a more effective level. ZAK offers gold nuggets to the systems administrator who prospects for them.