looks OK..... but no cigar!

Timed Out means that the server can´t send the backup order. If you can browse the clients but that backups can´t start, check bidirectional traffic on port 29000 which is the SSH port used to send/receive backup data

The following message is coming up for each client ::--->

"30902: Activity failed - client was given a workorder but did not acknowledge its receipt"

The client doesn't even see the restore start so the delay is totally within the grid iteself.

This isn't necessarily true. By this point in the process, the workorder has already been generated and placed on the Administrator Server's "green list". If it takes longer than 5 minutes for the agent on the client to receive the workorder, process it and return an acknowledgement to the Administrator Server, the job will be timed out.

While this can happen if the Administrator Server is heavily loaded and "misses" the acknowledgement of the workorder, it doesn't sound like that was the issue in the specific instance you've mentioned here. I say this because restoring a single directory will generate a much smaller workorder than restoring thousands of individual files and larger workorders take longer to process on the client side.

For issues with clients failing with "Timed Out - Response", a review of the avagent.log file from the affected clients will provide more information about whether the workorder was received, processed and acknowledged.

Another possible cause of this error is if your restore selection contains a very large number of individual files.  I was attempting to restore several tens of thousands of exchange log files via windows filesystem plug in and got the same error.

Apparently the restore list takes too long to load, a 5 minute time limit is reached and it times out the job without recieving the acknowledgement.  The client doesn't even see the restore start so the delay is totally within the grid iteself.

to get around the problem I had to restore at the directory level and then just ignore/delete the files I did not want after the restore. 

an inspection of the log showed activity from hours before the restore request, but nothing since then up to the time the restore was requested. avagent.log on the client had no logging activity from the restore, so it still appeared that from the clients perspective it never recieved the request.

If there was no indication in the logs that the workorder was received by the agent, that does make it less likely that the client was the culprit. In the absence of any messages about the workorder in avagent.log, a look at the MCS logs might provide more insight but I generally recommend engaging support if it reaches that point. I'm afraid the MCS logs aren't particularly friendly.

I was getting this a well.

If you do an on demand backup of the client from the GUI using the same Policy/group as your auto backup does it work?

it could be than that too many jobs are starting at once.

if a manual backup works but on the group - try braking them into two groups with different start times say 15 or 30 minutes between and see if they start then.