Fix 0X0000085E: Remote API not supported on server

Cause 1: SMB version mismatch between client and server

I've seen this error hundreds of times, and nine times out of ten it's an SMB protocol mismatch. The error 0X0000085E (which maps to NERR_InvalidAPI) occurs when your client tries to call a remote API — usually something like NetServerEnum or NetShareEnum — and the server responds with 'I don't support that API.' But the server does support it — it's just that the SMB dialect negotiation failed first.

This happens most often when a Windows 10 client (build 22H2 or later) talks to an older Windows Server 2012 R2 box. Microsoft tightened SMB signing and encryption defaults in recent updates. If the server doesn't match, the API call gets rejected before it even starts.

Fix: Force SMB 2.0 on the client (temporary)

Open PowerShell as Admin and run:

Set-SmbClientConfiguration -EnableSMB2Protocol $true -Force

Then try your command again. If it works, the server is stuck on SMB 2.0 and your client tried SMB 3.1.1. The permanent fix is to update the server to support SMB 3.0 or later — ideally Windows Server 2016+.

But don't leave SMB 3 disabled. Re-enable it after testing with:

Set-SmbClientConfiguration -EnableSMB2Protocol $false -Force

Then either upgrade the server or configure the client to negotiate down gracefully. You can do that by setting the Smb2CreditsMin registry value — but honestly, just upgrade the server if you can.

Cause 2: Server service is disabled or blocked

Second most common cause: the Server service on the remote machine isn't running, or a firewall is blocking ports 445 and 139. I've had sysadmins swear the service was running — only to find it set to Manual and stopped after a reboot.

The error pops up when you run tools like net view or Get-SmbShare against a remote server. The API call hits the server but the service that handles it — srv2.sys on the server side — isn't listening.

Fix: Check the Server service and firewall

On the remote server, run:

Get-Service -Name Server | Select-Object Status,StartType

If it's not running, start it:

Set-Service -Name Server -StartupType Automatic -Status Running

Then check the Windows Firewall. Run this to be sure:

New-NetFirewallRule -DisplayName "SMB Inbound" -Direction Inbound -Protocol TCP -LocalPort 445 -Action Allow

I prefer using netsh advfirewall for older servers, but the PowerShell cmdlet works on 2012 R2 and later.

One weird edge case: if the remote server is a Domain Controller and you've hardened it by disabling the Server service (which some security guides recommend), you'll get this error when trying to enumerate shares or printers. Don't disable the Server service on a DC. Instead, limit SMB via GPO.

Cause 3: Remote Registry service is missing or stopped

This one trips up people who are trying to read registry keys remotely. The 0X0000085E error can appear if the Remote Registry service isn't running on the target machine. But here's the kicker — it's not just the service. The API calls that depend on it (like RegConnectRegistry) get blocked.

I've seen this on freshly deployed Windows Server 2022 boxes where the Remote Registry service defaults to Disabled for security. If you need remote registry access for management tools (like Invoke-Command with registry operations), you'll hit this wall.

Fix: Enable Remote Registry (with caution)

On the remote server, run:

Set-Service -Name RemoteRegistry -StartupType Automatic -Status Running

Then test your API call again. But think before you leave it enabled — it's a known attack vector. If you only need it temporarily, set it to Manual and start it on demand:

Set-Service -Name RemoteRegistry -StartupType Manual

Also check the registry key HKLM\SYSTEM\CurrentControlSet\Control\SecurePipeServers\winreg. If the AllowedPaths value is too restrictive, remote reads fail even with the service running. I'd set Machine to include System\CurrentControlSet\Services\LanmanServer if you're troubleshooting SMB APIs.

Quick-reference summary table