Outlook Addin Script error - Pagerequestmanager

actually there is a solution mentioned in the post. Have you tried it?

This is rather a workaround and not a real solution.
Also this needs to be explained further. 

Why is this happening?
Why is this not happening for all users but only a few? (within the same environment and across Versions). 
What is the impact when setting the registry key?

We had a ticket open for this back in april but the technician couldnt find a solution. It was only one user back then and it was possible to fix it with recreating the user Profile.

Since this is happening to more users now and across customers, we need an explanation for this. 

What do the users have in comon? maybe same browser? Different GPOs? Higher security options?

I think you will find a solution there. As far as I remember this problem isn't uncommon.

3 Customers: 
EV11 CH3
EV11 CH4
EV12

Windows 7, Windows 8 Windows 10

Different Client Versions (11 and 12)

IE11 and Office 2013 are the only mutuality.

Its not happening for all users but only for some, so I think i can rule out a general GPO setting. Also the error appears all out of a sudden and is gone when the user profil is recreated. They all have no problem opening shortcuts or using the Vault in a browser. Only the Search Vault Button in Outlook is broken. 

Agree my workaround is not a great solution but in my case it was a relatively small number of PCs, all of which have a 'special' support agreement (they wanted freedom to change IE settings).

The latest 12 Add-In made no difference.

In my case a user profile created when the PC had full corporate IE policies worked, it the PC was then moved to the 'no IE' policies group it continued to work. Only when a new profile was created did we get the error. This points to something in the HKCU registry (based on our GPO preferences, not policies, that are set and not backed out if the policy is removed)

I did log this with support (Case #21394597) and spent a lot of time troubleshooting, asking for information and escaltion, before relenting with the IE User Agent String.

Interstingly the client trace on 'bad' PCs records:

Launching EV web application in Outlook: http://evserver/EnterpriseVault/searcho2k.asp..........”

Working PCs record:

Launching EV web application in Outlook: http://evserver/EnterpriseVault/search/shell.aspx..........”

In my mind this points to the Add-In for Outlook not playing nice with IE11 in certain (unknown) circumstances.

I hope the information helps and if I get anything further I'll certainly share it.

Well, the workaround leads to more problems, so we had to remove the registry entry. The EV Problem immediately came back after this. 

Launching EV web application in Outlook: http://evserver/EnterpriseVault/searcho2k.asp..........”

I have checked a client log from a bad PC. It connects to https://evserver.companyweb.com/EnterpriseVault/search/shell.aspx so this is likely not the cause.

Not quite sure if a new ticket will help here. 

The registry "fix" also caused us issues, various sites (payroll site!) in our corporate compatibility list didn't work with a manual string set to "Version"="MSIE 11.0". Changing the value of "Version" to "MSIE 9.0" or others may help. Again still not a great solution but this is a relatively minor inconvenience for me.

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\User Agent]
@="Mozilla/5.0"
"Compatible"="compatible"
"Version"="MSIE 9.0"
"Platform"="Windows NT 6.1"

I do believe that it's a local IE configuration but I don't have the resource to dig through the many policies and settings.

I agree that Veritas should be able to provide more information on this issue. My previous case involved troubleshooting a specific case rather than the dev team reviewing. If I get a chance I will log another case referring to this thread.