I think you should check your crawl sources and see if you can narrow down whether it is a particular web app that is causing you the dramas. Access Denied may not be about user permissions, but things like IP restrictions on web applications being indexed. Log into a workstation using the crawler account and then hit each site listed in the crawl sources. Is this a single server farm or is there a dedicated crawl server? I have seen SSP web applications configured so that only loopback 127.0.0.1 can access them, and then of course when a indexing server tries to hit it, it complains of access denied.
Or remove your sources altogether and add them back one by one. Thats a wild guess, granted, but check the IIS logs for the web apps and check the subcodes for the 404 errors. That might give you some more hints.. Regards Paul p.s, this issue also below (from the deep recesses of my docco) springs to mind - not that it is this issue here, but it will explain how the indexer may be crawling the wrong server and therefore getting an access denied in my above scenario. 1.1 HOSTS file issue on MyServer Noted this regular occurring entry in the event log of MyServer Event Type: Error Event Source: Office SharePoint Server Event Category: Office Server Shared Services Event ID: 6482 Date: 6/5/2007 Time: 9:39:20 AM User: N/A Computer: MyServer Description: Application Server Administration job failed for service instance Microsoft.Office.Server.Search.Administration.SearchServiceInstance (8a566f1c-a539-4801-9c86-9daecab7e47a). Reason: Access to the path 'C:\WINDOWS\system32\drivers\etc\HOSTS' is denied. Technical Support Details: System.UnauthorizedAccessException: Access to the path 'C:\WINDOWS\system32\drivers\etc\HOSTS' is denied. at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath) at System.IO.FileInfo.Delete() at Microsoft.Search.Administration.Security.HOSTSFile.CleanupDedicatedGathering (Hashtable HOSTSFileMappings, StringBuilder HOSTSComments, IEnumerable obsoleteHosts, String dedicatedName, Boolean isDirty) at Microsoft.Search.Administration.Security.HOSTSFile.ConfigureDedicatedGatheri ng(SearchServiceInstance searchServiceInstance, SPServer dedicatedWebFrontEndServer, IList`1 previousWebApplicationHostNames) at Microsoft.Office.Server.Search.Administration.SearchServiceInstance.Synchron izeDefaultContentSource(IDictionary applications) at Microsoft.Office.Server.Search.Administration.SearchServiceInstance.Synchron ize() at Microsoft.Office.Server.Administration.ApplicationServerJob.ProvisionLocalSh aredServiceInstances(Boolean isAdministrationServiceJob) http://blogs.msdn.com/jjameson/archive/2007/05/05/the-case-of-the-disappeari ng-hosts-file.aspx The reason that SharePoint on MyServer needs access to the hosts file at all, the answer is due to one of the configuration settings that you can specify for Office SharePoint Server Search. In our case, we are using a farm configuration three front-end Web servers and one SSP server. In order to minimize the impact on users, we have the index server MyServer (i.e. the SSP) crawl itself. In Central Administration, if you specify a dedicated front-end for crawling content, then a timer job is created to add an entry to the hosts file to force the Web application (i.e. the host header) to resolve to the index server. Unfortunately, instead of "editing" the file in-place, the developer who implemented this feature decided it would be easier to just read the hosts file, add the appropriate entries, delete the original file, and then create a new file. If your SharePoint farm account (i.e. the one that the Windows SharePoint Servers Timer runs under Domain\farmaccount) is a member of the local Administrators group then there is no problem (which appears to be how this feature was tested). However, if you adhere to the "principle of least privilege" then there's definitely a problem. The workaround is to grant the following permissions for the WSS_ADMIN_WPG on the %SystemRoot%\System32\drivers\etc folder: Traverse Folder / Execute File List Folder / Read Data Read Attributes Read Extended Attributes Create Files / Write Data Read Permissions From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Trent Allday Sent: Wednesday, 23 July 2008 3:09 PM To: [email protected] Subject: RE: [OzMOSS] RE: MOSS Search I have tried to changing the search account to another user and now I am getting a different message. Access is denied. Check that the Default Content Access Account has access to this content, or add a crawl rule to crawl this content. (The item was deleted because it was either not found or the crawler was denied access to it.) >From what I can see though they have permission to everything. . SQL Server (owner to all db's) . Member of Adminstrators & domain admins . All ticked in "personalisation services permissions" . DCOM - SPSearch, account has full control on all three. Is there something im missing. At least now I am getting something in the log. Regards, Trent Allday TAD Solutions | P: (03) 9018 9040 | F: (03) 9769 7561 | M: 0418 745 253 | W: TadSolutions.com.au From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Culmsee Sent: Wednesday, 23 July 2008 9:18 AM To: [email protected] Subject: RE: [OzMOSS] RE: MOSS Search Make sure that your search account has full rights under "personalisation services permissions" in your shared service provider From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Trent Allday Sent: Tuesday, 22 July 2008 9:18 PM To: [email protected] Subject: RE: [OzMOSS] RE: MOSS Search I have looked at the index's are they all are as they are supposed to be. I checked each individually and ran the sql command and all come back as 1. I have created a new content source to see if that will have any effect, but at this stage it doesn't seem so. Can anyone offer any more advice. I am really stuck on this one. Cheers. Regards, Trent ------------------------------------------------------------------- OzMOSS.com - to unsubscribe from this list, send a message back to the list with 'unsubscribe' as the subject. Powered by mailenable.com ------------------------------------------------------------------- OzMOSS.com - to unsubscribe from this list, send a message back to the list with 'unsubscribe' as the subject. Powered by mailenable.com ------------------------------------------------------------------- OzMOSS.com - to unsubscribe from this list, send a message back to the list with 'unsubscribe' as the subject. Powered by mailenable.com
