OutlookEX UDF - Help & Support (II)

[Malkavian99]

Sorry for the delayed response. Only get to work on this while at work.

I found out why I was still showing the old version.  I have corrected the issue with version 0.10.0.0.

Problem still exists. Errors have changed.

If Outlook is open and I run the script I get a 6002 error and the full email is left in the outbox.  If Outlook is closed and I run the program, I get a 4000 error and a partial email is left in the outbox.  The partial has nothing in the TO field and nothing in the body, only a subject line.

Attached is what add-ins we are running as the base install for our Outlook.

I really think that it is an issue with our exchange server, but I could be wrong.  Is there a way with the Outlookex.udf to open an email visible to the user with all the information added and allow them to hit the send button?  I'm wondering if this might correct the problem for now by allowing them to resolve the issue right then.  Right now they have to go into their Outbox, open the email and manually click send.

I have also determined it is not just this one person affected.  I have another email address that I'm using for testing and it does it on that one as well. Same issue, cannot resolve due to an address close to it.

 

[water]

Is there a way with the Outlookex.udf to open an email visible to the user with all the information added and allow them to hit the send button?

Sure.

You have to either create your own version of _OL_Wrapper_SendMail and add

$oItem.Display()

replacing

; Send mail
_OL_ItemSend($oOL, $oItem, Default)
If @error Then Return SetError(@error + 6000, @extended, 0)

Or you add the function calls wrapped in _OL_Wrapper_SendMail directly to your script.

[pfiore]

That method didn't work.  It gives us the Active Sync error we previously encountered.

COM Error Encountered in ResponseTest.au3
OutlookEx UDF version = 0.9.0
@AutoItVersion = 3.3.8.1
@AutoItX64 = 0
@Compiled = 0
@OSArch = X64
@OSVersion = WIN7
Scriptline = 84
NumberHex = 80020009
Number = -2147352567
WinDescription =
Description = Sorry, Exchange ActiveSync doesn't support what you're trying to do.
Source = Microsoft Outlook
HelpFile =
HelpContext = 0
LastDllError = 0

[water]

I wonder what line 84 is. It is not in the script I posted and in the UDF it is a comment line.

[pfiore]

Sorry that was your logic in our test script.  Line 84 mapped to the $oReply.Save() in the _OL_ItemReplyEX method.

I retried using your vanilla script and got the same error on line 53 which is the same $oReply.Save() in the _OL_ItemReplyEX method.
 

[Malkavian99]

Thanks for the the line on how to Display the item.  I copied the _OL_Wrapper_SendMail function and created the _OL_Wrapper_SendMailDisplay function in the Outlookex.au3 file and made the change to display.  This seems to be the best work around for right now. 

I was looking at the _OL_ItemSend function and the 6002 error seems to be generating from there, but the extended doesn't have anything, just show 0.

I will be looking into this a bit more with a co-worker that also work with autoit and see if he see's something I don't see.

[water]

Sorry that was your logic in our test script.  Line 84 mapped to the $oReply.Save() in the _OL_ItemReplyEX method.

I retried using your vanilla script and got the same error on line 53 which is the same $oReply.Save() in the _OL_ItemReplyEX method.

 

Strange. Maybe it's a bug?

[Malkavian99]

I think it is more a security feature has been enabled on Outlook via Group Policy or through the exchange server that if say an external program is accessing Outlook it wants you to verify the recipients if they are close to someone else.

It works on other email addresses just fine, just not when two or more are similar. Not sure how to make Outlook resolve. Even tried moving the email address from the first position to the second and got the same result. 

Edited November 12, 2013 by Malkavian99

[water]

You could use function _OL_ItemRecipientCheck to check the recipients.

The function returns a 2D array with a row for every recipient. If one of the recipients couldn't be resolved ($aResult[$i][1] = False) then call _OL_ItemRecipientSelect to let the suer select the correct recipient.

[Malkavian99]

Should I run that right before doing the sendmail wrapper using the recipients list?  I will read up on that.  I have been looking at our AD accounts for the two people and found some oddities concerning the other person.  I think the reason it is not resolving is certain things are not correct for the other person due to a recent name change.  I am working to get them corrected and see if that doesn't fix the issue.

[pfiore]

Strange. Maybe it's a bug?

Possible.

The initial work around you provided is working well at this time.

[water]

As I have no active sync to test I suggest to stick with the working solution

[water]

Should I run that right before doing the sendmail wrapper using the recipients list?  I will read up on that.  I have been looking at our AD accounts for the two people and found some oddities concerning the other person.  I think the reason it is not resolving is certain things are not correct for the other person due to a recent name change.  I am working to get them corrected and see if that doesn't fix the issue.

The idea is to check the recipients, select the correct one when Outlook couldn't resolve it and then pass the objects to the wrapper.

[Malkavian99]

I will work with that today.  I think we might have found the problem and it is a setting with our exchange server.  For automatic email updating our server keeps wanting to change a persons email address from Jane.A.Doe@aaa.com to JaneA.Doe@aaa.com.  We think they missed a setting to allow for multiple periods in the address name.  Until they fix it I will use the work around to the Recipients check to make it work.

[water]

If they are going to fix it in the next few days I would wait for the settings to be changed. My solution is a bit complex and I'm not 100% sure it works.

[Malkavian99]

I'm sure it will not be in the next few days.  I still have to try and describe the problem with our System Admins and then have them go to our central office to initiat the change across all exchange servers.  We have I think 10 across the country.

[water]

I see. Good luck

[Malkavian99]

Now I'm not sure if it is a problem. It might be a new security feature we implemented.  Central office does things and never tells the lonely techs in the field that something changed.

[water]

If it is a feature (and won't go away) we would need some time to code and test my "solution".

[Malkavian99]

Did some testing and had some odd results.  When it did the RecipientCheck it came back as True in the results, so the recipient is fine.  It seems to be something in our Outlook settings or group policy settings on our workstations that might be causing the issue.

Right now the address is being resolved through the Global Address Book.  Is it possible to put a address in that would be in the users personal contacts? Say like a mailing list the user has created?

Thanks