Re: XenApp Integration with FNMS 2017 R3

It looks like the 2017 R3 XenApp agent does support direct upload to a beacon (using the -url command line option). This causes the XenApp agent to upload a .raa file to the beacon which (like inventory) gets passed up the beacon chain until it is consumed by the FNMS servers.

The intent of this option is that it can avoid the need for a staging database local to the beacon, but in reality it just means that the data is effectively "staged" in the FNMSCompliance database (just that it happens automatically with OOTB functionality). So, whilst the -url option avoids the need for the beacon side staging DB, it doesn't avoid the need for an inventory connection to be defined to that "staged" data. So you still need a beacon to define that connection to the "Staged" data - which in this case happens to be the FNMSCompliance db.

If FNMS cloud is being used, then you can't access the FNMSCompliance database so it's not an option - so it's just applicable for specific on prem use cases. In most cases, the staging db local to the beacon is just more convenient anyway as you could just use a SQL express edition (the volume of XenApp data is usually small) - and if you can also use the staging db for other purposes (business adapters etc) then it is much more compelling.

To answer your specific question tho - it is 'possible' to avoid a staging db, but it's very uncommon, not an option for cloud FNMS and probably should only be considered for very specific controlled environments.

Re: XenApp Integration with FNMS 2017 R3

Not having EdgeSight essentially means that you won't have visibility of actual usage of apps by users through Citrix. You can still integrate by deploying the FNMS XenApp agent to servers in the Citrix farm. The FNMS XenApp agent collects ACL (Access Control List) data which denotes which published applications are accessible to which users/groups. This ACL information is used by FNMS to reflect the users 'ability to access' the application - this is done by showing an installation of the application via the access mode of 'XenApp'.

The 2017 R3 adapters reference has full details of how to implement this:

Re: XenApp Integration with FNMS 2017 R3

Hi!
Staging database is required in 2017 R3, The direct upload is possible from 2018 R1 onward if memory serves correctly.
Even still the staging database is recommended, as it's much easier to work with. Also Getting all AD data via the FNMS AD connector is critical, for all Domains that are part of the Citrix XenApp Farm, we compare the SID of the groups we collect with the SID of the AD Data collected.

Re: XenApp Integration with FNMS 2017 R3

It looks like the 2017 R3 XenApp agent does support direct upload to a beacon (using the -url command line option). This causes the XenApp agent to upload a .raa file to the beacon which (like inventory) gets passed up the beacon chain until it is consumed by the FNMS servers.

The intent of this option is that it can avoid the need for a staging database local to the beacon, but in reality it just means that the data is effectively "staged" in the FNMSCompliance database (just that it happens automatically with OOTB functionality). So, whilst the -url option avoids the need for the beacon side staging DB, it doesn't avoid the need for an inventory connection to be defined to that "staged" data. So you still need a beacon to define that connection to the "Staged" data - which in this case happens to be the FNMSCompliance db.

If FNMS cloud is being used, then you can't access the FNMSCompliance database so it's not an option - so it's just applicable for specific on prem use cases. In most cases, the staging db local to the beacon is just more convenient anyway as you could just use a SQL express edition (the volume of XenApp data is usually small) - and if you can also use the staging db for other purposes (business adapters etc) then it is much more compelling.

To answer your specific question tho - it is 'possible' to avoid a staging db, but it's very uncommon, not an option for cloud FNMS and probably should only be considered for very specific controlled environments.