COM Add-ins Using Default Security
In Microsoft all COM add-ins that run on a computer, not configured to obtain security settings from a Microsoft Exchange Server, are considered trusted by default. This implies that the add-ins that run on clients that are not Exchange clients and the add-ins that use default security in Exchange environments are trusted automatically.
The main Application object that is passed to the OnConnection event of the add-in. Read below for more information.
COM Add-ins Using Security Settings from an Exchange Server
There has been no change in the way Outlook trusts COM add-ins in an Exchange environment when the security settings are obtained from the Exchange server. An add-in will be considered trusted only if it's registered in the Security Settings folder. Again, as in Outlook 2002, Outlook 2003 trusts only the main Application object that is passed to the OnConnection event of the add-in.
Outlook Object Model Guard Improvements and its Impact on COM Add-ins
Outlook 2003 inherits the Outlook 2002 object model guard behavior, and in addition, blocks code that attempts to access the Body and HTMLBody properties of various Outlook items. This allows users to verify that the program or add-in accessing the Body and HTMLBody properties of items is trustworthy, before they allow access to the contents of the items. Even though this displays security warnings in the existing COM add-ins that access the Body or HTMLBody properties of items, this will help prevent malicious code from running without the user being aware of it.
You can avoid the display of security warnings by deriving all objects, properties, and methods from the Application object passed in the OnConnection procedure of the add-in. Outlook trusts only the Application object passed in the OnConnection procedure of the add-in. If you create a new Application object - for example, by using the CreateObject method - that object and any of its subordinate objects, properties, and methods will not be trusted and the blocked properties and methods will throw security warnings.
Sample Code for Writing a Trusted COM Add-in
The following add-in uses only the Application object (TrustedOL) passed in the OnConnection procedure of the add-in. Therefore, it does not display security warnings if run in an environment not running Exchange or in an Exchange environment where the add-in has been trusted by the administrator using the Security Settings folder.
This add-in adds a button to the Standard toolbar called "MailItem." When the user clicks the MailItem button, the add-in creates a mailitem and displays a message to the user without displaying any security warnings.
Dim TrustedOL As Outlook.Application
Dim WithEvents oButton As Office.CommandBarButton
Private Sub AddinInstance_OnConnection(ByVal Application As Object,
ByVal ConnectMode As AddInDesignerObjects.ext_ConnectMode, ByVal
AddInInst As Object, custom() As Variant)
Set TrustedOL = Application
Set oButton = TrustedOL.ActiveExplorer.CommandBars.Item("Standard").Controls.Add(, , , 1, True)
oButton.Caption = "MailItem"
Private Sub AddinInstance_OnDisconnection(ByVal RemoveMode As
AddInDesignerObjects.ext_DisconnectMode, custom() As Variant)
Set TrustedOL = Nothing
Set oButton = Nothing
Private Sub obutton_Click(ByVal Ctrl As Office.CommandBarButton,
CancelDefault As Boolean)
Dim MI As Outlook.MailItem
Dim oFolder As Outlook.MAPIFolder
Dim MI2 As Outlook.MailItem
Set MI = TrustedOL.CreateItem(olMailItem)
MI.To = TrustedOL.Session.CurrentUser
MI.Subject = "Test message from COM add-in"
MI.Body = "This is the body."
Set oFolder = TrustedOL.Session.GetDefaultFolder(olFolderInbox)
MsgBox ("I am going to move the item.")
Set MI2 = MI.Move(oFolder)
Set MI = Nothing
Set oFolder = Nothing
Set MI2 = Nothing
Note For more information on writing trusted Outlook COM add-ins, see OL2002: How to Create Trusted Outlook COM Add-ins.
The following are known issues that result in an add-in hitting object model blocks even though it is constructed properly using the trust mechanism and is considered trusted by Outlook 2003.
Using the Inspector object in an Outlook form
When you attempt to bind a control to a property derived from the Inspector object, Outlook 2003 will show the security warning. A Microsoft Visual Basic for Applications (VBA) example is shown below with the line of code that shows the error highlighted in bold text. In this example, the control is being bound to a custom property, but Outlook will show a security warning if you try to bind a control to any property derived from the Inspector object.
Private Sub obutton_Click(ByVal ctrl As Office.CommandBarButton,
CancelDefault As Boolean)
Dim mai As Outlook.MailItem
Dim uprs As Outlook.UserProperties
Dim upr As Outlook.UserProperty
Dim isp As Outlook.Inspector
Dim pags As Pages
Dim pag As MSForms.UserForm
Dim ctrl1 As MSForms.Control
Dim ctrls As MSForms.Controls
Set mai = outApp.CreateItem(olMailItem)
mai.To = outApp.Session.CurrentUser
mai.Subject = "Yes/No binding to a Controls"
Set uprs = mai.UserProperties
Set isp = mai.GetInspector
Set pags = isp.ModifiedFormPages
Set pag = pags.Add("MyFirstPage")
Set upr = uprs.Add("MyFormula", olFormula)
upr.Formula = "[To]"
Set ctrls = pag.Controls
Set ctrl1 = ctrls.Add("Forms.TextBox.1", "MyText", 1)
ctrl1.ItemProperty = "MyFormula"
ctrl1.ControlProperty = "Value"
A workaround for this scenario is to use the SetControlItemProperty method of the Inspector object, replacing the line that causes the security warning:
ctrl1.ItemProperty = "MyFormula"
With this line:
New Object Model Blocks in Outlook 2003
The following are the additional properties that have been blocked in Outlook 2003:
The IMAddress and Body properties of a ContactItem object.
The HTMLBody and Body properties of a MailItem object.
The HTMLBody and Body properties of a PostItem object.
The Body property of an AppointmentItem object.
The Body property of a TaskItem object.
The Body property of a TaskRequestItem object.
The Body property of a TaskRequestAcceptItem object.
The Body property of a TaskRequestDeclineItem object.
The Body property of a TaskRequestUpdateItem object.
The Body property of a DistListItem object.
The Body property of a JournalItem object.
The Body property of a MeetingItem object.
The Body property of a ReportItem object.
The Body property of a RemoteItem object.
The Body property of a NoteItem object.
The Body property of a DocumentItem object.
Also, if you use a third-party add-ins, custom solutions, or other programs that integrates with Outlook 2003, you may receive one or more of the following warnings:
A program is trying to automatically send e-mail on your behalf. Do you want to allow this? If you unexpectedly receive this message, it may be caused by a virus, and you should choose No.
A program is trying to access e-mail addresses you have stored in Outlook. Do you want to allow this? If you unexpectedly receive this message, it may be caused by a virus, and you should choose No.
These warning messages are commonly associated with software that is designed to synchronize Outlook data with handheld computers, but may occur with any type of add-in or custom solution.
Note For more information about the Outlook 2002 Object Model Guard, see Microsoft Outlook 2002 Developer Security Overview.
Why a Change in Trust Model in Outlook 2003 and Not in Previous Versions of Outlook?
There are two major factors that contributed to this change in trust model in Outlook 2003. The first is that Outlook 2003 is the first version of Outlook that has Microsoft Windows 2000 SP3 as its minimum platform version. Previous versions of Outlook supported Microsoft Windows 98 operating systems. The second reason is that with the additional object model blocks that are added in Outlook 2003, there are tasks that independent software vendors (ISV) need to handle, that do not have any simple workarounds.
© 2022 Better Solutions Limited. All Rights Reserved. © 2022 Better Solutions Limited TopPrev