Today, I want to talk about ProfileDisk and its benefits using FlexDisk or VHD.  ProfileDisk is a new major feature scheduled for ProfileUnity 6.5,  targeted for release in Q1 of 2015.

Before I talk about ProfileDisk, let’s level set about ProfileUnity itself and how it deals with the user profile. Today, ProfileUnity uses its portability engine to backup and restore users’ profiles. This engine is highly optimized to make backup and restore of a user’s profile as fast as possible. This engine archives the profile into smaller parts that also include a checksum so that the solution can sort through what does and does NOT need to be save or restored. Out of the box, ProfileUnity comes with templates that cover 85% of the user profile, Windows settings, application settings, etc. ProfileUnity’s portability engine backups up and restores profile on login, logoff or on triggers for example on PCoIP or ICA disconnect  the users profile can be saved. This approach gives you great control over how much or how little of the profile you want to make portable. But this approach also sometimes requires you to create a portability rule for paths that are not captured out-of-the-box. Customers have told us they want a fully persistent desktop, leveraging non persistent VDI but without having to configure many portability rules.    Essentially, they want a feature that would act as an “easy button” or “catch all” for users’ profiles.

By using our FlexDisk technology, we can use a VMDK for the whole profile creating this “easy button” for the entire user profile. This VMDK can be attached to any View VDI desktop on the fly and detached at logoff, whether persistent or non-persistent. This avoids the need to restore the profile at login, and adds only about 5 seconds of login time for Virtual Center to hot-add the VMDK upon our request. This technology is also created in a way that has the least overhead possible for the users’ profiles. Some application layering products on the market intertwine the user installed applications layer and the user profile layer into a single layer on a VMDK. The negatives for this approach are that the format is not native to Windows but is only are native to the layering product, which is often proprietary. With these products, the profile has a filter driver in-between the users profile and Windows. The issue with a filter driver is always performance.  If your user has a 5 or 10 GB .ost file — how well will it perform? When we attach a VMDK for a user’s profile, we are hands off and DO NOT add this middle filter driver layer.  The profile is 100% native to the OS and is in 100% native format. After all, if you’re trying to have a profile easy button, you should have the lightest touch as possible, a major consideration in complex virtual desktop environments.

While using a VHD, we have also adapted this same technique for a network VHD. We can hold off the login for a total overhead of 2 sec, mount the VHD, and then let Windows continue on its way. This method has the same key advantage as above — no filter driver layer. The first question you might have is — with a “full” profile on a network share — how will it perform?  Well, the answer is that it performs better than you would think, for a few reasons. First, the VHD is a block device.  When you mount a block device, Windows will cache common read requests into memory, which make the profile perform well. Also, from a file server point of view, it’s a LOT less file handles than a folder redirection because you have a single VHD vs the thousands and thousands of files you would have with a folder redirection. This technology supports View RDSH published desktops, XenDesktop, and XenApp Published desktops (basically single session desktops.

Keep in mind a few things about this technology. If you have more than one desktop session or application session, ProfileUnity’s portability engine can be used on top of ProfileDisk or in place of ProfileDisk, so that you can support more than one session. When it comes to DR and using VMDKs for your users’ profiles, it might be easier to use the portability engine to save out the profile from the ProfileDisk VMDK to a CIFS share. Backing up and replicating a CIFS share may be easier then backing up and replicating a VMDK on VMFS volume. The other thing to keep in mind is that ProfileDisk only captures 100% of what is in the user profile, C:users%username% and registry HKCU.  When it comes to applications that write out of these two paths you have a few problems. The first problem is identifying where the application wrote to.  We have a tool called app tracer coming out in ProfileUnity 6.5, that will allow you to open the application and track down the change locations and publish these paths for capture from ProfileUnity’s portability engine. The second problem is users don’t have access to these paths, so we can first, elevate the application to allow it to write outside the profile and second, we can elevate to layback down the settings that are out of the profile path — both of which can be done without the user being an admin.

I hope this helps you to get an idea about what we have coming in Q1 2015 with ProfileUnity 6.5!

ProfileDisk –The Profile Easy Button!