DCOM: use target IP (not FQDN) for COSERVERINFO.pwszName on RemoteCreateInstance

[chemrid]

Fixes the SCM activation failure described in #11.

When DcomClient.ConnectTo addresses a target by FQDN, IRemoteSCMActivator::RemoteCreateInstance fails with E_FAIL (0x80004005): the FQDN flows through ScmActivatorClient into COSERVERINFO.pwszName and the SCM treats it as a foreign/remote server. Passing null/empty instead yields E_INVALIDARG (0x80070057).

This change resolves the host to its IP for the activation server name (the RPC bind/endpoint is unchanged):

string activationName = host;
try { var addrs = System.Net.Dns.GetHostAddresses(host); if (addrs.Length > 0) activationName = addrs[0].ToString(); } catch { }
var scmClient = new ScmActivatorClient(dcom, activationName);

Verified with NTLM end-to-end (WMI query + full software inventory) against a DC and a member server addressed by FQDN; the IP-addressed path is unchanged.

Correction: an earlier version of this description also claimed verification over Kerberos. That was wrong. In my environment Kerberos for DCOM does not complete the RPC bind — it fails separately with RPC_S_SEC_PKG_ERROR (0x721) when Kerberos is the only mechanism; the apparent success was NTLM fallback inside SPNEGO. That Kerberos bind problem is independent of this activation fix and is still under investigation.

[codewhisperer84]

Have you tried this with the latest pre-release build? Titanis was encoding one of the fields documented as being ignored with a token value, which appeared to actually be a buffer size hint, and I think this imposed a limitation on the length of the host name at around 16 characters, which coincidently seemed to match up with all host/IP vs. FQDN scenarios, depending on the length of the FQDN. I'm curious if this would also fix your FQDN scenario.

[chemrid]

Correction to the description: I removed the claim that this was verified over Kerberos. This fix is verified only for the NTLM-by-FQDN activation path. A controlled test (SPNEGO offering Kerberos only, no NTLM) shows the Kerberos DCOM bind fails with RPC_S_SEC_PKG_ERROR (0x721) on every target — so the earlier "works with Kerberos" result was actually NTLM fallback. The Kerberos bind issue is separate from this COSERVERINFO.pwszName activation fix.