I keep geting an error that has been confusing me for quite a while now. It seems that when my curric server talks to the admin server it throws up a netlogon error in the event log.
Here's what it says.
Code:This computer was not able to set up a secure session with a domain controller in domain admin11101 due to the following: There are currently no logon servers available to service the logon request. This may lead to authentication problems. Make sure that this computer is connected to the network. If the problem persists, please contact your domain administrator. ADDITTIONAL INFORMATION If this computer is a domain controller for the specified domain, it sets up the secure session to the primary domain controller emulator in the specified domain. Otherwise, this computer sets up the secure session th any domain controller in the specified domain. For more information, see help and support center at Http://go.microsoft.com/fwlink/events.asp.
I've tried looking at microsofts knowledge base but couldn't come up with any possible answers.
For reference, my curric server is 2003 standard, and my admin server is 2000 advanced server. Don't know if that has any bearing on this or not.
It looks like either a DNS issue or a trust issue.
Yeah, DNS would of been my second stab in the dark.
How would I go about checking the trust?
When you say DNS should the admin server have a record in the curric DNS?
I think they need more than a record in your case and that they should actually be replicating with each other. Not sure though without looking it up so of to google you go! On the trust side have you looked in the trusts console to see whats what? Failing that netdom is describing as the swiss army knife of trusts so check that out for testing stuff.
To check the trust:
This has to be done from the Curric domain and the case sensitivity is important!Code:netdom trust /d:Curric ADMIN /verify /twoway
How do you have DNS setup on the two domains? They need to be able to:
1. communicate if on separate LANs with some type of routing
2. communicate by name
If those two conditions are not met, you will get various interesting errors.
Geoff, I've looked at the DNS on my curric server, there is no record of the admin server in it.
My Admin server has the curric server listed as a name server but nothing else.
tried running netdom like this
But the result was the comand could not complete succesfuly.Code:netdom trust /d:norden2000 ADMIN11101 /verify /twoway
The way our network is setup is wierd, the admin domain is on the standard cleo ip range. 10.120.x.x but the curric domain is on a completely different ip range for some reason, 99.0.x.x don't know why and i've been here for a year, but the mess the network was in when I started was unbelievable.
There are 2 nic's in each DC, one connects to the external network using 10.x.x.x on each, the other conects to the curric domain using 99.0.x.x
It's a crazy setup and I don't know why we don't use the 10.x.x.x ip range, even the other technician doesn't know, and she's been here for about 5 or 6 years.
It's done like that for security. Its fairly meaningless though and I recommend you ignore it as a technique. I'd put your admin server on the same ip range. It saves a lot of hassle.
Once thats done. Make sure the server's can ping each other.
Then you need to sync up the DNS. You need to setup each DNS domain in a master/slave fashion. So for the admin dns domain the admin server is the master and the curric server is the slave. The reverse being true for the curric DNS domain.
Once that's synced up everything will just start working. Verify with the netdom tool.
Server location records are probably not accessible.Originally Posted by dezt
If Domain A Wants to Trust Domain B then domain A needs to be able to read the server location records for domain B as far as I understand it. For a two way trust, domain B would also need to know the location records for domain A.
Have you tried adding each others dns server as a forwarder for the specific domain name in dns?
You might also be able to add the other domains dns server as a secondary on the ad contollers setting up the trust
My servers can ping each other, I just need to setup the dns as master/slave fashion. I've made sure that the admin server is setup as a name server for the curric dns as well as the curric server. and vice versa.
Is that right so far?
You need to be able see the srv record for each domain. If you have setup forwarders for each of the other domains then you should be able to query both domains dns server and get the srv records from each (as in it will fetch the result itself and return it).
You have a client in test1.school. It requests the srv records for test2.school. It sends this request to the test1.school dns server. test1.school dns server sees it is a test2.school domain and uses the forwarder you have setup - the fowarder being the test2.school dns server. test2.school sends the srv record to test1.school dns server. test1.school sends this information back to the test1.school client. and vice-versa.Code:Domain A test1.school Domain B test2.school DNS for test1.school DNS test2.school Forwarder for test2.school domain Forwarder for test1.school domain
Ok, I think I have a major problem here, I looked at the MS article and followed the instructions for nslookup. The result it should have given me was different to the result it gave me.
Should be hostname.domainname internet=ip address.
I'm getting a bit worried nowCode:Server :UnKnown IP address :188.8.131.52 DNS request timed out timeout was 2 seconds *** request to UnKnown timed-out
It should be like this yes....
What are the event logs in DNS saying?Z:\>nslookup
Default Server: fmdc1.fishermore.lancs.sch.uk
Can you resolve host names through ping?
Run netdiag and dcdiag they can be very usefull.
Here's the 2 errors I keep getting in my DNS event log
andCode:The DNS server encountered a packet addressed to itself on IP address 184.108.40.206. The packet is for the DNS name "220.127.116.11.in-addr.arpa.". The packet will be discarded. This condition usually indicates a configuration error. Check the following areas for possible self-send configuration errors: 1) Forwarders list. (DNS servers should not forward to themselves). 2) Master lists of secondary zones. 3) Notify lists of primary zones. 4) Delegations of subzones. Must not contain NS record for this DNS server unless subzone is also on this server. 5) Root hints. Example of self-delegation: -> This DNS server dns1.example.microsoft.com is the primary for the zone example.microsoft.com. -> The example.microsoft.com zone contains a delegation of bar.example.microsoft.com to dns1.example.microsoft.com, (bar.example.microsoft.com NS dns1.example.microsoft.com) -> BUT the bar.example.microsoft.com zone is NOT on this server. Note, you should make this delegation check (with nslookup or DNS manager) both on this DNS server and on the server(s) you delegated the subzone to. It is possible that the delegation was done correctly, but that the primary DNS for the subzone, has any incorrect NS record pointing back at this server. If this incorrect NS record is cached at this server, then the self-send could result. If found, the subzone DNS server admin should remove the offending NS record. You can use the DNS server debug logging facility to track down the cause of this problem.
hope these are of use to you.Code:The DNS server has encountered numerous run-time events. To determine the initial cause of these run-time events, examine the DNS server event log entries that precede this event. To prevent the DNS server from filling the event log too quickly, subsequent events with Event IDs higher than 3000 will be suppressed until events are no longer being generated at a high rate.
There are currently 1 users browsing this thread. (0 members and 1 guests)