How can I deploy and manage virtual applications for remote users who never connect to my network (or vpn in)?

  • Article

Hello Everyone,

I’d like to address a scenario our customers ask us if it’s supported on a regular basis.

Just to provide some context as we talk through the scenario, I’d like to first be clear there are two actions that need to occur on the App-V client in order for a user to successfully run a virtual app.

1)      Application publishing – The app first needs to be added to client so the user will now see the app shortcuts and file types associations (FTA’s) are registered. The App-V Management Server can perform this function over the RTSP(s) protocol. Remember, even though an app has been published (i.e. added) to the App-V client, this does not mean the bits have been downloaded (streamed) to the client. Publishing can also be accomplished using our command line interface, SFTMIME. The App-V management server requires Active Directory and SQL.

2) Application Streaming - This is the function that is required to get the application bits down to the client AFTER the app has been published. The App-V Management server provides streaming capability and supports only the RTSP(S) protocol. Our App-V Streaming server supports streaming (not publishing) and only supports the RTSP(s) protocol. Customers also have a choice to streaming from a web server (IIS 6.0 & 7.0) using HTTP(s) or from a Windows file server (file streaming) using SMB.

Scenario:

Customer would like to provision App-V packages to users who will never connect to the internal network (VPN) BUT are connected to the Internet over low bandwidth (128k). They also had a requirement for the App-V client to dynamically receive updates to the application when the client is on the Internet. This solution needs to provide a rich end user experience for both provisioning the initial application and receiving updates.

So, what’s the most efficient way to publish an App-V package AND provide a rich user experience so the user isn’t waiting for days for the application to stream down to his client?

I’d like to share the experience I had in working with a customer to implement a solution to address the scenario and requirements stated above. The following next two paragraphs go over the proposed solution the customer had planned to implement. Luckily, we had a chance to review and provide a supported solution for the customer to be successful.

Initial customer plan for publishing and loading of the package

In order to ensure a good user experience, the customer wanted to provision and load machines by sending the user a DVD which contained the App-V package MSI along with the package SFT file. The MSI contains the commands (SFTMIME) to PUBLISH and LOAD the app on the client along with Icons and FTA’s. When the user receives the DVD, he/she simply clicks on the MSI (provided they have ADD Package privs on the client), the package is added (published) to the App-V client and then imported into the App-V cache. The user clicks on the app icon and the application launches.

Customer plan to send application updates to the remote clients

In order to ensure the user always had the most update to date version of their application(s) AND minimize the amount of data that needed to traverse between the server and client, they planned on hosting an App-V Management server which was Internet facing. This would allow the App-V clients to receive updates, via differential streaming, from the Internet facing App-V Management server so only the differential blocks, in the package, are streamed to the client. This minimizes the amount of data that needs to traverse over the slow Internet link to the client and provides a rich end user experience.

Well, after listening to the customer’s requirements and proposed solution, we had to come back with the “Not Supported” statement. We then worked with the customer to come up with a solution that met their requirements along with also being supported.

Solution

Just to reiterate, here’s the Scenario:

Customer wants to provision apps to users who never connect to their corpnet (but do connect to the Internet via 128k link) and provide updates dynamically over the Internet. The main requirement was to provide a rich end user experience for publishing, loading and updating the application.

Required Components of the Solution:

App-V Client

App-V client is required for running applications on the system.

DVD containing a batch file to add and load the application (via SFTMIME) along with the SFT files

In order to get the initial application(s) out to the user (which may be up to 2GB in size), the customer would burn a DVD containing and SFT(s).

A Server Hosting Updated Applications

The customer has choice where the client will stream updates from. They can choose to stream from:

1)      An App-V Streaming server (RTSP(s))

2)      IIS 6.0 or 7.0 server (HTTP(s))

3)      Windows file server (SMB).

Using the App-V Management Server is NOT supported in this case.

What’s the difference between the Streaming server, IIS and File server?

If your customer uses the App-V Streaming Server, they can use the ‘Active Update’ feature. This means when the application is updated to V2, the administrator simply places the V2 package on the Streaming server and next time the user closes and re-opens the application, they will receive V2 (via differential streaming). That’s it. The Streaming Server is “smart” enough to know even though the client is requesting V1 of the application, the Streaming server knows about V2 so it will serve up that application to the client. No need to touch the client to “tell” it there are updates available.

However, If your customer chooses to use IIS (HTTP(s) or File (SMB), then when the package is updated, you must configure the client to “point” (via the OVERRRIDEURL setting) to the new SFT (V2) hosted on the server. Since there is no App-V Management Server to dynamically RE-PUBLISH the app on the client to point to the V2 SFT, you would need to go through the process of republishing the package again, via DVD, so the client will point to the V2 of the SFT on the server (defeats purpose of exercise). Once the client was pointed to the V2 SFT, it would receive the new version via differential streaming.

Here’s a technical breakdown of how the scenario could be implemented and supported.

Publishing: Accomplished when the user receives the DVD and clicks on the .bat file.

Loading: Accomplished after the application is published via the .bat file.

Updating Applications: Via differential streaming using the App-V Streaming server.

Step 1: On the DVD, the customer would need to craft a solution so when the user inserted the DVD or clicked on a (batch) file on the DVD, the package would be added via SFTMIME, loading of the package (via SFTMIME) would occur by importing the SFT on the DVD and the OverrideURL is set, for the package, to the remote Streaming Server for updates.

 

Technical Details

1)      SFTMIME ADD PACKAGE:<<package>> /MANIFEST <<location of manifest>> /OVERRIDEURL<<Override URL of the LWS>> (OverrideURL is used for updates to the application AFTER it’s loaded)

2)      SFTMIME LOAD PACKAGE:<<package>> /SFTPATH (Location of SFT on DVD).

Step 2: After the application has been published and loaded into the App-V cache and the user launches the app, the client will query the Streaming server and check for updates to the application. If the application has been updated, only the changes to the application will stream (differential streaming) down to the client and then the application is launched.

You’re done!