TSM Client problem (ANS1017E)

chris_magic

ADSM.ORG Member
Joined
May 17, 2007
Messages
178
Reaction score
0
Points
0
Location
Quebec, Qc, Canada
Hello,

I am a newbie on TSM. I use the version 5.4 of TSM on a Windows 2k3 server 32bit.
My clients are Windows 2k3 server 32&64 bit.
I have to deploy my clients everywhere and the clients are on different subnet and of this fact I use a firewall.

I have a problem for the clients communicating by the firewall.
On the firewall the port 1500, 1501 and 1581 are open from the server to the client. I'm able to make a telnet with this port from the server to the client.

You can see the dsm.opt file of my clients:

PASSWORDACCESS GENERATE
DOMAIN C:
DOMAIN SYSTEMSERVICES
DOMAIN SYSTEMSTATE
DOMAIN ALL-LOCAL
COMMmethod TCPip
TCPSERVERADDRESS 172.21.204.46
TCPPort 1500
TCPCLIENTADDRESS 172.21.208.14
TCPCLIENTPORT 1501
SCHEDMODE PROMPTED
TCPADMINPORT 1501
SESSIONINITIATION SERVERONLY
MANAGEDSERVICES WEBCLIENT SCHEDULE
REVOKEREMOTEACCESS ACCESS

I have a got a message of error indicating to me that they have a communication TCP/Ip failure and in the DSMError.log file I have got this:

05/16/2007 10:09:10 ANS5216E Could not establish a TCP/IP connection with address '172.21.204.46:1500'. The TCP/IP error is 'Unknown error' (errno = 10060).
05/16/2007 10:09:10 ANS4039E Could not establish a session with a TSM server or client agent. The TSM return code is -50.
05/16/2007 10:09:10 ANS1017E Session rejected: TCP/IP connection failure

I will need your assistance because I don't find the solution in spite of many tests.
I am at your disposal if you wish more precise information.

Christophe
 
Well first and foremost, can you ping (or traceroute) the TSM server from the TSM client?

Then depending on the rule in the firewall, I'd check the logs to see what is happening to traffic once it gets to the firewall. We have a similar issue but our rule is specific to server initiated. So schedules have to be set to prompted.
 
No, I'm not able to ping or traceroute the server from the client. It's blocked by the firewall.

Normaly if you open the right port from the server to the client you're able to start schedule.
The schedule is set up to prompt.

Well first and foremost, can you ping (or traceroute) the TSM server from the TSM client?

Then depending on the rule in the firewall, I'd check the logs to see what is happening to traffic once it gets to the firewall. We have a similar issue but our rule is specific to server initiated. So schedules have to be set to prompted.
 
Is the rule restricting traffic in one direction and not the other? Can you ping the server from the client or the client from the server?

I would assume with the ports open in the firewall, that you'd be able to ping the TSM server from the client, if not your schedule obviously wont pick up. You may also want to try via IP instead of DNS name, and have your firewall admin check the range of IPs those ports are open for.

Try telnet xxx.xxx.xx.xx 1580 or either of the other two ports to further test your connectivity, however if you cannot ping (unless its turned off) you will likely not be able to do these commands either. In that case, Id try to start the dsmc to see if it gets through, and do a q sched or even just authenticate to the TSM server.
 
Yes, I'm able to ping the client from the server but not in the opposite direction.
I'm able to make a telnet from the server to the client by the different port.

Is the rule restricting traffic in one direction and not the other? Can you ping the server from the client or the client from the server?

I would assume with the ports open in the firewall, that you'd be able to ping the TSM server from the client, if not your schedule obviously wont pick up. You may also want to try via IP instead of DNS name, and have your firewall admin check the range of IPs those ports are open for.

Try telnet xxx.xxx.xx.xx 1580 or either of the other two ports to further test your connectivity, however if you cannot ping (unless its turned off) you will likely not be able to do these commands either. In that case, Id try to start the dsmc to see if it gets through, and do a q sched or even just authenticate to the TSM server.
 
If you can get to the client from the server, but not the other way, I'd say have a look at the firewall rules. If you need to limit the traffic so its initiated internally and then is allowed from the external IP thats possible too using the prompt schedules, but the rule in the firewall has to reflect that.
 
try to read webports option on the client manual

DSM.OPT for Windows & DSM.SYS for UNIX/LINUX must have the option
webports 2123 2124
and of course open ports 2123 2124 on the firewall.
the port numbers depends on which port is available. those 2 examples are the default port numbers.
 
you have some Firewall wichi will only allowed the flux in one drirection,

so confirm on your firewall if the flux is opened in the right direction
client 1500 ==> TSM server
TSM Server ==> 1501 client

and of course if you want to use the webinterface you got open the Webports too
 
For the moment I opened the port 1500 & 1501 in the two directions.
I don't have any more the message of error:"connection refusal" but
I obtain the message of error:"connection refused - password
has expired"

I updated the password by the console of administration of the TSM Server. Moreover on the Client, I carried out this command line: dsmcutil updatepw /node:XXXXXX /password:xxxxx /validate:no
I stopped the services on the Client and then I started again them.

you have some Firewall wichi will only allowed the flux in one drirection,

so confirm on your firewall if the flux is opened in the right direction
client 1500 ==> TSM server
TSM Server ==> 1501 client

and of course if you want to use the webinterface you got open the Webports too
 
Back
Top