Scenario: As a customer, you want to simplify your image management overhead by providing non-persistent Desktop Experience workloads to your users, but some users require access to non-standard applications that you don’t want to put into the base non-persistent image, nor provide via an Application Experience from another Frame Account, nor provide via a persistent workload. How do you accomplish this with Frame?
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!
Follow Us
More content created by
Jake Norman© 2024 Dizzion, Inc. All rights reserved. Frame, the Frame logo and all Dizzio product, feature and service names mentioned herein are registered trademarks of Dizzion, Inc. in the United States and other countries. All other brand names mentioned herein are for identification purposes only and may be the trademarks of their respective holder(s). This post may contain links to external websites that are not part of Dizzion. Dizzion does not control these sites and disclaims all responsibility for the content or accuracy of any external site. Our decision to link to an external site should not be considered an endorsement of any content on such a site. Certain information contained in this post may relate to or be based on studies, publications, surveys and other data obtained from third-party sources and our own internal estimates and research. While we believe these third-party studies, publications, surveys and other data are reliable as of the date of this post, they have not independently verified, and we make no representation as to the adequacy, fairness, accuracy, or completeness of any information obtained from third-party sources.