I've seen this really only on large bundles, that contain a file over say a few hundred MB in size.

Working on a Adobe Acrobat Pro 9 bundle. I zip up all the required installation files and I have a zip of about 890MB or so. The bundle copies the file down, extracts it, then runs the MSI. I do this for most of my apps nowadays since ZCM is so bad at handling large numbers of files. I've gotten used to this method and it's worked in the past for my app pushes over ZCM.

Anyway, for a modest sub-100MB bundle this is no big deal as the bundle appears to be pushable just after a few minutes. For the big bundles this timing can take quite a while. I haven't timed it to the second but it seems to take upwards of an hour before a large bundle is ready to be pushed without error. Any attempts to refresh a client too early result in the classic...

Failed to process action: Information for id %LONGSTRING% has not been cached.

error that I've grown to hate.

Is this normal behavior? Something to do with internal placing of data in the content-repo? Can this be monitored in anyway or are my hands tied and I just have to keep retrying a refresh on my clients until ZCM decides the bundle is ready?

There are only maybe 10-15 users connected to the ZCM server at this time, we are just now ramping up it's usage slowly as we push out new Windows 7 clients over this summer.