AppV5Book 02 Native-Deployment-Infrastructure

THE APP-V 5 BOOK
Copyright (c) 2012, 2013 by
Falko Gräfe, Ment van der Plas, Nicke Källén and Kalle Saunamäki
All rights reserved. No content of this book may be reproduced, stored in a retrieval system, or
transmitted in any form or by any means, without the prior written permission of all authors.
The authors shall assume no liability, either explicit or implied, for this document. Information in
this document, including URL and other references, is subject to change without prior notice.
All sample code and guidelines described in this document for illustrative purposes only. These
examples have not been thoroughly tested under all conditions. The authors, therefore, cannot
guarantee or imply reliability, serviceability, or functionality of these programs or code examples.
All brand names and product names used in this document are trademarks of their respective
holders and are recognized as such.
This document is for your personal use only. You may not distribute it neither
printed nor electronically to anybody else within or outside your organization.
You also may not use any content of this document for any commercial activities
including trainings, workshops, architectural designs, presentations or alike,
without the written permission of all authors.
Please pay respect to the voluntary community contribution of the authors by following this
“don’t distribute at all” guideline!
Chapter 2
App-V Native
Deployment
Infrastructure
2 Native Infrastructure Deployment

IN THIS CHAPTER
2.1 GENER A L A R C HI TEC TU R E ............................................... 1
APP-V REQUIREMENTS ............................................................................................ 2
INFRASTRUCTURE COMPONENTS ....................................................................... 8
DESIGN CONSIDERATIONS ................................................................................... 26
2.2 I NS TA LLI NG A WO R K I NG DEPLO YM ENT

I NF R A S TRU C TU RE ......................................................... 6 5
PRE-REQUISITES INSTALLATIONS ...................................................................... 66
MANAGEMENT SERVER INSTALLATION ......................................................... 95
PUBLISHING SERVER INSTALLATION ............................................................. 108
2.3 DEPLO Y M ENT I NF R A S TR UC TU R E

C O NF I GU R A TIO NS ...................................................... 11 9
STANDARD CONFIGURATIONS ........................................................................ 120
MONITORING .......................................................................................................... 143
HIGH AVAILABILITY AND SCALABILITY ....................................................... 147
COMMUNICATION SECURITY ........................................................................... 155
CONFIGURATION AND MONITORING BEST PRACTICES .......................... 164
2.4 A DM I NI S TR A TION F O R A PP-V M A NA GEM ENT

S ER VER .............. .......................................................... 16 6
STANDARD OPERATIONS ................................................................................... 167
ADVANCED OPERATIONS................................................................................... 206
ADMINISTRATION BEST PRACTICES ............................................................... 220

2.5 TR O U BLES HO O TING A NA TI VE DE PLO Y M ENT ........... 22 6
COMMON RECOMMENDATIONS...................................................................... 227
INSTALLATION ISSUES ......................................................................................... 234
CONFIGURATION ISSUES .................................................................................... 235
OPERATIONAL TROUBLESHOOTING .............................................................. 240
2.6 A PPENDI X .......... .......................................................... 25 3
APP-V 5 SQL MIRRORING CONFIGURATION ................................................. 254
APP-V 5 CONNECTION SECURITY..................................................................... 256

ACKNOWLEDGEMENT
We would like to thank Aaron Parker (@STEALTHPUPPY) for

his support. Aaron is not only a constant source of
inspiration with regards to content: he greatly edited the
entire document so that it finally can be considered as to be
written in English.
We also would like to thank Sebastian Gernert for his

review. He is giving us (and you) confidence by confirming
the technical validity of this document.
Falko, Ment, Nicke & Kalle

2.1 G ENERAL
A RCHITECTURE
General Architecture
A P P -V R E Q U IR E M EN T S
So you’re thinking about installing the Microsoft App-V Native Infrastructure? In
this chapter we’ll walk through the general architecture of such an environment
and discuss the various requirements and dependencies of the infrastructure
components.
INFRASTRUCTURE REQUIREMENTS
When planning your App-V 5.0 Native Infrastructure it’s important to know the
requirements of the infrastructure components. In this chapter we’ve divided them
into:
 General requirements, that need to exist in the environment, but are outside
the scope of the App-V infrastructure, such as Active Directory and
installation accounts.
 Technical requirements, which define the basis on which the App-V

infrastructure can be built, such as operating system and database platform.
 Software requirements, which are installed locally on each machine and may
depend on a server role.
As the software requirements will become relevant during actual installation,

these will be discussed in the installation section of this chapter. For now we will
focus on the general and technical requirements.
The first chapter of our book described different server roles that can exist in the
App-V Native Infrastructure. Some roles can be installed from the App-V installer
software. We’ll call these the “official” roles. The installer will check if the technical
and software requirements of those particular server roles are met before installing
the software. Other roles are more or less a conceptual component and are not
The App-V Book App-V Native Deployment Infrastructure 2
Personal copy, do not distribute. Commercial use prohibited. © 2012, 2013 Authors
installable from the App-V installer software. They need to be configured or setup
manually. Requirements for these roles also need to be manually checked.
The following table shows an overview of the server roles and their availability
from the App-V installer software.
Server Role Available from installer
Management Server 
Management Server Database 
Publishing Server 
Streaming Server 
Reporting Server 
Reporting Server Database 
Package Repository 
Note: Even the official roles are not mandatory in each and every environment.
The Reporting Server for example can be installed as a standalone component in
any given infrastructure.
GENERAL REQUIREMENTS
Before anything else, preparation is the key to success. Whichever architecture you
choose, you should prepare your rollout by setting up the following components:
Requirement Description
Active Directory Microsoft App-V 5.0 is dependent on Microsoft Active

Directory for authentication and authorization of applications
and Connection Groups.
If you are planning on using the Management Server, Active
Directory will be used to apply role based access control to the
management interface. In that case an Active Directory group
which contains the App-V Administrators will be required.
Active Directory can also be used to configure the App-V
clients through Group Policy Objects.
Installation Account An installation account is required to install App-V server

role(s) from the App-V installer sources onto a local machine.
This installation account needs to have the following privileges:
• Local administrative rights on the machine you are
performing the installation on
• Read permissions to query Active Directory
Package Repository The Package Repository is the authoritative source for all
package related data. It will also act as the source for all
replication that occurs to the Streaming Servers. One of the
Streaming Servers can be assigned as the authoritative source as
well.
Depending on the given infrastructure the following
components need to have access to this location:
• The account who administers the App-V infrastructure
and adds application to the environment
• The service which accesses the packages and extracts
meta data information from the package (the
Management Server).
SUPPORTED OPERATING SYSTEMS
Microsoft App-V 5.0 server components require a minimum of Windows Server

2008 R2, with the exception of the Management Server which requires Windows
Server 2008 R2 SP1. The installation executable appv_server_setup.exe will
check for the compatibility of the underlying operating system.
The server roles that are not installed by the installer can be installed on any
supported Windows operating system, as they are only dependent on either
Internet Information Server (IIS) for streaming over HTTP(s) or File Shares for
streaming over SMB.
Management Server
Package Repository
Publishing Server
Streaming Server
Reporting Server
Minimum OS
Microsoft Windows Server 2003 Standard, Enterprise,

Datacenter or Web Server SP1/SP2/R2
    

Datacenter or Web Server
    

Datacenter or Web Server R2
    

Datacenter or Web Server R2 SP1
    
Microsoft Windows Server 2012 Standard, Datacenter     

Non-Windows based Operating Systems     
SUPPORTED DATABASE PLATFORMS
There’s a maximum of two databases in the App-V Native Infrastructure

environment, the Management Database and optionally the Reporting Database.
Their supported Database Engines are identical.
Minimum SQL
Management Database
Reporting Database
Microsoft SQL Server 2008 Standard, Enterprise, Datacenter or Developer
Edition (32 or 64-bit)
 
Microsoft SQL Server 2008 Standard, Enterprise, Datacenter or Developer

Edition R2 SP2 (32 or 64-bit)
 
Microsoft SQL Server 2012 (Standard, Enterprise, Datacenter or Developer

Edition (32 or 64-bit)
 
UNSUPPORTED SCENARIOS
Although the design of an App-V 5.0 environment is very flexible, there are certain
scenarios that are not supported. The table on the next page shows an overview of
these scenarios:
Unsupported Description
Scenario
Domain Controller None of the official App-V Server components can be installed on a
server that holds the role Active Directory Domain Controller
Server Core None of the official App-V Server components can be installed on a
server that runs Windows Server Core
Previous App-V 5.0 server components can’t be installed on a system that

installations of has any of the following components installed:
App-V • Microsoft App-V 4.5 Management Server 1
• Microsoft App-V 5.0 server components from non-official
releases (i.e. beta)
Previous releases have to be removed or App-V 5 has to be
installed on other servers.
It is supported to have an App-V 4.5 Native Infrastructure running
side-by-side with an App-V 5.0 Native Infrastructure, as long as the
server components aren’t installed on the same machine. The App-
V client is the only component where two versions, 4.6 SP1 and 5.0,
can coexist on the same machine.
Database Engine Microsoft SQL Server Express as a database engine for either App-
V 5.0 databases is not supported.
Remote Database If you want to let the App-V installer software create the
Creation management or reporting database for you, you must run the
software on the local machine that is also running Microsoft SQL
Server.
Alternatively you could create the database by running the SQL
scripts provided with the setup.
1 An installation of App-V 5.0 server components side-by-side with a Microsoft App-V 4.5
Lightweight Streaming Server (LWS) is supported, but we don’t recommend it.
HTTP://TECHNET.MICROSOFT.COM/EN-US/LIBRARY/JJ713426.ASPX
I N F RA ST R U CT UR E CO MP O N EN T S
Now that we’ve looked at the general and technical requirements, and discussed
some unsupported scenarios, it’s time to take a detailed look at various server
components and their characteristics.
While the different components are discussed in this chapter, they are also
supported by diagrams positioning them within the entire architecture. These
diagrams are explained in the upcoming sections, and all of them share a common
component: data flow. While designing this environment it’s important to
understand that there are two different types of data in a typical App-V
Infrastructure:
 Management data (or meta data) flows through the environment and
includes generic application information (i.e. name, version etc.) and their
relationships, authorization and reporting. This data is stored in XML files
and is typically small in size. This data is represented with a blue arrow.
Management Data
 Package data (or binary data) flows primarily to the components that either
require this for their service offerings (Streaming Server) or for execution
(Client). As this data holds the entire package, it’s typically pretty large. This
data is represented with a green arrow.
APP-V MANAGEMENT SERVER
The Microsoft App-V Management Server provides centralized management

functionality for the App-V 5.0 infrastructure. It primarily offers management of
virtual applications and their relationships (FIGURE 1 APP-V MANAGEMENT SERVER
CONSOLE). This includes adding, updating and removing applications, enhanced
application deployment configuration and authorization. It also manages security
features like role based access control, and registers and authenticates other
infrastructure components that are dependent on the Management Server, namely
the Publishing Server.
Unlike earlier versions of App-V, it does not maintain any reporting features. This
functionality is now offered as a dedicated server role, which does not require
deployment of a Management Server. The license provider functionality, which
was also available in earlier version, no longer exists.
The Management Server is entirely based on web services provided by Internet

Information Server (IIS) and is operated by a web-based management console.
Figure 1 App-V Management Server Console
The installation of the App-V Management Server will create a dedicated IIS
website, for which the name can be specified during the installation setup. By
default it’s called the Microsoft App-V Management Service. The Microsoft
App-V Management Service will be configured to listen on a dedicated port
number, which can be provided during setup (FIGURE 2 APP-V MANAGEMENT
SERVER WEB SERVICE). In the setup process Web Distributed Authoring and
Versioning (WebDAV) is automatically disabled for the Management Service.
Figure 2 App-V Management Server Web Service
Note: You must ensure that the Microsoft App-V Management Service website
name and port are available on the computer and are not in use by another
website. Also make sure that the port is opened in the firewall, if present.
Important!
Unless the Default Web Site is r emoved from IIS or reconfi gured
this means that port 80 is not available for the Microsoft App-V
Management Service Web Site.
The App-V Management Server is not directly contacted by the App-V Client. It
communicates solely with the App-V Management Database and the App-V
Publishing Server(s).
Figure 3 App-V Management Server relationships
The Management Database will be consulted for all administrative actions within
the App-V Management console or PowerShell and will be used to record
necessary changes. The Publishing Server(s) synchronize(s) the configuration from
the Management Server periodically to be able to serve their clients. The
Publishing Server registers with the Management Server before it can start
synchronization.
As a result, the number of simultaneous connections to the Management Server

will be limited. More importantly it’s not very likely that the load on the
Management Server will increase when number of users or devices increases.
APP-V MANAGEMENT DATABASE
The Management Server(s) store their entire configuration in the App-V

Management Database. This includes all application related assets (with the
exception of the actual application package files), their deployment configuration
(like shortcuts and file type associations), their relationships and of course their
authorization assignments. New App-V Management Servers that are added to the
environment don’t require any additional configuration before they become
operational, other than being able to read from and write to the database. The
same goes for App-V Management Servers that are being restored after an
unexpected crash. All the information they require is already stored in the
database. It’s therefore important to back up the database regularly.
The only component in the environment that contacts the database is the App-V
Management Server.
Figure 4 App-V Management Database relationships
The database (incl. stored procedures, views, permissions etc.) can be created by
the App-V server setup when the first App-V Management Server is installed or
by executing SQL scripts that are extracted from the server setup. As remote
database creation by setup is not supported you will most likely go for the SQL
scripts, unless you can actually run the App-V server installer on the SQL server
when the database administrator isn’t watching.
The SQL scripts (there’s a total of 6 scripts) however can’t be executed out of the
box. Customization is required because the scripts reference two distinct Domain
Accounts or Domain Groups (for read and write permission on the database) that
need to match your organizational environment. Customization is also needed if
you want to change the default database name [AppVManagement].
Note: Although not required, we recommend using Domain Groups to assign

permissions to the database, as this will increase flexibility when your
environment expands beyond a single system.
The [ManagementDbWriteAccessAccountName] should be set to the Domain

Group that requires write permissions to the database. This group should include
the machine accounts of all the Management Servers in the environment and the
App-V Administrator account.
The [ManagementDbPublicAccessAccountName] is used during installation and

should contain the same members as the WriteAccess group.
More details can be found in the installation section of this chapter.
Note: It’s not only the name of the Domain Group but also the SID that should be
configured in the script. For more information on how to determine this, see the
installation sub chapter.
Important!
If the Management Server and t he Management Database are being
installed to the same system, the
[Management DbWri teAccessAccountName] should be set to
"NT AUTHORITY\N ETWORK SERVICE" and
[Management DbWri teAccessAccountSid] should be set to
“010100000000000514000000".
The size of the Management Database depends on several variables. As the App-V
Management Server extracts the application information from the package and
stores it in the database, the calculated size of the database is dependent on the
number of applications, the size of the main configuration file
(AppXManifest.XML) and the number of customization that you will apply to the
package. Depending on your environment this may or may not be hard to predict
beforehand.
The following calculation can be used as a rule of thumb:
Number of packages
Size of the database
= * Average size of manifest (in MB)
(in MB)
* (Number of customizations + 4)
Example:
Given an environment with 250 packages with an average manifest file of 1MB
(which is the one from Microsoft Office 2013, so presumably pretty large) and an
average of 2 customization per package would set the size of the Management
Database to: 250 * 1Mb * (2 + 4) = 1500Mb (1.5Gb).
Procedures for backup and restore of the Management Database don’t differ from
any other given database and depend highly on your configuration (e.g. single or
clustered servers). Since the entire environment configuration is stored in the
database it’s highly recommended that you should keep your backup current and
test the restore procedures regularly. In case of a restore of the database the
Management Server(s) will pick up the configuration without jeopardizing any
data integrity.
APP-V PUBLISHING SERVER
The Publishing Server takes pride in being the man-in-the-middle and is therefore
blessed with one of the most crucial roles in the App-V infrastructure. It positioned
to be both the central delivery service for all App-V Client communication as well
as the retrieval service for all configuration updates from the Management Server.
Without a Publishing Server no applications would be delivered.
Figure 5 App-V Publishing Server relationships
Didn’t we always love the App-V 4.x Management infrastructure for its speed and
snappiness in getting the latest information and configuration down to the client?
Well, we can truly see the influence of the Microsoft System Center team: in the
5.0 Management infrastructure we are confronted with timers and intervals now.
But quite honestly, there is nothing to be really upset about.
The Publishing Server communicates at fixed intervals with the Management

Server. Information and configuration on new or updated applications is
transferred, along with their authorization assets and their network location
(stream). By default this interval (PUBLISHING_MGT_SERVER_REFRESH_INTERVAL)
is configured at 600 seconds (10 minutes). This can however be changed in the
Registry.
This default interval means that it can take up to 10 minutes before a Publishing
Server is aware of a new or modified application. Depending on the App-V Client
Refresh interval it could take even longer before the change is replicated down to
the client. Unlike earlier versions of the App-V Client, version 5.0 no longer
actively checks package status on the server for each subsequent application
launch. This means that any changes (including applying and removing
authorization) will require more time to be known to the client.
Lowering the default interval value results in a higher load on both, the
Management and the Publishing Server. Increasing the interval results in a longer
delay in the availability of new or updated applications.
Note: We think that the default value of 600 seconds is fast enough for most
production environments. In case of emergency you could also restart the web
service to force an update.
Just like the Management Server, the Publishing Server is based on IIS and the
installation of the Publishing Server will create a dedicated IIS Website. By default
it’s called the [Microsoft App-V Publishing Service] but its name can be
altered during setup.
Figure 6 App-V Publishing Server Web Service
The Microsoft App-V Publishing Service also requires a dedicated port number to
listen on, which must be provided during setup.
Note: You must ensure that the Microsoft App-V Publishing Service website name
and port are available on the computer and are not in use by another website.
Also make sure that the port is opened in the firewall.
Important!
Unless the Default Web Site is r emoved from IIS or reconfi gured,
port 80 is not available for the Microsoft App-V Publishing
Service. If you are i nstalling the Publishing Server onto t he same
machine as t he Management Server, the port that is used by the
Management Server is also not available.
The Publishing Server has no management console. Instead, during the setup the
Publishing Server is configured to communicate to a dedicated Management
Server through its web service and port.
Example: http://appvmgmt.appv.demo.local:8080
Additionally the Publishing Server needs to be registered as an authorized server

for communication. A successful last publishing attempt will be registered on the
same screen in the Management console.
Figure 7 App-V Management console Publishing Server Authorization
Tip: To check general availability of the Publishing Server and its health you could
browse to http://publishingserver.FQDN:port/ and a formatted list of
applications, GUIDs and network locations should be presented to you.
Figure 8 App-V Publishing Server XML
Unlike the Management Server, the Publishing Server is in direct contact with all
the App-V Clients. Sizing and scaling the server is therefore an important part of
the design process, as the load on this server will increase with the number of
users and devices. It is also dependent on the number of periodic refreshes from
each client. The impact on the network is limited as only the Publishing
Configuration (like the example above) travels to the clients, not the application
binaries…just yet.
APP-V STREAMING SERVER
The App-V Streaming Server is not a component that we can ‘install’ anymore.
Instead it merely represents a network location in the form a file share or an IIS
website where the virtual application packages are located.
The Streaming Server doesn’t connect to or handle connections from any other
component than the App-V Client, the Package Repository and other Streaming
Servers in the case of replication, depending on how that’s configured.
Figure 9 App-V Streaming Server relationships
Setting up an App-V Streaming Server is not hard, but it’s not automated by one of
the installers. First you need to determine the protocol that you want to use. App-
V 5.0 supports both HTTP (and HTTPS) as well as SMB as delivery protocols.
HTTP(s) requires a web server, while for SMB a simple File Server is sufficient.
Compared to SMB 2.x, HTTP is a more efficient network protocol. While the
throughput of data when using HTTP(s) as a protocol is likely to be higher, so is
the impact on the server (from a CPU and Memory perspective). Also take the
number of concurrent connections into consideration while planning your protocol
choice. Although this may not be true for SMB 3.x this does however require
capable Operating System on both the clients and servers. Securing the App-V
data stream (remember we are talking about delivering application binaries here,
not application communication traffic) will always have a negative impact on
performance.
Note: When deciding secure protocols over unsecure protocols, think for a second
about what you are actually securing! It’s not the communication traffic of the
application that’s being secured, but the application binaries travelling over the
network. Because using HTTPS instead of HTTP causes significant encryption
overhead on the Publishing Server and decryption overhead on the client while
not protecting very sensitive data we don’t generally recommend encrypting that
traffic.
Secondly, if you are going stream with HTTP, you need to setup your website.
This can be a dedicated web server or a server that already hosts other web
services. The Publishing Server would be a good candidate for also hosting the
App-V Streaming Server. Keep in mind that combining roles might have a
negative impact on performance. Creating the App-V Streaming Server is done by
creating a Virtual Directory that points to the (local) location of all the package
content and registering a MIME type APPV: application/appv. By default this
will cause the App-V Streaming Server to use port 80, but other ports can be
configured in IIS to suit your needs. Don’t forget to open up this port in the
firewall.
Thirdly you need to think of access security. Users and computers that are
authorized for a certain application also need access to the application package.
This may sound logical, but the application authorization is handled at two
different places. The Management console connects the application object to the
security group, so the Publishing Server is able to deliver all the application objects
to the App-V Client. However, the machine or user that is allowed to access the
application objects also requires access to the application object binaries to retrieve
and register the actual application. This is often realized by applying the same
security groups to both the application object in the Management console as well
as the actual NTFS permissions on the application binaries on the network source.
Tip: Browse to http://appvstreamingserver:port/virtualdirectory or

\\appvstreamingserver\share to check the accessibility of your packages.
Lastly you need to think of replication. Unless your environment is relatively small
or you are bound to one geographical location, it’s very likely that you will have
multiple App-V Streaming Servers in your environment. Keeping those servers in
sync is very important because the unavailability of an application on one server
may cause application launch failures on connected clients. The App-V Streaming
Server does not handle replication for you. However Microsoft has some pretty
good solutions for you, Distributed File System Replication (DFSR) being one of
them. DFSR uses a compression algorithm called Remote Differential Compression
(RDC) which optimizes replication. Alternatively, good-old Robocopy may save
the day as well.
Tip: Make sure that you match your application authorization process to you fit
your replication model to ensure you don’t authorize an application object that
hasn’t been fully replicated.
APP-V REPORTING SERVER
The last installable server role is actually a new one, the App-V Reporting Server.
It sits between the App-V Clients and a database - the App-V Reporting Database.
The App-V Reporting Server receives reporting data from the App-V Clients and
writes it to the database.
Figure 10 App-V Reporting Server relationships
Just like the other App-V server roles it’s based on IIS, so it also requires a Web
Service name and a dedicated port. The default name is [Microsoft App-V
Reporting Service] but this can be changed during setup.
Note: You must ensure that the Microsoft App-V Reporting Service website name
and port are available on the computer and are not in use by another website. Also
make sure that the port is opened in the firewall, if present.
Important!
Unless the D e f a ul t W eb Si te is removed from II S or r econfigured,
port 80 is not available for the [ M i c r os of t A p p- V Re p or ti ng
S e rv i ce . If you are installing the Reporting Server ont o the same
machine as t he Management Server and / or the Publishing Server,
the ports t hat are used by these servers are also not availabl e.
The App-V Reporting Server has no management console nor does it connect to
other servers or services except for the Reporting Database. In fact, the availability
of other infrastructure components other than the database is not even required.
This means that in standalone or 3rd party deployment scenarios the Reporting
Server can function just the same.
The App-V Reporting Server is configured on the client by setting several

properties, including the server URL.
Strangely enough, the App-V Reporting Server itself can’t generate any reports by
itself. It merely acts as a central reporting point for all clients coordinating the data
throughput to the database. Reports can however be created by means of SQL
Reporting Services or by 3rd party database analysis tools or just Excel.
APP-V REPORTING DATABASE
The App-V Reporting Server stores all acquired reporting data into the App-V
Reporting Database. This includes relevant information about application usage,
reporting clients and packages. The only component in the environment that
contacts the database is the App-V Reporting Server. The number of concurrent
connections to the database and the amount of data flowing to the Reporting
Server will determine the load on the server. As the number of concurrent
connections is low because of asynchronous behavior it’s not very likely that it will
put the server under serious stress.
Figure 11 App-V Reporting Database relationships
The database (incl. stored procedures, views, permissions etc.) can be created by
the App-V server setup when the first App-V Reporting Server is installed or by
executing SQL scripts that can be extracted from the server setup. Just like with the
Management Database, remote database creation of the Reporting Database is not
offered by the setup.
There are several SQL scripts for the Reporting Database and just like with the
Management Database they can’t be executed out of the box. Customization is
required because the scripts reference two distinct Domain Accounts or Domain
Groups (for read and write permission on the database) that need to match your
organizational environment. Customization is also needed if you want to change
the default database name [AppVReporting].
Note: Although not required, we recommend using Domain Groups to assign

permissions to the database, as this will increase the flexibility when your
environment expands beyond a single system.
The [ReportingDbWriteAccessAccountName] should be set to the Domain

Group that requires write permissions to the database. This group should include
the machine accounts of all the Reporting Servers in the environment and the App-
V Administrator account.
According to documentation in the sql scripts, the

[ReportingDbPublicAccessAccountName] is required during installation; we
recommend using the same members as for the WriteAccess permission.
Note: It’s not only the name of the Domain Group but also the SID that has to be
configured in the script. For more information on how to determine this, see our
installation section later in this chapter.
Important!
If the Management Server and t he Management Database are being
installed to the same system, the
[ReportingDbWriteAccessAccountName] should be set to "NT
AUTHORITY\NETWORK SERVICE" and
[ReportingDbWriteAccessAccountSid] should be set t o
“010100000000000514000000".
D ES IG N CO N S ID E R AT I O N S
We’ve discussed the infrastructure components, their functionality, service and
high-level configuration in the previous section. What we haven’t discussed yet is
how you design these components for your environment and organization.
Although the requirements for an individual company may differ the general
considerations are usually very similar. This section will discuss most of them,
including physical and functional placement of infrastructure components, the
impact of service disruption of these components, disaster recovery scenarios and
security.
SERVICE DISRUPTION IMPACT
Depending on an organization’s scope on application virtualization, the App-V

infrastructure might be responsible for just deploying some special use
applications or it is required to ensure that a major amount of business critical
applications is available for users. A virtual application deployment can be
separated into two major categories, each having different requirements with
regards to high availability.
 Initial application deployment (including initial application update

deployment) is a processes where a new App-V package or an updated
version of an existing package will be made available on a given client device
for the first time.
 Subsequent application use refers to a situation where the package has been
published and used on the client before.
The impact of a failing initial deployment can be considered as low to medium.

Unless for new, security related updates it is usually not extremely urgent to
deploy a new package to client. In most cases it is sufficient to deploy a new

package within a time frame of some hours to days.
The impact of a failing subsequent launch however is high, because users already
have visible access to published packages or may even have started them
previously. A failing application launch is a major issue in most organizations,
especially when several or all applications are affected. From an App-V client
perspective, a previously published package can have the following major load
states:
 Not available - The package is not available on the client, nor is the client and
user aware that there is an authorized access to an application; it’s simply not
registered. Needless to say that the application can’t be started at this point.
 Registered - The package has been added to the client, but it has not been
registered to the user or the operating system. The App-V Management
Server will skip this stage when an application is new to a user or client and
publishes it straightaway, but when application authorization is revoked; it
will only revert the publishing part of the registration and will not remove the
package from client. Hence the package ends up in this state.
 Published - The package has been registered to the client and has also been
published. Shortcuts and file type associations are visible to the user, entry
points are registered to the OS and if applicable, dynamic configuration files
have been applied. The application hasn’t been started at this point, but the
user is able to do so.
 Launch components loaded - If the package has been optimized for network
traffic (e.g. feature block definition) and the user starts the application, the
client downloads just enough components to start the application and a user
can perform basic/common tasks with these components. Depending on
Autoload setup (configured to always download to 100% by default) the
App-V client will continue downloading the remaining bits in one stream or
will stop and send additional bits per request.
 Fully loaded - The package is downloaded and extracted entirely onto the
client machine. In this scenario the application can also be used offline,
assuming the application itself doesn’t require network access.
The following diagram shows the flow of the Package Load State:
User launches the application

(not applicable for SCS mode)
Application is added by the management

infrastructure
Figure 12: App-V Package Load States
A special scenario when it comes to package availability is called Shared Content

Store (SCS). When an App-V Client is configured in this way (this is a client
configuration setting), it will not download any bits except for the information it
requires for adding and publishing the package. This usually includes some
metadata information about the package, the file structure, icon files etc. As this a
relative small portion of the entire package, usually around 5%, this saves an
enormous amount of disk space. This is typically beneficial for hosted desktop
implementations like Virtual Desktop Infrastructures (VDI) and Server Based
Computing (SBC) scenarios. Instead of downloading and caching the application
binaries on the client, it will fetch each and every (including recurring) streaming
requests straight from the server.
Note: These states will be discussed more detailed in the Client chapter of this
book. The above descriptions are therefore simplified 2.
As you can imagine, reaching one of the states directly impacts the usability of
applications in the case of a network outage situation. If an application was not
loaded previously or can’t be loaded on request, the application can’t be launched,
but users are able to try. Between this state and the fully loaded state the
application can be launched and it can be used as well. However calling a certain
feature may cause the application to fail, if the corresponding component hasn’t
already been downloaded. A fully loaded package can be considered to be ‘ready
for offline use’. A Shared Content Store on the other hand always requires a (fast
and available) network connection to the Streaming Server and applications
simply won’t work without a connection.
For a risk analysis, the targeted load state is an important factor for the calculation:
While the probability of an outage of the Streaming Server component is the same
for all scenarios, the impact on a VDI implementation with a Shared Content Store
is extremely high compared to a Fat Client or Remote Desktop Session Host with
fully preloaded packages.
2 Also there might be in-between states like a load state somewhere between FB1 and fully loaded
state. Also a Shared Content Store model allows downloading some portions of the package (like
FB1) onto the client and only access less frequently used components on the central store.
Whatever scenario you choose, you should incorporate failover capabilities right
from the beginning. Most failover technologies used here can be leveraged to scale
the environment in the case of increased requirements (more apps or users). In the
upcoming sections, first HA and scalability options for individual components are
discussed. After that, some scenarios will be described that we expect to be mostly
frequently used.
Whether you’re deciding where to physically, functionally or performance wise

place your server components, the first thing you need to determine is the impact
of a disruption in the services they offer. Based on that impact and the service level
you are trying to achieve you hold an important asset of the design you are trying
to create.
ACTIVE DIRECTORY
Browsing through the installation, configuration and administration guidelines

you must surely notice that an App-V Native Infrastructure deployment relies
heavily on a working Active Directory infrastructure, as almost all activities cause
AD communication. If you didn’t get it yet: No AD = no App-V! 3
While a properly working and accessible AD is crucial for App-V components to

work, we will not discuss how AD can be designed and implemented in a scalable
and fail-safe manner. Last time we checked we aren’t AD MVP’s, so we advise you
to obtain this expertise elsewhere.
3 This is true for a Native Infrastructure, which is what we are talking about here. Other models,
namely a stand-alone deployment, may not need an AD
SERVICE DISRUPTION IMPACT
Focusing on App-V (Server) components alone one could identify six scenarios in
which the App-V service is disrupted, that are described below.
 Scenario 1 - Baseline; all components operational (no disruption)
 Scenario 2 - Management Database down
 Scenario 3 - Management Server down
 Scenario 4 - Publishing Server down
 Scenario 5 - Streaming Server down
 Scenario 6 - Reporting Database down
 Scenario 7- Reporting Server down
Note: Some server components are optional and may not exist in your
environment. Disruption of multiple components should be treated as a
concatenation of each individual scenario.
The scenarios above will be discussed in detail below. We assume that only one
entity of a component exists in the environment and that if that component fails
there are no backup components available, unless stated otherwise.
SCENARIO 1 – ALL COMPONENTS OPERATIONAL: THE BASELINE
The first scenario is our reference scenario. In this scenario all components are
fully operational. Applications, including their relationships, can be added or
modified in the environment and users are able to retrieve new or updated
applications and have the ability to start them, even if they haven’t been started
before. Reporting information flows upstream to the management environment
and everybody is happy.
SCENARIO 2 – MANAGEMENT DATABASE FAILURE
This first failure scenario assumes disruption of the Management Database, a fairly
critical component but not as critical as you may think. When the Management
Database is down the Management Server is no longer able to retrieve and save
changes to the management environment. This means that you can no longer
logon to the Management Server web console and it’s not possible to add, update
or delete applications and Connection Groups. The Publishing Server, which
contacts the Management Server on a regular basis, will no longer receive any
updates, but will however continue to service the clients existing applications and
Connection Groups based on the information received during the last refresh.
Your users will hardly notice this disruption as they’re able to start and run their
applications as normal. They can even receive access to new applications if these
applications were created prior to the service disruption.
SCENARIO 3 – MANAGEMENT SERVER FAILURE
The impact of a failing Management Server is very similar to a failure of the

database in scenario 2. However, if there are multiple Management Servers in the
environment you will still be able to add, modify and delete application in the
environment through another Management Server web console. Publishing
Servers that are configured to receive the publishing information from the failing
Management Server will be unable to do so until it’s restored. However they do
continue to service their clients based on the information they’ve received in the
last successful refresh.
SCENARIO 4 – PUBLISHING SERVER FAILURE
The Publishing Server is probably one of the most critical components in the
infrastructure as it is the primary point of contact for the App-V Client to receive
authorized application records. If the Publishing Server is unavailable the user will
not receive any application updates, however previously acquired and registered
applications can be used. The user does not receive an error or prompt when the
client is unable to perform a publishing refresh. Most important aspect of a failing
Publishing Server might be the fact that the configuration change of an application
authorization is not propagated down to the client. This would either prevent a
user from using an application or wrongly allow him to continue using it.
SCENARIO 5 – STREAMING SERVER FAILURE
When the Streaming Server fails the impact depends on the actual endpoint device
type and configuration, especially on the configuration of Autoload and Shared
Content Store. A traditional device like a desktop or laptop with a default App-V
Client installation would be configured to automatically load used applications in
the background (Autoload). This means that any application that the user has
started is stored completely in cache (100%) and can be used offline. This also
means that these applications continue to run if the Streaming Server is not
operational. Consequently applications that haven’t been started previously can’t
be used in such an event.
Autoload can also be configured not to load applications in the background. This
would leave the application deployment in a state where only the bits that are
required to actually run the application are loaded. Other bits are left on the server
and are requested on demand. This configuration is typically used to prevent
excessive or unnecessary network traffic (for example in always connected or low
bandwidth scenarios) but it’s not a proper configuration for offline usage. Hence if
the client was configured this way, a failing Streaming Server would impact the
application usage heavily. The user would experience starting and running
applications (that were previously started) up to the point where the application
required an unused feature. The following streaming request will remain
unanswered and the application would typically crash.
The third and last configuration state of Autoload is to load all applications. This
could be considered the ultimate offline scenario where all applications, regardless
of the user actually having run them, will be loaded into cache, making them
available offline. This would of course have more impact on storage. However if
the client was setup with this configuration state it would mean that the
applications are able to start even when the Publishing Server is not operational.
Note: Needless to say, the ability to run an application while being offline depends
also on the architecture of the application. Typically client-server applications
don’t support such a scenario in the first place.
Another configuration besides Autoload plays an important role in the user

experience when a Streaming Server is unavailable, namely the Shared Content
Store (SCS). In normal user operation (e.g. we are not talking PowerShell scripted
management), if the App-V Client is configured in SCS mode, this would block
the client from caching anything on the local system 4. An application can be
started and just like in other scenarios, the bits that are required for application
launch travel the wire. However they are not cached locally. While using the
application, all subsequent streaming requests are always directed back to the
Streaming Server. This scenario is extremely useful in Hosted Virtual Desktop
Infrastructure (VDI) scenario where the storage demands are as high as the prices.
Fast storage is crucial, but also expensive and so the less storage you require, the
4 Even in SCS mode, administrators can load/mount applications into the local cache, allowing
mixed-mode operations.
better. The side effect of this configuration is that while the size requirements for
storage go down, the requirements for network and connecting services go up,
both for bandwidth and availability. As you can imagine an App-V Client in SCS
mode without a Streaming Server is useless.
SCENARIO 6 – REPORTING DATABASE FAILURE
As reporting is not a crucial component in the environment, a failing Reporting

Database would not impact the user at all. The user can continue to use the
applications. However the Reporting Server will not be able to store reporting
content in the database. The information will remain on the client for a certain
amount of time, which is configurable. If a cache limit is set, the cached
information on the client will be overwritten. When the Reporting Database is back
online and the reporting interval has expired, the client will upload the content to
the Reporting Server.
SCENARIO 7 – REPORTING SERVER FAILURE
A failing Reporting Server has identical impact as a failing Reporting Database.

Unless additional Reporting Servers are part of you environment, the client will be
unable to upload its reporting data until the service is restored.
DISRUPTION MATRIX
The following table shows an overview of all the service disruption scenarios and
their impact on each relevant service, structured by impact on Administration and
User Experience:
Administration and Management Impact Matrix
Service Baseline
Availability
Management
MGMT MGMT PUB STR REP REP

DB SRV SRV SRV DB SRV
Add new
application(s)
      
Update existing
application(s)
      
Delete
application(s)
      
Create new
Connection Group(s)
      
Update existing
Connection Group(s)
      
Delete Connection
Group(s)
      
Receive reporting
information
      
User Experience Impact Matrix
Service Baseline
Availability
User Experience
MGMT MGMT PUB STR REP REP
DB SRV SRV SRV DB SRV
Receive newly created

application(s)
      
Receive new access to
existing application(s)
      
Remove access to
existing application(s)
      
Start new
application(s)
      
Run previously started
application(s)
    5  
Run non-started
application(s)
      
Receive updated
application(s)
      
Start updated
application(s)
      
5 Ability depends on Autoload configuration: by default it is set to fully load applications after first
launch; therefore packages will be available without network connectivity later on.
HIGH AVAILABILITY
While reading through the service disruption impact in the previous section you
might have created a mental picture of which components are good candidates for
a high availability (HA) scenario. There are two distinct components that can be
configured for increased availability:
 Database(s), which includes the Management Database and optionally the

Reporting Database.
 Web service(s), which includes the Management, Publishing and optionally

the Streaming web services.
DATABASES
Microsoft App-V databases are only supported on Microsoft SQL Server, which
means that high availability scenarios also depend on the supported functionality
offered by SQL Server. The App-V infrastructure supports SQL high availability
based on Windows Server Failover Clustering (WSFC) or SQL Mirroring 6.
SQL Clustering can be implemented as either of the following:
 AlwaysOn Failover Cluster Instances. This scenario leverages WSFC and

high availability is offered through redundancy at the service level. A single
database instance is installed across multiple WFSC nodes but it appears to
the client as an instance running on a single computer.
 AlwaysOn Availability Groups, which also leverages WSFC but offers

redundancy at database level. Introduced in SQL Server 2012 it offers a
6 See “Planning for High Availability with App-V 5.0“, HTTP://TECHNET.MICROSOFT.COM/EN-

US/LIBRARY/DN343758.ASPX Note that the article as of today (August 2013) only mentions Mirroring
support for the Management Database (but not for the Reporting Database)
primary database to the client with a failover environment to a set of backup

databases.
SQL Mirroring requires additional configuration on the App-V Management

Server, hence it is not a transparent configuration.
Log shipping (which allows you to send the SQL transaction log from a primary
database to one or more secondary databases) is not supported.
SERVER COMPONENTS
The setup installation wizard of the server components has no built-in ability to
configure the environment for a high availability scenario. Sure you can run the
setup on multiple servers and install the individual services across different
machines, but these identical services are created in isolation and unaware of each
other. E.g. if you setup a Management Server on two different servers, this doesn’t
automatically mean they are load balanced.
So creating a high available implementation for the server components means that
we need to perform additional steps post-setup.
LOAD BALANCER
As all of the App-V Server components are web server services, one way to
achieve high availability in the web server services of App-V is by adding a Load
Balancer to the environment, either as a software load balancer through Windows
Network Load Balancing (NLB) or a hardware or virtual load balancer from
vendors like Cisco, F5, Barracuda, Riverbed, Kemp and Citrix.
A load balancer intelligently distributes network traffic from client devices over
multiple servers. In this way, it enhances the following service quality attributes:
 Performance (the load is divided between multiple targets)
 Scalability (it’s easier to add additional servers when performance drops)
 Availability (unavailable servers are detected and removed from the pool)
Having a load balancer in your design is therefore always a good idea!
While each load balancer is different and dependent on vendor specific

terminology, most of them share some common characteristics that are described
below.
First of all, the load balancer will make all servers that are in scope, available
through a single Virtual IP-address (VIP) or Virtual Cluster; a one stop shop.
Additionally it will listen on designated ports and manage all connections and
traffic that pass through it. The client needs to be setup to “talk” to the VIP on the
configured port and as the-man-in-the-middle the load balancer will handle the
request for the client to the server(s).
Note: You may consider distributing load to a server’s specific TCP port only (and
not to entire machines based on IP addresses), but that is not required and may
result in more complex load balancing rules.
Secondly a load balancer uses probing to determine the health of a server that is
part of its scope. The simplest way is to ping the server, usually several times per
minute. More advanced probing would not only check the availability the server,
but also check the service running on it. In the case of App-V this would be a
probe that checks the HTTP response of the IIS Web Service that is running on the
server.
Note: Keep in mind to check the correct ports that where defined during setup.
The default port 80 might be in use by the Default Web Site and not the actual
App-V Web Service.
Depending on the probe interval and the retry attempts of the load balancer, a
server or service that is not responding correctly is removed from the scope. For
example if the probe interval is set to 15 seconds and the retry attempt is set to 3, it
would take 45 seconds before the load balancer determines a service failure.
During this period the user would experience a “freeze” of the application or an
interrupted stream, depending of the client configuration. The application doesn’t
crash and after the server is removed from the pool the application or stream
continues as expected, but from another server.
The same rules apply when the server or service is restored. The interval is likely
to be higher because you want the server or service to stabilize before the load
balancer adds the server back into the pool. It’s very common for services to
chatter during startup. For example if the interval is set to 60 seconds and the retry
attempt is set to 3, it would take 3 minutes before a server is added back to the
pool. Users don’t experience this because only subsequent sessions or requests will
be divided across the entire scope of servers.
Note: Be sure to mimic these scenarios and check out the user experience for each
and every of them to determine if it’s sufficient and as expected.
A third important load balancing functionality is called affinity or stickiness. This

functionality determines if the load balancer should route new requests from the
same client to the same server (hence only load balance on initial client requests)
or not. Disabling affinity allows for a more advanced load balancing because it
allows multiple requests from the client to be handled concurrently by the
different servers. If enabled the affinity is often accompanied by a session timeout
(like 5 minutes). An inactive session is treated as a new connection by the load

balancer and evaluated through the standard process.
Luckily there’s no alternate configuration required to allow App-V to run through

a load balancer as its ‘normal’ HTTP(s) or SMB traffic. That applies to all App-V
Web Services, including the Management Server, Publishing Server, Streaming
Server and Reporting Server.
PUBLISHING SERVER
The Publishing Server is queried by App-V Clients regularly, usually during log-
on, but potentially also during daily operations.
In case of a failing Publishing Server, users could still launch virtual applications,
but they would not be able to get new applications and information about
application updates or retirements.
The App-V Publishing Server is one of the client facing components in an App-V
native infrastructure that should ideally be made highly available. For some
scenarios it might be acceptable that publishing information isn’t updated for a
couple of hours to days, but most implementations do not allow this. It is also
recommended to plan for scaling-out the Publishing Server service from the
beginning, especially in scenarios where some thousands of users may connect to
the environment during peak-hours.
As the Publishing Server is a stateless IIS web service, we recommend to using

‘simple’ network load-balancing solutions like (virtual) appliances or Windows
NLB to achieve both high availability and scalability goals. It’s a good practice to
plan a virtual IP address and virtual server name using a DNS alias preferably for
the App-V Publishing Server right from the beginning – even if you are planning
for a single machine only.
MANAGEMENT SERVER
The Management Server is queried by the Publishing Servers every few minutes
(default: 10) for a list of packages, Connection Groups and their corresponding AD
group assignments. Publishing Servers cache this information and are therefore
able to operate even when the Management Server service fails , even when the
Publishing Server is rebooted. The Management Server machine also hosts the
Management console (Silverlight based GUI) and the PowerShell cmdlets required
for administrative tasks.
Although an HA implementation of a Management Server is not as critical as for

the Publishing Server, we do recommend designing it as highly available for most
environments.
The Management Server is an IIS web application, just like the Publishing Server.
It can be configured for high availability following the same design guidelines as
the Publishing Server.
STREAMING SERVER
As described before, the availability requirements for the Streaming Server may
vary depending on the actual implementation and configuration. In a scenario
where packages are fully loaded into the client’s cache and only a few changes or
updates are applied, the availability and performance of the Streaming service
doesn’t need to be that high. If, on the other hand, Shared Content Mode is
implemented, access to package files must be guaranteed for the entire operation
and the service has to provide very high performance as well. Based on the
technology you have chosen for package delivery, achieving HA and scalability is
different as well.
File based streaming
Because it is just a file server you can rely on a set of proven methods to ensure
ability and scalability requirements in an App-V deployment as well. The most
common approaches are:
 File Server Cluster: Using Microsoft Cluster Services is perhaps the best-
known technology for implementing failover capabilities for file services.
Also 3rd party solutions (like storage systems) offer cluster-like features.
Implementing a File Server Cluster usually is considered to be a proven and
well-known technology.
 Distributed File System (DFS) is a newer model, namely for high availability
scenarios, introducing the concept of DFS name spaces (DFS-N) that can
actually span several individual file servers (or even file server clusters).
While DFS is presumably Microsoft’s preferred method, organizations often
find it difficult to implement DFS correctly. As an extra you could also benefit
from the replication services that are offered by DFS replication (DFS-R) for
keeping multiple Streaming Servers synchronized.
As for some of the services we’ve already discussed: this section is not intended to
explain the configuration of File Server clustering or DFS – please refer to your
trusted advisor when you need help here.
Web based streaming
There is not much to say about how to configure a scalable and reliable web server
infrastructure beyond the information that was provided above. Compared to the
IIS web applications like the App-V Management Server or the App-V Publishing
Server, web based streaming is even simpler, because it is not a .NET application,
but just a core feature of IIS.
Content Replication
No matter what technology is used for deploying the package files or how
requests are routed to the server, all nodes that provide the Streaming service
feature usually need to hold the same package files and XML files, and they have
to store it in the same directory structure. In contrast to other software distribution

solutions, App-V does not provide any integrated feature to synchronize files
between infrastructure servers. In fact, as we’ve learned it doesn’t even have a
dedicated and installable feature for serving those files to clients. But because only
simple files need to be replicated, you can use existing methods for that.
Microsoft’s Distributed File System Services Replication (DFS-R), available for free
on each Windows based fileserver, is one solution to accomplish that task. The
advantage of DFS-R is that you’d set it up once, and then it just replicates all the
files automatically. Fire and Forget. (You never did hear about a broken DFS
replication, did you? 😉)
Another frequently used method, that’s proven its reliability in real life scenarios,
is simply Robocopy. Microsoft made it part of every Operating Systems a while
back now, so it is available on every App-V server. You can run Robocopy
regularly using Windows Task Scheduler, or you just force a replication as often as
you need it. Note that Robocopy is flexible enough to retry failed attempts – and
remember that it even can delete files, so validate its settings carefully.
REPORTING SERVER
For the App-V Reporting Service usually the requirements for HA and scalability
are quite low, because deploying App-V applications works without reporting at
all. If configured, App-V clients periodically try to upload usage information to
that server – and if it fails, they just try it again. Load on the Reporting Server can
be indirectly controlled by the client’s upload interval as well. Because the App-V
Reporting Server doesn’t do any more than receiving XML data and transfer it into
an SQL database, there is not much computing power required.
If required, it can be designed for HA & scalability exactly as any other IIS based
web service.
BRANCHECACHE
Introduced in Windows 7 and Windows Server 2008 R2, BranchCache is designed

to provide optimization and improve file transfer performance for data being
accessed from geographically remote locations. Organizations would otherwise
require heavy investment in WAN upgrades (if even possible) or additional
hardware infrastructure. BranchCache supports SMB, HTTP and HTTPS protocols.
BranchCache can operate in two modes:
 Distributed Cache mode. Windows clients will utilize peer-to-peer network

architecture to minimize the impact on the WAN. The first client will
download the content, cache it locally and send it directly to its peers as they
request it. This mode requires no additional configuration other than enabling
it on the client.
 Hosted Cache mode. In this scenario a dedicated server (running Windows

Server) will host the cache and act as a source for local clients.
In both scenarios the actual cache is passive and read-only, meaning that content is
only retrieved when a client requests it and writes are always done directly to the
source.
Although not specially designed for this scenario, one could leverage BranchCache
as a high availability solution for the App-V streaming data because the App-V
Client supports the same protocols. Even though the cache is volatile and will only
build when clients start making requests, it will provide a form of high
availability; albeit without any form of management. On remote locations it will
also provide an increased delivery performance and user experience as well as
lower the dependency of high latency or instable network connections.
CLIENT CONFIGURATION
While implementing a high available server component infrastructure is the most

flexible solution and offers the best failover functionality, it’s also the most
complex implementation and requires knowledge of a lot of additional hardware
or software components. Question is: are there HA solutions configurable in the
client?
The App-V Client has three configuration items where its setup to connect to App-
V related server components: the Publishing Server, the Reporting Server and the
Package Source Root (the latter one being for the Streaming Server source).
If the Publishing Server is part of your environment (and judging by the fact that
you are reading this chapter we assume you are at least thinking about it) you can
configure the App-V Client the location (URL) and the frequency as well as the
trigger of the Publishing Refresh. From a HA perspective the App-V Client allows
you to configure multiple Publishing Servers on a single client, each represented
by a unique ID. This could be because you want to distinguish the User Publishing
Refresh from the Global Publishing Refresh or because of implementing a
failover / backup solution.
However, when a client is configured with multiple Publishing Servers it doesn’t

treat the first configured server as a primary server and fall back to a second
configured server. Instead, regardless of the actual URL, it will perform a refresh
against all of them. The refresh however is somewhat more sophisticated
compared to earlier versions. When the subsequent servers are queried - so the
publishing refresh does hit the server – the App-V Client compares the package
and version GUIDs that are published to the ones that are registered on the client.
If it matches: publishing is done. It does not try to download, override or repair
any of those packages. It considers them to be available. If the GUIDs don’t match:
only the additional packages are published. Because of this behavioral change
compared to earlier versions of App-V, one could configure the client with
multiple Publishing Servers acting as each other’s backup, without going through
the hassle of implementing load balancers or other network components.
Now the Reporting Server is another story. The App-V Client can only be
configured with one Reporting Server. However since unavailability of the
Reporting Server only means that the client will keep the data locally until the
server is restored, a HA configuration seems a little overrated here.
The PackageSourceRoot configuration is a single configuration as well; and a very

important configuration. It determines the general location of the the streaming
source. By default the Publishing Server will deliver the path that was used during
package import in the Management console. In a distributed environment with
multiple servers, this would usually point to an available source close to the client.
Unfortunately you can only setup one PackageSourceRoot per client and given the
importance of this key this would be your single point of failure if you didn’t
implement a HA solution for the Streaming Server.
FUNCTIONAL AND PHYSICAL PLACEMENT
No organization is the same, which makes it hard to determine a best practice

design. This section will give you some design principles and scenarios that will
help you in the process of designing the environment for your situation. It will try
to provide the answers to the following questions:
 When could you consolidate roles onto a single server? E.g. combining or co-
hosting functionality.
 When would you centralize or decentralize roles in a distributed

environment? E.g. geographical placement.
SMALL AND MEDIUM SIZE SCENARIO
This first of our scalable and reliable scenarios addresses environments with some
hundreds to a very few thousands of users and clients, a few (up to a hundred)
packages and a single geographical site (or multiple sites but well connected).
Active
Directory
App-V Server
Virtual Address
MS SQL
Clients Cluster
Figure 13 Small and medium size App-V infrastructure
For such a scenario, the ‘smallest possible’ flexible scenarios would be a co-hosted
two box implementation.
Note: As mentioned before, we consider the Active Directory and the SQL
Database services as ‘external’ components. We always recommend hosting SQL
services on a server other than the App-V machines.
For the native App-V services, two Operating System environments (‘machines’,
physical or virtual) are required. On each of these equally configured
environments, the following services are installed:
 App-V Management Service
 App-V Publishing Service
 (optional) App-V Reporting Service
 (optional) Web based streaming
So, in this scenario the App-V services are co-hosted (one machine hosts several
services). If you are using the Reporting Server, then it is going to be installed on
the same machines as well. However, for the Streaming service, the term ‘optional’
has another meaning. If you have an existing File Server or Web Server that meets
your streaming requirement, you are fine to use that. If you don’t have any
existing suitable infrastructure, providing the package file download service from
the two co-hosted machines is probably ideal. In this case, it’s recommended to use
the web based approach as reliability for the web based services has to be
implemented anyway. If you opt for a file based delivery, you additionally also
would have to establish high availability and scalability for a file server as well.
To implement HA and scalability, such a small scenario will most likely leverage
Windows Network Load Balancing services. External load balancing solutions are
usually not available for such deployments, but if they are it’s much easier to use
them than to implement Microsoft NLB.
Note: It’s a general recommendation to always implement a load balanced, high

available scenario because it’s makes the environment easier to adapt in case of
changing requirements.
In this scenario client requests for publishing data, streaming data or upload
requests for reporting data will be directed to a virtual IP address / host name
which is bound to the load balancing solution. It’s not necessary to make the
requests from the Publishing Service to the Management Service run through the
load balancer as well. This is not only potentially faster; it also does not require re-
configuring the Publishing Service after its initial installation. Theoretically this
could lead to a situation where the Management Service is down but the
Publishing Service still is active and unable to receive updates. However that
scenario is very unlikely because both services run on the same host and both rely
on IIS, so if that failed, all web services wouldn’t be available.
From a performance perspective, the App-V Client benefits most when the App-V
Streaming Server is geographically close by. In a single site scenario this is no
issue, but in a multi-site scenario one could opt to place one server on each site,
depending on HA requirements.
MEDIUM AND LARGE SIZE SCENARIO
Larger organizations or implementations with requirements for a more flexible

and scalable environment, may consider a more complex design where all services
are implemented individually. It has already been outlined how these components
can be addressed one-by-one. The following architecture just brings all of these
components together. Such a scenario of course should preferably not rely on
Windows Network Balancing, because that only can identify low-level network
outages to individual servers, but cannot monitor or address a service failure.
Active
Directory
Streaming Server
Virtual Address Management Server
Virtual Address
MS SQL
Cluster
Publishing Server
Virtual Address
Reporting Server
Virtual Address
Figure 14 Medium and large size App-V infrastructure
In this scenario, every connection is addressing a virtual IP address / machine

name, and none of the services are co-hosted together on any given OS instance.
DISTRIBUTED DEPLOYMENT
Organizations that opt for this scenario usually don’t just have a single datacenter
(or a nearby pair) but host their services in different datacenters, sometimes spread
around the world. Also many organizations need to support subsidiaries that
don’t have a dedicated datacenter or have a very weak internet connection.
Microsoft’s new design of strictly separated App-V services in App-V 5.0 in

combination with the usage of standard communications protocols makes
architecting a distributed scenario possible again.
As all configuration data is stored in the Management Database, it should be

centralized in a major data center. Management Servers, as the only component
that directly communicates with that DB, should be located close to the
Management Database as SQL queries to the database are often time and network
sensitive, something that WAN connections are not known to offer. When there
are multiple datacenters involved with long distances in between (something like
Americas, Europe and Asia) it can be challenging to replicate SQL data between
them. In those scenarios it’s probably best to build a HA SQL across datacenter
boundaries. There you place Management Servers and allow the Publishing
Server to connect over WAN to it. The physical ‘distance’, or even the network
distance, between the Publishing Server and the Management Server can be quite
long.
The Publishing Server, sitting between the Management Service and the Client,
usually should be located close to the client because every user log-on will initiate
a Client-to-Publishing Server connection. A refresh uses HTTP(S) to transfer XML
data, which under normal circumstances is relatively small. Communication
timeouts and interval refreshes can be adjusted in the Publishing Server’s
configuration according to the actual network capabilities.
The Streaming Server should always be located close to the client. Compared to
previous discussed components, it’s responsible for transferring the largest
amount of data. As it only relies on standard file or web services, this might
already be available in your data centers and larger locations anyway.
And what about reporting? Reporting is not a critical component in the

environment and therefore can be treated differently than the Management Server
and Database and doesn’t necessarily have to be centralized. Clients hold on to
their data anyway when the connection is temporarily down.
SIZING & PERFORMANCE
Designing your environment is as much about availability as it is about

performance. Performance is however a tricky subject as it is dependent on many
components and is hard to scope. The user may experience a slow starting
application because it was not optimized for streaming during sequencing or
because it was a bad idea after all to put the streaming source on an existing
shared file server. One example has everything to do with the quality of your
design and one absolutely nothing. Quantifying performance, in terms of
expectations and reality, can be a project by itself.
Unfortunately, at this time, Microsoft has not released any server sizing metrics to
design an App-V infrastructure. There are also no other sources that have
published any reports on performance either. This makes it very hard to predict
“how many users can exist on a single server?” or “how much RAM a Streaming
Server requires?”
But this does not mean that we simply have to make an educated guess and pray
for a good end result? No! Your design should be flexible enough to support a
changing environment and provide a quality foundation. If your infrastructure
design is adaptable and scalable you can always withstand these demands.
INTERNAL SCALABILITY
As the metrics for hardware sizing are not available yet, you have to make sure
that your hardware can scale when resource utilization is high. One way to
achieve this is to build your environment on virtualization solutions, which allow
you to expand both CPU and RAM on a machine level easily; e.g. scale up and
down. Even on the network layer you could benefit from virtualization, for
example when the (virtual) server and the virtual desktops are on the same data
center location, switch, chassis or even blade.
EXTERNAL SCALABILITY
If you don’t want to expand your (virtual) hardware, a virtualization platform also
makes it easier to expand the number of virtual machines; e.g. scale out and in. In
some scenarios external scalability (creating more similar equipped components in
parallel) might even give you more performance than internal scalability (expand
resources on existing components). To support external scalability it’s recommend
to always design your environment with a load balancer from the start. Although
implementing a load balancer at a later stage is technically not more difficult, there
are far more configuration adjustments on existing components you have to make
in the process.
PREDICTING THE GROWTH
The most common change in every organization is the number of users and
devices that are reliant on your environment and the number of applications they
use. Let’s say you’ve established an adaptable and scalable solution. How would
these changes affect the components in the App-V infrastructure?
MORE USERS / DEVICES
An increasing amount of users would cause an increasing amount of refreshes

against the Publishing Server, either during logon or periodically or both. The
amount of data that travels to the Client however is relatively low as it’s only the
XML data of the applications that the user is entitled to. Depending on the baseline
resource utilization, the number of users would have to grow significantly to make
the Publishing Server hit a resource limit making scaling out necessary. Although
a rapid change in user numbers is not very common, it’s not unthinkable. Consider
mergers and acquisitions.
As we’ve learned earlier, users do not access the Management Server or

Management Database directly which means that more users have no effect on
these components. An increasing amount of Publishing Servers would however
impact these components, but the chance of that impact being severe is not very
likely.
The Streaming Server is a component that is in direct contact with the Client, so an
increasing amount of users will definitely impact resource utilization. The amount
of data transferred from server to the client is very large, when compared to the
Publishing Server.
Lastly we have the Reporting Server and its corresponding Database. One would
say that because it’s in direct contact with the device, it’s likely to have impact
when the numbers go up. Well basically it doesn’t. Not only because the amount
of data is relatively low, but also when compared the Publishing Server the
communication times do not need to be as frequent and can be limited in size as
well. Furthermore the Client caches the information it wants to send when the
Reporting Server is unavailable, making this component very unlikely to be
affected by an increasing number of users.
MORE APPLICATIONS
An increasing amount of applications would not increase the amount of refreshes,

but it will change the amount of data that travels between the Client and the
Publishing Server. But just like with the user growth impact it’s still XML-based so
relatively easy to absorb and transfer. Only a rapid increase in your application
estate would affect this noticeably and even then it depends on the number of
application assignments of an individual user, which is not very likely to increase
in the short term.
However, unlike with the user growth impact, the Management Database does get
affected by an increasing amount of the applications, as these application
definitions are stored within the database. As we’ve described previously, the size
of the database depends on the number of applications and the amount of
customizations that you apply. This will grow by MBs and not GBs.
Conclusively we think the table below gives a weighted impact on the App-V
Native Infrastructure component of a changing environment:
Impact on Change Number of Users Number of

Applications
Management Database Low Medium
Management Server Low Low
Publishing Server Medium Low
Streaming Server High Medium
Reporting Database Low Low
Reporting Server Low Low
DISASTER RECOVERY
We’ve talking about service disruption in an earlier section, discussing the impact
of failing services on the infrastructure. Independent of your high availability
design, it’s a good thing to have a disaster recovery plan so you at least know how
to respond to a service outage. High availability usually only buys you time.
BACKUP
Disaster Recovery plans can only be executed if you have backed up the critical
components of your environment. If you look at the App-V infrastructure, there
are two components that actually hold crucial data: the database(s) and the
package repository. With this data you can recreate any environment.
Tip: It’s a good idea to back up at least the database(s) and the package repository
data. Other components can be easily recreated.
The Management Server does not hold any unique information but instead stores
everything in the Management Database. The Publishing Server also does not hold
any unique information as it’s no more than a read-only Management Server. The
Streaming Server holds a replicated copy of the package repository, which you
only have to backup once. Lastly the Reporting Server, just like Management
Server, stores its information in the Reporting Database. What we do recommend
is to make sure you make unattended installations and configuration of these
components, including the prerequisite software or components.
The interval of your backups depends on the amount of changes in your

environment in a certain timeframe and the amount of time you are ‘allowed’ to
lose in case of failure. Be sure to make regular backups of the required components
following your organization’s standards, but more importantly actually test the
restore process once or twice. You wouldn’t be the first one who found out the
hard way that the restore process is not as solid as expected.
RESTORE
We identify two types of disaster recovery scenarios when it comes to App-V

infrastructure components:
 A failing server; an entire server (and therefore all services that it provides) is
down due to hardware or software failure.
 A failing service; a particular service is down but the server it runs on is still
operational.
Restoring a failed server depends on your organization’s standard policies. If

you’ve followed our suggestion above you haven’t made any backups or
snapshots of the Management, Publishing, Streaming or Reporting Server.
Redeploying those servers is as easy as enrolling a server from scratch following
your organization’s standard image deployment procedure. Hopefully this is more
sophisticated than a manual and a DVD. A manual? You wish!
Tip: To keep impact as low as possible you could preferably keep the name
identical to the originally failing component.
If you’ve restored the server you have to restore the service that was running on it.
This means installing the prerequisites on the server, installing and configuring
Internet Information Services, installing SQL Server on the database servers and
the App-V service that originated on component you are restoring. If you don’t
like doing this manually, we are including some unattended installation scripts
during the installation sections later. Be sure to capture your initial installation and
keep the unattended installation for later reference.
If you were restoring the Management, Publishing, Streaming or Reporting Server

you are basically done after this step. The Management Server is instantly
operational as it can directly contact to the Management Database. The Reporting
Server will also start accepting client connections, but this will happen as soon as
the client hits its configured reporting interval. The Publishing Server can start
servicing clients as soon as it has contacted the Management Server once, which
may vary between one to ten minutes, depending on whether you changed the
default interval. The Streaming Server will require a full replication of the
streaming content before it can service clients. Depending on the amount of data,
the replication topology and interval, this may take several hours or even days.
If you are restoring a database, whether it’s the Management or Reporting

Database, you are required to restore the database from backup before it becomes
operational. If you are restoring the Package Repository you have to restore the
package content and wait for a replication cycle to finish.
FULL BLACKOUT RESTORE SCENARIO
With so many moving parts it may be hard to figure out the order in which restore
should take place. So let’s assume you are experiencing an entire meltdown and
you have to restore all components from scratch.
You first start with restoring all the basic server components. By basic we mean
getting the (virtual) hardware running again and get the basic operating system on
the box, including other required components. As discussed earlier you preferably
keep original server names (and IP addresses) when you install the server, to ease
configuration of other components, such as firewall exceptions..
Next it’s time to install the SQL Server onto the server that holds the Management
Database and restore the Management Database onto it. After we have a running
Management Database we can start installing the Management Server(s) and point
it to the restored database. All configurations should be picked up directly by the
Management Server from the Management Database.
Note: One could bring up the Streaming Server first so that the client can connect
to it and continue to run applications as soon as possible. This actually is a good
strategy as well.
To prevent the Publishing Server(s) from delivering application objects to the

App-V client when the corresponding content is not ready on the Streaming Server
we advise to start installing the Streaming Server first followed by the Package
Repository. As the latter one probably holds a large amount of data it may take a
significant time to restore. Additionally we have to wait for a full replication cycle
before the Streaming Server is operational. At this point the clients that have
previously received package publishing information, but haven’t started the
application, are able to stream the content in the event an application is started.
Also any client configured in Shared Content Store mode will be able run
applications again.
To complete the infrastructure you can now install the Publishing Server(s) again.
As soon as they’ve synchronized with the Management Server, your primary
application delivery chain is restored.
Lastly you should restore the Reporting Database and install the Reporting Server.
SECURITY & SUPPORTABILITY
An important aspect of any infrastructure design is security and supportability. By

applying security to your environment you prevent unauthorized access to your
infrastructure. Supportability and manageability is another essential and
mandatory component in your design but often overlooked usually due to time
constraints.
SECURITY
To limit non-App-V administrators from accessing the management environment,

you can apply role-based security. The App-V Server installation will ask you
which group you want to add to the App-V Administrators role. This group will
grant access to add, update or remove applications, Connection Groups,
permissions and package customizations to the environment.
Figure 15 App-V Management console Administrators
The Management console allows you to add additional groups to or remove

groups from this role. If all groups are accidently removed from the console, the
group that was created during setup (or configurable in a file 7) will be granted
access again after the server reboots. It is not possible to grant users or groups
limited – read or write – access to the Management console.
If other people in your organization require read access to your App-V

environment you could leverage the App-V Reporting Server and Database to
support that. As we’ve discussed these components don’t have the actual reports
available, but they can offer read-only access through the actual reporting solution
that you use.
Unlike earlier releases, the App-V Client itself no longer offers non-local
administrators the ability to perform any delegated administrative tasks. That
applies to both the user interface and PowerShell administration. Instead, the non-
local administrators have a limited set of activities that they can perform on the
client, such as initiating a publishing refresh, an application repair and setting
application offline availability. A local administrator can also perform all other
actions.
SUPPORTABILITY
App-V 5 offers several support tools. As PowerShell is now the common

administration layer across all components, PowerShell Remoting would by far be
the most powerful tool. The Windows Remote Management (WinRM) service, by
default set to manual startup, is required to be running to leverage PowerShell
Remoting. Secondly PowerShell Remoting has to be separately enabled as well.
7 More details are found in the Management Server configuration chapter
Although this is a highly powerful and extendable administrative solution, it’s not
very user friendly for users who not familiar with the PowerShell language or
scripting. Typically your first and second lines of support don’t have this
knowledge. These users better off using the native App-V Client Management
console 8.
Figure 16 App-V Client Management console
Not only will this support those staff and the user performing some of the more
simple actions on the client, it even has an option to show the PowerShell
commands that were executed underneath.
8 Note that the Beta version of Service Pack 2 for App-V 5 does not install the Client Management
Console by default any longer. It might be that Microsoft will offer it as a separate download later.
Installing a Working Deployment Infrastructure
2.2 I NSTALLING A W ORKING

D EPLOYMENT
I NFRASTRUCTURE
P R E - R E Q U IS IT ES I N S TAL LAT IO N S
The prerequisites for various App-V infrastructure components are summarized in
the following table.
.NET Framework 4 Full or 4.5
KB2533623/KB2758857 (*)
SQL Server connection 9
VC++ 2010 SP1 x86
VC++ 2010 SP1 x64

Active Directory
PowerShell 3 (*)
IIS extended
Silverlight
IIS basic
(*)
Management DB  
Reporting DB  
Management
Server
         
Publishing Server       
Reporting Server        
Streaming Server
(File)

Streaming Server
(Web)
 
9 Connection to a SQL Server means that ‘somewhere’ a supported version of SQL Server instance is
running.
For a complete and updated overview refer to the App-V 5 prerequisites at

HTTP://TECHNET.MICROSOFT.COM/EN-US/LIBRARY/JJ713458.ASPX.
Components that are marked with a (*) are already part of a default installation of
Windows Server 2012 and only need to be installed on Windows Server 2008 R2.
Hotfixes or Service Packs for the OS may pre-install or supersede some of these
components.
Note: KB2533623 was replaced by KB2758857 (or maybe even newer hotfixes).
Launching the KB2555623 update may return a ‘this update is not applicable to
this machine’ message if a newer hotfix is already installed.
ACTIVE DIRECTORY PREPARATION
As stated above and below several times we do not recommend to use individual
accounts at all, neither user nor computer. Whenever possible, you should use AD
groups. The recommendation goes even further by implementing a role-based
access control model (RBAC). In a Microsoft model, this usually implemented
following the AGDLP principle. Accounts (A) become members of role oriented
Global groups (G), like the App-V administrators group or the App-V
Management Server group. These Global groups are assigned to access right
oriented Domain Local (DL) groups, like a group for SQL server write access or a
group for content repository write access. Finally these groups are used to assign
the technical Permission (P), for instance inside SQL server, on NTFS, shares,
management consoles and alike. Within our description we try to align with the
AGDLP principle as much as possible 10. Throughout this document, permission
10 AGDLP does not only allow to leverage a role-based access model, it also addresses the challenge
of ‘token size explosion’, where Kerberos tickets get very long by placing target resources (file
groups include ‘ACL’ as part of their name to differentiate them from account
groups.
It is not necessary to create one or more dedicated AD Organization Units (OUs)

for App-V: User accounts, computer accounts, account groups and
permission/ACL groups should be organized within existing structures. Indeed we
recommend creating (and name) dedicated groups for various App-V. Depending
on the actual implementation, the following groups are recommended:
Account / Role Permissions / Membership
App-V Server Local Admins on every infrastructure machine

Installer (User) Temporary SQL server sysadmin privileges if no pre-created
database is used (described in SQL Database Pre-creation)
App-V App-V Admins Group

Administrator (User) SQL Management DB Read/Write
SQL Reporting DB Read
Content Store Read/Write
Management Server SQL Management database R/W

(Computer) Content Store Read/Write
Publishing Server (no permissions on other systems required)

(Computer)
Reporting Server SQL Reporting database Read/Write

(Computer)
servers, web servers and alike) in dedicated AD Domains. When Domain Local groups are used, a
user’s token does not contain group information from ‘different’ target systems, but only the one
from the current (sub) domain.
Account / Role Permissions / Membership
Streaming Server Content Store Read

(Computer)
App-V Client Content Store Read for Global Publishing (Application Access)
Machines Content Store Read for Shared Content Store
App-V Client Content Store Read

Administrators Application Access
App-V Users Content Store Read

Application Access
Permission Groups used in ACLs
Description Details Potential Members
App-V Permission to administer Group of App-V Admins

Administration App-V using the App-V
Permission Management console or
PoSh Cmdlets on the
Publishing Server 11
SQL sysadmin Permission to create new Group of SQL Admins or

Permission databases and, stored Installing User
procedures using setup
wizard or SQL scripts
11 Specified during App-V Management Server installation
SQL App-V Account to modify data Group of App-V Admins

Management DB in the App-V Group of App-V Management
Read/Write Management Database Servers
Permission
Installing User
SQL App-V Permission to read the Uncertain 12

Management DB App-V Management DB
Read Permission
SQL App-V Permission to write Group of App-V Reporting Servers

Reporting DB collected reporting data
Read/Write into DB
Permission
SQL App-V Permission to read Group of App-V Admins and/or

Reporting Read collected reporting data Group of users that create reports
Permissions from DB
App-V files Copy .appv files and Group of App-V Admins

Read/Write config.xml files onto
Permissions Streaming Server’s
‘Content’
12 According to the SQL script provided by Microsoft, this account ‘should be the account
corresponding to the user who will be installing Management Service’. This is misleading. This
‘Read Only’ group does not seem to be used at all.
App-V files read- Read content of .appv Group of App-V Management

only permission files and config.xml files Servers
Group of App-V Publishing Servers
File Streaming:
Default publishing: group of App-V
users
Global publishing group of App-V
client machines
Shared Content Store mode: group of
App-V client machines
Web Streaming:
Default publishing: group of App-V
users
Global publishing group of App-V
client machines
Alternatively the individual accounts
the local IIS_IUSR may be granted
access.
Shared Content Store mode: group of
App-V client machines
If IIS and actual files are on the same
machine: the machine’s (local)
Network Service account
If IIS points to a remote server for
content: the machine$ account
App-V Applications Get access to App-V Groups, Users or Computers that

access applications, packages should get access to applications
and Connection Groups
Note: If you are importing web based packages using the Management console or
PoSh, the (local and hidden) IIS_IUSR account has to have access to IIS’
web.config file in order to read IIS permissions.
SQL DATABASE PRE-CREATION
During the App-V Management Server component installation you have to specify
connection parameters to a SQL database that holds the management information.
When you install the Reporting Server component, this also requires (another)
database.
When you decide to install the SQL database on the same machine as the App-V
services, the setup wizard can create and configure the database(s) as an integrated
part of the process. However the wizard is not able to create and configure the
database if the DB should be hosted on another machine. Remember that we do
not recommend installing SQL services and App-V services on the same machine
for production deployments anyway; therefore using a remote database is a
default configuration from our perspective. Also remember that the SQL database
may not be hosted on an Active Directory Domain Controller, as this is not
supported by Microsoft.
There are several ways to pre-create the App-V management database and
reporting database on SQL Server machines.
It is not sufficient t o create empty databases and gr ant some users

access to it. Do not attempt to create any of the databases
manually.
For the App-V setup wizard to succeed, several tables, stored procedures and
other objects have to be pre-configured. Microsoft provides two methods to pre-
create the databases. One method is to execute the App-V setup wizard directly on
the SQL server. This is a good and recommended scenario for non-production or
smaller environments or for environments where a single SQL server machine is
dedicated for App-V. The other method is to prepare multiple SQL scripts
(.sql files) that SQL administrators can review and execute on the SQL server.
While this method requires more preparation, it might be required in
environments where it is not permitted to run any applications (including setup
wizards) on the SQL server machines or where the database should be hosted on a
SQL cluster. Also the setup wizard does only allow specifying a single computer
(but not a permission group) for granting access. The advantage of using the SQL
scripts is that rigorous SQL administrators may inspect and validate them, because
they are presented in clear-text, also it allows to specify computer groups.
Furthermore it can be used to prepare SQL cluster instances. The following table
summarizes the main differences between the two preparation methods:
Description Setup Wizard SQL Scripts
Complexity Low Medium/Complex
Local execution on SQL Setup.exe .sql scripts

server
Remote database support No Yes
SQL Cluster support No Yes
SQL Sysadmin privileges Installing user on SQL User who runs the scripts
machine
SQL changes can be pre- No Yes

inspected
Accounts that can be specified One individual account One group of users and/or
for SQL access rights (typically a computer) computers (incl. nesting)
Accounts that can be specified One individual account One group of users and/or
for App-V Admin rights (typically a user) computers (incl. nesting)
SQL DATABASE ACCESS RIGHTS
For both pre-creation methods you need to specify accounts or groups that will be
given permissions to the database.
Note: We do recommend always specifying AD groups (and do not use individual

user or computer accounts). The format is always domain\account-group.
Because the setup wizard does not allow specifying permission groups, we
recommend using the SQL scripts instead.
One group needs to get read and write permissions to the App-V management
database. All App-V Management Server computer accounts should be members
of this group. Optionally (and ideally) you should also add the App-V
administrators to that group. We’ll use demo\SG.SQL.ACL.AppvDB.RW in the
upcoming screenshots for that.
When using the SQL scripts (and not the setup wizard) you’ll notice that there is a
second group for ‘public access’. This group is – according to some information –
is only required for the installation and gets read access to a single table. You
could use the same group as for the read-write access or create another one. For
the examples the group demo\SG.SQL.ACL.AppvDB.RO is used, however it
contains the same members as the .RW group.
If you are using the App-V Reporting service to store client usage data in a SQL
database, similar access rights are required. You may use the same or different
groups depending on the security policy within your organization. Note that you
may need an additional group with specific SQL permissions if Non-App-V
admins should be able to extract reporting data later on.
APP-V MANAGEMENT DB PRE-CREATION WITH SETUP WIZARD
To use the App-V setup wizard for database pre-creation, you have to logon to the
targeted SQL server. You have to have local Windows admin permissions and SQL
sysadmin permissions.
Launch the App-V setup wizard “as administrator” (FIGURE 17). You may run it
from a network share.
Figure 17: Always run the setup wizard as an administrator
The setup wizard will launch. Click Install then proceed through the wizard
using the default values until you reach the Feature Selection screen.
In the Feature Selection screen, activate the Management Server DB feature, then
click Next (FIGURE 18):
Figure 18: Setup Wizard - Select Management Database component
Accept the default settings in the Installation Location screen; proceed to the first
Configure screen.
In the first Configuration screen (FIGURE 19), choose if you want to use the SQL
default instance or if you want to specify another named instance.
Provide a name for the App-V management database. Remember to follow

Microsoft’s rules for database names 13.
13 Database Identifiers HTTP://MSDN.MICROSOFT.COM/EN-US/LIBRARY/MS175874.ASPX
Figure 19: Setup Wizard - Specify Management Database name and location
Click Next .
In the second Configure screen (FIGURE 20), specify a computer account that will
access the database. Provide the name of the App-V Management Server AD
account here. Note that you only can specify a single computer (neither multiple
computers nor a group) here. Use the domain\account format.
Enter the App-V Administrators group name or the name of the currently
installing account into the Install Administrator Login field. As mentioned above
the recommendation is to prefer a group to an individual account here. Because
there is only a limited effect, you may enter the read-write group (instead of the
read-only group) here as well.
Figure 20: Setup Wizard - Specify Management Database access permissions
Confirm your settings with Next , and then proceed through the subsequent steps
until the wizard ends.
APP-V MANAGEMENT DB PRE-CREATION WITH SQL SCRIPTS
If the setup wizard is not appropriate (for security or flexibility reasons) you may
be required to use the SQL script based method to pre-create the App-V
management database.
The first task is to extract the script from the setup.exe. For this, run the
following command (as an administrator) on a temporary or test server (you may
also run this on the machine that should become an App-V server):
appv_server_setup.exe /layout c:\temp
This will extract the content of the setup wizard to the temp folder. Underneath of
it, there is a new folder for the database scripts, containing one folder with the (not
yet working) SQL scripts to pre-configure the management database, and another
folder containing the scripts to pre-configure the reporting database. FIGURE 21
shows the content of the ManagementDatabase subfolder.
Figure 21: Extracted SQL scripts
These scripts need some preparation beforehand. Both the readme.txt and each .sql
file contain some further information we will use for the upcoming steps.
At first you have to determine the SIDs for the entities that should get access to the
App-V Management database.
Using a PoSh example from Technet 14, combined with the

demo\SG.SQL.ACL.AppvDB.RW group specified above, the command would be (for
your use just replace the value between the double quotes):
14 Microsoft TechNet PowerShell tip of the week: Working with SIDs at

HTTP://TECHNET.MICROSOFT.COM/EN-US/LIBRARY/FF730940.ASPX
$objUser = New-Object
System.Security.Principal.NTAccount("demo\SG.SQL.ACL.AppvDB.RW")
$strSID =
$objUser.Translate([System.Security.Principal.SecurityIdentifier])
$strSID.Value
The output of $sftSID.Value returns the group’s SID, the command also works
for computer or user objects as shown in FIGURE 22.
Figure 22: Determine a SID using PoSh
For the App-V SQL scripts, this SID has to be streamlined first. Remove all dashes
and the ‘S’ at the beginning, so that it looks
like 1521397847259041778234562756747971114.
If you want to use a separate account or group for the read-only access to the
management DB, you also have to determine the streamlined SID for that.
Now, the SID(s) and account/group name(s) have to be entered into the
Permissions.sql file. You can modify it with Notepad or any other text editor.
Within Permissions.sql, replace the presets in square brackets with your actual
values, removing the square brackets. FIGURE 23 shows you the original, FIGURE 24
the modified Permissions.sql file.
Figure 23: Management DB original Permissions.sql file
Figure 24: Management DB adjusted Permissions.sql file
Save and close the Permissions.sql file.
The default name for the upcoming database is AppVirtManagement. If this name
doesn’t match your requirements, edit the Database.sql file.
Simply Search and Replace all instances of AppVirtManagement with your new
name. Interestingly you don’t need to remove the square brackets in this file.
FIGURE 25 shows a modified SQL script; save and close that as well.
Figure 25: : Management DB adjusted Database.sql file
If you don’t want to manually modify all the different SQL files, there is a PoSh
script available that might make things a little bit easier 15.
After they are adjusted, the scripts have to be executed by the SQL administrator
against the SQL server that should host the database. For this, sysadmin
permissions are required.
There are several ways to run SQL scripts. One is to log on to a SQL server using
the SQL Server Management Studio. This provides the ability to open a file and
15 Remote Database Preparation for App-V 5, HTTP://KIRXBLOG.WORDPRESS.COM/2012/11/01/REMOTE-

DATABASE-PREPARATION-FOR-APP-V-5/
run it as a ‘query’. However there is a certain chance that the scripts are executed
against the wrong database, because the target database has to be manually
selected (and the ‘master’ DB is the default target – something you don’t want to
modify, right?).
Another method is using the OSQL command line application. Suppose the
modified SQL scripts are located under C:\temp, the following commands have to
be executed; remember to adjust the database name if you have modified that and
note that the parameters -E, -i, -d are case sensitive:
CD c:\temp\DatabaseScripts\ManagementDatabase
OSQL -E -i database.sql
OSQL -E -d MS_Appv5_Management -i CreateTables.sql
OSQL -E -d MS_Appv5_Management -i CreateStoredProcs.sql
OSQL -E -d MS_Appv5_Management -i UpdateTables.sql
OSQL -E -d MS_Appv5_Management -i InsertVersionInfo.sql
OSQL -E -d MS_Appv5_Management -i Permissions.sql
FIGURE 26 shows the OSQL online help as well as two examples of how to run a
SQL script against the DB server and against a specific database.
Figure 26: Sample OSQL commands and outputs
APP-V REPORTING DB PRE-CREATION WITH SETUP WIZARD
Setting up the database for Reporting data basically requires the same steps as for
the Management database. In the setup wizard Feature Selection step just select
the “Reporting Database” option and proceed.
APP-V REPORTING DB PRE-CREATION WITH SQL SCRIPTS
The process to pre-create the Reporting database using SQL scripts is very similar
to the one for the Management DB, however the scripts itself are not exactly the
same. The main difference is that the reporting sub folder contains an additional
script, ScheduleReportingJob.sql, which should be executed against the reporting

database after all the other scripts have been run.
RUNTIME ENVIRONMENT INSTALLATION
Install the following components onto the App-V specific server machines
according to the requirements table in the following order:
 Microsoft Visual C++ 2010 SP1 x86 Runtime
 Microsoft Visual C++ 2010 SP1 x64 Runtime
 .NET Framework 4 Full or 4.5
 PowerShell 3 (as part of the Windows Management Framework), Reboot

required
 Microsoft KB2533623 / KB2758857
 Silverlight 4 or 5
Component VC++ VC++ .NET FW PoSh 3(*) KB Silver-

2010 SP1 2010 SP1 4 Full or 2533623/ light
x86 x64 4.5(*) 2758857(*)
Management
Server
     
Publishing
Server
   
Reporting
Server
   
(*) already available on Windows Server 2012
After the installation, reboot the machi ne(s)
The components can usually be installed using a (very) basic graphical user
interface; because they are so simple, self-explaining and well documented we
won’t annoy you by including all these next-next-finish screenshots here. For an
unattended installation, take the following script as an example (you may need to
adjust it):
:: @echo off
:: ---------- Install System Requirements for App-V 5 Servers
:: ---------- on Windows Server 2008 R2
:: ---------- Script expects components in the INS subfolder
:: ----- Install C++ Runtime environments ("<percent>~dp0" returns the

actual path)
"%~dp0\Ins\vcredist_x86_EN.exe" /q:a /passive /c:"INSTALL.EXE /q:a
/passive /c:""msiexec /i vcredist.msi /qn"" "
"%~dp0\Ins\vcredist_x64_EN.exe" /q:a /passive /c:"INSTALL.EXE /q:a
/passive /c:""msiexec /i vcredist.msi /qn"" "
:: ----- Install Dot.NET 4.0

"%~dp0\Ins\dotNetFx40_Full_x86_x64_MUI.exe" /q:a /passive /norestart
:: ----- Install Win Management Framework (PowerShell 3)

wusa.exe "%~dp0\Ins\Windows6.1-KB2506143-x64_PoSh3.msu" /quiet
:: This installer initiates a reboot
(The machine reboots; this is a required reboot to continue the installation)

:: ----- Install KB2533623 (new filesystem API)
wusa.exe "%~dp0\Ins\Windows6.1-KB2533623-x64_FileSystem.msu" /quiet
/norestart
:: the installer attempt to initae a rebbot which is not required here
:: ----- Install Silverlight
"%~dp0\Ins\Silverlight5.exe" /q
(Reboot the machine again; this reboot is not initiated automatically)
INTERNET INFORMATION SERVER PREPARATION
IIS FOR PUBLISHING SERVER
To ensure that all required components are installed, a script-based installation is

strongly recommended. Create the following script, save it as a .cmd file and run it
as an administrator on the designated machines:
Note that the dism command spans several lines. Each of these line ends with a ^
to indicate that the command continues on the next line. Make sure to include that
^ symbol at the end of each line.
:: ---------- Install and configure IIS for App-V Services

dism /Online /Enable-Feature /FeatureName:IIS-ApplicationDevelopment ^
/FeatureName:IIS-ASPNET /FeatureName:IIS-CommonHttpFeatures ^
/FeatureName:IIS-DefaultDocument /FeatureName:IIS-DirectoryBrowsing ^
/FeatureName:IIS-HealthAndDiagnostics ^
/FeatureName:IIS-HttpCompressionStatic ^
/FeatureName:IIS-HttpErrors /FeatureName:IIS-HttpLogging ^
/FeatureName:IIS-HttpTracing /FeatureName:IIS-ISAPIExtensions ^
/FeatureName:IIS-ISAPIFilter ^
/FeatureName:IIS-LoggingLibraries /FeatureName:IIS-ManagementConsole ^
/FeatureName:IIS-ManagementService /FeatureName:IIS-NetFxExtensibility ^
/FeatureName:IIS-Performance /FeatureName:IIS-RequestFiltering ^
/FeatureName:IIS-RequestMonitor /FeatureName:IIS-Security ^
/FeatureName:IIS-StaticContent /FeatureName:IIS-WebServer ^
/FeatureName:IIS-WebServerManagementTools ^
/FeatureName:IIS-WebServerRole /FeatureName:IIS-WindowsAuthentication ^
/FeatureName:WAS-ConfigurationAPI /FeatureName:WAS-NetFxEnvironment ^
/FeatureName:WAS-ProcessModel /FeatureName:WAS-WindowsActivationService
%windir%\microsoft.net\framework64\v4.0.30319\aspnet_regiis.exe –ir
Important: Ensure t hat .NET 4 or 4.5 are installed/activated on the

machine pri or to r unning t his script!
As a result of the script (or as a guideline if you really want to manually enable the
IIS role services), the IIS role configuration looks like in FIGURE 27
Figure 27: Required IIS Role Services
Note that you’ll be prompted with another window during a manual install and
configure IIS once you select the ASP.NET role service as shown in FIGURE 28. Just
accept the default value to add the services.
Figure 28: Required ASP.NET Role Services
IIS FOR MANAGEMENT SERVER
The Management Server has the same IIS requirements as the Publishing Server,
so you may refer to the previous section for instructions.
IIS FOR STREAMING SERVER
For the Streaming Service, which isn’t an installable component, you simply have
to enable the IIS role on the server.
On a Windows Server 2008 R2 or Windows Server 2012 machine, use the Server
Manager / Add Roles to enable the Web Server (IIS) role on the machine and click-
through the wizard.
Figure 29: Enable the IIS Role in Server Manager
In fact you also could use the script from section IIS FOR PUBLISHING SERVER,
however this also would install some application server / ASP features that are not
required
Remember to enable the .appv MIME type extension as part of the configuration
process as described in the section ADD .APPV AS A MIME TYPE
IIS FOR REPORTING SERVER
The Reporting Server has the same requirements as the Publishing and
Management Servers, so use the information from the section IIS for Publishing
Server
IIS PORT SHARING CONSIDERATIONS
In a well-distributed environment, where each App-V service is running on a

dedicated (virtual) machine, we recommend configuring all web based services on
port 80; the communications use HTTP and port 80 is the most common port for
that. However, by default IIS only allows one service to listen on port 80 at a time –
and usually this is the Default Website, being part of the IIS installation.
In order to configure the App-V services for port 80 right during installation, the
IIS Default Website port has to be reconfigured first. There is no easy rule for when
to use what configuration, but here are some guidelines
 If using web based streaming, IIS Default Website (and thereby the streaming
port) of that machine should remain on 80. Other App-V services should be
configured to other ports.
 If using file based streaming, the IIS Default Website’s port should be
relocated to somewhere like 84 or 8080 and ‘one’ App-V service should listen
on 80.
 If you are spreading all App-V services across different machines, every App-
V service should listen on port 80.
 IIS Default Website needs to be relocated on the Publishing, Reporting

and Management Servers.
 IIS Default Website should not be relocated for the web-based streaming
machine, since that one is a sub-feature of default IIS
 If you are using any co-hosted scenario (more than one App-V service on a
machine) you should try to find a configuration that allows using different
ports.
 If this is possible, use 8016 or 81 for the Publishing, 8013 or 82 for

Management and optional 8019 or 83 for Reporting 16 - or anything else
 If this is not possible and you are limited to using only one port, install
the services to the above, different ports and relocate them afterwards as
described in a blog post 17.
 If you have a small (co-hosted) deployment that requires HA/Failover, try

allowing different ports; otherwise you’d need your two boxes, but 2-4 virtual
IP addresses and DNS names just to enforce Host Headers as described in the
blog post.
 Finally, if you are forced to use SSL encryption forget anything about IIS port
sharing – it then gets way to complicated (you’d ask one of us for a week of
Consultancy)
After all these considerations, to actually change the port of the IIS Default Web
Site, open the IIS Management console, right click on it and select Edit Bindings .
Here you’ll find the port number to modify. Restart IIS after doing that (FIGURE
30).
16 The ‘P‘ is the 16th, ‘M’ the 13th and ‘R’ the 19th letter in a Latin alphabet – now after reading this
imagine how ‘creative’ our App-V documentations for customers look like when we could write
more than 3 pages about an IIS port
17 H T T P : / / K I R X B L O G . W O R D P R E S S . C O M / 2 0 1 3 / 0 2 / 0 4 / H O W - T O - S H A R E - P O R T S - O F - A P P - V - 5 -
SERVICES/
Figure 30: IIS - Edit Port Bindings
If you want to speci fy port 80 during i nstallation of any App-V

services you have to first relocate the IIS default port.
M AN AG EM EN T S E RV E R I N S TA L LAT IO N
OVERVIEW
The App-V Management Server offers a fairly straightforward installation wizard

and can be easily used to setup a more complex environment as well. In the
previous part all the prerequisites for any server installation scenario have been
detailed, and the database has been setup on a dedicated machine for the SQL
Server. When we install the Management Server we will need to pick a port that is
used to access the server. In a large environment where we may have a dedicated
node for each different App-V Server feature, the obvious choice would be to
select port 80 (standard HTTP) for all nodes as we are simply installing a web
service.
App-V Server features can be installed on multiple servers to provide scalability

and high availability; however each App-V Server feature would need a common
way to be accessed, such as leveraging a load balancer. Each Management Server
node does need connectivity to the database on our SQL Server.
If a single server is hosting multiple components then they can either use different
ports or be configured to share a single port 18.
18 A port sharing implementation can’t be configured using the installation wizard. See the
description at H T T P : / / K I R X B L O G . W O R D P R E S S . C O M / 2 0 1 3 / 0 2 / 0 4 / H O W - T O - S H A R E - P O R T S -
OF-APP-V-5-SERVICES/
Important: I n August 2013 Microsoft released Hot Fix 1 for App-

V 5 Service Pack 1. After installing the Management Server you
should immediately install HF1. 19
GUI BASED INSTALLATION
To start the installation, locate the installation files (FIGURE 31 INSTALLATION FILES)
in your source directory.
Figure 31 Installation files
Ensure that you start the appv_server_setup.exe with administrative privileges;

otherwise the setup will refuse to run and prompts for elevation (FIGURE 32
ADMINISTRATIVE PRIVILEGES)
19 See HTTP://SUPPORT.MICROSOFT.COM/KB/2873465. This Hot Fix addresses an issue with priorities in

Connection Groups as they are discussed in section CONNECTION GROUPS MANAGEMENT
Figure 32 Administrative Privileges
The installation wizard first presents you with an overview of the options, and
since there are no components presently installed we can only pick from the choice
of Install .
Figure 33 Install
After we have clicked Install we first need to accept the licensing terms (FIGURE
34 LICENSE TERMS). It is not possible to continue the installation unless the terms
are agreed to.
Figure 34 License Terms
Next up we are presented with a list of all the possible roles we can install (FIGURE
35 MANAGEMENT SERVER) and this screen actually gives a very good overview of
all the components that the App-V infrastructure is made up of. As the
Management Server DB can no longer be installed remotely as in the past versions
of App-V, we have already set-up that database previously on a SQL Server and
will now only install the Management Server feature. Simply check the required
feature and click Next .
Figure 35 Management Server
The installer offers to install the Management Server components in any directory,
but there is no reason for placing the files anywhere else as the installation
directory will not contain any content data and thus will be small in size 20. (FIGURE
36 INSTALLATION DIRECTORY)
20 In fact there is a bug that prevents you from installing some App-V server components on a drive
other than C: (HTTP://SUPPORT.MICROSOFT.COM/KB/2800730 )
Figure 36 Installation directory
Next up is to set the parameters for our SQL Server connection. We can use a local
server or a remote one; in this case we have a remote SQL Server that is going to be
used. It is recommended to specify a FQDN (instead of a short name) here. We can
also specify a custom (i.e. named) instance if necessary, however we have only a
default instance setup. Last option is to specify our database name.
Figure 37 Management Database
The Management Server itself has a few pieces to configure – such as who can
administer the server and how to reach the web server. (FIGURE 38 MANAGEMENT
SERVER CONFIGURATION)
The group is specified by domain\group-name. It would be good idea to make

yourself a member of the administrative group you choose during installation
before logging onto the server, in order to be able to administrate the server right
away after the installation.
We can name our management website anything we like, but suggested default
name is probably a good choice unless you have compelling reasons to customize
it such as when the IIS on the local machine already has website by the same name.
The Port Binding (what port the website the App-V Management Server will be
reachable at) is blank and you will have to enter a valid port number that is
currently not in use on the server. We recommend to use port 80 unless it’s
conflicting with another website on that specific server.
Figure 38 Management Server Configuration
Click on Install – to install! (FIGURE 39 INSTALL)
Figure 39 Install
Once the installation has finished we are (hopefully!) presented with a

confirmation that it did complete without issues and a brief reminder where we
can reach our web-based management console (Figure 40 COMPLETED
INSTALLATION). If you were not a member of the selected group that can
administer the Management Server, you cannot access the console and will be
presented with an error message.
Figure 40 Completed installation
Remember to install Hot Fix 1 (or newer) after installing the Management Server
software!
This wraps up the installation of the Management Server.
COMMAND-LINE INSTALLATION
Installing any App-V Server components via a command-line is now easier than
ever before and offers a possibility to set all the necessary parameters. As there are
quite a few options, let us begin with locating the installation files and retrieving
the documentation – by executing the following command;
Appv_server_setup.exe /?
A nicely documented window presents itself with examples and definitions that
will certainly fit whatever scenario you had in mind. (FIGURE 41 COMMAND LINE
PARAMETERS)
Figure 41 Command line parameters
Let’s gather the setup we have
1. Dedicated server
2. Use suggested name for the website and port 80 for website.
3. AD group (SG.AppV.Admin)
4. Remote SQL (SQLSRV)
5. Default instance
6. Pre-existing database (AppVManagement)
As with the GUI –based installer, we have to execute the command line setup from
an elevated command prompt.
Using the above information we can easily construct our command-line

installation;
appv_server_setup.exe /QUIET /MANAGEMENT_SERVER

/MANAGEMENT_ADMINACCOUNT="DEMO\SG.AppV.Admin"
/MANAGEMENT_WEBSITE_NAME="Microsoft App-V Management Service"
/MANAGEMENT_WEBSITE_PORT="80"
/EXISTING_MANAGEMENT_DB_REMOTE_SQL_SERVER_NAME="SQLSRV.DEMO.LAB
" /EXISTING_MANAGEMENT_DB_SQLINSTANCE_USE_DEFAULT
/EXISTING_MANAGEMENT_DB_NAME="AppVManagement"
Let’s review the parameters used:
/QUIET specifies that it is a quiet installation
/MANAGEMENT_SERVER specifies the component we wish to install (no value

necessary)
/MANAGEMENT_ADMINACCOUNT defines the group that will administer the

environment
/MANAGEMENT_WEBSITE_NAME defines the name of the website that will be created
/MANAGEMENT_WEBSITE_PORT defines the port the website will use
/EXISTING_MANAGEMENT_DB_REMOTE_SQL_SERVER_NAME defines the SQL Server

that hosts our installed database. If we are using a local database we can use the
/EXISTING_MANAGEMENT_DB_SQL_SERVER_LOCAL parameter instead, which does
not expect any server address value to be provided.
/EXISTING_MANAGEMENT_DB_SQLINSTANCE_DEFAULT defines that we will use the

default instance on the SQL Server. If we have a custom database we can use
/EXISITING_MANAGEMENT_DB_CUSTOM_SQLINSTANCE.
/EXISTING_MANAGEMENT_DB_NAME specifies the database name.
Since the installation is executed silently, we can only verify the log-files
afterwards to see if the installation was successful. An installation log file is
generated in %TEMP% of the current user and it is named
Appv_server_datetime.log, wherein the datetime portion represents the
installation timestamp.
Remember to install Hot Fix 1 (or newer) after installing the Management Server
software!
P UB LIS H IN G S E RV E R I N STA L LAT IO N
OVERVIEW
The App-V Publishing Server has, just as the other components, a straightforward
installation. It does require an App-V Management Server to interact with, but this
does not have to be reachable at the time of installation. App-V dedicated
infrastructure is a three-tier infrastructure, where the Publishing Server will
connect to the Management Server to retrieve all packages and configurations.
During the installation we need to configure which Management Server we will
connect to and receive configuration from, and which port the publishing website
will be available on. This component’s address is what we will configure any
future clients to connect to for receiving information about available applications.
To simplify the configuration, we should strive to offer the website on port 80
which is the default for HTTP traffic 21.
The component can be installed on multiple servers to provide scalability and high
availability; however the high availability itself needs to be configured through an
external load balancing mechanism, as App-V does not have such a feature built-
in. Publishing Server nodes only need connectivity to the Management Server.
21 A port sharing implementation can’t be configured using the installation wizard. See the
description at H T T P : / / K I R X B L O G . W O R D P R E S S . C O M / 2 0 1 3 / 0 2 / 0 4 / H O W - T O - S H A R E - P O R T S -
OF-APP-V-5-SERVICES/
GUI BASED INSTALLATION
To start the installation, locate the installation files (FIGURE 31 INSTALLATION FILES)
in your source directory.
Figure 42 Installation files
Ensure that you start the appv_server_setup.exe with administrative privileges;

otherwise the setup will refuse to run and prompts you for elevation. (FIGURE 32
ADMINISTRATIVE PRIVILEGES)
Figure 43 Administrative Privileges
The installation wizard first presents you with an overview of the options, and
since there are no components presently installed we can only pick from the choice
of Install
Figure 44 Install
After we have clicked Install we need to confirm whether we accept the license
terms or not (FIGURE 45 LICENSE TERMS). It is not possible to continue the
installation unless the terms are agreed to.
Figure 45 License Terms
Finally we can select which component we want to install (FIGURE 46 PUBLISHING

SERVER) by selecting Publishing Server .
Figure 46 Publishing Server
The installer offers to install the Publishing Server components in any directory,
but there is little reason for placing the files elsewhere. (FIGURE 47 INSTALLATION
DIRECTORY)
Figure 47 Installation directory
The Publishing Server has some minor configuration (FIGURE 48 PUBLISHING

SERVER CONFIGURATION) before we can complete the installation.
First we must enter the URL of our Management Server , which is either already
installed or is going to be installed later. Both the address of the server and the
port of the website have to match what is configured during the Management
Server installation. The address here can be configured to point to an external load
balancer that will pass the requests between multiple Management Servers, or in a
simpler environment it would be the actual URL with FQDN of our single
Management Server.
We also have to specify a Website name and the port for the website that
Publishing Server will listen on. No port is recommended by the installer, but
since the App-V Publishing Server will need to be contactable by all clients, we do
recommend the standard port 80 for all HTTP services.
Figure 48 Publishing Server Configuration
Finally, we receive a confirmation that we can proceed with the installation before
committing any changes to the server. (FIGURE 49 READY FOR INSTALLATION)
Figure 49 Ready for Installation
Once we complete the wizard we will receive feedback that the installation was
successful and what the final steps are before using the Publishing Server (FIGURE
50 FINISHED INSTALLATION). As noted on the summary screen, we now have to
register the Publishing Server with the Management Server so it can receive all
metadata for applications.
Figure 50 Finished installation
If the Publishing Server and the Management Server are installed on the same
node, the Publishing Server should be registered automatically. If the Management
Server and the Publishing Server are installed on separate nodes, you will have to
manually register the Publishing Server with the Management Server. This is
described in the section CONFIGURING PUBLISHING SERVERS.
Installing the Publishing Server has ended.
COMMAND-LINE INSTALLATION
Just as for using the command-line to install the App-V Management Server we
can leverage this powerful installer for the Publishing Server. Let us start starting
the documentation from the installer:
Appv_server_setup.exe /?
Once again we have a nice list of examples and definitions and can easily create
our command-line. (FIGURE 41 COMMAND LINE PARAMETERS)
Figure 51 Command line parameters
Before we dive into the possible parameters, let’s summarize what we do know;
1. Management Server is installed on http://srv01.demo.lab
2. It uses port 80
3. Our Publishing Server will use port 80
We have to execute the command line from an elevated command prompt
Using the above information we can easily construct our command-line

installation:
appv_server_setup.exe /QUIET /PUBLISHING_SERVER

/PUBLISHING_MGT_SERVER=http://srv01.demo.lab
/PUBLISHING_WEBSITE_NAME=”Microsoft AppV Publishing Service”
/PUBLISHING_WEBSITE_PORT=”80”
/QUIET specifies that it is a quiet installation
/PUBLISHING_SERVER specifies which component we are about to install (no value

is necessary for this parameter)
/PUBLISHING_MGT_SERVER defines the address where we can reach the App-V

Management Server, including the port at which it operates at
/PUBLISHING_WEBSITE_NAME defines the name of the App-V Publishing website.
/PUBLISHING_WEBSITE_PORT defines the port at which the App-V Publishing

website will respond on requests.
Since the installation is executed silently we only can verify the log-files afterwards
to see if the installation went through correctly. Installation log file is generated
within %TEMP% of the current user and it is named Appv_server_datetime.log,
wherein the datetime portion represents the installation timestamp.
Deployment Infrastructure Configurations
2.3 D EPLOYMENT
I NFRASTRUCTURE
C ONFIGURATIONS
S TAN D ARD C O N F IG U R AT IO N S
After the components for the App-V Native Infrastructure have been installed
(and perhaps updated with Hot Fixes), the environment is almost ready to use.
However there are some configuration steps required and you may find some
information in this section that may help you in optimizing the environment and
troubleshooting it. In contrast to administration, the configuration section does not
address topics like application management or other tasks that can be considered
as daily business. Instead it covers more one-time configuration tasks. Right here
we’ll focus on native App-V infrastructure components; as the Package Repository
and the databases for the management or reporting data are relying on industry-
standard technologies, they aren’t discussed here and as the Client and Sequencer
have their own, dedicated chapters in this book later on, they aren’t discussed here
either.
PUBLISHING SERVER CONFIGURATIONS
As mentioned previously, the Publishing Server service is not a native Windows

Service, but a web application hosted on IIS. Microsoft does not provide any
graphical user interface to configure it, and frankly this also isn’t necessary either.
To make configuration changes (and of course to verify them), Regedit, the IIS
Management console and perhaps a text editor are sufficient.
Relevant configuration settings can be found in the Registry under

HLKM\Software\Microsoft\AppV\Server\PublishingService, as shown in
FIGURE 52.
Figure 52: Reporting Server Registry configuration
INSTALLDIR specifies the installation directory and should not be modified under
any circumstances. If the installation was to an incorrect directory it’s surely better
to uninstall and re-install the Publishing Server. Because the Publishing Server
does not hold any configuration data, this is an easy and low-risk task.
PUBLISHING_MGT_SERVER specifies the protocol, server name and port of the App-
V Management Server service that is to be queried. If both, Publishing Server and
Management Server are installed on the same machine (co-hosted scenario) and if
no encryption is used, localhost can be used to specify the Management Server.
Note that the right communication port (81 in the screenshot) has to be specified.
When you modify the environment later on (like isolate the Management Service
on a dedicated machine, place it behind a load-balancer or such), you can adjust
the Registry setting here. Because the targeted App-V Management Service is also
an IIS web service, HTTP and HTTPS are the only two supported protocols.
Remember that any encrypted (HTTPS) communication between the two services
– even on the same machine – not only would require decent certificates, but also
the FQDN of the Management Server has to be specified.
PUBLISHING_MGT_SERVER_REFRESH_INTERVALL (default value: 600) specifies how

often (in seconds) the Publishing Service queries the Management Service for the
list of packages, applications or Connection Groups including their user or group
assignments and other configurations. By default, such a request is sent every 600
seconds (10 minutes). Especially for test or demonstration purposes it is very
useful to shorten that interval to something like 30 seconds. However, a short
refresh interval causes more network traffic and increases the load on both the
Publishing Server and the Management Server. If you set it too short, both servers
may even become unresponsive. For production environments you should leave it
at its default value of 600 seconds.
You may find some references to modifying the webconfig.xml file for adjusting
this setting. This recommendation was true for pre-releases and the beta version of
App-V 5 but does not apply to the final release.
PUBLISHING_MGT_SERVER_TIMEOUT (default value: 100) specifies in seconds, how

long the Publishing Server should wait for a proper result from the Management
Server. You should leave it as it is.
PUBLISHING_WEBSITE_NAME specifies the name of the IIS web site for the
Publishing Service as it was defined during installation. You should not modify
this setting.
PUBLISHING_WEBSITE_PORT specifies the TCP port IIS uses for the Publishing
Service. Clients will connect to the service using this port to retrieve individual
publishing information. You should not change this setting – and you should
ensure that your firewall allows communications to this port. To add more ports
(like 443 for a secure HTTPS connection) you should use the IIS (site) configuration
settings only.
To force the changes to take effect you can restart the WWW Web Publishing
Service (Windows service), restart the App-V Publishing web application
within IIS or launch the iisreset command with elevated rights. Of course you
also can restart the entire machine. All actions cause the service to stop functioning
for a while, so clients won’t receive publishing information during that time.
MANAGEMENT SERVER CONFIGURATION
The App-V Management Server is also an IIS web application. Like the Publishing
Service it can be configured via the Registry or IIS Manager. Additionally some
settings show up in the Management console or in configuration text files.
In the Registry, HKLM\Software\Microsoft\AppV\Server\ManagementService

holds several configuration data (FIGURE 53).
Figure 53: Management Server Registry configuration
INSTALLDIR shows the directory the App-V Management Server components were
installed to. You shouldn’t modify this.
MANAGEMENT_ADMINACCOUNT, _SID and _TYPE are also values that you should not
change. They show which user or group was specified during installation as being
the “App-V Administrator”.
MANAGEMENT_CMDLET_URL and MANAGEMENT_CONSOLE_URL both point to local

resources and should not be changed, though it is not certain what purpose these
values may have.
MANAGEMENT_DB…. entries of course specify connection parameters to the App-V

Management Database as they were specified during the installation. We are not
sure why there are separate entries for _SERVER and _SERVER_NAME 22. You may
modify all of these settings, if you move your database to another server.
MANAGEMENT_SQL_CONNECTION_STRING points to local modules for the database

connection. Since they don’t contain any actual dynamic or variable parameters
this entry should not be modified unless you are connecting to a SQL Mirror
database 23.
MANAGEMENT_WEBSITE_NAME and MANAGEMENT_WEBSITE_PORT describe settings of

the IIS web application. The _NAME value shouldn’t require any change. The _PORT
value is used for inbound connections from the Publishing Server. Also the web
based management console is reachable at this port. This value should not be
modified.
There are two files that appear to be used for configuration purposes. Both are
located in the INSTALLDIR (usually C:\Program Files\Microsoft Application
Virtualization Server\ManagementService, see FIGURE 54).
22 A guess: The name was changed during the development process, whereas some modules still
point to the original entry while others use the renamed one. MANAMGEMENT_DB_SERVER may
include the instance name (server\instance).
23 For a connection to a SQL Mirror, refer to the section APP-V 5 SQL MIRRORING CONFIGURATION in
the Appendix.
Figure 54: Management Server AdminGroup.xml path
The AdminGroup.xml looks interesting, though it only holds the information

specified during installation. In fact this file forms a protective backup: in case you
remove all entries from the Administrators entry in the management console,
resetting the IIS web application (iisreset) or rebooting the machine restores one
admin entry based on the value specified here. FIGURE 55 shows an example of
this.
Figure 55: Management Server AdminGroup.xml content
The folder also contains a web.config file: It doesn’t contain any options you
should modify.
When moving over from Registry and file based modifications to the web based
management console, there are two sections that can be considered as having
configuration purposes.
CONFIGURING PUBLISHING SERVERS
The Servers section shows the list of know Publishing Servers, but not the
Management or Reporting Servers (FIGURE 56). After you installed the Publishing
Server, you may have to register it using the Management console – you should
verify its registration anyway.
Figure 56: Server MMC - List of Publishing Servers
Clicking on the REGISTER NEW SERVER link (top-right) will open a new form that
allows you to enter the name and a description for that new Publishing Server
(FIGURE 57):
Figure 57: Server MMC - Add new Publishing Server
Enter the server name (or a part of it), then click on Check and select the
appropriate machine name from the drop down list showing potential matches.
Note that you have to use the domain\server format. You also can enter a
description. Clicking on Add inserts the new server name into the database. If the
Add button is grayed out, repeat the check/select steps.
As a result, the new server appears in the server list (FIGURE 58):
Figure 58: Server MMC - Updated Publishing Server list
Right clicking on a server entry allows for removing it; this is useful if a Publishing
Server machine was de-provisioned (FIGURE 59). You’d be prompted if you really
want to remove that server.
Figure 59: Server MMC - Remove a Publishing Server
There is no PowerShell cmdlet to control this configuration.
CONFIGURING ADMINISTRATORS
The Administrators section (accessible via the cogwheel icon) does indeed allow
some configuration.
Of course it does show a list of currently configured App-V Administrators.

Initially this view shows the admin account that was specified during installation.
As you can see in FIGURE 60 we followed our Best Practice of using groups only
(and never individual users).
Figure 60: Server MMC - Administrators list
The top right Add Administrators link opens a form where you can select new
groups (or users) for becoming an App-V admins. Enter the domain name
followed by a backslash and the actual group name (or user name if you really
have to). It is sufficient to enter the first few characters of the group; a list of
matching items will be generated for you (FIGURE 61). Clicking the Check button
retrieves a list of matching objects, allowing you to select one.
Figure 61: Server MMC - Add Administrators
Then click Add , followed by Close , and the new group or user will be added to the
App-V administrators list.
Removing an administrator is not so nicely presented in the management console.

For this task you have to right-click on an entry and select remove as
administrator in the popup menu (see FIGURE 62).
Figure 62: Server MMC - Remove Administrators
You’ll be prompted with a warning message that needs confirmation (FIGURE 63).
Figure 63: Server MMC - Admin removal confirmation
If you confirm the removal, the task ends with an information message bar, telling
you that the entry was removed from the list of administrators.
Figure 64: Server MMC - List of Administrators
Managing Administrators can only be done using the GUI, and not with PoSh.
RESTORE ADMIN ACCESS AFTER ACCIDENTAL LOCK OUT
Warning: The following actions may irreversibly destroy your

App-V implementation! Do onl y try t hem in volatile test
environments.
Ok, so just for the fun of it: What happens if you are removing the last
administrator account from the list? Does the Management console prevent this?
After reading and understanding the warning message just above you easily can
guess the answer: The console allows you to remove even the last account!
Immediately after you’ve done this you are prevented from performing any
further actions. You can still click through the sections, but an error message
clearly indicates that you are lost.
Figure 65: Last Admin removal confirmation
Are you really? Luckily not: Just initiate an iisreset (or reboot the machine). In
such a situation the App-V Management Service reads the file AdminGroup.xml
located in the installation directory C:\Program Files\Microsoft Application
Virtualization Server\ManagementService\
The group/user object, which is identified by its AccountSID value, then will be
added back automatically as an App-V Administrator (also in the database). But
again this isn’t a daily occurrence, this is an emergency task! 24
24 Another way to restore the App-V admin group would be to directly modify the database,
RoleAssigmnents table.
STREAMING SERVER CONFIGURATION
Though there is no dedicated installer for the Streaming Server, this component
still requires some configuration as well. The configuration differs depending on
the technology used: File server or Web server.
We recommend implementing the Streaming Server on a Web Server rather than

on a File Server.
FILE SERVER
If the App-V packages should be downloaded by the client from a file share, of
course you’d need to configure one. Because Windows file share configuration is a
common task, it won’t be described detailed here. However, just to remind you of
a few Best Practices:
 In the file sharing configuration, allow full access for everyone.
 Limit the actual access rights by configuring NTFS permissions on files and
folders.
 Prevent the share from being used offline.
 Prefer the Share and Storage management console over the right-click-on-a-
folder method.
 Always use groups (but no users) to control ACLs.
Specific for App-V apply the following configurations:
 The App-V Client potentially accesses the file in the actual user’s and the
machine’s context. Therefor users and computers require read access
permissions on the respective .appv files.
 The App-V Management Server machine accounts require read access to the
files.
 App-V Administrators should have read/write permissions on the folder in

order to copy new packages to that location or to run a synchronization from
the Package Repository before adding them using the App-V Management
console.
 As a common sense name the share ‘content’. Most organizations did and
do it this way.
 It is easily possible to hide the App-V share from browsing

(\\server\content$). However in this case also administrators can’t just
‘browse’ for a package from within the Management console unless they
know the share name.
 Changing the file server or file share name afterwards requires to adjust all
packages that were previously added from the old file share name or to
modify the Client’s PackageSoureRoot Registry value.
Remember: The App-V Management Server machine accounts need read access,
all users and client computers need read access to the shared files.
WEB SERVER
Like for a file server implementation, the default configuration of a web server like
Internet Information Server will not be part of this book.
App-V specific configuration:
 Create a new Virtual Directory in IIS that points to a directory on the server.
 Add .appv files as a perceived MIME type to Virtual Directory within IIS as
described here in this section below.
 Do not enable Directory Browsing, neither on the top IIS level nor on the
Virtual Directory level. Because it is IIS 25 and not an individual user who
accesses the folders, there is no easy method to restrict access based on user
group memberships.
 Ensure that clients treat the Streaming Server URL as ‘local intranet’.
CREATE AN IIS VIRTUAL DIRECTORY FOR THE .APPV FILES
To allow downloading .appv files and to import configuration.xml files via IIS into
the management Database, a Virtual Directory has to be created that links to the
physical (file system) location. Our recommended best practice is to name this
Virtual Directory “Content”.
In the IIS Management console right-click the Default Website and select Add
Virtual Directory… (FIGURE 66)
25 Usually the System or Network account
Figure 66: IIS MMC - Virtual Directory configuration (1)
You’ll be prompted with a new window where you specify the name (Alias) and
Physical path for that directory (FIGURE 67). Avoid special characters in the
alias.
Figure 67: IIS MMC - Virtual Directory configuration (2)
Leave the other (default) settings and confirm with OK ; the new Virtual Directory
on IIS has been created.
ADD .APPV AS A MIME TYPE
Because IIS only offers files of known types we must tell IIS about the .appv file
format. This is done by adding a new MIME type.
To accomplish this, select the newly created virtual directory (content) in the IIS
Management console. The main window (FIGURE 68) will show you a set of
configuration items.
Figure 68: IIS MMC - Add new MIME Type (1)
Click on MIME Types brings up a list of know types, mostly inherited from the IIS
installation as shown in FIGURE 69. Just click anywhere in the right-hand pane and
choose Add...
In the next screen (FIGURE 70), add .appv (or appv without the dot) into the file
name extension field. Enter application/ms-appv as the actual type 26.
26 It doesn’t really matter what you enter here; in fact also application/zip would be fine, because
essentially .appv files are .zip containers. HTTP://EN.WIKIPEDIA.ORG/WIKI/MIME_TYPE lists some well-
known MIME types, the official registration is done by IANA
HTTP://WWW.IANA.ORG/ASSIGNMENTS/MEDIA-TYPES
As a result, the .appv extension should appear in the list. With this operation, a
web.config (xml formatted) file is placed into the virtual directory.
Important:
The < s e r v er n am e> \I I S_ I SU RS group has to have read access to the
web.config file. Ensure to adjust NTFS settings of the superi or
folder.
An example of NTFS permissions to the web based content share can be seen in
FIGURE 71.
Figure 71: IIS web.config NTFS permissions
M O N IT O R IN G
As Microsoft Application Virtualization might be the primary or at least a very
important delivery model for applications, it is critical to monitor App-V related
services to verify their availability. Though users might be able to launch
applications even if all servers have failed, this shouldn’t be your default mode of
operation. As a reminder you should refer back to the ERROR! REFERENCE SOURCE
NOT FOUND. sections above in the GENERAL ARCHITECTURE sub chapter.
Since Microsoft shifted from proprietary implementations to standard technologies

with version 5, monitoring has become easier than it was for the 4.x versions. In
essence, monitoring comes down to web service availability checks, pings and
Event Log parsing.
Because there is a variety of monitoring solutions available in the market and we

can’t address even the most relevant ones, this section will focus on some general
guidelines. The actual implementation then depends on the chosen solution,
whether it’s Microsoft System Center Operations Manager, HP Open View, IBM
Tivoli, Nagios, a homegrown solution or whatever suits.
IDENTIFY COUNTERS
The following ‘checkpoints’ could and should be monitored. Remember that no

Windows Performance Counter can really tell you if a feature is available. Also
Event Logs or Windows Service health checks are not really telling you if your
user can use or update App-V applications. However, here are some items you
should look at:
 Hardware counters
 Network Bandwidth, maybe Latency
 CPU Utilization
 Memory Utilization
 Disk I/O (or Queue length)
 Service Counters
 There are some IIS application specific counters, grouped under the
following sections of Windows Performance Counters. They do contain
specific entries for App-V related objects:
 A_POOL_WAS
 W3SVC_W3WP
 WAS_W3WP
 Web Service
 Service Monitoring
 You should verify that the following Windows services are active
 Server
 Windows Process Activation Service (not required for the

Streaming Server)
 World Wide Web Publishing Service (not required, if Streaming is

file based instead of web based)
 Event Log Monitoring
 The Event Log facility Application and Services Log / Microsoft

contains a dedicated section for App-V. Monitor its entries for errors
 Functional Tests
 From a client, try to get the list of applications (query the Publishing
Server) and download some well-known .appv files regularly. You also
might use the Client’s PowerShell interface to add/mount applications 27
DEFINE A BASE LINE
Collecting counters and errors is not enough: not every single error is a real issue
(but a bunch of errors occurring within an hour potentially is) and having a
number of 123.456 for a counter doesn’t tell itself if things are good or not.
Therefore, each of the counters that you want to observe needs a threshold that
marks the spot where things go critical (amber traffic lights) or wrong (red traffic
lights). While there are some easy ones (75%-90% CPU or Memory Utilization)
other ones are not that easy to define, such as for Disk I/O of the Streaming Server.
To identify realistic values for such counters, you should monitor the values in
three states: low (nothing happening), intensively used (a lot of users are working
with no issues) and overloaded. Then define your thresholds based on those
figures.
You should use tools such as the following to actually create or simulate load in
the environment 28.
 Denamik LoadGen (H T T P :// W W W . D E N A M I K . C OM / L O A D G E N . H T M L ),
 HP LoadRunner H T T P :// W W W 8. H P . C OM / U S / E N / S OF T W A R E -
S O L U T I O N S / S O F T W A R E . H T M L ? C OM P URI=1175451& J U M P I D = R E G _ R 1
002_ U S E N _ C -001_ T I T L E _ R 0003
 Login VSI (H T T P :// W W W . L OG I N V S I . C OM /)
27 But you’d have to wait for the next chapter of this book to learn how ;-)
28 Just use the one with the shortest URL - at least two of the authors would like you for that ;-)
Of course you also can start asking your users to help you here, but you shouldn’t
do so if they know your name, so using tools or robots is easier to handle.
SYSTEM CENTER OPERATIONS MANAGER INTEGRATION
Microsoft offers a Management Pack for its own monitoring solution, System
Center Operations Manager (aka MOM or OpsMgr). It can be downloaded from
HTTP://WWW.MICROSOFT.COM/EN-US/DOWNLOAD/DETAILS.ASPX?ID=38418 and
includes pre-created tests and categorizations. Note that the description of
Management Pack can also be used as a guideline for other solutions.
H IG H A VAI LA BI L IT Y AN D S CA L ABI L IT Y
In the SERVICE DISRUPTION IMPACT section we explained the effects of failing
components to the App-V application delivery chain, how to avoid them and what
technologies to use. On the next pages we’ll explain how to actually configure
components for HA scenarios.
Active
Directory
Streaming Server
Virtual Address Management Server
Virtual Address
MS SQL
Cluster
Publishing Server
Virtual Address
Reporting Server
Virtual Address
Figure 72: Scenario - High Availability
ACTIVE DIRECTORY
From a configuration perspective, nothing specific has to be done with App-V

components to make them aware of a fault tolerant Active Directory.
REQUIRED MODIFICATIONS AFTER CHANGING AD
Adding or removing a Domain Controller server to/from the Active Directory

domain is not an issue.
If you need to change your AD domain, well, then you should re-install and re-
configure all individual App-V Components (you probably need to do that for
almost all your Windows systems anyway, don’t you?).
MANAGEMENT DATABASE
Because the App-V Management Database is an important component in a Native

Infrastructure model we recommend establishing SQL failover by using an SQL
Cluster. Scaling can be achieved by improving the performance of individual SQL
server machines. High Availability also could be achieved using SQL Mirroring, as
described in APP-V 5 SQL MIRRORING CONFIGURATION.
The App-V Management service is the only component that connects to the
Management DB. Because it is not trivial to connect an existing Management
Server machine to an SQL cluster afterwards, it is strongly recommended to
establish that connection during the initial installation of the App-V Management
Server(s). Remember that only the script-based installation of the Management
Database is able to create a clustered database.
REQUIRED MODIFICATIONS AFTER CHANGING THE
MANAGEMENT DATABASE
If the database connection changes post-install (like from a single box to a

clustered SQL instance) you have to adjust Registry settings on the Management
Server(s):
In
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AppV\Server\ManagementService
adjust the following settings:
Value Name Set to
MANAGEMENT_DB_NAME <New_Database_Name>
MANAGEMENT_DB_SQL_INSTANCE <New_SQL-Server_Instance_Name>
<New_SQL-Server(cluster)_Name> \
MANAGEMENT_DB_SQL_SERVER
<Instance_Name>
MANAGEMENT_DB_SQL_SERVER_NAME <New_SQL-Server(cluster)_Name>
After these modifications, restart the IIS web application, IIS or the entire machine.
PUBLISHING SERVER
For some scenarios it might be acceptable that publishing information isn’t update
for a day or two, but most implementations will not allow for this , so HA is a
requirement.
Regardless of the load balancer’s actual implementation (that we discussed

earlier), the following settings and requirements should be applied:
 Plan and reserve a virtual IP address and a virtual server name for App-V
Publishing right from the beginning – even if you start planning for a single
machine only. Use that virtual server name in all configurations.
 Activate host affinity: Every connection established by a given client device

through the load balancer should be directed to the same Publishing Server
node. While this is not a technical requirement, it may allow the individual
nodes to cache certain information. 29
 Spread session load and determine availability based on service queries:

While it is OK to determine a node’s availability based on its network
connectivity (ping) only, it is recommended to use graceful requests to the
Publishing Server in order to determine if a node is really able to answer
requests. The response time of such a monitor also could be used as a metric
to redirect new requests to the fastest answering (hence least loaded) node.
(Remember that Windows NLB does not allow for such advanced tests).
 You may consider distributing load to the Publishing Server’s specific TCP
port only (and not to entire machines based on IP addresses), but that is not
required, though it would be more correct.
As for now, Microsoft has not provided any scaling information for the Publishing
Server. For a rough estimation expect that every client queries an XML document
from the Publishing Server during logon (and additionally at manual refresh
operations). Note that some configuration data may be as large as 5 MBs.
REQUIRED MODIFICATIONS AFTER CHANGING THE PUBLISHING

SERVER
If the Publishing Server address changes (like to a virtual load-balanced name), the
App-V Client configuration has to be adjusted.
This can be done by modifying the corresponding Registry value on the client
(HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AppV\Client\Publishing\Serve
rs\<ID>: URL value); directly, by using the App-V Client ADMX or with
29 It also may make troubleshooting easier, esp. in test and pilot deployments. If the load Balancer
directs all requests from a given client to the same node, also ‘admin’ requests like an RDP
connection would be directed to the same node as the App-V publishing requests.
PowerShell Set-AppvPublishingServer command with the URL para… hey,

hey, wait…. There is no input parameter that lets you set the URL directly, so you
might need to remove and then re-add the Publishing Server configuration on the
clients (didn’t we just say that you should plan for HA configurations right from
the beginning?) – or you change the value in the Registry.
Remember that you have to add each new Publishing Server to the Management
DB using the Server Management console, but you don’t need to add a virtual
name to that list.
MANAGEMENT SERVER
Like the Publishing Server, the Management Server is an IIS application: High
availability and scalability can be achieved by using a simple web load balancer or
even Microsoft NLB. Because only Administrators and the Publishing Servers
access this service, it usually does not warrant such scalability.
REQUIRED MODIFICATIONS AFTER CHANGING THE
MANAGEMENT SERVER
You have to re-configure each Publishing Server to point to the modified

Management Server URL. To do so, modify the PUBLISHING_MGT_SERVER Registry
value at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AppV\Server\
PublishingService.
Also you have to tell your administrators that they should connect to a new URL.
STREAMING SERVER
Depending on the actual implementation, the availability requirements for the

Streaming Service may vary. In a scenario where .app-v files are fully loaded into
the client’s cache and only a few changes or updates are applied, the availability
and performance of the Streaming service doesn’t have to be that high. If, on the
other hand, the Shared Content Mode is implemented, access to .appv files must
be guaranteed for the entire operation so it has to provide very high performance
and availability.
Estimating load depends on a set of different parameters, like the amount of

clients and users, package update interval, whether the packages are reasonably
consistent on a client device or change often. The Shared Content Store model of
course has a major impact on such a calculation as well.
Based on the technology you have chosen for the .appv file delivery achieving HA
and scalability is different as well.
FILE BASED STREAMING
Use well-known technologies like (Windows) File Server Cluster or Distributed

File System (DFS) to achieve scalability and high-availability. To reduce network
consumption, esp. in smaller subsidiaries, you may use file caching technologies
like Microsoft BranchCache or Citrix Branch Repeater (CloudBridge).
WEB BASED STREAMING
To configure a highly available web server, just follow the instructions given for
the Publishing Server above… it’s just a web server.
CONTENT REPLICATION
Unlike common Software Distribution systems, App-V does not have a built-in
method for replicating package files (content) across several App-V Streaming
Servers. Therefore, you have to find an appropriate solution that copies the
package files from the central Package Repository down to each Streaming Server.
The most common methods are Robocopy and DFS-R (Microsoft Distributed File
System Replication). Both methods have their advantages and disadvantages;
selecting one of them potentially depends on your attitude.
Note for both methods that your replication source (or first replication target)
should be the node ‘close’ to your Management Server so that you can start
importing apps even when they haven’t replicated entirely.
Imagine the following: You copy a package directly to StreamingServer_A and

initiate the replication process (DFS-R or Robocopy). Then, you open the App-V
Management console, import a new package (section ADD APPLICATION tells you
how) and point to the virtual Streaming Server Name (because you have to get the
‘right’ entry into the database). And because it is a virtual name, ‘some’ process
decides that you are directed to StreamingServer_B – but on Server_B, the new
package has not yet arrived (replication is still in progress) so you can’t select the
new package file. Or even worse, some technologies show you a placeholder for a
yet-to-arrive file, but then import fails (or your .app-v file is already there, but the
configuration XMLs aren’t… you name the issues).
One way to overcome this would be to use nasty hosts files on your admin
machines, telling that <virtual Streaming Server> name always points to
StreamingServer_A – or you ensure that your load balancing solution / DFS name
space or so always points every request from a given client (your admin PC) to a
given target (StreamingServer_A) – which is not easy, though, because you might
be using different technologies.
REQUIRED MODIFICATIONS AFTER CHANGING THE STREAMING

SERVER
Changing the Streaming Source after adding packages would require some work,
because the streaming URL/UNC is stored for each package in the Management
Database, PackageVersions table. Because the path is not visible in the
Management console, you can’t modify it there. Also the PoSh commands don’t
provide for changing just the URL. Thus one method would be to adjust all the
paths directly in the Management Database.
Luckily there’s another option by telling the Client to ignore the original URL and
download/stream the package (and configuration files) from another server
instead. There is a Client Registry setting called PackageSourceRoot that can be
used to override the source URL. It is located at
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AppV\Client\Streaming and can
also be set via Group Policies / ADMX template. A downside of that method is that
some entities may show the original URL (like the database, the XML files which
are transferred between the Publishing Server and the Client), while the active
download location is somewhere else.
C O M MUN I CAT IO N S EC U RIT Y

As App-V 5 uses industry-standard technologies for communication it should not
be necessary to dive deeply into its secure configuration.
The following table summarizes the common communication between App-V

components. In the section below we’ll discuss how they can be secured.
Remember that some of the technologies depend on your infrastructure design –
namely you’d probably have SMB or HTTP to download packages from the
Streaming Server.
App-V Client
Management
Management
Server
Publishing
Streaming
Reporting
Reporting
Directory
Database
Database
Active
Server
Server
Server
Server
Client
App-V HTTP
 HTTP HTTP    KERB
Client SMB
Publishing
    HTTP   KERB
Server
Streaming
       KERB
Server
Reporting
      SQL KERB
Server
Management HTTP
    SQL  KERB
Server SMB
Management
       KERB
Database
Reporting
       KERB
Database
Active
       
Directory
Admin’s
    HTTP   KERB*
Browser
(*) indirectly, during user logon
In this table, the component in the first column (the client) establishes a connection
to the components listed in the other columns (the server). In fact often the
majority of data packages go from the server to the client. Note that the App-V
Publishing Server acts as a type of client when connecting to the Management

Server.
To streamline this document, some explanations about SSL Security have been
placed in the APPENDIX.
ACTIVE DIRECTORY
Kerberos based communication is encrypted by default using industry-standard

technologies 30. While there is no App-V specific configuration required, you
should be aware that Microsoft updates its Kerberos implementations from time to
time. Therefore it might be possible that clients and servers can’t communicate
with each other if they don’t share the same encryption methods 31 (like when you
enforced the latest security feature). However, such deviation doesn’t play a big
role amongst the supported operating systems for App-V components.
MANAGEMENT DATABASE
While the communication to SQL Servers (and Clusters) can be encrypted using
SSL, Microsoft has not yet disclosed any information on whether this is a
supported scenario for the App-V Management Server. It might be possible to
30 What is Kerberos Authentication? HTTP://TECHNET.MICROSOFT.COM/EN-

US/LIBRARY/CC780469(V=WS.10).ASPX
31 Windows Configurations for Kerberos Supported Encryption Type
HTTP://BLOGS.MSDN.COM/B/OPENSPECIFICATION/ARCHIVE/2011/05/31/WINDOWS-CONFIGURATIONS-FOR-
KERBEROS-SUPPORTED-ENCRYPTION-TYPE.ASPX
enable SSL on the SQL Server as described in a TechNet article 32. Because the
App-V Management Server’s Registry refers to FQDNs instead of short server
names, chances are there that the entire communication can be encrypted. Since
the initial communication (namely the authentication) is always automatically
encrypted anyway, there is only a limited benefit of encrypting the entire
communication.
The stored database itself can also be encrypted. This can be achieved on the file
system level (using BitLocker or EFS) or by using Transparent Data Encryption
(TDE 33), which was introduced with SQL Server 2008 Enterprise Edition and
basically provides the same level of security as BitLocker and EFS (when you look
at the data on the disk/file level, you only see encrypted information. When you
look at the data from within SQL Server (with Management Studio, OSQL, SQL
Query), that data is not encrypted.
SQL Server also supports cell encryption, but since the application (App-V) would
have to be aware of that it can’t be used for the App-V Management Database.
PUBLISHING SERVER
As the Publishing Server is an IIS web application, communication to it can be

secured using SSL. A Server Certificate has to be installed on the server machine,
and it has to be bound to the Publishing Server web applications using a dedicated
port. The Common Name on the Server Certificate has to be the Full Qualified
Domain Name that App-V clients use to connect to that server. On the client, the
Registry value HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AppV\Client\
32 Encrypting Connections to SQL Server HTTP://MSDN.MICROSOFT.COM/EN-

US/LIBRARY/MS189067(V=SQL.105).ASPX
33 Database Encryption in SQL Server 2008 Enterprise: HTTP://MSDN.MICROSOFT.COM/EN-
US/LIBRARY/CC278098(V=SQL.100).ASPX
Publishing\Servers\<ID>: URL has to be adjusted and the client machine has to

trust the server certificate’s issuer/CA (by installing a root/intermediate certificate).
MANAGEMENT SERVER
The Management Server is an IIS web application, so it can be secured using

basically the same methods as for the Publishing Server. There are several
components that interfere with a secured Management Server. One is the App-V
Publishing Server installation that acts as an SSL client. Therefore, all Publishing
Server machines have to have the root/intermediate certificate installed that
establishes trust to the issuer of the server certificate used by the Management
Server web app. Also, the Publishing Server’s Registry value
PUBLISHING_MGT_SERVER has to point to the secure protocol + FQDN + port.
Another component is the App-V Management console hosted on the

Management Server (which is accessed by admins from within a browser
potentially from another machine). Admins should be instructed to access the
console using HTTPS + FQDN + port for a secure communication. The
root/intermediate certificate is required on all machines where App-V
administrators want to open a web browser to connect to the Management Server’s
Silverlight console.
Note: You can and should enforce the usage of SSL connections to the
Management console if you have to ensure a secure communication. If you don’t,
admins may open the console’s URL over HTTP. The Appendix outlines how to
achieve this.
FIGURE 73 shows a screenshot of a secure connection to the Management console

but apparently something went wrong with the PowerShell cmdlet.
Figure 73: Secured Management console connection
As you can see, PowerShell can’t connect to the App-V Management Service any
longer, though it’s running on the same machine. The trigger that caused that error
was SSL enforcement.
To allow the PowerShell cmdlet to connect, the Management Server’s Registry has
to be adjusted at HKLM\Software\Microsoft\AppV\Server\
ManagementService.
To place emphasis on a repeated statement: Just changing the protocol and port
isn’t enough.
Figure 74: Incorrect URL specification
Because the given server name does not match with the CN of the Server
Certificate (= the FQDN of the machine), PowerShell still would fail.
Figure 75: Incorrect URL PowerShell error
Remember to always use the FQDN when you poi nt to a secured

server.
STREAMING SERVER
FILE SERVER
If the Streaming Server is accessed using SMB, the encryption capabilities depend
on the SMB version. In SMB 3 (Windows 8, Windows Server 2012), the
communication to file shares can be easily encrypted by activating a check box in
the share’s properties dialog 34. However non-SMB 3 devices won’t be able to
access that share. In SMB 2, the initial authentication uses encryption, but the
actual data transmission would need some underlying security technologies like
IPSec or hardware encryption to be protected. While older SMB implementations
don’t offer encryption, SMB signing can at least be activated via Group Policy 35.
All clients and the Management Servers would potentially establish a secure
connection to the package store.
WEB SERVER
It is not surprising that a web based streaming source can be secured with the
same methods as the other web based features of App-V: SSL. Note that the App-V
Management Server machine (namely via the Management console during
package import) and all clients have to establish a secure connection to the
Streaming Server and would hence require a valid root/intermediate certificate.
Because there is neither a client nor a Management Server configuration specifying

the path to the Streaming Server, there is no setting to adjust. However when
importing a package with the Management console, the secure path has to be
specified. For previously imported packages the path would require adjustments
34 http://blogs.technet.com/b/filecab/archive/2012/05/03/smb-3-security-enhancements-in-windows-
server-2012.aspx
35 Since only the communication (and not the original files) is signed, the added value is quite
limited.
for every package in the Management Database directly (but because you do your
planning in advance and as careful as us, later adjustments shouldn’t be required,
right?)
C O N F IG U R AT I O N AN D M O N IT O RIN G B ES T
P RA CT IC E S
We recommend:
 Use only groups (not individual users) for any permission assignments;
follow the AGDLP principle
 Do not modify the _WEBSITE_NAME nor _WEBSITE_PORT Registry settings for

the Management, Publishing or Reporting services unless you changed the
corresponding port in IIS as well. Remember that package URLs, client
connection parameters and the Publishing Server configuration contain
references that may include such ports and would require further
adjustments.
 As the streaming source, a web server is preferred to a file server. Past tests
have shown that HTTP file transfer appears to be much faster than SMB
transfers. This may, however, change with SMB 3.
 For a faster publishing of configuration changes in test environments adjust

the Publishing Server’s PUBLISHING_MGT_SERVER_REFRESH_INTERVALL
value.
 Monitor the server component’s Event Logs for errors, the general network
availability via ping and service availability via customized HTTP requests
with a given user account and result validation. Monitor the Streaming
Server’s Disk I/O
 Plan high availability for all components right from the start: It is easier to
configure a Load Balancer with just one node than re-architecting the
environment from a one-node scenario to a load balanced solution
 Plan your highly available environment using industry-standard

technologies:
 Publishing Service: Windows Network Load Balancing or 3rd party (Web)

Load Balancing
 Management Database. SQL Cluster
 Management Service: Windows Network Load Balancing or 3rd party

(Web) Load Balancing
 File based Streaming: Scale-out File Cluster, DFS or a highly available 3rd
party file server with SMB 2 and SMB 3 support
 Web based Streaming: Windows Network Load Balancing or 3rd party

(Web) Load balancing
 Reporting Database: SQL Cluster
 Reporting Service: Windows Network Load Balancing or 3rd party (Web)

Load Balancing
 Co-hosting: Do not run the SQL database on any of the App-V servers. Co-
locate the Publishing, Management and Reporting services on a single
(virtual) machine; consider a separate machine for the streaming feature.
 For a highly available co-hosted scenario, do not load balance the services
individually (Publishing on machine A  Management on machine B), but
the entire machine (Publishing on machine A  Management on machine A).
Administration for App-V Management Server
2.4 A DMINISTRATION FOR

A PP -V M ANAGEMENT
S ERVER
S TAN D ARD O P E RAT IO N S

As part of using the App-V Management Server, there are several operations that
can be performed to manage applications. All of them will be explained below,
both from a perspective of using the web-based console as well as via PowerShell
cmdlets. To access the web-based console you can logon to the server and look for
a shortcut named Application Virtualization Management console on the Start
menu or Start screen. Usage of the console requires that the Silverlight plugin is
installed, even though it is not suggested during the installation of the App-V
Management Server. If you attempt to access the management console without
Silverlight installed, you will be prompted to install it.
Before we dive into the actual doing of things, here are a few basic steps to enable
the use of PowerShell that is vital to our explanations below.
POWERSHELL
Run the below PowerShell command to see the list of available PowerShell
Modules:
Get-Module –ListAvailable
Figure 76 Get-Module -ListAvailable
Validate that the AppVServer module is available like in FIGURE 76 GET-MODULE -

LISTAVAILABLE.
To import the AppVServer module, you must first loosen the execution policy by
running the following command. This needs to be executed with Administrative
permissions;;
Set-ExecutionPolicy RemoteSigned
Continue by importing the App-V 'Server's module;;

Import-Module AppVServer
Once the module is imported, you can list all the management commands
available by running the below command;;
Get-Command –Module AppVServer
Figure 77 Get-Command - Module AppVServer
This will produce a list of possible commandlets that can be used with the App-V
Management Server. Let's continue with specific operations within the App-V
Management Server.
PACKAGE MANAGEMENT
A vital part of the App-V Management Server is to deliver applications and

therefore we will iterate through the possible ways we can manage applications
within the web-based console of the App-V Management Server.
A file-share has been setup that is readily available through out the use of this
entire chapter, also known as our package repository. For purposes of later
discussion in this section, we have placed three different App-V packages on the
file-share to be used as examples (see FIGURE 78 FILE share).
Figure 78 File share
OVERVIEW
Lets present an overview of the steps that can be performed for the management of
our packages
Enable an application;;
1. Import the application package
2. Assign the application package to one or multiple AD-groups
3. Publish the application package
Disable an application;;
1. Unpublish the application package
2. Remove assignment to the application package
3. Remove the package
Edit / Upgrade a package;;
1. Add an updated version of a package
2. Edit configuration of a package
ADD APPLICATION
MANAGEMENT CONSOLE
When you first start the App-V Management Server web-based management
console you are directly presented with the view of the packages and applications
currently imported to the system. The initial setup (unlike the previous App-V 4.5
Management Server) does not have any example packages imported for quick
streaming and client testing, therefore the view is empty (FIGURE 79 APP-V
MANAGEMENT SERVER CONSOLE)
Figure 79 App-V Management Server Console
To add a new package you can simply click the ADD OR UPGRADE PACKAGES in the
upper right-hand corner. Adding a package will not readily make it available for
clients, as it is simply an entity within the App-V Management Server. To make it

actually available for clients we will need to assign it to users and publish it, steps
which will be explained a bit later.
Choosing adding or upgrading package will present a dialog to select a package

from our package repository (see FIGURE 81 SELECT PACKAGES DIALOG).
Figure 80 Add or upgrade packages dialog
You can browse to the package using the UNC path or via URL to a possible web
server. In this case the package is located on a UNC-path. The path selected is the
final path which the client will use to retrieve the package from. A good practice is
to select the proper path – UNC or URL – from the beginning.
Figure 81 Select Packages dialog
Once the package is selected you can click Add . A progress indicator will show the
status of importing packages’ metadata into the database.
Figure 82 Progress indicator for adding a package
You can also choose to add multiple packages by simply clicking on Browse
repeatedly and locating multiple files. Any new files selected will be appended
onto the list of packages to process. (FIGURE 84 PROGRESS OF MULTIPLE PACKAGES)
Figure 83 Multiple packages selected
The package paths are separated by a semicolon. Our experience so far is that there
isn’t a limitation on how many packages you can add in a single run.
Figure 84 Progress of multiple packages
The progress of adding each package will be presented as soon as you click Add .
Once you click Close you can see your newly added packages listed, and if you
right-click a package you are presented with options pertaining to that package
(FIGURE 85 PACKAGE OPTIONS).
Figure 85 Package options
These options provide possible ways of editing the configuration of a package and
making it available to different users. Let's briefly go through the options
presented in FIGURE 85 PACKAGE OPTIONS.
Publish will make the package available for clients.
Edit active directory access allows us to define a security group that the
application will be available to. Each granted AD access can have a separate
configuration.
Edit default configuration will alter the default configuration (can only be
the Deployment Configuration) for the package.
Transfer default configuration from.. will copy the configuration options

from a previous state of the same application.
Transfer access and configurations from.. will copy the configuration

options and security group assignments from a previous state of the same
application.
Delete will remove the entire package, including all assignments and
configurations.
POWERSHELL
In PowerShell, the command to add an application (or rather a package) is

Import-AppVServerPackage and it’s quite easy to use. Below is a sample
command that corresponds to the action we just performed using the console.
Import-AppvServerPackage
\\filesrv.demo.lab\content\InstEd\InstEd.appv
Output after running the command can be seen in FIGURE 86 IMPORT-

APPVSERVERPACKAGE.
Figure 86 Import-AppVServerPackage
This output can be used later on when handling the package and indicates a
successful import. You can also verify what packages are available by using the
verb “Get”.
Get-AppVServerPackage
This will produce a list of all packages. (FIGURE 87 GET APP-VSERVERPACKAGE)
Figure 87 Get App-VServerPackage
PUBLISH APPLICTION
Before you make the application available to clients you need to specify who will
have access to it and how it is going to be configured.
You can assign access to a security group only, but not directly to either user
objects or computer objects. Right-click on the application and choose edit
active directory access (FIGURE 88 EDIT AD ACCESS).
Figure 88 Edit AD access
You can search for an full security group by entering domain\group-name (FIGURE
89 ASSIGN AD GROUP) and clicking Check or pressing the Enter key. If you do not
enter the full name of a group it will begin a search for matching group names.
Figure 89 Assign AD Group
When searching for security groups you will be presented with a list of possible
options. See example of a search in FIGURE 90 SEARCH FOR AD GROUPS.
Figure 90 Search for AD Groups
Click Grant Access (FIGURE 91 SECURITY GROUP LOCATED) to assign the

application to the security group. You can make both users and computer Active
Directory objects part of the security group and allow the client to receive the
application based on both object types.
Figure 91 Security Group located
When you have clicked Grant Access it will become grey and be assigned to the
application. You can choose to DELETE it, Edit Default to modify the
configuration or Close to go back to the general view of the application.
Default Configuration is a computer-based default set of options for a package.

The more simple options are to enable shortcuts, which can be done from within
the management console. There are far more options than that and more complex
topics (such as scripts and Registry entries) can be implemented in the Sequencer
generated file _DeploymentConfig.xml. This entire file can be imported into the
console for the Default Configuration. If you click Edit Default you have the
option to import the file.
Important: The Deployment Config configuration file will not

automatically be picked-up when import ing a package.
To delete an AD group assignment you can remain in this view and see the list of
currently assigned AD groups. Each AD group can have a different configurations
assigned to an application that you can easily alter. If you want to delete a single
or multiple AD groups you can simply check the box on the left of the AD
group and then click the top-column name DELETE (FIGURE 92 EDIT AD GROUP).
This will trigger a confirmation dialog and will also remove the configuration
created.
Figure 92 Edit AD Group
You can verify the properties of the application after you press close and verify
that the security group is visible (or not visible if removed) under AD ACCESS of
the package properties (FIGURE 93).
Figure 93 Package properties
POWERSHELL
Granting access to an application using PowerShell cmdlets is a single line

operation and can be performed with Grant-AppVServerPackage. There are
several parameters that need to be passed to it – for example PackageID,
VersionID and Groups.
Grant-AppvServerPackage -PackageID 6d7ec20c-14ed-4317-8744-

5f389e418fdb -VersionID 9158516c-21f9-4803-9664-481c0edf3813 -
Groups DEMO\SG.AppV.U.InstEd
The PackageID and VersionID can be identified using the Get-

AppVServerPackage cmdlet. You can also place these two commands in a single
command line to avoid having to manually extract the GUIDs for different
properties and reenter them on a different cmdlet.
\\filesrv.demo.lab\content\InstEd\InstEd.appv | Grant-
AppvServerPackage -Groups DEMO\SG.AppV.U.InstEd
To make the application available for clients there is a final step to perform. This
basic On/Off button is an easy way to make it appear or disappear on the clients,
regardless of how many security group assignments there are. Right-click the
application and choose Publish (FIGURE 94 PUBLISH APPLICATION) to make the
application available.
Do notice that if the application is part of a Connection Group (which will be

discussed later), it can still be published to clients even though it is in an
unpublished state.
Figure 94 Publish application
There are no confirmations that an application will be published, but rather once
the action is completed it will show a green icon with the word “published” under
status (FIGURE 95 ONE PUBLISHED APPLICATION). The package is now available to
clients as soon as the Publishing Servers refresh their data against the Management
Server.
Figure 95 One published application
POWERSHELL
To publish the application using PowerShell you can use the cmdlet Publish-
AppVServerPackage. The Publish-AppVServerPackage only requires the
identification of the package you want publish and then it will toggle the
publishing state. Parameters to identify a package are PackageID and VersionID.
Publish-AppVServerPackage -PackageID 6d7ec20c-14ed-4317-8744-

5f389e418fdb -VersionID 9158516c-21f9-4803-9664-481c0edf3813
To avoid to manually extracting the GUIDs for PackageID and VersionID you can
pipe the previous resulting objects to the next cmdlet using a single line:
\\filesrv.demo.lab\content\InstEd\InstEd.appv | Grant-
AppvServerPackage -Groups DEMO\SG.AppV.U.InstEd | Publish-
AppVServerPackage
UPDATE AN APPLICATION
MANAGEMENT CONSOLE
In order to provide an updated application via the App-V 5 Management Server,

you first need to do an actual update against one of the previously created
packages using the App-V Sequencer or other compatible packaging tools. With a
Sequencer set with default options, updated and subsequently saved packages
have names with a suffix matching the version number of the package. Updated
packages keep their Package GUID, but get a new Version GUID.
For clarity the folder carrying the updated package in the example below also has
the suffix appended to its name, although this is not something that Sequencer will
do for you. The version number of our package becomes 2 on a first update done
against it, and therefore all the files making up the package will have _2 appended
to the file name as depicted in FIGURE 97 UPDATED PACKAGE FILES.
Figure 96 File-share with updated package
Figure 97 Updated package files
In the management console, the steps to update a package are very similiar to
adding a new package. We click on the ADD or UPGRADE PACKAGE from the
management console.
Figure 98 Package overview
Now simply select our newly generated APPV file with the name InstEd_2.appv
and click Add (FIGURE 99 ADD OR UPGRADE PACKAGES).
Figure 99 Add or upgrade packages
Once the addition into the database is complete, a few new options will be
presented.
This happens because the package GUID is the same as for the original package,
however the version GUID is different making it as new revision of the same
package. The App-V Management Server will therefore detect that this is an
upgrade of an already existing package within our environment. You can choose
to copy any assigned AD Access and configurations from the previous package
and choose to Apply those via Apply Upgrade Options (FIGURE 100 PACKAGE
UPDATE IMPORT PROGRESS).
As you may also want to reuse the previous configuration, choose to check Copy
access and configurations from previous version and click Apply
Upgrade Options . Once that is completed you can safely click Close .
Figure 100 Package Update Import progress
You can now see that there are two entries for InstEd package, with different
version numbers to them. Our newly added version is not yet published and
therefore it is not available to any clients which will continue to see only the
original one. This gives you the time to verify that the AD Access and
configuration has followed along to our new package, modify it according to new
requirements if necessary and perhaps perform any other tasks you wish to
complete before it is made available for the endpoints running the virtual
application in the package.
Figure 101 Package overview updated package
Select the package shows that the AD Access is the same as for version 1 of the
package.
Figure 102 Properties of upgraded package
Once the new version is published it will become available to all workstations or
users associated with it. Since you can assign different active directory groups to
the original package and the updated package, there is a possibility to do a
gradual move to a new version or staged update. Server will only present the
highest version of a package to a client if multiple active versions exists, and the
client will also only use the highest version of any package with the same GUID.
Within the App-V 5.0 RTM release that has been available since November 2012
there was an issue on the client where an updated package could not be added
during a publishing refresh for an account with only User privileges. Performing a
publishing refresh as a user with Administrative privileges then allowed the
package to be added. App-V 5 hotfix 1 has been released to address this topic and
can be requested from Microsoft. Original KB-article can still be downloaded,
however App-V 5.0 Service Pack 1 also remediates the issue 36
REMOVE A PACKAGE
There are multiple ways to ensure that an application will no longer be visible;
 Unpublish the application
 Remove AD group access
 Remove the application
Removing the application is the only way to 100% ensure that it

can not be deployed or used anymore, even within a Connection
Group.
MANAGEMENT CONSOLE
A package can be decommissioned in different phases to allow for a possibility of

rollback, but you can also remove a package entirely straight away.
If you right-click a package from the management console you immediately see
two options that handle the package removal phase differently (FIGURE 103
PACKAGE OPTIONS - REMOVE PACKAGE).
36 HTTP://SUPPORT.MICROSOFT.COM/KB/2799153
Figure 103 Package options - remove package
The first option, which is only available if a package is published, is unpublish .

This will remove the possibility of clients receiving or using the package. If a client
has the package it will be unpublished upon the next refresh, unless it is part of a
deployed Connection Group. Clicking unpublish will not request confirmation
before it goes into effect, however it will only be effective once the Publishing
Servers have refreshed their data against the Management Servers
Delete package will request a confirmation before the change goes into effect, and
it will delete a package from the database regardless of whether it's published or
not. It will not delete any files on a file server or web server; the files must be
removed manually if you want to retire the package completely.
The confirmation will not – unfortunately - clarify which version of the package is
going to be deleted, but only presents you with the package name. (FIGURE 104
CONFIRMATION TO DELETE PACKAGE)
Figure 104 Confirmation to delete package
You should note that any configurations tied to the package will also disappear if
you choose to delete the package.
POWERSHELL
Using PowerShell you can both delete and unpublish the package just like in the
web console.
Let's first identify which package to delete. Using Get-AppVServerPackage you

can see a list of all packages and to clarify which package to operate on, you can
use the parameters -Name and -Version. Lets retrieve the updated InstEd package
and unpublish it.
Get-AppVServerPackage –Name insted –Version 0.0.0.2
You can then parse this package to Unpublish-AppVServerPackage to alter its

published state.
Get-AppvServerPackage -Name insted -Version 0.0.0.2 | Unpublish-
AppvServerPackage
If you wish to perform this on all of our InstEd packages to ensure that no version
is available for the clients, you can remove the -Version parameter.
Get-AppvServerPackage -Name insted | Unpublish-AppvServerPackage
The output provided by running the command will show us that all InstEd
packages have been unpublished.
Figure 105 Unpublish-AppVServerPackage
Like many of the other cmdlets you can also identify packages using PackageGuid
and VersionGuid to improve accuracy of selecting packages. As the demonstration
shows, just using the -Name parameter may not limit the selection to a single
package.
Using the Remove-AppVServerPackage you can just as easily delete the package
from our App-V Management Server.
Get-AppvServerPackage -Name insted -Version 0.0.0.2 | Remove-
AppvServerPackage
No output is generated to confirm which package or packages are removed, so be

sure that you accurately target your package, or you can append the –verbose
parameter to receive output. You could use PackageGuid, VersionGuid or Package
ID as parameters for the Remove-AppVServerPackage to refine a selection of the
package to a specific instance. Each imported package has an unique ID, which can
be viewed with Get-AppVServerPackage.
CONNECTION GROUPS MANAGEMENT
Connection Groups allow packages to interact with each other at runtime, linking
them together in a shared virtual environment.
In the App-V Management Server, a Connection Group is treated as its own entity,
just like a package. Once assigned to a group that Connection Group will bring in
tow all of the packages that are assigned to it even if they are unpublished.
Package priority configurations requires at least Hot Fix 1 for

App-V 5 SP1 37.
CREATING AND PUBLISHING A CONNECTION GROUP
MANAGEMENT CONSOLE
The Connection Group node is not visible when you open the management
console for the first time, as you are redirected to the Packages node immediately.
Figure 106 Connection Groups menu
37 HTTP://SUPPORT.MICROSOFT.COM/KB/2873465.
By choosing the Packages-node on the left hand side you are presented with the
new text options: Packages and Connection Groups (FIGURE 106 CONNECTION
GROUPS MENU).
Figure 107 Connection Groups overview, empty
The Connection Groups overview looks very much like the general Packages
overview and you can become familiar quite easily with the interface. Click the
ADD CONNECTION GROUP in the upper right hand corner to create a new
Connection Group (FIGURE 107 CONNECTION GROUPS OVERVIEW, EMPTY)
Figure 108 Connection Group overview - newly created group
A New Connection Group v1 will be created, but not yet published. (FIGURE 108
CONNECTION GROUP OVERVIEW - NEWLY CREATED GROUP) All its properties will be
blank until they are configured. Let’s rename the Connection Group by double-
clicking the name New Connection Group. You can add packages by clicking EDIT
within the CONNECTED PACKAGES column.
Figure 109 Connection Group - edit packages
The view to add packages (FIGURE 109 CONNECTION GROUP - EDIT PACKAGES) will
be presented at the bottom of the window and is quite simple. It offers the entire
library of packages on the right hand side, but unfortunately there is no possibility
to filter which packages are seen. You can select one package at a time and click
the arrow pointing towards packages to add them to the Connection Group.
If the packages you assign to the Connection Group already have an AD ACCESS
entitlement setup it is possibile to copy this configuration to the Connection
Group. If there is a small number of packages (in the above figure we will only
assign Java and Freemind) this can be easy to grasp, but if adding a large amount
of packages it will be a challenge to understand how many AD groups actually
will be assigned until you click Close . Since you haven’t published the newly
created Connection Group yet, an excessive amount of assigned AD Groups will
not impact anything, but it’s perhaps a good idea to review afterwards in any case.
More important is understanding how ordering impacts the deployment of

packages. If there is a conflict between packages when it comes to a virtualized
Registry key (or rather, Registry values) or a virtualized file, the package higher up
the list will have precendence over any packages below it. In essence; top package
wins.
Once all our configurations are set you can choose to publish the Connection
Group and thereby make it visible to the clients. Simply right click the Connection
Group and choose to Publish it (FIGURE 110 CONNECTION GROUP RIGHT-CLICK
OPTIONS). The status will toggle from a black icon to a green icon to indicate that
it's now available.
Figure 110 Connection Group right-click options
POWERSHELL
The method of establishing a new Connection Group within the App-V

Management Server is quite straightforward, but is divided into several steps.
Let’s begin by creating the Connection Group with the cmdlet New-
AppvServerConnectionGroup. The only parameter necessary for this command is
the name of our Connection Group.
New-AppvServerConnectionGroup –Name FreemindPowerShell
Figure 111 New-AppVServerConnectionGroup
The server will generate both a GroupGuid and VersionGuid and as the output in
FIGURE 110 CONNECTION GROUP RIGHT-CLICK OPTIONS shows, there aren’t any
packages or AD groups assigned to the Connection Group just yet. You can
continue to assign an AD group by using Grant-AppvServerConnectionGroup
command, which requires that you provide it an identifier to which Connection
Group you want to grant the permission to.
To be certain that you are dealing with the right Connection Group, we
recommend to use the GroupGuid and VersionGuid, but in smaller environments
you can go ahead with specifying just a name.
Grant-AppvServerConnectionGroup -GroupID ad256877-7231-4b67-b311-

716566b1ad0b -VersionID bfb5ac76-f730-4928-8c58-af3370ad2bc6 -
Groups DEMO\SG.AppV.U.Freemind
The output will be almost the same as previously shown from New-
AppvServerConnectionGroup and should additionally clearly show the new AD
group assigned.
The next step is to add packages to our Connection Group. Packages can be
assigned using the Set-AppvServerConnectionGroup and the parameter
AppvServerPackage. Unfortunately, this parameter is too ambiguous and
therefore it is recommended to get packages using the Get-AppvServerPackage
and pass the information onwards to the Set-AppvServerConnectionGroup.
Get-AppvServerPackage -PackageID f795cc32-c151-442d-b149-

fd7bb221b5da -VersionID 277205ec-c73e-47bf-b6d8-51852cec1253 |
Set-AppvServerConnectionGroup -GroupID ad256877-7231-4b67-b311-
716566b1ad0b -VersionID bfb5ac76-f730-4928-8c58-af3370ad2bc6
The above example will fetch the Java package that was previously created and
pass on the information to Set-AppvServerConnectionGroup, and make it part of
the Connection Group. Using the AppvServerPackage property you can also use
the Get-AppvServerPackage cmdlet to insert packages.
Set-AppvServerConnectionGroup -GroupID ad256877-7231-4b67-b311-

716566b1ad0b -VersionID 0153305e-ad50-4343-9597-b6c283b74999 -
AppvServerPackage (Get-AppvServerPackage | where { ( $_.Name -
eq "Java") -OR ( $_.Name -eq "Freemind" ) } )
Once you run the above command and make a change to the Connection Group, a
new VersionID will be generated for the Connection Group and both Java and
Freemind will be added to the Connection Group. One potential issue that you
could be looking at is the lack of control in ordering the packages. When utilizing
the web-based administration console you can clearly see in what order packages
are added.
To publish the Connection Group use the Publish-AppvServerConnectionGroup

cmdlet and specify either the Name or the PackageID and VersionID.
Publish-AppvServerConnectionGroup -Name FreemindPowershell
This will toggle the Connection Group to a published state and make it available
as soon as the Publishing Server has refreshed against the Management Server.
UNPUBLISH AND REMOVE A CONNECTION GROUP
MANAGEMENT CONSOLE
Removing a Connection Group can be done in two different ways. To allow for a
fast rollback we always recommend to unpublish the Connection Group. Just as
the packages are handled this way, Connection Groups can be unpublished and
thereby made unavailable for all clients, but still have their configuration intact
and available for re-publishing later if needed.
If you right-click on the Connection Group you can simply choose to Unpublish it
and have its publishing state toggled.
To remove the Connection Group and loose all configurations related to it, you can
right-click on it and choose Delete . This will generate a confirmation prompt
(FIGURE 112 CONFIRM DELETE OF CONNECTION GROUP) to acknowledge that you
want to remove it. Once removed, all configurations will be deleted.
Figure 112 Confirm delete of Connection Group
POWERSHELL
Just as with performing the removal of a Connection Group via the management
console, we recommend unpublishing the Connection Group first. Use the
Unpublish-AppvServerConnectionGroup which can accept the parameters
PackageID and VersionID or Name.
Unpublish-AppvServerConnectionGroup -Name Freemindpowershell
This will provide the ouput to confirm that the package is unpublished. To entirely
remove the package you can use Remove-AppvServerConnectiongroup, which
also accepts PackageID and VersionID or Name as parameters to specify a
package.
Remove-AppvServerConnectionGroup –Name FreemindPowershell
This will, just like the management console, present a confirmation request before
proceeding with the removal. If you wish to suppress the confirmation the switch
–Confirm can be used. No output is provided once the removal is completed.
Because Connection Groups are only logical combinations of packages, no files

will be deleted from our package repository.
UPDATE A CONNECTION GROUP
MANAGEMENT CONSOLE
One aspect of the Connection Groups we haven’t mentioned yet is the importance
it plays for user settings. Once a Connection Group is created, user settings will be
maintained within the Connection Group ID and not within each seperate
package. If a brand new Connection Group, with its own Connection Group ID is
created, no settings will be transfered from any other Connection Group. To
persist user settings between Connection Groups, we can create a new version of a
Connection Group.
To update a Connection Group and maintain the Group ID to avoid the loss of
settings, you can select copy as new version (FIGURE 113 COPY AS NEW VERSION)
from the context menu.
Figure 113 Copy as new version
The option will create a new Connection Group with an incremented version
number. You can copy from any past version of the same Connection Group, as
the version number will always be incremented to the highest number in the
series. If you choose to copy a published Connection Group, the new Connection
Group will also be created in a published state (FIGURE 114 CONNECTION GROUPS
WITH THREE VERSIONS)
Figure 114 Connection Groups with three versions
Once the Publishing Server refreshes the configuration from the Management
Server, clients will only be presented with the highest version of the Connection
Group.
POWERSHELL
Creating a new version of an existing Connection Group can also be acheived

through PowerShell using the cmdlet Update-AppvServerConnectionGroup. You
only need to pass the group name as a parameter to receive a new version of the
Connection Group.
Update-AppvServerConnectionGroup Freemind
The above command generates a new group, maintaining the Group ID of

Freemind. If multiple versions of a group exist, the cmdlet will choose the latest
version of the Connection Group and create a copy of that with a higher version
number. If using the -AppvServerConnectionGroup parameter, we need to pass
a ConnectionGroup object to it by either inlining the Get-
AppvServerConnectionGroup:
Update-AppvServerConnectionGroup -AppvServerConnectionGroup (Get-

AppvServerConnectionGroup -GroupID 9b07c99d-7a20-445e-b718-
712cc1061172 -VersionID 8d1f33c4-4b5e-4224-afc8-35560fca743b)
or
Get-AppvServerConnectionGroup -GroupID 9b07c99d-7a20-445e-b718-

712cc1061172 -VersionID 8d1f33c4-4b5e-4224-afc8-35560fca743b |
Update-AppvServerConnectionGroup
The two above commands will result in a a new Connection Group with the
highest version number of all Connection Groups with the same Group ID (or
Group GUID).
A D VAN CED O P E RAT IO N S

App-V 5 has introduced a new concept with Dynamic Configuration files that can
allow one package to service multiple package configuration requirements without
touching the base package with the Sequencer.
The App-V 5 Management Server can easily deploy – in different variations – these
configuration files for both computers (Deployment Configuration) and users
(User Configuration) to accomodate any specific departmental needs. Let’s go
through the native possibilities the Management Server offers and then continue
with the extended ability to deploy your own complex configurations.
CONFIGURATION HANDLING
MANAGEMENT CONSOLE
For each package added onto the Management Server, there are several different
ways to edit its configuration. Simply by right clicking a package (FIGURE 115
RIGHT-CLICK A PACKAGE) you can see multiple options refering to configuration. In
fact, all of the options apart from unpublish and delete refers to editing a
configuration set for the package and in some way deploy it differently to the
selected targets. Edit default configuration is the obvious choice if one
wants to edit the options for the package and only have a single deployment
requirement or a target.
Figure 115 Right-click a package
DEFAULT CONFIGURATION
Clicking edit default configuration presents a new bottom toolbar (FIGURE

116 DEFAULT CONFIGURATION) that shows the native ways to alter the imported
package and the ability to also perform advanced operations.
The first choice here is Applications which will show a list of the different
virtual applications within the package. By unchecking the Enable column, the
application and all its associated extensions (File Type Associations, shortcuts,
protocol handlers, etc.) will no longer be presented to the client.
Figure 116 Default Configuration
Choosing Shortcuts presents a view where you can control which application
shortcuts are created and where they are presented at. You can completely disable
placements of shortcuts for all applications using Enable Shortcuts option, or
customize some of them to your liking. Click Add new shortcut (FIGURE 117
SHORTCUTS) to create additional shortcuts or Edit to edit any of the existing
shortcuts. If you do not select any specific shortcut in the list and click Edit , you
will be editing the topmost one.
Figure 117 Shortcuts
Modifying an existing shortcut is not a very complicated affair and the menu does
offer a very intuitive way forward. The applications are preconfigured from within
the package. If you wish to modify a different application you can choose them
from the list or simply choose to Add new shortcut from the previous menu
(FIGURE 117 SHORTCUTS). The placement of the shortcut can be picked from the
drop-down menu (FIGURE 118 EDIT SHORTCUT) and any additional path can be
added in the text-field just below it. If any additional parameters are necessary for
the shortcut (obviously depending on the particular application and its
requirements), you can add them to the PARAMETERS line.
Important: Remember that the placement of the shortcut has to be

one of the predefined locations and the t ext-field can not be used
to freely place the shortcut in a pat h outside of those predefined
locations.
Unfortunately it is not possible to rename the shortcut and thereby create multiple
shortcuts side-by-side with different parameters (for example with parameters
pointing to different servers like development, validation or production etc.), as
the shortcut name is inherited from the application name. A possible way to get
around this limitation would be to place the shortcut with a different subfolder per
desired startup configuration.
Figure 118 Edit Shortcut
File Type Associations are a bit more complex to configure than shortcuts and
unlike the App-V 4.x Management Server, there can be no customization done at
the Management Server level for FTAs. Rather, a simplistic view is offered that
presents some basic information regarding published FTAs, but certainly not
enough if extensive troubleshooting is required. (FIGURE 119 FILE TYPE
ASSOCIATION). There is also no possibility of disabling all File Type Associations
completely as it was the case with shortcuts, and all of the editing is under the
Advanced menu. Alterations to File Type Associations are expected to be
performed within the dynamic configurationfile.
Figure 119 File Type Association
Advanced offers only two buttons (FIGURE 120 ADVANCED), but it is quite powerful
despite this. Using the Advanced functionality, you will work directly with the
Dynamic Configuration files, providing all the possibilities for application and
package publishing customization.
Dynamic Configuration files will be discussed more detailed in this book’s

Sequencing chapter and also will be part of the upcoming Client chapter.
The first button is Export Configuration , which can be a life-saver in many

cases.
Note: You should always export the current configuration before making
alterations.
If you make alterations and aren’t really sure where you are starting from,
exporting the current configuration before importing any alterations will allow
you to quickly and easily revert to a known working configuration.
An export will also allow you to save the configuration to an external file to any
location you desire.
The second option here is to Import and Overwrite this Configuration ,

which will replace the existing dynamic configuration with the selected
configuration file. If you import configurations using this functionality, it will
overwrite any configuration with that from the imported file. As this is the Default
Configuration, you can only import Deployment Configuration files and not any
User Configuration files. User configuration files can only be applied to a Custom
Configuration, something we will discuss later on.
Figure 120 Advanced
Once you import a configuration (the import is directly into the database), you will
be prompted for confirmation to overwrite the existing configuration (FIGURE 121
CONFIRM OVERWRITE). The prompt clearly states that any previous configurations
will be lost.
Figure 121 Confirm Overwrite
TRANSFER OF CONFIGURATIONS
Looking back at options available from the package’s context menu (FIGURE 115
RIGHT-CLICK A PACKAGE) two additional menu items are presented:
 Transfer default configuration from…
 Transfer access and configuration from…
These will transfer either default configuration or AD access assignments from a

different version of a package to the currently selected version. (FIGURE 122 SELECT
PREVIOUS VERSION),
Figure 122 Select Previous Version
CUSTOM CONFIGURATION
Selecting the option edit active directory access (back from FIGURE 115
RIGHT-CLICK A PACKAGE) will also present a different method for apply a
configuration, however now limited to the User Configuration XML file. FIGURE
123 AD ACCESS shows the options presented when the choice is made to edit the
AD Access.
Figure 123 AD Access
If you select the drop-down menu (FIGURE 123 AD ACCESS) from Assigned
Configuration , you can see that there are two choices, Default and Custom . If
Custom is selected, there is a new option presented: Edit (FIGURE 124 CUSTOM
CONFIGURATION).
Figure 124 Custom Configuration
Selecting Edit (from FIGURE 124 CUSTOM CONFIGURATION) presents an almost

identical page to editing a Default Configuration. The options are the same, but the
initial page will give you the Advanced options (FIGURE 125 CUSTOM
CONFIGURATION EDIT).
You can edit a Custom Configuration very much like you can edit a Default
Configuration, however the configuration is now only applied for users. As such,
you can only import a User Configuration file, as opposed to Default
Configuration which only accepts the Deployment Configuration file. It will ask
you to confirm an overwrite of the configuration and if uncertain, it’s
recommended to export the current running configuration for recovery in case
something goes wrong.
Figure 125 Custom Configuration Edit
One topic that is relevant at this point when dealing with both the Default
Configuration and Custom Configuration is precedence and how to best leverage
it. There are a few basic rules:
 Custom Configuration wins over Default Configuration
 A Custom Configuration is applied at publishing time, an operation that

occurs after the applying the Default Configuration
 There can be conflict handling if a computer / user is assigned multiple

configurations , in which case no configuration wins
 If a package has multiple Custom Configurations and a user is assigned

all of them, it could potentially give the user none of them.
 There can be multiple User Configurations, but only one Deployment

Configuration imported per package
 I cannot motivate why it is like this, but there can be only one
Deployment Configuration per package. The name suggests this, Default
Configuration, but why is unfortunately unknown
 Only one configuration will be applied by the App-V Publishing Server
 You cannot mix and match between multiple Custom Configurations for
a user.
Keep these golden rules in mind and understanding of configurations will be

much easier.
CONFIGURATION MANAGEMENT
POWERSHELL
The ability to use PowerShell to automate the handling of advanced package

configuration is a bit different when compared to the management console,
however the main concepts are there and they still fit well for automation.
To retrieve the current configuration for any package there are two commands:
Get-AppvServerPackageDeploymentConfiguration -Name java
Get-AppvServerPackageUserConfiguration -Name java -Group
DEMO\SG.AppV.U.Freemind
The first cmdlet will retrieve what is called Default Configuration from the web-
based console, but called the Deployment Configuration within the PowerShell
cmdlets. Since there can be only one Deployment Configuration, there is only a
requirement to specify which package contains the desired configuration. It
accepts the parameters Name (as used in the example), PackageID along with
VersionID or a package passed from Get-AppVServerPackage.
The second cmdlet allows you to retrieve Custom Configuration, as it’s called in
the management console, or the contents of the currently applied User
Configuration. As there can be multiple user configurations assigned to a package
the cmdlet requires some additional parameters compared to the previous cmdlet
Get-AppvServerPackageDeploymentConfiguration. The package must be
specified, just like the previous cmdlet, however it also requires information as to
which AD entitlement is assigned the configuration. The parameter is called –
Group and the entry should match the domain and AD group name.
Both of the above commands will output the contents directly to the console for a
quick review. To allow for editing, and to re-import it, you can send it to a text-file
with the below example:
Get-AppvServerPackageUserConfiguration -Name java -Group

DEMO\SG.AppV.U.Freemind > javauserconfig.xml
Allows for an easy backup!
To handle the configuration of a package we can perform any updates in a simple

overwrite manner. Meaning, we can import a configuration file and overwrite any
existing configuration. This of course makes the previous examples of how to back
up the current configuration even more valuable.
To apply a Deployment Configuration we can use Set-AppVServerPackage to

insert new configuration:
Set-AppvServerPackage -name java -

DynamicDeploymentConfigurationPath
\\FILESRV.DEMO.LAB\CONTENT\JAVA\JAVA_DEPLOYMENTCONFIG.XML
As the Deployment Configuration can only exist as one instance per package, we
only need to specify which package we wish to update and where the
configuration file is located.
User Configuration is, again, a bit trickier however it is quite simple once you
understand that it can exist as multiple configurations.
Set-AppvServerPackage -name java -DynamicUserConfigurationPath

"\\filesrv.demo.lab\Content\Java\Java_UserConfig.xml" -Groups
"DEMO\SG.AppV.U.Freemind"
We have to specify which package and which User Configuration file to use and
need to identify the AD entitlement this should affect. If you omit the –Groups
parameter there will be no error message to indicate that this import was not
successful, however you will notice that no configurations are altered.
A D M IN IST RAT IO N B ES T P R A CT IC ES
RULES OF THE APP-V MANAGEMENT SERVER
As part of maintaining an environment there are a few practices that will assist
any administrator in scaling the environment in regards to packages and users and
computers that are using those packages. Let’s clarify a few key bullet points
before we dive into the nitty-gritty details of naming standards and structure.
Rules of the Application Virtualization Management Server, v5:
 Application packages can be assigned to both users and computer accounts –

even at the same time
 The client needs to be configured for a Global Refresh for it to receive

applications assigned to its computer account
 The client needs to be configured for a User Refresh for it to receive

applications assigned to user accounts
 There can only be one Deployment Configuration imported per package

named the Default Configuration
 The can be multiple User Configurations imported per package named

Custom Configurations
 Applications that are part of a Connection Group, are published in the same
context (user vs. global)
 All applications that are members of a Connection Group are published once
the Connection Group is assigned and published, regardless of the
assignment or publishing state of those applications
 A new version of a Connection Group or application will allow the user to

retain user settings
 Moving an application between Connection Groups will not transfer its user
settings
These rules are good to remember when it comes to building your environment.
PACKAGING NAMING CONVENTION
In previous versions of App-V a large portion of any training time was spent on
naming conventions and in particular the requirement for a unique 8.3 directory
name. This was strongly recommended to allow for trouble-free co-existence of
packages on the same client. In addition, every package had to have truly unique
package name and combination of name+version. Two applications having
identical human-visible names had bad implications for publishing and co-
existence on the same client.
App-V 5 has greatly improved this area by utilizing GUIDs for packages and
Connection Groups, completed by version GUIDs. There could still be a need to
emphasize App-V 5 characteristics within the package name, however they are far
less complex and anyone familiar with traditional package building will realize
that there is nothing unique with App-V 5 and its requirement for package names.
Technically the App-V 5 Management Server does not require a separate folder or
location for a new version of a package; however it could be logical to place a new
version within a separate folder to avoid overwriting configuration files and to be
able to remove an older package version more easily. As the App-V 5 Management
console will detect the version number on its own and match it to a previous
version of the package (with version number in 0.0.0 format) based on the package
GUID, we are not forced to separate the two packages physically. To allow for
easy filtering amongst a thousand packages, creating a base identifier such as the
Vendor-name within the package name will allow for an easy overview. We could
also use language, to easily identify all packages relating to a specific set of users,
or OS architecture to identify packages only compatible with a certain operating
system.
This all leads to the following suggestion for a folder per package. It is
recommended to omit the package version from the package name, as it will be
available within the package itself and can be viewed in a unique column within
the Management console.
 Vendor Application Version Language OS Architecture Package Version
 Vendor – such as Adobe, Autodesk, Microsoft
 Application – such as Reader, AutoCAD, Office
 Version – such as XI, 2013, 2013
 Language – such as en, se, de
 OS Architecture – such as 64, 32
 Package Version – such as 0.0.0.0, 0.0.0.1, 0.0.0.2
An example of a package of Autodesk AutoCAD 2013, English language,

packaged on a 32-bit platform, would have a folder of:
 Autodesk AutoCAD 2013 EN 32 0.0.0.0
And the package name would be;
 Autodesk AutoCAD 2013 EN 32
This creates a way of grouping applications and filtering them within the
management console and can allow an administrator to easily identify the folder
on a file-server / web-server and relate it to an imported package.
ASSIGNMENT OF APPLICATIONS
Entitlement of applications using the App-V 5 Management Server has a few

possibilities, such as per computer, per user or mixed, and therefore some basic
practices can be in place before allowing people to assign applications.
Since there can be only one Deployment Configuration, it would be recommended

to leverage this as a generic application state suitable for any common user. If an
application needs to be deployed for multiple distinct user groups, the only way
forward is by providing custom configuration using the User Configuration file.
User Configuration can be assigned to a specific AD group, and will allow you to
reuse a specific package for multiple purposes without altering the core package
file. However, a user cannot be assigned a package with multiple configurations.
Note however that since features available in a Deployment Configuration file

differs slightly from a User Configuration file, it is therefore not possible to cater
all possible deployment scenarios using a single package published by the
Management Server. An example of such a scenario could be certain package
scripts events that can only be defined in the Deployment Configuration file.
CONNECTION GROUPS
Connection Groups should be considered as their own entity from a publishing

perspective; though they will encapsulate all packages assigned to them.
Connection Groups will primarily apply the Deployment Configuration (also
known as Default Configuration) for any user that previously has not had the
application.
Since Connection Groups are providing a wide entitlement to any applications that
are members of those groups, , they should be considered their own application in
their own right.
USER VS. COMPUTER
Since packages, and by extension all applications contained within, can be

assigned to both users and computers there are endless possibilities for
deployment. As you can decide to both not make a specific object (such as a
computer) part of an AD group and to not enable a publishing refresh (such as a
global publishing refresh) there are multiple ways to ensure that a specific
application is delivered in the right context to a user or computer.
Examples include:
One AD group for one application configuration
 Create an AD group for a specific application
 Assign both users and computer objects within the same AD Group
 Define the Global Publishing Refresh on a specific set of computers, but no

user Publishing Refresh (such as a science lab department)
 Define the User Publishing Refresh on the laptops (as an example) to allow
the users to receive their applications
Multiple AD groups for one application
 Create multiple AD groups – one for each context (users vs. computers)
 Assign only the right type of object for each AD group
 Define both a Global Publishing Refresh and the User Publishing Refresh on
all clients
The above two scenarios leverage the App-V infrastructure quite differently, but
can ensure that only the desired application will be delivered to the user.
A very simple approach is to decide which context you will deliver applications to
– for example only configure the User Publishing Refresh and therefore only allow
applications assigned to users to receive applications.
Troubleshooting a Native Deployment
2.5 T ROUBLESHOOTING A
N ATIVE D EPLOYMENT
C O M MO N R EC O M ME N D AT I O N S
Before digging into the details, here are some common guidelines that you should
follow regardless of the actual issue. The upcoming sections will be more specific.
Event Viewer is your friend
In our tests there were almost no App-V related issues that did not leave any
traces in Windows Event Logs. A first step should always be to view the
Application and Services Logs / Microsoft / App-V section of
Eventvwr.exe or Eventvwr.msc as shown in FIGURE 126: WINDOWS EVENT LOG -
COHOSTED SERVER.
Figure 126: Windows Event Log - CoHosted Server
While the Client log is especially chatty and even though it doesn’t provide too
much meaningful text, you will be able to see if something goes wrong, and
receive some explicit information along with some cryptic error codes that assist
with searching for solutions. As an example we forced our demo implementation
to throw some errors in FIGURE 127: WINDOWS EVENT LOG - MANAGEMENT
ERRORS.
Figure 127: Windows Event Log - Management Errors
App-V components (Client, Management, Publishing, Reporting, but not

Streaming) allow activation of additional logs via the Show Analytic and Debug
Logs option. FIGURE 128: WINDOWS EVENT LOG - UNHIDE ANALYTIC AND DEBUG
LOGS shows how to get there.
Figure 128: Windows Event Log - Unhide Analytic and Debug Logs
After the visibility of these logs has been triggered, you have to enable them to
gather results (FIGURE 129: WINDOWS EVENT LOG - ENABLE AN ANALYTIC LOG).
Figure 129: Windows Event Log - Enable an Analytic Log
You should enable only one or a small number of the Debug/Performance logs at
the same time, otherwise the system could become saturated. You should also only
enable them for a limited time, while you are reproducing an error.
Isolate the Issue
You should try to isolate the issue as well as you possibly can: “does it affect one
or all machines or users?”, “is it only showing up at one or several packages?”,
“did it ever work previously?” and similar questions don’t only help you to
identify the potential cause; they also might help others (like in forums) to help
you better.
Document your remediation steps
We know that this is a hard one, especially if your production environment has a
severe issue or if an issue that prevents you from reaching an important milestone,
but anyway; document your remediation steps. Make a note about configuration
changes that you made to solve a problem – even if it did not seemed to improve
the situation. This helps you to make your solution reproducible. It also supports
working in a more structured manner. And others won’t ask you to this and that if
you already did it.
Search the Internet, but do it right.
It may be obvious but we’d really remind you to use two search engines to
identify potential causes before you start asking questions of others. Failing actions
in the Management console or with PowerShell as well as the Event Viewer often
return text and some (alpha)numeric error code. It is that error code you should be
after. Unfortunately App-V Error codes follow different conventions (or masks).
Sometime it is a single block like 0x80511008, sometime it consists of several
blocks like 0x5970167-0xB or 0x74F00F0C-0x80190191, and so an easy advice
like v4 just can’t be given. Look for single ‘full’ hexadecimal blocks: 0x80511008,
0x5970167, 0x74F00F0C and 0x80190191 would be the terms to search for.
Figure 130: Windows Event Log - Sample Error Message
As a side note, if ‘App-V 0x74F00F0C’ doesn’t return a result, try it again without
‘App-V’: Microsoft tends to use similar error codes for similar issues across
different products – so even errors for another product might provide you with a
hint.
Additionally it might be helpful to convert some values between hex and decimal.
Take that 191 portion of one of the errors and convert it. Doesn’t that look like a
familiar HTTP error code? Indeed it is. 38 Finally, don’t rely on Microsoft Event IDs.
38 And no, we don’t do the conversion and unveiling for you right here. Troubleshooting does not
mean ‘sit and wait for an answer’, it means ‘go, do something’!
Two of the errors shown so far have the same Event ID, but different causes and
App-V Event IDs aren’t that popular on the Internet yet, either.
Understand communication relations and the deployment process
So, your package doesn’t show up on the client? In that case you should go down
the route that the App-V client goes, make a turn on the crossroads to follow
Publishing Server Road until you reach Management Server Boulevard with its
intersections. You get it… down in this sub chapter.
Access Permissions are the enemy
App-V components heavily leverage user or machine account access permissions;

its web services often use impersonation when connecting to certain resources.
Though we haven’t gathered any statistics, missing access permissions are the
number one cause of App-V deployment issues in the environments we have seen
so far. Did you ever spend a day figuring out that your customer uses a slightly
locked-down IIS? Some of us have. Therefore you should start your evaluation in
an unrestricted lab environment, but your proof-of-concept requires you to take
restrictions and permissions into account.
I N S TA L LAT IO N I SS U ES
Monitoring forums and blogs indicate that installing App-V components does not
cause major issues. Of course you did install and verify the system prerequisites in
advance.
A small lesson that you’ll learn very quickly is that the App-V installation wizard
does not request privileged execution automatically, even though it’s required. So
you have to right-click  Run as administrator to launch the wizard. In
theory it could occur that the machines you are installing on are not member of a
domain yet, or that your account doesn’t have proper permissions.
In case of an installation issue, MSI logs should give some guideline about what
went wrong, allowing you to search the Internet for similar issues.
A minor challenge might be that App-V doesn’t support database access if the
database instances use dynamic ports (instead of the default TCP 1433). Because
most organizations protect their SQL servers using firewalls, dynamic ports are
very uncommon. And you should install App-V server components to the C:\
drive only.
C O N F IG U R AT I O N I SS UE S
Even after the installation wizard(s) have finished without any errors there might
be situations where the App-V environment still isn’t working well correctly. This
subsection gives some more general guidelines, because it partially overlaps with
the upcoming OPERATIONAL TROUBLESHOOTING section that is actually more
detailed.
Anyway, you should validate your environment as soon as possible after

installation; all App-V components should be up and running and can be queried.
APP-V MANAGEMENT DATABASE
Open the database with Microsoft SQL Server Management Studio and validate
that the App-V Management database’s Permissions table contains at least one
entry (perhaps your SQL Server admin may need to complete this step).
Open the App-V Management console and verify that you can access data.
Enter the following URL in a browser and ensure that it does not return an error:
http(s)://<App-V Management Server>:<Port>/Console.html.
Figure 131: Management Server Verification - Management console
It appears to be OK if you as an Administrator are asked for credentials once for

every session, but if you receive an ‘Authorization denied’ page, impersonation
may have failed at a given point.
Open the IIS Management console and verify that the Application Virtualization
Management (web site and application pool) are running and not in a stopped
state (it’s hard to see, but FIGURE 132: MANAGEMENT SERVER VERIFICATION - WEB
SITE shows a little Stop icon, and FIGURE 133: MANAGEMENT SERVER VERIFICATION
- APPLICATION POOL shows a Stop as well).
Figure 132: Management Server Verification - Web Site
Figure 133: Management Server Verification - Application Pool
If you are running an HA/LB scenario repeat the above steps on every machine
that hosts the Management Service.
Open the following URL in a browser with a user account that has been provided
access to App-V applications. Open the following URL to check the Publishing
Server’s internal status: http(s)://<App-V Publishing Server>:<Port>. It
should return an XML formatted document that looks similar to FIGURE 134:
PUBLISHING SERVER VERIFICATION - APPLICATION LIST.
Figure 134: Publishing Server Verification - Application List
Open the IIS Management console and verify that the Application Virtualization
Publishing web site and application pool are running and not in a stopped state
If you are running an HA/LB scenario validate this on every machine that hosts the
Publishing Service.
As a user, open the URI (UNC or URL) to an .appv file. Regardless of the
implementation type you should be asked if that file should be opened / saved /
canceled. This message indicates that the .appv file can be read and can
potentially be downloaded. This should work for all .appv files even before they
are imported into the Management console. FIGURE 135: STREAMING SERVER
VERIFICATION - FILE DOWNLOAD shows a web based successful download attempt.
Figure 135: Streaming Server Verification - File Download
O P E R AT I O N AL T RO U BL E SH O O T IN G
APP-V COMMUNICATION FLOWS
One of the first steps in a troubleshooting process is to identify the actual failing
sub-process or component - let’s remind ourselves of some of the general tasks that
are performed by App-V components and how they interact with others.
APP-V CLIENT
On an App-V Client, to get a new application the following sub processes are
(almost) always performed: 39
Publishing Refresh: The App-V Client connects to an App-V Publishing Server to

retrieve a list of available packages including their download / streaming location
in XML format. Sometimes this is called the APPLIST or Application List.
Add Package: The App-V Client creates a key with the Packages’ GUID in the
Registry at HKLM\Software\Microsoft\App-V\Client\Packages. This step is
automatically initiated by the Publishing Refresh step or by using the PoSh
command add-appvclientpackage.
Note that adding the package is a prerequisite for both, publishing and mounting
a package, but publishing and mounting can be performed in any sequence.
39
These steps will be discussed more detailed in the upcoming ‚Client‘ chapter of our book
Publish Package Applications: The App-V Client unveils the package’s

applications to the user’s working environment. Shortcuts are created, file type
associations are registered and other entry points (like protocol handlers) are
exposed to the operating system. This can be performed per-user or globally
(essentially affecting the ‘all users’ locations).
Important: Publishi ng the application i nitiates a dow nload from

the Streaming Ser ver, using the URI pointing to t he .appv file
Regardless of the publishing method, several files from inside the .appv file are
downloaded and extracted during this step. These components are referred to as
Primary Feature Block.
In a Native Deployment, data is transferred from the Publishing Server, whereas

in other deployment methods (like PoSh publish-appvclientpackage or
Configuration Manager) leverage configuration XML files.
Mount / Stream / Download the package content: In its default configuration, all
files that are accessed by virtual applications first have to be downloaded into the
client’s App-V cache (as opposed to Shared Content Store mode, where files are
not really downloaded, but spares-files to the URI location are created).
Depending on the configuration (and packaging), these files:
 are downloaded in separate steps (Feature Block 1 first entirely, then the files
of Feature Block 2 as they are required).
 are downloaded entirely (if using the mount-appvclientpackage command

line or if the client is configured to download the entire package or if the
Sequencing Engineer decided to create a monolithic package).
 they aren’t downloaded at all (Shared Content Store mode).
Launch Applications: The App-V Client creates the virtual environment for the
package and starts the application.
The Publishing Server is queried by clients and returns the list of currently
assigned packages and applications. It regularly initiates connections to the App-V
Management Server to retrieve a list of all available packages and applications.
The interval is specified in the Publishing Server’s Registry:
HLKM\Software\Microsoft\AppV\Server\PublishingService, value
PUBLISHING_MGT_SERVER_REFRESH_INTERVALL.
The Publishing Server caches the information, so it still can continue to operate if
the Management Server is not responding; a persistent caching model is used that
even keeps the information across reboots.
The Management Server is queried by the Publishing Servers regularly, as

configured on the Publishing Servers. It is also queried by the Management
console and by the PowerShell cmdlets that are installed on the same machine.
The App-V Management Service itself queries the App-V Management Database
quite often, but the data cache is not persistent. That means that after a few
minutes the Management Server would throw error messages if the database is
offline. However this is not that much of an issue, because the Publishing Server
does cache the info – so clients still can retrieve an application list.
The App-V Streaming Server (file or web) is queried by the App-V Client to
download the content of .appv files.
Remember that the initial contact to an .appv file is initiated during the Publishing
phase, such as to download the icon files for shortcuts and FTAs.
Also, the Streaming Server is queried by the App-V Management Server while
adding/importing packages into the App-V environment via the Management
console or PowerShell.
COMPONENT VERIFICATION AND CHECKPOINTS
Knowing the communication flow only gives a structure for troubleshooting

processes; it doesn’t help that much to identify the actual failing component.
PUBLISHING SERVER
Establish a browser connection to the Publishing Server URL. If you use variables
for the server location, use the variables (placeholders) and their resolved value(s).
If you have multiple servers behind a load balancer, connect to all of them.
The first attempt should be performed from a client machine with the user account
that faces the issues.
Connect to the URL http(s)://<App-V Publishing Server>:<Port>. Use the

URL that is specified in the client’s Registry or (better) is returned by Get-
AppvPublishingServer.
Don’t attempt connections to http(s)://localhost:<Port>. Localhost

connections are not in the Intranet security zone and cause misleading results.
You should receive an XML formatted reply like in FIGURE 136: PUBLISHING
SERVER VERIFICATION - APPLICATION LIST EXPANDED.
Figure 136: Publishing Server Verification - Application List expanded
If you receive a Logon Window (FIGURE 137: PUBLISHING SERVER VERIFICATION -

WEB SERVER AUTHENTICATION), first identify whether it comes from a proxy server
or from the Publishing Server. If the prompt comes from the proxy, try to
overcome it (either by adding the Publishing Server to the proxy bypass list or by
enabling pass-through authentication to the proxy).
Figure 137: Publishing Server Verification - Web Server Authentication
If the prompt comes from the Publishing Server, add the Publishing Server URL to
the list of ‘Intranet sites’ on the operating system 40. Alternatively you could use
Windows Credential Manager to store and ‘auto fill’ these credentials.
You may receive a certificate related error message (FIGURE 138: PUBLISHING
SERVER VERIFICATION - SSL CONNECTION ERROR gives an example) while using a
secured HTTPS connection.
40 Note that Site-Zone assignments, proxies and other settings usually are effective on the operating
system level although they are configured using Internet Explorer settings. In return, settings that
you configure ‘obviously’ in IE in fact influence App-V client communication.
Figure 138: Publishing Server Verification - SSL Connection Error
The most common causes for that are:
 The client machine does not trust the issuer of the certificate: install a
root/intermediate certificate into the client’s machine store.
 The connection URL and the name on the certificate don’t match: adjust the
Publishing Server URL for the App-V client accordingly, retry with the
adjusted URL (note that adjusting the URL in the browser’s address bar does
not solve any issue of the App-V client!). Alternatively you may be required
to re-issue a new, proper Server Certificate.
 A certificate is not yet valid or has expired.
Refer to the APPENDIX for some addition information.
If you are receiving an XML document, but it does not contain anything or does
contain odd or expired information, validate that:
 The user is member of the right groups (and has logged off and on before a
publishing refresh)
 The Publishing Server’s last refresh time is not old. To validate it, open the
URL http(s)://<App-V Publishing Server>:<Port>/info.. If the last
refresh is too old, there is potentially an issue with the Management Server
(the Publishing Server seems to be working). FIGURE 139: PUBLISHING SERVER
VERIFICATION - LAST REFRESH TIME INFO shows an example.
Figure 139: Publishing Server Verification - Last Refresh Time Info
If you are getting HTTP errors, you may need to expand the message text.
404 errors indicate that the URL (server name, port, path) is not valid or that IIS
and/or the Publishing Service are not running at all.
401 or 403 errors (unauthorized or forbidden) indicate authentication and

authorization errors. They may appear if IIS has tightened security settings, or if
Integrated Windows Authentication is not enabled.
50x errors are often internal server errors of the web application or IIS. They may
occur if software prerequisites aren’t properly installed. They also appear if
accounts used by IIS don’t have proper access rights to local or remote folders.
Anyway you should check:
 If IIS is running at all (Figure 140)
 If App-V Publishing Application Pool is running (Figure 141)
 If the App-V Publishing Web Site is running (Figure 142)
Figure 140: IIS Verification - Web Server
Figure 141: IIS Verification - Application Pool
Figure 142: IIS Verification - Web Site
MANAGEMENT SERVER
While the Management Server is not crucial for continuous package delivery, it is
required to import new packages or versions into the native App-V environment
and to update deployment configuration and user configuration adjustments.
As stated above, the Publishing Servers, the Management console Silverlight

application and the server’s PowerShell cmdlets require a working service.
As the Management service also is an IIS web application, initial checks should
include that IIS and the web application pool are running and that the requests to
the URL return valid results.
Run the get-appvserverpackage cmdlet locally on the server to see if it is

running properly.
Open the Management console at URL

http(s)://<AppvManagementServerName>:<port>/management.html, log in if
requested and see if you can browse through the categories without errors.
Go to a Publishing Server, open its Registry

HLKM\Software\Microsoft\AppV\Server\PublishingService, copy the
PUBLISHING_MGT_SERVER URL and open it from the Publishing Server’s internet

browser: you should see an XML formatted result like in FIGURE 143:
MANAGEMENT SERVER VERIFICATION – ALL PACKAGES LIST.
Figure 143: Management Server Verification – All Packages List
If the App-V Management Server fails to connect to the Database, it will return
errors. FIGURE 144 shows an error of an entirely disconnected database, and
FIGURE 145 shows the Event Viewer entry for this.
Figure 144: Management Server Verification - SQL Connection Issue
Figure 145: Management Server Verification - SQL Connection Issue
There is not that much to check on the Streaming Server – it’s just a file or web
server, right? However, to validate its availability you again should try to
download one or more .appv files from the location that is specified in the
application list returned by the Publishing Server or that can be found in the result
of get-appvclientpackage –all.
Remember– based on the publishing method – both, the client machine and the
user may need to have read access to these files.
If you are using a web server, ensure that ‘.appv’ is registered as a MIME type.
Appendix
2.6 A PPENDIX
Appendix
A P P -V 5 SQL M I RRO R IN G C O N F IG U R AT I O N
The f ollowing descr iption has not been validated by the aut hors
nor is it based on any public Microsoft documentation. Follow at
your own risk!
In August 2013, Microsoft ‘silently’ updated its article of Planning for High
Availability with App-V 5 (HTTP://TECHNET.MICROSOFT.COM/EN-
US/LIBRARY/DN343758.ASPX). In here, SQL Mirroring is named as a supported
method to achieve high availability for the Management Database (interestingly
the Reporting Database is not mentioned in that section).
However, MS did not provide any documentation how to achieve it. The only
indication of how to tell the App-V Management Server to fall back to the
mirrored database in case of a primary DB failure is a description given by
Hal Lange at Technet’s App-V forum
HTTP://SOCIAL.TECHNET.MICROSOFT.COM/FORUMS/EN-US/57D10F6E-16B6-4F76-
A0BD-06A6710C74D4/APPV-50-DATABASE-MIRRORING.
Because of our aimed press date for this chapter, we did not verify the
configuration, but it seems valid. As forums are volatile, FIGURE 146: SQL
MIRRORING FORUM POST shows a quote of it.
Appendix
Figure 146: SQL Mirroring Forum Post
Appendix
A P P -V 5 C O N N E CT IO N S E CU R IT Y
A BRIEF INTRODUCTION INTO PK I , S SL AND
CERTIFICATES
Let’s start this section with a prediction: we won’t be über-precise here. This
section is just to remind you some of the key principles of SSL/TLS communication
by using free-style explanations of common terms and procedures. We’ll focus on
SSL communication, namely for Windows and IIS, as they are relevant for App-V.
TYPES OF CERTIFICATES
First, you can imagine a Certificate as a form of ID, Passport or other document
that proves someone’s identity.
SERVER CERTIFICATES
A Server Certificate usually identifies a computer that answers requests. The key
information on such a certificate is a Common Name (what is the referenced name
for that server), the expiration date, the issuer (who created that certificate) and a
Private Key validator.
Here comes the first point to note: the Common Name has to match the
URI/address clients are connecting to.
Let’s suppose you have one sever behind a load balancer. Technically you can
establish a connection through the load balancer’s name, the load balancer’s IP
address, the actual machine name or the actual machine’s IP address. And yes, in a
Appendix
LAN you can use a short name (myNLB) or a fully qualified domain name
(myNLB.demo.lab) to connect to that machine.
However, in an SSL scenario you are limited in your freedom. Most software only
will allow a connection to the address that matches the certificate’s Common
Name. So if the certificate is issued to ‘myNLB.demo.lab’, only connections to that
address will succeed (actually it’s not case sensitive). Due to some restrictions of
some issuers:
Do only use the FQDN (and neither short names nor IP addresses) as the Common
name of a certificate. In return, also use FQDNs only when you specify addresses.
(Note that relative paths like ‘/content’ or ports like ‘:443’ are not considered as
part of the name).
There is a special form of server certificates called Wildcard Certificates like

*.demo.lab that can be attached to every server that matches that pattern.
The expiration date (actually the validity period) is quite self-explainitory.

certificates will only be accepted if the date is within the specified time frame.
Often server certificates expire after one or two years. Note that sometimes
certificates created on a given day are only valid starting the day after.
The creator or issuer of a certificate is an important characteristic as well. It does

not only tell us who apparently created a certificate – clients also have to have an
established trust relationship to that issuer. Well’ talk about that in a second.
Depending on the issuer, there are some classes identified. Public Certificates are,
well, used in the public and are often issued by large security companies like
VeriSign. Private Certificates are issued by an organization’s IT department and
are usually only used inside that organization. Then we have self-signed
certificates that a single server (or appliance) creates. These aren’t very common
outside of small lab environments.
Appendix
Because of security reasons, you cannot install any server certificate on any server.
Instead usually a server only accepts certificates that were requested by it. A
‘Certificate Signing Request’ is created and sent to the Issuer – and only if the
returning certificate matches the original request, will that server accept it.
Technically, the server holds a Private Key for that certificate. (If someone sends
you an ID card – will you use it if you never requested it? Probably not. Servers act
the same way). In certain scenarios, the Certificate and the Private Key are
bundled together and can be imported into any server – but as you can see that
doesn’t really increase security, so most server certificates do not contain an
exportable Private Key.
ROOT AND INTERMEDIATE CERTIFICATES
In the section above we mentioned that a client only accepts certificates from a
‘trustworthy’ organization. If a man shows you an ID issued by Interpol, you
might trust it. If a man shows you an ID issued by TheAppvBook.Inc, you’ll
probably just ignore that. The way to tell a computer (or application) to trust an
issuer is to install a Root or Intermediate Certificate. A Root Certificate is highest in
the hierarchy, but there might be intermediate certificate authorities as well. In the
above example, Interpol may allow the Dutch Police to create Interpol ID Cards for
Dutch Interpol Employees. Because you trust Interpol (as a reliable organization)
and Interpol trusts its Dutch department, you (should) automatically trust the
Dutch Interpol (at least this is how computers act). In this case, Dutch Interpol is
an Intermediate Certificate Authority. And yes, as an administrator (or even user)
you may choose to trust us as well and to install our TheAppvBook root or
intermediate certificate.
Returning to the Server Certificates – because most Public issuers are already
installed on the operating system (or in browsers), server certificates issued by
them or by subordinate authorities are trusted automatically. For Private
Certificate Authorities, the Root/Intermediate Certificate has to be installed onto
Appendix
computers that want to establish an encrypted communication. AD can do that;

Software Distribution Systems or Administrators can do that too. Basically the
same applies for Self-Signed Certificates – they also have to be installed onto client
computers.
Note that in some Operating Systems users may install Root/Intermediate

Certificates for themselves – but they are then limited to their personal use –
neither other users nor system services would accept them.
CLIENT CERTIFICATES
Whenever you hear someone talking about Client Certificates, you should first
listen carefully: because they often have to be installed on a client,
Root/Intermediate Certificates are called Client Certificates. In fact they aren’t.
A Client Certificates is used to clearly identify or authenticate a client computer or

user to a server. So it is the ID of a user or client computer. Like Server Certificates,
Client Certificates are issued for individual objects and basically have the same
characteristics (whereas a Root/Intermediate Certificate can be used on millions of
computers and has no ‘individuality’).
SECURITY TECHNOLOGIES
There are some general security technologies that leverage certificates.
AUTHENTICATION
Like a combination of username and password, certificates are used to identify the
communicating end points. Commonly a server authenticates itself to a client by
presenting a server certificate (the client can be sure it’s communicating with the
right server and not just any server with the same name). Client certificates can be
used to authenticate users. The client certificate is presented to a server and that
Appendix
server allows or denies access to certain resources based on the information stored
in the certificate. Client certificates often do not only contain the username, but
may also contain group membership information. Client certificates are usually
installed on a client machine or they are stored on USB drives or smart cards.
While IIS generally supports client certificate based authentication and

authorization, there is no documentation whether this is a supported scenario for
App-V. Since the primary Windows Logon supports certificate based Smart Card
authentication, App-V could in theory support such an environment.
SIGNING
To ensure that a document (or data) was not modified during communication,
signing is used. In contrast to Encryption (see the next section), signing itself does
not hide any data that is transferred. Often, the sender runs an algorithm to create
a so-called ‘fingerprint’ of the actual data. That fingerprint cannot be converted
back to the original data. The receiver can then run a similar algorithm to validate
the fingerprint: if the newly generated fingerprint is the same, the data has not
been modified. Private Key / Public Key technologies can validate that the
fingerprint was created by the original sender (and not by a man-in-the-middle). If
that ‘sender verification’ is not in place, an attacker could of course could easily
modify the actual data and the fingerprint. SSL does use signing silently.
ENCRYPTION
If the data should be kept secret, encryption comes into place. Here some
mathematical magic ensures that only the right receiver of data can convert
encrypted data back into clear text. Again, certificates and Private/Public key
combinations are used in SSL to ensure that no man-in-the-middle can read or
decrypt the data.
In fact, most SSL communication uses Encryption and Signing at the same time.
This not only ensures that the data is kept secret during the communication, it also
Appendix
ensures that the data was not modified. And because sender and receiver
exchange one-time keys during the initial communication process, they both can
make sure that they are communicating with the same endpoint during the entire
process.
IIS CERTIFICATE MANAGEMENT
Using a PKI / Certificates for App-V with IIS is not that complicated, at least if the
organization has an existing PKI infrastructure.
SERVER CERTIFICATES FOR A SINGLE SERVER
Let’s start simply: you have one server that should be accessible via SSL, IIS is
already installed.
The first thing to do is creating a Certificate Signing Request (CSR).
 You can use IIS Manager to do that. In this case, you also have to use IIS to
import the certificate itself later on.
 You can use openssl command line tool for this.
 Some Certificate Authorities / issuer offer a web page to create such a request.
Appendix
Step Screenshot and Description
1 In IIS Manager, select the server and find the Server Certificates icon
2 Click on Create Certificate Request in the right-hand Actions

pane
Appendix
3 Fill in all information. Remember that Common Name has to be the

FQDN that clients use to connect to that server
Specify the provider and the Bit (key) length. Note that 1024 Bits isn’t
4
considered secure any longer (but not all systems understand keys with
4096+ bits length).
Appendix
5 Save the request as a (text) file. You should give it a meaningful name
and you may use the .csr (certificate signing request) extension. The
content looks cryptic.
Next, you send the CRL file to the Certificate Authority or insert the cryptic
content into the CA’s web form. With a sample, web based internal CA; the
process looks similar to this (but might be different for other CAs)
Appendix
1 Go to the CA’s web site and Request a Certificate:
Appendix
2 When prompted, select to submit an advanced certificate request
3 When you have an .csr like text file, you could submit a certificate
by using a … file
Appendix
4 Copy the entire content of the text file (including the ---Begin and
the Request--- pieces into the form and select the right template: Web
Server. Other CAs may ask you for the web server type (Windows or
IIS).
Appendix
5 Now you can download the Server Certificate (or you are asked to
return to the website if the certificate requires approval or the CA sends
you the certificate by mail). While Windows likes DER certificates, some
Linux based server may require using Base 64 encoded certificates
When you have the actual (server) certificate file, it has to be imported using IIS
Manager, openssl or the Certificates MMC Snap-in.
1 When using IIS, you return to the Server Certificates section on the
server level, there you click on Complete Certificate Request…
Appendix
2 This will ask you for the certificate file name and a ‘friendly’ name.
While you can choose basically any name here you should also use the
FQDN.
3 After that, the Server Certificate is imported into the machine’s

certificate store (but not used yet)
Appendix
4 Now you have to bind the certificate to your web site, so in our
example select the App-V Management Service site then click on
Bindings…
5 Here you click on Add…
Appendix
6 Select https as the type and the right server certificate from the drop
down box. In the example below the port was to 4431 to avoid potential
conflicts with other secure services on this machine
Now, this web site / application uses SSL.
SERVER CERTIFICATES FOR A CO-HOSTED SERVER
If you have more than one App-V service running on a single box, it doesn’t have
to get scary – you can use one and the same Server Certificate for different
components.
There are two constraints that you have to remember:
 All services have to be made available under the same server FQDN (you
can’t use different DNS aliases for different services)
 All IIS based services have to be bound to different SSL ports. You cannot just
use 443. You could use spare ports like 444. Remember that 445 is reserved for
SMB already!
Appendix
SERVER CERTIFICATES FOR LOAD BALANCED SCENARIOS
In a load balanced scenario, the load-balancer technology matters.
 Windows NLB: each node needs a Server Certificate that is issued to the
virtual name. You can request individual certificates (with individual CSRs)
for each server, or you can ask for a Server Certificate that allows you to
export the Private Key as well. Such a Certificate can be copied and imported
to other machines (most CAs will refuse to do that).
 DNS Round Robin (not recommended): each node needs a Server Certificate
that is issued to the virtual DNS name.
 Web Load Balancing: when using an external Load Balancer, there are again
several configuration options. With SSL Offloading configured, the LB
accepts SSL connections (from a less secure network) but forwards the
request unencrypted to the server. In this scenario only the LB has to have a
Server Certificate. Another scenario takes the SSL stream, decrypts it and
actively establishes own SSL connections to the server nodes. Because the
connection then would be interrupted, this is an uncommon scenario. Most
commonly the LB will be transparent to the client and simply forward
requests to one of the nodes. In that case the LB doesn’t need any Server
Certificate, but every node needs one issued to the virtual name (similar to
the NLB scenario)
ENFORCING ENCRYPTION
Just adding a Server Certificate to a machine, import it into IIS and bind it to a web
service or application doesn’t increase security: users and clients can still connect
using unsecure channels. Therefore, SSL encryption has to be enforced.
Appendix
1 Enforcing SSL is done on the application/site level, so select the site and
click on SSL Settings.
Appendix
2 Enable the checkbox at Require SSL and leave the other settings as
they are ( Ignore )
3 That’s it: When a user or client/application now tries to establish an

unsecure connection to that site, the connection is refused:
Appendix

AppV5Book 02 Native-Deployment-Infrastructure

Uploaded by

Copyright:

Available Formats

You might also like

AppV5Book 02 Native-Deployment-Infrastructure

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

AppV5Book 02 Native-Deployment-Infrastructure

Uploaded by

Copyright:

Available Formats

THE APP-V 5 BOOK

Copyright (c) 2012, 2013 by

2 Native Infrastructure Deployment

2.1 GENER A L A R C HI TEC TU R E ............................................... 1

APP-V REQUIREMENTS ............................................................................................ 2

INFRASTRUCTURE COMPONENTS ....................................................................... 8

DESIGN CONSIDERATIONS ................................................................................... 26

2.2 I NS TA LLI NG A WO R K I NG DEPLO YM ENT

PRE-REQUISITES INSTALLATIONS ...................................................................... 66

MANAGEMENT SERVER INSTALLATION ......................................................... 95

PUBLISHING SERVER INSTALLATION ............................................................. 108

2.3 DEPLO Y M ENT I NF R A S TR UC TU R E

STANDARD CONFIGURATIONS ........................................................................ 120

MONITORING .......................................................................................................... 143

HIGH AVAILABILITY AND SCALABILITY ....................................................... 147

COMMUNICATION SECURITY ........................................................................... 155

CONFIGURATION AND MONITORING BEST PRACTICES .......................... 164

2.4 A DM I NI S TR A TION F O R A PP-V M A NA GEM ENT

STANDARD OPERATIONS ................................................................................... 167

ADVANCED OPERATIONS................................................................................... 206

ADMINISTRATION BEST PRACTICES ............................................................... 220

COMMON RECOMMENDATIONS...................................................................... 227

INSTALLATION ISSUES ......................................................................................... 234

CONFIGURATION ISSUES .................................................................................... 235

OPERATIONAL TROUBLESHOOTING .............................................................. 240

2.6 A PPENDI X .......... .......................................................... 25 3

APP-V 5 SQL MIRRORING CONFIGURATION ................................................. 254

APP-V 5 CONNECTION SECURITY..................................................................... 256

We would like to thank Aaron Parker (@STEALTHPUPPY) for

We also would like to thank Sebastian Gernert for his

Falko, Ment, Nicke & Kalle

 Technical requirements, which define the basis on which the App-V

As the software requirements will become relevant during actual installation,

The App-V Book App-V Native Deployment Infrastructure 2

Server Role Available from installer

Management Server Database 

Reporting Server Database 

The App-V Book App-V Native Deployment Infrastructure 3

Active Directory Microsoft App-V 5.0 is dependent on Microsoft Active

Installation Account An installation account is required to install App-V server

The App-V Book App-V Native Deployment Infrastructure 4

SUPPORTED OPERATING SYSTEMS

Microsoft App-V 5.0 server components require a minimum of Windows Server

Microsoft Windows Server 2003 Standard, Enterprise,

Microsoft Windows Server 2008 Standard, Enterprise,

Microsoft Windows Server 2008 Standard, Enterprise,

Microsoft Windows Server 2008 Standard, Enterprise,

Microsoft Windows Server 2012 Standard, Datacenter     

The App-V Book App-V Native Deployment Infrastructure 5

SUPPORTED DATABASE PLATFORMS

There’s a maximum of two databases in the App-V Native Infrastructure

Microsoft SQL Server 2008 Standard, Enterprise, Datacenter or Developer

Microsoft SQL Server 2012 (Standard, Enterprise, Datacenter or Developer

The App-V Book App-V Native Deployment Infrastructure 6

Previous App-V 5.0 server components can’t be installed on a system that

The App-V Book App-V Native Deployment Infrastructure 7

The App-V Book App-V Native Deployment Infrastructure 8

APP-V MANAGEMENT SERVER