We have been having storage capacity and clutter issues with USMT scan states uploaded to our K2000. 90% of these have been migrated because the K2000 selects all profiles for migration by default and my peers will quite often zip through this without de-selecting profiles not needed. This will result in a lot of garbage data being captured as well as create duplicate local user accounts and profiles. This can form in to a very long list that takes up a lot of space that we have to manually clean up on each of our RSA(s).

Would it be possible to add the following features?
- Server Global setting or Task-Specific option to not auto-select profiles for migration when doing a manual deployment?
- Option to cleanup scanstates after X days paired with the ability to flag a capture for retention? E.G. automatically remove all scanstates that have been on the server longer then 45 days a long as they are not flagged for retention?

I Like the Sysprep Executor utility as it's fairly intuitive and user friendly when it's being ran prior to a capture, it however has a few barriers preventing me from using it.

- Custom Unattend answer file.

I have a few answer files created manually in WSIM as use a few settings that are not available in the Sysprep Creator menu, would it be possible to add an option to sysprep creator to select an unattend XML file instead of generating one via the menu options?

- Support for custom .bat,.cmd or .ps1 files prior to capture.

I have a script that I run before sysprep that performs the following tasks, not all of these are currently included within Sysprep executor. Would it be possible to add the ability to Sysprep Executor to run a custom script prior to running sysprep.exe so that I can automate the steps it does not natively cover?

* Close explorer.exe

* Verify bitlocker is off.

*Verify there is not a pending reboot

* Verify there is atleast 1 rearm remaining

* Verify VMWare tools is not installed.

* Verify the system is not a domain member.

* Reset McAfee's Agent GUID (A new one will be generated after next reboot, during the sysprep process)

* Remove windows Update Client ID's

* Stop the KACE agent (If installed) and remove the KUID (A new one will be generated after next reboot, during the sysprep process)

* Stop windows media player network sharing service and ensure it's startup is set to manual.

* Delete recent file history.

* Delete RDP connection history.

* Clear out Microsoft Office application MRU list

* Clear out types paths in windows explorer

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.