Announcing AppV_SelfService (AVSS), a new free tool for simplifying App-V 5 app delivery to VMs

Today we are releasing a new tool called "AppV_SelfService" that (1) simplifies App-V application management, (2) improves the datacenter performance, and (3) is free. (In light of Brian's VDI Paradox, your BS alarm should be going off at full volume right now because he says you always have to pick "2 out of 3.

Today we are releasing a new tool called "AppV_SelfService" that (1) simplifies App-V application management, (2) improves the datacenter performance, and (3) is free. (In light of Brian's VDI Paradox, your BS alarm should be going off at full volume right now because he says you always have to pick "2 out of 3."  But hang in there!) I showed the beta version at BriForum Chicago and Citrix Synergy in Anaheim.

AppV_SelfService is an alternative way to distribute App-V 5 virtual applications. Why? Because the way you deliver virtual applications for consumption inside a datacenter shouldn't be the way that you deliver them to the rest of the enterprise. When delivering the apps outside the data center, or even inside the datacenter to machines with local storage, streaming and local caching are critical features for performance and user experience. It turns out not to be so important on VMs.

 image depicting datacenter tiers

In these environments, we want to optimize on the amount of storage needed and IOPS. We use new features of App-V 5 to optimize on both of those desires, and by adding a small (as little as 56kb) agent to the client system we can eliminate the back end infrastructure typically used to deliver virtual apps, simplify the steps required to deploy new apps, and even let users choose their own apps if you want.

App-V version 5 includes a couple of new features that I prefer to use inside the datacenter.

  • The first is that virtual application packages can be created on a way so the packages can be added to a client OS with only metadata plus a minuscule amount of executable file content. Called "Fault Streaming" by Microsoft, only enough information for publishing (such as icons, COM objects, and a few KB of primary executables) is placed on the client. 
  • The second feature of App-V 5 is the shared cache mode. While it should not used on clients outside the datacenter, it really makes a lot of sense inside. The new shared cache mode does not require the construction of a cache bundle file like the old system. You just make the sequenced application .appv files individually available on a CIFS share.

 This means several positive things in a VM environment, depending on how you construct it:

  • Your base image for the VM will be smaller. The more apps you virtualize, the smaller it is. This is helpful when booting as it reduces the read IOs. Some of those reads will simply be delayed, but most of the assets of the virtual applications available to the user will never be read off of the share in a typical session.
  • If you use post logon app publishing against a shared standard image, the write IOs are for publishing are very small because the package primary/publishing blocks that need to be committed to the VM disk are so small. 
  • If you do persistent images, or pre-publish in the base image, it is the same primary/publishing blocks that are any different than not having those apps in the image.
  • Even better, the new shared cache system will not cause write IOs when the virtual app is run. Unlike the old system, it reads from the share directly into memory without having to write to the cache file inside the VM. This write IOPS reduction is key to improving the performance in your environment.
  • By separating out the storage of the OS image from single-instance application storage, you may be able to take advantage of different kinds of storage. For example, if VMs are always pre-booted, those VM images could live on slower storage, leaving the more expensive SSD storage for the virtual applications. In addition to getting great read performance right when you need it, the virtual apps don't get written back to, so the life expectancy of the SSDs should be better than advertised.

Traditionally, to publish on demand, you needed an App-V Server. And this is where our tool comes in. Because in App-V 5, the App-V Server doesn't actually stream anything, we can do it more simply.

If you did this with the App-V Server, well you need a Management Server, a Publishing Server, and a Database. (Plus redundancy and load balancing and all that.) Then you would import the package into the server and assign users. Except on that last part nobody actually assigns users. You actually create an application package security group in Active Directory and assign the package to that group. Then other people in your company use standard AD tools to assign users and user groups as members of that group. All this so that the application gets published every time the user logs in.

We eliminate all that. You just copy the package to the share, create the AD group like you did before, and let those other people add the members just like they did before. You install our small windows service in the base image, and possibly a GUI add-on depending on if you want self service (aka "user requested virtual apps") to automatic deployment of authorized apps. The trick? You must name the AD Security Group using the same name as the virtual package name. That's it.

When the user logs in, if configured in automatic mode, the service matches up the names and publishes authorized apps for the user (but only those not already present if you have persistent images).  If an upgrade package is found, that will be automatically applied too.  Remove a user from the AD Security Group, the package gets removed.

In Self Service mode, the user launches a GUI tool that presents the available authorized packages for selection.  Even users with standard rights can add authorized packages because the background service actually does the work, eliminating the need for an elevation prompt.  Although the GUI tool lacks a built-in workflow to request new apps, this is similar to the old Zero Touch feature that Softricity had.

Image of SelfService GUI application

Simpler, Faster, and Cheaper.  So what's not to love?

  • It isn't ready for RDS quite yet.  That will require more work.
  • It doesn't handle Connection Groups.  That will appear in the upcoming 1.5 release.
  • You don't have to pay for it.  It's hard to believe, but I do get the complaint that it is sometimes a hard sell to Management to take on a free tool. 

Thanks to those that provided feedback in the beta. Check out the release and please provide me some email feedback, both positive and negative.

__

Tim Mangan is a Microsoft MVP for App-V and a Citrix CTP.  He is the author of several books, including the new PowerShell for App-V 5 book, and can be found at TMurgent Technologies (www.tmurgent.com) where his title is "Kahuna".

Catch Tim talking App-V at Briforum Chicago in July!

Join the conversation

8 comments

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.

Wow, looks like you did it once again Tim!!  


Sounds like Fault Streaming is like the original ThinApp approach, local executable that brings over portions of sequence as needed, is that right?


Cancel

Or I might say it is like the way we did it at SoftwareWow back in 1999 before we added caching.


Cancel

can applications be published to computers instead of ad groups?


Cancel

Authorization is only to user accounts at this time; machine accounts are ignored.  Machine account authorization (with global publishing) will be added in the future.


Cancel

Hi Tim


Is there still an OS compatability issue with App-V 5, in that applicatios packaged for XP wont run on windows 7?


Basically we need to virtualise some XP applications for some new windows 7 VDs we are deploying.


Thanks


Kevin


Cancel

Kevin,


Yes, if the app won't run on Windows 7 natively, then 99.9999% of the time it won't work on Windows 7 by virtualizing it.


There are a number of apps where it is just the installer that is the problem.  Sometimes you can fix the installer via repackaging.  Otherwise I have seen some customers with the installer issue sequence it on Windows XP (using App-V 4.6) and convert to App-V 5 and run the app successfully.


Cancel

Hi Tim,


Did you get around to, or planning a RDSH version of this?


Mark


Cancel

Works great with RDS already. Timer feature added earlier this year to get the apps out prior to logons.


Cancel

-ADS BY GOOGLE

SearchVirtualDesktop

SearchEnterpriseDesktop

SearchServerVirtualization

SearchVMware

Close