We ran into this issue and it was fixed by simply recreating the SSP from scratch after patching up fully. Apparently some revisions of MOSS have a bug that can corrupt your SSP.
So: 1. delete SSP 2. fully patch up 3. recreate SSP and search indexes On Wed, Jul 23, 2008 at 6:03 PM, Paul Culmsee <[EMAIL PROTECTED]> wrote: > 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.ConfigureDedicatedGathering(SearchServiceInstance > searchServiceInstance, SPServer dedicatedWebFrontEndServer, IList`1 > previousWebApplicationHostNames) > > at > Microsoft.Office.Server.Search.Administration.SearchServiceInstance.SynchronizeDefaultContentSource(IDictionary > applications) > > at > Microsoft.Office.Server.Search.Administration.SearchServiceInstance.Synchronize() > > at > Microsoft.Office.Server.Administration.ApplicationServerJob.ProvisionLocalSharedServiceInstances(Boolean > isAdministrationServiceJob) > > > > http://blogs.msdn.com/jjameson/archive/2007/05/05/the-case-of-the-disappearing-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: listserver@ozMOSS.com > 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: listserver@ozMOSS.com > 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: listserver@ozMOSS.com > 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 ;3I'(��.�˛���m���ka��b�� �֦z����rKh����p��n�˛���m欶����r�����u��j)^���y�&
