The information in this article applies to:
- Microsoft COM/DCOM libraries included with:
Microsoft Windows NT 4.0
Microsoft Windows 95 with DCOM support
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://www.microsoft.com/oledev/olecom/oleview.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.