8:52 - Saturday, 19 April 2014

“this Network Location Can’t Be Included Because It Is Not Indexed” On Windows 2008R2 Remote Desktop Services Hosting

#Topics: this location cant be included because it cant be indexed,this network location cant be included because it is not indexed,2008 R2 “network location cant be included because it is not indexed”,this network location can\t be included becase it is not indexed,server location cant be indexed

I’m setting up a new terminal server for our users on Win2008R2 (I guess I should call it Remote Desktop Services now!)

When I try to change the location of “Documents” (by removing the default Documents library and adding a new one), to use the file server ie \fileserverusernameDocuments I get the message:

“This network location can’t be included because it is not indexed”

I certainly don’t want to make folders available offline, and in fact, I have set the GPO to prohibit offline folders on the terminal servers.

What is the best practice for document libraries on terminal server and network file shares?

Having the same issue, 2008 R2 RDS. Unable to add any network folders, regardless of the host platform or search index settings. Tried a folder on a 2003 server. The 2003 server has Search 4.0 loaded, and the target folder is indexed. I am able to add that folder to the library of several Windows 7 Professional workstations without issue, but RDS on 2008 R2 rejects the folder with the “not indexed” message.

Cannot add folders on another 2008 R2 server with Windows Search role installed. Even tried removing Windows Search and adding Indexing role instead, still no go. Also can’t add folders that are indexed on Windows 7 systems. Have also tried various sharing and discovery options on the 2008 server; none seem to change the behavior, yet I can add any of these folders to a Windows 7 workstation without problems.

The popular symbolic link workaround for Windows 7 does work, but I’ve found that many utilities and backup programs do not handle those links correctly, and users are confused by the misleading drive letter prefix on the file paths, so that workaround creates other issues.

Have concluded that this must either be a bug, or there is some undiscovered security setting that is preventing it from working.