App Management Roundup #3: Catching up on Unidesk's App Management, layering, and Azure products

"The year of application management" continues, and this article is part of a series profiling Application Management products.

“The year of application management” continues, and this article is part of a series profiling Application Management products. It's a really hot space that is shifting the way we think about managing apps away from the classic methods like SCCM and App-V to more modern approaches that make installing and provisioning apps easier across multiple platforms. There are a number of companies involved (those with links are ones that we've covered as part of this series), and today we're focusing on Unidesk.

Last week I had a call with an old friend, Unidesk’s Ron Oglesby, to talk about how Unidesk fits into the discussion around modern application management. We’ve been adding them to the list of other products as we’ve profiled each one over the past few months, but Unidesk is different. Though the end result is the same (managing applications without SCCM, App-V or baking them into the base image), Unidesk does it as part of their overall layering solution, so I want to begin there.

Unidesk is the reason I hesitate to call these new ways of managing applications “Application Layering” like so many others. Call it a soapbox issue if you want, but “Layering” conveys that we’re using the layer cake approach to assembling Windows desktops, and what AppVolumes, Ceedo, CloudHouse, FSLogix, Liquidware, and others are doing is certainly not assembling a desktop from a number of layers. Each has a different approach, but none of them are what I would call layering.

I will admit to using “Application Layering” in the past just to test it out. It feels dirty. It’s not as bad as saying “on premise,” because even typing that right here makes my skin crawl, but it’s close. I’m going with Application Management from here on out.

We’ve written about Unidesk’s layering platform in greater detail recently, talking about how they’ve added a platform interface module that allows them to branch out from vSphere. They added Hyper-V support afterwards, and they now have two Azure-based offerings: an Azure IaaS-based solution that’s available today and an Azure RemoteApp-based solution that’s coming in the next month or so.

The Azure IaaS-based product takes the Unidesk layering model and applies it directly to Azure virtual machines. That means you can assemble an OS layer, app layers, user personalization layers, and so on in Azure the same way that you’d do it on premises. 

The Azure RemoteApp-based product is a little more limited based on how Azure RemoteApp works. You’ll recall there are two ways to use Azure RemoteApp: cloud-only and hybrid. The cloud-only model leverages servers that Microsoft creates, manages, and updates. They own the entire stack, and your users have to work within that without third party applications. Hybrid, on the other hand, is a virtual machine that you assemble offline, then upload into Azure. Microsoft then takes care of scaling it up or down to meet demand, but you’re responsible for updates. Unidesk has built something to help with that.

With Unidesk’s Azure RemoteApp solution, you can use your on premises Unidesk environment to build RDSH virtual machines from layers, package them as a VHD, and upload them to Azure RemoteApp. It means that you get to keep using the same workflow to build your on premises and cloud RDSH servers.

On to the applications

When it comes to applications, Unidesk’s approach is to create layers for each application, then add them together with the other layers at boot. Their approach allows you to put a single application into a layer rather than bundling certain applications that depend on each other together. For example, in other products like AppVolumes (not trying to pick on them, but it’s a good example), you can’t install Office in one stack and Visio in another and expect them to work together (a process called cross-layer merging). You end up having to create one stack with just Office for users that only need Office, then another stack with Office + Visio for users that need both, then one with Office + Project for users that need that set of apps, then one with Office + Visio + Project for those users that are absolutely addicted to flow and Gantt charts. 

Unidesk’s approach to layering applications together can determine the dependencies of each application layer to ensure that they play well together. Sometimes this happens in realtime as the layers are assembled into a VM. Other times this happens in an out-of-band capacity as the applications are being packaged. In that scenario, the packager is aware of the other application layers that have already been created, and if the application you’re packaging has a dependency in a layer that already exists, it can mount that layer during installation. The packager also watches what is being installed, so if it sees something like a filter driver or lower-level service (like a VDA) that needs to be present at boot, it can redirect them from the application layer to the appropriate lower-level layer.

It’s all very sophisticated, and it has to be because layering is really complex. If you talk to Ron, you’ll get a good idea of the complexity and the level of effort it’s taken them to put together such a complete package. In spite of that, there’s one specific drawback: it only works on virtual machines.

I was pretty sure I’d get laughed off the phone call, but I summoned up the courage to ask him about any plans to work out some sort of physical desktop solution. I was surprised when Ron told me they hadn’t ruled out physical as a possibility. 

Currently, the only thing even close to layering on physical PCs is VMware Mirage, which they acquired from Wanova. Ron rather famously wrote an article about how Mirage is not layering, so if Unidesk is thinking about it, it probably won’t be like anything we’ve seen before.

I’m always impressed with Unidesk, so I’m looking forward to seeing what’s next. In Q4, Unidesk is going to release their 4.0 product, about which they’ve yet to share anything publicly. The only thing I’ve seen so far about it is this tweet from Shane Kleinert:

So…I guess get ready for a bombshell announcement sometime before the end of the year! I can’t wait to see it.

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

@Gabe Let me correct a misunderstanding. App Volumes doesn't limit you, multiple office apps in multiple AppStacks are supported. However it's simpler to have bundles when you use multiple versions/editions since Microsoft has strict support restrictions on version and edition coexistence. For example, many customers use Office 2013 plus Visio 2010. In this case, Visio should be installed before Office and with separate layers you can do this in simple static environments. However, App Volumes does dynamic application delivery based on users, groups, computers and OUs assignments and AppStacks may arrive in a wrong order. Another example – migration from traditional Office deployments to Office365 where Microsoft simply doesn’t allow you to have different versions on the same computer, no matter which installation/layering order you use. Office is a complex product and there are different considerations when designing a solution that does not require you to control the full VM and replace all your existing management investments. I don't believe the majority of customers will choose that path as it's too complex and expensive. Becomes abundantly clear as your scale up to enterprise customers. SMBs are less concerned since many of them don't manage much today, so a very limited market there. In my experience even SMBs prefer things that are a simple path towards better management vs. a silver bullet layers will solve the world approach that marries you to one approach. As those companies grow, they hit the same set of limitations that bigger customers see.

App Volumes is fundamentally a different architectural approach, and I agree with the sentiment that layers is a terribly confusing term for people that does not describe the use cases customers are trying to solve for. App Volumes does not require full VM control and lives with your existing infrastructure investments such as SCCM. As a result of our architecture, it enables us to address cross platform physical and virtual use cases at scale, avoiding problems like IO overhead in the data center to re-compose VMs to make changes. When it comes to cloud architectures, our belief is that full VM control is also a flawed approach, because cloud providers will only let you do so much to the underlying infrastructure. It's very easy to simply put a VM in Azure and say, hey look we control the VM to a point and can do X,Y,Z. App Volumes will work with VMFork and why it will also work with cloud providers starting with vCloud Air, physical environments (more details coming soon) and will be integrated uniquely with AirWatch to enable customers to manage applications in the existing domain joined world and EMM managed world when we release project A^2.

WRT to the Mirage. I am wiling to bet a cup of tea that Mirage alone as a product that gets ltd attention achieves more revenue than Unidesk does annually, because it solves problems for distributed physical management and also works along side SCCM. Hence why we will continue to offer Mirage and continue to invest in physical management on multiple fronts. Happy to discuss further, but wanted to clarify the misunderstanding.


I guess you could blame the Office stuff on Microsoft since it's their license file that prevents the cross-layer merging, but Unidesk has addressed that, and AppVolumes has not:

And there is this article that shows what I was describing above.

I didn't go into detail because I didn't want to pick on anything in particular. Rather, I was just trying to illustrate that Unidesk has a way to merge layers that have the same dependencies.


Layering etc. came about to optimize the cost of storage. But that is less of an issue now with HCI and Flash. It can simplify desktop management both for virtual and physical desktops.

Shouldn't a desktop admin be able to use their SCCM tool and install an app "layer" onto either a physical or a virtual desktop? Just like they do with MSIs today?

One app per layer sounds really good in theory. But in practice, there will still be some runtime interactions between apps that wouldn't get resolved correctly. I would prefer to create "packages" for users where I would be able to verify that the apps work in each package work as advertised.


@gabe Short answer is it's a solved problem without requiring full VM control and various use cases get fed into subsequent releases based on customer asks, bugs etc. I.E AV 2.9 today supports multiple Office 2013 SKUs in different AppStacks. The links you are looking at have dated information, but that's always a fun race between engineering and others. :-)


The office license file stuff is an example of conflicts cross layers that can show up in any layering tech by default if you dont handle it in the code. This is because the file (by default without some magic) will exist in multiple layers but only contain the entries for a single office app (office, visio, project, etc). This is actually pretty simple to solve with layer dependencies during layer creation. But its just one example of cross layer merging complexity that everyone in layering has to deal with. Some other common examples of layer complexity that needs to be handled:

Office Plugins in one layer (writable user layer or app layer) and Office in another

.NET applications that run NGEN in the background and create indexes and fusion keys in the registry in separate layers

Application prerequisites, where the install of the app requires other apps (from a different layer) just to install

Apps that touch/modify the Windows driver store.

Applications that modify existing registry keys or even add to things like existing string values in the registry (now you need to merge logically at the individual key level).

So, there is a ton of fun to be had in cross layer merge and conflict resolution. And that is just one facet of getting layers to work right. And the more apps you have the more likely you are to see the need for robust cross layer logic/conflict resolution.

As for the "atomic bomb" Shane mentioned... we do have some cool changes coming technology wise. Not sure its an atomic bomb, but we are proud of a bunch of new features coming out over the next six months and we'll be talking about some of them soon. You'll hear about it here I am sure.