Account Types
Frame can provide a very customized experience to the end user depending on the unique needs of your organization. This section of the documentation reviews all available Frame account types and their benefits.
Non-persistent (Default) vs. Persistent Desktop Accounts
Non-persistent Accounts Overview
A non-persistent Frame account is used when a Frame administrator wants their user sessions to be “stateless.” When sessions are stateless, any changes made to an instance are completely erased once the session is closed. The instance is then returned to a pool where it waits to be served to the next user, starting from a clean slate.
Non-persistent accounts can be created and configured with the following:
- AHV, AWS, Azure, and Google Cloud Platform
- Domain Joined Instances
Applicability
Non-persistent Frame accounts were designed for organizations who wish to:
- Deliver virtualized applications (rather than desktops),
- Provide a consistent end-user experience between user sessions,
- Simplify image management by updating a single image when desired and easily making it available to a group of users, and
- Provide groups of users access to different combinations of compute, memory, and GPU resources (e.g., instance types) based on user profiles.
Requirements
- Users must be able to authenticate to the platform using either:
Setup
Non-persistent Frame accounts are a selectable option during the "Create Accounts" process.
Persistent Desktop Accounts Overview
In a typical Frame account, sessions are “stateless.” This means that all changes made to an instance are wiped from the instance after the session is closed. The instance is then returned to a pool where it waits to be served to the next user. The Frame platform also offers an alternative option called “Persistent Desktops.”
Persistent Desktops are stateful, desktop-only instances which are individually assigned to users. Users are given administrative control over their own desktop – they can install and manage their own unique application sets and settings in their own persistent environment. Account administrators can still monitor usage and basic session activity through the account Dashboard.
Persistent Desktop accounts can be created and configured with the following:
- AHV, AWS, Azure, and Google Cloud Platform
- Domain Joined Instances
Applicability
Persistent Desktops were designed for organizations who prefer to give their users more control over their own environments. Frame Account administrators still configure the Sandbox image to be used as a base for all instances in the pool, but end users manage their own instance once assigned. If required, Persistent Desktops can be domain joined, in order for enterprises to manage these persistent desktops through a Windows domain.
Requirements
Users must be able to authenticate to the platform using either:
If the persistent desktop Frame account is configured to join the persistent desktop VMs to a Windows domain, the users can be required to authenticate to their Windows domain before accessing their assigned Windows desktop.
Setup
The Persistent Desktops feature is enabled upon account creation. It cannot be enabled on accounts that have already been created, since provisioning and infrastructure management of a Persistent Desktop account is handled differently than on a non-persistent Frame account.
Administration
See the Persistent Desktops Administration guide for more details.
📄️ Hierarchy
The Frame platform uses a hierarchical approach to organizing administration and access to accounts. In this section, we'll define each tier and the intended configuration strategy at each level.
📄️ Account Types
Details about non-persistent vs. Persistent Desktop accounts.
🗃️ Licensing
3 items
📄️ Deployment Planning
Frame enables customers and partners to create a range of end user experiences. This page reviews the key topics one should consider when planning a Frame deployment.