asked on

Is there a reason to have Windows Desktop Search running on a server?

Good morning, experts,

We have an abundance of error ID 3013 in our application log. They seem to be related to WDS. Is there a good reason to keep it running on the server? A couple of supervisors ago maintained that we had to have it running for some other application on the server to run correctly, but since this is supposed to be a SharePoint-only server, I want to turn it off to clean up the event log. A couple of examples are included below.

What are the implications of turning it off?

Do any of you have any suggestions or insights?

Thanks for your help and time,
Nancy

______________________________________

Event Type:      Error
Event Source:      Windows Search Service
Event Category:      Gatherer
Event ID:      3013
Date:            6/1/2011
Time:            8:31:32 AM
User:            N/A
Computer:      GFD-SHARESRV-02
Description:
The entry <C:\WINDOWS\DEBUG\USERMODE\CHKACC.BAK> in the hash map cannot be updated.

Context: Windows Application, SystemIndex Catalog

Details:       Unspecified error, (0x80004005)

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

________________________________________________

Event Type:      Error
Event Source:      Windows Search Service
Event Category:      Gatherer
Event ID:      3013
Date:            6/1/2011
Time:            5:24:59 AM
User:            N/A
Computer:      GFD-SHARESRV-02
Description:
The entry <C:\CONFIG.MSI\50FFF.RBF> in the hash map cannot be updated.

Context: Windows Application, SystemIndex Catalog

Details:       Unspecified error, (0x80004005)

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
____________________________________________________________

pcgremlin

Hello .. We've found that it's better to shut this service down on our servers. It's unnecessary.

ASKER CERTIFIED SOLUTION

wparrott

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

psv1973

Often you will want to quickly find a file on your computer or local network. SharePoint itself doesn't need it, but if you want to find file quickly while logged into the server themn you might want to use it. Having set that I can't imagine that that would be more important than running the server itself. So I would switch it off ( do you have a similar testing environment?)

nsyyoung

ASKER

@psv1973 - Yes, we have dev and test environments; I'm doing that now. The errors are mostly looking for a file that's there, but clearly isn't available while it's being sought. I'll try the group policy to exclude that folder and see if they go away.

@William - I don't think any other applications are running on this machine. That was two supervisors and at least one set of hardware ago.

I'll keep you posted.
N.

ee_reach

This was a cpu hog at inconvenient times so I shut it off on my servers.

You can search for the occasional file by name using Powershell. Here is an example of how to script the query:
http://technet.microsoft.com/en-us/library/ee176988.aspx

To search inside files themselves, I use Windows Grep:
http://www.wingrep.com/
I find you can get very fast responses from Windows Grep. You can get a full-featured trial verison for free. If you want to remove the nag screen, a sngle user license is $30.

Disclaimer: I am in no way connected with Microsoft, their Powershell tool, or Windows Grep.

nsyyoung

ASKER

@pcgremlin: I feel the same way, but since we don't know why it's installed, we've decided to continue to follow colloquial wisdom and continue to ignore the errors, rather than shut it down. The abundance of red 3013 errors happens when the server reboots, and there are only 2-5 daily when that's not the case. The service is not running on the dev or test environments - well, it is on the test environment now, for, um, testing, and we found that we can reset the index if it's a problem, so that's what we'll do if it becomes a problem. It's not typically a resource hog that we've found so far, but then I might be looking at the wrong times.

We'll be sure to exclude WDS from our 2010 install when we get that far.

@ee_reach: thanks for the tips. I'll explore them.

Thanks all,
Nancy