What do you do for desktop search in VDI and RDSH?

Here's a topic that I haven't thought about in a few years: What do you do for desktop search (or "Windows Search," as it's now called) in VDI and RDSH environments? Windows Search is a big part of the total desktop experience in today's world, allowing unified full-text search across Outlook contents and files on the desktop.

Here’s a topic that I haven’t thought about in a few years: What do you do for desktop search (or “Windows Search,” as it’s now called) in VDI and RDSH environments?

Windows Search is a big part of the total desktop experience in today’s world, allowing unified full-text search across Outlook contents and files on the desktop. Many (or most?) end users rely on Windows Search as a core part of their workflow. (Do you?  For me desktop search is how I do everything.)

We’ve always argued that in order for full remote published desktops (whether they’re VDI or RDSH) to be successful, you have to replace the users’ traditional desktops. (Otherwise you’re just supporting two desktops per user.) And in order to replace an existing desktop, the new desktop has to be able to do “everything” the old one did.

We tend to focus on all the big things like whether applications work or what the performance is like, but we often forget that when it comes to complete desktop replacement, it’s often the little things that come back to bite us. (How many of us have been chewed out by users because we took away their ability to change their desktop wallpaper?)

Windows Search / desktop search is one of those little things. Both Citrix and VMware recommend disabling it for VDI environments, though I can’t possibly see how users are okay with this? I initially started researching alternatives to Windows Search before taking a step back and looking at the performance impact of Windows Search itself. It turns out that it’s not so much that the constantly-running indexer is a problem, rather, it’s more that the Windows Search index is stored locally on a machine, so non-persistent desktops (VDI or RDSH) have to do a full rebuild every time a new VM is built for a user. For persistent desktops, the performance impact of the indexer running isn’t much, so it seems ok to leave Windows Search enabled.

So really we're just talking about non-persistent environments, which is good, but still not ideal.

So what are the options? Do you move the index to a persistent location? Do you go with a third-party desktop search product? (Both X1 Search 8 Virtual Edition and Axonic Lookeen 10 specifically market their Windows Search replacement products as being VDI and RDSH safe.)

Or maybe it is possible to just disable Windows Search altogether? All the user’s files should be on network shares, right? And the Exchange server can handle the mail search? Then again, with the push towards Dropbox-like enterprise file sync & share, maybe we need to figure out Windows Search again? (Or maybe we just use our file sync vendor’s search solution?)

So, in 2015 with Windows 7 in VDI environments, and with Server 2012 R2 RDSH, what do you do about full indexed desktop searching? How do you handle both persistent and non-persistent environments? Please share...

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

We primarily use NP desktops and we don't disable desktop search. Performance isn't the issue (Atlantis, etc.) anymore so we don't really need to worry about it.

Back in the days of spinning disk we disabled it and you know what? We never had a single complaint.

I don't think its that big of a deal anymore. - This is the first article I've seen in a long time addressing the topic.

Our users are pretty organised with their data (network shares/home drives/SharePoint, etc.) so maybe this could be the key factor?

We have just finished our final Office365 migration for mail and that seems to handle the search perfectly at the backend (non-cached).

For me enterprise file sync solutions need to work with our existing storage (shares) and data structure - not force users to change the way they work (if they are happy).


Whether this is important depends on if you are a piler or a filer. gigaom.com/.../open-thread-are-you-a-filer-or-a-piler For me, and apparently you Brian, we are pilers and rely on search, without outlook indexed search, my day would be crippled.  For this (personal) reason I'd never turn off windows search in a desktop.  Admittedly in my projects working for Atlantis I don't run into a situation where I'm I/O constrained.


Windows Search is a pre-requisite for Outlook 2013 on RDSSH/VDI

Windows Search is a useful client component for Exchange and SharePoint Content Indexes ...


this is very timely for me as this is on our radar again. We disable search here, but have been running an ilio pilot project with success so far, and one of the big reasons is that in that environment the persistent VDI sessions have search enabled. For us, the hit to performance fears across all our 1000+ persistent sessions have led us to keep it disabled, but with an expanded ilio pilot maybe we can give it back.... I know my user population in general would be very thankful.


I know in the past we have always disabled Windows desktop search in previous XA environments much to the disappointment and poor experience for our customers as it was a common feedback item for XA Hosted desktops.

In a current environment we have enabled the windows search function which is great for indexing user file systems but in a non persistent VDI\XA hosted world as far as I am aware if you do not enable your Exchange offline cache mode “OST” for Outlook the instant search function for outlook will not work as Windows desktop search will not index live exchange data, only the data that is in your OST will get indexed. To me the instant search function in Outlook is probably more critical to user experience than file system indexing.

So to deliver an efficient search function in Outlook via Windows desktop search we need to actually enable Offline cache mode and redirect a users OST file to a remote share which has huge implications “Read previous O365 on XA\XD Article on this site”. Then windows search indexes data from the users remote OST file to the local  XA\XD non persistent server\desktop to make their searches efficient in Outlook. Also I believe this happens each time a user logs in and off as the index is built dynamically.

I have to assume this could have an impact on scalability, design, IOPS and Network?


We enabled Windows Search, described here www.virtualdesktopblog.nl/.../search-function-in-remote-desktop-services. I defined via GPO, that no files were indexed. At least i wrote a little documentation for our customers how to configure the search parameters in the explorer (typ filter, subdirectories, search in non-indexed files). This is necessary, because a standard search in all file types in all subdirectories waste a lot of time.



Brian – very interesting article. You pointed out that Windows Search allows for "unified full-text search across Outlook contents and files on the desktop.”  What we are learning from customers and Microsoft themselves is that this is no longer true.  Just yesterday, we had a customer contact us and say that X1 should really market the single-pane-of-glass view across both email and files because Office 2013 removes the ability to search files and e-mails. This found this out the hard way when his IT staff upgraded him to Office 2013.  This is documented on the Microsoft Office site, as well:  technet.microsoft.com/.../cc178954.aspx

In Q4 of last year, X1 closed a 7-figure deal for the virtual search product.  We believe this deal really validates the use-case for our product and shows that business workers need an excellent search experience in the VDI environment.  As you mentioned, you use desktop search all the time.  So do the users as this organization.  For the customer, the value proposition with X1 is multifold:  X1 enables broader VDI deployment with an excellent end-user search experience without the need for Windows indexing; the customer is actually using X1 as a carrot to get more users on VDI (which is an IT strategic priority); and the users simple become more productive because of what the X1 interface allows them to do from a search and filtering perspective.  If anyone would like more info on this customer, a case study is available here:  www.x1.com/.../x1_case_study_large_fed_dod_agency.pdf


Tiers of service I think is the best way to address. I.E dedicated cheap but fast storage for those want/need it. The shared storage designs die unless you use some iOPS solutions that make life more complicated.