Fix unable to contact Server: This may be the server does not exist

In this blog post, you will learn how to fix “Fix unable to contact Server: This may be the server does not exist.” You may have run into this error after performing a swing migration, as described in this blog post “Build a New DC vs Swing Migration: Upgrade Server OS Correctly“. Plase, see AZURE Kubernetes Service (AKS) upgrade minor version from 1.32.3 to 1.33.7, and how to fix ADDS already contain a computer account.

Upgrading Domain Controllers (DCs) while retaining the same IP addresses is a common practice, particularly in environments where IPs are hardcoded into applications, or network devices. This involves performing a swing migration or rebuilding a new Domain Controller and transferring FSMO roles as the case maybe.

In many cases, the error “Unable to contact server: The server may not exist or may be unavailable” can be attributed to issues with Active Directory Web Services (ADWS). This service is critical for modern management tools, and if it is stopped, misconfigured, or unreachable, tools like Active Directory Users and Computers (ADUC) and PowerShell may fail to connect to the Domain Controller (DC).

ADWS is a built-in service introduced with Windows Server 2008 R2 and runs on every Domain Controller (both RODC and RWDC). It enables management communication over TCP port 9389 and is used by the Active Directory PowerShell module and other administrative tools.

If this port is blocked, the service is not running, or name resolution points to an unreachable DC, connectivity errors like “unable to contact Server: This may be the server does not exist” can occur. But this is not the reason for this issue.

Why was the error prompted “Fix unable to contact Server”?

There is no one-size-fits-all solution to this error. The message “Fix unable to contact Server: This may be the server does not exist” can be triggered by a variety of underlying issues, which we will explore shortly.

In many cases, this error indicates that the domain controller cannot locate or communicate with the target server, most commonly due to DNS misconfiguration. For example, the message “the specified server is not available” often points to incorrect name resolution or missing DNS records. Therefore, it is critical to verify that Techdc02 is correctly configured to use Techdc01 as its primary DNS server and that proper Active Directory–integrated DNS records (such as SRV records) are in place.

Additionally, after completing a swing migration, inconsistencies in replication metadata, stale computer accounts, or outdated DNS entries can lead to failures in Active Directory replication and authentication, which may surface as this error.

Therefore, when trying to move or transfer the FSMO roles to TechDC02. The FSMO role transfer failes with the error as shown in the image below.

Move-ADDirectoryServerOperationMasterRole -Identity "techdc02" -OperationMasterRole SchemaMaster, DomainNamingMaster, PDCEmulator, RIDMaster, InfrastructureMaster

Move-ADDirectoryServerOperationMasterRole -Identity TechDC02 -OperationMasterRole 0,1,2,3,4

Please see Active Directory Flexible Single-Master Operations Roles [FSMO], how to create a contact in Active Directory, and Active Directory Contact and a User Account Object Differences.

Verify Connectivity

Before proceeding with DNS misconfiguration troubleshooting, it is important to verify basic network and RPC connectivity. When encountering the error “unable to contact Server: This may be the server does not exist”, a common assumption is that a firewall is blocking communication. While this is not always the root cause, it is essential to rule it out early.

Start by testing RPC connectivity to the target domain controller using the following command:

Test-NetConnection -ComputerName TechDC02 -Port 135

TcpTestSucceeded : True. If false in your case, check firewall rules on both servers.

As you can see, the Active Directory Web Services (ADWS) is running. Therefore, this is not the issue as mentioned above.

Please see How to add a second Domain Controller, Unicode Manipulation: CVE-2026-25177 Privilege Escalation in AD, and how to replace Veeam Recovery Orchestrator License.

RPC Server is unavailable

Having verified RPC connectivity and ADWS service is running, let us try to transfer the FSMO roles again since the rebuild of TechDC02 is completed. We need to move the FSMO roles from TechDC01 to TechDC02. This way, we can perform the FSMO role transfer.

Move-ADDirectoryServerOperationMasterRole -Identity TechDC02.techdc01.techdirectarchive.com -OperationMasterRole SchemaMaster,DomainNamingMaster,RIDMaster,PDCEmulator,InfrastructureMaster -Force

Move-ADDirectoryServerOperationMasterRole -Identity TechDC02.techdc01.techdirectarchive.com -OperationMasterRole 0,1,2,3,4 -Force

As you can see below. The above commands failed. When we wish to force DC replication. We get an error “RPC Server is unavailable”.

We had already performed the RPC verification as shown below and above. There is no firewall issue, and the ADWS service is running.

Therefore, we need to troubleshoot and domain Controller functionality by running the command below.

dcdiag /v /c /d /e

We will have to look for RPC, connectivity and replication errors in the report. As you can see below, the LDAP search compatibility attribute search failed on TechDC02 etc.

From below, here are some errors preventing FSMO roles transfer.

As you can see, SPNs are critical for Kerberos authentication and AD replication.

Please see how to Fix failed to connect to the backup server: Make sure it is online, how to fix Domain Join Error during Windows Deployment, and SCVMM setup Error 10421: Fix VMM Service Account conflict.

Perform SRV Cleanup (Housekeeping)

Note: This is not the root cause of the issue, but performing cleanup is an important remediation step.

When domain controllers are forcefully removed (e.g., via Active Directory Sites and Services) instead of being properly demoted, residual metadata can remain in Active Directory and DNS. This is especially common during troubleshooting scenarios or incomplete decommissioning.

As part of this process, we will review DNS and remove any lingering domain controller records, particularly within the _msdcs zone.

During a swing migration, temporary or decommissioned domain controllers (e.g., TempDC) may leave behind stale DNS entries such as SRV and CNAME records (GUID-based records). Because Active Directory relies heavily on DNS for locating domain controllers, these stale entries can cause the environment to attempt communication using outdated references. This can lead to several issues, including:

• RPC error 1722 (The RPC server is unavailable)
• Active Directory replication failures
• FSMO role transfer or seizure failures
• SPN-related warnings or inconsistencies (even if not immediately critical)

Please see SCVMM setup Fails: Fix Missing Windows ADK Deployment Files, how to Integrate Hyper-V [SCVMM] with Veeam Recovery Orchestrator, and Integrate Hyper-V: Install System Center Virtual Machine Manager.

Was the Swing Migration actually needed?

Note: In most cases, a temporary domain controller is not required if you already have at least two domain controllers in the environment. You can start by decommissioning or upgrading the domain controller without FSMO roles first.

Additionally, Microsoft generally does not recommend swing migration as a standard upgrade approach unless there is a specific constraint (e.g., hardware reuse with identical hostname/IP requirements).

• Scenario 1: Single DC, replacing it, keeping hostname/IP: You must introduce a temporary second DC. This is because you can’t seize FSMO roles and safely reuse the hostname/IP on the same network without another DC present to handle AD metadata and replication. Otherwise, you risk replication conflicts, USN rollback, and AD corruption.

• Scenario 2: Already have at least two DCs, replacing one: You don’t need a temporary DC if you are replacing the DC without FSMO roles first. The remaining DC can continue handling AD services while you rebuild or upgrade the DC without FSMO roles in it. Once the new DC is ready, you transfer any roles if needed.

Note: A standard domain controller demotion and metadata cleanup (e.g., domain controller deregistration) does not typically require the following steps. However, since we are troubleshooting an inconsistent or partially decommissioned environment, additional cleanup is necessary.

Open DNS Manager and remove any stale entries related to TempDC, especially within the _msdcs.techdirectarchive.com zone (e.g., GUID-based CNAME and SRV records). These stale records can cause Active Directory to attempt communication with non-existent domain controllers. Once the cleanup is complete, proceed with further troubleshooting.

Forward Lookup Zones
_msdcs.techdc01.techdirectarchive.com
→ dc
→ domains
→ gc

Due to the lingering meta data as you can see below. We need to perform some clean up. I will remove the TempDC record since it is no longer needed.

Clear DNS “Ghosts

Since replication was failing at 20% at some point. We will thoroughly clean the meta data from the _msdcs.techdc01.techdirectarchive.com zone in DNS Manager. The command ipconfig /flushdns clears the local DNS cache, while ipconfig /registerdns forces the domain controller to re-register its DNS records in the DNS server. Now, run the below commands:

ipconfig /flushdns

ipconfig /registerdns

After cleanup, please perform AD replication.

repadmin /syncall /AdeP

You can also verify with PowerShell.

repadmin /replsummary

Due to the issue we are having to force DC replication. We may have to demote the DC we have just joined to the domain via the swing migration, To do this, you can safetly demote it.

Note: At this point, there were no DNS misconfiguration. Therefore, it is better to build a new DC. My take away, do not perform a swing migration or in-place upgrade of a Domian Controller. A simple rebuild is better as discussed here (Reddit), Silverpchu, and here (Microsoft).

Since I have showed this steps to demote a DC correctly, I would also like to remove the TechDC02 DC via Active Directory Sites and Services. We will have to delete the NTDS Settings object and the server object itself via Active Directory Site and Services

Sites
└ Default-First-Site-Name
└ Servers
└ tempDC

Please see Update Global Address List: Fixing the “Not Recognized” Error, Hub Transport Server: Resolving ‘Failed to Reach Running Status’, and Enable Virtualization in Windows: Fixing VirtualBox’s 32-bit Option.

Remove Stale DC From Sites and Services (Optional)

This step is consdered optional as you can decide to perform a clean demotion. Removing a DC from Sites and Services does not fully clean AD metadata. If the server is still live, this could cause replication issues or lingering references elsewhere.

Only perform this if the DC is permanently offline. As a blogger, I wish to show you hw to clean DNS and stale SRV/CNAME records in _msdcs. To do this, navigate to Sites, Default-First-Site-Name and Servers.

On the prompt, please confirm it. Shortly, the Server Object/NTDS settings object will be gone.

Please see Domain Name System Protocol: Client Registration Issue, How to fix VMware and HyperV are not compatible, and What are the different types of DNS Records.

Remove stale GUID-based CNAME and SRV records for the decommissioned DC

Note: Since we did not perform a clean demotion, some Active Directory metadata for that domain controller will remain. This forced removal does not automatically remove DNS records; any stale SRV and CNAME entries in the _msdcs.<domain> zone must be cleaned manually to prevent replication and authentication issues.

The _msdcs.techdc01.techdirectarchive.com zone (Microsoft DNS integrated with AD) contains SRV records for all DCs. Each DC must register its SRV records here to be discoverable in AD. If stale entries exist (TechDC02) since we did not do proper demotion due to troubleshooting error on “ADDS already contain a computer account“. I will therefore proceed and remove the alias record.

As you can see, there is a broken “_msdcs DNS reference to an old domain controller GUID” which occurred due to the swing migration we performed and the metadata was not fully cleaned.

Verify Known Domain Controllers to AD

Now on TechDC02, run the command below to retrieve information about domain controllers in your Active Directory environment.

Get-ADDomainController -Filter *

When you run it, it should return the following details as shown in the image:

• Hostname (Name)
• IPv4/IPv6 address
• Site location
• Domain name
• Whether it’s a Global Catalog
• Whether it holds FSMO roles etc.

Re-register DNS for TechDC02

ipconfig /registerdns
net stop netlogon
net start netlogon

This will recreate the below records

_ldap._tcp.dc._msdcs
_kerberos._tcp.dc._msdcs
GC records

Now, I have determined that, reinstalling this DC will be the best way to go about this. Therefore, I will proceed and remove the ADDS role in the ext step.

Remove ADDS Roles

Having done everything to fix this issue and no way around it. We will have to rebuild a new server for our Domain Controller. Therefore, we will have to remove the ADDS binaries correctly. This can be done via the remove Roles and Features via the Server Manager or with PowerShell or via the command line.

If you need to remove ADDS from this server using the command line, you can do so by executing one of the commands below.

Uninstall-ADDSDomainController -ForceRemoval -DemoteOperationMasterRole -Force

Uninstall-ADDSDomainController -ForceRemoval:$false -DemoteOperationMasterRole:$false -LocalAdministratorPassword (ConvertTo-SecureString "YourPass123!" -AsPlainText -Force) -Restart

Uninstall-ADDSDomainController -ForceRemoval:$false -DemoteOperationMasterRole:$false -SkipPreChecks

Active Directory Domain Services (ADDS) removal is n progress.

Please see Linux System Update: Upgrade vs. Dist-upgrade Differences, How to Find the Pathname of a Mapped Network Drive, and how to Import PST file into Exchange Server 2016.

Clean Up Stale Metadata

As mentioned above, we have to clear DNS Ghosts in the _msdcs.techdc01.techdirectarchive.com zone in DNS Manager. To do this, open DNS Manager and remove any entries for TempDC and TechDC02. Especially the below which are available in the _msdcs.techdc01.techdirectarchive.com and continue to troubleshoot.

Forward Lookup Zones
_msdcs.techdc01.techdirectarchive.com
→ dc
→ domains
→ gc

We have removed the CNMAE above but wanted to add the image here as it covers detailed cleanup section in this environment.

techdc02.techdirectarchive.com (NS) should be removed as well.

The below SRV reocrds must be removed as well.

Also, do the same for TempDC as shown below.

As mentioned before, do this for ldap as well

All records for TechDC02 must be removed. Delete the record as shown below.

For the reverse lookup record, also proceed and remove the lingeria records as shown below.

Perform DC Health Check

Now that the cleanup has completed. We can perform to determine if there are errors and also dcdiag /v to determine the health.

repadmin /showrepl

From the test on the domain controller TECHDC01, the initial connectivity and advertising tests passed. But the system flagged a significant failure in the DFSREvent test.

The error “DFS Replication service is stopping communication with partner TECHDC02” is expected in this scenario. The domain controller TechDC02 has been decommissioned, and its metadata has been properly cleaned up. This warning is acceptable because the current replication topology still references the old DC, and replication has not yet completed. Once you force a replication sync, the topology will update, and the replication status will reflect the current environment correctly.

Please see Outlook Data File: Fix PST Error – Exceeded Maximum Large Items, How to run the Cisco ASDM launcher, and The trust relationship between this workstation and the primary domain failed.

Perform Domin Join

At this stage, a new server has been setup and the post OS instllation performed. As you can see below, an error was prompted “An Active Directory Domain Controller (AD DC) for the domain could not be contacted”.

Re-register DNS for TechDC01 and also force DNS registration witht the commands below. This registers the A record in the domain DNS zone etc., as shown in the image below.

Please see Map a Network Drive: How to mount a Network Drive, Email Size Limits: Boost for High Profile Users in Exchange 2010, and Clone a Proxmox Container: CT Restoration Guide.

Restart net logon and Verify DNS Record exists

We can also verify the Domain Name and DC holding the FSMO Roles. To do this, run the PowerShell command below to verify the right domain name

(Get-ADDomain).DNSRoot

You can check if all DNS records exists by running the command below

dcdiag /test:dns /v

To also force the re-registration of DNS records, run th below command.

net stop netlogon

net start netlogon

When Netlogon starts, it automatically creates all the critical SRV records such as

_ldap._tcp.dc._msdcs.domain
_kerberos._tcp.dc._msdcs.domain
_gc._tcp.domain

The specified server is not available

Now that we are done cleaning off the lingering metadata, we have t focus now on fixing the error “The specified server is not available,” check your DNS settings again to ensure Techdc02 is pointing to TechDC01 as its Primary DNS

Never use the router’s IP “192.168.2.1“. Since 192.168.2.1 is a standard home router, it does not know how to resolve _ldap._tcp.dc._msdcs.techdc01.

If you plan to promote this server again as a domain controller (as in my case), you can specify a loopback address (127.0.0.1) in the Alternate DNS field. This ensures the server can resolve DNS queries locally during promotion. However, the primary DNS should still point to an existing, functioning domain controller to avoid replication or name resolution issues

If you set 127.0.0.1 as the only DNS entry on a new DC, it may fail to replicate because it will look at its own (empty) DNS database for the SRV records of its partners. Always ensure it has a path to a “known good” DNS server during the setup phase.

Now, attempt showing the server to the DC again. This should be successful.

We have succssfully joined the new server to the domain and we can now proceed with other workflow.

Upon joining the server ti the domain, you will be prompted to restart in order to correctly apply the changes.

You can now force replication again

How is repadmin /syncall different form repadmin /syncall /AdeP?

Here syncall triggers replication from the current DC. It syncs naming contexts (partitions) with its direct replication partners and uses the below default behavior:

• Pull-based replication
• Limited scope (no forced cross-site unless already scheduled

The syncall /AdeP adds the following flags by syncing all partitions (Domain, Configuration, Schema, and DNS zones)

Verify replication from TechDC01

repadmin /showrepl

Verify replication from TechDC02

From the command below. You can see that the fails/total drops to 0 / 5. This means, we can move those FSMO roles back to TECHDC01.

repadmin /replsummary

Verify the Domain Name and DC holding the FSMO Roles

To do this, run the PowerShell command below to verify the right domain name

(Get-ADDomain).DNSRoot

To verify the server holding FSMO roles, run the command below

netdom query fsmo

Now, you should be able to move the fsmo roles with any other the commands already mentioned.

Move-ADDirectoryServerOperationMasterRole -Identity TechDC02 -OperationMasterRole 0,1,2,3,4 -Force

As you can see, the FSMO roles has now been moved to TechDC02. I will proceed and demote TechDC01, install a new VM, install the ADDS Roles and Features, configure TCP parameters and join device to domain etc. When DC01 is running, determine if you should transfer the FSMO roles back to TechDC01 based on the server hardware.

FAQs

I hope you found this article on how to “Fix unable to contact Server: This may be the server does not exist” very useful. Please free free to leave a comment below.