IPD - Microsoft Application Virtualization 4 6

Infrastructure Planning
and Design
Microsoft Application Virtualization 4.6
Version 2.0
Published: September 2008

Updated: February 2010
For the latest information, please see www.microsoft.com/IPD
Copyright © 2010 Microsoft Corporation. This documentation is licensed to you under the
Creative Commons Attribution License. To view a copy of this license, visit
http://creativecommons.org/licenses/by/3.0/us/ or send a letter to Creative Commons, 543
Howard Street, 5th Floor, San Francisco, California, 94105, USA. When using this
documentation, provide the following attribution: Infrastructure Planning and Design is provided
with permission from Microsoft Corporation.
This documentation is provided to you for informational purposes only, and is provided to you
entirely "AS IS". Your use of the documentation cannot be understood as substituting for
customized service and information that might be developed by Microsoft Corporation for a
particular user based upon that user’s particular environment. To the extent permitted by law,
MICROSOFT MAKES NO WARRANTY OF ANY KIND, DISCLAIMS ALL EXPRESS, IMPLIED AND
STATUTORY WARRANTIES, AND ASSUMES NO LIABILITY TO YOU FOR ANY DAMAGES OF ANY
TYPE IN CONNECTION WITH THESE MATERIALS OR ANY INTELLECTUAL PROPERTY IN THEM.
Microsoft may have patents, patent applications, trademarks, or other intellectual property rights
covering subject matter within this documentation. Except as provided in a separate agreement
from Microsoft, your use of this document does not give you any license to these patents,
trademarks or other intellectual property.
Information in this document, including URL and other Internet Web site references, is subject to
change without notice. Unless otherwise noted, the example companies, organizations, products,
domain names, e-mail addresses, logos, people, places and events depicted herein are fictitious.
Microsoft, Active Directory, SQL Server, Windows, Windows Server, and Windows Vista are either
registered trademarks or trademarks of Microsoft Corporation in the United States and/or other
countries.
The names of actual companies and products mentioned herein may be the trademarks of their
respective owners.
You have no obligation to give Microsoft any suggestions, comments or other feedback
(“Feedback”) relating to the documentation. However, if you do provide any Feedback to
Microsoft then you provide to Microsoft, without charge, the right to use, share and
commercialize your Feedback in any way and for any purpose. You also give to third parties,
without charge, any patent rights needed for their products, technologies and services to use or
interface with any specific parts of a Microsoft software or service that includes the Feedback.
You will not give Feedback that is subject to a license that requires Microsoft to license its
software or documentation to third parties because we include your Feedback in them.
Solution Accelerators microsoft.com/technet/SolutionAccelerators

Contents
The Planning and Design Series Approach......................................................1
Introduction to the Microsoft Application Virtualization Guide........................2
Application Virtualization in Microsoft Infrastructure Optimization................5
Application Virtualization Design Process.......................................................6
Step 1: Determine the Project Scope..............................................................9
Step 2: Determine Which Model(s) Will Be Needed.......................................10
Step 3: Determine How Many Instances Will Be Needed for Each Model.......15
Step 4: Client and Sequencer Considerations................................................17
Step 5: Design the Streaming Infrastructure................................................21
Step 6: Design the Full Infrastructure..........................................................25
Conclusion...................................................................................................32
Appendix: Job Aids......................................................................................33
Version History............................................................................................34
Acknowledgments........................................................................................35

The Planning and Design Series
Approach
This guide is one in a series of planning and design guides that clarify and streamline the planning and design
process for Microsoft® infrastructure technologies.
Each guide in the series addresses a unique infrastructure technology or scenario. These guides include the
following topics:
 Defining the technical decision flow (flow chart) through the planning process.
 Describing the decisions to be made and the commonly available options to consider in making the
decisions.
 Relating the decisions and options to the business in terms of cost, complexity, and other characteristics.
 Framing the decision in terms of additional questions to the business to ensure a comprehensive
understanding of the appropriate business landscape.
The guides in this series are intended to complement and augment the product documentation.
Benefits of Using This Guide

Using this guide will help an organization to plan the best architecture for the business and to deliver the most
cost-effective Microsoft Application Virtualization (App-V) 4.6 infrastructure.
Benefits for Business Stakeholders/Decision Makers:
 Most cost-effective design solution for an implementation. IPD eliminates over-architecting and over-
spending by precisely matching the technology solution to the business needs.
 Alignment between the business and IT from the beginning of the design process to the end.
Benefits for Infrastructure Stakeholders/Decision Makers:
 Authoritative guidance. Microsoft is the best source for guidance about the design of Microsoft products.
 Business validation questions to ensure the solution meets the requirements of both business and
infrastructure stakeholders.
 High integrity design criteria that includes product limitations.
 Fault-tolerant infrastructure, where necessary.
 Proportionate system and network availability to meet business requirements. Infrastructure that is sized
appropriately to meet business requirements.
Benefits for Consultants or Partners:
 Rapid readiness for consulting engagements.
 Planning and design template to standardize design and peer reviews.
 A “leave-behind” for pre- and post-sales visits to customer sites.
 General classroom instruction/preparation.
Benefits for the Entire Organization:
Using this guide should result in a design that will be sized, configured, and appropriately placed to deliver a
solution for achieving stated business requirements, while considering the performance, capacity,
manageability, and fault tolerance of the system.

Introduction to the Microsoft
Application Virtualization Guide
Application coexistence continues to be a significant issue for business customers.
The task of managing the portfolio of applications in a company is a very complex process, and few tools are
available to assist in this process. Some of the challenges that occur when managing applications include
accommodating multiple versions of the same application as well as updating application packages.
Microsoft Application Virtualization (App-V) enables organizations to respond to the challenge by providing the
capability to make applications available to end-user computers without having to install the applications directly
on those computers.
The purpose of this guide is to present a clear and concise workflow of the decisions and tasks required to
implement App-V. This guide, when used in conjunction with product documentation, will enable companies to
confidently plan their App-V infrastructures.
The Appendix includes a sample job aid for recording the decisions made during the design process.
What’s New in Microsoft Application

Virtualization 4.6
The App-V 4.6 product provides the following enhancements and new features:
 Delivers support for 64-bit operating systems. Provides the ability to sequence and run 32-bit and 64-
bit applications on 64-bit Windows® 7, Windows Vista®, Windows XP, and Windows Server® 2008 R2,
including on Remote Desktop Session Host (RD Session Host) servers.
 Support for Windows 7 and Windows Server 2008 R2. Provides support for Windows 7 and Windows
Server 2008 R2, including support for Windows 7 features such as the taskbar, Jump List, AppLocker,
BranchCache, and BitLocker to Go.
 Expands globalization and localization. Provides 12 additional languages to support both virtualization
of non-English applications and running the App-V user interface in additional non-English languages.
 Adds support for Virtual Desktop Infrastructure (VDI) systems. Provides capability for read-only
shared cache to help optimize server disk storage in VDI scenarios.
 Improved sequencing experience. Provides improvements to the sequencing wizard and support for
sequencing 32-bit and 64-bit applications.
Assumptions
In writing this guide, the following assumptions were made in order to focus the scope of the material presented:
 The decision to implement Microsoft Application Virtualization has already been made.
 The reader has familiarity with Microsoft technologies such as Active Directory® Domain Services
(AD DS), Microsoft SQL Server®, Systems Management Server, System Center Configuration Manager
2007, file servers, and IIS servers. This guide does not attempt to educate the reader on the features and
capabilities of these or other Microsoft products.

Feedback
Please direct questions and comments about this guide to satfdbk@microsoft.com.
Please provide feedback on the usefulness of this guide by filling out the following survey:
http://go.microsoft.com/fwlink/?LinkID=132579.

4 Infrastructure Planning and Design
IPD in Microsoft Operations Framework

(MOF) 4.0)
Microsoft Operations Framework (MOF) offers integrated best practices, principles, and activities to assist an
organization in achieving reliable IT solutions and services. MOF provides guidance to help IT individuals and
organizations create, operate, and support IT services, while helping to ensure the investment in IT delivers
expected business value at an acceptable level of risk. MOF’s question-based guidance helps to determine
what is needed for an organization now, as well as providing activities that will keep the IT organization running
efficiently and effectively in the future.
Use MOF with IPD guides to ensure that people and process considerations are addressed when changes to
an organization’s IT services are being planned.
 Use the Plan Phase to maintain focus on meeting business needs, consider business requirements and
constraints, and align business strategy with IT strategy. IPD helps to define an architecture that delivers
the right solution as determined in the Plan Phase.
 Use the Deliver Phase to build solutions and deploy updated technology. In this phase, IPD helps IT pros
design their IT infrastructures.
 Use the Operate Phase to plan for operations, service monitoring and control, as well as troubleshooting.
The appropriate infrastructure built with the help of IPD guides can increase the efficiency and
effectiveness of operating activities.
 Use the Manage Layer to work effectively and efficiently to make decisions that are in compliance with
management objectives. The full value of sound architectural practices embodied in IPD will help deliver
value to the top levels of a business.
Figure 1. The architecture of Microsoft Operations Framework (MOF) 4.0

Application Virtualization in Microsoft

Infrastructure Optimization
The Infrastructure Optimization (IO) Model at Microsoft groups IT processes and technologies across a
continuum of organizational maturity. (For more information, see http://www.microsoft.com/infrastructure.) The
model was developed by industry analysts, the Massachusetts Institute of Technology (MIT) Center for
Information Systems Research (CISR), and Microsoft's own experiences with its enterprise customers. A key
goal for Microsoft in creating the Infrastructure Optimization Model was to develop a simple way to use a
maturity framework that is flexible and can easily be applied as the benchmark for technical capability and
business value.
IO is structured around three information technology models: Core Infrastructure Optimization, Application
Platform Optimization, and Business Productivity Infrastructure Optimization. According to the Core
Infrastructure Optimization Model, having administrator-controlled automated physical or virtual application
distribution will help move an organization to the Rationalized level. App-V gives the administrator control over
application distribution by delivering applications that are never installed, yet securely follow users anywhere, on
demand. On the path to the Dynamic level, organizations can use App-V to enable dynamic application access
and recovery for desktop applications.
Figure 2. Mapping of Microsoft Application Virtualization 4.6 technology into Core Infrastructure Model

Application Virtualization Design

Process
Application virtualization can best be described as running an application using a workstation or Remote
Desktop Session Host (RD Session Host) server without installing the application on the client operating
system. Instead of loading files into the program files directory and adding entries into the local registry, the
application is loaded into an isolated virtual environment on the client.
The goal of this guide is to address the most common scenarios, decisions, activities, options, tasks, and
outcomes relating to the process of implementing application virtualization. As with any significant change to the
Windows infrastructure, customers should review their planned changes with Microsoft Support Services to
ensure that the result will be an optimized and supported scenario.
The process of delivering virtualized applications to users via streaming is composed of two parts: The first part
involves publishing the application, which consists of delivering the shortcuts and file type associations,
package definition information, and content source location to each computer where the Microsoft Application
Virtualization Desktop Client or the Client for Remote Desktop Services (formerly Terminal Services) has been
installed. In the second part, the packaged virtual applications are deployed to the workstation or terminal
server. Alternatively, in an MSI deployment, the publishing information and deployment are combined in to a
single step.
The potential components of the Microsoft Application Virtualization architecture are shown in Figure 3 as a
reference.
Figure 3. Microsoft Application Virtualization architecture

Decisions
This guide addresses the decisions and/or activities that need to occur in planning an App-V implementation.
The following steps represent the most critical design elements in a well-planned App-V design:
 Step 1: Determine the Project Scope
 Step 2: Determine Which Model(s) Will Be Needed
 Step 3: Determine How Many Instances Will Be Needed for Each Model
 Step 4: Client and Sequencer Considerations
 Step 5: Design the Streaming Infrastructure
 Step 6: Design the Full Infrastructure
Some of these items represent decisions that must be made. Where this is the case, a corresponding list of
response options will be presented.
Other items in this list represent tasks that must be carried out. These types of items are addressed because
their presence is significant in order to complete the infrastructure design.
Decision Flow
The following figure provides a graphical overview of the steps in designing an App-V infrastructure.
Figure 4. The Microsoft Application Virtualization infrastructure decision flow

Applicable Scenarios
This guide addresses the following considerations that are related to planning and designing the necessary
components for a successful App-V infrastructure:
 Planning for streaming applications or deploying via software management systems.
 Planning for centralized, decentralized, or departmental use.
 Planning for isolated use, such as a lab or classroom.
 Planning for Internet-based clients.
 Rapidly deploying a new version of an application.
Out of Scope
This guide will not cover the mechanics (such as step-by-step directions) of delivering virtualized application
packages to desktops.

Step 1: Determine the Project Scope

Before designing a Microsoft Application Virtualization infrastructure, an organization needs to determine the
project’s scope: that is, determine which applications will be available virtually and identify the target user
population, and their locations, that will access them. The output of this step will be used to determine what type
of App-V infrastructure should be implemented in Step 2 and to drive the sizing and placement of the servers in
Steps 5 and 6.
Task 1: Determine Application Scope

Depending on the applications to be virtualized, the App-V infrastructure may be set up in different ways. The
first task is to define what applications the business needs virtualized. Record which applications the
organization plans to virtualize in Table A-1 in the Appendix. This list will be used at the end of this step to
validate with the business.
Task 2: Determine Location Scope

Location scope refers to the places (for example, enterprise-wide or a specific geographic location) where the
virtualized applications will be used. It can also refer to the user population (for example, a single department)
who will use them. Obtain a network map that includes the connection paths as well as available bandwidth to
each location. The number of users using virtualized applications and the WAN link speed will be used in Step 5
to determine whether a streaming server should be deployed at the location. Because App-V can support
Internet-based clients, this may also include users not on the company network.
In Table A-2 in the Appendix, record:
 The location.
 The number of users at the location.
 The connection paths and available bandwidth to each location.
Validating with the Business

In the above tasks, several pieces of information were recorded for each application. However, it is important to
clarify several items with the business:
 Is each application to be virtualized supported by the vendor? There may be additional risks to the
business if the vendor does not support an application once it is virtualized. If a problem with a virtualized
application arises, it may be necessary to reproduce the problem with the application installed locally in
order to receive support.
 Does the licensing agreement allow each application to be virtualized? Not all applications can be
legally used in a virtualized environment.
Step Summary
Decisions about the scope of the project must be based on the specific needs of the organization. In this step,
information about the applications to be virtualized and their usage at locations in the company was gathered.
This information drives decisions in Steps 2 and 3 for determining the types and number of instances, and in
Step 5 for designing the streaming mechanism.

Step 2: Determine Which Model(s) Will

Be Needed
A model refers to the process by which virtualized applications are published and delivered to users.
Deciding how to deploy virtualized applications will come down to determining what model or combination of
models for distribution will be required in the organization’s environment to support the business scope defined
in Step 1.
The three models for distribution are:
 Standalone Model. The Standalone Model allows virtual applications to be MSI-enabled for distribution
without streaming.
 Streaming Model. The Streaming Model offers application streaming without requiring Active Directory or
a database; it enables administrators to stream from existing servers or via System Center Configuration
Manager 2007 SP1 with R2 distribution points.
 Full Infrastructure Model. The Full Infrastructure Model provides for built-in software distribution,
management, and reporting capabilities; it also includes the streaming of applications.
All models require a Microsoft Application Virtualization client to be installed on the workstation or RD Session
Host server. More details on each of the options are given below.
Note whether each model will be required somewhere in the organization. In Step 3,
it will then be determined which model to use to deliver virtualized applications for each location.
Standalone Model
App-V in Standalone Model consists of the sequencer and the Microsoft Application Virtualization client; no
additional App-V infrastructure is required. Applications are prepared for virtualization in a process called
sequencing. The sequencer packages the publication information, shortcuts, and the install routines into a
Windows Installer file (MSI), and the virtualized application in to an SFT file. The application can then be
distributed using existing installation method, such as:
 Active Directory publishing through Group Policy objects (GPOs).
 Media distribution via USB key or CD.
 Run from a file share or Web server.
 Software management systems such as System Center Configuration Manager (ConfigMgr) 2007 or
Microsoft Systems Management Server (SMS) 2003.

Figure 5. An example of App-V Standalone Model
When to Use Standalone Model

The Standalone Delivery Scenario enables an organization to realize the benefits of application virtualization in
situations where no servers are available to support other methods of deploying virtual applications. Use the
App-V Standalone Model:
 With disconnected remote users who cannot connect to the App-V infrastructure.
 Where software management systems, such as ConfigMgr 2007 and SMS 2003,
are already in place.
 Where network bandwidth limitations prevent electronic software distribution. In this case, virtual
application delivery on physical media can be used (for example, CD, DVD, USB key, and so on).
Streaming Model
App-V in Streaming Model consists of one or more streaming servers, the sequencer, and the App-V client;
another mechanism such as an electronic software distribution system or Group Policy will need to be used to
publish the application icons to the client. As with Standalone Model deployments, applications are sequenced
using the App-V sequencer. However, instead of being packaged with an MSI file, the App-V–enabled
applications are placed on a streaming server that streams applications to client computers. Streaming is the
term used to describe the process of obtaining content from a sequenced application package, starting with
Feature Block 1, and then obtaining additional blocks as needed, which allows the application to be quickly
available for the user.

The virtual application package content is placed on Microsoft System Center Application Virtualization
Streaming Servers so that the package can be streamed to the clients on demand and be cached locally. File
servers and Web servers can also be used as streaming servers. Streaming applications across a WAN is
supported but should be tested in the organization’s environment to ensure performance is acceptable.
Additionally, ConfigMgr 2007 SP1 with R2 distribution points can stream content to users; it provides the further
benefit of automating the redirection to the “closest” server for clients that roam. ConfigMgr 2007 can be used to
publish and deploy streaming applications and keep the content on the streaming servers synchronized.
Figure 6. An example of App-V Streaming Model
When to Use Streaming Model

The Application Virtualization Streaming Model addresses the needs of businesses that want to use App-V with
the streaming capabilities but might not have or want the infrastructure to support management servers. Unlike
the App-V Management Server, the App-V Streaming Server does not use SQL Server or a management
console. These servers use access control lists (ACLs) to manage user access.
Use App-V Streaming Model:
 Where ConfigMgr 2007 SP1 with R2 is already in place and the organization will use it for managing virtual
application publishing and delivery.
 Where Active Directory or SQL Server-based servers aren’t present, but the organization still wants to take
advantage of streaming virtual applications.
Full Infrastructure Model

An App-V Full Infrastructure Model consists of one or more Microsoft System Center Application Virtualization
Management Servers as the core of the App-V system architecture. The Application Virtualization Management
Server can be used to publish applications to all clients. The publishing process places the virtual application
icons and shortcuts on the computer—typically on the Windows desktop or on the Start menu. It can also
stream applications to local users. Streaming servers can then be deployed at remote locations to make

application content available to end-user computers. Streaming servers should be on the same high-speed LAN
connection as the clients.
A complete App-V management environment will be needed if any of the following features are required when
planning an App-V installation:
 Dynamic group-based application publishing. The shortcuts and file type associations will be published
to the clients by the Application Virtualization Management Server. Applications can be associated with
security groups in Active Directory. Users will only receive the applications if they are members of the
associated groups.
 License enforcement:
 Named license. A software package can be associated with a specific user name. Only the user who
is named in the policy will be able to launch the application.
 Concurrent license restrictions. Software that is licensed for concurrent usage can be metered out
based on the number of users currently using an application. If more than the defined number of
users attempts to launch the application, the surplus launch attempts will be denied access to the
application.
 Reporting. App-V provides a console for generating reports on system utilization, software usage,
application utilization, and system errors, or the data can be extracted to create custom reports.
Figure 7. Example of an App-V Full Infrastructure Model instance
When to Use Full Infrastructure Model

The Application Virtualization Full Infrastructure Model addresses the needs of businesses that want to use
App-V to manage and stream virtual applications to clients.
Use App-V Full Infrastructure Model:
 Where the organization wants to use the Application Virtualization Management Server to publish the
application shortcuts to the clients.
 Where the additional reporting or licensing capabilities of the Application Virtualization Management
Server are desired.
 For rapid provisioning of applications to clients.


In addition to evaluating the decision in this step against IT-related criteria, planners should validate the effect of
the decision on the business:
Do the benefits provided by the App-V Full Infrastructure Model warrant the costs? Although the App-V
Full Infrastructure Model provides some enticing features, the costs associated with implementing App-V in Full
Infrastructure Model are greater than using the existing infrastructure.
Step Summary
In this step, the three models for distributing virtualized applications to the clients were described, and it was
noted which might be needed in the organization. This will be used in Steps 3, 4, 5, and 6.
If the organization already has a method for publishing the applications to clients, then the Standalone or
Streaming Models may suffice. If no infrastructure is in place to publish applications or if the additional features
provided by the App-V Management Server are desired, then Full Infrastructure Model should be chosen. A
combination of models may be required to deliver virtual applications within the organization.
Deciding how to deploy App-V applications will come down to determining what model or combination of models
for distribution will be required in the organization’s environment.

Step 3: Determine How Many Instances

Will Be Needed for Each Model
In Step 2, it was decided what model or combination of models need to be employed to meet the application
virtualization needs of the organization. Step 3 will focus on determining how many instances of each model will
be required.
The Standalone Model can be used wherever it is needed in the organization since no infrastructure is required.
If the decision to only use the Standalone Model has been made, all that remains is to complete Step 4.
Task 1: Determine the Number of Streaming

Model Instances
If it was determined in Step 2 that Streaming Model instances would be required, complete this task to
determine how many Streaming Model instances should be implemented. A Streaming Model instance is
defined as any type of streaming server that provides virtualized applications to a given location.
The following conditions apply when determining the number of instances:
 Each location that requires application virtualization should have a streaming server deployed locally.
Streaming applications across a WAN is supported but should be tested in the organization’s environment
to ensure performance is acceptable. Streaming should be limited to well-connected networks.
The use of BranchCache to augment a streaming infrastructure is supported. With BranchCache, virtual
applications traverse the WAN only once and are available to users faster through local BranchCache
points, eliminating the need for a file or IIS server in every branch.
 Internet-based clients may realize the benefits of application virtualization in a streaming environment by
the use of an ISA server or by placing a streaming server in a perimeter network (also known as DMZ).
Record the streaming model instance defined for each location in Table A-2 in the Appendix.
Task 2: Determine the Number of Full

Infrastructure Model Instances
If it was determined in Step 3 that Full Infrastructure Model instances are required, complete this task to
determine how many instances are needed. An App-V Full Infrastructure Model instance is anchored by a
single SQL Server database. Separate databases define separate instances.
Examples of business requirements that may require separation of App-V onto more than one instance include
the following:
 Technical. If the organization expects more than 12,000 publishing refresh operations per minute, a
separate instance may be required. A publishing refresh is a call to the Management Server to determine
which virtual application shortcuts are sent to the client for use by the end user. By default, this occurs at
logon and then once per day.
 Political. Different groups within the organization might each require their own installations.
 Regulatory requirements. Regulatory requirements can require total separation of an environment from
other environments.
 Isolation. A separate App-V instance may be required for testing applications before release.
Record in Table A-2 in the Appendix the locations that will be part of each Full Infrastructure Model instance.
Step Summary
In this step, the number of App-V Full Infrastructure Model instances was determined, and an App-V Streaming
Model instance was determined for each location requiring
App-V–enabled applications and recorded in Table A-2 in the Appendix. Ensure that each user and location that
needs to receive virtualized applications as identified in Step 1 can receive them via one of the methods above.
Note that the Standalone Model can be used wherever it is needed in the organization since no infrastructure is
required.
The reader has a choice at this juncture. If the decision to only use the Standalone Model has been made, all
that remains is to complete Step 4. If the decision to use the Streaming Model has been made, then Steps 4
and 5 need to be completed. If the organization will be using one or more Full Infrastructure Model instances,
then Steps 4, 5, and 6 will need to be completed.
Step 4: Client and Sequencer

Considerations
Certain considerations relating to clients and sequencers need to be taken into account when utilizing Microsoft
Application Virtualization in a production environment. Although these considerations do not affect the decisions
around the infrastructure design, they do have an impact on the day-to-day performance and functioning of the
environment.
Task 1: Client Considerations

The Application Virtualization client is the component that actually runs the virtual applications. The Application
Virtualization client enables users to interact with icons and to double-click file types to start a virtual application.
It also handles streaming of the application content from a streaming server and caches it before starting the
application.
There are two different types of Application Virtualization client software: the Application Virtualization Client for
Remote Desktop Services, which is used on RD Session Host servers, and the Application Virtualization
Desktop Client, which is used for all other computers.
Ensure that the client cache is large enough to handle the applications being assigned to the user. If the cache
is not scaled properly, then the user can experience application failures when disconnected. This occurs
because the cache may have flushed the application in preference for another more recently run application.
The client cache can be modified through the Desktop Configuration Client, which is installed with the App-V
client on the workstation. The maximum cache size is 1 terabyte.
RD Session Host Servers

RD Session Host servers or terminal servers can be used to take advantage of App-V virtual applications. Once
an application is loaded on an RD Session Host server in the App-V cache, any user who has permissions for
that application will benefit from loading it out of cache. Additionally, App-V can be used as an application
coexistence tool. Because each application runs in its own virtual environment, applications that normally could
not be installed on the same computer are able to co-exist, which may reduce the need for multiple servers.
RD Session Host Server Standalone Model

The RD Session Host server can run applications deployed as an MSI. The App-V client needs to be installed
using Remote Desktop Services install mode; however, when the App-V client has been installed, sequenced
applications will be loaded into the client cache and will be ready for execution. Apart from not having to install
the application in install mode, there is virtually no functional difference for end users accessing the RD Session
Host server.
RD Session Host Server in a Streaming or Full Infrastructure Model

Applications can also be delivered to RD Session Host servers via App-V in a Streaming Model or Full
Infrastructure Model. Because multiple users will be accessing the RD Session Host server to use applications
installed with App-V, it is recommended to pre-cache the applications for improved performance. Using
streaming infrastructure, applications sequenced for desktops can be deployed to an RD Session Host server
without any modifications.

RD Session Host servers should have sufficient network throughput to the App-V streaming servers to ensure
that applications can be quickly loaded and cached on the RD Session Host server. Furthermore, if an
application is updated through App-V, the RD Session Host server can quickly update its cache. If there is a
significant delay in updating an application, all users who attempt to use the application in question will not be
able to access it for the time the update is being loaded. Application updates can only occur after the last user
has exited the application. The update will then take place the next time that the application is launched.
Task 2: Sequencer Considerations

Sequencing is the process used by Application Virtualization to create virtual applications and application
packages. It requires the use of a computer with the Microsoft Application Virtualization Sequencer software
installed.
The sequencer application requires a workstation that should be configured ideally identical to a client
workstation found in the production environment in which the App-V infrastructure will be deployed. Applications
should be sequenced on the same version OS as in the environment.
The sequencer should not install any App-V client agents or antivirus software. This requirement stems from the
way the sequencer scans for resource usage while applications are being sequenced. In the case of agents, the
sequencer may capture information that is unique to a single instance of the agent. It is possible to create a
sequenced package with DLLs or other configuration information from antivirus software, which may be
undesirable.
Application dependencies occur when a software package requires a particular application to function properly.
For example, many applications require a custom SQL Server 2005 Express instance. If the instance is not
installed by the application,
it may be necessary to sequence the SQL Server Express and the application requiring SQL Server into the
same package. Middleware applications can be sequenced and packaged separately from the main application.
Multiple applications can communicate with the same single instance of the virtualized middleware.
The sequencer workstation can be either a physical workstation or a virtual workstation.
Physical Sequencer
The following considerations should be taken into account when planning to use a physical sequencer:
 When using a physical workstation, a reference disk image of the computer should be created once the
sequencer is installed. Each time an application is sequenced, the image should be reapplied to the
workstation to reset the computer. Physical machine sequencing will be able to sequence an application
much more quickly than virtual machine sequencing.
 With its slower reset time, the system will need to be re-imaged in order to sequence the next application.
 If the application has specific hardware library dependencies, such as graphics accelerators (for example,
CAD software), a physical server might be more desirable.

Virtual Sequencer
Virtual machines are ideal for sequencing applications and can be quickly and easily reset. It is possible to
quickly revert a sequencer to its base environment, which is ideal for sequencing many applications. Two virtual
hard disks will be required: the first for the OS and the second dedicated to the virtual drive for the App-V client.
The following consideration should be taken into account when planning to use a virtual sequencer:
 The system is slower to sequence applications due to running in a virtual machine than on a physical
machine. This does not usually cause a significant issue.
The Microsoft Application Virtualization Sequencer system environment must also be configured to match
deployment environments. An App-V package uses a virtual drive on the client to store sequenced application
files. When building the sequencer, it is important to physically designate a drive on the computer used for
sequencing. By default, this is a drive mapped to drive Q. On a physical computer, this can be a separate
partition mapped to the sequencer drive letter, or it can be a new hard drive in the computer. In a virtual
machine, this is best defined as a new virtual drive and is then configured as drive Q in Windows Volume
Manager.
Placing the Sequencer

Antivirus software can create issues during sequencing as any changes done to the antivirus software can be
captured by the sequencing process. For example, a new signature update could be captured as part of the
application sequencing. When this application is run, the signature could potentially interfere with the operation
of the client’s antivirus software, particularly if there are more recent signature updates. Because of this,
sequencers are frequently configured without antivirus software. If the sequencer does not have antivirus
software installed, it is recommended that the sequencer be placed in an isolated environment that is
disconnected from the production network.
This reduces the risk of the sequencer being affected by malware.
In some cases, it may be necessary to allow the sequencer workstation to communicate with a production
server in order to fully configure and test an application. In these scenarios, it may be necessary to run antivirus
software on the sequencer to comply with corporate policy. If antivirus software is installed, it is recommended
that it be disabled during sequencing. Alternatively, the server infrastructure can be reproduced in the
sequencer environment; however, this will increase the complexity of configuring and managing the sequencing
environment.
In situations with multiple App-V instances, the sequencer should usually be deployed to the same location that
manages applications for the organization. If the organization has a distributed administrative model, it could be
necessary to have a sequencer environment wherever there is an administrative authority.
Step Summary
In this step, it was decided whether to sequence on a virtual environment or a physical environment. It was also
determined where to place the sequencer.
If it was decided that only the Standalone Model will be used, the planning and design is complete. If it was
decided that Streaming or Full Infrastructure Models will be used, proceed to Step 5 to design the streaming
infrastructure.

Additional Reading
 Planning and Deployment Guide for the Application Virtualization System: http://technet.microsoft.com/en-
us/library/cc843778.aspx
 Microsoft Application Virtualization documentation: http://technet.microsoft.com/en-
us/library/dd351468.aspx
 The App-V Blog : Do I need to re-sequence my applications when I move to a new OS?:
http://blogs.technet.com/softgrid/archive/2009/12/14/do-i-need-to-re-sequence-my-applications-when-i-
move-to-a-new-os.aspx
 “Application Virtualization 4.5 for Terminal Services“
http://download.microsoft.com/download/6/9/0/69095D7C-649D-4A0E-AF0B-17B26EACCF67/App-V
%20Terminal%20Services.docx
 “Virtual Application Management with Microsoft Application Virtualization 4.5 and System Center
Configuration Manager 2007 R2“ http://download.microsoft.com/download/f/7/8/f784a197-73be-48ff-83da-
4102c05a6d44/App-V_and_ConfigMgr_Whitepaper_Final.docx
 “App-V Application Publishing and Client Interaction”:
http://download.microsoft.com/download/f/7/8/f784a197-73be-48ff-83da-
4102c05a6d44/AppPubandClientInteraction.docx
 Microsoft Application Virtualization 4.5 Sequencing Guide:
http://download.microsoft.com/download/f/7/8/f784a197-73be-48ff-83da-4102c05a6d44/App-
45_Sequencing_Guide_Final.docx

Step 5: Design the Streaming

Infrastructure
Streaming is the term used to describe the process of obtaining content from a sequenced application package,
starting with Feature Block 1, and then obtaining additional blocks as needed.
Once a shortcut has been placed on the user’s workstation (through any preferred publishing mechanism), the
user double-clicks the icon and the Microsoft Application Virtualization client will obtain the virtual application
package content in the form of an .SFT file from a streaming source location.
The purpose of this step is to select a streaming server type for each location defined in the scope in Step 1.
Task 1: Determine the Streaming Server

Types
For each Streaming Model instance identified in Step 3, determine the streaming server type. The following
streaming options are available to stream the .SFT files from the server(s) to the clients:
 File server. Server Message Block (SMB) streaming allows the App-V client to download applications
from a file server. No additional software is loaded on the server. The App-V application shortcut on the
client is configured to point to a folder share on the file server. Access permissions are managed through
share, folder, and file permissions in the same manner as any shared file. App-V clients running Windows
7 or Windows Server 2008 R2 can utilize BranchCache technology to reduce the need for a file server in
every branch.
 IIS server. A Web server can be used to stream applications to an App-V client.
No additional software is loaded on the server. A directory is created to contain the packages, and then a
virtual directory is created under the default Web site. App-V clients running Windows 7 or Windows
Server 2008 R2 can utilize BranchCache technology to reduce the need for an IIS server in every branch.
 Microsoft System Center Application Virtualization Streaming Server or Management Server.
Streaming using Real-time Transport Streaming Protocol (RTSP) requires installing App-V software on the
server and the creation of a folder as a standard file share. RTSP allows IT to use such features as Active
Upgrade, which allows for transparent application updates to be installed while the current version is in
use. This role can be installed by itself or on the Management Server if the Full Infrastructure Model is
used.
Beginning with ConfigMgr 2007 R2, distribution points can be enabled for streaming; this provides the further
benefit of automating the redirection to the “closest” server for clients that roam. ConfigMgr 2007 can be used to
publish and deploy streaming applications and keep the content on the streaming servers synchronized.
ConfigMgr 2007 SP1 with R2 uses IIS on standard distribution points and file server SMB streaming on branch
distribution points.
The product group has tested and determined that for the initial package load, file, IIS, and Application
Virtualization Streaming Servers or Management Servers will perform similarly. However, the cached launch
performance of IIS servers and file servers is several times better than the cached launch performance of the
Application Virtualization Streaming Servers or Management Servers due to the efficiency of the protocol.
The characteristics of these different options are summarized in the following table.

Table 1. Package Streaming Methods

Server type Protocol Advantages Disadvantages
File server SMB  Simple, low-cost solution to No active upgrade1

configure existing file server
with \CONTENT share
 Supports enhanced security using
IPsec
 Familiar protocol
IIS server HTTP/HTTPS  Supports enhanced security using No active upgrade1

HTTPS protocol
 Only one port in firewall to open
 Scalable
 Familiar protocol
Application RTSP/RTSPS  Active upgrade Server administration

Virtualization requirement
 Supports enhanced security using
Streaming Can handle fewer
RTSPS protocol
Server or simultaneous cached
 Only one port in firewall to open launches than file or IIS
Management servers
Server
Note ConfigMgr 2007 SP1 with R2 uses IIS on standard distribution points and file server SMB
streaming on branch distribution points.
1
Note An alternative transparent way of providing new versions of applications to users for IIS
or SMB streaming servers is to revise the OSD file to specify a new SFT file name (for example,
*_2.SFT) and send those with the next publishing refresh. When a user’s computer is started, the
client searches for the new file name, differentially streams the blocks down, and starts the new
application automatically. This may mitigate the need for Active Upgrade functionality.
Task 2: Determine the Streaming Server

Scaling
A single file or IIS server with a local content directory will support over 100,000 cached launches per minute.
Additional servers in a network load-balanced configuration can provide greater levels of availability and scale
out if needed. An Application Virtualization Streaming Server or Management Server can support much less—
around 1,800 cached launches on the same hardware as the file or IIS servers. For more information, including
detailed information on testing methodology for App-V server sizing, see:
http://download.microsoft.com/download/1/6/1/161042F3-9CDE-45F7-BC20-
4FBDA8888890/AppV45_ServerSizingGuide_Final.docx.
Some key points that might affect the server or environment should be considered:
 The RTSP(s) protocol used by the Streaming Server does not provide a means for limiting the amount of
network bandwidth the system will attempt to use. In highly starved networks with low available bandwidth,
the ability to successfully stream an application can be greatly hindered due to network saturation.
 The pattern of access to the applications can affect the server. Large numbers of users launching an
application at a specific time can saturate the network and stress the Streaming Servers. If applications
are frequently updated or if a large number of updates have been made, then large amounts of data can
be put onto the network.

 The method of deploying the application in the environment can have an impact.
For example, are applications fully cached on the client? This results in only pulling updates when the
application is patched. However, it also requires a large download of the application initially. If an
application is streamed on demand, then a smaller amount of data is initially streamed. But depending
upon usage, additional blocks will be streamed and cached when new features are invoked that were not
part of Feature Block 1. In addition to network performance impacts due to the amount and frequency of
the streamed data, the act of streaming also has a processor impact on the server. A sufficiently large
number of streams can cause the server’s performance to degrade, regardless of the available network
bandwidth.
 Additionally, depending upon the protocols chosen, additional processor overhead can be incurred with
streaming. If a protocol that supports encryption is used, then additional processor overhead is required to
encrypt the stream.
This is just a sampling of the variables that can affect the performance and scaling of the streaming servers.
Because a number of these variables are related to the environment, testing within the environment where the
App-V services will run is required. Once a baseline is established on the size of the servers, additional servers
can be added for redundancy and/or to increase capacity. Start with one streaming server (or two if required for
fault tolerance), and add additional servers as required. Performance monitoring should be done on the
streaming servers to help plan for additional capacity and performance requirements. Enough free drive space
should be available on the server(s) or a highly connected network access server (NAS) to hold the applications
being streamed.
Task 3: Determine Fault-Tolerance Approach

Fault tolerance for Microsoft System Center Application Virtualization Streaming Servers using RTSP/RTSPS
protocol is achieved by load balancing streaming servers. If Microsoft System Center Application Virtualization
Streaming Servers are to stream different applications, assign the servers to separate load-balanced groups.
For file servers used for streaming, implement failover clusters to gain fault tolerance; and for IIS, implement
load balancing. For additional discussion about fault-tolerance options available to file servers, see the
Infrastructure Planning and Design guide: Windows Server 2008 File Services; and for IIS, see the IPD guide:
Internet Information Services 7.0.
Task 4: Maintaining Application Packages

Across Multiple Streaming Servers
With potentially multiple virtualized application packages stored on potentially many systems, it may be
beneficial to consider an automated approach to keeping these applications and shares consistent. DFS-R and
DRS namespaces can be used to provide fault tolerance and synchronization. See the DFS section in the
Infrastructure Planning and Design Guide: Windows Server 2008 File Services for more information.


In this step, decisions must not only be evaluated against IT-related criteria; their effect on the business should
also be considered:
 Are there any regulatory or policy requirements governing the need for encryption? Many
companies have compliance and privacy laws that affect applications. It is important to make sure that
applications that interact with sensitive business information and data be kept in compliance with legal and
security policies.
 Is there sufficient cost justification to warrant fault tolerance for the streaming infrastructure?
Given that the streaming server is only accessed to load the application for first use, the organization may
want to weigh whether the costs of implementing fault tolerance are justified.
Step Summary
Although an organization may have a mix of streaming server types, each client can connect to only one type at
a time. The setting for the application content source is defined by the choice of streaming method for that
client.
In this step, the method that the Microsoft Application Virtualization Management System will use to stream the
virtual application packages, or .SFT files, from the server to the clients was determined.
If a Full Infrastructure Model instance was selected, proceed to Step 6 to design the infrastructure.
Additional Reading
 Infrastructure Planning and Design guide: Windows Server 2008 File Services:
http://www.microsoft.com/downloads/details.aspx?FamilyId=AD3921FB-8224-4681-9064-
075FDF042B0C&displaylang=en
 Infrastructure Planning and Design guide: Internet Information Services 7.0:
http://www.microsoft.com/downloads/details.aspx?FamilyId=AD3921FB-8224-4681-9064-
075FDF042B0C&displaylang=en
 App-V 4.5 Server Sizing Guide: http://download.microsoft.com/download/1/6/1/161042F3-9CDE-45F7-
BC20-4FBDA8888890/AppV45_ServerSizingGuide_Final.docx
 Application Virtualization 4.5 documentation page: http://technet.microsoft.com/en-
us/appvirtualization/cc843994.aspx

Step 6: Design the Full Infrastructure

In Step 5, the streaming infrastructure was designed. If it was determined in Step 2 that the Full Infrastructure
Model is needed, this step will determine the server resource scaling requirements and fault tolerance for each
role. This step will need to be repeated for each Full Infrastructure Model instance defined in Step 3.
An App-V Full Infrastructure Model instance includes the following server roles:
 A Microsoft System Center Application Virtualization Management Server.
 A streaming server, which streams applications to clients.
 A server running Microsoft SQL Server, for App-V configuration data.
The following roles, while required, are not covered in detail since they have no significant infrastructure
architecture discussion requirements:
 Active Directory Domain Services, for user authentication and application security management.
 A client or server running the Microsoft Application Virtualization Management Console.
 A sequencer for creating the virtualized application packages. Since the application packages can be
shared between instances, not all instances require a sequencer.
 App-V client installed on systems that require application virtualization: desktops, virtual machines (VMs),
or RD Session Host servers.
Task 1: Server Resource Considerations

For detailed information on App-V server sizing, see: http://download.microsoft.com/download/1/6/1/161042F3-
9CDE-45F7-BC20-4FBDA8888890/AppV45_ServerSizingGuide_Final.docx.
Management Server
Management Servers can be configured to perform the publishing refresh process, stream or load applications,
and authorize the launch of cached applications. In testing, it was found that if a Management Server only
performs the publishing refresh process, it can support a very large population (approximately 480,000
publishing refreshes per hour). Implementing the additional processes of loading and launching cached
operations are additive and will effectively reduce the maximum population that could be supported. Adding the
loading or streaming of packages will further reduce the performance of a single Management Server.
To increase the number of users that a Full Infrastructure Model instance is able to support, add additional
servers via load balancing.
Management Server Service

The Management Server service is used by the Management Console to control the
App-V system as well as to run reports. With the exception of running reports, other requests of the service are
extremely lightweight.
An important consideration to make if the Management Server service is placed on the Management Server is
the negative performance impact that report generation can have in large environments. For this reason, it is
recommended to have a dedicated server to host the Management Server service in large environments that
will be running reports.

SQL Server
The App-V SQL Server database is a required component in an App-V Full Infrastructure Model
implementation. The database contains configuration information and stores usage information for the App-V
infrastructure. The following is a list of App-V infrastructure operations that use the database:
 Publishing refresh
 Application load
 Application launch authorization
 Management Console
 Online/offline client application usage data collection and reporting or offline metering
Most of these are lightweight operations and will place a very small load on the server running SQL Server.
However, the offline metering will place a load on both the server and network based on the number of users
and the amount of application usage data that is collected.
Running the built-in reporting capabilities available on the App-V Management Console in large environments
can potentially add significant CPU load on the App-V SQL Server-based server. In such environments, the
product group recommends to periodically extract the data to a new database on a different server running SQL
Server so that custom reports can be generated against it using existing reporting tools available in the
organization.
The Microsoft Application Virtualization data store can be located on a dedicated SQL Server instance, or it may
be located on a SQL Server instance that has sufficient capacity to accommodate the App-V database along
with any other databases that reside on that instance.
Database Sizing
Database sizing and growth are primarily dependent on application launches and retained reporting information.
These operations are ongoing and continually add to the size of the database. These two processes will need to
be calculated along with any database cleanup operations to predict the proper size of the database. Other
database operations such as adding an application, adding new App-V clients, and fixing client errors will not
significantly increase the size of the database.
If a user launches and shuts down one application per hour for a normal work day, for a population of 10,000
users, the total impact to the database would be approximately 125 MB per day.
The following equation can be used to approximate the amount of data created by launching applications
against a Management Server:
(560 bytes per launch and shutdown) X (number of launches per day) X (user population) = Daily
database growth
Note This should only include applications launched from the Management Server, not from
Streaming Servers, IIS servers, or file servers, as that data is not captured and sent to the data
store.
If one application was launched each hour by a user all day, for a population of 10,000 users, the total would be
approximately 80 MB of data added to the data store each day.
The following equation can be used to approximate the amount of data created by application usage
information:
(365 bytes per application launched) X (number of launches per day) X (user population) = Daily
database growth
Task 2: Determine Fault Tolerance for Each

Role
A number of services are important to the functionality of the App-V infrastructure.
In order to increase the reliability and availability of these services, additional technology can be used to
increase each component system’s fault tolerance.
Component-level fault tolerance, such as hard drive mirroring, is not discussed at an App-V role level.
Management Server Service

Any server may host the Management Server service as long as it can communicate with the App-V database
and AD DS. The Management Server service reads and writes configuration data to the App-V database as well
as querying Active Directory for group membership information. Typically, this service will be installed on the
Management Server in smaller installations. The Management Console can be placed on the same
Management Server, or it may be placed on an administrator’s workstation.

The Management Server service is only used to configure the App-V environment and generate reports. If the
service fails, the App-V system will continue to function normally with the exception of App-V management
changes and reporting.
App-V does not offer any automatic fault tolerance for the Management Server service, so it is a single point of
failure to be monitored in the system.
Record the server(s) designated to hold the Management Server service in Table A-3 in the Appendix.
Microsoft SQL Server Fault Tolerance

App-V requires SQL Server 2000 (SP3a or SP4), SQL Server 2005 (SP1 or SP2), or
SQL Server 2008. Data about the application, license management, and reporting are kept in the SQL Server
database. In locations where fault tolerance is not required, the SQL Server-based server can be installed on
the same server as the Management Server service and Management Server. For more information on the
Infrastructure Planning and Design guide for SQL Server 2008, see http://go.microsoft.com/fwlink/?
LinkId=163302.
If the App-V database is unavailable, no configuration changes can be made to the App-V system. Streaming
Servers that are currently running will continue to service clients. However, the Management Server service will
fail to run if the database is unavailable during startup.
SQL Server provides a number of mechanisms for fault tolerance. This includes database mirroring, log
shipping, server clustering, and peer-to-peer replication. Although all of these provide some form of increased
fault tolerance for a database, the only supported method for App-V today is server clustering.
Clustering SQL Server-based servers will increase the complexity of the environment. Server clusters are made
up of two or more servers that can assume the load of the other servers in the cluster in the event of a failure.
Creating a new cluster will require additional servers with the appropriate hardware to support the cluster
service. Clustering will also require a shared storage device that can be locally attached to the servers running
SQL Server, thus increasing the costs of deploying App-V.
Record the designated SQL Server-based server(s) and the selected fault-tolerance level in Table A-3 in the
Appendix.

Management Server
Management Servers perform a critical role in the App-V infrastructure. They are the servers that have direct
connectivity to the client workstations. The Management Server role must be deployed in the same location
and, if possible, on the same fast LAN as the SQL Server role in order to ensure good connectivity between the
Management Server and the App-V configuration information that is stored in the SQL Server database. In
locations where fault tolerance is not required, the Management Server can be deployed to the same server as
SQL Server and the Management Server service.
Fault tolerance is achieved by load balancing Management Servers. The Management Server is not cluster
aware nor has it been tested on a server cluster, so this configuration is not supported at this time. There are
two network load balancing options available: software-based NLB and hardware load balancer.
Option 1: Software-Based NLB

NLB is a cost-effective method for providing load balancing as well as a basic level of fault tolerance and
scalability. NLB does not query the health of the Real-Time Streaming Protocol (RTSP) on the server. This can
lead to a situation where the server appears healthy because the NLB heartbeat is detected; however, the App-
V Management Server service is down and will not answer client requests.
Although up to 32 systems can be placed in a single software-based NLB cluster using Microsoft NLB, it has
been observed in production that the effective performance of the system drops for cluster groups containing
more than six members, so independent verification testing should be conducted if needed.
Option 2: Hardware Load Balancer

To provide access to the Management Server array of servers and to recognize when a Management Server
has stopped responding to requests automatically, a hardware load-balancing solution that supports Hypertext
Transfer Protocol (HTTP) and RTSP is required. This level of configuration adds complexity to the overall
deployment of the App-V servers. Hardware load balancers also add costs to the App-V solution. Two or more
hardware load balancers are necessary. If only one is implemented, then the hardware load balancer becomes
the single point of failure. Because the handling of client connections is handled by specialized hardware,
hardware load balancers tend to scale to handle more concurrent client sessions than software-based load
balancers.
Record the server(s) designated as the Management Server and the selected fault tolerance in Table A-3 in the
Appendix.

Evaluating the Characteristics

Complexity
NLB NLB is simple to implement. Low
Hardware load Hardware load balancers tend to increase the complexity of the environment Medium
balancer due to the need for two and the additional knowledge needed.
Cost
NLB NLB is available in all editions of Windows Server 2003 and later. As a best Low
practice, an additional network adapter is added to all nodes in the cluster to
create a private network for the cluster heartbeat.
Hardware load Two or more hardware load balancers are needed to ensure fault tolerance. If High
balancer only one hardware load balancer is used, it becomes the single point of
failure.
Fault Tolerance
NLB NLB only provides fault tolerance at the machine level. If the application layer →
fails, NLB will not detect it.
Hardware load Hardware load balancers are able to detect application layer failures. ↑
balancer
Security
NLB NLB does not affect security if properly implemented. →

Hardware load Hardware load balancers can increase security of the infrastructure due to ↑
balancer rudimentary packet screening features.
Combining Server Roles

Discounting scaling and fault-tolerance requirements, the minimum number of servers needed for a location
with connectivity to Active Directory is one. This server will host the Management Server, Streaming Server,
Management Server service, and SQL Server roles. Server roles, therefore, can be arranged in any desired
combination since they do not conflict with one another.
Ignoring scaling requirements, the minimum number of servers necessary to provide a fault-tolerant
implementation is four. The Management Server, Streaming Server, and SQL Server roles are all capable of
being placed in fault-tolerant configurations. The Management Server service can be combined with any of the
roles, but remains a single point of failure.

Although there are a number of fault-tolerance strategies and technologies available, not all are applicable to a
given service. Additionally, if App-V roles are combined, certain fault-tolerance options may no longer apply due
to incompatibilities.
In Table A-3 in the Appendix, verify that incompatible fault-tolerance options have not been selected for server
roles that are to be combined.
Table 2. Compatible Fault-Tolerant Role Combinations
Role NLB Server clustering Minimum servers
SQL Server Not applicable √ 2
Streaming Server √ Not applicable 2
Management Server √ Not applicable 2
Management Server service Not applicable Not applicable Not applicable

Review the decisions made for each server role with the affected business units:
Is there sufficient cost justification to warrant fault tolerance? If applications must be available,
implementing a load-balanced and redundant solution may be a requirement of the deployment. It is important
to understand which applications are critical to the enterprise and how virtualization and streaming may affect
their availability to the parties that rely on them. Ensure that the business agrees that there is an appropriate
balance between the costs and fault-tolerance capabilities.
Step Summary
This step should be repeated for each Full Infrastructure Model instance. At this point, the requirements around
scaling and fault tolerance will have been identified, as well as the implementation necessary to meet those
requirements for a given App-V instance.
Fault tolerance for App-V in the Full Infrastructure Model or the Streaming Model provides a system that is able
to service client requests for new applications or updates. Applications that have previously been cached will
run in a disconnected mode in the event of an infrastructure failure.
Additional Considerations
The Microsoft System Center Application Virtualization Dashboard is a Windows SharePoint Services-based
application that lets customers utilize a browser based graphically rich reporting experience to provide a view of
multiple sets of App-V statistics on a single Web page. Customers can also customize and create more
dashboards to meet their business and organizational requirements.
This dashboard is fully supported by the Solution Accelerators team at Microsoft.
For more information, see http://go.microsoft.com/fwlink/?LinkId=183417.

Additional Reading
 “An Overview of Windows Clustering Technologies: Server Clusters and Network Load Balancing”:
http://technet2.microsoft.com/windowsserver/en/library/c35dd48b-4fbc-4eee-8e5c-
2a9a35cf63b21033.mspx?mfr=true
 Planning Server Deployments: http://technet2.microsoft.com/windowsserver/en/library/cd6dd855-c25a-
42e9-a0b1-861989aeac741033.mspx?mfr=true
 “Configuring Network Load Balancing”: http://support.microsoft.com/kb/240997
 Infrastructure Planning and Design: Windows Server 2008 Active Directory Domain Services:
http://go.microsoft.com/fwlink/?LinkId=157704
 Infrastructure Planning and Design: Microsoft SQL Server 2008: http://go.microsoft.com/fwlink/?
LinkId=163302
 Planning and Deployment Guide for the Application Virtualization System: http://technet.microsoft.com/en-
us/library/cc843778.aspx
 App-V 4.5 Server Sizing Guide: http://download.microsoft.com/download/1/6/1/161042F3-9CDE-45F7-
BC20-4FBDA8888890/AppV45_ServerSizingGuide_Final.docx

Conclusion
This guide has summarized the critical design decisions, activities, and tasks required to enable a successful
design of a Microsoft Application Virtualization infrastructure. It focused on decisions involving:
 Which models will be used in the organization to deliver virtualized applications.
 How many instances of each model will be required to cover the locations and applications defined in the
scope.
 The placement, scaling considerations, and fault-tolerance options of each server role.
This was done by leading the reader through the six steps in the decision flow to arrive at a successful design.
Where appropriate, the decisions and tasks have been illustrated with typical usage scenarios.
This guide discussed the technical aspects, service characteristics, and business requirements needed to
complete a comprehensive review of the decision-making process.
When used in conjunction with product documentation, this guide will allow organizations to confidently plan the
implementation of Microsoft Application Virtualization technologies.
Additional Reading
 Microsoft Application Virtualization Team Blog: http://blogs.technet.com/softgrid/
 Microsoft Application Virtualization 4.5 documentation page: http://technet.microsoft.com/en-
us/appvirtualization/cc843994.aspx

Appendix: Job Aids

Use the table below to record the applications to be virtualized.
Table A-1. Application Categorization
Application name Supported? Licensing changes?
Use the table below to record information about each location in scope.
Table A-2. Location Categorization
Location Number Available Model Streaming instance Streaming instance
of users bandwidth name fault-tolerance
(if required) selection
(if required)
Detroit 250 T1 Full SVR-DET-A NLB
Flint 30 768 Streaming SVR-FLT-A None
If Full Infrastructure Model has been selected, use the table below to record the fault-tolerance selection for
each server role.
Table A-3. Full Infrastructure Fault Tolerance
Server role Server name Fault-tolerance selection
Management SVR-DET-A NLB
Management Web Service Not possible

SQL Server

Version History
Version Description Date
2.0 Updated to reflect the availability of Application Virtualization 4.6, February 2010
with these areas impacted:
 Provides support for Windows 7 and Windows Server 2008
R2
 BranchCache for file or IIS servers
 64-bit client support
 Remote Desktop Services terminology changed from
Terminal Services
 Server sizing data
1.0 Original release. September 2008

Acknowledgments
The Solution Accelerators–Management and Infrastructure (SA-MI) team acknowledges and thanks the people
who produced the Infrastructure Planning and Design guide: Microsoft Application Virtualization 4.6. The
following people were either directly responsible for or made a substantial contribution to the writing,
development, and testing of this guide.
Contributors:
 Jude Chosnyk – GrandMasters
 Joe Coulombe – Microsoft
 Charles Denny – Microsoft
 Michael Kaczmarek – Microsoft
 Robin Maher – Microsoft
 Daniel Nerenberg – Studio B
 Fergus Stewart – Microsoft
 Melissa Stowe – Microsoft
Reviewers:
 Karri Alexion-Tiernan – Microsoft
 Matt Babey – Microsoft
 Carlos Brito – Microsoft
 Steve Chadly – Microsoft
 Matthijs Gates – Microsoft
 Emre Kanlikilicer – Microsoft
 Brian Kelly – Microsoft
 Jim Kerr – Microsoft
 Chris Maher – Microsoft
Editors:
 Laurie Dunham – Microsoft
 Pat Rytkonen – Volt Technical Services

IPD - Microsoft Application Virtualization 4 6

Uploaded by

Document Informationclick to expand document information

Copyright:

Available Formats

IPD - Microsoft Application Virtualization 4 6

Uploaded by

Document Information

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

IPD - Microsoft Application Virtualization 4 6

Uploaded by

Copyright:

Available Formats

Infrastructure Planning

Microsoft Application Virtualization 4.6

Published: September 2008

Solution Accelerators microsoft.com/technet/SolutionAccelerators

Solution Accelerators microsoft.com/technet/SolutionAccelerators

Benefits of Using This Guide

Solution Accelerators microsoft.com/technet/SolutionAccelerators

What’s New in Microsoft Application

Solution Accelerators microsoft.com/technet/SolutionAccelerators

Solution Accelerators microsoft.com/technet/SolutionAccelerators

IPD in Microsoft Operations Framework

Figure 1. The architecture of Microsoft Operations Framework (MOF) 4.0

Solution Accelerators microsoft.com/technet/SolutionAccelerators

Application Virtualization in Microsoft

Solution Accelerators microsoft.com/technet/SolutionAccelerators

Application Virtualization Design

Figure 3. Microsoft Application Virtualization architecture

Solution Accelerators microsoft.com/technet/SolutionAccelerators

Figure 4. The Microsoft Application Virtualization infrastructure decision flow

Solution Accelerators microsoft.com/technet/SolutionAccelerators

Solution Accelerators microsoft.com/technet/SolutionAccelerators

Step 1: Determine the Project Scope

Task 1: Determine Application Scope

Task 2: Determine Location Scope

Validating with the Business

Solution Accelerators microsoft.com/technet/SolutionAccelerators

Step 2: Determine Which Model(s) Will

Solution Accelerators microsoft.com/technet/SolutionAccelerators

Figure 5. An example of App-V Standalone Model

When to Use Standalone Model

Solution Accelerators microsoft.com/technet/SolutionAccelerators

Figure 6. An example of App-V Streaming Model

When to Use Streaming Model

Full Infrastructure Model

Solution Accelerators microsoft.com/technet/SolutionAccelerators

Figure 7. Example of an App-V Full Infrastructure Model instance

When to Use Full Infrastructure Model

Solution Accelerators microsoft.com/technet/SolutionAccelerators

Validating with the Business

Solution Accelerators microsoft.com/technet/SolutionAccelerators

Step 3: Determine How Many Instances

Task 1: Determine the Number of Streaming

Task 2: Determine the Number of Full

Step 4: Client and Sequencer

Task 1: Client Considerations

RD Session Host Servers

RD Session Host Server Standalone Model

RD Session Host Server in a Streaming or Full Infrastructure Model

Solution Accelerators microsoft.com/technet/SolutionAccelerators

Task 2: Sequencer Considerations

Solution Accelerators microsoft.com/technet/SolutionAccelerators

Placing the Sequencer

Solution Accelerators microsoft.com/technet/SolutionAccelerators

Solution Accelerators microsoft.com/technet/SolutionAccelerators

Step 5: Design the Streaming

Task 1: Determine the Streaming Server

Solution Accelerators microsoft.com/technet/SolutionAccelerators

Table 1. Package Streaming Methods

File server SMB  Simple, low-cost solution to No active upgrade1