Which TCP/IP settings critical to join domain?

[Pat Coghlan]

I have a DC and several workstations on a subnet, and other workstations
on another subnet.

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
- could not join the domain

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.

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?

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.

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?

Thanks.

-Pat

 

[Herb Martin]

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 /serverC-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: ]

 

[Steve Riley [MSFT]]

Please search on Microsoft.com for the paper "Active Directory in segmented
networks." It documents everything you need to know.

Steve Riley
(e-mail address removed)

 

[Pat Coghlan]

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

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 /serverC-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: ]

 

[Herb Martin]

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 /serverC-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

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

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 /serverC-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: ]

 

[Pat Coghlan]

Once we drop in the new DC for domain yyy, the existing workstations
would still have the network ID configured as xxx. I didn't check this
at the time, though.

When joining the new domain, the workstations should be trying to find
the DC for the requested domain name: yyy. This process yields the
correct result for workstations in the same subnet as the DC, but not
for the remote workstations.

The field I was referring to before which isn't filled in is "suffix for
connection".

What would probably be very useful is a guideline as to when to use
"append primary suffix" vs "append the following DNS suffixes".

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 /serverC-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: ]

 

[Pat Coghlan]

As I understand things:

- DCs need to be able to write SRV records to master DNS server
- master DNS server pushes this information down to regional DNS
servers, which are used by workstations for name resolution and
discovery of the domain's DC.

If the DCs are prevented from writing SRV records to the master DNS
server, or this information isn't being pushed down to the regional
servers, then workstations won't be able to find the DC for the domain.
I think this is what is happening in our network.

On the other hand, though, even if this process is not working as it
should, workstations which have visibility (on subnet) of the DC have no
problem joining the domain through some kind of "back door" which is not
available to workstations which don't have visibility of the DC. This
"back door" could be some kind of broadcast or other query which does
not involve the use of DNS.

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 /serverC-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]

As I understand things:

- DCs need to be able to write SRV records to master DNS server
- master DNS server pushes this information down to regional DNS
servers, which are used by workstations for name resolution and
discovery of the domain's DC.

It's really a pull from the other DNS servers and technically the
clients can use ANY DNS server -- even one not involved --
to resolve the names as long as the DNS server specified can
find and resolve the address correctly.

BUT, yes, in most cases these will be the same when you only
have one zone/domain inside your network.

If the DCs are prevented from writing SRV records to the master DNS
server, or this information isn't being pushed down to the regional
servers, then workstations won't be able to find the DC for the domain.
I think this is what is happening in our network.

Yes. The latter means that all of the DNS servers must be at least
NT 4 with latest service packs or BIND 4.9.7 while the Primary
Server(s) must be Win2000+ or BIND 8.1.2 but in general, the
primary must be DYNAMIC and all of the DNS servers for the
zone must support SRV records.

On the other hand, though, even if this process is not working as it
should, workstations which have visibility (on subnet) of the DC have no
problem joining the domain through some kind of "back door" which is not
available to workstations which don't have visibility of the DC. This
"back door" could be some kind of broadcast or other query which does
not involve the use of DNS.

My guess is through NetBIOS perhaps.

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 /serverC-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: ]

 

[Pat Coghlan]

As I suspected, there is a misconfiguration in our primary/regional DNS
servers. Apparently, the A-records for the DCs are either associated
with the wrong zone (domain) or have been entered twice - once for the
right zone and once for the wrong one.

I guess the master DNS server checks the IP address of the DC attempting
to write SRV records and tries to validate its A-record. Perhaps it
finds the "bad" one first and rejects the write request.

Sound plausible?

-Pat

As I understand things:

- DCs need to be able to write SRV records to master DNS server
- master DNS server pushes this information down to regional DNS
servers, which are used by workstations for name resolution and
discovery of the domain's DC.

It's really a pull from the other DNS servers and technically the
clients can use ANY DNS server -- even one not involved --
to resolve the names as long as the DNS server specified can
find and resolve the address correctly.

BUT, yes, in most cases these will be the same when you only
have one zone/domain inside your network.

If the DCs are prevented from writing SRV records to the master DNS
server, or this information isn't being pushed down to the regional
servers, then workstations won't be able to find the DC for the domain.
I think this is what is happening in our network.

Yes. The latter means that all of the DNS servers must be at least
NT 4 with latest service packs or BIND 4.9.7 while the Primary
Server(s) must be Win2000+ or BIND 8.1.2 but in general, the
primary must be DYNAMIC and all of the DNS servers for the
zone must support SRV records.

On the other hand, though, even if this process is not working as it
should, workstations which have visibility (on subnet) of the DC have no
problem joining the domain through some kind of "back door" which is not
available to workstations which don't have visibility of the DC. This
"back door" could be some kind of broadcast or other query which does
not involve the use of DNS.

My guess is through NetBIOS perhaps.

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 /serverC-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]

As I suspected, there is a misconfiguration in our primary/regional DNS
servers. Apparently, the A-records for the DCs are either associated
with the wrong zone (domain) or have been entered twice - once for the
right zone and once for the wrong one.

Twice couldn't really hurt. Wrong zone (completely)
would make the NOT YOUR A-records but records for
some other zones.

The records for machines have to be in the zone the
machine wishes to join/be-a-member/respond-as.

(Doubled to another zone wouldn't matter unless someone
looked them up under that name.)

I guess the master DNS server checks the IP address of the DC attempting
to write SRV records and tries to validate its A-record. Perhaps it
finds the "bad" one first and rejects the write request.

Only rejects the request if:

a) Dynamic registration for the zone is off OR
b) Secure updates only are enabled and AUTHENTICATION fails.

--
Herb Martin

Sound plausible?

-Pat

As I understand things:

- DCs need to be able to write SRV records to master DNS server
- master DNS server pushes this information down to regional DNS
servers, which are used by workstations for name resolution and
discovery of the domain's DC.

It's really a pull from the other DNS servers and technically the
clients can use ANY DNS server -- even one not involved --
to resolve the names as long as the DNS server specified can
find and resolve the address correctly.

BUT, yes, in most cases these will be the same when you only
have one zone/domain inside your network.

If the DCs are prevented from writing SRV records to the master DNS
server, or this information isn't being pushed down to the regional
servers, then workstations won't be able to find the DC for the domain.
I think this is what is happening in our network.

Yes. The latter means that all of the DNS servers must be at least
NT 4 with latest service packs or BIND 4.9.7 while the Primary
Server(s) must be Win2000+ or BIND 8.1.2 but in general, the
primary must be DYNAMIC and all of the DNS servers for the
zone must support SRV records.

On the other hand, though, even if this process is not working as it
should, workstations which have visibility (on subnet) of the DC have no
problem joining the domain through some kind of "back door" which is not
available to workstations which don't have visibility of the DC. This
"back door" could be some kind of broadcast or other query which does
not involve the use of DNS.

My guess is through NetBIOS perhaps.

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 /serverC-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: ]