I have a Windows Server 2008 R2 network share setup as a map drive in Win 7 x64. I want to search it via Windows 7 but I always get "no items match your search". It's as though it's not even attempting to search.
The File Server role with Windows Search Service is installed. The drive holding the network share is added to the indexing options on the server, and it indicates that indexing is complete.
From what I understand, the search query should be sent to the server (where the content is indexed), executed, and the results returned.
Failed solutions:
create a symbolic link to the UNC. I find that to be an extreme fix to what should be a simple problem.
enable "Always Available Offline" for the UNC. In a corporate setting it's not acceptable to duplicate all server content locally, nor is it feasible with many TB's of server storage.
install the "Windows Desktop Search: Add-in for Files on Microsoft Networks" http://www.microsoft.com/downloads/details.aspx?DisplayLang=en&FamilyID=f7e981d9-5a3b-4872-a07e-220761e27283 It allows a UNC path to be entered into the indexing options on the client and then the index built locally. However, the add-on is not for Windows 7 and is not supported for x64.
Update:
The setup includes two clients (Both fully updated Win7 x64), one file server, no domain. Just to make it easy (security isn't an issue in this case), anonymous access is used. I really doubt it's a permissions problem as I can access, modify, and create content on the mapped drive. I just can't search it.
Searching on the server ALWAYS works. The share in question has lot of content: 2.17TB with 274,633 Files, however, the folder(s) I wish to search has only 11,503 files (54.3GB)
Searching on one of the two clients works most of the time. It appears to be somewhat unreliable. Some days it works, others it does not. Searching on the second client has never worked.
The index has been rebuilt on the server as well as both clients.
Update 2:
- From the client, if I highlight all files in the share, go to properties, and let Win 7 count the files, then proceed to do a search after the counting is complete, it works. I'm not sure why that worked (something to do with rebuilding the index, properly this time?). I have a feeling that as the fileserver content changes it wont stay working. Any thoughts?
Given that you're trying to search a server and not your local system, it's probably not related to indexing as you shouldn't have all your clients indexing a file server.
What happens on the system that doesn't work if you login as a completely different user and try to search the sever? If you get results, try the steps laid out on this site
There's a registry key:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced
In this key there are two values (both hex dword)
Start_SearchFiles Start_SearchPrograms
Uninstalling Windows Search sets the value of both of these to zero, when they default to something else. However, reinstalling Windows Search does not restore them to their default setting like it probably should. By manually setting both of them to 1, it re-enabled the windows search function from the start menu. Somebody might want to notify one of the Microsoft software engineers that they should correct this issue so that reinstalling Windows Search properly configures this registry key back to its default setting, that way if anybody else does what I just did they'll avoid the same headache I went through. (I don't know how to contact them myself.)
Another thing to try would be to try the steps outlined on this site
Go to Home Group on the Windows 7 machine in control panel (I know, but bear with me...). Click on "change advanced sharing options" and in the public section, turn ON network discovery (or toggle it off, apply, on, apply, if already on). Re-index and reboot.
This is just a suggestion. Also, do you notice if the shared network drive appears with an X on it, even for a brief time period, when the machine is turned on? Win 7 has a habit of giving up indexing a network share if it is not available immediately on bootup, even if it subsequently becomes available, like in 30 seconds.
I suspect that this is something to do with the Home Group interaction, even if you have it turned off. I have spent literally days getting machines to be visible when, for no apparent reason, they are immediately available to other machines on the same OS. All these cases involve some type of Windows 7 "homegroup" issue.
Try going in from the client PC and right click on the mapped drive. Make sure that "allow files on this drive to have contents indexed..." is checked.
The other option that I would check would be: double click the mapped drive, select all folders and then right click on them, click advanced, then make sure that "folder is ready for archiving" is checked and "allow files in this folder to have contents indexed" is checked.
I think that these settings are usually set on a per pc basis, not taken from the server's settings.
I got this working at a site I look after, where they have a need to search in specific folders on the network for scanned documents, and to search text within PDF files. Works beautifully. From a collection of about 70,000 files, they can search almost instantly over the network for filenames and PDF documents containing specific text. Sorry, this doesn't address your exact problems, but hopefully you, or someone, benefits from my efforts. I emailed someone my results so as to tell them about it and to document it. Now shared here :)
Cheers.
||||>>
Two hours of ****** around and a further two hours of searching and I finally find this:
http://sourcedaddy.com/windows-7/understanding-remote-search.html
This is exactly what I'm looking for!! Why couldn't I find a single MS website telling me this **?!?
... users of Windows 7 can also search content stored in shared folders on the network. To do this, the following prerequisites are required: The remote computer must be running Windows 7, Windows Vista, Windows Server 2008, Windows Server 2008 R2, or Windows XP or have Windows Server 2003 with WDS 4.0 installed. The Windows Search (WSearch) service must be running on the remote computer (on Windows Server 2008, you can enable the search service by installing the File Services role and then enabling the Windows Search role service within that role). The shared directory on the remote computer must be included in the indexed scope on the remote computer. Note To provide an optimal experience for remote search, Microsoft recommends that computers running older installed versions of Windows with WDS 2.6.6 or WDS 3.01 be upgraded to WDS 4.0. For more information concerning support for WDS, see the section titled "Understanding the Windows Search Versions" earlier in this tutorial.
Remote search performed from the local computer uses the Windows Search service on the remote computer to perform the query against the index on the remote computer.
Sounds like a case of bad/incomplete/corrupt indexing.
Have you tried the exact same search directly on the server? If that doesn't work either, may I suggest forcing a rebuild of the index:
(Steps taken from MS knowledge base.)
If Microsoft's options don't work out, you could try these (untested) alternatives:
You need to include the mapped drive to indexing options in win 7.
Try creating a new Library and including the folder in the Library.
What all descriptions seem to miss, is that even on the client system, given it is running Windows Server 2008 and above (say as Remote Desktop Server), Windows Search will only work, if the RDS has the File-Services role installed and the Windows Search feature is enabled.
I tried this simple modification and worked like a charm. Got this from some genius named Thekid2point0 on another site:
"Not sure if this would help but I had a user with this same issue and after awhile changing all the settings I could find, I found one that did the trick. Under the Folder options go to the Search tab and under how to search check the "Don't use the index when searching in file folders for system files" check box close windows explorer and then reopen and try your search again. This worked for me hopefully this will help someone else out there."