Protecting your business doesn’t have to mean sifting through endless alerts and notifications. With WatchGuard Total Security Suite, you can feel confident that your business is secure, meaning you can get back to the things that have been sitting on your to-do list.
Unable to join domain using FQDN
Hi Guys,
I am having an issue on a customer site where I can join the domain if I use "blah". However if I use the full root domain "blah.co.uk" I get the error message below.
Where this is really an issue is promoting a new domain controller, it is required to resolve the FQDN. Exchange is also unable to resolve the domain and cannot receive emails.
If I ping "blah.co.uk" this works correctly.
In the event log there are logs such as:
As well as this one which points towards it trying to register against a public DNS server:
I am having an issue on a customer site where I can join the domain if I use "blah". However if I use the full root domain "blah.co.uk" I get the error message below.
Where this is really an issue is promoting a new domain controller, it is required to resolve the FQDN. Exchange is also unable to resolve the domain and cannot receive emails.
If I ping "blah.co.uk" this works correctly.
DNS was successfully queried for the service location (SRV) resource record used to locate a domain controller for domain "blah.co.uk":
The query was for the SRV record for _ldap._tcp.dc._msdcs.blah.co.uk
The following domain controllers were identified by the query:
dc1.blah.co.uk
However no domain controllers could be contacted.
Common causes of this error include:
- Host (A) or (AAAA) records that map the names of the domain controllers to their IP addresses are missing or contain incorrect addresses.
- Domain controllers registered in DNS are not connected to the network or are not running.
In the event log there are logs such as:
The DNS server was unable to add or write an update of domain name Sales7 in zone blah.co.uk to the Active Directory. Check that the Active Directory is functioning properly and add or update this domain name using the DNS console. The extended error debug information (which may be empty) is "". The event data contains the error.
As well as this one which points towards it trying to register against a public DNS server:
The dynamic registration of the DNS record '422bc67f-c55f-461d-8f86-22d452011ec6._msdcs.blah.co.uk. 600 IN CNAME dc1.blah.co.uk.' failed on the following DNS server:
DNS server IP address: 213.143.3.4
Returned Response Code (RCODE): 5
Returned Status Code: 9017
For computers and users to locate this domain controller, this record must be registered in DNS.
USER ACTION
Determine what might have caused this failure, resolve the problem, and initiate registration of the DNS records by the domain controller. To determine what might have caused this failure, run DCDiag.exe. You can find this program on the Windows Server 2003 installation CD in Support\Tools\support.cab. To learn more about DCDiag.exe, see Help and Support Center. To initiate registration of the DNS records by this domain controller, run 'nltest.exe /dsregdns' from the command prompt on the domain controller or restart Net Logon service. Nltest.exe is available in the Microsoft Windows Server Resource Kit CD.
Or, you can manually add this record to DNS, but it is not recommended.
ADDITIONAL DATA
Error Value: DNS bad key.
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
Asked:
Who is Participating?
LVL 1
Issue was caused by AV. Even tho this was disabled, it had to be uninstalled to fix the issue.
I think one of your issues is going to be that your Windows domain is named the same as your Internet domain. This really should not be done and this is one of the reasons why. Your domain controller is using DNS to resolve the PUBLIC IP address most likely as it is trying to join as opposed to the local naming.
If you create a HOSTS table entry on the new server temporarily that points to the domain controller IP and try it again to see if that works.
If you create a HOSTS table entry on the new server temporarily that points to the domain controller IP and try it again to see if that works.
I have found that in many cases - the problem is
1. The New Domain Server is not the DHCP Server
2. The Workstation is using Dynamic IPs and is not pointing to the Domain server as the 1st DNS IP and the Router as the 2nd.
If something else is providing the DHCP - you pretty well need to go Static IP on the Workstation and the primary DNS should be the Domain Server.
The other way is to put an entry in the HOSTS file to point to the Domain Controller
I now use profwhiz.exe to move workstations from one domain to another without having to worry about creating a new profile for the User on the Workstation.
1. The New Domain Server is not the DHCP Server
2. The Workstation is using Dynamic IPs and is not pointing to the Domain server as the 1st DNS IP and the Router as the 2nd.
If something else is providing the DHCP - you pretty well need to go Static IP on the Workstation and the primary DNS should be the Domain Server.
The other way is to put an entry in the HOSTS file to point to the Domain Controller
I now use profwhiz.exe to move workstations from one domain to another without having to worry about creating a new profile for the User on the Workstation.
Thanks guys tried that, no luck.
The logs above are from the existing domain controller.
Agreed on the domain name, this wasn't our choice. We have inherited this issue.
The logs above are from the existing domain controller.
Agreed on the domain name, this wasn't our choice. We have inherited this issue.
Hi,
when you perform nslookp against your domain controller, does it resolving fine? i suspect that the DC is missing an A record. Try to create a host A record and see it works fine.
when you perform nslookp against your domain controller, does it resolving fine? i suspect that the DC is missing an A record. Try to create a host A record and see it works fine.
Can you take the domain controller and the new server and isolate them on a switch with no access to the Internet and try to join them. Once they are joined, they should be fine.
Is the DNS zone for the domain hosted locally on the DC? If not, it should be. Try creating a new host record on the DC's DNS zone for 'www' and point that to the public IP address on the Internet. Do the same for the MX records for exchangeInternal DNS zone should have an MX record for the private IP address of the Exchange server. Public DNS should have an MX record for the public address where exchange can be reached.
Tried isolating them so they had no internet access but the same result.
DNS is local to the single DC. browsing and pinging the domain name returns the DC and not the public site.
DNS is local to the single DC. browsing and pinging the domain name returns the DC and not the public site.
It seems as if netbios over TCP/IP is working if the clients can join via DOMAINNAME instead of domainname.com. What are the netbios over TCP/IP settings on the client. If it is set to the default, "Get from DHCP", try turning it on.
Does client computers also residing on public IPs or they have got private IPs ?
If client computers has private IP, how would they can communicate with DC with FQDN ?
If client computers has private IP, how would they can communicate with DC with FQDN ?
Are your clients explicitly using the internal DNS server or do they send lookups to the internet ?
It sounds like short names were in use in the environment for local resolution while DNS resolution on clients for the fqdn might be going out to the internet as indicated above.
I would try checking the internal dns servers to see if it forwards requests for the internal domain fqdn to the internet (if not then I would use the local dns server for name resolution on the internal clients)
Firebar is pretty much on point with the troubleshooting / resolution path.
You may also want to see if any lmhost files are configured in your environment
It sounds like short names were in use in the environment for local resolution while DNS resolution on clients for the fqdn might be going out to the internet as indicated above.
I would try checking the internal dns servers to see if it forwards requests for the internal domain fqdn to the internet (if not then I would use the local dns server for name resolution on the internal clients)
Firebar is pretty much on point with the troubleshooting / resolution path.
You may also want to see if any lmhost files are configured in your environment
Becraig, thats what we are seeing on the DNS server. It looks to be forwarding to the internet, but cant find a reason for this.
Tried changing the netbios over TCP/IP setting and this hasnt helped. Same result.
We are contemplating building a new domain to get over this issue, but would really like to avoid that.
Tried changing the netbios over TCP/IP setting and this hasnt helped. Same result.
We are contemplating building a new domain to get over this issue, but would really like to avoid that.
So firebar has given you the best path:
1) Ensure your internal clients explicitly use your DNS server
2) Forward all internet lookups to public DNS (domains other than your own)
3) Create a zone for your Domain in your DNS server
4) Forward all other request for your zone except for the AD related records to the internet.
Here is a nice little primer on your setup:
http://community.spiceworks.com/how_to/show/21213-using-same-fqdn-on-internal-and-public-networks
You might probably just want to do a walk through and compare.
1) Ensure your internal clients explicitly use your DNS server
2) Forward all internet lookups to public DNS (domains other than your own)
3) Create a zone for your Domain in your DNS server
4) Forward all other request for your zone except for the AD related records to the internet.
Here is a nice little primer on your setup:
http://community.spiceworks.com/how_to/show/21213-using-same-fqdn-on-internal-and-public-networks
You might probably just want to do a walk through and compare.
I am not ware why you published Domain controller on internet directly ?
Either you need to use split DNS scenario or you need to establish separate domain for internal clients
In split DNS you need to place one member server \ workgroup server in DMZ having standard primary zone with same name as your active directory dns zone (domain.co.uk) and you can publish it directly to internet with required records for external name resolution.
Same time your existing server that is having FSMO roles need to be placed \ transferred in corporate LAN network segment and its public IP needs to be replaced with private IP
Mahesh
Either you need to use split DNS scenario or you need to establish separate domain for internal clients
In split DNS you need to place one member server \ workgroup server in DMZ having standard primary zone with same name as your active directory dns zone (domain.co.uk) and you can publish it directly to internet with required records for external name resolution.
Same time your existing server that is having FSMO roles need to be placed \ transferred in corporate LAN network segment and its public IP needs to be replaced with private IP
Mahesh
From the last message you posted in the original question (dynamic registration failed...), it looks like perhaps you have a public DNS server configured in the NIC configuration on the DC.
Usually the easiest way to get to the bottom of issues like this is to run
dcdiag /v
dcdiag /v /test:dns
If you can post the results here that would be great.
Usually the easiest way to get to the bottom of issues like this is to run
dcdiag /v
dcdiag /v /test:dns
If you can post the results here that would be great.
Question has a verified solution.
Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.
Have a better answer? Share it in a comment.
All Courses
From novice to tech pro — start learning today.
