cugcblogs

From Field Book on Citrix/App-V Integration: Client Settings

by Tim Mangan, CTP Fellow, Boston CUGC Leader

Field Book Chapter 2: App-V Client Settings

ABOUT THE SERIES:

The Field Book on Citrix with App-V is a collection of experiences in customer implementations.  This article helps to understand the decision points around how to configure the App-V client.

Use tag FieldBook to search for more from the series.

Scenario:

Customer is setting up App-V for the first time.  It is a multi-site scenario.

  • App-V Clients will be on both XenApp and XenDesktop VDAs.  It is unclear yet if XenDesktop will be Private or Pooled (Persistent or non-persistent), so want to accommodate both.  No App-V clients needed on physical desktops.

The customer is choosing to implement the App-V Reporting server to help with existing license compliance concerns. 

Time-Frame:

The customer is using XenApp and XenDesktop 7.11 with MCS and App-V 5.1 RTM with Hotfixes.

Considerations:

The customer wants to keep things as simple as possible and is choosing to use the direct integration with the App-V package share rather than implement the App-V Management and Publishing Servers.

While Citrix recommendations are to use Citrix policies and not configure the App-V client directly except when additional settings are needed, the Citrix policies do not cover everything the customer needs.

The customer is Group Policy savvy and would prefer to configure the client using the App-V GPO provided by Microsoft rather than a configuration baked into the MCS images.

As MCS is in use (rather than PVS), movement of the App-V cache to an alternate drive is not required.  With PVS, typically the App-V cache location gets configured to an alternate, persistent local drive, and a boot script is run to delete that cache upon boot. With MCS, this is not needed and the default locations for the App-V cache are OK.

No App-V clients exist outside of the data center. With potential non-persistent XenDesktop, and semi-persistent XenApp in play, Shared Content Store (SCS) Mode is preferred for the App-V Clients to reduce IOPS.  For persistent XenDesktop, you could go either way as the IOPS reduction is a one-time hit per package, but the reduced storage requirement by going with SCS is important to the customer. 

Result:

Two Group Policy objects are able to be created to configure the App-V Clients.  The common settings configured in the GPS include:

  • Enable Scripting
  • Disable AutoLoad
  • Enable SharedContentStoreMode
  • Enable Reporting, configure main-site Report Server URL and extend Reporting Random Delay to 60 minutes.
  • Disable ExperienceImprovementOptIn  (just to be sure)

For clients running on XenApp, because no users have access to full desktops (only published applications), the following setting is added to their copy of the GPO:

  • Disable EnableDynamicVirtualization.

Outside of the GPO, it is also necessary to configure a logoff script for users of non-persistent XenDesktop.  That script runs the App-V PowerShell command to force a reporting update to the report server before the data is destroyed.  XenApp users do not need this, although a shutdown script is added to the XenApp server to do the same.  Non-persistent XenDesktop users need no script as reporting will eventually catch up with them.

Finally, because the OS is refreshed after booting, it is important to add a PowerShell line to the shutdown scripting to cause an immediate push of the reporting data to the report server, so as to not loose the last day’s reporting data.

Leave a Reply