Skip to main content

Frame Image Management: Onboarding and Configuring SaaS Applications

· 4 min read
Jake Norman

Frame Image Management: Onboarding and Configuring SaaS Applications

Scenario: As a customer, you want to use Frame to provide access to Software-as-a-Service (SaaS) applications. SaaS applications are also known as web-based software applications, meaning your main form of access to the application is through a web browser, such as Google Chrome or Microsoft Edge. You want to utilize the Application Experience to provide these applications to your users. With Frame, how do you accomplish this?

This series of blogs is 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?”. This blog will cover a common virtual desktop use case to provide SaaS applications to users.

Why are SaaS applications different than any other application?

With most applications, installing and onboarding them is as simple as is documented. SaaS applications are a different breed, since they usually work off of the same root application, the web browser. With Frame, onboarding an application is based upon the executable, and only one listing of the onboarded application will be visible in the Sandbox page on the Dashboard. For the example we show below, we will be using Google Chrome as the web browser.

Sandbox and Chrome Browser (Onboarded)

So, you have multiple use cases for one executable inside your Frame environment, but can only onboard each executable once. What do you do? Luckily, there is a way to accomplish what you need, although it's a little more complex than may be apparent at first glance.

The basics of what you need to do is actually very simple - use multiple executables. Bear with me here. During the onboarding process of an application, Frame grabs pertinent information of the application, such as executable name, and provides this information to you on the Sandbox page of the Dashboard.

Onboarded Chrome Browser Settings

Once the application onboarding is complete, the onboarded application is simply an entry in the Frame control plane database and is not tied to the executable in the Sandbox. Its only purpose is to tie your desires as the administrator to how Frame uses the application.

What does this mean? Well, it means you can onboard an application unrelated to the browser, such as PowerShell. Once that application exists within Frame as an onboarded application, you can edit the application however you wish, including changing the executable being used. In the example below, the path to the Chrome executable is configured.

Onboarded PowerShell Settings

Alright, I understand, now what?

Now that we've broken down what needs to be done, let's talk about how to actually do what you are looking to do. While you could definitely find multiple executables, you won't be using and onboard them, changing them all to match the applications you need. This way is a little cumbersome and could potentially cause problems in the future.

So, what's the best way to do this? While you still need multiple executables, it doesn't have to be different applications. You can make multiple copies of the primary executable and onboard those executables. Then, once onboarded, you can delete the additional executables as you won't need them anymore.

Multiple Chrome Executables with Different Names

Now, from the Sandbox page on the Dashboard, you would just change each of the onboarded applications to match the primary executable location and file name (e.g,. Chrome), but have a different display name, icon (if desired) and parameters. The parameter modification is especially important, as that's how you distinguish the URL that opens Google Chrome specifically to the SaaS website, rather than a default.

Chrome Executable Settings with Defined URL

At this point, the executables that were created inside the Sandbox for onboarding purposes are no longer necessary and can be deleted.

What's Next?

In this blog, we covered a common ask by Frame customers, providing a way for their users to access SaaS applications through Frame. Next, we will be covering another image management technique used in customer environments to install per-user persistent applications in a non-persistent workload.

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

LinkedInTwitter
#workfromframe
Jake Norman

More content created by

Jake Norman
Jake Norman is a Staff Consultant with Nutanix Professional Services. He has been a part of the Professional Services team for three years and prior to that spent 20+ years in a myriad of different environments focusing on EUC and UX work.

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