VMware Horizon Community
SummaCollege
Hot Shot
Hot Shot

Howto: store OST and Search on Writable Volume without pollution

My goal was to make use of a Writable Volume to store the OST files and search database. No other data should be stored on the Writable Volume to keep it clean and as small as possible. Users don't have administrator rights, but still the Writable Volume was polluted with onwanted data.

To achieve this i made use of UEM v9.7 next to App Volumes 2.16 and Windows 10 v1809.

I made the following changes to the snapvol.cfg file.

- To make sure no file changes are stored on the Writable Volume i commented out the following line using a #

#virtualize=\

- To make sure no registry changes are stored on the Writable Volumei deleted everything within # REGISTRY

Last thing is did was enable the "OST to Writable" setting within UEM. This was the only setting needed for all this to work. The OST and Search now automagically gets created on the writable volume without any other garbage. The aforementioned settings within the snapvol.cfg file are not necessary for this to work, i guess that the filter driver handles this seperately from the snapvol.cfg file.

Using default settings the OST is written to: "C:\SnapVolumesTemp\writable\UEM\OST"

And the search database is written to: "C:\SnapVolumesTemp\writable\persistent\Search"

For us the result is that our writable volumes are 100% clean, as small as possible and only used to store the data we want.

0 Kudos
12 Replies
VDINinja311
Enthusiast
Enthusiast

SummaCollege

We are also testing this exact setup. Have you noticed that if a user maps a networked printer with this writable volume it persists the mapping from desktop to desktop? We have noticed that. We do not want that as we control all of our printer mappings with UEM (AD Groups).

0 Kudos
SummaCollege
Hot Shot
Hot Shot

I haven't noticed this yet, but i must admit i am not sure i have tested this.

Let me try this today and i'll report back here...

0 Kudos
SummaCollege
Hot Shot
Hot Shot

I have done a few quick tests, but a manually created drive mapping is NOT persisted between sessions in my setup.

There must be a setting in UEM or the snapvol.cfg that is persisting the drive mapping in your setup then.

And we are also using UEM to create the regular drive mappings (and all other user GPO settings)

0 Kudos
VDINinja311
Enthusiast
Enthusiast

SummaCollege​, my previous post was about networked printer mappings not drive mappings. Smiley Happy

Our users aren't smart enough to manually map drives. Smiley Happy

0 Kudos
SummaCollege
Hot Shot
Hot Shot

You are absolutely right, i must have forgotten my coffee this morning Smiley Wink

Lee me try again...

0 Kudos
SummaCollege
Hot Shot
Hot Shot

Did another test, this time with printer mappings and not drive mappings Smiley Wink.

Result is the same, the printer mappings are not persistent between sessions. They are not remembered using UEM or stored on the Writable Volume.

0 Kudos
VDINinja311
Enthusiast
Enthusiast

Interesting, thanks for testing that. Now I need to figure out why we are seeing ours persist in the Writable.

You are using the 2.16 writable template, I assume?

0 Kudos
SummaCollege
Hot Shot
Hot Shot

Yes, we are using 2.16 templates.

Are you sure you are not including the registry settings using the snapvol.cfg? I have removed all registry inclusions from snapvol.cfg.

0 Kudos
VDINinja311
Enthusiast
Enthusiast

Have you been seeing any other issues with writables, or do yours seem to be solid?

0 Kudos
SummaCollege
Hot Shot
Hot Shot

We had our fair bit of issue regarding Writable Volumes.... but not really related to this. Mostly related to growing writables and increasing logintimes.

But ever since we are using the stripped down snapvol.cfg and UEM combined we had no issues so far. The logintimes and writable sizes are stable.

0 Kudos
mchadwick19
Hot Shot
Hot Shot

How did this impact (or improve, hopefully), login times?

I'd like to implement this to clean up our writable volumes.

VDI Engineer VCP-DCV, VCP7-DTM, VCAP7-DTM Design
0 Kudos
SummaCollege
Hot Shot
Hot Shot

It's a bit difficult for me to make an estimate on what the impact on logintimes was when implementing this approach. We were running a pilot environment with different ESXi, Horizon, App Volumes, hardware, etc. My good guess is that this minimalistic approach is helping login times to be more consistent. Current login times are anywhere inbetween 20-30sec. This is including attaching a few appstacks. Optimisation is not completed yet, only done using a subset of the available OSOT items. I am convinced that i am able to bring down the login times even further when i am at the point to do more optimisation.

For us, this approach is exactly what we need. We have maximum control over what gets included inside the writable volume and thus have less unwanted growth.

Edit: and not unimportant, we have had no issues until now!