Type:	Free
Version:	2.5.0.3	Updated:	August 31, 2017

AppV_SelfService (AVSS) is an alternative deployment tool for App-V 5 virtual application packages.

AVSS is a flexible alternative for App-V distribution. Intended for non-persistent and semi-persistent environments where publishing time and distribution complexity must be reduced, it is also capable of being a full replacement for persistent VDI and desktops. It does not require a database, and can publish virtual applications and connection groups. Publishing may be automatic, or virtual applications may be authorized and left to the user to select which applications they want using a simple and convenient GUI, even when the user does not have administrative privileges.

Feature Comparison Matrix:

Feature	App-V Server	SCCM	AVSS	App-V Scheduler
Centralized Admin	FS + Console + AD	Console + AD	FS + AD (Optional)	FS + Console + AD
Requires Database	yes	yes	no	no?
AD App Groups	recommended	recommended	optional	recommended
Machine Pub	yes	yes	yes	yes
User Pub	yes	yes	yes	yes
Connection Groups	yes	pre SP3	yes	no
Non-Persistent VDI?	yes	no	yes	yes
Publish before login	no	no	machine assigned	no
Publish after login	yes	very slow	yes	yes
User Self Publish	no	no	optional	no
Other features		Need SCCM Client	No central bottleneck (pull only)	Requires WinRM access to clients Has additional features
Cost	free (+ db license)	expensive	free	inexpensive

App-V Version Support:

AVSS supports App-V version 5 and above, including the new style connection groups in 5.0 SP3. Use of our AppV_DefConGroups" tool is also recommended.

The tool consists of two parts:

A Windows Service that acts as the controller to interface with the App-V Client. This controller may work in an automated mode or configured to work in end-use self service mode.
An optional WPF application (shown on the right) that can act as a self-service console for the end-user to manage the virtual applications that have been assigned (made available) to them. The end user chooses when to add, remove, and update packages based on those available and authorized to them. All without needing administrative access because the hard work is done by the Windows Service in the background.

Primary Usage Scenarios

Automated or Self-Service

The Automatic mode makes for a very simple distribution method to get packages into the hands of users. Just drop the package into a folder in the share. Optionally, you can also create an AD Security group and authorize specific machines or users. The next time they log in (or based on a configurable timer), they will automatically get the application. Another key benefit is that the tool does not republish already known apps on each logon. This significantly reduces/eliminates the multiple start menu refreshes that occur when the user logs in using the App-V Publishing server.

The SelfService mode is a replacement for the long-lost "ZeroTouch" product that Softricity had. That product was actually a web portal and didn't meet the Security requirements that Microsoft needed so they removed the product when they bought the company. This portal is a small desktop app you can install with the background service. There is no "workflow"; it just identifies the (authorized) apps and tells the service to add and publish them for the user. This allows users without admin rights to self-publish.

Using Active Directory or not

Most companies will want to integrate with Active Directory to use AD Security Groups to provide package authorization.

You can choose to skip AD integration and consider all users authorized to use any package in the package store. If you combine this with the App-V reporting server, you can track which packages are being used as a way to meet your license requirements.

Example: Automated Global Publishing upon boot

In this example the tool is installed with automatic mode enabled (no self-service GUI) and a file share that contains the packages is configured. If AD authorization is not used, the tool acts as a simple script to read the share and add/publish all found packages to the machine. With an optional timer, it will wake up occasionally to refresh this list. Another optional configuration setting, RemoverWhenMissingFromShare, will cause the service to unpublish/remove package when they are removed from the share. It doesn't get simpler than this!

With AD authorization enabled, it will match up found package names with those of security groups found in the AD OU, only applying those that are authorized for the machine at bootup, and those assigned to the user upon logon. In this case, the configuration setting UnpublishWhenNotAuthorized controls package unpublishing when no longer authorized. If this is enabled, the two RemoveWhenNotAuthorizedUser and RemoveWhenNotAuthorizedMachine controls whether the service performs package removal as well. These last two are usually disabled on RDS and enabled on single user desktops.

VDI situations

If doing VDI deployments, we would recommend setting the App-V client to use the new "shared cache" mode and not launching the application when configuring the streaming options. This significantly reduces the publishing time. If using pooled desktops we recommend using the automatic mode; and if you assign to the machine instead of the user the apps will get published before the user even logs in -- without having to include them in the base golden image. Personal VDI, and Desktop deployments may either use automatic or manual mode as desired.