5 Replies Latest reply on Jan 11, 2018 2:25 AM by phoffmann

    What's the bandwidth required by a PC to update the inventory in the core server?

    Rookie

      Hello

      What's the bandwidth required by a PC to update the inventory in the core server?

      Are there any official documentation regarding the  bandwidth required to the basic funcionallity of EndPointManager?

       

      Thanks a lot.

      Roberth

        • 1. Re: What's the bandwidth required by a PC to update the inventory in the core server?
          phoffmann SupportEmployee

          Not really, because "it depends".

           

          If you're sending a full, non-delta scan (for some reason - though it's unusual), scan can vary from 1 MB to 10+ MB in size. Run a an inventory scan with "/F /SYNC /O=myoutputfile.txt" on a representative device to know how big a "full size" scan is.

           

          This varies IMMENSLEY from account to account (and potentially by OS image). For instance, an "old" Windows XP device/image may have a LOT more clutter / software installed than a "nice and shiny" new Windows 10 image (for argument's sake). Or vice versa.

           

          Assuming it's "regular" scans, most delta scans tend to vary usually between 4 KB and 50 KB more or less. (You can turn on "Store Scans" to get an idea how much is thrown at your Core each day, as that'll take a copy of EVERY incoming file under "(...)\ManagementSuite\LDScan\Storage\").

           

          Here - again - is a case of "well - depends on how much changed since last the device sent a scan. If you send inventory scans regularly (such as - every day), chances are the delta scan will only need to be small. If you have some guy who only sends inventory 1x per month, chances are it's going to be bigger.

           

          There isn't much of a "line in the sand" that can be referenced here beyond the wildest generalisations. I've had customers where full on inventory scans were only about 1 MB in size (VERY tightly controlled desktop image), and others were regular desktops (not even file servers!) came in at over 10 MB on a sync scan (let's just say "not tightly controlled" environment).

           

          The vast majority of your inventory data is going to be software related.

           

          Does that help a bit / what's your real concern? I ask as it helps not having just "a part" of the question, but the entire context so that we can give better answers.

          • 2. Re: What's the bandwidth required by a PC to update the inventory in the core server?
            phoffmann SupportEmployee

            ... also moving this to the inventory section, since this isn't really related to agent deployment...

            • 4. Re: What's the bandwidth required by a PC to update the inventory in the core server?
              Rookie

              Thanks a lot for your answer.

              I understand that It's really complicated ensure the real bandwidth required because depend of any factors. But my customer request me that information to evalualate the impact the implement Ivanti in their network.

              • 5. Re: What's the bandwidth required by a PC to update the inventory in the core server?
                phoffmann SupportEmployee

                So - the best we can do is give "averages" (-ish) as general guide lines.

                 

                If they want a better idea, they can install a test Core and start installing a handful of agents on representative devices and store the inventory scans.

                 

                • A normal "first" / sync scan tends to be anywhere between 1-5 MB (for a desktop device), but can be quite a lot bigger for a server. File-servers in particular tend to reach over 10 MB easily.

                  A *LOT* here depends on how they configure things. They could (for instance) enable hash calculation for every file we find (to the end of using trusted hashes/files), but that adds a lot of size. And use of software monitoring does expand on the inventory too, for instance.

                  Similarly, just how clean (or "dirty") their image is, will affect the size of the inventory.
                • Then, on top of that, you've got usually anywhere between 2 MB to 5 MB (on average) of vulnerability data (if they use patch, which is usually a good idea).
                • Overall (with other eventing data), an AVERAGE device is usually around 5 - 10 MB of data in the database. (Again a lot depends on what they use & how they configure things).

                • And then there's frequency. If they send an inventory / security scan every hour on the hour, well - that's a LOT more data than if they send it 1x per day / 1x per week or whatnot. All these things are configurable (for a reason) and we're pretty good at "playing nice" with the network. It's in fact one of our chief considerations in most things we do (hence - peer download, preferred servers, etc).
                • Now - after the initial scan, things quieten down a lot. Inventory gets sent as DELTA-s ... (we're working very hard in being light & nice to your network) and/or compressing stuff before sending it on the wire. For instance - vulnerability scans are always "non-deltas" but we compress them before sending them out & they're decompressed on the Core before they get processed.
                • Find out what exactly your customers' concern / question is ... if it's a fear of "EPM/LANDesk will eat/crash my network", then that is rather unlikely, unless it's already teetering close to the edge.
                • If they want detailed information on how much data we send in THEIR environment, the only relevant data will be by setting up a test Core.

                 

                People can configure themselves either INTO or out of a LOT of trouble based on their config alone. But - every customer *IS* different.