SDA (K2000)
Please tell us how you’d like to see the System Deployment Appliance product improved!
-
Role-based access control (RBAC)
Regulate access to various functionality based on user roles and permissions. This would include granular access to capabilities such as:
- Logon to KBE
- Access to specific production images
- Server/workstation roles
- Samba share access
- Differentiate between access to deploy images, and access to log into connected machines as an admin.
272 votes -
Replication window for RSAs
Some of our sites are on low bandwidth data connections. Trying to sync multiple RSAs takes days as the syncs do not happen concurrently. As these tasks queue up, I am unable to do other K2000 tasks, such as driver feed updates, upload images, or recaching of drivers. If we could have a window for replication similar to the K1000 replication to network shares, this would improve efficiency in our environment and ensure our RSAs are more up-to-date.
267 votes -
Ability to apply K1 labels from the K2 as postinstall tasks
It would be beneficial to be able to leverage the label feature in the K1 at time of system deployment.
157 votes -
Be able to restore the K2000 database
I just found out that you can not restore the K2000 database even though you can backup the K2000 database. I want to be able to have all my settings if there is a catastrophic failure with my server or just need to refresh the hardware. I have to recreate all my labels, users, Ldap authentication, all my general settings, date time settings, relink all of my RSAs and K1000.
143 votes -
Slipstream Patches Into scripted Install
It would be very beneficial to have the K2000 be able to slipstream MS patches similar to nlite/RT7lite with all current patches. Right now a Windows 7 sp1 Scripted install has 170 patches pending from MS.
I see our K1000 as a maintainer of machines not an initial configuratior.109 votesWe’re looking at this after we get more K1000 synchronization built into the K2000.
-
Link tasks to a deployment and not to an image
It would be more practical to link tasks (pre-install, mid-install, post-install) to a deployment rather than an image. We are several people to deploy the same image but we use different pre and post-install tasks... If each person changes the tasks for each deployment of the same image we risk to have conflicts...
Actually we duplicate the image to have different tasks but it's not a good solution because the same wim stored many times on the K2000 Appliance.
Another solution would be to just duplicate a link on the wim file and not the entire wim.85 votes -
Detach the image media from the image deployment job
The idea is to have the same process for the Imaging that the scripted installation. Then the image captured will be stored in the media Library and not in the deployment image tab. To create an image deployment job, we will select the image in a dropdown list.
73 votes -
69 votes
We’d like to improve schedulling and automated tasks across the board on the K2000.
I’m not as enthusiastic about supporting user state migration to non-K2000 storage. The advantage of the K2000 is that everything’s centralized. We already have export of user state in 3.3. If the problem is not having enough native storage on the K2000, we’ve heard that loud and clear.
-
Deploy Windows Updates automatically after postinstallation tasks
It would be nice if the K2000 would also manage Windows Updates (like the K1000) to deploy them automatically as postinstallation Task.
68 votes -
Object History tracking for security auditing
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:
…
57 votes -
Start post install tasks manually on a client for testing purposes
It would be great to have an option to start the post install Task process on a test Client that has already the OS installed, so you don't have to run a full scripted install every time you want to test a postinstallation Task.
57 votesThank you for your suggestion. I have put this in our product feature backlog. Please vote for this feature if you are interested so we can move it up the priority list. If a workaround is discovered, it will be posted here.
-
Add Custom Boot Images
Is it possible to:
Create a share on the KBox2000 called kbox_custom for people to add their own .img or .iso files too with the intention of developing a system which allows the booting of custom iso's and img files, ie floppy images for things like running asset tagging utilities.
Suggestions for making it work:
Because the method for booting the current iso’s seems to be through the pxelinux kernel, add a section where they can create their own boot strings and tack them onto the bottom of the boot menu.
Something like what I’ve depicted in the picture attached…56 votes -
Modifying Post Installation Tasks In Each Deployment
Having the ability to modify the post install tasks in each deployment separately so that it is not required to create multiple versions of a single script, or to re-script and replace the post install every time you want to change it. Basically, post install tasks able to accept parameters assigned in the deployment detail page.
46 votes -
Loading bar of image deployment on target device
On Targert device add a loading bar to check the in order to see where the image is deployed, the technician deploying the image may not be able to see the web interface of the appliance to check the progress status.
For exemple : 0% ----------------- to 100 %
just displays the percentage to copy from the image for example.40 votesThank you for this feature request! We will review this and determine its place within our product backlog.
-
Allow option to choose which driver feed models to sync to RSA instead of all drivers downloaded on K2
Allow user to either choose to sync all driver feed items from the K2000 appliance or instead not sync those files and make the Remote Site Appliance Driver Feed available to choose specific models to download drivers to the RSA.
39 votes -
Capture Full Backup of SDA
Currently, backups are only done if a change to the item being backed up has occurred. This is incremental behavior. We should have the option to specify this behavior (via checkbox, for example).
What I would like is the ability to do a full backup of everything at will - scheduled or otherwise.
An example of a problem arising from the current solution is this: empty the Restore share and then try to back everything up. You cannot. If you offload your backup and then lose it, you cannot make another full backup.
Ideally, everything would be rolled up into…
39 votes -
Join multicast session from KBE
Right now, there doesn't appear to be a way to join a multicast session from the KBE. This would be very helpful if we get a new shipment of PCs in, and set them all up. Then, we just tell the K2 to start the session and wait for 30 clients. This way we don't need to harvest mac addresses before hand... We can just deploy.
37 votes -
Block level imaging of systems
We would like the ability to do block level imaging again. Unfortunately this ability was removed with the removal of the linux kbe in the newest K2000 release. So either implement your own program to do block level imaging or allow the customer to create a section in the WinPE environment where they can use 3rd party imaging programs like Acronis or Ghost. We had this ability when we bought Kace and now it was removed. If Acronis & Ghost can do block level imaging in WinPE, Kace should be able to do the same. This truly limits are ability…
28 votes -
Improved RSA Administration
With 100's of RSAs deployed, changes to the configuration of a single typically results in hours of work--login to RSA, change configuration, rinse/repeat.
Ideally, I'd like one or more administrative templates that would allow me to control common settings (e.g., proxy, authentication, admin password, NTP, etc.)
I'd also like to script the reboot of a remote site appliance (think quarterly maintenance reboots). Currently, this process is administratively cumbersome even when performing reboots of each RSA (guest) via vCenter.
23 votes -
2 Factor authentication
Would be nice to have a 2 factor authentication , as the kace 1000 and 2000 contains important information and detailed inventory
19 votes
- Don't see your idea?