What is app virtualization? Part 4: Cloaking

In today's article, we're going to cover the technology called "cloaking."

This article is Part 4 in a series about app virtualization. The other parts are:

In today’s article, we’re going to cover the technology called “cloaking."

Cloaking is a relatively new term in the app virtualization world, but it’s something that has gained traction in the past few years. Quite simply, “cloaking” is a technique where you use the same app virtualization and layering technologies we’ve been talking about previously in this series to make an app “disappear” and “appear” instantly.

Let’s dig in.

In past articles, we talked about how local app virtualization technology works. In those cases there’s an app virtualization software agent on a Windows computer which “tricks” Windows into thinking that an application's files and registry keys are installed in their regular locations, but in reality they’re stored in some other secret location controlled by the app virtualization agent. We talked about how local app virtualization and layering make it easy for IT admins to install and remove applications, and how it’s possible to isolate those applications from each other so incompatible applications can happily run side-by-side.

That said, our past conversations focused on using app virtualization and layering to “install” applications. In other words, even though you have the app virtualization trickery in place, you pretty much just use it to install the virtualized apps into each user’s Windows OS, and then from there on out the users would have those apps installed (albeit in a virtual way).

But if you think about how the app virtualization software works, you can imagine that it’s possible to “turn off” the app virtualization agent. If you did that, the app would essentially disappear, right? This happens because Windows doesn’t know that an app is virtualized—it’s relying on the app virtualization agent to intercept the Windows call to the file or registry key in the location that Windows thinks it’s in, and then the app virtualization agent steps in and makes the original file or registry key available from the secret virtualized location.

So by extending that logic, if the app virtualization agent were to shut down, then it wouldn’t be there to trick Windows into thinking the files were there, and essentially it would be like the app just disappeared. So if you had a virtualized copy of Microsoft Office on your computer, you’d see the icons in the Start Menu and Word and Excel in your Program Files folder, but if you turned off the app virtualization, those files would be appear to be gone.

What’s *really* cool is that you can also flip this concept around. Imagine that you installed an app via app virtualization so the app’s actual files and registry keys are not in their normal locations but are instead in the app virtualization’s own private location. But now imagine if you don’t actually turn on the app virtualization software. What happens? The files and registry keys are on the computer, but they’re sort of locked away and it appears like the app is not installed.

Then in order to “install” the app, all you have to do is turn on the app virtualization software, and BOOM! That app is instantly there. It would appear to the user like the app was just installed, but it only took like one second because the files were already there. :)

This is exactly what “cloaking” is. Like the layering we discussed in Part 3, cloaking uses the exact same local app virtualization technologies we’ve been talking about since Part 2. The only thing special about cloaking is that instead of having to “turn on” or “turn off” your entire app virtualization software, the software is designed so that it can turn on and off individual applications (So that’s where the “cloaking” name comes from. The apps are there, but can be hidden.)


So cloaking is cool and all, but why would anyone use it?

Lots of reasons.

First, like local app virtualization and layering, cloaking solutions can work with traditional physical Windows desktops and laptops. They are not just for VDI (though lots of people use them in concert with VDI.)

So one use of cloaking is that you can build a single base Windows image that actually has *all* your apps in it. I mean literally hundreds of apps. Then you can use that single base image for all your users. Then depending on the rights of the user when they log in, the cloaking software will automatically hide and un-hide the right combination of apps the user needs. So from the user’s standpoint, it just looks like they have the 15 apps they need and they don’t even know there are another 250 apps hidden deep inside the system somewhere.

Again, this also works for physical desktops and laptops. A typical laptop today has, what, at 500GB hard drive? So imagine if you used cloaking software to literally install every single corporate application any user would need across your entire company. In today’s world that might be 200GB worth of apps, but that would still leave 300GB of free space for the user.

Anyway, so if every user in your company secretly has every app on their laptop, now imagine what happens when you have a user who needs access to a new application? Instead of having to figure out a way to copy and distribute the files for that app to that user, all you have to do is give them permission to use that app, and the app cloaking agent on their laptop just goes “bink!” and then the app is there. Done. Takes 2 seconds.

This means that you only have to manage a single image for all your users, regardless of what apps they actually need because all the apps are on all the laptops all the time.

You can also use cloaking when you deploy new versions of apps. You can get all the apps deployed in the background, hidden from users, and then on your “go live” date you can flip the switch and the app cloaking agent on all your computers will turn off the old version of the app and turn on the new version. And if you later find out that there’s some kind of problem with the new app, you can push one button and instantly switch everyone to the old app.

Modern cloaking tools are compliant with application licensing too. Today’s software vendors license their apps based on them being installed, but an app that is cloaked is not actually installed since Windows and the user can’t see it. So you could, for example, use cloaking software to automatically turn off apps after the user hasn’t used them for 90 days, or you can integrate the cloaking software with your software asset management system so that you only actually pay for the licenses of the apps that are uncloaked and available for users to use.

Not just for physical

Cloaking solutions also work well for RDSH and VDI environments. In those cases you can build a single master image with all your apps installed and use the cloaking to just enable the specific apps each user needs in their own environment. In virtual environments all the storage is virtualized anyway, so having a 200GB base image doesn’t even matter. And it’s nice because you only have to manage one single image for everyone.

The key with cloaking, as mentioned earlier, is that it’s using the exact same app virtualization technologies as local app virtualization and layering. The only difference is really in how the products are sold and how they’re designed to hide and unhide applications dynamically. (And more and more, we’re seeing app virtualization vendors offer a combination of technologies and techniques that you can combine for your own perfect situation—something we’ll cover more in a future article.)

Join the conversation

1 comment

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

Of course Cloaking or App hiding has its place... Though your example simplifies it somewhat as to get to that single image you have to make the assumption that the hypothetical 200GB of apps all work fine together/installed on the same machine (or close enough) but it also ignores that once the image is down (thinking laptops) that you also need an image (or a variation) for each type of laptop/set of drivers.

Finally. you must remember that while functional, it will require that in the described hypothetical above, every update, to every app, must go out to every machine. Tricky when you build in an assumed failure rate of some percentage.

All of that said, its an interesting tactical tool I find as probably best targeted in virtual workloads vs physical machines, where shared image models are the norm.