|
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.
|