A Domain Controller for the Domain XXX Could Not be Contacted

Hi all,

I’m having issues adding one of my clients to a test domain that I have set up.
Error: A domain controller for the domain tilsed could not be contacted

Path used: Right click my comp etc etc.

Your have to bare with me on this one I am self teaching myself (which is probably not the best)

I have the following,

D link route containing a 4port switch.

Windows server 2003 R2

Win Xp prof

Background "“ I had a domain during my test setup with I have decided to reinstall windows server over the top and start again as I was not happy with some of it.

- Both machines have windows firewall disabled (router has firewall but this worked before)
- DHCP is not enabled on the server as the router takes care of this
- The computers are both wired to the router (the cables have not moved and the XP client was added to the domain before)
- Upnp is enabled on the router
- The server can pin the IP address of the workstation but not the host name
- The workstation can ping both the IP address and the host name
- Both machines can ping the servers IP
- Both machines can access the internet

I have a feeling this is a DNS issue?

Please please please provide some help if you have any ideas before I give up. Please also bare in mind im not the most tech savy and currently self teaching so don’t worry about sounding patronising.

Thanks in advance, please ask if you need any more information.

 

change the dns server for both the server and workstation to 192.168.1.4.

Since you are doing this via dhcp .. change the dhcp server information.

Also give your server a static ip, domain controlers should not be issued ips via dhcp ... i am sure it warned you about that when you ran dcpromo

 

That needs to be qualified.

If your server is doing the DNS resolution, then change the DNS on the server to 192.168.1.4. However your router is also doing DNS, so using it's DNS facilities is fine (when you start playing with Small Business Server that's a whole different animal, and I can explain if you need).

Second, serving DHCP on the router is absolutely fine, unless you plan on using VPN (even then, there are VPN routers in which case it's fine.. Again, a whole different kettle of fish).

The only thing that needs to be changed for it to actually work is:

a) give the server a static IP outside of the scope of the DHCP server on the router. and;

b) Point the DNS on your workstation to the fixed IP of the server. For the secondary DNS you should use 4.2.2.2 which points to Level 3's DNS.

 

Thanks guys this all worked smashingly!

 

NOOOO NEVER use external dns in a workstation or server's tcp-ip information!

Error1
no server in your enterprise should have external dns (epecialy domain controlers), this is done via the dns server and root hints. This is AD/dns 101.

Error2
He has a domain controler so, he needs to point his dns to 192.168.1.4. If he lets his router hand out external dns (why he cant connect now) it will not login to AD.

Error3
Domain controlers should not be issued IPs via a router, they should have static IPs (or at a minimum reservations). If they had dynamic IPs, then you would need to keep changing the dns servers in every computer's tcp-ip settings (or dhcp)
That would be time consuming and useless.

 

Cool.

As you see, in your case as long as you point your primary DNS on your workstation to your server, it will find the controller.

 

you should not be putting anything but the primary dns in there.... unless you have a second dns/dc server

 

Not true at all. The secondary DNS is an outside DNS to at least provide backup web surfing functionality in the event of a server malfunction.

 

No, thats what a secondary domain controler is for. If you put a non domain controler in there it is posable for you to cache bad results and cause problems until it is flushed.

If the primary dns server is overloaded, it is common for the secondary dns to be used, and since that secondary is now external, you have just messed everything up. No internal resources will be resolveable, and bad results will be cached for an hour.

Even worse if you are using a AD structure that uses the same internal / external name.


Read Microsoft's best practices .. it says not to do that, can lead to a split dns situation.

This was one of the most common service calls i delt with when i did small buisneess consulting ...

Quote from MS BP for windows 2003

For Domain controlers
Do not configure the DNS client settings on the domain controllers to point to your Internet Service Provider's (ISP's) DNS servers. If you configure the DNS client settings to point to your ISP's DNS servers, the Netlogon service on the domain controllers does not register the correct records for the Active Directory directory service. With these records, other domain controllers and computers can find Active Directory-related information. The domain controller must register its records with its own DNS server.

To forward external DNS requests, add the ISP's DNS servers as DNS forwarders in the DNS management console. If you do not configure forwarders, use the default root hints servers. In both cases, if you want the internal DNS server to forward to an Internet DNS server, you also must delete the root "." (also known as "dot ") zone in the DNS management console in the Forward Lookup Zones folder.

For workstations and member servers
Configure the primary and secondary DNS client settings to point to local primary and secondary DNS servers (if local DNS servers are available) that host the DNS zone for the computer's Active Directory domain.
If there are no local DNS servers available, point to a DNS server for that computer's Active Directory domain that can be reached through a reliable WAN link (Up-time and bandwidth determine reliability.)
Do not configure the client DNS settings to point to your ISP's DNS servers. If you do so, you may experience issues when you try to join the Windows 2000-based or Windows Server 2003-based server to the domain, or when you try to log on to the domain from that computer. Instead, the internal DNS server should forward to the ISP's DNS servers to resolve external names.

http://support.microsoft.com/kb/825036

 

On a very large network, yes. On a small network (under 10 clients) with a reliable server (in my case I use dual dual-core Xeons) that's completely unnecessary. In fact, what I've found is that if you rely strictly on internal DNS you will run into cases where you can't resolve external domain names. Further, if for any reason you have problems with your local DNS cache, which does happen on Windows servers (I've seen it), , your server goes down, or infection of the cache then you have an entire organization with absolutely no web access until IT gets to it.

The exception is if you name your local domain the same as your web domain....but if you do that you're an idiot and you'll have more problems than being unable to join a domain.

 

ummm local name same as domain name is one of the 3 dns infustrutures aproved by microsoft. So dumb .. no

You have no idea what you are talking about

How does using a dual xeon make your server more reliable?

I respectfuly disagree with your statements, and infact microsoft disagrees also ... that should be enough.

You have
same internal / external (domain.com)
diff internal / external (domain.local and domain.com)
and delegated internal from external (corp.domain.com and domain.com)