Accessing Outlook via COM on remote machine 
Author Message
 Accessing Outlook via COM on remote machine

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



Sat, 08 Jan 2005 13:04:07 GMT  
 Accessing Outlook via COM on remote machine
Scott,

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

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



Sat, 08 Jan 2005 21:52:23 GMT  
 Accessing Outlook via COM on remote machine


Quote:
> 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]...

Quote:

> 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



Sun, 09 Jan 2005 01:07:28 GMT  
 
 [ 3 post ] 

 Relevant Pages 

1. Accessing Outlook via COM

2. Outlook COM access warning dialog?

3. Accessing a remote machine

4. remote machine access using tcl

5. Python accessing Excel 97 via com

6. Importing via Access 97 odbc driver variable length Access Memo fiels

7. how can i send message to this newsgroup via outlook express

8. Sending Mail via outlook

9. Labview mailing via exchange/outlook

10. Accessing Access via VO

11. automate retrieving/sending outlook email via tcl/expect

12. Using remote MySQL server with PHP via HTTP

 

 
Powered by phpBB® Forum Software