Copyright: Remote Access Service
Citation: Remote Access Service


Before You Begin
Before You Begin	1 of 4

Before You Begin

This manual is for network administrators who are responsible for installing and maintaining the Microsoft® Windows NT™ Server Remote Access Service.

The manual assumes knowledge of:

The Microsoft Windows NT Server and MS-DOS® operating systems.

Installation, operation, and maintenance of asynchronous communication hardware, including serial ports, modems, and multiport adapters.

For clarity, this manual will capitalize references to the Windows NT Remote Access Service, or will use the acronym RAS. References to remote access products in general will be lowercase (for example, remote access servers).


How to Use This Manual
Before You Begin	2 of 4

How to Use This Manual

This manual contains the following chapters and appendixes:

Chapter 1, "Understanding Remote Access Service"

Describes the functions, features, and underlying concepts of the Remote Access Service and suggests ways to plan a Remote Access installation.

Chapter 2, "Installing and Configuring the Remote Access Service"

Tells how to add and configure Remote Access server software on computers running the Windows NT Server system, and tells how to install Remote Access client software on computers running the Windows NT system.

Chapter 3, "Choosing and Configuring Modems"

Discusses supported and unsupported modems and tells how to add a new modem to the MODEM.INF file.

Chapter 4, "Security"

Explains security features and the Remote Access security model.

Chapter 5, "Maintenance and Troubleshooting"

Tells how to monitor servers and users through audit records and error logs, and how to troubleshoot problems on the server and client.

Chapter 6, "X.25 Support"

Explains how to connect a Remote Access client to a Remote Access server through an X.25 network.

Chapter 7, "Support for Security Hosts and Switches"

Describes how the Terminal feature works with intermediary security devices and switches.

Appendix A, "Wide-Area Network Adapters"

Lists wide-area network adapters supported by the Remote Access Service.

Appendix B, "Migrating from Earlier Versions of the Remote Access Service"

Lists Remote Access configuration files, including new files specific to Remote Access, as well as modifications to the Redirector and MS-DOS files.

Appendix C, "Modifying Parameters"

Lists and describes Remote Access parameters and tells how to modify them in the Windows NT Server Registry.

Appendix D, "Cabling"

Lists supported modems and cabling information.

Appendix E, "Understanding MODEM.INF"

Analyzes in detail the MODEM.INF file.


Conventions
Before You Begin	3 of 4

Conventions

This manual uses different type styles and special characters for different purposes:

Convention	Used for

Bold	Commands that must be typed exactly as they appear. For example, regedit.

Italic	Variables. For example, the variable computername indicates that you substitute the name of a client or server.

Monospace	Examples and file listings.

ALL CAPITALS 	Filenames and pathnames in text.


Finding Further Information
Before You Begin	4 of 4

Finding Further Information

This manual contains conceptual information and installation and configuration steps for the Remote Access Service. For supplemental information, see Remote Access online Help.

For information specific to Windows NT Server, consult the following manuals:

Windows NT Server System Guide

Windows NT Server Concepts and Planning Guide

For further information about serial ports, modems, and multiport adapters, refer to the appropriate hardware manual(s), or consult your hardware manufacturer.

For information about Microsoft Product Support Services, see Windows NT Help in the Main program group.


Understanding Remote Access Service
Chapter 1	1 of 22

Understanding Remote Access Service

This chapter explains the basic operation of Windows NT Remote Access Service (RAS) and how to implement Windows NT Server RAS in a Windows NT Server network. This includes:

Overview of the major components of RAS

Remote access protocols-Point-to-Point Protocol (PPP), Serial Line Internet Protocol (SLIP), and Microsoft RAS protocol

Wide-area network (WAN) options

Security options

Remote access servers

LAN protocols-TCP/IP, IPX, and NetBEUI

For additional information about the Remote Access Service, see RAS online Help.


Remote Access Service Overview
Understanding Remote Access Service	2 of 22

Remote Access Service Overview

RAS allows remote users to work as if they are connected directly to the network. The RAS connection is transparent to Microsoft clients and network applications.

A Windows NT RAS configuration will include the following components:

Remote access clients

Windows NT, Windows™ for Workgroups, MS-DOS, and LAN Manager RAS clients can all connect to a Windows NT RAS server. Clients can also be any PPP client.

Remote access protocols

Windows NT version 3.5 RAS servers support the PPP protocol, enabling any PPP client to use TCP/IP, IPX, or NetBEUI. Windows NT version 3.5 clients can also access the large installed base of SLIP remote access servers. The Microsoft RAS protocol allows any Microsoft RAS client to dial in.

WAN options

Clients can dial in using standard telephone lines and a modem or modem pool. Faster links are possible using ISDN. You can also connect RAS clients to RAS servers using X.25 or an RS-232C null modem.

Security options

Windows NT logon and domain security, support for security hosts, data encryption, and callback provide secure network access for remote clients.

RAS servers

The Windows NT Server RAS permits up to 256 remote clients to dial in. The RAS server can be configured to provide access to an entire network or restrict access to the RAS server only.

LAN protocols

IP protocol support permits accessing a TCP/IP network, such as the global Internet. IPX protocol support enables remote clients to access NetWare® servers and printers. You can also use NetBIOS applications over IPX, TCP/IP, or NetBEUI. Windows Sockets applications over TCP/IP or IPX, named pipes, Remote Procedure Call (RPC), and the LAN Manager API are supported.

The following illustrates all RAS features and possible configurations. Actual implementations and configurations will vary and are discussed in this book.

Overview of Windows NT Server RAS


Remote Access Clients
Understanding Remote Access Service	3 of 22

Remote Access Clients

Clients to Windows NT RAS servers may be Windows NT, Microsoft Windows for Workgroups, MS-DOS, LAN Manager, or any PPP client. The client must have a modem (9600 baud or above is recommended for acceptable performance), an analog telephone line or other WAN connection, and remote access software installed.

Connecting can also be automated for any Microsoft client with a simple batch file and the rasdial command or with a custom, RAS-aware application using the appropriate Application Programming Interface for RAS. You can also schedule automatic backups to or from remote computers using RAS and the at command.


Windows NT Version 3.5 Clients
Understanding Remote Access Service	4 of 22

Remote Access Clients

Windows NT Version 3.5 Clients

Windows NT version 3.5 clients can take full advantage of Windows NT version 3.5 RAS features. Windows NT version 3.5 clients can also connect to any non-Microsoft remote access PPP server or SLIP server.

Windows NT version 3.5 clients negotiate logon and authentication with the server, whether the server is a Microsoft RAS server, a PPP server, or a SLIP server. You can also configure RAS phone book entries to use scripts that can completely automate logon.

For more information about configuring and using Windows NT version 3.5 clients, see RAS online Help.


Windows NT Version 3.1 Clients
Understanding Remote Access Service	5 of 22

Remote Access Clients

Windows NT Version 3.1 Clients

Windows NT version 3.1 clients use the Microsoft RAS protocol and are fully compatible with all versions of Microsoft RAS.

These clients do not support the PPP protocol introduced in Windows NT version 3.5. Only Windows NT version 3.5 or other PPP clients provide the support necessary to run TCP/IP or IPX applications on clients that directly communicate with servers on the LAN using TCP/IP or IPX.


Windows For Workgroups, MSDOS, and LAN Manager Clients
Understanding Remote Access Service	6 of 22

Remote Access Clients

Windows For Workgroups, MS-DOS, and LAN Manager Clients

Windows NT Server provides a Microsoft Network Client version 3.0 for MS-DOS and a Windows for Workgroups client that provide remote access. Separately purchased Windows for Workgroups and LAN Manager RAS clients can also connect to Windows NT version 3.5 RAS servers. These clients are fully compatible with all versions of Microsoft RAS.

The Microsoft Network Client version 3.0 for MS-DOS must be set up to use the full redirector (the default setting.) If the basic redirector is used, the Remote Access program rasphone will not start.

The Windows for Workgroups, MS-DOS, and LAN Manager clients can use the RAS NetBIOS gateway to access NetBIOS servers running TCP/IP, IPX, or NetBEUI, but these clients cannot run applications that must use TCP/IP or IPX on the client.

These clients also do not support the PPP protocol introduced in Windows NT version 3.5. Only Windows NT version 3.5 or other PPP clients provide the support necessary to run TCP/IP or IPX applications on clients that directly communicate with servers on the LAN using TCP/IP or IPX.


PPP Clients
Understanding Remote Access Service	7 of 22

Remote Access Clients

PPP Clients

Non-Microsoft PPP clients using TCP/IP, IPX, or NetBEUI can access a Windows NT version 3.5 RAS server. The RAS server will automatically negotiate authentication with PPP clients; the Windows NT RAS software needs no special configuration for non-Microsoft PPP clients.

For more information about your PPP client, see the software documentation for your PPP client.


Remote Access Protocols
Understanding Remote Access Service	8 of 22

Remote Access Protocols

Remote access protocols control the transmission of data over the wide-area network (WAN). The operating system and LAN protocol(s) of your remote access clients and servers are the major factors in the remote access protocol your clients will use.


PPP
Understanding Remote Access Service	9 of 22

Remote Access Protocols

PPP

Point-to-Point Protocol (PPP) has become the standard for remote access.

Remote Access protocol standards are defined in Requests for Comments (RFCs), which are published by the Internet Engineering Task Force and other working groups. The RFCs supported in this version of Windows NT RAS are:

RFC 1548  The Point-to-Point Protocol (PPP)

RFC 1549  PPP in HDLC Framing

RFC 1552  The PPP Internetwork Packet Exchange Control Protocol (IPXCP)

RFC 1334  PPP Authentication Protocols

RFC 1332  The PPP Internet Protocol Control Protocol (IPCP)

If your remote clients connect to third-party PPP servers, they may need to enable a post-connect terminal script to log on to the PPP server. After the server informs them it is switching to PPP framing mode, the user must start Terminal to complete logon.

Microsoft recommends that you use PPP because of its flexiblity and its role as an industry standard, and for future flexibility with client and server hardware and software.


SLIP
Understanding Remote Access Service	10 of 22

Remote Access Protocols

SLIP

Serial Line Internet Protocol (SLIP) is an older remote access standard typically used by UNIX® remote access servers. Windows NT Remote Access clients support SLIP and can connect to any remote access server using the SLIP standard. This permits Windows NT version 3.5 clients to connect to the large installed base of UNIX servers. The Windows NT Remote Access server does not support SLIP clients.

The RFCs supported in this version of Windows NT RAS are:

RFC 1144  Compressing TCP/IP Headers for Low-Speed Serial Links

RFC 1055  A Nonstandard for Transmission of IP Datagrams Over Serial Lines: SLIP


Microsoft RAS Protocol
Understanding Remote Access Service	11 of 22

Remote Access Protocols

Microsoft RAS Protocol

Microsoft RAS protocol is a proprietary remote access protocol supporting the NetBIOS standard. The Microsoft RAS protocol is used in all previous versions of Microsoft RAS and is used on Windows NT version 3.1, Windows for Workgroups, MS-DOS, and LAN Manager clients.

Microsoft RAS requires RAS clients to use the NetBEUI protocol. The RAS server then acts as a "gateway" for the remote client, providing access to servers that use the NetBEUI, TCP/IP, or IPX protocols.


WAN Options
Understanding Remote Access Service	12 of 22

WAN Options

Four options are available to connect clients to servers: phone lines, ISDN, X.25, and RS-232C null modem.


Phone Lines, Modems, and Modem Pools
Understanding Remote Access Service	13 of 22

WAN Options

Phone Lines, Modems, and Modem Pools

The most common WAN connection is a standard analog telephone line and a modem. Standard analog phone lines are available worldwide and will meet most RAS needs for roving users. (Standard analog phone lines are also called PSTN, Public Switched Telephone Network, or POTS, Plain-old Telephone Service.)

Nearly 200 modems are compatible with Windows NT. Most modems that comply with industry standards should interoperate, however, many difficult-to-detect problems can come from incompatible modems. Using the same modem on clients and servers can prevent these problems.

Modems are automatically detected. Automatic modem detection is especially useful for users who are not sure what modem is installed (for example, an internal modem).

Third-party modem pools can be used on either the client side or the server side. Modem pools are made available to RAS through the Network option in Control Panel. Consult your modem pool documentation for more information.

Modem data compression and error control are available. However, built-in software compression offers enhanced performance over modem data compression.

For more information about modems, see Chapter 3, "Choosing and Configuring Modems."


ISDN
Understanding Remote Access Service	14 of 22

WAN Options

ISDN

If you have a stationary remote site or sites that will use RAS, and would like much faster WAN speeds, you can use an Integrated Services Digital Network (ISDN) line. An ISDN line must be installed by the phone company at both the server and remote site. ISDN is not as widely available as standard phone lines. ISDN also requires that an ISDN card be installed in place of a modem in both the server and remote client.

Standard phone lines typically communicate at 9600 bits per second (bps), whereas ISDN communicates at speeds of 64 or 128 kilobits per second. Costs for ISDN equipment and lines can be higher than standard modems and phone lines. However, the speed of communication reduces the duration of connections, possibly saving toll charges.

An ISDN line comes with two B channels that transmit data at 64 kilobits per second, and one D channel for signaling that transmits data at 16 kilobits per second. You can configure each B channel to operate as a port. Some ISDN drivers allow you to aggregate the channels. This means you can statically assign a higher bandwidth by configuring both B channels to act as a single port. With this configuration, line speed increases to 128 kilobits per second. Channel aggregation schemes are specific to each driver, so you must use the same driver and equipment on the client and server.

For more information about ISDN, see RAS online Help.


X.25
Understanding Remote Access Service	15 of 22

WAN Options

X.25

X.25 is a standard packet-switching communication protocol (or transport) designed for WAN connectivity.

Windows NT RAS suppports connections based on the X.25 standard using Packet Assemblers/Disassemblers (PADs) and X.25 smart cards. You can also use a modem and special dial-up X.25 carriers (such as Sprintnet and Infonet®) in place of a PAD or smart card on RAS clients. For more information about RAS and X.25, see RAS online Help or Chapter 6, "X.25 Support."

The following illustration shows how a client connects to the Remote Access server through a dial-up PAD and the X.25 network.

How Remote Access Connects to the Server Through a Dial-Up PAD


RS-232C Null Modem
Understanding Remote Access Service	16 of 22

WAN Options

RS-232C Null Modem

In situations where you have two or more networks in the same location that are not physically connected, but you would like to use resources on both networks from one computer, you can use an RS-232C null modem. An RS-232C null modem can also be used as a substitute for a network card in a computer located near a RAS server.

The client connects an RS-232C cable from a COM port to a COM port on the RAS server. RAS is used to create network access.


Security Options
Understanding Remote Access Service	17 of 22

Security Options

Windows NT user accounts and domains provide security with encrypted authentication. RAS provides a callback feature and you can also encrypt data. You can install security hosts to prevent unauthorized access to your LAN.


User Accounts and Domains
Understanding Remote Access Service	18 of 22

Security Options

User Accounts and Domains

Windows NT Server security is integrated into RAS. User accounts on any domain can be used by remote clients for RAS access. Authentication can be encrypted at connect time.

This section explains Windows NT user accounts and approaches for implementing domain-based security for RAS. This section assumes you have a domain structure established and provides information about integrating RAS into your existing domain scheme.

For information about Windows NT Server user accounts and domains, see the Windows NT Server Concepts and Planning Guide.

If you are not using a Windows NT RAS server, you must provide Windows NT RAS clients valid user accounts for your network.

User Accounts

After RAS is installed, you must specify who can dial in to the server.

You need not create user accounts just for RAS users. RAS servers use the user accounts of any trusted domain or computer on the Windows NT network. Centralized user accounts simplify network and RAS administration.

Use the Remote Access Admin utility to select a computer's or domain's user accounts. You then grant RAS permission to the user accounts. You can also set callback behavior per user.

Domains

Remote Access servers using Windows NT Server domain-based security can be grouped in a single domain or distributed among several domains that may or may not have trusted relationships.

Centralized

Placing all Remote Access servers into a single domain simplifies central administration because only a single user-account database needs to be maintained, and because it allows the system administrator to monitor all RAS servers and users at once.

Centralized administration does not mean that all servers have to reside in the same physical location. Because the domain is logical rather than physical, the actual servers can be in different locations and still be part of the same domain.

Use trust relationships if departments maintain their own user accounts but Remote Access will be centrally administered. The RAS servers exist in the same domain, allowing administrators to monitor all RAS servers simultaneously.

In this configuration, it's best to set up an account on only one domain for each user, especially for users dialing in through RAS version 1.1 or earlier. If the Remote Access server can't find the user's account in the server's domain, it simultaneously checks the trusted domains and accepts the first response. If the first response comes from a domain where the user has a different password or does not have Remote Access permission, authentication fails even though another domain may have the same user account with Remote Access permission.

Distributed

Smaller organizations that value flexibility and local control, or organizations that have no clear need for centralized security, may prefer that individual departments or work groups set up and maintain their own Remote Access domains. Trust relationships can be used to permit access across domains.


Security Hosts
Understanding Remote Access Service	19 of 22

Security Options

Security Hosts

Security hosts are dedicated computers that validate users prior to connecting the user to the network. Typically users must carry a special "key," or a small device that looks like a pocket calculator. When logging on to the security host, the user must consult the key for a unique access code. Refer to the documentation for your security host for more information about specific security host operation.

When connecting through a security host or similar device, the user is often required to provide information before continuing. If the necessary information is static (never changes), you can use scripts as specified in the SWITCH.INF file to automate users' connections. If the necessary information requires user input, the RAS client phone book entry must be configured to use Terminal mode for the interactive session.

When you install a security host between the Remote Access server and its modem(s), the server's modem and the security host act together as a hybrid modem. The MODEM.INF file supplied with Windows NT includes a template for each supported security host paired with a particular modem.

For more information about security hosts, see Chapter 7, "Support for Security Hosts and Switches." For more information about creating and using scripts with the SWITCH.INF file and about using and configuring Terminal mode on a client, see RAS online Help.


Data Encryption and Callback
Understanding Remote Access Service	20 of 22

Security Options

Data Encryption and Callback

Windows NT version 3.5 clients can encrypt data in order to maintain security in case of unauthorized interception of remote access tranmissions. Clients configure each Phone Book entry to use data encryption. Windows NT RAS provides data encryption using the RSA™Data Security Incorporated RC4 algorithm.

The Callback feature can ensure that only users from specific locations are permitted access to your RAS server, in addition to saving toll charges for the user.


Remote Access Servers
Understanding Remote Access Service	21 of 22

Remote Access Servers

Windows NT Server administrators use the Remote Access Admin program to control the Remote Access server, view users, grant permissions, and monitor Remote Access traffic. For more information about using the Remote Access Admin program, see RAS online Help.

Events and errors are recorded in Event Viewer on Windows NT RAS clients and servers. Evaluating the log in Event Viewer can help you determine the source of problems.

You install and configure RAS using the Control Panel Network option. You specify startup options using the Control Panel Services option.

The Windows NT Server RAS permits up to 256 remote clients to dial in. The RAS server can be configured to provide access to an entire network or restrict access to resources on the RAS server only.

The server must have a multiport adapter or modems (9600 baud or above is recommended for acceptable performance), analog telephone lines or other WAN connections, and the RAS software installed. If the server will provide access to the network, a separate network adapter card must be installed and connected for each network the server will provide access to.

RAS servers are configured during initial RAS setup. You must specify whether access will be to the entire network or to the RAS server only. You must also select the protocols to use on the LAN (IPX, TCP/IP, and NetBEUI) and an authentication encryption option. For more information about remote access protocols and LAN protocols, see those sections elsewhere in this chapter.

Ports on RAS servers are configured individually. Each port on a computer can be set to Dial Out Only, Receive Calls Only, or Dial Out And Receive Calls. These settings affect only the port specified, not all ports. For example, your RAS server can be configured to provide access to the entire network, COM1 can be configured to receive calls, and COM2 can be configured for dial out and receive. A remote user can call in on either COM port, but a local user can only use COM2 for outbound RAS calls.

For more information about installing and configuring RAS, see Chapter 2, "Installing and Configuring Remote Access Service."


LAN Protocols
Understanding Remote Access Service	22 of 22

LAN Protocols

You are probably integrating remote access into an existing network. The protocol(s) you use in that network are a crucial factor in how you plan, integrate, and configure RAS.

Windows NT version 3.5 RAS supports TCP/IP, IPX, and NetBEUI. This support means you can integrate Windows NT RAS into existing Microsoft, UNIX, or NetWare networks using the PPP remote access standard. Windows NT version 3.5 RAS clients can also connect to existing SLIP-based remote access servers (primarily UNIX servers).

When you install and configure RAS, any protocols already installed on the computer (TCP/IP, IPX, and NetBEUI) are automatically enabled for RAS on inbound and outbound calls.

You must also specify if you want to provide access to the entire LAN, otherwise, users will be able to access only the RAS server. If you provide access to the entire LAN using TCP/IP or IPX, you must also configure how the server will provide IP addresses or IPX net numbers. If you provide access to the entire LAN using NetBEUI, no additional configuration is needed.

TCP/IP and RAS

TCP/IP is one of the most popular protocols in use today. Its routing capabilities provide maximum flexibility in an enterprise-wide network.

On a TCP/IP network, you must provide IP addresses to clients. Clients may also require a naming service or method for name resolution. This section explains IP addressing and name resolution for Windows NT RAS servers and clients on TCP/IP networks. If you are not using a Windows NT RAS server, consult your RAS server's documentation for information about assigning IP addresses and name resolution for clients.

For information about implementing the Microsoft TCP/IP protocol in a network, see the Windows NT Server TCP/IP manual.

Assigning IP Addresses to RAS Clients

In Windows NT, each remote computer connecting to a RAS server through PPP on a Microsoft TCP/IP network is automatically provided an IP address from a static range assigned to the RAS server by the administrator during setup.

Windows NT RAS clients can also use a preassigned IP address specified in their Phone Book, if this is required for some reason, such as a server application expecting a user at a particular address. The Windows NT RAS server must be configured to permit users to request a specific address.

Name Resolution for RAS Servers and Clients

In addition to requiring an IP address, RAS servers and clients on a TCP/IP network may require a mechanism to map computer names to IP addresses. Four name resolution options are available on a Windows NT network: Windows Internet Name Service (WINS), broadcast name registration, Domain Name System (DNS), and the HOSTS and LMHOSTS files.

RAS servers can use all these name resolution methods for operations performed on the server.

RAS clients are assigned same the WINS and DNS servers that are assigned to the RAS server. You must use the Registry if you want to override this automatic assignment. For more information about overriding the automatic assignment of WINS and DNS servers, see Appendix C, "Modifying Parameters."

RAS clients in small networks where IP addresses do not change can use a HOSTS or LMHOSTS file for name resolution. Using these files on the local drive saves transmitting name resolution requests to a WINS server and waiting for the response over the modem.

Note

Standard broadcast name resolution does not work over RAS. Users must have a name resolution method, such as WINS or an LMHOSTS file, or they must use IP addresses.

For information about name resolution on a Microsoft TCP/IP network, see the Windows NT Server TCP/IP manual.

Connecting to Third-party Remote Access Servers Using IP

The Windows NT RAS server enables remote clients to share the same subnet address as computers on the LAN. By enabling remote access clients to share the same subnet address with the LAN, Windows NT RAS servers conserve IP addresses.

Other vendors' remote access servers may require that remote clients have a different subnet address than clients on the LAN. If your remote clients are dialing into another vendor's remote access server and cannot connect to resources on the LAN, check the following configuration on your remote access server.

If your remote access server does not support proxy-ARP (Address Resolution Protocol), then your remote clients must be assigned a different subnet address than LAN clients. Ensure your server has been configured to assign remote clients with a subnet address that is unique on your LAN.

Ensure that your network routers are configured so that remote access clients can use ping on target hosts, and vice versa. Use ping in the following order:

1.	Remote client to target server, then remote client to remote access server, then remote access server to target server.

2.	Target server to remote client, then target server to remote access server, then remote access server to remote client.

For more information on TCP/IP addressing, see the Windows NT Server TCP/IP manual.

SLIP on TCP/IP Networks

Support for Serial Line Internet Protocol (SLIP) allows Windows NT RAS clients to connect to third-party remote access servers that use the SLIP remote communication standard. Clients can use SLIP only if the port for the Phone Book entry is a serial COM port.

When a user connects to a SLIP server, a Windows Terminal dialog box pops up for an interactive logon session with the UNIX SLIP server. The UNIX logon overrides and prevents the RAS logon from appearing. Once a connection is established, remote network access becomes transparent to the user.

For a list of SLIP servers supported by Windows NT RAS, see the Hardware Compatibility List. For more information about installing and configuring RAS with TCP/IP, see Chapter 2, "Installing and Configuring Remote Access Service."

IPX and RAS

IPX is the native NetWare protocol, used on many Novell networks. IPX is a routing protocol, making it suitable for enterprise-wide networks. This section explains how to integrate Windows NT RAS clients and servers into a NetWare IPX network.

Windows NT Support for NetWare

If Windows NT RAS computers must see a Novell NetWare network, the computer must run a NetWare redirector. (In Windows NT Workstation computers this is called the Client Service for NetWare and in Windows NT Server computers this is called the Gateway Service for NetWare.)

A Windows NT RAS server is also an IPX router and Service Advertising Protocol (SAP) agent for RAS clients only. RAS servers and their clients use the PPP IPX Configuration Protocol (IPXCP) defined in RFC 1552 to configure the remote access line for IPX. Once configured, RAS servers enable file and print services and the use of Windows Sockets applications over IPX on the NetWare network for RAS clients.

RAS servers provide clients connecting to an IPX network with an IPX net number and act as their SAP agent. The following section explains the addressing options available for Windows NT RAS using the IPX protocol.

For information about installing the connectivity services on a NetWare/Windows NT interconnected network, see the Windows NT Server Services for NetWare Networks manual.

IPX Addressing for Remote Clients

RAS clients are always provided an IPX address by the RAS server. The IPX net number is either generated automatically by the RAS server or a static pool of net numbers is given to the RAS server for assignment to RAS clients.

For automatically generated IPX net numbers, the Windows NT RAS server uses the NetWare Router Information Protocol (RIP) to determine an IPX net number that is not in use in the IPX network. The RAS server assigns that number to the remote client.

You can override the automatic assignments of net numbers. Manual assignments can be useful if you want more control of net number assignments for security or monitoring. When assigning IPX net numbers to a RAS server, ensure that duplicate net numbers are not assigned and that other NetWare services cannot assign the RAS IPX addresses. You can also assign the same network number to all clients to minimize RIP announcements from the RAS server.

For information about IPX addressing, see Windows NT Server Services for NetWare Networks.

NetBEUI and RAS

NetBEUI is suited for use in small worgroups or LANs. A NetBIOS gateway and the NetBEUI client protocol are installed by default on all Windows NT RAS servers and most Windows networking clients. Previous Windows NT RAS clients, LAN Manager RAS clients, MS-DOS RAS clients, and Windows for Worgroups RAS clients require NetBEUI.


Installing and Configuring Remote Access Service
Chapter 2	1 of 10

Installing and Configuring Remote Access Service

This chapter describes how to install Windows NT Remote Access Service (RAS) on your computer and how to configure the service to work in your network.

RAS can be installed during Custom Setup or after the initial Windows NT Setup is finished. During Express Setup, if there is not a network card in a computer, the user is given the option to install RAS. This section assumes that Windows NT has already been successfully installed on your computer.

You must be logged on as a member of the Administrators group to install and configure RAS.


Hardware Requirements for RAS
Installing and Configuring Remote Access Service	2 of 10

Hardware Requirements for RAS

Before you install RAS, all hardware should be installed and working. Depending on your network and requirements, you may need the following hardware:

Network adapter card with a certified Network Driver Interface Specification (NDIS) driver

One or more compatible modems (see the Hardware Compatibility List or the Remote Access Setup program)

Multiport adapter card, for acceptable performance with multiple remote connections

X.25 smart card, if using an X.25 network

ISDN card, if using an ISDN line

See the Hardware Compatibility List to verify the compatibility of all hardware in a Windows NT computer.


Installing Remote Access Software
Installing and Configuring Remote Access Service	3 of 10

Installing Remote Access Software

RAS installation will vary slightly depending on the network protocols you have installed. If you will use the TCP/IP or IPX protocol with RAS, you should install the protocol before you install RAS, although selecting a protocol that is not installed will cause that protocol to be installed at the conclusion of RAS Setup. For information about installing either protocol, see the Windows NT Server Installation Guide.

To add the Remote Access software

1.	In Control Panel, choose the Network option.

2.	In the Network Settings dialog box, choose the Add Software button.

3.	From the Network Software drop-down list, select Remote Access Service and then choose the Continue button.

When prompted for the path to the distribution files, provide the path and choose the OK button. The RAS files will be copied to your computer.

4.	In the Add Port dialog box, you will see a list of all ports available to Windows NT for RAS. If you have successfully installed a multiport adapter, ISDN card, X.25 card, or other device, you should see it in this list.

Select the port you will use for remote access and choose the OK button.

5.	Remote Access Setup will offer to automatically detect the modem connected to the selected port. Choose Cancel to manually select a modem or choose the OK button to automatically detect the modem. A dialog box will appear announcing the modem detected. Choose the OK button.

Occasionally, when attempting to detect a modem, Remote Access Setup may present a dialog box requiring you to select your modem from a short list of possible modems. This occurs only when Remote Access Setup cannot distinguish between two or more modems.

6.	In the Configure Port dialog box, the modem detected will be highlighted.

If RAS did not detect your modem, or if you chose to manually select the modem, select the device attached to the port from the list. Only supported modems are listed. If you are adding a port after initial RAS installation, you can use the Detect button to automatically detect the modem connected to the new port.

7.	In the Port Usage box, choose how the port is to be used.

Dial Out Only means the computer will be a RAS client only. Receive Calls Only means the computer will be a RAS server only. Dial Out And Receive Calls means the computer can be a client or server, however, the computer cannot do both at the same time.

8.	To configure information specific to the type of device attached to the port, select the device and choose the Settings button. The default settings are usually ideal. Choose the OK button.

9.	In the Remote Access Setup dialog box, configure RAS network-wide settings by choosing the Network button (see the following section, "Configuring RAS to Use LAN Protocols"). You can also configure or reconfigure the ports as desired by highlighting the desired port and using the buttons along the bottom of the port box.

Consult the following table for a description of each button's use. Default settings are usually ideal.

Option	Use to
Add	Make a port available to RAS.
Remove	Make a port unavailable to RAS.
Configure	Change the Remote Access settings for the port, such as the attached device or the intended usage (dialing out only, receiving calls only, or both).
Clone	Copy the same modem setup from one port to another.
Continue	Proceed to the next step in Setup when you finish with this dialog box.
Cancel	Leave the Setup program.
Network	Configure RAS server-wide settings. Set network access to entire network or RAS computer only. Select and configure network protocols the RAS server will support. Select network protocols the computer will use for dial out (client) connections. Set authentication and data encryption options.
Disable Automatic Restoration Of Network Connections At Logon	Clear this check box to restore your previous network connections when you log on to your computer. This box is checked by default because restoring connections over a remote link can be especially time consuming.
10.	Choose the Continue button when you are finished setting up the port and network configurations.

RAS Server Configuration dialog boxes will appear for the protocols installed on your computer. See the appropriate sections below for configuring LAN protocols for RAS use.

Remote Access Setup configures RAS, creates a Remote Access Service program group, and then confirms that installation was successful.

11.	Choose the OK button in the confirmation dialog box, and choose the OK button in the Network Settings dialog box.

You may be prompted to confirm network protocol or other settings.

12.	You must restart your computer for the Remote Access installation and configuration take effect.

When you return to Program Manager, you will see a new group called Remote Access Service.


Configuring RAS to Use LAN Protocols
Installing and Configuring Remote Access Service	4 of 10

Configuring RAS to Use LAN Protocols

Since RAS provides access to a LAN, you must select and configure the protocols to use on the LAN. The RAS computer may access a LAN as a client or as a server. You must configure the LAN protocols RAS will use in each role.

A RAS computer's role is determined when you specify how RAS-enabled ports will be used. Setting a port to Dial Out Only means the computer will be a RAS client only. Setting a port to Receive Calls Only means the computer will be a RAS server only. Setting a port to Dial Out And Receive Calls means the computer can be a client or a server.

Network LAN protocol settings apply to all RAS operations for all RAS-enabled ports.

To configure RAS to use LAN protocols

1.	In Control Panel, choose the Network option.

2.	In the Network Settings dialog box, select Remote Access Service in the Installed Network Software box and choose the Configure button.

3.	In the Remote Access Setup dialog box, choose the Network button.

4.	In the Network Configuration dialog box, select the protocols to use for dialing out in the Dial Out Protocols box.

The Dial Out Protocols box sets the protocols used when this computer dials out as a RAS client to another computer. If you do not select a protocol in the Dial Out Protocols box, you will be unable to select that protocol later when you configure a phone book entry for dialing out.

If no ports are configured for dial out, The Dial Out Protocols box will be dimmed.

5.	Select the protocols to use for receiving calls in the Server Settings box.

The Server Settings box sets the LAN protocols the RAS computer can use for servicing remote clients.

You must also configure parameters for each protocol the RAS server will support. See the appropriate section below to configure the RAS server for each protocol.

If no ports are configured to receive calls, the Server Settings box will not appear in the Network Configuration dialog box.

6.	Select an encryption option.

Require Any Authentication Including Clear Text permits connection using any authentication requested by the client (MS-CHAP, MD5-CHAP, SPAP, PAP). This option is useful if you have different RAS clients. Require Encrypted Authentication permits connection using any authentication requested by the client except PAP. Require Microsoft Encrypted Authentication permits connection using MS-CHAP authentication only. Require Data Encryption means all data sent over the wire is encrypted.

7.	When you are finished selecting protocols, choose the OK button. In the Remote Access Setup dialog box, choose the Continue button to exit Remote Access Setup.

8.	You must restart your computer for the changes to take effect.


Configuring a RAS Server to Use NetBEUI
Installing and Configuring Remote Access Service	5 of 10

Configuring RAS to Use LAN Protocols

Configuring a RAS Server to Use NetBEUI

Remote Access Setup enables NetBEUI and the NetBIOS gateway by default. You can configure whether NetBEUI clients can access the entire network or the RAS computer only.

To configure a RAS server to use NetBEUI for network connections

1.	In Control Panel, choose the Network option.

2.	In the Installed Network Software box, select Remote Access Service and choose the Configure button.

3.	In the Remote Access Setup dialog box, choose the Network button.

4.	In the Network Configuration dialog box, the NetBEUI check box is selected unless the NetBEUI protocol has been removed from the computer. Choose the Configure button.

5.	In the RAS Server NetBEUI Configuration dialog box, select whether to allow NetBEUI clients to access the entire network or the RAS computer only.

6.	Choose the OK button. In the Network Configuration dialog box, choose the OK button.

7.	In the Remote Access Setup dialog box, complete any other port configurations, as described earlier, and then choose the Continue button.

8.	You must restart your computer for the changes to take effect.


Configuring a RAS Server to Use TCP/IP
Installing and Configuring Remote Access Service	6 of 10

Configuring RAS to Use LAN Protocols

Configuring a RAS Server to Use TCP/IP

You use the Network icon in Control Panel to configure or reconfigure the TCP/IP settings for RAS connections.

The RAS server has two TCP/IP configurations:

Its own basic configuration and IP address as a server on the LAN. For information on this configuration, see the TCP/IP Help file.

Its RAS configuration to supply IP addresses to RAS clients.

This section explains how to configure RAS to supply IP addresses to RAS clients.

To configure a RAS server to use TCP/IP for network connections

1.	In Control Panel, choose the Network option.

2.	In the Installed Network Software box, select Remote Access Service and choose the Configure button.

3.	In the Remote Access Setup dialog box, choose the Network button.

4.	In the Network Configuration dialog box, the TCP/IP check box is selected if TCP/IP is installed. Choose the Configure button.

5.	In the RAS Server TCP/IP Configuration dialog box, select whether to allow TCP/IP clients to access the entire network or the RAS computer only.

6.	In the Remote TCP/IP Client Address Pool box, type the Begin and End IP addresses from the range allocated for RAS clients.

These values should be entered in dotted decimal notation (for example, 110.11.0.0). These numbers should be assigned by the network administrator.

7.	To define excluded addresses within the IP address pool range, use the Excluded Range controls, as follows:

Type the first IP address that is part of the excluded range in the From box, and type the last number in the To box. Then choose the Add button. Continue to define any other excluded ranges in the same way.

To exclude a single IP address, type the number in the From and To box and then choose the Add button.

To remove an IP address range from the excluded range, select the range in the Excluded Ranges box, and then choose the Remove button.

8.	To allow remote workstations to request a predetermined IP address, select that option's check box.

9.	Choose the OK button, and in the Network Configuration dialog box, choose the OK button.

10.	In the Remote Access Setup dialog box, complete any other port configurations, as described earlier, and then choose the Continue button.

11.	You must restart your computer for the changes to take effect.

Configuring Name Resolution for RAS Clients

RAS client name resolution is based on the services available on the network and the RAS server configuration.

If the RAS server is configured to use a WINS server and a DNS server on the network, RAS clients will use that WINS server and DNS server. If the RAS server has more than one network adapter card, the clients will use the WINS servers on the first network configured for INS and DNS.

RAS clients in small networks where IP addresses do not change can use a HOST file and LMHOSTS file for name resolution. Using these files on the local drive saves transmitting the name resolution request to the WINS server and waiting for a response over the modem.

Note

Standard broadcast name resolution does not work over RAS. Users must have a name resolution method, such as WINS or a LMHOSTS file, or they must use IP addresses.

For more information about name resolution on a Microsoft TCP/IP network, see Chapter 3, "Networking Concepts for TCP/IP," in the Windows NT Server TCP/IP manual.

Configuring Remote Access Entries for TCP/IP

RAS clients can use the Remote Access application to enter and maintain names and telephone numbers of remote networks. Clients connect to and disconnect from these networks using the Remote Access program. RAS users can select the network protocols to use for a specific Phone Book entry. If TCP/IP is installed, the Phone Book will automatically select TCP/IP using PPP. To change the TCP/IP configuration, use the following procedure.

To configure a RAS Phone Book entry for TCP/IP

1.	In the Remote Access Phone Book, select an entry and then choose the Edit button.

You can also follow this same procedure if you choose the Add or Clone button.

2.	In the Edit Phone Book Entry dialog box, choose the Network button. If the Network button is not visible, choose the Advanced button, and then choose the Network button.

3.	In the Network Protocol Settings dialog box, choose the TCP/IP Settings button.

When the COM port is an ISDN port, a message warns you this option is available only for a serial/modem port. If the current computer does not have a serial COM port, the SLIP option is not available.

4.	In the PPP TCP/IP Settings dialog box, select Server Assigned IP Address or select Require Specific IP Address and provide the IP address you want to use when connecting to the RAS server. You can also select the Use Default Gateway On Remote Network, if you require access to resources available through the default gateway. Choose the OK button.

5.	In the Network Protocol Settings dialog box, choose the OK button. In the Edit Phone Book Entry dialog box, complete any remaining configuration tasks, and then choose the OK button.

The TCP/IP settings for RAS are available the next time you dial.

If you dial in for a connection and the selected Phone Book entry is using SLIP, Terminal will appear. Also, the Remote Access Phone Book bypasses user authentication for connections using SLIP. You will not be asked for a user name and password.


Configuring a RAS Server to Use IPX
Installing and Configuring Remote Access Service	7 of 10

Configuring RAS to Use LAN Protocols

Configuring a RAS Server to Use IPX

You configure or reconfigure the IPX settings for RAS connections using the Network icon in Control Panel.

To configure a RAS server to use IPX for network connections

1.	In Control Panel, choose the Network option.

2.	In the Installed Network Software box, select Remote Access Service and choose the Configure button.

3.	In the Remote Access Setup dialog box, choose the Network button.

4.	In the Network Configuration dialog box, the IPX check box is selected if IPX is installed. Choose the Configure button.

5.	In the RAS Server IPX Configuration dialog box, select whether to allow IPX clients to access the entire network or the RAS server only, and then select a method for allocating IPX network numbers:

Allocate Network Numbers Automatically. The Windows NT RAS software uses the NetWare Router Information Protocol (RIP) to determine an IPX network number that is not in use in the IPX network. The RAS server assigns that number to the remote client.

Allocate Network Numbers (manual override). Manual assignments can be useful if you want more control of network number assignments for security or monitoring purposes.

If you choose to allocate network numbers manually, type the first network number in the From box. RAS automatically determines the number of available ports and inserts the ending network number for you.

You can also assign the same network number to all IPX client using either the automatic or the standard allocation method. Select the Assign Same Network Number To All IPX Clients check box.

6.	Choose the OK button, and in the Network Configuration dialog box, choose the OK button.

7.	In the Remote Access Setup dialog box, complete any other port configurations, as described earlier, and then choose the Continue button.

8.	You must restart your computer for the changes to take effect.


Special Configurations
Installing and Configuring Remote Access Service	8 of 10

Configuring RAS to Use LAN Protocols

Special Configurations

This section contains information about configuring RAS in special situations and using specialized hardware.

Configuring Stand-alone Remote Servers to Appear to Local Network Browsers

Users who set up a RAS server at home and dial into that server from a RAS server at work need to do the following in order for their home server's name to appear in the browsing list of remote clients that dial in.

To configure a remote RAS server to appear to local network browsers

1.	In Control Panel, choose the Network option.

2.	In the Networks Settings dialog box, choose the Change button next to the domain or workstation name. In the Rename Domain (or Workgroup) dialog box, type the new domain or workgroup name that matches the domain or workgroup name of the client dialing in. Choose the OK button.

3.	In the Networks Settings dialog box, choose the Add Adapter button. In the Add Network Adapter dialog box, choose the MS Loopback Adapter. Choose the Continue button.

4.	In the MS Loopback Adapter Card Setup dialog box, do not change the default frame type. RAS will work with the default. Choose the OK button, and then provide the path to the Windows NT distribution disk(s) and choose the OK button.

5.	In the Network Settings dialog box, choose OK and allow Windows NT to reboot your computer.

6.	After rebooting, configure the remote RAS server to allow access to the entire network, even though the computer may not be connected to a network.

This is described earlier in this chapter in the section "Configuring RAS to Use LAN Protocols." You will need to restart your computer, as described in that section.

Configuring Other Vendors' Dial-Up Servers for NetBIOS IP and IPX

If Windows NT clients dialing into other vendors' dial-up servers must access NetBIOS resources using IP and IPX, the dial-up servers must be configured to forward NetBIOS broadcast traffic. Forwarding this NetBIOS traffic may result in poor performance over the RAS connection if the LAN has a lot of NetBIOS activity. For information about configuring a server to forward NetBIOS broadcasts, see "IPXRouter Parameters" in Appendix C.

For better performance on TCP/IP networks, Windows NT clients can use WINS servers or proxies when dialing into other vendors' servers if the server can provide access to a Windows NT Server WINS server or proxy agent on the LAN. For more information, see TCPIP.HLP in the \systemroot\SYSTEM32 directory.


Granting Remote Access Permissions
Installing and Configuring Remote Access Service	9 of 10

Permissions

After installing Remote Access software on a server, you must grant Remote Access permissions to users before they try to connect through Remote Access client software. Without permission, users cannot successfully connect to the Remote Access computer even if the Remote Access client software has been installed on their computers.

To grant Remote Access permission to users

1.	Start the Administrator's utility by double-clicking the Remote Access Admin icon.

2.	Set the focus on the server or domain you want to set permissions for.

To set the focus, see the Remote Access Admin online Help.

3.	From the Users menu, choose Permissions.

The Remote Access Permissions dialog box appears. For further instructions, click the Help button on the dialog box.

Note

Microsoft does not recommend granting guest accounts dial-in permission. If you do, be sure to assign a password to the guest account.


ISDN Wide-Area Network Installation
Installing and Configuring Remote Access Service	10 of 10

ISDN Wide-Area Network Installation

ISDN offers a much faster communication speed than the telephone line. The phone line communicates typically at 9600 bits per second (bps), whereas ISDN communicates at speeds of 64 or 128 kilobits per second. Businesses that need this kind of speed usually have a large telecommuting work force or need to do extensive administrative tasks remotely, such as installing software on off-site workstations.

An ISDN line comes with two B channels and one D channel. Each B channel transmits data at 64 kilobits per second. The D channel is for signaling and transmits data at 16 kilobits per second.

Install ISDN cards on the server and on each client. (For instructions, see the card's documentation.) Then configure the B channels to each act as a port or to act together as a single port.

If your business has a large number of people calling in to the Remote Access server, configure each channel to operate as a port. Clients will be able to get higher throughputs by requesting channel aggregation at connection time. This feature is a dynamic and more efficient way of allocating ISDN resources.

However, you can also statically assign a higher bandwidth by configuring both channels to act as a single port. With this configuration, line speed increases to 128 kilobits per second.

To configure the ISDN card to work with RAS, see RAS online Help.


Choosing and Configuring Modems
Chapter 3	1 of 7

Choosing and Configuring Modems

This chapter contains the following:

Advice about choosing a modem that is compatible with the Remote Access Service

Instructions for reconfiguring Remote Access to work with modems other than those listed in the Hardware Compatibility List


Choosing Modems
Choosing and Configuring Modems	2 of 7

Choosing Modems

To make sure that your modems work with the Remote Access Service, select them from the list of supported modems in the Hardware Compatibility List. Microsoft has tested and verified these modems with the Remote Access Service.

Note

Many problems arise from modem incompatibilities. To ensure compatibility, have clients use the same kind of modems as the server's modem. Getting the same kind is less critical if you choose modems that conform to industry standards, but still it is safer to choose the same model for both clients and server.


Supported Modems
Choosing and Configuring Modems	3 of 7

Choosing Modems

Supported Modems

Modems that Remote Access supports do not necessarily work in all modes with other modems in the list. For example, the Hayes® V-Series 9600 modem connects at 9600 bits per second (bps) only with another Hayes V-Series 9600 modem. So if you install this modem on a Remote Access server, make sure that Remote Access clients also have Hayes V-Series 9600 modems. Otherwise, connections will probably be made at 2400 bps.

If you are using one of the modems named in the Hardware Compatibility List when you set up Remote Access and cannot connect, follow these steps.

To troubleshoot a supported modem

1.	Make sure your cabling is correct (see Appendix D, "Cabling").

2.	If you still cannot connect, check the modem's documentation to verify that the modem has been correctly installed.

3.	If it has been correctly installed, use a terminal emulator program, such as Windows NT Terminal, to see if you can issue commands to the modem.

4.	Turn on device logging.

For more information, see Chapter 5, "Maintenance and Troubleshooting."


Unsupported Modems
Choosing and Configuring Modems	4 of 7

Choosing Modems

Unsupported Modems

Modems other than those supported by Microsoft may also work with the Remote Access Service, even though they have not yet been tested with the software. If you choose unsupported modems, for best results make sure they conform to the following industry standards established by the Consultative Committee on Telephone and Telegraph (CCITT).

Table 3.1    Industry Standards for Modems

Speed in bits per second (bps)	CCITT standard
1200	V.22 or Bell 212A
2400	V.22bis
9600	V.32
14,400	V.32bis
28,800	V.34
For details about industry standard protocols, see the glossary in online Help.

When configuring an unsupported modem for the Remote Access Service, you will have to select from the list of supported modems a modem that matches yours as closely as possible. For best results, make your choice by first comparing entries in the MODEM.INF file with commands for your modem. You can find these commands in your modem's documentation.

To configure an unsupported modem

1.	In Control Panel, double-click the Network option.

2.	In the Installed Network Software box on the Network Settings dialog box, select Remote Access Service.

3.	Choose the Configure button.

4.	In the Remote Access Setup dialog box, select the port you want to configure for the unsupported modem, and choose the Configure button.

5.	From the list of modems, select the modem that is as similar to your modem as possible.

6.	Choose the OK button, and then choose the Continue button.

7.	In the Network Settings dialog box, choose the OK button.

8.	If you configure a new port for the unsupported modem, restart your computer.

If you reconfigure a port already in use, you don't need to restart your computer, but you do need to stop and then restart the Remote Access Service.

If you have trouble connecting through an unsupported modem, test the modem's compatibility.

To test a modem's compatibility

1.	Check the modem's documentation to make sure you have installed and configured the modem correctly.

2.	Make sure that your modem is connected to a serial communication (COM) port on your computer and that your software is set for the same port.

3.	Turn on your modem.

4.	Check to see if the modem works properly with Windows NT Terminal.

For instructions, see the following procedure.

If the test works, you can assume the modem is not malfunctioning.

5.	If the modem still does not work after you have verified that it works with Windows NT Terminal, contact your modem's manufacturer and request a modem command file compatible with the Remote Access Service MODEM.INF file.

For information about creating a correct modem command file, see "Adding a New Modem to MODEM.INF" in Appendix E, "Understanding MODEM.INF."

To test a modem with Windows NT Terminal

1.	From the Accessories group, double-click the Terminal icon.

2.	In Terminal, select Settings.

3.	From the Settings menu, choose Communications.

4.	In the Communications dialog box, select the bps at which your modem sends and receives data, and select the COM port your modem is connected to. Choose the OK button.

5.	In Terminal, type at and press ENTER.

Your modem should return OK, which is echoed on the dialog box. Some modems return 0, depending on their result code settings.

6.	If your modem won't work through Terminal, call the modem's manufacturer.


Compatibility and Speed
Choosing and Configuring Modems	5 of 7

Choosing Modems

Compatibility and Speed

Modems from different manufacturers, and even different models from the same manufacturer, may not be completely compatible in all settings and circumstances. Even modems that claim to follow the Hayes AT command set may not be able to communicate with other Hayes-compatible modems under every circumstance.

High-speed modems may perform their own error-correction and data compression, which you can take advantage of by setting modem features during setup on a server or through the Phone Book on a client.

Compatibility problems increase when you begin to consider high-speed modems of 9600 bps or above because some modems achieve high speeds in different ways. Even modems that follow the same standards for compression and error correction may be unable to communicate with each other at 9600 bps and therefore may fall back to 2400 bps. So, if you buy 9600-bps modems from different manufacturers to benefit from high data-exchange rates, you may be disappointed.

If you plan to connect more than one type of modem to a server, you can assign a different telephone number to each modem. That way, users can choose exactly which modem to connect to. The disadvantage is that users may have to dial several different modems before finding one that is not in use.

Note

For rates of 12,000 bps and higher, modem manufacturers often require that computer-to-modem communication occur at 19,200 bps. For this reason, the Remote Access software assumes that modems able to connect at 12,000 or 14,400 bps can function at the computer-to-modem speeds of 19,200 bps or faster. Virtually all high-speed modems can do so.


Direct Serial Connections
Choosing and Configuring Modems	6 of 7

Direct Serial Connections

You can select a null modem to establish a direct serial connection between two computers. Although a direct serial connection eliminates the need for a network adapter card, it is a slow link and password authentication is still required. A null modem configuration works best only for computers physically near each other.

To configure your system for a direct serial connection

Select a null modem from the list of modems during setup when configuring the COM ports for a serial connection.

A null modem must be configured on both the client and the server.

For information about configuring COM ports, see "Installing Remote Access Software" in Chapter 2, "Installing and Configuring Remote Access Service."

Important

For information about cabling required for null modems, see Appendix D, "Cabling."


Modem-Pooling Equipment
Choosing and Configuring Modems	7 of 7

Modem-Pooling Equipment

To configure a server to work with modem-pooling equipment

1.	Configure the equipment to behave like one of the modem types listed in the Setup program.

In other words, the modem-pooling equipment must generate and accept command strings as if it were a modem of the chosen type. The switching equipment must also have the same RS-232 signal behavior as the specified modem.

2.	Connect COM ports to this equipment and specify the modem type in the Remote Access Setup program.

Microsoft suggests that the equipment be configured as a Hayes-compatible modem, a widely known standard.


Security
Chapter 4	1 of 7

Security

This chapter describes network security for the Remote Access Service and how it works with the security model for Windows NT Server.


Security Features
Security	2 of 7

Security Features

Domain-based security

Remote Access servers participating in the same domain have identical copies of the user account database, ensuring easy administration and identical security restrictions for all access points to the network.

Remote Access permission

To connect to the network through Remote Access, a user must have a valid Windows NT Server user account that has been given Remote Access permission. You can grant or revoke Remote Access permissions as needed in Remote Access Admin.

Remote Access authentication

Remote users must be authenticated by a Remote Access server before they can access or generate traffic on the network. This authentication is a separate step from logging on to Windows NT Server. User passwords and the authentication procedure are encrypted when transmitted over phone lines.

Callback security

You can configure individual user accounts so that the Remote Access server calls the user back at a preset number before allowing access to the network.

Support for security hosts

You can add another level of security to your Remote Access configuration by connecting an intermediary security host between remote clients and the server. For details, see Chapter 7, "Support for Security Hosts and Switches."

Auditing

The Remote Access Service generates audit trails of remote connections. With this feature, you can audit all Remote Access activity. For more information about audits, see Chapter 5, "Maintenance and Troubleshooting."

Disconnecting users

Through Remote Access Admin, you can disconnect users without shutting down the Remote Access Service or interrupting authorized users.

Restricted network access

To restrict access to specific network resources, you can make all or specified networks or protocols unavailable to remote clients.

Data encryption

Data can be encrypted, maintaining security during unauthorized interception of remote access transmissions.


Security for Windows NT Server and Remote Access
Security	3 of 7

Security for Windows NT Server and Remote Access

This section describes restricting remote users' access to the network and to the Remote Access server.


Restricting Access to the Network
Security	4 of 7

Security for Windows NT Server and Remote Access

Restricting Access to the Network

Using the Windows NT Control Panel, you can:

Restrict remote users to specific parts of the network.

Restrict remote users to resources on the Remote Access server.

Allow remote users to see and access the network.

Restricting Users to the Dial-In Server

Although the Remote Access server may be connnected to a network, you can restrict remote users to the server they dial in to, making the network unavailable to them. See Figure 4.1

Figure 4.1 Remote Users Restricted to the Dial-In Server

Allowing Users to Access the Network

You can let remote users see and access all or part of the network by enabling or disabling sets of protocols and adapters called bindings. Figure 4.2 shows a configuration with two bindings that allow remote users to see and access all connections in the Remote Access gateway:

TCP/IP and Adapter 1

NetBEUI and Adapter 2

Figure 4.2 Remote Users Allowed Access to the Network

Restricting Users to a Part of the Network

Through the Windows NT Control Panel, you can disable some of the bindings, making specific paths unavailable to remote users. This feature lets you limit remote users' access to only the server(s) they need.

For information about disabling bindings, see the Windows NT Server System Guide.


How Security Works at Connection Time
Security	5 of 7

How Security Works at Connection Time

The following list shows how a remote user accesses resources on the network:

1.	Through the Remote Access Phone Book, a client dials a Remote Access server.

2.	The server sends a challenge to the client.

3.	The client sends an encrypted response to the server.

4.	The server checks the response against the user database.

5.	If the account is valid, the server checks for Remote Access permission.

6.	If Remote Access permission has been granted, the server connects the client.

If callback is enabled, the server calls the client back and repeats steps 2–6.

Note

When using RAS in a domain environment, changes in Remote Access permission do not take effect immediately on all servers. It can take up to 15 minutes for replication of the change to other servers in the domain. If necessary, you can resynchronize the domain to ensure that a user with revoked permissions cannot gain access to the network before the change is automatically replicated.


Configuring Callback
Security	6 of 7

How Security Works at Connection Time

Configuring Callback

When a user connects to a server from a client configured for callback, the server calls the user either at a preset number or at a number supplied by the user at connection time. You can configure each user's callback privilege when you grant him or her Remote Access permission. (For information about granting permission, see Chapter 2, "Installing and Configuring Remote Access Service," and online help for the Administrator's utility.)

In Remote Access Admin, the Remote Access Permissions dialog box contains three callback options:

Preset To

Set By Caller

No Callback (the default)

Choose one of these options to set up a user's callback privilege. The default is No Callback.

Note

Until the user has been authenticated and called back (if Callback is set), no data from the remote client or the Remote Access server is transferred.

To change a user's callback option

1.	Start Remote Access Admin.

2.	From the Users menu, choose Permissions.

3.	Select a user.

4.	Assign a different callback option.

Preset To

Select Preset To for maximum security, and type the number of the phone to which the user's modem is connected. When the user's call reaches the Remote Access server, the server takes the following steps:

1.	Determines whether the user name and password are correct.

2.	If they are, responds with a message announcing that the user will be called back.

3.	Disconnects and calls the user back at the preset number.

Set this option for stationary remote computers, such as those in home offices.

Set By Caller

This option is for the convenience of a remote user who calls from various places. It is not a security feature. Select Set By Caller for clients that call from various locations and different phone numbers. When the user's call reaches the Remote Access server, the following steps occur:

1.	The server first determines if the user name and password are correct.

2.	If they are, the Callback dialog box appears on the user's computer.

3.	The user types the current callback number in the dialog box and waits for the server to return the call.

Set this option to minimize telephone charges for anyone calling in from various locations, such as field representatives.

No Callback

If the user account has not been configured for callback, the Remote Access Service establishes a connection as soon as the user's name and password is authenticated.


Network Access Permission
Security	7 of 7

How Security Works at Connection Time

Network Access Permission

After passing Remote Access authentication and connecting to the LAN, users can access resources on the application server for which they have permission. For example, they can:

Do anything on the network for which they have sufficient privilege.

Use any network resource for which they have permission such as:

Use the File Manager to access files on the LAN server.

Access client-server applications such as electronic mail or SQL Server.

Remote users are also subject to Windows NT Server security, just as they are at the office. In other words, they cannot do anything for which they lack sufficient privilege, nor can they access resources for which they do not have permission.

Note

Remote Access authentication does not negate security restrictions on the file or application server.

For information about adding a remote client to a domain, see Remote Access online Help, Control Panel Help, and Chapter 15, "Server Manager," in the Windows NT Server System Guide.


Maintenance and Troubleshooting
Chapter 5	1 of 5

Maintenance and Troubleshooting

Once you have installed the Remote Access Service, routine maintenance consists of the following tasks:

Monitoring servers and users systematically.

Reviewing the Windows NT Server Event Viewer regularly to see whether network security is intact. (See "Troubleshooting" and "Audits" later in this chapter. For complete information about using Event Viewer, see the Windows NT Server System Guide.)

By conveying real-time information about users, ports, modems, and data transmissions, the Remote Access Administrator's utility simplifies monitoring servers and users and gives valuable clues to assist in troubleshooting. By having the utility running continuously, you can track activity on your Remote Access servers and respond promptly to problems with user accounts and hardware.

With the Remote Access Administrator's utility, you can look at a Remote Access Service domain in two ways:

The Remote Access servers in a domain.

This view of the domain lets you manage multiple Remote Access servers from a central location.

All the users who are connected to those servers.

This view lets you monitor user activity on all Remote Access servers in the domain.

Each time you start the utility, the default view is servers, and the Remote Access server(s) dialog box lists all the servers in the logon domain. You can set focus on a different domain, or you can focus on a single server in the current domain.


Troubleshooting
Maintenance and Troubleshooting	2 of 5

Troubleshooting

The Administrator's utility provides real-time information about active users and current connections and is therefore often the place to begin troubleshooting problems.

For example:

You may notice on the Remote Access server(s) dialog box that fewer than the expected number of ports are consistently in use on a server, suggesting that one or more of them may not be operating properly.

If users cannot make a connection, you can ask them to attempt to reconnect while you monitor their efforts in the Port Status dialog box.

When real-time data is insufficient to solve a problem, you can refer to the audit and error messages generated by Remote Access. The Windows NT Server Event Viewer records all the audits and error messages for Remote Access.

Events are classified into three main categories:

Event	Description

Audit	Normal behavior recorded for administration, for example, information about a connected client - user name, connection time, and current status.

Warning	An irregular or unexpected condition that doesn't affect the system's functionality.

Error	A major function fails or a network error occurs.

Audits are further divided into two categories:

Category of Audit	Example

Success audit	Client connects and disconnects normally.

Failure audit	Server disconnects a client that's been inactive too long, or a client tries to connect with the wrong password.


Audits
Maintenance and Troubleshooting	3 of 5

Troubleshooting

Audits

The Windows NT Server Event Viewer records activity on each Remote Access server. Because the audits recorded in the log are the best evidence of possible attempts to violate network security, be sure to review them regularly. For information about using Event Viewer, see the Windows NT Server System Guide.

To enable audits, make sure the EnableAudits parameter is set to the default value 1. For more information, see Appendix C, "Modifying Parameters." The Remote Access Service generates, among others, the following audit records.

Success Audits

Message		Explanation
The user username has connected and has been successfully authenticated on port portname.		This message signifies a normal connection by a certain user on a given port.
User username has disconnected from port portname.		This message records a successful disconnection initiated by the user.
The user domainname\username on port number was called back at the number callback number.		This records a successful callback to a user at the specified phone number.
Failure Audits

Message		Explanation
The user connected to port portname has been disconnected due to inactivity.		The line was idle for a period longer than configured using the AutoDisconnect parameter in the Registry.
The user has connected and failed to authenticate on port portname. The line has been disconnected.		The user supplied an incorrect username, password, or both. The number of failed authentications before access is denied and the line is dropped depends on the value of the AuthenticateRetries parameter in the Registry.
The user connected to port portname has been disconnected due to authentication timeout.		Authentication took longer than the value set for timing out. You may need to increase the value of the AuthenticateTime parameter. See "Remote Access Parameters" in Appendix C.
The user connected to port portname has been disconnected because there was a transport-level error during the authentication conversation.		Too many errors occurred during the authentication conversation, possibly because of noisy lines or incompatible modems. Ask the user to try connecting with a lower initial speed.
The user connected to port portname has been disconnected because it could not be projected onto the network.		Most likely the user's computer name already exists on the network. Ask the user to configure the remote computerwith a different computer name, or to make sure the computer isn't already connected to the network through another means, such as the Ethernet or token ring.
Note

If the Remote Access Service fails to start, check Event Viewer for a description of the error that occurred at the time you tried to start Remote Access. For information about using Event Viewer, see the Windows NT Server System Guide. Once you have found the error, look it up in the error messages in Windows NT Server Messages, and take the recommended corrective action.


Client Problems
Maintenance and Troubleshooting	4 of 5

Troubleshooting

Client Problems

Because client problems usually stem from improper hardware or software configuration on the computer, first check the error message and audit logs for clues. If this doesn't help, see "Answers to Common Questions" in the Remote Access online Help.


RAS-Specific Logs
Maintenance and Troubleshooting	5 of 5

Troubleshooting

RAS-Specific Logs

You can enable two RAS-specific logs, the PPP log and the device log, by changing parameters in the Registry. These logs are text files and can be viewed in any text editor or at the command prompt. The logs cannot be viewed using Event Viewer.

When enabled, the PPP log records all PPP events in the file \systemroot\SYSTEM32\RAS\PPP.LOG. This parameter is useful to determine problems with PPP connections. To enable the PPP log, you must change the Logging parameter to 1 in

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasMan\PPP

When enabled, the device log is created in the file \systemroot\SYSTEM32\RAS \DEVICE.LOG. The device log records all communication from serial ports to the device connected to them during command mode. Logging stops after successful connection to the device and data is transmitted. To enable the device log, you must change the Logging parameter to 1 in

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasMan\Parameters

For more information about enabling these logs, see Appendix C, "Modifying Parameters."


X.25 Support
Chapter 6	1 of 12

X.25 Support

An X.25 network transmits data with a packet-switching protocol. This protocol relies on an elaborate worldwide network of packet-forwarding nodes (DCEs) that can participate in delivering an X.25 packet to its designated address.

The Remote Access Service lets you access the X.25 network in two general ways:

Server/Client		Method of access
Client (for the Windows™ or Windows NT operating systems)		Asynchronous Packet Assemblers/Disassemblers (PADs)
Server and client (for Windows NT systems only)		Direct connections
The next section tells how to access the X.25 network in both ways for specific configurations.


X.25 Configurations
X.25 Support	2 of 12

X.25 Configurations

The Remote Access Service for X.25 networks offers two possible configurations for the client and one for the server:

Table 6.1    X.25 Configurations

Client/Server		Configuration
Client		Dial-up PAD
Client		Direct connection through X.25 smart card
Server		Direct connection through X.25 smart card


Accessing X.25 Through Dial-Up PADs
X.25 Support	3 of 12

X.25 Configurations

Accessing X.25 Through Dial-Up PADs

Operating between the client and the Remote Access server, an asynchronous PAD converts serially transmitted data into X.25 packets. When the PAD receives a packet from an X.25 network, it puts the packet out on a serial line, making communication possible between the client and the X.25 network.

Remote Access clients can connect with Remote Access servers through dial-up PAD services supplied by X.25 carriers, such as Sprintnet and Infonet. Once the client's modem (modem A in Figure 6.1) connects to the PAD's modem (modem B), the client software must converse with the dial-up PAD. When their conversation is successfully completed, a connection is established between client and server. The conversation (command/response scripts) for the PADs supported by an X.25 carrier is stored in the PAD.INF file. Remote Access software supplies one example. To customize for your PAD, see "PAD.INF Format," later in this chapter.

There are two Sprintnet entries in PAD.INF, Sprintnet Standard, and Sprintnet Alternate. Generally, if you are calling through 9600 bits per second (bps) or faster dial-up PADs, try Sprintnet Standard. If you are calling through 2400 bps or slower dial-up PADs, try Sprintnet Alternate.

If one Sprintnet entry fails to connect reliably, try the other one. Sprintnet dialup PADs should work with one or the other, but there is no rule for which one to choose.

Note

For dial-up PADs, you must use the COMMAND= format, not the COMMAND_INIT, COMMAND_DIAL, and COMMAND_LISTEN format.

Figure 6.1 shows how a client connects to the Remote Access server through a dial-up PAD and the X.25 network.

Figure 6.1    Connecting to the Server Through a Dial-Up PAD

Note

For best results when using a dial-up PAD, get the same modem that the PAD carrier has (or at least match the V. protocol supported by the carrier's modem).

Dial-up asynchronous PADs constitute a practical choice for Remote Access clients because they don't require an X.25 line plugged into the back of the computer. Their only requirement is the telephone number of the PAD service for the carrier.

The following table compares connecting through dial-up PADs and connecting directly:

Table 6.2    Comparison of Dial-Up PADs to Connecting Directly

Dial-Up PAD		Direct connection
Saves the expense of a dedicated leased line (direct connection).		Requires expensive leased line.
Allows connections from hotels, airports, homes-anywhere a phone line is available.		Requires users to dial in from a fixed location.
Requires two steps to connect.		Connects conveniently in one step.
Limits maximum communication speed to whichever speed is slower, the modem's or the PAD's.		Lets communication take place up to the speed of a leased line, 56 kilobytes (K).
Allows less control in configuring PADs.		Offers greater reliability.
Only a client can connect through a dial-up PAD.		Both servers and clients can connect directly.
PAD and Serial Configuration

To configure your PAD correctly, set the X.3 parameters according to Table 6.3 later in this chapter.

Also, configure dial-up PADs to the following serial communication settings:

8 data bits

1 stop bit

No parity serial communication

For dial-up PADs, make sure your vendor supports this configuration. The PADs may already be set to the correct configuration for connecting directly through an internal X.25 smart card. If so, do not change it.


Connecting to the X.25 Network Directly
X.25 Support	4 of 12

X.25 Configurations

Connecting to the X.25 Network Directly

The Remote Access Service also supports connecting directly from the remote computer to the X.25 network through a smart card, which acts like a modem. An X.25 smart card is a hardware card with a PAD embedded in it. To the personal computer, a smart card looks like several communication ports attached to PADs. Accessing the X.25 network through a direct connection has two requirements:

A direct line connection to an X.25 network (clients only)

A smart card

Note

The server side always requires an X.25 smart card, but the client side requires one only when connecting to the X.25 network directly.

Figure 6.2 shows how the server and a Windows NT client (both equipped with smart cards) connect to the X.25 network directly.

Figure 6.2    Connecting to X.25 Directly


Callback
X.25 Support	5 of 12

Callback

The Remote Access server does not support callback on X.25 networks.


Setting Up the Remote Access Server for an X.25 Network
X.25 Support	6 of 12

Setting Up the Remote Access Server for an X.25 Network

After installing Windows NT Server and adding the Remote Access Service, follow these steps.

To set up the Remote Access server for an X.25 network

1.	Install the X.25 smart card (according to the manufacturer's instructions).

A communications driver for the X.25 smart card supplied by the hardware manufacturer or a third party then emulates communication ports.

2.	Make sure your X.25 smart card is configured with the X.3-parameter values shown in Table 6.3.

Table 6.3    X.25 Configuration Values

Parameter number		X.3 parameter	Value
1		PAD Recall	0
2		Echo	0
3		Data Fwd. Char	0
4		Idle Timer	1
5		Device Ctrl	0
6		PAD Service Signals	1
7		Break Signal	0
8		Discard Output	0
9		Padding after CR	0
10		Line Folding	0
11		Not Set
12		Flow Control	0
13		Linefeed Insertion	0
14		Padding after LF	0
15		Editing	0
16		Character Delete	0
17		Line Delete	0
18		Line Display	0
19		Editing PAD Srv Signals	0
20		Echo Mask	0
21		Parity Treatment	0
22		Page Wait	0
Caution

Failure to set these values as shown prevents the Remote Access Service from functioning properly. For information on setting these values, see the instructions with your X.25 smart card.

3.	From the list of devices on the Remote Access Setup dialog box, select an entry corresponding to the X.25 smart card.

4.	In setting up the Remote Access server, make sure that the ports selected are configured for dial-in.

Note

Make sure that the speed of the leased line can support all the serial communication (COM) ports at all speeds at which clients will dial in. For example, 4 clients connecting at 9600 bps (through dial-up PADs) will require a 38,400-bps (4 times 9600) leased line on the server end. If the leased line does not have adequate bandwidth, it can cause time-outs and can cause the performance for connected clients to degrade.


Setting Up Remote Access Clients
X.25 Support	7 of 12

Setting Up Remote Access Clients

This section tells how to set up Remote Access clients for connecting to the X.25 network through PAD services and for connecting to the X.25 network directly.


Connecting Through Dial-Up PADs
X.25 Support	8 of 12

Setting Up Remote Access Clients

Connecting Through Dial-Up PADs

In general, a client connects to an X.25 network in two steps:

1.	Dial from the client's modem to a PAD (modem-to-modem).

2.	Establish a connection over the X.25 network between the PAD and the server-side X.25 smart card.

Once you've established a connection, communicate as you would through any asynchronous connection. For a more complete description of connecting through dial-up PADs, see "Accessing X.25 Through Dial-Up PADs," earlier in this chapter.

Configuring Client PADs

The client PAD, through which a remote computer connects to the X.25 network, may have previously been set to X.3-parameter values that are incompatible with the Remote Access Service. Therefore, it is very important to configure the X.25 smart card on the Remote Access server so that it changes the client PAD's X.3 settings to the values in Table 6.3 as soon as a connection is established through X.29 commands. To configure an X.25 smart card to make these changes, see the configuration manual for your specific card.

Note

If the X.25 smart card on the server end does not support commands for the X.29 language, the client PAD script must set the X.3 parameters locally. If you have problems, contact the support site for your X.25 smart card vendor.


Connecting Directly
X.25 Support	9 of 12

Setting Up Remote Access Clients

Connecting Directly

To set up the client for connecting directly to the X.25 network, follow the same procedures as you did in setting up the Remote Access server. See "Setting Up the Remote Access Server for an X.25 Network," earlier in this chapter. Make sure the communication ports are selected as dial-out.


Configuring Remote Access Software for X.25
X.25 Support	10 of 12

Configuring Remote Access Software for X.25

Connecting to a server through an X.25 network is similar to connecting through a phone line. The only difference is that the phone book entry must specify an X.25 PAD type and an X.121 address.

To add a phone book entry with X.25 or to add X.25 to an existing entry

See the Remote Access online Help. This online Help also provides troubleshooting information.


PAD.INF Format
X.25 Support	11 of 12

Configuring Remote Access Software for X.25

PAD.INF Format

Similar in format to MODEM.INF, PAD.INF contains the conversations between the client software and the PAD, whereas MODEM.INF contains script information used to talk to the modem. For details, see Appendix E, "Understanding MODEM.INF." You can find PAD.INF in the \systemroot\SYSTEM32\RAS subdirectory.

The macros in the following list are reserved words, which you cannot define in PAD.INF to create a new entry. Reserved words are case insensitive.

x25address

diagnostics

userdata

facilities

Caution

Using reserved words as macro names in PAD.INF could result in unpredictable behavior of the Remote Access software.

Sample PAD.INF

The following sample PAD.INF file can guide you in creating a section within PAD.INF for your X.25 network. This example shows an entry for Sprintnet:

[SPRINTNET]

;The following three lines are temporary.

DEFAULTOFF=

MAXCARRIERBPS=9600

MAXCONNECTBPS=9600

; The next line will give a delay of 2 secs -

; allowing the PAD to initialize

COMMAND=

NoResponse

COMMAND=

NoResponse

; The @ character sets the SPRINTNET PAD for 8 databit communication.

COMMAND=@

NoResponse

COMMAND=

NoResponse

; The D character requests a 9600 speed.

COMMAND=D<cr>

; We don't care for the response so we ignore it.

OK=<ignore>

; A carriage return line feed again to initialize

; the PAD read/write buffers

COMMAND=<cr><lf>

OK=<ignore>

COMMAND=<cr><lf>

OK=<ignore>

; Set X.3 settings on the PAD which make it work well with RAS.

; Broken into two parts since the line is too long.

COMMAND=SET 1:0,2:0,3:0,4:1,5:0,6:1,7:0,8:0,9:0,10:0,11:0<cr>

OK=<ignore>

; Set the other half of X.3 parameters

COMMAND=SET 12:0,13:0,14:0,15:0,16:0,17:0,18:0,19:0,20:0,21:0,22:0<cr>

OK=<ignore>

; Finally try to call RAS X25 server

COMMAND=C <x25address><cr><lf>

CONNECT=<match>"CONNECT"

ERROR_DIAGNOSTICS=<cr><lf><Diagnostics>

; CONNECT response means that the connection completed fine.

; X25ERROR response means connection attempt failed - the X25 CAUSE and

; DIAGNOSTIC information will be extracted from the response and

; sent to the user.

; ERROR responses are for generic failures.

Once this sample conversation for SPRINTNET is completed (with all the correct responses), the X.25 connection is established. If any errors are detected during the PAD conversation, no connection is made.

Note

The Remote Access Service currently works with PADs set to 8 data bits, 1 stop bit, and no parity. Consult the documentation for the PAD to see how to install these settings.

In PAD.INF, you can use the COMMAND_ series of commands (COMMAND_INIT, COMMAND_DIAL, and COMMAND_LISTEN) instead of the generic COMMAND. But do not mix the two families of commands. For more information on the COMMAND_ series, see Appendix E, "Understanding MODEM.INF."


Troubleshooting
X.25 Support	12 of 12

Configuring Remote Access Software for X.25

Troubleshooting

See the Remote Access online Help.


Support for Security Hosts and Switches
Chapter 7	1 of 6

Support for Security Hosts and Switches

Remote Access supports various kinds of intermediary devices (switches and hosts) between the Remote Access client and the Remote Access server. These devices include:

Modem-pool switch

Security host

X.25 network

Figure 7.1 shows a sample configuration incorporating a modem pool and a security host.

Figure 7.1    Sample Configuration with Modem Pool and Security Host


Connecting Through Intermediary Devices
Support for Security Hosts and Switches	2 of 6

Connecting Through Intermediary Devices

Before connecting to the Remote Access server, a client can have one of two possible dialogs with each intermediary device:

Static

A dialog that's always the same and requires no input from the user.

Interactive

A dialog that always changes, requiring input from the user.

You must prepare the client to conduct the correct dialog with each intermediary.

With a configuration that requires both types of dialogs, preparation takes two general steps:

1.	Write a script for the static dialog. (See the next section, "Writing Scripts.")

2.	Activate terminal mode for the interactive dialogs. (See "Activating Terminal Mode on the Client," later in this chapter.)

If your configuration requires only one kind of dialog, take only one of these steps. For example:

If your clients connect through only one intermediary with a static dialog, such as an X.25 network, skip step 2.

If your clients connect through a security host with an interactive dialog, skip step 1.


Writing Scripts
Support for Security Hosts and Switches	3 of 6

Connecting Through Intermediary Devices

Writing Scripts

To write a script for static dialogs, such as the one between the client and the modem-pool switch in Figure 7.2, add the intermediary device to the SWITCH.INF file. See PAD.INF for an example.

Figure 7.2    Sample Dialogs Between Client and Intermediary Devices

Figure 7.2 shows an example where two dialogs are required: preconnect (a modem-pool switch) and postconnect (a security host). Although preconnect and postconnect dialogs can be either static or interactive, the preconnect dialog is normally static and the postconnect is normally interactive. Static dialogs require no interaction between the switch and the user. Interactive dialogs require input from the user onto a terminal screen.

With static dialogs, the user selects from the Switch dialog box a user-written custom script. With interactive dialogs, the user selects Terminal from the Switch dialog box. See online Help for accessing the Switch dialog box.

To write a script

1.	In the client's SWITCH.INF file, type the name of the device within brackets.

2.	Add one or more commands followed by zero or more responses. For information about commands, see Appendix E, "Understanding MODEM.INF."

As with PAD.INF, responses in SWITCH.INF immediately follow their commands. For more information about PAD.INF, see Chapter 6, "X.25 Support."

Here is a sample entry from a SWITCH.INF file:

[Teleswitch]

COMMAND=<cr><cr>

OK=Ready<cr>

Error=Failure<cr>

To add an entry to your SWITCH.INF file, create a sequence of commands and responses that follow the order in the sample SWITCH.INF file.

The Remote Access Terminal feature lets the user communicate with intermediary devices that require an interactive dialog. For instructions about activating Terminal, see the Remote Access online Help.


Security Hosts
Support for Security Hosts and Switches	4 of 6

Security Hosts

A security host is a third-party authentication device that verifies whether a caller from a remote client is authorized to connect to the Remote Access server. This verification supplements security already supplied by the Remote Access Service and Windows NT Server.

For example, one kind of security system consists of two hardware devices, the security host and security card. The security host is installed between the Remote Access server and its modem. The security card is a small unit the size of a credit card, resembling a pocket calculator without keys. The security card displays in its window a different access number every minute. This number is synchronized with the same number calculated in the security host every minute. When connecting, the remote user sends the number on the security card to the host. If the number is correct, the security host connects the remote user with the Remote Access server.

Another kind prompts the remote user to type in a username (which may or may not be the same as the Remote Access username) and a password (which differs from the Remote Access password).

The security host must be configured to allow the RAS server to initialize the modem before the security functions take effect. The RAS server must also be able to directly initialize the modem connected to the security host without security checks from the security host. The security host may interpret the RAS server's attempt to initalize the modem as an attempt to dial out.

You should also set up the host for a fixed bits per second (bps) speed rather than autobaud. The fixed bps should equal the value of the MAXCONNECTBPS parameter for the entry you created for this device in the MODEM.INF file.

To make third-party security devices work with the Remote Access Service

1.	If the Remote Access server's modem is different from the modem in the security host's section in MODEM.INF, the MODEM.INF file on the Remote Access server needs to be customized to link the security host to the server's modem.

2.	The remote user needs to activate Terminal mode to interact with the security host.

Note

If you want to use a Security Dynamics security host, you must order two connectors through your Security Dynamics provider to permit initialization of the RAS modem. Specify that you want the dial-out option when you order. The provider will then send you an AND gate and a jumper box. For the ACM/400 security host, you will also receive different software.


Customizing the Remote Access Server’s MODEM.INF
Support for Security Hosts and Switches	5 of 6

Security Hosts

Customizing the Remote Access Server's MODEM.INF

When you install a security host between the Remote Access server and its modem(s), the server's modem and the security host act together as a new type of modem. The MODEM.INF file is shipped with a template for each supported security host paired with a particular modem. For example, the ACM/400 is paired with an AT&T® Comsphere 3820 modem.

To use the security host with a different modem, you will have to modify the MODEM.INF file. For details about MODEM.INF, see Appendix E, "Understanding MODEM.INF."

To customize MODEM.INF

1.	Make a backup copy of the MODEM.INF file.

2.	In the security host's section, replace all of the values for the _on and _off macros (such as speaker_on=M1) with the values from the section for the modem you'll be using.

3.	In the security host's section, replace all COMMAND_INIT= lines with the COMMAND_INIT= lines from the section for the modem you'll be using.

The security host section must have the same number of COMMAND_INIT lines as the section for the modem you want to use. Do not change any other line in the security host section.

Note

LOOP= lines are not needed for all modems. However, if you are in doubt, leave them in.

After customizing the security host section in MODEM.INF, install the security host and modem on the Remote Access server using Control Panel.

To install a security device

1.	In the Windows NT Server Control Panel, choose the Network icon.

2.	In the Installed Network Software window, select Remote Access Service.

3.	Choose the Configure button.

4.	In the Remote Access Setup dialog box, select the security device connected between the Remote Access server and its modem, and choose Continue button.

You must also ensure that Hardware Flow Control is not changed from the default, which is on.

5.	In the Network Settings dialog box, choose the OK button.

6.	Choose the Yes button.


Activating Terminal Mode on the Client
Support for Security Hosts and Switches	6 of 6

Security Hosts

Activating Terminal Mode on the Client

Remote Access Terminal lets the remote user send the correct access number to the security device. If the number is correct, the user is connected to the Remote Access server.

To prepare the client for Terminal mode

1.	In the Remote Access Phone Book, select the entry you want to connect to.

2.	Choose the Edit button.

3.	Choose the Advanced button.

4.	Choose the Security button.

5.	In the After Dialing field, select Terminal.

6.	Choose the OK button.

To connect to the Remote Access server

1.	Select the entry you have just prepared for Terminal mode.

2.	Choose the Dial button.

When prompted, type your username and password, and choose the OK button.

3.	When Terminal appears, type the access information required by your security host, for example, your personal identification number, followed by the number on the dialog box of the security card, or a username and password.

4.	As soon as the security host indicates that you have been authenticated, choose the Done button. The indication varies from one security host to another. For example, you may get an OK, or the cursor may just drop to the next line.

Authentication on the Remote Access server begins.


Wide-Area Network Adapters
Appendix A	1 of 1

Wide-Area Network Adapters

For a list of specific products supported by the Remote Access Service, see the Hardware Compatibility List.

For Digiboard serial and ISDN cards, contact Digiboard at the following address:

Digiboard
6400 Flying Cloud Drive
Eden Prairie, MN   55344
U.S.A.

Telephone: (612) 943-9020

For Eicon X.25 smart cards, contact Eicon at the following address:

Eicon Technology, Inc.
14755 Preston Road, Suite 620
Dallas, TX   75240
U.S.A.

Telephone: (214) 239-3270
Fax: (214) 239-3304

Eicon Technology Corporation
2196 32nd Avenue
Montreal, Quebec
Canada  H8T 3H7

Telephone: (514) 631-2592
Fax: (514) 631-3092

Eicon Technology Ltd.
Kingsway Business Park
Oldfield Road
Hampton, Middlesex TW12 2HD
United Kingdom

Telephone: 44 (81) 941-7122
Fax: 44 (81) 941-0548


Migrating from Earlier Versions of the Remote Access Service
Appendix B	1 of 5

Migrating from Earlier Versions of the Remote Access Service

This appendix gives configuration suggestions for using earlier versions of RAS and migrating to version 3.5.


Backward Compatibility
	Migrating from Earlier Versions of the Remote Access Service	2 of 5
Backward Compatibility

For backward compatibility, the Remote Access servers, version 1.1 or earlier, should contain the following minimal configuration.


LANMAN.INI File
	Migrating from Earlier Versions of the Remote Access Service	3 of 5
Backward Compatibility

LANMAN.INI File

[remoteaccess]
MaxNames=8	;For extra NetBIOS names on Windows NT workstations
remotelisten=all	;Enables the peer capabilities of Windows NT
	;workstations through the Remote Access server.


PROTOCOL.INI File
	Migrating from Earlier Versions of the Remote Access Service	4 of 5
Backward Compatibility

PROTOCOL.INI File

[netbeui_xif]
sessions=160
ncbs=180
names=160
[tcpip_xif]
nbsessions=100
numnames=127	;This is the maximum for the TCP/IP stack.
;numncbs=85	;Commenting out the numncbs line lets the TCP/IP
	;stack assume the highest value possible.
If servers with earlier versions of the Remote Access Service do not have this minimal configuration, Windows NT computers will see the following error message when dialing in:

The server cannot allocate NetBIOS resources needed to support the client.


Administering an OS/2 RAS Server on a Windows NT Domain
	Migrating from Earlier Versions of the Remote Access Service	5 of 5
Backward Compatibility

Administering an OS/2 RAS Server on a Windows NT Domain

If you have RAS servers running OS/2 for LAN Manager on a Windows NT domain, you must use a Windows NT computer to remotely administer the OS/2 RAS server. You can, of course, continue to administer the OS/2 server locally.


Modifying Parameters
Appendix C	1 of 12

Modifying Parameters

When you install the Remote Access Service on a server, the Setup program adds the RemoteAccess key to the Windows NT Registry. The RemoteAccess key and its subkeys contain parameters specific to Remote Access.

This appendix tells you how to modify Remote Access parameters in the Registry.


Modifying the Registry
Modifying Parameters	2 of 12

Modifying the Registry

The Remote Access Setup program adds Remote Access keys to the Windows NT Registry.

Remote Access generally supplies good default values for RAS parameters, which you normally do not need to override. Still, for some systems, you may want to adjust individual parameters to suit your particular needs.

There are several sets of parameters you can modify or add. You can override their defaults by adding or changing the appropriate key in the Registry. You can find these keys on the paths indicated in each section below.

To edit the Registry

1.	Double-click the Command Prompt icon in the Windows NT Program Manager Main group.

2.	At the prompt, type regedt32.

This command can also be run from File Manager and the Task List, or an icon can be created in a Program Group.

For detailed information on how to add a parameter to a key in the Registry, see online Help for the Windows NT Registry editor.


RemoteAccess Parameters
Modifying Parameters	3 of 12

RemoteAccess Parameters

The default values of these parameters work well for all Windows NT operations.

The Parameters subkey for RemoteAccess has the following Registry path:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services
\RemoteAccess\Parameters.

AuthenticateRetries		REG_DWORD		0 to 10
Sets the maximum number of unsuccessful retries that are allowed if the initial attempt at authentication fails.

Default: 2.

AuthenticateTime		REG_DWORD		20-600 seconds
Sets the maximum time limit, in seconds, within which a user must be successfully authenticated. If the client does not complete the authentication process within this time, the user is disconnected.

Default: 120 seconds.

AutoDisconnect		REG_DWORD		0-1000 minutes
Sets the time interval after which inactive connections are terminated. Inactivity is measured by lack of NetBIOS session data transfer, such as copying files, accessing network resources, and sending and receiving electronic mail. You may want to set this parameter to 0 minutes if clients are running NetBIOS datagram applications. Setting this parameter to 0 turns off AutoDisconnect.

Default: 20 minutes.

CallbackTime		REG_DWORD		2-12 seconds
Sets the time interval that the server waits before calling the client back when the Callback feature has been set. Each client communicates the value of its own callback time when connecting to a Remote Access server. This value can be found in the MODEM.INF file for the client. If this value is not communicated (that is, if the client does not communicate a value for the callback time, as with Remote Access version 1.0 and 1.1 clients), then the value of the CallbackTime parameter becomes the default.

Default: 2 seconds.

EnableAudit		REG_DWORD		0-1
Determines whether Remote Access auditing is turned on or off. If this feature is enabled, all audits are recorded in the Windows NT event log. You can see these audits in the Windows NT Event Viewer.

Default: 1 (enabled).

NetbiosGatewayEnabled		REG_DWORD		0-1
Makes the server function like a NetBIOS gateway, allowing clients to access the LAN. If disabled, remote clients can access only the resources on the Remote Access server in a point-to-point connection; dial-in users cannot see the network or access network resources. This parameter should never be modified directly. Use RAS Setup to modify this parameter because RAS Setup also modifies bindings when changing this parameter.

Default: 1 (enabled).


NetbiosGateway Parameters
Modifying Parameters	4 of 12

NetbiosGateway Parameters

The Registry path for these entries is the following:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services
\RemoteAccess\Parameters\NetbiosGateway

DisableMcastFwdWhenSessionTraffic		REG_DWORD		0-1
Allows NetBIOS session traffic (for example, Windows NT-based applications) to take priority over multicast datagrams (such as server messages). In other words, multicast datagrams are transferred only when there is no session traffic. Unless you're using an application that depends on multicast datagrams, leave this parameter enabled.

Default: 1 (enabled).

EnableBroadcast		REG_DWORD		0-1
Determines whether broadcast datagrams are forwarded to remote computers. Broadcast datagrams are not often useful and take up too much bandwidth on a slow link. Unless you're using an application that relies on broadcast datagrams, leave this parameter disabled.

Default: 0 (disabled).

See also MultiCastForwardRate.

EnableNetbiosSessionsAuditing		REG_DWORD		0-1
Turns on and off Remote Access auditing of the establishment of NetBIOS sessions between the remote clients and the Windows NT servers. Turning this parameter on helps the administrator track the NetBIOS resources accessed on the LAN.

Default: 0 (disabled).

MaxBcastDgBuffered		REG_DWORD		16-255
Sets the number of broadcast datagrams that the gateway buffers for a client. If you're using an application that communicates extensively through multicast or broadcast datagrams, then increase this parameter so that the Remote Access server can deliver all datagrams reliably.

Default: 32.

MaxDgBufferedPerGroupName		REG_DWORD		1-255
Sets the number of datagrams that can be buffered per group name. Increasing this value buffers more datagrams per group name, but also takes up more virtual memory.

Default: 10.

MaxDynMem		REG_DWORD		131072-4294967295
Sets the amount of virtual memory used to buffer NetBIOS session data for each remote client.

Note

Because the Remote Access server is a gateway between the slow line and the LAN, data is stored (buffered) in its memory when coming from the fast line (LAN) before it is forwarded to the slow line (asynchronous line).

The Remote Access server minimizes the usage of the system's physical memory by locking only a minimal set of pages (about 64K per client) and making use of virtual memory (up to MaxDynMem) to buffer the rest of the data.

So, as long as you have space on your hard disk to expand PAGEFILE.SYS, you can increase this parameter if needed.

You may have problems if you have an application with a LAN (fast) sender and an asynchronous (slow) receiver, and if the sender is sending more data than the Remote Access server can buffer in MaxDynMem. The Remote Access server tries to apply a form of NetBIOS level flow control by not submitting NCB.RECEIVE on the session, until it has enough buffer space to get incoming data.

For this reason, if you have such an application, you should increase your NetBIOS SEND/RECEIVE time-outs on the application server so that it waits for all data to be transmitted over the slow link to the remote client.

Default: 655350.

MaxNames		REG_DWORD		1-255
Sets the number of unique NetBIOS names each client can have, with a limit of 255 names for all clients together.

Note

Remote clients running Windows NT and Windows for Workgroups may need as many as seven or eight names each. To accommodate these computers, make sure MaxNames is set to 8 or greater. If you have Windows NT or Windows for Workgroups clients dialing in to servers running Remote Access version 1.1 or earlier, set this parameter to 8 or greater.

Default: 255.

MaxSessions		REG_DWORD		1-255
Sets the maximum number of simultaneous NetBIOS sessions each client can have, with a limit of 255 sessions for all clients together. If you have multiple clients connecting simultaneously with each running 4 or 5 sessions, decrease the value of this parameter so that the total number of sessions does not exceed 255.

Default: 255.

MultiCastForwardRate		REG_DWORD		-1 (disabled), 0-32,767 seconds
Governs the multicasting of group name datagrams to all remote computers. This parameter filters datagrams sent on group names by forwarding them at a time interval specified by the parameter.

Default: 5.

The value –1 disables forwarding. The value 0 guarantees delivery of group name datagrams. The value n forwards datagrams every n seconds, where 1 n 32,767.

If the EnableBroadcast parameter is set to 0, then broadcasts are not forwarded even if the MultiCastForwardRate parameter is set to a positive number (in this case, only multicast datagrams are forwarded). If MultiCastForwardRate is set to -1, broadcasts are still not forwarded even if EnableBroadcast is set to 1. See also EnableBroadcast.

To save bandwidth for session traffic, you should filter the datagrams. However, if you have an application based on multicast datagrams, set this parameter to 0. Setting it to 0 guarantees delivery of all datagrams sent on group names from the LAN to the remote client.

NumRecvQueryIndications		REG_DWORD		1-32
Allows a Remote Access client to initiate multiple network connections simultaneously. If a remote client is running a NetBIOS application that does multiple NCB.CALL commands simultaneously, increase this parameter to improve performance.

Default: 3.

RcvDgSubmittedPerGroupName		REG_DWORD		1-32
Determines the number of NetBIOS commands of the type Receive Datagram that can be submitted simultaneously per group name on the LAN stack. Keep this setting as small as possible to minimize the amount of memory consumed by system resources. Each datagram command received locks about 1.5K of physical memory in the system.

Default: 3.

RemoteListen		REG_DWORD		0-2
Sets the level of access that a LAN client has to a remote client's resources. This is done by posting NCB.LISTEN commands on the NetBIOS names of the client.

Setting	Meaning		Remark
0	Allows no access.		Because every remote listen posted consumes one session, setting this parameter to 0 saves sessions.
1	Makes the Server and Messenger services available on the client.		A remote client running the Server service can make its resources (such as disks and printers) available to LAN users. A remote client running the Messenger service can receive messages from LAN users, printers, and so on.
2	Enables NCB.LISTEN for all remote client NetBIOS names.		This setting allows any NetBIOS application running on a client to answer NCB.CALL commands issued by LAN applications.
Note

It is best to leave the RemoteListen parameter set to the default, 1 (messages).

Allowing NCB.LISTEN capability on remote clients can significantly drain system resources and therefore is not recommended. If the RemoteListen parameter is configured to 2, Remote Access posts an NCB.LISTEN on all NetBIOS names of Remote Access clients. Considering that the average Windows NT client has about 7 or 8 NetBIOS names assigned to it, the total number of NetBIOS names for which an NCB.LISTEN would be posted is 7 or 8 * 256 (the maximum number of clients per Remote Access server).

Default: 1 (messages).

SizWorkBufs		REG_DWORD		1024-65536
Sets the size of work buffers. The default setting is optimized for the server message block (SMB) protocol, the protocol between the client and the server running Windows NT Server.

Default: 4500.


IP Parameters
Modifying Parameters	5 of 12

IP Parameters

The Registry path for these entries is the following:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services
\RemoteAccess\Parameters\IP

WINSNameServer		REG_SZ		IP Address
Change this parameter in a RAS client's Registry to override the automatic assignment of the RAS server's WINS server to the RAS client.

This parameter appears in the Registry only during an active connection to a RAS server.

WINSNameServerBackup		REG_SZ		IP Address
Add this parameter to a RAS client's Registry to override the automatic assignment of the RAS server's backup WINS server to the RAS client.

This parameter appears in the Registry only during an active connection to a RAS server.

WIDNSNameServers		REG_MULTI_SZ		IP Addresses
Add this parameter to a RAS client's Registry to override the automatic assignment of the RAS server's DNS servers to the RAS client.

This parameter appears in the Registry only during an active connection to a RAS server.


AsyncMac Parameters
Modifying Parameters	6 of 12

AsyncMac Parameters

The Registry path for these entries is the following:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services
\AsyncMacn\Parameters

MaxFrameSize		REG_DWORD		576-1514
Determines the maximum frame size. Use smaller frames for noisy links. A lower setting sends less data per frame, slowing performance. Do not change this parameter for previous versions of the Remote Access Service. The value is negotiated between the server and Windows NT clients.

Default: 1514.

TimeoutBase		REG_DWORD		500-1000
Determines the amount of time that elapses on a NetBIOS gateway before a connection is disconnected. If you are experiencing an abnormal number of time-out errors using the NetBIOS gateway (more than 10 time-outs per 100 kilobytes received), increase the TimeoutBase value from 500 to 1000 if your computer has a security device or your computer's modems have hardware compression or error control enabled.

With TimeoutBase increased to 1000, network functionality may on very rare occasions act abnormally. For example, you may have to type network commands more than once, or functionality may periodically slow down.

Default: 500.

XonXoff		REG_DWORD		0-FFFFFFFF
Add this parameter with the value 0x000A0000 to remove the standard XON and XOFF control values (ASCII values 17 and 19).


NdisWan Parameter
Modifying Parameters	7 of 12

NdisWan Parameter

The Registry path for this entry is the following:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services
\NdisWan\Parameters

NetworkAddress="xxxxxx"		REG_SZ		Network address
Add this parameter to reassign the first 4 bytes of the 6-byte IEEE address. For example, if you reset the address to "03-1F-2C-81-92-34", only the first four bytes are looked at. The last two bytes are reserved to uniquely identify the port. Reset this parameter in the NdisWan\Parameters key with the datatype REG_SZ.

Some terminal switching devices or serial devices may require certain control characters to be removed from the byte stream to operate properly with the Remote Access Service. To remove the standard XON and XOFF control characters (ASCII values 17 and 19), set XonXoff to the following hex value:

0x000A0000

For this parameter to work, both the client and the server must add this parameter. If only one end has added it, the Remote Access Service will not function properly.


IPXRouter Parameters
Modifying Parameters	8 of 12

IPXRouter Parameters

The Registry path for this entry is the following:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services
\IPXRouter\Parameters

NetbiosRouting		REG_DWORD		0, 2, 4, or 6
Controls the forwarding of IPX NetBIOS broadcast packets. The RAS server can forward NetBIOS broadcast packets (IPX type-20) between RAS clients and the local network. Enable this parameter if you want to run an IPX NetBIOS application over RAS, but you do not want to use the RAS NetBIOS gateway.

Set to 2, this parameter enables forwarding of NetBIOS broadcast packets from the remote client to the LAN. Set to 4, this parameter enables forwarding of NetBIOS broadcast packets from the LAN to the remote client. Set to 6, this parameter enables two-way forwarding of NetBIOS packets between remote clients and the LAN.

Default: 0.


RasMan Parameters
Modifying Parameters	9 of 12

RasMan Parameters

The Registry path for this entry is the following:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services
\RasMan\Parameters

Logging		REG_DWORD		0-1
Sets logging of all communication from serial ports to the device connected to them during command mode. This parameter is useful for solving problems with serial devices and for testing new entries added to the MODEM.INF or PAD.INF files.

You may want to view the DEVICE.LOG file in a text editor that can display both character and hexadecimal output, as some of the information will not be printable characters. Also, DEVICE.LOG contains a carriage return and line feed at the end of each line. These bytes are provided by the program that creates the DEVICE.LOG file and do not represent information communicated from or to the device.

Set to 1, communication from the serial port to the device connected to it will be logged in the file \systemroot\SYSTEM32\RAS\DEVICE.LOG.

Logging is suspended after successful connection to the remote device and transmission of data. Logging resumes when a new connection is established and is appended to DEVICE.LOG until the file size exceeds approximately 100K. DEVICE.LOG is then cleared and logging resumes. DEVICE.LOG is also cleared when any RAS component started after all RAS components have been stopped.

Default: 0.


PPP Parameters
Modifying Parameters	10 of 12

PPP Parameters

The Registry path for these entries is the following:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services
\RasMan\PPP

MaxTerminate		REG_DWORD		0 - unlimited
Sets the number of Terminate-Request packets sent without receiving a Terminate-Ack before assuming that the peer is unable to respond.

Default: 2.

MaxConfigure		REG_DWORD		0 - unlimited
Sets the number of Configure-Request packets sent without receiving a valid Configure-Ack, Configure-Nak, or Configure-Reject before assuming that the peer is unable to respond.

Default: 10.

MaxFailure		REG_DWORD		0 - unlimited
Sets the number of Configure-Nak packets sent without sending a Configure-Ack before assuming that the configuration is not converging.

Default: 10.

MaxReject		REG_DWORD		0 - unlimited
Sets the number of Config-Rejects sent before assuming that the PPP negotiation will not converge.

Default: 5.

RestartTimer		REG_DWORD		0 - unlimited
Sets the time (in seconds) available for transmission of Configure-Request and Terminate-Request packets. Expiration of the Restart timer causes a time-out event, and retransmission of the corresponding Configure-Request or Terminate-Request packet.

Default: 3.

NegotiateTime		REG_DWORD		0 - unlimited
Sets the amount of time allowed (in seconds) for PPP negotiation to converge successfully before disconnecting the line. 0 means that the line will never be hung up.

Default: 150.

ForceEncryptedPassword		REG_DWORD		0 - 1
Used on RAS servers only. Sets the use of the Crypto-Handshake Authentication Protocol (CHAP) while authenticating clients. Set to 1, the server will use CHAP during authentication. Set to 0, the server will negotiate PAP.

Default: 1.

Logging		REG_DWORD		0 - 1
Sets logging of PPP events. Set to 1, all PPP events will be logged in the file \systemroot\SYSTEM32\RAS\PPP.LOG. This parameter is useful for solving problems with PPP connections.

Default: 0.


PPP Subkeys
Modifying Parameters	11 of 12

PPP Parameters

PPP Subkeys

The following entries are subkeys to the PPP key.

CBCP		REG_EXPAND_SZ		DLL Path
Specifies the location of the Callback Control Protocol (CBCP) DLL. CBCP negotiates callback information with the remote client. Always present.

CHAP		REG_EXPAND_SZ		DLL Path
Specifies the location of the Crypto-Handshake Authentication Protocol (CHAP) DLL. Always present.

COMPCP		REG_EXPAND_SZ		DLL Path
Specifies the location of the Compression Control Protocol (CCP) DLL. CCP negotiates compression with the remote client. Always present.

IPCP		REG_EXPAND_SZ		DLL Path
Specifies the location of the Internet Protocol Control Protocol (IPCP) DLL. Present if RAS is configured to use TCP/IP and TCP/IP is installed.

IPXCP		REG_EXPAND_SZ		DLL Path
Specifies the location of the Internetwork Packet Exchange Control Protocol (IPXCP) DLL. Present if RAS is configured to use IPX and the Client Service for NetWare or Gateway Service for NetWare is installed.

NBFCP		REG_EXPAND_SZ		DLL Path
Specifies the location of the NetBEUI Framing Control Protocol (NBFCP) DLL. Present if RAS is configured to use NetBEUI and NetBEUI is installed.

PAP		REG_EXPAND_SZ		DLL Path
Specifies the location of the Password Authentication Protocol (PAP) DLL. Always present.


Rdr Parameters
Modifying Parameters	12 of 12

Rdr Parameters

The Registry path for this entry is the following:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services
\Rdr\Parameters

RawIoTimeLimit		REG_DWORD		see below
This parameter applies only to configurations using the NetBIOS gateway.

Sets the redirector to send data in 64 kilobyte blocks. When RawIoTimeLimit turned on, throughput increases by 10-15 percent. All other simultaneous data transfers are blocked when communicating at this speed.

This parameter is turned off for slow links and on for faster links, by default. For example, if you are communicating at 14,400 bps or slower, this feature is turned off. If you are communicating at faster speeds, such as through an ISDN line, this feature is turned on.

The following list shows what values turn raw I/O on and off for ISDN connections:

RawIoTimeLimit set to 9:

Raw I/O is enabled when connected through one 64K channel.Raw I/O is enabled when connected through two 64K channels.

RawIoTimeLimit set to 5 (default):

Raw I/O is disabled when connected through one 64K channel.Raw I/O is enabled when connected through two 64K channels.

RawIoTimeLimit set to 0:

Raw I/O is disabled when connected through one 64K channel.Raw I/O is disabled when connected through two 64K channels.


Cabling
Appendix D	1 of 4

Cabling

Most ISA and EISA computers have one of the following serial port connectors:

25-pin male "D-shell" connectors

9-pin male connectors

Most off-the-shelf cables will work with your modems, but not all. Some cables do not have all the pins connected as shown in the following tables. When purchasing cables, tell your dealer exactly what you need and provide the information in these tables to be sure you have the correct match.

Note

Do not use the 9-to-25-pin converters that come with most mouse hardware, because some of them do not carry modem signals.


25-Pin Cabling
Cabling	2 of 4

25-Pin Cabling

As Table D.1 shows, pins 1 through 8 on the serial port connector are wired to their counterparts on the modem connector. Ribbon cables usually have all 25 pins wired straight across, but they can cause interference to TVs, radios, and VCRs. Shielded RS-232 cable normally corrects this problem.

Table D.1    25-Pin Cable Wiring

25-pin serial port connector	25-pin modem connector	Signal
1	1	Ground
2	2	Transmit Data
3	3	Receive Data
4	4	Request to Send
5	5	Clear to Send
6	6	Data Set Ready
7	7	Signal Ground
8	8	Carrier Detect
20	20	Data Terminal Ready


9-Pin Cabling
Cabling	3 of 4

9-Pin Cabling

The following table shows how to connect a 9-pin serial port connector on a computer to a 25-pin connector on a modem. Again, if you buy an off-the-shelf cable, be sure all pins are connected as shown in Table D.2.

Table D.2    9-Pin Cable Wiring

9-pin serial port connector	25-pin modem connector	Signal
1	8	Carrier Detect
2	3	Receive Data
3	2	Transmit Data
4	20	Data Terminal Ready
5	7	Signal Ground
6	6	Data Set Ready
7	4	Request to Send
8	5	Clear to Send
9	22	Ring Indicator (optional)
Note

Some modems have the Data Set Ready (DSR) signal physically tied to the Data Carrier Detect (DCD) signal. Some 1200-bps modems and other 2400-bps modems have dip switches default to this setting as well. As a result, if such a modem loses power while listening for a call, the Remote Access server cannot detect the condition because the DSR will not change, as it does with other modems.

Serial Cabling Requirements

The remote Access Service requires the following pins on the RS-232 cable:

Rx	Receive
Tx	Transmit
CTS	Clear To Send
RTS	Ready To Send
DTR	Data Terminal Ready
DSR	Data Set Ready
DCD	Data Carrier Detected
Caution

All the pins listed above must be present. The Remote Access Service does not work if any of the seven pins is missing. If any pins are not present and working, the Remote Access Service reports a hardware error.


Null Modem Cabling
Cabling	4 of 4

Null Modem Cabling

If you are using a null modem to make a direct serial connection between two computers, your cable must be wired as shown in tables D.3 and D.4.

Table D.3    9-Pin Null Modem Cabling

Remote host serial port connector	Calling system serial port connector	Signal
3	2	Transmit Data
2	3	Receive Data
7	8	Request to Send
8	7	Clear to Send
6, 1	4	Data Set Ready and Carrier Detect
5	5	Signal Ground
4	6, 1	Data Terminal Ready
Table D.4    25-Pin Null Modem Cabling

Remote host serial port connector	Calling system serial port connector	Signal
2	3	Transmit Data
3	2	Receive Data
4	5	Request to Send
5	4	Clear to Send
6, 8	20	Data Set Ready and Carrier Detect
7	7	Signal Ground
20	6, 8	Data Terminal Ready
Off-the-shelf null modem cables may not be wired properly. Be sure to tell your dealer that your null modem cables must be wired as shown in Table D.4.


Understanding MODEM.INF
Appendix E	1 of 8

Understanding MODEM.INF

If you want to configure an unsupported modem to work with the Remote Access Service, you must add an entry for that modem in the MODEM.INF file.


Adding a New Modem to MODEM.INF
Understanding MODEM.INF	2 of 8

Adding a New Modem to MODEM.INF

If you are using a modem that is not explicitly supported in MODEM.INF, you can append a new section containing the command strings required by your modem. The name of the section should be the name of your modem and should be enclosed in brackets. For information about macros used in building a new section, see "Substitution Macros," later in this Appendix.

Note

To minimize the risk of corrupting existing modem sections, add any new sections to the end of the MODEM.INF file.

To edit MODEM.INF for a new modem

1.	Back up your existing MODEM.INF file.

2.	Copy an existing section to the end of MODEM.INF and rename the section header of the copy to the name of your modem. For information about section headers, see "Section Headers," later in this Appendix.

3.	Change MAXCONNECTBPS and MAXCARRIERBPS to the values of the new modem, and set values for CALLBACKTIME and DEFAULTOFF For example:

MAXCARRIERBPS=9600

MAXCONNECTBPS=19200

CALLBACKTIME=10

DEFAULTOFF=speaker compression

Configuration parameter	Description

MAXCARRIERBPS	The maximum speed at which the client's modem and the Remote Access server's modem exchange data (bps rate on the telephone line). This speed is always equal to or less than MAXCONNECTBPS.

MAXCONNECTBPS	The maximum speed at which a modem talks to the computer (DTE to DCE bps transfer rate). Set this value to the maximum serial port bps that the modem can support.

CALLBACKTIME	The time in seconds that the server waits before calling the client back. This delay allows the client's modem to reset itself. Start with 10 seconds, and increase this number if there are problems.

DEFAULTOFF	A list of all the on/off macros that you want set to off by default, until turned on by RASPHONE.EXE.

4.	Change the command strings for hwflowcontrol, protocol (error control), compression, and speaker. Check your modem's documentation for the correct values.

For example:

<hwflowcontrol_off>=&K0

<hwflowcontrol_on>=&K3

<protocol_off>=&Q0 S36=1

<protocol_on>=&Q5 S36=5 S46=138

<compression_off>=*DC0

<compression_on>=*DC1

<speaker_on>=M1

<speaker_off>=M0

Note

If you don't find values for these commands in your modem's documentation, contact the modem's manufacturer. If a modem does not support these features, these macros may be omitted from MODEM.INF. (If you omit a macro definition in step 4, be sure to also omit the same macro in the COMMAND_INIT string in step 5.) Also, protocol means error control.

5.	And finally, change the commands in the following example. Again, check your modem's documentation for the correct values.

COMMAND_INIT=AT&F&C1&D2 v1 s0=0 s2=128 s7=55 w1<cr>

COMMAND_INIT=AT<hwflowcontrol><protocol><compression><speaker><cr>

COMMAND_LISTEN=ATS0=1<cr>

COMMAND_DIAL=ATDT<phonenumber><cr>

Command	Description
COMMAND_INIT	Initializes the modem.
COMMAND_LISTEN	Sets the modem to autoanswer mode. Check your modem's documentation for the value that makes the modem answer after the first ring. Insert this value for Remote Access servers and clients configured for callback.
COMMAND_DIAL	Dials the phone number and connects. Do not enter an actual phone number here. Enter <phonenumber>, as shown in the example.
The following table lists the modes to which you should initialize your modem. The codes in the left column show examples of each mode. Codes like these form the COMMAND_INIT string. For the codes used by your modem, consult the modem's documentation.

Table E.1    Sample COMMAND_INIT Codes

Code	Meaning
&F	Restores factory settings.
&C1	Causes data carrier detect (DCD) to track the presence of a data carrier.
&D2	Hangs up and disables autoanswer when the data terminal ready (DTR) signal goes from on to off (high to low).
V1	Allows verbose (English words) return codes.
L1	Lowers the speaker volume.
Q0	Lets the modem return result codes.
E1	Enables character echo in the command state.
S0	Answers on a certain ring number: S0=0 for COMMAND_INIT, S0=1 for COMMAND_LISTEN.
S2=128	Disables the escape character.
S7=55	Sets the carrier waiting time (to about 55 seconds).
W1	Enables negotiation progress messages.
S95=44	Allows carrier, protocol, and compression messages.
Being meticulous when you create a new modem section can save a lot of debugging time later. Microsoft also recommends that you document your work so that others can quickly understand the entries in case you are not available, or so you can remember later what you did and why you did it. Be sure to type a semicolon (;) at the beginning of each comment line.

Important

If you edit MODEM.INF and your new modem does not work, restore the original version of the file and use one of the modems listed in the Hardware Compatibility List.


MODEM.INF
Understanding MODEM.INF	3 of 8

MODEM.INF

The MODEM.INF file lists all the modems supported by Remote Access, along with the command and response strings each modem needs for correct operation. When you select a modem during Remote Access installation, the Setup program associates the selected modem with the specified communication port. Remote Access connection utilities read MODEM.INF to obtain the command strings for the modem associated with each communication port. You can find MODEM.INF in the \systemroot\SYSTEM32\RAS directory.

The MODEM.INF file consists of two main parts:

A global [Responses] section

Individual sections for each supported modem, such as [Hayes V 9600]

Each section contains the following four components. The first three must appear in the order given. Comment lines can appear anywhere.

Component		Quantity
Section header		Only one
Configuration parameters and substitution macros		Zero or more
Commands		One or more
Comment lines		Zero or more


Responses
Understanding MODEM.INF	4 of 8

MODEM.INF

Responses

A command-response set consists of one command followed by zero or more responses. Responses are strings that are expected to be received from the device, and can contain macros. Responses take the form:

keyword=value_string

The MODEM.INF file contains two types of responses:

Type of response	Location
Global	In the [Responses] section.
Private	Immediately following the command line that is expected to produce the response, and before the next command line.
A modem can match any response. Normally, if the modem returns only carrier bps, put the expected responses in the private modem section. If the modem returns connect bps or both carrier bps and connect bps, put the expected responses in the global section. To find out which bps string(s) your modem returns, see your modem's documentation.

Global Responses

Responses used by most modems are in the global [Responses] section of MODEM.INF. For example:

[Responses]

LOOP=<cr><lf>RING<cr><lf>

CONNECT_V42=<cr><lf>CONNECT <connectbps> RELIABLE  EC=(LAPM) \	DC=(None)<cr><lf>

ERROR=<cr><lf>ERROR<cr><lf>

The only information contained by LOOP is that another response is coming. Remote Access then waits for that response before moving on. Any response keyword beginning with LOOP or LOOP_ acts this way.

Private Responses

Specific MODEM.INF sections can contain private response strings. Remote Access checks for private responses first. If it doesn't find a response string to match the actual string returned by the modem, it continues checking in the global response section. There is one exception, however. If the first part of a string containing an <append> macro is matched in the private section, the global section will not be searched. Instead, Remote Access waits a few seconds for the rest of the string to arrive from the modem.

For information about adding an entry to MODEM.INF, see "Adding a New Modem to MODEM.INF," earlier in this Appendix.

The following example shows a section with private responses. Microsoft encourages you to use this method of inserting responses for any section you add.

COMMAND_LISTEN=ATS0=1<cr>

CONNECT=<cr><lf>CONNECT <carrierbps><cr><lf>

CONNECT_EC=<cr><lf>CONNECT <carrierbps>/MNP<cr><lf>

CONNECT_EC=<cr><lf>CONNECT <carrierbps>/MNP/COMPRESSED<cr><lf>

CONNECT_EC=<cr><lf>CONNECT <carrierbps>/MNP COMPRESSED<cr><lf>

CONNECT_EC=<cr><lf>CONNECT <carrierbps>/V42<cr><lf>

CONNECT_EC=<cr><lf>CONNECT <carrierbps>/V42BIS<cr><lf>


Syntax
Understanding MODEM.INF	5 of 8

MODEM.INF

Syntax

This section explains the components that make up the syntax of the MODEM.INF file.

Section Headers

Section headers identify the specific device to which the section applies. In MODEM.INF it is normally a name that identifies the modem make and model. A section header is a string of up to 32 characters between square brackets, and it occupies the first line in each section. For example, [Hayes V 9600].

Configuration Parameters

Remote Access works with the modem through these parameters. They take the following form:

parameter_name=value_string

For example:

MAXCARRIERBPS=9600

CALLBACKTIME=8


Substitution Macros
Understanding MODEM.INF	6 of 8

MODEM.INF

Substitution Macros

Substitution macros are place holders that are replaced by their values in command strings. Macros follow these rules:

In the MODEM.INF file, macros must come before the first command, and by convention, after the configuration parameters.

Macro names must be enclosed in angle brackets (< >).

For example:

<reset>=&F

<speaker_on>=M1

<speaker_off>=M0

There are two types of macros:

Macro Type	Form
Unary	<macro_name>=value_string
Binary	<macro_name_ON>=value_string
	<macro_name_OFF>=value_string
The command AT<reset><cr> would be sent as AT&F<cr>. Binary macro place holders are replaced according to instructions from the user. For example, if the user disables the speaker then the command AT<speaker><cr> is sent as ATM0<cr>. If the user enables the speaker then it is sent as ATM1<cr>.

Some responses can also use macros. Most macros in response strings behave the same way as in commands. However, certain macros, such as <carrierbps> and <diagnostics>, capture information such as baud rate from the device response string.

Nested macros are not allowed. Two adjacent left angle brackets are always interpreted as a less than sign, and two adjacent right angle brackets are always interpreted as a greater than sign. Interpreting angle brackets this way allows greater than and less than symbols in a command string, when required.

The macros in the following list are reserved words, which means you cannot define them in MODEM.INF when creating a new macro. Reserved words are case insensitive.

carrierbps

connectbps

message

phonenumber

cr

lf

match

?

append

hXX

ignore

Caution

These macros are defined internally, so they do not need to be defined in MODEM.INF. However, they can be used in MODEM.INF, as phonenumber is used in the COMMAND_DIAL= string.

For additional reserved words, see "PAD.INF Format," in Chapter 6, "X.25 Support."

Table E.2 lists macros defined in the files MODEM.INF. Always enclose these macros in angle brackets (< >).

Table E.2    Macros Defined in MODEM.INF

Macro	Function
speaker	Turns the modem speaker on or off.
protocol	Turns the error correction protocol on or off.
compression	Turns modem compression on or off.
hwflowcontrol	Tells the modem whether to use hardware flow control between the COM port and modem.
cr	Inserts a carriage return.
lf	Inserts a line feed.
match	Reports a match if the string enclosed in quotation marks is found in the device response. For example, <match>"Smith" matches Jane Smith and John Smith III.
?	Inserts a wildcard character, for example, CO<?><?>2 matches COOL2 or COAT2, but not COOL3.
append	Causes information to be broken into two segments and received from the modem one segment at a time. The client expects delays between the segments and waits until all the information has arrived. See the sample MODEM.INF file for an example.
hXX (XX are hexadecimal digits)	Allows any hexadecimal character to appear in a string including the zero byte, <h00>.
ignore	Ignores the rest of a response from the macro on. For example, <cr><lf>CONNECTV-<ignore> reads the following responses as the same: "crlfCONNECTV-1.1" and "crlfCONNECTV-2.3."
In Table E.2, the first four macros (speaker, protocol, compression, and hwflowcontrol) are binary macros. Define them as shown with speaker in the first example in this section.

As values, use them as shown in the following example:

COMMAND_INIT=AT<speaker><cr>

This command sends ATM1<cr> to the modem if the speaker is to be turned on and ATM0<cr> if the speaker is to be turned off. Through the Remote Access Phone Book, the user determines which macros are to be on or off. The Phone Book then reads the MODEM.INF file to find out which value string to send to the modem. Note that value strings sometimes differ among modems.

The Remote Access Service uses the last five macros in the Table E.2 (match, ?, append, hXX, and ignore) in response strings to recognize responses from a modem or another device.

Commands

Commands are strings of characters sent to the modem. These strings can contain macros, and take the following form:

command_keyword=value_string

The set of command keywords (or types) is:

COMMAND_INIT

COMMAND_DIAL

COMMAND_LISTEN

The MODEM.INF file initializes the modem, dials a phone number, and puts the modem into answer mode with the command types COMMAND_INIT, COMMAND_DIAL, and COMMAND_LISTEN. Commands of a given type are executed in the order found in the MODEM.INF file. By convention commands of the same type are grouped together, as shown in the following example from MODEM.INF:

COMMAND_INIT=AT&F&C1&D2 V1 S0=0 S2=128 S7=55 W0 S95=44<cr>

COMMAND_INIT=AT<speaker><protocol><compression><hwflowcontrol><cr>

COMMAND_LISTEN=ATS0=1<cr>

COMMAND_DIAL=ATDT<phonenumber><cr>

Multiple Command Strings

Because most modems accept strings of about 50 characters, the Remote Access Service supports multiple command strings. That way you can break up long commands into strings the modem can accept.

For example, the first line could be rewritten as a multiple command string:

COMMAND_INIT=AT&F&C1&D2 V1 S0=0 S2=128 S7=55 W0 \	S95=44<speaker><protocol><compression><hwflowcontrol><cr>

COMMAND_INIT=AT&F&C1&D2 V1 S0=0 S2=128 S7=55 W0 S95=44<cr>

COMMAND_INIT=AT<speaker><protocol><compression><hwflowcontrol><cr>

Notice that each string:

Is a command in its own right.

Begins with AT and ends with a carriage return (<cr>).

Gets a response before going to the next string.

Comment Lines

Comment lines begin with a semicolon (;), and they can appear anywhere in the file. Comment lines convey important information to those who maintain the .INF files. For example:

; Explanation of modem commands

; &F Reset modem to factory default settings

; &C1 DCD tracks presence of modem carrier

; &D2 Hangup & disable autoanswer when DTR goes from ON TO OFF

Line Continuation

A backslash (\) signals a line continuation. This mark indicates commands or responses are continued on the next line, making files more legible. A double backslash (\\) denotes a backslash.

For example:

CONNECT_EC=\

<cr><lf>CARRIER <carrierbps><cr><lf><append>\

<cr><lf>PROTOCOL: V.42/LAPM<cr><lf>\

<cr><lf>COMPRESSION: NONE<cr><lf>\

<cr><lf>CONNECT <connectbps><cr><lf>

<protocol_on>=K0

<protocol_off>=K1


Assigning an Alias
Understanding MODEM.INF	7 of 8

MODEM.INF

Assigning an Alias

If a modem's command strings are identical to those already listed for another modem, the name of the latter modem can be used as an alias for the former.

For example:

[QT Modem]

ALIAS=Codex 326X Fast

In this example, the QT modem uses command strings of a Codex 326X Fast modem.

An alias to an alias is not allowed. In other words, you cannot nest aliases. For example, if you want to alias two modems to another modem, you must alias them directly:

[Modem 1]

;Modem 1's normal entries go here

[Modem 2]

ALIAS=Modem 1

[Modem 3]

ALIAS=Modem 1

;You cannot say ALIAS=Modem 2


Adding Modem Detection Information to MODEM.INF
Understanding MODEM.INF	8 of 8

MODEM.INF

Adding Modem Detection Information to MODEM.INF

The command and response that enable Remote Access Setup to automatically detect modems are:

DETECT_STRING

DETECT_RESPONSE

Insert the appropriate modem identification command after the DETECT_STRING parameter, followed by <cr>. Then insert the response expected from the modem after the DETECT_RESPONSE parameter. For example:

[DataRace RediModem V.32bis]

; Command sent is ATI3<cr>, and the response is

; "PC Half-Card V.32bis/V.42bis/Fax". Actually, the modem

; might return more than just the string in quotation marks,

; but all that is needed to make a positive identification is

; the information in quotation marks.

DETECT_STRING=ATI3<cr>

DETECT_RESPONSE=PC Half-Card V.32bis/V.42bis/Fax

If there are several possible responses that might be returned for a specific modem, then for each DETECT_STRING command, list all possible combinations of responses that could occur. For example, the following section enables Setup to detect the [Datatrek 2424AMH] modem. Setup sends the ATI9 command and expects any one of the four possible responses to be returned.

DETECT_STRING=ATI9<cr>

DETECT_RESPONSE=C3

DETECT_RESPONSE=C2

DETECT_RESPONSE=3.

DETECT_RESPONSE=2.

If multiple commands are required to make a positive identification, list all the required commands and their corresponding responses. For example, the following section enables Setup to detect the the [Intel 9600EX] modem. Setup expects specific responses for both the ATI0 and ATI3 commands in order to make a unique identification.

DETECT_STRING=ATI0<cr>

DETECT_RESPONSE=969

DETECT_STRING=ATI3<cr>

DETECT_RESPONSE=U21