When I set out to install Windows NT Server 4 at home, I already had a lot of the tools in place. I had two Windows 95 machines (each with a 10/100 Network Interface Card) networked via a crossover Cat5 cable. While I initially networked these machines for gaming, I ultimately wanted to use them as the foundation for my networking test bed. I already had a 4 port fast Ethernet hub and a standalone laptop computer. By purchasing some additional cable and a PCMCIA network card for my laptop, I planned to build a LAN around a server and two workstations. Since this class is the first in a series of networking classes, I thought it was only fitting to build the network for my first class project and have it available for subsequent lessons and experimentation. I can only learn so much in books. Having a working LAN only a few feet away gives me an excellent opportunity to apply what I’ve learned and see some of these mechanisms in action.
Before I could think about the networking details, I had to find out whether NT Server would run on my computer and then decide where to put it. If any of my existing hardware was incompatible, I’d have to consider swapping parts or using a different machine entirely. I probably wouldn’t have taken this as seriously if it weren’t for a friend’s warning. He had tried to install NT Server at work—his problems started during the hardware setup phase of the installation. NT didn’t recognize the IDE controller and he was forced to swap it out for a SCSI drive. (One of my books says that server has broader support for SCSI cards than IDE, interesting when you consider the prevalence and comparable performance of IDE controllers nowadays). This prompted me to check my system against Microsoft’s Hardware Compatibility List. (The list is available on Microsoft’s web site: it’s updated on a regular basis and searchable by manufacturer as well type). The most important components were listed as compatible: my IDE controller, graphics accelerator, and modem were listed. My hard drive wasn’t, but there were plenty by the same manufacturer. And since the controller was given the thumbs up, I figured I was half way there. I didn’t find my NIC in the list either, but drivers were available from the manufacturers web site. I visited the web sites of various hardware manufacturers and downloaded any necessary drivers or updates before starting the installation.
Since I wanted continued access to Windows 98, I decided to setup NT Server to dual boot between the two operating systems. I didn’t realize I could do this at first, but one of my books had tips for setting this up. You can even install NT and Windows on the same partition (but you must install them on a FAT partition). Since Windows doesn’t support NTFS, I wanted to keep them on separate partitions so that I could experiment with the features inherent in NT’s native file system. You can assign permissions to directories and files that reside in NTFS partitions. (File system permissions are not the same as shares. Share level permissions only apply to network connections, whereas the former can also limit access to local users. Administrators can also use file system permissions to restrict access to files within a shared resource, thus enabling finer security control over network resources. NTFS supports larger file and partition sizes than FAT. It also logs all changes to the file system and can use this information to correct discrepancies arising from system failures or power losses. To take advantage of these features (and others), I partitioned my first drive into two separate partitions: I formatted the primary partition for FAT and installed Windows 98 there. During the hardware phase of installation, I formatted the extended partition for NTFS and specified this partition for the NT’s system files.
Once the hardware phase is complete, you must decide which security model you’d like to use. The Workgroup Security Model is analogous to a peer-to-peer network (and more fitting for small-scale networks of 10 computers or less, where security isn’t a big concern). Users manage the resources on their own workstation and make them available to other users on the network as they see fit. Anyone with the password can use the resource. If I planned on utilizing this kind of network, I must set up NT as a stand-alone server. In the Domain Security Model, user accounts are managed on a central computer (called the Primary Domain Controller). When a user logs into this machine, the PDC permits or denies access to all shared resources on the network (servers, workstations, printers, and so on). Administration is centralized. Access to all resources is controlled and maintained on a single machine; users don’t have to maintain their own set of passwords or log into each resource separately. I went with the more secure, centralized model and opted to configure the server as the Primary Domain Controller. I specified a server name, as well as the Administrator password.
The next phase involved network and protocol configuration. I had an option between local and remote access (Wired to the network and Remote access to the network). I went with the former since this fit my scenario, identified my network adapter card (NT detected it automatically), and specified NetBEUI as the only network protocol. According to the author of the MCSE: NT Server 4 Study Guide, NetBEUI is very fast and easy to implement. It cannot be routed between networks and there’s very little cross-platform support. It’s more fitting for smaller, self-contained networks consisting mainly of Microsoft operating systems that do not need to communicate with remote networks. Because I didn’t want to get bogged down in more advanced protocols such as TCP/IP, I went with the author’s discretion and stuck with this protocol for now. Configuring it involved nothing more than installing it. I named the domain, configured the graphics accelerator, and completed the installation. I rebooted, entered the Administrator password, and within minute I was logged on.
The system was running smoothly, but I still needed to make some changes to the hardware setup. With the help of the manual, installing the drivers for my sound card was fairly simple. However, getting NT to recognize my Zip drive was not so easy. NT treats the parallel-port zip drive like a SCSI controller. Using the SCSI Adapters utility, I added a new controller and installed the appropriate driver. I rebooted the computer, and was introduced the Event Viewer for the first time. A message appeared on screen: “At least one service or driver failed during system startup. Use Event Viewer to examine the event log for details.” The Event Viewer logs all error messages, so that if you’re not at the computer when the problem occurs, you can still review the log for details. The utility records system events (recorded by the Windows NT kernel and drivers), security events (as set by audit and user policies), and application events (errors and events recorded by applications designed to use the event log). There are three types of warnings: blue icons mark informative messages (they do not indicate problems), yellow icons indicate non-critical resources that aren’t functioning correctly, and red icons indicate a critical problem in the computer’s configuration that could deny access to a service. Unfortunately, the zip driver showed up in the Event Viewer as a critical error: “The following boot-start or system-start driver(s) failed to load: ppa3nt”. After numerous trips through Iomega and Microsoft’s web site, I still couldn’t get the system to identify the drive. I used the Windows NT Diagnostics to try and identify a resource conflict. Like other diagnostics tools, it provides a hardware blueprint of the system: motherboard and microprocessor type, bios date and manufacturer, installed volumes (or drives), memory information (i.e. physical memory and page file), the state and dependencies of all loaded services and drivers, and most importantly resources (IRQ, I/O port, DMA, and Memory). While there didn’t appear to be any problems, I didn’t know enough about hardware configuration, services or devices under Windows NT to figure out what was wrong. In the interest of time (assuming I’d eventually figure it out), I plugged the drive into a Windows machine and shared it from there.
Once hardware configuration was complete, it was time to create user accounts, share drives and directories, and configure each workstation to log into the server. I launched NT’s User manager for Domains and created two user accounts (one for each workstation). The User manager lets me specify the username and password, which the groups user belong to, permitted login hours, home directory, whether the user has dial up access (an important part of RAS configuration), when and if the account expires, among many other things. I can assign users to new groups, or make them a part of NT’s special built-in groups, such as Account Operators (who can administer domain user and group accounts). Group accounts streamline user administration and security, especially in larger networks. Suppose you’ve installed a new drive and want to share it to a select group of users. By organizing users into groups, you don’t have to assign permissions to each user individually. You can assign them to the group and give access to all members of that group in a matter of moments. Dealing with users one at a time is also less reliable. It’s easier to overlook someone or assign access to the wrong person if you have to think about each user every time you add a share or change the structure of the network. In larger networks, an admin may define groups based on the departments in the organization (i.e. engineering, finance, marketing, etc.) He can give each group or department different access privileges based on their needs in the organization. If a user gets promoted and moves to a different department, the administrator can simply add them to the appropriate group (and remove them from another if necessary).
While the ideas behind user and group management or key to anyone interested in LAN administration, they didn’t apply to me in this situation. For the time being, I created two users and made them a part of the Domain Users group by default. A user name wasn’t going to do me any good unless I had access to something–I wanted to share one of the drives for access to common files. In NT, you can right-click any drive or directory and share it by selecting the appropriate command. I named the share and gave Change permissions to the Domain Users group (this allows users to read, create, delete, and rename directories and files contained with the share). Windows NT provides a utility named Server Manager. Among other things, it displays all of the available shares in one window and lets you modify the permissions for all of them in one place. This is easier than navigating the directory structure and selecting them individually.
The next step was to configure the workstations. I had already installed the network hardware on the machines (an easy job in Windows 95), and plugged the corresponding cables into the hub. I installed several pieces of software on each machine. Each computer needs the Client for Microsoft Networks—this enables users to connect to other Windows servers and computers and use their shared resources. If you plan on sharing a workstation’s resources, you’ll need to install File and printer sharing for Microsoft Networks—this lets each computer share its own files or printers with Windows NT and Windows for Workgroups machines. (This was a must for me since my printer and a number of critical files reside on my primary workstation.) I installed NetBEUI and configured both workstations to log onto the domain I specified during NT Server’s installation. I setup each workstation for user-level access control—each machine obtains the list of users from the NT Server domain. By specifying permissions this way, users don’t have to specify a password every time they want to access a shared driver or printer. Instead they can assign permissions to a group. Assuming another user is a member of that group, they are automatically granted access to the share when they log on. I shared relevant drives and a printer, and granted full access to NT’s default Domain Users group. Anxious to test my results, I restarted each computer and waited for the password prompt. Both computers logged into the domain without a problem.
Now that the machines could communicate locally, I wanted to take it another step and configure at least one workstation for remote access. To make this work, you must install RAS (Remote Access Service) on the server and set up the dial-up networking connection (DUN) on the client First I needed to install the modem. Using the Windows NT Diagnostics, it was fairly simple to identify the available IRQs and COM ports. I set the jumpers on the modem, let NT detect it for me, and installed the appropriate drivers when prompted. I rebooted and installed RAS. I told it which modem to use (I only have one) and configured it to accept and receive calls (a few switch in the RAS properties dialog box). RAS can use NetBEUI, NWLINK (analogous to the IPX/SPX protocols make popular by NetWare), and TCP/IP. I used NetBEUI because it’s efficient (according to the authors), I’m using it at home, and it’s the simplest to configure. Configuring the workstation for access to my network was almost identical to configuring it for access to an Internet service provider–it just uses a different protocol. I specified the modem to use, entered the phone number and dialer settings, and set a few options in the Server Types dialog box. I enabled the NetBEUI and Log on to network options, disabled the other protocols, and gave it a whirl. I took the laptop to my parent’s house, plugged in the modem, and fired up the DUN connection. Within moments, I was browsing the entire network, accessing shares, and moving files between the two computers. This was particularly refreshing. More than once I’ve been miles away from home wishing I had a document or two in order to continue my work.
My last goal for this project was to configure the server for dialup access to my Internet service provider. I configured RAS to dial-out and defined TCP/IP as one of the dial-out protocols (you’ll remember that I configured NetBEUI as the protocol for dial-in access). You can define different protocols for the dial-in and dial-out functions. You can also use multiple protocols for each function, assuming you have the necessary protocols installed. To set up RAS for access to the Internet, I first needed to install the TCP/IP protocol. I plugged in a phony value for the IP Address (192.168.0.1) and the Subnet mask (255.255.255.0). The Subnet mask marks which part of the IP Address I the network ID and which part indicates the station. My numbers imply the server is station 1 on the network defined by 192.168.0. If I were to assign an IP address to one of the workstations, I might select 192.168.0.2, and assign 3, 4, 5, and so on to subsequent stations. I defined the host name and left everything else alone.
Since the TCP/IP protocol is complex and beyond the scope of my knowledge at this point, I stuck with the minimum requirements needed to establish the RAS Connection. Creating the dial-up networking connection was similar to other connections I had created on my workstations. I entered the phone number (as well as alternate numbers) and set the dialer properties, defined TCP/IP as the protocol, defined the primary and secondary DNS addresses, and fired up the connection. At first, the connection would terminate immediately after the remote computer answered. It turns out that the security settings for the dial-up connection were the culprit—the connection accepted only encrypted authentication. The authentication protocol defines the way that the server and client exchange the username and password (this information can be encrypted for security reasons). My ISP uses PAP (Password Authentication Protocol) in which a simple, unencrypted password is acceptable–NT wouldn’t accept the unencrypted data and terminated the connection. To specify PAP as the protocol, I enabled the Allow any authentication including clear text option and tried again. Once the Internet connection worked, I began evaluating software that would let me share a single Internet connection among multiple workstations. I.Share, developed by Artisoft., defines a single Internet connection on the server as a shareable resource. If the workstation has the client software installed, any winsock connection will elicit the appropriate resource on the server computer and dial-out to the Internet. Another piece of software, named WinGate, uses proxy server technology to perform the same functions. This research has spawned interest in the TCP/IP protocol and other Internet-related technologies: proxy servers, web servers, firewalls, routers, T1 and ISDN, and so on.
This project has reaffirmed my interests in LAN management and technologies. Setting up and administering a small LAN has taken a lot of mystery out of the process. I’ve touched on the basic configuration of network protocols (on the server and client side), hardware configuration, user and group management, shares and permissions, and even Remote Access Service. Before I began the installation, I didn’t understand many these concepts or how they worked in Windows NT Server. At the same time, the introduction of new concepts has opened doors to new mysteries and illuminated a lot of the limitations in my knowledge. However, this is by no means intimidating. The relative ease at which this project progressed (with the exception the Zip driver installation) has bolstered my confidence and reaffirmed my decision to make LAN Administration a primary interest if not a primary career choice. When I graduated from college as an English major, I still hadn’t found anything I was truly passionate about and I had no idea what I was going to do for a living. Shortly after I purchased by first computer, those questions were answered. Now, as I sit here in room full of computers and anti-static bags, I’m one step closer to finding out which part of the computer industry I want to stake my claim in. This project has awakened me to the incredible breadth of networking technology. Understanding the broader concepts behind local and global networks is one thing; understanding how different software technologies (such as NT) utilize these concepts is another. There’s still a lot to learn, but there’s nothing a little study time and experience won’t take care of.