Harold, Richard, Gary and Wanda (and everyone else who replied)

Now all four Windows 2008 Servers are completing successfully the partial 
dsm.opt is below all I did was comment out the TCPCLIENTADDRESS line (on two of 
the servers dsm.opt file)

*TCPCLIENTADDRESS xxx.x.x.xxx

Before that I did put in the following

tcpclientport 1501
Webport 1552 1553
HTTPport 1581
TCPport 1500


LANG AMENG
DOMAIN ALL-LOCAL
TCPSERVERADDRESS xxxx.xxx.xxxx.xx.xxs
PASSWORDACCESS GENERATE
*TCPCLIENTADDRESS xxx.x.x.xxx
NODENAME xxxxxxxx
tcpclientport 1501
Webport 1552 1553
HTTPport 1581
TCPport 1500
Errorlogname c:\progra~1\tivoli\tsm\baclient\dsmerror.log
SCHEDlogname c:\progra~1\tivoli\tsm\baclient\dsmsched.log
Errorlogretention 14
schedlogretention 7
LARGECOMMbuffers  yes
changingretries 2
subdir yes
txnbytelimit 25600
tcpb 32
tcpw 63
tcpnodelay yes
schedmode prompted
replace prompt
*exclude "*:\MSSQL\DATA\MSSQL.1\MSSQL\Data\*.*"
MANAGEDSERVICES WEBCLIENT SCHEDULE



However, here is another dsm.opt from one of the 4 that was missing (but now 
the backup is completing successfully) and I did not have to comment out the 

TCPCLIENTADDRESS xxx.x.x.xxx

and I DON'T have the following.

Webport 1552 1553
 

I am still confused because on this one I have the following.

tcpclientp 1581 and not >>>> HTTPport 1581


LANG AMENG
DOMAIN ALL-LOCAL
TCPSERVERADDRESS xxxx.xxx.xxxx.xxx
TCPCLIENTADDRESS xxx.x.x.xxx
tcpclientp 1581
webports 1500 1501


this one looks like this

LANG AMENG
DOMAIN ALL-LOCAL
TCPSERVERADDRESS xxxx.xxx.xxxx.xx.xx
webports 1500 1501 1552 1553 
tcpclientp 1581

Thanks  for all your help!

Regards
-----Original Message-----
From: Hughes, Timothy 
Sent: Monday, November 21, 2011 11:40 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: RE: Windows 2008 client ..TSM schedule won't run

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 AT VM.MARIST DOT EDU] On Behalf Of 
Prather, Wanda
Sent: Monday, November 21, 2011 10:48 AM
To: ADSM-L AT VM.MARIST DOT 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 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