AppV_SelfService: A Tool for Automatic or Self-Service AppV 5 Publishing without servers
Back to AppV_SelfService Main Page
Overview
Inside the data center, a major challenge today for both enterprises and cloud providers is optimizing the performance (and cost) on the hypervisor
and storage tiers.
A common technique in use is to combine image management and add Microsoft App-V to achieve a level of performance without sacrificing flexibility
in delivering desktops and applications.
AppV_SelfService (AVSS) enhances both performance and your flexibility options while simplifying the infrastructure needed in the management tier.
The figure below represents a typical data center using AVSS.
Hypervisor based machines are run inside the data center.
The VMs may be Windows 7/8 VDI operating systems for individual use or Remote Desktop Servers (usually with XenApp) for shared access.
In most cases, the storage of the OS image is kept on a centralized storage tier instead of local storage and brought over at boot time.
The base image usually includes a number of natively installed applications and the App-V Client.
Prior to App-V 5, the App-V apps would be handled one of two ways:
- In a shared image, this image usually included a pre-cached copy of all of the required App-V applications, significantly increasing the size of this image while reducing write IOPS.
- In a personal image, this image would cache all published packages, either directly into the image copy or some sort of User Profile Storage (which could be a roaming profile, home drive, UPM or layering solution).
-
Usually this also involved an App-V server in the Management Tier to deliver shortcuts and stream the App-V packages to the VM.
For most customers, this server was used to identify and stream packages, and assignment of packages to users would point to Security Groups in an
"Applications Organizational Unit", enabling individual assignments to be performed directly in AD.
Using AVSS (in conjunction with App-V 5), we can add a small additional agent to the base image (a little as 60kb) that replaces the need for the App-V server.
AVSS works with the packages located in the App-V storage and an Active Directory OU directly, without the need of a Management System.
Simply by using a naming convention where the name of the AD Security Group matches that of the App-V Package Name, it can determine which packages
are assigned to be available to the user.
AVSS can be configured in two modes
- Automatic Mode The AVSS service will detect user logon and published all packages assigned to the user.
- Self Service Mode The user may launch the SelfServe app, which will show the user the currently assigned packages,
to allow self-selection.
Plus, with App-V 5, we can enabled the "shared cache mode" on App-v clients located in the data center.
The new shared cache mode allows the App-v packages to stream from the storage tier on demand directly into memory of the VM without being written back out to storage.
This combination reduces write IOPS significantly.
This combination allows for a virtual app nirvana: Reduced storage needs, increased performance due to IOPS reduction, and less management infrastructure without affecting flexibility in dynamic virtual application assignment.
Operation
AVSS adds two components to the client system. A low impact windows service (AppV_SelfService), and an optional GUI component(AppV_SelfServe).
In Automatic Publishing mode, the GUI is not used and all actions are taken by the windows service.
The service takes an absolute minimum of resources on the computer in normal use. After starting, it waits for the kernel to signal a user logon.
At that time, the service will enumerate the content store, query the App-V Client, and (if enabled) query Active Directory for group memberships of the user.
Any authorized packages that are not present at the client will be added (including any DeploymentConfig), and published (including any UserConfig) by using the client PowerShell interface.
Version checking is included to ensure that only the latest version of a package is added. Automatic removal of packages when the user has been removed from AD membership is also performed.
In SelfService mode, the service instead waits for a kernel signal that a message has arrived on the Pipe queue.
The user would launch the SelfServe GUI tool, which would perform the same enumerations and display the current status and each package.
The user could then right click on a package to add, update, or remove. This will send a message to the Windows Service to perform the action.
The App-V PowerShell interface requires administrative access to perform add/remove actions, which is easily handled by the Windows Service running in the Local System context.
This overcomes the inability of standard users to self-publish. The Publishing is performed in use user's context and does not apply to all users, unless publishing to the machine (-Global) is requested.
AVSS also works with connection group files created with the AppV_DefConGroups utility. AVDCG is a separate free tool from TMurgent that generates AppG xml files that define connection groups. AVSS will discover these files when they are also located in the package share. Whenever the publishing of a package completes all of the required packages for a connection group, the connection group is added and enabled to the user or machine (as appropriate).