Integrating Windows NT into a UNIX Environment

A crash course in NT basics for the UNIX administrator

As a Swiss-based IS consulting firm, the Comit Gruppe offers services such as technical consulting and bespoke software development for the banking and financial industry. Like many companies that implemented computer networks in the 1980s, the Comit Gruppe's network evolved over the years into a disparate array of machines. These machines included various UNIX servers and workstations, VAX servers running OpenVMS, and PCs running DOS and Windows 3.1. The multitude of operating systems and various hardware platforms caused several problems for the IS department, including overlapping administrative and support tasks for different environments, needing to hire specialists for each client/server platform, and having to bolt on software so PCs could access data on the servers. The clients also suffered various problems because of conflicts among different protocol stacks and lack of available memory resulting from terminate-and-stay-resident (TSR) programs loaded in conventional memory.

The company eventually decided to migrate many of the workstation and server platforms to a common and more manageable environment. The company introduced several Windows NT 3.51 servers into the organization and deployed NT Workstation 3.51 on the clients. I was responsible for adding NT into this environment with minimum disruption to services. This article is for UNIX systems administrators who face the many issues associated with introducing NT into a corporate UNIX environment.

Pre-NT Networking Environment
With five offices in Switzerland (two in Basel, two in Zurich, and one in Bern) and one in Dublin, Ireland, the Comit Gruppe keeps in touch through a WAN using leased lines and dial-up connections. Each office in the company uses a LAN with 10MB Ethernet and TCP/IP. In the pre-NT network, several database servers throughout the organization ran Oracle on either SCO UNIX or an OpenVMS platform. Several UNIX servers ran Lotus Notes to provide corporate email, and other UNIX servers handled the network file and print sharing requirements.

The clients on the pre-NT network consisted of UNIX workstations and PCs running DOS and Windows 3.1. The PC clients accessed data and printers from the UNIX servers using an NFS client for Windows.

Moving to NT
The Comit Gruppe decided to migrate as much of its network as possible to NT for several reasons, including the need for an environment that supports the new 32-bit desktop Windows applications and a requirement for a robust and reliable platform that was easy to control and manage. Although the existing UNIX servers provided several services (such as file and print sharing and Lotus Notes database services) to the PC clients, the Comit Gruppe needed to satisfy the growing demands of its client population. Moving these services to an alternative platform would free up valuable resources on the UNIX servers and let the company fully deploy these machines as database servers.

In addition to supporting the growing needs of the desktop users, the company supports several mobile notebook PC users. These machines require multiple configurations to ensure that they have the correct TCP/IP address when they access the LAN from the different offices. Supporting these machines led to additional overhead for the company's IS staff. The company knew that upgrading and replacing the existing UNIX server hardware would be costly. Fortunately, NT offered an environment that suited both the desktop and mobile client requirements and gave the Comit Gruppe a relatively inexpensive Intel-based server environment, compared to the existing UNIX platform. (For a list of advantages associated with migrating to NT, see the sidebar, "Benefits of Migrating to Windows NT.")

Integration Issues
To integrate NT into the existing UNIX networking environment and ensure a smooth-running project, the Comit Gruppe had to address several issues. The company decided to migrate the clients to NT in waves, so they had to maintain access to existing data on the UNIX servers. The company had to ensure that remote users could access the network for email and file and print sharing services. The Comit Gruppe also had to maintain access to the Lotus Notes databases, which would remain on the UNIX servers. Finally, the company needed to ensure that the migration caused minimum disruption to the clients. With these issues in mind, the next step was deciding how to deploy NT by considering which domain model to use, where to locate the NT servers, whether to deploy TCP/IP with NT, and how best to install NT on the workstations. (For a list of the migration issues that the Comit Gruppe faced, see the sidebar, "Migration Issues," page 192.)

When a Domain Is Not a Domain
When preparing to deploy NT, the Comit Gruppe had to sort through the differences in terminology for the UNIX and NT platforms. For example, UNIX administrators think of a domain in terms of Network Information Service (NIS) domains, Domain Name Service (DNS) domains, and email domains. An NT domain is a secure logical grouping of servers, workstations, and users. Domains form the basis for NT's networking security.

Grouping NT servers, workstations, and users into an NT domain prevents computers or users who are not members of that domain from accessing resources within the domain. More than one domain can exist on the same physical network as other domains and remain secure from users not defined within that domain, except by means of specific sharing mechanisms known as trusted domains.

By logging on once, without having to log on to each server that's part of the domain, users on an NT domain can access resources on servers within the domain. With this single logon, clients don't need to remember different user IDs and passwords for each server they access. One logon also reduces the administrative overhead associated with maintaining user IDs.

NT Server comes with several tools, such as the User Manager and Server Manager for Domains, which let the administrator centrally manage all user accounts and servers within the domain.

NT Domains
Understanding NT's domains will be old hat for NT network administrators, but UNIX network administrators will want to review the basics before adding an NT domain into a UNIX environment. Each NT domain must have a Primary Domain Controller (PDC). The PDC is an NT server that validates users logging on to the NT domain and contains the master copy of the Security Accounts Manager (SAM) security database for the domain. The SAM database contains information about users who are members of the domain, details about the servers and workstations in the domain, and information about the security accounts policy for the domain.

For fault tolerance and performance reasons, most NT domains have another server acting as a Backup Domain Controller (BDC), which maintains a copy of the SAM database. The BDC provides fault tolerance in case the PDC fails or goes offline. The BDC can also share the workload with the PDC and authenticate users logging on to the domain. More than one BDC can exist within the domain to provide additional redundancy and performance enhancement.

NT domains can also contain other domain servers that don't take part in authenticating users logging on to the domain. These servers are typically not suited to the additional overhead of maintaining a copy of the SAM database and authenticating user logons. As a result, these servers are better suited as database servers, application servers, and intranet servers.

NT Domain Models
Each domain's SAM database can be up to 40KB in size, which allows for up to 40,000 user accounts. However, many companies require more than one domain within the organization because of security, political, and size considerations. With NT Server, you can set up multiple domains and establish trust relationships between pairs of domains, so that one domain trusts another domain. This feature lets members of the trusted domain access resources on the trusting domain. Selecting the correct domain structure (i.e., domain model) to use within your organization is key to the successful implementation of NT networking and security. (For more information about domains and trust relationships, see "Related Articles in Windows NT Magazine," page 190.)

You can categorize most types of domains into one of four major domain models:

The Comit Gruppe Model
Because of its multiple office locations, the Comit Gruppe considered setting up a separate domain for each office and establishing trust relationships among the various domains. However, because the company has fewer than 200 users throughout the whole organization and uses mostly high-speed leased lines between four out of five of its offices, it decided to use a single domain model, as you see in Figure 1. Deploying one domain reduces the administrative overhead. Because the company doesn't have to maintain trust relationships, it can train fewer staff to administer NT, and it can manage the entire domain from one location.

Implementing TCP/IP with NT
Whereas TCP/IP is by far the most common protocol for UNIX, NT comes with several protocols, including TCP/IP. The 32-bit NT TCP/IP protocol stack is self-tuning and lets you integrate NT with existing TCP/IP networks. The Comit Gruppe already had a TCP/IP network with a subnet scheme, so the company deployed NT into this scheme.

If you're considering deploying TCP/IP into your organization, you need to consider your routing requirements, how you plan to segment your network, network security, and network traffic patterns. You can configure NT's TCP/IP settings from the TCP/IP Configuration dialog box in the Network applet in the Control Panel, as you see in Screen 1. Using this applet, you can specify such items as the IP address and the default gateway for the PC. If you click the DNS button in the TCP/IP Configuration screen, you can enter the details of the DNS servers that the PC will use to resolve the host names to their corresponding IP address. Screen 2, page 190, shows the DNS Configuration screen.

NT Server also comes with two services, Dynamic Host Configuration Protocol (DHCP) and the Windows Internet Naming Service (WINS), to reduce the overhead of managing TCP/IP under NT. With DHCP, you can define the range of TCP/IP addresses that you want to use in a particular subnet and dynamically allocate TCP/IP addresses to workstations as they attach to the network.

DHCP lets you allocate TCP/IP addresses from a central server and eliminate duplicate IP addresses on the subnet. If you have several workstations and are running out of IP addresses, you can use DHCP to specify the amount of time a workstation can lease an IP address. If the workstation does not renew its lease, NT removes the workstation from the network and automatically allocates the IP address used by this workstation to another workstation. You can also use DHCP to define other TCP/IP parameters such as the IP addresses of DNS servers on the network and default gateway options. (For more information about DHCP, see "Related Articles in Windows NT Magazine.")

A major issue with installing NT into a routed network is that NT uses NetBIOS to communicate and transfer network requests to the underlying protocol, in this case TCP/IP. NT uses NetBIOS commands over the underlying protocol to communicate between hosts on the network. With NetBIOS, any operating system using Windows-based networking, such as NT, Windows 95, and Windows for Workgroups, registers its host names uniquely on the network and uses network broadcasts to resolve and locate the destination PC.

Although NetBIOS is suited for small LANs where no routing is required, it's not suitable for resolving host names or for transporting other network requests in a routed environment. Because NT transmits all network commands using NetBIOS, by default you can't install an NT-based network into a routed environment. To overcome this problem, Microsoft developed the WINS service. A WINS server behaves similarly to a DNS server for resolving TCP/IP host names. A WINS server stores all the NT host names and their corresponding TCP/IP addresses in a database. You configure the TCP/IP stack for a Windows networking client PC to point to the relevant WINS server to resolve NetBIOS names on the network.

You can configure the WINS server to pass on any host names that it can't resolve to a DNS server. WINS also works with DHCP. When DHCP allocates a new TCP/IP address to a workstation, DHCP notifies the WINS server of the change in the host's TCP/IP address. If that workstation is a new host on the network, the DHCP server sends details of the new host name and the new TCP/IP address to the WINS server. You can even set up WINS and DHCP to run from the same physical server.

The disadvantage of NetBIOS name resolution is that DNS doesn't understand NetBIOS and can't resolve NetBIOS-based hosts. This limitation means that in a mixed UNIX and NT environment, you can't use DNS to resolve any Windows networking-based hosts using DNS. One solution is to manually add all the NetBIOS names and associated TCP/IP addresses to the DNS server. However, this task can become quite laborious with DHCP because every time the DHCP server allocates or changes the TCP/IP address for a client, you have to manually make the corresponding change to the DNS server. With NT Server 3.51, you have to use a third-party DNS server that is compatible with the WINS service. With NT Server 4.0, Microsoft included a DNS server that works with WINS. In a WAN environment, you can partner WINS servers and pass unresolved requests from one partner server to the next to determine whether the requested host name is in another segment of the WAN. (For more information about DNS and WINS, see "Related Articles in Windows NT Magazine.")

Deploying NT Server
After deciding on a single domain model, the Comit Gruppe had to decide how many servers it needed, which servers would be domain controllers, and which servers would run the DHCP and WINS services. Each of the five offices had its own network segment and TCP/IP subnet, and each connected to the other offices via a routed network. Because of this configuration, we decided to create a local NT server for each office. We configured each server as a domain controller and located the PDC in an office in Basel and located BDCs in each of the remaining offices. We decided to create a domain controller in each office to minimize the amount of network traffic that needed to pass over the WAN for clients logging on to the LAN. Each domain controller would satisfy the logon requests for the clients in that particular office. We also decided to configure each domain controller to run the DHCP and WINS services to manage all NT TCP/IP traffic and requests locally.

We began by installing the PDC. Because we were preparing for a clean install of NT, we entered each username and its account information from scratch into the SAM database on the PDC. After we created all the user accounts and set the accounts policies for the network, we set up each BDC at the same physical location as the PDC. This approach let us quickly copy the SAM database from the PDC onto the BDCs. Once we set up each BDC, we transported it to its appropriate office. The only exception to this approach was the installation of the BDC for the Dublin, Ireland, office, which we installed over a remote link.

After we installed the NT servers, we had to decide how to best access the data on the UNIX servers. UNIX shares disks over the network using NFS, but NT Server doesn't support sharing files using NFS. Several NFS solutions are available for NT Server. However, because we were deploying NT into the organization to reduce our dependence on UNIX, we decided not to use NFS. Instead, we used Andrew Tridgell's Samba (http://samba.anu.edu.au/samba), public domain software that lets a UNIX server behave similarly to a Windows-based network server. Samba let us share resources from the UNIX servers to the NT servers and clients. With Samba, our NT users could still access data on the UNIX servers without having to upgrade their NFS software to a 32-bit version for NT. Samba also let us copy data to and from the UNIX servers and the NT servers quickly and easily. (For more information about Samba, see "Related Articles in Windows NT Magazine.") After we installed each domain controller, we were ready to deploy NT onto the client workstations.

Deploying NT onto Client PCs
When deploying NT, we had to determine which PCs were capable of running NT and which ones we needed to replace or upgrade. Microsoft's recommendation for minimum NT Workstation system requirements is a 486 CPU with 16MB of RAM. (Microsoft publishes a Hardware Compatibility List—HCL—of the hardware that Microsoft has tested and supports on NT. Microsoft updates the HCL regularly and makes it available at http://www.microsoft.com.) We set our minimum requirement for a client workstation as a 90MHz Pentium CPU with 32MB of RAM and at least 150MB of available hard disk space. Because installing NT onto hardware that is not on the HCL can lead to unexpected results, Microsoft strongly advises that you install NT using only hardware on the HCL.

After we determined the hardware requirements for the NT installation, we had to ensure that applications being used in the organization would run on NT. Most Windows 3.1 and DOS 16-bit applications run well under NT. However, applications requiring special drivers or direct access to the hardware may not work under NT. To determine what applications were in use in the organization, we emailed a questionnaire to all users. We examined the results of the questionnaire, identified any software that would not run under NT, and either replaced or upgraded these packages with an NT version.

All the clients that we wanted to upgrade to NT were running DOS and Windows 3.1. Installing NT into the same directory as Windows 3.1 (e.g., C:Windows) lets NT preserve desktop settings such as program groups and desktop wallpaper and to migrate any application systems from the win.ini and system.ini files.

To install NT on each PC, we had to decide whether to install NT Workstation from the NT Workstation CD-ROM or from a network share. If a PC had a local CD-ROM drive, the quickest and easiest way to install NT was using the CD-ROM. We also invested in several Micro Solutions Backpack CD-ROM drives (http://www.micro-solutions.com), which you can attach to the parallel port of a PC.

Where we had to install NT Workstation from a network share, we copied the NT Workstation CD-ROM onto an NFS-mounted drive on some of the UNIX servers. To install NT onto the PC, we created a DOS bootable disk and installed the DOS version of the NFS client onto the diskette. Booting the PC with this diskette let us attach the PC to the relevant NFS share on the UNIX server and run the NT setup program from the server. Using the network install let us install NT onto multiple PCs at the same time.

Next Steps
To take full advantage of the NT environment, the Comit Gruppe has planned several steps over the next few months.

NT has provided the Comit Gruppe with a stable, reliable, and future-proof platform that will let the company continue to provide the high standards and quality of service to its clients. NT gives us a very manageable platform that reduces the cost of ownership of our WAN.