Thanks Richard for this information.
-----Original Message----- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Richard Sims Sent: Sunday, November 20, 2011 6:33 PM To: ADSM-L@VM.MARIST.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
