Outlook default security settings

[Guest]

We are an Outlook 2003/Exchange 2003 shop. When Exchange 2003 was
introduced, our engineer at the time created an Outlook Security Settings
form for default user settings. When we migrated our desktops to Windows XP,
though, the registry key to activate the default custom settings was dropped
out. Now when I add that reg key for a user, I suddenly get security
warnings about an add-in that I did not get prior to adding the key. It's as
though the system default security settings are not as stringent as those on
the form. But I cannot find another source for the settings. What are the
system defaults and where can I find them?

 

[Sue Mosher [MVP-Outlook]]

What kind of security warnings?

 

[Guest]

They say "A program is trying to access e-mail addresses you have stored in
Outlook. Do you want to allow this?" We know this is caused by a third party
Outlook add-in.

 

[Sue Mosher [MVP-Outlook]]

In that case, you should check to see whether your security settings form item is trusting that particular add-in. The registry entry you mentioned transfers control of the "object model guard" security to the security settings folder.

--
Sue Mosher, Outlook MVP
Author of Microsoft Outlook 2007 Programming:
Jumpstart for Power Users and Administrators
http://www.outlookcode.com/article.aspx?id=54

They say "A program is trying to access e-mail addresses you have stored in
Outlook. Do you want to allow this?" We know this is caused by a third party
Outlook add-in.

 

[Guest]

Thanks, Sue. I did add the add-in's dll to the trusted code page of the form,
but here's the odd thing: if the reg key is set to 0 (no transfer of control)
then I do not get the security prompt; if the reg key is set to 1 (use the
form) I do get the prompt. Doesn't that sound like the system default
settings are somehow less stringent (less secure) than those on the security
form?

 

[Sue Mosher [MVP-Outlook]]

Not at all. In fact, that behavior makes perfect sense. If the value is 0, then Outlook's default security applies, which means all add-ins are trusted. If it's anything else, then the security settings folder options apply, and the only add-ins that are trusted are those on the trusted code page. In other words, the security is tighter when the folder options are in control.

My guess is that the security settings item that is trusting the add-in just isn't working correctly -- or users have a different version of the ..dll installed from the one that was trusted on the security settings form. I'd suggest checking the versions, deleting the security settings item, and creating a new one. Make sure you do this using a mail profile that does not use Cached Exchange mode.

--
Sue Mosher, Outlook MVP
Author of Microsoft Outlook 2007 Programming:
Jumpstart for Power Users and Administrators
http://www.outlookcode.com/article.aspx?id=54

 

[Guest]

Ah, so. Thank you very much, Sue!

 

[Guest]

This is fruitful information, Sue, and leads me to another question: we have
another 3rd party Outlook add-in that causes the same security warning - even
without using the form, just with the default security. Are there levels of
trust or different aspects of trust that would account for this?

 

[Sue Mosher [MVP-Outlook]]

At issue is how the add-in itself is constructed. What is actually "trusted" in an add-in is a particular programming object that represents the Outlook application itself, plus all other Outlook objects derived from that first one. If the add-in is not constructed properly so that it uses that particular Application object to derive all others, it will always trigger security prompts, even if you trust it with the security settings form. The add-in could also be using the CDO 1.21 library, which cannot be trusted in the same way as an add-in. To avoid CDO security prompts, you would modify the settings on the second page of the security settings form, but that would apply to all applications.

--
Sue Mosher, Outlook MVP
Author of Microsoft Outlook 2007 Programming:
Jumpstart for Power Users and Administrators
http://www.outlookcode.com/article.aspx?id=54

 

[Guest]

Got it. Thanks, Sue!
--
Kate Brown

At issue is how the add-in itself is constructed. What is actually "trusted" in an add-in is a particular programming object that represents the Outlook application itself, plus all other Outlook objects derived from that first one. If the add-in is not constructed properly so that it uses that particular Application object to derive all others, it will always trigger security prompts, even if you trust it with the security settings form. The add-in could also be using the CDO 1.21 library, which cannot be trusted in the same way as an add-in. To avoid CDO security prompts, you would modify the settings on the second page of the security settings form, but that would apply to all applications.

--
Sue Mosher, Outlook MVP
Author of Microsoft Outlook 2007 Programming:
Jumpstart for Power Users and Administrators
http://www.outlookcode.com/article.aspx?id=54