"2010" <> wrote in message
news:0D77D0A4-B6F8-4E3E-9D0D-...
>
>
> I have a two way forest trust. I can browse files on external trusted
> domain controller(server A) but when I go to browse files on a external
> trusted member server(server B) I get a "no logon servers available" error
> .
> On internal domain pc when I do a nslookup by hostname to server A it
> fails
> when I nslookup and include suffix it is successful. Same with server B.
> I
> can ping both servers by hostname. I am using secondary zones to transfer
> records between trusts. I think DNS is not resolving by hostname for some
> reason and unless it is handed off to WINS it is failing. WINS also has a
> wrong IP listed from server from a multihomed NIC .
Just as an FYI, a multihomed DC, especially with WINS and DNS on it, or RRAS
on a DC, problematic. The suggested recommendation by all engineers is to
not multihome a DC. There are tricks to *force* a mulithomed DC to properly
function, but I don't recommend the changes unless the DC absolutely must
have two NICs. For the most part, I have not yet found nor have been
convinced with a good reason the past 9 years, to multihome a DC. However,
if you feel the DC needs to remain multihomed, please read the following for
more info on why it causes problems, as well as a step by step procedure to
make it work.
As for browsing on a member server in a trusted domain, have the necessary
permissions been applied on the member server to allow your account to
access the server? Normally in a trusted scenario, the idea is to add the
Domain Administrators group of DomainA to DomainB's Local Administrators
group, and vice-versa. Same with the Domain Users to the Domain Local Users
group.
Also, whether you use Secondary zones or Conditional Forwarding for the
trusted domain or forest, as Marcin said, you will need to add the other
domain's suffix to all machines on your side that will access resources at
the trusted domain. This will allow the client-side resolver service to
'devolve' each suffix when trying to resolve a name. For example, a machine
on domainA.com is trying to resolve a machine on domainB.com's domain called
'machineB', which makes the FQDN of that machine, machineB.domainB.com, and
the domainA machine does not have "domainB.com" set as a Search Suffix, the
client side resolver will not be able to resolve machineB.domainB.com under
the domainB.com beause the search suffix is not set to send that query,
irregardless if domainA's DNS has a that zone or a thousand other zones on
the machine. The search suffix tells the client to "try" that zone name as a
suffix to add to the host name you are trying to resolve.
Another suggestion is to setup WINS replication partners between the two
WINS servers on each side. This way a single name NetBIOS name query can be
resolved. In the above scenario, it would have resolved by WINS if a
replication partnerhip existed.
As for that member server, if their side has your search suffix, and WINS
partnership in place, I believe it would have worked without a problem.
Ace
|