Any words of advice/caution etc? Did my POC with 2.9.6 but read about 4. Please share your thoughts. Do not care about retaining old layers etc.. Will recreate.
The major difference between 2.x and 4.x right now is who provisions your machines. Unidesk 2 and 3 provision machines directly: we're responsible for creating and deleting the desktop and session host machines ourselves. In V4, we'll make images for other provisioning systems like PVS, MCS, or View Composer. So if you have a provisioning system you use or want to use, V4 is the right way to go. But if you want or need Unidesk to actually create and manage your VMs, stay with 2.x. The current version of 2.x is 2.10.
If you do want to use 4.x, you will need to make all new layers for it. But V2 and V4 coexist perfectly well, so you can absolutely have them deployed in parallel for testing and evaluation.
That is great to know about having them co-exist. I will be doing that today. We currently have Vmware Horizon and it was greatly crippled when using 2.9.6 as the only thing I needed to do it in was assign rights to pools. So what your saying is in 4.0 I am back to Horizon managing the desktops.
Yes. We'll use layers to build all the base images you need, and you can assign them to Automatic pools for Composer to thin-clone them out. And with V4 you also get access to the Elastic Layring feature that allows layers to be attached on the fly based on the specific AD user logging in.
... and you lose all user personalisation... so you need a different solution to keep user settings if using linked clone pools.
in my opinion v4 is not ready for vmware view until there is something done to address user personalisation
Thanks Andrew, I wasn't aware it was released yet.
The release notes say user layer is "ready for testing". Does that mean it is not intended for production yet?
We just became Unidesk customers (to find out a week later that we are now Citrix customers, when it took as some time to get rid of Citrix and put in VMware :)), but that's besides the point. We were told that 2.x is all that can support user profiles.
We are in pilot phase and about to begin deployment. Should we be looking at 4.x again now that user layer functionality is in?
The user persistence in V2 is still a bit more robust than what is in V4. In V4, we have user-specific VHDs that are added only at login time, which means that there are things that it might capture but won't be part of Windows early enough. Many startup services can't really be layered in this way, for instance. The V2 user persistence covers the entire machine from startup to shutdown. It will be better about handling all user-installed software and non-user-specific settings you want to make. V4 User Layers do cover an awful lot of cases, though. The difference is in the timing.
But really I still think it all comes down to whether you want Unidesk to actually create your VMs or if you have another provisioning system you prefer.
Interesting choice to use VHD instead of VMDK for VMware... I guess something that can apply to all hypervisors.
Is there any documentation that talks about where the VHD lives and performance difference between 2.x personalisation layer and 4.x user layer?
eg if VHD was on a file share then performance will be much slower than a VMDK attached to the machine. And a whole lot of other limitations and reliability issues with VHD on file shares. (been through that already with another product)
We don't use user-insalled apps. Only need user state persistence functionality. Does that mean 4.x should take care of that reliably?
The VHDs are indeed mounted from a file share, specifically for portability. A VMDK is only accessible from a machine on a host with access to the datastore, but a VHD on a file share is accessible from any authorized Windows machine on the network. I don't believe there is any performance comparison document anywhere, but for boring user desktops, I wouldn't particularly expect a measurable difference.
V4 should work fine for you. V4 also completely, peacefully coexists with V2, so there's no real reason you have to choose between them. You can't share layers between them, but you can absolutely run them side by side.
Stuff like this really gets me confused as I read about Unidesk 4. As a Unidesk 2 customer, I don't quite grasp which features I'd be giving up and gaining by going to v4 in Vsphere. I watched the video https://www.youtube.com/watch?v=PDAAVBRTlIk but it made no mention of personalization layers. Unless I just can't find it, it seems to me that Unidesk should build a comprehensive overview for use 2.x VSphere users to better understand what we'd be getting into.
There are many advantages to the 4.x architecture over 2.x you certainly should get those from out marketing but a higlight would be:
Highly Available Desktops due to the Non Persistent model that allows a user to use any of many desktops
Simplified DR becasue the layers are stored either within a single appliance that can be backed up and replicated as a normal VM or on an SMB share that can be copied or replicated at a SAN level.
Dynamic App Deployment based on AD Group Membership
Layerd Image Management which provides the ability to manage applications and the operating system as layers but publishe then as layered images to be used in the provisioning system of your choice. These images take full advantage of the driverstore merge and fusion key merge tech we created in 2.x.
Support for most hypervisors, Microsoft Azure and in the future Citrix cloud and other cloud providors either integrated wiht those hypervisors and cloud providers or in a hybrid mode all from one apppliance. Our new connector architecture allows you to support as many vCenters, XenCenters whatever as you want all from a single appliance.
We do not yet have the user writable elastic (dynamic) layer. It is in Unidesk Labs (beta) for Win7X64 and coming soon for Win7X32 and Win10X64. After those are available we will be adding the ability to use a User Writable layer on Session Hosts.
Now what you will lose:
First due to changes in the way we create layers there is no migration path at all from earlier versions.
Also since the user writable layer is mounted to the desktop at logon, you cannnot have user installed applications that include kernel drivers or other hooks into the boot process. This of course was different in 2.x where the writable layer wnet wiht the desktop and it was there at boot.
Hope this helps.
"Also since the user writable layer is mounted to the desktop at logon, you cannnot have user installed applications that include kernel drivers or other hooks into the boot process. This of course was different in 2.x where the writable layer wnet wiht the desktop and it was there at boot."