11-21-2013 03:31 AM
Solved! Go to Solution.
11-25-2013 04:27 AM
I suspect the premium client would have the same issue. As you've discovered internally, the extensions will work in both premium and light clients on Internet Explorer. The issue is that the browser cannot be identified as Internet Explorer.
This User-Agent header is why the extensions aren't working:
Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko
You need to work out why it isn't coming through as Internet Explorer, and you can clearly see the difference in the log files you sent through.
Check if the browser is set to use a different header, or if the firewall is set to change it as it passes through. You can use something like Fiddler to see what it is as it leaves the client and work out if it's on the client or later down the line.
How are they enforcing the light client externally?
11-21-2013 04:49 AM
How do I determine the IP address of the firewall / proxy ?
If I add this, do you think this is the correct configuration for the environment?
I failed to mention, I added the IPs of the CAS Servers and Mailbox Role servers to "Exchange Servers.txt" before running the owauser.wsf
Is there anything I'm missing?
Cheers
CD
11-21-2013 05:58 AM
Hello,
When you connect externally, are you using CAS to CAS connection or are you connecting to the same CAS server you connect internally?
11-21-2013 06:02 AM
Same CAS Server internally and Externally
11-21-2013 06:06 AM
Thanks for replying.
I'm trying to find out if they are using a Load Balancer to determine which CAS Server the connection is to, or if they are Active/Passive CAS Servers.
Would the configuration be different in these 2 cases?
Cheers
CD
11-21-2013 09:56 AM
The easiest way to determine the correct IP address to use is to look in the IIS log file on the CAS and see where the CAS thinks the connection is coming from. All external connections *should* be coming through the same firewall/proxy and so you should see the same client IP address for those connections in the log file.
If you use that IP address in the setting, then any connection coming through that firewall/proxy will be determined as external, and you can configure a different url for external access to EV.
HOWEVER, your problem is that the EV functionality isn't working inside OWA, and the external URL configuration isn't relevant to that. Remember that in the OWA 2010 premium client, there is no EV toolbar, the archive/restore functionality is via right click, and may not be available if you click on a conversation rather than individual item.
Do you see the "Archived item" banner in the preview of shortcuts?
Have you turned on logging via the web.config file and taken a look at the file produced?
11-21-2013 01:47 PM
Hi A_S_G,
EV works in OWA internally fine, just not externally. So I thought it was the external IP that was the issue?
I do see the "item as been archived" when opening shortcuts off the network, but opens fine when connected to the network.
Haven't tried logging yet, I just got confused with the configuration, and needed it clearing up.
Thanks for your help, will try the IIS logs to find the IP and see if that resolves the issue.
Cheers
CD
11-21-2013 08:13 PM
11-21-2013 09:24 PM
For archive/retrieval, EV does not require to published & also you should be able see EV toolbar/options even if users accessing OWA from external, publishing EV require only for AE/search. If you cannot retrieve emails from external but same happens from internal via OWA then there is something (firewall) stopping between CAS & external client machine for EV verbs or forms to function correctly , If firewall is Juniper then take a look at tech note http://www.symantec.com/docs/TECH53286 You can take fiddler trace of internal & external OWA and compare on what communication is not passing externally.
11-22-2013 06:17 AM
Hello Chay,
Enable OWA logging and open OWA internally and externally. Then, post the two log files so we can take a look. Based on your description, it sounds that an external component is causing this behavior. I was thinking that maybe it was something related to the external URL/IP and how the Exchange CAS was sending the requests to the EV server. If you enable the EV OWA logging, we can see those requests. Go to IIS console and select OWA virtual directory. Click on Application settings on the right pane. Then, add the following key on the bottom section:
Key: EnterpriseVault_LogEnabled
Value: true
If the key is already there, just updated the value. Also, take note of the EnterpriseVault_LogFolder value which is the folder where the log files will be stored. You don't need to restart IIS after that, Open IS, clear the cache, cookies. etc and recreate the issue, like I mentioned, internally and externally.
11-22-2013 09:32 AM
Let me start by saying I am not an expert, at all. That said, we had a similar problem for a long time. For us the problem turned out being our two CAS servers were attempting to connect to the IIS on the Enterprise Vault server but were failing. Looking in the IIS logs (I think) it showed the connections comming from an IPV6 address not an IPV4. The addresses were valid for our CAS servers but not what we entered into the owauser.wsf file (we entered IPV4 numbers). To further complicate matters we entered the IPV6 address into the owauser.wsf file but it failed to modify the web.config. We manually modified the web.config then it worked. I pasted the portion of the web.config we modified. Where you see xxx is where we manually inserted the IPV6 addresses.
</system.web>
<system.webServer>
<security>
<ipSecurity>
<add ipAddress="xxx" allowed="true" />
<add ipAddress="xxx" allowed="true" />
</ipSecurity>
</security>
</system.webServer>
</configuration>
Crazy
11-25-2013 02:47 AM
Looking at those log files, I can see some different scenarios going on:
11-25-2013 03:08 AM
Hi A_S_G,
All browsers involved were Internet Explorer.
The customer is enforced to use the light client externally.
I can use the light and premium client when I'm on the network and both settings return Enterprise Vault archived items.
Do you think the light client functionality is the problem?
Cheers
Chay
11-25-2013 04:27 AM
I suspect the premium client would have the same issue. As you've discovered internally, the extensions will work in both premium and light clients on Internet Explorer. The issue is that the browser cannot be identified as Internet Explorer.
This User-Agent header is why the extensions aren't working:
Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko
You need to work out why it isn't coming through as Internet Explorer, and you can clearly see the difference in the log files you sent through.
Check if the browser is set to use a different header, or if the firewall is set to change it as it passes through. You can use something like Fiddler to see what it is as it leaves the client and work out if it's on the client or later down the line.
How are they enforcing the light client externally?
11-25-2013 04:58 AM
Hi A_S_G,
YOU WERE RIGHT!
However, it looks like the problem is IE11 set the User-Agent header to pretend to be Firefox...
I can access archived items using IE 8 and 9 and I'm guessing 10 will be fine as well.
This is slightly annoying, but I'm glad the issue is solved.
Internet Explorer 11 does not seem compatible.
11-25-2013 06:13 AM
Hi ChayD,
Internet Explorer 11 is not supported yet with Enterprise Vault. According with the compatibility guide, IE 11 is not listed in the guide:
Enterprise Vault Compatibility List
http://www.symantec.com/docs/TECH38537 (Page 55)
11-26-2013 02:43 AM
Hi Guys,
Thanks for all the advice. Still can't seem to find the correct IP Address.
I have turned on logging and called the same item from both inside and outside the network.
Please see attached.
Cheers
Chay