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 SQL1.Fabrikam.com 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)
NetworkAddress: 192.168.1.100[49299]
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 192.168.2.200 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:
[MS-DCOM] 2.2.19.3
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 <https://msdn.microsoft.com/en-us/library/windows/desktop/aa378456(v=vs.85).aspx>