Change the maximum run time of cumulative updates to 30 minutes
With the new 'cumulative updates' model I think it would be a good idea to change the maximum run time of cumulative updates to 30 minutes (or whatever is best suited). I have noticed more timeout issues with patching in the last couple of months due to the default 10 minutes not being enough time to install 'X' patches as a single CU. This would be preferred to manually overriding them every month.
This is improved for win10 cumulative updates on ConfigMgr 1706. If the update size is bigger at import time; we will set a larger timeout.
Arthur Benedetti White commented
the Issue we are having is not timeouts but patches not able to install due to the 180 minute runtime being set on them, i am noticing this on office patches and some 3rd party ones. usually our maintenance window does not exceed 3 hours so none of these new office patches are able to run until i manually adjust the runtime on each patch
Bryan Dam commented
@Paul and @Anashir ... that absolutely is in the product now. Check out the SUP component's 'Max Runtime' tab.
Paul S. commented
+1 for Anashir QADRI comment.
We need the ability to set this globally, and not just a default for select OS.
I am currently trying to patch a server and the update is timing out on approx 12 servers. Can we have a client setting for updates where you can increase the timeout globally for all updates.
Anashir QADRI commented
we should be able to set and modify a global default value to maximum run time for all software updates (instead of modifying each update into SCCM console or by Powershell)
It would be nice if the Maximum Run Time could be ignored altogether through some sort of client settings.
This is still an issue specifically with feature updates. Instead of changing the default time out time for everyone, can you make it changeable to each ADR? Some I need to set at 200 min others 10 min is fine.
Run the query below to find all the updates with timeout discrepancies in your environment. The workaround that we are using in my company is to change the max timeouts of the ArticleIDs found in the query to 3600 seconds via the Console or PowerShell script.
SELECT CI_ID, a.ArticleID, a.CI_UniqueID, a.Title, a.MaxExecutionTime as ExpectedMaxExecutionTime, Body.value('(ConfigurationItemProperties/Properties/Property[@Name = "MaxExecutionTime"])', 'varchar(255)') as ActualMaxExecutionTime
INNER JOIN v_UpdateInfo a on a.CI_UniqueID = RIGHT(Body.value('(ConfigurationItemProperties/@ModelName)', 'varchar(255)'), 36)
WHERE Document_ID IN
(SELECT Document_ID FROM CI_CIDocuments WHERE DocumentType = 2
AND Body.value('(ConfigurationItemProperties/@Type)', 'varchar(255)') = 'SoftwareUpdateBundle'
AND a.MaxExecutionTime != Body.value('(ConfigurationItemProperties/Properties/Property[@Name = "MaxExecutionTime"])', 'varchar(255)'))
ORDER by DateLastModified desc
This is still an issue for us. Time is set to 60 minutes by default, but it timed out on most of our servers. Can the CUs be set to 90 or 120 minutes by default, please?
Seems to be some new issue in ConfigMgr v1802. If you look into the properties of a Cumulative Update in class SMS_SoftwareUpdate, you will see the MaxExecutionTime of 3600, but looking at the CI properties document (e.g. http://<mpserver>/SMS_MP/.sms_dcm?Id&DocumentId=e6404221-0834-4e9f-ad7e-7563dfa6fe29/PROPERTIES) you will find a MaxExecutionTime of 1800. Workaround: If you then change the update's max execution time to say 61 minutes and recycle the MPs IIS application, CI properties document will correctly reflect 3660 seconds. Same problem for .Net Feature Update but not Malicious Removal Tool. Hoping MS fix it again with CMv1806 prod.
This is still an issue. Latest Cumulative Update, KB4284880, is set to 60 minutes by default, and it timed out on most of our servers. Should the CUs be set to 90 or 120 minutes by default?
Even if Maximum Run Time for Cumulative Updates are set to 60 minutes, it fails to install after 30 minutes on Windows Server 2016 (CCMexec.log => [MaxExecutionTime ( 1800 ) expired. Update will not be monitored]
Is there a way to change this for Server 2016 Essentials. I cannot install any of the CU's using windows update. I can install them it I download them from the update catalog and manually run the MSU file.
Mike Plichta commented
We need to up it to 200 minutes to ensure all models could install. This requirement breaks the automatic deployment rule processes.
Needs to be changed for the Quality Rollups for older OS's as well
E Williams commented
It would be nice if Microsoft actually did do the change and modify the MTU to 30 min, but haven't done on some updates on Patch Tuesday (PT) this month 10/10/2017. CU for Windows server 2016 (KB4041691), for example, is about 1.1Gb in size and had a MTU of 10 min, fine for standard spec servers, but for lower test and dev spec VM servers they have failed to install. It ain;t being changed! Annoying.
Jürgen Winter commented
@yannara: And at the time you synced, you already had SCCM 1706 with the second first wave update (Or 1706 which was downloaded after August 08)?
Also, 30min might not be enough for devices with HDD.
I still see 5min max runtime in CU of W2016 server, KB4041691 as example which I synced today, was set to 5min and its size is 1185mb.
Stefan Röll commented
Cumulate Updates for Windows Server 2016 now have a default maximum run time of 60 minutes.
It´s now in 1706 for Server 2016 :-)
Greg Mackinnon commented
I am just running my second month of cumulative updates using SCCM, and I am experiencing bulk timeout-related failures for Cumulative Updates on Server 2016, and some additional failures on Server 2012 R2.
I agree with others that the default timeout of 10 minutes is completely inadequate for Cumulative Updates on servers, and that it should be bumped to 30-45 minutes.