-----Geoff Gill  <ADSM-L AT VM.MARIST DOT 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.