App-v High Availability Design

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 Models 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 Windows Installer-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), 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 Microsoft System Center Configuration Manager 2007 or Microsoft Systems Management Server (SMS) 2003.

Figure 3. 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 Configuration Manager 2007 and Systems Management Server 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 a Windows Installer 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, Configuration Manager 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. Configuration Manager 2007 can be used to publish and deploy streaming applications and keep the content on the streaming servers synchronized.

Figure 4. 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 Configuration Manager 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 5. 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.

Validating with the Business

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, demilitarized zone, and screened subnet).

Record the streaming model instance defined for each location in Table A-2 in Appendix A.

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 Appendix A 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 Appendix A. 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: Assess 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 a Windows Installer file. 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 operating system 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 dynamic-link libraries (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 operating system 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/cc843848.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

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 servers 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 website. 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 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 Configuration Manager 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. Configuration Manager 2007 can be used to publish and deploy streaming applications and keep the content on the streaming servers synchronized. Configuration Manager 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 Table 1.

Table 1. Package Streaming Methods

Server type	Protocol	Advantages	Disadvantages
File server	SMB	Simple, low-cost solution to configure existing file server with \CONTENT share Supports enhanced security using IPsec Familiar protocol	No active upgrade¹
IIS server	HTTP/HTTPS	Supports enhanced security using HTTPS protocol Only one port in firewall to open Scalable Familiar protocol	No active upgrade¹
Application Virtualization Streaming Server or Management Server	RTSP/RTSPS	Active upgrade Supports enhanced security using RTSPS protocol Only one port in firewall to open	Server administration requirement Can handle fewer simultaneous cached launches than file or IIS servers

NoteConfiguration Manager 2007 SP1 with R2 uses IIS on standard distribution points and file server SMB streaming on branch distribution points.

¹ NoteAn 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 the App-V 4.5 Server Sizing Guide at 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 and RTSPS 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 servers 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 for Windows Server 2008 and Windows Server 2008 R2 File Services; and for IIS, see the Infrastructure Planning and Design Guide for Internet Information Services 7.0 and Internet Information Services 7.5.

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. Distributed File System (DFS) Replication and DRS namespaces can be used to provide fault tolerance and synchronization. See the DFS section in the IPD guide for File Services for more information.

Validating with the Business

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 for Windows Server 2008 and Windows Server 2008 R2 File Services: http://go.microsoft.com/fwlink/?LinkId=160976
Infrastructure Planning and Design Guide for Internet Information Services 7.0 and Internet Information Services 7.5: http://go.microsoft.com/fwlink/?LinkId=157703
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 the App-V 4.5 Server Sizing Guide at 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 megabytes (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 servers designated to hold the Management Server service in Table A-3 in Appendix A.

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, see the Infrastructure Planning and Design Guide for Microsoft SQL Server 2008 and Microsoft SQL Server 2008 R2 at 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 servers and the selected fault-tolerance level in Table A-3 in Appendix A.

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 (NLB) 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 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 servers designated as the Management Server and the selected fault tolerance in Table A-3 in Appendix A.

Evaluating the Characteristics

Tables 2 through 5 compare the complexity, cost, fault tolerance, and security of the two Network Load Balancing options: software-based NLB and hardware load balancer.

Table 2. Complexity Characteristics of NLB and Hardware Load Balancer

Option	Characteristics	Level
NLB	NLB is simple to implement.	Low
Hardware load balancer	Hardware load balancers tend to increase the complexity of the environment due to the need for two and the additional knowledge needed.	Medium

Table 3. Cost Characteristics of NLB and Hardware Load Balancer

Option	Characteristics	Level
NLB	NLB is available in all editions of Windows Server 2003 and later. As a best practice, an additional network adapter is added to all nodes in the cluster to create a private network for the cluster heartbeat.	Low
Hardware load balancer	Two or more hardware load balancers are needed to ensure fault tolerance. If only one hardware load balancer is used, it becomes the single point of failure.	High

Table 4. Fault-Tolerance Characteristics of NLB and Hardware Load Balancer

Option	Characteristics	Level
NLB	NLB only provides fault tolerance at the machine level. If the application layer fails, NLB will not detect it.	→
Hardware load balancer	Hardware load balancers are able to detect application layer failures.	↑

Table 5. Security Characteristics of NLB and Hardware Load Balancer

Option		Characteristics	Level
NLB	NLB does not affect security if properly implemented.			→
Hardware load balancer	Hardware load balancers can increase security of the infrastructure due to 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 Appendix A, verify that incompatible fault-tolerance options have not been selected for server roles that are to be combined.

Table 6. 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

Validating with the Business

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 Microsoft SharePoint^® Foundation 2010-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://technet.microsoft.com/en-us/library/cc739634(WS.10).aspx
Planning Server Deployments: http://technet.microsoft.com/en-us/library/cc783586(WS.10).aspx
Knowledge Base article 240997 "Configuring Network Load Balancing": http://support.microsoft.com/kb/240997
Infrastructure Planning and Design Guide for Windows Server 2008 and Windows Server 2008 R2 Active Directory Domain Services : http://go.microsoft.com/fwlink/?LinkId=157704
Infrastructure Planning and Design Guide for Microsoft SQL Server 2008 and Microsoft SQL Server 2008 R2: 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 Blog: http://blogs.technet.com/softgrid/
Microsoft Application Virtualization 4.5 documentation page: http://technet.microsoft.com/en-us/appvirtualization/cc843994.aspx

Appendix A: 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 of users	Available bandwidth	Model	Streaming instance name (if required)	Streaming instance fault-tolerance 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

Appendix B: IPD in Microsoft Operations Framework 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 B-1. The architecture of Microsoft Operations Framework (MOF) 4.0

Appendix C: 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 C-1. Mapping of Microsoft Application Virtualization 4.6 technology into the Core Infrastructure Optimization Model