99.9% virtualization with Numecent Cloudpaging and App-V.

You already know that real application virtualization benefits come about not when you’ve virtualized a few applications, but when you’ve converted your whole estate.  While it can be hard work to achieve, if anyone’s told you it’s not possible, they’re wrong.  In this article, I’ll explain how you can use App-V alongside Numecent Cloudpaging to achieve just that, and a little later on, how your users can access all their apps from ONE dashboard.

—

Growing up in Ireland, I learned humility and will likely never rest on my laurels, so the words “career” and “expert” give me the heebie-jeebies! With that said, more than any other product, I feel I’m an expert when it comes to App-V and have had the pleasure of working with it for more than ten years. I first worked with Sofricity’s Softgrid before it became App-V.

Most organizations I’ve spoken to tell me they’d like to virtualize 100% of their apps but end up with about 50-60% sequenced with App-V. Many have also become skeptical of bringing in outside help for an App-V project because they feel that once the project finishes they’ll be left with apps which they can’t remediate or manage themselves due to perceived complexity.

When you get down to the nuts and bolts of it, the reason there is such complexity with remediating and managing apps delivered with App-V is that the apps run isolated. Certain low-level system components, all kernel level drivers and more just won’t work in your App-V apps or with other application virtualization products, for that matter.

Application Isolation is a double edged sword.

It can break your heart knowing certain apps won’t work when isolated and with the complexity isolation adds for managing applications with dependencies. But isolation is still a valuable asset, particularly on Remote Desktop Session Hosts and in a Virtual Desktop Infrastructure.

In recent years, developers have gotten better at ensuring their applications can run successfully side by side. “DLL Hell” isn’t as big of a problem anymore. Odds are you can install all of the applications a user needs on their machine for them, and they will all work just fine. It’s when you get to your session hosts and try to install 50 apps on a box that conflicts start to arise.

In the past, you’d have siloed applications to combat this. Saying “Okay, these two apps don’t work well together, so I’ll ensure they run on different sets of servers,” becomes a costly workaround and introduces management complexity.

With the growing popularity of read-only or non-persistent images with products like Citrix PVS, MCS, VMware Horizon and pretty much all VDI products, isolation provides peace of mind when deploying applications on these types of disposable machines. You can deploy your applications without fear of conflicts alongside other appvirt features like streaming, and you also ensure you can deliver your user’s new applications without needing to get in and update any image or parent VM or even requiring a desktop re-compose which can take some time and cause a user downtime.

In short:

• Isolation sucks because it breaks apps and introduces management complexity.
• Isolation is great because it allows you to run all of your apps across all of your servers – no need to silo. You can reduce the number of install related reboots required, there’s less risk of bad packages breaking machines, and with certain appvirt products you get a dynamic delivery through app streaming.

Limitations of isolation.

The isolation in App-V is very rigid. To ensure something is isolated you include it in your package. If you don’t include it in the package and allow the app to write something on “first-launch,” it will get created on the local machine. There’s very little control without getting deep into scripting. With App-V 5.x, you can use features like RunVirtual to run locally installed applications with visibility of your sequenced applications.

With VMware ThinApp, you have three different isolation options. One which runs the application completely isolated, ensuring it never attempts to write outside of its virtual bubble, and a couple of others which allow the app to write to a sandbox and run with less restrictive isolation. You can also toggle the isolation at a directory level.

Most application virtualization and container products provide a similar level of control as ThinApp. With this level of control, you will still run into plenty of applications that either won’t work as a virtual application, or they require a whole lot effort to get working.

Introducing Numecent Cloudpaging.

This is why I am such a big fan of Numecent Cloudpaging. You can still run your applications isolated, but there is a greater level of granularity and control over how isolated the application’s files, folders (shown in the screenshot below) and registry run than in any other virtualization product.

In my experience, no other product features the layer 1 and layer 2 isolation settings which Cloudpaging has. These layers essentially run the application as though it’s installed on the machine. This is like switching isolation off. This is HUGE!

You can “Cloudify” 99.9% of your applications with Cloudpaging, possibly taking the approach of trying the apps with isolation first then if the app doesn’t work, you can identify which file, registry or directory is having the problem and you can change the isolation setting for that directory.

Failing that you could just change the global isolation setting as shown in the screenshot below to run the entire app without isolation. In most cases, you don’t have to test and tweak isolation settings, the packaging tool runs a quick check and notifies you if it detects something which may require a specific setting. It’s awesome!

The popularity of Application Layering.

VMware App Volumes, Citrix App Layering, and Liquidware FlexApp provide a means to deliver applications with a very high rate of compatibility too. Layering doesn’t run the applications isolated in the same way as appvirt and containers.

Personally, I don’t put my applications in layers as a first choice. I prefer to only layer applications which:

• Don’t work virtualized
• Take too much effort to virtualize
• Can be virtualized but aren’t the best candidates for virtualization

I take this approach because we lose the benefits of isolation when using layering. In most cases, layering works together great with virtual applications and containers, so you don’t have to pick one or the other.

In a recent Project VRC survey, most respondents said that they currently don’t deploy virtual apps, containers or layers. Of those who do use one of these technologies, the majority use App-V 4.x or 5.x. I work a lot with App-V too, and have a higher rate of success than most, so most of my apps are already sequenced, tested and deployed with App-V 5.1.

While I’m a big fan of cloudpaging, I’d prefer to not start from scratch and repackage all of my apps. With Software 2’s AppsAnywhere, I don’t have to.

Enter AppsAnywhere.

AppsAnywhere is an incredible product that provides a slick web interface for publishing applications and I haven’t been this excited about a product in a long time. At first glance, you might think “big deal” Citrix XenApp, Horizon Apps and many others allow me to publish apps too. Wait, there’s a difference here!

[x_pullquote cite=”Rory” type=”right”]I haven’t been this excited about a product [AppsAnywhere] in a long time.[/x_pullquote]Software 2 does a great job integrating with RDS for running hosted applications which makes delivering applications in RDS much simpler than using say RDS, App-V, and RemoteApp.

One of my biggest bugbears with RDS is that it becomes difficult to manage at scale because, in my opinion, the Server Manager tools just aren’t fit for purpose. The reason I loved Unidesk 3.x so much was that it allowed me to manage my desktops and apps without ever needing to go into Server Manager or even onto my hosts to manage machines, sessions, and apps.

With AppsAnywhere, you work with a single admin portal and viewing and managing Cloudpaging sessions is made easy.  But as I said earlier, I’ve already sequenced most of my apps, and I don’t want to have to repackage them with Cloudpaging. Now I don’t have to. Using AppsAnywhere, I can publish my App-V applications AND my Numecent Cloudpaging applications together side by side.

In fact, in my environment, I also have Citrix App Layering setup with RDS, Hyper-V, and SCVMM, so I can publish my app layers as RemoteApp applications too. All of my applications are virtualized, and no installs necessary 🙂

Virtualization examples

For my BYOD (Bring Your Own Device) and remote workers, I can also publish apps which are hyperlinks taking them to a download for them to install themselves. I can also deliver mobile or non-Windows apps with a cool contextualized delivery – if a user accesses via a Macbook, they will ONLY see the apps which I’ve made available for Mac users.

Maybe you’ll have a set of apps published which are downloads to a vendors .dmg or .pkg or even to your own custom Mac package hosted on your company FTP. Of course, I can just publish my apps with RemoteApp which Mac users can access. In future, with the recently announced HTML5 client, I can publish with this to my Mac, iPad and mobile users or even to my Chromebook users. When users access on Windows, they get their Cloudpaging apps streamed down to their machine.

This is a very attractive prospect for me for a few reasons. A while ago I had a request to publish a web app in XenApp. “No big deal” I thought until I was told it was for everybody in the organization. We simply didn’t have the capacity to start publishing web apps for everybody in the organization.

With AppsAnywhere, if there are no dependencies, I could just publish as an external website.  If something more is required, I can publish as a direct download and move the load to the user’s machines. For example, when I recently needed to deploy a custom package for a VPN client to home users, this would have been ideal.  Alternatively, for Windows Users, I can publish with a Cloudpaging Delivery Method which will install the Cloudpaging agent as part of the AppsAnywhere client on the user’s machine when they launch the application.

If I can move users off sessions hosts and their virtual desktops, I can reduce our resources and eliminate issues with constraints and cost encountered with running and maintaining the hosts in my data center. Less money spent on hardware, power, labor and licensing.

In my opinion, AppsAnywhere is slicker and much easier to manage than Microsoft’s inTune and VMware’s AirWatch. With the versatility of contextualized delivery and an ever growing list of delivery methods, I am really excited to continue to work with Numecent Cloudpaging, App-V, and AppsAnywhere together to make my life a lot easier.

All of my apps virtualized and a delivery method which reduces my reliance on managing Session Hosts means I have more time to browse the web 🙂 .