-----Geoff Gill <ADSM-L@VM.MARIST.EDU> wrote: ----- >What we have are 2 windows clients, one on 5.3.4.0 and another on >5.3.4.8. Both of these clients consistently show missed, yet you can >restart the scheduler service and it will communicate and pick up >the schedule. The log on the client shows no attempt to start and >the TSM server only has the standard messages when the attempt to >contact a client fails. Gui and command line access from the client >work just fine. > >I've asked those folks to verify certain things but have not heard >back so I thought while waiting for a response I'd throw this out >there. Besides the standard NIC/switch mismatch, which I have seen >cause this, is there something DNS wise that might cause this and >does anyone have any suggestions for other things to check?
We see this kind of behavior because of firewalls. In some cases the firewalls are dedicated systems controlling traffic between subnets. In other cases the firewalls are software running on the TSM client systems. When the client scheduler service starts up it attempts to bind to a TCP port specified by the tcpclientport option. If this port is not available the client software searches for an unused port to bind to. Once a suitable port is found the scheduler service connects to the TSM server and reports the port number. When the time comes to run a backup the server attempts to open a connection to the port on which the scheduler service is listening. It is fairly common at our site for a firewall to blockthe server to client connections when a new client is first set up.
