Skip to Main Content
Patch My PC Feature and Application Request

A community where customers and the community can provide feedback to make a better product for everyone! For more details on how we prioritize request, please see:

24 VOTE
Status SHIPPED
Created by Aaron Genter
Created on Jul 26, 2021

Conflicting Processes Time Out

Please allow for a longer timeout than 300 seconds. The timeout values in SCCM can be handled with scripting, so there doesn't have to be a conflict with the SCCM 10 minute default timeout for those who need a longer setting.

  • Attach files
  • Admin
    Cody Mathis
    Reply
    |
    Sep 1, 2021

    Appreciate that :)


    Please do let us know how things work out! We anticipate that a customer who wants this would handle the max run time with scripting as you mention.

  • Aaron Genter
    Reply
    |
    Aug 31, 2021

    That actually sounds like a very good solution and it's good to know you looked at all angles of this and not just "please give us more time." In my case, I have scripts that run to set the execution time and will just schedule everything around ADRs.

  • Admin
    Cody Mathis
    Reply
    |
    Aug 30, 2021

    I hope this meets the need!

    Our main concern was we really did not want to allow customers to set a max run time for the notification that exceeded the max run time of the update or app. This would generate a lot of errors, tickets, and confusion.

    If the notification process is running, but the run time is exceeded for a ConfigMgr update it will COMPLETELY stop all other updates from running until the notification closes. Not great :(

    To work around this we now let you specify to use the max run time from the update. Scriptrunner actually queries WMI locally on the endpoint and checks for the max run time of the update being executed, and then minuses 15 minutes to allow for update installation. This will be the notification timeout.

    For example, if you set your update maximum runtime to 75 minutes, the effective notification timeout will be 60 minutes when it pops up.

    Note: You must set the maximum run time on the update before you deploy it to your clients. This means if you use an ADR and it evaluates shortly after the update is published you would not see your clients respecting your update max run time settings likely because they would get the update in policy prior to the update max run time change.

    I will be updating docs accordingly soon.

  • Aaron Genter
    Reply
    |
    Aug 30, 2021

    Thank you!

  • Admin
    Cody Mathis
    Reply
    |
    Aug 20, 2021

    We have made some good progress on this idea and intend to release some changes in the next preview!

  • Derek Carpenter
    Reply
    |
    Aug 9, 2021

    We'd prefer to take the approach wherein the window is displayed for upwards of 2 hours (7200 seconds). The idea being that the window may consistantly display during an employee's lunch hour and they could potentially miss these prompts all together.

  • Daniel Rung
    Reply
    |
    Aug 3, 2021

    900 seconds would be great

  • +13
10 VOTE

Notifications - Max Runtime Increase

Merged
Extend the max runtime for deferrals from 5 minutes to 30 minutes. This would be ideal for apps like Zoom, AnyConnect and Jabber, because someone may be in the middle of a call/meeting when the countdown timer begins. Also, make the auto close and...
Peter Maudlin about 3 years ago in Application Request 3 SHIPPED