Fixing RPC_S_UNSUPPORTED_NAME_SYNTAX (0X000006C9)

1. DNS Suffix Mismatch (Most Common)

Nine times out of ten, this error pops up when a client or server tries to connect to a remote machine using a fully qualified domain name (FQDN) but the target's DNS suffix doesn't match what the source expects. I see this a lot with domain controllers in multi-domain forests or after migrating DNS zones.

Here's the scenario: A Windows Server 2019 member server tries to contact a DC in a child domain using dc.child.domain.local, but the client's DNS suffix search list doesn't include child.domain.local. RPC chokes on the name format and throws 0X000006C9.

Check the client's DNS suffix:

ipconfig /all | find "DNS Suffix"

If it's blank or wrong, open the network adapter properties, select Internet Protocol Version 4 (TCP/IPv4), click Advanced, then the DNS tab. Make sure "Append primary and connection specific DNS suffixes" is checked, and list any additional suffixes under "Append these DNS suffixes".

For domain-joined machines, run this to force the correct suffix:

reg add "HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters" /v Domain /d domain.local /f
reg add "HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters" /v SearchList /d "domain.local,child.domain.local" /f

Reboot after. That fixes about 60% of cases alone.

2. WINS or NetBIOS Name Resolution Failure

When the name being resolved is a NetBIOS name (single-label, no dots) and WINS is missing or misconfigured, RPC falls over. This is common in mixed environments with older apps that still use NetBIOS.

Check WINS settings:

Open the adapter properties, go to IPv4 > Advanced > WINS. If you have a WINS server, make sure it's correct. If you don't use WINS, disable NetBIOS over TCP/IP entirely — it removes the dependency. Select "Disable NetBIOS over TCP/IP".

Alternatively, verify the NetBIOS name resolves via nbtstat:

nbtstat -a ServerName

If it fails, check the LMHOSTS file in C:\Windows\System32\drivers\etc\lmhosts. Remove old or duplicate entries. A stale LMHOSTS entry pointing to a wrong IP is a classic hidden cause.

If you can't disable NetBIOS, register the failing server's NetBIOS name in DNS as a host (A) record. That way the client falls back to DNS when WINS fails. But honestly, disabling NetBIOS is cleaner unless you have legacy dependencies.

3. Group Policy Blocking RPC Name Resolution

Less common but I've seen it blow up after a security audit. Group Policy can restrict the RPC name syntax that clients accept. Specifically, the policy "Network access: Named Pipes that can be accessed anonymously" and "Network access: Shares that can be accessed anonymously" can interfere if they're too restrictive.

Check this policy:

Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options

Look for "Network security: Allow LocalSystem to use computer identity for NTLM". Set it to Enabled. Also check "Network access: Let Everyone permissions apply to anonymous users". Set it to Enabled temporarily to test — if the error goes away, you know the GPO is the culprit. Then refine the policy to allow only what's needed.

Another common GPO offender is the "Restrict Remote RPC" setting under Computer Configuration > Administrative Templates > System > Remote Procedure Call. If it's set to "Enabled" with a custom restriction string, it can reject valid name formats. Change it to "Not configured" or set the restriction string to O:BAG:SYD:(A;;RPCWDM;;;AU) which allows authenticated users.

Run gpupdate /force and test.

Quick-Reference Summary

If none of these work, run a network trace using Wireshark on the client. Filter for rpc and dns. You'll usually see the client attempting a DNS query that fails or gets a response with a name format the RPC stack doesn't expect. That's your smoking gun.