Conference noted::pwdoswinv5

    Hi,
        
    >Could someone clarrify this for me please ?
    >I have a customer with a VAX with 3 network adapters with PC's hanging
    >off each run running DECnet.
    >1. In looking at previous notes I believe NETBIOS over DECnet is supported
    >on only one adapter (i.e. only BROWSE on one run). Y/N
    
    Correct.
    
    >2. If this is the case then PCs will *NOT* be able to perform logon
    >validation over the 2nd/3rd adapters. i.e. They will receive the
    >message "You were logged on .... but not validated". Y/N
    
    Correct.  (The message may be more like "No domain controllers could
    be found...".)
    
    >3. The PC's on the 2nd/3rd adapters *CAN* connect to services if they
    >specify the service name but will NOT be able to browse. Y/N
    
    Not sure if browsing won't function (depends on whether the redirector 
    in use checks the local decnet netbios cache first; I'll defer to the
    client folks here).  As for connecting to services/shares, yes it can
    be done, but with one requirement (see comments for 4. below).
    
    >4. The PC's on the 2nd/3rd adapters *WILL* be able to acquire a
    >license *IF* they NCP DEFINE NODE xx.xxxx NAME yyyy
    >                  NCP DEFINE REMOTE-ADAPTER-NAME PWRK$Lyyyy
    
    You also need the MS-NET flag set - nodes defined with MS-NET flag are
    preloaded into the local decnet netbios cache.  When connecting to
    shares, the local cache is checked first (thus avoiding the netbios
    broadcast seeking the decnet address of the specified server).  So your
    first NCP command should be:
    
    	NCP DEFINE NODE <xx.yyy> NAME <nodename> MS-NET
    
    >5. With respect to the license server name, this is a tricky one - The
    >V5 server update was performed (a long time ago) on one of the nodes in 
    >the cluster origionally (for testing purposes) but now runs on another
    >therefore the LICENSE SERVER thinks it is the OLD server. i.e. License
    >software says a license was successfully loaded from zzzz when in
    >actual fact it was loaded from yyyy.
    
    This is a common misconception.  The license server is a separate
    entity and therefore, maintains its own, separate NETBIOS name.  This
    name just happens to be derived from either the DECnet cluster alias
    name (if it exists) or the nodename of the cluster node on which the
    license server is originally started.   But that name is no way tied to
    that specific cluster node.  In fact you could copy the license
    database file to another non-clustered vms server and the name will
    remain PWRK$Lold-vax-name.  But that's ok.  That's the name the clients
    which already have obtained a license are looking for. 
    
    The only thing you need to remember is to tie the decnet nodename of
    the node currently running the license server to the license server
    name.  Be aware that since the license server is defined as a specific 
    node in the cluster (in the remote adapter table on the clients in
    networks #2 & #3), you must ensure the license server process always
    runs on that cluster node (I know they run it on only one node now, but
    things change ;o).  The pwrk$license_server_inhibit logical name is
    used for that purpose (defined on nodes you wish NOT to run the license
    server).
    
    >All pathworks modules run on the one node in the cluster. This being the
    >case they have two options for loading licenses over the WAN.
    
    They have two options, but not the two you describe.
    
    >  a. Update the license server name in the database and
    >     DEFINE NODE current-pworks-node-no NAME current-vax-name
    >     DEFINE REMOTE-ADAPTER-NAME PWRK$Lcurrent-vax-name
    >
    
    Clients which already obtained a license from PWRK$Lold-vax-name will
    still try to verify their license with that name.  I'm still not clear
    here, but I think you'd have to take some action on each client (ie,
    delete the pwliclm.dat file) so they would seek out the new license
    server name.
    
    >  or
    >   b. DEFINE NODE current-pworks-node-no NAME old-vax-name
    >     DEFINE REMOTE-ADAPTER-NAME PWRK$Lold-vax-name
    
    Nope.  The "old-vax-name" isn't necessary, MS-NET is missing, and your
    2nd command would fail (you didn't provide the nodename that owns the
    remote adapter name).  If you don't want to affect clients which have
    already obtained a license from "old-vax-name", just define whatever
    decnet node is the current license server as you normally would.  Then
    tie the license server name to that node definition:
    
    NCP DEFINE NODE current-pworks-node-no NAME current-pwrks-node-name MS-NET
    NCP DEFINE REMOTE-ADAPTER-NAME PWRK$Lold-vax-name current-pwrks-nodename
              
    HTH,
    
    Paul

>    4. The PC's on the 2nd/3rd adapters *WILL* be able to acquire a
>    license *IF* they NCP DEFINE NODE xx.xxxx NAME yyyy
>                      NCP DEFINE REMOTE-ADAPTER-NAME PWRK$Lyyyy

	You should add "MSNET" to the end of the "DEFINE NODE"
	command and you will have to add the node name to the 
	"DEFINE REMOTE-ADAPTER-NAME" command.  See:

		NCP HELP DEFINE REMOTE-ADAPTER-NAME

	You will also need to tell the client licensing software the
	NetBIOS name of the license server.  If you run PWSETUP
	in "Administrator" mode you will be prompted for the
	data.  Otherwise you edit your template and set the
	LICSERVER keyword.

>    5. With respect to the license server name, this is a tricky one - The

	Look at the first few lines of the License Server log file to
	see what name it is using.