A Scripted Solution for Complex Networking Problems

What began as a patch to an application-accessibility problem at Children's Hospital, Boston, ended as a full-scale rollout of centrally managed PCs. After solving the accessibility problem, the hospital's IT group uncovered several weaknesses in network design. Users needed access to applications in a multitasking environment, whereas the IT staff needed to maintain the ease of administration in a terminal-based environment. The following article describes a complex, scripted solution that the hospital's IT staff developed in response to the problems.

In late 1996, some hospital clinicians expressed concern that a single-application connection to their online patient records wasn't doing the trick. An Oracle database on the VMS server contained all patient records. The clinicians were using green-screen video display terminals (VDTs) to connect to the database server, but the terminals displayed only one application (i.e., one patient record) at a time. When the clinicians wanted to collect information from various sources, they had to open each application, write down pertinent information, close the application, and open the next.

To resolve this problem, the IT department introduced PCs and WRQ's Reflection 6.0 for UNIX and Digital 6.0. This solution let clinicians run multiple terminal sessions from Windows 3.x. However, running multiple terminal sessions generated problems because each session required its own socket. This situation generated increasing amounts of network bandwidth and CPU cycles as the system added sessions. To solve increased network-utilization problems and deliver patient data to clinicians' desktops, the IT department developed a Web-based front end to the database, called Results Reporting, through Netscape Navigator 4.03. The application gave users access to the Results Reporting database by using Common Object Request Broker Architecture (CORBA), HTML, Perl, and Java.

The IT group now realized that clinicians needed a multitasking environment and customized-application suites based on user identity and PC location. The challenge was to provide a multitasking environment while maintaining ease of administration. And how could the IT staff easily replace the 5000 terminals currently distributed among the 12 buildings of Children's Hospital, Boston?

A terminal server-based application set that permitted hospital staff access only to needed applications wasn't a practical solution. The movement from VDTs to Windows-based PCs began in early 1997, and only Citrix WinFrame-based versions of multiuser NT were available. (Microsoft didn't release Windows NT Server 4.0, Terminal Server Edition until July 1998.) Terminal-server distribution wasn't a viable solution because of the network's size and distribution.

In addition, the IT staff also wanted to use the NT 4.0 GUI. Multiuser NT supports about 12 to 15 users per CPU for average usage levels or up to 50 users for occasional usage. To support the 5000 terminals already in place, the hospital needed a minimum of 100 terminal server CPUs—even with light usage. The staff thought that installing the applications locally and locking them down seemed more practical.

The Cure
The hospital's IT staff worked for 5 months to develop two tools to address two key problems. Staff members included Ron Ingrassia, Alex Khayat, Jamie Desova, Benjamin Marshall, Michael Comier, Steven Mullen, Douglas Caldwell, Richard Chalifoux, and Kevin Murray.

The first tool involved using an unattended installation script to install NT and user applications in one of three available configurations and on one of two available platforms. The second tool involved writing a set of machine and user policies to determine the user's access to the OS and the installed applications. Depending on a computer's location and the person's identity logging on, a computer might have one of the following configurations:

The unattended installation script and system policies resulted in a three-step process:

Script on a Disk
The IT staff decided to install the various installation scripts from a disk and a CD-ROM. Using the DOS 6.22 Menu command, Khayat developed a menu system that let systems administrators specify which type of computer and tier configuration they wanted to build. Running from the disk's autoexec.bat and config.sys files, the script formats the 4GB hard disk into C: and D: partitions, connects to the installation server holding the program files, and installs the appropriate files. All application and OS files go on the C: partition, and the Microsoft Systems Management Server (SMS) 1.2 client files (used for updating virus signatures, upgrading applications, and remote control-based troubleshooting) go on the D: partition. The installation works quite smoothly, requiring no user intervention after the systems administrator selects the workstation's platform and application tier. Using scripts on disks or CD-ROMs, a systems administrator can install NT and a complete application suite in about 25 minutes on as many computers as the network can handle.

The installation process creates one of two basic configurations: locked-down Tier 1 and Tier 2 computers, and fully open Tier 3 computers. The exact application set available to clinicians using the locked-down computers depends on the computer's physical location and the clinicians' group membership.

A Matter of Policy
When a user logs on to any network computer, three actions define the user interface: the system policy runs, the shell loads, and the logon script executes. The system policy defines most settings, and the shell contains the desktop's appearance. Any required driver or application updates run during and after the logon script. The system uses one large 3.7MB system policy to support approximately 70 NT domain groups. The system subdivides the system policy at the departmental- and user-group levels. This system policy defines everything about the computer's accessibility (e.g., desktop wallpaper, hidden DOS windows, custom desktop, Start menu icons). In short, the system policy defines anything you can control from the console.

According to Khayat, the My Computer icon was the only unwanted piece of the interface that he couldn't delete. Apparently, Microsoft insists that this icon and folder remain. However, Khayat was able to edit the folder's contents so that a user only saw personally accessible drive letters.

When the computer first connects to the server, the system policy takes about 1 minute to download to the computer's hard disk. Subsequent logons take only about 5 seconds because the policy is already present on the hard disk.

The Registry's Rescue
Originally, Khayat tried to use NT's System Policy Editor (SPE) to build the system policy, but he found that creating and editing policies directly from regedt32 was easier. Khayat said, "Ntconfig.pol is a binary and compressed version of the Registry. The only reason that there's a policy editor is to make it easier for those unused to working with the Registry to make policies. However, it's simpler to edit two keys by hand and import those changes than to write 50 lines of code to do the same thing." Direct edits supplement a customized children.adm file that created a standard look and feel (e.g., custom colors, sounds, wallpaper with the hospital logo) for all the hospital's network computers.

The system doesn't always apply the system policy. The setup changes when a user logs on to a Tier 3 computer, which the hospital locates only in personal offices. Win32 OSs have a default policy-handler file that merges the specified policy settings into the local Registry. However, you don't have to use this policy handler. Instead, you can create a DLL that has additional instructions and edit the Registry so that the PolicyHandler key points to both the new policy downloader DLL name, and the part of the DLL that merges policy data into the Registry (i.e., the function name).

As you can see from the following Registry setting, the hospital's new downloader DLL name is policy.dll and the function name is ProcessPolicies:

[HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NT CurrentVersionWinlogon]"PolicyHandler"="policy.dll, ProcessPolicies"

Policy.dll looks for a 1KB NoPolicy file in NT's root directory. If NoPolicy exists, the policy associated with that user doesn't execute. If NoPolicy exists, the policy executes and the system gives the user who is logging on restricted access based on user identity.

Timing Is Crucial
The user interface (UI) relies heavily on policy. The IT staff defines user icons based on department and stores the icons in the iconsdesk or iconsstart folders of the departments' shared directories. Some applications that the system policy defines are shell-dependent, so the timing of loading shell components is also important. The NOS/OA group ensures that the computers' CPUs load the appropriate shell quickly so that applications can find crucial shell components.

Tier 1 computers run in TaskStation mode, which is functionally equivalent to a VDT. When a user logs on to TaskStation mode, the customized shell (referenced in HKEY_LOCAL_MACHINE SOFTWAREMicrosoftWindows NTCurrentVersionWinlogonShell = S:\runshell.wsh) runs in a loop and checks intermittently to ensure that the two open applications—Netscape Navigator and Reflections—are still in their predefined locations. (\ in the above statement indicates that you're running a script on S instead of referencing a folder.)

The runshell.wsh file is a Windows Scripting Host (WSH) file that calls a couple of batch files running on the server. One batch file opens Netscape Navigator, and another batch file opens Reflections. Each batch file loads the software and checks every 5 seconds to ensure that the application is running as originally set up. Any changes users make to the kiosk environment don't last because the system restores the environment to its original state every 5 seconds.

The other two tiers have a more open desktop. Tier 2 users get an abbreviated desktop and can access only their network directories: Private (P) and Shared (S). Tier 3 users get a nearly complete user desktop with access to local drives and to a larger home and shared directory. The IT staff uses Argent's Quota Server 2.1 to limit all user directories to about 25MB per user.

The logon script's function is to update the local settings. This function includes retrieving updated virus signatures and applications to the client (via SMS), creating a hardware and software inventory for the SMS server, and creating default printer connections.

Creating default printer connections is more complicated than it might appear, however. Clinicians won't always work from the same computer, and not all clinicians get to use all printers. To resolve this problem, Khayat integrated the con2prt utility from the Zero Administration Kit (ZAK) with the logon scripts to connect a current user's session to the closest available printer and made that printer the default.

Large-Scale Headaches
Unlike other applications, NT is meant for large-scale installations. Hospital staff required a diverse array of applications, including Microsoft Office 97, Adobe Acrobat, Netscape Navigator, the Oracle database client, Apple QuickTime (for displaying video representations of X rays in the charts), RealPlayer, and other customized applications depending on the department. Of all these applications, only Office 97's design provided for an uneventful wide-scale deployment.

Netscape Navigator in particular caused Khayat headaches. "The browser wasn't equipped to deal with unattended installations," Khayat says. "When we asked Netscape about how to perform the scripted installation, it wasn't interested in supporting the process and suggested that we have the staff install the browser at each workstation."

Using Microsoft Internet Explorer (IE) 4.0 with the Internet Explorer Administration Kit (IEAK) is a logical alternative, but at the time of implementation, neither IE 4.0 nor IEAK were available. And earlier versions of IE didn't support features that Web-based applications need. Also, Netscape Navigator had become the hospital standard, and as a matter of policy, the hospital's CIO and Board of Directors didn't want to become an all-Microsoft shop.

Having the medical staff install its own software wasn't part of Khayat's plan for a low-administration network. Instead, Khayat devised a large-scale installation method for Netscape Navigator and for the other applications with similar problems. He used Sysdiff to record the state of the Registry before and after setup. He exported those Registry keys to a file and edited the installation file to import the file to the local Registry and copy the application files to their appropriate locations. He couldn't follow this procedure with QuickTime, however, and had to create a new installation package. Netscape Navigator's settings are machinecentric, so he edited the browser's settings so that it looked in users' P network directory for the prefs.js file, which contains all the following user-file settings:

[HKEY_LOCAL_MACHINESOFTWARENetscapeNetscape Navigator Usersdefault]"DirRoot"="P:\Default"

Setting Up User Shares
Another problem that the hospital's IT staff encountered was how to automatically create and delete shares for each workstation. In the hospital's environment, shares serve several purposes. Users have a private directory on the file server (mapped to P), which is accessible only to them and in which they store their personal files. A shared directory on the file server (mapped to S) stores files needed by the group to which the user belongs. Also located in that shared directory—called common for all users—is a folder containing the icons that appear on the users' desktop.

The IT staff disabled the Run command in Tier 1 and Tier 2. The only way a user can run any application is if that application's icon appears on the desktop. So shares are crucial not only in terms of user storage but in the presentation of the user interface. Therefore, system policies must incorporate mapping shares rather than the logon script, which loads after the shell. (According to Khayat, adding the shares to the system policy settings also dramatically reduced the amount of time needed to log on, from 15 to 25 seconds to 4 to 5 seconds.)

The IT staff organized shares on each server in a four-tiered hierarchy of four user groups, 10 departments, 200 groups, and 7000 users. Each of the four user groups represents one disk array containing roughly 46GB and allocating approximately 25MB per user. Each department has a common share mapped locally to a user's S drive, and each user has a private directory mapped locally to a P drive. So users within those groups have access to a shared directory and a private directory that the system must map without any user intervention at logon.

Providing the mapping without intervention appeared simple: Use Net Use to map the shares to P and S. In the hospital's environment, however, this solution originally had two problems. Net Use requires a direct mapping to a share name, such as: \servernamesharename. The shared directories apply to the department level, so the system needed to control only 10 S mappings. However, the same technique wasn't practical with the 7000 shares required to map each user's P directory. If Khayat had devised a logon script that used the %username%variable, he still would have had to share each user's home directory individually. Besides, Khayat wanted to make the process of mapping shares as fast as possible to support any applications or shell settings that required those shares. Defining the S and P drives in the system policy meant the share mapping was nearly instantaneous, rather than taking as long as half a minute to execute a logon script.

After experimenting with a couple of tools to map user private home directories to the P drive on each client computer, the IT staff settled on Root Use, a Net Use-like tool available from Microsoft or from the Windows NT Magazine Web site at http://www.winntmag.com/ articles (InstantDoc ID 7163). Unlike Net Use, Root Use doesn't require sharing the full path of the share. For example, if all users' home directories are in folders subordinate to a Homedirs folder, you only have to share Homedirs and use Root Use to connect to the share. This method automatically connects users to their home directories subordinate to Homedirs.

A common problem with using Net Use, however, is also a problem with Root Use. Root Use only maps shares per machine, not per user. Except for Tier 3 users (in private offices), few clinicians use the same workstation. Root Use caused drive mappings to fail after the first logon because a particular machine didn't let the system overwrite the mappings for the new user with different P and S drives. Rebooting, which wasn't practical, was the only way to automatically delete these mappings. Khayat asked Microsoft to create a customized Graphical Identification and Authentication (GINA), which is NT's logon and authentication mechanism, exclusively for Children's Hospital, Boston. The GINA ran both logon scripts (as the basic GINA does) and logout scripts. The staff uses the following customized GINA

[HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NT   CurrentVersionWinlogon]"GinaDLL"="gina_x86.dll""NeedCtrlAltDel"=dword:00000001

to create a simple logout.bat file that contains the following:

SUBST P: /dROOT USE P: /dNET USE P: /d

This logout.bat file reverses the commands and unmaps the drives each time a user logs off. The /d switch disconnects the share. To reference logout.bat, you go to a new logout key located in:

[HKEY_LOCAL_MACHINESOFTWARE MicrosoftWindows NT   CurrentVersion WinlogonLogoff"UserScript"="C:\Logout.bat""SystemScript"="""LogFile"="C:\Log.txt""Timeout"="5"

(Those who have been using Windows 2000—Win2K—will recognize the logout script capability as part of the new OS. Children's Hospital, Boston, plans to evaluate Win2K, but doesn't plan to convert immediately.)

Locking down computers on a large scale isn't a quick or easy task. It took 5 months to develop the policies and installation scripts that support the final product, and the IT staff at Children's Hospital, Boston, is still in the process of implementing this solution on all 5000 computers. However, the end result is a securely locked-down computer that can't be misconfigured, can be quickly and easily replaced with a computer of identical capabilities, and isn't dependent on a terminal server. With a lot of preparation, you really can install locked-down client workstations of varying configurations on your network and minimize network administration thereafter.

SNAPSHOT
Clinicians at Children's Hospital, Boston, needed quick and easy access to online patient records. The problem's resolution exposed a larger need for new computers to replace the 5000 green-screen video display units that gave the clinicians access to computing power. Complications quickly arose. For the most part, computers were in public areas, not private offices, and the hospital staff needed access to whichever computer was handy at the time. The new computers also had to be easy to set up—installing a customized computing environment on 5000 computers isn't a task completed in one afternoon. To keep support costs down, the IT staff needed to customize computer interfaces depending on the individuals using the computers, and the computers' physical location.

Network Operating System (NOS) Technical Analyst Alex Khayat developed a comprehensive scripting solution using installation scripts and system policies. He studied the Registry's structure to find important entries required for customizing the OS and applications. Using this information, Khayat developed an installation script that installed, in a matter of minutes, a customized version of Windows NT Workstation and a suite of applications. To control access to these applications and to provide appropriate network resources to the user, Khayat used a logon script and complex system policy that defined the interface according to the user's group membership and the computer's physical location.

Corrections to this Article: