Windows 2003 dns server repair

Skip to main content. This browser is no longer supported. Download Microsoft Edge More info. Contents Exit focus mode. Please rate your experience Yes No. Any additional feedback? Keep this in mind if you had any applications running on these DCs and if they had any information stored in the registry. To save time required to re-install software, determine if applications that need to be installed on the DCs are compatible with virtual DC cloning.

Such applications can be installed on the source DC prior to cloning in order to save the time and effort required to install them on the cloned virtual DCs. Perform this procedure only on the first Windows Server DC that is restored in the domain. To perform an authoritative restore of SYSVOL, select the check box When restoring replicated data sets, mark the restored data as the primary data for all replicas. Marking the restored data as the primary data in the Backup is equivalent to setting the BurFlags entry to D4 under the following registry subkey:.

In Components , select the Networking Services check box, and then click Details. If you are prompted, in Copy files from , type the full path of the distribution files, and then click OK.

Ensure that the parent DNS zone contains delegation resource records name server NS and glue host A resource records for the child zone that is hosted on this DNS server. If you are installing the DNS Server service on a server in the child domain, this DC will not be able to register its records immediately.

This is because it is currently isolated as part of the recovery process, and its primary DNS server is the forest root DNS server. Configure this computer with the same IP address as it had before the disaster to avoid DC service lookup failures. Skip to main content. This browser is no longer supported.

The test to determine whether machines on your network have trouble resolving internal names, external names, or both is also designed to help you to figure out where you should start troubleshooting the problem. For example, if you are having trouble resolving the names of other computers on your internal network, then you most likely have a true DNS failure. If, on the other hand, internal name resolutions are working, then the DNS server is obviously functional.

It could be that the forwarder is set incorrectly or that an external DNS server is down. Let's pretend that you have done these two tests and you determine that both internal and external name resolutions are failing for every computer on the network. If that's the case, then all signs point to a problem with your DNS server. As simple as it sounds, the first thing that I recommend doing is taking a quick glance at your DNS server to make sure that the monitor is not displaying the Blue Screen of Death or some other type of catastrophic error message.

If the DNS server appears at first glance to be functional, then select the Services command from the server's Administrative Tools menu to open the Service Control Manager. If for some reason the DNS service is not running, then you can right-click on the service and select the Start command from the resulting shortcut menu.

Hopefully, doing so will start the DNS service and fix your problem. Even if it does though, you need to take some time and look through the server's System log for clues as to why the service has failed. Assuming that the server appears to be functional and the DNS service is running, then the next step is to test for a communications problem between the DNS server and other machines on your network. The easiest way of accomplishing this is to go to one of the workstations that is experiencing name resolution problems and open a Command Prompt window.

This will display the IP configuration for each network adapter on the system. There are two things that you need to look for when this information is displayed. If the ping is returned, then it means that there is a functional communications path between the workstation and the DNS server.

If the ping fails, then it doesn't automatically mean that there is a communications problem. One way of testing this is to ping a known good server by IP address not by fully qualified domain name that is in close proximity to the DNS server. If the ping continues to fail and you have ruled out firewall restrictions as the cause, then there is most likely a communications problem of some sort going on.

You should verify that the IP address that is bound to the server's primary network interface matches the address that network workstations are configured to use as their DNS server.

If everything checks out, then try pinging the server's primary IP address from the Command Prompt window. Since you are pinging the server's own IP address, the ping won't verify network connectivity. If the self ping succeeds, then try pinging some other IP addresses on your network especially the IP address of the workstation that was unable to ping the DNS server earlier. If these pings fail, then a communications problem is definitely to blame.

You might make sure that the patch cable is connected securely to the server's network adapter. If that doesn't solve the problem, you might try plugging the DNS server into a different port on your switch, or replacing the network adapter and patch cable.

What if the ping tests are successful though?