When a prompted mode B/A client contacts the server the IP address is
"registered" and stored on the server. When it is time to prompt (ping)
that client, the IP address is used. If the IP address changes for that
client, then the client must be stopped and re-started in order for the new
IP address to be "registered" with server. This is the only way the server
can know about new IP address. Polling mode clients are not registered with
the server. Also, if a "prompted" mode client is changed to "polling" mode,
the IP address is removed from the server registration table.

Failed schedule causes: 1) The fact that one or more files get skipped
or for some reason get marked as failed, when other files have succesfully
been backed up does NOT cause the schedule to be marked as failed. Any many
cases where a client backup thousands of files ther may be files for which the
backup failed. It would not make since to fail the schedule since in fact
the schedule was executed and the client completed its backup. This is why
there are sched and error logs for the client. These errors are different
than a schedule error. 2) At the end of the start duration for a given
schedule, the schedule manager looks for nodes associated with the schedule
which never "started" (probably caused by the client scheduler not being
active at the known IP address). These get marked as "missed". At the same
time this "check" is performed the schedule manager also checks for nodes
which are in a "started" or "re-started" state. For these nodes, there is
check done to determine if there is an active session for the node/schedule
combination. If there is no session (most likely caused by some sort of
timeout) then the schedule is marked as "failed" in the server schedule
event table. Here is the "catch": Although the client may-reconnect after this
time and complete the activity, the event table will NOT be updated to note
this. This case is what most administrators might be seeing. There has to be
some sort of garbage cleanup for clients that never do re-connect.
If you see a lot of this, you should consider updating your IdleWait and
commtimeout periods to longer values. Also consider a longer duration for
the schedule.
 While the duration is used for a start period and not the time the scheuled
activity must comlpete in, the end of the duration is used as a sanity
check for prompted sessions that have "disappeared".

Tom Brooks
ADSM Server Devlopment