Re: Which TCP/IP settings critical to join domain?
From: Pat Coghlan (coghlan_at_sympatico.ca)
Date: 01/17/05
- Next message: Herb Martin: "Re: Which TCP/IP settings critical to join domain?"
- Previous message: Desmond Lee: "RE: What is difference ???"
- In reply to: Herb Martin: "Re: Which TCP/IP settings critical to join domain?"
- Next in thread: Herb Martin: "Re: Which TCP/IP settings critical to join domain?"
- Reply: Herb Martin: "Re: Which TCP/IP settings critical to join domain?"
- Messages sorted by: [ date ] [ thread ]
Date: Mon, 17 Jan 2005 09:14:29 -0500
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: ]
>
- Next message: Herb Martin: "Re: Which TCP/IP settings critical to join domain?"
- Previous message: Desmond Lee: "RE: What is difference ???"
- In reply to: Herb Martin: "Re: Which TCP/IP settings critical to join domain?"
- Next in thread: Herb Martin: "Re: Which TCP/IP settings critical to join domain?"
- Reply: Herb Martin: "Re: Which TCP/IP settings critical to join domain?"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
