Click on our Sponsors to help Support SunWorld
Connectivity by Rawn Shah

Getting started with Windows remote connectivity

Knowing the details makes remote connectivity a more realistic option

SunWorld
March  1996
[Next story]
[Table of Contents]
[Search]
Subscribe to SunWorld, it's free!

Abstract
Microsoft created multiple levels of support for networking issues and technologies, such as analog modems, ISDN, remote accessibility and connection, remote file and resource sharing, and user identification. This article explores these technologies and how they combine to form the grand unity of remote computing promised by the new generations of Microsoft operating systems. (2,000 words)


Mail this
article to
a friend

Windows 95 has standardized remote connectivity for mobile users with application and system level support. Windows for Workgroups 3.11, Windows 95, and NT share key features that consolidate a variety of remote connectivity components The unifying technologies include:

Microsoft created multiple levels of support for networking issues and technologies, such as analog modems, ISDN, remote accessibility and connection, remote file and resource sharing, and user identification. In this article we will explore some of these technologies and how they combine to form the grand unity of remote computing promised by the new generations of Microsoft operating systems.


Advertisements

The grand unity, an introduction
While Remote Application Services (RAS), a software gateway between the server and a remote PC, has been available on Windows for Workgroups 3.11 for some time, remote connectivity to the office LAN was not truly viable until Windows NT and 95 came along. The cooperative multitasking Windows 3.x family of operating environments inhibits the data access performance of remote nodes beyond one or two connections to the RAS server at a time. The new networking architectures and operating system designs of Windows 95 and NT are able to support up to 64 RAS client connections at a time.

Both Windows 95 and NT have Winsock 1.1 as core components of the OS providing standardized networking support. With the introduction of Winsock 2.0 this structure has evolved, but mainly only on the software protocol levels and not in the hardware layers. (Windows 95's LAN and WAN architecture is explored in depth in the SunWorld Onlnine columns, "Networking in Windows 95" and "Networking with Windows 95 part 2.") This new Winsock standard will formally support not just TCP/IP but also IPX/SPX, DECnet, and OSI as well as important hardware communications technology such as ISDN and ATM. Although Winsock 2.0 promises support for telephony-based connection-oriented systems, much of this is proposed as a direct interface to the TAPI. This allows an application to have direct control of modem, ISDN, or other connection-oriented networking technologies as needed.

With RAS, far-flung Windows for Workgroups 3.11, Windows 95, and NT users can connect to an NT server and access the home office's network. RAS is a software gateway between the NetBIOS NT LAN and the serial connection on the remote PC. On the remote PC side, RAS handles the dial-up protocol and negotiation process to make the connection and authenticate the user.

At the network protocol level, Microsoft uses the Internet DHCP standard for TCP/IP address assignments. This makes it easy to integrate many client PCs into the network. DHCP is the successor to the old BOOTP where clients broadcast requests to the network in hopes of finding a DHCP server that would respond with the proper network information for the client. With DHCP, you no longer need to directly assign individual TCP/IP parameters for each computer. The procedure is a dynamic negotiation and can also support a greater number of clients at a time.

DHCP has its shortcomings. Topping the list is its inability to match an Internet hostname with an IP address because the Domain Naming System (DNS) does not support dynamic mapping of names to addresses. In response, Microsoft created Windows Internet Naming System (WINS), which locates resources and identifies clients uniquely.

Telephony API (TAPI)
The Microsoft Telephony API is a device-independent application layer that allows software control of telephony-oriented devices, such as telephones, fax machines, pagers, modems, and ISDN Terminal Adapters. Alternatively, you can control parts of the PC (such as the serial ports) through the Win 95 COMM layer. This, however, is device-specific and you must monitor a port directly, or program the initialization of a modem.

TAPI was also created to facilitate the growing voice-mail and software-based branch exchange markets. This capability may lead Microsoft into the telecommunications market by providing the means for telecommunications software/hardware vendors to create PBX packages based upon the Microsoft Back Office and NT servers. TAPI and these proposed software packages will allow administrators to direct voice-mail over a LAN or WAN through Microsoft Exchange, as well as creating voice-based menu systems that can be controlled by PC-based software. Various large telecommunication hardware vendors such as Northern Telecomm (Nortel) report they are working on such software.

Today, Microsoft supports TAPI in Windows 95's Dial-up Networking, as well as the HyperTerminal application. In NTserver, it is built into RAS.

More about RAS
RAS is probably the most visible of all the Microsoft remote computing technologies. As I mentioned earlier, it is the software gateway that allows remote Windows 95, NT Workstation, and Workgroups 3.11 users to communicate with the office LAN. In Windows 95, RAS appears as the Dial-up Networking addition to the operating system.

RAS allows users to connect using standard communications protocols like the Point-to-Point Protocol (PPP). PPP is a multiprotocol transport mechanism over asynchronous and synchronous serial connections. It is one of the most prevalent protocols on the Internet, succeeding the older Serial-Line Internet Protocol (SLIP). PPP can transport not only TCP/IP, but also NetBIOS, IPX/SPX, HDLC, and so on. PPP employs basic authentication services such as Password Authentication Protocol (PAP) and Challenge Handshake Authentication Protocol (CHAP) to identify and authenticate remote users.

PAP, which sends a non-encrypted ASCII password to the remote server, is an authentication system, it does not really provide any security. CHAP, on the other hand, can use several security algorithms for the actual encryption of passwords. The most common is the DES (Data Encryption Standard) -- used by most Unixes. Microsoft added to the list of security mechanisms supported by CHAP with MS-CHAP or more technically RSA MD4. It provides a more secure encryption algorithm for authentication and is incompatible with other non-NT PPP systems. NT also supports the use of Shiva PAP (SPAP), which works very much like PAP with the exception that it encrypts the passwords before they are sent to the server.

Using RAS
To configure Windows 95 to use RAS, you need to install the dial-up networking service, which adds the software necessary to handle modems, serial communications, and authentication protocols. Note that this is not the same as the Microsoft Network, which is a commercial online service. With this in place, you can now install a new type of "Dial-up Adapter" in the networking control panel. This is a driver that emulates NDIS queries and redirects them to TAPI, which in turn sends them to a modem.

You can install both a LAN interface and a modem with Windows 95 at the same time; for example, a Windows 95 PC may have a Xircom Modem+Ethernet PC Card (formerly PCMCIA) -- the modem is for use on the road while the faster Ethernet allows better connectivity in the office. Whatever your connection, keep in mind RAS may make its own preferences. For example, if you connect to the same LAN via the Ethernet as well as through a modem, the computer will use the faster Ethernet link. When using several networking adapters, make sure you configure the protocol-specific parameters for the protocols that will be communicating over that adapter. It is possible to set up a LAN connection that uses only IPX/SPX, while having a TCP/IP dial-up connection at the same time.

For the dial-up connection you can also specify remote server-based settings. For example, if you connect to an Internet server using dynamic PPP, you will want to indicate the server type as Internet and set the address to be obtained from the server. If, on the other hand, you need to assign an IP address to the system specifically, then you should enter the address in the given field. Keep in mind the information for server settings will override whatever protocol specific properties you set for the dial-up connection in the Networking control panel.

If your Windows 95 computer is set to a specific NT domain and the system has been locked by your administrator so that it can be modified by the network staff through the Windows 95 profiling system, you may need your network manager's help. You will need to indicate the NT domain that you belong to if connecting to an NT server.

To use NetWare services remotely, you must have an NT server running Gateway Services for NetWare (GSNW) as well as the NetWare IPX/SPX protocol. You must then configure the resources that can be accessed by remote NetBIOS clients. GSNW is a translator between NetBIOS and NetWare services, which allows Windows for Workgroups 3.11, Windows 95, and NT clients to access the NetWare server as a volume on the NT server

User profiles in Windows 95
Windows 95 and NT user profiles can be set to identify users on the network uniquely. These profiles can be administered remotely for other NT or 95 computers, or by using the Microsoft System Management Server (SMS). With SMS it is possible for the network administrators to designate that only specific applications be used on a Windows 95 computer or to allow the allocation of licenses for applications as requested.

This is a very handy tool for managing software and computers. The administration staff no longer worries about illegal software being installed on the network or controlling license access to individual computers. The user can be allowed access to a fixed directory structure, or to only the files they need. This results in fewer worries about the unauthorized access of secure information.

To enable these features, you must have Remote Administration and Remote Registry services installed and running on your Windows 95 computer. Make sure you have file and printer sharing enabled first. Open the Passwords Control Panel, select the option for Remote Administration, and then enter a password for the Remote Administrator. You must install Remote Registry from the Windows 95 CD-ROM from the location Admin\Nettools\RemoteReg. You must also specify that user-level sharing be enabled instead of the basic system-level sharing.

A shared Windows 95 system
Windows 95 allows you to use a shared version of the OS by booting from a network server. This saves space on each client and reduces administration chores. Windows 95 needs to be installed on the server using the NetSetup program. The supported server types currently are NT, LAN Manager 2.x, another Windows 95 computer, LANtastic 5.x, VINES 5.52, Pathworks 5.x, LAN Server 1.2+, NetWare 3.x & 4.x, and PC-NFS 5.0. You cannot, however, remote-boot over an RAS connection; not only would it be too slow in most cases, but the Netsetup program does not support the dial-up adapter as a valid choice for the client.

For the client, you will need real-mode (16-bit) and protected-mode (32-bit) network drivers installed. You must have this server volume mounted as a drive on your client computer. The server must also export a second volume which will be the repository for any files of your diskless client PC.

This computer can now be booted with a floppy or a small local drive. From the Netsetup directory on the Windows 95 CD-ROM, you must run the Batch program and enable the Server Based Setup option. You should then select Floppy Disk or Local Drive Boot procedures. This will create the installation script for remote booting.

On the remote server, you must then run the setup program to activate this script. You will need to enter the directory name on the user base location where the user's personal files will be kept. The network server also needs a machines.ini file with the proper info about the client computers which are installed. The Windows 95 Resource Kit will give you a full explanation of the definitions for this file.

Remote use
Remote connectivity has certainly improved with the advent of SMS, which provides a much nicer method of administrating a large number of clients. As a competitor to the NetWare NOS, it offers all the requirements in a more elegant, user-friendly interface.

Most administrators, however, forget the nature of remote clients and often pre-record the login and password allowing remote users to mindlessly connect to the corporate network with the click of a button.

Unfortunately, users pick trivial passwords and lose portable computers. A laptop computer in the wrong hands exposes an organization's data. A remote computer needs to be treated with greater precautions than an on-site desktop. The Network administrator needs to instill an awareness of the dangers of remote access and implement security measures and training for remote users.


Click on our Sponsors to help Support SunWorld


Resources


About the author
Rawn Shah is vice president of RTD Systems & Networking, Inc., a Tucson, Arizona based network consultancy and integrator. Reach Rawn at rawn.shah@sunworld.com.

What did you think of this article?
-Very worth reading
-Worth reading
-Not worth reading
-Too long
-Just right
-Too short
-Too technical
-Just right
-Not technical enough
 
 
 
    

SunWorld
[Table of Contents]
Subscribe to SunWorld, it's free!
[Search]
Feedback
[Next story]
Sun's Site

[(c) Copyright  Web Publishing Inc., and IDG Communication company]

If you have technical problems with this magazine, contact webmaster@sunworld.com

URL: http://www.sunworld.com/swol-03-1996/swol-03-connectivity.html
Last modified: