Outlook & Search

[reuvygroovy]

Hi,

We are have started to implement the Outlook UEM configuration to enable offline OST files and Cached Mode. But we have noticed that even though the OST carries over each time to a new workstation in it's original size (ie. it doesn't start from scratch), the problem is that Windows Search's index is empty upon connecting to the new desktop, when searching for a word we get "We couldn’t find what you were looking for".

When i rebuild the index on the desktop after connecting the search works just fine, but when I reconnect to a new desktop again, the above issue repeats itself.

Where is the index stored exactly? On the local PC? Do i need to redirect it as well?

Thanks,

RS

[LarryBlanco2]

I think in order to get a solution to your problem more information is needed. 

OS version?

R using using view composer or Instant Clones? Or is it a full VM?

Are you using App Volumes? and with or without writeable volumes?  and what version?  I assume you are because of your posting here.

There are so many variables and there have been so many issues with outlook search that it's hard just to give one answer.

But for the most part the search index is redirected on an AppVolume writeable to here on the VM:

C:\SnapVolumesTemp\writable\persistent\Search\Data\Applications\Windows

[reuvygroovy]

Sorry,

We're using:

• Instance Clones
• App Volumes & Writable Volumes version 2.14
• I tried now to redirect the Index location to a folder on the writable volume but I haven't had time to check and/or this isn't mentioned anywhere as a requirement in any of the documents.

That's why I asked if this is known and/or anything is written about this.

[LarryBlanco2]

The Outlook search only worked for me on Version 2.14, which u are running.  All previous version of app vols had issues, at least for me, with Outlook and search working correctly.

You are still required to follow the documentation on outlook search redirection for Instant Clones and App Vols.   I've attached my modified zip file that worked for me for the app vols writable volumes.  KB: 2149799.  Although do note the the bat files in the writable volumes are now different in version 2.14 vs all previously released versions.  I do not think the article has been updated to reflect that, hence my modified zip file. 

Also, within UEM, I do not use the "App Volumes - Outlook OST Redirection."  I just use the "ADMX-based Setting" and have the default location redirected to a network share.  Something similar to:

\\server\VDI_User_Profiles\%username%\AppData\Microsoft\Outlook

If you do decide to use the "Outlook OST Redirection" feature built into UEM it'll redirect the OST to "C:\SnapVolumesTemp\Writable\UEM\OST" by default.    I had limited success with this.  That is why i decided to redirect to a network share using GPO via UEM instead.  Added benefit is that the writeable volume is not inflated with OST files.

I would like to note that my environment is currently Windows 7.   Windows 10 is likely different.   We are finally starting testing and migration.

Larry

[reuvygroovy]

Hi,

Thanks for the detailed reply.

1. You know that OST redirection to a network share isn't supported by Microsoft right?
2. What benefit is there anyhow to storing the OST on a network share as opposed to a writable volume - the storage is required regardless - what are the tradeoffs?
3. How come you redirected the Windows Server via a startup script instead of using the built-in GPO setting to do so?

Thanks!

[LarryBlanco2]

1) It is essentially supported. Although if you do run into any issues and you want MS support, it needs to be reproducible in a non-redirected environment.

It specifically for RDSH and VDI environments using Outlook 2010 and newer. 

https://support.microsoft.com/en-gb/help/297019/limits-to-using-personal-folders-pst-files-over-lan-...

Outlook 2010 or later versions functionality is supported when networked .pst or .ost files are used under the following conditions:

• A high bandwidth/low latency network connection is used.
• There is single client access per file (one Outlook client per .pst or .ost).
• Either Windows Server 2008 R2 or later Remote Desktop Session Host (RDSH), or Windows Server 2008 R2 or later Virtual Desktop Infrastructure (VDI) is used to run Outlook remotely.

2) I find easier to manage the volume and it's size as one entity on our storage system as opposed to managing each individual writable vmdk.  OST files take anywhere from 1mb to 10+GB inside the writable. Most of the time,  the size  of the mailbox does not translate to the size of the OST.   A user can have a mailbox with a max size of just 3GB and their OST can be 12GB.   I see that issue all the time.  Or the helpdesk recreates the OST and now they have 2 or more OST with different sizes and their writeable ran out of space because of the OST files.

2a)  I conducted some tests before going this route.   Comparing speeds of the cached OST on the writable and on my NAS   There wasn't any noticeable difference in opening outlook and it loading the ost.   In my environment, I have a NetApp NAS and I do use VSAN for the Instant Clones and App Stacks.   So It's fast all around.   I store the OST on a volume on the netapp.   I can easily monitor the space with our monitoring tools and it automatically grows when it needs to. 

3) I don't quite follow the last question.   Why I used UEM to create the GPO 'admx' for the OST redirection instead of just using GPO?  If that the question, It's to have everything in one place where it's VDI related.   My helpdesk can see and somewhat understand UEM.   If I start throwing other tools to lookup GPO and GPP's I think their heads might explode.

Larry B.

[reuvygroovy]

Hi,

Just to confirm - you DO NOT redirect the user's Search Index as part of a writable volume and/or when using OST files on the network? Is the index then contained within the OST file itself and automatically immediately available upon connection on the new desktop (ie. you don't have to wait for a re-indexing of the content)?

I haven't seen anyone mention anything specifically about the index, that's why I ask.