Thnaks - kind of guessed it "must be" - just doesn't seem that "logical" to me as it would (IMO) make more sense for the clinet to be comparing it's s/w versions with it's designated repository and updating from them irrespective of the Master Repo Contents. - but "Hey Ho"
I agree... it doesn't make much sense, the only explaination I have see (which isn't really logic) is that the issue is the catalog file being out of sync... that's what causes the agents to give the cannot find vaild repository message.
What's happening here, as someone else said, is that the agents think the distributed repos are out of date. The agents know the timestamp of the master repo because they receive it when they talk to the server. When they run an update, the first thing they do is check that version against the repo that they are using and if it is older than the master version that they have, they will reject the repo.
The important point is that *any* change to the master repo will modify its timestamp - so if you check in a new product, remove one, or move something from one branch to another, then you must replicate to the distributed repos before the clients will accept them.
So-called "local" repos (which are defined in the agent policy, and are not replicated to by the ePO server) are exempt from this check, which may be a way round the issue if it's a big problem for you...
Hmmm... must be something else then happy I've just done a quick test and pulling to the eval branch will certainly cause the master catalog version to be updated and the clients to reject the distributed repos until they are replicated to.
One point is that the clients effectively have a window in which they will still accept a distributed repo, even if in theory it's out of date. Because the clients get the master catalog version from the epo server, then between the time that you modify the master repo and the next time that the client contacts the server and gets the updated master catalog version, that client will still accept the distributed repos.
You can tell if you're dealing with this issue by looking in the mscript.log (or the agent_machinename.log if it's CMA 3.6) - if it is this issue you'll see messages like "<repo_name> is not up to date site. Catalog version <foo> < <bar>"
Thanks Joe - but that the error was the "unable to find a valid repository" that was being reported in the renote agent logs - initially on CMA3.6 but also on MA4.0.
We've "worked around" it for now by modifying the overnight pull times but it's "annoying" wink - up until we noticed this following a DAT update schedule change - I'd only ever seen this whne clienst tried to update "during" a replication interval and had assumed it was due to the repository being locked during the replication.