This is targetted for our next major release
This slipped to our next feature release.
Thank you for your request. We are publishing information in a Knowledge Base article as Microsoft’s updates/patching practices evolve:
This is at the top of the priority list for patch/update feature requests for a future release.
Just so I am clear, let me know if this scenario captures your request. There is a ticket rule that can be enabled that will automatically reopen a ticket should the enduser reply to a closed ticket email notification with something like “Hey don’t close this out, I’m still not fixed.” The ticket rule engages and then automatically changes the ticket to “reopened”.
But let’s say that enduser said “thank you, great job” – technically we will still reopen the ticket since the rule is doing exactly what is expected. The customer wants the enduser to be able to close it out at that point and we will not allow the enduser to do so. Only the ticket owner can close it out. That is working as designed.
If this is the case, the best option would be to just turn that rule off and not use it. You can make the Status field an “editable” field and the enduser can close this ticket out from the portal if they need to or reopen if they need to. Will that help - even temporarily? I ask because there are so many higher rated requests, that I am not confident that we can move this into a relase anytime soon.
This is planned for this year.
This was delayed but is still planned. Our apologies for the delay.
-The implementation level certification courses are available to customers, partners, and employees.
-Currently, the implementation level certification tests are available to partners and employees and not customers.
To learn more about the free courses available to customers, please check this out:
We will leave this request open for future consideration.
The K1000 agentless inventory now supports most server class devices, including Windows, Linux, Debian, SUSE, RHEL, Ubuntu, Fedora, and FreeBSD. It would good to know if you think that a read-only agent is still necessary given the broader support agentless has.
Please consult this document and see if that will help:
We added this feature (below) in SMA 9.0. Please let me know if that satisfies this request. Thanks for your suggestion.
Software catalog customization –Restrict what items are considered "licensed" software in License Compliance - .NET, Facetime, Spotify, Solitaire, vSphere Client, etc. - and only see what is important to you.
Thank you for your input. Offering both 32 and 64 bit clients would double our Windows agent QA testing time and we are sensitive to the impact of extending test times as it impacts our ability to release full-featured updates at our desired pace. A surprisingly large amount of our customers still need 32bit support today. We are going to continue monitoring this closely to determine the best time to drop 32 bit support (of course older versions of the agent would still be available once we moved to 64 bit). In the meantime, it would be helpful to know specifically what difficulties a 32bit client is causing so we might consider work-arounds in parallel with the 64bit only decision.
Based on the number of votes, our presenters were asked to poll the session attendees about this at our recent KACE UserKon 2018. Surprisingly, the response was overwhelming that pursuing the addition of a 64 bit agent instead of other features was not a good investment of resources. There was also a legitimate concern that offering two agents would add potential confusion and complexity as well. We will likely stay with the 32 bit agent only for the near future.