6 Replies Latest reply on Dec 14, 2009 10:20 AM by mrpg

    Anyone managing 7000+ clients?

    mrpg

      Just wondering if in a situation where you're managing over 5, 6, 7, 8000 clients- if it's crazy to have one ePO server or is having agent handlers spread across your clients a must?  I'm in a process of going from managing 300 clients one 3.6 server to managing 7600 on 4.5 right now and ultimately having approx 11,000 by March.

       

      What I don't want is a situation where management of these clients becomes unstable.

       

       

       

      Thanks

       

       

      Message was edited by: mrpg on 12/10/09 8:25:43 PM GMT-05:00
        • 1. Re: Anyone managing 7000+ clients?
          GWIRT

          ePO will handle 100,000 nodes just fine (as long as you have the right hardware), 11,000 should be no problem. You probably won't need an agent handler, but I would recomend a few distributed repositories.

          • 2. Re: Anyone managing 7000+ clients?
            rphillips

            Im curious as to how you have your IT dept setup to Handle these.

             

            Are you Going to have 1 Specific Administrator overseeing the ePO daily and or spread out to multiple people etc.Im curious as to how other IT depts are utilizing and managing ePO there systems and there setups..

             

            Back to your question we will have about 5000 Endpoint Users and we have 1 Agent Handler in the DMZ handling our external on te road clients etc....

            • 3. Re: Anyone managing 7000+ clients?

              Hi

               

              Until July this year i operated about 13000 clients (XP, 8.0, 8.5) by a single ePO 3.6.1 and the DB on the same server (W2K3 SE, VmWare ESX) without any Problems. I used three distributed repositories (HTTP, FTP, UNC) on the same server and also the same on a particular server.

              From August a new Domain was getting productiv for Vista Clients (VSE 8.7) and i prepared a new ePO (W2K3, VmWare ESX, starting with 4.0, now 4.5, actually 2500 Clients) using dedicated DB Services on particular Server and Distributed repositories (HTTP, FTP, UNC) on the same Server. No problems until now.

              The XP Clients (12000) i brought up to VSE 8.5 and moved them to a new ePO (W2K3 R2 EE, VmWare ESX, starting with 4.0, actually 4.5) using dedicated DB Services on particular Server and Distributed repositories (HTTP, FTP, UNC) on the same as well as on a separate Server. No problems until now.

               

              Markus

               

               

              Nachricht geändert durch vaccinator on 14.12.09 04:18:44 CST
              • 4. Re: Anyone managing 7000+ clients?

                We have three ePO 3.6.1 servers, the biggest one is looking after 45K machines without breaking a sweat.

                 

                The sizing should take a couple of important factors into account, some main ones are;

                - Which products will be managed. The more products managed the higher the load on ePO

                - The ASCI interval. Turning it down to 2-4 hours will ease the burden

                - Event filtering. Do you really need to know the stop and start time of every scan job? Cookie detections? Etc etc.

                 

                By paying attention to what is going on with both the ePO and SQL DB we have managed to cut down the overhead to a manageble point.

                 

                Matt

                • 5. Re: Anyone managing 7000+ clients?
                  mrpg

                  Sounds good- I'll have to check my filtering options again- I've only unchcecked about 15 or so from whatever is select out the box.  Currently with 7000+ clients my ASCI is set to 90 minutes.  

                   

                  To answer Brad's questions-  currently I'm the sole ePO guy really.  Eventually when things are set and we're manaing 90-100%, the plan is to bring in a backup pool of 1-3 people.

                  • 6. Re: Anyone managing 7000+ clients?

                    I found the most efficent way was to do a top ten query on the events table by event ID grouped by week or month. It quickly gives you an idea of where the bulk of the events come from.