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.
Warning: contents of this tutorial are Copyright Software Toolbox, Inc. 2001-2002, and
may not be reproduced in electronic or written form without written permission of Software Toolbox Inc. Anyone found copying copyrighted material from
this site for use on another site will be prosecuted. You are welcome to link to this site from your site. The information in this article is
accurate to the best of our professional judgement at the time of writing but is subject to change.