Aug 29, 2013 - 9 Comments - Virtual Vibes -

Sequencing a Shortcut in App-V 5.0 – Local and Virtual Interaction

This is now done within the package editor rather during the sequencing workflow itself, however the functionality is identical.

We talked about this technique in 4.x here, all these same concepts apply in 5.0 so if you are interested in the concepts jump over to the post.

What I want to discuss in this post is what has changed and how does the client handle the shortcuts we publish.

So might be thinking RunVirtual or even the new integrations we have with App-V 5.0 SP2 has pretty much deprecated this technique, however there still might be instances where you want users to intentionally use a different shortcut to trigger a certain virtual application to load in with a local process.

So what’s changed?

No much but the first change is where we configure our shortcuts:

 

Here I have added a shortcut to a local process of Internet Explorer held at “C:\Program Files\Internet Explorer\iexplore.exe”

The last change is how the shortcut gets laid down on the client itself and loads the virtual environment. In App-V 4.x our shortcuts were built up from sfttray commands, this intermediary process would launch the virtual environment and then invoke the necessary executable.

In App-V 5.0 our shortcuts call executables directly as discussed here. So in order to make sure the VE is loaded when we call this local process the shortcut path is amended to:

“C:\Program Files\Internet Explorer\iexplore.exe”  /appvve:DCB70E2E-C005-46B7-86FD-63899D03F8D1_2EA3C6FE-267B-4728-BD21-4C29615AC22B

The addition of the /appvve makes sure the local process loads with the virtual environment of our App-V application.  This is all handled by our client to automatically so there is no need to sequence any differently.

9 Responses to Sequencing a Shortcut in App-V 5.0 – Local and Virtual Interaction

  1. Mark C

    Hi Thamim. Is this method also supported with the ID’s of the Connection Group unlike RunVirtual? Also it doesn’t seem to have the same limitation as RunVirtual in that the packages done’t need to be globally published. Is this correct?

    26 Apr 2014 - Reply
    • Thamim Karim

      Hi Mark, this is correct. You can test this directly from PowerShell, it is the same thing. No requirement for global publish. Obviously the downside is extra shortcuts.

      26 Apr 2014 - Reply
  2. Becki

    Do you do this all within one package, at the time of sequencing the ad-in, or do you go back in to edit the package/create a new one?

    26 Apr 2014 - Reply
  3. Raj

    Hi Thamim. When I was sequencing a package for “Freeplane” application, I have unchecked the “allow named & COM objects to interact with local system”. But when I launch the Freeplane application, still I see it is able to interact with the locally installed “Java 7” application, which is a dependency for the “Freeplane”. Please could you let me know how local interaction is possible when we disable the option in sequencer.

    And also I would like to know the real significance of the “allow named & COM objects to interact with local system” check boxes in sequencer.

    5 Apr 2016 - Reply
  4. Raj

    Hi Thamim. Can you give me insights on my above query?

    11 Apr 2016 - Reply
  5. Raj

    Thanks for the reply Thamim.

    I have sequenced “Freeplane” software, which requires “Java 7” as a dependency and I had installed “java 7 ” locally. By nature any App-V package should not look into the local machine, unless explicitly said. But in this case my “Freeplane” app-v package is able to look for the locally installed Java 7 and able to interact with it. Now the concern is how should I disable App-V package interaction with locally installed softwares.

    19 Apr 2016 - Reply
    • Thamim Karim

      I think you have misunderstood how App-V works, packages do not need to be told to not see natively installed software, they will by default if the directories or registry keys are not present within the virtual environment. If you want freeplane to see your particular version of Java then put it in the App-V package or in a connection group with the package.

      19 Apr 2016 - Reply
  6. Raj

    Ok. Thanks for the clarification. It means by default App-V has access to look into the native installed softwares. So there is no way that I can stop my App-V package looking into the local machine for any components.

    20 Apr 2016 - Reply

Leave a Reply

Your email address will not be published. Required fields are marked *