Frame Image Management: Installing Persistent Applications into a Non-Persistent Workload

This blog series centers around Frame Image Management. Image Management is “How do I set up my environment in the most optimal way, to minimize the number of images I have to manage?”. The first part of this series covered how to onboard and configure SaaS applications. This blog post will cover another common virtual desktop use case, how to install persistent applications into a non-persistent workload.

A quick note!​

For those of you asking, what is the difference between a non-persistent and persistent environment, check out this detailed breakdown explaining the differences as it pertains to Frame. What are the caveats to doing this?

For this to work, please note that there are a couple caveats. This scenario will not work if an application is tied to, or licensed by, the following information:

• IP address
• MAC address
• Computer’s hostname
• Other hardware identifiers

If you have restrictions as per the above, other than the IP address, you would need to use a persistent desktop. For the IP address, Frame utilizes DHCP, even for persistent workloads. As such, there is no guarantee that the IP address won’t change. In addition, any application that does not allow you to install the application to an alternate file directory will not work in this scenario. For example, the enterprise version of Google Chrome has no way to change the location of the application during the installation process. As such, this application would not be a good fit for this scenario.

Alright, I understand, now what?​

Okay, now that the caveats are out of the way, let’s get into the nitty gritty.

For this to work, the user must have access to a persistent disk which is attached to their non-persistent workload VM each time they establish a Frame session. With Frame, you can use Personal Drives, which you can enable from the Settings page on the Account Dashboard.

Please note that, Personal Drives do not incur additional costs when using on-premises infrastructure (they just consume storage you’ve already paid for). However, in the public cloud (AWS, Azure, Google), Personal Drives have an additional cost based upon the amount of storage used.

A Personal Drive is a persistent disk added to your workload machine, added to the OS as the P: drive. This drive’s purpose can be something simple like providing a location to which users can save files or be used for the installation of applications, as in this case.

So, with the Personal Drive added to the workload machine, you can install applications to a persistent location that isn’t reset when the user closes their session. Doing so may be possible through the application installer but may also be possible through command line variables. Make sure to check vendor documentation on the best way to handle this.

That seems easy enough, but what are some possible issues I can run into?​

That’s a fantastic question. While installing applications is a straightforward process when using the defaults, installing to an alternate location in a non-persistent VDI environment can throw some wrenches into how the application is expected to work.

One possible issue that may be seen with applications in this scenario is if the application requires the existence of values in the Local Machine registry hive (HKLM). Since the location where the HKLM registry hive exists is located on the C: drive, any values that are added to this location during installation will not be retained. Most applications work perfectly fine without these values and will recreate them if they don’t exist, but there’s no way to guarantee your application will work as you desire.

In addition, by default, any custom registry values in the Local Machine registry hive will also not be retained, although this can be bypassed in a couple different ways, one being by using a script or group policy to set the values upon boot or logon and another using a profile management tool that allows extension of the profile to include Local Machine registry information. This can also be seen by the application not existing in the Programs and Features applet, as the list of applications installed is a merger of installed applications based upon a registry key and values, which aren’t persisted upon closing your session.

What’s next?​

In this blog, we covered a common ask by Frame customers, how to install persistent applications into a non-persistent workload. Next, we will be covering another image management technique used in customer environments, pre-configuring user-specific settings for all users from the Sandbox.

Contact Us​

Need help with your Frame deployment, have an idea for a new use case, or just want to learn more about Frame?

Email us at frame-sales@dizzion.com and one of our experts will reach out!