Copyright: Citrix WinFrame Copyright 1994-1996
Citation: Citrix WinFrame Copyright 1994-1996


Solutions Guide Contents
Citrix WINFRAME

Solutions Guide

Contents

Welcome

Chapter 1	Setting Up a WINFRAME Environment

Chapter 2	Planning, Installing, and Integrating a WINFRAME Project

Chapter 3	Security and WINFRAME

Chapter 4	Internet Connectivity and WINFRAME

Chapter 5	Remote Node Connectivity Products

Chapter 6	3270 Mainframe Connectivity and WINFRAME

Chapter 7	AS/400 Minicomputer Connectivity and WINFRAME

Chapter 8	ISDN Connectivity and WINFRAME

Chapter 9	X.25 Connectivity and WINFRAME

Chapter 10	Software Application Notes


Welcome Contents, Solutions Guide
Citrix WINFRAME

Solutions Guide

Contents

Welcome

Finding Information About WINFRAME

Documentation Conventions

Chapter 1	Setting Up a WINFRAME Environment

Chapter 2	Planning, Installing, and Integrating a WINFRAME Project

Chapter 3	Security and WINFRAME

Chapter 4	Internet Connectivity and WINFRAME

Chapter 5	Remote Node Connectivity Products

Chapter 6	3270 Mainframe Connectivity and WINFRAME

Chapter 7	AS/400 Minicomputer Connectivity and WINFRAME

Chapter 8	ISDN Connectivity and WINFRAME

Chapter 9	X.25 Connectivity and WINFRAME

Chapter 10	Software Application Notes


Chapter 1 Contents, Solutions Guide
Citrix WINFRAME

Solutions Guide

Contents

Welcome

Chapter 1	Setting Up a WINFRAME Environment

Single Machine or Multiple Machines?

WINFRAME as a Standalone Server vs. WINFRAME on a Network Domain

Configuring Users on WINFRAME

Domain-Wide User vs. Machine-Specific User, Home Directories, and Profiles

Chapter 2	Planning, Installing, and Integrating a WINFRAME Project

Chapter 3	Security and WINFRAME

Chapter 4	Internet Connectivity and WINFRAME

Chapter 5	Remote Node Connectivity Products

Chapter 6	3270 Mainframe Connectivity and WINFRAME

Chapter 7	AS/400 Minicomputer Connectivity and WINFRAME

Chapter 8	ISDN Connectivity and WINFRAME

Chapter 9	X.25 Connectivity and WINFRAME

Chapter 10	Software Application Notes


Chapter 2 Contents, Solutions Guide
Citrix WINFRAME

Solutions Guide

Contents

Welcome

Chapter 1	Setting Up a WINFRAME Environment

Chapter 2	Planning, Installing, and Integrating a WINFRAME Project

Chapter 3	Security and WINFRAME

Chapter 4	Internet Connectivity and WINFRAME

Chapter 5	Remote Node Connectivity Products

Chapter 6	3270 Mainframe Connectivity and WINFRAME

Chapter 7	AS/400 Minicomputer Connectivity and WINFRAME

Chapter 8	ISDN Connectivity and WINFRAME

Chapter 9	X.25 Connectivity and WINFRAME

Chapter 10	Software Application Notes


Chapter 3 Contents, Solutions Guide
Citrix WINFRAME

Solutions Guide

Contents

Welcome

Chapter 1	Setting Up a WINFRAME Environment

Chapter 2	Planning, Installing, and Integrating a WINFRAME Project

Chapter 3	Security and WINFRAME

Customizing Winlogon

Protecting Against Viruses and Trojan Horses

How to Prevent Virus Outbreaks

How to Prevent Trojan Horse Attacks

How to Control What Users Can Do

Permissions

ClipBook Viewer Permissions

Auditing

The AUDITLOG Utility

User Rights

Setting Password and Account Policy

How Administrators Should Log On

Allowing Guest Access

How Local Guest Logons Work

How Network Guest Logons Work

Managing Guest Logons

Configuring Users on WINFRAME

Third-Party Security Devices

Communication Devices MultiGuard

Digital Pathways Defender 5000

Security Dynamics Access Control Module

Chapter 4	Internet Connectivity and WINFRAME

Chapter 5	Remote Node Connectivity Products

Chapter 6	3270 Mainframe Connectivity and WINFRAME

Chapter 7	AS/400 Minicomputer Connectivity and WINFRAME

Chapter 8	ISDN Connectivity and WINFRAME

Chapter 9	X.25 Connectivity and WINFRAME

Chapter 10	Software Application Notes


Chapter 4 Contents, Solutions Guide
Citrix WINFRAME

Solutions Guide

Contents

Welcome

Chapter 1	Setting Up a WINFRAME Environment

Chapter 2	Planning, Installing, and Integrating a WINFRAME Project

Chapter 3	Security and WINFRAME

Chapter 4	Internet Connectivity and WINFRAME

How to Connect WINFRAME to the Internet

Chapter 5	Remote Node Connectivity Products

Chapter 6	3270 Mainframe Connectivity and WINFRAME

Chapter 7	AS/400 Minicomputer Connectivity and WINFRAME

Chapter 8	ISDN Connectivity and WINFRAME

Chapter 9	X.25 Connectivity and WINFRAME

Chapter 10	Software Application Notes


Chapter 5 Contents, Solutions Guide
Citrix WINFRAME

Solutions Guide

Contents

Welcome

Chapter 1	Setting Up a WINFRAME Environment

Chapter 2	Planning, Installing, and Integrating a WINFRAME Project

Chapter 3	Security and WINFRAME

Chapter 4	Internet Connectivity and WINFRAME

Chapter 5	Remote Node Connectivity Products

Remote Connection Bandwidth Constraints

Application Considerations

Third-Party Remote LAN Node Connectivity Solutions

3Com Access Builder

Attachmate RLN Version 2.x

Novell NetWare Connect Version 2.0

Shiva LanRover

Chapter 6	3270 Mainframe Connectivity and WINFRAME

Chapter 7	AS/400 Minicomputer Connectivity and WINFRAME

Chapter 8	ISDN Connectivity and WINFRAME

Chapter 9	X.25 Connectivity and WINFRAME

Chapter 10	Software Application Notes


Chapter 6 Contents, Solutions Guide
Citrix WINFRAME

Solutions Guide

Contents

Welcome

Chapter 1	Setting Up a WINFRAME Environment

Chapter 2	Planning, Installing, and Integrating a WINFRAME Project

Chapter 3	Security and WINFRAME

Chapter 4	Internet Connectivity and WINFRAME

Chapter 5	Remote Node Connectivity Products

Chapter 6	3270 Mainframe Connectivity and WINFRAME

Microsoft SNA Client/SNA Server 2.11

Chapter 7	AS/400 Minicomputer Connectivity and WINFRAME

Chapter 8	ISDN Connectivity and WINFRAME

Chapter 9	X.25 Connectivity and WINFRAME

Chapter 10	Software Application Notes


Chapter 7 Contents, Solutions Guide
Citrix WINFRAME

Solutions Guide

Contents

Welcome

Chapter 1	Setting Up a WINFRAME Environment

Chapter 2	Planning, Installing, and Integrating a WINFRAME Project

Chapter 3	Security and WINFRAME

Chapter 4	Internet Connectivity and WINFRAME

Chapter 5	Remote Node Connectivity Products

Chapter 6	3270 Mainframe Connectivity and WINFRAME

Chapter 7	AS/400 Minicomputer Connectivity and WINFRAME

Microsoft SNA Client/SNA Server 2.11

Chapter 8	ISDN Connectivity and WINFRAME

Chapter 9	X.25 Connectivity and WINFRAME

Chapter 10	Software Application Notes


Chapter 8 Contents, Solutions Guide
Citrix WINFRAME

Solutions Guide

Contents

Welcome

Chapter 1	Setting Up a WINFRAME Environment

Chapter 2	Planning, Installing, and Integrating a WINFRAME Project

Chapter 3	Security and WINFRAME

Chapter 4	Internet Connectivity and WINFRAME

Chapter 5	Remote Node Connectivity Products

Chapter 6	3270 Mainframe Connectivity and WINFRAME

Chapter 7	AS/400 Minicomputer Connectivity and WINFRAME

Chapter 8	ISDN Connectivity and WINFRAME

DigiBoard IMAC Bridge

Gandalf ISDN Bridges

Chapter 9	X.25 Connectivity and WINFRAME

Chapter 10	Software Application Notes


Chapter 9 Contents, Solutions Guide
Citrix WINFRAME

Solutions Guide

Contents

Welcome

Chapter 1	Setting Up a WINFRAME Environment

Chapter 2	Planning, Installing, and Integrating a WINFRAME Project

Chapter 3	Security and WINFRAME

Chapter 4	Internet Connectivity and WINFRAME

Chapter 5	Remote Node Connectivity Products

Chapter 6	3270 Mainframe Connectivity and WINFRAME

Chapter 7	AS/400 Minicomputer Connectivity and WINFRAME

Chapter 8	ISDN Connectivity and WINFRAME

Chapter 9	X.25 Connectivity and WINFRAME

Configuring X.25 for WINFRAME

Chapter 10	Software Application Notes


Chapter 10 Contents, Solutions Guide
Citrix WINFRAME

Solutions Guide

Contents

Welcome

Chapter 1	Setting Up a WINFRAME Environment

Chapter 2	Planning, Installing, and Integrating a WINFRAME Project

Chapter 3	Security and WINFRAME

Chapter 4	Internet Connectivity and WINFRAME

Chapter 5	Remote Node Connectivity Products

Chapter 6	3270 Mainframe Connectivity and WINFRAME

Chapter 7	AS/400 Minicomputer Connectivity and WINFRAME

Chapter 8	ISDN Connectivity and WINFRAME

Chapter 9	X.25 Connectivity and WINFRAME

Chapter 10	Software Application Notes

Advanced Revelation Version 3.1

Arcada Backup Exec, Windows NT Enterprise Edition, Version 6.0

File and Print Services for NetWare

IBM OS/2 LAN Server 4.0

Lotus Notes and a Sample Large-Scale Deployment

Microsoft Access 2.0

Microsoft PowerPoint 4.0

WordPerfect for Windows, Version 6.1


Welcome
Welcome	1 of 3

Welcome

How to Use This Guide

To get the most out of the WINFRAME Solutions Guide, review the table of contents for the solution category of interest.

For each category, youll find a brief overview and a description of how the products discussed can be used with WINFRAME.

This guide will help you choose hardware and software that can be used with WINFRAME.

Note

The products listed in this guide have been tested and found to be compatible with WINFRAME. Other products may (and probably will) work, but Citrix cannot guarantee the compatibility of untested products.

Since WINFRAME is based on Microsoft Windows NT Server Version 3.51, most Windows NT compatible applications can be expected to work. Review the application notes in the Solutions Guide and in the online WINFRAME Readme for detailed application integration tips and techniques.

Who Should Use This Guide

This guide is designed to help administrators and resellers with the installation, set up, and operation of WINFRAME and to select the proper hardware and software components necessary to build a system running WINFRAME.


Finding Information About WinFrame
Welcome	2 of 3

Finding Information About WINFRAME

This guide presents information to help you plan your WINFRAME installation.

The WINFRAME documentation set includes the following manuals:

Quick Install Guide

Provides a concise description of the installation procedures for your WINFRAME package.

Installation Guide

Summarizes key features in WINFRAME and presents step-by-step procedures for installing WINFRAME and additional networking services.

System Guide

Provides a description of the applications and tools included in your WINFRAME package. This manual presents procedures for completing common tasks such as organizing the desktop, managing files and directories, printing, using applications, administering the network, and more. A glossary at the end of the System Guide defines common terms used in WINFRAME.

Concepts and Planning Guide

Provides information about the concepts behind WINFRAME, such as network drivers and protocols, security, user environments, management of network files and printers, fault tolerance, and performance monitoring.

Network Operations Quick Reference

Provides a summary of procedures for network management tasks using WINFRAME.

Remote Access Service (WINFRAME/Enterprise only)

Provides background information and procedures for installing and managing Remote Access servers and clients for dial-in network access.

Services for Macintosh (WINFRAME/Enterprise only)

Provides background information and procedures for installing and using Services for Macintosh so that PC and Apple Macintosh computers can share files and printers on the network.

Services for NetWare Networks

Provides detailed information for installing and using Gateway Service for NetWare. Describes the Migration Tool for NetWare, which helps you integrate WINFRAME into an existing NetWare 2.x and 3.x network by transferring user and group accounts and other data from NetWare to WINFRAME.

TCP/IP

Provides background information and procedures for using TCP/IP as a transport protocol on the network. This includes instructions for installing and configuring WINFRAME computers as Dynamic Host Configuration Protocol (DHCP) servers and Windows Internet Name Service (WINS) servers to support automatic configuration of Internet Protocol (IP) addresses and name resolution services, respectively, for computers on a Windows NT network.

WINFRAME Client Users Guide

Provides information and procedures for installing and using the WINFRAME Client program, which provides remote access to a WINFRAME server.

*WINFRAME/Enterprise only

Additional Information

Refer to Additional Online Information in the Welcome chapter of the Installation Guide for assistance in getting online help.

Other sources of information in the WINFRAME package include:

Release Notes

Contain detailed, up-to-date information on your WINFRAME package.

WINFRAME Help

An online help file containing the latest WINFRAME information. Updates are available from the Citrix BBS.

WINFRAME Books Online

Contain the WINFRAME documentation (except for the Quick Install Guide and the WINFRAME Client Users Guide) as an online help file.

Citrix on the World Wide Web

You can obtain the latest Citrix information from our Web site (http://www.citrix.com), including the latest online copies of WINFRAME help and the Solutions Guide..


Documentation Conventions
Welcome	2 of 3

Documentation Conventions

This manual uses several type styles and special characters, described in the following list:

Convention	Use
bold	Represents commands, command options, and file entries. Type bold words exactly as they appear (for example, net use).
italic	Introduces new terms and represents variables. For example, the variable computer name indicates that you type the name of a workstation or a server.
ALL UPPERCASE	Represents filenames and paths. (You can, however, type such entries in uppercase or lowercase letters, or a combination of the two.)
SMALL CAPITALS	Represents keyboard names (for example, CTRL, ENTER, and F2).
[brackets]	Encloses optional items in syntax statements. For example, [password] indicates that you can choose to type a password with the command. Type only the information within the brackets, not the brackets themselves.
...(ellipsis)	Indicates a command element may be repeated.
	Indicates a procedure.
Windows NT	Refers to operating system and networking functionality that is available in WINFRAME, Windows NT Server, and Windows NT Workstation.
\WINNT or \systemroot	Refers to the WINFRAME system tree. This can be \WINFRAME\, \WINNT, \WINNT35, \WINDOWS, or whatever other directory name you specified when installing WINFRAME.


Setting Up a WinFrame Environment
Chapter 1	1 of 5

Setting Up a WINFRAME Environment

WINFRAME is a multiuser Windows application server, based on Microsoft Windows NT Server Version 3.51 under license from Microsoft, that supports enterprise application publishing using a thin client architecture. This network-centric approach includes Citrix ICA™-based universal client software that works in concert with WINFRAME multiuser application server software over dialup, LAN, WAN, and Internet connections. The Citrix thin client architecture provides the high-performance and universal application access needed by users while the multiuser application server offers IS professionals the economic benefits of single-point control and management.

Citrix Intelligent Console Architecture (ICA) is a general-purpose presentation services protocol. Conceptually similar to the UNIX X Windows protocol, ICA allows an applications user interface to execute with minimal resource consumption on a client PC while application logic executes on the WINFRAME multiuser application server.

Citrix MultiWin is a multiuser extension to Microsoft Windows NT Server.


Single Machine or Multiple Machines?
Setting up a WINFRAME Environment	2 of 5

Single Machine or Multiple Machines?

There are two basic ways to design a system to support a large number of users using WINFRAME. The first and most direct approach is to have a large single machine with enough power to support a large number of users. For example, if the machine is to support 50 users, a large, fast multiprocessor machine with a large amount of RAM is needed. How much RAM and how many processors per user is very dependent on what type of applications will be run on the WINFRAME machine.

As a rule of thumb, a Pentium per 10-15 users and approximately 5-8MB of RAM with 15-20MB of page file space per user is needed. In the 50 user, single machine example, you will need a 4-5 processor Pentium SMP server with approximately 300MB of RAM and 1GB of page file space on the hard disk. Please keep in mind that the numbers change according to what applications will be run and how intensively the users utilize the machine. For example, if the users will be running a simple data entry front end application that communicates with a database server elsewhere on a network, the requirements will be on the low end of the given ranges. If however the database server is running locally on the WINFRAME server along with the client front end applications, the requirements will be on the high end of the given ranges.

The second solution is to have multiple smaller machines that smaller groups of people will use. For example, instead of having one large machine to serve 50 users, you may have five smaller systems. Each of these systems will require one Pentium processor per system with approximately 64-80MB of RAM per system, with 200MB of page file space on the hard disk. Each system will support approximately ten users. Once again, the requirements per machine will be more or less depending on the applications the users will be using.

Note

Please refer to the Release Notes, the Installation Guide, and the Quick Install Guide for more detailed information on system configuration guidelines.


WinFrame as a Standalone Server vs. WinFrame on a Network Domain
Setting up a WINFRAME Environment	3 of 5

WINFRAME as a Standalone Server vs. WINFRAME on a Network Domain

WINFRAME can be used in one of two ways: as a stand-alone server or as a server on a network domain. When you install WINFRAME, you have the option of configuring it as a server or as a domain controller.

When installed as a server, WINFRAME can be used as a stand-alone system or it can join an existing network domain. If your WINFRAME server is not joining an existing WINFRAME or Windows NT domain and you do not anticipate having more than one WINFRAME server (for example, if you are adding a single WINFRAME server to an existing NetWare network for Dial-In user access), you do not need to establish a domain. If your configuration will eventually expand past a single WINFRAME server, establishing a WINFRAME domain will avoid the need to recreate users on each additional server.

If you set up WINFRAME as a domain controller, it becomes the central point for a new network domain. Other WINFRAME or Windows NT servers can join this network domain. Usually the best configuration is to make one WINFRAME server a domain controller and configure all other WINFRAME servers as servers on that network domain. During WINFRAME Setup, you are given the option of joining a network domain. In this case, you would select the name of the domain used on the domain controller to join the network domain. Setting up a domain allows your WINFRAME and Windows NT systems to work together. You may also leave the WINFRAME server in its own network workgroup, which is the default; the system becomes a stand-alone system and is unaware of the domain.

Note

If you do not join a network domain during the installation of the WINFRAME server, you can join the network domain at a later time by using the Network application within the WINFRAME Control Panel.


Configuring Users on WinFrame
Setting up a WINFRAME Environment	4 of 5

Configuring Users on WINFRAME

To login to WINFRAME, you must have a userID. The userID can be configured on the WINFRAME server or on the domain. If a user is configured for a particular WINFRAME server, that user can login and use only that WINFRAME server. If the userID is configured on the domain, the user can login to any WINFRAME or Windows NT system that is in the domain. This flexibility allows users to login from any system on the network. If desired, access can be restricted to specific WINFRAME servers or it can be granted across the network domain.

Use the User Manager for Domains utility to configure users on a WinFrame server. See the System Guide or Books Online for more information about this utility.


Domain Wide User vs. Machine Specific User, Home Directories, and Profiles
Setting up a WINFRAME Environment	5 of 5

Domain-Wide User vs. Machine-Specific User,Home Directories, and Profiles

Users and their Home Directories and Profiles can be configured one of two ways. The first way is to configure the users on a local or machine-specific level. These users are configured to use only that one particular system and cannot access other machines unless they have an individual login for each machine for which they need access. The Profiles and Home Directories for users in this configuration are stored on a local drive on the system or on a network server. This method may be adequate for smaller, single-server installations.

The second way (and the more scaleable method) is to set up a domain of users and machines. One of the WINFRAME systems is installed as a domain controller and the rest of the WINFRAME servers are configured as servers. One or more of the systems can share disk space for the users Home Directories and Profile storage. Users are then configured as Domain Users, Administrators, or Guests so they can login to any WINFRAME system in the domain and still have their own Profile and Home Directory. Applications can be stored on one or more of the WINFRAME servers, where the application directories are shared so that any other WINFRAME server can access them for its users. Security can be set to restrict users to particular machines or prevent access to particular machines. File security and user profile security can be set to secure data as needed. See the WINFRAME System Guide for more detail on configuring users and security.


Planning, Installing, and Integrating a WinFrame Project
Chapter 2	1 of 1

Planning, Installing and Integrating a WINFRAME Project

Deploying a WINFRAME server requires planning, preparation, and attention to detail. This chapter contains some guidelines in outline form that can be used to plan a WINFRAME deployment project.

A typical WINFRAME deployment project has five stages:

1.	Analysis

2.	Evaluation

3.	Capacity planning

4.	System deployment

5.	System maintenance

The following sections detail the steps involved in each stage of the planning and deployment process.

Analysis

Here are some sample questions that will help analyze system requirements, along with possible answers:

1.	What business problem are you trying to solve?

Streamline order entry process

Improve customer service

2.	What computing platform and applications are you using?

NetWare

Oracle database

PowerBuilder application on Windows 3.1 desktops

3.	How many users will need access? How many concurrent users? How long will a typical connection last?

100 users total, 25 concurrent connections, 30 minutes

4.	How will you be connecting to the application server?

Async Dial-In

Remote node (Microsoft RAS or third-party remote node software)

LAN

WAN

Internet

ISDN

5.	What client hardware/software will you be using?

486DX/2 Windows laptop, 12MB RAM, Shiva PPP dialer supporting IP and IPX

6.	What are the functional requirements for a remote user?

Interactively access Microsoft Office, client/server applications, 3270 connectivity to mainframe applications

Print e-mail, documents, reports to client printer

File transfer between client and servers

Security issues like dialback, firewalls, third-party security hardware, etc.

7.	What is the time frame for initial pilot and full deployment?

Thirty day pilot, full deployment in the following 60 days

8.	Have the resources been allocated for this project?

Budget approved

Project manager and internal resources assigned

9.	Who are the decision makers?

Director of MIS: budget approval, overall responsibility

Vice President of Finance: signoff on success criteria and final OK

Project Manager: owns the project

Evaluation

It is essential to establish the scope of the evaluation pilot project. This can range from demonstrating multiple concurrent users running the corporate applications to addressing issues like optimum hardware configuration, server/application tuning, client software distribution (and automatic updates), ongoing maintenance, disaster recovery, etc. Keep the following guidelines in mind:

1.	Set up a test environment that emulates actual field conditions.

2.	Use the server and client hardware/software configurations that will actually be deployed.

3.	Agree on a prioritized set of success criteria. Some examples of these are:

Applications that need to be tested

Acceptable performance results based on clearly defined benchmarks

Printing requirements

Authentication and security mechanisms

Event logging, auditing, and reporting requirements

4.	Select several users to help you streamline the client software distribution and configuration process, and maintain a log that records common questions and problems.

5.	Set up a contingency plan in the event of failure; for example, server hardware, communication lines, modems, power.

Capacity Planning

Characterize the resource requirements of a typical user utilizing Performance Monitor, network analyzers, etc. The most important categories to monitor are:

1.	CPU

2.	Memory

3.	Paging file

4.	Disk subsystems

5.	NIC

6.	LAN/WAN bandwidth utilization

Based on the above criteria, you should be able to arrive at the following:

Optimum server configuration (CPU, RAM, disk, NICs, protocols, services)

Number of servers required

Number of users per server

Network design considerations (backbone segments, multiple NICs/protocols)

Deployment

Here are a few important considerations to ensure a smooth deployment:

Document server hardware/software setup

Ensure adequate trained staff to administer the system

Distribute client software with clear documentation on setup and usage

Set up a help desk with trained staff to handle questions and problems

Establish a weekly review meeting to monitor the operation and resolve open issues

Maintenance

Plan for the following:

Help desk, problem escalation procedures, reseller/Citrix direct support

Procedures for testing interim fixes and loading software upgrades prior to deployment

Maintenance contracts for support, notification of fixes, and software upgrades

Disaster recovery procedures like backup/restore and hot spares


Security and WinFrame
Chapter 3	1 of 13

Security and WINFRAME

Unauthorized access to computer systems is a serious problem in many organizations. This chapter describes some techniques a WINFRAME administrator can use to protect valuable computer resources and company data. For those companies requiring additional security measures for remote access, WINFRAME supports several third-party security solutions described later in this chapter.

WINFRAME and the WINFRAME Client provide security features over and above the features provided by the Windows NT Server operating system:

Login names and passwords sent to the WINFRAME server from the WINFRAME Client are never sent in clear text.

The Citrix ICA protocol uses a compression technique that effectively scrambles all data sent over the communications link. Additional encryption can also be specified for the WinStation using WinStation Configuration.

WINFRAME WinStations can be configured to require callback to a fixed telephone number, preventing an intruder from accessing your server from a remote location.

WINFRAME WinStations can be configured to always require a password to be entered, preventing an intruder who has obtained access to a WINFRAME Client PC from accessing a WINFRAME server.

WINFRAME Remote Access Service (RAS) supports RSA and DES security options.

WINFRAME can be used with third-party security hardware for maximum security.

WINFRAME provides the AUDITLOG utility, which can be used to generate a report of failed logon attempts or user logon/logoff reports, as text reports or in a format readable by spreadsheet or database programs.


Customizing Winlogon
Security and WINFRAME	2 of 13

Customizing Winlogon

Winlogon is the process that controls the logon sequence to a WINFRAME server. Winlogon can be customized by adding an announcement box prior to the logon screen. Winlogon customization fulfills two important goals:

To identify the purpose of the machine to the organization

To add an announcement indicating that unauthorized access to the server is prohibited

Note

To successfully prosecute system break-ins, most courts require that you declare that your system may only be accessed by users with valid accounts. In addition, you should avoid Welcome messages because they may be interpreted as giving blanket permission to anyone to access your system.

Modifications to Winlogon are controlled by the Registry configuration database. The value entries that control Winlogon are found under the following Registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon

Note

To modify the Registry configuration database, use the Registry Editor, REGEDT32.EXE, located in %systemroot%\system32\REGEDT.EXE, where %systemroot% is the root directory of the installation partition. The Registry Editor is not loaded as an icon at installation.

There are several ways to start the Registry Editor.

Start it from the Run menu under Program Manager or File Manager.

Locate it in the File Manager and double-click on the executable.

Add an icon to a program group.

From the Administrative Tools program group, double-click the Windows NT Diagnostics icon and select Tools, Registry Editor.

To customize Winlogon

1.	With the Registry Editor, proceed to the Winlogon Registry key (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon).

2.	Scan down the Winlogon value list on the right side of the window and locate LegalNoticeCaption and LegalNoticeText. When strings are assigned to these two values, an announcement appears prior to the login screen. The announcement is displayed until the user clicks on OK. Specify two strings for the announcement box: LegalNoticeCaption for the title bar, and LegalNoticeText for the dialog box. For example:

LegalNoticeCaption:REG_SZ: This is the Corporate Internet Server.
LegalNoticeText:REG_SZ: Unauthorized Access is Strictly Prohibited.

3.	Exit the Registry Editor and log off. When you log back on, the message box will appear.

Note

WINFRAME has a screen saver that is automatically invoked after 15 minutes of workstation connected state idle time.

Note

It is recommended that WinStations be left in a disconnected state whenever possible, because connected WinStations consume valuable CPU time that could otherwise be used by active users. If WinStations must be left in a connected state,  modify the screen saver and time-out periods by using the Registry Editor on the following key:

HKEY_USERS\DEFAULT\Control Panel\Desktop

Search for the values:

ScreenSaveTimeOut:REG_SZ:900 SCRSAVE.EXE:REG_SZ:D:\WF_15\System32\logon.scr

Change the logon.scr to another .scr file or (none); other .scr choices are listed in the \system32 directory.

The (none) choice looks like:

SCRSAVE.EXE:REG_SZ:(none)

The time-out period is listed in seconds. To change the time-out from 15 to 5 minutes, change the time-out period from 900 to 300.

Caution

Some screen saver programs consume valuable CPU resources. It is highly recommended that you select a low-overhead screen saver such as logon.scr, black16.scr, or (none) if you must leave a workstation in a connected state.


Protecting Against Viruses and Trojan Horses
Security and WINFRAME	3 of 13

Protecting Against Viruses and Trojan Horses

It is extremely important to prevent intentional intrusions into your computer network that take the form of viruses and Trojan horses. Viruses are programs that attempt to spread from computer to computer and either cause damage (by erasing or corrupting data) or annoy users (by printing messages or altering what is displayed on the screen) on every computer they infect. Trojan horses are programs that masquerade as other common programs while they attempt to capture information.

An example of a Trojan horse is a program that masquerades as a system logon screen in an attempt to capture user names and password information, which the writers of the Trojan horse can use later to access the system.

How to Prevent Virus Outbreaks

Viruses are usually not intentionally introduced to your system. In most cases, users unknowingly introduce a virus into your network when they obtain what they believe to be a useful, safe program from another source, such as an online bulletin board. Many network users are unaware that they can bring viruses into the network this way. Therefore, one of the best ways to keep your network virus-free is by educating your users.

Have at least one commercial virus-detection program in use and regularly check your file servers for viruses. If possible, make virus-detection software available to your users.

Other ways to protect against computer viruses include the following:

Set file permissions to make all applications available on network servers and workstations read and execute only, preventing them from being replaced by viruses. (For more information about this procedure, refer to Chapter 13 of the System Guide.)

Before putting a new application or file on the network, put it on a computer not attached to the network and check it with your virus detection software. Log on to this computer using an account as a Guest so that the program being examined will not be able to modify any important files.

Regularly use an NT-compatible virus scanner. You may consider using the at command to periodically run the virus scanning program; for example, late at night when no users are logged on.

NEVER LEAVE A DISKETTE IN THE DISKETTE DRIVE OF YOUR SERVER. If the system is rebooted (for example, because of a power failure), the system may attempt to boot from diskette and become infected.

Regularly back up the files on your file servers (and workstations, if possible) so that damage is minimized if a virus attack does occur.

How to Prevent Trojan Horse Attacks

WINFRAME provides an important safeguard against Trojan horse programs. Before you can log onto a WINFRAME computer, you must press the secure attention sequence, CTRL+ALT+DEL. This series of keystrokes always directly invokes the WINFRAME operating system logon screen; Trojan horse programs will never be activated this way. Users provide only their user name and password to the operating system itself. To ensure the effectiveness of this procedure, you should train your users to always press CTRL+ALT+DEL, or CTRL+F1 on a WINFRAME Windows Client WinStation, before logging on at a computer, even if the logon window already appears on the screen.

The secure attention sequence is also required before a user can unlock a locked workstation or change his/her password.

Another way to guard against Trojan horses is to make your applications read and execute only so that they cannot be replaced with programs that masquerade as the original program and illegally obtain information.


How to Control What Users Can Do
Security and WINFRAME	4 of 13

How to Control What Users Can Do

You can control what users can and cannot do on their workstations and on the rest of the network in several ways. The most important method, and the one most often utilized, is to use the predefined local groups. Adding a user to one of these groups will give the user a large set of predefined rights and abilities. (For more information on what each predefined local group can do, see What Different Types of Users Can Do in the Concepts and Planning Guide.)

Another way to restrict users abilities is by limiting their logon hours and the network computers they are allowed to use.

Permissions on each file, directory, or printer shared on the network define who can and cannot access those resources. You can assign permissions to local groups, global groups, and directly to individual users. It is not recommended that you assign permissions to individual users, however, because this is hard to maintain for large numbers of users.

You can monitor what users do by auditing actions and resources. Auditing an action or resource causes an entry to be written to the Event Log whenever that action is performed or that resource is accessed.

Although not recommended, you can directly manipulate user rights (also called rights) that specify what actions local groups, global groups, and users can perform. Using the predefined local groups and their predetermined sets of rights should serve most needs. If you need to grant rights to other groups or users, or fine-tune what rights the predetermined groups have, you have the ability to do so.

Finally, you can also control a users desktop environment by assigning the user a profile. For more information about profiles, see Chapter 13 of the System Guide.

Permissions

Use File Manager to set NTFS partition file permissions. These permissions apply to all users accessing the computer with the NTFS permissions and to users accessing these files over the network (if they are shared). You can set file permissions to a fine degree of granularity; for example, you may set different permissions for each file in a directory. You can also set many other types of permissions. For example, you can let one user read the contents of a file and change it, let another user only read the file, and prevent other users from any access to the file.

This type of access restriction is not available for files on file allocation table (FAT) or high-performance file system (HPFS) partitions on WINFRAME or Windows NT computers. Files on these partitions are always readable and changeable. However, you can protect shared directories on FAT or HPFS partitions by specifying one set of permissions that apply to all users for all files and subdirectories of the shared directory. These are called share permissions.

Similar types of permissions can be set on shared printers managed by WINFRAME or Windows NT Server computers. For more information, see Chapter 6, Sharing Printers" in the Concepts and Planning Guide.

ClipBook Viewer Permissions

ClipBook Viewer enables you to share information among different applications and users and dynamically link and embed that information into other files and documents on the same computer or on other WINFRAME or Windows NT computers. For more information about ClipBook Viewer and object linking and embedding (OLE), see the System Guide.

When data is transferred to ClipBook Viewer, it takes the format of a page. ClipBook Viewer can hold up to 127 pages that can be shared with other users. The user who creates a page can set permissions on the page, specifying whether or not other users can use the page.

To create, share, stop sharing, and delete a ClipBook Viewer page, a user must be in one of the following groups on the computer:

Administrators

Server Operators

Power Users

Users

In addition, the special group Everyone can use ClipBook Viewer to see a list of pages shared on the computer.

When a user creates and shares a new ClipBook Viewer page, that user becomes the owner of the new page and the following permissions are set by default on the page. The owner of the page may change these permissions.

Permissions for New ClipBook Viewer Page

User or group	Permissions
User name of creator/owner	Full Control
Everyone	Read and Link
The following list shows the types of permissions that can be set on ClipBook Viewer pages. You can grant different permissions to different users, thereby allowing some people access to the page while denying access to others.

No Access

Read

Read and Link

Change

Full Control

Auditing

You can specify that an audit entry be written to the Event Log whenever certain actions are performed or files are accessed. The audit entry shows the action performed, the user who performed it, and the date and time of the action. You can audit both successful and failed attempts at actions, so the audit trail can show both who actually performed actions on the network and who tried to perform actions that are not permitted.

Note

Event Viewer log entries for logon events now include the computer name where the logon attempt originated.

The following table lists the categories of events you can choose to audit and what events are covered by each category. For each of the categories listed below, you can choose whether to audit only successful actions in that category, failed attempts to perform actions in that category, both, or neither.

Category	Events
Logon and Logoff	Logon attempts, logoff attempts, and the creating and breaking of network connections to servers.
File and Object Access	Accesses a directory or a file set for auditing in File Manager; uses of a printer managed by the computer.
Use Of User Rights	Successful uses of user rights and failed attempts to use rights not assigned to users.
User and Group  Management	Creation, deletion, and modification of user and group accounts.
Security Policy Changes	Granting or revoking user rights to users and groups, and establishing and breaking trust relationships with other domains.
Restart, Shutdown,  and System	Shutting down and restarting the computer, filling up the audit log, and discarding audit entries if the audit log is already full.
Process Tracking	Starting and stopping processes on the computer.
You specify what types of system events are audited through User Manager. You specify what files are audited and how (provided you have used User Manager to turn on the auditing of file accesses) through File Manager.

The following table shows the types of directory and file accesses you can audit.

Directory Access	File Access
Displaying names of files in the directory	Displaying the files data
Displaying directory attributes	Displaying file attributes
Changing directory attributes	Displaying the files owner and permissions
Creating subdirectories  and files	Changing the file
Going to the directorys subdirectories	Changing file attributes
Displaying the directorys owner and permissions	Running the file
Deleting the directory	Deleting the file
Changing directory permissions	Changing the files permissions
Changing directory ownership	Changing the files ownership


The AUDITLOG Utility
Security and WINFRAME	5 of 13

The AUDITLOG Utility

The AUDITLOG utility is used to generate reports of logon/logoff activity for a WINFRAME server based on the WINFRAME security Event Log. To use AUDITLOG, logon/logoff accounting must be enabled.

Syntax

AUDITLOG	[/eventlog:filename] [username|winstation] [/write:filename] [/detail] [/time] [/fail|/all] [/before:mm/dd/yy] [/after:mm/dd/yy]
AUDITLOG	[/clear[:filename]]
AUDITLOG	[/?]

Parameters

/eventlog:filename

Specifies the name of a backup security event log to use as input to AUDITLOG. Create a backup security log from the Event Log Viewer or with the AUDITLOG /CLEAR:filename utility, which saves the current event log in filename and clears the event log.

username

Generates a report of logon/logoff activity for the specified username.

winstation

Generates a report of logon/logoff activity for the specified winstation.

/write:filename

Specifies the name of an output file. Creates a comma-delimited file that can be imported into an application such as a spreadsheet to produce custom reports or statistics.

/detail

Generates a detailed report of logon/logoff activity.

/time

Generates a report of logon/logoff activity for each user, displaying logon/logoff times and total time logged on. Useful for gathering usage statistics by user.

/fail

Generates a report of failed logon/logoff attempts.

/all

Generates a report of all logon/logoff activity.

/clear[:filename]]

Closes the current logon/logoff log file, optionally saves it as filename, and opens a new log file.

/before:mm/dd/yy

Reports on logon/logoff activity only before mm/dd/yy.

/after:mm/dd/yy

Reports on logon/logoff activity only after mm/dd/yy.

/? (help)

Displays the syntax for the utility and information about the utilitys options.

Remarks

AUDITLOG gives the administrator a powerful tool in verifying and maintaining system security and correct usage. The information can be extracted as reports or as comma-delimited files that can be used as input to other programs.

You must enable logon/logoff accounting in order to collect the information used by AUDITLOG. To enable logon/logoff accounting, logon as an administrator and start User Manager. In User Manager, select Audit from the Policies pull-down menu and check the Logon Success and Failure boxes. Choose OK to save your changes.

You can use the at command to set up an automatic procedure that runs AUDITLOG periodically.


User Rights
Security and WINFRAME	6 of 13

User Rights

User rights control who can perform many types of actions on WINFRAME computers. The actions governed by rights include the ability to log on locally at the computer, shut it down, set its time, back up and restore the servers files, and perform other tasks.

On Windows NT domains, rights are granted and restricted on the domain level; if a group has a right in a domain, its members have that right on all primary and backup domain controllers in the domain. On each Windows NT Workstation computer and on each server computer that is not a domain controller, rights granted apply only to that single computer.

User rights	Comments	Granted to Domains	Granted to Workstations and servers
Manage auditing and security log	Specify what types of file and object access are to be audited. View and clear the security log.	Administrators	Administrators
Back up files and directories		Administrators, Server Operators, Backup Operators	Administrators, Backup Operators
Restore files and directories	This right supersedes file permissions. When performing a restore, a user with the Restore right can overwrite files for which he or she has no permissions.	Administrators, Server Operators, Backup Operators	Administrators, Backup Operators
Change system time		Administrators, Server Operators	Administrators, Power Users
Access this computer from network	Access the computer from another workstation on the network.	Administrators, Everyone	Administrators, Power Users, Everyone
Log on locally	Ability to log on at the computer itself, on the computers keyboard, or at a WinStation.	Administrators, Server Operators, Account Operators, Print Operators, Backup Operators	Administrators, Backup Operators, Power Users, Users, Guests
Shut down the system		Administrators, Server Operators, Account Operators, Print Operators, Backup Operators	Administrators, Backup Operators, Power Users, Users, Guests
Add workstations to domain	Allows a user who is not a member of the domains administrators group to add new WINFRAME computers to the domain.	None1	N/A
Take ownership of files and other objects	Take ownership of files and directories on the computer.	Administrators	Administrators
Load and unload device drivers		Administrators	Administrators
Force shutdown from a remote system	This right gives a user no abilities in this version of the operating system, but will be supported in future upgrades of the operating system.	Administrators, Server Operators	Administrators, Power Users

Members of the domains Administrators and Server Operators groups can always add workstations to a domain, whether or not this right is assigned to them. This right is needed only to enable users who are not members of these groups to add workstations to the domain.

For more detailed information and tables showing the rights assigned to the built-in local groups, see What Different Types of Users Can Do in the Concepts and Planning Guide.


Setting Password and Account Policy
Security and WINFRAME	7 of 13

Setting Password and Account Policy

For each domain, you can specify all aspects of password policy: minimum password length (default is six characters), minimum and maximum password age (defaults are 14 and 30 days), and password uniqueness, which prevents a user from changing his/her password to a password that the user has used recently (the default is to prevent users from reusing their last three passwords).

Note

If you use password uniqueness as part of your password policy, be sure to set minimum password age high enough to prevent users from quickly cycling through several temporary passwords to get to their favorite password.

You can also specify these other aspects of account policy:

Whether account lockout occurs

Whether users are forced to disconnect from the domains servers when their logon hours expire

Whether users must log on to change their passwords

When account lockout is enabled, if too many invalid logon attempts occur on a user account and no more than a specified length of time occurs between any two of the logon attempts, the account is locked out. Accounts that are locked out cannot log on. If you enable account lockout, you can specify how many invalid logon attempts cause lockout, the maximum amount of time that can occur between any two of the attempts to trigger lockout, and how long accounts are locked out.

If users are forced to disconnect from servers when their logon hours expire, they are given warnings just before the end of their specified logon hours. If they have not ended their connections by then, the server(s) to which they are connected will end the connection(s). However, users are not forced to log off from their workstations.

If users must logon to change their passwords, they cannot change their passwords after they expire and will need an administrator to change their passwords. If users are not required to log on to change their passwords, they are prompted to change their passwords the first time they attempt to log on after their passwords expire and will not need help from an administrator.


How Administrators Should Log On
Security and WINFRAME	8 of 13

How Administrators Should Log On

Most or all of the administrators on your network have a dual role: they are both administrators and users of the network. Although at times they will perform network administration tasks, at other times they will simply be network users performing the same tasks as other users.

Therefore, it is a good idea for each administrator to have two user accounts. One of these accounts should be in the Administrators group and be the account the administrator uses when performing network management tasks. The other account should be in the Users group in the domain and be the account the administrator uses when not performing network management. The network will be more secure if the administrator uses two accounts.


Allowing Guest Access
Security and WINFRAME	9 of 13

Allowing Guest Access

By default, every domain and every WINFRAME computer initially has a Guest account defined. The Guest account has no password and can be used for two types of Guest logons: local Guest logons and network Guest logons. You can configure each domain and computer so that it allows both types of Guest logon, only one type, or neither.

How Local Guest Logons Work

A local Guest logon occurs when a user logging on at a WINFRAME computer specifies Guest as the user name in the logon dialog box. The Guest user can then work at that computer (subject to the rights and permissions you have granted the Guest account) and use it to access the network.

How Network Guest Logons Work

A network Guest logon occurs at a computer when a user from a domain that the computer does not trust tries to access the computer over the network. The computer allowing the network Guest logon does not recognize the account trying to access it because the computer does not trust that domain. In this case, access is approved as a Guest logon (as long as the Guest account of the target computer has no password). The Guest user then has all rights, permissions, and group memberships on the computer that are granted to the Guest account, even though the Guest user doesnt specify Guest as his/her user name.

Note

If you have set up your network so that all user accounts are defined in domains that are trusted by all other domains, network Guest logons will rarely happen at servers. A network Guest logon can occur only when a user from an untrusted domain tries to access the computer. (Network Guest logons may still happen with user accounts stored at Windows NT Workstation computers or when a user of a DOS computer logs on stand-alone and then accesses a WINFRAME or Windows NT Server computer.)

Managing Guest Logons

If you do not want to allow either local or network Guest logons on a domain, you do not need to do anything; by default, the Guest account is disabled. If you want to allow both local and remote Guest logons, use User Manager For Domains to enable the Guest account. To allow local Guest logons but not network Guest logons, enable the Guest account, but revoke its Access This Computer From Network right. To allow network Guest logons but not local Guest logons, enable the Guest account and revoke its Log On Locally right (be sure Guest has the Access This Computer From Network right).

Managing Guest logons on Windows NT Workstation computers and on servers that are not domain controllers works the same way, except that the Guest account is enabled by default. No action is required if you want to allow Guest logons on the computer. If you want to prevent Guest logons, you must disable the Guest account.

Configuring Users on WINFRAME

To login to WINFRAME, a person must have a userID configured for use on a particular WINFRAME server or on the network domain. If a user is configured for use on a particular WINFRAME server, the user can login and use only that WINFRAME server. If the userID is configured on the network domain, the user can login to any WINFRAME or Windows NT system that has joined the network domain. This makes it far more flexible and allows users to login from anywhere on the network. Access can be restricted to specific WINFRAME servers or can be granted across the network domain. This can be configured in the User Manager for Domains Utility. Refer to Chapter 13 of the System Guide for additional information about this utility.

If you have a Novell NetWare 3.x server on your network, you can move the configured userIDs from the NetWare server to the WINFRAME server. This makes it easy to create accounts on the WINFRAME server by migrating the userIDs already configured for your WINFRAME network. See the WINFRAME Online Readme Migrating UserIDs from a NetWare Server to a WINFRAME Server for more information.


Third-Party Security Devices
Security and WINFRAME	10 of 13

Third-Party Security Devices

This section contains detailed installation and integration information for the following third-party security devices:

Communication Devices Inc. MultiGuard

Digital Pathways Defender 5000 Security System

Security Dynamics Access Control Module System

These security devices are placed between a COM port on the WINFRAME server and the modem for that COM port. They control remote access to the WINFRAME server through proprietary access control hardware and software. The remote user dials in to the modem attached to the security device, and obtains access to the WINFRAME server by successfully completing an authentication dialog with the security device. Once the user has been authenticated, the security device is transparent to the user. A typical external security device configuration is illustrated below.

There are several general configuration issues encountered when using third-party security devices:

For the WINFRAME server to properly detect when a connection is made or broken, the security device must supply modem signals that can be used by the WINFRAME server to detect when a connection is made or terminated. This varies depending on the security device.

The client PC, and the WINFRAME Client software, may need to be configured to operate properly with the security device. Some security systems require software or hardware on the client PC.

The WINFRAME server and the security device itself must be secured from unauthorized tampering. You may want to place all hardware in a secured room to prevent unauthorized personnel from having access to the equipment.

Most third-party security devices secure remote Dial-In users (or local, directly connected async users) only. You may also need to consider how to secure your system from improper access by LAN- or WAN-connected users.


Communication Devices MultiGuard
Security and WINFRAME	11 of 13

Third-Party Security Devices

Communication Devices MultiGuard

The Communication Devices MultiGuard is a hardware-resident data communications security device that protects dial-up access to networks and host computers. MultiGuard verifies that users have authorization and access privileges when users enter IDs, passwords, and personal identifiers. The MultiGuard supports three modes of operation: callback, Dial-In, and network dial out.

There are two main ways to use MultiGuard with WINFRAME: Dial-In and WINFRAME configured with RAS. The MultiGuard allows dial-out and call back with RAS and WinStations, respectively. The MultiGuard system is composed of two major elements:

1.	The MultiGuard hardware, which is a highly secure communications controller that connects and disconnects the input/output lines to the protected host computer

2.	SoftToken Disk, a software solution on the client that optimizes security by allowing access to the host with a diskette configured for that specific users loggin name and password, and an encrypted algorithm password identical to the users records on the MultiGuard)

Note

There is also a hardware SecurNet Key solution where the user does not need the diskette but has a hand-held calculator-like device to help decipher the SoftToken challenge response from the MultiGuard host.

Requirements

Software Requirements

1.	WINFRAME server software Version 1.5 or higher

2.	WINFRAME client software shipped with WINFRAME 1.5 or higher

3.	Communication Devices NetGuard Administrative software for Windows Version 1.08 or higher

4.	Communication Devices SoftToken security disk for use with DOSGuard or WinGuard Version 2.04 or higher

Hardware Requirements

1.	A WINFRAME server with a configured modem

2.	Communication Devices MultiGuard

3.	A client machine with a modem

4.	Proper asynchronous cables as outlined in both the WINFRAME and CDI manuals

Installation

There are two ways to configure a Dial-In connection to a WINFRAME server:

1.	Modem Dial-In to a WINFRAME server via the MultiGuard

2.	Direct-connect to a WINFRAME server via the MultiGuard

To use Dial-In with the WINFRAME Client, make sure you are using the version of the WINFRAME client shipped with Versions 1.6 and later.

Modem Dial-In

Assuming a WinStation is properly configured on the WINFRAME server and Dial-In is able to connect to the WINFRAME server and run a remote control session, use the following procedure to integrate the WINFRAME server with the MultiGuard device:

1.	Use the WinStation Configuration utility on the WINFRAME server to set the WinStation to Connect on DSR. Connect the host modem to a modem port on the MultiGuard via a modem cable.

2.	Connect the WinStation COM port to the MultiGuard host port via a modem cable.

3.	Configure the user of the MultiGuard with Secure Call Thru security.

Note

For installation purposes, you may wish to disable Token Security. After a connection is made to the host through the MultiGuard, configure your client Token disk and host using Token security enabled for that specific user.

4.	From the terminal you used to configure your MultiGuard, login as a MultiGuard administrator.

5.	Under the Port Control menu, select P to modify/review parameters.

6.	Select single card and the card number you are using to connect to your WINFRAME server and set that channel with the following parameters:

Port Security: (1) Enabled
Host to Modem Call Access: (1) Enabled
Baud-Rate: Equal to the speed configured on your WinStation and your Dial-In Client
Bits/Parity: (3) 8, None

7.	Return to the main menu and select System Options.

8.	Select H for Enable/Disable Host to Modem Access and make sure you have this set for Enable.

9.	Under the System Options menu, select U for Security and set it for 1 User ID & Password.

10.	Return to the main menu and select User Functions; select C for change user parameters.

11.	Enter a user who is already in the system and establish the following settings:

User Type: (S) for Secure Call Thru
User Enabled: (A) Always
Delete user if inactive: (N) for No

Usage

1.	Run the WINFRAME Client on the remote client machine.

2.	In the WINFRAME client, select the configured entry that was previously connected to the WINFRAME host.

3.	Dial in to the WINFRAME host. Press ENTER until you receive a login prompt for the MultiGuard. Enter the proper user name and password.

4.	Continue logging into the WINFRAME Dial-In WinStation with your WINFRAME password.

Dial-In

Assuming a WinStation is properly configured on the WINFRAME server and a Dial-In PC is able to connect to the WINFRAME server and run a remote control session, integrate the WINFRAME server with the MultiGuard for a direct asynchronous connection:

1.	Use the WinStation Configuration Utility on the WINFRAME server to set the WinStation to Connect on DSR.

2.	Connect the COM port of the client machine to a modem port on the MultiGuard via a null modem cable.

3.	Connect the host port of the MultiGuard to the WINFRAME server WinStation COM port using a straight modem cable.

4.	Configure the security of a user on the MultiGuard with Secure Call Thru.

Note

For Dial-In you can only use Secure Call Thru with user name and password checking.

5.	From the terminal you used to configure your MultiGuard, login as a MultiGuard administrator.

6.	Under the Port Control menu, select P to modify/review parameters.

7.	Select single card and the card number you are using to connect to your WINFRAME server and set that channel with the following parameters:

Port Security: (1) Enabled
Host to Modem Call Access: (1) Enabled
Baud-Rate: Equal to the speed configured in your WinStation and your Dial-In client
Bits/Parity: (3) 8, None

8.	Return to the main menu and select System Options.

9.	Select H for Enable/Disable Host to Modem Access and make sure you have this set for Enable.

10.	Under the System Options menu, select U for Security and set it for 1 User ID & Password.

11.	Return to the main menu and select User Functions; select C for change user parameters.

12.	Edit a user who is already in the system and establish the following settings:

User Type: (S) for Secure Call Thru
User Enabled: (A) Always
Delete user if inactive: (N) for No

Usage

1.	Run the WINFRAME Client on the remote client machine configured for direct-connect.

2.	In the WINFRAME client, select the configured entry that was previously connected to the WINFRAME host.

3.	Connect into the WINFRAME host. Press ENTER until you get to a login prompt for the MultiGuard. Enter the proper user name and password.

4.	Continue logging into the WINFRAME Dial-In WinStation with your WINFRAME password.

Modem Dial-In Usage With Token Security Checking Enabled for a User

1.	Configure a SoftToken disk and the MultiGuard for a specific user who has security set for Token.

2.	Run the remote DOS or Windows SoftToken security TSR that is supplied with the MultiGuard on the remote client machine (DOSGuard or WinGuard).

Note

WinGuard must be installed while DOSGuard is a single executable file.

3.	Run the WINFRAME client on the remote client machine.

4.	In the WINFRAME client, select the configured entry that was previously connected to the WINFRAME host.

5.	Dial in to the WINFRAME host.

Note

For Dial-In using Token security, the client machine must be running WinGuard with a DCD delay of at least ten seconds and the user must quickly make the direct-connect asynchronous connection immediately after running this. Once you are connected, the MultiGuard software automatically enters the required information such as user name, password, and security challenge.

6.	Continue logging into the WINFRAME WinStation with your WINFRAME password.


Digital Pathways Defender 5000
Security and WINFRAME	12 of 13

Third-Party Security Devices

Digital Pathways Defender 5000

The Digital Pathways Defender 5000 is a hardware-resident data communications security device that protects dial-up access to networks and host computers. Defender 5000 verifies that users have authorization and access privileges when they enter usernames, passwords and personal identifiers. The Defender 5000 supports three modes of operation: callback, Dial-In, and dial-out over the network.

There are two main ways to use the Defender with WINFRAME: Dial-In and WINFRAME configured with RAS. The Defender 5000 allows dial-out and call-back with RAS and WinStations, respectively. The Defender 5000 system is composed of two major elements:

1.	The Defender 5000 hardware, which is a highly secure communications controller that connects and disconnects the input/output lines to the protected host computer

2.	SNK Disk, a software solution on the client that optimizes security by allowing access to the host with a diskette configured for that specific users login name and password, and an encrypted algorithm password identical to the users records on the Defender 5000.

Note

There is also a hardware SecureNet Key solution which uses a hand-held calculator-like device to decipher the SNK challenge response from the Defender 5000 host.

Requirements

Software Requirements

1.	WINFRAME server software Version 1.5 or higher

2.	WINFRAME client software Version 1.5 or higher

3.	Digital Pathways Super Administrative software Version 2.07

4.	Digital Pathways WinSNK software user disk for DOS and Windows versions; WinSNK 1.21, Filter 1.20, and Driver 1.20 or higher.

Hardware Requirements

1.	A WINFRAME server with a configured modem

2.	Digital Pathways Defender 5000

3.	A client machine with a modem

4.	Digital Pathways Hardware SecureNet Key (not required if using a WinSNK user disk)

Using Digital Pathways Hardware with Citrix WINFRAME ICA Connections

Installation

There are two methods of making a Dial-In connection to the WINFRAME server:

1.	Modem Dial-In to a WINFRAME server via the Defender 5000

2.	Direct-connect to a WINFRAME server via the Defender 5000

Note

To use the WINFRAME Windows clients with asynchronous connections, WINFRAME Client software Version 1.6 or higher is required. Version 1.5 of the WINFRAME Client did not support async connectivity for the Windows clients.

Modem Dial-In

Assuming a WinStation is properly configured on the WINFRAME server and a remote client is able to dial into the WinStation and run a remote control session, do the following to integrate the WINFRAME server with the Defender 5000:

1.	Use WinStation Configuration to set the WinStation to Connect on DCD.

2.	Connect the host modem to a modem port on the Defender 5000 via a modem cable.

3.	Connect the WinStation COM port to the Defender 5000 host port via a modem cable.

4.	Configure the host port of the Defender 5000 with SNK security checking disabled.

Note

For installation purposes, you may wish to disable SNK Security within the Defender 5000. After a connection is made to the host through the Defender, configure your client SNK disk and host using SNK security enabled.

5.	From the terminal you used to configure your Defender 5000, login as a Defender 5000 administrator.

6.	Under the Status/box menu of the Defender 5000, select the board and channel you are going to use for your connection.

7.	Configure this channel with the following parameters:

Program: DC (Direct Connect)

Modem Type: Options 0-9 (select the modem type you are using at the host end)

Host Name: A-Z (this is the host name assigned for security purposes; the letter designated here must also be used in each users individual record under the [4] OK Hosts menu)

Init Rate: Equal to the baud setting of the dial-in modem and the WINFRAME ICA WinStation

8.	Run the WINFRAME Client on the remote client machine.

9.	In the WINFRAME client, select the entry that was previously connected to the WINFRAME server.

10.	Dial into the WINFRAME server.

11.	Press ENTER until you get to a login prompt for the Defender. Enter the user name and password that have security privileges to the host/modem port of the Defender.

12.	Continue logging into the WINFRAME Dial-In WinStation with your WINFRAME password.

Direct Connect

Assuming a WinStation is properly configured on the WINFRAME server and a direct connect client is able to connect into a WinStation and run a remote control session, do the following to integrate the WINFRAME server with the Defender 5000 for a direct asynchronous connection:

1.	With the Configuration Utility of the WINFRAME server, set the WinStation to Connect on DCD.

2.	Connect the COM port of the client machine to a modem port on the Defender 5000 via a null modem cable.

3.	Connect the host port of the Defender 5000 to the WINFRAME server WinStation COM port.

4.	Configure the host port of the Defender 5000 with SNK security checking disabled.

Note

For installation purposes, you may wish to disable SNK Security within the Defender 5000. After connection is made to the host through the Defender, configure your client SNK disk and host using SNK security enabled.

5.	From the terminal you used to configure your Defender 5000, login as a Defender 5000 administrator.

6.	Under the Status/box menu of the Defender 5000, select the board and channel you are going to use for your connection.

7.	Configure this channel with the following parameters:

Program: DC (Direct Connect)

Modem Type: Options 0-9 (select the modem type you are using at the host end)

Host Name: A-Z (this is the host name assigned for security purposes; the letter designated here must also be used in each users individual record under the [4] OK Hosts menu)

Init Rate: Equal to the baud setting of the dial-in modem and the WINFRAME WinStation

8.	Run the WINFRAME Client on the remote client machine.

9.	In the WINFRAME client, select the configured entry that was previously connected to the WINFRAME server.

10.	Connect to the WINFRAME server.

11.	Press ENTER until you get to a login prompt for the Defender. Enter the user name and password that have security privileges to that specific Defender port.

12.	Continue logging into the WINFRAME WinStation with your WINFRAME password.

Direct Connect and Modem Dial-In Usage With SNK Checking

1.	Configure an SNK user disk and the Defender 5000 for a specific user to have access privileges to the designated host/modem port.

2.	Configure the Defender 5000 for SNK security checking enabled for the Defender host port.

3.	Run the remote DOS or Windows SNK security TSR that is supplied with the Defender 5000 on the remote client machine (SNK.EXE /V).

4.	Run the WINFRAME client on the remote client machine.

5.	In the WINFRAME client, select the configured entry that was previously connected to the WINFRAME server.

6.	Dial or connect to the WINFRAME server.

7.	When connected, press ENTER and enter a valid user name and password for the Defender 5000. If you are using the right version of SNK software, the SNK challenge will automatically be echoed.

8.	Continue logging into the WINFRAME WinStation with your WINFRAME password.

Using Digital Pathways Hardware with Citrix WINFRAME RAS

The following chart lists connectivity options for the various WINFRAME clients and their compatibility with remote node dial-in connections. The top row indicates the WINFRAME client being used to run a remote control session. The left-hand column identifies the dial-up (remote node) client being used. The intersection states which protocols can be used for that particular combination of WINFRAME client and remote node client. (No means this combination is not currently possible.)

Note

For the RAS configurations, a dial-up connection to a RAS server must be established first. This is a remote node connection. A WINFRAME client can then be used to connect to a WINFRAME server over the dial-up connection. This is a remote control session (over a remote node session).

Remote Node Client Software	DOS Client	Win16 Client	Win32 Client
Windows 3.1 RAS	No	NetBIOS	No
Citrix WINFRAME or Windows NT 3.5x RAS	No	No	NetBIOS IPX/SPX TCP/IP
Windows 95 Dial up Networking	No	No	NetBIOS IPX/SPX TCP/IP
WINFRAME Dial-Up Manager for DOS	IPX/SPX TCP/IP	IPX/SPX TCP/IP	No
WINFRAME Dial-Up Manager for Windows 3.1x	No	IPX/SPX TCP/IP	No

Installation

To ensure proper security and configuration settings, set up a remote node client to dial in and make a connection to a WINFRAME RAS server without the Defender 5000 product connected. Run the remote control software provided with WINFRAME to ensure a proper connection to the WINFRAME server. Consult the WINFRAME documentation for settings and installation.

Note

When RAS is installed and configured, you must use RAS Admin to enable dial-in access for each user.

WINFRAME RAS Server Configuration

1.	Use the RAS Admin icon under Server/Stop Remote Access Service to shut down RAS before continuing with the next step.

2.	With a text editor, edit the modem.inf file located in <WinDir> \system32\ras. Set the MAXCONNECTBPS= to match the speed of your modem and channel baud rate of the Defender 5000. This is also the maximum baud rate for the dial-in remote node software you are using.

Note

In the Defender 5000, the channel baud rate is located in the Status/box menu and designated as rate when the particular host port is highlighted. You will need to set this when you reach that part of the installation.

3.	Reboot your system for these changes to take effect.

4.	Connect and configure modems and clients.

5.	On the remote computer, you now have a remote node client and a remote control client configured for connection to a WINFRAME server. Test this again; if it does not work, change the MODEM.INF file until a proper baud-rate is chosen and a connection is made.

Defender 5000 Configuration

1.	Using a modem or straight-through cable, connect the Defender 5000 between the WINFRAME server serial port and the server modem.

2.	Contact Digital Pathways for a Lingo script file (NT-RAS35.LNG), which was written to allow the WINFRAME remote access server to communicate to the modem via the Defender 5000 for modem initialization. This file has to be uploaded into the Defender 5000. This file must also be edited for a modem type and Digital Pathways should be consulted for the proper modification.

3.	Once the script is installed for a specific modem type, reboot the Defender and configure the host port that will be used.

4.	Temporarily disable SNK checking. When the system is configured, re-enable it in the Defender 5000 for the specific user class.

5.	Configure the Defender host port with the following settings:

Program: DC (Direct Connect)

Modem Type: Options 0-9 (select the modem type you are using at the host end). Note the NT-RAS35.LNG script file points to a specific modem. If you change this, you must also change your lingo script file.

Host Name: A-Z (this is the host name assigned for security purposes; the letter designated here must also be used in each users individual record under the [4] OK Hosts menu)

Init Rate: Equal to the baud setting of the dial-in remote node client and the MAXCONNECTBPS setting you selected in your MODEM.INF file above.

Remote node and remote control client connection

1.	Connect and configure modems and clients.

2.	Dial into the RAS port with a remote node client with the following settings:

Terminal mode on connect: enabled

Baud-rate: equal to the channel baud rate settings of the Defender 5000 and WINFRAME RAS Server

Note

This baud rate cannot exceed the baud speed of the host modem or remote modem.

Protocol: IPX, TCP/IP, or NetBIOS

3.	Press ENTER twice to receive a login prompt for the Defender 5000.

4.	Enter the Defender 5000 user name and password.

5.	You have passed Defender security and are now connected to the WINFRAME RAS server.

6.	If you have entered your WINFRAME user name and password in your dial-up remote node client, you will be authenticated and logged on to the network automatically. If not, you will be prompted to enter your user name and password now.

7.	Depending on which protocol you are using, run ping (TCP/IP), net use (NetBIOS), or slist (IPX/SPX) to verify that you are connected to the network properly.

Note

If your remote workstation has a network connection, unplug it temporarily to verify that the network status reported in the previous step is actually from the modem.

8.	Run the remote control client and establish a remote control session.

9.	Enable SNK password checking on the Defender. On the client end, you must run the SNK client software before you dial up with your remote node client. Be sure to use a /v option when running (e.g., SNK.EXE /v).

Note

Make sure you are using the correct versions of the DOS SNK and the WinSNK programs.


Security Dynamics Access Control Module
Security and WINFRAME	13 of 13

Third-Party Security Devices

Security Dynamics Access Control Module

The Security Dynamics Access Control Module is a hardware-resident access-control system with accompanying credit card size SecurID cards. When installed in a physically secure area and used properly, the ACM protects a WINFRAME server by preventing unauthorized persons from access, while allowing authorized users to gain entry easily.

The Security Dynamics ACM system can be used to secure:

1.	WINFRAME remote access connections

2.	WINFRAME ICA dial-in connections

The ACM does this without restricting ports to Dial-In only. The ACM allows dial out and call back with RAS and WinStations, respectively. The Security Dynamics ACM system is composed of two elements:

1.	The Access Control Module (hardware), which is a highly secure communications controller that connects and disconnects the input/output lines to the protected host computer.

2.	The SecurID card(s), credit card size unit(s) that calculate and display codes that change unpredictably at a specified interval.

Requirements

1.	Citrix WINFRAME server Version 1.5 or higher

2.	Security Dynamics Equipment

3.	ACM/400 hardware running software, Version 1.12A or later

4.	SecurID cards.

Note

One of the cards must be an administrator level card.

Using Security Dynamics Hardware with Citrix WINFRAME RAS

Below is a chart listing connectivity options for the various WINFRAME clients and their compatibility with remote node Dial-In connections. The listing across the top row indicates the WinFrame client being used to run a remote control session. The listing along the left-hand column identifies the dial up client being used.

Note

For the RAS configurations, a dial up connection to a RAS server must be established first. Then, a WINFRAME client can be used to connect to a WINFRAME server over the dial up connection.

Remote Node Client Software	DOS Client	Win16 Client	Win32 Client
Windows 3.1 RAS	No	Yes NetBIOS only	No
Citrix WINFRAME or Windows NT 3.5x RAS	No	No	Yes
Windows 95 Dial up Networking	Yes	No	Yes
WINFRAME Dial-Up Manager for DOS	Yes	Yes	No
WINFRAME Dial-Up Manager for Windows 3.1x	No	Yes	No
Integration

Install the WINFRAME server. To ensure working configurations, connect and configure terminals and remote PCs without the SecurID product.

Note

For best asynchronous connectivity performance, equip the WINFRAME server with an intelligent multiport adapter.

Two connectivity scenarios are described utilizing the SecurID equipment with the WINFRAME server:

1.	The ACM connected to a WINFRAME RAS server for Dial-In and dial out

2.	The ACM connected to a WINFRAME WinStation port for Dial-In and call back

WINFRAME RAS Server Configuration

1.	With a text editor, edit the MODEM.INF file located in <WinDir> \system32\ras. Find the specific modem you are using and set MAXCONNECTBPS= to match the speed of your modem and ACM.

Note

The fastest baud rate that the ACM currently can handle is 38400. This must be done before configuring the RAS port for a specific modem.

2.	Install and configure RAS.

3.	Connect and configure modems and clients.

4.	Dial into the RAS port with a valid client to verify that the RAS connection works.

WINFRAME Server WinStation Configuration

1.	Run WinStation Configuration in the Administrative Tools group.

2.	Create a new WinStation and select a transport (NetBIOS, IPX, or TCP/IP), depending on the client you will be running.

ACM Configuration

1.	Using modem or straight-through cables, connect the ACM between the WINFRAME port and the host modem.

2.	With a TTY terminal client, dial into the host modem connected to the DTE terminal on the ACM or connect via direct connect to the DTE input of another port using a null modem cable.

3.	Select different baud rates until you receive an Enter PASSCODE: prompt in terminal mode.

4.	Enter an ADMIN SecurID passcode to enter the Administration utility.

5.	Configure the ACM for valid users and SecureID cards.

Note

You must have the SecurID serial number found on each SecurID card configured for each specific user who will have access to the ACM. Under the Main Administration menu, go to channel settings to configure the ports. Set the modem port as follows:

Baud rate: equal to the RAS server and modem. The fastest baud rate that the ACM currently can handle is 38400

Data Bits: 7 or 8 to match the RAS server (default = 8)

Parity: None, Even Odd, Mark, or Space to match RAS server

Protocol: DCD at modem and DCD at host (default = d-d)

Host Command Mode: Enable, Text, same as channel baud rate (t##)

Dialout: Y (enabled)

Note

Always have dial out enabled on the ACM so that it allows the RAS server to initialize and set the modem to auto-answer after each call. Also, for dial out to function properly, your ACM hardware may require host and modem adapters to be attached to each port of your ACM. Various revisions of the ACM hardware exist, requiring different models of these adapters.

Note

In order for the ACM to function properly, it is very important that the cables used to connect devices to the ACM hardware are properly configured. The cables should include the following pins: 1, 2, 3, 4, 5, 6, 7, 8, 29, and 22. The dial out option, in particular, is reliant on pin 22 (Ring Indicator) to function properly. The cable connecting the modem to the ACMs DTE port must support pin 22 or the dial out function will not work. When the ring indicator connection protocol is selected, the cable connecting the ACM on either the modem or the host side of the ACM will require pin 22, depending on the particular setting selected.

RAS Client

1.	Install the client dial in software you want to use.

2.	Create an entry.

3.	Select the compatible transport.

4.	Set the baud rate you selected under RAS Client above.

5.	Select a setting; i.e.,Terminal mode on connect, Post Connect Terminal mode, or similar variations.

6.	Dial into the RAS Server/ACM/modem with proper user name and password (if not already configured).

7.	The terminal screen will appear and an Enter PASSCODE: prompt will be displayed. Type your PIN and CARDCODE and press ENTER.

8.	Run the appropriate WINFRAME client.

WINFRAME Client Software

1.	Install and run the appropriate WinFrame client.

2.	Add a new entry and select user-specific settings and the following:

Transport: NetBIOS, IPX, or TCP/IP (depending on what type of transport the WinStation is configured for

Device :COM#:(same baud as WinStation, modem connected to client)

Phone Number: Phone number of the Dial-In WinStation modem

3.	Select the configured entry to dial into the WinStation. An Enter PASSCODE: prompt will appear. Type your PIN and CARDCODE and press ENTER.

Using Security Dynamics Hardware with Citrix WINFRAME Dial-In

The WINFRAME Client is supported by the ACM for direct connections and for modem connections used for both Dial-In only and Dial-In and call back.

WINFRAME Server WinStation Configuration

From the WINFRAME console, use the WinStation Configuration utility in the Administrative Tools program group to configure an ICA Dial-In WinStation terminal with the following parameters:

Transport: Async

Device: The COM port connected to the modem via the ACM.

Baud rate: Match the ACM and the modem. The fastest baud rate that the ACM currently can handle is 38400.

Device connect on: DCD

Modem: Choose none for a direct asynchronous connection or select a modem. If your modem is not listed, select a compatible modem or check your modem documentation for proper initialization strings.

ACM Configuration

1.	Using a modem or straight-through cable, connect the ACM between the WINFRAME WinStation COM port and the modem.

2.	With a TTY terminal client, dial into the host modem connected to the DTE terminal on the ACM or connect via direct-connect to the DTE input of another port using a null modem cable.

3.	Select different baud rates until you receive an Enter PASSCODE: prompt in terminal mode.

4.	Enter an ADMIN SecurID passcode to enter the Administration utility.

5.	Configure the ACM for valid users and SecurID cards.

6.	Under the Main Administration menu, go to channel settings to configure the ports. Set the modem port as follows:

Baud rate: The fastest baud rate that the ACM currently can handle is 38400

Data Bits: 7 or 8 to match the RAS server (default = 8)

Parity: None, Even Odd, Mark, or Space to match RAS server

Protocol: DCD at modem and DCD at host (default = d-d)

Host Command Mode: Enable, Text, same as channel baud rate (t##)

Dialout: Y (enabled)

Note

Always have dial-out enabled on the ACM so that it allows the WinFrame server to initialize and set the modem to auto-answer after each call. For dial-out to function properly, your ACM hardware may require host and modem adapters to be attached to each port of your ACM. Various revisions of the ACM hardware exist, requiring different models of these adapters.

Note

In order for the ACM to function properly, it is very important that the cables used to connect devices to the ACM hardware are properly configured. The cables should include the following pins: 1, 2, 3, 4, 5, 6, 7, 8, 29, and 22. The dial-out option, in particular, is reliant on pin 22 (Ring Indicator) to function properly. The cable connecting the modem to the ACMs DTE port must support pin 22 or the dial-out function will not work. When the ring indicator connection protocol is selected, the cable connecting the ACM on either the modem or the host side of the ACM will require pin 22, depending on the particular setting selected.

WINFRAME Client Software

1.	Install and run the WINFRAME Client.

2.	Add a new entry and select user specific settings and the following:

Transport: serial

Device: COM# (same baud rate as WinStation, modem connected to client)

Phone Number: phone number of the Dial-In WinStation modem

3.	Select the configured entry to dial into the WinStation. An Enter PASSCODE: prompt will be displayed. Type your PIN and CARDCODE and press ENTER.


Internet Connectivity and WinFrame
Chapter 4	1 of 2

Internet Connectivity
and WINFRAME

WINFRAME application servers can be used to solve common Internet requirements:

WINFRAME allows access providers to create a Windows Internet gateway, giving customers easy access to the Internet.

WINFRAME allows any organization to easily publish information over the Internet using conventional Windows applications and tools to create interactive Windows Internet services.

WINFRAME gives local LAN users Internet access without having to install TCP/IP software on each workstation, and also requires only one IP address for all users.

See the following illustration for sample Internet Windows gateway and Interactive Windows Internet service configurations.


How to Connect WinFrame to the Internet
Internet Connectivity and WINFRAME	2 of 2

How to Connect WINFRAME to the Internet

In order to connect a WINFRAME server to the Internet, you need three components:

An Internet leased line (56KB, T1, T3)

An Internet router (IP)

An optional Internet firewall between your LAN and the Internet

The Internet Leased Line

Contact an Internet access provider to get an Internet leased line. Your provider can also give you guidelines for selecting the proper line speed (56KB, T1, or T3). Some of the major Internet access providers are:

CERFnet
Contact: Sales Manager
Phone: (800) 876-2373, (619) 455-3900
Fax: (619) 455-3990
E-mail: Sales@cerf.net

Delphi Internet Services Corp.
Contact: Walt Howe
Phone: (800) 695-4005
Fax: (617) 491-6642
E-mail: walthowe@delphi.com

NEARnet
Contact: NEARNET information hotline
Phone: (617) 873-8730
Fax: (617) 873-5620
E-mail: nearnet-join@near.net

Netcom On-Line Communication Services
Contact: Sales
Phone: (800) 501-8649, (408) 554-8649
Fax: (408) 241-9145
E-mail: info@netcom.com

OARnet
Contact: Sales
Phone: (800) 627-8101, (614) 728-8100
Fax: (614) 728-8110
E-mail: info@oar.net

PSINet
Contact: Sales
Phone: (800) 82PSI82, (703) 620-6651
Fax: (703) 620-2430
E-mail: info@psi.com

The Internet Router

Your Internet access provider can help you select an Internet router for your connectivity needs. For instance, if you have a Novell NetWare LAN and want to gain Internet access from any LAN workstation, you will need a router that can handle IP packets.

Routers are hardware or software systems that manage the exchange of information (in the form of data packets) between network cabling systems. Routers are "intelligent"  they not only pass packets between different cabling systems but they also route the packets through the most efficient path.

Routers can also connect cabling systems that use different kinds of transmission media and different addressing systems. For example, a router can connect a local Ethernet 10BASE-T network to the Internet using a 56Kbps leased digital line.

The Internet Firewall (Optional)

If the WINFRAME Internet server will be connected to an existing network, you may want to consider using a firewall system to prevent unauthorized users from accessing your LAN. Firewall systems allow outgoing TCP/IP packets to flow freely, while they reject or filter any incoming TCP/IP packets such as electronic mail, remote terminal sessions, or file transfers.

Note

A WINFRAME server does not need to be connected to a network in order to service information over the Internet. If the data and programs are available on the WINFRAME server hard drive, you can create a stand-alone WINFRAME Internet server. Such a configuration does not require a firewall system because all the information available to the Internet is directly protected by the WINFRAME security system.

When connecting WINFRAME to the Internet, you have two types of firewall options. One option is to use a dedicated firewall system to filter any Internet TCP/IP packets that travel into your LAN, as illustrated below:

The second option is to use WINFRAME as a firewall. This method requires two network cards in your WINFRAME server. One card is configured for TCP/IP and is connected to your Internet router. The second network card is configured for IPX and is connected to your local network, as illustrated below:

For instance, in a Novell NetWare environment, one card manages the TCP/IP traffic coming from the Internet while the other card manages only the IPX traffic coming from the LAN.

To use this option, it is recommended that you use a restricted Windows application shell instead of the Windows Program Manager. A restricted shell limits the applications an Internet user can access and restricts any access to system command prompts. This type of configuration effectively controls access to the information you want to publish over the Internet in a fully secured environment.

For additional information concerning the Internet firewall, refer to Firewalls and Internet Security, Repelling the Wily Hacker, William R. Cheswick and Steven M. Bellovin, ISBN 0-201-63357-4, and Building Internet Firewalls, D. Brent Chapman and Elizabeth D. Zwicky, ISBN 1-56592-124-0.


Remote Node Connectivity Products
Chapter 5	1 of 7

Remote Node Connectivity Products

Remote LAN node products allow a remote PC to dial in to a computer on the local network running a remote node product, also called the remote node server, and appear as a LAN workstation. After the remote node connection is established, the remote computer can access network resources on a WINFRAME server or use the WINFRAME Client to establish a remote node + remote control user session. WINFRAME/Enterprise contains a native remote node solution called WINFRAME Remote Access Service (RAS) that is compatible with many third-party remote node solutions.

Remote node and remote control are two distinct, but compatible, methods of remotely accessing a WINFRAME server. A remote node session accesses the WINFRAME server through a network emulation layer that causes the remote connection to emulate a LAN connection. A remote control session uses the WINFRAME Client to execute applications on the WINFRAME server and uses the client PC for presentation services (display, keyboard, and mouse data) only. Remote users can simultaneously run applications using remote node and applications using remote control.

With WINFRAME remote node, users become true network nodes and gain total network transparency. Remote node also allows remote users to work detached from the network and connect to it only when required.

WINFRAME remote control support provides remote users with the high performance they need to run applications outside the network. Remote control requires users to work connected to the WINFRAME server. This mode is particularly well-suited for applications that are designed to run over the network. The WINFRAME Client also supports Dial-In remote control to the WINFRAME server.

Some typical remote node configurations are shown below.


Remote Connection Bandwidth Constraints
Remote Node Connectivity Products	2 of 7

Remote Connection Bandwidth Constraints

Remote users such as mobile workers, telecommuters, and branch office personnel work outside the boundaries of a high-speed LAN. They connect to the LAN using communications media such as standard telephone lines, WAN links (T1, T3, 56kb, or X.25), broadband connections (ISDN, Frame Relay, or ATM), or the Internet.

Remote connections are orders of magnitude slower than traditional high-speed Local Area Networks. The most commonly used links are phone lines. The following table shows the dramatic constraints on bandwidth (kilobytes per second) and data round trip times (latency) for remote users using various connection methods:

Connection	Bandwidth	Latency
Modem	2400 - 28800 bps	0.2 - 2 seconds
Leased Line	9600 - 56000 bps	0.005 - 1 seconds
LAN	4000 - 100000 Kbps	0.0005 - 0.001 seconds
Application Considerations

Most applications can be placed into one of two categories:

Bandwidth-demanding applications. These applications are designed to run over high-speed network connections. Most existing applications fall into this category.

Bandwidth-efficient applications. These applications are designed to run over low-speed connections. Many new applications fall into this category.

Bandwidth-Demanding Applications Need
Remote Node + Remote Control

Bandwidth-demanding applications include shared database applications, two-tier client/server database applications, and many other legacy applications for DOS or Windows.

These applications have been designed to run over high-speed networks and typically require large amounts of data to travel between the client PC and the database or file server. To illustrate why bandwidth-demanding applications need  remote control, consider two-tier client/server applications, which are the most bandwidth-efficient applications in this category. Two-tier client/server applications require much less bandwidth than shared database or legacy applications, because they are designed to send a compact request to a database server, which will send only results to the client PC.  However, a typical two-tier client/server application, such as a customer tracking database, might need to exchange 50 criteria before transferring the required data to the client.

The table below shows typical response times encountered performing a request that exchanges 50 criteria over three different types of network connections:

Transport	Bandwidth	Latency	Minimum Response Time
LAN	10 Mbps	0.0005 seconds	0.025 seconds
Leased Line	56 Kbps	0.1 seconds	5 seconds
Modem	14.4 Kbps	0.4 seconds	20 seconds

The example below illustrates the performance problem of a two-tier client/server application running over a low speed remote node connection. In this case, the client portion of the application runs on the remote PC and the server portion runs on a database server on the network. To execute a transaction, the application would exchange 50 criteria between the remote PC and the database server before transferring the required data to the client. These exchanges are performed over a 14.4Kbps modem connection. The resulting response time for the user is 20 seconds.

The example below illustrates the performance of a two-tier client/server application running over a low speed connection using combined remote node and remote control modes. In this case, the client portion of the application runs on the WINFRAME server connected to the LAN, and the server portion runs on the database server. To execute a transaction, the application would exchange 50 criteria between the WINFRAME server and the database server before transferring the required results to the client. In this case, the criteria are exchanged over a 10Mbps LAN connection instead of a 14.4Kbps modem connection. The 10Mbps LAN connection is nearly 700 times faster than the 14.4Kbps modem connection. In this scenario, the latencies for the transmission of the user interface results to the client PC using the Citrix ICA 3.0 protocol is negligible, and the resulting response time for the user is in the range of 0.025 seconds.

Using remote node and remote control together with Citrix WINFRAME and the WINFRAME Client gives the user the best of both worlds - the transparent network access of remote node, and the high performance of remote control.

Bandwidth-Efficient Applications Need Only Remote Node

Bandwidth-efficient applications include three-tier client/server applications, replicated database applications, and workgroup and productivity applications.

The most efficient applications within this group are three-tier client/server applications. These applications are composed of three components:

The client that manages the application user interface and runs on the remote PC.

The agent that performs the business logic of the applications and runs on a server connected to the network.

The database server that stores the data, executes SQL database commands, and runs on a server connected to the LAN.

With this architecture, designed to run over low speed network connections, only small compact requests travel between the client PC and the agent server. Large SQL requests are performed on the network between the agent and the database server.

Lets take again the example of a three-tier client/server application, such as a customer tracking database, which might exchange 50 criteria between the agent and the database server and then send the required results to the client. In this scenario, the transmission of the user interface results to the client is negligible, and the resulting response time for the user is in the range of 0.025 seconds.


Third-Party Remote LAN Node Connectivity Solutions
Remote Node Connectivity Products	3 of 7

Third-Party Remote LAN Node Connectivity Solutions

Vendor	Model	Version	Notes
3Com	AccessBuilder	2.01
Attachmate	Remote LAN Node	2.0x
Novell	NetWare Connect	2.01
Shiva	LAN Rover Family	3.0	Download latest Shiva updates from Shiva BBS (617) 273-0023.


3Com Access Builder
Remote Node Connectivity Products	4 of 7

3Com AccessBuilder

The 3Com AccessBuilder 2000 is a remote node solution that allows remote client systems to access a network via modem. The AccessBuilder 2000 series family consists of RISC-based multi-protocol, multiport networking devices. These offer a simple and cost-effective solution for remote users to access the corporate network for data transmission or retrieval using the Public Switched Telephone Network (PSTN). A system consists of a hardware unit and client software used to establish an asynchronous modem connection to a network. Protocols supported are IPX, TCP/IP, and NetBEUI.

Once the modem connection to the AccessBuilder has been established, the remote user can run a WINFRAME client to start a remote control session on the WINFRAME  server. Running a remote control session on the WINFRAME server in this manner allows fast access to the network, quick application response, fast processing, and total access to the network over a remote connection. In addition, the remote user has the ability to simultaneously run his/her own point-to-point (PPP) network applications locally while still running a remote control session.

Requirements

Software Requirements

WINFRAME, Version 1.5 or higher

WINFRAME Client, Version 1.5 or higher

3Com AccessBuilder, Version 2.0 or higher

Hardware Requirements

A WINFRAME server

A 3Com AccessBuilder 2000 with at least one modem

A client machine with a modem able to dial in to the AccessBuilder

A network linking the WINFRAME host and the 3Com AccessBuilder

Connectivity Requirements Usage Chart

Below is a chart listing the connectivity options available for using the 3Com AccessBuilder in conjunction with a WINFRAME client. The listings across the top row indicate the dial-in options available to make a remote node connection. The listings in the left hand column identify the WINFRAME client options used to make a connection to a WINFRAME server.

Note

A dial-up connection to the 3Com AccessBuilder must first be established between the client machine and the 3Com AccessBuilder. The WINFRAME client can then be used to connect to a WINFRAME server over the dial-up connection for a remote node + remote control session.

	3Com Dial in client for DOS	3Com Windows 3.1 Dial in client	WINFRAME DOS Dial-up Manager	WINFRAME Win16 Dial-up Manager	Windows 95 Dial-up Networking	WINFRAME RAS
DOS  Client	Yes	No	Yes	No	No	No
Win16 Remote Application Manager	Yes	Yes	Yes	Yes	No	No
Win32 Remote Application Manager	No	No	No	No	Yes	Yes
System Integration

The following steps describe how to integrate the 3Com AccessBuilder with the WINFRAME server. For simplicity, IPX connections are used. For help on IP with IPX, or IP alone, please consult the appropriate documentation for the specific setup you want to configure.

To integrate 3Com AccessBuilder with WINFRAME

1.	WINFRAME Server

Ensure that the WINFRAME server is up and running. Use the WinStation Configuration Utility in the Administration Tools Group to determine that IPX WinStations are available on the WINFRAME server.

2.	3Com AccessBuilder Host

Follow the normal installation procedure as defined in the documentation provided with AccessBuilder. The 3Com administration software must be installed on a Windows 3.1x client. This machine must reside on the same network as AccessBuilder.

When the software is installed and AccessBuilder is connected to the network, configure AccessBuilder. This includes creating users with network access privileges.

3.	Dial-In Clients (choose one of the following to be installed on the remote users machine)

3Com AccessBuilder Dial-up Client for DOS
Follow the installation procedure defined in the documentation provided with the AccessBuilder Remote Client.

Run ABSETUP.BAT to configure your dial-up client. You will need to configure modem type, COM port, baud rate, login user name, phone number to dial, and other information. When you are done entering the appropriate information, run ABLOGIN.BAT. Your remote client will not initialize the modem and dial into the AccessBuilder 2000.

After you have successfully logged in, return to a DOS prompt. Execute a NetWare command; for example, nlist, to verify that you have a valid network connection.

Hang up the connection and go to step 4.

3Com AccessBuilder Dial-Up Client for Windows
Follow the installation procedure defined in the documentation provided with the AccessBuilder Remote Client and then proceed to step 4.

WINFRAME Client for DOS Dial-Up Manager
Install the WINFRAME Client for DOS as described in Chapter 3 of the WINFRAME Client Users Guide. Install Dial-Up Manager. Go to step 4.

WINFRAME Client for Windows (Win16) Dial-Up Manager
Install the WINFRAME Client for Windows (Win16) described in Chapter 6 of the WINFRAME Client Users Guide. Install Dial-Up Manager. Go to step 4.

Windows 95 Dial-up Networking
Under the Windows 95 Control Panel/Add-Remove Programs, choose the Windows set up, double-click Communications, and select Dial-up Networking.

Under Control Panel/network/configuration/protocol, choose Add and select protocol/Microsoft. Select TCP/IP and/or IPX-SPX. Go to step 4.

WINFRAME RAS Server
From the console, select Control Panel, Network, and choose add software. Select Remote Access Service. Install as described in the WINFRAME documentation. Go to step 4.

4.	For WINFRAME clients, choose one of the following to be installed on the remote users client system:

If the client system is a DOS system, install the WINFRAME client for DOS.

If the client system is a Windows 3.1x or Windows for Workgroups system, install the WINFRAME Win16 client.

If the client system is a Windows 95 or Windows NT system, install the WINFRAME Win32 client.

Refer to the WINFRAME Client documentation for installation instructions. When installing the DOS or Win16 WINFRAME client, install only the Remote Application Manager if you are using a third-party PPP dial-in client. The third-party software supplies the remote node networking connectivity. Only install the Dial-Up Manager if you intend to use the WINFRAME Client Dial-Up Manager for remote node connectivity.

Usage

1.	Ensure that an appropriate WINFRAME WinStation is configured and available (for example, an IPX WinStation).

2.	From the client system, establish a remote node connection to the network by dialing into the AccessBuilder with one of  the dial-in clients as outlined in step 3 of the installation section.

3.	Execute the appropriate WINFRAME client (use the connectivity chart above to select the correct WINFRAME client).

Notes

For optimum performance, run the WINFRAME client software from a local drive on the remote client system.

The 3Com Windows client will not work with the NETX shell. For IPX connectivity, VLMs must be used.

When a third-party PPP client connects to a 3Com AccessBuilder, the remote client can act as a router instead of a bridge.


Attachmate RLN Version 2.x
Remote Node Connectivity Products	5 of 7

Attachmate RLN Version 2.x

Remote LAN Node server Version 2.x from Attachmate is a remote node solution that allows remote client systems to access a network via modem. Once a connection to the remote network has been established, the client user can run the WINFRAME Remote Application Manager to start a remote control session on the WINFRAME server. This allows the user to access the network and run applications on the WINFRAME server. This gives Attachmate RLN users faster access to the network, quicker application response and processing, and total access to the network over a remote connection.

Requirements

Hardware Requirements

Attachmate RLN Server: see the Attachmate RLN Server Administrators Guide for hardware requirements.

Client system: 386 minimum with 48MB RAM, hard disk, and modem

Software Requirements

Attachmate RLN server Version 2.0x

Attachmate RLN Client Maker Version 2.0x

Attachmate RLN Manager Version 2.0x

DOS/Windows for Client system

WINFRAME

Installation

Attachmate RLN Server Installation

To install the Attachmate RLN Server, follow the steps in the Attachmate RLN Server Administrators Guide. Chapter 3 covers hardware requirements of the Attachmate RLN Server and how to install it. Chapter 4 covers the installation of the Attachmate RLN Server software itself. The Attachmate RLN Server can be set up and configured for IPX/SPX and TCP/IP network protocols. Set up the server with the network protocols that are used on your network.

Attachmate RLN Client Installation on the Client System

The client system should have a modem connected and DOS installed. If the client will be using Windows, Windows 3.1 or Windows for Workgroups 3.11 should be installed. A DOS system must have at least 4MB of RAM; a Windows system must have at least 8MB of RAM. Install the Attachmate RLN client according to the Attachmate RLN documentation.

Note

If you are using Windows 95 or Windows NT 3.5, check with the Attachmate RLN documentation on connectivity. The standard Attachmate RLN client software will not work on Windows NT 3.5. While it can be made to work under Windows 95, it is not recommended.

Installation of WINFRAME Client Remote
Application Manager on Client System

If the client is a DOS system, install the WINFRAME Client for DOS. If the system is running Windows 3.1 or Windows for Workgroups 3.11, install the Win16 WINFRAME Client. If you are using Windows 95 or Windows NT, install the Win32 WINFRAME Client. See the WINFRAME Client documentation for installation instructions for each of these setups. When installing the DOS or Win16 WINFRAME Client, install the Remote Application Manager only. Do not install the Dial-Up Manager or any of the Dial-Up Manager network support. The Attachmate RLN client will supply all the remote node networking connectivity.

Configuration

The Attachmate RLN server should be set up and running on the network. The Attachmate RLN server should have at least one dial-in modem configured for remote node access and should have either IPX/SPX and/or TCP/IP networking protocols installed, depending on your network. This provides remote node access to the network for remote clients. The WINFRAME server should be set up and configured on the same network or on a network accessible from the Attachmate RLN server. The WINFRAME server should have IPX and/or TCP/IP WinStations configured for remote control sessions. If the WINFRAME server will use IPX, it should have the IPX protocol and the NetWare Gateway Service installed. If the WINFRAME server will use TCP/IP, the TCP/IP protocol should be installed and configured for your network.

The client should have DOS and (if desired) Windows installed. The Attachmate RLN client software should be installed on the client system along with the desired WINFRAME client.

Usage

Before running Windows, load the Attachmate RLN client software and establish a remote node connection. A sample set of commands follows:

RLN -c2
RLNUSER
LSL
PDETHER
IPXODI
NETX

The -c2 parameter on the RLN command specifies the COM port used (COM2 in this example). The RLNUSER program sets up the modem on the client, creates a dial-out entry for the Attachmate RLN server, and dials out and connects to the remote network. Once the remote node connection is successfully established, exit the RLNUSER program. If there is a preconfigured Attachmate RLN server entry, you can auto load and dial the server from the command line by typing RLNUSER dcaservername, where dcaservername is the name of the preconfigured entry for dial out in the RLNUSER program.

After the RLN connection is established, the standard NetWare and TCP/IP stacks can be loaded using the special Attachmate RLN ODI driver, PDETHER. This example loads NETX, but VLMs can be loaded instead if your network uses 4.x NetWare file servers. When all of these are loaded, the client system is connected to the remote network and has standard network access. All of these commands can be added to the AUTOEXEC.BAT file of the client system so that the connection can be automatically dialed and connected, and the network will be loaded when the client system is booted, or placed in a batch file.

At this point, the remote user can run the WINFRAME Client and connect to any WINFRAME server on the remote network.

Troubleshooting

The RLNUSER program says that it cannot access the modem. It gives the error message, Error 1011: DSR and CTS did not go high. What is going on?

This is caused by not using the -c<n> parameter on the RLN TSR when you load it. If your modem is connected to COM1, it will work because this is the default setting. If your modem is on any other COM port, you must supply the -c<n> parameter in order to tell the Attachmate RLN client which COM port the modem is connected to; i.e., RLN -c2 would load the TSR to use a modem on COM2.


Novell NetWare Connect Version 2.0
Remote Node Connectivity Products	6 of 7

Novell NetWare Connect Version 2.0

NetWare Connect 2.0 is a software add-on component to a Novell NetWare 3.x or 4.x file server that provides access to a Novell network via asynchronous connections, utilizing an intelligent multiport serial controller in the file server.

NetWare Connect provides two services that can be used in conjunction with WINFRAME. When connected using DOSDIAL for DOS or Remote Client Dialer for Windows, your computer appears as a locally connected workstation on the network. When connected via a NASI WinStation, your computer functions as if it had dialed into a modem directly connected to the WINFRAME host.

NASI Connection Services (NCS)

NASI Connection Service (NCS) allows remote users to dial into a LAN and local users to dial out from one of the pooled communication ports. A WINFRAME NASI WinStation is configured to connect to a NetWare Connect port for asynchronous dial-in access. When a user dials into the NetWare Connect server with the WINFRAME client for DOS, a NetWare Connect login authentication is required, and then a list of services (WINFRAME hosts that have a WinStation attached to a port on the NetWare Connect server) is presented. When a WINFRAME host is selected, the user is logged in, and it appears as if the user dialed into a modem that was attached directly to the WINFRAME host. The only exception is the NetWare Connect login and the service selector. The advanced Intelligent Console Architecture (ICA 3.0) protocol used by the WINFRAME clients improves performance because it sends only compressed screen updates and mouse and keyboard events over the NASI connection.

A NASI WinStation is required for each simultaneous NASI connection to the WINFRAME server. Use WinStation configuration to create and maintain NASI WinStations.

Point-To-Point Protocol Remote Node Services (PPPRNS)

Point-To-Point Protocol Remote Node Service (PPPRNS) is a new feature implemented in NetWare Connect 2.0, which gives remote node access to the workstations dialing in. Remote node is the ability to dial in to a remote network and act as a network workstation. You can access network drives on servers on the LAN, access printers on the LAN, send e-mail, etc. The remote PC acts as if it is on the host network. The communication taking place on the LAN is translated on the NetWare Connect server and sent over the modem to the remote workstation.

In contrast, NetWare Connect 1.0 used the Novell NetWare Remote Node (NRN) communication protocol to allow remote node attachment to the LAN through the NetWare Connect 1.0 server. NetWare Connect 1.0s NRN was a Novell proprietary protocol. Users were forced to use only the Novell client software, and only the IPX transport was available. In creating and using PPPRNS in NetWare Connect 2.0, Novell used an industry standard protocol, PPP, and an industry standard PPP Link Control Protocol (LCP) extension, IPXCP (Internetwork Packet Exchange Control Protocol). With NetWare Connect 2.0, virtually any third-party TCP/IP with a PPP stack can connect to the NetWare Connect server. The remote PC, in effect, becomes another node on the LAN and has access to all network resources.

In comparing the two services/protocols provided by NetWare Connect 2.0, NCS is the easiest to implement of the two, but PPPRNS is the most versatile, providing direct IPX and TCP/IP protocol access to the LAN. When using PPPRNS, not only can WINFRAME hosts be accessed, but any NetWare or IPX servers and any TCP/IP resources, depending on which transport is installed.

The Novell NetWare Connect client software and information on each implementation supporting the PPPRNS service are listed in the Connection Types Supported table. NetWare Connect provides two client components for DOS, Windows, and Windows for Workgroups that support IPX and TCP/IP over PPPRNS: DOSDIAL for DOS, and Remote Client Dialer for Windows and Windows for Workgroups.

Requirements

Network

NetWare server with NetWare Connect Version 2.0 installed and operational

Modems installed on the NetWare Connect server configured for dial-in service

Citrix WINFRAME host connected to a NetWare network

Remote Workstation

Novell NetWare Connect client software loaded and operational (see Connection Types Supported below)

Modem supported by the transport being used on the remote workstation

High-speed serial port (16550 or equivalent) or intelligent serial port board

WINFRAME client software for the remote workstations environment

Connection Types Supported

Following is a list of the different WINFRAME client connections supported with NetWare Connect 2.0, the components needed, and the protocol used to communicate with the NetWare Connect server.

1.	DOS

Novell NetWare Connect DOSDIAL, WINFRAME Client for DOS (PPPRNS Protocol)

WINFRAME client for DOS (NCS Protocol)

2.	Windows 16-Bit

Novell NetWare Remote Client Dialer for Windows, WINFRAME Client for DOS (PPPRNS Protocol)

Installation

NetWare Server

Install NetWare Connect 2.0 on the NetWare server. Please carefully read any README files or notes supplied with NetWare Connect 2.0.

Notes

Under NetWare Connect Setup for PPPRNS, the NetWare Connect PPP ports and the clients should have their own IP network ( i.e., if the network card installed in the NetWare Connect server has an IP address of 1.1.1.1, the PPP ports would be 1.1.2.x, and the IP address pool would fall under the 1.1.2.x network).

Under NetWare Connect Setup for PPPRNS, the IPX network address should be a (network-wide) unique address. In other words, if the network card installed in the NetWare Connect server has an IPX address of 0000DADA, the PPPRNS IPX address would be 0000DADB.

IP and IPX addresses mentioned above are examples. Usage and assignment is specific to individual sites. Sample NetWare server AUTOEXEC.NCF and NetWare Connect NWCSTART.NCF files are included later in this chapter.

Sample Configuration 1

Workstation:	DOS
Transport:	TCP/IP and/or IPX
Components:	Novell NetWare Connect DOSDIAL, WINFRAME Client for DOS
Connection:	PPPRNS

Verify that WinStations (TCP/IP or IPX) are configured on the WINFRAME server for the network protocol in use. Make sure you have enough WinStations configured to support both local LAN connections and remote NetWare Connect connections.

To install a WINFRAME remote workstation

1.	Install both the NetWare Connect DOSDIAL and WINFRAME Client for DOS software on the remote workstation. After installation is complete, verify that the system boots properly.

2.	Start the NetWare Connect DOSDIAL client to establish an IPX and/or IP connection to the NetWare Connect 2.0 host on the remote network. After you exit NetWare Connect DOSDIAL, change to the network drive and verify that a remote network connection has been established.

Note

Do not proceed until this step is completed successfully.

3.	Start the WINFRAME Client.

4.	Create a remote application. If you select IPX as the transport, you may or may not be able to see server names in the WINFRAME server list, depending on whether or not you have loaded a Novell DOS redirector, NETX.EXE, or VLMs. If no redirector has been installed, you must enter the MAC address of the WINFRAME server you wish to connect to (i.e., 00DA004BC382). To identify the MAC address of the WINFRAME server, click on the Windows NT Diagnostics icon and select Network from the WINFRAME server console under Administrative Tools.

5.	If you configured PPPRNS to use TCP/IP on the NetWare Connect 2.0 server and also configured it during client setup, choose Novell TCP/IP as the transport.

6.	If you have a functioning DNS system or have a correct and valid HOSTS file, enter the name of the WINFRAME host you wish to connect to. If no name resolution is available, either add the name and IP address to your local HOSTS file, or enter the IP address of the WINFRAME host you wish to connect to in the Properties dialog box (for example, 128.128.1.2). The HOSTS file is under the TCP directory, in the directory in which the TCP/IP transport is installed.

Sample Configuration 2

Workstation:	DOS
Transport:	Serial Port (NCS)
Components:	WINFRAME client for DOS and WINFRAME client supported modem (16550 UART recommended)
Connection:	Novell NCS

Use WinStation configuration to set up NASI WinStations on your WINFRAME server.

To install the WINFRAME remote workstation

1.	Install the WINFRAME Client for DOS but do not choose any networking components.

2.	Change to the directory the client is installed in and run WFCLIENT.EXE.

3.	When installed, there are no entries in the server list. Create an entry by clicking on Entry, New, and filling out the fields on the Properties screen.

4.	Assign a name to the entry, select Serial for the transport (unless you are using one of the supported intelligent serial boards), and click on Settings.

5.	Fill in this form to match your configuration, including baud rate, port, and modem type.

6.	Click OK to exit the device setting and return to the Properties screen.

7.	Enter a telephone number and fill in the user information, if desired.

Note

If no user information is entered, it will be requested when the attachment to WINFRAME is made.

8.	Click on OK to save the entry.

9.	To dial the WINFRAME host, either double-click the name or highlight the name by single-clicking on it and then selecting Entry, Connect.

10.	The screen will clear and a message saying it is dialing will appear. Once the connection to the NetWare Connect server is made, it will ask for a login. Enter the username and password when requested.

11.	Once the authentication is passed, a service selector will appear.

12.	Select the WINFRAME host to connect to by typing its number and pressing ENTER. From this point on, the connection will function as a standard WINFRAME asynchronous connection. Refer to the WINFRAME Client User Guide for further information.

Troubleshooting

To troubleshoot client problems, first isolate which client software is set up incorrectly. For example, load only the NetWare Connect client software and attempt to access the network before starting the WINFRAME client. If you cannot access the network, troubleshoot the NetWare Connect 2.0 server and client configuration.

Note

Listed below are samples of the remote workstation and server configuration files that NetWare Connect 2.0 uses. They will differ depending on your hardware and software configurations. They are provided as examples only.

A sample server AUTOEXEC.NCF file, located in the SYS:SYSTEM directory:

file server name 312NWC
IPX internal net 1234baba
load conlog
load SMC8000 port=300 frame=ETHERNET_802.3 name=IPXNET
bind IPX to IPXNET net=A
load SMC8000 port=300 name=IPNET frame=ETHERNET_II
load tcpip forward=yes
bind IP to IPNET address=128.128.1.220 mask=255.255.255.0
load AIODGXI port=110 mem=D0000  name=PCXI8
nwcstart
load nwccon
load monitor
load remote ""
load rspx

A sample server NWCSTART.NCF file, located in the SYS:SYSTEM directory:

;
; These are support modules used by NetWare Connect services.
;
load NWCSS
; Load BSPXCOM for NetWare Connect Service Manager
load BSPXCOM
;
; NASI Connection Service
;
load sys:\system\ncs.nlm
;
; PPP Remote Node Service
;
load ipxstack
load ipxrtr
load PPPRNS

A sample remote workstation STARTNET.BAT file, located in the NetWare Connect client directory:

c:\nwcnet\bin\yesno.exe "Do you want to load the remote client software? (y/n) "
if errorlevel 1 go to LoadNet
go to LoadRem
:LoadNet
echo off
lh C:\NWCLIENT\lsl.com /C=C:\NWCLIENT\net.cfg
lh C:\NWCLIENT\nesl.com
lh C:\NWCLIENT\ncomx.com
lh C:\NWCLIENT\nwremote.com
REM Load IPX
REM @ LH C:\NWCLIENT\IPXODI.COM
@ lh c:\nwclient\ipxodi.com
REM Load TCPIP
REM @ C:\NWCNET\BIN\TCPIP.EXE
@ c:\nwcnet\bin\tcpip.exe
C:\NWCLIENT\vlm.exe /C=C:\NWCLIENT\net.cfg
@ SET NWLANGUAGE=ENGLISH
echo on
go to Exit
:LoadRem
REM **DO NOT DELETE**
:Exit

A sample remote workstation NET.CFG file, located in the NetWare Connect client directory:

Link Support
   MemPool 6192
   Buffers 10 1580
Link Driver NCOMX
   Port 3f8
   Int 4
   Modem Name
   Frame ETHERNET_802.3
Protocol TCPIP
   PATH SCRIPT C:\NWCNET\SCRIPT
   PATH PROFILE C:\NWCNET\PROFILE
   PATH LWP_CFG C:\NWCNET\HSTACC
   PATH TCP_CFG C:\NWCNET\TCP
NetWare DOS Requester
   FIRST NETWORK DRIVE = F
   NETWARE PROTOCOL = NDS BIND PNW

The sample lines below are added to the AUTOEXEC.BAT file in your root directory:

PATH C:\NWCLIENT;%PATH%
PATH C:\NWCNET\BIN;%PATH%
@CALL C:\NWCLIENT\STARTNET

The sample line below is added to the CONFIG.SYS file in your root directory:

LASTDRIVE=Z


Shiva LanRover
Remote Node Connectivity Products	7 of 7

Shiva LanRover

Shiva LanRover provides a remote node solution that allows remote client systems to access a network via a modem. When a connection to the remote network has been established, the client user can run the WINFRAME Remote Application Manager to start a remote control session on the WINFRAME server. This allows the user to access the network and run applications on the WINFRAME server. This gives Shiva LanRover users quick application response and processing, fast access to the network, and total access to the network over a remote connection.

Requirements

Hardware Requirements

Shiva LanRover: see the Shiva LanRover documentation for hardware requirements.

Client system: 386 minimum with 48MB of RAM, hard disk, and modem

Software Requirements

Shiva Client Software

Shiva Net Manager

DOS/Windows

WINFRAME

Installation

Shiva LanRover Installation

To install the Shiva LanRover, follow the steps in the Shiva LanRover documentation. The Shiva LanRover must be configured for your network by the Shiva Net Manager program. This is a Windows 3.1 program that must run on a DOS/Windows 3.1 system. It will not run on WINFRAME or Windows NT. Refer to the Shiva documentation regarding the use of this software to configure the LanRover. Various network protocols can be used by the Shiva LanRover including IPX/SPX, TCP/IP, and NetBEUI.

A corresponding network protocol stack must be installed on the remote client to support these protocols that must agree with your network. This section addresses only IPX support. See the Shiva manuals for more information on supported NetBEUI and TCP/IP stacks.

Shiva LanRover Client Installation on the Client System

A DOS system needs 4MB of RAM; a Windows system needs 8MB of RAM. Connect a modem to a COM port with a modem cable. Install the Shiva client according to the Shiva documentation.

Note

If you are using Windows 95 or Windows NT 3.5, check with the Shiva documentation about connectivity. Windows 95 and Windows NT come with their own PPP network client. These are the Windows 95 Dial-Up Networking application and the Windows NT Remote Access. See the Shiva manuals for how to use these PPP clients with the Shiva LanRover. Once connected, the WINFRAME Win32 Client Remote Application Manager may be run as usual.

Installation of WINFRAME Client Remote Application Manager on Client System

If the client is a DOS system, install the WINFRAME client for DOS. If the system is running Windows 3.1 or Windows for Workgroups 3.11, install the Win16 WINFRAME client. If you are using Windows 95 or Windows NT, install the Win32 WINFRAME client. See the WINFRAME client documentation for installation instructions for each of these set ups. When installing the DOS or Win16 WINFRAME client, install the Remote Application Manager only. Do not install the Dial-Up Manager or any of the Dial-Up Manager network support. The Shiva client will supply all the remote node networking connectivity.

Configuration

The Shiva LanRover should be set up, configured, and running on the network. The Shiva LanRover should have at least one dial-in modem configured for remote node access and should have either IPX/SPX, and/or TCP/IP, and/or NetBEUI networking protocols installed, depending on your network. This will provide remote node access to the network for remote clients.

The WINFRAME server should be set up and configured on the same network or on a network accessible by the Shiva LanRover. The WINFRAME server should have either IPX, and/or TCP/IP, and/or NetBIOS WinStations configured for remote control sessions to connect to. If the WINFRAME server will be using IPX, it should have the IPX protocol and the NetWare Gateway Service installed. If the WINFRAME server will be using TCP/IP, the TCP/IP protocol should be installed and configured for the IP address required by your network. If the WINFRAME server will be using NetBEUI, the NetBEUI protocol should be installed.

DOS and, if desired, Windows should be installed on the client system. The Shiva client software should be installed on the client system along with the desired WINFRAME client.

Usage

Loading

Boot the client PC. Load the Shiva client software and establish a remote node connection. A typical set of commands follows:

LSL
DIALODI
CONNECT
IPXODI
NETX
GUARD

Connection

When started, the CONNECT program allows the user to set up the modem on the client, create a dial out entry for the Shiva LanRover, and dial out and connect to the remote network. Once connected, the CONNECT program can be exited. If you have a preconfigured Shiva LanRover entry, you can auto-load and dial the server from the command line by typing connect @sample, where sample is the name of the preconfigured entry for dial out in the CONNECT program. Once connected via modem, the standard NetWare, TCP/IP, and NetBEUI stacks can be loaded using the special Shiva ODI driver, DIALODI. This example loads NETX, but VLMs could be loaded instead if your network uses 4.x NetWare file servers. A TCP/IP stack could also be loaded that would hook into the DIALODI driver. If you are using LAN Manager, obtain the NDIS version of this driver from Shiva for NetBEUI support. Once all of these are loaded, the client system should be connected to the remote network and have standard network access. All of these commands can be added to the AUTOEXEC.BAT file of the client system so that the connection will be automatically dialed and connected, and the network will be loaded upon booting the client system.

Running the Application

The GUARD application does not have to be loaded in order to connect to the network, although it is very useful. The GUARD application prevents remote users from accidentally running large applications over the remote node connection. If the user attempts to start a large application, the user is notified that this may cause slow performance. The user may terminate the application if desired.

The suggested method of running large applications is to use the WINFRAME Remote Application Manager to connect to a WINFRAME server and to run the large application on the WINFRAME server. This is far faster than running the application over the remote node connection.

At this point, the remote user can start the WINFRAME client for DOS, or if the client has Windows, Windows may be started and the Win16 Remote Application Manager can be loaded. After the desired WINFRAME client is loaded, a remote control session can be created on any WINFRAME server on the remote network. From the WINFRAME server, the user may then access any network server and printer, and run any application on the remote network.


3270 Mainframe Connectivity and WinFrame
Chapter 6	1 of 2

3270 Mainframe Connectivity
and WINFRAME

The 3270 series of mainframe peripherals is a family of IBM system components (terminals, printers, and terminal cluster controllers) that can be used with a mainframe computer over a Systems Network Architecture (SNA) link. There are several ways to link a WINFRAME application server to a mainframe using the 3270 protocol. Instead of multiple individual connections, a gateway should be used. A gateway is a shared connection between a LAN and a larger system  in this case a mainframe  that performs the required protocol conversions.

Other Windows NT-compatible 3270 products may work, but have not been tested by Citrix at this time. Refer to the online WINFRAME Readme for the latest compatibility information, as well as general application integration guidelines.

Note

Some products use the network address of the NIC as a session/user identifier. These products are limited to only one concurrent user on a WINFRAME server. In these cases, the only solution is to use a data communications gateway between the WINFRAME server and the mainframe. The terminal emulator can then use a virtual socket-based protocol (for example, IPX) to communicate with the gateway, allowing multiple users on the WINFRAME server to use the product.

A sample 3270 configuration is illustrated below.

Supported 3270 Connectivity Products

Vendor	Model	Version	Notes
Microsoft	SNA Client	2.11	Requires Microsoft SNA Server 2.11


Microsoft SNA Client/Microsoft SNA Server 2.11
3270 Connectivity and WINFRAME	2 of 2

Microsoft SNA Client/SNA Server 2.11

Microsoft SNA Client/SNA Server supports both 3270 and 5250 connections. There are two components:

The SNA Server, which communicates with the mainframe and acts as the gateway.

The SNA Client. This communicates with the SNA Server component. Each WINFRAME user accessing a 3270/5250 session runs a copy of the SNA Client.

Because these components are standard Microsoft Windows NT packages, installation and configuration are straightforward and there are no special considerations for WINFRAME.

Requirements

Software Requirements:

Microsoft SNA Client/SNA Server Version 2.11

WINFRAME Version 1.5 and above

Hardware Requirements:

486DX with a 66MHz CPU or larger

Minimum of 16MB

Minimum of 20MB free hard disk space

WINFRAME-supported network adapter

Supported SNA communications adapter(s)

Installation

There are three ways that Microsoft SNA Server can be installed on a WINFRAME application server: as an SNA Server, an SNA Client, or both SNA Server and SNA Client.

SNA Server and Client Installation

For the SNA-based installation on a WINFRAME server, follow the instructions described in the Microsoft SNA Server Installation Guide. However, when Microsoft SNA Server is installed on a WINFRAME server, there are three files that must be registered as system global. Follow this procedure:

1.	From the SNA Server Setup Finish dialog box, choose the Exit button.

2.	From the Main Group, start a DOS prompt.

3.	Type net stop snabase and press ENTER.

4.	Change to the SNA Servers system directory (i.e., C:\SNA\SYSTEM).

5.	Execute the following commands:

REGISTER SNADMOD.DLL /SYSTEM
REGISTER SNAMANAG.DLL /SYSTEM
REGISTER SNAADMIN.EXE /SYSTEM

6.	Type net start snabase and press ENTER.

Configuration

To configure the Microsoft SNA Server connection, logical unit (LU), and users, follow the instructions in the Microsoft SNA Server Administration Guide.


AS/400 Minicomputer Connectivity and WinFrame
Chapter 7	1 of 2

AS/400 Minicomputer
Connectivity and WINFRAME

IBMs AS/400 family of minicomputers is used by many businesses. In its standard configuration, the AS/400 connects to separate IBM 5250-series terminals over a specialized dual coaxial cable called twinax.

There are several ways to link an AS/400 minicomputer to a WINFRAME server. Instead of multiple individual connections, a gateway should be used. A gateway is a shared connection between a LAN and a larger system, in this case a minicomputer, that performs the required protocol conversions.

Other Windows NT-compatible 5250 products may work, but have not been tested by Citrix at this time. Refer to the online WINFRAME Readme for the latest compatibility information, as well as general application integration guidelines.

Note

Some products use the network address of the NIC as a session/user identifier. These products are limited to only one concurrent user on a WINFRAME server. In these cases, the only solution is to use a data communications gateway between the WINFRAME server and the minicomputer. The terminal emulator can then use a virtual socket-based protocol (for example, IPX) to communicate with the gateway, allowing multiple users on the WINFRAME server to use the product.

A sample 5250 configuration is illustrated below.

Supported AS/400 Connectivity Products

Vendor	Model	Version	Notes
Eicon	Access for Windows NT Multiuser	3.21	Requires Microsoft SNA Server 2.11
Microsoft	SNA Client	2.11	Requires Microsoft SNA Server 2.11


Microsoft SNA Client/SNA Server 2.11
AS/400 Minicomputer Connectivity and WINFRAME	2 of 2

Microsoft SNA Client/SNA Server 2.11

Microsoft SNA Client/SNA Server supports both 3270 and 5250 connections. There are two components:

The SNA Server, which communicates with the mainframe and acts as the gateway.

The SNA Client. This communicates with the SNA Server component. Each WINFRAME user accessing a 3270/5250 session runs a copy of the SNA Client.

Because these components are standard Microsoft Windows NT packages, installation and configuration are straightforward and there are no special considerations for WINFRAME.

Requirements

Software Requirements

Microsoft SNA Client/SNA Server Version 2.11

WINFRAME Version 1.5 and above

Hardware Requirements

486DX with a 66MHz CPU or larger

Minimum of 16MB

Minimum of 20MB free hard disk space

WINFRAME-supported network adapter

Supported SNA communications adapter(s)

Installation

There are three ways that Microsoft SNA Server can be installed on a WINFRAME application server: as an SNA Server, an SNA Client, or both SNA Server and SNA Client.

SNA Server and Client Installation

For the SNA-based installation on a WINFRAME server, follow the instructions described in the Microsoft SNA Server Installation Guide. However, when Microsoft SNA Server is installed on a WINFRAME server, there are three files that must be registered as system global. Follow this procedure:

1.	From the SNA Server Setup Finish dialog box, choose the Exit button.

2.	From the Main Group, start a DOS prompt.

3.	Type net stop snabase and press ENTER.

4.	Change to the SNA Servers system directory (i.e., C:\SNA\SYSTEM).

5.	Execute the following commands:

REGISTER SNADMOD.DLL /SYSTEM
REGISTER SNAMANAG.DLL /SYSTEM
REGISTER SNAADMIN.EXE /SYSTEM

6.	Type net start snabase and press ENTER.

Configuration

To configure the Microsoft SNA Server connection, logical unit (LU), and users, follow the instructions in the Microsoft SNA Server Administration Guide.


ISDN Connectivity and WinFrame
Chapter 8	1 of 3

ISDN Connectivity and WINFRAME

Integrated Services Digital Network (ISDN) is an International Telephone and Telegraph Union Standardization Sector (ITU-T, formerly CCITT) standard for a digital communications network intended to replace conventional telephone service with a completely digital transmission system. You must obtain ISDN connections from your telephone company.

Most current ISDN products function as LAN bridges. ISDN bridge products provide remote networking over ISDN lines, often supporting both IP and IPX networks. They can be compared to remote node connectivity products. Remote and local workstations connect to WINFRAME servers on either side of the ISDN bridge.

In general, ISDN bridges are transparent to WINFRAME. Any external ISDN products (i.e., a product that acts as a LAN bridge and connects directly to the existing network cabling) can be expected to work. Field experience indicates that a 128Kbps BRI line can support approximately six to ten concurrent users without performance degradation.

A typical ISDN bridge configuration is shown below.

Supported ISDN Connectivity Products

Vendor	Model	Version
DigiBoard	IMAC Bridge	External
Gandalf	LANLine Bridge	i Series
Notes

A blinking cursor on the remote session will cause continuous ISDN data transmission, which may incur excessive line charges over time.  The cursor blink can be disabled by setting the cursor blink rate to its minimum value in the desktop settings using the control panel.

It may be necessary to use SPX WinStations on the WINFRAME server instead of IPX because not all ISDN bridges are capable of spoofing ICA IPX watchdog packets. Refer to the documentation supplied with your ISDN product for more information.


DigiBoard IMAC Bridge
ISDN Connectivity and WINFRAME	2 of 3

DigiBoard IMAC Bridge

The DigiBoard ISDN IMAC provides remote Ethernet network bridging over standard basic rate 2B+D (2 x 64Kbps data channels) ISDN lines. The IMAC is protocol independent and can bridge the IPX, SPX, TCP/IP, NetBIOS, and NetBEUI protocols. Ethernet frames are transparently transmitted between the local and remote networks over the ISDN line. The DigiBoard ISDN products allow two-way access between the local and remote networks. The two LANs, or PC and LAN, appear as one contiguous network. The WINFRAME Client can establish a network remote control session on a WINFRAME server as if it were on the local LAN.

Requirements

Hardware Requirements

DigiBoard IMAC ISDN/MAC layer bridge on the remote and local side

ISDN lines installed at both the local and remote sites

Software Requirements

WINFRAME server and client software

Installation

1.	Install the DigiBoard IMAC bridge by following the Sample Installation section in the DigiBoard IMAC manual.

2.	Install and configure the WINFRAME Client software on the client PC. Refer to the WINFRAME Client Users Guide for detailed information.

Configuration

The tested configuration used a copy of the Listen2 profile, which controls incoming Ethernet traffic by using two B channels.

When configuring a profile on the IMAC, the following settings give the best performance (options are set via the IMACs SET PROFILE command):

/FILTER_LOGIC=SOFT (maintains a filter table of up to 2047 MAC addresses)
/NUMBER_OF_CHANNELS=2 (use both channels for the bridging)
/CHANNEL=B1:B2 (use both B1 and B2 channels)

Usage

1.	If the DigiBoard IMAC bridges are operating and the ISDN lines are active, the remote network should appear as if it is local. Depending on the DigiBoard IMAC bridge equipment purchased, your bandwidth will be either 64Kbps or 128Kbps. WINFRAME compression provides excellent performance connection over the bridge.

2.	The IMAC bridges can be remotely configured and managed by any SNMP management system or via TCP/IP commands.

3.	After the ISDN connection is established, start the WINFRAME Client on the client PC. You may now connect to a remote application using the network protocols supported by your installation.

Notes

The DigiBoard IMAC bridge products are an excellent way to access remote LANs. Special features on the IMAC series bridges allow connections to be initiated or dropped transparently to users, giving the remote office a virtual presence on the central site LAN while keeping line charges at a minimum.

WINFRAME greatly improves the performance of the ISDN bridge because the execution of the applications is performed on the WINFRAME server, requiring only screen updates, keystrokes, and mouse activity to be sent across the bridge.


Gandalf ISDN Bridges
ISDN Connectivity and WINFRAME	3 of 3

Gandalf ISDN Bridges

The Gandalf LANLine remote access products provide remote Ethernet network bridging over standard basic rate 2B+D (2 x 64Kbps data channels) ISDN lines. They are protocol independent and can bridge the IPX, SPX, TCP/IP, NetBIOS, and NetBEUI protocols. Ethernet frames are transparently transmitted between the local and remote networks over the ISDN line. The Gandalf LANLine products allow two-way access between the local and remote networks. The two LANs, or PC and LAN, appear as one contiguous network. The WINFRAME Client can establish a network remote control session on a WINFRAME server as if it were on the local LAN.

Requirements

Hardware Requirements

Gandalf LANLine Series Intelligent bridge on both the remote and local sides

ISDN lines installed at both the local and remote sites

Software Requirements

WINFRAME server and client software

Installation

1.	Install the LANLine Series bridges following the steps in the Gandalf Users Manual.

2.	Install and configure the WINFRAME Client software on the client PC. Refer to the WINFRAME Client Users Guide for detailed information.

Usage

1.	Once the Gandalf bridges are operating and the ISDN lines are active, the remote network can be accessed. Depending on the Gandalf bridge equipment you purchased, your bandwidth will be either 64Kbps or 128Kbps uncompressed. Gandalfs data compression combined with the WINFRAME compression provide excellent performance for several simultaneous connections over the bridge.

2.	The LANLine bridges can be configured and managed remotely by any SNMP management system.

3.	After the ISDN connection is established, start the WINFRAME Client on the client PC. You may now connect to a remote application using the network protocols supported by your installation.

Notes

The Gandalf LANLine Series bridge products are an excellent way to access remote LANs. Special features on the LANLine series bridges allow connections to be initiated or dropped, transparently to users, giving the remote office a virtual presence on the central site LAN while keeping line charges at a minimum. Combined with data compression rates of up to 8:1, LANLine solutions can make ISDN an affordable alternative.

WINFRAME greatly improves the performance of the ISDN bridge because the execution of the applications is performed on the WINFRAME server, requiring only screen updates, keystrokes, and mouse activity to be sent across the bridge.


X.25 Connectivity and WinFrame
Chapter 9	1 of 2

X.25 Connectivity and WINFRAME

X.25 is the ITU-T (formerly CCITT) standard that defines the connection between a terminal and a public packet-switched network. X.25 describes the electrical connections, the transmission protocol, error detection and correction, and other aspects of the link. X.25 networks are normally accessible through asynchronous modems, and an interface between the modem and the terminal  a packet assembler/disassembler (PAD)  is required. This interface may be internal or external. External and internal PAD solutions are supported by WINFRAME servers.

An internal PAD is an intelligent adapter installed in the application server that connects to the public packet-switching network via a modem and provides X.25 services by appearing as a collection of COM ports. An external PAD is a stand-alone unit that connects to the public packet-switching network via a modem, and it has multiple async RS-232 ports that can be connected to async ports on the application server.

Ports on an external PAD can be connected to multiple application servers to provide load balancing. This requires that the same users and applications be accessible from all application servers.

X.25 technology requires advanced knowledge and skill. This integration should be attempted only by engineers and technicians already familiar with X.25 technology. Each proposal should be preceded with a pilot test to verify the specific configurations and functions.

A typical X.25 configuration, showing both internal and external PADs, is shown below.


Configuring X.25 for WinFrame
X.25 Connectivity and WINFRAME	2 of 2

Configuring X.25 for WINFRAME

X.25 was originally developed for dumb terminals using 7-bit ASCII and ASCII control characters to perform control functions such as flow control and link maintenance. The protocols used to control an X.25 link are X.29 and X.3. X.29 defines the procedures used to connect two separate packet switched networks; X.3 defines the protocol and parameters used to configure and control the operation of an X.25 link. Use X.29 on the host PAD to set the X.3 PAD parameters to values that allow data to flow properly between the WINFRAME server and the client PCs.

The ICA protocol used by WINFRAME uses 8-bit binary data, and has its own set of non-ASCII control sequences that are not compatible with the default X.3 settings. Some of the changes required for WINFRAME servers are:

Disable the Escape to Command Level character (DLE, CTRL-P)

Disable Echo

Disable XON/XOFF Flow Control

Use hardware flow control

Enable 8-bit data transfer

The WINFRAME Client automatically switches in ASCII mode when ASCII data is detected. This allows you to type in any X.29 and X.3 data required to establish a connection to a remote WINFRAME server. Once the connection is established, the WINFRAME Client automatically switches back to ICA mode when ICA data is detected. These is no automated scripting facility available in the WINFRAME Client Remote Application Manager; however, the WINFRAME Client Dial-Up Manager and some RAS solutions do offer scripting facilities that can be used to automate the connection process.


Software Application Notes
Chapter 10	1 of 9

Software Application Notes

This chapter contains application notes for popular software applications. The applications are in alphabetical order. Refer to the online Readmes for general information on installing and configuring applications on a WINFRAME server.

Note

The products listed in this guide have been tested and found to be compatible with WINFRAME. Other products may (and probably will) work, but Citrix cannot guarantee the compatibility of untested products.

Since WINFRAME is based on Microsoft Windows NT Server Version 3.51, most Windows NT compatible applications can be expected to work. Review the application notes in the Solutions Guide and in the online WINFRAME Readme for detailed application integration tips and techniques.

WINFRAME supports Windows 32-bit applications, Windows 16-bit applications, DOS text applications, DOS graphical applications (console only), and OS/2 text applications. DOS graphical applications are supported on the console only; ICA WinStations support DOS text-mode programs only. OS/2 graphical programs that make use of the OS/2 graphical user interface (GUI) are not supported. OS/2 text applications, however, are supported. DOS and OS/2 text applications can use their standard installation procedures.

Windows applications can be 16-bit or 32-bit. There are two ways to install these applications: user-specific and user-global. User-specific means that the application is installed for use by a specific userid. The default installation process is user-specific. Any .DLL or .INI files or other application-specific files are installed to that user's home directory. To install an application for a specific user, login as that user and install the application in the usual manner. Only the user who installed the application has the complete set of installation files, even if the application is installed to a network or shared directory. Other users may not have access to all the .DLLs and .INI files needed to run the application, and a separate install isusually required for each user who wants to use the application.

Because doing user-specific installs for many individual users can be a time consuming process, many applications offer network installs. WINFRAME permits network installs. Check with the application's documentation to see if a network install option is supported. This allows an administrator to perform a server install to the WINFRAME server or elsewhere on the network. Individual users can then run the applications SETUP or INSTALL utility, which configures a user for that application and copies the required .DLL and .INI files.

The second (and preferred) installation method is user-global. With this method, an application is installed once by an administrator and can be run by anyone who logs into that WINFRAME server. The CHANGE USER /INSTALL utility is used to ensure that the .DLL and .INI files are copied to system directories. After the install is complete, the CHANGE USER /EXECUTE utility restores .INI file mapping. When a user starts the application for the first time, the required user-specific files are automatically copied to the users Home Directory.


Advanced Revelation Version 3.1
Software Application Notes	2 of 9

Advanced Revelation Version 3.1

Advanced Revelation 3.1 for DOS is a database application that supports multiple users.

Software Requirements

Advanced Revelation 3.1 for DOS

WINFRAME

Installation

Follow the installation procedure in the Advanced Revelation 3.1 manuals and installation documentation.

Usage

The default DOS keyboard polling detection does not prevent Advanced Revelation 3.1 for DOS from trying to use all the available CPU in the system. Before running Advanced Revelation, run AREVFIX in the DOS window in which you will run Advanced Revelation. AREVFIX is a TSR that prevents Advanced Revelation from using all the CPU in the system. An Advanced Revelation .PIF file can be set up to point to a custom AUTOEXEC.NT file that runs AREVFIX before running Advanced Revelation so that a Windows icon can be used.


Arcada Backup Exec, Windows NT Enterprise Edition, Version 6.0
Software Application Notes	3 of 9

Arcada Backup Exec, Windows NT Enterprise Edition, Version 6.0

Arcada Backup Exec, Windows NT Enterprise Edition, Version 6.0 is a true 32-bit client/server data storage and management solution offering advanced features such as centralized administration and monitoring, remote administration, global network view, unattended backup, disk grooming, e-mail notification, and compression. Backup Exec can be used to back up FAT, NTFS, and NetWare file systems. In addition, Backup Exec offers optional agents that can be used to backup UNIX, Macintosh, and Windows 95 workstations.

Requirements

A tape drive supported by Arcada Backup Exec, that has a Windows NT device driver

WINFRAME Server Software, Version 1.5 or higher

Arcada Backup Exec, Windows NT Enterprise Edition, Version 6.0

System Integration

Prior to installing the Backup Exec software, verify that the WINFRAME server is up and running, and that the tape backup unit is configured and operational.

Follow the installation directions in the Backup Exec manual.

Note

If the tape backup unit was added after installing WINFRAME, you need to load the appropriate tape device driver in order for WINFRAME to properly recognize the tape backup unit. Use the Options selection in Windows NT Setup to add the SCSI tape backup unit. You will then need to reboot the server.

Usage

Follow the usage directions in the Backup Exec manual.

Note

Some WINFRAME systems may hang when restoring an HPFS system partition to the same WINFRAME host. To avoid this problem, use the NTFS or FAT file systems for WINFRAME partitions.


File and Print Services for NetWare
Software Application Notes	4 of 9

File and Print Services for NetWare

File and Print Services for NetWare enables users of NetWare client computers to access volumes and printers shared on WINFRAME. This requires no changes or modifications to the software on the NETX or VLM clients.

If your system is a WINFRAME 1.5 system, you must install the Citrix WINFRAME Service Pack 3 for WINFRAME 1.5 before proceeding. This is not required for a WINFRAME 1.6 system, because Service Pack 3 is part of WinFrame 1.6. If additional hardware or software is installed on a WINFRAME 1.5 server after Service Pack 3 is installed, you must reinstall Service Pack 3 to make sure that the latest copies of the system files are present.

When File and Print Services for NetWare is installed on a WINFRAME server, certain WINFRAME-specific files are overwritten, causing incorrect system operation. The version of the User Manager program (USRMGR.EXE) supplied with File and Print Services is used to maintain NetWare-specific user information. This program must be renamed and the original WINFRAME-specific USRMGR.EXE retained. The following installation procedure addresses these problems.

Requirements

WINFRAME Version 1.5 or 1.6 server

File and Print Services for NetWare

Installation

1.	If your system is a WINFRAME 1.5 system, you must install the Citrix WINFRAME Service Pack 3 for WINFRAME 1.5 before proceeding. This is not required for a WINFRAME 1.6 system, because Service Pack 3 is part of WINFRAME 1.6.

2.	Back up the following files before installing File and Print Services for NetWare. You must back up these files, because the File and Print Services for NetWare installation overwrites them. The files to back up are:

%SystemRoot%\system32\usrmgr.exe
%SystemRoot%\system32\netmsg.dll
%SystemRoot%\system32\drivers\nwlnkipx.sys

%SystemRoot% is the disk drive containing the WINFRAME system files. A sample set of commands (assuming your system drive is drive C) is:

cd %systemroot%\system32
copy usrmgr.exe usrmgr.ctx
copy netmsg.dll netmsg.ctx
copy drivers\nwlnkipx.sys drivers\nwlnkipx.ctx

3.	Install File and Print Services for NetWare following the documentation supplied with the software. DO NOT reboot the WINFRAME server after the installation is completed. The following steps must be performed first.

4.	After File and Print Services for NetWare is installed, rename the \%SystemRoot%\system32\USRMGR.EXE file to NWUSRMGR.EXE using the following command: ren usrmgr.exe nwusrmgr.exe.

5.	Create a program item in the Administrative Tools group for NWUSRMGR.EXE. Name this program item NetWare User Manager.

Note

The NetWare User Manager should only be used to configure NetWare parameters for users. Do not use the NetWare User Manager for any other user maintenance activities because it may adversely affect WINFRAME-specific user configuration data.

6.	Restore the files backed up in step 2 to their original directories, overwriting the files installed by File and Print Services for NetWare installation. A sample set of commands (assuming your system drive is drive C) is:

cd %systemroot%\system32
copy usrmgr.ctx usrmgr.exe
ren netmsg.dll netmsg.fpn
copy netmsg.ctx netmsg.dll
ren nwlnkipx.sys nwlnkipx.fpn
copy drivers\nwlnkipx.ctx drivers\nwlnkipx.sys

Note

You must rename netmsg.dll before you copy netmsg.ctx. If you do not, netmsg.dll will return a message that says it is in use when you try to overwrite it.

7.	It is necessary to register fpnw.dll as system global. Perform the following command at a prompt (assuming %systemroot%\system32 is still the current directory):

register fpnw.dll /system

8.	Reboot your WINFRAME server and verify that the system and File and Print Services for NetWare operate normally.


IBM OS/2 LAN Server 4.0
Software Application Notes	5 of 9

IBM OS/2 LAN Server 4.0

This section discusses the integration of WINFRAME servers with IBM OS/2 LAN Server 4.0 servers. The information also applies to IBM LAN Manager 2.x.

IBM OS/2 LAN Server is a server product that allows users to share directories, printers, and serial devices with other workstations on the LAN. The LAN Server program is installed on a system that has an OS/2 operating system as a base. Servers belong to logical groups called domains. Within each domain, one server is assigned as the domain controller. The domain controller manages information about users, groups, and workstations in the domain. Other servers can be a part of the domain but only one is designated as the domain controller. This concept of domains, users, and shareable resources is currently implemented by IBM as their LAN Server Product and Microsoft as their Microsoft NT network, upon which the WINFRAME server product is based. Unfortunately, IBM LAN Server 4.0 cannot participate in Microsoft domains or share account information with a Microsoft domain controller or a WINFRAME server. This section discusses the ways to bridge these incompatibilities.

Software Requirements

WINFRAME server software, Version 1.5 or higher

IBM OS/2 operating system

IBM OS/2 LAN Server, Version 4.0

Installation

The following sections describe how to make browsing available between the clients and servers of the IBM LAN Server domain and the clients and servers of the WINFRAME domain.

Note

IBM LAN Server domains are viewed and treated as workgroups under WINFRAME.

To let users with accounts on other systems access WINFRAME and Windows NT resources, you can create local accounts for those users in WINFRAME domains containing those resources. You can then place those accounts in local or global groups in the domain and assign necessary permissions to those groups. Although you can give permissions directly to local accounts, it is not recommended    it would be difficult to maintain if you later upgrade those other systems to WINFRAME and no longer require the use of local accounts.

If you do replace other systems with WINFRAME after giving those users local accounts, you can then delete the local accounts and begin using those users WINFRAME accounts.

Local accounts are different from other user accounts in one important way    a local account in one domain cannot be used in domains that trust that domain. Therefore, if a user from another network operating system needs to access several domains, you must create a local account for the user on each of those domains.

To make IBM LAN Server domains visible to a WINFRAME browser using the Control Panel

1.	On the WINFRAME server, double-click the Networks option in Control Panel to display the Network Settings dialog box.

2.	Select Computer Browser from the Installed Network Software box and then choose the Configure button to display the Browser Configuration dialog box.

3.	For each LAN Manager domain you want to add, type the LAN Server domain name in the box on the left and then choose the Add button.

4.	When finished adding up to four domains, choose the OK button.

To make LAN Server domains visible to a WINFRAME browser using the WINFRAME Registry

1.	Run the REGEDT32.EXE file from File Manager or Program Manager of the WINFRAME browser to start the Registry Editor.

2.	Locate the following Key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services \LANmanServer\Parameters

3.	In the Other Domains entry, add the names of the LAN Server domains that you want to be made visible to the WINFRAME browser. A WINFRAME server can connect to standalone LAN Server 4.0 servers and LAN Server 4.0 servers participating in a LAN Server 4.0 domain. LAN Server 4.0 and WINFRAME servers interoperate because they both use server message blocks (SMBs) to communicate between the redirector and server software. The NetBEUI frame (NBF) and TCP/IP protocols used by WINFRAME are also interoperable with NetBEUI and TCP/IP protocols written for LAN Server 4.0.

Note

LAN Server 4.0 servers can act as backup domain controllers in a WINFRAME server domain. Both local and global user accounts are replicated to LAN Server 4.0 servers acting as BDCs. Because LAN Server 4.0 does not support trust relationships or local groups, a LAN Server 4.0 server can never be a primary domain controller.

Net Using LAN Server 4.0 Server Shares That Are Not Visible Through the Browser

Even though the LAN Server domains are not visible in the browse list, connections can be forced to computers in those domains by using their server name (\\servername\sharename) in the PATH line of the Connect Network Drive dialog box in File Manager.

Add at Least One WINFRAME or NT Workstation to Each LAN Server Domain

1.	On the WINFRAME server, double-click the Networks option in Control Panel to display the Network Settings dialog box.

2.	Select Change Domain or Change Workgroup.

3.	Select member of DOMAIN domain-name (where domain-name is the LAN Server domain you are joining).

4.	Enter an Admin username and password from the LAN Server domain.

Additional Notes

Allowing WINFRAME Users Access to LAN Server 4.0 Servers

The WINFRAME system of pass-through authentication depends on the fact that trust relationships allow servers in one domain to recognize users accounts from other domains. However, even though LAN Server 4.0 servers can participate in WINFRAME domains and can recognize user accounts in their own domain, they will not be able to recognize user accounts from trusted domains.

For example, suppose that a domain called Sales trusts a domain called MIS. This lets you assign permissions on the server running WINFRAME and Windows NT Server in Sales to users from MIS. However, you cannot assign permissions for resources on the LAN Server 4.0 server in Sales to users from MIS.

To solve this problem, you can create local accounts in the domain containing the LAN Server 4.0 server. You should create a local account for each user from a trusted domain who needs to access those servers. You create a local account in the same way you create regular user accounts, except that while creating the account, you use User Manager for Domains to designate it as a local account.

You can then place the local account in global groups in your domain and assign those global groups the required permissions on LAN Server 4.0 servers (you must use global groups for this, because LAN Server 4.0 server does not recognize local groups). Although you can give permissions directly to local accounts, it is not recommended; it would be difficult to maintain when you upgrade your LAN Server 4.0 server to WINFRAME and no longer require the use of local accounts.

If you upgrade all the servers in your domain to WINFRAME so that no LAN Server 4.0 servers remain, you can remove all local accounts from the domain and begin referring to the WINFRAME accounts instead. When it is time to remove local accounts from a domain, their different icons will help you do so accurately and quickly.

Interactions With Servers Running Other Network Systems

With the exception of LAN Server 4.0 servers, servers running network operating systems other than Windows NT (such as Novell NetWare) cannot participate in domains or share account information with WINFRAME or Windows NT Server.

You can incorporate LAN Server 4.0 servers into your network in two ways:

1. 	As a server in a Windows NT domain (where the primary domain controller must be a WINFRAME or Windows NT Server computer)

2. 	As a part of an IBM LAN Server 4.0 domain, where a LAN Server 4.0 server is the primary domain controller.

Adding a LAN Server 4.0 server to a Windows NT domain presents a few problems, because the LAN Server 4.0 server is limited to LAN Server 4.0 abilities. Although the LAN Server 4.0 server receives a copy of the domains user and group database, the LAN Server 4.0 server does not recognize local groups, so you will not be able to assign permissions for resources on LAN Server 4.0 servers to the domains local groups.

Also, if the domain containing LAN Server 4.0 servers trusts other domains, you cannot assign permissions on the LAN Server 4.0 servers to users and global groups from the trusted domain. LAN Server 4.0 servers do not recognize trust relationships.

Domains made entirely of LAN Server 4.0 servers cannot have trust relationships with other domains, but resources on these domains can be accessed by Windows NT workstation users. Because LAN Server 4.0 domains cannot trust other domains, they cannot use users and global groups defined on other domains. Therefore, for a WINFRAME or Windows NT user to access a resource in a LAN Server 4.0 domain, that user must also have an account in the LAN Server 4.0 domain (or that domain must allow guest logons).


Lotus Notes and a Sample Large-Scale Deployment
Software Application Notes	6 of 9

Lotus Notes and a Sample
Large-Scale Deployment

At the recent IBM/Lotus Lotusphere conference in Orlando, Florida, a Microsoft Windows-based kiosk system was set up. This system supported a 250 workstation network used by attendees at the conference to access Lotus cc:Mail, Notes mail, and Notes-based applications. Conference attendees could communicate with one another, access information about conference sessions, activities, and participating vendors through the kiosks, as well as by dialing in to the network.

Citrix Systems, Inc. was invited to participate in the conference to provide a remote computing solution for the kiosk system, called Lotusphere Unplugged. The goal was to give attendees access to the kiosk applications by dialing into the network from their hotel rooms and other remote locations using notebook computers. This section describes how this system was deployed and discusses the techniques used to solve some of the technical issues encountered.

Objectives of the Installation

The objectives of the system configuration were:

Support a very large number of users (over 10,000).

Support a wide variety of remote users and platforms with minimal workstation hardware configuration issues.

Transparently support more concurrent Dial-In users than can be run on a single WINFRAME server.

Allow users to access Lotus Notes applications directly from Windows 95
PC-based kiosks or over Dial-In connections to a Citrix WINFRAME server, and transparently access the same set of applications (not including multimedia video).

All users to have the same execution environment though a common program manager desktop with specific icons for Lotus applications.

The environment to be managed and secured by using built-in security facilities to restrict access and execution rights to programs, files, and accessories.

In this configuration, each user already had a loginID in a Windows NT server domain. A special technique described below was used to avoid a complete Notes node (client) installation for each user. The users were configured to run Notes from both Windows 95 (kiosk) and Windows NT (WINFRAME Dial-In) workstations.

Implementation Planning and Steps

The following planning and implementation issues had to be defined and resolved:

1.	Software and Hardware Requirements

2.	Special WINFRAME Configuration Techniques

3.	User Profile Considerations

4.	Application Installation Issues

5.	Security Considerations

6.	Miscellaneous WINFRAME Configuration Considerations

The following sections describe these decisions.

Requirements

Software

Lotus Notes 3.3

WINFRAME

Hardware

100 analog phone lines on a hunt group with a single master telephone number

100 rack-mounted MultiTech 28.8Kbps modems

DigiBoard X/EM intelligent multiport RS-232 subsystems

Five IBM 320 dual 100MHz Pentium SMP servers with 256MB of RAM and 1GB FAST SCSI-2 hard disk

100MB HP VG-AnyLAN EISA network adapters

The equipment was configured and WINFRAME installed on each dual-processor IBM server. Load distribution across all five machines was accomplished by alternating the phone line connections. Line 1 was connected to machine 1, line 2 to machine 2, etc., with line 6 connected to machine 1. This was done for all 100 lines. In this way users were spread fairly evenly across all five servers.

Note

The dual-processor Pentium servers described above are adequate to run 20 simultaneous users with a light-weight Lotus Notes application. Other more CPU-intensive Notes applications may get better performance by reducing the user count to 1215 on a similar machine. Acceptable performance for a specific combination of applications, hardware, and network environment can only be determined with an on-site pilot project and careful performance benchmarking.

Special WINFRAME Configuration Techniques

Lotus Notes node (client) installation typically includes a set of program and data files that are installed on each users workstation. These files include USER.ID, NOTES.INI, NAMES.NSF, and DESKTOP.DSK. Notes is designed to assume that only one user at a time is using these files. There are at least two ways to solve this problem when users are running WINFRAME.

The first method is to manually place a copy of these files in each users home directory. For a relatively small number of users, this may be the simplest approach, but it requires manual set up for each user added.

The second way is to organize the files so that there are enough unique copies for the number of concurrent users who are running Notes via the WINFRAME server. To avoid consuming the disk space necessary for each user to have a personal copy of these files in his/her home directory, the second approach was used in this configuration. Because a maximum of 20 users were expected to run on a specific WINFRAME server, 20 subdirectories were created. The subdirectories were named sequentially (ant001, ant002, etc.) with names that matched the names given to the 20 WinStations configured on the WINFRAME server. As users connected to a WINFRAME server, their unique WinStation names were used to determine a path name to a unique subdirectory containing the specific files for each concurrent user.

In this configuration, an application was run from the Startup program group for each user via a customized, minimal user profile. One function of this application was to set the correct paths that included the WinStation-specific Notes directory for each user as the user logged into a WINFRAME server.

A common INI file was read by the startup application that gave the base directory locations for the various applications (Notes, cc:Mail 6.0, etc.; for example c:\apps\lotus\PvtNotes). This meant that each application server had to have the same directory structure for these applications.

The files that must be unique for each user include USER.ID, NOTES.INI, NAMES.NSF, and DESKTOP.DSK.

These files fall into two categories: files that have user-specific information and must be unique for each user and files that can be executed by only one user at a time but are not unique to a specific user.

The user-specific files were placed in each users home directory. Each users home directory was created on a common network share point.

U:\HOMEDIR\USERS\%USERNAME%\USER.ID
U:\HOMEDIR\USERS\%USERNAME%\WINDOWS\NOTES.INI

Twenty copies of the non-user-specific files were stored in subdirectories on the WINFRAME server. The directory names included the WINFRAME WinStation name used to derive unique sets of file names for each concurrent user running on the WINFRAME server.

D:\NOTES\PORT\(WinStation name)\DESKTOP.DSK
D:\NOTES\PORT\(WinStation name)\NAMES.NSF
D:\NOTES\PORT\(WinStation name)\<OTHER NOTES FILES FROM THE NOTES NODE INSTALLATION>

The Notes program files were installed on each WINFRAME server in the \NOTES directory.

User Profile Configuration

Users were created in a Windows NT domain with separate primary and backup domain controllers. (WINFRAME servers can be used as domain controllers, but were not in this configuration.) For the purposes of this application note, it is assumed that the users were created using the User Manager for Domains. Users can then login to the domain via a Windows 95 workstation or by running a session on a WINFRAME server. Users running on WINFRAME appear as Windows NT users from a network and application program perspective.

There are several ways to control aspects of a users execution environment such as the programs the user can run. One way is to replace the default Program Manager with a custom front-end application. This application can then be used to launch programs by displaying a menu or set of icons. The approach used in this project was to customize the existing Windows NT Program Manager to include just the icons for the applications to be deployed. The User Profile Editor was utilized to restrict the users desktop environment by removing items other than the specific programs deployed. Each user was given a unique home directory. All users home directories were kept on the same NT server for consistency and simplicity.

A common Windows NT user profile was shared by all WINFRAME users. It was kept in a shared directory on the network. The only icons available to Lotusphere attendees were Notes, cc:Mail, and Logout (a program that logs the user out).

The users were configured as follows:

1.	Login as an administrator. Start the User Profile Editor in the Administrative Tools group. Make the following changes to the profile fields (any fields not mentioned can be left in the default state):

Permitted to use profile: Domain Admins group

Disable Run in File Menu: Enabled

Disable Save Settings Menu Item and Never Save Settings: Enabled

Show Common Program Groups: Disabled

Lock all program groups so users cannot make any changes to the program groups.

Allow User to Connect/Remove Connections in Print Manager: Disabled

Save this profile in a file named ATTENDEE.USR. This profile is used with the user created in Step 2.

2.	Start the User Manager for Domains. Create a new user (for example, a user named ATTENDEE). This user is the Lotus Notes prototype user. Make sure the group memberships for this user include the Domain Admins group. Use the ATTENDEE.USR profile created in Step 1 as the user profile.

3.	Login as the user created in Step 2. Remove unneeded program groups and program items from the Program Manager desktop. Add the Lotus Notes applications to the Startup group.

Important

Set the working directory for the Lotus Notes program item to %HomeDrive%%HomePath%\WINDOWS. This ensures that the user-unique NOTES.INI file is used. The NOTES.INI file points to the USER.ID file. Save the Program Manager settings using the Save Settings Now option on the Options pull-down list and then logout.

4.	Login as an administrator. Start User Manager for Domains and edit the user created in Step 2. Remove membership in the Domain Admins group and make the account a member of the Domain Users group only. Save the changes and exit the User Manager for Domains.

5.	Start the User Profile Editor. Update the Permitted to use profile field of the ATTENDEE.USR profile file to Domain Users. This allows the user created in Step 2 to access and use this profile.

6.	Login as the user created above and verify that this user can execute Lotus Notes and that other resources are properly secured.

7.	If the resulting desktop or environment is incorrect, change the user back to a Domain Admin, use the User Profile Editor to change the Permitted to use profile field in ATTENDEE.USE to Domain Administrator, and repeat Steps 3 through 6 until this user can execute Lotus Notes and is properly secured.

Application-Specific Considerations

Both the Lotus Notes server and node installs were performed on the WINFRAME server. The WINFRAME CHANGE /INSTALL utility was used to ensure that user profile changes made by the install process were directed to the system default user profile.

Begin by performing a Notes server-install (in this situation the WINFRAME server appears like a file server to Notes), then perform a node-install to one private notes directory. It is the node install that places various programs and DLLs in the appropriate application and system directories.

Note

The Lotus Notes install attempts to replace MPR.DLL in the SYSTEM32 subdirectory. It is important that you do not change or replace the version of the DLL that is shipped with WINFRAME.

Note

In the version of Lotus Notes used in this configuration, there seemed to be a problem in the Node install when a non-default installation directory was specified. In this scenario, some portion of the install appeared to ignore the directory path specified and put some files in C:\Notes; the resulting install will not work. A workaround is to accept the defaults and move the directories later.

After testing the initial install, the node-installed directory was xcopied 19 times per server. This resulted in 20 node installations that could support the maximum 20 concurrent users on the WINFRAME server.

Additional servers were brought online by replicating these 20 directories on the other WINFRAME servers used to support the remote Notes users. For each additional WINFRAME server, the programs and DLLs in the SYSTEM32 and SYSTEM directories were also copied to each of the corresponding directories. These files were replicated manually to the other WINFRAME servers in this configuration using the REPLACE command: REPLACE source destination /A /P. The /A switch indicates to add new files to the destination directory instead of replacing existing files. The /P switch prompts for confirmation before replacing a destination file or adding a source file. As with any application, the System Integrator must avoid allowing an application to replace key Windows NT files that include important WINFRAME extensions. This rarely occurs but needs to be understood and monitored.

Note

This technique of replicating an application installation, although convenient, may not always work. In some instances it may be necessary to run the application installation procedure on each WINFRAME server.

Security Considerations

Once the users are configured and the applications installed, the File Manager is used to modify users access to files on the system.

User security is provided by making all Lotus Notes users members of the Domain Users group and by modifying the user profile. Some specific permissions were removed to secure the system, such as removing the ability to access and run CMD.EXE.

For example, one approach is to remove Everyone from any access to the application directories, add the Domain Users to the access list, and then change permissions on all application files and subdirectories in a tree structure similar to the one below.

In the example below the Notes node files that are required to be separate for each concurrent user are contained in the antxxx subdirectories. This naming convention is also used to name the WinStations.

These per-user Notes directories had to be given the following permissions for Notes to run correctly: Read, Execute, Delete, Create, and Write.

c:\apps
+Lotus
+Notes (the server-install with additional subdirectories)
+PvtNotes
+ant001 (the node-install, with additional subdirectoriess)
+ant002 (xcopy of ant001)
…
+ccMail
+wMail (cc:Mail wrapper application)

This one-root-directory structure is not required but does make setting permissions easier.

WINFRAME Configuration Considerations

Several features of WINFRAME were utilized to secure the system for remote access by a diverse and uncontrolled group of users. Several settings in WinStation Configuration and Advanced WinStation Configuration were utilized to limit a users ability to make changes to the system. These settings include:

Turn off all (inherit user configuration) settings

Turn off all client device connections

Reset workstation on broken or timed-out connection (dont leave session running for possible reconnect)

Set the Idle timeout to 5 minutes

Overview and Benefits of the Synergy
Between Notes and WINFRAME

Lotus Notes is an environment for developing applications that enable groups of people to share information and work together. There are two main parts to Notes. The first is the Notes Server program for NT, which can run on a WINFRAME server. The second part is the Notes Workstation program for Windows, which can also run on a WINFRAME server. Most times, an environment will have a Notes Server running on one system. This will either be a NetWare, Windows NT, or WINFRAME server. The Notes Workstation program can then be set up for Windows workstations on the network or for users on WINFRAME WinStations.

Lotus Notes is an industry-leading client/server application development platform. Notes applications are typically deployed in a LAN environment with a Microsoft Windows-based client front-end program and a back-end database server. A Lotus Notes application represents an advanced two-tier client/server application model.

While two-tier client/server applications perform very well on a high-bandwidth LAN, they are typically not optimized for low-bandwidth telephone or wide-area network (WAN) connections. Furthermore, they tend to demand high-powered client workstations and often present a client workstation software distribution and maintenance challenge.

Lotus Notes has the unique advantage of supporting a database replication capability. This enables the deployment of a distributed database architecture that can alleviate many of the WAN and dialin bandwidth problems that plague many two-tier client/server applications.

Unfortunately, the amount of distributed data needed by certain applications can result in network bandwidth problems even with Lotus Notes. In addition, even when network bandwidth is not an issue, the distribution and maintenance of software and hardware at remote sites can become expensive and unwieldy.

WINFRAME enables Lotus Notes-based solutions to take advantage of a three-tiered client/server architecture without any code changes to the Notes applications. WINFRAME and this three-tiered architecture provide the following benefits:

Reduces or eliminates the need for Notes database replication when a user has no need to operate when disconnected.

Supports fast remote execution of the Notes node (client) software even over low-bandwidth phone or WAN connections.

Reduces data traffic over WAN connections, which minimizes bandwidth requirements while increasing performance.

Simplifies administration of end-user software by minimizing the workstation hardware and software requirements while leaving the Notes client software centrally located on the corporate LAN/WAN.

Scaleable to hundreds or even thousands of concurrent users.

Additional Installation Notes

Installing Lotus Notes Server for NT on a WINFRAME Server

1.	It is recommended that you create an administrative user specifically for Lotus Notes on the WINFRAME server that will run the Lotus Notes Server. Once you have created this user, login at the WINFRAME console under this administrative username.

2.	Proceed with the standard Lotus Notes Server for NT installation. See the Lotus Notes documentation for specifics of the Lotus Notes Server installation.

3.	During the install, Do not add the Notes data directory to the system path. You must add it to the Lotus Notes administrators private path. Do this by clicking on the System application in the Windows Control Panel. Once there, select the Path statement in the User environment variables for administrator text box, where administrator is the name of the Lotus Notes administrator you are currently logged in as. Add the path of the Notes data directory, usually C:\NOTES\DATA, and click the Set button. Do not change the Path statement in the System Environment Variables text box. Make sure the path statement in the System Environment Variables text box does not have the Notes data path in it. When done, click the OK button to save your changes.

Installing the Lotus Notes Workstation Program for Windows

Note

The Lotus Notes Workstation program for Windows allows you to do a public install. It is suggested that you do a single public install to the WINFRAME server or to any available network server. Users who want to set themselves up for Lotus Notes access can then run the standard Lotus Notes Workstation Setup program from the public install by changing into that directory and running the Setup program. If you do a public installation of the workstation program, each user must Net Use the directory in order to install it if it is on the network. You cannot use the UNC name to install.

1.	Login as the user for which you want to set up the Lotus Notes Workstation for Windows program.

2.	If you did a public install of the Lotus Notes Workstation for Windows program, Net Use the directory if on the network; change into the public directory, and run the Setup program. If a public install was not done, load the CD-ROM or floppies as normal and do a normal install of the Workstation program.

3.	Repeat Steps 1 and 2 for each of the users for which you want to set up the Lotus Notes Workstation program for Windows.

Usage

Although both the Lotus Notes Server and many copies of the Lotus Notes Workstation for Windows can run on a single WINFRAME server, this is not always the best solution. If the system you are running WINFRAME on is a high end, SMP system with a large amount of RAM and a very fast hard disk subsystem, you may be able to do this. If you are working with smaller systems, you will get better performance splitting up the two parts of Lotus Notes.

For example, you might have a standalone Windows NT server that runs the Lotus Notes Server and install the Lotus Notes Workstation for Windows client programs on the WINFRAME servers on the network. This gives the Lotus Notes Server a system to itself, allowing it to use all of the system resources of the Windows NT server. The WINFRAME server can then concentrate on supporting many remote users, or those on the network who want to access the Lotus Notes Server elsewhere on the network. If the Lotus Notes Server is run on the WINFRAME server where users are trying to access it, you may find that performance is below average because WINFRAME is on an under-powered computer that cannot support both the Lotus Notes Server and many copies of the Lotus Notes Workstation. For that reason, the Lotus Notes Server should be given its own NT-based system, unless you are sure that the computer you are installing WINFRAME on can handle the extra load. WINFRAME is scalable and can handle both Notes Server and Notes Workstation, but performance depends on the computer WINFRAME is running on.


Microsoft Access 2.0
Software Application Notes	7 of 9

Microsoft Access 2.0

Microsoft Access 2.0 for Windows is a database management system, allowing the user to design and customize databases. The following is for user-specific installations. User-global installations should not have this problem. See the online Readme General Installation of Applications on WINFRAME for information on the preferred user-global install method.

Software Requirements

Microsoft Access 2.0 for Windows

WINFRAME

Installation

Follow the installation procedure in the Microsoft Access documentation.

Configuration

If the Output To option in the File menu returns No Output Formats Installed, copy the file MSACC20.INI, found in the users \WINDOWS directory, to the %SystemRoot% directory on the NT boot drive. After copying the MSACC20.INI file to the system directory, the Output To option in the File menu will function correctly.


Microsoft Power Point 4.0
Software Application Notes	8 of 9

Microsoft PowerPoint 4.0

Microsoft PowerPoint 4.0 is a presentation tool used to generate slideshow presentations. The following procedure is for user-specific installations, and is not required for user-global installations. See the online Readme General Installation of Applications on WINFRAME for information on the preferred user-global install method.

Software Requirements

Microsoft PowerPoint 4.0

WINFRAME

Installation

Refer to the Microsoft PowerPoint 4.0 documentation. It is preferable to do a network server install and then allow individual users to set themselves up by running the Setup program from the network server directory.

Configuration

Because this is a 16-bit application, each user must be set up for this application individually. Once the server install is completed on a network server or the local WINFRAME system, each user should run the PowerPoint Setup program. This will configure the correct .INI files and settings needed to run the application.

Usage

Although the application has full functionality as installed, there is one additional note about its use. If installed correctly, when the application starts, the user will receive a popup error message claiming the application could not find the POWERPNT.INI file. As a result, no startup information will be saved. This includes, for instance, removing the Show Tips at Startup option. This is due to an installation bug in PowerPoint 4.0. To fix this problem, place a blank file called POWERPNT.INI in the main \WINFRAME directory. To do this:

1.	Log in as an administrator at the WINFRAME console. Start a Command Prompt session.

2.	Type copy con powerpnt.ini and press ENTER. Press CTRL+Z and press ENTER. Type exit and press ENTER.

PowerPoint 4.0 will now load and function normally.


WordPerfect for Windows, Version 6.1
Software Application Notes	9 of 9

WordPerfect for Windows, Version 6.1

WordPerfect for Windows is a word processing application. The following information is for both user-specific and user-global installations. See the online Readme General Installation of Applications on WINFRAME for more information.

Software Requirements

WordPerfect for Windows

WINFRAME

Installation

To do a user-specific installation for one user (not recommended), follow the standard installation procedure outlined in the WordPerfect documentation.

To do a user-global installation (recommended method)

1.	Login as an administrator at the console

2.	At a command prompt, type change user /install.

3.	Install WordPerfect following the standard installation procedure outlined in the WordPerfect documentation.

4.	At the command prompt, type change user /execute.

All users on the system should now be able to run WordPerfect. Please read the General Installation of Applications on WINFRAME for more information.

Usage

If you are using a Hewlett Packard (HP) LaserJet 4 printer and have the HP LASER JET 4 printer driver, you may experience long delays while printing very large print jobs. To fix this problem, an older version of the HP LASER JET 4 printer driver is provided for your use on the WINFRAME installation CD-ROM in the path:

\SUPPORT\CITRIX\HPPCL5MS.DLL

Replace the driver and the problem should resolve itself. If you are not experiencing any of these problems, use the default driver. If you still have a problem, contact your HP dealer or HP support for the latest Windows NT driver for HP LaserJet 4 printers.