Honeywell Software

License Management
Unified License Manager (ULM)

Server Tools Guide

Copyright
April 2015

The information in this file is subject to change over time. Honeywell may make changes to
the requirements described. Future revisions will incorporate changes, including corrections
of typographical errors and technical inaccuracies.

For further information please contact

Honeywell
130 Dufferin Ave.
London, Ontario
N6A 5R2
Telephone: (519) 679-6570
Facsimile: (519) 679-3977

Copyright Honeywell 2015 All rights reserved.

Prepared in Canada.
 Table of Contents
1 Administrator Console .......................................... 1-1
1.1 Introduction .................................................... 1-2
1.2 Getting Started ................................................ 1-2
1.3 What Can Administrator Console be used for? ...... 1-2
1.4 The Current Users Tab ...................................... 1-4
1.5 Disconnecting Users from ULM ........................... 1-5
1.6 Installed Licenses ............................................. 1-6
1.7 Alerts Tab ....................................................... 1-7

2 Usage Monitor ...................................................... 2-1

2.1 Introduction .................................................... 2-2
2.2 Getting Started ................................................ 2-2
2.3 What is the Usage Monitor Used For? .................. 2-2
2.4 Viewing Logs ................................................... 2-3
2.5 Analyzing Logged Data...................................... 2-4
2.6 Stitched Log .................................................... 2-5
2.7 Reporting from the Usage Monitor ...................... 2-6
2.8 Scripting ......................................................... 2-6

3 Access Control Configuration................................ 3-1

3.1 Summary ........................................................ 3-2
3.2 Server Settings - AccessControl.xml ................... 3-2
3.3 General Syntax ................................................ 3-3
3.4 Machine/User Definition .................................... 3-4
3.5 Machine Definition ............................................ 3-4
3.6 Group Definition............................................... 3-6
3.7 Precedence, Inheritance and Implicit access ........ 3-8
3.8 ‘By Exception’ Partial Wildcards ........................ 3-12
3.9 Limiting access to the Admin Console Tool ......... 3-14
3.10 AccessControl.xml file encoding standard .......... 3-14
3.11 Troubleshooting ............................................. 3-14

1
2
 Administrator Console 1-1

1 Administrator Console

1.1 Introduction .................................................................................. 2

1.2 Getting Started .............................................................................. 2

1.3 What Can Administrator Console be used for? ............................... 2

1.3.1 Server Properties Tab ............................................................... 3

1.4 The Current Users Tab ................................................................... 4

1.5 Disconnecting Users from ULM ...................................................... 5

1.5.1 Forcibly Disconnecting Users...................................................... 5

1.6 Installed Licenses.......................................................................... 6

1.6.1 Admin Limit Column ................................................................. 6

1.7 Alerts Tab ...................................................................................... 7

1.7.1 Mail Setup for Alerts................................................................. 7
1.7.2 Types of Alerts and Frequency ................................................... 8
1.7.3 Alert Triggers and Resulting Email .............................................. 9

1-1
1-2 Introduction

1.1 Introduction
The ULM offers two license administrator tools available from the ULM
Config Wizard, Server Tools page:
• Administrator Console (Admin Console)
• Limiting access to the Admin Console Tool
• Usage Monitor

The Administrator Console is designed to enable license administrators

to manage the users of licenses on a live basis. Usage Monitor allows
the license administrator to analyze past license usage, which can be
useful for department usage billing or to determine the need for
additional or alternate licenses. For more information on limiting
access to users of this tool refer to Limiting access to the Admin
Console Tool.

1.2 Getting Started

Prior to installation, a word of caution - Administrator Console should
NOT be installed on every user's workstation. Administrator Console
has powerful capabilities prudently reserved for license administrators.
Typically, it would be installed on one or two machines with limited
access.

Note it is not required that Admin Console resides on the

Server machine in order for the license administrator to use
it.

To install Admin Console run the setup.exe found in the ULM Admin
Tools folder on the installation media.

Once installed the Server Tools can be accessed via:

Start > All Programs > Honeywell > ULM Admin Tools > Admin Console

1.3 What Can Administrator

Console be used for?
Administrator Console is a tool for ULM license administration. It has
the capability to:
• Set maximum commute time/users

1-2
 Administrator Console 1-3

• Monitor feature usage across the organization, or on an

individual user basis
• Disconnect specific users from the ULM

1.3.1 Server Properties Tab

Server properties are configured, and messages viewed for a given
server on the Server Properties tab.

Figure 1.1

Begin by entering the server name in the Server field - you are now
ready to configure properties for that server. Commute Limits (days/
users), Forced Disconnect Timeout and Reporting Interval are available,
configurable fields for the server.

Commute Limit (days) allows the license administrator to set the

maximum allowable time limit in consecutive days that users will
commute license options from the server. Admin Console allows the
license administrator to select a commute limit between 0 and 90 days.

Commute Limit (users) allows the license administrator to set the

maximum number of users of any license once commuted from the
server. Any value between 1 and unlimited concurrent users is
allowed. Clearing the Commute Limit (users) field, by pressing
Delete, will set it to [unlimited]. Note that all commuted licenses are
themselves network licenses and a computer with a commuted license
can act as a license server. Please refer to the ULM Licensing Guide
for further details on commuting licenses.

1-3
1-4 The Current Users Tab

Forced Disconnect Timeout (minutes) allows the license administrator

to specify the time in minutes before a forcibly disconnected user can
log back in to the server. Admin Console allows the license
administrator to select a timeout period between 1 and 60 minutes.

If a Reporting Interval (hh:mm:ss) is set, a list of all active licenses will

be written to the ActiveLicenses.XML file in the SimStation folder
(C:\Program Files\Common Files\Honeywell\SimStation) on that
interval. User limit exceeded failure alerts will also be written to this
file. Note that clearing the Reporting Interval, by pressing Delete, will
set it to the status of [disabled], and no reports get written.

The Server Messages window displays such server messages as ULM

status, user limit exceeded, and forcibly disconnected users. Clicking
the Refresh button updates all the information reported about the
server.

1.4 The Current Users Tab

Current users, the respective licenses they are using and how many
licenses they have outstanding, are displayed in the Current Users tab.

Figure 1.2

1-4
 Administrator Console 1-5

1.5 Disconnecting Users from

ULM
Disconnecting users from the server is done on the Current Users tab.
Simply select a specific user from the Current Users list and click on the
Disconnect Selected User button to force the return of their
license(s) to the pool.

Note that once a user is disconnected by the license

administrator, they will not be able to re-acquire a license
until the Force Disconnect Timeout period has passed.

Figure 1.3

1.5.1 Forcibly Disconnecting Users

Forcibly disconnecting users from the ULM is useful in cases where the
quantity of licenses for specific features is very tight and demand is
high. As an example, consider the following scenario:

ABCServer has 3 licenses available (for 3 concurrent users) between

their day and night shifts. At the conclusion of the day shift, users are
required to close their program thereby releasing their licenses for the
night users. In the event that any of the day users neglects to close the
program, the license administrator can forcibly disconnect them
releasing the license for the night user(s). Consequently, the

1-5
1-6 Installed Licenses

Administrator Console can give an indication that licenses are being

maxed out and therefore additional licenses may need to be purchased
if the current ULM is consistently not meeting usage demand.

1.6 Installed Licenses

All license options available on a given server are displayed on the
Installed Licenses tab.

Figure 1.4

1.6.1 Admin Limit Column

The Admin Limit column allows the administrator to reduce the
effective usage limit on any license on the server below that configured
Note: Not all ULM users
by Honeywell in the license file (as shown in the Usage Limit column).
use the Token system.
The Admin Limit is of particular use in a Token system where otherwise
high user usage of a specific feature can mean insufficient tokens
remain for other features.

1-6
 Administrator Console 1-7

1.6.2 Install a License File Button

The Install a license file... button allows the license administrator to
remotely install a .ULMLicense file onto the server. The Install a License
File button is most useful when the license file is local and the server is
remote. Click the Install a license file..and browse to the location of the
*.ULMLicense file.

1.7 Alerts Tab

Alerts pertinent to exceeded user limits can be configured/added on the
Alerts tab. Alerts provide the license administrator with an email
message notifying them of any user failures to access the server due to
lack of available licenses.

To add an alert click the Add Alert button, enter a valid email address
and check Enable Alerts. Optionally, Start and End times may be
specified in the definition of an alert. License failures outside those
times will not trigger an alert. Note that Start and End times are not
required in order to configure an alert. The next time there is a license
failure due to the user limit being exceeded the license administrator
will be notified via email. A valid mail profile needs to be configured the
first time alerts are used by clicking the Setup e-mail for server…
button.

1.7.1 Mail Setup for Alerts

Mail can be configured to use MAPI or SMTP (with or without SSL).
Select the type of mail server from the dropdown.
• MAPI: Mail Profile and Mail Password are required as a
minimum in order to login into a mail client on the system
account. A more likely setup is to have an email client running
on a user account on the same machine. To avoid having to
install an email client on the system account, enter the login
credentials for the user account (User Name, User Domain and
Password).
• SMTP: The SMTP Server must be entered. Some servers require
a SMTP Port to be entered and some require use of SSL (check
with your mail server administrator). As a convenience,
choosing smtp.gmail.com will automatically select port 465 and
the SLL option. Most SMTP servers also require authentication
via a logon name (i.e. gmail name without @gmail.com) and

1-7
1-8 Alerts Tab

password so enter these here. And finally, enter a sender email

address (i.e. [email protected]) and optionally enter a
sender name for display purposes (i.e. John Smith).

Note: Test that the email has been configured property by

using the testing optin the Setup e-mail window.

Once an email has been successfully sent, the Setup e-mail dialog can
be closed and all settings will be remembered.

Figure 1.5

1.7.2 Types of Alerts and

Frequency
Four kinds of Alerts can be generated.
• Usage Limits Exceeded
• Usage Alert Limits Exceeded
• Licenses Expire within (30, 60 or 90) days
• Commuted License requested or returned.

The ULM Server Admin Console will automatically check for the need to
send "Usage Limits Exceeded" and "Commuted License" alert emails on
the same interval as the report generation - recall that the Reporting
Interval can be set on the Server Properties tab. All other alerts are
checked for and sent once daily or when Server is restarted.

1-8
 Administrator Console 1-9

The Admin Console will not allow disabling of the Reporting Interval
while alerts are enabled. If the Reporting Interval is disabled, and then
alerts are enabled, Admin Console will automatically set the interval to
5 minutes so that alerts get reported.

1.7.3 Alert Triggers and Resulting

Email
The Usage Limits ExceededThe ULM alert will be triggered if any
requests for licenses were rejected due to over usage since the last
reporting interval. The resulting email details the license failure in the
attachment ActiveLicenses.XML file, and states the following general
message in the body of the email:

Requests for these license(s) have failed due to exceeded user limits:
HoneywellProgram.Process

The Usage Alert Limits Exceeded alert only applies to licenses that have
an Alert Limit configured (see the Installed Licenses page). Note
that the Alert Limit will default to the Soft Limit if one has been
configured by Honeywell. The alert will be triggered once daily if any
license usage exceeds the configured Alert Limit over the previous day
(within the Start and End times if configured). The resulting email has
an attachment of each license file involved and details the high license
usage with the following message in the body of the email:

On license server:
<Server Machine Name> (Server IP address)

The following licenses have exceeded usage alert limits by the number
of users shown.
• ACME.aaa (2)
• ACME.bbb (1)

The Licenses Expire Within set of alerts can be configured for a 30, 60
or 90 day check into the future. Note that for these alerts the Start and
End times cannot be entered and are ignored. Soon to expire licenses
will checked for once daily and an alert is only triggered once for the
chosen time frame (although a server restart can cause these alerts to
be sent again). The resulting email has an attachment of each license
file involved and details the soon to expire licenses with the following
message in the body of the email:

On license server:
<Server Machine Name> (Server IP address)

1-9
1-10 Alerts Tab

The following licenses have expired on the dates shown.

01/23/2010 (expired):
ACME.aaa

The following licenses are active and will expire on the dates
shown.

05/27/2011:
ACME.bbb (valid for another 10 days)

The Commute License - Requested/Returned alerts will be

generated for each commuted or returned license. Multiple
licenses commuted to the same machine will result in a single
alert with all the licenses listed. These alerts will be tallied and
sent on the same Reporting Interval as for other alerts. Note
that the alert regarding requested licenses will be sent earlier if
a commuted license is returned before the Reporting Interval
has elapsed. This ensures a logical sequence of alert emails that
properly represent the currently commuted licenses. The
resulting email with have the following example message body:

On license server:
<Server Machine Name> (Server IP address)

The following licenses:

ACME.aaa (7 days and 1 user)
ACME.bbb (7 days and 2 users)

have been commuted to machine:

<Client Machine Name>

by user:
<User Name>

1-10
 Usage Monitor 2-1

2 Usage Monitor

2.1 Introduction .................................................................................. 2

2.2 Getting Started .............................................................................. 2

2.3 What is the Usage Monitor Used For? ............................................ 2

2.4 Viewing Logs ................................................................................. 3

2.4.1 Sorting Logged Usage Data ....................................................... 3

2.5 Analyzing Logged Data .................................................................. 4

2.5.1 Usage Graph Tab...................................................................... 4
2.5.2 Usage Details Tab .................................................................... 4
2.5.3 User Usage Tab........................................................................ 5

2.6 Stitched Log................................................................................... 5

2.7 Reporting from the Usage Monitor................................................. 6

2.8 Scripting ........................................................................................ 6

2-1
2-2 Introduction

2.1 Introduction
The ULM offers two license administrator tools (ULM Admin Tools):
• Usage Monitor
Note: Admin Tools has
been renamed to Server • Administrator Console
Tools on the ULM Config • Limiting access to the Admin Console Tool
Wizard.
Admin Console is designed to enable license administrators to manage
the users of licenses on a live basis. Usage Monitor allows the license
administrator to analyze past license usage, which can be useful for
department usage billing or to determine the need for additional or
alternate licenses. For more information on limiting access to users of
this tool refer to Limiting access to the Admin Console Tool.

2.2 Getting Started

The Usage Monitor is installed by running AdminTools setup.exe found
in the ULM Admin Tools folder on the installation DVD. There is no
requirement to install the Admin Tools on the ULM server. Like the
Administrator Console, the Usage Monitor is intended to be used
primarily by administrators.

2.3 What is the Usage

Monitor Used For?
The Usage Monitor can be used to analyse the license usage.log files
created by a ULM network server. These logs contain a record of each
usage event on the server.

The Usage Monitor tool provides the following functions:

• Usage Log and Usage Graph - display the actual log file in text
format or a graph of usage, sorted by license options, license
buckets, machine or by individual user's accounts.
• Usage Details and User Usage - show a tabular view of usage by
license or user, sort data for usage peaks and determine the
time duration- each license was used for.
• Stitched Log - combine multiple log files together.
• Scripting and Reporting - play logged scripts of previous actions
e.g. to setup a report, and create printable reports.

2-2
 Usage Monitor 2-3

2.4 Viewing Logs

On opening the Usage Monitor, the current usage.log file is loaded from
the SimStation folder (typically C:\Program Files\Common
Files\Honeywell\SimStation) of the machine on which the ULM Admin
Tools is installed. Any other usage.log file can be loaded by pressing
Load Usage.

2.4.1 Sorting Logged Usage Data

By using the Preferred Licenses option all the usage information shown
within the tool can be filtered to show only certain licenses. To use this
option type the name(s) of the licenses to filter by in the Preferred
Licenses table and check the Apply Preferred Licenses? option. The
tool provides drop down lists to help identify license names. For
example start to type character "U" in the cell and the drop down
reveals all license features starting with "U". After the main name has
been entered continue typing with a period (.) and select the license
option from the list. Always press Refresh Log button after making
changes to these options.

Figure 2.1

Activating the Combine Buckets? option combines the licenses

contained in separate license buckets, so that the displayed usage data
does not distinguish which bucket the license originates from.

2-3
2-4 Analyzing Logged Data

2.5 Analyzing Logged Data

2.5.1 Usage Graph Tab
Click the Usage Graph to display the License usage. To re-scale the axes
either:
• Move the cursor over either axes so that a four-headed arrow
appears, then click and drag to move the axis
• Click and drag a rectangle to zoom in (right-click and choose
Note: The license list can Zoom All to zoom back out).
be filtered using the
Preferred License option. The license to display may be selected in the Licenses list.

Data may be filtered by four categories:

• UserName – directly filter for user account
• MachineName – every account of specific machine
• MachineName:UserName – user(s) account(s) on a specific
machine
• UserName (MachineName) – as above but drop down list is
sorted by user name instead of machine name.

The graph data is colour coded:

• Concurrent Usage – the actual combined usage of a license
option
• Usage Limit – the maximum number of licenses allowed;
normally a horizontal line
• Admin Limit – usage limit set by license administrator (in the
Admin Console)
• Soft Limit – An additional limit which may be configured by
Honeywell

2.5.2 Usage Details Tab

This shows a tabular view of the license usage (grouped by license)
over a defined date range along with details of peak usage, failures etc
This can be useful for department usage billing or to predict the future
license requirements.

The displayed date range may be configured using the Filter Date
Range options. The radio buttons at the top right control the time units
used to display the Usage above Soft Limit and Maxed out Duration
properties.

The data displayed, for the specified time period, is as follows:

• Peak Usage – the maximum concurrent usage of the option.

2-4
 Usage Monitor 2-5

• Usage above Soft Limit – the total length of time when the
usage was over the configured (by Honeywell) Soft Limit.
• Failures – the number of failures, click the “…” button see failure
dates/times .
• Maxed out Duration – the total length of time when the usage
was at the usage limit (i.e. at the maximum allowed number of
licenses).
• Maxed out Dates – the number of days on which the usage was
at the usage limit, click the “…” button to see the dates.

2.5.3 User Usage Tab

On this tab the total duration of usage of each license is displayed. The
controls at the top can be used to configure a date range and set
whether overall usage is reported ("Show Category" = <none>) or total
usage per user or machine ("Show Category" = UserName,
MachineName….) is displayed. The radio buttons at the top right define
the time units used.

2.6 Stitched Log

When multiple log files, originating from the same license server, are
loaded into the Usage Monitor the "Create Stitched Log" button can be
used to combine them into a single log.

Figure 2.2

2-5
2-6 Reporting from the Usage Monitor

2.7 Reporting from the Usage

Monitor
A text usage report can be printed using the Tools menu - Print
Report… option. Information on the report can come from either the
Note: Note that graphics
Preferred Licenses or All Licenses .
printing is not yet
supported.
Figure 2.3

Press Preview… to see the report. The report can be sent straight to a
printer (Print) or to a text file (Print to File)

2.8 Scripting
A script of all the actions taken (for example to generate a monthly
report) can be recorded (use Tools - Script - Record menu option) as a
text file with a "*.script" extension. Scripts can be replayed directly
from the Usage Monitor (Tools - Script - Play menu option) or from the
command line using the syntax /sx <script name> ("x" forces the
application to close after script hsa run).

Figure 2.4

2-6
 Access Control Configuration 3-1

3 Access Control
Configuration
3.1 Summary ....................................................................................... 2

3.2 Server Settings - AccessControl.xml .............................................. 2

3.2.1 Examples................................................................................ 2

3.3 General Syntax .............................................................................. 3

3.4 Machine/User Definition ................................................................ 4

3.5.1 User Definition......................................................................... 6

3.5 Machine Definition ......................................................................... 4

3.6 Group Definition ............................................................................ 6

3.6.1 Group Definition on Active Directory Systems .............................. 7

3.7 Precedence, Inheritance and Implicit access ................................ 8

3.8 ‘By Exception’ Partial Wildcards ...................................................12

3.9 Limiting access to the Admin Console Tool ...................................14

3.10 AccessControl.xml file encoding standard...................................14

3.11 Troubleshooting..........................................................................14

3-1
3-2 Summary

3.1 Summary
The Honeywell Software License Management system, Unified License
Manager (ULM) features an Access Control capability which allows
network licenses or license buckets to be restricted to certain users
(logging into certain network domains) and/or certain machines
(operating in certain network domains).

This chapter is a guide for server administrators configuring access

control.

Here the ULM Server is a machine running the ULM software, hosting
licenses which are accessible over the network to ULM client machines
which may be running software which is licensed using the ULM.

3.2 Server Settings -

AccessControl.xml
Access control is set on the ULM server by creating a text file named
AccessControl.xml and placing it in the ULM folder (C:\Program
Files\Common Files\Honeywell\SimStation). It is NOT necessary to
restart the ULM service (SimStation) after making changes to this file.

If there is an error when the access control file is read by the ULM a
message:
For a parsing error:
Message: Failed loading AccessControl.xml. <Specific reason
for parse failure>.

For other errors:

Message: Error in AccessControl.xml - <specific error
encountered>.

is shown in the Admin Console Server Messages window.

3.2.1 Examples
Listed below, in Example 1, is a very simple AccessControl.xml file
which illustrates the file structure.

Example 1
<?xml version="1.0" encoding="utf-8" ?>

3-2
 Access Control Configuration 3-3

<AccessControl>
<License name="ACME.aaa" access="*@*.tudor.com"/>
<License name="ACME.ddd" deny="[email protected]"/>
</AccessControl>

Here User Principle Name (UPN) user names are used, with wildcards,
as well as the access and deny keywords. This access control file
means that any user who matches the UPN *@*.tudor.com, where *
can represent any single word (an * cannot contain any dots) can use
the ACME.aaa and the user [email protected] may not use the
ACME.ddd license, implicitly any other user may.

Example 2 below, shows how machine names can be also used.

Example 2
<?xml version="1.0" encoding="utf-8" ?>
<AccessControl>
<License name="ACME.aaa" access="*.*.kings.com:*"/>
</AccessControl>

Here any user (signified by the * after the colon) may use the
ACME.aaa license when they are logged into a machine whose name
matches the *.*.kings.com string (for example
georgesPC.windsor.kings.com or jamesPC.stuart.kings.com) again the
* can represent any single word (an * cannot contain any dots) so a
user with the machine name elizabethsPC.queens.windsor.kings.com is
not allowed access.

3.3 General Syntax

The general syntax to grant or deny access to licenses is as follows:
<License name=[license name] access=[machine/user or group
name(s) semi-colon delimited] deny=[machine/user or group
name(s) semi-colon delimited]/>

Similarly, if the licenses on the server are grouped into buckets then
this syntax may be used; any access control will then apply to all
licenses within the bucket:
<Bucket name=[bucket name] access=[machine/user or group name(s)
semi-colon delimited] deny=[machine/user or group name(s) semi-
colon delimited]/>

3-3
3-4 Machine/User Definition

The PrintAllowedLicenses command (covered in Section Troubleshooting

below) can be used to list the licenses available on the server, including
which bucket they are in. The Admin Console also displays the bucket
for each license. Changes to the bucket configuration of the server
license file can only be made by Honeywell.

Group and Machine/User definition is covered in the following sections.

An exclusiveAccess syntax can also be used to override all other access

permissions, for example for a license inside a bucket where other
permissions have been set.
<License name=[license name] exclusiveAccess =[machine/user or
group name(s) semi-colon delimited]/>

Comments may be included in the access control file using the syntax:
<!-- Anything inside is ignored -->

3.4 Machine/User Definition

In overview, Machine/User name definitions are made as follows:

"[machine]:[user]" – for example "windsor.kings.com:henry"

If no colon (:) is entered then the entry is assumed to be just the user
name:

"[user]" – for example "henry"

A single asterisk (*) wildcard may be used to imply any machine or any
user:

"*:[user]" – a specified user on any machine – this is

equivalent to “[user]”, as above
"[machine]:*" – any user on a specified machine

3.5 Machine Definition

If a machine name is included in the access control file the full machine
name with full domain must be specified.

3-4
 Access Control Configuration 3-5

The asterisk wildcard (*) can replace a machine name, a complete

domain name or one or more prefix names of a domain name. No
other variations are accepted. The asterisk (*) wildcard can only
replace a whole word (there can be no “.”’s in the section to be replaced
by the *).

Consider the examples:

"*.domain" – any machine in a given domain for example

“*.kings.com”
"machine.domain" – a specific machine in a specific domain for
example “henryspc.kings.com”
"*.*.suffix" –any machine in any domain that has a given
suffix for example “*.*.kings.com”

Asterisk wildcards (*) can only be used at the start of the machine
definition. Trailing wildcards are not supported; the ULM does not
check for an explicit machine on any domain such as: “machine.*” or
“machine.*.*” etc.

Consider also the following two examples:

• Example A: *.queens.windsor.kings.com"
• Example B: *.windsor.kings.com"

Example B does NOT include example A. Example A defines any user

on any computer in the queens.windsor.kings.com domain. Example B
defines any user on any computer in the windsor.kings.com domain.
This illustrates the point that the * wildcard can only replace a whole
word (there can be no “.”’s in the section to be replaced by the *). This
is consistent with how network domain privileges work (where a
privilege in the “b” domain does not automatically extend to the “a.b”
domain).

Returning to one of the introductory examples to see this in practice:

<?xml version="1.0" encoding="utf-8" ?>
<AccessControl>
<License name="ACME.aaa" access="*.*.kings.com:*"/>
</AccessControl>

Here any user (signified by the * after the colon) may use the
ACME.aaa license when they are logged into a machine whose name
matches the *.*.kings.com string (for example
georgesPC.windsor.kings.com or jamesPC.stuart.kings.com). The *
can represent any single word (no dots within a *) so a user with the
machine name elizabethsPC.queens.windsor.kings.com is not allowed
access.

3-5
3-6 Group Definition

3.5.1 User Definition

User names are reported and tracked in User Principle Name (UPN)
form:
user@domain

The UPN of any user will be reported in the usage.log file which may be
examined in the Usage Monitor, for example:
02/12/2010 9:00 License: ACME.aaa (Process1) +1 Referencer:
ACME @ henryspc.kings.com (1):[email protected]

If the use of the domain name is required as part of the access control
then the @ sign must be used in the user name specification. It is still
possible to make ‘old style’ non-UPN user specifications.

So both

"[user]" – for example “henry"

and

"[user]@[domain]" – for example "[email protected]"

are permissible.

In the first case above a user henry would match the user definition
regardless of the domain they were logging in to.

Asterisk wildcards (*) may be used within the UPN user name definition
subject to the same restrictions as described above for machine names:
• Asterisk wildcards can be used to replace any single words in the
[user]@[domain] string. (* wildcards cannot contain dots)

Asterisk wildcards can also be used only at the start of the domain
name only; trailing wildcards are not supported. (for example
“*@tudor.*” won’t work.)

3.6 Group Definition

In order to simplify configuration, groups of users may be defined at
the start of the access control file and then later used in access= and
deny= statements.

3-6
 Access Control Configuration 3-7

Groups can be defined as a combination of users and other group

names with the syntax:
<Group name=[unique name for group] members=[machine/user or
group names(s) semi-colon delimited]/>

Or this multi-line syntax:

<Group name=[unique name for group]>
<member name=[machine/user or group name]/>
<member name=[machine/user or group name]/>
</Group>

Or any combination of the two as in Example 3 below:

Example 3
<Group name="Group1" members="William;Henry"/>
<Group name="Group2">
<member name="Arthur"/>
<member name="Group1"/>
</Group>
<Group name="Group3" members="Elizabeth;Mary">
<member name="Victoria"/>
<member name="Group1"/>
</Group>

Group names must not match with any user names or use the special
group name of AllLicenses. Adding members to AllLicenses gives
them access to all licenses on the server.

3.6.1 Group Definition on Active

Directory Systems
Beginning with ULM 5.30.1 and only on Active Directory systems,
groups in AccessControl.xml can optionally be defined by members in
an AD group or OU (Organizational Unit). Changes made to the Active
Directory will be automatically synchronized by ULM (an on hourly
basis) without needing further changes to AccessControl.xml.

The syntax for defining such a group is as follows:

<Group name=[unique name for group] ADQuery_Group=[canonical
name for AD group]>

Or:
<Group name=[unique name for group] ADQuery_OU=[canonical name
for AD OU]>

3-7
3-8 Precedence, Inheritance and

Examples:
<Group name="Group4"
ADQuery_Group="cn=group,ou=container,dc=domain,dc=com"/>

<Group name="Group5"
ADQuery_OU="ou=container,dc=domain,dc=com"/>

Note that ADQuery_Group and ADQuery_OU cannot be used together

on a single group but individually they can be combined with any of the
options listed in Section 3.6 - Group Definition (including referencing
another group).

Also note that changes made to AccessControl.xml for AD members will

likely take 1 minute to become active but could take 11 minutes and in
the worst case 1 hour and 11 minutes. The amount of time spent
updating here depends on the size of the AD group or OU. Further
membership changes just to Active Directory can take between 10
minutes to an hour to propagate to ULM. AD updates are processed
hourly regardless of how long the AD query takes.

3.7 Precedence, Inheritance

and Implicit access
The access control precedence, inheritance and implicit access rules are
defined as follows:
1. Any licenses or buckets on a license server which are not explicitly
mentioned within an access control file on the server are implicitly
accessible to any user.
2. Access control statements on licenses within a bucket extend or
augment those made for the bucket overall.
3. Any members placed in the special group AllLicenses have access to
any licenses on the server overriding any other access defined in the
access control file, except any access given by the exclusiveAccess
keyword.
4. a new top-level AllLicenses element, which can optionally replace
the use of the AllLicenses group. Functionally it is treated just like
the AllLicenses group, if both syntaxes are used together the results
are merged; however, the use of this new element is necessary to
give extra functionality, for example in order to deny access to
licenses on the server. The syntax is the same as for a Bucket or
License:
<AllLicenses access="Tudors" deny="James"/>

3-8
 Access Control Configuration 3-9

5. For license files containing buckets if a <License name=…/>

statement is made in the access control file outside of a bucket then
the access established applies to this license in every bucket, except
if this access is overridden by the use of the exclusiveAccess
keyword.
6. The exclusiveAccess keyword grants access that overrides any other
access established in the access control file. exclusiveAccess set for
licenses within a bucket overrides any exclusiveAccess settings for
the bucket as a whole, and any exclusiveAccess statements made
for that license outside of a bucket. In other words for license files
containing buckets, if a <License name=… exclusiveAccess =… />
statement is made in the access control file outside of a bucket,
then the access established applies to this license in every bucket,
except if overridden by any exclusiveAccess= settings made on the
bucket or within the buckets.
7. Controls denying access are independent of controls allowing
access. Both tests for allowed access and not denied access
must pass before access is granted. So, for example, even though
a user/machine is allowed access to a license because of
membership of the AllLicenses group if they are denied access to a
specific license or bucket through the use of a Deny statement the
Deny will take precedence.

Based on these rules the table below shows the order of precedence for
access (top of list has the highest precedence). A Deny statement at
any level will override access:

Table 1
Order of Precedence (for
Order of Precedence
exclusiveAccess)

AllLicenses (all licenses) License within Bucket

License outside of bucket (named Bucket
license in any bucket)
License outside of bucket
Bucket (all licenses within this bucket)
License within Bucket (just this
license)
[Use of exclusiveAccess overrides this
order and leads to its own order of
precedence – see right]

These rules are illustrated in the examples below.

Consider the access control file in Example 4 below:

3-9
3-10 Precedence, Inheritance and

Example 4
<?xml version="1.0" encoding="utf-8" ?>
<AccessControl>
<Groups>
<Group name="Tudors">
<member name="*@tudor.com"/>
</Group>
<Group name="Stuarts">
<member name="*@stuart.com "/>
</Group>
<Group name="Windsors">
<member name="*@windsor.com "/>
</Group>
</Groups>
<Bucket name="XXX" access="Windsors"/>
<Bucket name="Process1andProcess2" deny="Stuarts">
<License name="ACME.bbb" deny="Tudors"/>
<License name="ACME.eee" deny="Tudors"/>
</Bucket>
<Bucket name="Process1">
<License name="ACME.aaa" deny="Stuarts"/>
</Bucket>
</AccessControl>

The license file contains three buckets:

XXX • containing ACME Product 3 licenses

Process1 and Process2 • containing aaa, ccc, fff (Process1) and Process2 and
eee licenses (Process2)
Process1 • containing aaa, ccc, fff (Process1) licenses

Based on the access control file above these have the following access:

Bucket: XXX Any user in the group Windsors is explicitly

access="Windsors" granted access to this bucket, any other user is
hence implicitly denied.
Bucket: Process1 and Process2 Any user in the group Stuarts is explicitly denied
deny="Stuarts" access to this bucket, any other user is hence
implicitly granted access.
Process2 and eee licenses within – Access control statements on licenses within the
Bucket Process1 and Process2 bucket augment those for the bucket overall,
deny="Tudors" hence any user in the group Tudors is explicitly
denied access. All other users, except those in
group Stuarts which are denied access to the
whole bucket (including those in group Windsors)
still have implicit access.
Bucket Process1 There are no access control statements for the
bucket, hence any user is implicitly granted
access.
process license within Bucket As above, the access control statement on the
Process1 license within the bucket augments that for the
deny="Stuarts" whole bucket (none) so any users in the group
Stuarts are explicitly denied access.

3-10
 Access Control Configuration 3-11

Consider Example 5 below where groups are defined and the special
AllLicenses and exclusiveAccess keywords used.

Example 5
<?xml version="1.0" encoding="utf-8" ?>
<AccessControl>
<Groups>
<Group name="AllLicenses" members="Stephen;Richard"/>
<Group name="Group1" members="William;Henry"/>
<Group name="Group2" members="Arthur;Group1"/>
</Groups>
<License name="ACME.aaa" access="Group1"/>
<License name="ACME.ddd" exclusiveAccess="John"/>
<License name="ACME.ccc" access="Group2"/>
<License name="ACME.bbb" access="Group2" deny="Stephen"/>
</AccessControl>

Here Richard and Stephen are assigned to the special group AllLicenses
which means they can access all licenses (with exceptions noted
below). William and Henry (Group1) can access the ACME.aaa license.
Arthur, William and Henry (Group2) can access the ACME.ccc license.

Note the exclusiveAccess setting on ACME.ddd; this supersedes any

more global access rights and assigns only the access mentioned. So
for ACME.ddd, only John has access and not Richard and Stephen (even
though they have been added to the AllLicenses group).

The ACME.bbb license may be accessed by Group2 and Richard

(because of the AllLicenses group but not by Stephen (who is also in
AllLicenses) because of the explicit deny statement.

Note Example 6 below (here the license feature names SpecialLicense

and ThisLicenseInAnyBucket are made up to illustrate the effect of the
settings):

Example 6
<?xml version="1.0" encoding="utf-8" ?>
<AccessControl>
<Groups>
<Group name="Group1" members="Charles;Henry"/>
<Group name="Group2" members="Arthur;Group1"/>
</Groups>
<AllLicenses access="Edward;Mary;Elizabeth"/>
<Bucket name="Bucket1" access="Group1;William">
<License name="ACME.aaa" access="Anne;George"/>
<License name="ACME.fff" access="Anne"/>
</Bucket>

3-11
3-12 ‘By Exception’ Partial Wildcards

<Bucket name="ACMESpecial" exclusiveAccess="Victoria">

<License name="ACME.bbb" exclusiveAccess="Richard"/>
</Bucket>
<Bucket name="ACMESpecial2" exclusiveAccess="John"/>
<License name="ACME.SpecialLicense" exclusiveAccess="John"/>
<License name="ACME.ThisLicenseInAnyBucket" access="Group2"/>
</AccessControl>

Here the users Edward, Mary and Elizabeth have access to all licenses
in all buckets (using the new <AllLicenses …/> syntax) with the
exception of those licenses marked as exclusiveAccess below.

When defining access control for a bucket it is possible to set which

users have access to all the licenses in the bucket and to grant extra
access to particular licenses within that bucket. So in this case Charles,
Henry (Group1) and William have access to all the licenses in Bucket1,
Additionally Anne and George have access to the ACME.aaa license and
Anne has access to the ACME.fff license.

When the exclusiveAccess keyword is used for a license within a bucket

then this supersedes the containing access. So for the bucket Special,
Victoria has exclusive access to all the licenses in the bucket except
ACME.bbb. Again because of the exclusiveAccess keyword, only
Richard has access to ACME.bbb regardless of access settings on the
bucket or on AllLicenses.

Similarly the user John has exclusive access to all the licenses in bucket
Special2 (this overrides the AllLicenses access for Edward, Mary and
Elizabeth).

Note that the example above has some "License name" definitions
outside the Bucket definitions. This means that the defined access is
applied to the named license(s) regardless of their containing bucket.
So ACME.SpecialLicense is only ever accessible by the user John
whatever bucket it appears in and ACME. ThisLicenseInAnyBucket is
always accessible by the members of Group2 whatever bucket it
appears in, unless access is prohibited by an exclusive Access keyword
for the bucket or license within the bucket.

3.8 ‘By Exception’ Partial

Wildcards
A ‘by exception’ partial wildcard is supported within the user definition.
This is configured as follows:
!{User name with wildcard 1] + [optional exception 1_1] +
[optional exception 1_2] + …..;!{User name with wildcard 2] +

3-12
 Access Control Configuration 3-13

[optional exception 2_1] + [optional exception 2_2]+….;…

Or in words, for each grouping of wildcard + exceptions, NOT any user

matching the first string – with a wildcard that can represent part of the
user name, apart from the specifically named exceptions.

For example:
<Bucket name="Bucket1" access="*@kings.com;!abc*@kings.com +
[email protected];!xyz*@kings.com +
[email protected];!jkl*@kings.com"/>

means

Allow access to any user in the kings.com domain

BUT

Disallow access to anyone matching abc*@kings.com except

[email protected]

AND Disallow access to anyone matching xyz*@kings.com except

[email protected]

AND Disallow access to anyone matching jkl*@kings.com (with no

exceptions)

So, for example, [email protected] and [email protected] have

access but [email protected], [email protected] and
[email protected] do not.

ULM 4.27 onwards doesn't require a leading word wildcard (such as

"*@kings.com" as seen above). This means it's possible to use the
deny keyword to allow all user names matching a partial wildcard.

For example:
<Bucket name="Bucket1" deny="!abc*@kings.com +
[email protected]"/>

means

Allow access to anyone matching abc*@kings.com

BUT

Disallow access to [email protected]

Note that this is not a reliable way of controlling access as it relies on a

fuzzy match but it could be handy for some customers.

3-13
3-14 Limiting access to the Admin

3.9 Limiting access to the

Admin Console Tool
The ULM server automatically adds a license feature
AdminConsole.Access to the server. By allowing/denying access to this
feature using the AccessControl.xml file it is possible to control which
users can use the ULM Admin Console tool to view the server. Example
7 below illustrates this feature.

Example 7
<?xml version="1.0" encoding="utf-8" ?>
<AccessControl>
<Groups>
<Group name="Admin" members="William"/>
</Groups>
<License name="AdminConsole.Access" access="Admin"/>
</AccessControl>

3.10 AccessControl.xml file

encoding standard
Both ANSI and UTF-8 encoding are supported. The Notepad tool
supplied with Windows supports both standards, via an option on the
Save As dialogue, the default is ANSI.

3.11 Troubleshooting
The PrintAllowedLicenses command line tool, available in the
SimStation folder (typically C:\Program Files\Common
Files\Honeywell\SimStation) can be used to display all the licenses
available to the currently logged in user, and the bucket in which they
are contained (displayed in brackets). It can be run on the client or the
server. When run on the client it shows all the licenses available on all
the configured alternate hosts. When run with the /v (verbose) switch
PrintAllowedLicenses will display any access and deny lists for each
available license. PrintAllowedLicenses can also be supplied with a
machine/user name to display the licenses available for that machine/
user. For full details run PrintAllowedLicenses /?.

3-14
 Access Control Configuration 3-15

If there is an error when the access control file is read by the ULM a
message:

For a parsing error:

Message: Failed loading AccessControl.xml. <Specific reason for
parse failure>.

For other errors:

Message: Error in AccessControl.xml - <specific error
encountered>.

is shown in the Admin Console Server Messages window (and in the

diagnostic.log file).

When access is blocked by access control settings the usage.log

(viewable in the Usage Monitor) shows a failure message and the user
can see the following license message:
Reason: User does not have access.

Specific to Active Directory systems (see section 3.6.1) and when

trying to determine what members have been fetched from an AD
group or OU, look for the following text file after making edits to
AccessControl.xml:
<SimStation directory>\Pending\ADQueryOutput.txt

After sufficient time for AD query to complete (likely no more than 1-11
minutes), the results of the last group with an AD reference in
AccessControl.xml will appear in this file. The contents of the file will
vary slightly depending on the type of query being done (group or OU).
ULM will only use full UPN members listed (i.e. only those containing
the '@' symbol). If the members list is not correct then either a
different AD group/OU is needed or possibly an additional group with
another AD group/OU could be used as well.

3-15