See this article:
http://seer.entsupport.symantec.com/docs/295039.htm 
probably you will have to add the servername to the intranet zone.

Thanks for the reply.  Unforntunately, all of the necessary names have been added already.  This has been working without issue for quite awhile and just started having this problem recently.

I'm having a similar issue. For me, it always works if you put your AD username and password in...

we spent a lot of time on it and it all came down to kerberos and constrained delegation. i recommend looking into it.

im gonna guess its C:\Program Files\Enterprise Vault\ doesn't have authenticated users allowed to that directory, at least for JVals issue

another thing i've seen is that a customer will be prompted for credentials and not notice that it says EVSERVER\username where it should be DOMAIN\username. they just go ahead and type in their password and then throw their hands up when it doesnt work. it's a difficult one to troubleshoot without actually seeing it happen on the workstation.

AndrewB - OK, I'll check the SPN's for the EV server/service account, thanks for the suggestion.  Doesn't that usually throw an event log error though?  Thought I would've seen something?

JesusWept - Can you give a little more detail?  Do you mean that filepath on every individual user's workstation?

Thanks!
JV

Results from SPN List:

SMTPSVC/server.domain.com
SMTPSVC/server
WSMAN/server
WSMAN/server.domain.com
TERMSRV/server.domain.com
TERMSRV/server
MSSQLSvc/server.domain.com:SQLInstance
MSSQLSvc/server.domain.com:49182
RestrictedKrbHost/server.domain.com
RestrictedKrbHost/server
HOST/server
HOST/server.domain.com

Results from duplicate SPN search:

MSSQLSvc/server.domain.com:SQLInstance is registered on these accounts:
CN=Server,CN=Computers,DC=corp,DC=domain,DC=com
CN=Enterprise Vault,OU=EVault Accounts, OU=System,OU=Users,DC=corp,DC=domain,DC=com

Anything look incorrect here?

Thanks!

Another interesting development.  There are some users who this only happens when attempting to open an archived message with an attachement.  Plus, double-clicking to open does not work, but restoring using the 'Restore from vault' button DOES work.

can you run setspn -L evserver and paste the results here please? here's an example of what it should look like. note that the physical server name is EVSERVER and the dns alias is vault1.

C:\>setspn -l EVSERVER
Registered ServicePrincipalNames for CN=EVSERVER,OU=Servers,DC=company,DC=com:
        http/vault1.company.com
        http/vault1
        host/vault1.company.com
        host/vault1
        TERMSRV/EVSERVER.company.com
        TERMSRV/EVSERVER
        HOST/EVSERVER
        HOST/EVSERVER.company.com

Registered ServicePrincipalNames for CN=LMIEVAULT01,CN=Computers,DC=corp,DC=medicineforthedefense,DC=com:
        SMTPSVC/lmievault01.corp.medicineforthedefense.com
        SMTPSVC/LMIEVAULT01
        WSMAN/lmievault01
        WSMAN/lmievault01.corp.medicineforthedefense.com
        TERMSRV/lmievault01.corp.medicineforthedefense.com
        TERMSRV/LMIEVAULT01
        MSSQLSvc/lmievault01.corp.medicineforthedefense.com:EVSQL
        MSSQLSvc/lmievault01.corp.medicineforthedefense.com:49182
        RestrictedKrbHost/LMIEVAULT01.corp.medicineforthedefense.com
        RestrictedKrbHost/LMIEVAULT01
        HOST/LMIEVAULT01
        HOST/lmievault01.corp.medicineforthedefense.com

Should there be an SPN for every EVault alias/dns entry, and/or an SPN for every value listed in the Desktop Policy --> 'Add server to Intranet Zone'  field?

you need http and host SPNs on your ev server for its corresponding alias

Gotcha, definitely missing those.  Will add those and see where I stand.  Thanks!

JV

Should this take effect immediately?

i presume after AD replication. i don't recall a reboot or anything.

Excellent, thank you!

when i said file path i meant on the server that you're accessing, so C:\Program Files\Enterprise Vault\ <--- authenticated users needs permission to that directory and the \webapp directory on the server

Still getting Kerberos login failures on the EV server from some users trying to open archived items.  Wouldn't the changes have taken effect by now?

OK so things you should run down are

1. Are you absolutely sure authenticated users has access to the EV installation directory? (not just webapp but the whole shebang)
2. Are you sure that DisableStrictNameChecking and DisableLoopBackCheck are set properly on the server?
3. In the IIS logs do you see what kind of 401/402/403 error you are getting when trying to access it?
4. i take it you get the same results when you go to ArchiveExplorerUI.asp or Search.asp?

You may want to run Fiddler2 and reproduce the behavior or run Procmon on the EV server and have it filtered against the EV directory

or you can do the shotgun method of reinstalling IIS and then run webapp.vbs in the EV install directory

AndrewB - The amount of kerberos audit failures is about the same.  I can reproduce them at will by having one of the users attempt to open an archived email.  Appears to be substantially more prevalent when attempting to open an archived item with an attachment, usually 2+MB.

JW2 -
1. Yes
2. Yes
3. There isn't anything in the IIS logs related to the user attempting to access an archived item

This issue has resolved and is not longer occuring.  The only thing that I changed was to add missing SPN's for all of the DNS aliases that exist for the EV site/server.  So best guess is that this resolved it.  Thanks for everyone's help!

JV