Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

Support programmatic startup of Outlook in Enterprise Vault

Created: 09 Jul 2012 • Updated: 31 Jul 2012 | 13 comments
Laurence Lederman's picture
1 Agree
0 Disagree
+1 1 Vote
Login to vote
Status: Reviewed

Enterprise Vault Add-in for Outlook 2010 does not work if Outlook is started programatically through Microsoft APIs.

Problem Scenario

On a PC with the EV add-in installed and enabled:

  1. Start Microsoft Outlook programmatically (using the Microsoft Outlook published API) so that the Outlook User Interface is not visible (see example code below).
  2. Start the Microsoft Outlook User Interface normally from a shortcut.

Problem Description

The following problems are experienced in this scenario:

  1. The Enterprise Vault ribbon tab does not display.
  2. The Enterprise Vault option under the “File” tab also does not display.
  3. The add-in provided functions fail to operate through the Outlook UI as a result.
  4. Access to items stored in the users local Vault Cache become inaccessible through Microsoft Outlooks UI.
  5. Programmatic access to such items via the Outlook API generally fails with a COM Exception of the form: “System.Runtime.InteropServices.COMException (0x80040201): The operation failed.  The messaging interfaces have returned an unknown error. If the problem persists, restart Outlook.”
  6. Symantec support state that this behaviour is not a bug and that programmatically starting Outlook is not supported in their add-in. Outlook’s API however, reports that the add-in is indeed loaded.
  7. If Outlook is started and then connected to programmatically, the Enterprise Vault add-in behaves normally.

Required Behaviour

The Enterprise Vault add-in should display its user interface elements and operate normally under the problem scenario described, i.e. in the same way that it operates when Outlook is started in the usual way from a shortcut without a programmatic start having been performed first.

Impact Statement

Many commercial and departmental applications integrate with Microsoft Outlook in this way or through other supported Microsoft integration platform techniques. The current behaviour of the EV Add-In effectively renders the add-in unusable in such environments.

Example Code

Create a simple Windows Forms application using Visual Studio; add the following code to, for example, a form button control click event handler.

VB.Net

Dim objOutlookApplication As Outlook.Application

objOutlookApplication = CreateObject("Outlook.Application")

Dim objNamespace As Outlook.NameSpace = objOutlookApplication.GetNamespace("MAPI")

Dim objFolder As Outlook.Folder

objFolder = objNamespace.GetDefaultFolder(Outlook.OlDefaultFolders.olFolderInbox)

C#.Net

Outlook.Application objOutlookApplication = default(Outlook.Application);

objOutlookApplication = Interaction.CreateObject("Outlook.Application");

Outlook.NameSpace objNamespace = objOutlookApplication.GetNamespace("MAPI");

Outlook.Folder objFolder = default(Outlook.Folder);

objFolder = objNamespace.GetDefaultFolder(Outlook.OlDefaultFolders.olFolderInbox);

Comments 13 CommentsJump to latest comment

Jim Nolan's picture

Programatically removing and readding the add in using the Outlook Object Model will make the EV tab visible but in turn causes all sorts of stability issues.

0
Login to vote
JesusWept3's picture

I remember I worked on one heck of a case back for 2007 when the OOM was slowly becoming defacto and we had a customer who had a start up app to show the outlook calendar on the desktop and then when they launched outlook the log files exploded

I seem to remember it was because it was switching contexts so that the client attempted to load the first time and certain things failed and then when actual outlook was launched it couldn't lock a mutex, so every time it tried to perform a function and go to sleep for one minute, the sleep would fail and it was doing the checks about 100 times a second and causing logs to explode until it had filled the drive space

It did eventually get fixed as a one off for the customer that eventually got written in to the code, but technically speaking it was correct that the methods for us were just not supported and didn't even have that design consideration in mind

If its a company wide application that everyone uses and it's affecting user experience then I would push back on Symantec and asked for it to be etracked

0
Login to vote
Alex Brown's picture

The EV Outlook Add-in does has not been testing against Outlook being invoked programatically. In theory the EV Add-in should just load as it is implemented against the Outlook Object Model and should therefore be invoked automatically as Outlook starts.

Having said that almost every use case we see on a regular basis involves Outlook being run interactively and to this point there are currently no plans to change our testing methodlogy on this.

0
Login to vote
Jim Nolan's picture

It is a little strange for a software vendor to produce an Outlook Add-In and then not ensure it works correctly when invoked through a very common way of starting Outlook, the Outlook Object Model. The main issue I have with Symantecs stance on this is that you report the add is loaded when Outlook is started through this method. If its not supported and/or does not work correctly in this context then it should not be loaded at all in order to avoid impacting the stability of Outlook itself (which is an unfortuate by product of it half working).

0
Login to vote
Rob.Wilcox's picture

So, why is Outlook being started programatically?

0
Login to vote
Jim Nolan's picture

We have a business application that integrates e-Mail capabilities seamlessly into core business processes.

There are a number of function points but one example is as follows. We provide a screen that allows users to file e-Mails into our Enterprise Document Management System. The screen provides a tree of folders on one side and a list of e-Mails (for example the users inbox) on the other. Users can file e-Mails by dragging and dropping them onto the folder tree. Depending on the content of the e-Mails being filed, this then kicks off a workflow process to, for example, process an insurance claim if the e-Mail is a loss notification. 

The integration is achieved using the Outlook Object Model ergo Outlook is started programatically (indeed in much the same way as Word, Excel etc start it when using the "Mail As" style functions within those products). We have looked at other integration techniques that avoid the need to use the Outlook Object Model such as using a 3rd party Exchange MAPI client (Redemption RDO) but this surfaced a memory leak issue with Redemption which rendered it unusable.

0
Login to vote
Jim Nolan's picture

Could Symantec comment further on the issue given that this functionality works correctly in the Outlook 2003 version of the EV Add-In and no longer works in Outlook 2010 version of the EV Add-In

0
Login to vote
Rob.Wilcox's picture

Jim - have you raised the issue through the support channels?

0
Login to vote
Jim Nolan's picture

Rob - Yes we did and were told it was not a "bug" but a feature request and were therefore directed by support to log it here. As you can probably tell, I am not exactly in agreement that this is anything other than a bug.

0
Login to vote
Rob.Wilcox's picture

Hmm.. you say it works with Oultook 2003 version of the add-in.. but not the 2010 version. I take you mean a version of the add-in prior to 10.0.1? The 10.0.1 client 'unified' the add-ins, so rather than there being a HTTP add-in and DCOM add-in there is now only one.

Have you tried the 10.0.1 unified client?

What version have you tried in your original post (sorry if you have already stated that)

0
Login to vote
Jim Nolan's picture

Rob

The version we are using under Outlook 2003 is 8.0.4.2002.0 (http). This is found under Help>About Enterprise Vault.

The version under Outlook 2010 is not posssible to find by the same method. The event log yeilds the following start up info and examination of Valkerie.dll reveals its version 9.0.2.1061 (see below):

Name: Enterprise Vault Add-in

Description: Provides features within Outlook for the Enterprise Vault application.

ProgID: EnterpriseVault.DesktopUI

GUID: {6DB3F999-745B-11D5-A688-0008C711C41A}

Load Behavior: 03

HKLM: 1

Location: C:\Program Files (x86)\Enterprise Vault\EVClient\Valkyrie.dll

Boot Time (Milliseconds): 124

0
Login to vote
Rob.Wilcox's picture

Okay, brief history lesson.

For a long time there have been two versions of the add-in. A DCOM client offering full functionality, and a HTTP client offering slightly reduced functionality. These are two separate MSIs.

These existed with Outlook 2003 and Outlook 2007.

With the advent of Outlook 2010, a huge amount of work was needed in order to support the methods available for Outlook. This came about with the EV 9.0.1 Outlook Add-in.

So, saying it worked with EV 8.0.4, but not 9.0.1 or higher is comparing apples with oranges, unfortunately. It would be worth trying Outlook 2003/2007 with the 9.0.2 or 9.0.3 HTTP addin, and, trying Outlook 2003/2007 and Outlook 2010 with the 10.0.1 client -- where the two clients were then merged.

0
Login to vote
Tennek's picture

In response to the first post.

Is this still an issue in Enterprise Vault Outlook addin 10.0.4, in combination with outlook 2013?

I have the same problem, but i can't find no other articles regarding this problem.

I have looked in the release notes of version 10.0.4 but couldn't find anything.

Thanks.

0
Login to vote