Outlook ost and Search Index and Writeable Volumes

[robsisk1972]

Greetings all,

So I am attempting to persist the Outook.ost and Outlook search indexes by creating a custom template and writeable disk.  I do not want the entire use profile to be captured on this wirteable disk...ONLY the OST and Windows/Outlook Serach index.

I followed this article Create and size a new AppStack template | Age Roskam with a little success but have 1 major issue.

The issue is once configured to a user and the user logs on, it acts like it is attempting to capture a appstack like it was running on a provisioning machine. User gets the message stating "I am in provisioning mode"  etc.   I guess I'm not too shocked since the template data that is copied is from the /cloudvolumes/apps_templates/    folder.

Has anyone been able to get this to work?   Should I not be using the template in /cloudvolumes/apps_templates/?   Should I be modifying one of the writeable disk templates instead?

Thanks for looking

Rob

[Ray_handels]

Has anyone been able to get this to work?   Should I not be using the template in /cloudvolumes/apps_templates/?   Should I be modifying one of the writeable disk templates instead?

Yes. The appstack becomes read only after the provisioning process. If you need to have a read write disk you need to create a writable. Change the writable template (i'd suggest changing the UIA only, saves the hassle of removing the profile part ) and create a writable using that template. It will automatically create a writable with the user name in it so you also know what writable is for what user.

If you were to copy it from 1 datastore to another and import it in another Apppvolumes manager it will be attached to that specific user as well.

[robsisk1972]

Thanks Ray....Going to give this another go today by using a copy of the Writable UIA template instead of the AppStack template.    Hoping you nailed!

[robsisk1972]

Well....Looks like using a modified version of the writable profile disk got me passed my initial problem of the VM wanting to run like a promising machine.   Makes sense since I was using the App template as my initial base.   Appears this article needs revised as it does say to use the app writable template.  Create a custom writeable volume for specifically the Outlook OST and Search Indexes | Age Roskam     

This new configuration (using the profile writable template as the base)  does mount the writable and does store the OST and no other drives are seen by the user (like the writable disk) until I assign and mount a application disk from App Volumes.   If the user has both an appstack assigned and is using my new writable template, the user will see an new disk (E:) and be able to write to it.   If users can see this disk, they will surely move files to it and I don't want that.   My guess is that Trojans would love to store data here and have it persisted back.  

Again....Does anyone really have something like this working or is it even supported by VMWare?  Seems like VMware is strongly recommending getting away from writable profile disks to persist user data and now recommending the UEM instead.  But if using the UEM only makes Outlook re-index after every session, how can we get away from this? 

I have a support request in now and am waiting on a call.  Will see if they can provide a solution.  

Thanks for looking

[Ray_handels]

Yes, we are using writable volumes for a few years now. To be honest, one of theings we don't store is the OST file because users have a 10GB mailbox, we would end up with mail being stored in very expensive SSD disks, not really feasible .

Make sure to create the following registry key

\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\svdriver\Parameters\DriveLetterSettings=6 (DWORD). This hides the drive letter for the writable but does give it a drive letter name. The driveletter part is mostly done for applications that don't install on a network drive (looking at you google). You could use other values and just disable driveletters for appstacks and writables altogether.

I would also suggest creating this key This shows the free disk space on the writable (and the amount a user can still safe on his writable) instead of the GI.

Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\svdriver\Parameters\ReportSystemFreeSpace=0 (DWORD).

[HappierIT_TSmit]

This was really helpful. I was tasked with setting up non-persistent instant clones for a client but their line of business app required cached mode in outlook. The licensing they got sold on was also 0365 for office and Windows 10 Enterprise (E3 subscription). This created an additional layer of complexity that would cause the writeable to become corrupt after the first login. Testing with a KMS server did not replicate the issue.

The writable profiles in our test environment kept corrupting. After one login it would get stuck at the welcome screen. I would have to remove the desktop in view, then power off manually in vcenter and then delete the writeable (or restore from backup).

When they did work the profiles slowed down login times and were needlessly large. I wish %userprofile% was accepted in snapvol.cfg...

I made a custom snapvol.cfg to only virtualize a custom OST path like in the article you shared and also included the path for windows search. You would need to include a script to enable and start windows search when the writeable mounts or it kills your provisioning time (windows search should be disabled during provisioning). VMware Knowledge Base

I use UEM to capture all other settings and have implemented folder redirection through UEM.

App Volumes 2.16

Horizon 7.7

vSAN

using direct attach to host

UEM 9.4

vCenter 6.7

Azure AD SSO (password hash)

Windows 10 Enterpise (E3 subscription).