How to Configure DCOM for Cloudhouse Compatibility Containers

Save to PDF

Applies to: Compatibility Containers

06/06/2019 Cliff Hobbs   ID: 383000

Purpose

The purpose of this article is to detail how to configure an application that uses the Distributed Component Object Model (DCOM) in the scenario where the DCOM Client and Server components are running in different Cloudhouse Compatibility Containers™ on different computers.

Note

This article only applies to Containers created from release 1903 onwards.

See DCOM support in Cloudhouse Compatibility Containers for background information on DCOM and the scenarios currently supported by Cloudhouse Containers; and How to troubleshoot DCOM in Cloudhouse Compatibility Containers for details of how to troubleshoot DCOM.

Prerequisites

To complete this process, you need:

  • The DCOM server module packaged into a Cloudhouse Container that will run on one computer.
  • The DCOM client module packaged into a separate Cloudhouse Container that will run on a different computer.
  • Details of the DCOM security setup in the current environment the Containers are replacing, such as:
    • The users that currently have access.
    • Any permissions.
    • The names of the servers that both the DCOM client and server modules are running on.
    • The ports in use.
    • Any firewalls between the client and server modules. 

Note

We recommend using Notepad++ to edit XML files.

Step-by-step process

There are four parts to configuring DCOM:

Configuring the DCOM Server Container

To configure the Container containing the DCOM server:

Note

For this article, the Container containing the DCOM server is running a DCOM server application called TestCOMServer64.exe.exe

  1. On the computer running the Container that contains the DCOM server application, navigate to the Container folder.
  2. Open ComRegistryKeys.xml in a text editor.
  3. Enable COM (which is disabled by default) by changing Enabled="false" to Enabled="true"
    For example:
    <?xml version="1.0" ?> 
    <COM xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" Enabled = "true">
      <OutOfProcServers>
        <OutOfProcServer>
          <Path>%DefaultDir%\ProgData\Program Files\TestComServer\TestCOMServer64.exe</Path> 
        </OutOfProcServer>
      </OutOfProcServers>
    </COM>
  4. Create a firewall exception for the DCOM server application to add its deployed path to any firewalls in between the computer running the DCOM server application and the computer running the DCOM client.

Note

Leave ComregistryKeys.xml open as it is required later in this process. 

  1. Open AppAcceleratorV.clc in a text editor.
  2. Search for the <Features> section.
  3. Verify a line for the COMVirtualization is present which enables this feature. If it is not, add the line and save the AppAcceleratorV.clc file
    <Features>
       <Feature>COMVirtualization</Feature>
    </Features>

Now we need to find out the CLSID (also known as the class ID) which is the globally unique identifier that identifies a COM class object, which in this case is the COM server application.

To do this:

  1. Open ComRegistryKeys.xml in a text editor (if it isn't already).
  2. Search this file for the name of the DCOM server application. In our example, we need to search for TestCOMServer64.exe
    For example:
      <Write>
        <KeyName>HKEY_CURRENT_USER\Software\Cloudhouse\AppAccelerator\%GUID%\HKLM\SOFTWARE\Classes\CLSID\{67c9e120-9365-4a43-878e-c8f17d5ef51e}\LocalServer32</KeyName>
        <ValueName />
        <Value ValueType="String">%DefaultDir%\ProgData\Program Files\TestComServer\TestCOMServer64.exe</Value>
      </Write>
  3. Make a note of the value of the CLSID for the DCOM server application. In our example, this is:
    {67c9e120-9365-4a43-878e-c8f17d5ef51e} as shown below:
      <Write>    <KeyName>HKEY_CURRENT_USER\Software\Cloudhouse\AppAccelerator\%GUID%\HKLM\SOFTWARE\Classes\CLSID\{67c9e120-9365-4a43-878e-c8f17d5ef51e}\LocalServer32</KeyName>
        <ValueName />
        <Value ValueType="String">%DefaultDir%\ProgData\Program Files\TestComServer\TestCOMServer64.exe</Value>
      </Write>

Note

Check the remainder of the ComRegistryKeys.xml for other instances of the same DCOM server application, but with different CLSIDs. Make a note of any additional CLSIDs for the application.

The next part of the process is to find out the PackageID of the Container containing the DCOM server. To do this:

  1. On the computer running the Container that contains the DCOM server application, navigate to the Container folder.
  2. Open the chmetadata.json file in a text editor, such as Notepad ++.
  3. Make a note of the value specified for the PackageID entry. In our example, this is TestCOMServer_2136
    For example:
    {
      "PackageId": "TestCOMServer_2136",
      "IsTelemetryEnabled": true,
      "TelemetryApiUrl": "https://telemetry.cloudhouse.com/telemetry",
      "Icon": "%DefaultDir%\\Cloudhouse.Container.Run.exe",
      "Name": "TestCOMServer",
      "Version": "",
      "Publisher": "",
      "AuthUrl": "https://auth.cloudhouse.com/oauth/token",
      "UsageReportingUrl": "https://containers.cloudhouse.com/api/UsageEvents"
    }

Now we have the CLSID(s) and PackageID of the DCOM server components, we can configure the DCOM client with them, as detailed in the Configuring the DCOM Client Container section.

The final part of the server configuration process is to deploy the DCOM server Container using Cloudhouse.Container.Deploy.exe as a machine-based deployment as detailed in Machine-Based Deployment.

This completes configuring the DCOM server Container. Next, we need to configure the Container containing the DCOM client.

Configuring the DCOM Client Container

To configure the Container containing the DCOM client:

Note

For this article, the Container containing the DCOM client is running a DCOM client application called TestCOMClient64.exe

  1. Navigate to the Container folder.
  2. Open AppAcceleratorV.clc in a text editor.
  3. Search for the <Features> section.
  4. Verify a line for the COMVirtualization feature is present which enables this feature. If it is not, add the line and save the AppAcceleratorV.clc file. 
    <Features>
       <Feature>COMVirtualization</Feature>
    </Features>
  5. In your text editor, search for the <COM> section of the AppAcceleratorV.clc file.
  6. Add a line for the CLSID noted in the Configuring the DCOM Server Container section, in the following format:

    <CLSID ID="{<cls_id_of_com_server>}" ExternalPackageId="<packageid_of_com_server>"/> 

    where {<cls_id_of_com_server>} is the CLSID of the DCOM server component and <packageid_of_com_server> is the Package ID of the Container running the DCOM server.

    For our example, the line will be:

    <COM>
      <CLSID ID="{67c9e120-9365-4a43-878e-c8f17d5ef51e}" ExternalPackageId="TestCOMServer_2136"/>
    </COM>
  1. Repeat Step 6 to add any additional CLSIDs for the DCOM server application.

Changing the remote DCOM Server name

Next, we need to change the name of the remote DCOM server name which is achieved in either of the following ways:

Changing the remote DCOM server name through the AppRegistry.xml

To change the remote DCOM server name through AppRegistry.xml:

  1. On the computer running the Container containing the DCOM client application, navigate to the Container folder.
  2. Open AppRegistry.xml in a text editor.
  3. Search for RemoteServerName until you locate a line containing the CLSIDs for the DCOM server application.
  4. Change the value of <ip_addressto the IP address of the server running the DCOM server. For example, if the IP address of the DCOM server is 192.168.8.14, the line would be:
    <Write>
      <KeyName>HKEY_CURRENT_USER\Software\Cloudhouse\AppAccelerator\%GUID%\HKCU\Software\Classes\AppID\{67c9e120-9365-4a43-878e-c8f17d5ef51e}</KeyName>
      <ValueName>RemoteServerName</ValueName>
      <Value ValueType="String">192.168.8.14</Value>
    </Write>
  5. Save the file.

Changing the remote DCOM server name through AppAccelerator.clc

If the name or IP address of the DCOM server has been hardcoded into the DCOM client, you can use the NetworkRedirection feature to easily redirect any calls made by the DCOM client from the old DCOM server to the new, containerised version through the AppAccelerator.clc file.

To change the remote DCOM server name through AppAccelerator.clc:

  1. On the computer running the Container containing the DCOM client application, navigate to the Container folder.
  2. Open AppAcceleratorV.clc in a text editor.
  3. Verify the NetworkRedirection Feature is enabled.
    <Features>
             <Feature>NetworkRedirection</Feature>
    </Feature>
  4. Copy the following entry to your the AppAccelerator.clc file
    <Network>
       <Connect>
          <From><IP>ip_address_of_old_DCOM_server</IP></From>
          <To><IP>ip_address_of_new_DCOM_server</IP</To>
       </Connect>
    // OR
       <DomainName>
          <From>fqdn_of_old_DCOM_server</From>
          <To>fqdn_of_old_DCOM_server</To>
       </DomainName>
    </Network>
  5. Change the values to the relevant values for your environment.
Item Description
ip_address_of_old_DCOM_server IP address of the old DCOM server
ip_address_of_new_DCOM_server IP address of the new DCOM server
fqdn_of_old_DCOM_server Fully Qualified Domain Name (FQDN) of the old DCOM server
fqdn_of_new_DCOM_server FQDN of the new, containerised DCOM server

For example, if the old IP address is 192.168.3.44 and the IP address of the new DCOM server is 193.163.9.81 you would configure the file as follows:

<Network>
    <Connect>
        <From><IP>192.168.3.44</IP></From>
      <To><IP>193.163.9.81</IP</To>
   </Connect>
</Network>

Likewise, if the old FQDN of the DCOM server is dcom.legacy.com and the FQDN of the new DCOM server is dcom.cloudhouse.com you would configure the file as follows:

<Network>
   <DomainName>
      <From>dcom.legacy.com</From>
      <To>dcom.cloudhouse.com</To>
   </DomainName>
</Network>

Note

You only need to configure either the IP address or the FQDN.

  1. Save the file.

The final part of the server configuration process is to deploy the DCOM client Container using Cloudhouse.Container.Deploy.exe as detailed in Deploying Containers.

This completes configuring the DCOM client Container. We now need to confirm the two DCOM applications in their Containers can communicate with each other via DCOM.

Testing DCOM works

To test DCOM works between the Containers:

  1. Verify both the server and client DCOM Containers have been configured as detailed above and are running/have been deployed.

Tip

You don't need to deploy the Containers to test them. Provided they are running, you should be able to test them.

  1. Invoke a process on the DCOM client application to verify it can communicate successfully with the DCOM server application.

Note

In the event of issues, see How to troubleshoot DCOM in Cloudhouse Compatibility Containers for troubleshooting information.

Source:
Was this article helpful?

Table of Contents

    Can't find what you're looking for?

    Contact Support