Active Directory Domain Controller (AD DC) could not be contacted

Do the workstations have their dns and dhcp setup to auto, i.e. Gets its IP and gateway from your dns and dhcp server? Or, was it hard-coded to a network address space different from the server?

On a workstation...
- Open a CMD prompt
- IPCONFIG /ALL

In the list that shows...
DNS Servers: This is the IP of your domain controller (DC)
IP or IPv4 address: This is the workstation's IP. It should be on the same network space as the DC

Example:
If your DC IP is 10.0.0.1
Your workstation might have an IP like 10.0.0.10

Can you PING your DC's IP address? It should return something like "Reply from 10.0.0.1: bytes..."

I don't know your scenario, but usually in a small environment on the same machine (or VM) you put DNS role and Domain Controller (DC) role....

As NewVillageIT said...here is the example scenario:

(DC + DNS) <-----because these roles are in the same windows server machine: 10.10.10.4
Gateway: 10.10.10.10
Subnet: 255.255.255.0

Your workstation, in order to join the domain, has to be in the same subnet of your DC, must have the same gateway ip and 10.10.10.4 set it up as primary DNS SERVER.....

Try with your own IPs and let us know....

Your workstations are trying to contact a domain controller. To do this, they are contacting the DNS server (often installed on the DC as an additional role) and are trying to locate SRV records. SRV records are registered in DNS by the domain controller. You can reregister them by doing one of the following:
- Reboot the DC
- Stop/start the netlogon service on the DC
- Open a command prompt on DC and type NLTEST /DSREGDNS
You may be using a 3rd-party DNS server that's not allowing SRV records to be registered or the DNS config on the Domain Controller is wrong.

I tried all your suggestions and I'm still having the same problem.  One other strange issue I've discovered is that I can PING my domain controllers static IP addresses (192.168.7.25 and 192.168.7.26, since I have 2 NIC cards in the server) and the results are normal.  However if I PING the server as "servername.daisrvr.com", I get what appears to be a public address (50.63.x.x)???    Also, if I PING "daisrvr.com", I get the IP address 184.168.221.48 which is the IP assigned to the domain thru GoDaddy where I purchased my SSL certificate.  Not sure if any of this helps, but it's got me baffled?

You are using a configuration that is called 'split-brain' DNS where you are trying to use the same name for your internal name as for your external company presence. Have you created the local DNS zone daisrvr.com on your DNS server? If not then all your clients will try to resolve the name externally.  

To recap:
- Ensure that the zone daisrvr.com exists on your local DNS server
- Ensure that the SRV records for your domain controller are registered on this zone
- Ensure that you clients are talking to the local DNS server to resolve daisrvr.com addresses

albatros99:  You're way over my head at this point.  In my DNS, I have a daisrvr.com zone that contains SRV records along with records for each of my workstations.  I have no idea whether this is a "local DNS zone" !?  The fact that daisrvr.com has a public IP addresses is new to me, I only uncovered this fact while trying to work out this problem.  Frankly, I have a completely different domain name that I set up for RemoteApp access to my system which is pointing to the IP address that Comcast has assigned to my Internet service.  I needed 2 SSL certificates to make my RemoteApps available to my client, one to connect to my public domain (which is actually "daipdc.com") and the other to connect to my server.  The second one apparently required that GoDaddy set up a public domain and IP in order for this SSL certificate to resolve correctly!?  Frankly, I'm not even sure what I'm talking about at this point, since everything is becoming so convoluted for me.  To make things even more complicated, the SSL certificate is set up for access to "myserver.daisrvr.com" which is the 50.x.x.x IP number and not the 184.x.x.x number assigned to the domain that GoDaddy apparently set up for me....I'm totally confused!

Since the zone looks okay, the next thing I would check is what DNS server the client is using. The primary DNS server should be your local DNS server (the one that is hosting the zone, as per your printscreen). If that's not the case, and if it's going to the internet to resolve the name - then the domain join will fail. Do an IPCONFIG /ALL on the client and verify the DNS server settings match.

Settings look like they're OK to me (see attached):

It does indeed look right. Some reasons I can think of that are worth testing:
- Disable IP 6 on the primary NIC  
- Check for persistent routes (route print in command window)
- If the client has multiple NIC's (for example wireless and wired) disable all non-essential NIC's  

As long as an NSLOOKUP of DAISRVR.COM on the client does not return the IP of your local DNS server, the domain join will not work.

I don't know how to disable ipv6, so if you could help me with that....the files below show the "route print" and the "nslookup", which I agree is definitely a problem, but I just don't know what to do about it!

Unbelievable!  After all that, all I had to do was uncheck a single checkbox.  As soon as I "unchecked" ipv6 on my NICs, the network started working....at first, I lost Internet connectivity, but that just turned out to be a problem on my server's NICs that were still pointing to my old Gateway address.  I still have a couple more things I need to get working, but I should be able to get through that myself.  Thanks so much for your continued interest in resolving my problem.  You've saved me hours of potential work attempting to reconstruct my network!

albatros99 showed an incredible amount of interest (and concern) in my predicament and continued asking pertinent questions, reviewing "screen print" information I supplied, and, eventually, resolved my issue which was, quite frankly, causing me a considerable amount of anxiety in that I need my network working correctly to do my work that provides for my family.  Thanks again, albatros99, you're a lifesaver!

Glad to hear it's working. Just to add some final comments: there are of course documented ways to change the order of preference for IPv6 / IPv4 or also to completely disable it.  

See Microsoft KB article 929852 for details. But I find that most of the time it's sufficient to just uncheck the box on the interface.