Digital PDFs

XX-55E46-A3

May 1997

26 pages

Original

48.9kB

Document:	PATHWORKS for OpenVMS V5 Integrating with Windows NT
Order Number:	XX-55E46-A3
Revision:	0
Pages:	26
Original Filename:	PATHWORKS_for_OpenVMS_V5_Integ_19may1997LI01Q1PF.pdf

OCR Text

Revision 05/20/97

PATHWORKS for OpenVMS V5
Integrating with Windows NT

A White Paper on the Technical Issues of Microsoft Windows NT
Interoperability in the PATHWORKS for OpenVMS Environment

May 1997

DIGITAL believes the information in this publication is accurate as of its publication date; such information is subject to
change without notice. DIGITAL is not responsible for any inadvertent errors.
DIGITAL conducts its business in a manner that conserves the environment and protects the safety and health of its employees,
customers, and the community.
DIGITAL, the DIGITAL logo, PATHWORKS, VAX, and OpenVMS are trademarks of Digital Equipment Corporation.
Microsoft, Windows, Windows NT, Windows 95 and MS-DOS are trademarks or registered trademarks of Microsoft
Corporation.
Printed in U.S.A. Copyright 1997 Digital Equipment Corporation. All rights reserved.

Digital Equipment Corporation

Preface
The intended audience for this white paper includes computing professionals
involved in the decisions related to multivendor desktop and server platform
interoperability.

Need for Highly Available Servers Within Domains

Users with LANMAN Network Accounts and OpenVMS Accounts

OpenVMS or Digital UNIX Applications

DECnet Nodes and/or Applications

TCP/IP Hosts and/or Applications

The goal of this white paper is to provide facts regarding the technical issues
involved when creating a multivendor production environment consisting of
Windows NT and PATHWORKS V5 servers together with various desktop client
platforms.

Digital Equipment Corporation

Revision History

Overview

Inter-operating in a Windows NT Domain

Merging a PATHWORKS V5 PDC into a Windows NT Domain

Setting up a PATHWORKS V5 Backup Domain Controller or Member Server

Managing User Accounts

Managing User Profiles

Managing PATHWORKS Server in a Windows NT Domain

PATHWORKS Clusters

Enabling Browsing

Managing Shares

Setting up Print Shares

Connecting to a PATHWORKS Server from a Windows NT Client

Common Network Protocol

PATHWORKS Client Licensing

Connecting to PATHWORKS File Shares

Domain Logon

Digital Equipment Corporation

Revision History
Revision
0.1
0.2

Date
7/1/96
11/1/96

0.3
0.4
0.6
0.7
0.8
0.9
0.9a
0.9b
1.0
1.1

11/1/96
11/4/96
11/7/96
11/7/96
11/8/96
11/9/96
11/24/96
1/16/97
1/20/97
5/6/97

Author
Ronnie Cheng
Richard Boulifard
Michael Smith
Michael Stewart
Nelson Wilkinson
Diane McFarland
Michael Stewart
Ronnie Cheng
Michael Stewart
Brad Cooper
Michael Stewart
Diane McFarland
Ronnie Cheng
Mike Stewart
Mike Stewart

Edit History
Outline of contents
Initial technical writing of document

Editorial review of document
Editorial changes to document format
Engineering technical review
Editorial changes from 0.6
Independent technical review
Editorial changes from 0.8
Editorial review from 0.9
Final review
Final review changes from 0.9b
New license changes

Digital Equipment Corporation

Overview
The PATHWORKS V5 for OpenVMS server works well as a down-level server in a Windows NT
domain. Due to the differences of protocol level, there are a number of steps that need to be
taken to ensure a seamless integration into the Windows NT network environment. This
document attempts to identify these steps and the known limitations.

Digital Equipment Corporation

Inter-operating in a Windows NT Domain
A Windows NT domain is defined as a domain where a Windows NT server functions as the
Primary Domain Controller (PDC). A PATHWORKS V5 for OpenVMS server can assume the
role of a Backup Domain Controller (BDC), Member server or Standalone server in a Windows
NT domain as a “down-level” server. A down-level server is a server running in a Windows NT
domain that supports an SMB protocol level less than V3.0. The concept of Member server is
different in a Windows NT domain than in a LAN Manager V2.2 domain. For ease of reference
in this paper, when the term “Member server” is used, it is based on the LAN Manager V2.2
definition. The server will behave in the network as expected in the LAN Manager V2.2 style.

Digital Equipment Corporation

Merging a PATHWORKS V5 PDC into a Windows NT Domain
Perform the following steps:
1. Put the PATHWORKS server in Standalone mode and set the Guest account password to
blank (null) using the undocumented LMUSER command:
$ NET ACCOUNTS /ROLE:STANDALONE
$ @SYS$STARTUP:PWRK$DEFINE_COMMANDS.COM
$ LMUSER –MP “” GUEST
2. Ensure a common transport is running on both systems:
 The choices are NetBEUI, TCP/IP, or DECnet. Note that NetBEUI is not

routeable.
 If TCP/IP is used, the LMHOSTS file may need a PATHWORKS server entry.
 Check the Network icon in the Control Panel for available Windows NT

transports.
 Check the ADMIN utility for configured transports on the PATHWORKS server.

3. Run the upgrade procedure on the PATHWORKS server: (Sample output from the upgrade
procedure can be found at the end of this section.)
$ SET DEF SYS$UPDATE
$ @PWRK$UPGRADE
select Additional Upgrade Utilities
select UAS Merge
select Standalone UAS Merge Report (if needed)
select Standalone UAS Merge
The LANMAN accounts on the PATHWORKS server will be copied to the Primary
Domain Controller system. The status of the passwords for those accounts will be as
follows on PATHWORKS Version 5.0C ECO3 and later servers:
If the PDC is a Windows NT machine, and the keyword “mergepwd_username”
is set to “Yes” in the [VMSSERVER] section of the PATHWORKS file
PWRK$LMROOT:[LANMAN]LANMAN.INI, the account's username is
passed along as the password during the UAS Merge.
If the PDC is a Windows NT machine, and the keyword “mergepwd_username”
is not set to “Yes”, then the password after the UAS Merge will be unknown.
Windows NT machines will not accept encrypted passwords.
(Prior to 5.0C ECO3, merged LANMAN user accounts had unknown passwords.)
4. At the end of the merge procedure, select the new PATHWORKS server role:
0 for Backup Domain Controller
1 for Member Server
5. Make sure the time is synchronized on the PATHWORKS system and the Windows NT PDC:
$ SET TIME=30-OCT-1996:19:31:0.0

Digital Equipment Corporation

Perform the following steps on the Windows NT PDC:
1. Make Guest Account Modifications:
Enable Guest account. (It's disabled by default). Set it to have a null password. This
can be done via User Manager. Select Policies Account Allow Blank Passwords.

2. Make User Accounts Modifications:
Add the text: “HOSTMAP=vmsuser” in the account’s Description field. This will allow
synchronization between UAS and UAF. This is only necessary if the OpenVMS account
is different than the UAS account.
Make certain that the GROUP Servers is a global group.
3. SYNC the Domain on the Windows NT machine:
Server Manager

Select a Server  Computer Menu  Sync with entire Domain

4. Enable Browsing between LAN Manager 2.x and Windows NT.

Enable NT to browse LM 2.x Clients:

Select Control Panel
Network
from Installed Network Software
LANMAN domains.

Network Settings  choose Computer Browser
 Configure  in Browser Configuration, add

NOTE:
If using the NT 3.5 Workstation only: to add LANMAN domains, edit the registry and
set the parameter OtherDomains to the name of the domain the workstation needs
to see. This parameter has a data type of REG_MULTI_SZ under this key:
\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet
\Services\LanmanWorkstation\Parameters
For example, if the LAN Manager domain name is FIDO—after setting the parameter,
this value would show in the Registry Editor: OtherDomains:REG_MULTI_SZ:FIDO.

Enable LM 2.x Servers to Browse NT:

Select Control Panel
Network
Network Settings
choose Server from Installed
Network Software
Configure
in Server Dialog Box, check Make Browser
Broadcasts to LM 2.x Clients.

NOTE:
If using the NT 3.5 Workstation only: to enable the LM 2.x to Browse NT feature, edit
the registry and change the Lmannounce setting from 0 to 1 under:
\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet
\Services\LanmanServer\Parameters

Digital Equipment Corporation

NOTES:
The Windows NT domain controller does not require a PATHWORKS license for
domain communication. However, a license would be required if the Windows NT server
needs to make connections to PATHWORKS V5 file or print services or to perform
management functions (such as deleting shares, etc.).

Sample output from upgrade procedure:
The following procedure merges PATHWORKS users and groups from an OpenVMS system
with users and groups on a Windows NT system. When OpenVMS-based PATHWORKS
systems share a domain with Windows NT systems, the NT system must be the Primary
Domain Controller (PDC).
If the OpenVMS system is switched to a Backup or Member server in the Windows NT's
domain, the Windows NT user database will overwrite the OpenVMS PATHWORKS user
database. All users and groups on the OpenVMS system will be lost. The merge procedure
saves the user database by combining it with the user database on the Windows NT system.
Before starting, make a backup copy of the OpenVMS system PATHWORKS user
database. Copy the file PWRK$LMROOT:[LANMAN.DATAFILES]ACCOUNTS.LMX to a
different directory, or to tape, so a backup will be available, if needed.
PROCEDURE:
The exact steps for a UAS merge are detailed below:
1. $ @SYS$UPDATE:PWRK$UPGRADE
This procedure shuts down the currently running PATHWORKS V5 server.
Do you want to continue with upgrade [yes]: <CR>
Shutting down the currently running server(s)...
Stopping IPX Daemon (NPSD)...OK
PATHWORKS is configured to use DECnet, NetBEUI, TCP/IP.
>>If you are upgrading a server in an existing domain that has a designated
>>Primary Domain Controller, the upgrade procedure communicates with it to
>>enumerate users and groups in the existing domain.
>>If you are not upgrading a server in an existing domain, press Return.
Are you upgrading a server in an existing domain [no]:YES
>>The upgrade procedure uses only one of the transports configured on the server.
>>Choose a transport and make sure that the designated Primary Domain Controller
>>is running that transport.

Digital Equipment Corporation

Which transport do you want to use for upgrade [DECnet]: NetBEUI
Starting NBDAEMON in order to perform upgrade over NetBEUI...
Process PWRK$NBDAEMON created with identification 00000133
Enter the name of the Domain [PF2 for Help]: NTDOMAIN
Enter Primary Domain Controller's node name [PF2 for Help]: NT1
Enter a user name for a privileged account [Admin | PF2 for Help]:<CR>
>>This assumes that an account called Admin has been created on the NT server.
Enter password:xxxxxxx
>>The Upgrade Utility menu appears.
Additional Upgrade Utilities
UAS Merge.
Standalone UAS Merge Report
>>Use the report to view users and groups that will be merged. Uncommented
>>lines will be executed. Edit the report as desired.
Standalone UAS Merge.
Do you want to use a UAS Merge report as input to the Standalone UAS merge?
Enter Y or N, or press Return to use the default: Y
Specify the UAS Merge report for the Standalone UAS merge on the next
line [PWRK$LMUPGRADE:PWRK$UPG$UAS_SA.RPT is default] <CR>
>>Accounts and groups are added at the PDC and the message “UAS Merge
>>complete” is displayed.
Please enter the node name of this system [VMSSYS | PF2 for Help]<CR>
>>The OpenVMS system's name is added to the Servers group on the PDC.
Enter new workstation role [0 for backup, 1 for member, PF2 for Help]:0
Standalone merge complete
press Return to continue <CR>
Return to Previous Menu
Exit
>>Check the User list on the NT PDC to make sure the account database was
>>updated with users from the OpenVMS system.
Start PATHWORKS on the OpenVMS system. It should come up as a Backup or
Member server in the NT domain.

Digital Equipment Corporation

2. $ @SYS$STARTUP:PWRK$STARTUP
>>Verify server’s role by using the DCL command $NET ACCOUNTS.
$net accounts
Force user logoff how long after time expires:
Lock out account after how many bad passwords:
Minimum password age (days):
Maximum password age (days):
Minimum password length:
Length of password history maintained:
Server role:
Primary Domain Controller for workstation domain:

Never
Never
0
Unlimited
0
None
BACKUP
\\NT1

The command completed successfully.

Digital Equipment Corporation

Setting up a PATHWORKS V5 Backup Domain Controller or Member Server
In LAN Manager V2.2, a Backup Domain Controller (BDC) and/or a Member server gets an
updated copy of the User Accounts Subsystem (UAS) from the Primary Domain Controller (PDC)
so that they share the same user and group information. The BDC also runs the NETLOGON
service and can perform NETLOGON authentication for clients. The Member server does run the
NETLOGON service, but it does NOT perform NETLOGON authentication for clients.
********************************** WARNING: *************************************
These steps result in the Windows NT user database overwriting the
PATHWORKS server user database. To avoid loss of the user database,
perform the UAS merge procedure in the PWRK$UPGRADE utility.
Refer to the section “Merging a PATHWORKS V5 PDC into a Windows
NT Domain” for more information.
**************************************************************************************
Perform the following steps on the indicated (PW or NT) system:
The following steps assume the PATHWORKS server is currently a Standalone LAN Manager
server. If the PATHWORKS server is currently a PDC, BDC or Member, see the section titled
“Merging a PATHWORKS V5 PDC into a Windows NT Domain”.
PW

1. Modify the PWRK$LANMAN:LANMAN.INI file for correct host account mapping,
password synchronization, and compatibility mode settings:
(See the PATHWORKS Server Administrator’s Guide for further details on these
settings.)
[VMSSERVER]
applyhostmapcomment = yes
When a user connects to the server, this parameter determines if the server
looks for an OpenVMS account name that matches the LAN Manager account
name.
hostmapmode = if_exist_else_default
This parameter determines to which account a user maps. The setting
“if_exist_else_default” means map to PWRK$DEFAULT if there is no OpenVMS
account.
hostpasswordsync = yes
This specifies whether the password for each LAN Manager user account is to be
synchronized with the password for its corresponding OpenVMS account.
compatibility = no
This setting determines if there will be support for clients with earlier versions of
the PATHWORKS client software as well as for those running PATHWORKS V5
for DOS and Windows.
[WORKSTATION]
domain = ntdomainname
This specifies the name of the domain that includes the server.

Digital Equipment Corporation

2. Start/restart PATHWORKS and clear the Guest account password using the
undocumented LMUSER command:
$ @SYS$STARTUP:PWRK$STARTUP.COM
$ @SYS$STARTUP:PWRK$DEFINE_COMMANDS.COM
$ LMUSER –MP “” GUEST

3. Make Windows NT User Accounts Modifications:
Add the text: “HOSTMAP=vmsuser” in the account’s Description field. This will
allow synchronization between UAS and User Authorization File (UAF). This is only
necessary if the OpenVMS account is different than the UAS account.
Make certain that the GROUP Servers is a global group.
Create an account called Admin that matches the PATHWORKS LAN Manager
Admin account and put it in the Administrators group.
Enable Guest account. (It's disabled by default.) Set it to have a null password. This
can be done via User Manager. Select Policies Account Allow Blank Passwords.

4. Enable Browsing between LAN Manager 2.x and Windows NT.

Enable NT to browse LM 2.x Clients:

Select Control Panel
Network
from Installed Network Software
LANMAN domains.

Network Settings  choose Computer Browser
 Configure  in Browser Configuration, add

Enable LM 2.x Servers to Browse NT:

Select Control Panel
Network
Network Settings
choose Server from Installed
Network Software
Configure
in Server Dialog Box, check Make Browser
Broadcasts to LM 2.x Clients.

Digital Equipment Corporation

BOTH 5. Ensure a common transport is running on both systems:
The choices are NetBEUI, TCP/IP, or DECnet. Note that NetBEUI is not a routeable
protocol. If TCP/IP is used, the LMHOSTS file may need a PATHWORKS entry.
Check the Network icon in the Control Panel for available Windows NT transports.
Check the ADMIN Utility for configured transports for the PATHWORKS server.
PW

6. Make sure the time is synchronized on the PATHWORKS server and the NT PDC:
$ SET TIME=30-OCT-1996:19:31:0.0

7. Logon to PATHWORKS server using the Admin account:
$ NET LOGON ADMIN <password>

8. Change server role to Backup Domain Controller or Member Server:
********************************** WARNING: *************************************
This step results in the Windows NT user database overwriting the
PATHWORKS server user database. To avoid loss of the user database,
perform the UAS merge procedure in the PWRK$UPGRADE utility.
Refer to the section “Merging a PATHWORKS V5 PDC into a Windows
NT Domain” for more information.
**************************************************************************************
$ NET ACCOUNTS /ROLE:BACKUP
**or**
$ NET ACCOUNTS /ROLE:MEMBER

NOTES:
1. The Windows NT domain controller does not require a PATHWORKS license for
domain communication. However, a license would be required if the Windows NT
server needs to make connections to PATHWORKS V5 file or print services or to
perform management functions (such as deleting shares, etc.).
2. The BDCs will receive user account information from the PDC and will validate user
logon requests. The Member servers will receive user account information from the
PDC, but they will NOT validate user logon requests.

Digital Equipment Corporation

Managing User Accounts
There are some differences in the way user accounts are administered on Windows NT servers
and PATHWORKS V5 servers. The following is a comparison of some of the important account
fields and how they can be managed:
General
Default Administration Account Name
Default Users
Default Groups

NT Server
PATHWORKS Server
Administrator Admin
Guest
Guest
Users, Guests, Admins*, Users*, Guests*
Administrators,
Replicators,
Backup Operators

Account Fields
Name
Full Name
Description
Comment
User Comment
Password
Confirm Password
Host Map
Privilege Level
Operator Privileges
User Must Change Password at Next Logon
User Cannot Change Password
Password Never Expires
Account Disabled
Group Membership
User Profile Path
Logon Script Name
Home Directory (Local or Connect To)
Logon Hours
Logon To
Account Expiration
Logon Domain
User Storage Limit
Hostname

NT Server
Y
Y
Y
N
N
Y
Y
*Note1
N
N
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
N
N
N

PATHWORKS Server
Y
Y
N (description in NT
Y maps to comment in V5)
Y
Y
N
Y
Y
Y
N
N
N
Y
Y
N
Y
Y
Y
Y
Y
Y
Y
Y

*Note1: Hostmap on a PATHWORKS system is equivalent to the Description field being set to
“hostmap=vmsuser” on the Windows NT system.
Tool Name
User Manager for Domains
User Manager for Domains
NetAdmin
ADMIN/PATH

Digital Equipment Corporation

Operating System
WIN NT
WIN 95 (from Resource Kit)
WIN 3.1/WFW 3.11
OpenVMS

Managing User Profiles
Due to the differences between Windows NT and PATHWORKS V5, there are certain fields in
the user profile that can be set on Windows NT that have no translation on the PATHWORKS V5
server. This section identifies the fields which cannot be managed from the other server.
Using the User Manager for Domains utility from the Windows NT server to manage a
PATHWORKS V5 server:
The following fields cannot be entered: Comment, User Comment, Logon
Domain, User Storage Limit, VMS Hostname.
To set the Hostmap field on the PATHWORKS server, set the Description field
to be “hostmap=vmsusername”.
Local Groups are not viewable in ADMIN/PATH but are via NET commands.
(Hint: Only utilize Global Groups.)
Creating a new account will not create an OpenVMS user account on the
PATHWORKS system.
Using the ADMIN utility from the PATHWORKS server to manage a Windows NT
server:
The following fields cannot be entered: Description, Confirm Password, User
Must Change Password at Next Logon, User Cannot Change Password,
Password Never Expires, User Profile Path.
Creating a new account will create a personal share on the PATHWORKS
system, but it will fail to set permissions correctly on this share. Either remove
the personal share or set the desired permissions.
Local Groups are not viewable in ADMIN/PATH but are via NET commands.
(Hint: Only utilize Global Groups.)
Since the Password Never Expires field does not exist on the PATHWORKS
server, the Guest account password (if present) will expire on the PATHWORKS
system after the number of days specified in the Security Settings section of the
ADMIN menu.

Digital Equipment Corporation

Managing PATHWORKS Server in a Windows NT Domain
Although PATHWORKS and Windows NT are related network operating systems, they are
slightly different. In addition, there are differences between OpenVMS and the Windows NT
operating system in regard to administration, security, and licensing. The following pages detail
some considerations and limitations for managing a PATHWORKS server that is in a Windows
NT domain.

Digital Equipment Corporation

PATHWORKS Clusters
An OpenVMS cluster has some special considerations when more than one node is running
PATHWORKS for OpenVMS (LANMAN) V5.0.
The considerations revolve around the fact that all members of the OpenVMS cluster running
PATHWORKS V5 must be running in the same LAN Manager role. All members of the cluster
running PATHWORKS V5 must have: a common SYSUAF and RIGHTSLIST; a common
PWRK$ROOT (meaning on the same cluster-accessible drive); and, due to the manner in which
NETLOGON runs in a cluster, all members must be on the same network (e.g., no split-rail
Ethernets).
Other important facts: The account in the Servers group that matters when a cluster is being
used is the PATHWORKS cluster alias account name. That account name must be different
than any of the server names and the domain name. Also note that Windows NT acting as a
client has trouble connecting to a PATHWORKS V5 cluster alias, since the NT client cannot
resolve the alias name. So those clients should connect directly to a node in the cluster.

Digital Equipment Corporation

Enabling Browsing
Microsoft Windows-based LAN Manager clients (Windows for Workgroups, Windows 95 and
Windows NT) use what Microsoft calls a “master browse server” to help clients browse shared
resources on the network. Master browse servers listen for LANMAN service announcements
and keep a list of LANMAN servers in their workgroup or domain. Backup browse servers are
also created automatically when more than 15 Windows for Workgroups or Windows 95 clients—
or 31 Windows NT clients—are started in a workgroup or domain. When the user browses the
network from a Microsoft Windows client and double-clicks on a workgroup or domain name, a
request is sent to the master browse server or to one of the backups for a list of LANMAN
servers in that workgroup or domain. Any Microsoft Windows-based client can be a master
browse server. However, a PATHWORKS V5 server can not function in this capacity since the
V5 server runs an earlier version of LANMAN.
For a client to browse a PATHWORKS V5 server, several requirements must be met:
1. The Microsoft Windows client that is browsing must have a PATHWORKS client-based
license loaded into its PATHWORKS license responder, or the server must have serverbased licenses loaded and available.
2. There must be at least one Microsoft client with its workgroup name set to the same name as
the PATHWORKS domain.
3. If the Microsoft client is a Windows for Workgroups or a Windows 95 machine, it must have
file sharing enabled. In Windows for Workgroups, this is done by selecting Network
Network Setup Sharing. On a Windows 95 machine, this service is added by choosing
Settings Control Panel Network.

After it is configured and rebooted, the master browse server will need several minutes to build a
list of available servers in the domain or workgroup. If there is only one Microsoft client in the
workgroup or domain that can act as a master browse server, then that machine must stay on all
the time in order for other Microsoft clients to be able to browse.
More information about browsing and masters browse servers can be found in the Windows 95
Resource Kit, Windows for Workgroups Resource Kit, or Windows NT Resource Kit.

Digital Equipment Corporation

Managing Shares
Although Windows NT and LAN Manager V2.2 use different versions of the SMB specification,
there are certain share management functions that can be performed when the Windows NT and
V5 servers are in the same domain.
Function

From NT to V5

From V5 to NT

VIEWING SHARES
ADDING SHARES
STOPPING SHARES
PAUSE SHARING
VIEWING PERMISSIONS
SETTING PERMISSIONS
VIEWING SESSIONS
STOPPING SESSIONS
VIEWING CONNECTIONS
STOPPING CONNECTIONS
VIEWING STATISTICS
VIEWING SERVICES
STOPPING SERVICES
STARTING SERVICES

Y
N
Y
Y **
N
N
Y
Y
Y
Y
Y ***
Y
Y
Y ****

Y
Y*
Y
Y
N
N
Y
Y
Y
Y
Y
N
N
N

* if directory exists, and the path is obtained by the GUI, using the Dir button
** by pausing the Server service
*** limited
**** cannot set startup options

Digital Equipment Corporation

Setting up Print Shares
For proper operation of PATHWORKS print shares in a Windows client environment, the
OpenVMS print queue name and the PATHWORKS V5 share name should be the same. If the
names are different, Windows will ask for the status of the print queue by the name of the print
share. This will fail and cause the Windows client to show the print share in an error condition. If
the names are the same, the Windows client will get back the status of the queue and will show
the jobs in the queue. A workaround to this problem is to create an OpenVMS logical that points
the share name to the queue name by executing:
$ DEFINE /SYS /EXE <sharename> <queuename>
If it is to be used on a permanent basis, this DEFINE command needs to be in the OpenVMS
system startup procedure.

Digital Equipment Corporation

Connecting to a PATHWORKS Server from a Windows NT Client
In order to make file and print connections, the Windows NT client (whether Workstation or
Server) requires no special software or configuration, with the following exceptions: the client
and server must share a common protocol, and the client must be properly licensed to connect
to the PATHWORKS server. A PATHWORKS V5 server will refuse unlicensed connections
from Windows NT clients.
Windows NT clients and PATHWORKS V5 servers are both LAN Manager based. Thus, they
can communicate with one another. However, the following points—common network protocol,
PATHWORKS client licensing, connecting to PATHWORKS file shares, and domain logon—
should be considered. These will be discussed on the following pages.

Digital Equipment Corporation

Common Network Protocol
There has to be a common network protocol between the Windows NT client and the
PATHWORKS server for a connection to be made. The PATHWORKS V5 server is capable of
LAN Manager file and print connections over TCP/IP, DECnet and NetBEUI. The Windows NT
client has native network protocols for TCP/IP and NetBEUI, and it can run DECnet by installing
PATHWORKS for Windows NT. PATHWORKS for Windows NT is only required if DECnet is
needed on the Windows NT client.
WAN connections can be made over TCP/IP and DECnet (if installed). To make a WAN file and
print connection over TCP/IP, add the IP address and name of the PATHWORKS server to the
LMHOSTS file. If WINS is being used, add the PATHWORKS server information to the WINS
database. To make a WAN file and print connection over DECnet, define the PATHWORKS
server as Object 64 in the Remote Adapter table in the NCP database. NetBEUI, which is a nonrouteable protocol, does not support WAN connections.

Digital Equipment Corporation

PATHWORKS Client Licensing
The PATHWORKS V5 server will refuse a file and print connection from a Windows NT machine
without a valid PATHWORKS license. There are two licenses that could be used, depending on
the Windows NT client configuration:
A “native” Windows NT client ( i.e., no PATHWORKS is installed on the Windows NT machine)
can use a client license. Or the native Windows NT client can use a server license. To use the
PATHWORKS client license, the PATHWORKS client license requester must be installed on the
Windows NT machine and configured to request the correct license. The PATHWORKS license
requester can be installed from the PATHWORKS CD-ROM or from the PATHWORKS FPA
License Requester kit, which can be obtained from the Digital Customer Support Center or
copied from the Internet. No PATHWORKS client requester is required with server licensing.

Digital Equipment Corporation

Connecting to PATHWORKS File Shares
After proper PATHWORKS licensing is configured, connecting to PATHWORKS file shares is
accomplished in the same manner as connecting to Windows NT file shares—through Network
Neighborhood, Explorer or Start Run \\servername\sharename. Note that Start Run
\\servername\sharename does not work with personal shares.

Digital Equipment Corporation

Domain Logon
All clients need a PATHWORKS license to logon to a PATHWORKS domain controller.
Also, a Windows NT Workstation client (configured for domain logon) cannot get domain logon
validation from a PATHWORKS V5 server, since the Windows NT product is a later version of
LAN Manager than the PATHWORKS server product.

Digital Equipment Corporation