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:
- Tier 1:TaskStations/Kiosk Mode, which doesn't use the NT shell, has no taskbar or desktop icons, and displays only two applications that the user can't reconfigure or shut down
- Tier 2:Fully locked-down computers that display a fixed set of applications
- Tier 3:Fully open computers that display all installed applications and support the shared and private network drives of Tier 2 computers plus two additional network drives
The unattended installation script and system policies resulted in a three-step process:
- To build a new PC, staff members take it to a staging area and install the proper OS and application settings.
- Staff members move the new PC to its final location.
- The application set that's visible on the new PC depends on the PC's location and the users that will log on.
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_MACHINE\SOFTWARE\Microsoft\Windows NT\ CurrentVersion\Winlogon]
"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 \icons\desk or icons\start 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\ SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell = 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.
Previous
Register
