Cumulative Update 50166236 issues with 2019 servers
Did anyone else notice HyperV 2019 servers initially failing to install Cumulative Update KB5016623 after a reboot? In KACE, we are getting a Deploy Success, but detect status would return with Not Patched. Getting an error code of 0x800F0840 on the servers. Additional reboots will not resolve themselves with these reboots. It would take another attempt at Detect and Deploy and an extremely long time to resolve, including another reboot. I believe, but am not sure, that this is an ongoing issue with Cumulative Updates and 2019 servers. I realize the error means 'failed to be changed to the installed state," but this does not seem to occur when installing the patches manually, only when using KACE.
Has anyone else have this issue?
Answers (2)
I had 31 2019 servers receive KB5016623 without issue this past month. I do do a double deploy as I like to catch all patches in the first one and then apply ONLY the OS patches in the second. Not sure if this had an impact on the success?
| PTCH321774 | KB5016623 | 2022-08 Cumulative Update for Windows Server 2019 for x64-based Systems (KB5016623) | 31 |
Comments:
-
Would you mind talking about why you do a double deploy? Are you just doing a deploy and not a detect/deploy? If so, then I think I can see why you double deploy. I was told by Kace to never do a detect/deploy which I now know is wrong... this works very well for us. I only do OS patches though.. you are doing applications as well? I dont trust kace to do apps on servers. - barchetta 2 years ago
-
The reason I do this is because for the 4 years I have been patching with Kace, I find that unattended patching to servers doesn't always go as planned with the server detect and deploy and OS patch reboots have to be very controlled in my environment. The unexpected results are likely due in part to only completing them once a month and someone else having set up the patch labels for all the applications - there being a bunch of applications as well as the OS to update. I have the best results when I use our catch all detect and deploy (for practically everything subscribed to) and then a second one with a label I created for OS patches (i.e. --updated monthly-- (KBSYS.PATCH.TITLE like '%2022-09%') AND (PATCH_STATUS.STATUS = '0') OR (KBSYS.PATCH.TITLE like '%Malicious software removal tool%') ). Doing it this way also helps me easily see that the OS patch deploy was successfully for the 100 plus servers I automate this for and I only have to check on the ones it did not by utilizing the schedule status. I schedule the two to run about 4-5 hours apart in the wee hours of a Sunday morning after Windows patch Tuesday. Before doing it this way I had major trust issues, as I have a small timeframe to complete these, and would have to check every server to ensure the OS patch completed. With 100 plus servers you can imagine my want to change it to a process I could count on. My way has helped to clearly know what needs manual intervention to be fully patched and saves me a ton of time. - Mashby1 2 years ago
-
Barchetta. We tend to do a detect and deploy with three tries with a timeout of 6 hours. So, in this case, the first deploy would go out, patch, and request a reboot, and that first reboot request might be around 30 minutes or so after deployment. KACE will do another pass and see that CU failed to patch (but successful deploy). It will detect it again, attempt the deployment again and then have another reboot request. That second round might take up to 2 hours.
The point is on 2019 servers and Cumulative Updates; it should detect, deploy, and reboot on the first pass. Another detect and that second detect should report back patching has been successful unless a rare dependent patch is required. - Argos 2 years ago
We didnt have that issue.. installed on 90 some servers. we do a single detect/deploy with a max retry of 2. In looking at one of them I do see 2 de ploy tries on that one and also KB5011259.
Just a thought, perhaps you might be seeing this due to a timeout in your scheduler being low. I guess if you really want to know, pull a "kapture" from one of them and deep dive. When you say "extremely long time to resolve" what is that time? There was discussion on here that we should allow up to 4 hrs for servers and I tend to agree. Yeah it seems extreme but it is what it is. I guess staging might be a good idea.. been thinking about that. Anyone staging?
