AppClarity user roles
Running your first Compliance License Summary
Viewing software install counts across all devices
Viewing product usage
Viewing product compliance
Viewing your effective license position
Creating a license entitlement
Creating and linking a maintenance entitlement
Creating an entitlement using a SKU
Creating an agreement entitlement
Importing entitlements from a folder
Managing compliance for user-based licenses
Calculating license demand
Excluding devices from License Demand Calculation using Management Groups
Reclaiming a product based on its usage
Stopping a reclaim policy
Viewing the software reclaim reports
Scheduling AppClarity reports
- AppClarity user roles
How SAM users use AppClarity to view software inventory and usage, handle software reclaim, manage entitlements and view effective license positions, compliance and calculate license demand.
In this section...
AppClarity supports Role Based Access Control (RBAC). RBAC allows a Tachyon Administrator to allocate specific AppClarity based roles to different users, thereby enabling access and actions to the screens those users need to carry out their roles. This avoids unwanted access being permitted to SAM team members outside of their role, ensuring data security and improving governance.
There are pre-defined roles with sets of permissions aimed at particular SAM user types. Tachyon Administrators can assign any of these AppClarity based roles to any AD domain user.
Typically you would install AppClarity using the the Tachyon installation account. This role has purposefully limited permissions, but is able to add new Tachyon users and assign roles to those users. So after installing AppClarity one of the first steps would be to add the AppClarity Administrator role to an existing or new Tachyon user and then continue with the verification steps to confirm that AppClarity has been successfully installed. Please refer to Verifying for more details.
After the AppClarity installation has been verified you would then have the ongoing task of identifying your SAM users adding them as Tachyon users and assigning their AppClarity roles to allow them to carry out their SAM duties.
AppClarity permissions are granted on a module level (for example, Entitlement, Reclaim or Compliance) and not at per screen level (such as Entitlement→Summary Report or Reclaim→Savings), for example:
- A Tachyon Administrator has a request for a Reclaim Viewer to only view the Entitlement→Summary Report
- The Tachyon Administrator assigns the role of Entitlement Administrator to the Reclaim Viewer.
- The Reclaim Viewer would be able to view all screens under Entitlement module, not just the requested screen, Entitlement→Summary Report.
The first time you start AppClarity it's advisable and helpful to start with viewing the License Summary for the situation where you have no entitlements defined in the selected compliance repository, refer to the Repositories page for more information.
This gives you an established baseline to work with, where you can see what AppClarity is reporting to you without involving entitlements. It also lets you get familiar with the way that the information gets into the License Summary for a particular compliance repository.
The AppClarity reports are fundamentally based on inventory provided by Tachyon. The inventory shows what software is installed on what devices. If you're a user interested in the software reclaimer aspects of AppClarity you can focus on the software you want to reclaim. Or, if you're a S AM user interested in license compliance you can focus on the software you want to be compliant on.
To view software install counts across all devices you utilize the Inventory by Product and by Device screens to focus on the software and devices you are interested in.
The inventory information retrieved by Inventory from sources such as Configuration Manager and Tachyon includes data on how often products are being used on particular devices. If you're a user interested in the software reclaimer aspects of AppClarity you can focus on reclaiming software based on its usage. There are two ways of viewing product usage in AppClarity:
- To view product usage information across all servers and workstations in your network switch to Inventory→SLA Inventory and then Inventory→ Product Usage to investigate the products you are interested in.
To view usage information for reclaimable software, i.e. software installed on workstations not on servers, switch to AppClarity→Reclaim→Usage Summary . By default, that page also contains a filter to show licensable products only, but you can remove that if you're interested in reclaiming any type of software on workstations.
The reclaimer does not work on server OS. From AppClarity 7.1 software reclaimer works for any device where Server OS does not contain "Server" (ie. only client OS) or Server OS is not NULL. Other types of device are removed from the reclaim reports.
You can view your compliance position, focusing on the products installed on your system. From here, you can also add entitlements for a specific product.
Before viewing the Compliance → License Summary, please ensure that License Demand reports for SQL Core, IBM PVU, Oracle Processor and RedHat Socket has been successfully refreshed for the Default Compliance repository.
AppClarity can take Inventory and combine that with your entitlements to show your current compliance position, or the license position. The compliance position shows the result of matching up your current installations with your currently defined entitlements so that you can tell whether your entitlements are deficient, sufficient or surplus to your installations.
In this example we will show how to use the License Summary and License Position pages to identify license deficits and how you can work to quickly implement the entitlements you need to change the deficits into surpluses. Before viewing License Summary, please ensure all License Demand reports have refreshed to get the correct numbers for complex metric based products.
Entitlements are key components for determining your compliance position, also known as the license position. The license entitlements you create are taken into account against the installations on your enterprise, you can then create various reports to show exactly what your effective license position is.
There are three types of entitlement you can create in AppClarity:
You may see when you create an entitlement that there is a fourth type called Contract. Contracts are really just placeholders for documentary evidence of ownership and may be associated with any of the three types of entitlement. In our example we show how a contract can be associated with a license.
By combining these types you can model a wide range of complex entitlements that you may have in your enterprise, allowing these to convert easily into AppClarity.
It is generally a good idea if the license, maintenance and agreement entitlements you create have at least one associated contract. It's not mandatory, but it makes sense if the entitlements you create have proof that you own the particular license, maintenance or agreement. For example the contract may contain an enterprise agreement, a scan of a proof of purchase, a .PDF of an order or a paid purchase order. You create the contract and link to or load the associated proof into it. After saving, it may then be linked to the license, maintenance or agreement you want it associated with. Subsequently, when auditing your licenses AppClarity holds the proof of ownership linked to the entitlements that cover your installations.
A Maintenance entitlement type in AppClarity specifies the rights and limitations for an organization to install and/or use updated versions of software defined in a license. For example you could specify a maintenance entitlement for Microsoft Visio 2016 to cover all new versions from the current date for the next 3 years.
A maintenance entitlement can be linked as a child of an agreement, a license or another maintenance entitlement. Maintenance entitlements can also have other child maintenance entitlements. As with all the entitlements, maintenance can also have one or more associated contracts.
Stock Keeping Unit (SKU) codes can be used in some cases to help quickly fill out the details for an entitlement, they can even automatically create and link additional entitlements to model associated maintenance details. AppClarity will retrieve the information for a SKU from 1E Catalog.
A SKU (pronounced 'skue') is an identification, usually alphanumeric, of a particular product that allows it to be tracked for inventory purposes. In AppClarity, via the 1E Catalog, a SKU is associated with the license metrics and use rights associated with a particular software product purchase.
SKUs are in widespread use throughout the software industry, where publishers refer to their software using a SKU. The SKU gets added to most purchase orders to indicate the software or package being bought. Even small differences between two software titles are indicated by different SKUs. The SKU also indicates the license metrics and maintenance terms associated with the purchase and any additional use rights covered by the purchased license.
AppClarity uses the SKU data to automatically:
- Prefill the settings in an entitlement with the product details, license metrics, and basic maintenance terms that are indicated by the SKU
- Set the additional use rights that are part of the license indicated by the SKU
Agreement entitlements provide a way of grouping and organizing entitlements together to model the agreement structures in place between your organization and a vendor of a specific software title. Agreements can act as containers for license, maintenance, and even other agreement entitlements.
Large organizations may have thousands of entitlements to arrange. For AppClarity to report on your effective license position these need to be defined in AppClarity. To help get your entitlements in place, quickly and effectively AppClarity enables you to import directly from a particular folder. This means you can construct your TSV files as needed, place them in the folder and then import.
After importing the entitlements into AppClarity they are marked as Draft Entitlements. It gives you a chance to view any issues that arose as a result of the import process, and when that's done you can publish all of these entitlements in one go.
You can view your compliance position by focusing on how licenses are consumed by user as well as by device. From here you can also add entitlements for a specific product.
You may want to find out the quantity of licenses you would need to purchase or submit into AppClarity in order to make your product compliant. App Clarity provides license demand calculation reports that perform complex licensing calculations to find out what your ideal licensing position should be.
The complex server licensing covers four major reports of different vendors, for the most used and most expensive forms of licensing that occur in customer environments:
- Microsoft Core License Demand
- IBM Processor Value Unit (PVU) License Demand
- Oracle Processor License Demand
- Red Hat Socket Demand.
To view and refresh these reports the logged-in user must have any of the user roles:
|License Demand Calculation Report (LDC) page||Role|
|View a License Demand Calculation (LDC) pages ||Global Administrator|
|Refresh a License Demand Calculation (LDC) Report||Global Administrator|
Refer to AppClarity user roles for more information about Role Based Access Controls (RBAC) in AppClarity. In future versions of AppClarity we plan to extend the number of vendors and products available. This example focuses on the Microsoft Core License Demand report.
It may be required to exclude some groups of machines from LDC or Compliance reporting, as these may be for developer's devices for which an exemption is permitted and therefore the software on those devices should not be considered in the count of licenses. In AppClarity 7.1 this exemption is carried out by adding the machines to a Management Group. The naming convention of the Management group is very specific and care should be taken when creating it, the name is of the format:
- License Exemption OR
- License Exemption - Vendor name OR
- License Exemption - Vendor name "Identifier for Management group"
Each of these has a specific function the first will exclude all software for the machines in the group from the LDC and Compliance, the others will exclude all software for the specified vendor from the LDC and Compliance.
For the same vendor, two separate management groups could be created as below, and devices falling in either management group would exempt them for SQL Server installations from the Microsoft Core LDC, and in the Compliance Reporting, all installations where the Vendor is Microsoft Corporation will be excluded from the device (this would include, SQL Server, Office 365, Visual Studio etc).
- License Exemption - Microsoft Corporation
- License Exemption - Microsoft Corporation "for MSDN licenses".
Take care when naming Management groups, as any misspelling of the License Exemption, the Vendor or inappropriate spacing will result in the exemption of installations not being applied.
Remember that when being audited for Compliance you may have to prove that you are entitled to exempt machines from Licensing.
Inventory fetches information from its data sources to return details of how products are being used, wherever available. Reclaim Administrators who are interested in reclaiming unused software in order to recycle licenses can use this information to set their reclaim policies.
- Evaluating a reclaim policy without affecting your environment
If you're planning on setting up a reclaim policy want to be sure what the impact will be, (i.e. on impacted devices, where software is no longer installed and reclaimed), can evaluate your policy before setting it up. By using Reclaim Evaluate you can identify devices where software would be:
- Marked for Mandatory Uninstall (i.e. will be removed in upcoming mandatory reclaim cycle)
- Marked for Optional Uninstall.
If, after you evaluate the policy and you're comfortable with the impacted devices, you can setup the policy the same reclaim actions.
- Reclaiming a product using SCCM Uninstall
You can reclaim any software from your environment using either of these methods:
- Traditional reclaim - the reclaimer included with earlier versions of AppClarity
- SCCM custom Reclaim - which uses existing SCCM packages/applications added to any install collections
Using 1E SCCM Reclaim creates an uninstall collection you can use to reclaim software using your SCCM installation.
To use SCCM custom Reclaim, your administrator must have enabled the SCCM Uninstall Provider.
SAM users (AppClarity Administrator, Reclaim Administrator) who have defined reclaim policies may want to stop those policies from being applied. There are many reasons why this may be required, but here are some reasons:
- A published policy needs to be temporarily stopped.
- A published policy needs revision.
- The policy is no longer needed or the policy was created accidentally or was used as part of a test.
- There's an emergency, policies are not working as expected and need to be stopped to prevent any further consequences.
SAM users interested in software reclaim would like to view summary/history information of software reclaim (i.e. successful, failed, in progress, opt out) in order to:
- Verify a software reclaim policy is working as expected
- Check the progress of a reclaim policy
- Audit the software reclaims
- Evaluate how effectively AppClarity saves money on licenses.
To do this the user checks the Software Reclaim Summary page.
When an entitlement repository or compliance repository is created, and e.g. reclaim consolidation is run for an compliance repository, then it creates a default reclaim consolidation schedule for this compliance repository, to run on daily basis. You can also create schedules for the repositories you create and schedule them to run at a frequency of your choice.