I have an issue where new clients, upon joining the domain, are not
registering in DNS. Further, they do not register in DNS at any point
thereafter.

My environment consists of 2 separate AD forests/domains (domA.com and
sub1.domB.com), each having their own AD integrated DNS (Dynamic updates =
Secure only). The DNS servers for domA.com have a domain specific Forwarder
record for sub1.domB.com.

There are also a number of other DNS zones hosted on BIND servers (e.g.
domB.com, sub2.domB.com, sub3.domB.com, etc). The DNS zones associated with
domB.com represent a company that acquired the company that originally owned
domA.com.

I am trying to add clients to sub1.domB.com and I would like for them to
register themselves in DNS in sub1.domB.com.

The clients are newly built XP SP2 with default TCP/IP properties:
Obtain an IP address automatically
Obtain DNS server address automatically
Append primary and connection specific DNS suffixes
Append parent suffixes of the primary DNS suffix = {unchecked}
DNS suffix for this connection = {blank}
Register this connection's addresses in DNS = {checked}
Use this connection's DNS suffix in DNS registration = {unchecked})

The clients start out as workgroup machines. They obtain their TCP/IP info
via a DHCP server that is a member of domA.com. The DHCP client service is
running on the client.

On the DHCP server, the primary and secondary DNS servers are DNS servers in
domA.com. Scope option 006 includes only DNS servers for domA.com. Scope
option 015 is set to domA.com. The DHCP server is also set to register
clients in DNS:
Automatically update DHCP client information in DNS = {checked}
Always update DNS
Discard forward (name-to-address) lookups when lease expires = {checked}
Enable updates for DNS clients that do not support dynamic update =
{checked}

The clients successfully join the sub1.domB.com AD domain using the fqdn.
However, they do not register in the sub1.domB.com DNS domain. Upon reboot,
or upon using ipconfig /registerdns, they still do not register in the
sub1.domB.com DNS domain.

Can anyone explain why the DNS registration does not work?

--
John S

It's an OS, not a religion.

"JohnS" <NNTPAlias@nospam.nospam> wrote in message
news:7D3DFE24-04D8-4F19-8C57-06E86EE58F66@microsoft.com...
>I have an issue where new clients, upon joining the domain, are not
> registering in DNS. Further, they do not register in DNS at any point
> thereafter.

DNS Clients must use STRICTLY the set of (internal) DNS servers which
can find the DNS servers for their own Domain AND ALL other domains
internally and externall.

The most common error is to mix DNS Servers (sets) on the DNS client
NIC->IP properties -- i.e, putting DNS servers in there which cannot
find everything the clients will ever need.

DNS Clients believe that EVERY DNS server will return the same and
the correct answers.

> My environment consists of 2 separate AD forests/domains (domA.com and
> sub1.domB.com), each having their own AD integrated DNS (Dynamic updates =
> Secure only). The DNS servers for domA.com have a domain specific
> Forwarder
> record for sub1.domB.com.
>
> There are also a number of other DNS zones hosted on BIND servers (e.g.
> domB.com, sub2.domB.com, sub3.domB.com, etc). The DNS zones associated
> with
> domB.com represent a company that acquired the company that originally
> owned
> domA.com.
>
> I am trying to add clients to sub1.domB.com and I would like for them to
> register themselves in DNS in sub1.domB.com.

The DNS Server(s) these clients use must be either IN sub1.domB.com or able
to FIND sub1.domB.com. No exeptions.

Clients should also have their Primary DNS suffix set in the SYSTEM Control
Panel.

> The clients are newly built XP SP2 with default TCP/IP properties:
> Obtain an IP address automatically
> Obtain DNS server address automatically
> Append primary and connection specific DNS suffixes
> Append parent suffixes of the primary DNS suffix = {unchecked}
> DNS suffix for this connection = {blank}
> Register this connection's addresses in DNS = {checked}
> Use this connection's DNS suffix in DNS registration = {unchecked})

DHCP should also give out the correct DNS name for these clients if at
all possible.

> The clients start out as workgroup machines. They obtain their TCP/IP
> info
> via a DHCP server that is a member of domA.com. The DHCP client service
> is
> running on the client.

When they switch to domain machines the Primary DNS suffix needs to be
added to them as part of this change.

> On the DHCP server, the primary and secondary DNS servers are DNS servers
> in
> domA.com. Scope option 006 includes only DNS servers for domA.com. Scope
> option 015 is set to domA.com. The DHCP server is also set to register
> clients in DNS:
> Automatically update DHCP client information in DNS = {checked}
> Always update DNS
> Discard forward (name-to-address) lookups when lease expires = {checked}
> Enable updates for DNS clients that do not support dynamic update =
> {checked}
>
> The clients successfully join the sub1.domB.com AD domain using the fqdn.
> However, they do not register in the sub1.domB.com DNS domain. Upon
> reboot,
> or upon using ipconfig /registerdns, they still do not register in the
> sub1.domB.com DNS domain.
>
> Can anyone explain why the DNS registration does not work?
>
> --
> John S
>
> It's an OS, not a religion.

Let's try this again...

See my comments embedded below.

--
John S

It's an OS, not a religion.


"Herb Martin" wrote:

>
> "JohnS" <NNTPAlias@nospam.nospam> wrote in message
> news:7D3DFE24-04D8-4F19-8C57-06E86EE58F66@microsoft.com...
> >I have an issue where new clients, upon joining the domain, are not
> > registering in DNS. Further, they do not register in DNS at any point
> > thereafter.
>
> DNS Clients must use STRICTLY the set of (internal) DNS servers which
> can find the DNS servers for their own Domain AND ALL other domains
> internally and externall.
>
> The most common error is to mix DNS Servers (sets) on the DNS client
> NIC->IP properties -- i.e, putting DNS servers in there which cannot
> find everything the clients will ever need.
>
> DNS Clients believe that EVERY DNS server will return the same and
> the correct answers.
>

The DNS servers known to the client are technically not mixed, they just
aren't part of sub1.domB.com. The are both part of domA.com.

> > My environment consists of 2 separate AD forests/domains (domA.com and
> > sub1.domB.com), each having their own AD integrated DNS (Dynamic updates =
> > Secure only). The DNS servers for domA.com have a domain specific
> > Forwarder
> > record for sub1.domB.com.
> >
> > There are also a number of other DNS zones hosted on BIND servers (e.g.
> > domB.com, sub2.domB.com, sub3.domB.com, etc). The DNS zones associated
> > with
> > domB.com represent a company that acquired the company that originally
> > owned
> > domA.com.
> >
> > I am trying to add clients to sub1.domB.com and I would like for them to
> > register themselves in DNS in sub1.domB.com.
>
> The DNS Server(s) these clients use must be either IN sub1.domB.com or able
> to FIND sub1.domB.com. No exeptions.
>

The DNS servers in use by the client can consistently resolve sub1.domB.com
as well as all hostnames within sub1.domB.com.

> Clients should also have their Primary DNS suffix set in the SYSTEM Control
> Panel.
>

I should have specifically included this info before. Upon joining
sub1.domB.com, the Primary DNS suffix of this computer is successfully set.
In addition, Change primary DNS suffix when domain membership changes =
{checked}.

> > The clients are newly built XP SP2 with default TCP/IP properties:
> > Obtain an IP address automatically
> > Obtain DNS server address automatically
> > Append primary and connection specific DNS suffixes
> > Append parent suffixes of the primary DNS suffix = {unchecked}
> > DNS suffix for this connection = {blank}
> > Register this connection's addresses in DNS = {checked}
> > Use this connection's DNS suffix in DNS registration = {unchecked})
>
> DHCP should also give out the correct DNS name for these clients if at
> all possible.
>

I can't do this yet since the DHCP scope was not set up for and is not
specific to the destination domain.

> > The clients start out as workgroup machines. They obtain their TCP/IP
> > info
> > via a DHCP server that is a member of domA.com. The DHCP client service
> > is
> > running on the client.
>
> When they switch to domain machines the Primary DNS suffix needs to be
> added to them as part of this change.
>

Answered above.

> > On the DHCP server, the primary and secondary DNS servers are DNS servers
> > in
> > domA.com. Scope option 006 includes only DNS servers for domA.com. Scope
> > option 015 is set to domA.com. The DHCP server is also set to register
> > clients in DNS:
> > Automatically update DHCP client information in DNS = {checked}
> > Always update DNS
> > Discard forward (name-to-address) lookups when lease expires = {checked}
> > Enable updates for DNS clients that do not support dynamic update =
> > {checked}
> >
> > The clients successfully join the sub1.domB.com AD domain using the fqdn.
> > However, they do not register in the sub1.domB.com DNS domain. Upon
> > reboot,
> > or upon using ipconfig /registerdns, they still do not register in the
> > sub1.domB.com DNS domain.
> >
> > Can anyone explain why the DNS registration does not work?
> >
> > --
> > John S
> >
> > It's an OS, not a religion.
>
>
>

--
John S

It''s an OS, not a religion.


"Herb Martin" wrote:

>
> "JohnS" <NNTPAlias@nospam.nospam> wrote in message
> news:7D3DFE24-04D8-4F19-8C57-06E86EE58F66@microsoft.com...
> >I have an issue where new clients, upon joining the domain, are not
> > registering in DNS. Further, they do not register in DNS at any point
> > thereafter.
>
> DNS Clients must use STRICTLY the set of (internal) DNS servers which
> can find the DNS servers for their own Domain AND ALL other domains
> internally and externall.
>
> The most common error is to mix DNS Servers (sets) on the DNS client
> NIC->IP properties -- i.e, putting DNS servers in there which cannot
> find everything the clients will ever need.
>
> DNS Clients believe that EVERY DNS server will return the same and
> the correct answers.
>
> > My environment consists of 2 separate AD forests/domains (domA.com and
> > sub1.domB.com), each having their own AD integrated DNS (Dynamic updates =
> > Secure only). The DNS servers for domA.com have a domain specific
> > Forwarder
> > record for sub1.domB.com.
> >
> > There are also a number of other DNS zones hosted on BIND servers (e.g.
> > domB.com, sub2.domB.com, sub3.domB.com, etc). The DNS zones associated
> > with
> > domB.com represent a company that acquired the company that originally
> > owned
> > domA.com.
> >
> > I am trying to add clients to sub1.domB.com and I would like for them to
> > register themselves in DNS in sub1.domB.com.
>
> The DNS Server(s) these clients use must be either IN sub1.domB.com or able
> to FIND sub1.domB.com. No exeptions.
>
> Clients should also have their Primary DNS suffix set in the SYSTEM Control
> Panel.
>
> > The clients are newly built XP SP2 with default TCP/IP properties:
> > Obtain an IP address automatically
> > Obtain DNS server address automatically
> > Append primary and connection specific DNS suffixes
> > Append parent suffixes of the primary DNS suffix = {unchecked}
> > DNS suffix for this connection = {blank}
> > Register this connection's addresses in DNS = {checked}
> > Use this connection's DNS suffix in DNS registration = {unchecked})
>
> DHCP should also give out the correct DNS name for these clients if at
> all possible.
>
> > The clients start out as workgroup machines. They obtain their TCP/IP
> > info
> > via a DHCP server that is a member of domA.com. The DHCP client service
> > is
> > running on the client.
>
> When they switch to domain machines the Primary DNS suffix needs to be
> added to them as part of this change.
>
> > On the DHCP server, the primary and secondary DNS servers are DNS servers
> > in
> > domA.com. Scope option 006 includes only DNS servers for domA.com. Scope
> > option 015 is set to domA.com. The DHCP server is also set to register
> > clients in DNS:
> > Automatically update DHCP client information in DNS = {checked}
> > Always update DNS
> > Discard forward (name-to-address) lookups when lease expires = {checked}
> > Enable updates for DNS clients that do not support dynamic update =
> > {checked}
> >
> > The clients successfully join the sub1.domB.com AD domain using the fqdn.
> > However, they do not register in the sub1.domB.com DNS domain. Upon
> > reboot,
> > or upon using ipconfig /registerdns, they still do not register in the
> > sub1.domB.com DNS domain.
> >
> > Can anyone explain why the DNS registration does not work?
> >
> > --
> > John S
> >
> > It's an OS, not a religion.
>
>
>

"JohnS" <NNTPAlias@nospam.nospam> wrote in message
news:A0CEA758-3A27-46E5-B933-01909B432C11@microsoft.com...
> Let's try this again...
>
> See my comments embedded below.
>
> --
> John S
>
> It's an OS, not a religion.
>
>
> "Herb Martin" wrote:
>
>>
>> "JohnS" <NNTPAlias@nospam.nospam> wrote in message
>> news:7D3DFE24-04D8-4F19-8C57-06E86EE58F66@microsoft.com...
>> >I have an issue where new clients, upon joining the domain, are not
>> > registering in DNS. Further, they do not register in DNS at any point
>> > thereafter.
>>
>> DNS Clients must use STRICTLY the set of (internal) DNS servers which
>> can find the DNS servers for their own Domain AND ALL other domains
>> internally and externall.
>>
>> The most common error is to mix DNS Servers (sets) on the DNS client
>> NIC->IP properties -- i.e, putting DNS servers in there which cannot
>> find everything the clients will ever need.
>>
>> DNS Clients believe that EVERY DNS server will return the same and
>> the correct answers.
>>
>
> The DNS servers known to the client are technically not mixed, they just
> aren't part of sub1.domB.com. The are both part of domA.com.

As long as every DNS Server (e.g., in domA.com) can FIND the Primary
DNS server for the zone where the clients need to register (e.g,
sub1.domB.com)
then this should not be the problem.

This makes it more likely that the DNS Clients don't know their own Primary
DNS Suffix.

>> > My environment consists of 2 separate AD forests/domains (domA.com and
>> > sub1.domB.com), each having their own AD integrated DNS (Dynamic
>> > updates =
>> > Secure only). The DNS servers for domA.com have a domain specific
>> > Forwarder
>> > record for sub1.domB.com.
>> >
>> > There are also a number of other DNS zones hosted on BIND servers (e.g.
>> > domB.com, sub2.domB.com, sub3.domB.com, etc). The DNS zones associated
>> > with
>> > domB.com represent a company that acquired the company that originally
>> > owned
>> > domA.com.
>> >
>> > I am trying to add clients to sub1.domB.com and I would like for them
>> > to
>> > register themselves in DNS in sub1.domB.com.
>>
>> The DNS Server(s) these clients use must be either IN sub1.domB.com or
>> able
>> to FIND sub1.domB.com. No exeptions.
>>
>
> The DNS servers in use by the client can consistently resolve
> sub1.domB.com
> as well as all hostnames within sub1.domB.com.
>
>> Clients should also have their Primary DNS suffix set in the SYSTEM
>> Control
>> Panel.
>>
>
> I should have specifically included this info before. Upon joining
> sub1.domB.com, the Primary DNS suffix of this computer is successfully
> set.
> In addition, Change primary DNS suffix when domain membership changes =
> {checked}.

The former is important (and good) and the latter is not an issue in this
case but
is useful if you want to avoid having to reset this value when the client
changes
domain (if ever.)

>> > The clients are newly built XP SP2 with default TCP/IP properties:
>> > Obtain an IP address automatically
>> > Obtain DNS server address automatically
>> > Append primary and connection specific DNS suffixes
>> > Append parent suffixes of the primary DNS suffix = {unchecked}
>> > DNS suffix for this connection = {blank}
>> > Register this connection's addresses in DNS = {checked}
>> > Use this connection's DNS suffix in DNS registration = {unchecked})
>>
>> DHCP should also give out the correct DNS name for these clients if at
>> all possible.
>>
>
> I can't do this yet since the DHCP scope was not set up for and is not
> specific to the destination domain.

Yes, I suspected that was part of the problem since you have multiple
domains.

Try setting the IP manually for one of these clients to the "home DNS
server"
for their domain (only) and see if it then registers.

This should NOT be necessary but it will allow you to remove a bunch of
variables
and perpaps reduce the possibilities of where the problem might be
originating.

>> > The clients start out as workgroup machines. They obtain their TCP/IP
>> > info
>> > via a DHCP server that is a member of domA.com. The DHCP client
>> > service
>> > is
>> > running on the client.
>>
>> When they switch to domain machines the Primary DNS suffix needs to be
>> added to them as part of this change.
>>
>
> Answered above.
>
>> > On the DHCP server, the primary and secondary DNS servers are DNS
>> > servers
>> > in
>> > domA.com. Scope option 006 includes only DNS servers for domA.com.
>> > Scope
>> > option 015 is set to domA.com. The DHCP server is also set to register
>> > clients in DNS:
>> > Automatically update DHCP client information in DNS = {checked}
>> > Always update DNS
>> > Discard forward (name-to-address) lookups when lease expires =
>> > {checked}
>> > Enable updates for DNS clients that do not support dynamic update =
>> > {checked}
>> >
>> > The clients successfully join the sub1.domB.com AD domain using the
>> > fqdn.
>> > However, they do not register in the sub1.domB.com DNS domain. Upon
>> > reboot,
>> > or upon using ipconfig /registerdns, they still do not register in the
>> > sub1.domB.com DNS domain.
>> >
>> > Can anyone explain why the DNS registration does not work?
>> >
>> > --
>> > John S
>> >
>> > It's an OS, not a religion.
>>
>>
>>

Herb,
Thanks for the quick replies. It's reassuring to know that it is indeed
supposed to work the way I thought it should. Manually changing the DNS
Server Search Order on the client to point to DNS servers in sub1.domB.com is
the next step. I'll follow up with the level of success...
--
John S

It's an OS, not a religion.


"Herb Martin" wrote:

>
> "JohnS" <NNTPAlias@nospam.nospam> wrote in message
> news:A0CEA758-3A27-46E5-B933-01909B432C11@microsoft.com...
> > Let's try this again...
> >
> > See my comments embedded below.
> >
> > --
> > John S
> >
> > It's an OS, not a religion.
> >
> >
> > "Herb Martin" wrote:
> >
> >>
> >> "JohnS" <NNTPAlias@nospam.nospam> wrote in message
> >> news:7D3DFE24-04D8-4F19-8C57-06E86EE58F66@microsoft.com...
> >> >I have an issue where new clients, upon joining the domain, are not
> >> > registering in DNS. Further, they do not register in DNS at any point
> >> > thereafter.
> >>
> >> DNS Clients must use STRICTLY the set of (internal) DNS servers which
> >> can find the DNS servers for their own Domain AND ALL other domains
> >> internally and externall.
> >>
> >> The most common error is to mix DNS Servers (sets) on the DNS client
> >> NIC->IP properties -- i.e, putting DNS servers in there which cannot
> >> find everything the clients will ever need.
> >>
> >> DNS Clients believe that EVERY DNS server will return the same and
> >> the correct answers.
> >>
> >
> > The DNS servers known to the client are technically not mixed, they just
> > aren't part of sub1.domB.com. The are both part of domA.com.
>
> As long as every DNS Server (e.g., in domA.com) can FIND the Primary
> DNS server for the zone where the clients need to register (e.g,
> sub1.domB.com)
> then this should not be the problem.
>
> This makes it more likely that the DNS Clients don't know their own Primary
> DNS Suffix.
>
> >> > My environment consists of 2 separate AD forests/domains (domA.com and
> >> > sub1.domB.com), each having their own AD integrated DNS (Dynamic
> >> > updates =
> >> > Secure only). The DNS servers for domA.com have a domain specific
> >> > Forwarder
> >> > record for sub1.domB.com.
> >> >
> >> > There are also a number of other DNS zones hosted on BIND servers (e.g.
> >> > domB.com, sub2.domB.com, sub3.domB.com, etc). The DNS zones associated
> >> > with
> >> > domB.com represent a company that acquired the company that originally
> >> > owned
> >> > domA.com.
> >> >
> >> > I am trying to add clients to sub1.domB.com and I would like for them
> >> > to
> >> > register themselves in DNS in sub1.domB.com.
> >>
> >> The DNS Server(s) these clients use must be either IN sub1.domB.com or
> >> able
> >> to FIND sub1.domB.com. No exeptions.
> >>
> >
> > The DNS servers in use by the client can consistently resolve
> > sub1.domB.com
> > as well as all hostnames within sub1.domB.com.
> >
> >> Clients should also have their Primary DNS suffix set in the SYSTEM
> >> Control
> >> Panel.
> >>
> >
> > I should have specifically included this info before. Upon joining
> > sub1.domB.com, the Primary DNS suffix of this computer is successfully
> > set.
> > In addition, Change primary DNS suffix when domain membership changes =
> > {checked}.
>
> The former is important (and good) and the latter is not an issue in this
> case but
> is useful if you want to avoid having to reset this value when the client
> changes
> domain (if ever.)
>
> >> > The clients are newly built XP SP2 with default TCP/IP properties:
> >> > Obtain an IP address automatically
> >> > Obtain DNS server address automatically
> >> > Append primary and connection specific DNS suffixes
> >> > Append parent suffixes of the primary DNS suffix = {unchecked}
> >> > DNS suffix for this connection = {blank}
> >> > Register this connection's addresses in DNS = {checked}
> >> > Use this connection's DNS suffix in DNS registration = {unchecked})
> >>
> >> DHCP should also give out the correct DNS name for these clients if at
> >> all possible.
> >>
> >
> > I can't do this yet since the DHCP scope was not set up for and is not
> > specific to the destination domain.
>
> Yes, I suspected that was part of the problem since you have multiple
> domains.
>
> Try setting the IP manually for one of these clients to the "home DNS
> server"
> for their domain (only) and see if it then registers.
>
> This should NOT be necessary but it will allow you to remove a bunch of
> variables
> and perpaps reduce the possibilities of where the problem might be
> originating.
>
> >> > The clients start out as workgroup machines. They obtain their TCP/IP
> >> > info
> >> > via a DHCP server that is a member of domA.com. The DHCP client
> >> > service
> >> > is
> >> > running on the client.
> >>
> >> When they switch to domain machines the Primary DNS suffix needs to be
> >> added to them as part of this change.
> >>
> >
> > Answered above.
> >
> >> > On the DHCP server, the primary and secondary DNS servers are DNS
> >> > servers
> >> > in
> >> > domA.com. Scope option 006 includes only DNS servers for domA.com.
> >> > Scope
> >> > option 015 is set to domA.com. The DHCP server is also set to register
> >> > clients in DNS:
> >> > Automatically update DHCP client information in DNS = {checked}
> >> > Always update DNS
> >> > Discard forward (name-to-address) lookups when lease expires =
> >> > {checked}
> >> > Enable updates for DNS clients that do not support dynamic update =
> >> > {checked}
> >> >
> >> > The clients successfully join the sub1.domB.com AD domain using the
> >> > fqdn.
> >> > However, they do not register in the sub1.domB.com DNS domain. Upon
> >> > reboot,
> >> > or upon using ipconfig /registerdns, they still do not register in the
> >> > sub1.domB.com DNS domain.
> >> >
> >> > Can anyone explain why the DNS registration does not work?
> >> >
> >> > --
> >> > John S
> >> >
> >> > It's an OS, not a religion.
> >>
> >>
> >>
>
>
>

"JohnS" <NNTPAlias@nospam.nospam> wrote in message
news:77BD334F-F8F6-4774-93D4-0E16E8A2B1EC@microsoft.com...
> Herb,
> Thanks for the quick replies. It's reassuring to know that it is indeed
> supposed to work the way I thought it should. Manually changing the DNS
> Server Search Order on the client to point to DNS servers in sub1.domB.com
> is
> the next step. I'll follow up with the level of success...

If this fixes the problem then you do NOT have a reliable or true solution.

You can NEVER DEPEND on the order of DNS servers on the client --
you must presume that the client will contact and use ANY ONE of those
DNS servers listed.

It is fine to replace the DNS settings as a test but do not consider that if
the mere order is ful that the problem is fixed (it's not.)

--
Herb Martin, MCSE, MVP
http://www.LearnQuick.Com
(phone on web site)

> --
> John S
>
> It's an OS, not a religion.
>
>
> "Herb Martin" wrote:
>
>>
>> "JohnS" <NNTPAlias@nospam.nospam> wrote in message
>> news:A0CEA758-3A27-46E5-B933-01909B432C11@microsoft.com...
>> > Let's try this again...
>> >
>> > See my comments embedded below.
>> >
>> > --
>> > John S
>> >
>> > It's an OS, not a religion.
>> >
>> >
>> > "Herb Martin" wrote:
>> >
>> >>
>> >> "JohnS" <NNTPAlias@nospam.nospam> wrote in message
>> >> news:7D3DFE24-04D8-4F19-8C57-06E86EE58F66@microsoft.com...
>> >> >I have an issue where new clients, upon joining the domain, are not
>> >> > registering in DNS. Further, they do not register in DNS at any
>> >> > point
>> >> > thereafter.
>> >>
>> >> DNS Clients must use STRICTLY the set of (internal) DNS servers which
>> >> can find the DNS servers for their own Domain AND ALL other domains
>> >> internally and externall.
>> >>
>> >> The most common error is to mix DNS Servers (sets) on the DNS client
>> >> NIC->IP properties -- i.e, putting DNS servers in there which cannot
>> >> find everything the clients will ever need.
>> >>
>> >> DNS Clients believe that EVERY DNS server will return the same and
>> >> the correct answers.
>> >>
>> >
>> > The DNS servers known to the client are technically not mixed, they
>> > just
>> > aren't part of sub1.domB.com. The are both part of domA.com.
>>
>> As long as every DNS Server (e.g., in domA.com) can FIND the Primary
>> DNS server for the zone where the clients need to register (e.g,
>> sub1.domB.com)
>> then this should not be the problem.
>>
>> This makes it more likely that the DNS Clients don't know their own
>> Primary
>> DNS Suffix.
>>
>> >> > My environment consists of 2 separate AD forests/domains (domA.com
>> >> > and
>> >> > sub1.domB.com), each having their own AD integrated DNS (Dynamic
>> >> > updates =
>> >> > Secure only). The DNS servers for domA.com have a domain specific
>> >> > Forwarder
>> >> > record for sub1.domB.com.
>> >> >
>> >> > There are also a number of other DNS zones hosted on BIND servers
>> >> > (e.g.
>> >> > domB.com, sub2.domB.com, sub3.domB.com, etc). The DNS zones
>> >> > associated
>> >> > with
>> >> > domB.com represent a company that acquired the company that
>> >> > originally
>> >> > owned
>> >> > domA.com.
>> >> >
>> >> > I am trying to add clients to sub1.domB.com and I would like for
>> >> > them
>> >> > to
>> >> > register themselves in DNS in sub1.domB.com.
>> >>
>> >> The DNS Server(s) these clients use must be either IN sub1.domB.com or
>> >> able
>> >> to FIND sub1.domB.com. No exeptions.
>> >>
>> >
>> > The DNS servers in use by the client can consistently resolve
>> > sub1.domB.com
>> > as well as all hostnames within sub1.domB.com.
>> >
>> >> Clients should also have their Primary DNS suffix set in the SYSTEM
>> >> Control
>> >> Panel.
>> >>
>> >
>> > I should have specifically included this info before. Upon joining
>> > sub1.domB.com, the Primary DNS suffix of this computer is successfully
>> > set.
>> > In addition, Change primary DNS suffix when domain membership changes =
>> > {checked}.
>>
>> The former is important (and good) and the latter is not an issue in this
>> case but
>> is useful if you want to avoid having to reset this value when the client
>> changes
>> domain (if ever.)
>>
>> >> > The clients are newly built XP SP2 with default TCP/IP properties:
>> >> > Obtain an IP address automatically
>> >> > Obtain DNS server address automatically
>> >> > Append primary and connection specific DNS suffixes
>> >> > Append parent suffixes of the primary DNS suffix = {unchecked}
>> >> > DNS suffix for this connection = {blank}
>> >> > Register this connection's addresses in DNS = {checked}
>> >> > Use this connection's DNS suffix in DNS registration = {unchecked})
>> >>
>> >> DHCP should also give out the correct DNS name for these clients if at
>> >> all possible.
>> >>
>> >
>> > I can't do this yet since the DHCP scope was not set up for and is not
>> > specific to the destination domain.
>>
>> Yes, I suspected that was part of the problem since you have multiple
>> domains.
>>
>> Try setting the IP manually for one of these clients to the "home DNS
>> server"
>> for their domain (only) and see if it then registers.
>>
>> This should NOT be necessary but it will allow you to remove a bunch of
>> variables
>> and perpaps reduce the possibilities of where the problem might be
>> originating.
>>
>> >> > The clients start out as workgroup machines. They obtain their
>> >> > TCP/IP
>> >> > info
>> >> > via a DHCP server that is a member of domA.com. The DHCP client
>> >> > service
>> >> > is
>> >> > running on the client.
>> >>
>> >> When they switch to domain machines the Primary DNS suffix needs to be
>> >> added to them as part of this change.
>> >>
>> >
>> > Answered above.
>> >
>> >> > On the DHCP server, the primary and secondary DNS servers are DNS
>> >> > servers
>> >> > in
>> >> > domA.com. Scope option 006 includes only DNS servers for domA.com.
>> >> > Scope
>> >> > option 015 is set to domA.com. The DHCP server is also set to
>> >> > register
>> >> > clients in DNS:
>> >> > Automatically update DHCP client information in DNS = {checked}
>> >> > Always update DNS
>> >> > Discard forward (name-to-address) lookups when lease expires =
>> >> > {checked}
>> >> > Enable updates for DNS clients that do not support dynamic update =
>> >> > {checked}
>> >> >
>> >> > The clients successfully join the sub1.domB.com AD domain using the
>> >> > fqdn.
>> >> > However, they do not register in the sub1.domB.com DNS domain. Upon
>> >> > reboot,
>> >> > or upon using ipconfig /registerdns, they still do not register in
>> >> > the
>> >> > sub1.domB.com DNS domain.
>> >> >
>> >> > Can anyone explain why the DNS registration does not work?
>> >> >
>> >> > --
>> >> > John S
>> >> >
>> >> > It's an OS, not a religion.
>> >>
>> >>
>> >>
>>
>>
>>

Hello,

Thank you for using newsgroup!

Also I'd like to thanks Herb Martin for his great and suggestions
sharing.

Thanks & Regards,

Ken Zhao

Microsoft Online Support
Microsoft Global Technical Support Center

Get Secure! - www.microsoft.com/security <http://www.microsoft.com/security>
================================================== ==
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
================================================== ==
This posting is provided "AS IS" with no warranties, and confers no rights.





--------------------
| From: "Herb Martin" <news@learnquick.com>
| References: <7D3DFE24-04D8-4F19-8C57-06E86EE58F66@microsoft.com>
<OL0Z2DfrHHA.3284@TK2MSFTNGP03.phx.gbl>
<A0CEA758-3A27-46E5-B933-01909B432C11@microsoft.com>
<ukQHu7frHHA.3448@TK2MSFTNGP05.phx.gbl>
<77BD334F-F8F6-4774-93D4-0E16E8A2B1EC@microsoft.com>
| Subject: Re: Clients not registering in AD integrated DNS
| Date: Wed, 13 Jun 2007 18:59:42 -0500
| Lines: 208
| X-Priority: 3
| X-MSMail-Priority: Normal
| X-Newsreader: Microsoft Outlook Express 6.00.3790.3959
| X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.3959
| X-RFC2646: Format=Flowed; Original
| Message-ID: <#LDZqbhrHHA.4992@TK2MSFTNGP05.phx.gbl>
| Newsgroups: microsoft.public.windows.server.dns
| NNTP-Posting-Host: cpe-72-177-48-225.austin.res.rr.com 72.177.48.225
| Path: TK2MSFTNGHUB02.phx.gbl!TK2MSFTNGP01.phx.gbl!TK2MSF TNGP05.phx.gbl
| Xref: TK2MSFTNGHUB02.phx.gbl microsoft.public.windows.server.dns:3562
| X-Tomcat-NG: microsoft.public.windows.server.dns
|
|
| "JohnS" <NNTPAlias@nospam.nospam> wrote in message
| news:77BD334F-F8F6-4774-93D4-0E16E8A2B1EC@microsoft.com...
| > Herb,
| > Thanks for the quick replies. It's reassuring to know that it is indeed
| > supposed to work the way I thought it should. Manually changing the DNS
| > Server Search Order on the client to point to DNS servers in
sub1.domB.com
| > is
| > the next step. I'll follow up with the level of success...
|
| If this fixes the problem then you do NOT have a reliable or true
solution.
|
| You can NEVER DEPEND on the order of DNS servers on the client --
| you must presume that the client will contact and use ANY ONE of those
| DNS servers listed.
|
| It is fine to replace the DNS settings as a test but do not consider that
if
| the mere order is ful that the problem is fixed (it's not.)
|
| --
| Herb Martin, MCSE, MVP
| http://www.LearnQuick.Com
| (phone on web site)
|
| > --
| > John S
| >
| > It's an OS, not a religion.
| >
| >
| > "Herb Martin" wrote:
| >
| >>
| >> "JohnS" <NNTPAlias@nospam.nospam> wrote in message
| >> news:A0CEA758-3A27-46E5-B933-01909B432C11@microsoft.com...
| >> > Let's try this again...
| >> >
| >> > See my comments embedded below.
| >> >
| >> > --
| >> > John S
| >> >
| >> > It's an OS, not a religion.
| >> >
| >> >
| >> > "Herb Martin" wrote:
| >> >
| >> >>
| >> >> "JohnS" <NNTPAlias@nospam.nospam> wrote in message
| >> >> news:7D3DFE24-04D8-4F19-8C57-06E86EE58F66@microsoft.com...
| >> >> >I have an issue where new clients, upon joining the domain, are not
| >> >> > registering in DNS. Further, they do not register in DNS at any
| >> >> > point
| >> >> > thereafter.
| >> >>
| >> >> DNS Clients must use STRICTLY the set of (internal) DNS servers
which
| >> >> can find the DNS servers for their own Domain AND ALL other domains
| >> >> internally and externall.
| >> >>
| >> >> The most common error is to mix DNS Servers (sets) on the DNS client
| >> >> NIC->IP properties -- i.e, putting DNS servers in there which cannot
| >> >> find everything the clients will ever need.
| >> >>
| >> >> DNS Clients believe that EVERY DNS server will return the same and
| >> >> the correct answers.
| >> >>
| >> >
| >> > The DNS servers known to the client are technically not mixed, they
| >> > just
| >> > aren't part of sub1.domB.com. The are both part of domA.com.
| >>
| >> As long as every DNS Server (e.g., in domA.com) can FIND the Primary
| >> DNS server for the zone where the clients need to register (e.g,
| >> sub1.domB.com)
| >> then this should not be the problem.
| >>
| >> This makes it more likely that the DNS Clients don't know their own
| >> Primary
| >> DNS Suffix.
| >>
| >> >> > My environment consists of 2 separate AD forests/domains
(domA.com
| >> >> > and
| >> >> > sub1.domB.com), each having their own AD integrated DNS (Dynamic
| >> >> > updates =
| >> >> > Secure only). The DNS servers for domA.com have a domain specific
| >> >> > Forwarder
| >> >> > record for sub1.domB.com.
| >> >> >
| >> >> > There are also a number of other DNS zones hosted on BIND servers
| >> >> > (e.g.
| >> >> > domB.com, sub2.domB.com, sub3.domB.com, etc). The DNS zones
| >> >> > associated
| >> >> > with
| >> >> > domB.com represent a company that acquired the company that
| >> >> > originally
| >> >> > owned
| >> >> > domA.com.
| >> >> >
| >> >> > I am trying to add clients to sub1.domB.com and I would like for
| >> >> > them
| >> >> > to
| >> >> > register themselves in DNS in sub1.domB.com.
| >> >>
| >> >> The DNS Server(s) these clients use must be either IN sub1.domB.com
or
| >> >> able
| >> >> to FIND sub1.domB.com. No exeptions.
| >> >>
| >> >
| >> > The DNS servers in use by the client can consistently resolve
| >> > sub1.domB.com
| >> > as well as all hostnames within sub1.domB.com.
| >> >
| >> >> Clients should also have their Primary DNS suffix set in the SYSTEM
| >> >> Control
| >> >> Panel.
| >> >>
| >> >
| >> > I should have specifically included this info before. Upon joining
| >> > sub1.domB.com, the Primary DNS suffix of this computer is
successfully
| >> > set.
| >> > In addition, Change primary DNS suffix when domain membership
changes =
| >> > {checked}.
| >>
| >> The former is important (and good) and the latter is not an issue in
this
| >> case but
| >> is useful if you want to avoid having to reset this value when the
client
| >> changes
| >> domain (if ever.)
| >>
| >> >> > The clients are newly built XP SP2 with default TCP/IP properties:
| >> >> > Obtain an IP address automatically
| >> >> > Obtain DNS server address automatically
| >> >> > Append primary and connection specific DNS suffixes
| >> >> > Append parent suffixes of the primary DNS suffix = {unchecked}
| >> >> > DNS suffix for this connection = {blank}
| >> >> > Register this connection's addresses in DNS = {checked}
| >> >> > Use this connection's DNS suffix in DNS registration =
{unchecked})
| >> >>
| >> >> DHCP should also give out the correct DNS name for these clients if
at
| >> >> all possible.
| >> >>
| >> >
| >> > I can't do this yet since the DHCP scope was not set up for and is
not
| >> > specific to the destination domain.
| >>
| >> Yes, I suspected that was part of the problem since you have multiple
| >> domains.
| >>
| >> Try setting the IP manually for one of these clients to the "home DNS
| >> server"
| >> for their domain (only) and see if it then registers.
| >>
| >> This should NOT be necessary but it will allow you to remove a bunch of
| >> variables
| >> and perpaps reduce the possibilities of where the problem might be
| >> originating.
| >>
| >> >> > The clients start out as workgroup machines. They obtain their
| >> >> > TCP/IP
| >> >> > info
| >> >> > via a DHCP server that is a member of domA.com. The DHCP client
| >> >> > service
| >> >> > is
| >> >> > running on the client.
| >> >>
| >> >> When they switch to domain machines the Primary DNS suffix needs to
be
| >> >> added to them as part of this change.
| >> >>
| >> >
| >> > Answered above.
| >> >
| >> >> > On the DHCP server, the primary and secondary DNS servers are DNS
| >> >> > servers
| >> >> > in
| >> >> > domA.com. Scope option 006 includes only DNS servers for
domA.com.
| >> >> > Scope
| >> >> > option 015 is set to domA.com. The DHCP server is also set to
| >> >> > register
| >> >> > clients in DNS:
| >> >> > Automatically update DHCP client information in DNS = {checked}
| >> >> > Always update DNS
| >> >> > Discard forward (name-to-address) lookups when lease expires =
| >> >> > {checked}
| >> >> > Enable updates for DNS clients that do not support dynamic
update =
| >> >> > {checked}
| >> >> >
| >> >> > The clients successfully join the sub1.domB.com AD domain using
the
| >> >> > fqdn.
| >> >> > However, they do not register in the sub1.domB.com DNS domain.
Upon
| >> >> > reboot,
| >> >> > or upon using ipconfig /registerdns, they still do not register
in
| >> >> > the
| >> >> > sub1.domB.com DNS domain.
| >> >> >
| >> >> > Can anyone explain why the DNS registration does not work?
| >> >> >
| >> >> > --
| >> >> > John S
| >> >> >
| >> >> > It's an OS, not a religion.
| >> >>
| >> >>
| >> >>
| >>
| >>
| >>
|
|
|

Herb,

First, I wasn't saying I would change the order of the existing entries.
That is a fairly useless thing to do. I was saying I would change both
entries from the set of DNS servers in domA.com to the set of DNS servers in
sub1.domB.com. I was just using the proper name for those entries and
perhaps that caused confusion.

Second, it made no difference. Hardcoding the DNS servers for sub1.domB.com
on the client had no effect at all.

As another test, I decided to use static addressing and take the DHCP server
out of the equation. I gave the client a static IP, gateway, netmask, and
DNS server IP addrs (both in sub1.domB.com), rebooted, and it registered in
sub1.domB.com DNS with no issues.

So, now I am wondering how it is that the DHCP server can prevent the client
from registering in DNS. Everything I've ever read tells me that a DHCP
server might additionally try to register a client in DNS, but shouldn't
prevent the client from attempting to do so itself.

I did one more test after this... I removed the client entry from the DNS
server, set the client back to using DHCP for everything. No hardcoding of
anything. Then I made the following changes:
DNS suffix for this connection = sub1.domB.com
Use this connection's DNS suffix in DNS registration = {checked}

Using this method, the client again registered itself in sub1.domB.com DNS.
However, I shouldn't have needed to do this since these settings are supposed
to be for registering in additional DNS domains.

--
John S

It's an OS, not a religion.


"Herb Martin" wrote:

>
> "JohnS" <NNTPAlias@nospam.nospam> wrote in message
> news:77BD334F-F8F6-4774-93D4-0E16E8A2B1EC@microsoft.com...
> > Herb,
> > Thanks for the quick replies. It's reassuring to know that it is indeed
> > supposed to work the way I thought it should. Manually changing the DNS
> > Server Search Order on the client to point to DNS servers in sub1.domB.com
> > is
> > the next step. I'll follow up with the level of success...
>
> If this fixes the problem then you do NOT have a reliable or true solution.
>
> You can NEVER DEPEND on the order of DNS servers on the client --
> you must presume that the client will contact and use ANY ONE of those
> DNS servers listed.
>
> It is fine to replace the DNS settings as a test but do not consider that if
> the mere order is ful that the problem is fixed (it's not.)
>
> --
> Herb Martin, MCSE, MVP
> http://www.LearnQuick.Com
> (phone on web site)
>
> > --
> > John S
> >
> > It's an OS, not a religion.
> >
> >
> > "Herb Martin" wrote:
> >
> >>
> >> "JohnS" <NNTPAlias@nospam.nospam> wrote in message
> >> news:A0CEA758-3A27-46E5-B933-01909B432C11@microsoft.com...
> >> > Let's try this again...
> >> >
> >> > See my comments embedded below.
> >> >
> >> > --
> >> > John S
> >> >
> >> > It's an OS, not a religion.
> >> >
> >> >
> >> > "Herb Martin" wrote:
> >> >
> >> >>
> >> >> "JohnS" <NNTPAlias@nospam.nospam> wrote in message
> >> >> news:7D3DFE24-04D8-4F19-8C57-06E86EE58F66@microsoft.com...
> >> >> >I have an issue where new clients, upon joining the domain, are not
> >> >> > registering in DNS. Further, they do not register in DNS at any
> >> >> > point
> >> >> > thereafter.
> >> >>
> >> >> DNS Clients must use STRICTLY the set of (internal) DNS servers which
> >> >> can find the DNS servers for their own Domain AND ALL other domains
> >> >> internally and externall.
> >> >>
> >> >> The most common error is to mix DNS Servers (sets) on the DNS client
> >> >> NIC->IP properties -- i.e, putting DNS servers in there which cannot
> >> >> find everything the clients will ever need.
> >> >>
> >> >> DNS Clients believe that EVERY DNS server will return the same and
> >> >> the correct answers.
> >> >>
> >> >
> >> > The DNS servers known to the client are technically not mixed, they
> >> > just
> >> > aren't part of sub1.domB.com. The are both part of domA.com.
> >>
> >> As long as every DNS Server (e.g., in domA.com) can FIND the Primary
> >> DNS server for the zone where the clients need to register (e.g,
> >> sub1.domB.com)
> >> then this should not be the problem.
> >>
> >> This makes it more likely that the DNS Clients don't know their own
> >> Primary
> >> DNS Suffix.
> >>
> >> >> > My environment consists of 2 separate AD forests/domains (domA.com
> >> >> > and
> >> >> > sub1.domB.com), each having their own AD integrated DNS (Dynamic
> >> >> > updates =
> >> >> > Secure only). The DNS servers for domA.com have a domain specific
> >> >> > Forwarder
> >> >> > record for sub1.domB.com.
> >> >> >
> >> >> > There are also a number of other DNS zones hosted on BIND servers
> >> >> > (e.g.
> >> >> > domB.com, sub2.domB.com, sub3.domB.com, etc). The DNS zones
> >> >> > associated
> >> >> > with
> >> >> > domB.com represent a company that acquired the company that
> >> >> > originally
> >> >> > owned
> >> >> > domA.com.
> >> >> >
> >> >> > I am trying to add clients to sub1.domB.com and I would like for
> >> >> > them
> >> >> > to
> >> >> > register themselves in DNS in sub1.domB.com.
> >> >>
> >> >> The DNS Server(s) these clients use must be either IN sub1.domB.com or
> >> >> able
> >> >> to FIND sub1.domB.com. No exeptions.
> >> >>
> >> >
> >> > The DNS servers in use by the client can consistently resolve
> >> > sub1.domB.com
> >> > as well as all hostnames within sub1.domB.com.
> >> >
> >> >> Clients should also have their Primary DNS suffix set in the SYSTEM
> >> >> Control
> >> >> Panel.
> >> >>
> >> >
> >> > I should have specifically included this info before. Upon joining
> >> > sub1.domB.com, the Primary DNS suffix of this computer is successfully
> >> > set.
> >> > In addition, Change primary DNS suffix when domain membership changes =
> >> > {checked}.
> >>
> >> The former is important (and good) and the latter is not an issue in this
> >> case but
> >> is useful if you want to avoid having to reset this value when the client
> >> changes
> >> domain (if ever.)
> >>
> >> >> > The clients are newly built XP SP2 with default TCP/IP properties:
> >> >> > Obtain an IP address automatically
> >> >> > Obtain DNS server address automatically
> >> >> > Append primary and connection specific DNS suffixes
> >> >> > Append parent suffixes of the primary DNS suffix = {unchecked}
> >> >> > DNS suffix for this connection = {blank}
> >> >> > Register this connection's addresses in DNS = {checked}
> >> >> > Use this connection's DNS suffix in DNS registration = {unchecked})
> >> >>
> >> >> DHCP should also give out the correct DNS name for these clients if at
> >> >> all possible.
> >> >>
> >> >
> >> > I can't do this yet since the DHCP scope was not set up for and is not
> >> > specific to the destination domain.
> >>
> >> Yes, I suspected that was part of the problem since you have multiple
> >> domains.
> >>
> >> Try setting the IP manually for one of these clients to the "home DNS
> >> server"
> >> for their domain (only) and see if it then registers.
> >>
> >> This should NOT be necessary but it will allow you to remove a bunch of
> >> variables
> >> and perpaps reduce the possibilities of where the problem might be
> >> originating.
> >>
> >> >> > The clients start out as workgroup machines. They obtain their
> >> >> > TCP/IP
> >> >> > info
> >> >> > via a DHCP server that is a member of domA.com. The DHCP client
> >> >> > service
> >> >> > is
> >> >> > running on the client.
> >> >>
> >> >> When they switch to domain machines the Primary DNS suffix needs to be
> >> >> added to them as part of this change.
> >> >>
> >> >
> >> > Answered above.
> >> >
> >> >> > On the DHCP server, the primary and secondary DNS servers are DNS
> >> >> > servers
> >> >> > in
> >> >> > domA.com. Scope option 006 includes only DNS servers for domA.com.
> >> >> > Scope
> >> >> > option 015 is set to domA.com. The DHCP server is also set to
> >> >> > register
> >> >> > clients in DNS:
> >> >> > Automatically update DHCP client information in DNS = {checked}
> >> >> > Always update DNS
> >> >> > Discard forward (name-to-address) lookups when lease expires =
> >> >> > {checked}
> >> >> > Enable updates for DNS clients that do not support dynamic update =
> >> >> > {checked}
> >> >> >
> >> >> > The clients successfully join the sub1.domB.com AD domain using the
> >> >> > fqdn.
> >> >> > However, they do not register in the sub1.domB.com DNS domain. Upon
> >> >> > reboot,
> >> >> > or upon using ipconfig /registerdns, they still do not register in
> >> >> > the
> >> >> > sub1.domB.com DNS domain.
> >> >> >
> >> >> > Can anyone explain why the DNS registration does not work?
> >> >> >
> >> >> > --
> >> >> > John S
> >> >> >
> >> >> > It's an OS, not a religion.
> >> >>
> >> >>
> >> >>
> >>
> >>
> >>
>
>
>

"JohnS" <NNTPAlias@nospam.nospam> wrote in message
news:01D0143C-4A10-4C34-A78B-51F9EF5A5CB3@microsoft.com...
> Herb,
>
> First, I wasn't saying I would change the order of the existing entries.

Good.


> That is a fairly useless thing to do.

It isn't quite useful but can make the problem appear to go away so I
was worried for you.

> I was saying I would change both
> entries from the set of DNS servers in domA.com to the set of DNS servers
> in
> sub1.domB.com. I was just using the proper name for those entries and
> perhaps that caused confusion.

Ok, good. They way you said it (change the search order) strongly implied
you
were going to do just that, rather than REPLACE those settings.

> Second, it made no difference. Hardcoding the DNS servers for
> sub1.domB.com
> on the client had no effect at all.

Good. Then this is not likely the problem. If some machines can register
and
these cannot then things to check:


> As another test, I decided to use static addressing and take the DHCP
> server
> out of the equation. I gave the client a static IP, gateway, netmask, and
> DNS server IP addrs (both in sub1.domB.com), rebooted, and it registered
> in
> sub1.domB.com DNS with no issues.

Was the DHCP server set to do the registration? If so, you might need the
clients
to do their own registration (mostly due to authentication issues.)

What is the status of the Dynamic updates on the DNS? Is it set to SECURE
ONLY?

If so, then failure to authenticate would be a likely cause.

DHCP is not authenticated but the (manual) client is authenticated in that
domain.

> So, now I am wondering how it is that the DHCP server can prevent the
> client
> from registering in DNS. Everything I've ever read tells me that a DHCP
> server might additionally try to register a client in DNS, but shouldn't
> prevent the client from attempting to do so itself.
>
> I did one more test after this... I removed the client entry from the DNS
> server, set the client back to using DHCP for everything. No hardcoding
> of
> anything. Then I made the following changes:
> DNS suffix for this connection = sub1.domB.com
> Use this connection's DNS suffix in DNS registration = {checked}
>
> Using this method, the client again registered itself in sub1.domB.com
> DNS.
> However, I shouldn't have needed to do this since these settings are
> supposed
> to be for registering in additional DNS domains.

No, you should have that check box enabled (register in DNS) but you don't
need
to fill in the "connection suffix" so that it will just register the PRIMARY
DNS
suffix from the System Control Panel.

Herb,

Yes, the DHCP server was set to do the registration (as mentioned in my
original post and repeated below).

> >> > On the DHCP server, the primary and secondary DNS servers are DNS
> >> > servers
> >> > in
> >> > domA.com. Scope option 006 includes only DNS servers for domA.com.
> >> > Scope
> >> > option 015 is set to domA.com. The DHCP server is also set to register
> >> > clients in DNS:
> >> > Automatically update DHCP client information in DNS = {checked}
> >> > Always update DNS
> >> > Discard forward (name-to-address) lookups when lease expires =
> >> > {checked}
> >> > Enable updates for DNS clients that do not support dynamic update =
> >> > {checked}

And yes, I am using the "Secure only" setting (as mentioned in my original
post and repeated below).

> >> > My environment consists of 2 separate AD forests/domains (domA.com and
> >> > sub1.domB.com), each having their own AD integrated DNS (Dynamic
> >> > updates =
> >> > Secure only).

I knew before starting this that the DHCP server would be unsuccessful in
its attempt to do the registration due to authentication issues.

There are 2 checkboxes near the bottom of the "Advance TCP/IP Settings"
window on the client's NIC properties.

The 1st of those ("Register this connection's addresses in DNS") should be
checked in order to register in the "Primary DNS suffix of this computer" as
specified in the System Properties, Computer Name tab, Change button, More
button. The configuration of the DHCP server should have no effect on the
functionality of this checkbox.

The 2nd checkbox ("Use this connection's DNS suffix in DNS registration") is
supposed to be used in tandem with the value in the "DNS suffix for this
connection" field in order to register in additional DNS domains. I
shouldn't need to use either this checkbox or the associated field to
register in the domain associated with the 1st checkbox mentioned above. Yet
that is the only thing that allowed registration when also using the DHCP
server.

Can someone point me to documentation that suggests the use of a DHCP server
configured to register clients in DNS can cause the functionality of the 1st
checkbox mentioned above to be disabled?

If not, can someone suggest an alternative explanation as to why I had to
use the 2nd checkbox method to make all of this work?

--
John S

It's an OS, not a religion.


"Herb Martin" wrote:

>
> "JohnS" <NNTPAlias@nospam.nospam> wrote in message
> news:01D0143C-4A10-4C34-A78B-51F9EF5A5CB3@microsoft.com...
> > Herb,
> >
> > First, I wasn't saying I would change the order of the existing entries.
>
> Good.
>
>
> > That is a fairly useless thing to do.
>
> It isn't quite useful but can make the problem appear to go away so I
> was worried for you.
>
> > I was saying I would change both
> > entries from the set of DNS servers in domA.com to the set of DNS servers
> > in
> > sub1.domB.com. I was just using the proper name for those entries and
> > perhaps that caused confusion.
>
> Ok, good. They way you said it (change the search order) strongly implied
> you
> were going to do just that, rather than REPLACE those settings.
>
> > Second, it made no difference. Hardcoding the DNS servers for
> > sub1.domB.com
> > on the client had no effect at all.
>
> Good. Then this is not likely the problem. If some machines can register
> and
> these cannot then things to check:
>
>
> > As another test, I decided to use static addressing and take the DHCP
> > server
> > out of the equation. I gave the client a static IP, gateway, netmask, and
> > DNS server IP addrs (both in sub1.domB.com), rebooted, and it registered
> > in
> > sub1.domB.com DNS with no issues.
>
> Was the DHCP server set to do the registration? If so, you might need the
> clients
> to do their own registration (mostly due to authentication issues.)
>
> What is the status of the Dynamic updates on the DNS? Is it set to SECURE
> ONLY?
>
> If so, then failure to authenticate would be a likely cause.
>
> DHCP is not authenticated but the (manual) client is authenticated in that
> domain.
>
> > So, now I am wondering how it is that the DHCP server can prevent the
> > client
> > from registering in DNS. Everything I've ever read tells me that a DHCP
> > server might additionally try to register a client in DNS, but shouldn't
> > prevent the client from attempting to do so itself.
> >
> > I did one more test after this... I removed the client entry from the DNS
> > server, set the client back to using DHCP for everything. No hardcoding
> > of
> > anything. Then I made the following changes:
> > DNS suffix for this connection = sub1.domB.com
> > Use this connection's DNS suffix in DNS registration = {checked}
> >
> > Using this method, the client again registered itself in sub1.domB.com
> > DNS.
> > However, I shouldn't have needed to do this since these settings are
> > supposed
> > to be for registering in additional DNS domains.
>
> No, you should have that check box enabled (register in DNS) but you don't
> need
> to fill in the "connection suffix" so that it will just register the PRIMARY
> DNS
> suffix from the System Control Panel.
>
>
>

"JohnS" <NNTPAlias@nospam.nospam> wrote in message
news:3A4AB512-F345-44A3-AE99-59F26FDC4100@microsoft.com...
> Herb,
>
> Yes, the DHCP server was set to do the registration (as mentioned in my
> original post and repeated below).

I missed that (originally) even though I looked for it.

>> >> > On the DHCP server, the primary and secondary DNS servers are DNS
>> >> > servers
>> >> > in
>> >> > domA.com. Scope option 006 includes only DNS servers for domA.com.
>> >> > Scope
>> >> > option 015 is set to domA.com. The DHCP server is also set to
>> >> > register
>> >> > clients in DNS:
>> >> > Automatically update DHCP client information in DNS = {checked}
>> >> > Always update DNS
>> >> > Discard forward (name-to-address) lookups when lease expires =
>> >> > {checked}
>> >> > Enable updates for DNS clients that do not support dynamic update =
>> >> > {checked}
>
> And yes, I am using the "Secure only" setting (as mentioned in my original
> post and repeated below).

If the DHCP server is NOT in the domain with the AD, then it must be able
to AUTHENTICATE and get a referral to the domain that stores the DNS
securely.

This could be as simple as failure to authenticate the DHCP server or with
authentication failure to follow DNS or some other problem getting to the
"other" Domain through the trusts.