I've noticed this and I'm wondering if a reboot would fix.
The WSS 3 search service is running according to the wss 3 administrator. It seemed to stop a few weeks ago. Since then, I've have had to stop and restart IIS once due to another task I was doing unrelated to WSS 3.
I also went into each area's search and checked it to still index even though it is granular. Do you think either of these could be preventing the search index service to actually index? Do you think a reboot would be a good first start?
> I've noticed this and I'm wondering if a reboot would fix.
> The WSS 3 search service is running according to the wss 3 administrator. > It seemed to stop a few weeks ago. Since then, I've have had to stop and > restart IIS once due to another task I was doing unrelated to WSS 3.
> I also went into each area's search and checked it to still index even > though it is granular. Do you think either of these could be preventing > the search index service to actually index? Do you think a reboot would > be a good first start?
Thanks for the reply. I needed to reboot to do an image of the server and install some updates so I just did a clean reboot and tried my search and everything is now indexed. Interesting. I believe me mucking with IIS (stopping and starting) may have had something to do with it. We'll see how it goes. Thanks.
I have had several problems with search that required a reboot.
Rick, in the event logs, were there any VSS errors along with any entries, even only warnings, about the gatherer service? When I get both together, I also notice that indexing stops working (I can't search new documents/list items) until I reboot. This seems to be triggered most often by the slightest loss of connection with the databases (which in my case are on a separate SQL 2005 server).
I also once got the errors together in the event logs when I had to change the index service's password. For a moment there was a loss of connection between sharepoint's index service and the databases it needed access to. After all should have been well is when the errors happened and then it required a reboot to make everything magically work. Iisreset /noforce did not help, it had to be a full bounce of the server. I would love to know exactly why that is.
> Thanks for the reply. I needed to reboot to do an image of the server and > install some updates so I just did a clean reboot and tried my search and > everything is now indexed. Interesting. I believe me mucking with IIS > (stopping and starting) may have had something to do with it. We'll see > how it goes. Thanks.
I'm having a similar problem, looks like somewhat related to install of Backup Exec agent.
WSS 3.0 installed on a single box using SQL Server 2005.
Search works, mssearch.exe running on box, Search service shows as started in Central Admin panel, and all content databases are pointing to the sharepoint server.
However, new content after 9/10/07 is not being returned using search, only content added up to 9/10/07.
>From checking the application event log, it appears that on 9/10/07
the index was paused (event id 2442) but not restarted (event id 2444). Previously, all 2442 events were always followed within a minute or two by a 2444 event.
Context: Application 'Search', Catalog 'index file on the search server Search'
2444 text: Type: Information Source: Windows SharePoint Services 3 Search Category: Gatherer
The gatherer index resumed.
Context: Application 'Search', Catalog 'index file on the search server Search'
I don't think this is coincidence, but I'm not sure how it might be connected: our network guy installed Symantec Backup Exec agent on the box a few days before this.
What steps might I take to un-pause the index and crawl all the new stuff added since 9/10 (over 5GB of docs)?
Also, the Central Administration content database is the only one using Windows authentication for database access. All others are using SQL authentication, user sa. Does this seem right?
Sharepoint pauses the search service (particularly indexing) if the server's resources can't handle it. Have you checked to see if the server is reaching its RAM, processing, or hard drive limits since backup exec was installed?
Also, it is possible that you can check the Services MMC and see if the service is off for some reason. If that doesn't work (it's on but no one's home, so to speak), then try starting indexing from the command line using STSADM -o spsearch -action fullcrawlstart. However, you might want to really look at the other parameters of the command, such as starting the search service from there (see: http://technet2.microsoft.com/windowsserver/WSS/en/library/700c3d60-f... for more details).
And, have you checked the diagnostic logs for sharepoint in the Hive 12 directory, under LOGS? I don't always find them helpful, but they could give you more of a hint of what is going on. -callahan
"Eric Riehl" <mangyvar...@gmail.com> wrote in message
> I'm having a similar problem, looks like somewhat related to install > of Backup Exec agent.
> WSS 3.0 installed on a single box using SQL Server 2005.
> Search works, mssearch.exe running on box, Search service shows as > started in Central Admin panel, and all content databases are pointing > to the sharepoint server.
> However, new content after 9/10/07 is not being returned using search, > only content added up to 9/10/07.
>>From checking the application event log, it appears that on 9/10/07 > the index was paused (event id 2442) but not restarted (event id > 2444). Previously, all 2442 events were always followed within a > minute or two by a 2444 event.
> Context: Application 'Search', Catalog 'index file on the search > server Search'
> 2444 text: > Type: Information > Source: Windows SharePoint Services 3 Search > Category: Gatherer
> The gatherer index resumed.
> Context: Application 'Search', Catalog 'index file on the search > server Search'
> I don't think this is coincidence, but I'm not sure how it might be > connected: our network guy installed Symantec Backup Exec agent on the > box a few days before this.
> What steps might I take to un-pause the index and crawl all the new > stuff added since 9/10 (over 5GB of docs)?
> Also, the Central Administration content database is the only one > using Windows authentication for database access. All others are using > SQL authentication, user sa. Does this seem right?
Sharepoint pauses the search service (particularly indexing) if the server's 17-Oct-07
Sharepoint pauses the search service (particularly indexing) if the server's resources can't handle it. Have you checked to see if the server is reaching its RAM, processing, or hard drive limits since backup exec was installed?
Also, it is possible that you can check the Services MMC and see if the service is off for some reason. If that doesn't work (it's on but no one's home, so to speak), then try starting indexing from the command line using STSADM -o spsearch -action fullcrawlstart. However, you might want to really look at the other parameters of the command, such as starting the search service from there (see: http://technet2.microsoft.com/windowsserver/WSS/en/library/700c3d60-f... for more details).
And, have you checked the diagnostic logs for sharepoint in the Hive 12 directory, under LOGS? I don't always find them helpful, but they could give you more of a hint of what is going on. -callahan
"Eric Riehl" <mangyvar...@gmail.com> wrote in message
WSS 3 Search service running but nothing indexing? I've noticed this and I'm wondering if a reboot would fix.
The WSS 3 search service is running according to the wss 3 administrator. It seemed to stop a few weeks ago. Since then, I've have had to stop and restart IIS once due to another task I was doing unrelated to WSS 3.
I also went into each area's search and checked it to still index even though it is granular. Do you think either of these could be preventing the search index service to actually index? Do you think a reboot would be a good first start?
Thanks. Rick
On Saturday, August 25, 2007 8:19 AM
Daniel Bugday wrote:
Hi Rick,i don't think a restart of the computer helps you but that depends on Hi Rick, i don't think a restart of the computer helps you but that depends on what you did earlier when you restarted IIS.
I think you should check to see wheather the service is started and configured correctly using central administration site.
Thanks for the reply. Thanks for the reply. I needed to reboot to do an image of the server and install some updates so I just did a clean reboot and tried my search and everything is now indexed. Interesting. I believe me mucking with IIS (stopping and starting) may have had something to do with it. We'll see how it goes. Thanks.
Rick
On Sunday, August 26, 2007 1:21 AM
callahan wrote:
I have had several problems with search that required a reboot. I have had several problems with search that required a reboot.
Rick, in the event logs, were there any VSS errors along with any entries, even only warnings, about the gatherer service? When I get both together, I also notice that indexing stops working (I can't search new documents/list items) until I reboot. This seems to be triggered most often by the slightest loss of connection with the databases (which in my case are on a separate SQL 2005 server).
I also once got the errors together in the event logs when I had to change the index service's password. For a moment there was a loss of connection between sharepoint's index service and the databases it needed access to. After all should have been well is when the errors happened and then it required a reboot to make everything magically work. Iisreset /noforce did not help, it had to be a full bounce of the server. I would love to know exactly why that is.
I'm having a similar problem, looks like somewhat related to installof Backup I'm having a similar problem, looks like somewhat related to install of Backup Exec agent.
WSS 3.0 installed on a single box using SQL Server 2005.
Search works, mssearch.exe running on box, Search service shows as started in Central Admin panel, and all content databases are pointing to the sharepoint server.
However, new content after 9/10/07 is not being returned using search, only content added up to 9/10/07.
the index was paused (event id 2442) but not restarted (event id 2444). Previously, all 2442 events were always followed within a minute or two by a 2444 event.
Context: Application 'Search', Catalog 'index file on the search server Search'
2444 text: Type: Information Source: Windows SharePoint Services 3 Search Category: Gatherer
The gatherer index resumed.
Context: Application 'Search', Catalog 'index file on the search server Search'
I don't think this is coincidence, but I'm not sure how it might be connected: our network guy installed Symantec Backup Exec agent on the box a few days before this.
What steps might I take to un-pause the index and crawl all the new stuff added since 9/10 (over 5GB of docs)?
Also, the Central Administration content database is the only one using Windows authentication for database access. All others are using SQL authentication, user sa. Does this seem right?
Thanks.
On Wednesday, October 17, 2007 7:04 PM
callahan wrote:
Sharepoint pauses the search service (particularly indexing) if the server's Sharepoint pauses the search service (particularly indexing) if the server's resources can't handle it. Have you checked to see if the server is reaching its RAM, processing, or hard drive limits since backup exec was installed?
Also, it is possible that you can check the Services MMC and see if the service is off for some reason. If that doesn't work (it's on but no one's home, so to speak), then try starting indexing from the command line using STSADM -o spsearch -action fullcrawlstart. However, you might want to really look at the other parameters of the command, such as starting the search service from there (see: http://technet2.microsoft.com/windowsserver/WSS/en/library/700c3d60-f... for more details).
And, have you checked the diagnostic logs for sharepoint in the Hive 12 directory, under LOGS? I don't always find them helpful, but they could give you more of a hint of what is going on. -callahan
"Eric Riehl" <mangyvar...@gmail.com> wrote in message
Its a issue with Symantec Backup utility and fixed in its next version 12.0 Following is the article http://seer.entsupport.symantec.com/docs/294181.htm which talks SharePoint 2007 or SharePoint Services 3.0 Content Index gets paused, fails to resume, and is not updated after a backup completes
callahan wrote:
Sharepoint pauses the search service (particularly indexing) if the server's 17-Oct-07
Sharepoint pauses the search service (particularly indexing) if the server's resources can't handle it. Have you checked to see if the server is reaching its RAM, processing, or hard drive limits since backup exec was installed?
Also, it is possible that you can check the Services MMC and see if the service is off for some reason. If that doesn't work (it's on but no one's home, so to speak), then try starting indexing from the command line using STSADM -o spsearch -action fullcrawlstart. However, you might want to really look at the other parameters of the command, such as starting the search service from there (see: http://technet2.microsoft.com/windowsserver/WSS/en/library/700c3d60-f... for more details).
And, have you checked the diagnostic logs for sharepoint in the Hive 12 directory, under LOGS? I don't always find them helpful, but they could give you more of a hint of what is going on. -callahan
"Eric Riehl" <mangyvar...@gmail.com> wrote in message
WSS 3 Search service running but nothing indexing? I've noticed this and I'm wondering if a reboot would fix.
The WSS 3 search service is running according to the wss 3 administrator. It seemed to stop a few weeks ago. Since then, I've have had to stop and restart IIS once due to another task I was doing unrelated to WSS 3.
I also went into each area's search and checked it to still index even though it is granular. Do you think either of these could be preventing the search index service to actually index? Do you think a reboot would be a good first start?
Thanks. Rick
On Saturday, August 25, 2007 8:19 AM
Daniel Bugday wrote:
Hi Rick,i don't think a restart of the computer helps you but that depends on Hi Rick, i don't think a restart of the computer helps you but that depends on what you did earlier when you restarted IIS.
I think you should check to see wheather the service is started and configured correctly using central administration site.
Thanks for the reply. Thanks for the reply. I needed to reboot to do an image of the server and install some updates so I just did a clean reboot and tried my search and everything is now indexed. Interesting. I believe me mucking with IIS (stopping and starting) may have had something to do with it. We'll see how it goes. Thanks.
Rick
On Sunday, August 26, 2007 1:21 AM
callahan wrote:
I have had several problems with search that required a reboot. I have had several problems with search that required a reboot.
Rick, in the event logs, were there any VSS errors along with any entries, even only warnings, about the gatherer service? When I get both together, I also notice that indexing stops working (I can't search new documents/list items) until I reboot. This seems to be triggered most often by the slightest loss of connection with the databases (which in my case are on a separate SQL 2005 server).
I also once got the errors together in the event logs when I had to change the index service's password. For a moment there was a loss of connection between sharepoint's index service and the databases it needed access to. After all should have been well is when the errors happened and then it required a reboot to make everything magically work. Iisreset /noforce did not help, it had to be a full bounce of the server. I would love to know exactly why that is.
I'm having a similar problem, looks like somewhat related to installof Backup I'm having a similar problem, looks like somewhat related to install of Backup Exec agent.
WSS 3.0 installed on a single box using SQL Server 2005.
Search works, mssearch.exe running on box, Search service shows as started in Central Admin panel, and all content databases are pointing to the sharepoint server.
However, new content after 9/10/07 is not being returned using search, only content added up to 9/10/07.
the index was paused (event id 2442) but not restarted (event id 2444). Previously, all 2442 events were always followed within a minute or two by a 2444 event.
Context: Application 'Search', Catalog 'index file on the search server Search'
2444 text: Type: Information Source: Windows SharePoint Services 3 Search Category: Gatherer
The gatherer index resumed.
Context: Application 'Search', Catalog 'index file on the search server Search'
I don't think this is coincidence, but I'm not sure how it might be connected: our network guy installed Symantec Backup Exec agent on the box a few days before this.
What steps might I take to un-pause the index and crawl all the new stuff added since 9/10 (over 5GB of docs)?
Also, the Central Administration content database is the only one using Windows authentication for database access. All others are using SQL authentication, user sa. Does this seem right?
Thanks.
On Wednesday, October 17, 2007 7:04 PM
callahan wrote:
Sharepoint pauses the search service (particularly indexing) if the server's Sharepoint pauses the search service (particularly indexing) if the server's resources can't handle it. Have you checked to see if the server is reaching its RAM, processing, or hard drive limits since backup exec was installed?
Also, it is possible that you can check the Services MMC and see if the service is off for some reason. If that doesn't work (it's on but no one's home, so to speak), then try starting indexing from the command line using STSADM -o spsearch -action fullcrawlstart. However, you might want to really look at the other parameters of the command, such as starting the search service from there (see: http://technet2.microsoft.com/windowsserver/WSS/en/library/700c3d60-f... for more details).
And, have you checked the diagnostic logs for sharepoint in the Hive 12 directory, under LOGS? I don't always find them helpful, but they could give you more of a hint of what is going on. -callahan
"Eric Riehl" <mangyvar...@gmail.com> wrote in message
|
