locked
Disable app-v 5.0 clients from downloading all virtual applications RRS feed

  • Question

  • We will be using the AppV 5.0 Shared Content functionality in a VDI environment.  We may need the ability to block/disable/prevent end-users from doing the following items:

    • Download all virtual applications
    • Work offline
    • Download individual virtual applications

    I cannot find information online or any PowerShell commands on how to accomplish this goal.  Can this be done?


    Nick Moseley | http://t3chn1ck.wordpress.com

    Thursday, March 28, 2013 4:08 AM

Answers

  • I won't call it a Best Practice yet, but some organizations rename the Client's User Interface executable (AppvClientUX.exe in the client installation directory) at least to avoid poking around with the GUI.

    In theory only administrators are allowed to 'mount' (=really download) packages when in Shared Content Store mode to a client. Applies to the GUI and PoSh commands.

    Though it hasn't been confirmed yet it seems that you have to enable the SCS mode right during client to enforce that default-user restriction. It might be that if you enable SCS mode after installation (PoSH commend) non-admins users might still be able to 'mount'. [Again: not confirmed/validated]

    Generally, there are no 'permission' available in App-V 5 as they were in App-V 4 to prevent user from performing certain actions.

    Falko, thank for that tidbit of information.  We are configuring SCS mode with GPO.  I hadn't even tested the scenario myself before this post, but it seems that maybe the GPO has a side-effect that prevents all users (admin or low rights) from downloading or working offline.  The AppV client (with hotfix 1) did not download any files individually or in bulk.  Running the PowerShell commands to mount the packages also appears to have done nothing.  Well, at least the default cache location doesn't change (remains at 43.5 MB for 2.1 GB of packages)!


    Nick Moseley | http://t3chn1ck.wordpress.com

    • Proposed as answer by znack Friday, March 29, 2013 12:03 PM
    • Marked as answer by Aaron.ParkerModerator Saturday, April 13, 2013 8:23 AM
    Thursday, March 28, 2013 7:17 PM

All replies

  • We will be using the AppV 5.0 Shared Content functionality in a VDI environment.  We may need the ability to block/disable/prevent end-users from doing the following items:

      • Download all virtual applications
      • Work offline
      • Download individual virtual applications

      I cannot find information online or any PowerShell commands on how to accomplish this goal.  Can this be done?


      Nick Moseley | http://t3chn1ck.wordpress.com

    HI

    I'm not sure this is possible .but in theory it is possible .

    You give it for run, administrative privilege so end-user can't run  Microsoft Application Virtualization Client and then can't :

    • Download all virtual applications
    • Work offline
  • Download individual virtual applications

    Or you can use Application Control Policies for Preventing Standard Users from Running Per-user Applications.


  • Dear Problems ,You May Big But My God Is Bigger.

Thursday, March 28, 2013 5:39 AM
  • Now i Test in my Lab , and it work correctly .

    Dear Problems ,You May Big But My God Is Bigger.

    Thursday, March 28, 2013 5:47 AM
  • I won't call it a Best Practice yet, but some organizations rename the Client's User Interface executable (AppvClientUX.exe in the client installation directory) at least to avoid poking around with the GUI.

    In theory only administrators are allowed to 'mount' (=really download) packages when in Shared Content Store mode to a client. Applies to the GUI and PoSh commands.

    Though it hasn't been confirmed yet it seems that you have to enable the SCS mode right during client to enforce that default-user restriction. It might be that if you enable SCS mode after installation (PoSH commend) non-admins users might still be able to 'mount'. [Again: not confirmed/validated]

    Generally, there are no 'permission' available in App-V 5 as they were in App-V 4 to prevent user from performing certain actions. 



    Falko

    Twitter @kirk_tn   |  Blog kirxblog   |  Web kirx.org

    Thursday, March 28, 2013 7:26 AM
    Moderator
  • Now i Test in my Lab , and it work correctly .

    Dear Problems ,You May Big But My God Is Bigger.


    Thanks for the input, I appreciate it.  Unfortunately, I believe the settings you are referring to are for AppLocker, not App-V.  Also, we don't want to prevent execution of these applications as they are legitimately assigned to the end-user.  We just don't want that virtualized app to be downloaded to the local VDI system. 

    Nick Moseley | http://t3chn1ck.wordpress.com

    Thursday, March 28, 2013 6:46 PM
  • I won't call it a Best Practice yet, but some organizations rename the Client's User Interface executable (AppvClientUX.exe in the client installation directory) at least to avoid poking around with the GUI.

    In theory only administrators are allowed to 'mount' (=really download) packages when in Shared Content Store mode to a client. Applies to the GUI and PoSh commands.

    Though it hasn't been confirmed yet it seems that you have to enable the SCS mode right during client to enforce that default-user restriction. It might be that if you enable SCS mode after installation (PoSH commend) non-admins users might still be able to 'mount'. [Again: not confirmed/validated]

    Generally, there are no 'permission' available in App-V 5 as they were in App-V 4 to prevent user from performing certain actions.

    Falko, thank for that tidbit of information.  We are configuring SCS mode with GPO.  I hadn't even tested the scenario myself before this post, but it seems that maybe the GPO has a side-effect that prevents all users (admin or low rights) from downloading or working offline.  The AppV client (with hotfix 1) did not download any files individually or in bulk.  Running the PowerShell commands to mount the packages also appears to have done nothing.  Well, at least the default cache location doesn't change (remains at 43.5 MB for 2.1 GB of packages)!


    Nick Moseley | http://t3chn1ck.wordpress.com

    • Proposed as answer by znack Friday, March 29, 2013 12:03 PM
    • Marked as answer by Aaron.ParkerModerator Saturday, April 13, 2013 8:23 AM
    Thursday, March 28, 2013 7:17 PM