Offline Vault Syncing hangs when using RPC over HTTP connections

[MWallen]

Hello All,

I have been working with Symantec support for a couple weeks now  on an issue that came up when I enabled RPC connections to one of  my customer sites.

They are running EV 2007  SP4.

All functions EV are working with RPC connection including adding and removing items from archives and search vault\archive explorer.

The only issue I am seeing is every account I have tested so far (after about a minute being connected via RPC) a second login prompt hits while Offline vault sync process starts.  After adding in the account information the sync window just hangs and never updates. 

When locally connected the sync process works fine.

in the client logs we found

Got NON success code from IIS '401'
sleeping for 60000 seconds

which we found a tech note specifying a work around

http://support.veritas.com/docs/308227

This doc states that IWA might need to be removed and re-established....Etc.  

Ran this process which did not resolve the issue.  I have just been escalated to the next Symantec support tier.

Any troubleshooting idea would be appreciated while I wait for a response from support.

Thanks.

[Paul_Grimshaw]

I have found your case and taken a quick look at it and can see a bit more information in there. What I can see is that your request is failing on the
CPVAEArchiveContent::GetArchiveContents function and essentially what this function does is acquire the contents of the archive from indexing via a call to EnterpriseVault/ArchiveExplorer.asp page.

I can also see that your John Doe test user is getting to the EV server and running the Treeview.xml which is part of the process but I see no request in the EV IIS log to archiveexplorer.asp at all.

This is not normal. When a HTTP request is normally made to a webserver, the webserver will reply with a 401 'authentication denied' error, but within that response it will include a list of the www-authenticate headers that the client CAN use to authenticate with. At this point the client submits another request to exactly the same URL, but also attempts to authenticate by using one of the methods specified by the webserver.
As you are not issuing a second request at this point, either the client is not issuing the second request as there are no authenticate headers in the HTTP response from the front-end exchange server, or the client is hanging for another reason (bad data, for instance).

There is a third condition that could be happening here - a webserver will only write a log entry once it has completed its response. In other words, if the response never finishes, there is no log entry.

I also see that ISA is involved and firstly I just would like to suggest a couple of things:-

1. Rule out our application being the problem by testing internally, but faking the external addresses using hosts files.
2. If everything works without ISA involved then we have an ISA issue. A similar issue has been seen previously and it was fixed by changing the authentication option is ISA to authenticate with AD. I believe that would be the Authentication Delegation Tab within the firewall policy setting but please do not quote me on that as I am no ISA expert - Legal Disclaimer!!!!! :)
3, Download a tool called fiddler and reproduce the problem. Your connection is HTTPS so you need to switch on Capturing and decryption od HTTPS traffic and this is somewhere in the fiddler options section.

[MWallen]

Thanks for the reply.  I have downloaded Fiddler and have started playing around with it.  I did send in a log late yesterday and support is reviewing it now.  

  The customers ISA admin is out of the office until next week, which is making it hard to identify how it is configured at this time(verifying it is correct). Next week I will try and get the admin and Symantec support on a con call to continue working on it.  I will try step 1 first thing on monday. 

I will give an update on Monday after further testing.

Thanks again for the repsonse.  I appreciate your help.

Michael

[MWallen]

Paul,

Thanks again for your assistance.

Above under Option 1 you mentioned that I can trick EV into thinking an internal connection is external via Host file entries.  Could you give me a little more information as to how to do this properly.   What entries must be in the  host file to make sure I am getting an accurate test?

Thanks

Michael

 

[Paul_Grimshaw]

whatever address you use as a connection in the host file point this to your CAS servers IP address so that it does not go through ISA

[DanIhrig]

Have you or anyone else resolved this issue? If so, what was the resolution?

[Paul_Grimshaw]

I cannot say what the answer was in this scenario but a high percentage of the time the issue with this type of problem is an ISA setting. A good test is to test by bypassing the ISA server and if it works fine then you know that it is not ev configuration but an ISA issue

[Mario_VU]

Michael or Danlhrig, Did any of you found a solution for this?
Whe have the same problem here and it is a ISA problem as internally it is working, so before starting to troubleshout this problem ourself I wounder if one of you got it solved.
Thanks in advance.
Mario

[Mario_VU]

Michael or Danlhrig, Did any of you found a solution for this?
Whe have the same problem here and it is a ISA problem as internally it is working, so before starting to troubleshout this problem ourself I wounder if one of you got it solved.
Thanks in advance.
Mario

[MichelZ]

Do you need any more info here?
Please mark a post as a solution if it fits your needs.

Cheers