Outlook Guard - Trusted Locations 1

[1DMF]

Hi,

I have a thread in the VBA forum but want to cover all bases with where the problem may lie.

thread181-1723386

I have many applications all with a Trusted Location reg keys set for their application path.

Most of the time they work fine, then out of the blue for no apparent reason, they stop working and Outlook throws up the Outlook guard regarding something trying to send emails.

For the time being I have gone back to putting 'express click yes' on peoples machines, something I thought I had seen the back of since moving away from Office 2003.

Any help resolving this is appreciated, it's driving not just me but especially my users totally nuts with this annoying nag popup protection.

Thanks,
1DMF

"In complete darkness we are all the same, it is only our knowledge and wisdom that separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!"
Free Electronic Dance Music

 

[1DMF]

I have had a response to my issue via the MSDN network.

Apparently the MSDN article regarding the OOMG (Outlook Object Model Guard) is wrong when it keeps stating...

This warning is invoked when an untrusted solution attempts to send an item programmatically.

I've now been told that Outlook doesn't know the difference between a trusted application and an untrusted one, so the reg_keys don't do anything.

It would seem that the likely culprit is the problems we have had lately with the management of our McAfee A/V and the update failures.

Having checked the trust center security settings for programmatic access, it is set as...

Warn me about suspicious activity when my antivirus software is inactive or out-of-date

I believe this could be the problem and the 'trusted' / 'untrusted' comments on the MSDN site and the belief I could set the application as trusted via Trusted Location reg_keys sent me in the wrong direction.

So if you start getting this OOMG out of the blue when you didn't before, check your AV is up-to-date!



"In complete darkness we are all the same, it is only our knowledge and wisdom that separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!"
Free Electronic Dance Music

 

[1DMF]

We are still having a lot of problems with the OOMG.

As our AV provider uses McAfee and it keeps failing to update or communicate with their central management console system.

We have now been told by them that the reason MS Access and Outlook are having these problems is because of an incompatibility with Internet Explorer 11, and we need to downgrade IE to resolve the problem.

Outlook hasn't used IE since 2007, how can this be the problem?

All input appreciated.

1DMF.

"In complete darkness we are all the same, it is only our knowledge and wisdom that separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!"
Free Electronic Dance Music

 

[strongm]

Here's Microsoft on the subject (not answering the question about IE, just clarifying the AV situation). This refers to Outlook 2007 and later:

By default, Outlook relies on the existence and the status of an appropriate antivirus software on the client computer to trust cross-process applications: if Outlook detects that antivirus software is running with an acceptable status, Outlook will disable security warnings for the end user. All cross-process COM callers and add-ins will run without security warnings if all of the following conditions hold:

•The client computer is running Windows XP Service Pack 2 (SP2), Windows Vista, or a later version of Windows, and Windows Security Center (WSC) indicates that antivirus software on the computer is in a "Good" health status.

•The antivirus software installed on the client computer is designed for Windows XP SP2, Windows Vista, or later.

•Outlook is configured on the client computer in one of the following ways:

◦Uses the default Outlook security settings (that is, no Group Policy set up)

◦Uses security settings defined by Group Policy but does not have programmatic access policy applied

◦Uses security settings defined by Group Policy which is set to warn when the antivirus software is inactive or out of date​

So we can assume (from other threads) that you are running Windows 7 and Outlook 2007 (or possibly Outlook 2010)

None of which involves IE (of any version) at all. Perhaps your AV supplier would like to explain how IE could be causing this 'incompatibility'. Or are they suggesting that the problem is that somehow it is IE11 that is causing your workstations to "keep[] failing to update or communicate with their central management console system". Which would be odd, unless they are using some sort of bespoke tool to do that rather than McAfee's built-in updating capability

Alternatively, you might like to consider using CDO ...

 

[1DMF]

Thanks Mike,

I didn't think it was the likely cause, but that's what my boss has been told and he has accepted it and allowed them do downgrade all users to IE10.

The OOMG is behaving correctly, it's the fact McAfee isn't working properly, that is triggering the OOMG - as it should.

I didn't think I could Use CDO anymore, as I used to, or was that just a versioning thing? I used to use CDO 1.2.1

I moved to OOM as I thought it was the right think to do especially as Access 2010 won't let you run CDO 1.2.1

However, the 'something is trying to send an email' warning used to pop up when using CDO and I used to use ExpressClickYes to resolve the problem.

We never had a problem with OOMG until we outsourced the corporate AV management and they implemented McAfee!

"In complete darkness we are all the same, it is only our knowledge and wisdom that separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!"
Free Electronic Dance Music

 

[strongm]

Oh, CDO has moved on a lot since CDO 1.2.1, which is ancient (and as you allude, long deprecated)

The only thing it has in common is the name. CDO 1.2.1 was basically just a wrapper for certain bits of Outlook (which is why you got the warning messages). I'm talking about the Microsoft CDO for Windows 2000 (nominally CDO 2.0) library, which is a full SMTP client (and, oddly, NNTP), and does not need or use Outlook at all. It has been shipping as part of the OS for almost 15 years ...

Here's how complicated it is to send a basic email:

[blue][green]' Requires a reference to Microsoft CDO for Windows 2000[/green]
Public Sub SendMail()
    Dim cdoMsg As New CDO.Message

    With cdoMsg
        With .Configuration.Fields
            .Item(cdoSendUsingMethod).Value = cdoSendUsingPort
            .Item(cdoSMTPServerPort).Value = 25
            .Item(cdoSMTPServer).Value = "some.smtp.gateway" ' this could be your local Exchange server
            .Item(cdoSendUserName).Value = "<sender>" 
            [green]' If SMTP gateway requires authentication
            '.Item(cdoSendPassword).Value = "<password>"
            '.Item(cdoSMTPAuthenticate).Value = cdoBasic[/green]
            .Update
        End With
        .From = "me@company.com"
        .To = "my.friend@somewhere.net"
        .Subject = "tektips example"
        .TextBody = "Here is an example text message" & vbNewLine & "It is alo very easy to send HTML messages as well"
        [green]' Want an attachment?
        '.AddAttachment "<path to document>"[/green]
        On Error Resume Next 
        .Send
    End With
    
    If Err.Number <> 0 Then
        MsgBox "CDO error " & Hex$(Err.Number) & vbNewLine & Err.Description
    Else
        MsgBox "Mail sent!"
    End If
End Sub[/blue]

 

[1DMF]

Cool, I think I might incorporate this in one of my refactoring task due to some major changes in one of our app. Would be a good test to see how it performs in comparison to the current OOM wrapper I am using.

Is there anything special I need to have set up on the Exchange server to receive the SMTP request?

I need to run using windows authentication for domain user, but that won't work for remote users who don't log on to the domain!

The last thing I want is for them to have to keep providing a username and password each time an application tries to send an email, the apps have no idea what their domain / exchange password is plus it changes on a regular basis under our password policy GPO.

At least with using Outlook, it manages who is sending the email and ensures their sent items is correctly populated.



"In complete darkness we are all the same, it is only our knowledge and wisdom that separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!"
Free Electronic Dance Music

 

[strongm]

>Is there anything special I need to have set up on the Exchange server to receive the SMTP request?

You may have to configure relaying. Depends where the emails are being sent. If just to internal recipients you shouldn't have to do anything since the traffic will appear just like all other incoming SMTP traffic.

>The last thing I want is for them to have to keep providing a username and password

Since you are sending via Exchange's SMTP gateway you should only need cdoSendUserName, and that should be populated with the name from the default Outlook mail profile (if it exists).

 

[1DMF]

The other thing I need to do it grab the sent email and store a copy on a network drive, is that possible with CDO?

Am I delving into the realms of MAPI and Exchange?

"In complete darkness we are all the same, it is only our knowledge and wisdom that separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!"
Free Electronic Dance Music

 

[strongm]

> unless they are using some sort of bespoke tool to do that rather than McAfee's built-in updating capability

Actually, I suppose it might be this:

https://support.mcafeesaas.com/MCAFEE/_cs/AnswerDetail.aspx?sSessionID=&aid=191031

> grab the sent email and store a copy on a network drive

Well, there are number of strategies for this (e.g journaling or transport rules to name just 2) - and which you might want depends very much on why you need to store them (simple archive, audit trail, statutory compliance, etc)

What you certainly can't get from the CDO solution is an eml file. On the other hand you can get the full SMTP message really easily. Once the message has been sent successfully, just add the following line of code:

cdoMsg.GetStream.SaveToFile "<TARGET_TEXT_FILE>"

It's that simple.

 

[1DMF]

I was actually after a .msg file, for compliance requirement. We already run email archiving inline with Sarbanes Oxley, but certain systems the boss wants sent emails (and received , hence using your drag/drop code - many thank!), attached to the particular database record, so when others view the case record, they have access to the email audit trail, which otherwise would only reside in the users sent items / in-box.

I assume <TARGET> doesn't have to be plain text and could be .msg with HTML content and attachments?

Re: McAfee, that notice is for those using the control centre, the problem we are having is when Access opens an Outlook object and tries to send it, triggering the OOMG because McAfee isn't updating or communicating with the central management console and Windows is reporting AV status as bad!.

Incidentally, the support company actually downgraded all users to IE9 last night, and are now scratching their heads because for some reason it hasn't resolved the problem!






"In complete darkness we are all the same, it is only our knowledge and wisdom that separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!"
Free Electronic Dance Music

 

[strongm]

> McAfee, that notice is for those using the control centre

I know. My suspicion is that the company was grasping at straws, and was and were concluding that perhaps your policies (which control updates) were being corrupted because of using IE11 with the console. Hence get rid of IE11 to fix the problem. Of course they'd then still need to fix the broken policies since the existence of IE11 isn't where the problem lies.

>doesn't have to be plain text

Well, yes, actually. In fact ASCII only. Since that is all SMTP supports. Non-ASCII contents get MIME encrypted.

 

[1DMF]

OK, perhaps not appropriate for my needs then.

As always really appreciate your input.

Regards,
1DMF

"In complete darkness we are all the same, it is only our knowledge and wisdom that separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!"
Free Electronic Dance Music

 

[strongm]

Just to clarify, those MIME encrypted contents would be your attachments. They'd be in the text file. Just 'encrypted' so that they can be represented in ASCII. And there are plenty of tools that will read happily MIME encrypted text files (since that's how SMTP works ...)

 

[strongm]

(I should probably have used the word 'encoded' rather than 'encrypted', but I've been spending the day working on a PKI solution ...)

 

[1DMF]

No problem, I understood what you meant. I also appreciated that I could transform / decode the MIME data, but it's a lot of work, and a learning curve, especially when you consider I already have a great working solution doing exactly what we want, well apart from the poor AV management currently screwing things up!

Perhaps when the current 'requests' workload dies down, it's something I could look at reworking, and remove Outlook from the equation, but considering one of the requests is a complete re-write of the members' extranet, it's not going to be any time soon, or perhaps even this year!

The current ability to save an MSG file as a container for the email and the ability to hyperlink to it and it just opens in Outlook, is a nice, simple to use way of doing this, and usually it works fine ;-)

"In complete darkness we are all the same, it is only our knowledge and wisdom that separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!"
Free Electronic Dance Music