Investigating Issues

IT Asset Management (Cloud)
Proof that the App-V server adapter is operational, and the data upload is also successful, can be seen in either or both of two ways:
  • Installation records for the appropriate applications against expected inventory devices (possibly including Remote devices for which no hardware inventory is available)
  • The presence of any newly-discovered inventory of type App-V in the Discovered Inventory list, typically with an Assigned value of No.
If neither of these is the case, the issues could be with:
  • Imports from the App-V server adapter on an inventory beacon (for both App-V release 4.6, and App-V release 5.0 or later)
  • Imports of the .raa file from your App-V Management Server (only for App-V release 5.0 or later)
  • Missing links between the installer evidence (representing App-V packages) and the applications in the packages
  • Missing consumption on an appropriate license.

Each of these is covered in turn below.

No data imports from adapter on inventory beacon

Check the following to identify the problem with imports from the App-V server adapter:
  1. Are you sure that there should be new records? Have new packages been brought into production since the last time inventory was collected and fully processed?
  2. Check the Status of the latest upload (navigate to the system menu ( in the top right corner), select Data Inputs, choose the Inventory Data tab and select Show details). Also validate that the Last import date is as expected, so that the upload occurred after new App-V packages were brought into production.
  3. If uploads are not happening, move to the inventory beacon where the adapter runs, and check the status of the App-V connection. Use the Test connection button to ensure it can connect to the appropriate database (App-V Management Server database for App-V release 4.6, and the App-V reporting database for release 5.0 and later). Details about setting the connection are in Configuring the Adapter.
  4. On the same inventory beacon, test its connection to the central application server for IT Asset Management, using the Parent connection page and the Test connection button there. (If this inventory beacon is part of a hierarchy, check the connections all the way up the hierarchy to prove that uploads can reach the central server.)
  5. Check for stalled uploads by looking for an App-V inventory file in the %CommonAppData%\Flexera Software\Beacon\IntermediateData directory on the inventory beacon (or, in a hierarchy, in the chain of inventory beacons). (Notice that the folder for files from the App-V server adapter is separate from the folder for .raa files from the PowerShell scripts used with release 5.0 and later.) App-V data files are named in part for the connection you established (see Configuring the Adapter). Once an inventory file of this type is successfully uploaded, it is removed from this intermediate data location on the inventory beacon; so any file in this folder on any server in the hierarchy has not yet been uploaded to the parent server. Upload failures may occur for temporary reasons, such as a network timeout; but there is a catch-up task run overnight to re-attempt uploads of any stalled files.
  6. Has a reconciliation calculation occurred since the upload? Until this occurs (normally overnight), new App-V inventory cannot be displayed in the web interface for IT Asset Management. Check the date and time on the System Health page ( > System Health), in the License reconciliation card. The last import and reconciliation must be after the latest upload from the inventory beacon.
  7. If you are using App-V release 5.0 or later, a failure to upload and save .raa files may also prevent presentation of results, even when the application usage information is successfully imported from the App-V server adapter. Issues with .raa files are covered in the next section.

No data imports from the PowerShell script for App-V release 5.0 and later

If uploads of .raa files do not appear to be working:
  1. Ensure that a new upload is required: that is, that the AppVMgmtSvr.ps1 script has executed successfully since the last inventory import and license consumption calculation (the most recent file is always saved on the App-V Management Server for checking, and is only replaced the next time that the script executes):
  2. Move to that inventory beacon, and check for stalled uploads by looking for an .raa file in %CommonAppData%\Flexera Software\Incoming\RemoteApplications (this file path is different from the one used for files uploaded by the App-V server adapter). If you have a hierarchy of inventory beacons, check each in turn.
  3. If file uploads are happening successfully, has there been a reconcile since the last .raa file was uploaded? Check the date and time on the System Health page ( > System Health), in the License reconciliation card. The last import and reconciliation must be after the latest upload from the inventory beacon. If not, you may (as an administrator) manually trigger a reconcile (navigate to License Compliance > Reconcile ).

Missing application recognition

For App-V release 4.6, data imported from the App-V server adapter includes only the App-V package name and the Active Directory groups (or individuals) that may access the package, according to the Access Control Lists (ACL). Specifically, this imported information cannot recognize what application is hidden within the App-V package. Application recognition requires a separate step. Even for App-V release 5.0 and later, where much better installer evidence allows automatic matching of the evidence rules for the appropriate application, there may be cases where the installer evidence needs manual attention. This will be the case when:
  • There is no matching application available within IT Asset Management, either in application records that you have created locally, or in the Application Recognition Library
  • There is an appropriate application, but the values returned from App-V do not match with the existing inventory rules for the application record.
In cases where installer evidence from App-V is unmatched, you can check as follows:
  1. First be sure that data uploads and imports are happening, as validated in the previous sections.
  2. Navigate to License Compliance > Evidence column > Discovered Evidence > Installer evidence tab, filter for Type=App-V, and check the Assigned column. If it displays No, you need to link this package to an application, as described in Import Evidence and Recognize Applications.) For App-V release 4.6, newly imported evidence is always unassigned, and requires you to manually associate the evidence (or App-V package) with an application.
  3. For App-V release 5.0 (and later), when installer evidence appears in the above listing, it may be worth checking why the data from the App-V installer evidence did not match existing evidence rules for the appropriate application (assuming the application is already present locally or in the Application Recognition Library). To do this, navigate to the Evidence tab of the application's properties, where all existing evidence "rules" are listed (making sure that Installer is the selected subtab). Compare the data displayed there with content in your .raa file (see sample .raa file in File Format for .raa). Here is a worked example of successful matching using the FileZilla 3 application:
    App-V element's attribute Application's installer evidence property
    msiDisplayName="FileZilla Client 3.2.4.1" Name FileZilla Client 3.2.%
    msiPublisher="" Publisher (blank)

    msiVersion="3.2.4.1"

    Version 3.2.%
    accessModeID="2" (produces the evidence type App-V) Type Any
    Thus the .raa entry produces installer evidence that is immediately matched by the existing installer evidence rule for the application, and produces an installation count against that application. But looking ahead (in imagination) to the day when the .raa entry covers a version of 4.2.3.1, the App-V package data in the .raa file would no longer match this evidence rule. At that time, if a new rule was yet to be published in the Application Recognition Library, the installer evidence created from the .raa file would appear in the Discovered Evidence listing, and you could link it to the application, preferably generalizing it (similarly to the example above) to create a rule that would match several minor releases.

Missing consumption

Showing consumption of license entitlements for App-V packages (and the applications they contain) requires:
  • The adapter gathers data from the App-V server and uploads and imports it into IT Asset Management (see first section above for more details).
  • For App-V release 5.0 or later, the .raa file is uploaded from your App-V Management Server
  • The application is recognized, either automatically, or because you have linked the App-V package to an application record (see previous section)
  • The application is linked to a license (and in turn the license should be linked to purchase records to show your legal entitlements) — here, this is left as an exercise for the reader.
  • Active Directory imports are current, allowing mapping of the groups and users from the ACLs in the App-V Management Server database to user records in IT Asset Management.
These notes address the last stage, enabling Active Directory to map from the ACL lists to user records. This process is automatic, provided that all the necessary data is available.
  1. On the appropriate inventory beacon, open the Active Directory page (from the Connections group), and validate that a connection is both established and scheduled. (For details, see Importing from Active Directory in the online help.) Review the Last run time to see when data was last collected, uploaded, and imported. You may also choose Execute Now if imports have been disrupted.
  2. Once sufficient time has passed for Active Directory data collection, upload, and import (normally, 30 minutes should be more than adequate), review the list of All Users to establish that the expected user names are all available (navigate to Enterprise > All Users).
    Tip: If you have App-V applications secured by security groups from multiple Active Directory domains, ensure that the Active Directory import runs against all applicable domains in your environment. The simplest approach may well be to ensure that you import from all your Active Directory domains, since if you use foreign security principals from multiple trusted domains, it can be difficult to keep track of access to App-V packages. FlexNet Manager Suite imports only from each individually specified Active Directory domain; so you need to ensure that all applicable domains are specified. As an example of multiple domains being affected:
    • Suppose you have Group-A in Domain-A that contains a child Group-B, where Group-B actually comes from Domain-B.
    • In this case, granting access to an App-V package to Group-A also grants access to Group-B (because of the parent-child relationship between the groups).
    • This inheritance continues to work even when there is only one-way trust from Domain-B to Domain-A.
    • In such a case, it is imperative that you run an Active Directory import against both Domain-A and Domain-B. When you have many domains, the simplest path is just to run an Active Directory import from every domain.
    Note: You cannot review Active Directory group memberships within IT Asset Management. Only the resulting list of users is available (along with computers, sites, and subnets).

IT Asset Management (Cloud)

Current