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

ID: Q158582

The information in this article applies to:
  • Microsoft Win32 Software Development Kit (SDK), on platform(s):
    • Microsoft Windows NT 4.0
    • Microsoft Windows 95
    • Microsoft Windows 2000

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 computer and server computer. This may involve running the server application's setup program or running the server application and shutting it down on both computers. The server application does not need to reside on the client computer. If the server uses custom interfaces, the marshaling code must be installed on the client and server computers. Automation servers that support vtbl-binding must install their type libraries on the client and server computers. Automation servers that do not support vtbl-binding do not need to install their type libraries on the client computer.

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

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

  1. Start the DCOMCNFG.exe graphical utility (found in the Windows NT system32 directory) on the client computer. It lists 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.


  2. 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 appear. 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 computer and the client computer.


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


  4. Run DCOMCNFG on the server computer, select your server, and select the Properties dialog box. 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 computer to the Launch and Access permissions. Click Apply. 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/psdk/bpc/ctrans_1gdu.htm on the World Wide Web.

  1. Run the OLE Viewer tool on the client computer 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 computer. Close the OLE Viewer tool.


  2. Run the OLE Viewer tool on the server computer 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 computer 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:
  1. Using the registry editor, modify the server application's registry entries on the client and the server computers. 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}"


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


  3. On the server computer, 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 computers and that it does not affect client applications on these computers.

It is not possible to launch a process on a Windows 95 computer securely from a client computer 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 computer will have to be launched manually or by some other mechanism to be accessed by a client application on another computer. 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 : kbole kbCOMt kbDCOM kbNTOS400 kbWinOS2000 kbSDKWin32 kbWinOS95 kbGrpCom kbDSupport kbhowto LeTwoArc
Version : WINDOWS:95
Platform : WINDOWS
Issue type : kbhowto


Last Reviewed: December 7, 1999
© 2000 Microsoft Corporation. All rights reserved. Terms of Use.