5 Replies Latest reply on Jun 18, 2020 11:43 PM by jigocz

    AppVolumes - Appstacks 2.15 vs 2.18.2

    jigocz Lurker



      let me share with you the experience while working with Appstacks created in AppVolumes version 2.15 and  then upgraded the AppVolumes and Appstacks to version 2.18.2 - all appstacks has been re-created for Appvolume version 2.18.2


      short info about our environment


      • We use direct appstacks assignments to user only.
      • The Golden image:
        • Windows 10 image LTSC - 1809 - OS Build 17763.1158 windows updates to 04/2020,
        • AppVolume Agent
        • Vmware Horizon agent 7.11.0
        • Vmware Tools 10.3.5 - build 10430147
      • after each appstack capture, the capturing (packaging) virtual machine is reverted back to the original snapshot,
      • the capturing (packaging) virtual machine has installed only the VMTools 10.3.5 and AppVolumeAgent
      • Appstack template used is 2.18.2
      • Writable volume used is 2.18.2 - uia_plus_profile



      => Our big problem now is that what was working with appvolumes version 2.15 is no longer working in version 2.18.2,


      => with appvolume agent version 2.15  we have assigned for example 11 versious appstacks, (captured from application template 2.15)

      1. SAPGUI_7.50FP9HF2_x86
      2. Python_2.7.8_x64
      3. PuTTY_0.70_x64
      4. PersonalCommunications_12.0.4.1_x86
      5. OracleDataAccessComponents_12.
      6. OneDrive_19.043.0304.0003_x86
      7. OfficeAccessDatabaseEngine2007EN
      8. Office2016_16.0_x86
      9. DB2ConnectServer_11.1.0.1527_x64
      10. Chrome_71.0.3578.98_x64
      11. AcrobatReaderDC_19.010.20069_x86


      => there is no any dependency that we would need to assign any of that appstacks in specific order, with some precedence, etc

      => how the appstack is assigned - attached it works without issue.



      => With version 2.18.2 all appstacks has been created from the beginning -  captured from application template 2.18.2) see the example below

      1. PersonalCommunications_12.0.4.1_x86_T2182
      2. OracleDataAccessComponents_12.
      3. SAPGUI_7.50FP9HF2_x86_T2182
      4. Python_2.7.8_x64_T2182
      5. PuTTY_0.70_x64_T2182
      6. OneDrive_19.043.0304.0003_x86_T2182
      7. OfficeAccessDatabaseEngine2007EN_12.0.4518.1031_x86_T2182
      8. Office2016_16.0_x86_T2182
      9. Chrome_71.0.3578.98_x64_T2182
      10. DB2ConnectServerRuntimeClient_11.5.0.1077_x64_T2182
      11. AcrobatReaderDC_19.010.20069_x86_T2182


      =>  it looks like there is a some new dependency with appstacks assignment order

      eg. PersonalCommunications works only when it is assigned in first place, but then the OracleDataAccessComponents does not work, also seems that SAPGui does not work correctly and there might be some other appstacks affected

      => is barely impossible to find combination for the appstack assignment to find the correct order when the all assigned apsptacks will work correctly

      => also might be good to understand what has been changed in version 2.18.2 - this was no problem in version 2.15

      => what we have observed during our internal troubleshooting for Appstacks and AppVolume agent  is that System Environment Variables under SystemProperties are propagated only from latest attached appstack,

      => while working with Appstacks 2.15 and AppVolume agent 2.15 are propagated all System environment variables under System Properties.



      We have opened the Support case with Vmware, after initial call we are waiting for further instructions and troubleshooting session.


      Has anyone observed this behaviour and if so, were you able to resolve it?


      Thank you.

        • 1. Re: AppVolumes - Appstacks 2.15 vs 2.18.2
          jigocz Lurker



          as part of our internal testing we have updated the appvolume agent in Golden image to version 2.18.4 (recently released by Vmware) and created a new desktop pool with one provisioned VDI VM and test user is logged in - with appstacks and writable volume attached  =>  to  check for appstacks assignment order  with appvolume agent 2.18.4


          ==> new appvolume agent 2.18.4 does not solve the problem with appstacks assignement order / system variables.


          The SupportCase is still opened with Vmware Support without further update till today.

          • 2. Re: AppVolumes - Appstacks 2.15 vs 2.18.2
            antonpaloka Novice

            We just upgraded to this version as well on our manager. In the process of upgrading, I am upgrading the tools to the same version as you, but the appvolume agent cannot contact manager whenever I use that version of tools. Curious if you would be will to test updating the tools, if your environment allows it?


            EDIT: FYI - I just tried to install my agents, starting with VM Tools 11.1.0 and App Volumes 2.18.4 and I have no error messages contacting manager.

            • 3. Re: AppVolumes - Appstacks 2.15 vs 2.18.2
              antonpaloka Novice



              Just wanted to check in again, if you had a chance to upgrade the VMware Tools

              • 4. Re: AppVolumes - Appstacks 2.15 vs 2.18.2
                jigocz Lurker

                yes, we have tested also with the Vmware Tools 11.0.6

                • 5. Re: AppVolumes - Appstacks 2.15 vs 2.18.2
                  jigocz Lurker



                  we have been told by Vmware support that  in Appvolume version 2.18.0 there is special handling for environment variables in a certain callback function, but it is not present in 2.18.2 onwards.

                  The recommendation is to downgrade the agent to 2.18.0 and deploy a test pool to see if the issue with environment variables occurs.

                  If it doesn't occur, then I would suggest running this build of agent in your environment until 2.18.5 is released. This should also contain fixes of the 2.18.4 build.

                  This build  - 2.18.5 is do for release at the end of July, but this date could change if engineering need to push the date back, if they need to add other fixes to the build, etc..