Patch Bandwidth
When you set up a patching schedule, and it runs, do all clients that need to download patches do so at once? We have bandwidth concerns at some remote locations so we are thinking about ways we can combat this. Obviously, if all clients try to patch at one time they will be pulling a lot of data across the network and we will have to stagger these schedules. Is this assumption accurate?
Thanks.
Thanks.
0 Comments
[ + ] Show comments
Answers (5)
Please log in to answer
Posted by:
GillySpy
13 years ago
All clients that are connected and have an active patching task will download what they need. For a scan (detect) they download less than for a deploy. You can see current tasks at settings->support->ts tools->tasks
For remote sites you might consider using a replication share where the kbox sends all payloads to that machine once and clients download from the local share. A share can be any storage device that you can map a drive to a machine running a kbox agent.
For remote sites you might consider using a replication share where the kbox sends all payloads to that machine once and clients download from the local share. A share can be any storage device that you can map a drive to a machine running a kbox agent.
Posted by:
zookdj
13 years ago
Do you have replication shares setup at your remote locations? Those allow patches to be downloaded once across the WAN (on a schedule you specify), and then the clients at the remote locations (based on labels) will copy the patches they need from the replication share.
Posted by:
bowlesrice
13 years ago
wkucardinal,
A replication share is a "full replication of all digital assets and is managed automatically by the KBOX," so it holds scripting dependencies as well as patches. Once you've decided the location of your share, you can manage the 24/7 bandwidth by hour from the KACE Management Appliance under Distribtution>Replication; this is especially helpful on T1 circuits or less. If the replication window is open with no bandwidth limitations have been set, and you add a 500mb-1gb application package to your scripting (such as an MS Office Upgrade), it could cause problems. Bandwidth limitations and proper labeling can help eliminate any potential issues.
As far as I know, there aren't any limits to how many shares you can have on a subnet, VLAN, etc. With proper labeling, you could point 150 computers to one RS and another 150 to another RS. All of these could reside on the same subnet and could help you speed up patching or scripting. According to KACE, "machines in that label go to that replication share to get files, as long as it is a member of only one label with a replication share."
It might also be to your advantage, especially if you also have a k2000 series appliance, to have the RSA virtual machine and the RS on the same physical computer/IP address. If you have network monitoring, you can easily point potential slowness to the KBOX or an RSA/RS and discontinue and KBOX tasks with this setup. I found that it's time consuming to point network slowness to the KBOX if the share is on an outer-office SQL, Domain Controller, Print Server, etc. Also, I don't like to have the agent on critical servers for stability and patching purposes, which was a personal choice.
I believe the share may require an agent be installed to replicate, so you'll want to make sure you have enough license/nodes for all of your new shares.
You could chat with KACE and confirm this information, but I hope it at least gave you some helpful ideas.
Rich
A replication share is a "full replication of all digital assets and is managed automatically by the KBOX," so it holds scripting dependencies as well as patches. Once you've decided the location of your share, you can manage the 24/7 bandwidth by hour from the KACE Management Appliance under Distribtution>Replication; this is especially helpful on T1 circuits or less. If the replication window is open with no bandwidth limitations have been set, and you add a 500mb-1gb application package to your scripting (such as an MS Office Upgrade), it could cause problems. Bandwidth limitations and proper labeling can help eliminate any potential issues.
As far as I know, there aren't any limits to how many shares you can have on a subnet, VLAN, etc. With proper labeling, you could point 150 computers to one RS and another 150 to another RS. All of these could reside on the same subnet and could help you speed up patching or scripting. According to KACE, "machines in that label go to that replication share to get files, as long as it is a member of only one label with a replication share."
It might also be to your advantage, especially if you also have a k2000 series appliance, to have the RSA virtual machine and the RS on the same physical computer/IP address. If you have network monitoring, you can easily point potential slowness to the KBOX or an RSA/RS and discontinue and KBOX tasks with this setup. I found that it's time consuming to point network slowness to the KBOX if the share is on an outer-office SQL, Domain Controller, Print Server, etc. Also, I don't like to have the agent on critical servers for stability and patching purposes, which was a personal choice.
I believe the share may require an agent be installed to replicate, so you'll want to make sure you have enough license/nodes for all of your new shares.
You could chat with KACE and confirm this information, but I hope it at least gave you some helpful ideas.
Rich
Posted by:
wkucardinal
13 years ago
Yes, I was aware of the replication share, and we will utilize that. It sounds like we are going to need several of them!
Posted by:
dyehardfan
13 years ago
ORIGINAL: wkucardinal
Yes, I was aware of the replication share, and we will utilize that. It sounds like we are going to need several of them!
We have one at each location. We already have a BDC at each one so I have just created a seperate partition on them and use it as our RepShare.
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.