Altiva Licence Server
If any problems occur getting the Altiva Licence Server started, the source of the problem can usually be found in the debugging log file: "Debug_xxxx.log" (where x denotes an incremented number, e.g. "debug_0051.log"). The easiest way to view the current debugging log file on the server machine is to use the ALS Main Window and click on the Debug Log button. Service related issues may also be logged in the Windows Event Viewer, which can be viewed by clicking on "Control Panel > Administrative Tools > Event Viewer > Application" and looking for a source set to "Altiva".
If you are not currently on the server machine, you can view the current status of ALS by opening your browser and entering the server computer name, followed by the HTML port number, for example:
This can also be done from within the licensed product (e.g. CADconform) by clicking on "Licence Information".
The most common problems are listed below:
For all other issues not addressed above, see Resolving Other Problems.
The Service Cannot be Installed
This problem is rare, but it is possible that an error may cause the service to not install correctly. This will result in the "Install" button being enabled, and the "Start" button being disabled. This problem will not be recorded in the Debug Log because the log is only started when the service is started (or attempted to start). Generally this sort of problem is caused by a faulty installation of ALS. Reinstalling the program will generally fix this issue. Additionally this may occur if the current user does not have full administrative privileges. If so, then this can be resolved by logging in as an administrator. This level of privilege is required because Windows Services require administrative privileges to install, mmodify or remove background services.
The ALS Service is "Disabled"
If the Windows Service Control Manager (services.msc) reports the "Altiva Licence Server" service as "Disabled", then the service can neither be started nor uninstalled. This usually happens when the service is marked for deletion, but some other program is preventing it from being removed. In most cases rebooting the computer will fix this problem, however this may be undesirable when the server is used to host other essential applications. The following checklist shows which programs are known to create a service lock. These programs should either be closed or killed using the Windows Task Manager (TaskMgr.exe) to allow Windows to remove the service cleanly:
When all programs and processes have been closed and/or killed, Task Manager itself should be exited. When the services console is reopened, the service should no longer be shown.
The Service Does Not Start
Usually if there is a problem with the general configuration or setup of ALS, the service will not start correctly. In this case, the problem can almost certainly be determined by examing the debug log. Generally the symptom is that the Install button is disabled and the Start button is enabled, but clicking "Start" results in an error message. Issues that may result in a non-starting service include incorrect licence files (e.g. the server does not match the licence file), or a misconfigured port (see below).
bind() failed: Address already in use (10048)
This error may be shown in the debug log for a number of reasons. The usual cause is an existing program that is already using the port (1999 by default). There is no official authority allocating ports to Windows programs, and thus most programs allow configurable ports with a "guessed" default. This may result in multiple programs attempting to use the same port. If this occurs, then you will see the error message above in the debug log. To see which ports are currently in use by the server, follow these steps (NB: for advanced users only):
If you have determined that there is a port collision and wish to change the default port used by ALS to something other than 1999, then follow these steps:
If the service installs and starts with no errors, but the licences always time-out connecting to the licence server, then it is likely to be a firewall issue. Generally you need to create an exception for ALS on both the server and the client to allow communication on the defined port (1999 by default). This is done automatically by ALS for the Windows Firewall, but for 3rd party firewalls you may need to follow extra steps to do this. For general information on firewall issues, see this resource: http://support.microsoft.com/kb/842242 (.)
Note that if your firewall allows exceptions based on application, then it should be sufficient to allow the "ALS.EXE" application in order to give full access to the ALS services. If your firewall allows exceptions per port, then you will need to allow both the main communication port as well as the HTML port. These ports are defined in the configuration file. By default they are ports 1999 and 1998 respectively.
If the ALS service starts with no errors reported in the debug log, but licences are not served, then it is likely that the problem is on the client-side. The most common problem here is that the client-side firewall is blocked for the server port (1999 by default), so the firewall settings should be checked. The second most likely problem on the client-side is that the server can not be reached. It may be worth attempting to "ping" the server from a client machine (see your IT manager for more information) to ensure the server is reachable.
You can increase the level of debug information by editing the "als.cfg" file, setting "DEBUG_LEVEL_NUM=3" and restarting the service. This will produce a lot more debugging information in the log files, which may help in isolating the problem.
If a problem persists, then please send all log files to Altiva Software so we can determine what the problem is.
Contact details for Altiva Software can be found on the Altiva website. Alternatively, you can contact us directly via e-mail.