Outlook For Windows

Collipal Cabello <[email protected]>
Newsgroups alt.comp.software.financial.quickbooks
Message-ID <[email protected]>
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.


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:

WindowsSearch



outlook for windows

DOWNLOAD https://1gely-formu.blogspot.com/?fnly=2x7vpA 






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?

Thanks!


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

 f448fe82f3
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.