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:
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.
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.
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.
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.
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...
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.
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.
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.
Thank you!
We have made some good progress on this idea and intend to release some changes in the next preview!
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.
900 seconds would be great