Where is my GUI?! – SP2 for App-V 5.0

Share on facebook
Share on twitter
Share on linkedin
Share on reddit
Share on stumbleupon

Anyone who has downloaded and installed the App-V 5.0 SP2 Beta may have noticed that the client doesn’t seem to have the usual client GUI which we have become familiar with:

Well this isn’t an issue or bug, it is actually intentional. The client graphical user interface has been left out of the default client installation. It can however be downloaded separately.

Here’s the interesting part though, the separate download is provided to you as an .appv package!

This means there is no need to install any additional components, simply deploy the .appv package:

So if you’re wondering where your client GUI for App-V 5.0 SP2 Beta is, the answer is it waiting for you as a downloadable .appv package!

Go grab it here!

**UPDATE** Since the general availability of SP2 for App-V 5.0 yesterday the client GUI now also available as traditional .msi as well as a .appv.

Leave a Reply.

12 thoughts on “Where is my GUI?! – SP2 for App-V 5.0”

    • Hi Thamim,

      Thanks for sharing the link.

      I published the .appv package via the management console and have hit a problem. The app launches fine on my client but freezes my mouse completely (and it doesn’t time out, until I restart). Saying that I can get to the application using my keybaord which functions perfectly fine. Once I hit the “Update” button using my keyboard, this releases the mouse. Its weird!. This is also a random thing that happens and not each time I launch the client. Say one in every 4 attempts.
      I am logged in as admin. On AppV 5.0 SP3

      Any ideas?

      P.s. A Thick install of msi on the client build works perfectly fine and doesn’t freeze my mouse.

      Thanks in advance.

      Reply
        • Hi, Thanks for sharing the links, haven’t come across them before. I will have a read and reply back with my findings!!. Thanks.

          Reply
          • Hi Thamim,

            Sorry for the delay in responding.

            Good news! As mentioned in the link that you provided the issue is to do with the wispts.exe process that runs (even though the machine has no touch enabled devices connected). Killing this process re-enables the mouse.

            As per Dan’s blog, this links to a .Net framework issue. If you install the MS rollup Hotfix rollup 3026376, this fixes the issue. 🙂

            Thanks for your help with this!

            On a side note – Initially I tried going with a AppV package workaround mentioned in the links, that adds a Classes\Interface registry key set to overides the local key, so this intentionally breaks the touchinput functionality only for that virtual app. This meant I created REG_SZ key within the package, which I did, but when deployed to the machine the fix did not work, checking the AppV registry key for this package on the client machine shows the key to be saved in BINARY as opposed to string even though I set it to be a string key. Little confused. Did not further investigate this.

          • Hi,

            Great to hear the hotfix worked to solve this issue. I haven’t noticed the registry key population issue you mentioned when trying the alternative fix, I’ll try and repro it when I get some time to check if I see the same thing.

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.