Anyone Here know Domain and DNS Configuration? - IT WORKS!!!

[goodlookin1]

Running DHCP services off a DC is unnecessary. DHCP and DNS are technically independent of one another. If you already have an existing appliance or server that is providing DHCP leases, turning that off and lighting it up on the DC doesn't really bring you any closer to a solution to this issue.

I totally agree. But when these funky issues arise, I prefer to take the path of least resistance: Eliminating as many potential culprits as possible. In this case, I'd rather have all the problems coming from the server than problems coming potentially from both the router and the server.

[ke6guj]

The router is no longer giving off the DHCP, the server is. The workstation should still have the router's gateway even with this setup? I thought with the server now doing DHCP, it would also become the gateway?

no, the router is still the gateway to the outside world. whatever DHCP server you end up using, on the DC or in the router itself should give out the router address as the gateway.

the DC needs to have the router IP address as its gateway. on the DC, you have its DNS settings in the NIC point to itself and in whatever DHCP server you end up with, the client DNS settings should point to the DNS server on the DC.

[goodlookin1]

no, the router is still the gateway to the outside world. whatever DHCP server you end up using, on the DC or in the router itself should give out the router address as the gateway.

the DC needs to have the router IP address as its gateway. on the DC, you have its DNS settings in the NIC point to itself and in whatever DHCP server you end up with, the client DNS settings should point to the DNS server on the DC.

Assume for below:
Server IP: 192.168.1.3
Router IP: 192.168.1.1
Workstation IP: 192.168.1.100

So my setup should look like this?:

Server:
IP: 192.168.1.3
SM: 255.255.255.0
DG: 192.168.1.1
DNS: 192.168.1.1

Workstation
IP: 192.168.1.100
SM: 255.255.255.0
DG: 192.168.1.1
DNS: 192.168.1.3

I was under the impression that the Workstation should be set like this (but the server would remain as above):

Workstation
IP: 192.168.1.100
SM: 255.255.255.0
DG: 192.168.1.3
DNS: 192.168.1.3

[ke6guj]

assuming you have DNS properly configured on server, it should be set as the following.

Assume for below:
Server IP: 192.168.1.3
Router IP: 192.168.1.1
Workstation IP: 192.168.1.100

So my setup should look like this?:

Server:
IP: 192.168.1.3
SM: 255.255.255.0
DG: 192.168.1.1
DNS: 192.168.1.1 192.168.1.3

Workstation
IP: 192.168.1.100
SM: 255.255.255.0
DG: 192.168.1.1
DNS: 192.168.1.3

I was under the impression that the Workstation should be set like this (but the server would remain as above):

Workstation
IP: 192.168.1.100
SM: 255.255.255.0
DG: 192.168.1.3 192.168.1.1
DNS: 192.168.1.3

on the server's dns settings, you would add forwarders to public DNS server like 4.2.2.2 and 8.8.8.8, or maybe to your ISP's private DNS server.

so, on whatever DHCP server you end up using, you need to set the DG as 192.168.1.1 and DNS as 192.168.1.3

[goodlookin1]

assuming you have DNS properly configured on server, it should be set as the following.





on the server's dns settings, you would add forwarders to public DNS server like 4.2.2.2 and 8.8.8.8, or maybe to your ISP's private DNS server.

so, on whatever DHCP server you end up using, you need to set the DG as 192.168.1.1 and DNS as 192.168.1.3

Ok, gotcha, thanks!

[ke6guj]

oh, and if you were planning on installing WINS on the server, then that needs to be added to the scope options as well to tell the clients that WINS is at 192.168.1.3, and with the basic DHCP servers included in some routers, you might not even have the option to set additional scope options beyond the basic DNS and gateway options.

[goodlookin1]

Ok, some progress: I can now ping the domain.local from both the server and workstation. Everything ***appears*** to be working, except when I go to test the domain. Here is the DCDIAG report from the server:

Microsoft Windows [Version 6.2.9200]
(c) 2012 Microsoft Corporation. All rights reserved.

C:\Windows\system32>dcdiag /test:dns

Directory Server Diagnosis

Performing initial setup:
Trying to find home server...
Home Server = PRECISION
* Identified AD Forest.
Done gathering initial info.

Doing initial required tests

Testing server: Default-First-Site-Name\PRECISION
Starting test: Connectivity
The host c4c0fbe3-9f77-4e7e-9022-14d1a8ba5318._msdcs.PMPMED.local
could not be resolved to an IP address. Check the DNS server, DHCP,
server name, etc.
Got error while checking LDAP and RPC connectivity. Please check your
firewall settings.
......................... PRECISION failed test Connectivity

Doing primary tests

Testing server: Default-First-Site-Name\PRECISION

Starting test: DNS

DNS Tests are running and not hung. Please wait a few minutes...
......................... PRECISION passed test DNS

Running partition tests on : ForestDnsZones

Running partition tests on : DomainDnsZones

Running partition tests on : Schema

Running partition tests on : Configuration

Running partition tests on : PMPMED

Running enterprise tests on : PMPMED.local
Starting test: DNS
Test results for domain controllers:

DC: PRECISION
Domain: PMPMED.local


TEST: Basic (Basc)
Error: No LDAP connectivity
Warning: adapter
[00000010] Broadcom NetXtreme Gigabit Ethernet has invalid
DNS server: 192.168.10.10 (precision.)
Error: all DNS servers are invalid
No host records (A or AAAA) were found for this DC

TEST: Dynamic update (Dyn)
Warning: Failed to add the test record dcdiag-test-record in z
one PMPMED.local

TEST: Records registration (RReg)
Error: Record registrations cannot be found for all the network
adapters

Summary of test results for DNS servers used by the above domain
controllers:

DNS server: 192.168.10.10 (precision.)
1 test failure on this DNS server
Name resolution is not functional. _ldap._tcp.PMPMED.local. faile
d on the DNS server 192.168.10.10

Summary of DNS test results:

Auth Basc Forw Del Dyn RReg Ext
__________________________________________________ _______________
Domain: PMPMED.local
PRECISION PASS FAIL PASS PASS WARN FAIL n/a

......................... PMPMED.local failed test DNS

I have stopped the Netlogon service, flushed the dns and registered it, then started the Netlogon service again, but it's still not kicking over.

I have added A host records in every location I can think of. I eve created an A record that included the GUID._msdcs.PMPMED.local and did the same for a CNAME record, but no dice.

Any ideas?

[goodlookin1]

IT WORKS NOW!!!

Alright, so I think the culprit was the updates on the DNS records. I had checked off "secure only", but I read a post online that someone had the same issue as me and had changed to "secure and unsecure updates". So I changed to that and did some other things (once again, reinstalled everything, dropped DHCP and put it back onto the router, reconfigured the DNS forwarders, etc). I also forgot that I had changed the subnet of the network but forgot to change it on the switch (it's managed), so I reconfigured the switch as well to reflect the proper network subnet.

Once I did these things, I saw the additional automatic DNS entries that I didnt have before. I then did the DCDIAG test on the DNS and it connected successfully. I then pinged the FQDN from the workstation and that worked as well. I finally tried joining the workstation to the Domain and SUCCESS!

Long couple days on this project.....about 13 hours just to get it working right. Now I finally get to do the configuration of the users, rights management, etc, and I can get past all of this guess and check garbage :-)

Thanks for all the suggestions.

[the86d]

I believe that the term "FQDN" requires official registration (at the DNS root zone too)... externally.

Correct me if I am wrong, as Wikipedia has had some misinformation, as have all of us : http://en.wikipedia.org/wiki/Fully_q...ed_domain_name

[ocabj]

fully qualified domain name doesn't have to be publicly registered. I could literally create a private namespace using RFC 1918 addresses on my home/office network with the .ocabj TLD and have the FQDN for my ldap server to be ldap.ocabj such that "nslookup ldap.ocabj" or "ping ldap.ocabj" works as long as it's in my own local DNS that's authoritative for the zone.

In real world, you often see Windows AD hosts have long FQDNs internal only to the Windows domain hosts because the DNS for that AD isn't being forwarded to other DNS servers for that organization whose clients aren't in the AD Domain.