Came across this the other day – Ericom is providing a free Beta of its HTML5 Client for VMware View.

HTML5 technology represents a new frontier in interactive browser-based applications and user experience. It’s the first VDI solution to provide native support for Chrome, safari and other browsers using WebSockets and http protocols.

Leveraging this innovative technology and integrated RDP compression and acceleration technology, Ericom’s high performance HTML5 client enables enterprises to provide users seamless access to VMware View virtual desktops – running wholly within the browser – from any HTML5-compatible web browser, such as Firefox, Google Chrome and Safari.

Although RDP-based, this technology is very interesting and key to a device-agnostic application delivery services model. Sign up for the beta if you get a moment and let us know of your results -

Being able to deliver applications and information seamlessly to any device is a huge organizational need – which shifts the “Why can’t I run these apps on my devices” conversation from an accusational criticism of the IT Group to a dialog about the pure usability of the device itself.

Enjoy -

Was posed a typical problem a few weeks back.  There was an application in our customers business that was updated quite frequently and the application required these updates to launch.  The problem was, the users were using the application through a terminal server on Thin Clients and XenApp published applications.  The application needed the users to be local administrators on the server in order to complete the update.  In this instance the application was a custom application from Sara Lee for transferring files, not much use for anyone else as an application… but the principal and application of ThinApp is widespread to many apps that have this issue.

Solution: The ThinApp sandbox.  Packaging the applications and linking the dependencies via AppLink, we were able to deploy the application fully isolated from the terminal server.  This allowed the application to use the sandbox location (the users profile in this instance) to install and run the updates therefore bypassing the security need.  The application was able to update and run as normal as a ThinApp. 

The deeper I dive with application virtualization and delivery, the more uses (and less problems) I find.  Now if only EVERY application was isolated and virtualized that would be an admins dream.  1 more down… looking forward to the next challenge.

First off, I love a good application virtualization challenge.  This one provided exactly that, there was a lot of packaging, repackaging, adjusting and comparing along the way but in the end we ended up with a virtualized application that performed fast and 100% of the time.

The use case:  Our customer needed a way to deliver the Nexterna Clearview Client to users with Internet Explorer 6 as the compatible browser.  Due to a recent SharePoint 2010 project, the Citrix servers needed to be Internet Explorer 7 or 8.  Easy answer, virtualize IE6 with ThinApp and run it side by side on the same server with IE8.  Utilize ThinDirect to send all users accessing the Clearview web application and associated client install to the virtualized IE6 and leave all other traffic for IE8 to provide.

The application must run on a 32bit W2K3 operating sytem and SOAP 3.0 and MDAC 2.8 are dependencies.  We started off packaging the application on a clean XP virtual machine.  Success! (or so we thought) The application built and ran when performing testing in the Dirty, Washed and Clean (see @ThinAppGuru Travis Sales ThinApp Methodology) states.  When moved over to the Windows 2003 server we found that the ActiveX controls failed to load properly and Clearview uses ActiveX controls for all of it’s operations besides the main menu.  To clarify, the ActiveX controls seemed to load but they failed to display, no errors.

So we dug in, and by we I mean we.  We started examining the package and ensuring all the DLLs and OCX files were picked up and registered correctly by the packager.  Everything looked good.  Still worked on the XP machine (even on the Clean snapshot) so we were confidant that everything on the XP build was being packaged properly.

After working for several hours with Travis Sales at VMWare and trying several different sandbox configurations, browser settings, etc… we decided to try a different packaging environment.  Went with a W2K3 SP2 build.  Again, the packaging process went off without a hitch.  However, this time it worked on all platforms and we finally had a successful ThinApp package.

After doing using Beyond Compare to compare the XP capture vs. the W2K3 capture we noticed several small differences that could not be explained away easily.  Several CLSID objects in the HKLM registry directly related to the OCX files that did not appear in the XP package and a few different file sizes of core DLLs that could explain the difference in operation.  The general thought is that the Nexterna Clearview Client is at some level OS aware of what environment it is being installed to and the installer leaves out critical files/registry entries needed for server operation of the virtualized environment when being packaged in a XP environment.  We are still pursuing the loose ends but it was a good case of how utilizing a good packaging methodology can help isolate unknowns and allow you to make assumptions and test those assumptions while moving towards a successful ThinApp package.

Til the next app…

Something a co-worker asked me made me think about a way to store, backup and deliver ThinApp applications over the web from anywhere with as little jumping through hoops as possible.  While this is by no means a go-to market solution (VMWare View using PCOIP would be much better suited for that) or even a complete thought I was thinking what if we uploaded ThinApp applications to a SharePoint 2010 document library?  How would they be accessed?  Could we use it as the file share for our View/XenApp repository?  What benefits would it provide?

So I gave it a shot.  The answer is still being tested but the initial results seem promising.  By using the UNC path ability of a SharePoint doc library you can point View/XenApp to this repository by utilizing \sharepointaddress.domainname.comsitedoclibraryaddress”, you can also do this from anywhere on your network (as UNC implies) and over the internet if your SharePoint 2010 solution is internet facing to access the ThinApp applications from anywhere (given the right credentials of course).

But this also had some decent side effects, you could use the power of the SharePoint document library to add descriptive data to each ThinApp application.  Such as last modified date, who packaged it, who owns it, license information, notes on the packaege, supported operating systems, etc…  Users could download the packages themselves from the library (again, credentials) and run them locally if desired.  You could configure alerts, workflows, all that fancy management stuff that makes SharePoint a great business tool to help IT manage the packaged applications.

Then there is the backups, a few lines in a scheduled PowerShell script and you have complete backups of your entire SharePoint farm including content in doc libraries.  Making backup management and restoring simple and more reliable.

Leave your thoughts below if you can come up with any more uses… more to come.

In Part 3 of the applications in the cloud segement (You can read Part 1 and Part 2 here) were going to switch the focus from the end user (sort of) to the administrator/developer/datacenter and talk about Virtual Appliances and how they can be utilized to increase the availibility, performance and overall cost of ownership for client server applications in the datacenter.  By using Virtual Appliances and applying the principals of “Just Enough OS” (JEOS, horrible acronym) virtual appliances can be like ThinApp for the datacenter.  Allowing your applications to be abstracted from the bare metal of the systems that is running them, providing portability, security and performance to make operate effectively in the cloud. Read more >>

Following the similar trend of what is cloud computing and how will applications get there from my previous post, here is part 2 of the applications series.  Datacenters, private clouds, public clouds and personal computers are all designed for one thing.  Servicing users with applications.  During VMWare President and CEO, Paul Maritz’s keynote address he made one excellent observation about applications today and where they are going to need to go in the future.  Applications today are relatively unmovable (or at least costly to move) and are targeted at a specific audience (devices) in the business environment.  However, the end user more frequently than ever is bringing a myriad of devices into the workplace along with the company issued devices (IPads, Macs, Droids, etc…) and wanting access to these business critical applications on these devices.  In order to do this developers and applications managers must shift their thinking and begin developing and adapting applications that are independent of the systems they run on.  Whether it be a web application, lob application, etc… (more on these in part 3… Virtual Appliances) these applications must be portable in and out of the cloud or between the devices (servers/hosts in this instance) that make up this cloud.  These applications must be manageable in a package/manage once, deploy everywhere, run anywhere type setup.  Most importantly the applications and IT must change from servicing devices to servicing the end user.

Servicing the end user and allowing them (and the market) to dictate what is the most efficient way (device) for them to interact with IT will be the true mountain to climb when moving to a true public cloud architecture.

This is where ThinApp 4.6 and project “Horizon” make great strides. Read more >>

In Part One of the VMWare ThinApp AppLink Series we talked about how to package dependant packages in a seperate package than the main virtualized application using VMWare’s ThinApp.  In Part Two we will continue with that process by explaining how to tie all thos packages together and discussing the benefits of seperating your packages. Read more >>