Opc interface to the pi system

Notes and Recommendations on DCOM Configuration

Using DCOM without a Windows Primary Domain Controller

If a Primary Domain Controller is not available, or if the OPC server and OPC client nodes are not on the same Windows domain, DCOM cannot use domain security to determine which machines can access each other. Therefore, it will fall back on the most basic of security models: the account(s) under which the client and server are running must be valid and privileged on both nodes. That means that the OPC Server node must have a user account defined that is the same as the user account on the OPC client node under which the client itself will run, and the passwords for those two accounts must also be identical. Likewise, the account under which the OPC server is running must also exist on the client node, and it must have the same password on the both nodes. Otherwise, DCOM will not pass any communication between the client and the server, although it may well launch the OPC Server. Note that these accounts must be a local account on each node, not a domain account.

Some sites have reported problems when their server and client nodes were in different Workgroups. If establishing communication between the server and a client is not possible, and the two machines are in different workgroups, it might succeed by moving the two machines into the same Workgroup.

Note: Do not use the Local System account to run applications that use DCOM. While the Local System account has plenty of privileges locally, it has no authority outside its own system.

DCOM Configuration on Two Nodes

If two nodes are being used, both nodes have to be configured to allow access. That is because the OPC Server makes calls to the client, and the client makes calls to the server, and if the configuration is not set up to give them both permission to communicate, the windows system will not allow communication.

DCOM Configuration on a Single Node

Even if you are using the same node for both the OPC server and the OPC client, DCOM still needs to be configured. In this case, make sure that DCOM permissions have been granted to the accounts under which the OPC server and the client will run.

Registration of Proxy DLLs

The OPC clients (e.g. OPC Interface, PI OPCClient tool, etc.) use proxy DLL’s to communicate with OPC Servers. On the client node the following files are needed opcproxy.dll and opccomn_ps.dll. These files are usually installed during the interface installation. However, if they are missing, the client will not be able to communicate to the server. These files are also located (usually in …\system32 directory) on the OPC Server node. They can be manually copied and registered on the client node.

Here is how to register: Make sure they are both copied (opcproxy.dll and opccomn_ps.dll) into …\system32 directory. Run

C:>regsvr32 opcproxy.dll

The following dialog box should appear:

Click OK, and then run

C:>regsvr32 opccomn_ps.dll

The following dialog box should come out:

Click on OK to complete this procedure.

DCOM Security Configuration for the Interface

The PI OPC Interface uses DCOM to communicate to a remote OPC server. DCOM is Microsoft’s proprietary communication protocol that allows remote client and server applications to security communicate. DCOM uses Windows security model to authenticate clients and servers, while establishing a communication. In general, DCOM security for an OPC client application can be configured in two different ways: 1. Programmatically, when an application starts up; 2. Manually, by using DCOM Configuration utility (i.e. dcomcnfg.exe), before the start up. In order to set DCOM security programmatically, the OPC client application should make a specific Windows API call for DCOM security with desired options. If an application does not make that call, it will use the system’s (i.e. local computer’s) default DCOM security settings. These setting can be set up with DCOM Configuration utility (see Default DCOM Permissions on OPC Client Node section for more details).

If you do not want to use the system’s settings, you can use the interface’s special command line parameters that can set the DCOM security for the interface. This can be done with /DA and /DI parameters. The changes made to those parameters will only affect the PI OPC Interface. Here is a brief description of what they do and configuration options:

/DA parameter is used for setting up the Default Authentication Level. This setting is necessary for authentication of an OPC server application during establishing a communication and making calls. The possible options for this parameter are the following:

• 
  Default – Uses a standard negotiation between the interface and OPC Server for selecting an appropriate authentication level. This may vary depending on Windows OS;
  
• 
  None – Does not use authentication. All security settings are ignored;
  
• 
  Connect – The authentication takes place only when an initial connection is made to the server. After connection has been established, no additional authentication checks will be performed.
  
• 
  Call – The authentication occurs at the beginning of each RPC call (i.e. a callback from OPC Server). In this case the data packet headers are signed, but the data packets exchange is not signed or encrypted;
  
• 
  Packet – Authenticates the data on a per-packet basis. All data is authenticated.
  
• 
  Packet Integrity – Authenticates and verifies that the data packets are signed and have not been modified during transit (i.e. checks for packet integrity). The packets are not encrypted;
  
• 
  Packet Privacy – Includes all previous authentication levels and signs and encrypts each data packet. This setting ensures that the communication between the client and the server is confidential.
  

If you do not set the Default Authentication Level correctly, the OPC server will not be able to send callbacks to the client. This usually means that all Asynchronous calls (e.g. Poll or Advise) will not return data updates. The most commonly used settings are Connect and None.

/DI parameter sets up the Default Impersonation Level. The Default Impersonation Level is used for granting permissions to the PI OPC Interface for executing permissible operations on OPC Server objects. The possible options are as follows:

• 
  Anonymous – The client is anonymous to the server. This means that the identity of the user associated with the OPC Interface is hidden from the OPC server.
  
• 
  Identify – The OPC Server can identify the user associated with the OPC Interface, and can perform actions as that user.
  
• 
  Impersonate – The OPC Server can perform actions as the user associated with the OPC Interface, but is not allowed to access other computers as that user.
  
• 
  Delegate – The DCOM server can act as the user associated with the DCOM client, including access other computers as that user (only supported in Windows 2000 and later)
  

The most commonly used settings are Identify and Impersonate.