Skip to content
11:11 Systems
Rethink Connected
11:11 Systems11:11 Systems
  • Why 11:11
    • Submenu
      • Column 1
        • Cloud Console
          Cloud Console
          Compliance
          Compliance

      • Column 2
        • Global Regions
          Cloud Regions
          Catalyst
          Planning and Assessment

      • WHY CHOOSE 11:11
      • Overview
      • Leadership
      • News & Media
      •  
      • Careers
      • Technology Partners
      • Customer Stories
  • Products & Services
    • Products & Services
      • CLOUD
      • Cloud Overview
      • Public Cloud
      • Private Cloud
      • Object Storage
      • Cloud Labs
      • Colocation/Bare-Metal
      • BACKUP
      • Backup Overview
      • Backup
      • Microsoft 365 Backup
      • DISASTER RECOVERY
      • DRaaS Overview
      • DRaaS for Veeam
      • DRaaS for Zerto
      • Autopilot
      • SECURITY
      • Security Overview
      • Continuous Risk Scanning
      • Managed SIEM
      • Managed EDR
      • Managed Firewall
      • CONNECTIVITY
      • Connectivity Overview
      • SD-WAN
      • Multi-Cloud Connect
      • Managed IP
  • Solutions
    • Solutions Submenu
      • INDUSTRY
      • Education
      • Financial
      • Government
      • Healthcare
  • Partners
    • Partners Submenu
      • Overview
      • Become a Partner
      • Partner Portals
  • Resources
    • Resources Submenu
      • Events
      • Webinars
      • News & Media
      • White Papers
      • Podcast
      • Data Sheets
      • Customer Stories
      • Innovation Blog
  • Support
    • Support Submenu
      • Contact Support
      • Product Documentation
      • API Documentation
Search:
  • Console Login
  • Contact
Header Right Menu
Free Trial
  • Why 11:11
    • Cloud Console
    • Compliance
    • Cloud Regions
    • Planning and Assessment
    • WHY CHOOSE 11:11
    • Overview
    • Leadership
    • News & Media
    • Careers
    • Technology Partners
    • Customer Stories
    • Blog
  • Products & Services
    • CLOUD
    • Cloud Overview
    • Public Cloud
    • Private Cloud
    • Object Storage
    • Cloud Labs
    • Colocation/Bare-Metal
    • BACKUP
    • Backup Overview
    • Backup
    • Microsoft 365 Backup
    • DISASTER RECOVERY
    • DRaaS Overview
    • DRaaS for Veeam
    • DRaaS for Zerto
    • Autopilot
    • SECURITY
    • Security Overview
    • Continuous Risk Scanning
    • Managed SIEM
    • Managed EDR
    • Managed Firewall
    • CLOUD CONNECTIVITY
    • Connectivity Overview
    • SD-WAN
    • Multi Cloud Connect
    • Managed IP
  • Solutions
    • INDUSTRY
    • Education
    • Financial
    • Government
    • Healthcare
    • Column 2
  • Partners
    • Overview
    • Become a Partner
    • Partner Portals
  • Resources
    • Events
    • Webinars
    • News & Media
    • Whitepapers
    • Podcast
    • Datasheets
    • Customer Stories
    • Innovation Blog
  • Support
    • Contact Support
    • Success Center
    • API Documentation
  • Contact
  • Console Login
  • Free Trial
Tags: Disaster Recovery
Author: Mike Mosley
Date: August 17, 2018

Domain Controller Failover Troubleshooting

Editor’s Note: As of January 2022, iland is now 11:11 Systems, a managed infrastructure solutions provider at the forefront of cloud, connectivity, and security. As a legacy iland.com blog post, this article likely contains information that is no longer relevant. For the most up-to-date product information and resources, or if you have further questions, please refer to the 11:11 Systems Success Center or contact us directly.

After running a failover, it is common to find that your domain controller (DC) is not operating properly. Because these servers control the overall domain and DNS functionality, this can cause the rest of your protected services or applications to fail. You may not even be able to log in to your other servers as they cannot authenticate or do not have a trust relationship with your domain controller.

Unfortunately, there can be various causes for issues that impact your domain on failover. It is recommended to view and export any relevant event viewer logs and open a case with Microsoft. However, before doing so, you may want to run through the following steps.

Network Profile

The first (and easiest) thing to check once logged in to a failed over DC server is the network profile. You can do this by hovering over the network icon in the system tray in the bottom right corner. Alternatively, you can open the Network and Sharing Center (pictured below) and view your active networks. In your production environment, you will most likely see that this is set to something like “domain.local” and is using the domain network profile.

After a failover, you may see that this has changed in your DC to the public network profile. This can be troublesome as it is a good indicator that the domain cannot be reached, and there may be other problems. Moreover, you may have the Windows firewall enabled on the public network profile. This may block remote access to this server as well as any communication to the rest of your failed-over environment.

You may be able to resolve this rather easily by restarting the network location awareness (NLA) service. This will also automatically restart the network list service. Restarting these services allows Windows to try and reidentify the network it is attached to and hopefully join the domain network profile. Ensuring that your DC is on the domain network profile will help the rest of the environment boot up with the domain network profile as well.

Before actually running a failover, it is recommended to change the NLA service startup type to “Automatic (Delayed Start)” (pictured below).

This gives the services extra time before assigning which network profile for the server. Many times, the public network profile is assigned because DNS and AD services have not started yet. So, by setting a delayed start, you have a better chance of booting up to the correct domain network profile after a failover. Another recommendation is to make sure that the DC has configured as the primary DNS server. This may be the first server booting up in the failover environment, and it is likely that you would not have connectivity to other DNS or DC servers at this point. So, pointing to itself for DNS is the easiest way to enable hostname resolution for this server.

DNS

In order for your domain controller to work properly, you will need to make sure that DNS is functioning as expected. As mentioned above, you may want to change the primary DNS server of the DC to its own IP address. This ensures the server is not trying to use a DNS server it has no communication with after a failover. If you have confirmed this domain controller has itself configured as the primary DNS server, you will want to confirm the DNS is working. You can run an NSLOOKUP command on your domain to see if you get the correct hostname resolution.

If this fails, you can open the DNS tool through the server manager and ensure that it connects and starts up as expected. If not, you may need to review the DNS server configuration in your production environment. You may have stale DNS or forwarder entries no longer in use that may be causing issues during the failover. However, while failed over, you can try restarting the DNS service to see if that resolves the issue. If that continues to fail, you can check the event viewer logs under “Applications and Services > DNS Server.”

SYSVOL Folder

Assuming you have confirmed that you are on the domain network profile and the DNS is working as expected, you can check to confirm that the SYSVOL folder has populated. The SYSVOL directory is the DC server’s copy of the domain public files and contains the user login scripts, NETLOGON information, group policy data, and more. If this folder has not populated, the domain will not have full functionality. You can verify this folder has populated by opening a file browser and typing in:\\<DomainControllerIP/Hostname>\SYSVOL. This should have a directory with your domain name. If you are not able to reach this folder or if there is nothing populated, your domain controller may not be in authoritative mode.

To resolve this, you can do a quick registry change to manually force this DC server into authoritative mode. Before you continue, please use caution when making changes to the registry. Also, this change is only necessary on the failed-over domain controller. You will not need to run through this process on the production domain controller. First, open a command prompt as an administrator and run the following command: Net Stop NTFRS. Once that completes, open regedit and browse to the following location at startup: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process. Right-click on the burflag key and choose “Modify.” Set the value data to D4 and click “OK.”

Back at your command prompt, type in the following command: Net Start NTFRS.

Once you have completed these steps, check the SYSVOL directory to confirm that the domain folder has populated. If it has not populated, you may want to try rebooting the domain controller and then review the event viewer logs to find more information. The bottom line here is that if the SYSVOL folder is not populating, you will not have full domain functionality. You will want to ensure that this folder is populated before failing over the rest of the environment.

Other Considerations

While the above topics are very common issues that can impact the domain on failover, other factors may cause disruption or errors. If you have multiple domain controllers in your production environment, you may need to replicate and include all servers in your failover plan. If you are unable or do not want to include all DCs, you will want to ensure that you are at least failing over the FSMO master. If you are unsure which DC has which roles, you can run the following command: NetDOM /query fsmo. This will display the server that is the holder of each FSMO role. This server needs to be replicated and failed over first to allow domain functionality.

You may also want to review the DNS servers that are configured on the other servers in your production environment. While we have already gone over the importance of your domain controller pointing to itself for DNS, you also want to ensure that the rest of your servers are pointing to your DC. After you failover the DC, you may then failover an exchange or file server. However, if they are using a different DNS server that has not been failed over, they may not be able to join the domain in the failover environment. Before failing over, it is best to confirm the DC/DNS server you are failing over is the same DNS server used by other protected servers.

Summary

As mentioned at the beginning of this article, there are numerous issues or misconfigurations that can impact a domain during a failover event. While the checks and considerations can be helpful in many situations, they may not resolve all of your issues. A reboot is always a good idea, but the logs in the event viewer will be very helpful in determining the root cause and help steer you to a resolution.

Below is a diagram to recap all of the steps we discussed:

Category: DRaaSBy Mike MosleyAugust 17, 2018
Tags: Disaster Recovery

Author: Mike Mosley

Mike Mosely is a cloud engineer at 11:11 and has worked at the company for over 3 years. He holds a number of VMware certifications including VCP5 as well as the Veeam VMCE certification. Mike works closely with customers to build cloud solutions that fit their requirements.

Post navigation

PreviousPrevious post:Using Zerto for Disaster Recovery and Workload Migration to a VMware Cloud: Part 1NextNext post:iland, Now 11:11 Systems, Named a Leader by Gartner for Three Years Running

Related Posts

Preparing for 2023 with 11:11 Systems: IT Trends in Security, Cloud, and More
February 1, 2023
11:11 Systems Wins 2022 Backup and Disaster Recovery Award from Cloud Computing Magazine
January 25, 2023
How businesses can respond to IT disruptions during the holiday season
How businesses can respond to IT disruptions during the holiday season
January 4, 2023
The CloudBytes Podcast: Season 3 is Here!
December 2, 2022
Celebrating Get To Know Your Customers Day
October 20, 2022
Experts: Prepare for Busy 2022 Hurricane Season
July 1, 2022
PRODUCTS & SERVICES
  • Cloud
  • Backup
  • Disaster Recovery
  • Managed Security
  • Connectivity Solutions
  • Compliance
COMPANY
  • Why 11:11
  • Customer Stories
  • Careers
  • Leadership
  • Technology Partners
  • News & Media
  • Contact Support
CLOUD REGIONS
  • North America
  • EMEA
  • APAC
CONNECT
  • LinkedIn
  • Twitter
  • Facebook
  • Youtube

© 2023 11:11 Systems Inc., All Rights Reserved | Privacy Notice

Go to Top
PRIVACY POLICY AND COOKIE CONSENT
To provide the best experiences, we use technologies like cookies to store and/or access device information. Consenting to these technologies will allow us to process data such as browsing behavior or unique IDs on this site. Not consenting or withdrawing consent, may adversely affect certain features and functions.
Functional Always active
The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistics
The technical storage or access that is used exclusively for statistical purposes. The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.
Manage options Manage services Manage vendors Read more about these purposes
View preferences
{title} {title} {title}
PRIVACY POLICY AND COOKIE CONSENT
To provide the best experiences, we use technologies like cookies to store and/or access device information that allows us to process data such as browsing behavior. Not consenting or withdrawing consent, may adversely affect certain features and functions. By clicking Accept, closing this message, or continuing to browse, you consent to these technologies and accept our Privacy Notice.
Functional Always active
The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistics
The technical storage or access that is used exclusively for statistical purposes. The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.
Manage options Manage services Manage vendors Read more about these purposes
View preferences
{title} {title} {title}