03-08-2012 02:35 PM
Ok, I am once again working on trying to get Mobile Search 10 to work (gave up last time). I have done a fresh install on Windows 2008 R2 SP1, Windows 2003 SP2...same result with both..."Access Denied". It appears that the application is not properly passing the impersonation settings to the backend Enterprise Vault server. My question is this...does ANYBODY have EV10 and EV Mobile Search 10 working? I have a case open, but I have a strong feeling there is a bug in it. If you have EV 10, but no mobile search, can you try installing it and see if you can get it working?...takes about 10 minutes in all if you have to install IIS too. I have been installing it with "Basic Authentication" (Blackberry mode during setup...you'll see what I mean).
Symantec Case # 416-559-498
03-08-2012 03:31 PM
03-08-2012 03:36 PM
Yes. The install is by the book and I have verified all settings tons of times. I simply want to know if anybody else has this working on EV 10.
03-08-2012 03:43 PM
03-08-2012 03:48 PM
No worries at all. When installing Mobile Search, it installs as a web application and sets everything properly anyways (<identity impersonate="true"/>). I have verified all settings through GUI as well as web.config...its all perfect. I can already see exactly what it is doing as it does log an error on the backend EV server, so I KNOW it is not properly passing the authenticated users credentials. Mobile Search always worked perfectly for me when on EV 9.0.x.
03-08-2012 04:26 PM
03-08-2012 04:31 PM
The machine account. By default, when you install mobile search, it sets the application pool identity to "Local System", and that account cannot request network resources. Its like it doesnt care what is set and is trying to use the "Network Service" account.
03-08-2012 05:14 PM
03-08-2012 05:33 PM
03-08-2012 05:46 PM
but thats what i'm trying to say, the application pool doesn't matter in terms of what NET Framework runs under, it will always run under the network service account, so for instance if you run the app pool under the domain admin account, and then remove the NETWORK SYSTEM from having rights to the Temporary ASP Net folders on NTFS, you would find the aspx pages would fail to compile etc
but anywho, will let you know at least if i can reproduce...last question :)
i should be able to repro just using IE right? or do i need to use a BB simulator?
03-08-2012 06:15 PM
03-09-2012 01:37 PM
OK so i got it all set up and its working fine on my machine.
So what i have is
AdExch.Enterprise.Vault (192.168.100.1)
- Running on Windows Server 2003 w/ IIS6
- Exchange Server 2003
- Has the OWA and MobileSearch app
- Has the EV10 API installed
- Uses HTTPS with a self signed cert through SelfSSL
ev10server (sqlev.enterprise.vault / 192.168.100.5)
- Running on Windows Server 2008 R2 x64
- Installed EV10 and all the hotfixes related to indexing
- Uses HTTPS with a self signed cert through SelfSSL
I created an SSL Certificate through SelfSSL and placed them in the trusted root authorities on both the EV Server and the Exchange Server and my client machine.
The issues i faced were
1. gave me a 404 2 1206 error in the IIS logs when trying to hit Search.aspx, this was due to an ISAPI filter not being recognised, so i just allowed it for the moment
2. After that it told me the NT AUTHORITY\NETWORK SERVICE didn't have access to the Temporary ASPNET folder, so i gave it the permissions
After that everything ran fine.
So just to come back to this, are you absolutely 100% sure that you have impersonation enabled in IIS?
If you open up your IIS Manager for 7, then expand out MachineName -> Sites -> Default Web Site
Then click "EnterpriseVault" and in the middle, under IIS, click Authentication
Is "ASP.NET Impersonation" set to Enabled or Disabled?
And is it also set that way on your /mobilesearch/ page?
03-09-2012 08:30 PM
03-09-2012 08:53 PM
03-11-2012 09:04 AM
It works for me as well. You are actually getting "Access Denied". Test user can access the archive from search.asp right? Any error in the event log?
03-12-2012 09:48 AM
"Temporary ASP.NET Files" (under .NET 2.0.50727) has the correct permissions...EVMobileSearchAppPool application pool is configured for .Net 2.0, Classic pipeline, LocalSystem Identity. The only difference I can see between my setup vs your's JW, is that my EV server is not configured for HTTPS, only HTTP.
CareFreeX...yes, there is one event logged on the EV server...same as it has always been since EV 10/Mobile Search 10. Also yes, the users have no problem using any other method to search their archives...only Mobile Search is an issue.
Log Name: Symantec Enterprise Vault
Source: Enterprise Vault
Date: 3/8/2012 4:49:30 PM
Event ID: 7263
Task Category: Index Server
Level: Warning
Keywords: Classic
User: N/A
Computer: EVSERVER.Company.com
Description:
Search request refused because the user does not have sufficient permissions to search any folder in the archive.
User: Domain\WEBSERVER$
Required Permissions: Read
Archive: Some Guy
Archive Id: 183CCEDECB2F48A468AF205D8DD4F682F1110000CompanyEV
JW...can you setup your lab environment so that the EV server uses HTTP instead of HTTPS and see if it still works?
03-26-2012 07:33 AM
I am trying to test this for you When running through the install it states "unable to detect an SSL Certificicate on the HTTPS binding of the default web site. Error 1.
I have not read the install instructiosn but it seems to me that SSL may be a pre-req for this. Because of that I would ask if you have tried with SSL?
03-26-2012 07:38 AM
You can only install with SSL, so yes...I have a third party cert installed. I have a feeling it is a problem with the EV server as I have built three Mobile Search servers with different OS' and they all do the same thing.
03-26-2012 02:06 PM
It's probably not the problem here but you may want to double check in IIS and the virtual directories->advanced settings->Physical Path Credentials that it's not some weird account set in that property.
Had one customer with that setting set on one of the EV servers (don't know why) which created some "funny" issues when everything was done using that account.
Rather than the account that tried to access the server.
03-26-2012 04:36 PM
Just double checked, all web applications are configured for pass-through authentication already.