KACE Product Support

1. We use the email functionality to send scheduled reports to people.

2. You can generate reports from anything in the database (requires SQL query knowledge). Showing newly installed software by workstation would be possible, but "newly" would have to be defined as a time period.

3. We didn't use automated provisioning. I've used it to push agents to a few systems (all Windows machines), but we did our mass deployment using custom logon scripts.

4. If you have the Help Desk module, yes. Otherwise, no. In order to link IP scan data to Assets, you have to write custom SQL rules (which requires the Help Desk module). We've done this for several assets. We've got rules that populate asset data based on IP scan data.

5. The self-service application installation works very well. When a user clicks a link for a software installation, it simply tells their agent to go to the KBOX to download and install the appropriate managed installation. You can configure these installs just like any other managed install in KBOX.

Thanks Andy.
I'm looking at the login script for provisioning also, but with 4000 workstations, this maybe a significant load on the server. We may have to do a combination and try a managed provision by IP so we can break it up by VLAN. Once that is complete, then test in the login script and force a provisioning when applicable. We will probably run into some issues with provisioning on some devices, is there reporting for missed provisions when using provision by IP range?

Has anyone else come up with another strategy for provisioning that we should consider?

Our logon scripts are written in AutoIT - which gives us a bit more power than using a batch file. Before the KBOX, we would deploy software via custom logon scripts which would point to client systems' local branch file servers. If you've got a similar network configuration, you could always write a custom logon script in AutoIT, VBS, or Powershell to install the agent from a local repository at each of your locations. If all 4000 of your systems are at the same location, you could build some randomization (such as a random 0-60 minute timeout for installation) into the script or point to several systems at your location hosting the installer.

There are many ways you can provision. If you want to use the KBOX for provisioning, your phased deployment plan should really only be limited by the available bandwidth between locations. If you've got plenty to spare, then I'd open it up and provision the entire company. If you have limited bandwidth and need to be careful when deploying, then you can provision a few subnets at a time.

We are on a single campus with 1G through out, with some limited 10G connectivity. Bandwidth is not the issue. I'm more concerned with slaming the Kbox server from login scripts pulling from 4000 devices within the first few hours of the day, and then providing updates for inventory. Is there a way in Kbox to throttle the provisioning?
I like your idea to randomize the provision in the login script and need to explore some randomization, using mod() based on IP or something.
Thanks, Rich.

I believe the KBOX automatically throttles agent provisioning. I know that once the agents are there, the KBOX only allows 20 (by default, but this can be changed) to download at a time. You may want to ask your sales rep about this.

Rich O,

What Andy says is true for everything once the agent is deployed. The green light connection and associated message queue allows the KBOX to have control over it's own destiny - even if you tell 10,000 machines to patch now, what it is really doing is throwing 10,000 patch tasks on the queue, and there is a setting that let's you tune how aggressively the KBOX addresses the queued requests, but this queue protects it from denial of service type load issues. For provisioning, the initial contact is an http request. If you use our provisioning, it is managed so that the initial requests and hits to the samba server, etc are staggered. If you do your own rollout, if everyone is on the same network getting the remote proc call at exactly the same time, you could overwhelm the initial web request, but it would take a lot of agents aligned exactly for that to happen, because the first thing that happens is that they get put on the queue with a bootstrap event, so you should be OK.

For your questions about other ways to provision, the two most common ways are to deploy a GPO or logon script that runs the agent_provisioning.bat from the KBOX share. The advantage of this is that you will always be running the current agent, and you get all the smarts like the check for .NET, etc. A basic command line looks like: \\kbox\client\agent_provisioning\agent_provisioning.bat kbox_host_name "client". There are other optional parameters, which are documented in the header of the bat file, but you only need those two. This method is great because you don't have to attach any executable payload to the logon script. The other option is to p[ush and run the KInstaller.exe with -server=kbox_host_name as a parameter to make sure that the agent connects to the kbox automatically. If you need to flesh this out a bit more for the meeting with your manager, contact your sales rep and let's set up a quick meeting to go through all of your questions live with an SE.

Thanks,

Chris...