DCOM Tutorial - Preface and Best Practices

DCOM Tutorial Home

We recommend you read these best practices, and although you may not understand all of them
now, you will as you go through the setups see why they are important.

 If using DCOM, please try and use Windows NT/2000/XP if at all possible - although you
can get DCOM for Windows 95 and it came with Windows 98, the versions of DCOM in
those operating systems is far from perfect and since Microsoft has officially obsoleted
those operating systems, don't count on any upgrades to them for the known bugs in the
OS.

 If you aren't logged in as the Administrator or an account with Administrator rights on the
NT machines you are setting up DCOM on, you won't find much success with the
information presented here. You do not have to run your applications as an Administrator
in order to use DCOM, but you'll need Admin rights to set it up.

 If you make a change to any DCOM config or security related setting on the CLIENT side,
you must restart the client application for the changes to take effect. Likewise, if you
make such changes on the SERVER side, you must restart the server application for the
changes to take effect. You typically only need to reboot either or both machines in
special instances where you are changing settings that globally affect all DCOM
applications on the machine. For example, if you change the DCOM Default
Authentication Level or Default Impersonation level, it's a good idea to reboot the
machine after this change, as this is a very broad change in what it covers relative to your
machine's use of DCOM.

 Security matters - if the 2 machines you're trying to connect over DCOM do not have
security rights for the user names to be used to access the machines, then you'll never
get DCOM to work. If you are not familiar with this topic we STRONGLY recommend you
read our note on NT/2000 User Permissions as they relate to OPC client/server
connections over DCOM. However, do not confuse access rights to get at shared folders
and printers with properly setup DCOM rights. Although it helps if you know that you can
access shared folders because that means that the machines are at least allowing logon
rights, there are still things that must be setup that specifically allow you to connect to
COM servers (i.e. OPC servers) and receive data back from them on a client machine
(i.e. one running your HMI/SCADA application).

 Try and have the OPC client computer and OPC server computer in the same Domain if
you can - and use Domain User accounts and Domain Groups for granting permissions if
you can.

 This document is not intended as the "be all and end all" of DCOM - but it will help you in
setting up your DCOM applications. If you really want to get into the technical nuts and
bolts, we recommend reading the following Microsoft Articles: DCOM Architecture and
DCOM Technical Overview. You in NO WAY need to read these to setup DCOM
properly. We provide these links for our readers who really want to get into the "nuts and
bolts" details. These articles assume you know the NT/2000 security model, related
terminology, and in some cases, some C++ programming.

 If you plan to run DCOM to connect between computers in DIFFERENT NT Domains

there are additional concerns and considerations that you must take into account when
 setting up DCOM regarding NT Domain Trusts relationships. Click here for our input on
the subject.

DCOM Configuration Tutorial for Windows XP & 2003 Editions

This section is intended to provide general guidance on configuring DCOM settings for Windows
XP and 2003 Operating Systems, which do differ slightly from Windows NT and 2000 Operating
Systems.

This article will simply outline the steps to configure DCOM. If you would like to know and
understand the reasons WHY some of these settings are so, then please read:

 NT/2000 User Security Permissions/Considerations

 Special considerations in multiple domain settings.

We will configure DCOM in 3 steps:

1. Configuring the general/default settings
2. Configuring the settings for OPCENUM
3. Configuring the settings for your OPC Server

Starting DCOM Configuration

The DCOM Configuration utility does not have an associated icon in either the Windows Control
Panel, nor the Windows START button.. so you have to start it manually:
1. Click on the Windows START button
2. Click on the RUN option
3. Type "DCOMCNFG" (without the quotes) and press ENTER. (case does not matter)

This will load the Windows "Component Services", which is shown below:

Step 1 - Configuring Default DCOM Security Options for Windows

XP & 2003 Operating Systems
The following screen is opened by:

1. Right-clicking on the "My Computer" node in the "Component Services" screen.

2. Choosing "Properties" from the menu.

This particular screen is not 100% identical to that of Windows NT, 2000 as there are more
options in some areas, and fewer options in others...
Once in this Properties screen, do click on the "Default Properties" tab first.
The options available in this screen should be configured as:
The Enable Distributed COM on this computer MUST be checked.
The Default Authentication Level should be set to Connect.

The Default Impersonation Level should be set to Identity

The next step is to click on the "Default COM Security" tab, which is shown below:

There are only 2 buttons in this screen, whereas there are 3 in Windows NT and 2000 Operating
Systems.

Click on the "Edit Default" button within the "Access Permissions" area and make sure that the
following accounts exist with the "Allow Access" permissions:

 Everyone
 Interactive
 System
 Network

Once that is complete, do the same with the "Edit Default" button in the "Launch Permissions"
section and give the right "Allow Launch" to the same accounts as mentioned in the bullet-points
above.
Now click the OK button to save and close the window.

Step 2 - Configuring DCOM Security Options for OPCENUM for

Windows XP & 2003 Operating Systems
The next step is to locate OPCEnum in the list of COM components. Simply click on, or expand
the "DCOM Config" section to show the objects available to configure:

Locate OPCEnum, and then open it's properties by simply right-clicking on it, and choosing
"Properties" from the menu.

General Tab

The General Tab has only one option, and that is the "Authentication level".

For each of use, you can select "None" as your option.

Location Tab

OPCEnum is a program that scans your registry for a list of OPC Servers on your computer.

OPCEnum needs to run on the computer where it resides.. therefore the option of choice here is
to check "Run application on this computer ".

Security Tab
There are 3 options in the Security tab that need to be set.

Launch Permissions:
Select the option "Use Default".

Access Permissions:
Select the option "Use Default".

Configuration Permissions:
Select the option "Customize", and then click the "Edit" button.

A window will open allowing to specify the accounts that do/don't have configuration permissions,
simply add the same "Network, Interactive, System and Everyone" groups as we have previously,
and make sure that they have "Full Control" rights.

End Points Tab

Use either the Interactive or System account.

Click OK to save and close the OPCENUM options window.

Last Step - Configuring DCOM Security Options for the OPC

Server, for Windows XP & 2003 Operating Systems
This step should only be followed if your computer has an OPC Server on it that you wish to allow
OPC Clients to connect to.

At the "Component Services" window, click on or expand the "DCOM Config" node and locate
your OPC Server from the list.

When you have found your OPC Server in this list, simply right-click on it and open it's properties.
Then follow the same steps as those listed for configuring OPCENUM.

Configuring DCOM (Distributed COM) to Connect

an OPC client to an OPC Server on another Machine
NT/2000 Domain Trust Relationship Considerations
DCOM Tutorial Home

When you're going from one domain to another in NT and browsing OPC servers, probably the
biggest issue to be concerned with is domain trust relationships. When you have multiple NT
domains, there are setups in BOTH domains that must be made so that Domain A trusts users
from Domain B and vice versa. For DCOM to work properly you'd have to have the trust going
both ways because there are DCOM calls going both ways and the NT security model will try and
validate the security credentials of the user going both ways. It is beyond the scope of our free
support to show users how to setup NT Domain Trusts, but the good news is any decent NT
administration book will address the issue.
Having said that, with Domain trusts setup properly, then you still have to have the Dcom
permissions setup properly as we discuss in our Dcom Configuration appnote.

User Permissions Considerations when setting up a DCOM

Connection between An OPC Client and OPC Server
A key foundation for setting up a DCOM connection between two computers is to have the
machines setup so that they have permission to access each other. This is a two way street. The
client must have permissions to access the machine with the OPC server and vice versa. If you
don't have permissions set both ways, then you will not have success. This article is not intended
to be a substitute for good knowledge of the Microsoft Windows NT and Windows 2000 user
accounts and security model. There are plenty of good books on the subject available at any local
bookstore. This article is intended to point out some key things you need to have setup before
you even try to configure a DCOM connection between an OPC client and an OPC server.

Types of Permissions:

There are some common types of permissions we discuss in our DCOM tutorial

 Access -- these permissions allow a client machine to connect to a server computer,

retrieve a list of OPC servers and connect to a server. They also allow the OPC server to
make what is known as a "callback" to your client. A callback occurs when you ask the
OPC server to notify your client only when data changes. If you use these types of reads,
sometimes called "subscription" or "exception" reads, then it is important that Access
permissions be set right on the client machine.

 Launch - these permissions are what allows an OPC client application to start or
"launch" an EXE running on the machine where the OPC server is located. There are 2
common EXEs that get launched: (1) OPCEnum.exe, a standard OPC common
component that lists the available OPC servers on a machine and returns that list to a
client and (2) the actual EXE that corresponds to the OPC server. For example, our TOP
Server OPC server EXE is "servermain.exe", the INGEAR AB Server is "IGOPCAB.exe"

 Configuration - these permissions allow a remote client to change the configuration of

the OPC servers setup in the registry - you should rarely have to touch these permissions
and in fact should not unless you know what you are doing.

So, the most common permissions you will see us discuss are Access and Launch permissions.
Users and Groups:
This document is not meant to replace common books on NT/2000 security, but there are some
key concepts we want to emphasize.
Users: A user is a particular login name+password combination used to gain access to a
machine running Windows NT/2000.
Groups: A group contains one to many users. Groups are a useful way to combine a set
of user accounts and grant them certain rights for access and launch. If the actual user
names that you wish to have access to your OPC servers will change with any frequency,
we recommend you use Groups when granting all rights. Then all you have to do is
add/remove users from the Groups in the NT/2000 user manager and their rights to
access OPC servers will carry along. Proper use of Groups, whether they be ones you
create on your own or any of the NT/2000 default groups, is a great way to reduce your
long term maintenance cost of the system
 Local Users/Groups: A Local user is an account that is known ONLY to the machine on
which the account was setup. Likewise for a Local Group. If you need an account to
have access to another machine, and the account is a Local User, you will need to create
a Local user with the identical username+password on the remote machine. For this
reason, we recommend running OPC Client - Server setups in a Domain if you can - the
maintenance and setup is easier.
Domain Users/Groups: A Domain User account is one that can be used anywhere
within an NT/2000 domain so long as the computer is a member of the domain.
Authentication of the user is handled by a primary domain controller machine, thus
allowing you to centralize your security management on the user/group level. A Domain
Group is a group that is available to any computer that is a member of the domain. We
recommend using Domain user accounts and Groups to setup your DCOM Config
permissions when setting up OPC client/server connections-- the risk of problems is
lower and the long term maintenance is much easier.

What's a Domain ?

In Windows NT there is the concept of a Domain (in in Win 2000 domains still applies, though the
concept has been evolved to talk about Forests/Trees, something beyond the scope of this
article). A domain is a group of machines that have reasons to need to be able to work together.
For example, you might have the paint shop domain, the body shop domain, the accounting
domain, the marketing domain, and sales domain in a large company. For the majority of their
day to day work, the users in each domain need only to access the machines in their group but
not others. The Windows NT concept of a Domain allows you to setup a Domain Server in the
group and setup security in the Domain so that the users within the domain have common access
to the Domain server and to some degree, to each other's machines. So for example, in the Paint
Shop, you might have a Domain Server (also called a Primary Domain Controller or PDC in
Microsoft-speak) and 10 Windows NT machines. When users login to their boxes, they log in to
the Paint_Shop domain, which then gives them access to any shared resources (drives, printers,
etc) in the Paint_Shop domain. Their user name and passwords are authenticated (validated,
checked - pick your term) against a database of users stored on the Domain Server. Unless a
special relationship called a "Domain Trust Relationship" has been setup, users in the Marketing
domain would not have access to shared resources in the Paint_Shop domain. In a Domain Trust
Relationship, the PDC (Primary Domain Controller) for the Paint_Shop domain agrees to trust the
Marketing domain's users as if they were their own. Domain Trust relationships and their setup
and maintenance is an advanced topic beyond this discussion - just be aware that if you have
multiple domains, you have to be more careful with your access rights setup.

In Windows 2000, machines can still be a member of a Domain, but you can optionally also setup
Windows 2000 machines to support the new Active Directory security model, a subject which is
beyond the scope of this particular document.

Get in the Domain - if you can

Now that you have the idea of a domain, why does it matter to OPC? The primary benefit of both
the OPC client computer and the OPC server computer being a member of a domain is that
security is centralized. Both machines will trust accounts that are members of the domain,
meaning their username/password combinations are found in the security database of the PDC
machine. The downside is that if the PDC goes down, you might not be able to validate security
after reboot of a machine in the domain until the PDC comes back. Fortunately you can have
BDCs or "Backup Domain Controllers" in a Domain to decrease this risk.

When you run an OPC client application on an NT/2000 machine, that application, even if it is
running as a service, has to run under some user name -- you'll hear this sometimes called
"running in the context of user name JoeSmith" -- it means you are running the application as if it
were launched after a user JoeSmith logged into that machine. The same applies to an OPC
server -- it too runs under some user name or "context".

So if we have OPC client on machine A, running under username JoeSmith, and it wants to talk
to an OPC server on machine B, that is running under the name BillJones, then DCOM security
defaults require that JoeSmith have access to Machine B, and BillJones have access to
MachineA. Without BOTH of those requirements met, you'll never get your DCOM connection to
work, at least not without some major trickery that just isn't worth the hassle.

OK - so what -- how does a Domain help this situation ? Simple -- if Machine A and B are
members of the Paint_Shop domain, and users JoeSmith and BillJones are both accounts in the
domain Paint_Shop, then unless you have done something to abnormally restrict those user's
rights (i.e. taken them out of the Domain Users group or other manual editing of rights), the
permissions are already setup, you're done. This is because Machine A trusts the PDC of the
Paint_Shop domain to advise it that BillJones has access, and Machine B trusts the PDC of the
Paint_Shop domain to advise it that JoeSmith has access.

Because of these relationships, getting an OPC client and OPC server on machines in the same
domain is probably the easiest scenario.

No Domain - What do you do ?

If you don't have a domain, it's OK. The risk of the PDC or having to have a BDC to decrease that
risk may be something your network design said doesn't work for you. If your NT/2000 machines
are not members of a domain, then they are running as standalone machines. Every NT/2000
machine (even those in a domain) has it's own "local" database of trusted users. When a machine
is not a member of the domain, the ONLY user accounts it will trust are those it finds in it's own
"local" security database.

Here is how this can get you into trouble on setting up and OPC client to server connection. If
machine A has an account JoeSmith and Machine B has an account BillJones, and that is all,
then how can an OPC client running as JoeSmith on Machine A, gain access to an OPC server
running as BIllJones on Machine B ? It can't -- when Machine B receives a request from the OPC
client, embedded inside that request is the notation "this is from user JoeSmith on Machine A".
Machine B says "I don't know any JoeSmith" and refuses the connection. The typical error
message thrown is "Access Denied". A sure sign you have this issue is when you try to connect
to a remote machine with an OPC client to browse available servers and you can't even connect
to the machine through the browse dialog without getting and "Access Denied" error. That's a
sure sign you have a permissions issue between your two boxes.

So what is the solution ? Well fortunately you can trick the boxes. All you need to do is create the
EXACT SAME user account names AND passwords on BOTH BOXES. So on Machine A, you
need to have an account JoeSmith AND BIllJones. On Machine B, you also need an account
JoeSmith and BIllJones. The passwords for BOTH JoeSmith accounts MUST match. The
passwords for the BillJones accounts must match on both boxes. JoeSmith and BillJones CAN
have different passwords between the two account names, and should for good security
measure. You should also make sure those accounts have identical access rights if you can.

Once you have that setup, when Machine A comes calling on Machine B with an OPC request
and identifies himself as JoeSmith with some password (it's encrypted), Machine B will look in it's
database, see the same accountname, the same password, and same "come on in request from
Machine A". When Machine B goes to return it's data from the OPC server to the OPC client on
machine B, the OPC server will go call Machine A as BillJones with a password -- Machine A will
look in it's database, see that it has that account, and accept the call.

A good way to see if you have these permissions set right is to go to Network Neighborhood,
browse from Machine A to Machine B and try to connect to Machine B. You may not have any
shared folders or printers, but so what - if you can connect to the machine without error, even if
no shared resources are available, you likely have solved the first phase of the Access
permissions challenge, gaining access to the machine. Your next step would be to make sure
that the users you've setup are granted the proper rights in the DCOM Config utility on the client
side and server side.

We know this may sound like a lot but if you read over this a few times, think about the simple
concept of Machine's A and B allowing people access to the machines, you can see why this
permissions issue is so crucial to proper DCOM configurations and setup.

If you have your basic access permissions working (i.e. you can at least see the machine and see
shared folders/shared printers), you can go on to DCOM Client setups or DCOM Server setups.

For Windows 2000/NT

DCOM Configuration Tutorial

OPC Client Computer Recommended Settings
DCOM Tutorial Home

This section is intended to provide general guidance on proper DCOM Config utility settings for
the computer on which your OPC Client application is running. Please note that depending on
whose OPC client you are running and how you intend to run your system (user logged in or not,
OPC server as a service or not, etc), these settings may vary. Software Toolbox is able to provide
extensive assistance with settings for OPC servers that are purchased from us (list of servers)
and limited assistance with OPC servers that are not bought from us, provided that you are using
one of our client applications such as the OPC Data ActiveX control.

This part of the tutorial is primarily oriented around the use of our OPC Data ActiveX control as an
OPC client, thought the concepts and principles used here can apply to other OPC clients. We
expect that you have already done the OPC server computer settings before doing this part.

If you are not already familiar with the DCOM Config utility and how to launch it, please review the
DCOM Config Utility Introduction. If you are familiar, please launch the DCOM Config utility on
the computer where your target OPC Client Application (this includes our OPC Data ActiveX
demo software if you are using it) is running if you intend to setup your machine with these
instructions.

Client Side DCOM Configuration Properties: Default Properties Tab

1. First, the Enable Distributed COM on this computer MUST be checked.

2. The Default Authentication Level should be set to Connect.

3. The Default Impersonation Level should be set to Identity

Note: There are other settings that can work, but there are also combinations that should have
been left out of this Microsoft utility. For example, if you set Authentication to connect and
Impersonation to Anonymous, you will not be able to access local OPC servers, much less
remote ones! The only other combination of these two settings we usually see as acceptable is
Authentication="None" and Impersonation ="Anonymous" or "Identify" which basically means to
"let anyone have access - don't authenticate any DCOM connections".

Client Side DCOM Configuration Properties: Default Security Tab

It is on this tab that you tell the operating system who you will allow to access the OPC client
application from remote OPC servers (Default Access Permissions). Unlike in the OPC server
side configuration, the only setting we are concerned with on the client side is the Default Access
Permissions on this tab.

It is important that you understand the concept of NT/2000 users and groups (read tutorial if you
do not) to make this part go smoothly. Before you start configuring, you will need to know the
following:

 What user name and/or groups that OPC Servers will be running under on the
machine(s) where OPC servers you wish to connect to are located.
 Whether this machine is a member of a domain or not and if so, the name of the domain
and associated domain users/groups you will grant access to.
 Whether or not you will be running the OPC server as an unattended NT/2000 service or
not. If running as a service, what user name (system account) or named user, you will be
running the service as.
 Note - the OPC clients on remote machines do NOT need to be Administrators on either
machine unless you want that - they can be regular user accounts, so long as you grant
them access in DCOM Config on the OPC server machine to Access and Launch the
OPC server, either explicitly through their user name or through a group containing them
(i.e. Domain users)

Client Side DCOM Configuration Properties: Default Security Tab - Default Access
Permissions Dialog

It is on this dialog that you will set who (i.e. users that remote OPC servers are running under) will
have access to make callbacks to this machine when subscription/exception based reads are
being done.

Important: Wrong settings here are the most common reason why we see users able to do one
time reads of remote OPC servers but NOT get data back when they are subscribed to the OPC
server and expecting the OPC server to send back data only when it changes. The key is that the
User Name or a Group containing the User Name that the remote OPC server is running under
be granted access here. Failure to grant access to the proper user or group will prevent the OPC
client from receiving the callbacks on subscription/exception reads from the remote OPC server.

To access this dialog, click on the Edit Default under the subheading Default Access Permissions
on the Dcom Config Default security tab.
In the dialog on the right, when you click "Add" you will be presented with a dialog that lets you
browse the local machine and domain (if applicable and logged into a domain) for users and
groups to grant permission to.

It is up to you to know what users and groups you wish to grant permissions to. If you want to be
very broad in your access you could add the Domain Group named "Everyone". A bit more
specific but still fairly "open" is to add the group "Domain Users".

Client Side DCOM Configuration Properties: Default Security Tab - Default Launch
Permissions Dialog

No changes normally required here.

Client Side DCOM Configuration Properties: Default Security Tab - Default Configuration
Permissions Dialog

No changes normally required here.

Client Side DCOM Configuration Properties: Default Protocols Tab

On this tab you set which of the installed network protocols on your computer to use for DCOM.
We recommend that you use Connection Oriented TCP-IP. You should have the preferred
protocol at the TOP of the list in this tab. If you don't want to use any of the other protocols,
remove them from the list. Note this does NOT remove the protocols from your computer, but
rather just says "do not use them for DCOM". The fewer the protocols in the list, the shorter your
timeouts will be in DCOM waiting for a call or connect to fail.

OPC Server Computer Recommended Settings - Step 1

OPC Server Settings Home | DCOM Tutorial Home | OPC Server Settings Step 2

This section covers the default DCOM settings for the OPC server computer.

If you are not already familiar with the DCOM Config utility and how to launch it, please review the
DCOM Config Utility Introduction. If you are familiar, please launch the DCOM Config utility on
the computer where your target OPC Server is running if you intend to setup your machine with
these instructions.

DCOM Configuration Properties: Default Properties Tab

1. First, the Enable Distributed COM on this computer MUST be checked.

2. The Default Authentication Level should be set to Connect.

3. The Default Impersonation Level should be set to Identity

Note: There are other settings that can work, but there are also combinations that should have
been left out of this Microsoft utility. For example, if you set Authentication to connect and
Impersonation to Anonymous, you will not be able to access local OPC servers, much less
remote ones! The only other combination of these two settings we usually see as acceptable is
Authentication="None" and Impersonation ="Anonymous" or "Identify" which basically means to
"let anyone have access - don't authenticate any DCOM connections".

DCOM Configuration Properties: Default Security Tab

This tab has the most settings to make. It is on this tab that you tell the operating system who
you will allow to access OPC servers on this machine (Default Access Permissions), who you will
allow to launch OPC servers on this machine (Default Launch permissions), and who you will
allow to configure OPC servers on this machine (Default Configuration Permissions. It is
important that you understand the concept of NT/2000 users and groups (read tutorial if you do
not) to make this part go smoothly. Before you start configuring, you will need to know the
following:

 What user name and/or groups that OPC clients will be running under on the remote
client machines
 What user name and/or groups that any local (same machine as the OPC server) OPC
clients will be running under.
 Whether this machine is a member of a domain or not and if so, the name of the domain
and associated domain users/groups you will grant access to.
 Whether or not you will be running the OPC server as an unattended NT/2000 service or
not. If running as a service, what user name (system account) or named user, you will be
running the service as.
 Note - the OPC clients on remote machines do NOT need to be Administrators on either
machine unless you want that - they can be regular user accounts, so long as you grant
them access in DCOM Config either explicitly through their user name or through a group
containing them (i.e. Domain users)

DCOM Configuration Properties: Default Security Tab - Default Access Permissions Dialog

It is on this dialog that you will set who will have access to OPC servers on this machine, unless
you override the settings for a specific OPC server on the Applications tab in DCOM Config. To
access this dialog, click on the Edit Default under the subheading Default Access Permissions on
the Dcom Config Default security tab.

In the dialog on the right, when you click "Add" you will be presented with a dialog that lets you
browse the local machine and domain (if applicable and logged into a domain) for users and
groups to grant permission to.

It is up to you to know what users and groups you wish to grant permissions to. If you want to be
very broad in your access you could add the Domain Group named "Everyone". A bit more
specific but still fairly "open" is to add the group "Domain Users".

DCOM Configuration Properties: Default Security Tab - Default Launch Permissions Dialog

It is here that you define who can actually start your OPC server on this computer. To access this
dialog, click on the Edit Default under the subheading Default Launch Permissions on the Dcom
Config Default security tab. Adding of users/groups is done the same way as was done for
Access Permissions.

If you plan to have a local client running on this computer and thus launching the OPC server or
have the OPC server running as a service, you will need to make sure that the username or
group containing the user that you intend to have launch the OPC server is included here.
Also, if you plan to NOT have the OPC server running until a remote client requests a connection,
at which time under COM rules, the OPC client will detect this and tell the server to activate, that
you MUST have the username OR a group containing the username that your remote OPC client
is running under included here. If you do NOT have this set right, and a remote client attempts to
connect, and the OPC server is not running ,it will not launch because that remote user does not
have "Launch Permissions".

Again, the rule of "know thy own users and groups applies." As a general statement, you can
include Adminstrators (local or domain) if you want be very broad. At a minimum you should
include the group INTERACTIVE so that local logged in users can launch the server and if you
are running the OPC server as a service you may need the SYSTEM account included as well.

DCOM Configuration Properties: Default Security Tab - Default Configuration Permissions

Dialog

To access this dialog, click on the Edit Default under the subheading Default Configuration
Permissions on the Dcom Config Default security tab

This dialog sets what users can change the DCOM configuration of the OPC servers on the
machine. Nearly all systems we see have this properly setup by default, therefore, we
recommend that if you are setting up DCOM the first time that you not change these settings. If
you have changed them before, we assume you know what you are doing by changing these
settings.

DCOM Configuration Properties: Default Protocols Tab

On this tab you set which of the installed network protocols on your computer to use for DCOM.
We recommend that you use Connection Oriented TCP-IP. You should have the preferred
protocol at the TOP of the list in this tab. If you don't want to use any of the other protocols,
remove them from the list. Note this does NOT remove the protocols from your computer, but
rather just says "do not use them for DCOM". The fewer the protocols in the list, the shorter your
timeouts will be in DCOM waiting for a call or connect to fail.