Jump to content
Welcome to our new Citrix community!
  • 0

Long logon times and windows search errors

George Georgiadis


Hi to all. I have 2 questions.


We use XenDesktop 7.18, latest version of ELM and Windows 10 1803 image, provisioned using MCS.

We have created an image with several applications, in it, following the instructions from the App Layer 4.x site. We do not use elastic layers but we use Full User layers, without UPM (I do not think that this is needed)


The first one is regarding logon times. I have noticed that the first time logon time is 35 seconds and after that, all other logons, goes up to 1,5 minutes.

We have excluded all GPOs and Citrix policies from applying during the logon. Is there a specific reason for this? Is there a way to check any log files or take some troubleshooting steps in order to find which part of the logon consumes this time?


The second one is that we get some errors, in the application log, saying that the search catalog is corrupted and have to rebuild. While rebuilding, a lot of CPU is consumed during the first 4-5 minutes, making the user experience, to be kind, not acceptable. And we use SSD for storage.

What is the best way to handle the Windows search, using App Layering? I know that the User layer does not capture any indexes from the Windows Search service. So, indexing should be in place and not corrupted, before deploying the image and create the VDs. How are the indexes are constructed, having in mind that several indexes are created in the app layers? Are those indexes added all together? Should we stop the Windows search service in the optimization tool?

The demand is that the users should be able.


An idea that I just had is to power on the final image, logon as a local admin, and let the Windows search complete the indexes. Is this an acceptable way?



I know I placed a lot of questions, various paremeters and some of my thoughts. I hope someone to pass his knowledge.


Thanks in advance, 



Link to comment

8 answers to this question

Recommended Posts

  • 1

Hi George,

Unfortunately what you are seeing is the normal behavior for search indexing with the user layer.  Indexes will be recreated every logon for any defined indexes.  I do not think the CPM outlook container is compatible with the user layer I think you need to use one or the other but i have not tested that directly I have only heard about it second hand so you could try it and see if it will work.



  • Like 1
Link to comment
  • 0

Hi Rob. 


The plan is to use full user layers and be able to have windows search enabled and work for every user, for file systems and Outlook(cached profile) as well. We have non-persistent Windows 10 1803 base image with 8-10 applications (through application layering). What is the walkthrough to achieve this?

I believe that if we power on the published image and logon with the local admin, for a few minutes, and wait for the indexing to be completed, it will be ok with the indexes of the file system. 


But what about the indexes of the user's profile (Document, Desktop and all otther libraries) and Outlook search? The indexes are stored in the C:\ProgramData\Microsoft\Search folder and are quite big (just looked on my laptop and it says 15GB full size and 3,5GB size on disk). But what about the Outlook searches (indexing)? It uses the Windows Search mechanism, which means that it stores the indexes in the same location.

From what I have read, the Full User layer, does not capture this folder. So any indexes created after the creation and updating of the user's profile, all these new indexes will be lost on logoff. So, everytime the user logs in, the profile-Outlook indexes have to be created from scratch. 

Do I have this correct in my mind? If yes, how do we handle this problem?


One workaround (for the Outlook indexing) I found is this https://support.citrix.com/article/CTX235347

I haven't tested it yet because I would like to know if it works in combination with Full User layering and/if someone has implement it.....


Once again thanks in advance.



Link to comment
  • 0

Thanks Rob. We will measure how much time will take  the indexes for the outlook search, to be recreated,  and we will decide our next steps. 

The search error I mentioned is caused by the CPM portion of the VDA, because the SearchIndexer.exe version is not supported by the version of the VDA. So, I removed the CPM portion, by installing the VDA to a new platform layer. Additionally, I logged in to the published image as local admin,  enable the Windows Search service and let the system for a few minutes to complete the indexing of the file system. 

Link to comment
  • 0

I can confirm that using Full User layering, it does not capture the Search indexes (for the file system and the outlook). So, every time a user logs in, his desktop performance suffers, for some minutes, from rebuilding the indexes. As everyone can understand, a huge part of customers have moved on to the Office365 platform, which means that Cached profiles are used. Online profiles are not an option. Honestly, if I knew it before deciding which tool to use, I would prefer to choose another solution. Please consider the idea to capture the indexes, in the next releases App Layering. The competitors seems to have given some extra attention on this small, but very crucial function, of a virtual desktop. Mail is everything for the users. They even use it "like" a file server. And searching, without affecting the performance, is very important. 

I didn't have the time to test the concurrent use of UPM and FUL and it does not seem to me a very good idea to split the user's profile to multiple locations and assemble it through multiple tools.

Link to comment
  • 0

Hi Rob


We're also experiencing long logon times and haven't been able to pinpoint the reason. We don't believe it is Antivirus related as if we removed the layer containing AV there isn't a noticeable improvement.


Curiously we did disable Windows Search in both the OS and Platform layer but no matter what we do when the user logs on the final image the Windows Search service is running. We noticed a lot of reference to Windows Search in the ulayersvc.log file so assumed it was somehow required by App Layering and it was forcibly enabling and running the service.


You seem to be saying Windows Search can be disabled and enabling User Layers shouldn't enable it (if so how can we disable as it keeps coming back on)?


If Windows Search is enabled there is "always" a penalty at logon as the indexes are always rebuilt?


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Create New...