Exchange 2003 OWA 403 Error when accessing Archive Explorer/Search

[wandarah]

Hi, 

EV 10.0.3 has been installed. At the moment, it is archiving from Exchange 2003. The OWA Extensions have been published. ISA 2006 rules have been published, and when clicking either Archive Explorer, or Search - an immediate 403 error is displayed. All other functionality works. 

All Exchange 2003 server IP's have been entered into ExchangeServers.txt (though as an aside, I have recreated the EVANON VD - and it no longer populates with the IP's, I have had to set it to 'Allow from any client' for now, advice here appreciated). 

It is a difficult environment with regard to change control, access to configuration etc - but from what I have seen, ISA appears to be configured correctly. When clicking Archive Explorer - the URL is correctly modified. i.e mail.xxx.com/enterprisevaultproxy

I have explored Symantec Connect,and various threads suggest removing. 'Require Channel SSL' from the Exchange VD on the Exchange servers, this is currently checked. Upon the IIS version on the Exchange Servers, I am assuming the 'Require SSL' check box on newer versions of IIS is the same option upon the EV servers, it is not checked upon any VD. I may be able to test the removal of such, but am wondering if any other potential fixes exist. 

Finally, logging into http://exchangeserver/exchange OWA interface allows me to click on either Archive Explorer, or Search - and no 403 error is displayed, however neither is an actual page displayed - just white space. 

Everything works from Outlook. 

Have had to now leave site, excuse brevity.Suspect may need to get the certificate?

[Arjun_Shelke]

Are you able to access AE and Search while logged onto Backend Server, ie. http://backendservername/exchange.

[Arjun_Shelke]

Troubleshooting EV OWA 2003 issue is tricky, you need check things at many places. So when you attempt to access AE or Search via http://exchangeserver/exchange and get blank page, what do you see in IIS logs on EV Server? If this URL is for FrontEnd server then you need to check all the hops, such as FE, BE and EV. To simplify this, you can try using backend server URL to understand whether communication between BE and EV is causing this issue. If using BE URL gives you same result then issue lies on BE or EV.

How is the desktop policy >> advanced >> OWA section has been configured?

[wandarah]

I see nothing of note in the IIS logs. Will check again to make sure I'm reading the right logs. 

No changes have been made to Desktop OWA Earlier than  2013 section. Did try playing with the Proxy URL by ensuring it had URL of OWA access point + /enterprisevault (and /enterprisevaultproxy, ahem) to no affect. 

[wandarah]

This is the URL it's going to [specific info redacted] externally:

https://mail.xxx.xx.xx/enterprisevaultproxy/archiveexplorerui.asp?OWA2003=1&OWA2003Url=https%3A%2F%2Fmail.xxx.co.nz%2FExchange%2Fxxxxx%40xxx.xx.xx%2F&mbx=xxxx@xxx.xx.xx&server=corsxc0005

This results in a 403. 

Internally it is http://servername/enterprisevaultproxy/archiveexplorerui.asp?OWA2003=1&OWA2003Url=https%3A%2F%2Fmail.xxx.co.nz%2FExchange%2Fxxxxx%40xxx.xx.xx%2F&mbx=xxxx@xxx.xx.xx&server=corsxc0005

This results in a blank page. 

Oddly, the IIS logs only contain one entry for the username in question, and that was sometime yesterday. I've turned on failed request linking, but that's yet to yeild any results. 

I feel like I'm missing something specific here. Probably to do with SSL/Certs maybe. 

[Arjun_Shelke]

Is this Frontend and backend setup? Did yu try accessing OWA using http://backendserver/exchange URL?

In this case, we first need to resolve the blank page issue. Once it works internally then we can troubleshoot external access issue.

Can you tell me following: Authentication of Virtual Directories on Exchange Server (such as Basic, IWA, Digest etc)

1. Exchange VD

2. EnterpriseVaultProxy

3. EnterpriseVaultExchange

4. EVOWA

Login to Backend Exchange 2003 Server using admin rights and try following:

1. Open command prompt

2. type proxycfg -d

3. On the same server, open IE , delete temp cookies and files and type http://backendexchangeserver/exchange in address bar.

4. Open Archive explorer and check the results.

[Arjun_Shelke]

Additionally, on EnterpriseVaultProxy virtual directory properties, check "Execute permissions" set to.

It should be set to "Scripts Only". You may need to check this on both FE and BE exchange servers.

[wandarah]

Think I've found the issue, after rechecking. 

The new ISA rule for Enterprise Vault OWA includes the /EnterpriseVaultProxy/* path, instead of it being added to the pre-existing OWA rule. 

They have a seperate rule for RPC over HTTPS that containst the /RPC/ path, so I don't believe I need to worry about that particulary. 

My second concern, is that they will move to Exchange 2010 and Outlook Anywhere, which again uses the same listener, locked down to 443. If I understand correctly, this step will require me moving EV to SSL and publishing the EV certificate on ISA. 

Again, the Exchange VD on the Backend servers are locked to 'Require SSL' which is why I don't believe it works internally. I don't need it to work internally though. 

Am working with Support to produce logs. 

[wandarah]

For the record in answer to authentication question above:

1. Basic + IWA (turns out I was lying about it being set to Require SSL, this only exists on the FE server)

2. Basic + IWA

3. Basic + IWA

4. Basic + IWA

I cannot run that command on this production server. 

[wandarah]

Right, so finally. Plan of attack is. 

1. Move the EnterpriseVaultProxy/* path to the correct ISA rule. 

2. Convince them to enable HTTP for AE and Search (and outlook anywhere) when they move to Exchange 2010 - and modify the ISA rule accordingly. 

3. Alternatively, set up SSL. 

Duh. 

[Arjun_Shelke]

Glad to know. I hope that resolves this issue

[wandarah]

Same. I am constantly forgetting out ISA rules should work. So, I have recorded this here so future generations have no need to feel as dopey as me. 

[wandarah]

Hi, 

I'm back. 

Extensions now working correctly internally. 

Can I just get confirmation of two things. It seems, as above, a single ISA rule was published in an attempt to combine the rules for OWA 2003, and OWA 2010. 

So to resolve:

We need to move the /EnterpriseProxy/ path to the existing OWA Rule for standard access (which points to the FE server). It is irrelevant if it is set to HTTPS or HTTP as the FE server proxies requests for Archive Explorer and Search to EV internally, and the connectivity between the two is not encrypted.

Secondly:

The new ISA rule which contains the /EnterpriseVault/ path is correct as it points to the internal name of an EVserver (by the way, does it matter if it is the A record, or the CNAME alias of the server?), though it is set to connect to the Published Web Server via SSL. EV is not set up for SSL (again, as above). However setting it to 'Redirect to HTTP' in the 'Bindings' tab, should successfully offload SSL and allow the connectivity between EV and ISA to be performed via HTTP. Is this correct?

Input appreciated. 

[Arjun_Shelke]

Yes thats correct. It does not really matter whether you use Host name or CNAME. It just needs to be resolved internally.

[wandarah]

Thanks. 

Are you saying it's all correct? :)

[Pradeep-Papnai]

Required configuration of EV for External OWA &  “RPC over http/https”
--------------
For Exchange 2010/2007, if we need Enterprise vault functionality from external by OWA or outlook Anywhere (RPC over http/https), Enterprise vault host record must be published. I would suggest to publish EV alias instead of machine host name. (alias can work fine in case of additional building block configuration http://www.symantec.com/docs/TECH38701)

Details for web app is present in "Symantec Enterprise Vault Outlook Web Access (OWA 2010 and earlier) Internal and External WebApp URLs" http://www.symantec.com/docs/TECH63250

If you have setup firewall other than ISA /TMG (Cisco Pix, Lynxes, watchguard,..etc). then you should have separate published host record for EV server.

Example:-

https://web.domain.com/owa                                  (External IP 200.100.1.1 )              https://CAS.domain.local/owa (internal IP 10.0.0.2)

https://EV.domain.com/enterprisevault          (External IP 200.100.1.1 )   http://EV.domain.local/enterprisevault (internal IP 10.0.0.3)

You can get the help of Network administrator to publish the host record and configure one to one mapping between external name to internal host name. You need to opened the same ports as you required for RPC over http/https for EV record.

When user click on Archive explorer & vault search, the request goes to EV publish name.

If ISA /TMG is in place for link translation, we can use existing published host record of exchange, that can work for EV as well as it does web proxing, Example:-

https://host.domain.com/owa                                  (External IP 200.100.1.1 )              https://CAS.domain.local/owa (internal IP 10.0.0.2)
https://host.domain.com/enterprisevault           (external IP 200.100.1.1)               http://EV.domain.local/enterprisevault (internal IP 10.0.0.3)

EV desktop policy settings for "RPC over http / https Outlook mode".
-----------------------------

Once you configure EV host record publishing, then the changes you need to make on EV server.
Open VAC \ Expand policy \ Exchange \ select appropriate desktop policy \  Right click select ‘properties’ \ Advance \ next to ‘List setting from’ select ‘outlook’ \ make change below settings.
RPC over http restriction. = None
RPC over http connection = use proxy
RPC over http proxy URL =  https://EV.domain.com/enterprisevault          

Where "https://EV.domain.com/enterprisevault"   is  External EV published Name  

Synchronize all user in EV server.

[wandarah]

Thanks for that, however we are using ISA - and just looking for confirmation that above approach is legit (I'm assuming it is). 

[Pradeep-Papnai]

Above approach works in most of the environment, I belive you already know the publish information for ISA.

http://support.veritas.com/docs/283170 (ISA 2004)

http://support.veritas.com/docs/305637 (ISA 2006)

[wandarah]

Yep. Cheers!