Overview
Q1 - Administering Thin Clients with
AxRM
The AxRM
software allows system administrators to manage and configure Axel
TCP/IP products remotely over a network.
The remote Axel device is selected by its IP
address or network
name. (The software can also assign an IP address to a newly installed
terminal that has not had an IP address set)
AxRM is an abbreviation for Axel Remote Management
software.
AxRM is used for:
- obtaining hardware and firmware
revision levels,
- obtaining Ethernet and serial line
configuration,
- rebooting the peripheral,
- remotely configuring a peripheral,
- downloading firmware,
- reloading factory settings,
- repairing a terminal with bootp (lost
firmware).
It is also possible:
- to manage a terminal database,
- to compile a list (batch) of commands
to run consecutively,
- to download a firmware though BOOTP,
- to set IP addresses by using the device
MAC address.
Click
here to
download AxRM.
First you must get the firmware file. Most of the firmware are
available from our WEB site of the Firmware
Download Zone. If a firmware file is missing, contact the
Axel technical support.
Note:
we advise to upgrade a firmware only if it's actually needed (new
feature, problem fix...). Indeed, in opposite of a PC, Axel thin
clients don't need regular upgrades (for example for fixing a security
breach).
Run AxRM. If the thin client is not included in the database,
click the Discover option. The thin client can also manually added.
Then click-right the thin client entry and select 'Firmware
Download'. Enter the firmware file name (FK...). Leave enabled the
'Preserve the configuration' option. Click [Run Command]
Attention:
the firmware file must match the thin client hardware (FK40, FK55,
FK56...)
First the terminal configuration will be retreived and stored. The the
firmware file will be uploaded to the thin client. After the thin
client reboot, the configuration file is sent back. After a second
reboot the thin client is ready to be used.
Q3 - Thin Clients and DHCP
To open a connection to a terminal (i.e to remotely
administrate a thin client), AxRM must know the ID of this thin client.
When static IP addresses are used the IP address is suitable for this
identifier.
However when the IP address is provided by DHCP, the IP address can't
be used as the IP address is liable to change.
In this situation the ID must be the DNS name.
Note:
to be compliant with this rule, when a terminal is discovered by AxRM,
the ID associated in the AxRM database is either the IP address or the
DNS name (depending if the
thin client is running
DHCP or not).
When the ID is the DNS name, DDNS (Dynamic DNS) must be used. In this
scenario the DHCP server collaborates with the DNS server, updating the
DNS server with the new terminal's DNS name.
Using a DNS name allows AxRM to administrate terminals in a
dynamic-IP-addressing environment.
Care needs to be taken over the 'DNS Cache' on the machine where AxRM
is running. For more information, please consult the next article.
Q4 - The DNS Windows Cache
When a TCP/IP device opens a connection in a DNS environment, the DNS
name of the destination must first be "resolved". This DNS resolution
allows the IP address to be obtained from the DNS name, allowing the
connection to be established. (This IP address can be dynamic when
using a DHCP environment).
Each time a DNS name has to be resolved a DNS request is sent to the
DNS server(s).
'DNS Cache'
Overview
To reduce the number of DNS requests, a DNS cache is maintained on
Windows machines. This is an array where known associations between
name and IP are stored. The Windows machine first searches for an entry
in its DNS cache before sending a DNS request to the server.
This causes a
potential problem in the following scenario:
The thin client boots, obtains an IP address via DHCP, the
DHCP server updates the DNS server. The first time AxRM contacts
this thin client it resolves the thin client's
DNS name and obtains the IP address. Connection is established, remote
commands work and the PC caches the thin client's
DNS name and IP address. When the thin client
reboots it will re-contact the DHCP server to request an IP address.
This IP address may be different to the address previously provided.
Now, when the AxRM PC tries to contact the thin client, it will first
access its own DNS cache, lookup the DNS name and find the old IP
address is still associated to the DNS, and the connection with
fail....
Solution:
The solution is disabling the DNS cache. Then each time a DNS name is
to be resolved a DNS request will be have to be sent.
The AxRM preferences (V3.5.10 minimum) allow the DNS cache to be
disabled.
To manually disable then
DNS cache enter the following command from a DOS prompt.
net stop
dnscache
Note:
To disable the DNS cache permanently in Windows, use the Service
Controller tool or the Services tool to set the DNS Client service
startup type to Disabled. Note that the name of the Windows DNS Client
service may also appear as "Dnscache." For more information consult the
Microsoft knowledge base:
http://support.microsoft.com/kb/318803.
Q5 - Tuning a Firewall
for AxRM
The AxRM tool
uses the following commands:
- PING: checking terminal availability,
- RSH: administration command protocol,
- RSH: legacy administration command protocol,
- TFTP: downloading firmware,
- REMOTE ACCESS: taking control of a terminal,
- BOOTP: "repairing" a terminal when the firmware
is lost.
Note: when running
an administration command, the used protocols depends on the AxRM
preferences (see the option "Administration Command Protocol(s)") :
- XML only :
PING and XML
- RSH only : PING,
RSH and TFTP
- XML and RSH : PING,
XML, RSH and TFTP
If you have a
firewall there is a high chance that some services will be blocked by
default.
There are three ways to resolve this issue.
1. Connect the terminal to a non-firewalled PC,
2. Turning off the firewall for the duration of
the download
3. Enabling AxRM to work through the firewall.
This is covered in more detail below.
PING
The ICMP protocol must be allowed.
XML
Enable TCP port 80. (It should be laready opened because this is the
tcp port uses by Internet Browsers)
RSH
From the PC/Firewall, RSH requires an outgoing port, and an incoming
port. When 'RSH' is allowed within the firewall:
- an outgoing port is enabled (514),
- along with a range of incoming ports starting at
1024. (or another value is the 'Local RSH Port Base' default valued had
been modified)
REMOTE ACCESS
Three outgoing ports must be enabled:
- 4096: 'Set-Up via Telnet' function
- 4098 : 'Remote Control' function.
- 5900 : 'VNC Remote Control' function.
TFTP
Enable UDP port 70 - this is the port TFTP listens to.
BOOTP
Enable UDP port 69 - this is the port TFTP listens to. .
Troubleshooting
P1 - Installation Problem: SQLDMO.DLL
P2 - Installation
Problem: fraplus1.ocx and btnplus1.ocx
During the installation of AxRM the following error messages may be
seen:
An error occurred
while registering the file c:\windows\system32\FraPlus1.ocx
An error occurred
while registering the file c:\windows\system32\BtnPlus1.ocx
This error is due to an incompatibility of these components with the
new Windows function 'DEP' (Data Execution Prevention)
Note:
Data Execution Prevention is a set of hardware and software
technologies that perform additional checks on memory to help prevent
malicious code from running on a system. It's only used on some CPU
processors.
To install AxRM it is necessary to restrict the function of DEP:
In the control panel click on "system". On the "Advanced" tab, under
Performance, click "Settings" . On the "Data Execution Prevention" tab
select the option "Turn on DEP for essential Windows programs and
services only". Reboot the server to make this change take effect.
The AxRM installation will now proceed as normal.
P3 - AxRM Terminates After the
Splash Screen
Problem:
When running AxRM the splash screen is displayed then AxRM terminates.
Explanation
#1:
AxRM execution is aborted by the DEP module (Data Execution
Prevention). The DEP module does not recognise AxRM and prevents it
from running.
Two methods can be used to fix this problem:
1. Set AxRM as a trusted software:
In the control panel
click on "system". On the "Advanced" tab, under Performance, click
"Settings" . On the "Data Execution Prevention" tab:
- either select the option "Turn on DEP for essential Windows programs
and services only"
- or check the "Axel Remote Manager" item. Reboot the server to make
this change take effect.
2. Disable the XP-like menu component in AxRM
(V2.3.3 minimum)
Run "regedit.exe".
Go to [HKEY_LOCAL_MACHINE]-[SOFTWARE]-[Axel]-[AxRM V2] and set
"UseHookMenu" to 0.
Explanation
#2:
After the splash screen, AxRM attempts to detect the current NIC
(Network Interface Card). This detection has certainly failed.
An alternative NIC detection method is available. To enable it, run
"regedit.exe". Go to [HKEY_LOCAL_MACHINE]-[SOFTWARE]-[Axel]-[AxRM V2]
and set "ListNICLegacyMethod" to 1 (AxRM V3.2.0 minimum).
P4 - 'Old' Thin Clients can't be
Administered
By default, to administrate thin clients, the XML protocol is used by
AxRM. With 'opd' thin client, this XML protocol could be not supported.
In this case, the AxRM settings must be changed. Go
to [Files]-[Preferences] and select the "General" tab.
Set the "Administration Command Protocol(s)" to "XML and RSH".
P5 - "Syntax Error or not XML DATA"
When Running an Admin. Command
When running an administration command the message "Syntax
error or not XML Data" is displayed
This could be due to an anti-virus software. (Now such utilities not
only check files and memory but also parse network dataflow.).
Disable the anti-virus or only the network parser and try again.
If the problem remains, this could due to a router (who checks and
reformat dataflow). In this case, the solution is to use the
legacy administration protocol (RSH) instead of the default
one (XML). Go
to [Files]-[Preferences] and select the "General" tab.
Set the "Administration Command Protocol(s)" to "RSH only".
P6 - Miscellaneous Issues with Remote
Control
The possible problems are the following:
1 - 'Remote
Access' option and related icon are inaccessible (greyed out)
The target thin client is too old. This function is not available on
these discontinued products:
- AX3000 Models 55 & 65E
- AX3000 Models 60 & 60E
- AX3000 Models 65, 65B & 65E
2 - In the 'Remote
Access' box, the 'VNC Remote Control' option is inaccessible (greyed
out)
The VNC
remote control is only supported by AX3000 Models 80 and 85.
3 - Error Message
"Remote Control Service is not enabled on the Axel device"
The remote access is not enabled at the thin client set-up level: enter
the thin client set-up and go to
[Configuration]-[Advanced]-[Remote Control] and enable the
function.
Note
: the connection could be blocked by a firewall (open TCP port
4098).
4 - Error Message "VNC
Server not enabled on the remote terminal"
The
VNC remote control is not enabled at the thin client set-up level:
enter the
thin client set-up and go to
[Configuration]-[Advanced]-[Remote
Control] and enable the remote control option..
Note
: the VNC connection could be blocked by a firewall (open TCP
port 5900).
5
- A third-party VNC client can't take the remote control of an Axel
thin client
First check
the TCP port (by default the Axel VNC TCP port is 5900).
Then check the number of color. On the VNC cient side enable the 16bpp
or the full color options.
P7 - "Invalid
Firmware" Error When the Thin Client Boots Up
If the firmware download is interrupted the terminal can be left in a
state where you cannot enter the setup menu to download new firmware .
Power fluctuations or hardware failure can also cause the firmware to
become corrupted. To recover from this situation the following
procedure needs to be used.
Download and install on a Windows PC AxRM (Axel Remote Management). Run
AxRM and select 'Advanced Functions' 'Repair Device with bootp'
Enter serial number of 'faulty' terminal in box indicated. Enter IP
address to be allocated to terminal. (At this stage the Axel has no IP
address). Navigate the 'Firmware File' to firmware file (email Axel for
this 'FK.TCP.....'). Click 'Start bootp' button. Power cycle the
terminal.
What Actually Happens:
If the terminal cannot load its f/w it sends out a bootp request to
find a bootp server from which to download new f/w. Part of this bootp
request its own MAC address. Within the AxRM tool there is a bootp and
TFTP server. When AxRM's bootp server is started it listens for a bootp
request from the faulty terminal. It also knows the MAC address of the
terminal as you entered it - (It can work out the MAC address from the
terminal's serial number that you entered).
At this stage the terminal has broadcasted a bootp request containing
MAC address, and the PC is listening for a bootp request with specific
MAC address. Contact is made. The IP address is transferred, AxRM's
TFTP server is started, and the firmware file is automatically
transferred. You should see 20 or so lines of dots on the Axel screen
as the f/w transfers, the process takes about 30 seconds. Afterwards
the terminal will need setting up - it will have lost all settings.
If this doesn't happen please call Axel with any error messages given.
If you
haven't found your answer here please try the General FAQ page
|
