Tuyen Nguyen

My feedback

  1. 3 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  SMA (K1000)  ·  Flag idea as inappropriate…  ·  Admin →
    Tuyen Nguyen shared this idea  · 
  2. 370 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    22 comments  ·  SMA (K1000) » UX  ·  Flag idea as inappropriate…  ·  Admin →
    under review  ·  Dean Wade responded

    Over the coming releases, we will be revamping our targeting and scheduling pages. This a great example of where we will extend your ability to control what you are targeting and when it should be delivered.

    Tuyen Nguyen commented  · 

    Is there any progress on this? In addition to this, it would be good to have it so that the selection can be based on AND or NOT for groups of labels. Right now with one group of labels are considered OR now with the deployment going to machines being in one label OR another label OR... in the list. I would like to have another group of labels be added so that you can give an AND or NOT to it.

    For example, in an AND setting, you can send to label of computers of production type AND then with the second group of labels put in labels of computers with some software not installed, and deploy the software to the targeted set of computers in this way, instead of having to create a label separately for this which I have found does not play well when smart-labelling based on other smart labels.

    Also, in the form of NOT, it would work in the same way as this request of exclude based on a label. So you can have first group of labels be to the list of production computers, and then for selection with the second group of labels, you can select AND NOT for a group of computers with some software installed already, and in this way it would deploy the process to just the targeted computers that are production and does not have the software installed.

    Tuyen Nguyen supported this idea  · 
  3. 9 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  SMA (K1000)  ·  Flag idea as inappropriate…  ·  Admin →
    Tuyen Nguyen supported this idea  · 
    Tuyen Nguyen shared this idea  · 
  4. 1 vote
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    2 comments  ·  SMA (K1000) » Patch Management  ·  Flag idea as inappropriate…  ·  Admin →
    Tuyen Nguyen commented  · 

    Yes, I agree with this, and I have an open ticket with Kace support about this. It seems the default behavior of the reboot process is to reboot, and the user notification is just a stop to the next step of reboot. The correct way of the reboot process should be that on the reboot step, it should determine if the user did in fact accept the reboot notification or not.

    Currently:
    1 - patch is deployed and installed
    2 - if reboot notification is enabled, user is notified to accept reboot or not, and if user does not accept reboot, then process stops
    3 - reboot the computer

    The problem with this is as I have seen also in my user's Kace logs is that the Kuseralert process failed to execute for some reason, and then it went on to step 3 to reboot.

    Proposed change:
    1 - patch is deployed and installed
    2a - if reboot notification to user is enabled, set a reboot flag to 0, if reboot notification to user is not enabled, set reboot flag to 1 and continue to step 3
    2b - notify user of reboot, if maximum number of prompts are reached, then notify of required reboot and set reboot flag to 1, else notify as usual and if user accepts reboot set reboot flag to 1, if user does not accept reboot set reboot flag to 0
    3 - if reboot flag is 0, DO NOT reboot the computer, if reboot flag is 1 then reboot the computer

    The default behavior of Kace currently is to reboot without checking that a user has accepted reboot or not, and the above proposed change in the process could avoid this issue.

  5. 3 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  SMA (K1000) » Appliance  ·  Flag idea as inappropriate…  ·  Admin →
    Tuyen Nguyen shared this idea  · 
  6. 9 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  SMA (K1000)  ·  Flag idea as inappropriate…  ·  Admin →
    Tuyen Nguyen shared this idea  · 
  7. 7 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  SMA (K1000) » Patch Management  ·  Flag idea as inappropriate…  ·  Admin →
    Tuyen Nguyen shared this idea  · 
  8. 30 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    under review  ·  3 comments  ·  SMA (K1000) » Patch Management  ·  Flag idea as inappropriate…  ·  Admin →
    Tuyen Nguyen supported this idea  · 
  9. 821 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    17 comments  ·  SMA (K1000) » Patch Management  ·  Flag idea as inappropriate…  ·  Admin →
    Tuyen Nguyen commented  · 

    Also, with the patch on demand, I would like it so that we don't need it to be in a schedule to initiate a patch on demand, or if a schedule is needed, then make it so that the alert window that usually came up would be just a notification icon such that they would be able to open the notification icon to initiate the install -- kind of like how SCCM has a notification icon that allows the user to open and then say they want to install the patch.

    Tuyen Nguyen supported this idea  · 
  10. 4 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    1 comment  ·  SMA (K1000) » Managed Install  ·  Flag idea as inappropriate…  ·  Admin →
    Tuyen Nguyen supported this idea  · 
    Tuyen Nguyen shared this idea  · 

Feedback and Knowledge Base