1

Disclaimer: Yes, I think this questions boils down to understanding some DCOM basics and what VBS CreateObject actually does/needs:

I have a 3rd party application that offers an automation interface via (D?)COM. The interface is automatically registered when we install the application and it works fine when running simple VBS scripts locally:

This works fine on the same machine:

Dim oAppApi

WScript.Echo "Hello, try to connect ..."
Set oAppApi = CreateObject("theapp.theapp") ' Note that this will either start the application or connect to an already started instance
WScript.Echo oAppApi.APIVersion

oAppApi.DisconnectFromTool

This also works on the same machine:

Dim oAppApi

WScript.Echo "Hello, try to connect ..."
Set oAppApi = CreateObject("theapp.theapp", "localhost")
WScript.Echo oAppApi.APIVersion

oAppApi.DisconnectFromTool

This will fail when run on another PC in the same network:

Dim oAppApi

WScript.Echo "Hello, try to connect ..."
Set oAppApi = CreateObject("theapp.theapp", "machineNameWithAppInstalled") ' FAIL: ActiveX component can't create object

What would be neccessary to make this simple VBScript work from the remote machine?

  • Would anything need to be installed on the client machine? (COM proxy DLL or somesuch?)
  • Does the ServerName.TypeNameof CreateObject need to be known on the client side?
  • Do we have to do some DMCOMCnfg magic on the server?

Additional Details:

Since, from what I know of COM, this might depend on how the stuff is registered, here's my "trace" through the registry for "TheApp.TheApp" on the application PC:

[HKEY_CLASSES_ROOT\TheApp.TheApp]
@="com.company.toolAPI.theapp.theapp"

[HKEY_CLASSES_ROOT\TheApp.TheApp\CLSID]
@="{0CBEA087-0CC7-4D15-A659-8B3AC68B82E1}"

[HKEY_CLASSES_ROOT\TheApp.TheApp\CurVer]
@="TheApp.TheApp.7.2"

...


[HKEY_CLASSES_ROOT\TheApp.TheApp.7.2]
@="TheApp.TheApp"

[HKEY_CLASSES_ROOT\TheApp.TheApp.7.2\CLSID]
@="{0CBEA087-0CC7-4D15-A659-8B3AC68B82E1}"

...

[HKEY_CLASSES_ROOT\AppID\{0CBEA087-0CC7-4D15-A659-8B3AC68B82E1}]
@="THEAPP72 Server"
"DllSurrogate"=""
"RunAs"="Interactive User"

...

[HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{0CBEA087-0CC7-4D15-A659-8B3AC68B82E1}]
@="com.company.toolAPI.theapp.theapp"
"AppID"="{0CBEA087-0CC7-4D15-A659-8B3AC68B82E1}"

[HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{0CBEA087-0CC7-4D15-A659-8B3AC68B82E1}\Implemented Categories]

[HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{0CBEA087-0CC7-4D15-A659-8B3AC68B82E1}\Implemented Categories\{62C8FE65-4EBB-45e7-B440-6E39B2CDBF29}]

[HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{0CBEA087-0CC7-4D15-A659-8B3AC68B82E1}\InprocServer32]
@="mscoree.dll"
"ThreadingModel"="Both"
"Class"="com.company.toolAPI.theapp.theapp"
"Assembly"="TheAppCOM, Version=11.0.0.0, Culture=neutral, PublicKeyToken=c9b6e760b808c9f9"
"RuntimeVersion"="v2.0.50727"
"CodeBase"="file:///C:/Company/THEAPP7.2/interface/TheAppCOM.DLL"

[HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{0CBEA087-0CC7-4D15-A659-8B3AC68B82E1}\InprocServer32\11.0.0.0]
"Class"="com.company.toolAPI.theapp.theapp"
"Assembly"="TheAppCOM, Version=11.0.0.0, Culture=neutral, PublicKeyToken=c9b6e760b808c9f9"
"RuntimeVersion"="v2.0.50727"
"CodeBase"="file:///C:/Company/THEAPP7.2/interface/TheAppCOM.DLL"

[HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{0CBEA087-0CC7-4D15-A659-8B3AC68B82E1}\ProgId]
@="TheApp.TheApp"
Martin Ba
  • 37,187
  • 33
  • 183
  • 337
  • 2
    All of the 3 are necessary somehow. On the server, I'd recommend you use a COM+ application as its much easier and powerful than the manual surrogate (DCOMCnfg points to it): https://stackoverflow.com/a/24732010/403671 . On the client you must have a registered proxy, which for an OLE automation-compatible COM object (such as a .NET COM object) can be just a .tlb (but it can also be the full .Dll if it contains the tlb, or if it's dependencies are ok). – Simon Mourier Feb 12 '21 at 17:58

1 Answers1

0

I used RDS.DataSpace to access a 'middle-tier' dcom server.

Example: http://www.oblique.ch/ms/rds25.html#_Toc483670219

softwearmale
  • 1
  • 2