HOWTO: Configure a Non-DCOM Server and Client to Use DCOM

ID: Q158582

4.00 WINDOWS NT kbole kbhowto

The information in this article applies to:

Microsoft Win32 Software Development Kit (SDK), on platform(s):
- Microsoft Windows NT 4.0
- Microsoft Windows 95

SUMMARY

COM server and client applications that were written before the introduction of DCOM can be configured to use DCOM by making appropriate changes to the server application's registry entries. The server and client applications do not need to be rewritten. This procedure can be applied to any COM server and client, including those created using MFC or Visual Basic.

MORE INFORMATION

The registry entries can be changed using the DCOMCNFG.EXE tool, the OLE Viewer tool, or manually.

Before making the changes, register the server application in the registry of the client machine and server machine. This may involve running the server application's setup program or running the server application and shutting it down on both machines. The server application does not need to reside on the client machine. If the server uses custom interfaces, the marshaling code must be installed on the client and server machines. Automation servers that support vtbl-binding must install their type libraries on the client and server machines. Automation servers that do not support vtbl-binding do not need to install their type libraries on the client machine.

After the registry changes have been made, run the client application on the client machine. DCOM will look at the server application registry entries on the client machine and will determine the name of the server machine. It will then connect to the server machine, determine the location of the server application from the registry entries on the server machine, and launch the server application on that machine.

Note that DCOM is not supported for 16-bit applications. Also, see the last section of this article for special instructions for DCOM on Windows 95.

Changing the Registry Using DCOMCNFG

Launch the DCOMCNFG.EXE graphical utility (found in the Windows NT system32 directory) on the client machine. It will list all the registered servers. If you do not see the name of your server, it is probably listed by CLSID. (This is true for many Visual Basic servers because they do not put a name string as the default value of their CLSID key.) To determine the CLSID of your server, run the registry editor (regedit.exe). Open the HKEY_CLASSES_ROOT folder. All the ProgIDs (for example, 'MyServer.MyClass') of the registered servers will be listed in the left pane. Select the ProgID key of your server and open it. Then select the CLSID sub-key and open it. The CLSID value will be listed in the right pane.

If your server is listed by its CLSID and if you would like DCOMCNFG to list the name of the server instead, open the registry editor (after closing DCOMCNFG) and go down the list in the left pane until you reach the CLSID key. Open the CLSID key and find and open your server's CLSID. At the top of the right pane is a value preceded by "(Default)." Double- click on this prefix; a string editor will pop up. Enter the name of your server in this string editor and close the registry editor. Now when DCOMCNFG is run, it will list your server by name instead of CLSID. Do this on the server machine and the client machine.

Run DCOMCNFG on the client machine, select your server (by name or by CLSID) and select the Properties button. This will bring up a Properties dialog. Select the Location tab. Then select the "Run application on the following computer" checkbox and specify the name of the server machine. Clear the other checkboxes, and then press the Apply button.

Run DCOMCNFG on the server machine, select your server, and select the Properties dialog. Select the Security tab. You can choose to apply the default access and launch permissions to the server or you can choose to apply custom permissions. The default permissions can be changed using the Default Security tab in DCOMCNFG. Make sure that SYSTEM is in the Launch and Access permissions, and then add the account of the user on the client machine to the Launch and Access permissions. Press the Apply button. You are now ready to access the server from the client.

Changing the Registry Using the OLE Viewer Tool

Get the latest version of the OLE Viewer tool from http://msdn.microsoft.com/isapi/msdnlib.idc?theURL=/library/sdkdoc/bpc/ctrans_1gdu.htm on the World Wide Web.

Run the OLE Viewer tool on the client machine and select the View/ExpertMode menu. Double-click "All Objects" in the left pane and select your server. Select the "Implementation" tab in the right pane, select the LocalServer sub-tab. and clear the location of the server. Select the "Activation" tab and specify the name of the server machine. Close the OLE Viewer tool.

Run the OLE Viewer tool on the server machine and select the View/ExpertMode menu. Double-click "All Objects" in the left pane and select your server. Use the LaunchPermissions and AccessPermissions tabs in the right pane to set permissions for the server. You can choose to apply the default access and launch permissions or you can choose to apply custom permissions. The default permissions can be changed using the File/SystemConfiguration menu. Make sure that SYSTEM is in the Launch and Access permissions, and then add the account of the user on the client machine to the Launch and Access permissions. You are now ready to access the server from the client.

Changing the Registry Manually

You can also make many of these modifications manually instead of using the DCOMCNFG tool, as follows:

Using the registry editor, modify the server application's registry entries on the client and the server machines. The following registration information uses the REGEDIT4 syntax where the key is specified in square brackets. The line after each key specifies a name and a value. The name is on the left of '=' and the value on the right. '@' on the left indicates a value without a name. Replace the following GUIDs with your GUIDs. You can generate a new GUID for AppID (using uuidgen.exe), or use the same GUID as the CLSID. Replace hello.exe with your server's EXE name and replace 'Hello App' with a string that describes your server application: REGEDIT4 ;;;; CLSID key [HKEY_CLASSES_ROOT\CLSID\{0bf52b11-8cab-11cf-8572-00aa00c006cf}] "AppID"="{0bf52b15-8cab-11cf-8572-00aa00c006cf}" ;;;; AppID key [HKEY_CLASSES_ROOT\APPID\{0bf52b15-8cab-11cf-8572-00aa00c006cf}] @="Hello App" [HKEY_CLASSES_ROOT\APPID\hello.exe] "APPID"="{0bf52b15-8cab-11cf-8572-00aa00c006cf}"

Remove any InprocServer32 and LocalServer32 keys from the server application's registry entries on the client machine. (These should not be removed on the server machine where the server application resides.) Add the following key to the server's registry entries on the client machine. Use the same GUID for the AppID as in the previous step. Replace server_machine_name with the name of the machine on which the server is located: [HKEY_CLASSES_ROOT\APPID\{0bf52b15-8cab-11cf-8572-00aa00c006cf}] "RemoteServerName"="server_machine_name"

On the server machine, use DCOMCNFG or the OLE View tool to specify access and launch permissions for the server application. See the sections in this article that describe these tools for more information about how to specify permissions.

DCOM on Windows 95

DCOM for Windows 95 is in Beta at the time this article is being written. At this time, DCOMCNFG is not available for Windows 95 and the registry changes will have to made either by using the OLE Viewer tool or manually.

On Windows 95 with DCOM, there is an additional registry setting that enables or disables incoming calls:


   [HKEY_LOCAL_MACHINE\Software\Microsoft\OLE]
   "EnableRemoteConnections"="N"

By default, the EnableRemoteConnections named value is set to "N" and incoming calls are disabled. To enable incoming calls, change this to "Y." The OLE Viewer tool can be used to change this using its File/SystemConfiguration menu. Note that this affects server applications that run on Windows 95 machines and that it does not affect client applications on these machines.

It is not possible to launch a process on a Windows 95 machine securely from a client machine because all processes in Windows 95 run in the security context of the currently logged-on user. Therefore, DCOM on Windows 95 does not support remote activation. A server application on a Windows 95 machine will have to be launched manually or by some other mechanism to be accessed by a client application on another machine. Consequently, the DefaultLaunchPermissions and LaunchPermissions registry values have no affect on Windows 95.

Additional query words: 4.00 2.00 OLE COM DCOM OLE2 kbdss


Keywords          : LeTwoArc 
Version           : WINDOWS:95
Platform          : WINDOWS 
Issue type        : kbhowto

Last Reviewed: June 24, 1999