8 Replies Latest reply on Aug 30, 2013 10:19 AM by petersimmons

    Extending "Agent to server" communication time...

    DarrenFord

      Hi All,

       

      We run a large environment with around 36000 devices. We have been experiencing bursts of traffic on the hour an are looking at extending the comm time from 1 hour to 6 hours.

       

      Has anyone got any thoughts regarding this , Pros vs Cons.

       

      Thanks

       

      Message was edited by: DarrenFord on 8/26/13 6:49:41 AM CDT
        • 1. Re: Extending "Agent to server" communication time...
          JoeBidgood

          Hi...

           

          The agent doesn't schedule its communication at a specific time, but rather after a specific elapsed time after it starts - so it may not be down to agent/server comms (unless of course you definitely know that it is )

          The agent also picks a random 10-minute window for its first communication, so even if all your users came in and switched their machines on at exactly 9am, I'd expect to see a spread of traffic from the top of the hour until ten past. It's a pretty unlikely situation though.

           

          Definitely try changing the ASCI to two hours, for example. If the burst pattern changes to every two hours, then we'll know that this was the cause.  I'm wondering if it might be a task, though, as these run at a specific time and so are much more likely to produce time-specific traffic spikes. Do you have any tasks configured for the clients that could account for this?

           

          HTH -

           

          Joe

          • 2. Re: Extending "Agent to server" communication time...
            DarrenFord

            Thanks a mil ! Here are the client tasks I have setup...

             

            1.         McAfee ePO Client tasks

             

             

            1.1.       DeployMcAfee agent 4.8 (every policy enforcement)

              Upgrade ofMcAfee agent from earlier versions.

            1.2.       DeployVSE 8.8 to workstations (daily 7pm – 7am)

            Deployment ofVirusScan 8.8 to ALL workstations in PBB this will upgrade any devices still onearlier versions.

            1.3.       Signatureupdate 7th day (Sunday)

            Signature updates which runs on a Sunday.

            1.4.       Signatureupdate offline day (daily 7pm –7am)

            Main signature update task which runs during offlineday.

            1.5.       Signatureupdate at logon

            Signature updatewhich runs at logon of any device, this is primarily to target laptop users. (Bestpractise)

            1.6.       Signatureupdate at Start-up

            Signature updatewhich runs at start-up of any device, this is primarily to target laptop users.(Best practise)

             

            1.7.       Virusscan8.7\8.8 ODS scan (11pm)

            Full on demand scan of workstations andservers in PBB.

            1.8.       Virusscan8.7\8.8 memory and process scan, workstations (3pm)

            Daily memory and process scan which only runson workstations.

             

                   Virusscan 8.7\8.8 memory and process scan, Servers (8pm)

                        Daily memory and process scan which only runs on workstations.

                     

            6.10     Wakeup 3 Hourly

                        Agent wakeup of all devices every 3 hours.

             

            6.11      Wakeup at logon

                        Wakeup of devices which have just logged on.

             

            6.12     Wakeup at start-up

                                 Wakeup of devices which have just started up.

            • 3. Re: Extending "Agent to server" communication time...
              pankajs

              Hi Darranford,

              I was also facing same issue.I resolved this issue by removing agent wakeup task.

              agent wake task connect to you ePO server and client send system info to ePO server since you have thousand of systems in your environement defently you will face this issue.

               

              Please remove the Agent wakeup Task and check you will find some releaf.

              • 4. Re: Extending "Agent to server" communication time...
                dcobes

                That would depend which option he has checked. In the wake-up tasks, you have the option to perform a FULL wakeup or just send to ePO those things that have changed since the last communication.

                • 5. Re: Extending "Agent to server" communication time...
                  DarrenFord

                  Hi there all,

                   

                  All three wakeups are set to only collect properties which have changed.

                  • 6. Re: Extending "Agent to server" communication time...
                    JoeBidgood

                    I'd definitely look at the wakeup tasks as possible culprits - but before anything else, can we narrow down the traffic bursts that you're seeing? Is it primarily to the ePO server on the agent/server communication port - 80 or 443 by default?

                    If so, then check the server.log on the ePO server during one of the peaks - what sort of activity are you seeing? If it's primarily properties, policies, and so on, then the agent wakeup call is probably the problem. If it's primarily repository traffic then it's more likely to be the update tasks, and you might want to consider distributed repositories to take the load off the master repo.

                     

                    HTH -

                     

                    Joe

                    • 7. Re: Extending "Agent to server" communication time...
                      Jonesthemilk

                      Wouldn't 36,000 nodes running thro one epo Server be a bit OTT anyway?

                      I'd certainly invest in some DR's or even Agent Handlers, bandwidth permitting?

                      • 8. Re: Extending "Agent to server" communication time...
                        petersimmons

                        I don't see the point of the following tasks 1.5, 6.10 and 6.11. You have a lot of redundancy in those. Consider disabling those first.

                         

                        Also make sure most of your tasks include a randomization within them.

                         

                        You only need a single DR to offload the update stuff from the ePO server. Going nuts standing up respositories is always counterproductive. 36K isn't hard to balance properly.