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.

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:

1. 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.

2. 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.

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:

• Licenses
• Maintenance
• Agreement.

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.

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:

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".
  

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.

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:

1. A published policy needs to be temporarily stopped.
2. A published policy needs revision.
3. The policy is no longer needed or the policy was created accidentally or was used as part of a test.
4. 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.