Table of Content
    Exchange Server Recovery

    How to Fix DAG Network Misconfigured Error?


    Table of Content

      Summary: In this post, we will be going through the DAG network misconfiguration error that usually occurs when viewing the network subnet status using the Exchange Admin Center (EAC) or the Exchange Management Shell (EMS). We will be looking at the possible solutions to resolve the issue. We will be mentioning an EDB recovery tool that can help recover data in case the database gets corrupted due to misconfiguration or other any issues.

      When viewing the network subnet status of Database Availability Group (DAG), you may get network misconfiguration errors. When you run the command Get-DatabaseAvailabilityGroup, you may see an error sating that there is a misconfiguration in the network of the Database Availability Group (DAG).

      run the command Get-DatabaseAvailabilityGroup

      The error message looks like the below.

      Get-DatabaseAvailabilityGroupNetwork
      Identity ReplicationEnabled Subnets
      -------- ------------------ -------
      DAG01\MapiDagNetwork True {{10.0.0.00/24,Misconfigured}, {192.168.0.0/24,Misconfigured}}

      In this scenario, you can try to create a new Database Availability Group (DAG), where a node in the Exchange Server network has two interfaces which are on the same subnet. However, having two network cards on the same subnet might create issues with the database synchronization and network. So, it’s not a recommended configuration when setting up a new Database Availability Group (DAG). It’s always best to follow the vendor’s recommendations when it comes to resources and setup.

      Possible Solutions to Fix the DAG Network Misconfigured Error

      When setting up a network for Database Availability Group (DAG), you need to ensure that you have two networks for your Exchange Server nodes. One of the network cards is to be used by the corporate network to access the server. This should be on the same network as the other server to be accessible for MAPI and clients. The other network should be a closed network, only accessible by the Exchange Server nodes for the replication of the data and separate from the internal network. Both network cards must not be on the same network subnet to avoid conflicts and issues. In addition, it must not have any DNS servers configured, no Gateway address configured, and is not registered in the DNS.

      For example, if you have your internal network on IP Address 192.168.0.0, which will be used for the MAPI and client access, the replication network should be on a separate network, say 10.0.0.0.

      setting up a network for Database Availability Group

      You need to fully ensure that the configurations you have set are per the Microsoft’s recommendations. The hardware can sustain the new configurations and load. You need to also ensure that the ports are enabled and all the required ports have been opened per recommendation. It’s always best to consult with your vendor or supplier before setting everything up.

      It’s important to follow the recommendations. If you go forward with a non-supported configuration, surely there will be consequences. This can cause issues with the server’s uptime and data inconsistency, leading to a non-functional Exchange Server or even worse, corrupted databases or transaction logs.

      To Conclude

      In case there are consequences, you will need the right tools to recover as soon as possible. In case of a failing server where the databases might be corrupted or mismatch from the passive and active database with the misconfiguration, the solution is to reinstall the server per recommendation and guidelines. However, the issue is recovering the data from corrupted database. You can use a third-party Exchange Database Recovery application to facilitate the process. One application that tops the market when it comes to recovery from Exchange Server databases is Stellar Repair for Exchange. It is the right tool to restore user mailboxes, public folders, archive mailboxes, shared mailboxes, and disabled mailboxes from the EDB files of a crashed server. In case the Exchange Server has been reinstalled, with the application, you can export the recovered database directly to a live Exchange Server with automatic mailbox mapping, and parallel and priority mailbox recovery. This is an ideal solution to fix Exchange database corruption errors without any data loss.

      Was this article helpful?

      No NO

      About The Author

      Shelly Bhardwaj linkdin

      I am a Product Consultant and is associated with Stellar Data Recovery from last 8 years. I write about the latest technology tips and provide custom solutions related to Exchange Server, Office 365, MS Outlook, and many other Email Clients & different flavors of OS Servers. Read More

      Leave a comment

      Your email address will not be published. Required fields are marked *

      Image Captcha
      Refresh Image Captcha

      Enter Captcha Here :

      Related Posts

      WHY STELLAR® IS GLOBAL LEADER

      Why Choose Stellar?

      • 0M+

        Customers

      • 0+

        Years of Excellence

      • 0+

        R&D Engineers

      • 0+

        Countries

      • 0+

        PARTNERS

      • 0+

        Awards Received