Jump to content
Welcome to our new Citrix community!
  • 0

Citrix App Layering and App-V packages issue


Martin Mason1709161894

Question

Hi Guys,

 

We are currently having an issue within our App Layering builds with some App-V packaged applications.

We are running ELM 20.5.0.6, and we are 'deploying' non streamed packages that are both mounted and published globally within a separate 'App-V' layer where all app-v packages are deployed.

 

With some of the applications\packages we have noticed an issue when installing\deploying into our 'App-V' packaging machine (the VM used for capturing the changes on the layer) in that the applications are attempting to read data from 3 separate partitions when its being run as a published global application as opposed to it reading 1 partition when running as a published to the user.

It appears its attempted to read and write to various partitions at any given time and causing it not to fully read its cache.

 

As a work around my colleague created an app-v cache drive under a newly created partition (Q:) and created the below folders and ensured the SYSTEM account was the folders owner and updated the following registry keys so app-v will cache there as opposed to the C:\ProgramData\

 

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AppV\Client\Integration
IntegrationRootGlobal
REG_SZ
Q:\APPV\integration

 

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AppV\Client\Streaming
PackageInstallationRoot
REG_SZ
Q:\APPV\Cache

 

We are going to complete further testing, and will try and append\create a new sperate App-V partition (Q:) to see if this will resolve the issue, but we are wondering Is there any way we can change this behavior within the layer packaging machine and the C:\ProgramData\ issue?

Link to comment

8 answers to this question

Recommended Posts

  • 0

You say with some of your packages. Is that consistent behavior for the specific package meaning it always happens to that package.  If so, do you know if there were any sequencing differences between the packages that work and those that dont. Are you also running the application after adding, mounting, publishing.  App layering is going to respond the same way to the apps being installed so I would have to think the differences have something to do with the sequences.

Link to comment
  • 0
20 hours ago, Rob Zylowski1709158051 said:

You say with some of your packages. Is that consistent behavior for the specific package meaning it always happens to that package.  If so, do you know if there were any sequencing differences between the packages that work and those that dont. Are you also running the application after adding, mounting, publishing.  App layering is going to respond the same way to the apps being installed so I would have to think the differences have something to do with the sequences.

 

Hi Rob, thanks for your reply

 

The behavior is only happening on the layered build VMs not on any non app layered 2k19 machine or any other OS we deploy these application to. there are no differences in the sequencing practices from application to application as they are all sequenced to a set standard. each application is Added/mounted and then published globally and then tested.  

 

We are currently looking at adding a 2nd drive (Q:) to our layered build, would this be a valid option? if so would it be OS or Platform layer?

 

Thanks

Link to comment
  • 0

 Not sure in this case what the Q drive actually is.  You cant add a disk or partition in app layering itself.  You could temporarily add a disk in app layering while packaging if you are trying to for instance just capture the disk guid for a disk you will add to the vdas later but app layering will knot  capture anything on that disk. 

 

If the q drive is really something like a reparse point and not an actual disk I am not sure what would happen if you try to package it in a layer you would have to test it.

 

You may want to upgrade to 20.11 to see if there are any differences.  I have been working with AppV lately for a blog I am writing and i have not seen anything weird  with different applications.  I have even been able to use multiple appv layers together and it sounds like we are using the same process to cache the sequences.

Add-AppvClientPackage -Path "\\server\appv\drawio\drawio.Appv" | Mount-AppvClientPackage | Publish-AppvClientPackage -Global

After i run that i also launch the app to make sure its working.

 

It does seem very strange to me that some apps are working for you while others are not and that that has something to do with the partition configuration of the vm which should be the same to all the apps.  

Link to comment
  • 0

I guess the only other thing i think you could do is to script the appv add mount publish to run on your image after publishing.  See if its different that way without the Q drive or even add the Q drive then.  I have published scripts to automate that process for PVS images if you need to work that out let me know.

Link to comment
  • 0
1 hour ago, Rob Zylowski1709158051 said:

 Not sure in this case what the Q drive actually is.  You cant add a disk or partition in app layering itself.  You could temporarily add a disk in app layering while packaging if you are trying to for instance just capture the disk guid for a disk you will add to the vdas later but app layering will knot  capture anything on that disk. 

 

If the q drive is really something like a reparse point and not an actual disk I am not sure what would happen if you try to package it in a layer you would have to test it.

 

You may want to upgrade to 20.11 to see if there are any differences.  I have been working with AppV lately for a blog I am writing and i have not seen anything weird  with different applications.  I have even been able to use multiple appv layers together and it sounds like we are using the same process to cache the sequences.

Add-AppvClientPackage -Path "\\server\appv\drawio\drawio.Appv" | Mount-AppvClientPackage | Publish-AppvClientPackage -Global

After i run that i also launch the app to make sure its working.

 

It does seem very strange to me that some apps are working for you while others are not and that that has something to do with the partition configuration of the vm which should be the same to all the apps.  

 

56 minutes ago, Rob Zylowski1709158051 said:

I guess the only other thing i think you could do is to script the appv add mount publish to run on your image after publishing.  See if its different that way without the Q drive or even add the Q drive then.  I have published scripts to automate that process for PVS images if you need to work that out let me know.

 

Hi Rob, thanks again for the reply,

 

We will look to update the ELM asap, we are deploying the application as per the method you have stated but within a single app-v layer.

 

With regards your second point, if we deploy the packages 'on top' of a MCS deployed VM then everything works fine, would it be a valid option to deploy the app-v packages 'on top' of the deployed app-layering template VM, snapshot and then deploy the VMs with MCS? my concern here is that would negate the whole purpose of utilizing App Layering?

 

I.e. deploy the layered build to template and then deploy the app-v packages on the finalized template?

 

Thanks

Link to comment
  • 0
16 hours ago, Rob Zylowski1709158051 said:

Yea its not optimal to add things after but if it is the only thing that works then sometimes its still a good idea.  I assume you are using layering for more than just AppV apps?

Hi Rob, yes we are using layers for msi type apps, and a layer for app-v apps.

 

Should we enable the app-v client on the build on the OS layer, or the 'app-v' layer?

 

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...