The KACE SDA currently has no way to audit changes made to any imaging-related objects, including:

- KBEs
- System images
- Pre/Mid/Post install tasks
- Task Groups

Coupled with the "all or nothing" approach to permissions in the SDA, this creates an information gap that results in a security concern: how do you know what object or setting change was made, when it was made, and who made it?

Consider the worst case scenario: a disgruntled SDA Admin on their final day at the company adds a malicious script or application to a post-install task.

The risks that come with the current model:

1 - If you have more than one person in the image administration role, there is no way to prove accountability for this act of sabotage.

2 - If the change is not noticed immediately, there is no way to understand how far back it occurred and therefore no way to assess the true impact in terms of how many systems were imaged with the new configuration.

The KACE SMA has this functionality in the form of the Object History. Let's add it to the KACE SDA as well so that we can cover our security concerns there as well.

Basic configuration, such as system location or system contact, for SNMP is not available to the end user. Many SNMP monitoring tools pull this information and map devices using this information. This information can be provided in the /usr/local/etc/snmpd.conf however the end user can not edit this, so options might be to allow this information to be added in the konfig stage of the install or when going into the Security Settings/General Security Settings and putting a check mark in Enable SNMP Monitoring other fields can open (besides SNMP Community String) for syscontact and syslocation. Once saved this information can update the snmpd.conf file. Another option in this area would be to restart the snmpd service or after saving the box might request a reboot.

We have been facing a lot of situations where the sync queue was hanging and therefore the whole appliance is useless as nothing can be done anymore. This always requires calling the support which causes workload for the support, the customer and wasting time, cause the only thing Support will do is kill the hanging process. If there would be a "button" to kill the "current hanging" task it would be beneficial.

Example: RSA replication hangs because of new version has been installed but no version check, if the "nightly sync" task hits that rsa the whole queue is stuck (sounds like a bug anyway) but in that case the nightly sync does not continue and the the affected RSA is showing sync completed while the appliance status is showing "Updating blablabla". If I could "kill" that task the system could just go ahead and done deal.

Please make the "nightly sync" queue run multiple RSAs in parallel, or at least adjustable. We are running 200 RSAs and if one of them for whatever reason is blocking delaying the sync the whole queue gets into a backlog. Then it is hard to get it synced without manually interacting and canceling and pushing multiple RSAs at once.

As it is possible to run multiple syncs manually triggered in parallel it should not be a big deal to also make that work for the build in queues.

Same applies at days when we need to inject new drivers intro the driver feed. Every model is from my experience around 1 GB. My central appliance as enough bandwith to cover multiple sites in parallel, but small sites with a low band with are delaying the whole replication because of the sequential sync approach. So injecting a new driver package always require a weekend working on the Kace environment to get all RSAs back in sync.

Add an additional column in the "Deployment progress" view to be able to identify the machines. Right now its just possible to show the "Name", "Deployment", "Deployment Type" and "Date Started".

In a big envrioenment (we have 14k+ clients and 200 sites) this is completely useless as multiple installations starting at the same day and the list is showing the same "names" just the time is different. By adding the IP and Mac address (both values are available at that point already) would significantly help to identify the correct machine which needs to be monitored.

Easy implementation and a great benefit

Currently if a user updates the SDA (K2000) version, the Appliance Upgrade Log only has the date and time of the update. There is no way to see who started the process.

[Mon Jan 7 19:54:22 EST 2019] [notice] XXX Begin K2000 Server Update to 6.1.251 from 6.0.425
[Mon Jan 7 19:54:22 EST 2019] [notice] XXX===========================================================================
[Mon Jan 7 19:54:22 EST 2019] [notice] Removing backup 5.1.84_backup.sql.0.gz
[Mon Jan 7 19:54:22 EST 2019] [notice] Removing old database backups
[Mon Jan 7 19:54:22 EST 2019] [notice] kbox_upgrade:: NOTICE: Running kbox_upgrade.php part 1
[Mon Jan 7 19:54:21 EST 2019] [notice] kbox_upgrade:: NOTICE: Starting kbin upgrade process