EducationSoftwareStrategy.com
StrategyCommunity

Knowledge Base

Product

Community

Knowledge Base

TopicsBrowse ArticlesDeveloper Zone

Product

Download SoftwareProduct DocumentationSecurity Hub

Education

Tutorial VideosSolution GalleryEducation courses

Community

GuidelinesGrandmastersEvents
x_social-icon_white.svglinkedin_social-icon_white.svg
Strategy logoCommunity

© Strategy Inc. All Rights Reserved.

LegalTerms of UsePrivacy Policy
  1. Home
  2. Topics

Manual Compliance Auditing for Mixed Named User CPU Licenses in MicroStrategy 2019 Update 2


Andrew Geyster

Principal Product Specialist • MicroStrategy


This article provides general steps for manually checking compliance of a mixed deployment to assist MicroStrategy Administrators in maintaining their environments.

Starting with the release of Strategy ONE (March 2024), dossiers are also known as dashboards.
With the release of Strategy 2019, customers have informed us about incorrect Out of Compliance messages appearing in their environments. After some investigation it was discovered that this issue is related to users have both a Named User and CPU License Key for the same Intelligence Server cluster. This is referred to as a Mixed Named User CPU License Key. 
By default, License Manager automatically performs compliance checks and provides feedback to System Administrators regarding compliance status. To eliminate these false-positive messages from appearing, the issue has been temporarily suppressed starting with the release of 2019 Update 2. This release helps with Mixed Named User CPU deployments while overall system improvements are being worked on by the Technology team. 
If you have any questions about these changes or need assistance manually checking compliance, please reach out to your Account Executive. 

Environment Configuration


Deploying an environment that uses both a CPU and Named User License within a clustered Intelligence Server deployment varies from situation to situation. The most common method to set up the environment is with User Fencing to dictate the Named User License profiles to a single node, and then having the CPU license for the remaining unfenced users.
This method restricts the higher functionality or priority users to a system that can utilize all the available hardware. The bulk of users would share the hardware limited machines.
To run a Manual Compliance Check, the easiest method of setting this up is to have a single user group that contains all of the users who will be fenced to the Named User licensed Intelligence Server node. This allows for quick identification of fenced users and a faster analysis of the Named User compliance. 

Steps for Checking License Compliance Manually 


This process is broken down into a Named User Check and a CPU check. 

Named User Check

  • To begin checking the Named User compliance portion of a Mixed Named User CPU deployment is to determine the users who are currently relegated to that Intelligence Server node. Within Command Manager, the following scripts can be utilized to get the user and user group fencing:
ka0PW0000001JXVYA2_0EM2R000000hTFD.jpeg
    • LIST ALL FENCES;
    • LIST ALL PROPERTIES FOR FENCE "<user-fence>";
  • Once the list of all users and user groups that are fenced to the given Named User Intelligence Server, an Audit Report can be generated through License Manager:
ka0PW0000001JXVYA2_0EM2R000000hTFI.jpeg
    • If a single, specific User Group holds the fence configuration then that group can be selected from the Project Source/Data Source options, otherwise select the Everyone group.
    • If LDAP is utilized, also select the Include LDAP users for Auditing option.
  • After executing the Audit option, the Report option can be selected to generate a set of three License Manager files that contain Named User information. For manual audits, you'll need the .csv file generated. 
    Within the file, there will be a block which is referred to as Auditing Details that has below it the Project Source and a list of Enabled Users with their License Types.

ka0PW0000001JXVYA2_0EM2R000000hTFN.jpeg
  • Select the row that contains License Type and Enabled Users (include everything down to the last row of this block). This entire section can then be copied into a new Excel file and saved. 
  • Load the file into a MicroStratey deployment through the Add External Data functionality in Platform Web. No data preparation must be done at this point. 
  • Publish your dataset as an Intelligent cube.
  • Create a dossier based off of the cube and create one derived metric. 
ka0PW0000001JXVYA2_0EM2R000000hTFO.jpeg
  • You can run the dossier as is if the fenced users exist with a single user group so that it can run the Audit Report against the user group. However, if the Everyone user group had to be used then a filter must first be added. 
    The filter can be created at either the Chapter Level or the Visualization level, and there should be a qualification for Enabled users In List, where every user who was identified through Command Manager scripts is selected.

ka0PW0000001JXVYA2_0EM2R000000hTFX.jpeg
  • Once the filter is applied, the License Type attribute and # Fenced Users Derived Metric can be placed on the grid to provide the current Named User Licenses that are fenced to this Intelligence Server node. 

CPU Check


To check the CPU compliance within an mixed deployment, it's possible to use either Service Manager if a GUI is available or by checking the MSIReg.reg. 
The CPU compliance of an environment is based on the total number of processors utilized by Strategy Secure Enterprise for the same DSI and Key Group. What this means is that for a Mixed Named User CPU deployment, each Intelligence Server using the CPU portion of this license within the same subnet of processors must be aggregated. 

  • The number of currently active CPUs for any given Intelligence Server is easiest to determine through Service Manager. The Intelligence Server machine can be selected, with the Service as Strategy Intelligence Server.
  • At this point, the Option button in the bottom right will open a new panel. With the panel, the Intelligence Server Options section contains the currently configured processor affinity used to check compliance. 
ka0PW0000001JXVYA2_0EM2R000000hTFh.jpeg
  • This can be verified for each Intelligence Server node that has the CPU license, and if the total number of selected processors is below the licensed number. At this point the environment is in compliance. 


If a GUI is not available, this same information can be found within the MSIReg.reg for each CPU Intelligence Server. Thee key that holds this detail is: 

[HKEY_LOCAL_MACHINE\SOFTWARE\Strategy\DSS Server\Castor]. 
This has the bitmask function ProcessAffinity. 

ka0PW0000001JXVYA2_0EM2R000000hTFm.jpeg

The mask is designated as p followed by any number of 0s or 1s. For each 1 that is present inside of the mask, it's a processor selected for affinity and for each 0 it is a restricted processor. The mask does not necessarily have to have a number of digits equal to the total number of processors on the Intelligence Server. If it has less, then it will begin counting from processor 0 and go from there.   
When doing a Manual Compliance Audit, if you find during any step that the environment appears to be Out of Compliance of if there are questions raised during the procedure, please reach out to your Account Team. They will be able to assist in assuring that the audit is done correctly. 


Comment

0 comments

Details

Knowledge Article

Published:

July 2, 2019

Last Updated:

March 21, 2024