>>>>>>Is there a way to create an instance of a control on the client when the control resides on the server?
>>>>>>
>>>>>>Thanks for any help...
>>>>>>Michael
>>>>>
>>>>>Yes, this is what DCOM does. The client machine has to know the location of the server's control. You configure this and additional security settings with DCOMCNFG.
>>>>
>>>>Does that mean I have to configure each client, or configure the server to tell each client where to look?
>>>>
>>>>Thanks...
>>>>Michael
>>>
>>>You have to configure each client. There is probably a way to do this programmatically, but I don't know how. Ed?
>>
>>It's not too difficult; there's actually good documentation on a relatively simple approach using the Windows Scripting Host in the MSDN docs under the topic DCOM, registration element, which includes sample VBScript for registering both local and DCOM components using scripting. The MSDN documentation can be found on-line at msdn.microsoft.com, and I think is also available in the currently downloadable documentation on the WSH, as a part of the Script Component Tutorial.
>>
>>WSH makes life much easier... < g >
>
>After reading some of Rick Strahl's white papers, I was under the impression, when using DCOM, you did not have to install the full version on the client machine. You can just register the typelibrary. Simply copy the .VBR file to the client machine and running CLIREG32. Since I am not that familiar with the process, I was wondering if what I have stated is accurate.

See the MSDN entry on Registering a Script Component for Remote Instantiation in the MSDN documentation; it defines the exact requirements quite concisely. This is included in the Script Component Turtorial. It even suggests an exact method to create the proer registry information by exporting the necessary registry key data to a .REG file, which can then be used on local computers to create the necessary registry entries.