- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-29-2022 09:32 PM
Hello Experts,
I am looking forward to understand the inference % calculation for suite application with even no. of child applications. Does the inference % has to be a whole number or can we use rational number as well?
For example- if a suite product consists of 6 child applications and at-least 5 child applications must be installed in order to consume a full suite license, in this scenario what inference % should be added. (83.33% or 84%?) Is there a formula we can use to accurately calculate this?
Thank you,
Parul
Solved! Go to Solution.
- Labels:
-
Multiple Versions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-30-2022 08:14 AM
First, mathematically, fractions of a percent in this context mean nothing. Round up or down, the number you use should be a true representation of this kind of approach to a suite in as simple terms as possible. If you have 6 products, you could still say "inference is 90%" and it achieves the same as 84%.
However, I am cautious about using this feature. Inferring that a certain amount of suite components is used before the suite applies implies that you have no control over your buying methodology.
Say you buy Microsoft Office on a volume licensing plan. You will buy the same suite for everyone. You don't normally buy Office Pro Plus for one user and Excel Standalone for another. And what happens if they only install one part of the suite and uninstall the rest of the suite? Have they truly broken the bundle? Seems like, for some products, it's prone to incorrect accounting.
Despite how the documentation refers to Access as being an example of a part of that inference, it is incorrect to state that just because Access is installed that Office Professional is installed. You can have Office Standard installed and then purchase and use Access standalone. Probably not recommended, but if you're doing that so you can use Access only for project work and then reassign it to another user later, that makes more sense. You wouldn't want ServiceNow thinking that the wrong product is actually installed or the wrong entitlement is applied.
One last thing about Microsoft: Technically, if you install Access with the standalone installer, you can't apply a suite license to it. But that is a gray area that over time is becoming less of an issue with O365.
As well, this should NOT be used for anything that is assigned in a portal. Adobe Creative Cloud is a great example. If you use inference based on what is installed, you run the risk of not having an accurate representation of what is assigned to users in the portal. You could be using 5 products and be assigned all of them as single product licenses in an ETLA, spending much more than you should, but due to inference ServiceNow could be reporting that the user has All Apps installed. In reporting SaaS and subscription named-product licensing, you need to have a full and accurate accounting of what is assigned, not just what is installed. I would never use an inference percentage for Adobe and expect that ServiceNow reflects the same as the Adobe admin portal.
Having said that, this probably has some specific use cases that apply. For those non-publisher-pack products that won't get messed up using inferences, I would just leave it to a round number that captures the applicable components, not worrying about fractions of a percent.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-30-2022 08:14 AM
First, mathematically, fractions of a percent in this context mean nothing. Round up or down, the number you use should be a true representation of this kind of approach to a suite in as simple terms as possible. If you have 6 products, you could still say "inference is 90%" and it achieves the same as 84%.
However, I am cautious about using this feature. Inferring that a certain amount of suite components is used before the suite applies implies that you have no control over your buying methodology.
Say you buy Microsoft Office on a volume licensing plan. You will buy the same suite for everyone. You don't normally buy Office Pro Plus for one user and Excel Standalone for another. And what happens if they only install one part of the suite and uninstall the rest of the suite? Have they truly broken the bundle? Seems like, for some products, it's prone to incorrect accounting.
Despite how the documentation refers to Access as being an example of a part of that inference, it is incorrect to state that just because Access is installed that Office Professional is installed. You can have Office Standard installed and then purchase and use Access standalone. Probably not recommended, but if you're doing that so you can use Access only for project work and then reassign it to another user later, that makes more sense. You wouldn't want ServiceNow thinking that the wrong product is actually installed or the wrong entitlement is applied.
One last thing about Microsoft: Technically, if you install Access with the standalone installer, you can't apply a suite license to it. But that is a gray area that over time is becoming less of an issue with O365.
As well, this should NOT be used for anything that is assigned in a portal. Adobe Creative Cloud is a great example. If you use inference based on what is installed, you run the risk of not having an accurate representation of what is assigned to users in the portal. You could be using 5 products and be assigned all of them as single product licenses in an ETLA, spending much more than you should, but due to inference ServiceNow could be reporting that the user has All Apps installed. In reporting SaaS and subscription named-product licensing, you need to have a full and accurate accounting of what is assigned, not just what is installed. I would never use an inference percentage for Adobe and expect that ServiceNow reflects the same as the Adobe admin portal.
Having said that, this probably has some specific use cases that apply. For those non-publisher-pack products that won't get messed up using inferences, I would just leave it to a round number that captures the applicable components, not worrying about fractions of a percent.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-04-2023 12:25 PM
So how would you manage the CC All Apps Pro & Single App Pro software models? Are you saying to leave the inference percentage blank on both and delete the suite components? I agree SaaS software doesn't need to track installs so much as the subscription assignments as they can't use the applications without the right assignment in the Adobe Admin Console anyway.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-05-2023 08:36 AM - edited 04-05-2023 08:40 AM
Hi Gavin. Adobe is a great example where you should just leave the content service recommendations nearly as-is and focus more on the allocation and direct integration to properly position your licensing. There are two concepts at play here: the optimized view (what would be able to be covered based on available licensing) and the deployed view (what is actually assigned and used). The bundling for Adobe helps with the optimized view, not the deployed view.
If you do not allocate your licenses or ingest subscriptions using the Adobe direct integration, focusing primarily on software model inferences, you run a few risks:
- First, software model inferences are at that point install-based only. They will not identify where a user has a license assigned (and therefore consumed) but not installed.
- Single app licensing in ETLAs is a relatively new concept that the ServiceNow content service has not developed into a proper licensing and side-grade modeling system. Just relying on installs of target products will improperly come up with out of compliance warnings where the reconciliation model doesn't realize that the new product that doesn't have a direct entitlement can be covered by moving a single app license from one product to another (not without much more customization in the modeling and entitlements).
- All Apps Pro bundles, as mentioned, cannot properly apply without allocating that license both in ServiceNow and the Adobe portal. Relying on inferences for deployment does not reflect properly the state of the assignments in the portal, which ultimately determines your actual consumption.
I'll be candid and state that I have not found a truly proper way to have compliant status across the board for Adobe without a lot of care and feeding. However, this is the best approach I can share:
- First, enable the direct integration to Adobe's portal wherever possible. Without this, you're doing a lot of manual work and are prone to errors. This will load the Subscription table with what is actually assigned which also feeds the reconciliation and dashboards in Workspace/Classic.
- Move to entitlements - do not load entitlements against an exact publisher part number. It is restrictive and ultimately unnecessary for what you need as an asset manager. Instead, there should be a top-level software model for Adobe Creative Cloud All Apps as well as Adobe Creative Cloud Single App. Don't do anything with the suite components for All Apps unless you feel you are missing a product that should be included. Leave inference as default.
- You will normally have three main entitlements in an ETLA - All Apps, Single Apps, and Acrobat DC - but your agreement may vary. You will not be directly entitling named single apps like Photoshop or Illustrator (see below).
- Note: because the integration won't bring over "Single App" as an assigned product, you won't normally have a software model automatically created. You'll need to manually create one as the parent, with the covered products captured as downgrade rights. (If this changes in future versions of the Adobe API and Single App is what comes over, that has additional implications that will need to be addressed)
- You will also want to make sure any additional versions, such as CC 2023, have appropriate downgrade right membership. I would always recommend a target parent product and maintaining all possible downgrades as a master list in that parent. This prevents issues with daisy-chained downgrade rights and can carry the downgrade rights over to your entitlement automatically.
- When loading entitlements, simply specify the software model instead of using a PPN.
- ALWAYS ALLOCATE, even with the direct integration enabled. Conduct monthly reconciles to ensure you have the correct products allocated to the end users, or (better) use the allocation process in the Procurement app in ServiceNow to always have the right product allocated. If there are changes to assignments between single apps, make sure you reconcile those changes in ServiceNow to be as accurate as possible. You are allocating to the entitlement, which will be the Single App or All Apps entitlement. The downgrade rights will help with the compliance to the entitlement.
- Adjust for install discrepancies and always use reclamation rules where possible, even if you are not actually reclaiming using ServiceNow's remote management in the direct integration. This will give you usage data that the portal won't give you (sure, it's assigned and installed, but is it used?), assuming you are using SCCM, JAMF, or the ServiceNow MID server agent (this doesn't work agentless). Adobe will always require both the cloud integration and install monitoring to have a fully working asset management platform for that publisher.
This can be attributed to other SaaS applications, but Adobe's unique Single App approach to licensing their unbundled applications can be a headache in tools like ServiceNow. Reach out on LinkedIn if you want to talk about it. I'm always up to help out the community where I can.