BlaiseG
My feedback
13 results found
-
199 votes
Thank you for your very thorough desciption of the issue. We will consider this as a feature request in the future. We prioritize based on feedback like yours – so we encourage others to vote for this feature request.
An error occurred while saving the comment BlaiseG
supported this idea
·
-
42 votes
An error occurred while saving the comment BlaiseG
commented
We have an enormous challenge with duplicate records in our computer asset table. The issue doesn't occur during bulk asset imports so long as the current PK is selected, However, I want KACE to prevent anyone from attempting to add another record to the computer asset table if the serial number already exists. By default (at least at one time) KACE prevented duplicate computernames but that's not ideal for our environment. This would have to be an opt-in feature and I realize we'd have to clean up our existing table before we could turn it on.
-
70 votes
An error occurred while saving the comment BlaiseG
commented
We had to develop our own scripts to process a raw USB inventory into the various types of USB peripherals (besides printers). We need to know what peripherals are attached (by model) so that they can be placed on a refresh schedule (or to aid support in troubleshooting issues). I recognize this would be difficult to implement with just a VID and PID combination from raw inventory. However, if we could build our own reference/lookup table, we'd give KACE the smarts it needs to make the data collected into something more human readable/intelligible.
-
17 votes
An error occurred while saving the comment BlaiseG
commented
This would be so beneficial, I've used 3 votes on it. The size of our environment coupled with our inventory interval makes it very difficult to validate the results of a software release to the enterprise. It would be EXTREMELY useful for the agent to run a very quick inventory to report back to the K1 as part of the MI process to confirm that the software was indeed installed BEFORE the next full inventory interval.
BlaiseG
supported this idea
·
-
99 votes
This is under consideration but not planned for the next release, Please continue voting if you’d like to see this feature prioritized for a future release.
An error occurred while saving the comment BlaiseG
commented
This idea has been in STARTED status for 2 years. What's the latest? We currently use a custom inventory rule to collect this data with all of the results being in a single field. Ideally, we'd like this to be native functionality to aid in reporting.
-
14 votesBlaiseG
shared this idea
·
-
27 votes
An error occurred while saving the comment BlaiseG
commented
I realize the role of RSAs is being reconsidered. I'm posting this here as a specific item for consideration during those architectural/design discussions.
BlaiseG
shared this idea
·
-
272 votes
An error occurred while saving the comment BlaiseG
commented
Anxiously awaiting this feature...
BlaiseG
supported this idea
·
An error occurred while saving the comment BlaiseG
commented
Why was this functionality not 'built-in'? I cannot think of a single use-case where the 'readonly admin' will be used. Enterprise customers need the ability to segregate who does what--the team that builds the images is not the team that deploys the images in our organization.
I would give this suggestion 3 votes if I had any leftover.
-
146 votesunder review · 10 comments · KACE Systems Deployment Appliance (SDA) » Feature Enhancements · Admin →
An error occurred while saving the comment BlaiseG
commented
Had I known this was not possible at the time of implementation, I would have deployed virtual K2s instead of the physical K2s (and leveraged full-VM backups). Instead, I have to rely on 'hope and prayer' that I won't, one day, have to recover from a failed K2200 appliance.
-
275 votes
An error occurred while saving the comment BlaiseG
commented
Replication schedule parity with K1: the K2 replication to remote sites uses bandwidth throttling only. Ideally, we'd like the ability to replicate files more quickly during specific periods (e.g., after hours/weekends when retail locations are closed).
-
125 votes
Thank you for your suggestion. This has been added to the feature request list. We encourage others to vote as we use this input for prioritizing our release plans.
An error occurred while saving the comment BlaiseG
commented
I concur. We need the ability to be more selective with what gets replicated to each location. We don't need the same software packages used at our corporate locations replicated to all remote locations.
I'd also like to see a 'replication only' agent. It's very challenging to have a handful of servers in the organization that is predominately intended to contain only our client systems. We use organizations to segregate servers and client computers given the different teams of people supporting each.
-
121 votes
An error occurred while saving the comment BlaiseG
commented
I absolutely agree. Scripts need to be devoid of time and target. This could be accomplished by creating a task to execute a specific against a set number of targets at a specific time. Results would be aggregated on a separate tab simliar to run now and would ideally include the name of the KACE user that scheduled the script. This construct would provide the desparately needed visbibility into the timing of recurring scripts and script execution results AND would reduce the overall script glut. Currently, any scheduled script must be duplicated if the time or targets needs to change leading to script glut. Please vote this idea up!
-
95 votesBlaiseG
supported this idea
·
We're impacted by this issue, as well. Particularly for our mobile users who move between retail locations. We use labels for determining which replication share to use, which is based upon IP (i.e., "where am I now?").