By Max Ranzau
From the Skunkworks Dept. This is an article I’ve been looking forward to writing for a while. I had the opportunity to look at AppVolumes when it was still pre-VMware Cloudvolumes, but as you know – timing is everything, so I decided to hang back until VMware released AppVolumes today! In this article I will share some thoughts on how the AppVolumes product can be augmented by RES technology to offer some very interesting options for integrators.
AppVolumes – 7 steps towards understanding:
So, what’s all the fuss about then? Easy. AppVolumes effectively eliminates golden image management, by letting you to seamlessly attach applications to the image, no installation required. You’ll need vCenter and ESX to use it. If you are familiar with AppV it’s easy to understand the concept, however there some differences between AppVolumes and AppV. Here are the ground rules in rapid fire succession:
- There is no spoon and there is no bubble. This is essentially layering/shim technology and not application isolation/virtualization. AppVolumes alone is not going to help you solve application conflicts, multiple co-existing Java versions and such.
- On the plus side, there is no network streaming involved either delivering an AppVolume When an AppVolume is attached, it’s happening in the virtual disk system, making the distribution nearly instantaneous.
- As far as limits goes, it is currently recommended to attach no more than 10-20 volumes to a client. ThThe max. size of an AppVolume is around 20GB and you can have multiple apps per AppVolume.
- Creating an AppVolume is relatively easy. Without going overboard in details, it involves spinning up an empty target workload, installing the apps(s) you want and then AppVolumes taking care of the rest.
- Architecture-wise AppVolumes is relatively simple; you have a management server, that serves up a web-based console and an agent which is installed into the golden image. You can also deploy it on the fly later if you are supporting multiple images.
- Attaching a volume is done via mentioned console, you can specify either AD users, groups or an OU for a given AppVolume. Once you do, the apps in the AppVolume appear in the Program & Features control panel, in the filesystem and HKLM etc.
- When you dismount an appvolume all non-user specific data will be removed, being data in %programfiles*% and HKLM. However anything the application deposits within the user’s profile will be left behind.
While AppVolumes on it’s own presents a most interesting way of managing changes in a VDI environment, the limitations above are fairly obvious – especially in the last step. Let’s look at the challenges one at a time here:
- Unless you limit yourself to one app per volume, there isn’t really a granular method for controlling access to the individual AppVolume-delivered applications. Since there is a rather low limit to AppVolume attachments, one app per volume really isn’t a viable option option in most scenarios.
- Presuming you are supporting non-persistent workloads, where you want your user settings to survive, you’ll need something to pick up the changes.
- Due to mentioned limitation on mounted volumes, you’ll need to decide on a way to organize the contents of said volumes, in other words what apps go together into which volumes. Since there’s no application isolation. I imagine one interesting method to deal with potential app conflicts would be to wrap difficult applications within a ThinApp virtualization wrapper, again stored inside the AppVolume, thereby having application isolation within the environment. Someone will have to test this and let me know if it works. Presuming it does, you could in theory keep your master image very lean and load up the apps in one big honking AppVolume, with all the apps under the sun you’ll ever need. However, this won’t solve access restriction to the individual apps and also you got to think about what needs to happen when an app inside a volume needs to be updated.
There are several ways to skin the cat, as to how you divide up your apps across AppVolumes. Above in item #3, we discussed one potential deployment AppVolume strategy; using one big volume for all your apps. This may perhaps not be the best approach if you have apps in the mix that are often updated (Yes, Firefox, I’m looking at you…) You might be better off putting these types of apps in a separate volume. Another scenario may force you to spread your apps across multiple volumes if the 20GB size limit is of any concern. Finally another conceivable strategy could be to lump often-used-together-apps into the same AppVolumes. For example; make an AppVolume out of all the Adobe Apps. Remember you don’t have to do this as this for the purpose of security segregation: This isn’t MS-AppV bubbles: All AppVolumes apps can talk together across volumes like normal locally installed apps.
What should not be a concern, is access and security around the available apps. That’s something we can do something about! However, let’s be careful out there: Like some people maintain multiple golden master images for the sole purpose of security segregating usage groups, I’m sure there will be some who would be applying the same mode of thought to AppVolumes. This is not necessary. Allow me to explain why:
How RES technology fits into the picture
A bit of background: Years before images, VDI and such came around, RES Workspace Manager (or PowerFuse back then) already had the ability to cover up the presence of any and all applications on a given computer, either locally installed or virtual. The only apps the user would see, would be what they had been given access to. By today’s standard, even that is considered fairly static, as you may need to offer up certain apps as self-service with optional time limitations and/or approval workflows. We will discuss these scenarios further below.
Limiting Access: In short, you can have 300 apps installed on a computer, but suppose Max Generic User logs in, and I only have access to, say Word and Excel, then that’s all I’m ever going to see and able to access under any circumstances. With the start menu (yes, it’s coming back in Windows 10) locked down and managed, drives hidden and the Workspace Manager security subsystems enabled, then for all intents and purposes the apps WILL NOT be available. This is also important for licensing purposes. If I try to get cute and write a macro in Excel to launch an app that I somehow figured out is underneath the RES abstraction layer, all I’ll accomplish is receiving a message that I’m not allowed to do that, and attract the attention of the administrative staff as a log-entry and perhaps even a real-time alert will be issued immediately upon the execution of my high crime.
User specific configuration on app launch: Using Workspace Manager’s native functionality of simply managing the shortcuts and the security around the workspace as described above, takes care of the first challenge. This has already been tried and tested in the RESguru Skunkworks lab and I can report it works nicely. Add in the ability to configure AppVolume-delivered apps upon launch, makes the packaging process a breeze. Back in the dark ages one had during MSI packaging to worry about Active Setup, but with Workspace Manager in the mix, all you really have to do is next-next-finish package your app, regardless of the deployment method, being regular MSI, ThinApp, or AppVolumes. Draw a line between deployment and user configuration, leaving the configuration to the live Workspace – simplifying the AppVolume packaging process – is the overall takeaway here.
AppVolumes Agent deployment and population: As it stands today, you’re supposed to configure all volume access via the AppVolume web console, but just as we learned about the old SoftGrid client (remember the file:// .osd trick?), there’s usually always a way to load up the agent directly without the involvement of a server and AppVolumes is not an exception. The AppVolumes agent can manually load up a volume by running C:\Program Files (x86)\CloudVolumes\Agent\svservice.exe attach <volumename>. Another thing you can do (that is, if you’re going to use the management server) is deploy the AppVolumes agent using RES Automation Manager. The parameters you’ll need for the AppVolumesAgent.MSI is MANAGER_ADDR=<fqdn of management server> and MANAGER_PORT=<default is 80>
Offering AppVolumes content as subscribed services: By far, I think this is one of the most interesting avenues of integrating RES and VMware AppVolumes. One thing is the ability of workspace manager to only expose assigned apps, but combining this with self-serviced applications as well as approval workflows is pretty killer. If one already have a client where Cloudvolumes have been deployed and a given volume has been assigned to for example an AD group, I would use RES IT Store to pre-qualify users to the same AD group. There’s several ways to do this, but I’d probably do it this way:
- create a hidden ITS service (not displayed to the users in the store, service panel, etc) which is assigned to the AD group that a given volume is assigned to.
- Using the RES Workspace Manager ITS publishing wizard, I would then create managed apps + services for the individual apps in the volume
- Last, I’d configure a service dependency onto the hidden volume service.
If you remove someone from the AD group assigned to a given AppVolume, or if you remove the group as a whole from an AppVolume, the advantage of this approach is that RES IT Store would be able detect the change and automatically run return workflows in IT Store, thereby proper handling of licensing, de-configuration (remember, removed AppVolume based apps will still leave gunk in your profile), desktop, etc – all in one smooth automatic motion.
Before we wrap up let’s just recap the advantages of combining VMware AppVolumes with the RES Suite:
- Govern access, licensing and security around individual apps made available across multiple volumes
- Configure application on the fly (or rather, at launch) eliminating the need to to worry about user config at packaging time
- Capture the users changes to all apps, regardsless if AppVolumes are dismounted later
- Deploy the AppVolumes agent as well as attaching the volumes themselves using Automation Manager
- Create self service AppVolume based, apps by creating a IT Store service for each application.
- Allow for approval workflows, time-based access, plus auditing of access and usage.
Looking back, it’s been a while since I’ve seen such a great fit between technologies. I believe we are going to see a lot more of RES/VMware combined solutions in the near future.