4 Replies Latest reply on Mar 13, 2020 12:25 AM by julatoski

    Writable Volumes for Outlook Indexing

    curtistcreps Lurker

      Per the following article, I have successfully configured a writable app volume that captures a user's OST and indexing upon logon: VMware Knowledge Base

       

      I performed the following steps as instructed:

       

      1. Configure the writable per the above article

      2. Assign users to writable

      3. Log in and re-create Outlook profile

      4. Begin indexing

       

      I can confirm that I am seeing the OST in the default path of the writable (as specified in DEM: C:\Snapvolumestemp\) And from what I can tell, any PSTs being indexed are also being written to that location. The issue I am seeing now is that whenever a user logs back in, Outlook begins indexing again even though the data still exists in C:\Snapvolumestemp and I am also able to confirm that the writable has status "attached" in the AppVolumes manager. I can also verify that the the same path in the Outlook Indexing options exists even after indexing starts again on logon:

       

       

      Has anyone else seen this behavior before? Is there something that I'm not configuring correctly in Outlook that is causing it to re-index? We are using non-persistent desktops in our environment.

        • 1. Re: Writable Volumes for Outlook Indexing
          sjesse Master
          User ModeratorsvExpert

          You should update the location to appvolumes not horizon, as you may get higher quality responses.

          • 2. Re: Writable Volumes for Outlook Indexing
            VirtualSpence Enthusiast
            VMware Employees

            Which version of App Volumes are you running?
            The KB you're referencing states: Note: This solution can be used with App Volumes 2.12.x and 2.13.x. For AppVolumes 2.14 a solution to manage the OST file and the Search index is build-in, so that version does not require this KB anymore.

            1 person found this helpful
            • 3. Re: Writable Volumes for Outlook Indexing
              curtistcreps Lurker

              An update:

               

              I ended up transitioning over to the FSLogix route as many other people reported success with it. In all my testing I did with writable volumes, I just found that they were unreliable more so whenever PST's are attached in a mail profile and the search index needs to be roamed. We use very small mailbox sizes in our environment, 2GB for all users running Exchange 2010 (Migrating to 365 later this year). Naturally PST's are the only remedy for storing email for the end users and can't be avoided. We allocate enough storage per user (each has their own home drive) that they are able to store PST's on. Problem is, PST's that are referenced on UNC locations also cause indexing issues. I couldn't justify spending more time trying to figure out why writable volumes would cause the search index to rebuild at every log on, take massive amounts of time per user depending on the size of those PST's for Outlook to finish indexing and also prevent users from searching in Outlook at all while they waited for indexing to finish. FSLogix works well so far, as we have been using it for about three weeks now with no reported issues yet.

              • 4. Re: Writable Volumes for Outlook Indexing
                julatoski Enthusiast
                VMware Employees

                Very sorry you were having trouble with this KB article and I am happy you have found a solution to your problem.

                 

                App Volumes 2.13 and earlier are no longer supported and this KB is no longer relevant.  In all current versions of App Volumes, Outlook Search Index and OST files are automatically persisted to Writable Volumes without additional configuration. 

                 

                We will make sure this KB article is removed.

                 

                Thank you.