Home » Exchange » Exchange Server is in an Inconsistent State? Get Ways to Fix

Exchange Server is in an Inconsistent State? Get Ways to Fix

Shini Mohan | Modified: December 27, 2024 | Exchange | 6 Minutes Reading

No admin wants to see the alert that their Exchange Server is in an inconsistent state. This problem has been seen in every Exchange version from the decade-old 2010 to the latest 2019. It is when due to internal conflicts (most often in a post upgradation scenario) the server is unable to verify the correct entities. So as a result it pushes itself to an inconsistent state and sends out an alert to the admin.

Unlike other Exchange issues, this is a server-wide problem so no user would be able to send/receive or even access their mailbox. Moreover in certain scenarios, admins may get locked out of the EAC, so all the GUI-based interactions (and the ability to fix) with the server close alongside it. So without further ado let us explore all the options admins have in their arsenal.

Identify the Reasons Behind an Inconsistent Exchange Server

It is important to understand under what circumstances this type of error becomes more likely. Once admins become aware, they can predict and prevent the server from going into an inconsistent state.

The most likely cause is when there exists a previous version of Exchange and an attempt is made to install/ run a new version (sometimes with the same name).

This adds confusion to the live server environment as it attempts to connect to two different versions simultaneously. Resulting in a case where none gets connected. So if admins can dismantle the remains of the old version before they can avoid the issue altogether.

Method 1: If Exchange Server is in an Inconsistent State Rename it 

It is perhaps the first thing that comes into the minds of novice admins. Logically too most inconsistencies are due to a faulty naming structure so the idea of stopping conflicts or dissolving lingering DNS/AD records doesn’t sound so bad. However, readers will soon realize the flaws behind this approach.

Before renaming once try to install the Exchange server update again. Sometimes it can be that your infrastructure like bandwidth, storage, memory, etc may cause a delay and the Exchange server slips into an inconsistent state. If this does not work then.

Rename (No Straight Forward Method)

The Exchange Server Name is immutable and this is a feature designed to reduce mailing errors. Renaming essentially means every user domain, login credentials, and incoming address changes.

So Microsoft makes it practically impossible to rename a live Exchange Server. Admins have to perform a full reinstall and migrate all the data there.

Then, manually remove the old DNS records (A, CNAME, and PTR) associated with the previous server name.

Finally, run the following command on the Domain Controller:

repadmin /syncall /AdeP

Wait for replication to complete and verify using Active Directory Sites and Services.

This method is quick but not a deep fix. Use it when there are naming conflicts or minor DNS/AD issues.

Method 2: Remove the Exchange Server Object and Relaunch Exchange Setup

If a failed setup or uninstallation leaves residual objects in the Active Directory, this method cleans up AD to allow a fresh setup.

  1. Open ADSI Edit:
    • Inside your Domain Controller station launch ADSI Edit via run module (adsiedit.msc).
  2. Connect to the Correct Configuration Partition:
    • Then, right-click ADSI Edit > Connect to.
    • Pick Configuration under “Well-known Naming Contexts”.
  3. Find Problematic Exchange Server Object:
    The default path is explained in a tree-like structure bellow.
> CN=Configuration, DC=YourDomain, DC=com  
  > CN=Services  
    > CN=Microsoft Exchange  
      > CN=Your Exchange Organization  
        > CN=Administrative Groups  
          > CN=Exchange Administrative Group  
            > CN=Servers
  • Identify the server object causing the issue and delete it.
  1. Clean Up User/Other Objects:
    • In ADSI Edit, check for lingering Exchange-related attributes on user accounts (e.g., msExchHomeServerName, legacyExchangeDN).
    • Remove or clean up these attributes if necessary.
  2. Wait for AD Replication:
    • Allow time for the changes to replicate across all domain controllers.
repadmin /syncall /AdeP
  1. Relaunch Exchange Setup:
    • On the Exchange server, re-run the setup: 
      setup.exe /m:Install /IAcceptExchangeServerLicenseTerms

Caution:

  • Always back up AD before using ADSI Edit.
  • Avoid deleting other objects or attributes unintentionally.

Method 3: Rebuild the Server in Recovery Mode

It is perhaps the single most method that can perform a total recovery back from the Exchange Server inconsistent state.

First, ensure you hold the following permissions and complete the prerequisites

  • Membership in Domain Admins, Enterprise Admins, and Organization Management.
  • Install identical OS and hardware configurations.
  • Drive letters must match the original server.
  • Disable User Account Control (UAC) temporarily.

Steps:

  1. Install the Windows Server version designed to work with the Exchange counterpart you are trying to fix.
  2. Connect Domain:
    • Rejoin the server to the domain using the same name as the previous Exchange server.
  3. Prepare Prerequisites:
    • Install all required roles and features:
      Install-WindowsFeature RSAT-ADDS, Web-Server, Web-Mgmt-Tools, NET-Framework-Features
    • Install the required updates and the correct .NET Framework version.
  4. Run Exchange Recovery Mode:
    • Mount the Exchange Server installation media.
    • Run the following command: 
      .\setup.exe /m:RecoverServer /IAcceptExchangeServerLicenseTerms
    • The setup will read configuration data from Active Directory and recover the server.
  5. Reconfigure Custom Settings:
    • After recovery, reapply any custom settings:
      • Connectors
      • Transport Rules
      • Certificates
  6. Validate the Recovery:
    • Verify services:
      Get-Service *MSExchange*
    • Check database mount status:
      Get-MailboxDatabase -Status

Professionally Fix Database to Keep Server From Going into Inconsistent State

As explained in the early part of this text one of the major reasons why admins consistently find their server in an inconsistent state is due to faulty database.

If your server closed down abruptly you can try out the command line methods for an Exchange dirty shutdown repair but these are usually too complex and may lead to permanent dataloss.

We suggest you use the SysTools EDB Repair Solution, which provides a simplistic GUI-based way to fix database errors.

Download Now Purchase Now

Moreover, you can use the tool outside of other Exchange Server dependencies even when your Exchange Server is inconsistent.

These are the series of steps you have to perform once you get the tool.

  • Step 1. Launch the tool on your workstation
  • Step 2. Browse & Add Exchange Database File (EDB)
  • Step 3. Use Advance Scan Mode to Preview Exchange mailbox issues
  • Step 4. Repair and Export the now error-free mailboxes in the Offline EDB file format
  • Step 5. Finally, choose a location to save the Exchange database in the required file format.

Conclusion

Now admins no longer have to worry that their Exchange Server is in an inconsistent state. Moreover, the step-by-step command line remedy described here is enough to fix any inconsistency problems.

Begin with method 1 (restart server) if you feel that the problem is due to name reuse or DNS conflicts. Hop on to method 2 (remove server objects via ADSI Edit) to clean up residual AD entries.

Proceed to method 3 (Recover Server mode) if the rest of the methods fail. It is the most reliable recovery option but also the most complicated one.

Moreover with the help of the professional repair tool admins can fastrack their plans to bring back the Exchange server to the active state.