Web console
This page provides guidance for resolving common issues encountered in the UserLock Web application. It describes typical error messages, their causes, and recommended solutions. Use the sections below to troubleshoot problems such as service unavailability, authentication failures, or installation conflicts.
In case of errors connecting to the UserLock server, you will be redirected to the following page:

Make sure the UserLock service is started on the server. If it is stopped, start it and refresh the page.
If the message "You are not allowed to administer this UserLock server!" appears when you click the Connect button on the error page, it means that the Windows account you are using is not allowed to administer UserLock.
Connect to the UserLock server
Open the UserLock local administration console and go to the Server settings page of the server.
In the Permissions section, add the account you are using to the list and add the necessary rights.
Click on the Save button
Go back to the web application and click on the Connect button
Depending on the permissions configured in UserLock for the Windows account used, you may encounter the following error page:
)
Connect to the UserLock server
Open the UserLock local administration console and go to the server properties page.
In the Permissions section, select the relevant Windows account.
In the list of checkboxes on the right, make sure that the Activity/Reporting read rights are checked, otherwise you will not be able to view the vast majority of the application's pages.
To have access to perform actions on sessions, add write permissions.
To view the list of machines, make sure you have Machines and agents read permission.
To access actions on machines, add write permissions.
To view the server properties from the web application, make sure the Server settings read permission is checked. To be able to modify them, add write permissions.
This message appears when accessing the UserLock Web Console and that the UserLockAppPool application pool in IIS failed to start.
In the Windows Event Viewer (Application log) on the UserLock server, you will find this error:
The Module DLL 'C:\Program Files\Microsoft\Exchange Server\V14\Bin\kerbauth.dll' could not be loaded due to a configuration problem. The current configuration only supports loading images built for a x86 processor architecture. The data field contains the error number.Source: IIS-W3SVC-WP
Event ID: 2282
This is a known issue on 64-bit servers with Exchange, which sets these DLLs to load by default in all application pools. UserLock tries to load a DLL it doesn’t need because Exchange forces it, and there is no 32-bit version.
Workaround: modify these DLL loading settings.
Locate and backup the following file:%windir%\system32\inetsrv\config\applicationhost.config
Open this file with a text file editor. Note: If you are logged in to the IIS server, launch the editor with the "Run as administrator" option enabled, otherwise you will get an error when saving changes.
In the <globalModules> section, find and modify these entries by adding preCondition="bitness64" before /> on each line (if it’s not already there):
"kerbauth" image="<path>\kerbauth.dll"
"exppw" image="<path>\exppw.dll"
On Exchange V15 (not needed on V14): "cafe_exppw" image="<path>\exppw.dll"
For example, on Exchange V15, replace:
<add name="kerbauth" image="<path>\kerbauth.dll" />
<add name="exppw" image="<path>\exppw.dll" />
<add name="cafe_exppw" image="<path>\exppw.dll" />with this:
<add name="kerbauth" image="<path>\kerbauth.dll" preCondition="bitness64" />
<add name="exppw" image="<path>\exppw.dll" preCondition="bitness64" />
<add name="cafe_exppw" image="<path>\exppw.dll" preCondition="bitness64" />In each <isapiFilters> section, find and modify the following entries by adding preCondition="bitness64" before /> (if not already there):
"Exchange OWA Cookie Authentication ISAPI Filter" path="<path>\owaauth.dll"
"Exchange ActiveSync ISAPI Filter" path="<path>\AirFilter.dll"
For example, on Exchange V15, replace:
<filter name="Exchange OWA Cookie Authentication ISAPI Filter" path="<path>\owaauth.dll" enabled="true" />
<filter name="Exchange ActiveSync ISAPI Filter" path="<path>\AirFilter.dll" enabled="true" />By
<filter name="Exchange OWA Cookie Authentication ISAPI Filter" path="<path>\owaauth.dll" enabled="true" preCondition="bitness64" />
<filter name="Exchange ActiveSync ISAPI Filter" path="<path>\AirFilter.dll" enabled="true" preCondition="bitness64" />With this precondition attribute, these DLL won’t be loaded in the 32-bit application pool.
Save and close the file.
Restart IIS (run iisreset command) and relaunch the UserLock Web Console.
The Web Console should now work.
If the same error still occurs, other modules may require this preCondition. Check the Application log in Windows Event Viewer to see which modules are causing bitness issues.
Alternative solution:
Change the UserLockAppPool to 64-bit but we do not recommend this if you use the default Access database, which will not support running reports from the Web Console.
This error occurs because the UserLock service connects to the database using Windows authentication, the UserLock SQL Server database is hosted on a different server than the IIS server hosting the Web Console, and Kerberos delegation is not enabled on the IIS server to allow proper authentication to the database server.
In the Web Console, all reports and statistics (for example, data shown on the Last days tab of the dashboard) will be empty. You will also find this error message in the application log file.
Here is the procedure to configure delegation.
Note: If the SQL Server service account is a Managed Service Account, this procedure will not work. The only solution in that case is to change the UserLock service configuration to use SQL authentication instead of Windows authentication.
On the Database Server, open the Windows Services console to identify which account runs the SQL Server service.
In this example, the server hosting SQL Server is named VES2.VDE.intra and the SQL Server service runs as VDE\SQLServerSvc on port 1433.
Still on the Database Server, create a Service Principal Name (SPN) for the SQL Server instance using this command:
Setspn -A MSSQLSvc/[ServerName]:[PORT] [AccountName]Example:
Setspn -A MSSQLSvc/VES2.VDE.intra:1433 VDE\SQLServerSvcOnce the SPN is created, enable delegation for the IIS server hosting the UserLock Web Console in Active Directory.
Open Active Directory Users and Computers.
Find the IIS server hosting the UserLock Web Console and open its Properties. (In our example, this server is named VES1.)
Go to the Delegation tab.
Select Trust this computer for delegation to specified services only and choose Use any authentication protocol.
Click Add... to register the SQL Server service.
In the Add Services window, click Users or Computers... and enter the name of the SQL Server service account for which you defined the SPN (e.g., SQLServerSvc). Click Check Names and then OK.
The new entry will appear in the list. Select it and click OK.
Confirm by clicking OK or Apply.
The UserLock Web Console should now be able to retrieve all information from the database.
)
)
)
)