Part 1: Nutanix Xi Frame On-Prem AHV: What Does it Mean to Citrix, VMware and The EUC Community !
Part 2: Deploy & Configure Xi Frame VDI on On-Premises AHV
Part 3: Enhance Nutanix Xi Frame User Experience Domain Settings Optimization On-premises AHV
Part 4: Configure Nutanix Xi Frame Enterprise Profiles For VDI On AHV
Part 5: Configure Nutanix Xi Frame Streaming Gateway Appliance for AHV VDI
Introduction
In the process of assessing the readiness of Nutanix Xi Frame VDI solution to tackle enterprise customers with on-premises environments which is currently only limited to AHV, time to discuss enterprise profile management for virtual desktops and applications using Frame. Th biggest part of any VDI solution is the end user experience and profile management can either brake or make a VDI solution.
Enterprise Profiles
Technically speaking, profile and user data are two different things but in most VDI environments, they are treated alike. Xi Frame was originally meant to handle specific workloads hosted on the cloud delivered in an easy manner through a browser to end-users so enterprise integration was not initially part of the overall design of the product given it uses a built-in user “Frame” which cannot differentiate between different profiles and data. Now with AD integration, profile and data management become a core requirement of the VDI solution.
When one wants to expand the offering to a full blown VDI solution, these matters start to pop-up so applying profile management . Before Frame could live with offering storage integration with Google Drive, Box, Dropbox, and OneDrive for users to upload/download private data while profile management was not a core requirement of the solution because of how and why it was used so it was not actually needed. Enterprise VDI requires top-notch profile and data which might live in the cloud or be stored on-premises for security or other reasons, the last being the most used currently.
Now that Xi Frame virtual desktops are domain joined and users are using their AD credentials to login thus technically speaking, profile management becomes feasible from a solution perspective. Frame has made a smart move to utilize Liquadware Labs ProfileUnity for the same which utilizes container based technology to achieve profile and data management. Don’t forget, to enable this feature, domain settings must be configured and the require logon with domain account enabled to avoid profile conflicts.
Simple Configuration !
The even smarter move is automating the required backend infrastructure for this feature and including the ProfileUnity agent as part of the Frame guest agent so all that is required is enabling one single setting and all configuration is done. Only specify the size of the profile container disk that will be created for every user initially in the accounts settings portal.
How Does it Work ?
When users launch a session, a volume group is created on the AHV cluster within the storage container that was chosen when configuring the Frame Cloud Connector. This volume group will be specific to the logged in user and follow him whenever he/she log in or out of any available virtual desktop so it will attach itself to the assigned virtual desktop as a direct volume group when the session is initiated by the user from the launchpad an detach itself on session closing.
The size of the volume group per user depends on the input specified in the Xi Frame account configuration inside the portal and the good news is that its thin provisioned.
How Does it Feel !
For a technical preview feature, its actually really fast and consistently stable but I have some major concerns which I will discuss at the end of this post. The time it took to create the initial profile was minimal and the profile loading time for every login is also quite fast. I will leave specifics and numbers to a later benchmarking post.
Since the profile is a container, the look and feel of the profile is completely local and the experience is seamless and really fast, again I was surprised of how fast it is if we remove the brokering and login part of the experience aside.
Enterprise profiles can also be disabled which applies to all users in the Frame account and cannot be enabled/disabled to specific users or groups as of now. Disabling has a nice fail-back feature in which it will delete the volume groups but keep a backup in case a user needs their profile back or someone clicked the disable button by accident.
What Needs To Change ?
Nothing is currently wrong given this is an early access feature so technical preview not production but I noticed something very peculiar that I think needs to be addressed in coming versions because it also has other dependencies that need to be supported first.
The volume group disk is attached to the assigned virtual desktop VM before the user actually logs-in into the virtual desktop itself. Because SSO to a virtual desktop is not currently possible, this means that the user can login to Frame with an AD user and then login to the virtual desktop with another AD user. The AD user which the profile is created for or mounted afterwards is actually the user that logged in into Frame launchpad. Now in this scenario , say I login with Frame4 to my launchpad then when presented with the Windows login screen I login with Frame2, the profile wont load since it was created by Frame4 and the volume group attached is the one for Frame4, yet if the user has admin credentials, they can load the attached virtual disk which has the profile of the other user. When SSO is supported, this wont matter, but for now, I believe that they should change the design so that the volume group is attached on Windows sign-in rather than Launchpad sign-in.
The other minor thing is that the profile volume groups naming is senseless and so is the machine provisioning naming as well. At least, the naming for the virtual desktop published sandbox should be set from the portal which is technically possible since machines are being syspreped in the backend I assume, and more importantly, the profile containers should be names by the SID of the AD user in order to be identifiable for backup/restore later or other operational tasks and if possible the username like FSLogix does it for example. Also enabling/disabling the profiles feature should be available for specific users/groups rather than the entire account.
Last but not least, there needs to be more user control from the Frame account management portal such as logoff a user rather than terminate a machine and maybe shadow a user using remote assistance and so on. Naming schema and simple operational tasks as easy as they sound are mandatory for enterprise organizations.
Conclusion
I really liked the speed and stability of the offered profile containers with Xi Frame and with a little bit of customization work, I believe this can go a long way in enhancing end user experience for AHV based VDI users. I have three more posts in mind one for sizing , one for remote connectivity, and most importantly performance benchmarking.
Part 1: Nutanix Xi Frame On-Prem AHV: What Does it Mean to Citrix, VMware and The EUC Community !
Part 2: Deploy & Configure Xi Frame VDI on On-Premises AHV
Part 3: Enhance Nutanix Xi Frame User Experience Domain Settings Optimization On-premises AHV
Part 4: Configure Nutanix Xi Frame Enterprise Profiles For VDI On AHV
Part 5: Configure Nutanix Xi Frame Streaming Gateway Appliance for AHV VDI