"nesdog" <nesdog@discussions.microsoft.com> wrote in message
news:F6A520FB-C741-4C43-8625-FE4A08B15C42@microsoft.com...
> 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 , 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]

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 .

Sheldon

"Herb Martin" wrote:

> "nesdog" <nesdog@discussions.microsoft.com> wrote in message
> news:F6A520FB-C741-4C43-8625-FE4A08B15C42@microsoft.com...
> > 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 , 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" <nesdog@discussions.microsoft.com> wrote in message
news:297C9649-9D63-4DCA-8148-6C14D58B263F@microsoft.com...
> 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 .
>
> Sheldon
>
> "Herb Martin" wrote:
>
>> "nesdog" <nesdog@discussions.microsoft.com> wrote in message
>> news:F6A520FB-C741-4C43-8625-FE4A08B15C42@microsoft.com...
>> > 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 , 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" <nesdog@discussions.microsoft.com> wrote in message
news:297C9649-9D63-4DCA-8148-6C14D58B263F@microsoft.com...
> 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 .
>
> Sheldon
>
> "Herb Martin" wrote:
>
>> "nesdog" <nesdog@discussions.microsoft.com> wrote in message
>> news:F6A520FB-C741-4C43-8625-FE4A08B15C42@microsoft.com...
>> > 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 , 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" wrote:

> "nesdog" <nesdog@discussions.microsoft.com> wrote in message
> news:297C9649-9D63-4DCA-8148-6C14D58B263F@microsoft.com...
> > 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 .
> >
> > Sheldon
> >
> > "Herb Martin" wrote:
> >
> >> "nesdog" <nesdog@discussions.microsoft.com> wrote in message
> >> news:F6A520FB-C741-4C43-8625-FE4A08B15C42@microsoft.com...
> >> > 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 , 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" <nesdog@discussions.microsoft.com> wrote in message
news:7B140104-4752-4647-88DE-043585532DB2@microsoft.com...
> 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" wrote:
>
>> "nesdog" <nesdog@discussions.microsoft.com> wrote in message
>> news:297C9649-9D63-4DCA-8148-6C14D58B263F@microsoft.com...
>> > 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 .
>> >
>> > Sheldon
>> >
>> > "Herb Martin" wrote:
>> >
>> >> "nesdog" <nesdog@discussions.microsoft.com> wrote in message
>> >> news:F6A520FB-C741-4C43-8625-FE4A08B15C42@microsoft.com...
>> >> > 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 , 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]
>> >>
>> >>
>> >>
>>
>>
>>