Database architecture
UserLock relies on a central database to store activity logs. Understanding how this database works and which technologies are supported helps administrators make informed choices for performance, reliability, and long-term maintenance.
UserLock continuously records information such as:
session and authentication events,
user status changes,
administrator actions,
configuration changes.
A central database ensures this information is preserved, queryable, and consistent across the whole deployment.
By default, the UserLock installation package provides a free Microsoft Access database file (UserLock.mdb).
This option is designed for simplicity: it requires no configuration and allows administrators to start evaluating UserLock immediately.
However, Access has structural limitations:
maximum file size of 2 GB,
limited performance and scalability,
not resilient for long-term or production use.
Use case
👉 Suitable only for evaluation, testing, or very small environments.
For production deployments, IS Decisions strongly recommends using SQL Server or another supported system:
Microsoft SQL Server (2005 and newer, 32/64-bit)
No theoretical size limit.
Recommended for scalability, resilience, and enterprise integration.
Microsoft SQL Server Express (2005 and newer, 32/64-bit)
Free edition with a maximum database size of 10 GB.
Provides most SQL Server features, with CPU and RAM limitations.
A cost-effective option for SMB or smaller environments, but still robust enough for production.
MySQL 5.6 and newer
Requires the 32-bit ODBC driver (even on 64-bit operating systems).
The MySQL .NET connector must not be installed.
Once the ODBC driver is available, MySQL appears as an option in UserLock.
Note
LocalDB editions of SQL Server are not compatible with UserLock.
UserLock deployments frequently evolve over time. Common migration needs include:
moving from Access to SQL Server (most typical production scenario),
moving from one SQL Server to another (infrastructure change, upgrade, or disaster recovery).
UserLock provides dedicated tools and guides to perform these migrations while keeping data and history intact.
If you need help to deploy SQL Express, follow the guide on how to install and configure SQL Express.
Always use SQL Server (or SQL Server Express, or MySQL) for production.
Host the database on a dedicated and backed-up server.
Monitor database growth and plan maintenance (archiving, purging old logs).
Test migrations in a staging environment whenever possible.
Work with your DBA team to align with corporate standards and backup policies.
Note
For detailed configuration options in the console, see Server settings ▸ Database.
The UserLock database is composed of four tables:
the UserLogonEvents table to record session events,
the UserStatus table to record User status,
the AdminActions table to record administrator action,
the AdminActionResults table to record results related to administrator actions.
You can find below a list of the fields included in these tables, showing their type and their purpose.
This information is provided for transparency and integration purposes.
Note
The UserLock database is openly accessible to allow integration and reporting on collected data. However, we strongly recommend not altering the schema or content.
Field name | Data type | Field description |
|---|---|---|
EventType | integer | Interactive sessions Wi-Fi / VPN sessions IIS sessions SaaS sessions UAC events |
EventTime | date time | Date and time of the logon/logoff event |
UserAccount | string | User account name |
UserDomain | string | User domain |
UserFullName | string | User full name |
ComputerName | string | Logged on workstation or terminal server |
ComputerSession | integer | Terminal session identifier |
ClientName | string | Logged on workstation or terminal |
ClientAddress | string | Workstation or terminal IP address (MAC address for Wi-Fi sessions). |
SessionId | string | Session identifier |
SubSessionId | integer | Sub session identifier. Increased by 1 after each unlock event (new sub session) |
Status | integer | 0: For all session events, except for the cases below.
3: For interactive session logoff events automatically recorded after a shutdown or crash of the computer on which the session was running. |
ErrorId | string | Not null only if the session event could not be notified in real time to the UserLock server. This can happen in the following cases:
|
LastError | integer | Different from 0 only if the session event could not be notified in real time to the UserLock server. See the documentation for the ErrorId field above for more details. |
Param1 to Param6 | string | Dynamic fields used by Wi-fi/VPN/IIS logon/logoff events |
Id | integer | Record id (auto) |
LogonInfo | integer | The meaning of this value depends on the value of the associated EventType value. Detailed reasons for Logon succeeded, when associated 'EventType' = 1, 3, 5, 101, 201 or 501: Detailed reasons for Logon denied by UserLock, when associated 'EventType' = 4, 104 or 204 Logon denied by UserLock can be caused by several reasons. Therefore the value recorded for logon denied by UserLock is a cumulative value. For example, 25 means that group, user and time quota restrictions were applied (1+16+8). Detailed reasons for Logon Denied by Active Directory, when associated 'EventType' 20, 220 or 420: As logons denied by Active Directory have an exclusive reason, only a single value from this list will be stored. Detailed reason for Logon Denied by Active Directory, when associated 'EventType' 120: |
SessionType |
| Session Type: |
ServerAddress | chaîne | L'adresse IP de l'ordinateur où s'est déroulé l'événement de session. |
TimeZoneShift | entier | Time difference with UTC (Coordinated Universal Time), in minutes. |
SkipReason | entier | Relatif au bouton “Passer” optionnellement affiché dans la boîte de dialogue de configuration MFA. |
Country |
| Country from which the connection was established |
Field name | Data type | Field description |
|---|---|---|
Id | integer | Record id (auto) |
Status | integer | Current status of the user: |
Triggers | integer | Flags of remarkable conditions to help deduce the current status for the user. |
OldStatus | integer | Previous status of the user: |
OldTriggers | integer | Flags of remarkable conditions to help deduce the previous status for the user. |
UserAccount | string | User account name |
UserDomain | string | User domain |
UserFullName | string | User full name |
SessionId | string | Session identifier |
SubSessionId | string | Sub session identifier. Increased by 1 after each unlock event (new subsession) |
EventType | integer | Interactive sessions |
EventTime | date time | Date and time of the logon/logoff event |
Field name | Data type | Field description |
|---|---|---|
Id | integer | Record id (auto) |
ServerName | string | Server name |
Kind | integer |
|
Action | integer |
|
DateStart | date time | Date time when admin action started |
DateEnd | date time | Date time when admin action ended |
UserAccount | string | User account name initiating the action |
Priority | integer |
|
Severity | integer |
|
DisplayState | integer |
|
UserAccountFullName | string | User account full name initiating the action |
Domain | string | Domain name |
Field name | Data type | Field description |
|---|---|---|
Id | integer | Record id (auto) |
ServerName | string | Server name |
AdminActionId | integer | AdminAction identifier |
Item | string | The setting changed by the admin action |
Param1 | string | Dynamic fields |
Param2 | string | Dynamic fields |
Param3 | string | Dynamic fields |
Param4 | string | Dynamic fields |
Param5 | string | Dynamic fields |
Param6 | string | Dynamic fields |
StateResult | integer |
|
Details | string | Details about the admin action |