1

I have a Windows Server 2012 r2 virtual machine as DC1 and DNS server running on Windows Azure and a Windows Server 2012 r2 local machine as DC2, DHCP and DNS server on-premise. I found my DNS server on both DNS servers are not running. When I start DNS MMC, I see the screen :

"The server MYSERVER could not be contacted.

The error was:

Access was denied.

Would you like to add it anyway ?"

After select "Yes", the DNS MMC shows up but without any DNS zone. I cannot do anything on the MMC DNS except deleting the DNS zone.

I checked the event viewer and I found there are a lot error with Event ID 4000 & 4007 and I found the solution on Microsoft support. This solution did work on the local DC2 but not DC1.

"C:>netdom resetpwd /server: /userd: /passwordd:*

Type the password associated with the domain user:

The machine account password for the local machine could not be reset.

The specified network name is no longer available.

The command failed to complete successfully."

It says the specified network name is no longer available. Some says Symantec Endpoint Protection could cause this problem but there is no antivirus running on DC1.

On DC2, even I am able to access the DNS server and make changes now, but I cannot ping/RDP to some domain computers. Before this issue happened, everything worked just fine.

I have struggled with this issue for two days but yet remain unsolved. Can anyone give some advice or solution for this issue, please ?

Note: I tried this solution but it doesn't work for me.

CK Tan
  • 171
  • 1
  • 1
  • 13

2 Answers2

2

Where is your PDC FSMO currently held? This is the server you should use when running the command resetpwd /server:<PDC.domain.com> /userd:<Domain\domain_admin> /passwordd:* I'm assuming that the PDC FSMO is on DC2.

My guess is that when you ran this on DC2 you used the servername as DC2 which is correct. However, when you ran this on DC1, you specified the server name incorrectly as DC1. It should be DC2 as well since that is the PDC.

The MS Knowledgebase article is not particularly well written, which is why I'm making the assumptions above - apologies if my assumptions are incorrect.

Once DNS is fixed, you will need to run ipconfig /registerdns on each of the client machines in order to have them register with the DNS server, or just reboot them.

When you attempt to ping a client machine, is the server unable to resolve the name? If so, once the client machine is registered with DNS, it should work fine.

ChadH360
  • 404
  • 2
  • 3
  • ChadH360, thanks a lot! Your assumption saved my day. The DNS server on DC1 is now running too. But, the problem of not able to ping/RDC to some of the domain computers still remains. I couldn't ping them with IP address/ machine name. Before the DNS issue took place, everything was working fine. Do you have any idea ? – CK Tan Apr 22 '15 at 16:16
  • Updates: (1)The domain computers can ping the DC2 but I cannot ping the domain computers from DC2 (2)The active directory of DC1 and DC2 are not synced anymore – CK Tan Apr 22 '15 at 16:32
  • When I tried to add user on DC1, I got the error message: "Cannot create object (directory service was unable to allocate a relative identifier)". DC2 can add new user without problem. – CK Tan Apr 22 '15 at 16:45
  • It sounds like DC2 has lost contact with the domain because of DNS. Now that you have DNS working again, I would recommend the following. Set the primary dns server of DC1 to DC2, and the secondary dns server of DC1 as DC1. Do the opposite on DC2. In summary, set the primary DNS to the other server and the secondary DNS server to itself. Run ipconfig /registerdns on both servers (it might be worth rebooting DC1 as well). That should hopefully kick DNS and the domain back into touch! Bottom line is, DC1 can't access FSMO roles on DC2 which is why you can't add object to AD. – ChadH360 Apr 22 '15 at 20:26
0

It happened that i had this situation where one of my windows servers lost trust with the domain and the fix was straight forward.

  1. Turn of the network on the failing server
  2. Login with the domain administrator account and open the powershell
  3. Run the following command: Test-ComputerSecureChannel -Repair
    If the result is True, then you successfully fixed the problem.

I hope it helps someone.

alexander.polomodov
  • 1,060
  • 3
  • 10
  • 14
bytes
  • 1