Jump to content
Welcome to our new Citrix community!
  • From Field Book on Citrix/App-V Integration


    cugcblogs

    tim-mangan-175x175-1.png by Tim Mangan, CTP Fellow, Boston CUGC Leader

    Field Book Chapter 1: How do I Integrate?

    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 implement App-V in Studio.

    Use tag FieldBook to search for more from the series.

    Scenario:

    A Customer is migrating from some XenApp 5 and 6 farms and has been using Citrix Streaming in the past.  The customer primarily utilizes physical desktops with imaging and ESD, so XenApp usage is light; XenApp is used mostly for one-offs and people that need to access an in-house app with a database in a different part of the world. 

    They are already building a 7.7 farm and will move to App-V for the app virtualization benefits.  There is no apparent interest in converting packages from Citrix Streaming to App-V.

    Time-Frame:

    Since the decision to build the new XA 7.7 farm and the time I am being asked to design the App-V infrastructure, 7.8 has been released and 7.9 is in the process of being released.

    Considerations:

    The implementation is for XenApp with published applications only, no published desktops.  App-V Integration to XenApp using the ESD are not under consideration as publishing performance is not acceptable.

    Prior to 7.9, Citrix supported an interface that would pull App-V virtual applications from an App-V Server infrastructure. The 7.9 release adds the option to use direct integration with an App-V package share without the servers.  When the customer is not delivering App-V apps to physical desktops, elimination of the App-V Server would simplify the solution. 

    This is a consideration for the customer, but ultimately was rejected due to two reasons:

    1) The customer just installed 7.7 last week and has no intention to upgrade. They are in a LTSB mindset; just want this built and forgotten.

    2) A big use case for App-V for this customer is integration with Office.  They need to support multiple versions of Office, and will require connection groups.  If possible, they want to avoid Silos.  While 7.9 supports direct integration of App-V packages from the share, it does not support Connection Groups (later added in 7.11).

    The XenApp Farm has already been built for HA with a main site, two major branch sites, and a DR site.

    All application packaging, distribution, and assignments are controlled by the main site.  The customer is quite comfortable with DFS.

    If a remote site becomes disconnected from the Main/DR sites, there is no need to be able to publish new apps locally at the disconnected sites.  As long as existing users get the apps they already had, there are far more important things to be worrying about.

    Result:

    We implement the App-V Servers.  As the customer is already concerned with VM sprawl due to the large number of VMs to implement XenApp, we piggyback as much as possible.

    The App-V database resides on the same SQL Server(s) used for XenApp FMA.

    The Main and DR sites have both the App-V Management and App-V Publishing servers installed on all XenApp Delivery Controllers.

    Note: The customer had initially wanted the App-V Publishing Servers installed on the StoreFront Servers. While that might be the right location if the publishing server was also handling physical desktops, because that was not the case for this customer it wasn't the best choice. There is no need to expose the Web protocol based interfaces of the App-V Publishing Servers to the outside world.

    The two remote sites receive only App-V Publishing Servers, no Management Servers.

    DFS is used to replicate the App-V package storage between the main, remote, and DR sites.  While not all packages are required to be replicated to the remote sites, and while we can set up DFS replication more optimally, due to the low volume of packages a simple solution is the best.

    We implement a GPO to configure the App-V Client.  This includes turning on scripting and shared content store mode. Because the Citrix integration will take care of adding in the App-V Client configuration of the publishing server, we leave that out of the GPO.

    NetScalers are used to perform local load balancing within a site. App-V Publishing servers are configured to locate the Management server using a Localhost URL to avoid possible cross contamination if a Delivery Controller VM is acting up.  Globally, DNS controlled access to correct Storefront server ultimately causes delivery components to utilize the local site infrastructure.

    About Author:

    Tim Mangan is an independent consultant, Citrix CTP, and Microsoft MVP.


    User Feedback

    Recommended Comments

    There are no comments to display.



    Create an account or sign in to comment

    You need to be a member in order to leave a comment

    Create an account

    Sign up for a new account in our community. It's easy!

    Register a new account

    Sign in

    Already have an account? Sign in here.

    Sign In Now

×
×
  • Create New...