OPC and DCOM: Five things you need to know — Part 2

In Part 1 of this article we explained the initial system-wide settings that are required for DCOM to operate correctly on a PC that is to run an OPC server. In Part 2 we will discuss the server-specific settings which will need to be configured for your specific OPC application.

As we began in Part 1, a simple and effective strategy to establish reliable DCOM communication involves the following steps:

1. Remove Windows security
2. Set up mutual user account recognition
3. Configure system-wide DCOM settings
4. Configure server-specific DCOM settings
5. Restore Windows security

3. Once in the Component Services window (which is initiated by DCOMCNFG as above), navigate inside the Console Root folder to the Component Services folder, then to the Computers folder, expand My Computer, finally click on the DCOM folder.
4. In the list of objects in the right window pane, find the OPC Server to configure and right-click on it. Select the Properties option.

In the OPC-Server specific settings, only the Identity tab needs to change from the default settings. The rest of the tabs (refer to Figure 3) can refer to the default configuration that was set in Part 1 of this article (Configure system-wide DCOM settings).

You must pay special attention to the Identity tab. The Identity tab will look like one of the two screen captions in Figure 4.
The four Identity options are:

• The interactive user: The OPC server will assume the identity of the interactive user. This is the person who is currently logged on and using the computer on which the OPC server resides. Note that someone must be logged on. If no one is logged on to the computer, the OPC server will fail to launch. In addition, if someone is currently logged on, the OPC server will shut down as soon as the person logs off. Last, in the case of a reboot, the OPC server will not launch until someone logs on. Consequently, this is typically a poor setting for OPC servers. OPCTI does not recommend that you use this setting unless the OPC server vendor specifies this setting explicitly.
• The launching user: The OPC server will take the identity of the user account that launched it. With this setting, the operating system will attempt to initiate a new instance for every launching user. There are three general problems with this setting. The first problem is that some OPC servers will only allow a single instance to execute. Consequently, the second launching user will be unable to make the connection because an instance of the OPC server is already running on the computer. The second problem occurs when the OPC server vendor allows more than one instance of the OPC server to execute concurrently. In this case, the computer on which the OPC server resides will have multiple copies of the OPC server executing concurrently, which will consume a significant portion of the computer resources and might have an adverse affect on the computer’s performance. In addition, some system resources might be unavailable to any instances of the OPC server that follow the first. For example, the first launching user will be able to connect to a serial port, while every other launching user will simply receive Bad Quality data. OPCTI does not recommend that you use this setting unless the OPC server vendor specifies this setting explicitly. Last, the launching user must have administrative rights on the OPC server computer. They cannot be configured as a ‘limited’ user.
• This user: The OPC server will take the identity of a specific user account. This setting might be required when the OPC server is tightly coupled with the underlying data source. In this case, the OPC server must assume a specific identity to exchange data with the data source. However, since the OPC server uses a specific user account, it is possible that the computer running the OPC client does not recognise the OPC server’s user account. In this case, all callbacks will fail and all OPC data subscriptions (asynchronous data updates) will fail. If this is indeed the case, you will have to add the OPC server account on the computer running the OPC client application. Various DCS vendors require this setting for their OPC server. OPCTI does not recommend that you use this setting unless the OPC server vendor specifies this setting explicitly.
• The system account (services only): The OPC server will take the identity of the operating system (or System for short). This is typically the desired setting for the OPC server as the System account is recognised by all computers on the workgroup or domain. In addition, no one needs to be logged onto the computer, so the OPC server can execute in an unattended environment. OPCTI recommends configuring the identity of the OPC server with this setting, unless the OPC server vendor specifies a different setting explicitly. Note that Windows disables this option if the OPC server is not set up to execute as a Windows service. If this is the case, simply configure the OPC server to execute as a service before configuring this setting.

We encourage you to complete your DCOM set-up with this step. Integrators frequently establish OPC communication and don’t spend the necessary time to secure the computers again. This can lead to catastrophic results if network security is compromised due to a virus, worm, malicious intent, or simply unauthorised ‘experimentation’ by well-meaning co-workers.

Conclusion

OPC is a powerful industrial communication standard. However, OPC relies on having DCOM working properly. Luckily, DCOM problems can usually be overcome with relatively simple configuration changes as documented in this article. To get a deeper understanding of OPC, DCOM and the diagnosis of all common problems, OPCTI highly recommends that you take time to get formal OPC training. This will enable you to structure your OPC knowledge to help you reduce your short- and long-term project costs.

OPCTI also encourages you to provide us with feedback. Let us know about new problems and solutions that you found. We will pass these on to the rest of the OPC community to help everyone get connected.

*Randy Kondor is a computer engineer, and is the president of the OPC Training Institute, the world’s largest OPC training company. Kondor has been involved with the OPC industry since 1996 and is a strong supporter of the OPC Foundation. He continues to dedicate himself to spreading the OPC Foundation’s message about system interoperability and inter-vendor cooperation.

OPC Training Institute (OPCTI)
www.opcti.com