Search service is offline, no search even on new SSP's
in [Portal Server]
|
Prev: Sharepoint Upload error
Next: Editing 'My Website'
From: Diego Moore on 15 Jan 2008 05:37 On Jan 14, 9:05 pm, "John Timney \(MVP\)" <xyz_j...(a)timney.eclipse.co.uk> wrote: > I have seen problems with farms where the index and query server file > locations do not match and reset doesn't help. If this was me, I would > remove the index and query servers and then recreate them after a full IIS > reset or reboot. Get your index working first with the alternate access > mappings in place before you re-add the query server. With luck it will > beging to propogate one the query server gets added into the farm. Well that's pretty much what I did above aside from the alternate access mapping (which I'm not sure I understand, can you elaborate?). There is only one Index Server on this farm so by stopping the search and rebooting I've effectively done that! BTW: The search on the other SSP is now back up and running so it was a case in impatience! In fact the new Index location now has a folder named d1885afb-4997-4b34-8f14-407ee97c3eb8 which I assume would be SSP, but nothing else.
From: Tony Testa on 16 Jan 2008 21:13 We had something similar happen where our search just dissappeared from our sites, and we got similiar error messages. Our problem was that the content DB user account set in the SSP didn't have permissions to the database on that SQL Server. Once we gave that user permissions, everything fired back up and started working. What account is your SSP set to connect to your DB as? Does that users have permissions on that DB? Thanks, Tony Testa http://www.tonytestasworld.com On Jan 15, 5:37 am, Diego Moore <diego.mo...(a)gmail.com> wrote: > On Jan 14, 9:05 pm, "John Timney \(MVP\)" > > <xyz_j...(a)timney.eclipse.co.uk> wrote: > > I have seen problems with farms where the index and query server file > > locations do not match and reset doesn't help. If this was me, I would > > remove the index and query servers and then recreate them after a full IIS > > reset or reboot. Get your index working first with the alternate access > > mappings in place before you re-add the query server. With luck it will > > beging to propogate one the query server gets added into the farm. > > Well that's pretty much what I did above aside from the alternate > access mapping (which I'm not sure I understand, can you elaborate?). > > There is only one Index Server on this farm so by stopping the search > and rebooting I've effectively done that! > > BTW: The search on the other SSP is now back up and running so it was > a case in impatience! In fact the new Index location now has a folder > named d1885afb-4997-4b34-8f14-407ee97c3eb8 which I assume would be > SSP, but nothing else.
From: Diego Moore on 17 Jan 2008 04:27 On Jan 17, 2:13 am, Tony Testa <awte...(a)gmail.com> wrote: > We had something similar happen where our search just dissappeared > from our sites, and we got similiar error messages. > > Our problem was that the content DB user account set in the SSP didn't > have permissions to the database on that SQL Server. Once we gave > that user permissions, everything fired back up and started working. > > What account is your SSP set to connect to your DB as? Does that > users have permissions on that DB? That's what MS asked yesterday! Did you also have a SQL crash that somehow reset the permissions? We checked the permissions for the SSP and search DB and this is what we have: IntranetSSP_DB SharedServices4_Search_DB SPSharedServicesPool db_owner db_owner SPSharedServicesAcct db_owner db_owner SPSearchAcct db_owner db_owner SPContentPool db_owner db_owner We compared them to the SSP that is working and they're identical. Does anyone know what the *exact* permission are meant to be? Thanks,
From: rt on 17 Jan 2008 07:15 Hi, I have exactly the same problem since yesterday, for no apparent reason. There is no help I can find over the internet. Everything (but few) that I find talks about access (DB, DCOM, Registry,..). I've checked every tip, but everything seams correct (like the DBO access from the SSP stated here). Does anyone have another clue? I would really appreciate some help. Thanks,
From: rt on 17 Jan 2008 12:42
I've just solved the problem with a new SSP. Deleted the old SSP and the associated DB's. The search is working again. Regards. |