Thanks
I performed the 'dsmc q inclexcl' to test communication information as Richard
suggested I got a successful communication I believe. (this is the only one
left to fix see below)
Session established with server TSM: AIX
Server Version 6, Release 2, Level 2.0
Server date/time: 11/21/2011 10:47:31 Last access: 11/21/2011 10:26:23
*** FILE INCLUDE/EXCLUDE ***
Mode Function Pattern (match from top down) Source File
---- --------- ------------------------------ -----------------
Excl Directory *\...\History.IE5 Server
Excl Directory *\TEMPORARY Server
Excl Directory *\I386\ Server
Excl Directory *\RECYCLER Server
Excl Directory *\RECYCLED Server
Excl Directory *\...\Temporary Internet Files Server
Excl Directory *\System Volume Information Server
Excl Directory *\...\.TsmCacheDir TSM
Excl Directory c:\Windows\system32\microsoft\protect Operating System
Excl Directory \\?\Volume{d7559fa6-87ef-11e0-9592-806e6f6e6963}\Boot Operating S
ystem
Excl Directory C:\Windows\winsxs Operating System
Excl Directory C:\Windows\Vss\Writers Operating System
Excl Directory C:\Windows\Tasks Operating System
F.Y.I -
One of the two clients with the remaining issues backed up successfully last
night
Notice I had commented out the TCPCLIENTADDRESS which someone suggested wasn't
really needed.
With this edited dsm.opt file this client worked
LANG AMENG
DOMAIN ALL-LOCAL
TCPSERVERADDRESS xxxx.xxx.xxxx.xx.xx
PASSWORDACCESS GENERATE
*TCPCLIENTADDRESS 516.3.x.x.100
tcpclientport 1501
Webport 1552 1553
HTTPport 1581
TCPport 1500
NODENAME caplira
However this backup did not work ( noticied left the TCPCLIENTADDRESS
126.2.2.188 in)
LANG AMENG
DOMAIN ALL-LOCAL
TCPSERVERADDRESS xxxx.xxx.xxxx.xx.xx
PASSWORDACCESS GENERATE
TCPCLIENTADDRESS xxx.x.x.xxx
NODENAME malina22
tcpclientport 1501
Webport 1552 1553
HTTPport 1581
TCPport 1500
Wanda
Thanks again Harold, Richard and Wanda
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of
Prather, Wanda
Sent: Monday, November 21, 2011 10:48 AM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: Windows 2008 client ..TSM schedule won't run
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@VM.MARIST.EDU] On Behalf Of
Vandeventer, Harold [BS]
Sent: Monday, November 21, 2011 9:18 AM
To: ADSM-L@VM.MARIST.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@VM.MARIST.EDU] On Behalf Of
Hughes, Timothy
Sent: Monday, November 21, 2011 6:14 AM
To: ADSM-L@VM.MARIST.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@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
