FNMS handling of suite containing applications

[ianfisch]

I wanted to start a discussion, and hopefully get some of you to support in helping to raise the profile of a much needed enhancement that Flexera engineering are currently rejecting due to lack of demand

Here is the scenario:

I have a licence for a suite of applications. I have active maintenance on the suite and can therefore upgrade to later versions of each application that is a member of the suite as and when it is convenient for me to do so, or if the new version provides a features I want to take advantage of.

Under current FNMS versions, when I create a suite containing applications, I have to specify the "name" of each application I want to add as evidence. The restriction here is the name is version specific so I have to either specify all versions in the evidence, or create multiple suites with multiple combinations of versioning. For a suite containing a number of applications, each with a number of versions (and editions), the number of suites I need to create becomes unmanageable.

When the vendor releases a new version, I have to revisit all my suites and make the necessary adjustments.

Take Adobe Creative Cloud as an example.

The ARL contains a definition for Adobe Systems Creative Cloud Suite 2017. This contains 15 applications all at version CC(2017). So what if I decide to keep InCopy and Animate on versions 2016, but upgrade other component applications to 2017? The ARL entry won't recognise it, and instead may tell me I need two suite licencees, or I need to licence component products

I'd like to see an enhancement whereby suite members can be defined by Product rather than by Name. That way, the family of applications, independent of version can be grouped together.

Does anyone else see this as an issue, or how would you go about managing mixed version suite installations?

[malban]

Yes, this is a BIG issue and 100% should be a product enhancement. Not having this ability and not accounting for it manually, as you (and we) have done, leads to an overstatement of Adobe license position. For yearly subscriptions in large environments this can become very costly if you are not paying attention! Additionally, having to account for this manually, requires additional FTE operational time and oversight which o increases the total operational costs of FNMS. Given that the Adobe product use rights allow for organizations to do exactly what you stated, a commercial product like FNMS should support this ability out of the box.

A BIG +1 for this enhancement request and I strongly encourage others to support this enhancement by adding to this thread.

[RobertH]

Does the User Right: Support Downgrade from Most Recent Application already provide this functionality?

[ianfisch]

rchinds wrote:
Does the User Right: Support Downgrade from Most Recent Application already provide this functionality?

Not that I can see. The downgrade/upgrade right applies to the application. In this case the application is the suite, so using the CC example, the downgrade right would apply to CC 2017 to include CC 2016, CC 2015, etc, but not to the constituent applications that form the suite

[WStephans]

I just came across this post as I am trying to do the same exact thing. Has Flexera issued an enhancement for this??

[mfranz]

Hi,

I can understand that managing complex licenses and their applications can be cumbersome, specifically in large organisations and when multiple people need to work to gether. I sometimes wish there was a comment field for such relations to document when and why applications have been linked (and who did it).

If you're running FNMS on prem, you could automate this process, at least in parts. The table SoftwareTitleProduct has basically what you need. A Business Import could run daily and update licenses as new apps appear in the ARL.

Best regards,

Markward