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_MACHINE\SOFTWARE\Netscape\Netscape Navigator\ Users\default]
"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: \\servername\sharename. 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_MACHINE\SOFTWARE\Microsoft\Windows NT CurrentVersion\Winlogon]
"GinaDLL"="gina_x86.dll"
"NeedCtrlAltDel"=dword:00000001
to create a simple logout.bat file that contains the following:
SUBST P: /d
ROOT USE P: /d
NET 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_MACHINE\SOFTWARE\ Microsoft\Windows NT CurrentVersion\ Winlogon\Logoff
"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:
- The case study "A Scripted Solution for Complex Networking Problems" failed to include the following three people in the list of the original staff members who contributed to the Children's Hospital, Boston, IT project: Jamie Desousa, Michale Cormier, adn William Arrington. The correct photo caption for the photo that appears on the opening pages of the article is "Left to right: Jamie Desousa, Alex Khayat, Michale Cormier, Benjamin Marshall, and Douglas Caldwell." We apologize for any inconvenience these errors might have caused.