Check services and network protocols requirements

UserLock relies on standard Windows services and network protocols to communicate between the server, protected machines, and other components (SQL, IIS, Active Directory).
Before running the detailed tests below, verify the following conditions to ensure all communications can operate properly.

What to check before you start:

• ✅️ The UserLock service impersonation account must have administrative rights on all protected computers.

  See HTF005 – Impersonation account.

• ✅️ Review the Requirements help page for the full list of ports and Windows services used by UserLock.

• ✅️ The following communications must be allowed both ways between the server and workstations:

  • ICMP (Ping) — for basic network connectivity.

  • SMB / File and Printer Sharing (TCP 445, 139) — for admin$ access and agent deployment.

  • RPC — for remote registry access.

  • DNS / FQDN resolution — UserLock uses FQDN by default for reliability.

• ✅️ Run all checks from the UserLock server using the impersonation account, to reproduce the same conditions as the UserLock service.

1. Open the UserLock Console.

2. Launch UserLockPowerShell.

3. Run the following command (replace COMPUTERNAME with the NetBIOS name of the target):

   powershell

   (Get-UserLockAgentDistribution -Name COMPUTERNAME).Fqdn

4. Note the returned FQDN, for example: WKS1.corp.local.

1. Log on to the UserLock server using the impersonation account.

2. Open CMD and run (replace COMPUTERFQDN):

   ping COMPUTERFQDN
   explorer \\COMPUTERFQDN

3. You should observe:

   • The workstation replies to ping.

     

   • File Explorer opens the remote computer view.

     

1. On a workstation, log on as a standard user.

2. Open CMD and run:

   ping USERLOCKSERVERFQDN
   explorer \\USERLOCKSERVERFQDN

3. You should observe:

   • The UserLock server replies to ping.

     

   • File Explorer opens the server shares.

     

Check that the UserLock service impersonation account has administrative rights on the target computer.

1. On the UserLock server, log on as the service impersonation account.

2. Open CMD or PowerShell and run:

   powershell

   explorer \\COMPUTERFQDN\ADMIN$

3. You should see the Admin$ share contents of the workstation.

   • If you get Access Denied, the account lacks administrative rights or SMB traffic is blocked.

Check that the UserLock service impersonation account has remote access to the registry of the target computer.

1. On the UserLock server, run regedit.

2. In the File menu, select Connect Network Registry….

3. Type the FQDN of the target computer and click OK.

   

4. You should see the remote registry hive

   • If the connection fails, check RPC permissions or firewall rules.

To confirm end-to-end communication:

1. Prepare a test user USR1 and two workstations: WRK1, WRK2.

2. Install the Desktop Agent on both (reinstall if necessary).

3. Create a Session limit policy for USR1:

   • Limit Interactive sessions to 1.

   • Enable Close previous session.

4. Create a Notifications policy for USR1:

   • Enable Display welcome message

5. Test the result:

   • Log on to WRK1 as USR1 → welcome message should appear.

   • Log on to WRK2 as USR1 → prompt to log off WRK1 appears; confirm and continue.

   • If the session proceeds normally and the message displays, communication between components is working correctly..

1. From the UserLock Console, press ALT + F6 to open UlTerm

2. Run:

   bash

   REMOTEACCESSTEST <target-computer-FQDN>

3. The command returns detailed diagnostics about remote access rights.

   • Save the output for support if needed.

1. On a workstation with the Desktop Agent installed, run:

   bash

   C:\Windows\SysWOW64\UlAgentExe.exe /REMOTEACCESSTEST

2. This test checks communication from the agent’s point of view and helps identify workstation-side issues.