Citrix XenApp Inventory: Is anyone successfully importing accurate consumption?
We have an environment where half of our software is distributed via Citrix XenApp and half is installed through traditional methods. To complicate things further, most the titles distributed through Citrix are also available for local installations for some customers.
Since the FNMS 2015 version we have been working to get accurate License consumption data both Citrix and Local Installation combined against the same license. Since the 2017 R2 release we have found that we can no longer accomplish this successfully and have had to manually combine Flexera consumption with Citrix Consumption using an external process. This isn't ideal because of the complexity of determining right of multiple use, etc.
Because of this problem, we haven't been able to use FNMS for purchasing decisions or as audit support which degrades the value of the tooling. I have been tasked with solving this issue.
What I have found so far:
The only way to get accurate Citrix consumption work accurately is override the ARL and set the File Evidence Recognition Rule = 'Required' for the executable files distributed by Citrix. The problem with this method it this causes a lot of superfluous consumption on any machines where the executable is present whether of not the application is installed (uninstalled software, backups, file shares, packaging servers, etc). This can be handled with exemptions but this is a unsustainable practice at scale.
The second alternative was to make sure Citrix deployed application used a unique .exe name such as acrobat_citrix.exe. I suggested this but the idea was rejected.
I am looking to determine what processes others are using successfully integrate Citrix deployed application installation to their FlexNet License Consumption.
Are there other configuration alternative I am overlooking?
Is there other tooling that is being used between Citrix and FlexNet Manager to assist this?
Any help would be appreciated. 🙂
I don’t have a silver bullet answer for you sorry as I essentially agree that XenApp integration has some significant dependencies that affect the success of the integration.
The reliance on file evidence (as you note) for (ARL) recognising published apps via the exe they launch is crucial - I have also seen customers that publish apps via cmd/bat files and not exe’s too which is a real problem as the file evidence doesn’t even make it through to FNMS for potential matching (it’s discarded because it’s not an approved file type for file evidence). Even if the customer does publish apps always using exe’s though, your issue of needing the matching recognition rule to be "Required" becomes problematic.
Given the brittleness of this linkage, I have wondered if it might be worth removing all reliance on the file evidence of the invoked executable and just make the AppID of the published app available to FNMS as unrecognized evidence (as installer evidence) so it could then be linked to the appropriate app without causing conflicts with file evidence rules. There would then be work involved to monitor Unrecognized Installer Evidence and link it, but at least they could be easily identified/monitored/linked and not pollute other functionality relying on true file recognition.
Your proposed solution for utilizing the AppID seems like a robust option, as Citrix Logic could utilize the AppID discretely, avoiding conflicts with matching for traditional installation evidence and from future upgraded breaking the Citrix logic.
Just an idea: It may be even more elegant if the evidence could be automatically linked to application where the matching file evidence is already linked. This would provide some automation minimizing the need to manually map, and the risk of missing it on ARL managed packages.