0

A client of mine attempted to "troubleshoot" their DC's DNS by wildly adding/removing a bunch of conditional forwarders, stub zones, and forward lookup zone records to the DNS server, writing/erasing each addition/removal from Active Directory (ADDS uses itself as the DNS server). 4 days of no issues later, users who have logged off cannot log back in due to "no logon servers available". Users who stay logged in to their sessions has had intermittent difficulty accessing mapped drives as well.

Logged into the DC and attempted to open dsa.msc and was met with ADDS error dialog stating "Naming information cannot be located because: The specified domain either does not exist or could not be contacted". I was however able to open and access dnsmgmt.msc.

dcdiag /test:dns came back with passing all around with a warning that I didn't have a AAAA record (no IPv6 so this is understandable). I am also able to ping the server's hostname and am also able to ping the domain name as well without issue.

I noticed that SYSVOL and NTDS were not shared, and likewise noticed DfsSvc error in the event log (ID:14550) "The DFS Namespace service could not initialize cross forest trust information on this domain controller, but it will periodically retry the operation. The return code is in the record data" along with event ID 7009 "A timeout was reached (120000 milliseconds) while waiting for the File Replication service to connect." Lo and behold, File Replication service cannot be started because of Error 1053: The service did not respond to the start or control request in a timely fashion".

I hit a brick wall. If anyone has any suggestions or questions, anything would be helpful as I'm at a roadblock here.

Brandon
  • 61
  • 1
  • 10
  • 1
    I'd first suggest getting DNS in order as that may resolve the other issues. Is the AD DNS zone intact? Is it correct? What is the DC currently using for DNS in it's DNS client settings? – joeqwerty Aug 18 '16 at 02:49
  • Hello Joe and thanks for responding. As I mentioned, dcdiag /test:dns comes back passed all around, also pinging hostnames both internal and external reply and resolve without issue. Pinging the domain name likewise resolves and replies without issue, so by at least those two tests, it appears the DNS is intact. – Brandon Aug 18 '16 at 15:07

2 Answers2

1

My guess is that the issues are a result of all the DNS monkey business that's been going on. My suggestion would be to recreate the AD DNS zones from scratch.

If the AD DNS zones have been mangled beyond hope then you can do this to recreate them from scratch. This answer assumes that the _msdcs.yourdomain.com and yourdomain.com zones are separate, individual zones. Make note of the zone names before following this procedure.

  1. Change the zones from AD integrated zones to standard primary zones (uncheck the "Store the zone in Active Directory" checkbox for the zone type).

  2. Copy (don't move) the zone files to a safe destination (the zone files can be found at %systemroot%\system32\dns).

  3. Change the zones back to AD integrated zones.

  4. Delete the zones.

  5. Recreate the zones.

  6. Create a new delegation in the yourdomain.com zone for the _msdcs zone.

  7. Reboot the server.

  8. Wait.

  9. Recreate any static DNS records from the text copies of the zones.

Your _msdcs.yourdomain.com and yourdomain.com zones should then have been fully and correctly recreated.

If for some reason this doesn't work you have two alternatives:

  1. Perform an authoritative restore of the DC, if you have a backup.

  2. Recreate the original zones from the copies of the zone files that you made.

joeqwerty
  • 109,901
  • 6
  • 81
  • 172
  • Hello Joe and thanks again. I don't believe with all testing considered that DNS is an issue, but with the correlation of the client playing admin, it very well could be. The zone records appear intact and respond/resolve accordingly, pass dcdiag DNS testing and ping properly both internally/externally. DNS manager is likewise one of the only MMCs I can open at the moment without AD yelling at me about the Namespace error. It is also curious to me how this would affect the File Replication service to not respond to any start/stop/restart commands. Nevertheless, I will try this now. – Brandon Aug 18 '16 at 15:12
  • When recreating the zones (step 5) should I create them initially as AD integrated or better to leave them as Primary? Does it matter? – Brandon Aug 18 '16 at 15:25
  • I followed the steps and recreated all of the DNS entries successfully, however the problem still persists. File replications service is not responding to commands and receiving Namespace errors when attempting to access anything that references the Active Directory database. – Brandon Aug 18 '16 at 16:01
  • @Brandon: Apologies. I just saw your comments now. I missed the detail about the dcdiag DNS test when I read your question yesterday. If DNS is OK then you'll need to dig deeper. What's in the event logs for AD, DNS, FRS, etc.? – joeqwerty Aug 18 '16 at 16:10
  • Hello Joe. FRS is not responding to any attempt to stop or start it. Because of this, I cannot open any AD consoles as it results in the Naming error mentioned above. As a last-ditch effort, I plan to download the FRSDiag tool (https://www.microsoft.com/en-us/download/details.aspx?id=8613) to hopefully shed more light on the issue. Stay tuned, and I appreciate your help! – Brandon Aug 18 '16 at 16:41
  • Error 1053 when attempting to start FRS. Events are ID 13574 "The FRS has detected that this server is not a domain controller" and ID 13575 "This domain controller has migrated to using the DFS Replication service to replicate the SYSVOL share". Both descriptions end with "Use of the FRS for replication of non-SYSVOL content sets have been depreciated and therefore, the service has been stopped. The DFS repiclation service is recommended for replication of folders, the SYSVOL share on DCs and DFS link targets" – Brandon Aug 18 '16 at 16:55
  • If you run `Dfsrmig /getmigrationstate` from anelevated command prompt what is the output? What is the Startup Type of the FRS service? – joeqwerty Aug 18 '16 at 18:18
  • Running Dfsrmig /getmigrationstate returns "All domain controllers have migrated successfully to the Global state ('Eliminated'). Migration has reached a consistent state on all domain controllers. Succeeded." As far as the startup state of FRS, it is set to Automatic. – Brandon Aug 18 '16 at 19:16
  • OK, so that means your DC's are using DFSR and not FRS so the FRS error messages can be ignored. If you type \`\yourdomain.tld` in File Explorer do you see the SYSVOL and NETLOGON shares? – joeqwerty Aug 18 '16 at 21:07
  • You're right. No idea why I was attacking this from the FRS angle when it's clear as day via that event log that it was DFSR the whole time. When I realized this I performed an authoritative restore (for those who may be reading this in the future): – Brandon Aug 19 '16 at 04:20
  • Open CMD as admin: reg add "HKLM\SYSTEM\CurrentControlSet\Services\DFSR\Restore" /v SYSVOL /t REG_SZ /d "authoritative" /f reg add "HKLM\SYSTEM\CurrentControlSet\Control\BackupRestore\SystemStateRestore" /v LastRestoreId /t REG_SZ /d "10000000-0000-0000-0000-000000000000" /f net stop dfsr net start dfsr – Brandon Aug 19 '16 at 04:29
0

I might suggest two things:

  1. Consider what may be resolving over WINS vs DNS, and in particular what the source of DNS resolution is (local HOSTS file, DNS resolution cache, or one of your servers).

  2. I have found that playing with nslookup (both to see how the machine resolves fqdn's and to FORCE it to resolve using a specific DNS server) is an illuminating troubleshooting exercise.

Tony
  • 11
  • 1