Cross-site browsing issue

[Jim Hatfield]

We have an old two-site (US and UK) NT domain setup. The sites are
joined by a Lan-to-Lan VPN. There are two NT domains, each based
primarily in one site, but with a BDC in the "other" site.

Browsing works as expected, you can see all machines in each domain,
irrespective of site.

Now we merge with a Swedish company using AD and I decide to use
their AD for the whole organisation. I build a VPN to join the
Sweden Lan to the other two, and set up an AD DC in the UK. I set
up full two-way trust relationships. I move a couple of machines
in the UK into the AD domain. All works fine.

All except browsing that is. From a machine in the UK I can see
all machines in the old NT domains but in the AD domain I can only
see the machines in the UK, none of those in Sweden. The reverse
if I RDC to a machine in Sweden and browse from there. There
are no obvious errors in the Event Logs of any of the DCs.

Shouldn't cross-site browsing "just work"?

 

[Herb Martin]

It's almost always a WINS Server issue:

1) Lack of a WINS server

2) All machines NEED to be "WINS clients"
(this includes especially all servers, DCs and even the
` WINS server itself.)

3) Failure to replicate the WINS database --
with more than one WINS server they must be replicated

The first is likely at the remote site (new Swedish company).

The second is common when only a subset of servers are "missing";

the latter is quite common when two companies are involved if
each has it's own WINS server (set) and they have not been manually
configured to replicate.

 

[Jim Hatfield]

It's almost always a WINS Server issue:

1) Lack of a WINS server

2) All machines NEED to be "WINS clients"
(this includes especially all servers, DCs and even the
` WINS server itself.)

3) Failure to replicate the WINS database --
with more than one WINS server they must be replicated

The first is likely at the remote site (new Swedish company).

The second is common when only a subset of servers are "missing";

I thought WINS wasn't required with AD....

However both DCs are WINS servers, both point their WINS client
to themselves, and they are now configured to replicate. Sadly
it makes not a blind bit of difference. The DCs (and a client
machine) can browse everything in the old NT4 domains but only
local machines in the AD domain.

I see one difference. The AD domain name is "internal.local". On
the new DC in the UK if I do a "net view /domain:internal", I see
the list of local machines, same as if I just do a "net view". On
the old DC in Sweden, doing a "net view /domain:internal" gets me
an error 6118 "The list of servers for this workgroup is not
currently available". So *something* is not right there...

If only Windows browsing wasn't so obscure and difficult to debug...

 

[Jim Hatfield]

I see one difference. The AD domain name is "internal.local". On
the new DC in the UK if I do a "net view /domain:internal", I see
the list of local machines, same as if I just do a "net view". On
the old DC in Sweden, doing a "net view /domain:internal" gets me
an error 6118 "The list of servers for this workgroup is not
currently available". So *something* is not right there...

The more I look, the more problems creep out of the woodwork.

- if I run Domain Monitor on the NT4 PDCs, the status of the
AD domain is listed as "domain controller not found". I have
lmhosts entries to help netbios resolution but it doesn't
seem to help.

- the instructions for ADMT says to add each domain's Domain Admins
global group to the other's Administrator's local group. However
if I go into User Manager on the NT4 domains, open up Administrators
and then select the AD domain from the dropdown, the list of
names goes grey and is replaced by the message "Unable to browse
the selected domain because the following error occurred: there
are currently no logon servers available to service the logon
request.

- there are lots of errors from NETLOGON in the event log of the
NT4 PDCs like: No Windows NT Domain Controller is available
for domain INTERNAL. This event is expected and can be ignored
when booting with the "No Net" hardware profile.

- just doing a "net view" on the original AD DC now gets me an
System Error 6881.

jim

 

[Herb Martin]

I thought WINS wasn't required with AD....

It's a VERY common misconception -- due to a LOT of bad information
out there.

If you needed WINS under NT-4 it is a VERY safe bet you need it under
AD.

However both DCs are WINS servers, both point their WINS client
to themselves, and they are now configured to replicate. Sadly
it makes not a blind bit of difference. The DCs (and a client
machine) can browse everything in the old NT4 domains but only
local machines in the AD domain.

All machines, not just clients OR DCs, have to be WINS clients for
browsing to work fully.

Check the WINS database (MMC) and use BrowStat.exe to troubleshoot
that your browsers are available...

I see one difference. The AD domain name is "internal.local". On
the new DC in the UK if I do a "net view /domain:internal", I see
the list of local machines, same as if I just do a "net view". On
the old DC in Sweden, doing a "net view /domain:internal" gets me
an error 6118 "The list of servers for this workgroup is not
currently available". So *something* is not right there...

If only Windows browsing wasn't so obscure and difficult to debug...

It's actually fairly easy but TERRIBLY explained and poorly understood
by most people.

I only know about 5-10 rules but those solve almost every browsing
problem.

Also make sure you have a browsing problem which is almost entirely
divorced from either of "connectivity" (ping by number) and some what
separate from Name resolution "name to IP."

Oddly enough, it requires WINS to browse across subnets and across
domains, yet DNS may be the name resolution used to resolve the name
to an IP.

The reason: Master Browsers and the Domain Master Browser of each
domain use WINS as a "locator service" or "rendezvous service."

And remember ANY Windows machine MAY become Master Browser
of it's subnet (depending on "rank".)

 

[Herb Martin]

I see one difference. The AD domain name is "internal.local". On

The more I look, the more problems creep out of the woodwork.

- if I run Domain Monitor on the NT4 PDCs, the status of the
AD domain is listed as "domain controller not found". I have
lmhosts entries to help netbios resolution but it doesn't
seem to help.

The PDC Emulator must be online for cross-domain browsing to
work. Only the Domain Master Browsers (PDC) exchange full
domain lists .

On the AD side, run DCDiag on every DC (good to do anyway.)
Fix or report problems. (See below, I will add my DNS checklist
but much of that is focused on straightening out DCs.)

- the instructions for ADMT says to add each domain's Domain Admins
global group to the other's Administrator's local group. However
if I go into User Manager on the NT4 domains, open up Administrators
and then select the AD domain from the dropdown, the list of
names goes grey and is replaced by the message "Unable to browse
the selected domain because the following error occurred: there
are currently no logon servers available to service the logon
request.

External Trusts SEEM to be working but they are also depending on
NetBIOS (and maybe WINS) so this is not too suprising.

- there are lots of errors from NETLOGON in the event log of the
NT4 PDCs like: No Windows NT Domain Controller is available
for domain INTERNAL. This event is expected and can be ignored
when booting with the "No Net" hardware profile.

Consistent with not finding the PDC EMulator or maybe ANY DC,
of the AD domain. This also seems to point at WINS.

- just doing a "net view" on the original AD DC now gets me an
System Error 6881.

 

[Jim Hatfield]

All except browsing that is. From a machine in the UK I can see
all machines in the old NT domains but in the AD domain I can only
see the machines in the UK, none of those in Sweden. The reverse
if I RDC to a machine in Sweden and browse from there. There
are no obvious errors in the Event Logs of any of the DCs.

I think I might have found something. In the WINS database I
see the Domain Master Browser for the domain is set to
192.168.0.210 - but that is not the address bound to the network
card. It is a second address which seems to have something
to do with RRAS.

Is there a way I can force the Domain Master Browser entry to
a particular address on a multi-homed machine?

 

[Jim Hatfield]

I think I might have found something. In the WINS database I
see the Domain Master Browser for the domain is set to
192.168.0.210 - but that is not the address bound to the network
card. It is a second address which seems to have something
to do with RRAS.

Further to this, if I reboot the machine, everything suddenly
works fine. Both machines can browse all machines in both
sites, and the "nbtstat -n" shows up no errors at all. Interestingly,
"nbtstat -n" on the machine which has the RRAS server ONLY shows
the Ethernet card address.

Then as soon as someone makes a PPTP connection it all goes
pear-shaped again. Cross-site browsing fails and nbtstat -n
returns the name of the machine in the conflict state.

So it is becoming increasingly likely that RRAS is the issue.

 

[Herb Martin]

So it is becoming increasingly likely that RRAS is the issue.

I would carefully check the subnetting.

It appeared you have two network interfaces, with NetBIOS enabled,
on the same SUBNET (or broadcast domain.)

I cannot be sure since you didn't show the subnet masks.

You might post your IPConfig /all from the affected (DC) machine.

 

[Jim Hatfield]

I would carefully check the subnetting.

It appeared you have two network interfaces, with NetBIOS enabled,
on the same SUBNET (or broadcast domain.)

I believe not because the subnet mask of the RAS adaptor is
255.255.255.255.

I cannot be sure since you didn't show the subnet masks.

You might post your IPConfig /all from the affected (DC) machine.
Sure:

C:\Documents and Settings\Administrator>ipconfig /all

Windows 2000 IP Configuration

Host Name . . . . . . . . . . . . : server3
Primary DNS Suffix . . . . . . . : INTERNAL.local
Node Type . . . . . . . . . . . . : Hybrid
IP Routing Enabled. . . . . . . . : Yes
WINS Proxy Enabled. . . . . . . . : No
DNS Suffix Search List. . . . . . : INTERNAL.local

Ethernet adapter Local Area Connection:

Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Intel(R) PRO/100+ Server Adapter (PI
LA8470B)
Physical Address. . . . . . . . . : 00-02-B3-02-89-F7
DHCP Enabled. . . . . . . . . . . : No
IP Address. . . . . . . . . . . . : 192.168.0.101
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.0.1
DNS Servers . . . . . . . . . . . : 192.168.0.101
192.168.0.1
Primary WINS Server . . . . . . . : 192.168.0.101

PPP adapter RAS Server (Dial In) Interface:

Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : WAN (PPP/SLIP) Interface
Physical Address. . . . . . . . . : 00-53-45-00-00-00
DHCP Enabled. . . . . . . . . . . : No
IP Address. . . . . . . . . . . . : 192.168.0.210
Subnet Mask . . . . . . . . . . . : 255.255.255.255
Default Gateway . . . . . . . . . :
DNS Servers . . . . . . . . . . . : 127.0.0.1

It's interesting that between the time the machine is rebooted
and the time that someone makes an incoming PPTP connection,
all is OK. As soon as the PPTP connection is made, the machine
can no longer browse.

 

[Herb Martin]

I believe not because the subnet mask of the RAS adaptor is
255.255.255.255.

Alone that proves nothing -- it might even be wrong depending
on where it appears.

Right here may be part of the problem -- certainly if you
have a routing issue.

Why is the main NIC set to itself as a Default Gateway?

Such settings will prevent the machine (and the routers
on the machine in RRAS) from routing to any NIC (or
RRAS interface) NOT directly connected.

This looks wrong too, but I cannot remember if there is a cosmetic
bug that shows this in dynamic interfaces.

Were this really being used you could not reach any other stations
on that interface. But I believe this is a cosmetic interface but that
I have seen below.

Why is there no DNS server set on the main NIC?

And it really should be the IP since it will give this value to
the RRAS clients (and 127.0.0.1 will NOT make sense for them
-- that would refer to themselves.)

It's interesting that between the time the machine is rebooted
and the time that someone makes an incoming PPTP connection,
all is OK. As soon as the PPTP connection is made, the machine
can no longer browse.

Do you have WINS servers or not? If so, this machine should be
a WINS client.

What happens when you do "Net View /domainOMAIN_NAME"
(before and after the connection.)

 

[Jim Hatfield]

Why is the main NIC set to itself as a Default Gateway?

It is not. The main NIC is 192.168.0.101 and the gateway
is 192.168.0.1, a multihomed Linux box.

Why is there no DNS server set on the main NIC?

This isn't the main NIC, it's something to do with RRAS.

Do you have WINS servers or not? If so, this machine should be
a WINS client.

The machine is itself a WINS server.

What happens when you do "Net View /domainOMAIN_NAME"
(before and after the connection.)

After, ie now, I get a long pause then:

C:\Documents and Settings\Administrator>net view /domain:INTERNAL
System error 6118 has occurred.

The list of servers for this workgroup is not currently available

To do the "before" I will have to wait for a quiet period when
nobody is using the PPTP server, and reboot the machine. I'm
slightly nervous about this because it's in Sweden and I'm not

Jim

 

[Herb Martin]

It is not. The main NIC is 192.168.0.101 and the gateway
is 192.168.0.1, a multihomed Linux box.

Sorry, I must have misread this as IP .1 also.

This isn't the main NIC, it's something to do with RRAS.


The machine is itself a WINS server.

Then it should be a WINS client (usually of itself.)

Browsing is dependent on WINS. WINS Server is dependent on
"servers" being WINS clients so they may add themselves to the
WINS database.

RRAS servers 'give' their OWN WINS client setting to their RRAS
clients.

After, ie now, I get a long pause then:

Check any firewalls, including the SP2 type firewalls; this KB article
offers
specific ideas on this error (but it may not be your problem):

Internet firewalls can prevent browsing and file sharing
http://support.microsoft.com/default.aspx?scid=kb;en-us;q298804

This Google search gives the the other instances of this issue besides
the single mention (above) that is at Microsoft:

[ "System error 6118" microsoft: ]

To do the "before" I will have to wait for a quiet period when
nobody is using the PPTP server, and reboot the machine. I'm
slightly nervous about this because it's in Sweden and I'm not

Yes, that is always a little goosy. I suggest you have them install
a "phone activated power switch" (might be found under some other
name.)

Then if you get locked out on a reboot hang you can at least do a
power off by dialing in. Not perfect since you may still not be able
to boot (in rare situations) but better than nothing.

 

[Jim Hatfield]

Then it should be a WINS client (usually of itself.)

Yep, it is a client of itself. Same with the new DC which I
installed here in the UK.

Check any firewalls, including the SP2 type firewalls; this KB article
offers
specific ideas on this error (but it may not be your problem):

I have set up the three LAN's with Lan-to-Lan VPN connections and have
made sure that there are no packet filters blocking any inter-Lan
traffic.

I think this is the only realistic option. If it proves my
suspicion that the RRAS service is causing the problem then I
will just have to find another machine to run it on.

I might play around with disabling the RRAS service for short
periods when nobody is connected to see if that does anything.

Jim