Ressources techniques

If the deployment doesn't work on a workstation, you should check the following points:

1- Is the workstation registry remotely accessible from the server? (using regedit)
2- Is the workstation administrative share \\workstationName\admin$ accessible from the server?

Here under are some common reasons of a deployment problem:
- Failed to connect to workstation. Error code = 0x0005 Access is denied. The UserLock service account hasn't the administrative rights on all workstations. In this case, check that:
1- The UserLock service account is member of the "domain admin" group
2- The "domain admin" group is member of the administrators group on all workstations
- Failed to connect to workstation. Error code = 0x0035 Network path not found.
1-The computer is down or doesn't exist
2-The NetBIOS name of the workstation cannot be resolved because of a WINS problem.
3-The "File and network sharing" component is not installed in the network connection of the workstation or the server service and the remote registry service are not running.

You can ask us for an evaluation key at info@userlock.com. In order to send you the key, we need the exact number of workstations to protect in the domain.

Check that you have only one UserLock service running on your sub network.
Check that the agent is deployed on all workstations.

Older versions of UserLock (less than v2.5) were licensed according the number of user accounts in the domain and you have probably exceeded this number. To avoid this problem please download the latest version (2.5 or more).

Start the operating system in safe mode (without network).

For the GINA agent (NT4/2000/XP/2003)
Remove the following registry key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\GinaDLL
You can download a reg file here to do it.

For the Windows Vista/7/2008 Agent
OS 32 bits :
- Stop the UserLock service
- "c:\Windows\System32\ULAgentExe.exe /UNREGISTER" (unregister)
- "c:\Windows\System32\ULAgentExe.exe /SERVICE u" (delete « UlAgentService »)

OS 64 bits :
- Stop the UserLock service
- "c:\Windows\SysWOW64\ULAgentExe.exe /UNREGISTER" (unregister)
- "c:\Windows\SysWOW64\ULAgentExe.exe /SERVICE u" (delete « UlAgentService »)

The problem is not directly related to UserLock. The warning is generated when the UserLock deployer try to contact specific unavailable workstations listed in the Active Directory. In consequence their IP address is sometimes used by another computer. In consequence when the server contacts the workstation A the workstation B responds instead and this warning is generated.
You can read the following article of the Microsoft knowledge base about this problem: Q263208

To fix it you just need to remove all “ghost” computers listed in your Active Directory.

As workaround you can also set the following registry setting and restart the UserLock service (Version >= 3.02):
HKEY_LOCAL_MACHINE\SOFTWARE\ISDecisions\UserLock\CheckIpConflict = REG_DWORD:1

With the default configuration UserLock always disconnect any previous session for a user on the server in order to join it instead of creating a new session. This allows a user to continue his work from a new location without having to get back to the previous location in order to disconnect the session. You can change this behaviour in the Agent distributions properties (Agent tab) of the UserLock primary server or in server properties (Terminal server tab) if the server is in standalone terminal server mode. For the setting “Try to join any existing session on the server” select “If the new session is not allowed” or “Never”.

The upgrade procedure is explained in the following page of the help file:
http://www.isdecisions.com/help/UserLock/English/Default.htm#Reference/Upgrade_procedure.htm

Install UserLock on the new server

Start the configuration wizard but don’t click on Next in the Service account step. Leave the wizard on standby.

Copy the files UserLock.cfg and UserLock.mdb located in the folder “c:\program files\ISDecisions\UserLock” from the old server to the new server.

Stop the UserLock service on the old server

Click Next in the UserLock configuration wizard on the new server. The new service is automatically started and is working.

Uninstall UserLock from the old server or at least disable the service to avoid conflicts between the two servers.

The ASP.NET needs to be enabled in IIS.

• On Windows 2000/2003 you can install ASP.NET with the following command line:
  \Microsoft.NET\Framework\v2.0.50727\aspnet_regiis.exe –i
• On Windows 2008 the following IIS roles services are needed:
  - IIS 6 metabase compatibility (Without it the web configuration tool will not detect that IIS is installed)
  - Windows authentication
  - ASP.NET
  
• On 64 bits servers you need to make IIS run in 32 bits mode with the following command line:
  cscript %SYSTEMDRIVE%\inetpub\adminscripts\adsutil.vbs SET W3SVC/AppPools/Enable32bitAppOnWin64 1

Open the terminal services console (in administration tools) from your terminal server and display the RDP connection properties. In the general tab the setting “Use standard Windows authentication” should be unchecked. For Citrix terminal server you need to do same for the ICA connection.

UserLock regularly checks the agent status and tries to retrieve lost logon events on all workstations of the protected network zone. That's why logon events are generated.
You can slow down the check speed by adding the following registry value on the server:
- 32 bits: HKEY_LOCAL_MACHINE\SOFTWARE\ISDecisions\UserLock\WaitBetweenCheck = (DWORD)
- 64 bits: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\ISDecisions\UserLock\WaitBetweenCheck = (DWORD)
This value corresponds to the time interval in ms. Default value is 500 (an half second between each computer). If you set for example 5000 (each 5 s) you will get 10 times less logon events.
A service restart is needed after creating or changing this value. This setting only works on UserLock 3.5 or more.

When trying to use web interface, this error displays:

• "Runtime error" through an Internet browser.
• " The current identity (NT AUTHORITY\NETWORK SERVICE) does not have write access to 'c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files' " through the browsing inside IIS manager mmc.

The problem comes from the Network Service which doesn't have sufficient right.

This Microsoft article will explain you how to grant the "Network Service" right and solve your problem.

You can grant access to this account explicitly using the aspnet_regiis -ga switch, for example:
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50215>aspnet_regiis -ga "NT Authority\Network Service"