Unable to browse one child domain from another

Our WAN consists of a parent domain and two child domains (i.e.
parent.com and child1.parent.com and child2.parent.com). Domain
controllers with DNS in the parent domain exist on each end of a two-
node WAN joined by bonded T1's. There is a single child domain on
each end of the WAN. All DC's are running Windows Server 2003 R2
(with all updates). From each child domain, we are able to browse
(entire network, Microsoft Windows Network) and see the same child
domain as well as the parent domain but we are unable to see the other
child domain on the other end of the WAN. Name resolution appears to
work properly and DNS suffixes have been added such that I can
successfully ping any machine on the WAN by name. I can also type the
machine name into an explorer window's address bar and reach it
without issue however I still cannot see the child domain listed when
browsing.

parent - (Bonded T1's) - parent
/ \
child1 child2

If I attempt to type the child netbios domain name into the address
bar (\\child2), I receive an error "\\child2 is not accessible. You
might not have permission to use this network resource. Contact the
administrator of this server to find out if you have access
permissions." "The network path was not found." I attempted this
from a DC in child1 while logged in as administrator of
child1.parent.com.

On one end of the WAN (child1.parent.com), we only have a single DC
and it is not running DNS. We are currently relying on a DC from the
parent domain to provide DNS on this end. NetBIOS over TCP/IP is
enabled on the DC's NIC.

On the other end (child2.parent.com), DC's running DNS exist in both
the parent and child2 domains but that doesn't change the fact that
neither side can see the other. We do not have a WINS server on the
network. I believe we have DNS configured properly but I'm not
certain so I'm posting here.

Any assistance is greatly appreciated.

Dan

Are you using WINS? WINS will provide NetBIOS name resolution across
subnets. AD normally handles this if it is a pure AD network, unless
something was disabled. However, the easy solution is to use WINS.

What Is WINS?: Windows Internet Name Service (WINS)Although NetBIOS and
NetBIOS names can be used with network protocols other than TCP/IP, WINS was
designed specifically to support NetBIOS over TCP/IP ...
http://technet.microsoft.com/en-us/l...80(WS.10).aspx

We are not currently running WINS on any
server in either the child or parent domains. A year or so ago, we
eliminated an older server on the network but I know for a fact that
it was not running WINS either, however, I'm nearly certain that we
were able to browse from child to child prior to demotion of that
server. I'm just not sure what, if anything, configuration-wise was
changed that caused this to stop working.

Am I correct in assuming that we should be able to browse child to
child without WINS or is WINS absolutely necessary in order for this
to work?

Well, that's been a debated topic that has surfaced off and on. If
NetBIOS has been disabled, DirectSMB will be used, and AD will provide
browsing. However, I don't know what occured and what was changed, if
you had properly trasferred the PDC Emulator role, which will be a
factor, when the other DC was demoted, etc. There are many factors.
Yes, it should work without WINS, but then again, it's a bit more
flakier then to just use WINS.

Read what I've blogged on it in my Resolution blog.

DNS, WINS & the Client Side Resolver, NetBIOS, Browser Service,
Disabling NetBIOS, Direct Hosted SMB (DirectSMB), If One DC is Down,
Does a Client logon to Another DC, and DNS Forwarders Algorithm, and do
I need WINS?
http://msmvps.com/blogs/acefekay/arc...algorithm.aspx

I took a look at the link you provided and I see that there is a gray
area regarding the need for WINS vs. AD and DNS with resolution.

I can tell you for certain that the PDC Emulator role was properly
transferred from the old server to the new one (verified). I just
can't grasp why each child domain is capable of seeing itself and the
parent but not the other child. The entire forest is AD with
integrated DNS and everything appears to function properly.

Any other advise you have to offer or suggestions would be greatly
appreciated. If you require additional info such as specific info
related to our network config, please don't hesistate to ask but I
might be more inclined to communicate that info privately rather than
in a public forum.

I try to keep any support issues online. It helps so others can
collaborate if I miss anything. We try to work together on things in
the groups.

This is a difficult one to diagnose. If it was working, then now it is
not, can be caused by a variety of issues. I can tell you that for my
larger customers, I prefer WINS, because it also supports legacy NTLM
based apps. I am not sure if DirectSMB supports this because DirectSMB
is port 443 based, and the older apps are looking for NetBIOS on 139.

Thanks again. The issue here however is simple network browsing.
I'm not even trying to depend upon a particular app to resolve
resources across a WAN, I simply want to be able to open Network
Places and browse to any of the three domains that are available on
the WAN instead of only two at a time. I suppose WINS might be my
solution but I sure would like to know if there's something that I can
look into to see if this problem is related to a configuration issue.
Do you think I should post my original question in a different forum
to see if there are any other recommendations?

You can try posting it elsewhere, however most if not all of the folks
that monitor and respond in this group, also monitor the other groups.
I would imagine since no one else responded, they may not have any
suggestions.

When it comes to networking browsing, it can be tedious to
troubleshoot. As I've implied, WINS is the answer for multi-subnet
browsing to allow consitency, whether for apps or browsing in general,
especially if you have VPN access clients on a separate VPN subnet,
which does not work with DirectSMB browsing.

Maybe a call to Microsoft PSS may be in order?

So, what your are saying is that all the AD DNS infrastructure was
created for security, but does not allow browsing in a mulit-subnet
environment. So are we restricted still to WINS previously inability
to handle more than one same host names of two different child
domains, for example www.seattle.contessa and www.sanfrancisco.contessa,
in the same WINS database?

Really? I was under the impression that the browse list was entirely
dependant on compilation of client (LanManager) announcements (by the
Master Browser), and entirely dependant on NetBIOS / Broadcast.

Admittedly I dislike network browsing and was quite happy to see the
back of it (and NT domains), and therefore I'm quite happy to be proved
incorrect :)

Anyway, I do believe WINS is the right approach. I would also advise you
monitor which systems are being elected as Master Browser for each
subnet (Broadcast Domain), unless you're relaying Broadcast over your
routers / firewalls.

The Domain Master Browser (preferentially the PDC Emulator iirc) is
tasked with compiling the separate lists and presenting the complete
list to clients. DNS can't help with any of that, WINS itself only helps
Master Browsers find each other.

I believe NetBIOS-based Network Browsing is only available for legacy
support. It hasn't had a change of any significance for the last 10 to
15 years.

I don't want to skew the issue. a 'www' entry would *NEVER* be an entry
I would put in WINS. That is a hostname record that should only exist
in DNS for website URL access based on hostheader multisite web
hosting. It has nothign to do with the computer name. WINS is for the
NetBIOS name, or the 'computername.' Of course, you can have additional
DNS host names for a resource (conmputer, etc), and if using 'www' it's
assumed to be a hostheader and NOT a computer name.

AD support for browsing using DirectSMS (port 445) actually does work,
but if you ask me, it's flaky, and doesn't work for VPN clients. Also,
I'm also not sure if it supports legacy LanMan clients since they
specifically look for a NetBIOS name across port 139. Therefore, WINS
has always worked nicely for me!

I just want to make sure I'm not talking cross-purposes.

When I say browsing I mean looking at the list of computers under
Network Places, not browsing the shares on a single system. The latter
will use SMB over TCP on TCP Port 445 if NetBIOS is disabled.

The last few networks I've run have had NetBIOS disabled entirely, as a
direct result "My Network Places" is empty and all connections to shares
use SMB over TCP.

This is really sharing my experiences, I agree with your assertion that
WINS should be in place for browsing. If anything I'd like to lend
support to that, it is essential if network browsing is required on a
multi-subnet network.

Yes, you are correct. They actually refer to it as DirectSMB, but same
thing. The neighborhood list (Network Places), is NetBIOS based. Hence why I
like WINS. However, I did see one installation where it actually populated
cross-subnet without WINS. AD is supposed to support this using SMB, however
I've found it flaky, at best. There's nothing specific on how to support or
troubleshoot it that I've found, other than those links in my blog. However,
there are many articles on the Browser service.

Another stunning feature then ;)

Ah well, soon we'll all be running IPv6, right? :)

As a follow-up to my original post. I just want to let everyone know
that WINS resolved the browse issue. Thanks to ACE and other
contributors of this thread for their time and knowledge.