It would be nice to be able to define the security within the UI by label instead of by specific pre-determined roles. This would allow me to specify a "Service Desk Write" label which can then be associated with a group in my LDAP structure to which all members would get write access to the service desk, and I could have one for every tab called out in role creation. This would enable dynamic assignment of resources to users so that we are not required have to pre-determine every potential use case, define a role for that use case and manually assign or reassign as roles within the organization change.

The flexibility of being able to assign the attributes of a role to a smart label would enable a KACE admin to simplify the task of permission reassignment within the application and also make it easier to automate using any existing automation in place for role changes within an organization because it would become as simple as a group membership addition.

Past experience shows that whenever a set of patches is applied, even if “No Reboot” is chosen that a large percentage of the time the workstation is booted anyway. We don’t use this option anymore. We have one schedule set to detect … and another schedule set to deploy. The deploy job has an alert and is set to force a reboot. This allows our users have a chance to consent to a reboot during the day (laptops).

I just spoke with a support person and they confirmed that a deploy job has a max timeout of 1 hour, no matter what is specified in the deploy job. Our business model really needs a longer alert.

It is our wish to present an alert and ask the user to leave it there for most of the workday, say 8 hours ... until it’s convenient to him/her to patch and boot. A good example would as they leave for lunch or a long meeting. They can click “OK” to the alert and then expect a reboot.

Support also mentioned that a “Detect and Deploy” job has a 3 hour timeout. This doesn’t fit our business model. We need to run a detect job and later a deploy job so that the alert timing is more predictable.

Thanks!

The KBOX seems to require the specification of an LDAP login name and password in order for the scheduling icon to show up. Since our LDAP server does not require a LDAP login/password (all of the relevant user data is visible via anonymous bind), we left those fields blank. When I created a dummy LDAP account just for the purpose of binding, and specified this account for the LDAP login/password, the scheduling icon showed up again.

Ideally it would be good if this limitation could be removed (so that an LDAP login/password is not required to get the scheduling icon to show up). If that's not possible for some reason, it would be good to at least mention this requirement in the documentation, and/or issue a warning popup (e.g. "If you want to schedule user downloads from this LDAP server, KBOX requires an LDAP login/password to be specified"). As it stands, customers have no way of knowing that this dependency exists.

Occasionally patch detection or deployment fails usually due to machines going offline. The failure is reported back in the stats but nothing is done about it and this can result in a machine remaining insecure for an extended period.

I suggest detects and deploys auto-retry in a similar manner to Managed Installs do, say by default three times, next time the machine is online. This should ensure a higher success rate overall and I imagine would be easy to implement.

Now that users have more control over reboots the resulting delay in the patch deployment (pushing it outside of the usual schedule) won't be much of a problem.

There should be additional logging on the K1000 appliance to audit when kace admins make huge changes to the environment. Ex: Upgrading the Kace appliance to a major version.
We have about 7 or 8 employees that have admin access in our k1000 appliance and an upgrade was performed and ended up breaking our environment. We tried to figure out who initiated the upgrade by exporting all the logs and were only able to find other information like who uploaded items into the scripting section, who ran a script, etc. But no information on who started an appliance upgrade. This would be very a very helpful log. Thanks!