Virtualizing Desktops and Apps with Windows Server 2012 R2 Inside Out: Planning and Implementing App-V

Planning App-V infrastructure

When introducing a new technology, such as App-V. planning and designing the infrastructure are fundamental to a successful implementation. As we’ll discuss in this section, a reliable App-V environment depends heavily on the design and infrastructure. The process for implementing application virtualization is flexible and scalable, with larger deployments requiring more planning and different technologies.

Some key areas of interest when planning your App-V infrastructure include the following:

• The App-V infrastructure requirements
• The various App-V deployment models
• Sizing and performance
• High availability and disaster recovery

App-V infrastructure requirements

Before deploying App-V in your environment, you must ensure that the supporting infrastructure is in place and configured. App-V 5.0 has the following infrastructure requirements:

• Active Directory Domain Services AD DS is required for authentication and authorization of applications and connection groups. AD DS is needed only if you plan to deploy an App-V server, such as in a full infrastructure deployment model.
• Installation service account A service account in AD DS is required for the initial installation of the App-V server, presuming that your deployment is a full infrastructure model. This account needs Read permission to query AD DS and local Administrators group access on the server on which you perform the App-V installation. Following the installation of the management server, you can transition this to a security group in AD DS, allowing you to easily add users who require administrative access to the management console.
• Package repository This is the location where package files will be stored for delivery to App-V clients.

The servers in an App-V environment have the following requirements::

• Management server Supported on Windows Server 2008 R2 with SP. and newer. It requires the following technologies:

  • Microsoft .NET Framework 4.0 or newer
  • Windows PowerShell 3.0
  • Microsoft Visual C++ 2010 SP1 Redistributable Package (x86/x64)
  • Microsoft SQL Server 2008 Standard, Datacenter, or Developer edition (32-bit or 64-bit. or newer

• Reporting server Supported on Windows Server 2008 and newer. It requires the following:

  • Microsoft .NET Framework 4.0 or newer
  • Microsoft Visual C++ 2010 SP1 Redistributable Package (x86/x64)
  • Windows Web Server with the IIS role installed
  • Common HTTP Features (static content and default document)
  • Application Development (ASP.NET, .NET Extensibility, ISAPI Extensions, and ISAPI Filters)
  • Security (Windows Authentication, Request Filtering)
  • Management Tools (IIS Management Console)
  • 64-bit ASP.NET
  • Microsoft SQL Server 2008 Standard, Datacenter, or Developer edition (32-bit or 64-bit. or newer

• Publishing server Supported on Windows Server 2008 and newer. It requires the following:

  • Microsoft .NET Framework 4.0 or newer
  • Microsoft Visual C++ 2010 SP1 Redistributable Package (x86/x64)
  • Windows Web Server with the IIS role installed
  • Common HTTP Features (static content and default document)
  • Application Development (ASP.NET, .NET Extensibility, ISAPI Extensions, and ISAPI Filters)
  • Security (Windows Authentication, Request Filtering)
  • Management Tools (IIS Management Console)
  • 64-bit ASP.NET

Although the design of an App-V environment is very flexible, certain scenarios are not supported:

• Installation on domain controllers isn’t supported for any App-V server technology.
• Installation isn’t supported on Server Core installations of Windows Server.
• App-V 5.0 can’t be installed on a system that has a previous version of the App-V Management Server.
• Microsoft SQL Server Express as a database engine isn’t supported.

App-V deployment possibilities

Distributing virtual applications requires the App-V client software on the target computer. As you design your server infrastructure, you’ll need to review the four main deployment models that we introduced earlier in this chapter. Each model has its own strengths, and the model you choose will determine which type of server infrastructure you deploy.

App-V full infrastructure model

The full infrastructure model provides all of the management server capabilities that App-V offers, including application streaming, authentication, security, licensing, and metering.

When planning for the full infrastructure model, you’ll need AD DS and Microsoft SQL Server. The App-V Management Server should be on the same LAN segment hosting the database. Publishing servers are used in this model to publish content from a file server share to a distributed environment’s remote locations by providing streaming capabilities close to the clients that are using the applications. This reduces latency and improves the end-user experience.

System Center 2012 Configuration Manager–integrated model

If you have an existing System Center 2012 Configuration Manager infrastructure, or you are looking to implement one, you can leverage Configuration Manager to distribute virtual applications in the same way that you distribute traditional application packages. You can add virtual applications to a Configuration Manager environment by using the same Create Application Wizard, as shown in Figure 4-21.

Many of the advanced capabilities that are available for managing a traditional application—such as using task sequences and building queries in collections to define which devices are targeted—also are available for a virtual application. You can target both users and computers to deliver an application in a more intelligent way, expanding on capabilities of the App-V full infrastructure model. For example, when you use a primary device as one of the possible rule requirements, you can identify which deployment type is used based on whether the user is working on his or her primary device.

The Configuration Manager–integrated model requires both the App-V client and the Configuration Manager client on each managed system. It doesn’t use any server technologies of the full App-V infrastructure to deliver virtual applications. instead, it uses existing Configuration Manager distribution points to deliver the virtual application to client devices. Note that some reporting capabilities aren’t available in the integrated model when compared to the full infrastructure model. For example. if you use local delivery where clients download and execute the application. you only can report if the application has been used and the last application usage time. In the full infrastructure model with reporting, you can report the number of times an application has been used.

Application delivery to a Configuration Manager client works differently from the App-V full infrastructure scenario. In the full infrastructure model, the App-V client manages its own content, and it can refresh instantly against the publishing server. In the Configuration Manager–integrated scenario, the Configuration Manager client manages the App-V client.

Configuration Manager supports two types of delivery methods for virtual applications:

• Streaming delivery You can enable streaming delivery on Configuration Manager distribution points. This option streams a virtual application to a client through HTTP or HTTPS.
• Local delivery This delivery first uses the Configuration Manager client to download all the files needed for the application through Background Intelligent Transfer Service (BITS). After downloading the files, the package fully loads into the App-V client cache.

Electronic software distribution model

The electronic software distribution (ESD) model is ideal for environments in which you prefer to leverage an existing software distribution solution. In this case, most distribution systems can use the virtual .msi file produced by the App-V Sequencer for delivery with an .appv package.

Planning considerations for the ESD model include the following:

• Existing software distribution system An existing software distribution system that can recognize and distribute .msi packages to client devices.
• App-V Sequencer A system deployed in your environment with the App-V Sequencer installed for building and managing virtual applications.
• Windows PowerShell The ability to deploy a script that contains the App-V client module for Windows PowerShell cmdlets. This provides the ability to add and publish packages in ESD mode.
• Connection groups Designating connection groups (grouping one or more App-V packages to enable interaction with one another) requires manually creating a connection group XML file and deploying it by using a custom Windows PowerShell script.

• Group Policy Having Group Policy available simplifies the task of configuring the App-V client. Alternatively, a manual or scripted configuration is possible through the Windows Registry. In Figure 4-22, a GPO named App-V settings provides several App-V settings to computers.

  

  Figure 4-22 App-V GPO settings

Stand-alone deployment model

The App-V stand-alone model consists of the App-V Sequencer and an App-V client, and it requires no additional App-V infrastructure. The Sequencer has an option to create a virtual .msi file during the sequencing process. The virtual .msi file invokes Windows PowerShell commands and then publishes and loads the application to the App-V client cache.

The App-V Sequencer packages publication information. shortcuts, and the installation routines into an .appv file package, and the Sequencer generates virtual .msi files that you can execute manually. When executed, the installer adds the virtual application package to the App-V client and configures publication information to load applications from a local location rather than stream them across a WAN.

Stand-alone deployments require an App-V client on the computers, which allows a virtual .msi file to publish and load virtual applications or enables management through Windows PowerShell. You don’t configure an App-V client to connect to any App-V server.

The stand-alone delivery scenario enables an organization to deploy virtual applications in situations where no servers are available to support other deployment methods for virtual applications. Use stand-alone deployments in the following scenarios:

• There are remote users who can’t connect to an App-V infrastructure.
• Software management systems, such as Configuration Manager or another electronic software distribution system, already are in place.
• Network bandwidth limitations prevent electronic software distribution. In this case. you can use virtual application delivery on physical media.

Because the stand-alone model employs an .msi file, you can distribute the file if you use an existing software distribution infrastructure, such as GPOs, shared folders, optical media such as CDs and DVDs, USB flash drives, or others.

Service disruption impact

One of the common design steps in implementing App-V is to make the infrastructure highly scalable, which limits the impact of service disruption. The App-V infrastructure is highly dependent on AD DS. Therefore, it is recommended that you carefully plan your AD DS architecture to avoid unwanted service disruptions.

It’s important to point out that from a client perspective. once an application is loaded on a computer, that device can run the application independently from the server. A previously published package can have different states on client computers:

• Not Available In this state, the package isn’t registered or isn’t available on the client.
• Registered In this state, the package is registered to the computer, but it still is not registered for the user.
• Published In this state, the application is registered and published on the client, and the user can start using it.
• Partially Loaded In this state, the application can be started because the client already has downloaded the initial feature block. Depending on which portion is missing. the rest of the files can download over the network, so the file server repository is the critical technology that provides that functionality.
• Fully Loaded In this state, the application downloads and extracts entirely onto a client machine, and it can be used in an offline scenario.

The following areas will be a concern if the virtual applications aren’t configured to fully load on the client machine or aren’t already published on the publishing server:

• File server repository The most critical technology that influences an application’s functionality will be the file server repository. Storage availability and AD DS will need extra planning considerations in this scenario.
• Management server If the management server or the management database is down, adding new packages, updating existing packages, or managing connection groups won’t be possible.
• Publishing server Publishing server failure affects the ability to make changes to the publishing list that clients previously received, which is for non-persistent Virtual Desktop Infrastructure (VDI) and RDS scenarios.
• Reporting server Reporting server or reporting database failure isn’t critical to running App-V applications; the only functionality that might not work is reports that a client sends about usage statistics for virtual applications, which are stored in the reporting database.

Functional and physical placement

Organizations might plan different App-V infrastructure deployments based on their needs. When you start to plan for your App-V environment, you should try to answer the following questions to help with your design and implementation:

• Are there requirements that all roles must live on a single server? Decide whether you want to combine or cohost functionality.
• Do you need centralized or decentralized roles in a distributed environment?
• What are the requirements for high availability?
• Are the virtualized application users located in all of your office locations?
• Is your virtualization environment able to virtualize your entire App-V deployment?

Based on the answers to these questions, there are several design scenarios:

• Small and midsize deployments For small and midsize scenarios, which commonly address an environment with a small number of users and few packages in a single geographical site, you might cohost all of the roles on a single server.
• Midsize and large deployments For midsize and large deployments. which commonly require a flexible and scalable environment, you might consider a more complex design in which all services implement individually. In this scenario, every connection addresses a virtual IP address and machine name, and no services cohost on any given computer.
• Distributed deployments For distributed deployments, which commonly need to support a large number of users in different locations with many different requirements, you should implement a scenario that can address locations with no datacenter and weak Internet connectivity. For this type of design, all configuration data that is stored in a management database should be located in a major datacenter. Because the management server communicates with the management database, it should be located close to the SQL server because SQL communication is time-sensitive and network-sensitive. The file server repository share that holds the application should be located close to clients, and interval refreshes can be adjusted according to the actual network capabilities.

• High availability deployments In this scenario, you must have two identical machines (physical or virtual) that are configured in NLB mode (or behind a third-party hardware load balancer), where the following services are installed:

  • App-V management
  • App-V publishing
  • App-V reporting

Even if you don’t start with a highly available environment. you should consider using load balancing. It can simplify scaling out later and provide some additional capabilities such as drainstopping a server.

It is recommend that you host the SQL Server database separately from the App-V services. This consideration is made for performance. security, and scalability. For highly available designs, you should consider implementing a SQL Server cluster.

Sizing and performance

Actual sizing and performance planning depends on multiple factors, such as scaling an App-V infrastructure properly to lower the round-trip response time and providing proper package optimization for streaming across slow networks.

Round-trip response time on a publishing server is the time that is needed for the publishing server to receive a successful package metadata update from the management server. Round-trip response time on a client is the time the App-V client computer takes to receive a successful notification from the publishing server.

If you have increased internal demand, you can implement an additional management server behind your load balancers.

Often, users might demand external scalability based on the location you must support. A design should include a content repository in each location to provide conveniently located packages to clients. Additionally, you might consider implementing a publishing server and a management server to lower the round-trip response time on clients. Capacity planning should be included to evaluate future demands in planned growth to meet expected performance levels.

A few factors influence round-trip response time on a publishing server. Some of these include the number of:

• Publishing servers that make simultaneous requests.
• Connection groups that are configured on a management server.
• Access groups that are configured on a management server.
• A single management server can simultaneously respond to up to 320 publishing servers with a round-trip response time of approximately 40 seconds; a single management server with fewer than 50 publishing servers results in a round-trip response time of less than 5 seconds.
• The number of connection groups starts to influence round-trip response time after more than 400 are created.
• The number of access groups increases the round-trip response time as it grows.

The number of publishing servers that simultaneously connect to a management server does not influence central processing unit (CPU. utilization and SQL database transactions per second; batches per second are identical, regardless of the number of publishing servers.

For App-V, reporting server capacity planning should focus on the number of clients that simultaneously send reporting information to a reporting server. Round-trip response time increases linearly with an increased number of clients. For example, round-trip response time is 2.6 seconds with 500 clients and 5.2 seconds with 1,000 clients.

Capacity planning for the publishing server influences the round-trip response time on an App-V 5.0 client computer to send a publishing refresh request and to receive a response.

The following are the main factors that influence capacity planning of an App-V publishing server:

• The number of clients that simultaneously connect to a single publishing server.
• The number of packages in each refresh The network bandwidth between clients and the publishing server.
• A publishing server with a dual-core processor can respond to up to 5,000 clients that simultaneously request refreshes. From 5,000 through 10,000 clients, a publishing server should have a quad-core processor at minimum. Increasing the number of packages increases response time by 40 percent, and network bandwidth has a major influence on response time. For example, clients that run on slow networks—less than 1.5 megabits per second—will have a significantly slower response time than the same number of clients that run on LAN networks.

High availability for App-V

You should plan for a highly available App-V infrastructure in organizations where App-V is important. The high availability strategy for the App-V infrastructure depends on the App-V deployment model. because different procedures and settings for high availability are needed for different App-V deployment models.

Stand-alone deployment model

The stand-alone deployment model only requires an App-V Sequencer and client computers that have an installed App-V client. In the stand-alone deployment model, the App-V Sequencer is used only when a new application needs to be sequenced. Because the App-V Sequencer installs only when a new application needs to be sequenced, it isn’t necessary to make the Sequencer highly available. If you stream from a central share, this share can deploy on a clustered file system or on an NLB web farm. In cases where you require access to sequencing, even in a disaster recovery (DR) scenario, you can deploy multiple sequencing computers.

App-V full infrastructure model

From a planning perspective, the App-V full infrastructure model requires the most attention. Because there are a multitude of technologies with differing high availability models, you should spend time looking at the options available and decide which one makes the most sense for your environment. The following are some questions that you should answer to help you plan for high availability:

• Does the reporting service need to be highly available?
• Does the sequencing computer need to be highly available?
• Are there infrastructure technologies outside App-V that may impact the high availability of App-V, such as load balancers, switches, virtualization servers, or storage?
• Which secondary site should each office use in the case of a publishing server failure at the office?

The answers to the above questions will help you plan the services, the number of servers required, and the high-level design of your highly available environment.

The App-V full infrastructure model stores all configuration and application information in the management server database and stores all utilization data in the reporting server database, so each of these databases is a single point of failure in this model. Therefore, when you are configuring the App-V full infrastructure model to be highly available, you need to ensure that the management server database and the reporting server database remain accessible. You can do this by deploying these two databases on an instance that is installed on a highly available VM or on a clustered SQL Server instance.

App-V 5.0 supports multiple management, reporting, and publishing servers. You can configure the App-V 5.0 management and reporting server databases to work with multiple management servers and reporting servers by using a security group when specifying the computer account location during setup. At any time, you can add publishing servers to an existing App-V full infrastructure model deployment.

Consider Figure 4-23, which shows what can happen when the application team provides high availability for its services but another team isn’t engaged in the project and is unaware of potential impacts.

In the diagram above, although all of the App-V technologies are highly available, there is only one load balancer. It represents a single point of failure. Instead of this scenario, the availability of all services on which App-V is dependent should match the App-V availability.

Integrated Configuration Manager model

For the integrated Configuration Manager model to be made highly available, you should look at all of the options to meet your high availability requirements and figure out if any infrastructure changes are required:

• Are highly available VMs available in your environment? If so, you can use one or more for your Configuration Manager servers.
• Is your existing SQL environment highly available?
• Is the storage that the virtual environment uses highly available?
• Do you have distribution points in all of the locations to which you plan to deliver virtual applications? If so, you need to plan for scenarios in which a distribution point becomes unavailable. In environments with an existing Configuration Manager deployment, it isn’t unusual to have sites with a single distribution point. You should consider multiple distribution points if your requirements include immediate access to virtual applications, especially for new App-V clients.
• You also may want to look at the overall high availability of the Configuration Manager environment. Is there an existing hierarchy with a central administration site?

Similar to other App-V deployment models, you should look at all aspects of your environment and ensure that all of the services involved are configured for high availability.

• For more information about high availability in Configuration Manager, see the “ Planning for High Availability with Configuration Manager” website at http://technet.microsoft.com/en-us/library/hh846246.aspx.

Disaster recovery

A disaster recovery plan should include a proper backup of critical technologies to respond to a service outage. In addition. regular testing of restore operations will help ensure that the backups are functional and that the operational procedures are adequate to recover from a disaster. At a minimum, an App-V infrastructure backup should protect the management database and the package repository that contains the App-V packages. Outside App-V, you should ensure that the services on which App-V depends also are backed up and restored first after a disaster. For example. you need to ensure that AD DS, SQL, Server virtualization, and the core networking services are up and running before you can successfully recover App-V.

In an App-V backup and recovery scenario, each role has different requirements:

• A management server does not hold any unique data other than the registry configuration of the database source, so you can easily re-create this role in case of a disaster.
• A publishing server contains a registry value that indicates the host name of the management server to contact and a cached copy of the latest publishing data, which you need to back up.
• The reporting server has a registry value that indicates the name of the reporting database.

There are two different scenarios for recovery procedures:

• If a server that contains all of the roles fails, administrators should perform standard image recovery procedures that are defined by organizational policy. This often means restoring the VM or physical server to the most recent backup.
• If an App-V service fails, administrators should perform a recovery by installing the App-V technologies and prerequisites, such as installing and configuring Internet Information Services (IIS) and installing SQL Server on the database server.

When you restore the management server, it enables this service to become operational as soon as the service can contact the App-V database. When you complete the restoration of publishing servers, client requests will be serviced as soon as the service contacts the publishing servers (from 1 to 10 minutes). After the App-V services are restored, the reporting server starts accepting client connections.