Another thing I've done in cases like this is temporarily switch from prompted 
to polling mode.  That's usually easier to get working, as it eliminates a 
couple of the problems, like incorrect/changed IP address, and needs only 1 
port in the firewall (1500).

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of 
Vandeventer, Harold [BS]
Sent: Monday, November 21, 2011 9:18 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] Windows 2008 client ..TSM schedule won't run

Good details from Richard.

Are all the clients on the same remote network segment?

We had a case once where an agency setup new clients, but put them on a 
different network segment.  Firewall became the issue, again, even though the 
firewall mgr said "not the firewall."  The FW manager didn't know there were 
new IPs involved.

We also had a case where the client name in the DSM.OPT file did not exactly 
match the name as known by TSM server.  The node manager had worked on the 
node, and somehow modified the name (a typo) in the opt file.  




------------------------------------------------
Harold Vandeventer

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of 
Hughes, Timothy
Sent: Monday, November 21, 2011 6:14 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] Windows 2008 client ..TSM schedule won't run

Thanks Richard for this information.




-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of 
Richard Sims
Sent: Sunday, November 20, 2011 6:33 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Windows 2008 client ..TSM schedule won't run

Timothy -

Those direct peer logs were just what were needed... Rather than showing 
"nothing", they reveal the absence of something, that being network 
connectivity between the TSM server and client, at least at the midnight hour. 
The client has initialized CAD to listen on port 1500, and the server is trying 
to connect to client port 1500. If the CAD process is still extant at midnight, 
the situation may indicate a network blockage preventing communication. Another 
situation that can arise in prompted schedules is where the client's network 
address has changed: the TSM server's scheduling will attempt to use the last 
address it had for the client, which may now be defunct. (An exception is where 
the node is registered with an HLAddress.) Further note that the 2716 message 
reflects the TSM server using an IP address for the client communications 
attempt: if the client's network name is the same, but its IP address has been 
changed in its DNS entry, there you have another factor.

What I would do:  As a privileged admin on the client, perform a command like 
'dsmc q inclexcl', to test communication with the server, in the "upward" 
direction. This will also refresh the server's knowledge of the client address. 
Now go to the TSM server and issue command Define Clientaction to perform an 
innocuous OS command. (In Unix, I like to use 'touch /tmp/tsmclientaction' as 
the command, to leave solid evidence of contact, if successful.) Wait a while 
for the Define Clientaction to perform, then check the TSM Activity Log to see 
what happened. If still no server->client communication, firewall adjustments 
may be needed.

In this situation, changes to dsm.opt will have no remedial effect.

    Richard Sims