DNS Trust Logon Issues
2010
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 .
Marcin
features were implemented as their primary DNS servers...
Add dns suffixes for domains on the other side of the trust to members of
the local forest...
hth
Marcin
"2010" <20...@discussions.microsoft.com> wrote in message
news:0D77D0A4-B6F8-4E3E...@microsoft.com...
Ace Fekay [MCT]
news:0D77D0A4-B6F8-4E3E...@microsoft.com...
>
>
I replied to this same exact post in the General newsgroup. For future
posts, if you feel the post needs to be in multiple newsgroups, please
"cross-post" and not "multi-post." It helps you and us. Crossposting allows
the one post to populate multiple groups simultaneously and any responses to
any one of them, will automatically populate all groups it was posted to.
This way all you have to do is check one of them. Same with us. We can see
what others have responded to that allows us a better chance to work
together to assist you and not duplicate efforts.
I realize you've posted using the web version. I realize it is difficult to
crosspost using that method. If I may suggest, you can use a newsreader to
access the newsgroups, such as Outlook Express (XP and older), or Windows
Mail (Vista and newer). Access is free, and easier to keep track and watch
your threads.
FYI for others responding:
Newsgroups: microsoft.public.windows.server.general
From: =<20...@discussions.microsoft.com>
Subject: no logon servers available when connecting to most servers in trus
Date: Fri, 16 Oct 2009 11:16:02 -0700
Ace
2010
trust? There are new domain controllers here but the trust was not setup on
those specifically. The trust was setup on different domain controllers
whcih are now the backups.
"Marcin" wrote:
> .
>
Ace Fekay [MCT]
"2010" <20...@discussions.microsoft.com> wrote in message
news:0D77D0A4-B6F8-4E3E...@microsoft.com...
>
>
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