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

Elastic Layers causing outlook / windows search re-index at every login

Sergio Masone1709161115



We are using App Layering in our environment, with MCS, leveraging fslogix as the profile mgmt solution to redirect the outlook cache and search index. all our VDAs are single session windows 10 VDA's. We recently started deploying a few applications using elastic layers, and noticed every time an elastic layer is assigned, on every login, the outlook index needs to be rebuilt. this only happens when an elastic layer is presented, doesnt seem to matter what layer. when no elastic layers present, outlook search index roaming is working properly and doesnt re-index at every login, once elastic assigned, it is forced to re-index everything which isnt ideal..
Anyone else experience this? and what was done to bypass this.
I already have a ticket opened with Citrix support on this.

Link to comment

5 answers to this question

Recommended Posts

  • 0
16 minutes ago, Rob Zylowski1709158051 said:

Ill add to my list to do a little testing in my lab and see if i get the same results.  I am wondering f its some interaction between both products.

Hi Rob,

User Layers is set to None and "Elastic Layering" is set to Application Layering. when i run the elastic fit analysis it always has a warning about the layer containing windows search data, i'm not sure if its normal but it seems to show this message no matter the layer i create. the elastic fit message is:

The layer contains Windows search service data. Search will not work reliably if the layer is assigned elastically.
Is there anything special i need to do on apps I plan to assign elastically in relation to windows search when installing on the packaging machine to ignore the windows search data?

Link to comment
  • 0

more troubleshooting revealed that at every log on, under indexing option, the outlook app would disapear when an EL was attached. and the reg entries under \HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows Search\ProcessedSearchRoots\0004 the mapi16:/{SID} would go missing, so something in the process was interfering with this. I informed citrix of this, and they were able tp provide me with a workaround


The workaround was to add the following key into the image, (i created a app layer with this registry and added it to the published template)
response from engineering


HKLM\System\CurrentControlSet\Services\Unirsd\ExcludeKey [REG_MULTI_SZ]
Then set it to \Registry\Machine\Software\Microsoft\Windows Search

The problem this avoids is that FsLogix is trying to manage the registry key/values below this root location, and when we (later) start up our registry virtualization (which only happens if at least one App Layer is attached) we begin by virtualizing our persisted registry information from the P1 volume. The P1 information is stale as it was generated most likely during MCS image prep. This causes the index-related registry state to be altered just enough to cause problems."


thought id share this info in case someone else runs into this problem.



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...