Re: Which TCP/IP settings critical to join domain?

From: Herb Martin (news_at_LearnQuick.com)
Date: 01/17/05 

Date: Mon, 17 Jan 2005 09:17:09 -0600

"Pat Coghlan" <coghlan@sympatico.ca> wrote in message
news:fLPGd.6658$K03.289253@news20.bellglobal.com...
> In our network, the DCs are not configured with DNS. All workstations
> (and the DCs) point to dedicated DNS servers.
>
> Can you clarify what you meant by "stations should use their own domain
> name in the system control panel"?

In the System Control Panel there is a location for the
machine name, domain to which it belongs, and the
primary DNS name of the machine.

That should be correctly filled out.

> The workstations in the same subnet as the DCs were able to join the
> domain if "append primary DNS suffix was set",

If the machines own domain name is set, that will be
used to find the DC.

> while the workstations in
> remote subnets needed to have "append the following DNS suffixes"
> configured.

And if the machine's ówn domain name (in the System CP) is
not set it causes such trouble.

> I should note that I don't believe there was anything
> actually entered in the primary DNS suffix field when selecting the
> first option, so I'm not really sure what, if anything, got appended to
> lookups.
>
> To summarize:
>
> - old DC (domain xxx) was removed, new DC (domain yyy) was installed

Did you move the 5 (special master) roles, and ensure the
current DC is a GC?

If not, you can SEIZE*** the roles in NtdsUtil "roles" (subarea).

*** NEVER "seize" a single master role IF they original
role holder will be returned to the network -- seize only
if the original role holder DC is now lost (as is your case.)

> - workstations that had been part of domain xxx remained configured with
> "append primary DNS suffix", but I believe the primary suffix field was
> empty

Fill it it.

> - workstations on the local subnet had no difficulty finding/joining yyy
> - workstations in remote subnets required "append following DNS suffixes"

Not necessary, and it should be done the other way.

> It's as if the colocated workstations had access to information which
> the remote workstations lacked, allowing the colocated workstations to
> do successful name resolution but preventing the remote workstations
> from doing so.
>

I also have general suspicions about your DNS configurations,
so check these:

DNS for AD
    1) Dynamic for the zone supporting AD
    2) All internal DNS clients NIC\IP properties must specify SOLELY
        that internal, dynamic DNS server (set.)
    3) DCs and even DNS servers are DNS clients too -- see #2

Restart NetLogon on any DC if you change any of the above that
affects a DC and/or use:

    nltest /dsregdns /server:DC-ServerNameGoesHere

Ensure that DNS zones/domains are fully replicated to all DNS
servers for that (internal) zone/domain.

Also useful may be running DCDiag on each DC, sending the
output to a text file, and searching for FAIL, ERROR, WARN.

Single Lable domain zone names are a problem Google:
[ "SINGLE LABEL" domain names DNS 2000 | 2003 microsoft: ] 

-- 
Herb Martin
"Pat Coghlan" <coghlan@sympatico.ca> wrote in message
news:fLPGd.6658$K03.289253@news20.bellglobal.com...
> In our network, the DCs are not configured with DNS.  All workstations
> (and the DCs) point to dedicated DNS servers.
>
> Can you clarify what you meant by "stations should use their own domain
> name in the system control panel"?
>
> The workstations in the same subnet as the DCs were able to join the
> domain if "append primary DNS suffix was set", while the workstations in
> remote subnets needed to have "append the following DNS suffixes"
> configured.  I should note that I don't believe there was anything
> actually entered in the primary DNS suffix field when selecting the
> first option, so I'm not really sure what, if anything, got appended to
> lookups.
>
> To summarize:
>
> - old DC (domain xxx) was removed, new DC (domain yyy) was installed
> - workstations that had been part of domain xxx remained configured with
> "append primary DNS suffix", but I believe the primary suffix field was
> empty
> - workstations on the local subnet had no difficulty finding/joining yyy
> - workstations in remote subnets required "append following DNS suffixes"
>
> It's as if the colocated workstations had access to information which
> the remote workstations lacked, allowing the colocated workstations to
> do successful name resolution but preventing the remote workstations
> from doing so.
>
> -Pat
>
> Herb Martin wrote:
>
> > "Pat Coghlan" <coghlan@sympatico.ca> wrote in message
> > news:7PTFd.48585$TN6.1817460@news20.bellglobal.com...
> >
> >>I have a DC and several workstations on a subnet, and other workstations
> >>  on another subnet.
> >
> >
> > Routable IP between the subnets is required by this.
> >
> >
> >>The workstations on the same subnet as the DC had no problem joining the
> >>domain that the DC had just been built for, while the workstations on
> >>the remote subnet had the following problems:
> >>
> >>- could not ping the DC by name
> >
> >
> > How about ping by NUMBER?
> > How about RESOLVE the DC name?
> >
> >
> >>- could not join the domain
> >
> >
> > Makes sense based on the previous.
> >
> > Is it a routing problem or a name resolution
> > problem?
> >
> > Where is the DNS?  If the DNS is not reachable
> > then you have solve the routing problem first.
> >
> >
> >>If I changed the DNS settings from "append primary suffix" to "append
> >>these suffixes in the following order", the remote workstations can ping
> >>the DC by name, but they are still unable to join the domain.
> >
> >
> > The stations should all be set to use their OWN
> > domain name (in 99.999% of cases) in the SYSTEM
> > control panel, rather than depending on the NIC
> > suffix settings.
> >
> >
> >>Which TCP/IP settings are critical for workstations on a remote subnet
> >>to be able to detect a domain and be able to join it?
> >
> >
> > I think you may have a routing problem first, but...
> >
> > All internal clients must use SOLELY the internal
> > DNS server (see below.)
> >
> > Can you ping the DNS server by NUMBER or use
> > NSLookup to resolve from it?
> >
> >     nslookup DCNAME   DNS.IP.ADDR.ess
> >
> > (Ignore any initial error about "server name" IF you
> > see the resolution at the bottom of -- i.e., end of -- the
> > answer.)
> >
> >
> >>Our DCs can write SRV records to the backbone DNS servers, and this gets
> >>pushed out to our regional DNS servers (used by workstations), but there
> >>must be some kind of broadcast information that the colocated
> >>workstations have access to that the remote workstations are missing.
> >
> >
> > No.  Joining Win2000+ domains is not dependent on
> > any broadcast name resolution.  (But might slip by
> > if there is such on the same subnet -- you have a largely
> > problem anyway.)
> >
> >
> >>We also have remote workstation in another domain that, on most days,
> >>can't see the DCs and workstations that are in the main subnet (i.e.
> >>where DC is located).
> >>
> >>What's the trick here?
> >
> >
> >
> > DNS for AD
> >     1) Dynamic for the zone supporting AD
> >     2) All internal DNS clients NIC\IP properties must specify SOLELY
> >         that internal, dynamic DNS server (set.)
> >     3) DCs and even DNS servers are DNS clients too -- see #2
> >
> > Restart NetLogon on any DC if you change any of the above that
> > affects a DC and/or use:
> >
> >     nltest /dsregdns /server:DC-ServerNameGoesHere
> >
> > Ensure that DNS zones/domains are fully replicated to all DNS
> > servers for that (internal) zone/domain.
> >
> > Also useful may be running DCDiag on each DC, sending the
> > output to a text file, and searching for FAIL, ERROR, WARN.
> >
> > Also FYI:
> > Single Lable domain zone names are a problem Google:
> > [ "SINGLE LABEL"  domain names DNS 2000 | 2003 microsoft: ]
> >
Loading