Another Case of The RPC server is unavailable – Cross Domain DCOM Call Failure


Visual Overview -



Technical Overview


SSMS.exe here successfully calls the EndPointMapper on and is returned the network address SSMS.exe may call back on to work with the DCOM server.

This is the successful call to RemoteCreateInstance, after 10 seconds, client then aborts. So why?  (shortended)

- ScmReply:

- OxidBindings:

- Bindings:

- StringBindings:

TowerId: 7 (0x7)

NetworkAddress: sql1[49299]

- StringBindings:

TowerId: 7 (0x7)



SSMS.exe will choose the first address in list of network addreses and so ends up trying to call: SQL1. Now because SQL is the name of a local machine, DNS correct returns the IP and so the next outbound connection will be headed to the wrong SQL instance. This connection must fail.

If you’re looking at the network tracing, it may look like an abrupt end, caused by the client resetting the connection after having several successful calls to the correct server. Between those calls will be the new session with DNS and the local SQL machine.

This example can play out with other DCOM applications however, in my experience this is a rare situation.

Currently, there are only two workarounds:

1. Rename one of the machines

2. Use a host file entry to direct the netBIOS name to the address desired

General Lesson

Try not to duplicate server names between your domains; though ideally, the FQDN should be returned from the DCOM.


Further Reading

DCOM Servers are responsible for registering calling RpcEpRegister and supplying Binding details or relying on existing Bindings. Control over the Binding name then is due to the DCOM server implementer.

Research Details:


STRINGBINDING.aNetworkAddr.servername = MUST BE one of the following{ A NETBIOS Name, FQDN, IPv4, IPv6, } *removed other requirements to shorten output for our example.

From <>

Comments (0)

Skip to main content