Browsing Subnets

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

We have two subnets at our location. Win2K AD, two DC's, one with DNS. (we
have another site with DNS, DC's, etc across a T-1).

We are suddenly experiencing a situation where a computer on one subnet
cannot browse to shared resources on the other subnet via UNC ie;
\\machine1\share will no longer appear. I suspect a DNS problem but not sure
how to check this. It all worked fine in the past.

As a work around, I've had to scramble to update some hosts files while I
resolve this. A bit of help, please? :)

Thanks,

Sheldon
 
nesdog said:
We have two subnets at our location. Win2K AD, two DC's, one with DNS. (we
have another site with DNS, DC's, etc across a T-1).

Not related to your problem, but both DCs should run DNS
or you really don't have full fault tolerance. (It costs almost
nothing in both setup and network traffic.)
We are suddenly experiencing a situation where a computer on one subnet
cannot browse to shared resources on the other subnet via UNC ie;
\\machine1\share will no longer appear. I suspect a DNS problem but not
sure
how to check this. It all worked fine in the past.

Generally BROWSING is a NETBIOS issue to focus your
troubleshooting on NetBIOS (broadcasts and WINS server).

Since broadcasts don't work across subnets (i.e. across routers)
you have a practical need for WINS server(s).

In that case (using WINS Server) EVERY COMPUTER (client or
server) must be set as a WINS client -- this includes DCs and even
WINS servers themselves.
As a work around, I've had to scramble to update some hosts files while I
resolve this. A bit of help, please? :)

That would not fix a BROWSING problem -- you would need the
more complicated LMHOSTS file for browsing -- so perhaps you
have misstated your problem....

Name resolution can take place by either DNS or NetBIOS methods
most of the time, but Browsing PER SE is a NetBIOS application.

(BTW: If you have more than one WINS server they need to be
replicated.)

Post your "IPconfig /all" from both a "missing server" and an "affected
client". Send command output to a text file and post unedited as TEXT,
not graphics.
 
Hi Herb,

As it happens, we have two DC's on our site, with one providing AD
integrated DNS. Another server at the 2nd site also provides the DNS. We set
up both addresses in our DHCP scope, first ours then the remote one.

WINS? That would be moving backwards, would it not? It seems to me that DNS
should be able to offer up the name resolution for this. It actually was
working okay before so I thought perhaps something got zapped out of the DNS
database. The machines are not browsing via Network Neighborhood; rather we
could open Start, Run, \\machine name\share. Adding the entry into the hosts
files solved this issue temporarily and is manageable as we are small but are
kind of a pain to get to everyone.

Anyway, any other ideas?

Thanks for your help.

Sheldon

Herb Martin said:
nesdog said:
We have two subnets at our location. Win2K AD, two DC's, one with DNS. (we
have another site with DNS, DC's, etc across a T-1).

Not related to your problem, but both DCs should run DNS
or you really don't have full fault tolerance. (It costs almost
nothing in both setup and network traffic.)
We are suddenly experiencing a situation where a computer on one subnet
cannot browse to shared resources on the other subnet via UNC ie;
\\machine1\share will no longer appear. I suspect a DNS problem but not
sure
how to check this. It all worked fine in the past.

Generally BROWSING is a NETBIOS issue to focus your
troubleshooting on NetBIOS (broadcasts and WINS server).

Since broadcasts don't work across subnets (i.e. across routers)
you have a practical need for WINS server(s).

In that case (using WINS Server) EVERY COMPUTER (client or
server) must be set as a WINS client -- this includes DCs and even
WINS servers themselves.
As a work around, I've had to scramble to update some hosts files while I
resolve this. A bit of help, please? :)

That would not fix a BROWSING problem -- you would need the
more complicated LMHOSTS file for browsing -- so perhaps you
have misstated your problem....

Name resolution can take place by either DNS or NetBIOS methods
most of the time, but Browsing PER SE is a NetBIOS application.

(BTW: If you have more than one WINS server they need to be
replicated.)

Post your "IPconfig /all" from both a "missing server" and an "affected
client". Send command output to a text file and post unedited as TEXT,
not graphics.

--
Herb Martin, MCSE, MVP
Accelerated MCSE
http://www.LearnQuick.Com
[phone number on web site]
 
nesdog said:
Hi Herb,

As it happens, we have two DC's on our site, with one providing AD
integrated DNS. Another server at the 2nd site also provides the DNS. We
set
up both addresses in our DHCP scope, first ours then the remote one.

That is a better setup than you original (incorrect) report.

Also you might wish to set ALL DCs to be "GCs" - this is
much better for single domains and many SMALL multi-domain
forests.
WINS? That would be moving backwards, would it not?

No because you wish Browsing to work and browsing (as
well as some other stuff) is still a NetBIOS legacy application.
It seems to me that DNS
should be able to offer up the name resolution for this.

Name resolution possibly (although inefficiently for NetBIOS names)
but not the actual BROWSING.

The "Master Browsers" use NetBIOS, and to find each other across
routers (where broadcasts will not work) they need to all be registered
with the same WINS "database" (i.e., same server or a replicated set
of WINS servers.)
It actually was
working okay before so I thought perhaps something got zapped out of the
DNS
database.

If you cannot BROWSE you have a NetBIOS problem.

If you cannot RESOLVE names to IP addresses you may have
either (or both) a WINS or DNS resolution problem.

You cannot expect browsing to work across multiple subnets
unless you install and set EVERY computer to use the WINS
server(s.)
The machines are not browsing via Network Neighborhood; rather we
could open Start, Run, \\machine name\share.

That is not "browsing" but mere name resolution and will
work without WINS or NetBIOS if you DNS is setup correctly.
Adding the entry into the hosts
files solved this issue temporarily and is manageable as we are small but
are
kind of a pain to get to everyone.

That explains your misreport in the original post (and subject) since
you don't actually have a "Browsing" problem.
Anyway, any other ideas?

Yes: The one from my original answer:

Post your "IPconfig /all" from both a "missing server" and an "affected
client". Send command output to a text file and post unedited as TEXT,
not graphics.



--
Herb Martin, MCSE, MVP
Accelerated MCSE
http://www.LearnQuick.Com
[phone number on web site]
Thanks for your help.

Sheldon

Herb Martin said:
nesdog said:
We have two subnets at our location. Win2K AD, two DC's, one with DNS.
(we
have another site with DNS, DC's, etc across a T-1).

Not related to your problem, but both DCs should run DNS
or you really don't have full fault tolerance. (It costs almost
nothing in both setup and network traffic.)
We are suddenly experiencing a situation where a computer on one subnet
cannot browse to shared resources on the other subnet via UNC ie;
\\machine1\share will no longer appear. I suspect a DNS problem but
not
sure
how to check this. It all worked fine in the past.

Generally BROWSING is a NETBIOS issue to focus your
troubleshooting on NetBIOS (broadcasts and WINS server).

Since broadcasts don't work across subnets (i.e. across routers)
you have a practical need for WINS server(s).

In that case (using WINS Server) EVERY COMPUTER (client or
server) must be set as a WINS client -- this includes DCs and even
WINS servers themselves.
As a work around, I've had to scramble to update some hosts files while
I
resolve this. A bit of help, please? :)

That would not fix a BROWSING problem -- you would need the
more complicated LMHOSTS file for browsing -- so perhaps you
have misstated your problem....

Name resolution can take place by either DNS or NetBIOS methods
most of the time, but Browsing PER SE is a NetBIOS application.

(BTW: If you have more than one WINS server they need to be
replicated.)

Post your "IPconfig /all" from both a "missing server" and an "affected
client". Send command output to a text file and post unedited as TEXT,
not graphics.

--
Herb Martin, MCSE, MVP
Accelerated MCSE
http://www.LearnQuick.Com
[phone number on web site]
 
And test name resolution with nslookup from a non-working client.

....kurt

nesdog said:
Hi Herb,

As it happens, we have two DC's on our site, with one providing AD
integrated DNS. Another server at the 2nd site also provides the DNS. We
set
up both addresses in our DHCP scope, first ours then the remote one.

WINS? That would be moving backwards, would it not? It seems to me that
DNS
should be able to offer up the name resolution for this. It actually was
working okay before so I thought perhaps something got zapped out of the
DNS
database. The machines are not browsing via Network Neighborhood; rather
we
could open Start, Run, \\machine name\share. Adding the entry into the
hosts
files solved this issue temporarily and is manageable as we are small but
are
kind of a pain to get to everyone.

Anyway, any other ideas?

Thanks for your help.

Sheldon

Herb Martin said:
nesdog said:
We have two subnets at our location. Win2K AD, two DC's, one with DNS.
(we
have another site with DNS, DC's, etc across a T-1).

Not related to your problem, but both DCs should run DNS
or you really don't have full fault tolerance. (It costs almost
nothing in both setup and network traffic.)
We are suddenly experiencing a situation where a computer on one subnet
cannot browse to shared resources on the other subnet via UNC ie;
\\machine1\share will no longer appear. I suspect a DNS problem but
not
sure
how to check this. It all worked fine in the past.

Generally BROWSING is a NETBIOS issue to focus your
troubleshooting on NetBIOS (broadcasts and WINS server).

Since broadcasts don't work across subnets (i.e. across routers)
you have a practical need for WINS server(s).

In that case (using WINS Server) EVERY COMPUTER (client or
server) must be set as a WINS client -- this includes DCs and even
WINS servers themselves.
As a work around, I've had to scramble to update some hosts files while
I
resolve this. A bit of help, please? :)

That would not fix a BROWSING problem -- you would need the
more complicated LMHOSTS file for browsing -- so perhaps you
have misstated your problem....

Name resolution can take place by either DNS or NetBIOS methods
most of the time, but Browsing PER SE is a NetBIOS application.

(BTW: If you have more than one WINS server they need to be
replicated.)

Post your "IPconfig /all" from both a "missing server" and an "affected
client". Send command output to a text file and post unedited as TEXT,
not graphics.

--
Herb Martin, MCSE, MVP
Accelerated MCSE
http://www.LearnQuick.Com
[phone number on web site]
 
Thanks for the info. Sorry if I posted it incorrectly.. I knew what I meant
to say!

Sheldon

Herb Martin said:
nesdog said:
Hi Herb,

As it happens, we have two DC's on our site, with one providing AD
integrated DNS. Another server at the 2nd site also provides the DNS. We
set
up both addresses in our DHCP scope, first ours then the remote one.

That is a better setup than you original (incorrect) report.

Also you might wish to set ALL DCs to be "GCs" - this is
much better for single domains and many SMALL multi-domain
forests.
WINS? That would be moving backwards, would it not?

No because you wish Browsing to work and browsing (as
well as some other stuff) is still a NetBIOS legacy application.
It seems to me that DNS
should be able to offer up the name resolution for this.

Name resolution possibly (although inefficiently for NetBIOS names)
but not the actual BROWSING.

The "Master Browsers" use NetBIOS, and to find each other across
routers (where broadcasts will not work) they need to all be registered
with the same WINS "database" (i.e., same server or a replicated set
of WINS servers.)
It actually was
working okay before so I thought perhaps something got zapped out of the
DNS
database.

If you cannot BROWSE you have a NetBIOS problem.

If you cannot RESOLVE names to IP addresses you may have
either (or both) a WINS or DNS resolution problem.

You cannot expect browsing to work across multiple subnets
unless you install and set EVERY computer to use the WINS
server(s.)
The machines are not browsing via Network Neighborhood; rather we
could open Start, Run, \\machine name\share.

That is not "browsing" but mere name resolution and will
work without WINS or NetBIOS if you DNS is setup correctly.
Adding the entry into the hosts
files solved this issue temporarily and is manageable as we are small but
are
kind of a pain to get to everyone.

That explains your misreport in the original post (and subject) since
you don't actually have a "Browsing" problem.
Anyway, any other ideas?

Yes: The one from my original answer:

Post your "IPconfig /all" from both a "missing server" and an "affected
client". Send command output to a text file and post unedited as TEXT,
not graphics.



--
Herb Martin, MCSE, MVP
Accelerated MCSE
http://www.LearnQuick.Com
[phone number on web site]
Thanks for your help.

Sheldon

Herb Martin said:
We have two subnets at our location. Win2K AD, two DC's, one with DNS.
(we
have another site with DNS, DC's, etc across a T-1).

Not related to your problem, but both DCs should run DNS
or you really don't have full fault tolerance. (It costs almost
nothing in both setup and network traffic.)

We are suddenly experiencing a situation where a computer on one subnet
cannot browse to shared resources on the other subnet via UNC ie;
\\machine1\share will no longer appear. I suspect a DNS problem but
not
sure
how to check this. It all worked fine in the past.

Generally BROWSING is a NETBIOS issue to focus your
troubleshooting on NetBIOS (broadcasts and WINS server).

Since broadcasts don't work across subnets (i.e. across routers)
you have a practical need for WINS server(s).

In that case (using WINS Server) EVERY COMPUTER (client or
server) must be set as a WINS client -- this includes DCs and even
WINS servers themselves.

As a work around, I've had to scramble to update some hosts files while
I
resolve this. A bit of help, please? :)

That would not fix a BROWSING problem -- you would need the
more complicated LMHOSTS file for browsing -- so perhaps you
have misstated your problem....

Name resolution can take place by either DNS or NetBIOS methods
most of the time, but Browsing PER SE is a NetBIOS application.

(BTW: If you have more than one WINS server they need to be
replicated.)

Post your "IPconfig /all" from both a "missing server" and an "affected
client". Send command output to a text file and post unedited as TEXT,
not graphics.

--
Herb Martin, MCSE, MVP
Accelerated MCSE
http://www.LearnQuick.Com
[phone number on web site]
 
nesdog said:
Thanks for the info. Sorry if I posted it incorrectly.. I knew what I
meant
to say!

You're welcome.

Is it now fixed?

Mostly by posting the wrong details you incovenienced yourself
<grin>, and ALSO were able to learn more than just the answer
to the problem.

--
Herb Martin, MCSE, MVP
Accelerated MCSE
http://www.LearnQuick.Com
[phone number on web site]
Sheldon

Herb Martin said:
nesdog said:
Hi Herb,

As it happens, we have two DC's on our site, with one providing AD
integrated DNS. Another server at the 2nd site also provides the DNS.
We
set
up both addresses in our DHCP scope, first ours then the remote one.

That is a better setup than you original (incorrect) report.

Also you might wish to set ALL DCs to be "GCs" - this is
much better for single domains and many SMALL multi-domain
forests.
WINS? That would be moving backwards, would it not?

No because you wish Browsing to work and browsing (as
well as some other stuff) is still a NetBIOS legacy application.
It seems to me that DNS
should be able to offer up the name resolution for this.

Name resolution possibly (although inefficiently for NetBIOS names)
but not the actual BROWSING.

The "Master Browsers" use NetBIOS, and to find each other across
routers (where broadcasts will not work) they need to all be registered
with the same WINS "database" (i.e., same server or a replicated set
of WINS servers.)
It actually was
working okay before so I thought perhaps something got zapped out of
the
DNS
database.

If you cannot BROWSE you have a NetBIOS problem.

If you cannot RESOLVE names to IP addresses you may have
either (or both) a WINS or DNS resolution problem.

You cannot expect browsing to work across multiple subnets
unless you install and set EVERY computer to use the WINS
server(s.)
The machines are not browsing via Network Neighborhood; rather we
could open Start, Run, \\machine name\share.

That is not "browsing" but mere name resolution and will
work without WINS or NetBIOS if you DNS is setup correctly.
Adding the entry into the hosts
files solved this issue temporarily and is manageable as we are small
but
are
kind of a pain to get to everyone.

That explains your misreport in the original post (and subject) since
you don't actually have a "Browsing" problem.
Anyway, any other ideas?

Yes: The one from my original answer:

Post your "IPconfig /all" from both a "missing server" and an "affected
client". Send command output to a text file and post unedited as TEXT,
not graphics.



--
Herb Martin, MCSE, MVP
Accelerated MCSE
http://www.LearnQuick.Com
[phone number on web site]
Thanks for your help.

Sheldon

:

We have two subnets at our location. Win2K AD, two DC's, one with
DNS.
(we
have another site with DNS, DC's, etc across a T-1).

Not related to your problem, but both DCs should run DNS
or you really don't have full fault tolerance. (It costs almost
nothing in both setup and network traffic.)

We are suddenly experiencing a situation where a computer on one
subnet
cannot browse to shared resources on the other subnet via UNC ie;
\\machine1\share will no longer appear. I suspect a DNS problem but
not
sure
how to check this. It all worked fine in the past.

Generally BROWSING is a NETBIOS issue to focus your
troubleshooting on NetBIOS (broadcasts and WINS server).

Since broadcasts don't work across subnets (i.e. across routers)
you have a practical need for WINS server(s).

In that case (using WINS Server) EVERY COMPUTER (client or
server) must be set as a WINS client -- this includes DCs and even
WINS servers themselves.

As a work around, I've had to scramble to update some hosts files
while
I
resolve this. A bit of help, please? :)

That would not fix a BROWSING problem -- you would need the
more complicated LMHOSTS file for browsing -- so perhaps you
have misstated your problem....

Name resolution can take place by either DNS or NetBIOS methods
most of the time, but Browsing PER SE is a NetBIOS application.

(BTW: If you have more than one WINS server they need to be
replicated.)

Post your "IPconfig /all" from both a "missing server" and an
"affected
client". Send command output to a text file and post unedited as
TEXT,
not graphics.

--
Herb Martin, MCSE, MVP
Accelerated MCSE
http://www.LearnQuick.Com
[phone number on web site]
 
Back
Top