Accessing Outlook via COM on remote machine

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Accessing Outlook via COM on remote machine

Scott
I generated the COM interfaces for (Microsoft Outlook) msoutl9.olb
with the ActiveX Component Wizard with class prefix Outlook.

My problem arises when trying to access Microsoft Outlook on a remote
machine using the following code.

outlook := Outlook_Application onCLSID: Outlook_Application clsid
hostName: 'DELL'.
outlook session currentUser
    answers - "an OutlookRecipient('Scott Dumonceaux')"

outlook := Outlook_Application onCLSID: Outlook_Application clsid
hostName: 'MIC'.
outlook session currentUser
    answers - "an OutlookRecipient('Scott Dumonceaux')"

'Dell' is my machine and should answer "an OutlookRecipient('Scott
Dumonceaux')"
but 'MIC' is my girlfriends machine and should not answer that.

I get no error message connecting to the other machine, so it looks
like it successfully connected to the remote machine, but the data
indicates that it is only connecting to the local machine.  (I have
also checked other data like emails and contacts)

I would appreciated any help on how to connect OutLook on a remote
machine.

Thanks,
Scott


Reply | Threaded
Open this post in threaded view
|

Re: Accessing Outlook via COM on remote machine

Bill Schwab-2
Scott,

> outlook := Outlook_Application onCLSID: Outlook_Application clsid
> hostName: 'MIC'.
> outlook session currentUser
>     answers - "an OutlookRecipient('Scott Dumonceaux')"
>
> 'Dell' is my machine and should answer "an OutlookRecipient('Scott
> Dumonceaux')"
> but 'MIC' is my girlfriends machine and should not answer that.
>
> I get no error message connecting to the other machine, so it looks
> like it successfully connected to the remote machine, but the data
> indicates that it is only connecting to the local machine.  (I have
> also checked other data like emails and contacts)

You're venturing into DCOM, which is (asking for strength here<g>) marginal
technology at best.  Even if you do get it working, it's unlikely to be
reliable because the error handling is (asking for even more strength<g>)
apparently based on the idea that machines never crash, never get turned
off, never reboot while a peer thinks it's still connected, networks never
fail, etc.  I've worked with at least three CORBA ORBs, and all of them put
DCOM to shame in their ability to recognize that the other side wasn't
cooking on all burners.

Depending on the OS, you might need to make some changes to enable DCOM or
arrange for sufficient privileges on the right account for OE to run.  Also,
crossing between 9x and NT and then back can cause problems because of the
different approaches to security.  In the end, you'll probably do better to
do the networking yourself via sockets between two Dolphin apps, one of
which runs OE locally.

> I would appreciated any help on how to connect OutLook on a remote
> machine.

If you do make it work, please tell us - given the number of security holes
in OE, if it can be launched "for me" then I'll uninstall it from every
machine I own/control :)

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Accessing Outlook via COM on remote machine

Blair McGlashan
In reply to this post by Scott
"Scott" <[hidden email]> wrote in message
news:[hidden email]...
> I generated the COM interfaces for (Microsoft Outlook) msoutl9.olb
> with the ActiveX Component Wizard with class prefix Outlook.
>
> My problem arises when trying to access Microsoft Outlook on a remote
> machine using the following code.
...[snip demonstration of getting local object]...
>
> I get no error message connecting to the other machine, so it looks
> like it successfully connected to the remote machine, but the data
> indicates that it is only connecting to the local machine.  (I have
> also checked other data like emails and contacts)

As a consequence of the way Dolphin creates objects, even when a hostname is
specified a local implementation of the object will take precedence. I think
this is probably a bug in
COMInterface>>onCLSID:outerIUnknown:hostName:licenseKey:, from which one can
see that if a hostname is specified then the creation context flag
CLSCTX_REMOTE_SERVER is #bitOr:'d in with the default creation context flags
(which includes the flags for in-proc and local servers) rather than
replacing the default flags entirely. As a result if there is a local
version of the component available, then it will be used in preference.

To "fix" this replace the line:

    dwClsContext := dwClsContext bitOr: CLSCTX_REMOTE_SERVER].

with:

    dwClsContext := CLSCTX_REMOTE_SERVER].

You may find that after doing this that you get an error when attempting to
create the remote object, in which case you are in the realms of DCOM
configuration (Start/Run... "DCOMCNFG"). Frankly I've no idea how all this
is set up now in these days of COM+ and "component services", so perhaps
someone else more knowledgeable could chip in.

Regards

Blair