Video Screencast Help

Open a message in Enterprise Vault Search without having to choose "open" or "save"

Created: 13 May 2014 • Updated: 03 Nov 2014 | 21 comments
This issue has been solved. See solution.

We just upgraded a number of users to Enterprise Vault Search (EVS) in EV 11, and noticed that when a user double-clicks on a message resturned by the search, that a dialog then comes up saying "View Downloads - WIndows Internet Explorer" and then the user has to choose top either open or save the .msg file.  Is there a way around this so that we can just have the message open in Outlook when double-clicked?

Operating Systems:

Comments 21 CommentsJump to latest comment

AndrewB's picture

i havent seen this behavior. i wonder if it's an OS or IE setting. have you tried with another browser or another machine?

Andy Becker | Authorized Symantec Consultant | Trace3 | Symantec National Partner |

Stormonts's picture

Happens on multiple machines all with IE 10.  This is when you search from within Outlook, so I don't know how to make Outlook use a different browser to perform the search.

Mahesh Lokhande's picture

When Enterprise Vault Search is opened within Outlook(I think this is applicable for combination of Outlook 2010 and 2013 and IE 9 and IE 10), this particular dialog comes in while downloading any item. This is a browser behavior. By default it Outlook uses IE as default browser and it can't be overriden. As a workaround, you can click on gear icon on top right, and click on 'Open in New window' option which will open EVS in standalone browser window, then you won't see this dialog.

AndrewB's picture

if it's a browser behavior then why does it make a difference whether IE is opened within outlook or standalone?

Andy Becker | Authorized Symantec Consultant | Trace3 | Symantec National Partner |

SimonMCH's picture

Hi all - did anyone find a work-around for this? We've just installed EV11 and I'm seeing the same problem, the right-click Open in New Windows is not ideal as it should open in the Outlook Client automatically?

Will a fix / resolution be made for this Symantec?



Patti Rodgers's picture

You're looking at these search results via Outlook but what you're really seeing is Outlook integrating with your browser (I'll use IE just for simplicity's sake), and you're not "opening" an email like you do when you pull it direct from the Exchange edb; you're downloading a .msg file. So the OS and the browser are treating the request just like any other request to download a file from a site.  How this behaves is going to depend on IE settings, which vary a bit from version to version (with lots of new lockdowns in IE9), and to a lesser extent the OS security settings may be in play; there might also be some security-related GPO's being pushed down to the workstation, and/or a full-on desktop security software in the mix too.

Given all these variables and the huge risk in getting your security set too low, I wouldn't be overly optimistic that EV "fixes" it, because EV is not the one controlling the behavior and it's a lot of behaviors in play.  I'd recommend putting it into the Ideas section of this site if it's important to you, where EV Product Managers can have a look and evaluate.

That said-- a quick google search turns up this discussion on Microsoft's forums (the first page has more questions than answers but there are a few potential solutions for IE9 in the later pages):

This article discusses how to make that prompt reappar if it's disappeared so logic would dictate you can work in reverse to remove it:

You may want to talk to your corp security folks first to see if suppressing the Download dialog would even be allowed, then start with your version of IE, and your desktop OS, to see what methods Microsoft has to change this behavior. It may be trial-and-error especially when there are GPO in the mix.  

Personally I do not prefer to suppress this dialog at all, given the many different risks are associated with seamless download-and-open activities. I would rather accept that they must do one click now and then, than expose them to the risk of unknowingly opening malicious files, although there are probably features in our security products that let you manage this more granularly than the browser settings do.

EVAdmin_CCC's picture

I disagree with Symantecs Response to this topic.  This is not an Internet Explorer issue in the sense that security is the problem.  This was not an issue with the 'Classic' archive search embedded window we were using with previous versions.  I was just able to verify after rmoving a lab setup from EV 10 to EV 11 and was able to still use the classic search function and open evault messages without the prompt.  Once I migrated my policies to the new Entprise Vault Search capabilities ala EV11 the embedded search window then started to present me with the 'Download' by default option upon click selecting an found item.  Obviously this is an issue with how the search browser site is crafted and my guess is that it has to do with the heavy .Net functionality that was brought to the table with the new Search functions.  If we did setups in the past and used the 'Add EV server URL to Intranet Site' policies we were guaranteed of our security while still allowing the heavily website derived functionality of Enterprise Vault work seamlessly with Outlook clients..  If Symantec wants to keep us using a Web stie based product then the ownus should be on them to make sure that they are properly devloping it to work without having us to come up with work arounds to keep the functionality our users were use to while driving the EV product forward with new features.

O.Schmidt's picture


are there any news or solutions about this problem?
I think, that is a disadvantage to the old version (EV 10).

dihrig's picture

Nobody I've seen that is using EV11 is happy with the "download manager" dialog. They want seamless access to the item from the search page. I couldn't get any of the IE 'fixes' to bypass these to work yet. So I'll be interested if anyone has found a solution for this. Thanks.

JesusWept3's picture

OK so here is the deal.
If you do not have the EV Client installed on and you open an item in classic Archive Explorer you WILL see the file open/save dialog.

However, if you DO have the client, it opens up straight off, so why is this?
The reason is that when you open up an item, it actually connects to the EV Client and tells it to get the item from there.

So if we look do a quick Fiddler trace, both EV11 and EV10 call download.asp
They both use the same headers, though they use similar Query Parameters, but this does not affect the open/save dialog.

But then if we look at a Procmon trace, you actually see Internet Explorer calling Shell32.dll to connect to Valkyrie.dll and IT tells it to download the item.

EV10 download-2.png

So above, you can see Internet Explorer calling Valkyrie.dll and it opens the item.
You will also see in the client log the following

[9628][L]: ~CDownloadSTA::RequestCallback
[9628][L]: ~CShortcutItem::RequestCallback: 0x0
[9628][L]: ~CShortcutItem::Display: 0x0
[9628][L]: ~CDesktop::OpenItem: 0x0
[9628][L]: CShortcutItem::get_SavesetURL
[9628][L]: ~CShortcutItem::get_SavesetURL
[9688][M]: Downloading: http://evServer/enterprisevault//download.asp?VaultID=1C5E4B920122E294F90482454A5B61EF81110000evsite&SaveSetID=201409181055756~201409181553310000~Z~A0DFDEA50C75E034CE106D65019568F1&FormatType=Unicode&Client=EV10.0.4.1333-Outlook15&Format=MSG&AttachmentID=0
[9688][L]: CDownloadSTA::DoDownload: 0x0
[9688][L]: DesktopTls::TlsData::FindDownloadBytes
[9688][L]: ~DesktopTls::TlsData::FindDownloadBytes
[9688][L]: DesktopTls::TlsData::PushDownloadBytes
[9688][L]: ~DesktopTls::TlsData::PushDownloadBytes
[9688][L]: CDownloadBytes::Begin
[9688][L]: CDownloadBytesImpl::Begin
[9688][M]: CThreadManager::Add thread THID=4952

and if we look at the fiddler trace, we'll actually see that it is Outlook.exe calling it to be downloaded NOT internet explorer.


But if we call it in Enterprise Vault 11 it actually calls from Internet Explorer or Chrome.

So why does it do this?
The answer would pretty much be that its for cross-browser compatibility, because Chrome, Safari, Firefox etc can't do the shell execution that Internet Explorer allows, platforms such as Linux, OSX, mobile browsers can't do this either

So what you get in Cross browser compatibility, you give up in slight convenience.
With chrome you can set it to always open messages of this type after their first prompt, but again, this is the same behavior in EV10 and below already if you do not have the client. 

But here is a workaround that works for me

1. Open Regedit
2. Browse to HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\Shell\AttachmentExecute
3. You should see a registry key like '{0002DF01-0000-0000-C000-000000000046}'
4. Under the crate a REG_BINARY  named 'Outlook.File.msg.15' , do not give it a value
5. Attempt to open the item again, it should now open without prompting

Note if you have Outlook 2013 then it will be msg.15 , if its 2010 then msg.14 etc etc

Hopefully i've explained this well enough and the work around works

JesusWept3's picture

ok so if you go to HKEY_CLASSES_ROOT and scroll down to Outlook.File
Do you see one for Outlook.File.msg.12 ??

Outlook 2007 should be Outlook.File.msg.12
Outlook 2010 should be Outlook.File.msg.14
Outlook 2013 should be Outlook.File.msg.15


That is the name you should be putting in to the AttachmentExecute path


WiTSend's picture

This workaround is not particularily useful with 40,000 clients, not all on AD connected machines, thus we do not have complete coverage for GPO.  Also, having to modify the registry on 40K user machines is not the best of solutions even if feasible.

I belive it is incumbent on Symantec to resolve this issue from a back-end perspective with how the data is served.

JesusWept3's picture

Well the fact is its just not going to happen, that is expected browser behavior, people wanted compatibility for something other than Windows + Internet Explorer, and the fact is the only way to do that was to pull some of the existing functionality, because again, Chrome cannot do the same execution that Internet Explorer can, neither can mac distros etc

SimonMCH's picture

Hi All - tried for Outlook 2010 - this did not work either unfortunately - still getting the pop-up for saving / open.

Good try though!




JesusWept3's picture

Can you open a command prompt and type the following for us, and let us know what it says
"assoc .msg"


Stormonts's picture

Jesuswept3, at least for us we are using Enterprise Vault Search so there is no "classic archive explorer" which I believe is what you posted the fix for.

JesusWept3's picture

No, i posted it for the new version of Search/Archive Explorer

The "Classic" version didn't need a fix because again, when you double click an item IF the client is installed, it made a call that connected to Valkyrie.dll and had the client download the item, NOT have internet explorer download it.

The "New" version in EV11 does not have the same hook because of cross browser compatibility.
So the fix/workaround that was posted was an Internet Explorer registry setting that automatically opens certain file types instead of prompting for Save/Download

So if you had Windows without the client installed and using EV10, you would be prompted for the item to be downloaded. If you have Windows with the client installed and using EV10 and Internet Explorer, you would not get prompted for the item to be downloaded.

If you were to use EV11 with or without the client you will be prompted, thats per Internet Explorer security, so you add the registry and it opens automatically.

dihrig's picture

The AttachmentExecute reg key method was one I tried before posting and it didn't make any difference for me either. Outlook 2013 and Windows 7 SP1, IE9. The association is correct, but opening items in new EV Search page still pops up download manager...

JesusWept3's picture

The workaround is described here on an MSKB article:

So there could be some other GPO or security setting that could be stopping it i suppose.

In my environment I use Outlook 2013 + Windows 7 SP1 x86 + Internet Explorer 11
I also had this same workaround working on Outlook 2010 + Windows 7 SP1 x64 + IE10

The only thing I could really suggest is contacting your symantec rep and asking for an enhancement request to have it work the way that it used to, but you know how enhancements go.

You could also try contacting Microsoft to see why it still requests a Download even though the ExecuteAttachment reg_binary have all bee added correctly