Architecture and Operation

FlexNet Manager Suite 2022 R1 (On-Premises)

In order to track licenses for applications delivered remotely to users from a Citrix Virtual Desktops App environment, FlexNet Manager Suite needs information about which users and devices have access to which applications. There are several sources of such data available from XenApp servers, depending on the version of Citrix Virtual Desktops (formerly XenApp):

• For XenApp 6.0 and 6.5:
  • Access control lists (ACLs)
  • Streaming profiles
  • Citrix EdgeSight servers.
• For XenApp 7.5 and later:
  • Access control lists (ACLs)
  • User filters collected from Applications and Delivery Groups
  • App-V 5 packages (and the applications they contain).
    Tip: No usage tracking is possible for XenApp 7.5, as in this release Citrix did not include usage tracking capabilities, in XenApp.
• For XenApp 7.6 and later:
  • The XenDesktop database supplied as part of XenApp that tracks application usage.
• For XenApp 7.9 and later:
  • The collection of Application Group data
  • User filters collected from Application Groups.
    Note: A one time staging database update is required to use XenApp server agent to collect Application Group data and to collect user filters from Applications, Application Groups, and Delivery Groups.
• For Citrix Virtual Apps 7.1808 and later:
  • The collection of Application Group data
  • User filters collected from Application Groups.
    Note: A one time staging database update is required to use XenApp server agent to collect Application Group data and to collect user filters from Applications, Application Groups, and Delivery Groups.

These sources are discussed in turn in the following sections.

Access control lists (ACLs)

These are lists which specify the permissions associated with an object, such as an application’s executable file, on a server. The FlexNet Manager Agent for XenApp Server (XenApp server agent) is a tool that extracts information about users and which applications they can access remotely, and transfers that information to an inventory beacon for use in licensing calculations in FlexNet Manager Suite. To do this, the XenApp server agent must be installed:

• For Citrix XenApp 7.5 (and later) and Citrix Virtual Apps 7.1808 (and later), on one Delivery Controller for each Delivery Site. If you have multiple Delivery Sites, you may choose either of the following:
  • Install the XenApp server agent on one Delivery Controller in each Delivery Site
  • Use only a single XenApp server agent, and provide that XenApp server agent with the required network access and credentials to access all required Citrix Virtual Apps Delivery Controllers.
• For XenApp 6.0 or 6.5, on one controlling XenApp server in each Citrix farm.

Tip: While the XenApp server agent is installed only on one server per farm, for XenApp 6.x you also need software inventory from every XenApp server, in order to identify the editions of applications available to users and computers. This separate inventory of the XenApp servers can be obtained either by installing the FlexNet inventory agent on the XenApp server, or using Zero-footprint inventory collected by an inventory beacon. Do not get the two separate agents (FlexNet inventory agent, and XenApp server agent) confused. The main focus of this adapter documentation is the XenApp server agent.

The XenApp server agent is supplied as an integral part of the XenApp server adapter.

Tip: In earlier releases, the XenApp server agent extracted Active Directory names and details of users and devices from the XenApp server. Now, the XenApp server agent collects only Active Directory SIDs (a large performance improvement). As a result, best practice is that your inventory beacon completes its import of Active Directory data before importing Citrix Virtual Apps data, so that all Active Directory SIDs can be resolved against the user names, devices, and groups collected directly from Active Directory.

Streaming profiles for XenApp version 6.0 and 6.5

The XenApp server agent is also able to read the contents of the .profile and the key executable files associated with streamed applications published to your XenApp servers.

Tip: As the streaming profile is not stored in the XenApp server’s database, the XenApp server agent must have at least read access to the streaming profile location to be able to read and extract this information.

As these applications are not physically installed on your XenApp server, combining the XenApp server agent’s data from .profile files with EdgeSite server information may be the only way for FlexNet Manager Suite to recognize usage of such applications.

Note: FlexNet Manager Suite is only able to recognize usage of files streamed to a XenApp server, not those streamed directly to client devices.

Citrix EdgeSight servers for XenApp 6.0 and 6.5

Citrix EdgeSight for XenApp monitors and profiles the usage of remote and streamed applications by users, telling you both who is using that application, and on what device. The data from EdgeSight is very valuable for FlexNet Manager Suite: you may use it for license optimization (for example, tightening access through ACL permissions to exclude users who evidently do not need to use the applications); or it may be critical for any user-based or usage-based licensing of applications delivered through XenApp 6.0 or 6.5.

EdgeSight agents may be installed on each XenApp server, and report back to a central EdgeSight server, which can keep track of application usage on multiple XenApp machines, belonging to one or more farms. The FlexNet Beacon can connect to each EdgeSight server and collect this usage information for use in compliance calculations.

Unlike data from the XenApp server agent, EdgeSight data does contain details of which devices access a particular application. Thus, EdgeSight data is usually more valuable to an enterprise for calculating license compliance than the data about application availability returned by the XenApp server agent alone. If, however, your enterprise deploys streamed applications, EdgeSight usage data may need to be supplemented by XenApp server agent information to accurately recognize these applications.

The following information is returned from the EdgeSight server:

• A list of applications (product name, version, publisher, and description) and the users who use them
• The devices on which users request and run applications
• The XenApp servers from which users request applications
• The farms to which the XenApp servers belong.

Tip: The EdgeSight data does not include application editions. Because different XenApp servers may have different editions installed (and available to users), it is important to take software (and hardware) inventory of the XenApp servers themselves, using the FlexNet inventory agent (either installed locally on each server or operating remotely from an inventory beacon). This inventory reveals the software editions available on each of the servers, which can be combined with the information listed above to give complete usage data required for license calculations. For example, if server XenApp01 offers Visio Standard, while server XenApp02 offers Visio Professional, the inventory from XenApp01 and XenApp02, combined with the data listed above, allows the license consumption calculations to link users to the appropriate license.

To use EdgeSight data, you must create a database connection to the EdgeSight SQL server database.

App-V 5 packages for Citrix XenApp 7.5 (and later) and Citrix Virtual Apps 7.1808 (and later)

The XenApp server agent is able to inspect the contents of App-V 5 packages and recover the name, version, and publisher of the application contained in each package. The XenApp server agent also returns the user's ability to access these App-V packages (as recorded in the ACLs described earlier). However, in the ability to track which users actually use the applications, there are differences across versions:

• Version 7.5 has no technology like the EdgeSight server available in version 6.x, and so cannot report application usage
• From version 7.6, XenApp (Citrix Virtual Apps) again allows tracking application usage through connection to the Citrix Virtual Desktops (formerly XenDesktop) database incorporated in XenApp 7.6 and later.

VDI images for Citrix XenApp 7.5 (and later) and Citrix Virtual Apps 7.1808 (and later)

The same capabilities apply to VDI images. The XenApp server agent interrogates any VDI device managed by the XenApp server to read the applications listed in all VDI source images available (including spinning up any images that are currently dormant to inspect their applications). As with App-V packages:

• For XenApp version 7.5, there is no ability to track who uses any VDI image, or when
• For Citrix XenApp 7.6 (and later) and Citrix Virtual Apps 7.1808 (and later), the included Citrix Virtual Desktops (formerly XenDesktop) database allows collection of application usage information.

Changed architecture across versions

Because XenApp release 7.5 follows an extensive rewrite of the XenApp line by Citrix, the architectures of the two systems (and therefore the ways that the adapter integrates with the architecture) are quite different from version 6.x to 7.x.

Tip: The following three diagrams do not include the import of Active Directory data by the inventory beacon, as this is not part of the adapter itself. However, the prior import of Active Directory data (typically, by the same inventory beacon connecting to the staging database) is a prerequisite for operation of the adapter.

Also keep clearly in mind the distinction between the XenApp server agent, an executable installed on your XenApp server(s), and the XenApp server adapter(s), an XML file (with embedded SQL) installed on your inventory beacon. The XenApp server agent is responsible for the first part of the process, collecting data and normally writing it into a staging database; and the XenApp server adapter(s) takes the second part, loading data from the staging database to the central application server and its compliance database.

This diagram represents the architecture and data flows for the XenApp server adapter(s) connected to XenApp 6.0 or 6.5 (the key numbers are referenced in the table below):

The next diagram shows the architecture and data flows when connected to XenApp 7.5. The diagram is laid out similarly to highlight the changes in architecture, and in particular the absence of usage information:

Finally, the third diagram shows the architecture and data flows when connected to Citrix XenApp 7.6 (or later) and Citrix Virtual Apps 7.1808 (or later). The main point to note is the return of usage information:

The following table shows the data collected by the adapter through the different channels numbered in the three diagrams.

Table 1. Lists imported by XenApp server adapter

List	Case 1	Case 2	Case 3	Case 4
User SIDs, Active Directory Group SIDs	Y		Y
File evidence (.exe) details – file name, version, company, description	Y	Y	Y
Installer evidence (from App-V/streaming profiles) details – name, version, publisher	Y	Y	Y	Y
Application access rights per user SID	Y		Y
Application usage per user		Y		Y*
Client computer SIDs (with user SIDs)		Y		Y
XenApp servers with applications present for delivery	Y
App-V packages (and the applications therein) managed by Citrix Virtual Apps (formerly XenApp)			Y
XenApp servers that served applications		Y
Applications available in App-V packages (creates App-V 'evidence' records too)			Y	Y
Applications available as streaming profiles	Y

* Application usage by users and devices for Citrix XenApp 7.6 (and later) and Citrix Virtual Apps 7.1808 (and later) releases is limited to applications delivered in App-V packages. (Usage based on imported file evidence is not collected.)

Operation without a staging database

It is possible to vary the integration architecture (shown in previous diagrams) so that it does not require a separate staging database. This is achieved by using additional command-line options for the XenApp server agent that allow it to connect directly to an inventory beacon (see XenApp Server Agent Command Line Options for details). The inventory beacon uploads the collected data through the central application server (or, in a large multi-server implementation, the inventory server) directly into pre-staging tables in your compliance database.

This model still requires the XenApp server adapter installed on the inventory beacon, and you must still configure a connection to the "incoming" data (as described in Create Connections for Data Upload) — except that in this case, instead of connecting to an external staging database, the connection is directly to your central database server. The XenApp server adapter continues to perform its regular work on the central database, de-duplicating, normalizing and transforming data from the pre-staging tables in the compliance database into the appropriate Imported* staging tables in the same database, where it awaits the next compliance import.

This alternative varies the third diagram above to look more like this:

Operation with Citrix XenApp 7.5 (and later) or Citrix Virtual Apps 7.1808 (or later)

The XenApp server agent is installed on the XenApp server (at your discretion, on only one server that can access all other controllers for Citrix Virtual Apps (formerly XenApp) in your enterprise, or as many as one per Citrix Virtual Apps site).

Triggered by a Windows scheduled task, the agent runs according to your settings. It may collect inventory details only from the XenApp server on which it is installed (default), or it may collect from several controlling XenApp servers in sequence (identified with the -s command line option, detailed in XenApp Server Agent Command Line Options).

a. VDI images

Based on information found on the XenApp server, the XenApp server agent may connect to any relevant XenApp servers hosting VDI images that contain applications. XenApp allows an administrator to nominate applications within VDI images for delivery

1. As individual applications only
2. Within a VDI (delivered as a whole environment) only
3. Either as individual applications or within a VDI.

The XenApp server agent collects information on all applications within the VDI source images that are identified for individual delivery (options 1 or 3 above). The VDI evidence is returned to FlexNet Manager Suite as file evidence. (For XenApp version 7.6 and later, usage tracking is not available for the file evidence.)

Tip: To track inventory delivered within an entire VDI environment (option 2 above), use XenDesktop discovery and inventory through the rules-based process in the web interface of FlexNet Manager Suite.

b. App-V packages

Again based on information gathered from the XenApp server, the XenApp server agent connects to any Microsoft App-V publication server to inspect any App-V packages registered for delivery through XenApp. Because XenApp requires App-V version 5 (or later) for integration, the XenApp server agent can interrogate the packages to identify the applications inside. The App-V evidence is returned to FlexNet Manager Suite as installer evidence.

For XenApp version 7.6 and later (but not for version 7.5), a connection is also made to the XenDesktop database from the appropriate inventory beacon. This collects details of App-V application packages that users and devices have accessed. This additional information restores the ability (missing for version 7.5) to determine which users and devices have actually used each application, as distinct from merely having access to them. This may allow for more accurate license consumption calculations in later compliance calculations for applications delivered in this way.

c. Processing

So both kinds of applications are returned to FlexNet Manager Suite as evidence:

• From VDI images, file evidence is produced that normally includes file name, version, company, and description
• For App-V packages, installer evidence is returned that normally includes application name, version, and publisher.

When the data is finally imported into FlexNet Manager Suite:

• The incoming evidence is tested against existing evidence records (including "rules" generalized with wild cards) already linked to applications (either from the Application Recognition Library or from records produced in your enterprise).
• If the incoming evidence matches any existing rule or record, it is recorded against the linked application, and its presence is recorded in the properties of the appropriate user or device as an "installation" record. For XenApp 7.6 (or later), a usage record is automatically created for each user and each device shown to have accessed the application.
• If the incoming evidence is not matched, it is displayed in evidence listings (for example, navigate to License Compliance > Discovered Evidence (in the Evidence group), select the Installer evidence tab for App-V applications and the File evidence tab for VDI applications). You can select the evidence in the appropriate tab, and click Assign to choose an application record (or create a new one) to link to the evidence. (You only need do this the first time that new evidence is reported. Once linked to the application, your evidence serves as a 'rule' for matching future imports of the same evidence.)
• Once the incoming evidence is linked to an application (either automatically or manually), license reconciliation attempts to calculate consumption through XenApp on any license linked to the application. For this to take effect, you must correctly configure at least one license attached to the application:
  1. Navigate to the Use rights & rules tab of the license properties.
  2. Ensure that the License consumption rules heading is expanded (if not, click the heading).
  3. Select Access granted to users, or usage, consumes license entitlements to expose additional controls.
  4. Depending on the terms of your license, choose one of Consume one entitlement for each user or Consume one entitlement per device owned by each user.
  5. For XenApp 7.5, set Consume entitlements based on to Access (because only access records are available through XenApp 7.5). For other versions tracking App-V applications, check the terms of your license to see whether usage-based licensing is acceptable for this application, and make selections accordingly.

Collection of Application Group data and user filters from Applications, Application Groups, and Delivery Groups

The collection of Application Group data from XenApp server and XenApp Desktop is supported in FlexNet Manager Suite for XenApp and XenDesktop versions 7.9 and later. FlexNet Manager Suite also supports the collection of user filters from Applications, Application Groups, and Delivery Groups to more accurately calculate application access. (XenApp and XenDesktop provide the ability to add user filters to Applications, Application Groups, and Delivery Groups in order to restrict access.)

Note: To take advantage of support for Application Groups and the collection of user filters, you must use the new XenApp server agent, XenAppAgent. In addition, a one time staging database update is required to use XenAppAgent to collect Application Group data and user filters from Application Groups. The XenAppAgent installer can be found in the within the XenAppAgent folder of the Citrix XenApp Server Agent subdirectory that is provided in the Adapter Tools for FlexNet Manager Suite archive. The Adapter Tools for FlexNet Manager Suite archive is available in a zip archive in the Product and License Center.

Tip: Application Groups are groups that let you manage collections of applications. Being able to categorize applications into collections enables some settings to be administered for all applications in a group. The concept of Application Groups was added in the 7.9 release of XenApp and XenDesktop.