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

How to handle the constant barrage of Chrome Critical Security Vulnerabilities

Darryl Sakach


Chrome is constantly releasing new versions of Chrome to address critical security vulnerabilities. These are sometimes released multiple times in one week. With Chrome built as an App Layer we have a constant flow of creating a new app layer version, updating Chrome in the later, finalizing the layer, updating the assignments, publishing, testing the new vDisk, moving it to production, restarting the production target devices.


Does anyone have any suggestions on making this process more efficient?

Link to comment

4 answers to this question

Recommended Posts

  • 0

Hi Darryl,

Yes if you used elastic layers for chrome then the update would not require a reboot of the vdisk.  After you assign the new version to the user group then next logon for any user would use the new version.  You would want to test because by turning on elastic layering you will be adding some time to your logon but the mileage varies there.


User layers only work on desktops so you wouldn't be able to use those if your using multisession OS.


Ans yes i meant change the vdisk directly so you don have to wait for republishing each time.

  • Like 1
Link to comment
  • 1

With elastic layering you will decouple the app layer update from your image update process. You can also allow a single elastic layer to be used across different OS images (they are no longer chained to the base OS they were created against) In theory this allows you to have one Chrome App Layer assigned elastically to both Windows 10 instances and Windows 2019 for example.

In your example with PVS you would not require an update to the PVS image, the Chrome elastic layer is mounted from a file share at login.

I only include apps that are not able to be delivered as Elastic Layers within my image. All other apps are delivered elastically.


In regard to User Layers, these are not compatible with multi-session delivery (RDSH).

  • Like 1
Link to comment
  • 0

Thank you Rob.


No, we do not use elastic layering. I assume that by using elastic layering we would eliminate the assignment, publishing and restart steps . Is that correct?


When you say 'make the changes during week directly on a vdisk version' do you mean return to 'native' pvs vdisk versioning to make that update?


Our App Layered implementation is all for XenApp shared desktops and published apps. Is a User Layer approach appropriate for that type of implementation?

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...