Video Screencast Help

Is a Proxy required to retrieve the original item in OWA?

Created: 24 Apr 2014 • Updated: 25 Apr 2014 | 16 comments
JA3's picture
This issue has been solved. See solution.

I have Enterprise Vault 10.0.4 and Exchange 2010 SP3 RU2.  Exchange 2010 is 4 servers, running CAS/HT/mailbox roles, all members of the DAG, and all members of the CAS Array.  Two of the servers host mailbox databases.  I have a Brocade ADX load balancer in front of the other two servers to host the Outlook connection and OWA.  The Brocade ADX does not do any proxying, so owa.company.com/enterprisevault cannot be redirected to the Enterprise Vault server.

I have set EV to retrieve the original item in all cases - Outlook and OWA.  It works perfectly in Outlook, but the shortcut is retrieved when archived items are opened in OWA.  I have gone through a couple support cases and my anonymous configuration is correct, Exchange Servers text file is fine, and no issues found in a Dtrace, yet they can't tell me why this isn't working.

I need a definitive answer to this question: Is a proxy solution, like TMG, required to get this to work?  Or is there a way to make it work without that?

When I had Exchange 2007, I used TMG to load balance my CAS servers, and directed owa.company.com/enterprisevault to the EV server and it worked fine.

More info:
When the shortcut is opened, there is the gray bar with "The archived item is currently unavailable. If you choose reply or forward, only the content shown below will be included. Click here to preview the original item" and then the blue bar with "This message has been archived.  View the original item."
Clicking either opens another version of the shortcut, with the six icons in the upper left corner (Search, Archive Explorer, Download, Restore, Settings, Help)
If I connect directly to one of the mailbox servers (https://serverfqdn/owa) the behavior is the same as connecting through the load balancer DNS alias.

Thanks for any help in answering this!

Operating Systems:

Comments 16 CommentsJump to latest comment

JesusWept3's picture

OK so you definitely don't need a proxy, especially since you said behavior is the same when you go directly to the server.

Honestly would need to see a log generated on the EV Server specified in the web.config

Andrew G.'s picture

It certainly looks like a problem with the CAS server talking to the EV server, as the extensions seem to be loading ok.

Check the IIS log on the EV server to make sure that the request to restore the item to the mailbox (to "restore02k.asp") is making it as far as that, and what the error is. If the entry is for "EnterpriseVault" rather than "EVAnon", then you need to check the anon configuration (again) and ensure the mailbox is synchronised. You will need to close the browser and restart the OWA session to pick up any changes to the settings.

If there's no corresponding entry at all, then that indicates a problem with the CAS not being able to resolve the EV alias or trying to use a proxy to get there. You can check your proxy settings using proxycfg. You can see what URL the extensions are trying to use if you turn on logging via web.config and open the log file. Look for "owawebappurl".

If that doesn't get you anywhere please post the log file.

JA3's picture

I am attaching a partial log.  the only thing I've done in the file is change my company's name to "MyCompany"

It looks to my untrained eye that the impersonation may not be using the account I expected it to.  the portion that looks relevant to me (with the date/time/code part removed)
[ImpersonationManager::StartImpersonation] Entry: Current user: NT AUTHORITY\SYSTEM
[ImpersonationManager::StartImpersonation] Entry: Impersonation Level: None
[ImpersonationManager::StartImpersonation] Impersonating logged on user
[ImpersonationManager::StartImpersonation] Exit: Current user: MyCompany-NA\JLChamberlain
[ImpersonationManager::StartImpersonation] Exit: Impersonation Level: Impersonation
[EVContext::Initialise] EVContext intialised at 4/25/2014 10:50:27 AM
[EVContext::Initialise] Hidden settings loaded at 4/25/2014 10:50:27 AM
[EVContext::IsValidBrowser] Returning: True
[RequestProcessor::PostProcessRequest] Checking for reply/forward to EV item
[ImpersonationManager:StopImpersonation] Stopped impersonation

I expected the impersonation account to be 'MyCompany-NA\sysna-evanon'

I have the full log file if that is needed - just let me know

Also, I am not familiar with proxycfg, unless this is the older version of Netsh.  What would I look for using this?  My Exchange servers routing is good for public and replication NICS.  My EVault server has only one NIC.

Thanks for the help - i really do appreciate it!

AttachmentSize
partial EV log.txt 8.45 KB
JA3's picture

I realized the owawebappurl line wasn't in the partial file.  Here is the segment on the hidden message that includes that.  it does show as OWAWebAppURL=http://KVSServer1.NA.MyCompany.com/EVAnon

 

AttachmentSize
hidden message info.txt 13.74 KB
Andrew G.'s picture

Unfortunately your partial log file is too late in the process...it contains the redirection from the "unavailable" page to the EV view of the archived item, and not the part that is failing.

Can you search in the log file for "restoreo2k.asp"? That is the interesting part. Can you sanitize and post the log entries between the "#######" delimiters including the request to restoreo2k.asp?

In particular, it's the response to that request that is interesting.

Did you find an entry in the IIS log file on the EV server?

Andrew G.'s picture

proxycfg has indeed been replaced by netsh winhttp. Obviously been a while since I had to play with these settings. Mind you, they were used more by the OWA 2003 extensions than the more modern ones.

Try:

netsh winhttp show proxy

to see if it is using a proxy server. If so, you probably need to add the EV alias used in the owa url, e.g. KVSServer1.NA.MyCompany.com to the bypass list using netsh winhttp set proxy

JA3's picture

Attaching two files - the full evault log and a pratial IIS log.  the full evault log has spaces inserted as i did different things: Log on <space> open an archived item <space> click the link on the blue bar to open the original <space> click on the gray link that says item not available

I will look at the proxy settings and post those

AttachmentSize
partial IIS log.txt 2.42 KB
Full Log file.txt 305.35 KB
JA3's picture

Here is the proxy result on the Enterprise Vault server.

netsh>winhttp
netsh winhttp>show proxy

Current WinHTTP proxy settings:

    Direct access (no proxy server).

netsh winhttp>

 

Andrew G.'s picture

The OWA log file shows this:

4/25/2014 10:50:59 AM [7172,33] [RestoreRequest::Send] Exception sending request to restore item: System.Net.WebException: The remote server returned an error: (403) Forbidden.

and the IIS log file has this entry:

2014-04-25 14:50:59 2620:0:10:706c:94f:8ee1:1d02:f328 GET /EVAnon/restoreo2k.asp vaultid=1D7782EC828850C499F41346198B963EC1110000KVSSite.na.MyCompany.com&savesetid=201310252662845~201307122104040000~Z~00F2FA71E18463ED8F67309859A61541&mbx=Joshua.Chamberlain@MyCompany.COM&server=ADSiteEX3&restorelocation=3&foldername=Deleted%20Items 80 - 2620:0:10:70b8:e9fc:f5e8:c544:3380 - 403 6 5 202

and the important point is the "403 6" which translates as IP Address forbidden. That line also shows that it is actually using IP v6 addresses rather than IP v4.

I'm not sure that the ExchangeServers.txt file allows you to specify IPv6 addresses, so your best bet is to turn off IP v6 on the EV server and force it to IP v4.

Andrew G.'s picture

Actually, try adding the IP v6 address to the file and re-running owausr.wsf first.

I thought it hadn't worked on my system, but it must have been some other gremlin and it looks like it has now added the address in.

SOLUTION
JA3's picture

I have added the IPv6 addresses and reran owausr.wsf.  I restarted the EV Admin service (and all the others) and synchronized the jlchamberlain account.  I still get the same result.  I am enabling logging again to see if the error is still the same.  I may try disabling IPv6 if it is.  Will let you know...

JA3's picture

Progress?  It looks like it times out now instead of failing, amybe due to Shopping service issues?  Look starting on line 2441 of New Log attached here.

AttachmentSize
New Log File after IPv6 Change.txt 246.95 KB
Andrew G.'s picture

Check the shopping location and make sure the anon account has permissions on it.

JA3's picture

the evanon account has no explicit rights, but the local users group has read & execute plus special rights of Create files / write data and Create folders / append data.  Since the evanon is a domain account this should apply to it.  Should it have explicit rights other than this?

JA3's picture

I think this is a two-step solution.
Found this article:

http://www.symantec.com/business/support/index?page=content&id=TECH71115&actp=search&viewlocale=en_US&searchid=1398456157224

And I assigned Authenticated Users Write (and the three default read) permissions on the root Shopping folder.  I thne deleted my shopping subfolder and now this all works properly for me again!

I will mark the IPv6 post as the answer because that got me past that hurdle to where the Shopping error occurred.

One last question - I have only 78 subfolders - I am inclined to just delete them all and let them get recreated.  Any possible downside to doing this?

Thanks so much for your help!

Andrew G.'s picture

If they're empty then it shouldn't be an issue, but if they have files in then you would be deleting users baskets, and they might not be too happy.

Glad you've got things working!