DCOM over internet config problem

Dear COM gurus,

Here is my situation ... I have a VC++ server and a VB client that must communicate over
the internet.

My client and server can talk successfully on the same computer. I've tested it on my local
computer and on the remote system that will eventually host the server. They also talk
successfully on my local network with the client and server apps on different machines.

However, when I try to communicate with the server on a remote system, I get the following
error (from the VB client):
Run-time error '462':
The remote server machine does not exist or is unavailable.

I believe the error must be somewhere in the DCOM configuration or a firewall problem. Is
there a recipe/checklist for configuring DCOM over the internet ? What firewall ports need
to be open ?

In dcomcnfg, I've tried setting the Connection-oriented TCP/IP endpoints to use port 80
on both client and server machines, but that didn't work. I chose port 80 because I know
that traffic can flow through the firewall on that port.

Other dcomcnfg settings are as follows:
Client:
auth level = default
location: run on this computer, run where data is located
security access: allow everyone, interactive, (my user id), network, system
security launch: allow everyone, interactive, (my user id), network, system, users
security config: administrators = full, creator owner = full, everyone = special,
power users = special, system = full, users = read
identity: interactive user
endpoints: use static endpoint = 80 w/ connection-oriented TCP/IP
Server:
auth level = default
location: run on this computer
security access: allow everyone, interactive, (my user id), network, system, administrators
security launch: allow everyone, interactive, (my user id), network, system, administrators

security config: administrators = full, creator owner = full, everyone = read,
interactive = special, system = full
identity: (my user id)
endpoints: use static endpoint = 80 w/ connection-oriented TCP/IP

I hope someone out there can tell me what I'm doing wrong.

Thanks,
Keith Gemeinhart


--
Keith Gemeinhart ([email protected])
Technology Service Corp.
Bloomington, IN
Voice: (865) 692 - 1284
--

The following is from a Backgrounders article.

Hope this helps.
Spectre



COM Internet Services
Marc Levy
Microsoft Corporation

April 23, 1999

Contents
Introduction
A New DCOM Transport Protocol
Configuring the Tunneling TCP Protocol
OBJREF Moniker

Introduction
Component Object Model (COM) Internet Services (CIS) introduces support for a new Distributed COM (DCOM) transport protocol known as Tunneling Transmission Control Protocol (TCP) that allows DCOM to operate over TCP port 80. This allows a client and a server to communicate in the presence of most proxy servers and firewalls, thereby enabling a new class of COM-based Internet scenarios.

In addition to the new DCOM protocol, CIS also provides a new type of simple moniker—the OBJREF moniker—that facilitates the use of COM in Internet scenarios. The OBJREF moniker represents a reference to a running object and has a display name that can, for example, be embedded in an HTML page and bound by an ActiveX® control or client applet.

This article explains what the COM Internet Services are, how they work, and how to configure computers running Microsoft® Windows® to use the services. The article assumes the reader has a basic understanding of distributed COM and the DCOM configuration tool.

A New DCOM Transport Protocol
In many Internet situations, the network connectivity between a client and a server is subject to a number of restrictions. For example:

A proxy server that filters outbound network traffic may gate the client connection to the Internet. This is often the case for applications running in a corporate environment, but it can also apply to applications run by a user connecting to the Internet through an ISP.


A firewall often controls incoming Internet traffic, defining what combinations of network ports, packets, and protocols are accepted to protect the server (or client) network environment.
In practice, the net effect of such restrictions is that a client and a server will probably have a very narrow set of protocol and port combinations available to carry out a conversation. Because DCOM dynamically selects network ports in a range (1024 – 65535) on which Internet-to-intranet network traffic is typically not allowed, it is not possible to reliably use the existing DCOM transport protocols over the Internet (although they are perfectly suitable for intranets). Moreover, firewalls are often set up to restrict access to port 135, upon which DCOM depends for a variety of services (see Endnote 1).

The Tunneling TCP protocol introduces a special handshake at the beginning of each DCOM connection that allows it to pass through most firewalls and proxies. After this handshake, the wire protocol is simply DCOM over TCP. Aside from the caveats listed later in this article, this means:

The protocol is transparent to both client and server. Neither the client code nor the server code needs to be modified to use CIS.


All of the DCOM over TCP protocol services are available—including DCOM security and lifetime management (that is, "pinging") services.
Limitations of the Tunneling TCP Protocol
The Tunneling TCP protocol is subject to the following limitations:

It requires that Internet Information Server version 4.0 or higher be installed on the server-side machine hosting CIS-accessible COM objects, since part of CIS functionality is implemented using an ISAPI filter.


Because Tunneling TCP consists of non-HTTP traffic after the initial handshake, CIS requires that proxy servers and firewalls permit such traffic over a port opened to HTTP.
Note that because of these limitations, in practice, CIS does not support callbacks. This means, for example, that your applications cannot perform notifications using the connection point or advise sink mechanisms. However, if the CIS client can function as a CIS server and is configured as discussed later in this article, nothing prevents the client from receiving DCOM calls—including callbacks.

Protocol Overview
The Tunneling TCP protocol is illustrated in Figure 1.



Figure 1. The Tunneling TCP Protocol

If the client configuration indicates that HTTP traffic to the server should be routed through a proxy, the client DCOM run-time environment establishes a TCP/Internet Protocol (IP) connection to that proxy. It then sends the HTTP CONNECT method to the proxy requesting connection to port 80 on <server host>.


The proxy establishes a TCP/IP connection with <server host>. Note that this assumes that the proxy is configured to enable the HTTP CONNECT method on the port connected by the client. This port configuration on the proxy is sometimes referred to as "enabling SSL tunneling."


If the client configuration does not use a proxy, the DCOM run-time environment establishes a TCP/IP connection to port 80 on <server host>. After this step, whether or not the client uses a proxy, the client has a connection to port 80 on <server host> (perhaps mediated by a proxy). The client now sends the RPC_CONNECT command to the server requesting connection to the DCOM server on <server host> (see Endnote 2).


In response to the RPC_CONNECT, the server RPC run-time environment (implemented in part by an ISAPI filter/extension pair) establishes a local connection to the DCOM server (see Endnote 3).


Client and server have now established a mediated TCP/IP connection and engage in a DCOM over TCP conversation.
Configuring the Tunneling TCP Protocol
The Tunneling TCP protocol is supported on the operating systems listed in Table 1. This section describes how to configure the protocol on supported operating systems. Installation instructions are provided in the operating system or service pack release notes, as appropriate.

Table 1. Operating system support for Tunneling TCP

Operating System Client Server
(Requires IIS 4.0 or greater)
Windows® 95 w/DCOM95 1.2 Yes No
Windows® 98 w/DCOM98 1.3 Yes No
Windows NT® 4.0 Workstation w/SP4 Yes No
Windows NT® 4.0 Server w/SP4 Yes Yes
Windows® 2000 Workstation Yes No
Windows® 2000 Server Yes Yes


Client Configuration
Windows 95 and Windows 98
CIS requires that DCOM95 1.2 or a later version be installed on your Windows 95 machine. DCOM95 1.2 is available for download from the Microsoft COM Home Page, www.microsoft.com/com/default.asp.

On Windows 98, you must have DCOM98 1.3 or later installed. DCOM98 1.3 will ship with Windows 98 OSR1 and can also be downloaded from the Microsoft COM Home Page.

To enable CIS client support, run the CISCNFG utility as follows:

CISCNFG tcp_http

CISCNFG configures the protocols that DCOM uses and can be used with the following arguments:

tcp (DCOM over TCP only)


http (Tunneled TCP only)


tcp_http (DCOM over TCP is attempted, then Tunneled TCP)
After running CISCNFG, you must reboot your system.

Windows NT 4.0 SP4 and Windows 2000
CIS support is included with Windows NT 4.0 Service Pack 4 and Windows 2000.

To enable CIS, you need to add the Tunneling TCP protocol to the DCOM protocol list. You can modify the protocol list by running DCOMCNFG.

Select the Default Protocols tab.


Use the Add button to add Tunneling TCP/IP.


Reboot the system to have this change take effect.
Note If multiple protocols are configured, DCOM attempts to use them in the order in which they appear in the DCOM protocol list.

HTTP proxy configuration
If your client is located behind a proxy server, you need to ensure that your client machine is correctly configured to use the proxy server to access the web. To configure your client to use the proxy server, open Internet in the Control Panel. This can also be set via a registry key as described in the section "Registry Keys Affecting CIS". Note that this configuration is shared with the RPC run-time environment by other applications that use HTTP, most notably Microsoft Internet Explorer.

Server Configuration
Configuring the RPC Proxy on Windows NT Server 4.0
CIS requires that Service Pack 4 be installed on your Windows NT Server 4.0 computer. CIS also requires that Internet Information Server 4.0 (including the Internet Service Manager) be running. IIS 4.0 is part of the Windows NT 4.0 Option Pack.

Note CIS should not be installed on a machine running Microsoft Proxy Server.

Create an RPC subdirectory under your Inetpub directory. For example, at the command prompt, type:
md c:\inetpub\rpc

This directory will be referred to as %inetpub%\rpc in the following instructions.

Copy Rpcproxy.dll from the Windows system directory to %inetpub%\rpc. For example, at the command prompt, type:
copy %windir%\system32\rpcproxy.dll c:\inetpub\rpc

Create a virtual root for the directory you created. To do this:
From the Start menu, select Programs, point to Windows NT 4.0 Option Pack, then Microsoft Internet Information Server, and then click Internet Server Manager.


In the console tree (the left pane), select Console Root/IIS/<machine name>/Default Web Site.


Right-click Default Web Site, click Create New, and then click Virtual Directory. In the New Virtual Directory wizard, enter the following:
Alias to be used to access virtual directory RPC
Physical path %inetput%\rpc
Permissions Execute Access


Don't close Internet Service Manager. Change the connection timeout for the Default Web Site to 5 minutes. To do this:
In the console tree (the left pane), select Console Root/IIS/<machine name>/Default Web Site.


Right-click Default Web Site, and then click Properties.


In the Default Web Site Properties dialog box, select the Web Site tab.


Change the Connection Timeout to 300.


Click OK. Do not close Internet Service Manager.


Install the RPC Proxy ISAPI Filter. Select Console Root/IIS/<machine name> in the console tree (the left pane), right-click the machine name, click Properties, select Edit for the Master WWW Service Properties, select the ISAPI Filters tab, select Add, and then enter:
Filter name Rpcproxy
Executable %inetput%\rpc\rpcproxy.dll


You can close Internet Service Manager now.


Stop, and restart the Internet Information Server:
net stop iisadmin
net start w3svc

Enable CIS on the server as described in the section "Enabling CIS."
Configuring the RPC Proxy on Windows 2000 Server
On the Windows 2000 Server, CIS requires that the Internet Information Services (including the Internet Services Manager) be running.

On Windows 2000 Server, CIS has its own optional network setup (it is not installed by default). It can be installed just like other optional network components:

From the Control Panel, select Add/Remove Programs, click Add/Remove Windows Components, then click the Components button. This will start the Windows Components Wizard.


Select Networking Services, and click the Details button.


Select the COM Internet Services Proxy check box.
You can add CIS during the initial Windows 2000 Server install, or add it later to an existing system. On an upgrade from a Windows NT 4.0 (SP4) Server that already has CIS installed to Windows 2000, you will need to reinstall CIS as described above.

Enabling CIS
To enable CIS on the server, you need to add the Tunneling TCP protocol to the DCOM protocol list. You do this by running DCOMCNFG.

Select the Default Protocols tab.


Use the Add button to add Tunneling TCP/IP.


Reboot the system to have this change take effect.
In addition, it is possible to control whether or not CIS is enabled by changing the value of a DCOM property. This setting, which defaults to "disabled," can act as a coarse-grained security control to disable potential Internet access to DCOM. Note, however, that even when CIS is enabled, the usual DCOM security checks remain in effect. Run DCOMCNFG to set this property:

Select the Default Properties tab.


Select or unselect the Enable COM Internet Services on this computer check box.


Reboot the system for the change to take effect.
Proxy Server Configuration
If the client is configured to access the Internet through a proxy, the proxy server must be configured to enable the HTTP CONNECT method for the port to which the client connects (port 80 by default). This port configuration is sometime referred to as "enabling SSL tunneling." Consult the documentation for your proxy server for details on how to configure a port for the HTTP CONNECT method.

Configuring Microsoft Proxy Server
If you are using Microsoft Proxy Server, enabling HTTP CONNECT is achieved by manipulating a registry key (for example, using regedt32.exe) to indicate what ports should allow HTTP CONNECT. In the default configuration, two ports are enabled: 443 (https) and 563 (snews). The registry key of interest is:

HKEY_LOCAL_MACHINE\system\CurrentControlSet\services\w3proxy\parameters\SSLPortListMembers

The key value consists of a list of pairs of ports. For the default proxy configuration (handling HTTP traffic on port 80), add the pair "80 80" to the existing registry values. After making this modification, you will need to stop and restart the Microsoft Proxy Server for the new settings to take effect.

Firewall Configuration
The only configuration requirement placed by CIS on the firewall is that it allows TCP/IP traffic through port 80 unimpeded. Because port 80 is usually open to HTTP traffic, this is the standard scenario. In some rare cases, however, a firewall performs so-called application-level filtering on incoming traffic that may result in CIS traffic being rejected.

Configuration Tips and Known Issues
Incorrect proxy server settings on the CIS client
The proxy server setting on the client should not contain any leading forward slash ("/"). For example, the reference myproxy:80 is correct but http://myproxy is not. Note that the proxy server setting (set using Internet in the Control Panel) is stored as the value of the

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ProxyServer

in the registry.

CIS server side should not be installed on a machine hosting Microsoft Proxy Server
The RPC proxy, RpcProxy.dll, does not function properly when installed on a machine hosting Microsoft Proxy Server.

Issue with a multihomed CIS server
A client of a multihomed CIS server activating an object using one of the server IP addresses can cause failure. To work around this limitation, the client should use the server name (for example, the DNS name).

MTS use of callbacks
When a client and a server share a transaction in a Microsoft Transaction Server (MTS) scenario, the MTS infrastructure makes a callback to the client. This scenario is not supported with CIS unless the client machine is configured as a CIS server. Note, however, that this limitation does not hinder the most common transaction scenario for a base client, the case of a client not in a transaction calling a component that requires one.

Issue with HTTP caching devices
HTTP caching devices (for example, Cisco LocalDirector) may need to be tweaked or disabled.

Registry Keys Affecting CIS
Registry Key Description
HKEY_CURRENT_USER\Software\
Microsoft\Windows\CurrentVersion\

Internet Settings\ProxyServer
The value of this client-side setting indicates the <proxy server>:<port> that CIS uses. <proxy server> should not contain leading forward slashes ("/"). Note that this configuration is shared with the RPC run-time environment by other applications that use HTTP, such as Internet Explorer. Proxy Server configuration can also be set in the Control Panel by opening the Internet icon.
HKEY_LOCAL_MACHINE\SOFTWARE\
Microsoft\Rpc\DCOM Protocols
Client and server setting indicating which DCOM protocols to use. This can also be set with CISCNFG on Windows 95 and Windows 98 and DCOMCNFG for Windows NT 4.0.
HKEY_LOCAL_MACHINE\SOFTWARE\
Microsoft\Ole\EnableDCOMHTTP
The value of this server side setting indicates whether or not CIS is enabled for the machine. Possible values are "Y" and "N." This property can be set with DCOMCNFG.


OBJREF Moniker
To allow clients to establish connections to an object already running on a remote server, CIS provides a new type of simple moniker known as the OBJREF moniker. This moniker provides a simple mechanism for embedding references to remote objects in an HTML page.

OBJREF monikers are monikers that represent references to local or remote objects running on a distributed system. The OBJREF moniker represents a particular running instance on a particular server. If the object instance terminates, then the OBJREF moniker is invalid.

If a moniker is created from a proxy to a remote object and bound on a different machine, the moniker will bind to the original object in keeping with the DCOM short-cut semantics. If the object cannot be located during an attempt to bind, no new objects will be launched.

In many ways, the semantics of the OBJREF moniker are similar to that of a pointer moniker and essentially represent a remote pointer to a running object. However the display name of an OBJREF moniker may be embedded in an HTML page and bound by a client applet or ActiveX control.

Note For additional details, see the OBJREF moniker reference documentation in the Platform SDK.

When To Use
An active server page (or some other means of generating dynamic HTML content) may place the display name of an OBJREF moniker in a parameter to an applet or ActiveX control. The applet or control can then use the moniker to connect to the running object instance on the remote server.

To use OBJREF monikers, the server code generating the moniker must use the CreateObjrefMoniker function to create the monikers, passing an interface to the object that the moniker will bind.

Endnotes
Endnote 1. For a discussion of firewall issues, with DCOM over TCP applicable to some firewall scenarios, the reader is referred to Michael Nelson's article "Using Distributed COM with Firewalls".

Endnote 2. This may include the initial additional step of contacting the DCOM Service Control Manager on <server host> to resolve the DCOM server endpoint.

Endnote 3. This may include the initial additional step of contacting the DCOM Service Control Manager on <server host> to resolve the DCOM server endpoint.


--------------------------------------------------------------------------------

Just Copy the component on servermachine to the client and register make sure by just changing remoteservername is the remote servers name or ip.
this can be done in many ways.
through registry through dcom,through setup ,through createobject etcetc.
make sure that ur proxy on client points towards
the server.
the error indicates remoteservername doesnot exist.
not because of firewall or security problems.
this all comes with different errors

there's easier way
take a look at http://www.dcomlab.com/