Client Management Suite

Expand all | Collapse all

Throtling Settings

  • 1.  Throtling Settings

    Posted 03-30-2020 06:51 AM
    Hi All,

    Can someone recommend some throttling setting for these times when every VPN is being hammered. We are seeing massive issues when the agents are communicating and this is destroying our network. Id still like to be able to send out patches and software but cannot have it kill the connections.

    Any advice would be greatly appreciated.

    Thanks

    Andrew​

    ------------------------------
    Andrew Brain
    Team - Manager Vale of Glamorgan Council
    ------------------------------


  • 2.  RE: Throtling Settings

    Posted 03-31-2020 03:29 AM
    Start at the lowest you can go with it (for percentage - it's 1%), adjust as needed if that proves to be a burden on the network you can move to a 'kb' static setting for the clients.

    Take into account the number of clients connecting as well, if all the clients are connecting at relatively the same bandwidth... 100 clients @ 1% is still, 1 client wide open (zero throttle) and if 1 client wide open is straining the VPN network then adjust to static 'kb' settings. So, it really depends on what your network can handle for VPN.

    Relatively speaking throttling should resolve most bandwidth issue(s) but, bear in mind that even with throttling there is dropped packets, re-requests, etc (normal network traffic issues) to take into account as well and this includes software/patch deployment sizes. There are plenty of network bandwidth calculators to use on the internet, you can run the calculations based on patch size to bandwidth to come up with ETA for a complete download, etc.

    A blockout is your friend as well, you can enable the blockout for downloads during the day and open in the evening if that helps. CEM is also another option.

    Hope this helps.








  • 3.  RE: Throtling Settings

    Posted 03-31-2020 04:21 AM
    I'm trying to publish something more official soon on this platform unless someone else has something already.

    1) Local Internet Breakouts: If you can configure your VPN clients to filter out the Altiris traffic then the Altiris agents will communicate with the CEM instead of filling up your VPN tunnels. Network teams may already be looking into internet breakouts for all the new Video Conferencing traffic intended for public services like Zoom.

    2) Further leveraging local internet breakouts develop the Altiris policy for PCs on the internet to download their MS patches from MS directly instead of flooding your CEM with patch requests. Originally we planned that machines on the internet would download patch packages from CEM, install them then return to the office to act like distribution points for P2P. If those machines are not returning to the office then save your networks and let them get updates from the vendor where possible.

    3) Lower priority: New or replacement PCs shipped to employee directly but provisioned by Altiris over the internet. Haven't thought this all the way through yet.


  • 4.  RE: Throtling Settings

    Posted 03-31-2020 06:15 AM
    Edited by John Armstrong 03-31-2020 06:16 AM
    Greg pointed out some options that you could consider.

    Filtering out the agent traffic to the NS, it's do-able. Better option is a blockout for package downloads and allow them to update via Microsoft.

    Not know how long everyone will be OoO or WFH, you still want the basic communication from the agent to the NS (just in case situations).

    Disable peer to peer downloads in your Target Agent Settings... no need for those clients connected via VPN.

    And not knowing the lay out of your network, take a look at the option of 'Manually Assigned Agents' for site servers (of course this is dependent on where the client's original location was prior to being remote or if you have multiple site/package servers).

    No need to have agents reaching across your network to a site server in a different location (office) if they are coming in through your internet head to the main office (where most likely a site server or NS is performing these functions).

    Just my assumptions and thoughts.




  • 5.  RE: Throtling Settings

    Posted 04-03-2020 04:35 PM
    If you have the newer software version then you might look into Targeted Sites Settings, where you can limit the number of clients doing simultaneous downloads.
    These settings affect package downloads only and do not affect policy request for example.
    There is also a report available that shows the almost real time site download information.



  • 6.  RE: Throtling Settings

    Posted 04-03-2020 04:44 PM
    First, make sure you have a policy that re-enables the bandwidth throttling on the client side every day by setting the reg key.  People uncheck it and as far as I know, it stays that way.

    Then set the throttling low - like 10k. That's not as bad as it sounds. Make a task to disable bandwidth throttling in special one-off situations where you need to get something somewhere fast.

    ------------------------------
    Ben Barker
    Systems Engineer
    ------------------------------



  • 7.  RE: Throtling Settings

    Posted 06-21-2020 11:06 PM
    ​bandwidth throttling is broken below smp8.5 ru2  for percent throttling -and has been for a long time. They changed how the bandwidth throttle magic packet gets sent out to finally be accurate. Otherwise use the data bits method.