To configure settings for a particular server application (such as the ASO or SPO), you must first select the application from a list. To see the list, expand the DCOM Config folder under the My Computer node in the Component Services tree view.

To configure OpenROAD servers, select one of the following from the list:

Right-click the application name and select Properties. In both cases, a dialog with the following five tab pages displays:

The OpenROAD Installer sets the authentication level for the ASO and SPO to Packet Privacy because this provides the most secure default, with integrity-checking and encryption for all message traffic between the client and server. The cost of this added security is insignificant in most environments, and therefore we recommend keeping this default, but you can reduce the Authentication Level for the ASO or SPO if you want.

The ASO Authentication Level must be set to at least the Connect level. Because each ASO instance is a private server, launched under the same account as the client, that client must be authenticated to provide a security context under which to launch the process.

The SPO Authentication Level can be set as low as None, if you want to allow unauthenticated DCOM access to the SPO. But we do not recommended this because it provides no security. Using an HTTP gatekeeper is a better alternative because it enables you to be selective about which applications and which SCPs you expose to unauthenticated callers.

Location should be left at its default setting with only the "Run application on this computer" option selected.

Clients can explicitly request a different machine when they call the Initiate method of the RSO. The SPO can be configured to launch its ASO slaves on specified machines, independent of this DCOM location default. Therefore, a wide range of server process distributions can be achieved without ever changing the standard DCOM default for server location.

Do not change the Launch and Activation permissions if you are running one of the newer Windows systems that supports enhanced DCOM security. With all the choices under the new fine-grained security model, it is too easy to get these wrong, or get them out of sync with the Access Permissions.

The asreg (Application Server Installer) utility will automatically synchronize your Launch and Activation Permissions to correspond to whatever you set in the Access Permissions. Therefore, edit only the Access Permissions (described in Security Tab Page: Access Permissions and Security Tab Page: Launch and Activation Permissions). Then run asreg to take care of the other permissions. When you run asreg, be sure to click the Install button. Clicking the Uninstall button removes your access permission customizations, and the next time you click Install, all ASO and SPO permissions will revert to initial defaults.

If you are running an older version of Windows that does not support the enhanced DCOM security model, then asreg cannot help, and you will need to manually edit the Launch Permissions for the ASO. But do not edit Launch Permissions for the SPO. If you make a mistake editing the Launch permissions for the SPO you can cause it to malfunction. The only account with launch permission for the SPO must be SYSTEM. Under the basic DCOM security model, there is no such thing as Activation Permission, and there is no distinction between local and remote permissions, so manually editing the ASO Launch Permissions is not difficult in that case.

The OpenROAD Installer sets access permissions for the ASO and SPO to grant local and remote access to the Everyone Group. To be more selective about who is allowed to access the ASO and SPO, remove Everyone, and substitute your own choice of user IDs or group IDs.

Access permissions should always include the special user ID, SYSTEM.

When you have finished editing the Access Permissions, run the asreg utility to automatically synchronize your Launch and Activation Permissions to correspond to whatever you set in the Access Permissions. When you run asreg, be sure to click the Install button. Clicking the Uninstall button removes your access permission customizations, and the next time you click Install, all ASO and SPO permissions will revert to initial defaults.

If you are running an older version of Windows that does not support the enhanced DCOM security model, then asreg cannot help, and you will need to manually edit the Launch Permissions for the ASO, as described in Security Tab Page: Access Permissions and Security Tab Page: Launch and Activation Permissions.

DCOM configuration settings are kept in the JSON configuration file. The Configuration Permissions simply reflect the ACL in the JSON configuration file for this particular server application's settings. It is unlikely that you would ever need to change this ACL.

This tab page is for DCOM experts only. Its use is beyond the scope of this guide.

The OpenROAD Installer sets the DCOM configuration of the ASO to make it run under the user ID of the client who launches it. This allows the ASO to acquire the rights of its client's user account and to execute privileged operations (such as JSON configuration file updates) on that client's behalf. Anonymous remote users cannot launch a private ASO because they cannot provide an authenticated identity under which to launch the process.

The OpenROAD Installer sets the DCOM configuration of the SPO so that it runs under the user ID that you specified when you were prompted for it by the asreg utility. When an ASO slave is launched by the SPO, the ASO slave runs under the same user ID as the SPO. Therefore, all 4GL procedures executed on behalf of any client of the SPO execute in the security context of the user ID under which the SPO is run. By limiting the permissions given to that user ID, you can limit what those clients are allowed to do.

It is very important to run the SPO under a specific user ID to ensure that only one instance of the SPO can be launched. Never configure the SPO to run as "The launching user" or as "The interactive user." That can cause multiple instances of the SPO to be started, which can lead to a variety of anomalies in SPO behavior.

Do not forget to update the DCOM identity setting for your SPO whenever the password for the specified user ID expires. You can do that on this tab page, or you can accomplish the same thing by running asreg.