Phase one completed in SMA 9.0 on 8/20/2018. Please let us know what else you would like to see next after you check it out.
I'm still needing this feature, going on 4 years 8 months and still not implemented.
I find it very disappointing that this feature I requested isn't available still, after more than 3 years!
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 interesting idea, something that I'd like to expand upon. I'd like to have the inventory history for one Asset type be controllable to keep for a selectable time period, anywhere from "all time" to "1 month" only. This would be useful for things that don't change much, but when they do it would be important to know when the change happened and when, for example, software licenses.
This is a pretty good idea. Until we get around to implementing such a feature, you can actually “delete” it (we don’t really delete, just hide). Once you are happy with it you can “Show” it again. Deleted/Hidden content is only viewable by the author and admins, others just see a message that the content is hidden with a reason when available.
We are considering a Windows 10 Universal app but this would be a large effort that would delay all other work on K1 GO for an extended period. As such we are continuing to monitor for demand/adoption before taking this on. Please continue to vote and comment to help drive our decision.
This is a great idea. We will need to first blend the software and managed install functions into the software catalog in order to do this. This is something that will take a while to implement, but certainly has our interest.
I have figured out a way using current LDAP label behavior to install software automatically on a computer according to a user's group membership in Active Directory.
Example: A new employee started this week and you need to have Adobe Reader installed on their computer.
1. Create a group in Active Directory (AD) called "Software Adobe Reader". This will be a group of all users that have Adobe Reader installed.
2. Create a normal label in KACE and name it "Adobe Reader Install". Put some notes in the "Notes" field so you don't forget what this is doing. Select the checkbox for 'Computer Inventory' and 'Software' and leave the rest blank.
3. Create a LDAP label in KACE and choose the Associated Label Name "Adobe Reader Install" which you just created in step #2. Follow the example LDAP label configuration below. After this LDAP label is created it will be looking to the group "Software Adobe Reader" in AD. This LDAP label checks if the user is a member of the group "Software Adobe Reader" in AD, and if they are, it applies that LDAP label to their computer.
NOTE: LDAP labels cannot be applied to users, only computers. This means that your user list under Service Desk > Users cannot have LDAP labels applied to them according to AD membership. This is because users don't sync with KACE, computers do. I sure wish it would work though!
Example LDAP Label Configuration:
Server Hostname: YourServerName/IP
LDAP Port Number: YourPort (example: 389)
Search Base DN: DC=YourDomain,DC=com
Search Filter: (&(sAMAccountName=KBOX_USERNAME)(memberOf=CN=Software Adobe Reader,OU=SoftwareDeploy,OU=IT Department,DC=YourDomain,DC=com))
LDAP Login: PathToAccountYouUseForDomainAuthentication
4. Apply the normal label created in step #2 above to a script or MI so that that task will be ran on that computer when it has that label.
In Active Directory add the new employee to the AD group "Software Adobe Reader". The next time the computer the new user is using checks into KACE it will get the LDAP label "Adobe Reader Install", then the script(s)/MI(s) will run since the label "Adobe Reader Install" is now applied on that computer and is also associated to the script/MI.
This is targetted for the next major release
Because of the lack of fields that appear and disappear depending on the category selected, I am forced to use multiple queues that are very similar to each other, they just have slightly different fields. This feature would be so useful in usage of the Service Desk and in uncluttering the ticket with impertinent information when different options are chosen.
I agree, this is also a problem for our helpdesk groups too. We have two now, and potentially more down the road. It should be customizable to set which queue shows up as default for them, and in addition they should not be able to see tickets from other queues. I think being able to view tickets from queues they shouldn't be seeing to begin with would be fixed by creating a "limited-admin" role that can only see tickets from Helpdesk Queue A and not Helpdesk Queue B. I believe this has been mentioned in other suggestions by users, but I still wanted to say that I desire this feature.