Microsoft App-V

App-V allows applications to be deployed ("streamed") in real-time to any client from a virtual application server. It removes the need for traditional local installation of the applications, although a standalone deployment method is also supported. With a streaming-based implementation, the App-V client needs to be installed on the client machines and application data that is stored on the virtual application server is installed (streamed) to the client cache on demand when it is first used, or pre-installed in a local cache. The App-V stack sandboxes the execution environment so that an application does not make changes directly to the underlying operating system's file system and/or Windows Registry, but rather is contained in an application-specific "bubble". App-V applications are also sandboxed from each other, so that different versions of the same application can be run under App-V concurrently and so that mutually exclusive applications can co-exist on the same system. Nevertheless the separation is not a security boundary. App-V thus allows centralized installation and management of deployed applications. It supports policy based access control; administrators can define and restrict access to the applications by certain users, or on certain computers, by defining policies governing the usage. App-V also features a tracking interface to track the usage of the virtualized application. Servers may be implemented in highly available configurations when desired. The App-V client presents the user with a neat, locally installed application experience for virtualized applications. Access to start the virtualized application appears to be identical to the locally install application, as extensions for the application are integrated into the user's desktop shell by the App-V client. When two or more virtual applications have a dependency on each other, the individual virtualized applications may also be configured to run together in a single isolated bubble. Microsoft App-V is an additional component requiring licensing for use. Licensing is user-based and is either acquired by licensing Microsoft Desktop Optimization Pack (MDOP) for use on client operating systems, or as part of the Microsoft Remote Desktop Server Client Access License for use on Remote Desktop Servers. MDOP is a suite of technologies available as a subscription for Software Assurance customers. There also exists a licensing model that exists for hosting (cloud services) providers. ==Major versions and variants==

Microsoft released Version 5 of App-V in late November 2012, which is a third generation major redesign of the entire platform. Version 5 modernized the product, replacing components designed for use originally against Windows NT and Windows 2000 some 11 years earlier. The redesign also allowed for support of newer operating system features and improvements to virtualization support. Version 4.x of the product is still in widespread use and is currently in active support. Microsoft extended the version 4 based support for up to Windows 8.1 and Server 2012 R2 client operating systems; however, some of the newer operating system features are not available for virtualized applications using App-V 4.x. The Microsoft standard end of support date for App-V 4.x was July 2015. Versions 3.x and 2.x are not known to be in production use any more; support for these versions ended with the acquisition of Softricity by Microsoft. Versions 2.x through 4.x represent the second generation application virtualization product. There was no 1.x version of the product. Prior to the release of SoftGrid 2.0, Softricity was known as SoftwareWow.com. SoftwareWow.com was an early cloud based service provider with an application store that streamed applications (primarily games) to consumers. The service used an in-house first generation product to provide Software As A Service (SaaS). Although little online information exists about the company today, this product provided streaming services with very limited virtualization support. An offshoot of App-V was released by Microsoft under the name Microsoft Server Application Virtualization (“App-V for Servers”). This platform, which supports virtualization redirection but without isolation, is aimed at delivering virtualized server loads that would not have intra-application conflicts. The product is available as part of System Center Virtual Machine Manager, and is typically used to spin up new instances of servers on a demand-driven basis. ==Architecture==

Microsoft offers three options for the deployment of virtual applications, which affects the architectural components used: • A set of servers dedicated to App-V. • System Center Configuration Manager integration. • "Stand-alone" mode wherein the application may be delivered via other means. The implementation of these three deployment options are different when version 5.x or 4.x of App-V is used. Each are described separately. Architecture in versions 5.x The 5.x based architecture has three major options that may be used. All three of these options use a few common components: • Microsoft Application Virtualization 5.x Sequencer, which is used to package a customized application for virtualized delivery. • Microsoft Application Virtualization 5.x Client, which is used at the operating system used to run the virtual application. Two forms of the client exist, one for desktop operating systems (such as Windows 7 with Service Pack 1 and Windows 8), and one for server operating systems configured for use as Remote Desktop Session Host servers. • Microsoft Application Virtualization Report Server, an optional component that can gather usage information (called metering) of the virtualized applications. • Microsoft Application Virtualization Client Console, an optional component that can be delivered to client systems as a virtual application. Typically, the console is not required for end-users, however deploying the console application provides the user with additional control over the virtual applications that have been previously authorized and delivered. The remainder of the 5.x architecture is dependent on the deployment option used. Full App-V 5.x Server option The Full App-V 5.x Server composed of the following additional components: • Microsoft Application Virtualization 5.x Management Server, used to define applications and connection groups and assign them to Active Directory Security Groups containing lists of users or computers authorized to use the application. This server also distributes a summary of this information to multiple Publishing Servers. The Management Server is implemented as Web Service that stores configuration information in a back-end database. The Web Service may be accessed using a Silverlight-enabled web browser or PowerShell. • Microsoft Application Virtualization Publishing Server, used to authenticate users and computers and deliver appropriate virtual application metadata for publishing to the client. • Package Store, a simple file share that will be used by the clients to stream virtual applications from. In some cases, the Package Store may be fronted by a web server. Configuration Manager integration option The Configuration Manager composed of the following components: • Microsoft System Center Configuration Manager Site Server, used to define operating images, traditional application packages for installation, virtual applications, and other deployment tasks. These items may also be assigned to collections of users and computers, along with requirements and dependencies. This information is stored in a database and delivered, via a Distribution Point, to client machines. • Microsoft System Center Distribution Point, used to cache content for deployment for a highly scalable solution. • Microsoft System Center Client Agent, used to pull deployment metadata and content from the Distribution Point, and implement a variety of client component actions. From an App-V perspective, this component delivers the virtual application to the App-V Client. App-V 5 requires the use of System Center Configuration Manager 2012, and above, for full support of App-V features. Deployment by older versions, or other electronic delivery systems, are also possible by using the virtual msi method of deployment. Standalone mode The App-V 5.x clients contains a PowerShell API that is ultimately used by both of the server modes above. It is sometimes desirable to use this API directly at the client, either manually or using additional tooling developed by third parties. Architecture in versions 2.x through 4.x The 4.x based architecture has three major options that may be used as well. All three of these options use a couple of common components: • Microsoft Application Virtualization 4.x Sequencer, which is used to package a customized application for virtualized delivery. • Microsoft Application Virtualization 4.x Client, which is used at the operating system used to run the virtual application. Four forms of the client exist, combined in sets that support either x86 or x64 operating systems. One set for desktop operating systems (such as Windows XP and above), and the other set for server operating systems configured for use as Remote Desktop Session Host servers. Dedicated App-V management server The App-V 4.x system architecture is composed of the following components: • Microsoft Systems Center Virtual Application Management Server, which is used to define applications and assign them to Active Directory Users, or Security Groups containing lists of users, authorized to use the application. The server also performs runtime authentication against authorized lists and records application usage (metering) information in a database for reporting. • Microsoft Systems Center Virtual Application Management Service, which is a .NET remoting web service, manages client requests for applications. This server works in conjunction with the Management Server to provide authorized application metadata for publishing, verification of authorized use, and reporting data. The server also handles streaming operations of the virtualized packages using an extension of the RTSP protocol. • App-V Management Console, the management tool to set up, administer and manage App-V servers. It can be used to define policies that govern the usage of the applications. It can also be used to create, manage, update and replicate virtualized application packages. Shared System Center Configuration Manager In 2009 Microsoft offered a new way to implement App-V with enhancements to System Center Configuration Manager. System Center Configuration Manager Architecture consists of the following components: • System Center Configuration Manager Site Server, serving as the primary repository for holding system images, application packages created using traditional installers, and virtual applications. • System Center Configuration Manager Distribution Server, used to cache and distribute the software on a more local level. App-V 4.x has direct integrations with Configuration Manager 2007 SP1 through 2012 R2. "Stand-alone" mode The App-V clients may also be used in a "stand-alone mode" without either of the server infrastructures previously described. In this case, the sequenced packages are delivered using an external technique, such as an Electronic Software Delivery system or manual deployment. ==Operation==

Aside from the operations associated with the deployment operations, App-V Application Virtualization mainly comprises two componentsthe App-V Sequencer and the App-V Client. The App-V sequencer is the component which re-packages an application for virtualization and streaming. It analyzes the application for the resources that it requires, supports customization of the applications, and from this creates a package containing the executable components, data files, and registry settings required by the application. The package format for the 4.x and 5.x versions are quite different: • The 5.x product uses an App-V format that is based on standard compression formats with additional features. Internally, much of the metadata formatting is borrowed from AppX. • The App-V 4.x versions produce packages using the SFT format, along with additional files based on a modified version of the Open Software Description (OSD) specification originally proposed to the WC3 in 1997 by Microsoft and Marimba. The sequencer monitors the application installation, configuration, and runtime use of file and registry resources to determine package contents and configuration. It abstracts machine and user specific information to improve portability of the application components, allowing most applications to be run by different users, on different hardware, and even on different operating systems in some cases. The package is also configured for streaming operations, where portions of files may be delivered on an as-needed basis to clients. Guidelines for sequencing applications are different for the 4.x and 5.x versions. The App-V client receives virtual application package definitions in several ways. When configured to receive from a Full App-V Infrastructure Server, this occurs automatically on logon, or a timer, and is initiated by the App-V Client. It also may be sent instructions via a client API, which is used by System Center deployments, the virtual msi, and stand-alone methods. The App-V 5.x client API is PowerShell based, while the 4.x client uses a proprietary sftmime interface. Upon receiving the package, the client will download appropriate metadata, and possibly (dependent on both package and client configurations) some or all of the package components. The client is designed to utilize a streaming file system that operates much like local file paging activity. This allows for starting the application without all of the file(s) present in the cache locally. When the application requires a file portion not present, an operation called a stream-fault is performed that retrieves the needed file portion. The streamed package contents are cached by the client in memory for the duration of the application session, and may be retained in a local disk cache for future use. User settings are stored in the local system itself using redirection to ensure that the cached copy of the application is not changed. In some cases, this allows for the deployment of applications that are not multi-user aware to be used on Remote Desktop Shared Host systems. ==Capabilities specific to version 5.x==

Version 5.x, in addition to being a redesign, added a number capabilities not previously available in the 4.x version. 5.0 Service Pack 2 added to these. They include: • Support for additional integrations. Applications have many ways to provide integration to the operating system and user desktop shell. Previously, only application shortcuts, file type associations, and COM integrations were available for providing the user a native-like experience. Version 5.x, especially with Service Pack 2 and beyond, significantly expanded the types of integrations, called Application Extensions in App-V. In addition to improved Shortcut support, Protocol Handlers, Application Capabilities, Software Clients, App Paths, and a variety of shell extensions, browser helper objects, and Active-X integrations were added. Many of these extensions help overcome the objections to virtualizing complicated applications such as Microsoft Office and plug-ins to Office. • Application Size. The 4GB package size limitation is gone. No documented limit exists for App-v 5.x packages. • Improved Scripting. Dependent components that cannot be virtualized may now be installed locally by the App-V client when needed using the new scripting interface, even when the logged in user does not have administrative privileges to install software. This includes dependent device drivers. • Connection Groups: Used when multiple packages need to work together in a single virtual application environment, this replaces the Dynamic Suite Composition added to App-V 4.5. The primary benefit of this redesign is that the Connection Groups are now managed objects at the App-V or Configuration Manager level, rather than hidden modifications made by an administrator. • RunVirtual: Sometimes virtual applications are started using locally installed components, such as a local web browser using virtualized plug-ins. Previously, virtualizing these applications caused issues for users that already created their own shortcuts to the local component. Using RunVirtual, the administrator can ensure that any launch of the local component will be virtualized. == Limitations of version 4.x ==

• Microsoft Office plug-ins: Although one can sequence Microsoft Office plug-ins, it is not advised to sequence them due to many technical & usage issues. For example, in a situation where there are more than two plug-ins used by a user, if they are sequenced separately, then the user does not have control over which plug-in sequence starts when he opens a document. The only work around to resolve the issue is by creating a single suite or dynamic suite of all the plug-ins. • Application size: If the maximum client cache size is set to at least 4 GB (The max can be 64 GB), then the maximum size of application (sft file) which can be streamed on that machine is 4 GB. All applications that have an installed footprint greater than or equal to the max client size, set by the client, should not be sequenced. The maximum application size Softgrid can handle is 4GB, due to the use of the FAT32 file-system. • Device driver: App-V presently does not support sequencing of kernel-mode device drivers; thus any application that installs a device driver cannot be sequenced. The only exception to this is when the device driver can be pre-installed locally; in this case, the application is sequenced without the device driver. • Shortcuts: Applications should have minimum of one shortcut. If no shortcuts are present, then the application should be sequenced in a suite along with the application that needs it. Internet Explorer plugins require a special shortcut to start the browser process under the virtualization layer. • Middleware: Middleware applications may not be good candidates for sequencing as they may be runtime prerequisites for multiple applications. With later versions of App-V, they can be sequenced into a separate package that other virtual applications are linked to using a feature called Dynamic Suite Composition. • Path hard coding: The application should not have folder/file path hard coded in the application itself. Some applications hard code the path of files in their executables rather than parameterizing them or storing them in the Windows Registry. Configuration files ending in extensions such as ini, conf, dat, and txt are good places to look for application-specific settings of path information that may cause problems. Failing that, a shim can be used to remediate the application where source code or an update is not available. • Auto update: Applications with automatic updates should not be sequenced if their update mechanism cannot be disabled. Sequenced applications sometimes fail to update. In addition, allowing auto-update leads to non compliance of application version. • Services: Virtualization of services that must start at boot-time are not supported. All other types of services may generally be virtualized; they are started when the virtual application starts and shuts down or when an application main executable terminates. • Licensing policies: Applications with licensing enforcement tied to the machine, e.g. the license is tied to the system's MAC address or harddisk serial number. This type of application should not be sequenced if the activation can not be done by the user at the first launch of sequenced application, manually or by script. • Internet Explorer & service packs: Microsoft does not support sequencing of any version of Internet Explorer. == Similar technologies ==

• Liquidware FlexApp • Cameyo • Citrix XenApp (Formerly included as "Application Streaming"/"Project Tarpon". Discontinued as of Windows Server 2012. Now uses App-V as well.) • Installfree Bridge • Novell ZENworks Application Virtualization • Turbo Studio (formerly Spoon Studio and Xenocode Virtual Application) • VMware ThinApp == References ==