6 Replies Latest reply on Sep 22, 2010 12:30 AM by Attila Polinger

    Disabled repositories get re-enabled on client after ePO 4.5 P3 upgrade

    Attila Polinger

      Hello,

       

      just briefly: ePO 4.0 P7 to ePO 4.5 P3 was successful. MA extension version is 4.5.0.171. Three repositories in MA policies: two distributed showing as disabled, one fallback. (We want it this way.)

      MA version on client are 4.0.0.1494. No problem showing in agent log enforcing MA policies. However the above two distributed repos show on client as enabled and really they are, clients are using them.

       

      Tried enabling and disabling the above two repos with Save commands between the operation, then issued a wakeup call with Force complete policy and task update option selected. No change on clients.

       

      Any idea how to fix this?

       

      Thank you in advance.

       

      Attila

        • 1. Re: Disabled repositories get re-enabled on client after ePO 4.5 P3 upgrade
          jmcleish

          Hi Attila,

           

          I had a similar issue- check out thsi post and follow Joe's advice about creating a dummy repo to see if that helps.

          https://community.mcafee.com/message/144721

           

           

          Cheers

           

          Jane

          1 of 1 people found this helpful
          • 2. Re: Disabled repositories get re-enabled on client after ePO 4.5 P3 upgrade
            Attila Polinger

            Hi Jane,

             

            Thank you for your response!

             

            I created a dummy distributed repository in Software - Distributed Repositories menu and checked if it appeared in the master sitelist, it did (disabled). Then deleted this repo and checked if it disappeared from the master sitelist (it did).

            Did a client wakeup call but alas, the clients did NOT receive an updated sitelist (not any sitelist at all).

             

            I checked the client sitelist's "Local version" XML tag and also that of the Sitelist.XML on ePO server in Program Files\McAfee\ePolicy Orchestrator\DB and the two matched. Which means that I could not get the sitelist timestamp updated, even I created a dummy distributed repository and deleted it in separate sessions (I Save'd the changes in between).

             

            Could you please list your steps in the same issue when your problem just went away (even if I seemed to have performed the same) ? Thanks!

             

            Attila

            • 3. Re: Disabled repositories get re-enabled on client after ePO 4.5 P3 upgrade
              jmcleish

              I think i did it initally but didn't click the save inbetween the steps (step 2).

               

              I redid the steps actually saving it inbetween and then waited and when i check the clients they seem to be working again. Although i don't think an agent wakeup worked initially either- maybe have to wait for a scheduled agent-server comms (?? clutching at straws here)

               

              Jane

              • 4. Re: Disabled repositories get re-enabled on client after ePO 4.5 P3 upgrade
                Attila Polinger

                Dear Jane,

                 

                I tried the workaround twice more : I created a dummy distributed repo, woke up an agent and the new sitelist has arrived at the client successfully and now I can see the disabled dummy repo on the client beside the other two repos that are still enabled.

                 

                I then even modified one of the distributed repo and deleted the dummy, and pinged a client, a modified sitelist was also downloaded to the client, but still, the distributed repo is enabled on the client (while showing as disabled in the ePO policy on the server, this is crazy)

                 

                The client has MA 4.0.0.1494.

                Are you sure that the workaround for you worked for the above version of MA ?

                 

                Attila

                • 5. Re: Disabled repositories get re-enabled on client after ePO 4.5 P3 upgrade
                  jmcleish

                  Hi Attila,


                   

                  I then even modified one of the distributed repo and deleted the dummy, and pinged a client, a modified sitelist was also downloaded to the client, but still, the distributed repo is enabled on the client (while showing as disabled in the ePO policy on the server, this is crazy)

                   

                  What are you looking at to see if the repo is still enabled- I think i had to actually had to go into the UI and look there as i think it maybe still said it was enable on the client in the sitelist file (obviously something somewhere i don't understand)

                   

                  And yes- it was for that agent as most of my clients are on that agent and i checked the agent version as i was going to update.

                   

                  Sorry i can't be much more help.

                  Jane

                  • 6. Re: Disabled repositories get re-enabled on client after ePO 4.5 P3 upgrade
                    Attila Polinger

                    Hi Jane,

                     

                    I've made a support call and managed to get this escalated and the cause of the issue was so simple you'd never believe it. A previous bug that should have been corrected with Patch 3 for ePO 4.5 still prevailed somehow and when you used a distributed repository with a space or accented characters in the name, this produced this issue.

                     

                    The resolution was to eliminate spaces and accented characters from the name(s) of any distributed repositories. Then the repository got correctly disabled.

                     

                    Attila

                     

                     

                    Message was edited by: Attila Polinger on 9/22/10 7:29:52 AM CEST

                     

                     

                    Message was edited by: Attila Polinger on 9/22/10 7:30:53 AM CEST