Guide to configuring Microsoft App-V to both publish and stream via HTTP

Artykuł
12/02/2010

This post explains how to configure Microsoft Application Virtualization (App-V) to both publish and stream applications using HTTP. For the purpose of this document we will be setting up a brand new Windows 2008 R2 server to offer these functions and utilize a Windows 7 App-V client.

When choosing HTTP as your choice for streaming, we are gaining the performance offered by an optimized protocol like HTTP. On the other hand, when we choose HTTP as our protocol of choice to publish an app, it doesn't rely on the App-V server so there are a couple manual tasks that we have to approach. HTTP publishing is driven by a PUBLISHING.ASPX file that presents the App-V client with a list of applications available. This document (PUBLISHING.ASPX) is the heart of your HTTP publishing system and will need careful attention. On that note, let’s get started.

Setting-up IIS

Enable the following Web Server (IIS) Role Services on the IIS server that will serve for your HTTP Publishing and Streaming Services. Configure it as follows:

Creating the Virtual Directory in IIS:

For the purpose of this post we are going to create a virtual directory in IIS that points to a local folder called content, which is the App-V content folder. Create a folder on C:\ called C:\Content. After creating the virtual directory, we will enable Directory Browsing and enable Windows Authentication:

Open IIS Manager.

Once the CONTENT Virtual Directory has been created, enable Directory Browsing for the CONTENT Virtual Directory:

On the Authentication section for the CONTENT Virtual Directory, enable Windows Authentication and Anonymous Authentication:

In the Request Filtering section for the CONTENT Virtual Directory, delete the .cs rule that is by default set to FALSE, and re-create a new rule that will ALLOW .cs files to be run:

Mime Types:

There are 3 MIME-types that needs to be added to IIS in order to stream App-V packages. They needed to be added to the content Virtual Directory. They are:

File Extension	MIME-Type
.osd	application/softricity-osd
.sft	application/softricity-sft
.sprj	application/softricity-sprj

Brief Test 1:

At this point, you can do a brief test by opening Internet Explorer on the IIS Server and navigate to https://servername/content, and you should see directory browsing enabled:

Publishing Document:

There are 2 methods we can use to build a publishing document. Either we can have a C# script build the XML for the publishing document automatically, or we can manually build the publishing document. For the purpose of this post we will be leveraging the C# script.

Copy the code below into a file called publishing.aspx and put it into the root of the content folder:

<%@ Page Language="C#" AutoEventWireup="true" CodeFile="publishing.aspx.cs" Inherits="appv_publishing_service.publishing" ContentType="text/xml" %>

<DESKTOPCONFIG>

<POLICY

MANAGEDDESKTOP="TRUE"

REPORTING="FALSE">

<REFRESH

ONLOGIN="TRUE"

PERIOD="60"/>

</POLICY>

<APPLIST>

<%this.generate_app_xml(); %>

</APPLIST>

</DESKTOPCONFIG>

Make sure the 1^st line is 100% correct. Then we need to have a second file, located in the root of the content folder, called publishing.aspx.cs. This is the C# script that will propagate the manifest information into the publishing file. Copy the code and save it into the file publishing.aspx.cs:

// CodeBehind File: publishing.aspx.cs

using System;

using System.Xml;

using System.IO;

namespace appv_publishing_service

{

public

partial class

publishing : System.Web.UI.Page

{

protected void generate_app_xml()

{

string root_phys = MapPath(".");

string[] dirs = Directory.GetDirectories(root_phys);

foreach (string dir in dirs)

{

try

{

string[] manifests = Directory.GetFiles(Path.Combine(root_phys,dir), @"*_manifest.xml", SearchOption.TopDirectoryOnly);

foreach (string filename in manifests)

{

FileStream file = File.OpenRead(filename);

XmlDocument doc = new

XmlDocument();

doc.Load(file);

XmlNode applist = doc.SelectSingleNode(@"/PACKAGE/APPLIST");

Response.Write(applist.InnerXml);

}

catch (Exception ex)

{

// Output to log file

Response.AppendToLog(ex.Message);

}

Brief Test 2:

At this point you should have 2 files in your content folder of importance, publishing.aspx and publishing.aspx.cs. In Windows 2008 you will also have a web.config file.

In addition, if at this point you open IE and go to https://servername/content/publishing.aspx, you should see the following, granted you have no subfolders with packages in the content folder yet:

Setting up the Content Folder and Manifest Files:

In most App-V environments, content packages are copied in sub-folders within the content folder. I point this out because the publishing.aspx.cs script will be aggregating package information from the manifest files of all your packages into the publishing file (publishing.aspx). If the paths in your manifest files are not 100%, you can run into errors such as 4A-40000194.

For that reason, we spend some time ensuring the path in the manifest file for each package is 100% correct. Look at the following manifest file for Visio. This is how the sequencer will generate the manifest file by default. This is a partial and incorrect manifest for HTTP:

<?xml version="1.0" standalone="no"?>

</SHORTCUTLIST>

The above file will work fine if you copy all your packages to the root of the content folder. For most companies, they have many packages and store packages in subfolders within the content folder. For this reason, we need to do a find/replace:

Find: %SFT_MIME_SOURCE%/

Replace with: %SFT_MIME_SOURCE%/Visio_microsoft_v2003_MNT/ (your subfolder of the package)

<?xml version="1.0" standalone="no"?>

</SHORTCUTLIST>

Manifest files can be of different lengths. You will need to replace all the paths in the manifest file that does not include the subfolder, to include the subfolder name – not only the ones mentioned above.

Edit the OSD:

Ensure that your CODEBASE in the OSD is set for the correct protocol and path. Here is an example of how the CODEBASE should read:

In addition to the CODEBASE, there are several additional references in the OSD that makes use of %SFT_MIME_SOURCE%, which will need to be rectified by adding the subfolder to it. While editing the OSD, also ensure, just like we did with the manifest file, that the subfolder of the package is correctly reflected in the OSD. It is very likely that it does not include the subfolder. In the OSD, find/replace:

Find: %SFT_MIME_SOURCE%/

Replace with: %SFT_MIME_SOURCE%/Visio_microsoft_v2003_MNT/ (your subfolder of the package)

Configuring the App-V Client:

When configuring the App-V client, add a publishing server as follows:

It is important to have the path in to the Publishing Document as /content/publishing.aspx.

Configure the Application Source Root (ASR) on the client by editing the registry. In the registry, go to the following key (always backup your registry prior to making any changes):

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SoftGrid\4.5\Client\Configuration

Set the following keys as such:

ApplicationSourceRoot	https://servername
IconSourceRoot	https://servername/content
OSDSourceRoot	https://servername/content

Restart the “Application Virtualization Service Agent” on the client. Refresh the App-V client and you will be receiving applications.

Understanding the differences when using HTTP:

Active Upgrade: When using RTPS/S in a traditional App-V model, when a new version of a package has been published, updating the package, the App-V client has intelligence in identifying that the package has changed and the active upgrade process gets initiated. When we use HTTP, it is left up to the administrator to edit the individual OSD files and ensure that the HREF path is set to the correct version of the package.

Justin Luyt | Senior Support Engineer

Udostępnij za pośrednictwem

Guide to configuring Microsoft App-V to both publish and stream via HTTP

Dodatkowe zasoby