9 Apr 1995
Windows NT 3.5 is available in two packages. A Server package contains all of the functions and network options. A Workstation package is available at a lower price with a few constraints (only 10 concurrent other Windows stations can access the file server) and a with a few options removed (no Mac clients).
If Windows 95 (Chicago) were available today, it would probably be the most popular Microsoft Windows client system. However, since it has been delayed, the Windows NT Workstation provides the only stable product platform on which to do advanced application development. It is unlikely that anyone will run out and buy a Pentium system with 16 megabytes of RAM to run NT, but there are a number of users who already have such systems and, for them, NT is as good a choice as anything.
Still, Windows NT will be most attractive as a general purpose Server of just about anything. It can be a simple file and print server, in competition with Novell Netware. It can be a powerful database engine with the addition of SQL Server. It provides network management tools with SMS.
Both the Workstation and Server packages have identical Internet TCP/IP support. Both share files through FTP and printers through LPR. Both can, with programs developed by the EMWAC project, act as Gopher, Web, and WAIS servers. Although Unix also provides these functions, NT is much simpler to install and administer.
There are relatively few native NT client programs. However, all the 16-bit WINSOCK programs will run on NT.
NT does not support laptop computers, because it has no drivers for the PCMCIA adapter cards. If you have a laptop, wait for Chicago. It supports remote dial-up modem access to LAN services using either SLIP or PPP protocols. However, there is a strong bias in the design of the system to assume that all NT machines have a LAN adapter. During the installation process, it will automatically detect and configure the LAN from a long list of supported adapters. NT requires a new type of NDIS 3.x driver, and most vendors do not supply such software. So be careful to select only an adapter listed in the Microsoft Hardware Compatibility List for NT.
TCP/IP can be selected during the system installation. If it is the only protocol that will be used, then that is probably the best choice. However, TCP/IP does require some configuration, and if it is installed improperly it may be difficult to distinguish adapter card problems from configuration errors. NETBEUI and IPX are the other commonly used protocols, and they require no configuration. If one or both of these other protocols will be used to connect to file servers, then it may be easier to start with them, verify that the network is running, and then add TCP/IP later.
To add TCP/IP to a Windows NT system, open the Control Panel and click on the Network Icon. This opens a panel that displays the network adapters that have been configured for this machine and the various network software packages that have been installed.
[Select to display the Network Control Panel]
Click on the Add Software ... button. This presents a box with a drop down list of standard network software protocols packaged by Microsoft with the standard Windows NT system. There will be some additional items on the list for the NT Server that are omitted for NT Workstation. However, TCP/IP will be on all systems:
[Select to view the Add Network Software window]
Click the Continue button, and the system displays a list of TCP/IP related components that can be installed.
The DHCP and WINS Servers will not be offered as an option on a Windows NT Workstation. The first item, TCP/IP Internetworking contains the core protocol files and will be installed in any case. The other items include:
A Windows NT Server can act as a DHCP and WINS server. However, the configuration of these services is beyond the scope of this document.
To install TCP/IP, or any other NT system component, the machine must have access to the original distribution files. The NT distribution files can be located on a file server on the network, on a local or network shared CDROM, or they can be on the original diskettes. The user will be prompted for the source of the files and they will be copied to the NT system directory. Then components will be configured.
If you happen to choose the SNMP Service option, then you will get a rather cryptic panel asking for configuration information that only a network administrator might know. If you don't know how to fill this panel in, leave it blank. Better yet, don't add SNMP Service till you know what to do with it. It tends to produce a lot of Event Log messages anyway.
If you choose to install the FTP Server function, then Windows NT will warn you that FTP protocol transmits user passwords over the LAN in plain ASCII form. This is generally regarded as an insecure mechanism. This will not be a problem if the only use of FTP is to distribute public files to anonymous users.
The FTP server must then be configured. The Home Directory is the location where a remote FTP client starts out when first connecting to this machine. Note, however, that a remote user can use the "CD" command to change to any other directory on any other disk. Access to files on the server will be governed by the standard NT data security mechanism of a validated userid and access control lists. If an FTP server is accessible from the Internet, then remote users will have access to any files that have not been properly protected using the standard File Manager security options.
If the Allow Anonymous Connections box is checked, then remote users can logon with the dummy userid "anonymous". This is a TCP/IP convention, and it does not conform to NT security models. So the rest of the box supplies a real NT userid and password that will be substituted internally when the remote user connects. In this example (which is also the default) the anonymous FTP user becomes GUEST on this machine and has access to any files permitted to the GUEST account.
Clicking the Allow Only Anonymous Connections box, then local and RAS users will be discouraged from accessing files on the NT server using the insecure FTP protocol. Such users will therefore be encouraged to use the standard Windows network protocols that take better care of passwords and other sensitive stuff.
The system now returns to the Network Settings panel. [Select to view new Settings window.] Note that some TCP/IP related protocols (FTP Server, TCP/IP Printing) now appear in the list of Installed Network Software. If remote dial-in support using SLIP or PPP is not needed, then pressing the OK or Close button will trigger the post-processing where you will be asked to configure the IP address, network mask, and gateway address. However, if remote SLIP/PPP dial-up is required, then this is a good time to click Add Software ... again and add support for RAS.
Remote Access Services (RAS) is the name given by Microsoft to a bundle of support that allow LAN protocols (NETBEUI, Novell IPX, and TCP/IP) to be carried over an phone line. In most cases, this means an ordinary modem connected to an ordinary phone. However, there is also support for more exotic options like X.25 and ISDN. This document will concentrate, for now, on ordinary modems.
Each Microsoft operating system has its own approach to network software. In Chicago, the phone line is treated as a dummy Ethernet adapter and is installed like a hardware card. In NT, however, RAS is a software option installed like TCP/IP through the Add Software ... button of the Network item in the Control Panel. From the same list that included TCP/IP, another item is Remote Access Services.
[Select to view RAS in Add Software window.]
Although all modems use the same command to dial the phone, each has different options and switches that can be set to really foul things up. Some programs leave the modem set with unusual values, and when it fails to work the user blames the next program that tries to use it. In response, software companies are beginning to develop exhaustive tables of modem types along with all the commands needed to undo any mess left over from a previous configuration. NT can poll the COM ports to try and automatically identify the type of modem attached. If this fails, the user may have to select a modem from a list. Modems might have been configured during installation, but if that step was bypassed it can be done now by pressing the Add ... button to add a configuration for a new COM port.
Select one of the COM lines and press OK. The system will then offer to examine the modem and guess what type it is. If the modem is connected to the port and is powered up, let it go ahead.
If the modem is not available, then click Cancel and scroll down the list of modems till you find the correct model.
Also examine the box at the bottom of the screen. A Windows NT system can always be the remote machine that dials into the LAN, or it can always be the LAN-attached machine that answers the phone, or it can perform both functions. Choose the right button. This example assumes a remote client.
Also consider clicking the Network ... button. This brings up a panel that identifies the set of protocols that the line will support. Now, this is not the only place that this information will be configured. Later on, when you configure a remote location and provide the phone number there will be a second chance to select which protocols the remote station supports. A protocol can be rejected by turning off the "X" either here or for the individual remote workstation.
NETBEUI was the original protocol used for Windows networking. It is also the most efficient protocol for file and printer sharing between two NT machines directly connected by a phone line. Turning off NETBEUI here will generate a couple of "Are you REALLY sure you want to do this" messages. However, if the modem is connected to a separate communications controller, that device may not support NETBEUI over the phone line.
IPX is the Novell protocol. If you are not going to talk directly to a Novell server, it has the reputation of being a rather chatty protocol and can waste a lot of modem time.
Since this is, after all, a discussion about TCP/IP, that is the only protocol selected in this example. The system now returns (for the third time) to the Network Setup panel. This time click OK.
Windows NT now examines the set of protocols installed to determine if additional parameters are required. The set of panels that must now be displayed depends on the combinations of devices and protocols that have been selected. For example, now that both TCP/IP and RAS have been installed, it makes sense for NT to ask questions about the configuration of the line for TCP/IP purposes. If only NETBEUI had been installed, then the RAS questions would be different.
This will probably be the first panel presented. It requests configuration information for the TCP/IP use of the Ethernet Adapter card. If the box marked Enable Automatic DHCP Configuration is checked, then a Windows NT 3.5 Server must be on the LAN configured as a DHCP server. When this machine restarts, it will go out to the server to acquire a "lease" on an IP address and other configuration information.
Otherwise, enter the IP address, subnet mask, and default gateway address as previously discussed in Planning TCP/IP. If a Domain Name Server is present for this network, click the DNS... box.
DNS is a standard TCP/IP protocol for finding machines by a name. The PCLT server has a Domain Name of "pclt.cis.yale.edu". In this example, another machine named "pcltwiz.cis.yale.edu" is configured. The machine name goes first, then the rest of the domain name goes in a separate box. The IP address of one or more workstations is typed in to the box on the left, and the Add-> button moves the address into the Search Order list on the right.
Click OK here and on the previous TCP/IP Configuration panel. NT may pop up a nasty looking message saying that there is no WINS server configured. WINS is a good idea if TCP/IP is to be used as a transport mechanism between the file and print client and server components of Windows NT and WFWG. If TCP/IP is only going to be used to access the Internet, then WINS is not helpful.
The network changes do not take effect until the system is restarted. Press the button to reboot NT. When the system comes back up, the Program Manager has an additional group for Remote Access Services. Open it, and click the Remote Access icon.
The box labeled Remote Access Monitor displays the state of the important modem leads. This can be quite helpful if you have an internal modem that doesn't have external LED lights. The Remote Access panel contains a phone book. To save time, this example shows an entry that has already been added to the phone book. A new entry can be inserted with the Add button, or an old entry can be selected and changed with the Edit button.
Give the entry a name. Supply a phone number. Select a port. The "advanced" buttons are shown on the bottom. They allow control over more detailed items. Click the Network... button.
The Network panel under RAS allows this phone call to be associated with either the SLIP or PPP protocol, and it allows each protocol to be configured. SLIP is a simple, old, ad hoc protocol that was adopted because nothing else was available. PPP is a newer, better protocol that has been adopted after much discussion and refinement. PPP should be selected when it is available, and SLIP should be used only as a fallback.
When a remote NT Workstation dials into the central site, two types of devices can end up answering the phone. An NT Server can support a multiline adapter card and a bunch of modems. However, when a large number of lines are switched between a large number of systems, organizations generally prefer to use a dedicated communications server to route the remote traffic onto the LAN.
These devices are available from Cisco, Shiva, Xyplex, and many other vendors. To protect the network from unauthorized access, they generally request a userid and password before allowing the remote user to proceed. NT can be configured to present a "terminal" screen. The user then enters the user and password and issues any other commands, before allowing the RAS protocol to take over. Alternately, NT can be configured with a script that handles the logon automatically. This information is configured in the x:\WINNT\SYSTEM32\RAS\SWITCH.INF file.
OK=< match> "Username:"
OK=< match> "Password:"
OK=< match> "> "
This script waits for the central site device to type a message ending in the string "Username:". It then responds with a userid (represented here as "xxxxx"). It then waits for the system to enter a password and responds with it. It then waits for a command prompt and responds with the "PPP" command. Once this section has been added to SWITCH.INF, and RAS has been restarted, it can be associated with a particular phone book entry by loading the Phone Book Edit panel previously shown and clicking on the Security... button.
The dropdown list for scripts will allow specification of any names found in a "[name]" section of the SWITCH.INF dataset. Check the Microsoft documentation for more information on SWITCH.INF syntax.
Continue Back PCLT
Copyright 1995 PC Lube and Tune -- Windows on the World -- H. Gilbert