Drive Mapping Issues in Win2K AD, DNS related?

  • Thread starter Thread starter Dan
  • Start date Start date
D

Dan

I've been working on trying to resolve some issues with a new Win2k
AD. Here's the setup. I'm going to try to draw an ASCI picture to
help as I'm having difficulty putting things into words.


(DC,DNS) DC1.parent.com -----/WAN/------- DC2.parent.com (DC,DNS)
| |
| |
| |
server1.child1.parent.com server2.child2.parent.com
(DC,DHCP - 192.168.6.X) (DC,DHCP - 192.168.7.X)

I hope that turned out okay. Each half of this drawing indicates a
different physical location.

We are having difficulty with authentication between domains. For
instance, I am unable to connect to a share on
server1.child1.parent.com from a workstation or server in the
child2.parent.com domain, however my counterpart in the other location
is able to connect just fine to shares on server2.child2.parent.com
from any workstation or server in child1.parent.com. I receive the
error message "no logon servers are available, etc".

Each workstation and server in child2.parent.com is set to point to
the IP address of DC2.parent.com for DNS. I have added the domain
suffixes to each workstation in the child2.parent.com domain in this
order "child2.parent.com, child1.parent.com, parent.com". I have tried
mapping by NetBIOS name and by IP address with the same results.

DNS is setup with three forward lookup zones which are
child2.parent.com, child1.parent.com and parent.com. Each of those is
setup for dynamic updates and Name Servers are set within the
properties of each to point to DC1 and DC2. Host records have
automatically appeared in child2.parent.com for workstations
connecting to that domain. Manual hosts have been setup in parent.com
for DC1, DC2 and a member server. I am able to ping all of the
servers on both ends by IP successfully.

I have successfully verified the trust between child2.parent.com and
parent.com in both directions. We thought that creating an explicit
trust between child1.parent.com and child2.parent.com would resolve
the issue but we are unable to create the trust due to an error which
states that the logon server is unavailble or cannot be found.

Any assistance would be greatly appreciated.

Drivie
 
In
Dan said:
I've been working on trying to resolve some issues with a
new Win2k AD. Here's the setup. I'm going to try to
draw an ASCI picture to help as I'm having difficulty
putting things into words.


(DC,DNS) DC1.parent.com -----/WAN/-------
DC2.parent.com (DC,DNS) |
| | |
| |
server1.child1.parent.com
server2.child2.parent.com (DC,DHCP - 192.168.6.X)
(DC,DHCP - 192.168.7.X)

I hope that turned out okay. Each half of this drawing
indicates a different physical location.

We are having difficulty with authentication between
domains. For instance, I am unable to connect to a share
on server1.child1.parent.com from a workstation or server
in the child2.parent.com domain, however my counterpart
in the other location is able to connect just fine to
shares on server2.child2.parent.com from any workstation
or server in child1.parent.com. I receive the error
message "no logon servers are available, etc".

Each workstation and server in child2.parent.com is set
to point to the IP address of DC2.parent.com for DNS. I
have added the domain suffixes to each workstation in the
child2.parent.com domain in this order
"child2.parent.com, child1.parent.com, parent.com". I
have tried mapping by NetBIOS name and by IP address with
the same results.

DNS is setup with three forward lookup zones which are
child2.parent.com, child1.parent.com and parent.com.
Each of those is setup for dynamic updates and Name
Servers are set within the properties of each to point to
DC1 and DC2. Host records have automatically appeared in
child2.parent.com for workstations connecting to that
domain. Manual hosts have been setup in parent.com for
DC1, DC2 and a member server. I am able to ping all of
the servers on both ends by IP successfully.

I have successfully verified the trust between
child2.parent.com and parent.com in both directions. We
thought that creating an explicit trust between
child1.parent.com and child2.parent.com would resolve the
issue but we are unable to create the trust due to an
error which states that the logon server is unavailble or
cannot be found.
Click to expand...

Are you trying to map the drive by the NetBIOS name or FQDN?
e.g. Is it \\server2\share or \\server2.child2.parent.com\share ?

If you are trying to use \\server2\share have you configured WINS in both
domains, then set them as replication partners.
 
Kevin D. Goodknecht Sr. said:
In

Are you trying to map the drive by the NetBIOS name or FQDN?
e.g. Is it \\server2\share or \\server2.child2.parent.com\share ?

If you are trying to use \\server2\share have you configured WINS in both
domains, then set them as replication partners.
Click to expand...

Kevin,

Thanks for the reply. We have tried connecting via NetBIOS name and
by IP address but not by FQDN. DNS appears to resolve the host names
correctly by NetBIOS name but I still receive the error saying that
"no logon servers are available..." We do not have WINS setup so we
are unable to browse one child domain from the other but that's not a
big deal for us. Would WINS help to resolve authentication issues?

Thank you,

Drivie
 
In
Dan said:
"Kevin D. Goodknecht Sr. [MVP]" <[email protected]>
wrote in message


Kevin,

Thanks for the reply. We have tried connecting via
NetBIOS name and
by IP address but not by FQDN. DNS appears to resolve
the host names
correctly by NetBIOS name but I still receive the error
Click to expand...

DNS is not resolving the NetBIOS name, it is resolving the host name using
the DNS suffix search list. DNS can use WINS if configured to do so on the
zone properties.
saying that
"no logon servers are available..." We do not have WINS
setup so we
are unable to browse one child domain from the other but
that's not a
big deal for us. Would WINS help to resolve
authentication issues?
Click to expand...

If you are talking about browsing the different sites through Network
Places, the only way you can do this _is_ with WINS if you have two subnets.
NetBIOS is a broadcast protocol and will not cross a router. For that you
need WINS.

Set up a WINS server at each site and point the machines at each site to
that site's WINS server only. Then configure the WINS servers to replicate
with the other site. If you only have two sites configure them to replicate
with each other.
Site1<----->Site2
In this scenario each WINS server will use push pull to fully populate

If you have three sites configure WINS to replicate with only one other
site.
Site3<----->Site1<------->Site2
In the scenario Site3 uses push pull with Site1 which uses push pull with
Site2 to fully populate all three sites.
 
In
Dan said:
Kevin,

Thanks for the reply. We have tried connecting via NetBIOS name and
by IP address but not by FQDN. DNS appears to resolve the host names
correctly by NetBIOS name but I still receive the error saying that
"no logon servers are available..."
Click to expand...

This can depend on a coupel things:
1. What operating system are the clients?
2. If the clients are W2k or newer, then is DNS resolving and do the SRV
records exist? You said so far it does NOT resolve by FQDN, so there's a
huge hint that DNS is not setup correctly across your mutliple subnets.

If you can post this data below for us from a client and a server from both
subnets, that can give us a start in diagnosing this:
1. Unedited ipconfig /all
2. AD DNS domain name (as it shows in ADUC):
3. Zone names that exist on both DNS server in both subnets.
We do not have WINS setup so we
are unable to browse one child domain from the other but that's not a
big deal for us. Would WINS help to resolve authentication issues?
Click to expand...

That depends on what app is trying to authenticate. Active Directory for W2k
or newer clients use Kerberos, and Kerberos uses DNS, so no, WINS won't help
with Kerberos, but YES for backward level clients, such as Win98, WinME,
NT4, or DOS, etc.

If you need this Network neighborhood functionality along with the ability
for backward level clients, then you need WINS. I would follow Kevin's
advise on how to set it up.


--
Regards,
Ace

Please direct all replies ONLY to the Microsoft public newsgroups
so all can benefit.

This posting is provided "AS-IS" with no warranties or guarantees
and confers no rights.

Ace Fekay, MCSE 2003 & 2000, MCSA 2003 & 2000, MCSE+I, MCT, MVP
Microsoft Windows MVP - Windows Server - Directory Services

Security Is Like An Onion, It Has Layers
HAM AND EGGS: A day's work for a chicken;
A lifetime commitment for a pig.
 
Gentlemen,

First of all, sorry for the top-reply. Thank you for the quick
replies and attempts at assisting me in resolving these issues but it
would appear that I jumped the gun a bit. The day I posted the first
question, we had made some major changes to DNS which are reflected in
the ASCII drawing I created (meaning that it was current). Prior to
that, we had DNS running on each of the child DCs (in addition to DNS
on the parent DCs) with DHCP pointing the clients to the child DCs for
DNS and forwarders to Internet DNSs which I think was probably the
wrong setup. We were not using forwarders to the parent DCs and DNS
delegation which may have been the problem. Quickly after making the
changes reflected in the drawing, meaning that we removed DNS from the
child DCs and reconfigured DNS on the parent DCs, things still didn't
work so I figured I would post to see if there were any suggestions.
I guess I didn't give enough time for the DNS caches to flush and
update properly even though I forced the flushes and updates (or so I
thought).

As an update to this, I returned to the office this afternoon and lo
and behold, everything was working properly. I could map network
drives by NetBIOS name to both the parent DCs and servers in the child
domain on the other side of the WAN. I now understand that the client
is using the domain suffix list to locate the machines on the other
side of the WAN (Thank you Kevin for the clarification). Boy am I
happy that this is finally working! Oddly enough, it works perfectly
even on the Win98 and WinME clients without the need for WINS. I also
don't have DSCLIENT installed on the older 98/Me client machines so
I'm not sure how the authentication is functioning properly unless I
misunderstood ACE's reference to Kerberos authentication and DNS vs.
older client authentication.

Thanks again for the assistance guys. I greatly appreciate the
knowledge.

Drivie
 
In
Dan said:
Gentlemen,

First of all, sorry for the top-reply. Thank you for the quick
replies and attempts at assisting me in resolving these issues but it
would appear that I jumped the gun a bit. The day I posted the first
question, we had made some major changes to DNS which are reflected in
the ASCII drawing I created (meaning that it was current). Prior to
that, we had DNS running on each of the child DCs (in addition to DNS
on the parent DCs) with DHCP pointing the clients to the child DCs for
DNS and forwarders to Internet DNSs which I think was probably the
wrong setup. We were not using forwarders to the parent DCs and DNS
delegation which may have been the problem. Quickly after making the
changes reflected in the drawing, meaning that we removed DNS from the
child DCs and reconfigured DNS on the parent DCs, things still didn't
work so I figured I would post to see if there were any suggestions.
I guess I didn't give enough time for the DNS caches to flush and
update properly even though I forced the flushes and updates (or so I
thought).

As an update to this, I returned to the office this afternoon and lo
and behold, everything was working properly. I could map network
drives by NetBIOS name to both the parent DCs and servers in the child
domain on the other side of the WAN. I now understand that the client
is using the domain suffix list to locate the machines on the other
side of the WAN (Thank you Kevin for the clarification). Boy am I
happy that this is finally working! Oddly enough, it works perfectly
even on the Win98 and WinME clients without the need for WINS. I also
don't have DSCLIENT installed on the older 98/Me client machines so
I'm not sure how the authentication is functioning properly unless I
misunderstood ACE's reference to Kerberos authentication and DNS vs.
older client authentication.

Thanks again for the assistance guys. I greatly appreciate the
knowledge.

Drivie
Click to expand...

Glad you got it working. Don't worry about top posting, it's all good. Yes,
as Kevin mentioned, the search suffix dictates what its resolving and
devolution between the different suffixes.

Authentication and backward level clients are NTLMv2 based (uses NetBIOS).
Kerberos is W2k and newer based (uses DNS).

Apparently you're using delegation, so yes, the child needs to forward to
the parent, then the parent forwards to the ISP.

Glad you got it!



--
Regards,
Ace

Please direct all replies ONLY to the Microsoft public newsgroups
so all can benefit.

This posting is provided "AS-IS" with no warranties or guarantees
and confers no rights.

Ace Fekay, MCSE 2003 & 2000, MCSA 2003 & 2000, MCSE+I, MCT, MVP
Microsoft Windows MVP - Windows Server - Directory Services

Security Is Like An Onion, It Has Layers
HAM AND EGGS: A day's work for a chicken;
A lifetime commitment for a pig.
 
Ace,

As a follow-up to your post, I thought I would just clarify one thing.
I don't believe that we are actually utilizing delegation at this
point because we no longer have DNS installed on the child DCs so they
are just pointing to the parent DCs for DNS in their NIC settings (as
are the clients). Hopefully this still makes sense. It appears to
work properly. If you see anything wrong with this setup, of if there
is a better way to do things, please let me know.

Thanks again,

Drivie
 
In
Dan said:
Ace,

As a follow-up to your post, I thought I would just clarify one thing.
I don't believe that we are actually utilizing delegation at this
point because we no longer have DNS installed on the child DCs so they
are just pointing to the parent DCs for DNS in their NIC settings (as
are the clients). Hopefully this still makes sense. It appears to
work properly. If you see anything wrong with this setup, of if there
is a better way to do things, please let me know.

Thanks again,

Drivie

"Ace Fekay [MVP]"
Click to expand...

So you;re not using delegation. No problem, your setup is fine. Delegation
is just for allowing another domain's admins to administer DNS at their
location and/or to reduce WAN traffic. You can do it either way. Here's some
info on it:

255248 - HOW TO Create a Child Domain in Active Directory and Delegate the
DNS Namespace to the Child Domain:
http://support.microsoft.com/?id=255248

--
Regards,
Ace

Please direct all replies ONLY to the Microsoft public newsgroups
so all can benefit.

This posting is provided "AS-IS" with no warranties or guarantees
and confers no rights.

Ace Fekay, MCSE 2003 & 2000, MCSA 2003 & 2000, MCSE+I, MCT, MVP
Microsoft Windows MVP - Windows Server - Directory Services

Security Is Like An Onion, It Has Layers
HAM AND EGGS: A day's work for a chicken;
A lifetime commitment for a pig.
 
In
Dan said:
Ace,

As a follow-up to your post, I thought I would just
clarify one thing.
I don't believe that we are actually utilizing
delegation at this
point because we no longer have DNS installed on the
child DCs so they
are just pointing to the parent DCs for DNS in their NIC
settings (as
are the clients). Hopefully this still makes sense. It
appears to
work properly. If you see anything wrong with this
setup, of if there
is a better way to do things, please let me know.
Click to expand...

As a matter of opinion, there is nothing wrong with using the parent DC for
DNS, I do that myself. But, all my machines are at one site. It might work
better if you had a local DNS for the clients. As far as that goes you could
install DNS on the child DCs then pull a secondary of the zone from the
parent DC. The Mname record would be used in that case to update the primary
zone on the parent DNS.
 
Back
Top