SCCM Client and App-V client on the same box (continued)

In my previous post on the coexistence of the SCCM client and the App-V client on the same box I mentioned that the SCCM client will take control of the delivery and streaming of virtual App-V applications once it’s installed.

Aaron Parker posted a follow-up to this post in which he mentions that this behavior only occurs if you’ve allowed the virtual application package advertisement on the Advertised Programs Client Agent properties.


I did indeed forgot to mention that. Thanks Aaron!

Read more at source.

SCCM Client and App-V client on the same box

If you install the SCCM client on a machine on which the App-V client is installed, your current applications will no longer work and fail with the following error: Unable to initialize package information (0×00000000)


After the installation of the SCCM client the App-V client cache will be flushed and if you set up a publishing server you will recieve the published applications but they will fail to stream and start.

This is caused by a changed in registry during the installation of the SCCM Client:


LaunchCommand "C:\Program Files\Microsoft Application Virtualization Client\sfttray.exe" /launch "<APP>"
DDELaunchCommand "C:\Program Files\Microsoft Application Virtualization Client\sftdde.exe" "<APP>" <DDE>
With SCCM client installed:  
LaunchCommand "C:\Windows\system32\CCM\VappLauncher.exe" /launch "<APP>"
DDELaunchCommand "C:\Windows\system32\CCM\VappLauncher.exe" /launch "<APP>"

This means that when the SCCM client is installed on the system it is expected also to handle virtual application launch and stream.

I’ve seen that changing the registry back to the original value will make streaming available however if this is a supported scenario, I’m not sure. The SCCM client might change the value back in time.

Explanation of manifest.xml file in App-V 4.5

The manifest file is a new file in App-V 4.5 and automatically is generated each time when saving a Sequence. It is always named like the SPRJ and SFT filename you enter with _MANIFEST.XML following. So when you save a package and name it CRMAPP.SPRJ the manifest file will be named CRMAPP_MANIFEST.XML.

The manifest file contains all information to create Desktop, Quicklaunch and Start Menu shortcuts of the Sequenced application. Also all information about the application it’s File Type Associations and Context Menus are stored in there.

First off, lets talk about what it is NOT used for. Strangely enough the manifest file is not used in a “Native” App-V 4.5 infrastructure where you use the App-V Management and/or App-V Streaming server. In this case the .SPRJ file is still the file you use to import a Sequenced application into the App-V Management Console.

At this moment there are three other new App-V 4.5 deployment scenarios where the manifest file is used:

1. You need the manifest file each time you import a Sequenced Application into SCCM 2007 R2. So if you have existing Sequences based on SoftGrid 4.1/4.2 and you are thinking about using the App-V 4.5 integration available in SCCM 2007 R2, you simply need to open (not open for Package Upgrade!) your older Sequences and save them within the 4.5 Sequencer. The manifest file will automatically be created.

2. You can also use the manifest file to manually or script the import of a Sequence on any machine with the App-V 4.5 Client installed. This makes it possible to use App-V enabled (sequenced) applications without having any App-V Back-end infrastructure. The nice thing about doing it this way instead of pointing the .OSD file to a local file (which is another trick), is that with use of the Manifest file the application fully behaves like it is installed locally with all the shortcuts and File Type Associations.

This could be very usefull when Sequencing and you simply want to test the result on a App-V client.

This is the command you use:

SFTMIME.EXE add package:could-be-any-unique-name /manifest c:\folder\crmapp_manifest.xml /overrideurl c:\folder\crmapp.sft

So the unique package name I mention doesn’t even have to be the same as the name you used during packaging. It is best to do so off course. The streaming location in the OSD files from the Sequenced application will now be overruled by the /overrideurl parameter, and on launch the application will be streamed from file. When you launch the application at this point the application will be streamed from file.

If you also want to automatically load the application into cache after running the previous command, use the following command:

SFTMIME.EXE load package:should-be-the-same-name-as-before

To be able to use this type of import functionality the App-V client needs to be configured to “Allow Streaming from File” which you can set during a Custom Installation of the App-V 4.5 Client. Doing this afterwards cannot be done from the App-V Client Management Console (SFTCMC.MSC), but can be done by changing a registry key and restarting the App-V Client Service (SFTLIST). The registry key that needs it’s value to be changed from 0 to 1 is:


If necessary, for a non-local Admin to be able to run this command also the security settings within the App-V 4.5 client should be changed. The permissions called “Add Applications” should be checked in the App-V 4.5 Client for “Users” to be able to do this.

The use cases for using the command line to do this are various like for example doing this in a Terminal Services environment with App-V 4.5 and you don’t need App-V back-end infrastructure anymore.

3. With App-V 4.5 the option of creating an additional .MSI file when saving a Sequence is introduced. What actually happens is that the manifest file, .OSD and .ICO files are saved in the .MSI file. And when you run the .MSI file a MSI Custom Action is run from the .MSI file, which is actually the same SFTMIME command as I describe in scenario 2.

So also the end result of running the .MSI file will be the same as described in scenario 2. The downside of the “MSI way” is the OSD files are in the .MSI file and the .OSD files you see “outside” the MSI file are not used. Which means that if you want to quickly edit an .OSD file you need to do this from the Sequencer, where in scenario 2 you can do this without using the Sequencer en simply run the SFTMIME command again.

The nice thing from scenario 2 and 3 is that you can now easily integrate App-V 4.5 in any other deployment solution if you don’t want to use App-V in the “Native” way or if you are not using System Center Configuration Manager (SCCM).


App-V Ping tool available

A tool called the “App-V Ping tool” is available as a free download at Look for the Immidio Resourse Kit if you can’t find it. The tool can be used to check if an Microsoft Application Virtualization Management and/or Streaming server is available from a Client-Side perspective.

For example, with use of a startup script, which runs on the client device, you can use this tool to check if the nearest by and configured App-V Streaming Server is available and responding properly and if not point the App-V Client to another, maybe central App-V Management or Streaming Server. The tool does not only check if the RTSP port 554 is still alive, but even if it is still really accepting RTSP streaming requests.

The company Immidio was spun off from Login Consultants in order to provide software products to enterprise customers with requirements that go beyond free and unsupported tools. Immidio’s mission is providing state-of-the-art software products to manage application delivery and virtualization in IT environments.

App-V 64-Bit (x64) Client available in 2010!

This was anounced officially at TechEd in Barcelona earlier this week. The current server components do work on x64 versions of Windows. There simply is no App-V client available that works on x64 Windows. This has to do with some Device Drivers the App-V Client uses.

The few customers that asked me about x64 support, where all Terminal Services customers. The need for supporting App-V on x64 Windows Vista is obviously not there yet.