5 Replies Latest reply on Dec 3, 2010 8:56 AM by JoeBidgood

    GEM files??

      I am having some issues with one of my repositories where I am seeing about 500 machines that are showing a DAT version of 6149 after an uninstall and reinstall of VSE 8.7 hotfix 4 and a redeployment of MA 4.5 patch 3. I am using HTTP repositories at that site where the 500 machines are located and I noticed on that repository there are .gem files that start at 6149. Given that the current DAT version is 6183, is there anyway for my clients to start at a more current DAT instead of checking each .gem file before finally downloading the 6183 DAT?

        • 1. Re: GEM files??
          JoeBidgood

          That sounds like correct behaviour - the agent will go back as far as 35 incremental files before it requests the full zip file. 35 .gems should still work out cheaper in terms of bandwidth than the full zip...  or am I missing something? Are the machines not updating to 6183?

           

          HTH -

           

          Joe

          • 2. Re: GEM files??

            Ah ok, I was just thinking it might be more efficient to remove all but the last 5 or so GEM files and then when the updates start for the clients they wouldn't start clear back at 6149. And to answer you next question, no, I am currently at 523 workstations that are not updating and they are still reporting a DAT of 6149 and I have been sending update tasks to them for the past 24 hours...

            • 3. Re: GEM files??
              JoeBidgood

              Ah, OK, that sounds like a different problem

              On the client machines, check the agent and mcscript logs, and see if there is any indication as to why the update task is failing. (Post the files here if you like and we can take a look.)

               

              HTH -

               

              Joe

              • 4. Re: GEM files??

                Well, I think that I have found the issue and it appears to be one of my HTTP repositories. I ended up disabling the local repository and then sent my update tasks and the systems began updating without any issues when it grabbed the updated from the other repository.

                 

                Now my question would be, how to I go about getting a fresh copy of everything on the repository so that it will update its local clients properly? Can I just delete some of the shared folders that get updated during replication and then manually run a replication task to that repo to have it repopulate that folder? Or is there something more involved I need to do?

                • 5. Re: GEM files??
                  JoeBidgood

                  frostbitten wrote:

                   

                  Well, I think that I have found the issue and it appears to be one of my HTTP repositories. I ended up disabling the local repository and then sent my update tasks and the systems began updating without any issues when it grabbed the updated from the other repository.

                   

                  Now my question would be, how to I go about getting a fresh copy of everything on the repository so that it will update its local clients properly? Can I just delete some of the shared folders that get updated during replication and then manually run a replication task to that repo to have it repopulate that folder? Or is there something more involved I need to do?

                   

                  Nope, that method should work fine. If you want to be completely sure you can delete the entire folder structure of the offending repo and then perform a replication - that should replace everything. (Doesn't matter if you choose full or incremental replication - as it's effectively an empty repo the end result is the same.)

                   

                  HTH -

                   

                  Joe