The VS License Manager's usage privileges can be configured by editing and saving the ServerConfig.json file. This includes allowing, denying, restricting, and reserving checkout and borrowing of features for specific users. Restart the VS License Manager for the changes to take effect.
When to use which privilege rule?
▪If you want most of your users to be able to use all features and only a few to be restricted, use Deny Rules.
▪If you want to allow a few privileged users to use certain features and restrict most of your users, use Allow Rules.
▪If you want to control the number of features available to different user groups, use Limit Rules and Reserve Rules.
How to specify users?
In each rule, users can be specified as usernames, host names, or IP addresses (IPv4 or IPv6, see setting IP_VERSION) and must be separated by a semicolon:
"USERS": "UserOne;UserTwo;UserThree;..."
|
If the list becomes large, or if the same list is used in multiple privilege rules, it is useful to define GROUPS at the end of the configuration file. The format for MEMBERS is the same as for USERS. Curly braces {...} define a group within the group list [...], separated by commas.
"GROUPS": [
{
"NAME": "Group 1",
"MEMBERS": "UserOne;UserTwo;UserThree;...;UserN"
},
{
"NAME": "Group 2",
"MEMBERS": "Host01;Host02;Host03;...;HostX"
}
]
|
You can now specify users as follows:
"USERS": "Group 1;Group 2"
|
Linking a group within a group is supported.
Note:
▪When restricting many host names or IP addresses, you can use wildcards like "4.3.2.*" or "PC*" or IP ranges such as "4.3.2.10-50". Usage examples can be found below.
▪On Windows, you can use your local groups. If you have a local group "My Users" that contains a list of domain users or a domain user group, you can use it like a user or group name in the configuration file by simply prefixing it with '&': "USERS" : "&My Users". Usage examples can be found below.
▪The default ServerConfig.json contains two empty presets per rule, which can be edited or removed and are ignored by the VS License Manager.
Important syntax rules:
▪The server configuration file uses standard JSON syntax.
▪Square brackets [...] define the list of privilege rules for a privilege setting, separated by commas.
▪Curly braces {...} define a single privilege rule, separated by commas.
▪Multiple key-value pairs within a privilege rule must also be separated by commas.
▪All users, features, and serial numbers must be separated by a semicolon.
▪You can use the following examples as templates.
Allow Rules
The ALLOW_CHECKOUTS and ALLOW_BORROWS allow rules restrict the use of features to all but the specified users. So if you have privileged users, use these settings. They consist of the following keywords:
▪USERS: required, list of usernames or host names, IP addresses or group names ▪FEATURES: optional, list of the features to be restricted ▪SERIALNUMBERS: optional, the affected licenses / serial numbers (only needed if using multiple licenses on one VS License Manager) ▪COMMENT: optional, use it to add comments or explanations to a rule (will be ignored during parsing) Note: The optional FEATURES and SERIALNUMBERS keywords can be removed, left blank, or set to '*' if not used. The rule will then apply to all FEATURES / SERIALNUMBERS loaded by the VS License Manager.
Examples
A rule that allows functionality features only for selected users would look like this:
"ALLOW_CHECKOUTS": [
{
"FEATURES": "FUNCTIONALITY_ADVANCED_ANALYSIS;FUNCTIONALITY_TECHDOC",
"USERS": "Some user; Some other user; Another user"
}
],
|
Allowing borrowing of EXPORT_ALL only for the MEMBERS defined in a GROUP with the NAME "Borrow Users" would look like this:
"ALLOW_BORROWS": [
{
"FEATURES": "EXPORT_ALL",
"USERS": "Borrow Users"
}
],
...
"GROUPS" : [
{
"NAME": "Borrow Users",
"MEMBERS": "Some user; Some other user; Another user"
}
]
|
The same rule, but restricting the borrowing of all features for all users except the members of the defined group:
"ALLOW_BORROWS": [
{
"USERS": "Borrow Users"
}
],
|
Multiple allow rules are separated by a commas:
"ALLOW_CHECKOUTS": [
{
"FEATURES": "FUNCTIONALITY_ADVANCED_ANALYSIS;FUNCTIONALITY_TECHDOC",
"USERS": "Functionality Users"
},
{
"FEATURES": "KAS",
"USERS": "KAS Users"
}
],
|
Allowing a feature only for a specific windows user group using the prefix & would look like this:
"ALLOW_CHECKOUTS": [
{
"FEATURES": "EXPORT_ALL",
"USERS": "&WindowsGroup"
}
],
|
Allowing a feature for a specific hostname pattern would look like the following. This would allow all PC's with names like PC001 and PC456 or WS12CAD and WS34CAD.
"ALLOW_CHECKOUTS": [
{
"FEATURES": "EXPORT_ALL",
"USERS": "PC*;WS*CAD"
}
],
|
Allowing one of the multiple licenses only for a specific IP domain would look like this:
"ALLOW_CHECKOUTS": [
{
"SERIALNUMBERS": "2024-0101-123456",
"USERS": "4.3.2.*"
}
],
|
Allowing a license only for a specific IP range would look like this:
"ALLOW_CHECKOUTS": [
{
"COMMENT": "A specific IP range",
"USERS": "4.3.2.10-50"
}
],
|
|
Deny Rules
The DENY_CHECKOUTS and DENY_BORROWS deny rules restrict the use of features to the specified users, so most users will still be able to use them. The syntax and keywords are the same as for allow rules.
Examples
A rule that denies features to selected users would look like this:
"DENY_CHECKOUTS": [
{
"FEATURES": "FUNCTIONALITY_ADVANCED_ANALYSIS;FUNCTIONALITY_TECHDOC",
"USERS": "Some user; Some other user; Another user"
}
],
|
A rule that denies the borrowing of EXPORT_ALL for the MEMBERS defined in a GROUP with the NAME "Borrowing denied" would look like this:
"DENY_BORROWS": [
{
"FEATURES": "EXPORT_ALL",
"USERS": "Borrow denied"
}
],
...
"GROUPS" : [
{
"NAME": "Borrow denied",
"MEMBERS": "Some user; Some other user; Another user"
}
]
|
To disable borrowing of a feature for all users, set USERS to '*' or remove the value entirely:
"DENY_BORROWS": [
{
"FEATURES": "EXPORT_ALL"
}
],
|
Note:
▪At the same time, checkout rules also restrict borrowing actions, but borrowing rules do not affect checkout actions. ▪Deny rules override all allow rules. If a user is listed in both an allow rule and a deny rule for the same license and feature, the deny rule is applied and the allow rule is ignored. |
Limit Rules
The LIMIT_CHECKOUT and LIMIT_BORROW limit rules are useful for controlling the number of features that should be available to different user groups. They are also used to limit the borrowing duration of features. Their syntax is based on the allow and deny rules, with additional keywords:
▪COUNT: The number of features that should be available to the specified USERS. ▪EXCEPT_USERS: It is possible to add exceptions to a limit rule. So if you have privileged users within a larger group that you want to restrict, add them here. Only for LIMIT_BORROW:
▪HOURS: The maximum number of hours the specified features can be borrowed. ▪USERS can be optional for this rule type. If it is removed or left blank, the borrowing limit is applied to all users. Examples
Restrict the use of a feature within a group of users:
"LIMIT_CHECKOUTS": [
{
"FEATURES": "IMPORT_ALL",
"USERS": "User 1;User 2; User 3;...;User 30",
"COUNT": 15
}
],
|
Restrict the borrowing period of any feature to one week for all users, except for a privileged user who is allowed to borrow for three months. This is accomplished by first increasing the default value to three months, and then restricting all users except the privileged user:
"LIMIT_BORROWS": [
{
"HOURS": 2160
},
{
"EXCEPT_USERS": "Privileged User",
"HOURS": 168
}
],
|
|
Reserve Rules
The reserve rule RESERVE_CHECKOUTS, unlike the limit rules, can be used to ensure that a certain number of features are always available to certain users. The syntax is the same as for allow rules, with the addition of the COUNT keyword.
Examples
Reserve a feature for three privileged hosts:
"RESERVE_CHECKOUTS": [
{
"FEATURES": "IMPORT_2D_ADVANCED",
"USERS": "HostX;HostY;HostZ",
"COUNT": 3
}
],
|
|
