Conference noted::pwv50ift

    
    I guess I should have been a bit more explicit, but so there's no
    confusion, I'm talking LANMAN domains and not IP (DNS) domains.  DNS
    is not involved here.
    
    Paul

    NETLOGON sends out a mailslot to the IP broadcast address for the
    domain name.
    
    How can you resolve this in a wide area network? (answer yourself
    pls).
    
    All NETLOGON "processes" listen for incoming mailslot requests on
    the domain name. If members in a cluster receive such a mailslot,
    then only 1 cluster member has access to the UAS, so this is the
    one that will validate this mailslot request against the UAS. We
    call this the active member in the cluster. Which of the cluster
    members this is, is dependend (as you noticed) on which node was
    first started and where there any fail-overs.

    issue 2
    
    For replication, the PDC sends out a announce uas info mailslot to
    the domain name whenever there is a need to do so (every pulse inter-
    val or in between when there is a need for a uas update). Again this
    mailslot is received by every mailslot listener in the domain.
    
    Only the active node in the cluster (for a BDC) will process this
    message if a uas update is required. It is that node that will
    establish a connection to the PDC to request an update. If the PDC
    is a cluster then the PW cluster alias name is used, but if the
    PDC is a single node then the .... name is used. (Fill in yourself).
    
    Now if you use the PW cluster alias then the disadvantages are:
    - (Think of them yourself)
    Now if you use the server name then......
    
    Ergo,
    The PDC can better be a 1) cluster, 2) Single system (pick 1...)
    

    
    Now I'm more confused...and getting highly frustrated.
    
    >NETLOGON sends out a mailslot to the IP broadcast address for the
    >domain name.
    >
    >How can you resolve this in a wide area network? (answer yourself
    >pls).
    
    You can't resolve the broadcast - it won't pass the WAN router, which
    is why you have to use LMHOSTS file, correct?  So you have to direct
    the mailslot to a specific address, no?  How does LMHOSTS get used in 
    this configuration?  Do we look for entries there first and then send a
    directed mailslot to the addresses in LMHOSTS AND also send the
    mailslot to ff-ff-ff-ff-ff-ff?  
    
    >All NETLOGON "processes" listen for incoming mailslot requests on
    >the domain name. If members in a cluster receive such a mailslot,
    >then only 1 cluster member has access to the UAS, so this is the
    >one that will validate this mailslot request against the UAS. We
    >call this the active member in the cluster. Which of the cluster
    >members this is, is dependend (as you noticed) on which node was
    >first started and where there any fail-overs.
    
    Even in this WAN configuration using LMHOSTS, ALL netlogon processes
    receive the request????????  How are you getting the multicast past the
    router?
    
    >For replication, the PDC sends out a announce uas info mailslot to
    >the domain name whenever there is a need to do so (every pulse inter-
    >val or in between when there is a need for a uas update). Again this
    >mailslot is received by every mailslot listener in the domain.
    
    What if other "mailslot listener" systems are in another IP subnet? 
    And what if the other mailslot listener in that other subnet is a
    cluster?  The PDC must have an entry in the LMHOSTS file, no?   
    
    >Only the active node in the cluster (for a BDC) will process this
    >message if a uas update is required. It is that node that will
    >establish a connection to the PDC to request an update. If the PDC
    >is a cluster then the PW cluster alias name is used, but if the
    >PDC is a single node then the .... name is used. (Fill in yourself).
    
    Again, it seems you're indicating that even if the cluster is in
    another IP subnet (ie, across the country), all cluster nodes running
    PW will receive this PDC announcement.  I can't buy that.  Really?
    
    >Now if you use the PW cluster alias then the disadvantages are:
    >- (Think of them yourself)
    >Now if you use the server name then......
    >
    >Ergo,
    >The PDC can better be a 1) cluster, 2) Single system (pick 1...)
    
    I'm still too confused to respond to this (besides why should using the
    cluster alias have ANY disadvantages).  MY understanding is it's the
    cluster alias name that is used by NETLOGON in a cluster.  For example,
    the machine account that must exist in the SERVERS group is the cluster
    alias name and not the individual member names.  So, lacking ANY
    documentation, one must AssUMe it is the cluster alias name which one
    must enter in LMHOSTS.  Then we're back to "what IP address do I put on
    the LMHOSTS entry?".   
    
    Or, something that just came to mind, can I put an entry in the LMHOSTS
    file FOR EACH CLUSTER MEMBER (in the other subnet) running PW and
    expect everything to work?   This would be ideal, as I would not have
    to be concerned with which node in the remote cluster is the active
    NETLOGON process.  
    
    Maybe there is a light at the end of this tunnel ;o),
    
    Paul

    
    >NETLOGON sends out a mailslot to the IP broadcast address for the
    >domain name.
    >
    >How can you resolve this in a wide area network? (answer yourself
    >pls).
    
    You can't resolve the broadcast - it won't pass the WAN router, which
    is why you have to use LMHOSTS file, correct?  
: CORRECT, but what do you specify in there, the domain name??? Don't
: forget that the mailslot is send to the domain name, not to the cluster
: alias name.

    So you have to direct
    the mailslot to a specific address, no?  
: CORRECT

    How does LMHOSTS get used in 
    this configuration?  Do we look for entries there first and then send a
    directed mailslot to the addresses in LMHOSTS AND also send the
    mailslot to ff-ff-ff-ff-ff-ff?  
: If LMHOST can xlate then only to the address in LMHOST, if LMHOST
: can't xlate then to ff-ff-ff etc..
    
    >All NETLOGON "processes" listen for incoming mailslot requests on
    >the domain name. If members in a cluster receive such a mailslot,
    >then only 1 cluster member has access to the UAS, so this is the
    >one that will validate this mailslot request against the UAS. We
    >call this the active member in the cluster. Which of the cluster
    >members this is, is dependend (as you noticed) on which node was
    >first started and where there any fail-overs.
    
    Even in this WAN configuration using LMHOSTS, ALL netlogon processes
    receive the request????????  How are you getting the multicast past the
    router?
: No, if LMHOSTS performs an address xlation then only that IP address
: receives it.
: If you send a BC then you are limited to your IP area.
    
    >For replication, the PDC sends out a announce uas info mailslot to
    >the domain name whenever there is a need to do so (every pulse inter-
    >val or in between when there is a need for a uas update). Again this
    >mailslot is received by every mailslot listener in the domain.
    
    What if other "mailslot listener" systems are in another IP subnet? 
    And what if the other mailslot listener in that other subnet is a
    cluster?  The PDC must have an entry in the LMHOSTS file, no?   
: Yes, but then only 1 node in the cluster receives that mailslot,
: and if that node is not the active member then.... (no go)
    
    >Only the active node in the cluster (for a BDC) will process this
    >message if a uas update is required. It is that node that will
    >establish a connection to the PDC to request an update. If the PDC
    >is a cluster then the PW cluster alias name is used, but if the
    >PDC is a single node then the .... name is used. (Fill in yourself).
    
    Again, it seems you're indicating that even if the cluster is in
    another IP subnet (ie, across the country), all cluster nodes running
    PW will receive this PDC announcement.  I can't buy that.  Really?
: No that not what I am saying, see above
    
    >Now if you use the PW cluster alias then the disadvantages are:
    >- (Think of them yourself)
    >Now if you use the server name then......
    >
    >Ergo,
    >The PDC can better be a 1) cluster, 2) Single system (pick 1...)
    
    I'm still too confused to respond to this (besides why should using the
    cluster alias have ANY disadvantages).  MY understanding is it's the
    cluster alias name that is used by NETLOGON in a cluster.  For example,
    the machine account that must exist in the SERVERS group is the cluster
    alias name and not the individual member names.  So, lacking ANY
    documentation, one must AssUMe it is the cluster alias name which one
    must enter in LMHOSTS.  Then we're back to "what IP address do I put on
    the LMHOSTS entry?".   
    
    Or, something that just came to mind, can I put an entry in the LMHOSTS
    file FOR EACH CLUSTER MEMBER (in the other subnet) running PW and
    expect everything to work?   This would be ideal, as I would not have
    to be concerned with which node in the remote cluster is the active
    NETLOGON process.  
: I don'y know about this last solution, because i never tried it...

: But to be clear:
: When you use a broadcast on a local ip area, then every node in the cluster
: receives the mailslot and the active member will process it and respond.
: When the cluster is in another ip area, then the broadcast can't pass the
: router, so you have an option to use the lmhost file. When you specify
: the domain name to point to member a's address, then how does one
: guarantee that member a is the active member. If he's not, then you
: request doesn't get processed. This means that you must send it to
: all cluster nodes or the whole mechanism won't work.

: When you don't have a cluster but a single node, then its no problem,
: because the LMHOST file will always translate to the ip address of
: the active member (you only have 1).

    Maybe there is a light at the end of this tunnel ;o),

: I doubt it, I don't think it can work.
    
    Paul

: However there are mechanism defined that can make it work, see RFC1001
: but I don't think we support that in PW yet.

    I am only trying to make you thing (and myseld fow that matter).
    The code base is too huge to tell you the exact details and
    I don't know all of them either.
    
    Maybe other can add something
    
    Adrie

Adrie,
    
>: CORRECT, but what do you specify in there, the domain name??? Don't
>: forget that the mailslot is send to the domain name, not to the cluster
>: alias name.
    
    The domain name is specified in the entry, but after the keyword #DOM.
    
    
    I went to check the release notes (where this LMHOSTS stuff is
    documented).  I HATE IT WHEN WE DO THIS - THE INSTRUCTIONS AREN'T IN
    THE V5.0E RELEASE NOTES.  Or is it there a new set of docs for v5.0E 
    where we now document this (and presumably other features no longer
    listed in the release notes, ie, NET SHARE /SYNC)?????????
    
    Anyway, the v5.0D ECO3 release notes show:
    
                  The LMHOSTS file contains a list of nodes (servers and
                  domain controllers). You specify the following line for
                  each node:
    
                  address nodename #PRE #DOM:domain_name
    
               Where:
    
               o  address is an Internet address of form x.x.x.x, where x
                  is a decimal number from 0 to 255.
    
               o  nodename is a name from 1 to 16 characters long,
                  and may include a control character. (The format of
                  a control character is \0Xnn or \nn, where n is a
                  hexadecimal digit.
    
                  To preserve the casing of the characters, enclose the
                  nodename in double quotation marks. If the nodename is
                  not enclosed in quotes, the alphabetic characters are
                  set to uppercase before the nodename is loaded into
                  cache (see parameter #PRE) or used for matching.
    
                  If the node name includes a control character in
                  the last byte, you should include blank characters
                  to explicitly control the placement of the control
                  character. When the name is less than 16 characters in
                  length, it is padded out with blank characters.
                  Examples of Node Names
    
                  1.
    
                     hydral
    
                  2.
    
                     "hydral\0X03"
    
                  3.
    
                     "hydral          \0X03"
    
                  In Example 1, the node name will be interpreted as
                  uppercase and will be padded with blank characters.
    
                  In Example 2, the node name will not be interpreted as
                  uppercase, will be padded out with blank characters for
                  bytes 8 through 16.
    
                  In Example 3, the node name will not be interpreted as
                  uppercase, and no padding needs to be inserted because
                  blank spaces are already included in order that control
                  character resides in byte 16.
    
               o  #PRE is an optional parameter that indicates that the
                  entry should be preloaded into the cache.
    
                  o  #DOM:domainname is an optional parameter that
    		     specifies the domain for the node.
    
                  For example, the following entry might be included in the
                  LMHOSTS file:
    
                  12.13.14.15 server #PRE #DOM:PATHWORKS
    
                  This entry would result in NetBIOS name SERVER with
                  Internet address 12.13.14.15 being preloaded into the
                  cache. The NetBIOS name SERVER would be available for
                  matching, and the NetBIOS name PATHWORKS (the name of the
                  domain) would be available for matching.
    
            2.4.3.3 Managing the LMHOSTS File
    
                  To change the list of available nodes, edit the file
                  at any time. Domain names are resolved by checking the
                  LMHOSTS file.
    
    
    So I think the entry the customer used (and worked) was ok.  As long as
    the address we listed in LMHOSTS was the active NETLOGON server he says
    it worked.  If you could list ALL cluster members running PW in
    LMHOSTS, that would be theesolution.  Unfortunately, the customer
    looking to employ this configuration, changed his mind.  He demoted the
    cluster to BDC, and promoted a non-clustered BDC to PDC.  So, as you
    stated, with a single node, it's no problem.  Sure would like to know,
    though.  
    
    Paul

Reply 5 by UTRTSC::SWEEP says, in part:

> Or, something that just came to mind, can I put an entry in the LMHOSTS
> file FOR EACH CLUSTER MEMBER (in the other subnet) running PW and
> expect everything to work?   This would be ideal, as I would not have
> to be concerned with which node in the remote cluster is the active
> NETLOGON process.  

	Looks like this is supported, at least on Windows NT V4.0 clients.

	This is discussed in detail in:

		MS Windows NT Workstation 4.0 Resource Guide
		   Chapter 33 - Using LMHOSTS files
		      Creating the LMHOSTS file
		         Adding Domain Controllers by Using #DOM

	Here is an example where multiple hosts/addresses are 
	listed for a single domain:

	    102.54.94.97 mypdc   #PRE #DOM:mydomain  #The Primary DC
	    102.54.94.99 mybdc1  #PRE #DOM:mydomain  #A Backup DC
	    102.54.94.98 mybdc2  #PRE #DOM:mydomain  #Another Backup DC

	At least for Window NT V4.0 this means that when the client 
	wants to talk to a domain controller it will ask each node in 
	turn using the address for that node.  It is certainly worth 
	trying on Windows 95.
	

    Paul
    
    Did you try the LMHOST #DOM for all 3 cluster members ???
    
    I heared that eng in lkg tested this and that it worked..
    
    Adrie

    
    I haven't tried it (I'd need to setup a test WAN).  The customer never
    tried it either.  If lkg has confirmed it works, I hope they put
    something in the release notes...
    
    Paul