Flexxible|SmartWorkspaces Suite allows to deploy and orchestrate different user resource types:

• VDI
• SDI
• Published Application

These resources are created from a template. Its assignment process fires that user resource creation process.

VDI

VDI stands for Virtual Desktop Infrastructure and it refers to the process of running a user desktop inside a virtual machine (VM) that lives on a server in the datacenter. It’s a powerful form of desktop virtualization, because it enables fully customized desktops for each user with all the security and simplicity of centralized management.

VDI enables the customers to streamline the management and costs by consolidating and centralizing the desktops while delivering end-users mobility and the freedom to access virtual desktops anytime, from anywhere, on any device.  It’s important to understand, however, that VDI is only one form of desktop virtualization.

The VDI behaviour is determined by its type. There are two VDI types:

• Non-persistant or Pooled
• Persistant

Both cases are ruled by this principle: there is a VM for each user that "contains it".

Non-persistant or pooled VDI

A non-persistant desktop is composed by a minimum of two virtual hard disks. But, depending on the used technologies, they could be three:

1. Identity disk: this is a single identity disk, which is used to provide a unique identity to each VM. The XenDesktop inner functionality creates the identity disks. Each VM automatically gets an identity disk during the deployment. This disk stores the information about the machine account, domain belonging, etc
2. Differential disk: This is a copy of the template disk with write access. This disk will be disconnected or destroyed by closing the user session or rebooting the VDI. No stored data will be saved.  Right after that, a new disk will be generated and attached to the VM, in order to be available for a new user session.
3. User profile: Given that Flexxible|ProfileManager powered by Fslogix is used, a new disk will be attached to the VM to host the user profile, to avoid that any data stored on it to be deleted by the differential disk destruction.

The desktop behaviour becomes determined by the following VM features:

• The desktop is template-dependant. All the changes and updates will be performed by the update process to the last template version. Any  change to the configuration or the installed software should be first performed to the template. After that, it can be spreaded to the desktops by upgrading them to the new template version.
• Pooling operation. Once a user is assigned to a template, he will be allowed to access the first (whatever) available VM in the pool, to start a new user session.
• The log off and reboot operations involve some extra actions, because this process also restores the differential disk, taking some seconds more to complete it.
• The changes performed during the user session will be lost, except for those stored in the user profile. E.g. In case an allowed user installed a new application, updated a browser o any antivirus firmware and saved some new files in the user documents folder, all these changes would be lost, except for that documents, because the user documents folder is hosted in the user profile.
• The parity between those users assigned to the pool and those machines grouped on it should be taken into account. For instance, given a 50 machines pool and 70 users assigned to it, only 50 could work simultaneously.
• Hardware limitations. The assigned RAM or CPU can't be increased at VM level, but at the pool.

Persistant VDI

A persistant disk is composed by a minimum of two virtual hard disks. But, depending on the used technologies, they could be three:

1. Identity disk: this is a single identity disk, which is used to provide a unique identity to each VM. The XenDesktop inner functionality creates the identity disks. Each VM automatically gets an identity disk during the deployment. This disk stores the information about the machine account, the domain belonging, etc
2. Differential disk: This is a (full clone) copy of the template disk with write access. Any performed change will stand.
3. User profile: Given that Flexxible|ProfileManager powered by Fslogix is used, a new disk will be attached to the VM to host the user profile, so that a contingency desktop is provided to the user, in case of any access-blocking-event to his main desktop and to keep his profile available.

The desktop behaviour becomes determined by the following VM features:

• The desktop isn't template-dependant. Once the virtual machine is created, it's a template copy. But, from that moment on, those changes performed by the user they will stand and the desktop will break its dependance from the template. Therefore it can't be upgraded to the new template versions.
• Nominal operation. Once a user is assigned to a template, he will be linked to that VM, to start every new user session on that same one.
• The changes performed during the user session will be kept: Windows updates, antivirus, software installations...Any change performed by the user will persist in the desktop. The user profile will be saved in a different disk, to allow him to access to it, in case he's got several assigned resources and to reduce the impact of loosing access to his main desktop.
• The parity between those users assigned to the pool and those machines grouped on it should be taken into account. For instance, given a 50 machines pool and 70 users assigned to it, only 50 could work simultaneously.
• Hardware limitations. The assigned RAM or CPU can be increased at VM level.

SDI sessions

The principle "one user, one VM" makes no sense in a SDI environment, because a SDI is intended to provide the user with a complete desktop session on a shared environment: A single server where a group of users can start a session. We name this server type as "applications server", "SDI server" or "appserver".

The appserver operation is similar to the non-persistant VDI one and it's composed by a minimum of two virtual hard disks. But, depending on the used technologies, they could be more:

1. Identity disk: this is a single identity disk, which is used to provide a unique identity to each VM. The XenDesktop inner functionality creates the identity disks. Each VM automatically gets an identity disk during the deployment. This disk stores the information about the machine account, the domain belonging, etc
2. Differential disk: This is a copy of the template disk with write access. This disk will be destroyed by closing the session or rebooting. No stored data will be saved.  Right after that, a new disk will be generated and attached to the VM, in order to be available for a new user session.
3. User profile: Given that Flexxible|ProfileManager powered by Fslogix is used, a new disk will be attached to the VM to host the user profile, to avoid that any data stored on it to be deleted by the differential disk destruction. The amount of attached user disks to the VM will depend on the number of users connected to the appserver.

The appserver behaviour becomes determined by the following VM features:

• The desktop is template-dependant. All the changes and updates will be performed by the update process to the last template version. Any  change to the configuration or the installed software should be first performed to the template. After that, it can be spreaded to the desktops by upgrading them to the new template version.
• Pooling operation. Once a user is assigned to a template, he will be allowed to access the first (whatever) available VM in the pool, to start a new user session.
• User concurrency. A resource consume profile should be set, to assess the hardware needs for each appserver and the number of needed appservers to provide the services for the assigned users group.
• The changes performed during the user session will be lost, except for those stored in the user profile. E.g. In case an allowed user installed a new application, updated a browser o any antivirus firmware and saved some new files in the user documents folder, all these changes would be lost, except for that documents, because the user documents folder is hosted in the user profile.
• Hardware limitations. The assigned RAM or CPU can't be increased at VM level, but at the pool.

Published applications

The published applications allow to provide a user with just an application interface on his session. So, that user could be using a physical machine, a VDI or a SDI, but getting just the app interfacte from the infrastructure, instead of a full OS complete session.

Those servers used to provide published applicatons to the users  are the same that release the SDI sessions. In other words, both types have the features and they can provide both SDI sessions or published applications.