Integrating Windows 95/NT into an existing UNIX Enterprise Network

Cameron D. Luerkens, Mark J. Bartelme, Kevin K. Sizer, James 'Bud' Lande

- Rockwell Avionics and Communications, Collins

Abstract

A task of large Information Technologies (IT) organizations is how to connect thousands of PCs to an Enterprise network. Many of these networks have used UNIX servers to host and deliver applications to PCs running Windows 3.1 . With Windows 95/NT's dominance of the desktop, it is becoming essential to integrate the Windows environment with the existing UNIX infrastructure so existing resources can be used for their full lifecycle.

Introduction

Historical Perspective

Since 1992, Rockwell CACD has had an Enterprise Network based upon UNIX servers, 3,500+ PC's running Sun's PC-NFS 5.x under DOS 5/6 with Windows 3.x along with 500 UNIX workstations, primarily HP and SUN. Using DOS based PC-NFS 5.0, the PCs authenticated to the UNIX servers to allow connectivity to the network. The UNIX servers also hosted and served PC applications (Microsoft's Word, Excel, Powerpoint, and others) as needed.

Key PC components of the past Enterprise network included using UNIX as authentication Servers and mounting standard UNIX drives, with PC-NFS, during logon as follows:

Drive Letter Function

K: Mail Database Drive

L: Calendar Database Drive

Q: Global Scratch Drive with R/W access for all users

S: Drive hosting PC Software Executables (i.e. Excel, Netscape, …)

U: Utility files (i.e. Batch Files to start applications)

V: Home Drive hosting logon configuration files and User documents needing to be backed-up to the network

W: PC-NFS

Using this Enterprise setup, a user can log onto a UNIX box or log onto a PC authenticating to the UNIX servers in both cases. In the case of the PC, the Drive v: above, would be the users UNIX home directory. Other drives noted above are also UNIX file systems that are exported to the PCs for sharing using NFS. File systems can be shared transparently between UNIX and PCs using this setup.

To transition to 32-bit Windows, the same functionality and homogeneous aspects of the Enterprise network were desired.

Boundary Conditions for 32-bit Windows in CACD's Enterprise Network

There are four main features required for CACD's Enterprise Network that need to remain intact :

1. Central Authentication
2. Common File Sharing for all clients
3. Shared Printing
4. Common Naming Services.

Additional features that were desired included a virtual logon that would allow Users to access to the same applications and user data directories when logging in from any desktop on the network. Also, existing UNIX servers must continue to be used as PC Applications servers at this time.

Approaches and Test Results

Two approaches were considered. The first approach was using NFS-Client software on each Windows32 client. The second scenario was running SMB on the UNIX servers. Eight 32-bit NFS stacks for Windows 95/NT:

Vendor Product _

1. Netmanage Chameleon
2. Frontier SuperTCP
3. Hummingbird Maestro
4. SUN PC-NFS PRO
5. SUN Cyclone
6. Intergraph DiskAccess
7. FTP OnNet
8. Reflections WRQ

and two SMB solutions:

Vendor Product _

1. GNU SAMBA
2. SYNTAX Total Net Advanced Server (TAS)

were evaluated using the following (summarized) criteria based upon a 0-10 ranking:

Product Requirements

1. Installation Requirements
2. Naming Service Support
3. File Mounting capabilities
4. File Service Performance
5. Print Services
6. DHCP Capabilities
7. Costs
8. Availability

Features Availability/Performance__

1. PC-NFS 5.0 Mounting Features
2. Both Windows 95 & NT Support
3. Central Administration
4. Bundled Applications
5. Security
6. Application Compatability
7. Support Availability

The first requirement of the tests required the solutions to score above a zero in all categories of the Product Requirement tests. Five of the above ten products were eliminated from contention because they scored a zero in one of the categories. The remaining solutions were then tested for Features Availability/Performance. Hummingbird's Maestro tallied the highest score, in a close contest, based upon the weighted test results.

Decision

With Hummingbird's Maestro recording the highest score for Network functionality and with difficulties associated with the transition to 32-bit Windows while changing the server infrastructure to accommodate SMB, it was decided that the NFS client approach imposed the least risk and would be less disruptive to the network operation. The decision was finalized to use Hummingbird's NFS-Maestro running on the Windows 95/NT desktops. This product meets the needs of an Enterprise Network by providing authentication via a centralized account management authority, network-based file sharing and printing capabilities, and support for multiple naming services (NIS, DNS, DHCP).

Logon Process

Authentication Process

The logon process enforces a policy of NT Domain authentication. Once authenticated to an NT Domain Controller, authentication is performed transparently with Maestro NFS to provide for standard UNIX drive mounts (indicated above). The user desktop is maintained in the home directory so that the user is presented with their customized Desktop regardless of which PC in the environment they logon. Other drives and printers may be mounted according to the user's specific user or group profile (defined on the network in a centralized, mirrored fashion), or in a user maintained profile in the root of their UNIX home directory. Passwords for the NT and NIS domain must be kept in-synch in order to maintain transparent authentication. Maestro-NFS provides a means for the user to change both within the same change request.

Registry Settings & Policies

The entire logon process is driven by a single registry key which runs a PERL script on the local 95/NT machine to log the user in completely. Authentication is enforced via an NT Domain Controller with another registry entry, so the user can not logon to a machine unless authenticated. Server load-balancing is performed using NIS table entries to map subnets to appropriate servers. During the logon script, modifications are made to the registry for UNC mappings to the location of the PERL binaries and library files. Also based on the NIS table entries are the appropriate server locations for the standard drive mounts.

Printer & Drive Mounts

Once the PERL script starts up, it NFS mounts the "standard" network drives as well as parses profiles which are maintained centrally and distributed to Application servers for load balancing. These profiles use a meta-language with features to accomplish the following tasks:

1. NFS mount drives
2. Map network printers
3. Set env. variables for the global logon session

Profiles are created and maintained by network administrators. The organizational and project related mount points are all maintained within NIS tables so that references within the scripts do not require modification if a server is replaced or when a directory tree is moved.

After the network profiles are processed, the user-maintained profile (username.RWP file in the user home directory) is processed. This is a profile using the same meta-language as the network profiles and allows each individual user to customize their environment and drive/printer mappings beyond what the administrators have set up for them. Contents of a username.RWP file is listed below:

#Filename: JohnDoe.RWP on Home Drive (v:)

#Append path below to original path

set PATH=%path%;c:\windows\bin

#Set an Environment Variable

setenv temp=c:\windows\temp

#Mount an NFS Drive, where auto.vol is an NIS MAP

drive r: \\$auto.vol\Win32drivers

#Mount a Printer to an LPT port: where prtsvr is the Server name

#and pq1061801 is a Mail Station Address

printer lpt1: \\prtsvr\pq1061801

Universal logon and setup

The entire Windows 95/NT loadset is based upon PERL, a programming language mainly used for manipulating text, files and processes. Once the base operating system is in place and basic TCP/IP network functionality is available, all other locally-installed software (NFS Maestro, virus scanners, license metering software, etc.) is automatically installed via a PERL script. Once all the software has been installed and configured , the user is able to logon to the network. The entire logon process, from the moment of authenticating to the NT Domain Controller, is controlled by a master PERL script. PERL has been a very integral part of the 95/NT integration primarily because of it's ease of use, extensibility, and support of the Win32 Registry. Additionally, because of the way drives are mounted and home directories are used, a user's desktop can be stored and Start menu settings implemented so users can logon to any PC on the network as if it was their own personal desktop machine.

Software Distribution

Common Supported Application Suite

Each time a user logs in, a set of .LNK (shortcut) files are updated to local C: drives in their startup menu. These are copied via an rdist-style mechanism, only updating files on the local hard drive which have been updated on the network and which have appropriate UNIX permission set for each user. This strategy offers everyone a single "Rockwell Programs" sub-menu from the Start menu which contains shortcuts to all supported software packages. The shortcuts in the Rockwell Programs target PERL scripts on the server which are used to determine application setup requirements, depending on the user and machine. By using shortcuts to the PERL Scripts, users are able to customize the Windows environment to the applications startups without destroying the central control of the application startup scripts. Users can drag an application icon to the desktop, for instance, while the script that controls how the application starts up still remains on the server where modifications can be made globally, if needed.

Another important aspect of Rockwell Programs Start Menu concept involves application environment settings. By using PERL script wrappers to launch applications, the environment for the application can be modified independently from the global environment. The path as well as application specific registry entries can be modified as needed. This has proven especially significant as the diversity in client-server middleware has proliferated.

By installing all of the applications on the server, the administrative requirements on configuring and reconfiguring the client OS has been reduced tremendously. The performance aspect of server-based applications has been addressed by using Sun's CacheFS product. This provides for a persistent hard-disk cache of the server file system on each local client. Each client was configured to hold 30 megabytes of the most recently accessed files. The product works transparently to the user and provides local access times for the most recently used server based applications.

UNIX "depot" distribution model

All supported software packages are, in turn, installed by administrators on a master partition on a UNIX server. This master partition is pushed (via rdist) to several others servers for load-balancing. NIS Automount maps are used to control the load-balancing so that each user mounts a different S: drive, depending on the subnet address. The S: drive, through the use of the rdist mechanism, is a mirror image of the master.

In addition to the master server, a second server in a Test Bed environment has another copy of the S: drive software which is used for development and testing. The S: drive can be re-mounted to the development server to test and develop new loadsets without affecting production users. When a loadset has been created or modified, verified and tested, that particular portion of the tree (usually a single application's loadset) can be rdist-ed out to the master production server, and subsequently all of the regular production servers. This method provides a controlled software loadset test area which can easily be distributed to the entire network in a matter of minutes. This also makes fixing any "bugs" which appear in a loadset extremely easy. If a .DLL file is left out by mistake, the problem can be fixed for 4,000 users in approximately 5 minutes!

Laptop & Mobile User Integration

Docking to the Network

CACD standardized on Windows 95 for all laptops since it provides for better power-management and plug-n-play capabilities not yet available with NT (currently, Windows 95 distinguishes between "docked" and "undocked" configurations based upon whether or not there is a network card installed). When a user is here in the office, authentication is forced to an NT Domain Controller, just as if the Laptop was a desktop PC. In fact, as far as our logon procedures are concerned, they are just a desktop user when they're here on the network. The only distinguishing feature is a couple of additional registry entries which can be used to distinguish between laptops and desktops.

Remote Access

Currently remote access for laptops is handled differently depending on the needs of the individual users. To use a laptop in the field, the user simply ejects their PCMCIA network adapter and boots Win95. At the logon screen, pressing ESC will bring up the default "undocked" desktop. Users then use whichever remote access tools that have been locally installed (PCAnywhere, cc:Mobile, Lotus Notes, or SLIP/PPP) to access the network over standard dialup connections.

Future Direction for Rockwell Collins

Since this spring, Rockwell CACD has merged with its sister company, Rockwell CCA, to produce Rockwell Collins. This merger has doubled the number of PCs in the Company. Rockwell CCA had already began to merge multiple networks to a single Windows NT domain using TCP/IP protocol and SMB connectivity. Windows NT Servers are used for authenticating to the network and obtaining printing and file mounting services. To date, even though merged, two Network loadsets prevail, and a special bridge server is used to deliver software that is needed to be shared by both loadsets.

With the new merger, a new IT organization has been created within Rockwell Collins. A Common Desktop team has been created with the charter of combining the "Best of both Loadsets" to create a Common Desktop for Rockwell Collins. The near future issues for combining the two loadsets and to obtain PC connectivity are as follows:

1. How to merge NIS and NT domains transparently
   • Transparent password synchronization of the two domains
   • Mounting File Systems for NT and NIS Shares
2. Define an Enterprise printing strategy
3. Define boundaries for which applications should be loaded locally to optimize speed and reduce down time non-productivity versus which applications are best administered from the network for central administration
4. Select a push or pull strategy for delivering applications to the users from the network
5. Decide upon a disk cache strategy for caching network drive information

Acknolwledgements

A successfull rollout of Windows 95/NT to 3500+ clients cannot happen without a Core team providing technical and administrative expertise throughout the projects. Core team members who worked tirelessly to see the project through include Rick Bowersox, Mike Benge, Teri Nunez, Rafe Trent, Mark Bartelme, Kevin Sizer, James Lande, Dennis Juve and Cam Luerkens. A special acknowledgement goes to Richard Holland for introducing the idea that Perl was the scripting 'Tool of Choice' for this implementation.

Netscape is a trademark of Netscape Communications. UNIX is a registered trademark of X/OPEN. Windows is a trademark of Microsoft Corporation.

Author Information

Mark Bartelme is a Network Engineer at Rockwell Collins, Inc. . Mark , along with Kevin Sizer, was a primary designer of integrating Windows 95/NT to the UNIX/NT Domains using Perl as the tool of choice to implement the integration. He currently is leading a Common Desktop Planning team to combine the CCA and CACD loadsets into a single Collins loadset that will merge the "Best of Both' loadsets as well as add today's leading-edge technologies into the plan.

Cam Luerkens is a Senior Engineer at Rockwell Collins, Inc. . He was the Project Engineer for the design, development, and rollout of the 3500+ Windows 95/NT clients presented in the article above. . He currently is the Team Leader for the PC Client Desktop Integration team. Cam is also a member of the Common Desktop team led by Mark Bartelme.

Kevin Sizer is a Network Engineer at Rockwell Collins, Inc. . He currently is the Team Leader of the NT Server team. Kevin, along with Mark Barteleme, was a primary designer of integrating Windows 95/NT to the UNIX/NT Domains using Perl as the tool of choice to implement the integration. Kevin is also a member of the Common Desktop team led by Mark Bartelme.

James 'Bud' Lande is a UNIX Administrator at Rockwell Collins, Inc. and currently is a member of the UNIX administration team. Bud provided lead UNIX administration support to the Windows 95/NT Core team and led the implementation of DHCP and the integration of Hummingbird's Maestro (NFS Client for Windows 95/NT) to the UNIX servers. Bud is also a member of the Common Desktop team led by Mark Bartelme.

References

Hunt, Craig, TCP/IP Network Administration,

O'Reilly and Associates, 1991

Wall, Larry, and Schwartz, Randall L., Programming Perl,

O'Reilly and Associates, Inc. , Sebastopol, CA 1991

Stern, Hal, Managing NFS and NIS,

O'Reilly and Associates, 1992

Stevens, W. Richard, UNIX Networking Programming,

Prentice Hall, 1990