EV OWA External URL

[ChayDouglas]

Hi, Sorry if this is a double post, my original one has not shown up in the Forum. I am trying to configure EV for OWA at a customer. They have EV 10.0.2 on a Windows 2008 R2 Server. They have 2 CAS Servers and 2 separate Mailbox Role Servers. They use owa.company.com for both internal and external owa access. The Exchange Environment is 2010. I have installed the extensions on the 2 CAS Servers, ran the owauser.wsf cscript on Enterprise Vault, restarted services and sync'd mailboxes. When logging into OWA whilst on the network, I can retrieve archived items and can see the EV toolbar etc. However, when I log on externally I cannot see the toolbar or retrieve items. I have followed the following technote and believe the configuration is the "Different IP Address" example on page 16. http://www.symantec.com/docs/TECH63250 If I have chosen the right way to configure it, what would be the IP address(es) that go in the EnterpriseVault_ExternalIPAddresses web.config setting? I'm aware that the Enterprise Vault server needs to be published for Search / Archive Explorer but I'm not too worried about this stage at the moment. Thank you for any help Cheers CD

[ChayDouglas]

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

[GabeV]

Hello,

When you connect externally, are you using CAS to CAS connection or are you connecting to the same CAS server you connect internally?

[ChayDouglas]

Same CAS Server internally and Externally

[ChayDouglas]

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

[Andrew_G_]

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?

[ChayDouglas]

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

[A_J1]

If we have a Firewall ISA or TMG then the IP addresses of the firewall servers could be added to this list.

Note that when using a CAS proxy, the originator is the CAS server acting as proxy, not the firewall. In this case, it may be better to specify the host names to trigger the use of the external URL.

do we have a CAS Array ???

But as A_S_G said it would be go to check the IIS log to find from where the requested is Originated..

[Pradeep-Papnai]

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.

[GabeV]

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.

[ev_crazy]

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

[Andrew_G_]

Looking at those log files, I can see some different scenarios going on:

First, the working scenarios:

•   Both using OWA premium client

•   Client IP: 194.74.188.194
•   Browser Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729)

•  Client IP: 193.109.254.21
•  Browser: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)

Then, the ones where the extensions have been disabled:

• Using OWA basic client
• Client IP: 86.20.138.255
• Browser Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko

In the non-working cases, the extensions are disabled because the browser is not identified as Internet Explorer, as per the compatilbility charts.

So, please either test externally using Internet Explorer and the premium client, or if you are already doing so, amend your firewall rules to allow the User-Agent HTTP header through.

Note that if the user opts to use the OWA light client on the log in page using a browser which supports the OWA premium client, then OWA itself changes the User-Agent header and the Enterprise Vault extensions will be disabled. There is a setting to enable the extensions in this case, however if the browser really isn't Internet Explorer, then the behaviour of the extensions is undefined and may well break the mail experience and/or enterprise vault experience. Since you have non-ie browsers in use (by the look of those User-Agent strings in your log files), I would suggest that you don't enable this setting. I mention it here so that you make sure you test using Internet Explorer and the Premium Client.

Now, unless you want to use different URLs to access Enterprise Vault Search/Archive Explorer for internal and external users, forget about setting those IP addresses.

Hope that helps!

[ChayDouglas]

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

[Andrew_G_ · Accepted solution]

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?

[ChayDouglas]

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.

[GabeV]

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)

[ChayDouglas]

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