Fix RPC_S_INVALID_NETWORK_OPTIONS 0x6BC (RPC Error 1724)

RPC_S_INVALID_NETWORK_OPTIONS means the RPC client passed a network protocol the server can't use. Usually it's a missing or disabled protocol — fix it fast.

Quick answer: The RPC call is using a protocol sequence the target can't serve (classic culprits: ncacn_np after NetBIOS/SMBv1 got stripped, or ncacn_ip_tcp blocked by firewall). Force the transport, re-enable the missing protocol, or rebind to a working endpoint.

This one bites experienced admins more than newbies, because it usually appears right after a hardening pass. You disable NetBIOS, rip out SMBv1, tighten the firewall, and then some 2016-era line-of-business app or a WMI query from a Nagios box starts throwing 0x000006BC. The RPC runtime is basically saying the client asked for a protocol sequence (ncacn_np, ncacn_ip_tcp, ncacn_http, ncacn_spx) that isn't registered, isn't enabled, or isn't reachable on the server side. It's not a credential issue and it's not a name resolution issue — those throw different codes. This one is purely about the network options in the binding string.

A real scenario I hit twice last year: a customer removed SMBv1 from a file server fleet. A legacy ERP client that talked to the print spooler over ncacn_np (named pipes) started failing intermittently. The spooler service itself was fine. The endpoint mapper was fine. The binding just couldn't complete because the named pipe transport wasn't there anymore for that particular interface. Error 1724 every time.

Fix 1: Confirm which protocol sequence is failing

Don't guess. Turn up RPC diagnostic logging first so you know whether it's np, ip_tcp, http, or something weird.

netsh trace start scenario=NetConnection capture=yes tracefile=C:\rpc.etl
:: reproduce the failure
netsh trace stop

Then open rpc.etl in Event Viewer or Wireshark. You want to see the bind PDU and which protocol sequence the client negotiated. If you can't read ETLs quickly, grab Rpcdump.exe from the Windows SDK and run:

rpcdump /i 10.0.0.5

That lists every endpoint the target's endpoint mapper knows about. If the interface you need only shows ncacn_ip_tcp, but your app is binding ncacn_np, that's your error.

Fix 2: Re-enable the missing protocol on the server

If the client needs named pipes and you stripped NetBIOS or SMBv1, re-enable the minimum required. On modern Windows you don't need SMBv1 for named pipes — but you do need the SMB stack, the Server service, and NetBIOS over TCP/IP (or at least the file and printer sharing binding).

Open ncpa.cpl → adapter → Properties.
Make sure Client for Microsoft Networks and File and Printer Sharing for Microsoft Networks are checked.
In TCP/IPv4 Properties → Advanced → WINS tab → set NetBIOS to Enable NetBIOS over TCP/IP (or Default if WINS is configured).
Restart the Server service and any RPC-heavy service (Spooler, RemoteRegistry, WMI):

net stop spooler && net start spooler
net stop winmgmt && net start winmgmt

Yes, this reopens a hardening hole. The right long-term answer is to migrate the app off ncacn_np, not to keep SMBv1 alive. But for Tuesday at 3pm when payroll is down, this gets you working.

Fix 3: Allow RPC through the firewall properly

If you're binding ncacn_ip_tcp, the classic mistake is opening only TCP 135. Port 135 is just the Endpoint Mapper. The actual RPC call goes to a dynamic port in the 49152–65535 range (or 1024–5000 on older systems). Check your dynamic port range:

netsh int ipv4 show dynamicport tcp

If the range is the default 16384 ports, punch a firewall rule for it on the target, or restrict RPC to a fixed port range via the registry:

HKLM\SYSTEM\CurrentControlSet\Services\Rpc
  Ports = REG_MULTI_SZ
  PortsInternetAvailable = Y
  UseInternetPorts = Y

Then add a matching inbound rule. Reboot or restart the RPC services. Without this, you'll see 0x6BC on remote WMI, remote DCOM, and remote print management — all the usual suspects.

Fix 4: Check the binding string in the app or script

Sometimes it's not the server at all — it's the client hardcoding a protocol. If you're looking at source, the string looks like:

ncacn_ip_tcp:server.domain.com[49680]
ncacn_np:\\server.domain.com[\pipe\spoolss]
ncacn_http:server.domain.com[593]

If the app requests ncacn_http and the server doesn't have RPC over HTTP proxy installed, you'll get 0x6BC. Same with ncacn_spx — that transport is dead, no matter what your 1998 VB6 app thinks. Swap to a supported sequence and rebuild the binding.

Alternative fixes if the above doesn't work

DNS/multi-homed server: If the target has multiple NICs, the endpoint mapper may be returning an IP that isn't reachable from the client. Force the client to bind by DNS name and check HKLM\SOFTWARE\Microsoft\Rpc\ClientProtocols for stale entries.
Kerberos vs NTLM: Sometimes a failing SPN causes the RPC layer to fall back and fail with 6BC on the alternate transport. Run setspn -L on the target and verify the SPN matches what the client is calling.
Disable RPC over HTTP if unused: If RpcProxy is running but not configured, it can hijack bindings. Set the RpcProxy service to Disabled if you don't publish RPC over HTTPS.
Reset the RPC service: As a last resort, restart RpcSs on the server. You'll drop every dependent service briefly — schedule it.

Prevention

Before you harden a server, test every RPC-dependent app in the environment. Most shops have at least one thing talking ncacn_np that nobody documented. Build a lab replica of the hardening GPO, run your monitoring and backups against it for a week, and you'll catch the 0x6BC landmines before they hit production. Also: log RPC client binding failures via HKLM\SOFTWARE\Microsoft\Rpc\Debug with AllocFailures set to 1 during change windows. Cheap, and it saves you hours of packet capture later.