Fix: Unable to Find a Default Server with Active Directory Web Services Running

The most popular PowerShell module for managing Active Directory (RSAT-AD-PowerShell) accesses AD DS through Active Directory Web Service (ADWS) API interface running on the domain controller. If this service cannot be contacted, the error Unable to find a default server with Active Directory Web Services running will appear when you try to import the Active Directory module or run its cmdlets.

PowerShell 7 compatibility

Keep in mind that the ActiveDirectory module is a Windows PowerShell/RSAT module and is not a native PowerShell 7 module. On Windows, PowerShell 7 can load it through the Windows PowerShell compatibility layer:

Import-Module ActiveDirectory -UseWindowsPowerShell

This creates a compatibility session (WinPSCompatSession) with Windows PowerShell 5.1. If the module is not available or cannot be loaded from PowerShell 7, AD cmdlets such as Get-ADUser and Get-ADDomainController may fail before ADWS connectivity can be tested.

To check which PowerShell version you are using, run the command below:

$PSVersionTable.PSVersion

If you are troubleshooting this error from PowerShell 7, first you need to check if the ActiveDirectory module loads successfully before investigating ADWS connectivity.

What is Active Directory Web Services (ADWS)?

ADWS is a built-in domain controller service introduced in Windows Server 2008 R2 that runs on every DC (whether RODC or RWDC). Clients (including the AD PowerShell module) communicate with the Active Directory Web Services on DC over TCP port 9389.

Common ADWS Errors in PowerShell

If the service cannot be contacted, the following errors may occur:

• WARNING: Error initializing default drive: ‘Unable to find a default server with Active Directory Web Services running’

  

• Unable to contact the server. This may be because this server does not exist, it is currently down, or it does not have the Active Directory Web Services running. CategoryInfo: ResourceUnavailable, ADServerDownException

  

Troubleshooting Active Directory Web Services Connectivity

Before fixing Unable to find a default server with Active Directory Web Services running, first you should understand how this error occurs.

It usually happens when the client cannot discover/communicate with a DC that has Active Directory Web Services (ADWS) available. The causes of the error usually fall into one of the following categories:

• The client is facing DC discovery issues (DNS config is incorrect/unreachable LOGONSERVER)
• Problems with network connectivity (TCP port 9389 blocked/filtered)
• ADWS service problems (service stopped/misconfigured on the DC)
• Compatibility issues (target DC does not support ADWS)

Important. Keep in mind that ADWS availability is not discovered via a dedicated DNS SRV record. Instead, the client determines whether a DC supports AD Web Services through the DC Locator process using CLDAP (Netlogon) responses, where the DC advertises ADWS capability through specific capability flags.

By default, the RSAT-AD-PowerShell module connects to a DC selected by the DC Locator process.

This DC is often exposed through the LOGONSERVER environment variable. However, it’s important to understand that LOGONSERVER is not manually configured, it reflects the DC that was assigned during the user logon.

In case this DC is unavailable, misconfigured, or does not have ADWS running, PowerShell cmdlets may fail even in case other DCs are healthy.

To identify which of these categories causes the problem, try the steps below.

Step 1. Verify domain controller discovery (LOGONSERVER)

Check the value of this environment variable on your computer:

$env:LOGONSERVER

Step 2. Check basic connectivity to the DC

Before testing ADWS (port 9389), you need to ensure that the DC is reachable at the basic network level.

To check DNS resolution, use the command:

Resolve-DnsName DC02.contoso.com

To test ICMP connectivity:

Test-Connection DC02.contoso.com -Count 2

In order to verify core AD ports, use the following commands:

Test-NetConnection DC02.contoso.com -Port 389 # LDAP
Test-NetConnection DC02.contoso.com -Port 88 # Kerberos

Step 3. Test network connectivity to ADWS (port 9389)

If the correct DC is selected, check if the ADWS port is reachable:

Test-NetConnection DC02.contoso.com -Port 9389

If the command returns TcpTestSucceeded: False, it means the connection is blocked by the firewall, the ADWS service is not running, or the DC is down.

In case port 9389 is blocked, you need to check the Windows Firewall rule on the DC:

Get-NetFirewallRule -DisplayName "*Active Directory Web Services*" |
Select-Object DisplayName, Enabled, Direction

In case the rule is disabled, you need to enable it:

Enable-NetFirewallRule -DisplayName "Active Directory Web Services (TCP-In)"

Note that in enterprise environments, you should manage firewall rules centrally using Group Policy (instead of enabling them manually on each DC). To enable the ADWS firewall rule group, navigate to Computer Configuration → Policies → Windows Settings → Security Settings → Windows Defender Firewall with Advanced Security → Inbound Rules. Here you need to enable the predefined rule group Active Directory Web Services.

Step 4. Test another DC explicitly

In case the currently discovered DC is unavailable or does not provide ADWS, you should test another DC explicitly with the -Server parameter. This bypasses automatic DC selection for the individual AD cmdlet and lets you determine whether the problem is specific to the originally discovered DC.

Here is an example:

Get-ADUser -Filter * -Server DC02.contoso.com

If this command succeeds, the problem is likely related to DC discovery or the previously selected DC rather than the Active Directory PowerShell module itself.

Step 5. Discover available DCs with ADWS

Now you need to identify DCs that are available and running ADWS:

Get-ADDomainController -Discover -Service ADWS

The -ForceDiscover parameter clears cached DC info and forces a new DC discovery. Use it when the first discovery returns an unexpected DC or when DC selection may be affected by recent network/AD topology changes:

Get-ADDomainController -Discover -Service ADWS -ForceDiscover

If your client device is not joined AD, you can manually specify the DC where ADWS is running the ADWS role and request domain user credentials in the PowerShell command. Specify the target domain controller running ADWS by using the -Server DC_FQDN_or_IP_address parameter and prompt for user credentials. For example:

Get-ADUser -Filter * -Server DC02.contoso.com -Credential (Get-Credential)

Note that the -Server parameter works with most AD cmdlets when you need to target a specific DC.

In case you want to check ADWS status on all DCs, perform the following command:

Get-ADDomainController -Filter * | ForEach-Object {
$dc = $_.HostName
$result = Test-NetConnection $dc -Port 9389 -WarningAction SilentlyContinue
[PSCustomObject]@{
DC = $dc
ADWS_Port_9389 = $result.TcpTestSucceeded
}
}

Step 6. Verify ADWS service on the domain controller

If ADWS service doesn’t respond on a DC, ensure service is running.

1. Open the services.msc snap-in;
2. Check that the Active Directory Web Services is in a Running state.

   

3. Start it if the service is stopped. If the service is running, restart the DC or restart the service with the PowerShell command:
   

   Restart-Service -name ADWS -verbose

   
4. Verify if the ADWS service is configured to start automatically:
   

   Get-Service ADWS | Select-Object -Property Name, StartType, Status

   

   If necessary, change the startup type to automatic:

   Set-Service -Name ADWS -StartupType Automatic

5. As an alternative to manually checking services in services.msc, you can use the built-in AD diagnostic test to quickly verify the status of key DC services (including AD DS, DNS, Netlogon, and ADWS):
   

   dcdiag /test:services

Wrapping up

So, to fix Unable to Find a Default Server with Active Directory Web Services Running, you can follow our quick diagnostic flowchart:

In most of the cases the problem is either a blocked port 9389, a stopped ADWS service, or incorrect DC discovery. You should start with Step 1 and work through the steps in order.

$env:LOGONSERVER