Sign in
 
HomeLibraryWikiLearnGalleryDownloadsSupportForumsBlogs
Resources for IT Professionals > Forums Home > Microsoft Enterprise Search Forums > SharePoint - Search (pre-SharePoint 2010) > Timer cannot Start Indexing (E_ACCESSDENIED)

Answered Timer cannot Start Indexing (E_ACCESSDENIED)

    •  
      Friday, February 08, 2008 7:59 AM
       
       
      Sign In to Vote
      0
      Sign In to Vote

      Hi,

       

      I have a fresh MOSS 2007 installation on a single server with all services running on that machine. The event logs look quite good. Allmost 100 % clean.

       

      However, there is a problem with the timer job starting indexing. Indexing itself (started manually) runs ok. A scheduled run gives an error:

       

      Event Type: Error
      Event Source: Windows SharePoint Services 3
      Event Category: Timer
      Event ID: 6398
      Date: 8/1/2008
      Time: 1:24:18 PM
      User: N/A
      Computer: MOSS
      Description:
      The Execute method of job definition Microsoft.Office.Server.Search.Administration.IndexingScheduleJobDefinition (ID cb05c3bd-69a5-49f5-bacf-ca33294bf324) threw an exception. More information is included below.

      Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))

       

      I read (here: http://www.codeprof.com/dev-archive/130/328-1209-1300885.shtm) that this problem might go away if you add Network Service to the Administrators group. But doing so seems to just workaround the core problem.

       

      So: Network Service is the account used by "Windows SharePoint Service Timer" service (OWSTIMER.EXE:NT Authority\Network Service). What access rights are need to be set where so Timer Service can start "Window SharePoint Services Search" (MSSEARCH.EXE:HOME\spCrawl) ?

       

      Rgrds and tia,

      Riven

       

    Answers

    • Sunday, February 10, 2008 9:56 PM
       
       Answered
      Sign In to Vote
      0
      Sign In to Vote

      My assumption was wrong: the issue is not related to a security patch. I did a clean install w/o patches with same result.

      It seems to be an error of the psconfig.exe.

       

      I don't know why setup configures NetworkService for the Windows SharePoint Services Timer ... but it needs to have the identity of the WSS Administration Service, which is "Local System" to work properly. BTW: It does also work if the NetworkService is added to the adminsitrators group.

       

      Or does it work for anyone running as NetworkService? (w/o adding NetworkService to administrators group)

       

      Merits go to Matthew McDermott, who posted this solution in another thread!

       

      Rgrds,

      Riven

       

    All Replies

    • Friday, February 08, 2008 11:40 AM
       
       
      Sign In to Vote
      0
      Sign In to Vote

      Hi Riven,

       

      Check the permissions for the directory where your index is stored. The location of the index file can be found in the SSP properties.

       

      By adding the Network Service account to the Administrators group you would probably be giving permission to this directory, though this isn't recommended for production environments.

       

      Cheers

       

      Toby

       
    • Friday, February 08, 2008 4:46 PM
       
       
      Sign In to Vote
      0
      Sign In to Vote

      Thanks for your advise.

      File system rights are good.

       

      I noticed this:

      If the Timer Service is run by spSharedAP (Application Pool Owner) the error goes away. However, the crawl is not started.

       

      There is another single error right after start up (translated): The SQL database 'SharePoint_Config_.....' on SQL instance MOSS\Office Servers was not found. ...

      The requested database 'SharePoint_Config_.....'  cannot be opened. DB Log on failed für NT Authority\NetworkService.

      This error also goes away. So the WSS Timer Service obviously wants to connect to the config database but fails.

       

      What I do not understand: Shouldn't the "Standard Installation" (for small sites including SQL Express) run "out of the box". Yet, it installes a lot of application and services with the NT Authority\NetworkService account, though it is NOT recommended and not running properly.

       

      Regards,

      Riven

       
    • Friday, February 08, 2008 6:43 PM
       
       
      Sign In to Vote
      0
      Sign In to Vote

       

      It is recommended that you install using a domain account that is a member of the local administrators group of the server.

       

      It sounds like a problem with your database permissions. Can you check which roles it has on the database?

       
    • Saturday, February 09, 2008 11:19 AM
       
       
      Sign In to Vote
      0
      Sign In to Vote

      Hi Toby,

       

      thanks for your support.

       

      I installed the MOSS 2007 package as the local Administrator. That should be okay, shouldn't it?

       

      I found information that a windows security update is probably the cause for the problems I see. An update (issued between june and november 2008) that tightens security might prevent the network service from "doing something". (maybe impersonating?) I got Windows Server 2003 R2 with all available patches applied.

       

      I will try to set up Microsoft Enterprise Studio 2005 on that machine to check db permissions and report back.

      If you have any further information please let me know.

       

      Thx

      Riven

       
    • Saturday, February 09, 2008 12:04 PM
       
       
      Sign In to Vote
      0
      Sign In to Vote

       

      Hi, the way I would normally install a single server instance of WSS 3.0 is to install SQL Server 2005 Express first as a seperate install and then installl WSS 3.0 in advanced mode. You then get to specify which account you want to use to connect to the database and which account to run all the services under.

       

      Would re-install be possible?

       
    • Saturday, February 09, 2008 12:45 PM
       
       
      Sign In to Vote
      0
      Sign In to Vote

       

      It is a single server installation of a complete Microsoft Office SharePoint Server 2007. I relied on the single-server installation routine. But a good idea to seperate that and do it as an advanced installation. As a last means I would even reinstall.

       

      In the meantime I installed SQL Mgmgt Sudio. The surprising result: "NetworkService" has the following db role memberships for 'SharePoint_Config_ef40c262-3162-48ba-87c9-ed425f5e6b75': db_owner, WSS_Content_Application_Pools. It has the server roles dbcreator and securityadmin.

       

      That is fine a.f.a.i.k. and not the cause for an access problem. Error (of course) still there: The SQL database ... on instance ... was not found. The requested database ..... cannot be opened. error logging on account "nt authority\NetworkService".

       

      There must be another problem and I got a feeling it is related to a security patch ... Something before really accessing the db.

       

      The SharePoint loggin gives very long debugging output. at its end it refers to the internal procedures

      • Microsoft.SharePoint.Administration.SPConfigurationDatabase.get_Farm()
      • Microsoft.SharePoint.Administration.SPFarm.FindLocal(SPFarm& farm, Boolean& isJoined)

      Anyone? :-)

       

      Rgds,

      Riven

       

       
    • Saturday, February 09, 2008 1:05 PM
       
       
      Sign In to Vote
      0
      Sign In to Vote

      Have a look at this link, this has helped me loads when i've had problems with connectivity in SQL Server 2005 Express

       

      http://blogs.msdn.com/sql_protocols/archive/2006/03/23/558651.aspx

       
    • Saturday, February 09, 2008 10:34 PM
       
       
      Sign In to Vote
      0
      Sign In to Vote

       

      I have double checked that network service *has* acces to the Config db. For SQL instance or databes. Rights for NetworkService are sufficient. MIght we be barking up the wrong tree?

       

      The web server extension logs say the Timer job procedure threw an exception and the stack trace contains:

       

      The Execute method of job definition Microsoft.Office.Server.Search.Administration.IndexingScheduleJobDefinition (ID 9eb62f64-e27f-488d-84aa-94adc8401941) threw an exception. More information is included below.  Access Denied (Exception HRESULT: 0x80070005 (E_ACCESSDENIED))

      Exception stack trace: Microsoft.Office.Server.Search.Administration.SearchApi.RunOnServer[T](CodeToRun`1 remoteCode, CodeToRun`1 localCode, Boolean useCurrentSecurityContext, Int32 versionIn).

      ...

      (Repeated every minute)

       

      exception in SearchUpgradeProvisioner Keyword Config System.InvalidOperationException: jobServerSearchServiceInstance is null     at

      Microsoft.Office.Server.Search.Administration.SearchUpgradeProvisioner..ctor(SearchServiceInstance searchServiceInstance)     at

      Microsoft.Office.Server.Search.Administration.OSSPrimaryGathererProject.ProvisionContentSources() 
      02/09/2008 22:54:52.01  mssearch.exe (0x0E58)                    0x0E80 Search Server Common           GatherSvc                      0 Medium   CGatherApplication::CGatherApplication::GetRole - What is the role of this server? - FileBig Smile:\office\source\search\search\gather\gthrsvc\gthrapp.cxx Line:730 
      02/09/2008 22:54:52.01  mssearch.exe (0x0E58)                    0x0E80 Search Server Common           GatherSvc                      0 Medium   CGatherApplication::CGatherApplication::GetRole - The role of this server is 3 - FileBig Smile:\office\source\search\search\gather\gthrsvc\gthrapp.cxx Line:752 
      02/09/2008 22:54:52.05  mssearch.exe (0x0E58)                    0x0E80 Search Server Common           GatherPI                       0 Monitorable CContentSourceCollection::ValidateTrigger in m_pScheduler -> Activate or NewWorkItem, Error is 0x80070005 - FileBig Smile:\office\source\search\search\gather\server\contentsource.cxx Line:1356 
      02/09/2008 22:54:52.05  mssearch.exe (0x0E58)                    0x0E80 Search Server Common           Exceptions                     0 Monitorable <Exception><HR>0x80070005</HR><eip>600DCA47</eip><module>d:\office\source\search\search\gather\server\contentsource.cxx</module><line>1357</line></Exception> 
      If you had the source code this might help.

       

      I have a feeling, that the problem is connected to the internal steps *before* it tries to connect to the db. I will have a look at COM+ configs or the registry tree. Any suggestions?

       

      Regards,

      Myst

       
    • Sunday, February 10, 2008 9:56 PM
       
       Answered
      Sign In to Vote
      0
      Sign In to Vote

      My assumption was wrong: the issue is not related to a security patch. I did a clean install w/o patches with same result.

      It seems to be an error of the psconfig.exe.

       

      I don't know why setup configures NetworkService for the Windows SharePoint Services Timer ... but it needs to have the identity of the WSS Administration Service, which is "Local System" to work properly. BTW: It does also work if the NetworkService is added to the adminsitrators group.

       

      Or does it work for anyone running as NetworkService? (w/o adding NetworkService to administrators group)

       

      Merits go to Matthew McDermott, who posted this solution in another thread!

       

      Rgrds,

      Riven