Augusto Alvarez

Reviewing App-V and SCCM 2012 Integration – Part I

My second App-V book was finally published, “Microsoft Application Virtualization Advanced Guide” and as for my previous book, there’s one sample chapter available for download.

The chapter selected in this case is “Integrating App-V with System Center Configuration Manager 2012”, from where we review all that needs to be known about SCCM integration with virtual applications.

In these two posts I’m going to take a tour around that content as a quick overview and also some step-by-step guidance to accomplish this integration.

Understanding SCCM and App-V Integration

Integrating System Center Configuration Manager with App-V is a far much simpler with the new versions of these two platforms. Let’s review some of the benefits, considerations, delivery methods and components required.

Benefits of Integrating SCCM and App-V

There are several benefits we can review about using SCCM and App-V as an integrated platform instead of separate technologies. Let’s review some of the most important ones:

• Optimizing our Infrastructure: If we have already implemented SCCM in our environment, not integrating with App-V could translate into larger costs of management, troubleshooting, complexity and hardware; since you will need to implement Streaming Server functionality separately from Distribution Points. This role in Configuration Manager can fulfill the streaming process without acquiring big changes in our implementation.
• Improving client targeting: System Center Configuration Manager brings the possibility to deploy normal and virtual applications with an enhanced level of targeting, depending on collections and capabilities of the systems involved.
• Complementing App-V with SCCM assessments: App-V includes user targeting for their packages; integrating with Configuration Manager we can combine these possibilities with software metering, asset intelligence and wake-on-lan features for the virtual applications deployment.
• Virtual Applications delivery as a complement in Operating System Deployment: One of the most important features in SCCM is Operating System Deployment (OSD), which can be combined and scaled up with other features like Software Updates, software and hardware inventory, targeting for implementing operating system’s drivers, etc. Using App-V we can deliver applications as soon as the operating system is deployed, saving considerable time to deliver a ready-to-go operating system.
• Background delivery of App-V applications: In unstable or slow networks BITS protocol can be leveraged allowing application delivery as network connections permit. The SCCM client performs the download of the App-V application into the SCCM cache where it is then imported into the App-V cache. This offers much more flexible application delivery but comes with a storage penalty on the client. The application will exist in both the SCCM and App-V client cache and cannot be purged from the SCCM client cache. This means in this delivery model that there is at least a doubling of the storage required on the client for this delivery model.

Some Considerations about the Integration

SCCM does not provide the exact functionalities we can find in the native App-V components implemented. The idea of SCCM integration is to complement with the App-V platform. But, because of the Configuration Manager architecture, there are some considerations we should review.

Most of the integration features remain undocumented by Microsoft at the moment; but analyzing the infrastructure using the Beta and Release Candidate version of SCCM 2012 appears to maintain basic architecture definitions than from the previous version – SCCM 2007 R2/R3. Here are some of the considerations we can find so far:

• We must re-advertise an application when there’s an active upgrade: “Active Upgrade” is the process that we run in an App-V package to update the application using a service pack or any other of modification; the App­-V Full Infrastructure Model automatically delivers the new version to clients. SCCM does not handle updates in the same package as a delta that must be delivered to clients, so we will need to make a new advertisement every time there’s a virtual application update.
• Reduced reporting: App-V Full Infrastructure provides a very important set of reports we can execute and retrieve about our virtual application; Configuration Manager does not provide the same level of reporting. Using the “Local Delivery” as the preferred method for delivering applications it is not possible to report on how many times an application has been used.
• Targeting applications for Remote Desktop Services requires that users must logoff and logon in their sessions: This is not a limitation only for virtual applications, applies for all Configuration Manager Clients’ user targeted and /or user interaction with the SCCM client. The SCCM client only allows software distribution to the console session of a terminal server system (mstsc.exe /console). Therefore, if an application delivery is targeted to users that are using a remote session on the terminal services system; they will not be able to execute the advertisement.
• Asset Intelligence (in charge of reporting and inventory features) requires Feature Block 1 present in the virtual application streamed to clients: Asset Intelligence cannot inventory virtual applications applications that co-exist with the same version of an application installed locally. As we mentioned, virtual applications live within their own environment; making it possible for the same application working as installed locally and virtually deployed. If that’s the scenario, Asset Intelligence won’t inventory the App-V package.
• In order to use Dynamic Suite Composition (DSC) in virtual applications both interconnected packages must be advertised and registered with the App-V Client. That’s why using the delivery method Local Delivery (Download and Execute), later to be discussed, is the recommended option when we are using DSC.
  We can also use “Dependencies” in SCCM to guarantee that both packages can be delivered normally.

Components Involved

In this integration, we must understand which components are interacting in these two platforms:

• App-V Sequencer: The process of capturing it is the same and we don’t need to introduce any changes in that phase.
• SCCM Site Server: In charge of managing and handling the actions performed by the SCCM Distribution Points.
• SCCM Distribution Point: Storing and distributing the App-V applications.
• SCCM Client: Client agent agent that communicates with System Center Configuration Manager and receives the virtual applications.
• App-V Client: SCCM Client and App-V Client work together: The SCCM Client delivers the virtual application to the App-V Client Client, which has the responsibility of executing it.

Understanding Delivery Methods

Using SCCM to deploy virtual applications includes two types of delivery methods we can use to fit any specific scenario. These two delivery methods are the same that appeared in the App-V + SCCM 2007 integration.

The delivery methods remains the same, but SCCM 2012 adds some twists in the configurations that we can achieve, using some options that we are going to review later like “Persist content in the client cache” and “Enable peer-to-peer content distribution”.

Applying the different delivery methods will basically depend on the type of connectivity the client machine has with the SCCM distribution point; converting this integration into a highly scalable one since we can discriminate the type of user with a specific type of streaming delivery.

Let’s go through each type: Streaming delivery and Local delivery (Download and Execute).

Streaming Delivery

When using this delivery method, the App-V Client will be configured to receive applications using HTTP/HTTPS (Standard Distribution Point) or SMB (Branch Distribution Point) streaming.

This is how the delivery works in the streaming mode:

In this process we can evaluate the entire workflow in the Streaming Delivery from the moment the application is sequenced. These set of steps should be familiar to us if we already know and understand how a Streaming Server works with virtual applications, but note the following:

1. The App-V Client does not stream an application until one of the shortcuts of this application is double-clicked.
2. Once the streaming process started, the same behavior occurs at first: The Feature Block 1 is delivered from the SCCM Distribution Point to the App-V Client cache.
3. Once the application is running, the rest of the package is streamed down by the App-V Client.

The streaming delivery method must be considered when the clients and servers live in the same LAN; remember that the streaming process requires high-bandwidth connections. Another good example of using this method is when we have applications which are constantly updated, the updates occurs in the Distribution Point which delivers the new package to clients.

Avoid using this method when we have several offline users.

Local Delivery (Download and Execute)

The Local Delivery (download and execute) method explains itself; the initial task executed by the client is downloading the application, the complete package, and then executes it.

In this downloading process, the application is delivered to the SCCM client cache and then the SFT file is streamed from the SCCM clients’ cache into App-V clients’ cache. Basically the SCCM Client works as a local streaming server for the App-V Client.

This is how the delivery works in this mode:

In this process workflow we can see clearly how the SCCM Client is in charge of downloading the entire content of the package as soon as it’s advertised. But only when the user clicks on any of the shortcuts from the application, the App-V Client streams the application to the cache from the SCCM Client cache; and then it completes the launch process.

The application stays in App-V cache, ready to be launched, as long as the advertisements in Configuration Manager maintains.

The Local Delivery is the best approach when we are using slow networks between servers and clients, and of course for offline users; who can work normally with the application even when they are not connected to the network.

The Local Delivery also needs considerable amount of storage: Three times the size of the applications package: One for the SCCM Client; another for the App-V Client; and the third one is stored for calculating differentials when the application receives an update.

App-V Client and the “OverrideURL” Setting

As we reviewed, in both delivery methods the SCCM client streams down to the App-V client cache the applications published; to accomplish this, the App-V Client includes a new registry value “OverrideURL”.

This value can be changed to use an alternate server in charge of delivering the virtual applications. All this process is transparent for the user, the value is changed by the SCCM client and the streaming process is redirected to the Configuration Manager Distribution Point in charge of the delivery.

This is a simple diagram where we can see the interaction between the SCCM Client and the App-V Client.

Even though this concept appeared in the integration of App-V and SCCM 2007 R2, the basic functionality remains in this new version SCCM. Reviewing the deployment of App-V applications using SCCM we can confirm that the OverrideURL behavior is maintained, there’s an example of the Winamp virtual application (deployment reviewed later in this chapter) and the registry settings in the App-V Client.

The “OriginalURL” setting displays the configuration used in the OSD, and the “OverrideURL” use the SFT location in the SCCM Client cache.

Requirements for the SCCM + App-V Integration

In order to accomplish this smooth integration and without adding significant load into our operations, we must understand each of the requirements involved.

The requirements do not differ much from what we’ve seen earlier in SCCM 2007 R2, which is an important advantage if we already have this platform implemented and we are considering migrating to SCCM 2012.

The two important requirements we are going to analyze are: Platform requirements in SCCM 2012 and storage requirements for sizing the SCCM client cache.

SCCM 2012 Platform Requirements

Even though it could sound pretty obvious at this point, remember always that having a healthy environment in SCCM represents an important note before starting with changes in the environment.

Regarding System Center Configuration Manager 2012 components, the basic platform is needed:

· Primary Site.
· Site Server: A Site Server with the following roles installed:

• Site System.
• Site Server.
• Component Server.
• Distribution Point.
• Fallback Status Point.
• Management Point.
• Reporting Point.

· Distribution Points: At least one available and working with IIS and streaming enabled for BITS application delivery. This server will be in charge, of course, of the packages distribution.
· Clients: SCCM clients installed and working properly. We’ll review later in this chapter how to push clients’ agents in SCCM 2012.

For more information about Site System Servers and Site System Roles review the following link in Microsoft TechNet: “Fundamentals of Configuration Manager” http://technet.microsoft.com/en-us/library/gg682106.aspx.

Storage Requirements

These considerations depend primarily on the type of the delivery method chosen in the environment. As for the App-V environment, we must size the storage considering clients, App-V cache; and server, Distribution Points in SCCM. Here’s a general guideline about the storage requirements:

• SCCM Clients cache must be configured considering the full size of the App-V packages to be distributed.
• App-V Clients cache is recommended to size it considering the SCCM clients cache defined. The App-V client cache should be configured with free disk space threshold option, adding 1GB more to the SCCM client cache value.
  Using an SCCM Clients cache with 4GB, the App-V Client cache should be configured with a free disk space threshold of 9GB.
• SCCM Distribution Points should allocate space considering the size of the package multiplied by 3 . The triple sizing consideration, as said depends on the delivery method, current version of the package, upgrade version, App-V clients cache version, or differential files while constructing an upgraded version of the package.

In the next post we will continue evaluating the App-V and SCCM 2012 integration with the step-by-step processes to complete the integration.

Remember that the entire chapter “Integrating App-V with System Center Configuration Manager 2012” can be downloaded from this link.