8 Replies Latest reply on Sep 14, 2009 6:15 AM by jmaxwell

    Unable To Find a Valid Repository....


      Can someone explain to me if/why the following behaviour is "expected" ?

      I start off with all Distributed Repostories "synced" with the ePo Master Repository.

      I then pull down the overnight updates via scheduled server task directly into the "Current" Repository Branch of the Master Repository.

      Any clients that now try to update their AV DAT files now fail with an "Unable to find a valid Repository" message.

      The clients the won't update now until the Distributed Repositories are "Resynched" with the Master Repository.


        • 1. RE: Unable To Find a Valid Repository....
          Yes this is normal behavior. If the repositories aren't synced with the master, that will be the message on the clients agent logs.
          • 2. RE: Unable To Find a Valid Repository....
            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" :(

            Anyone seen this "logic" documented anywhere ?

            • 3. RE: Unable To Find a Valid Repository....
              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.

              Never thought it made sense either.
              • 4. RE: Unable To Find a Valid Repository....
                LOL - glad it's just not me who thinks it's "odd" :D

                • 5. RE: Unable To Find a Valid Repository....

                  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...
                  • 6. RE: Unable To Find a Valid Repository....

                    I don't believe that logic is quite correct since pulling overnight into the Evaluation Branch doesn't cause the problem....

                    • 7. RE: Unable To Find a Valid Repository....

                      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>"

                      HTH -

                      • 8. RE: Unable To Find a Valid Repository....
                        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.