[GH-ISSUE #1270] Windows updates not getting installed on most clients #791

New issue

Closed

opened 2026-03-02 02:19:04 +03:00 by kerem · 3 comments

kerem commented

2026-03-02 02:19:04 +03:00

Owner

Originally created by @af7567 on GitHub (Aug 31, 2022).
Original GitHub issue: https://github.com/amidaware/tacticalrmm/issues/1270

Server Info (please complete the following information):

OS: Ubuntu 22.04
Browser: chrome
RMM Version (as shown in top left of web UI): v0.14.7

Installation Method:

[*] Standard

Agent Info (please complete the following information):
All agents v2.3.0

Describe the bug
I noticed that windows updates were not getting installed on most clients even after changing the patch policy to install every day. The debug log only shows the "Installing windows updates on ......." message for 1 or 2 PCs when ~30 of them are online.

I added a DebugLog to winupdate/tasks.py to print a log message for every online_agent, even if it wasn't time for an update, and that also only shows a couple of PCs online when there are lots more.

I then removed the *ONLINE_AGENTS from the return value of online_agents in agents/models.py so I have

return [
            i
            for i in cls.objects.only()
            if i.status == AGENT_STATUS_ONLINE
        ]

and now it seems to actually be checking if updates need installing on all my online clients.

(I know that cls.objects.only() must be wrong, but I couldn't figure out how to just get all objects and this seemed to work :) )

Originally created by @af7567 on GitHub (Aug 31, 2022). Original GitHub issue: https://github.com/amidaware/tacticalrmm/issues/1270 **Server Info (please complete the following information):** - OS: Ubuntu 22.04 - Browser: chrome - RMM Version (as shown in top left of web UI): v0.14.7 **Installation Method:** - [*] Standard **Agent Info (please complete the following information):** All agents v2.3.0 **Describe the bug** I noticed that windows updates were not getting installed on most clients even after changing the patch policy to install every day. The debug log only shows the "Installing windows updates on ......." message for 1 or 2 PCs when ~30 of them are online. I added a DebugLog to winupdate/tasks.py to print a log message for every online_agent, even if it wasn't time for an update, and that also only shows a couple of PCs online when there are lots more. I then removed the *ONLINE_AGENTS from the return value of online_agents in agents/models.py so I have ``` return [ i for i in cls.objects.only() if i.status == AGENT_STATUS_ONLINE ] ``` and now it seems to actually be checking if updates need installing on all my online clients. (I know that cls.objects.only() must be wrong, but I couldn't figure out how to just get all objects and this seemed to work :) )

kerem closed this issue

2026-03-02 02:19:05 +03:00

kerem commented

2026-03-02 02:19:05 +03:00

Author

Owner

@af7567 commented on GitHub (Sep 1, 2022):

I just checked again this afternoon and it has gone back to only detecting 3 PCs online in the windows updates check, even though the GUI is showing 35 online. So I have no idea what's going on :)
Maybe it was a combination of changing the code and restarting the TRMM services that made it start showing all the online agents, but after it's been running a while it forgot about most of them.

@af7567 commented on GitHub (Sep 1, 2022): I just checked again this afternoon and it has gone back to only detecting 3 PCs online in the windows updates check, even though the GUI is showing 35 online. So I have no idea what's going on :) Maybe it was a combination of changing the code and restarting the TRMM services that made it start showing all the online agents, but after it's been running a while it forgot about most of them.

kerem commented

2026-03-02 02:19:05 +03:00

Author

Owner

@BMTTeam commented on GitHub (Sep 1, 2022):

I just want to jump on this ride (yeah, I think it's related) as well - since TRMM is managing the updates (it's been confirmed on Discord that if the update was executed outside the TRMM patching process, the date of the installation is not going to be documented, no matter it can be obtained from Windows. I hope that for NX based the dpkg.log file will be used as a base point at least) some of the updates are without dates when they were installed. No matter if it installed (well approved via server/workstation policy) via TRMM.
We had a case with several Windows machines (virtual and physical) that TRMM was indicating pending patches, even if you check on the system manually that there are not pending installation patches. I need to install the latest version 0.14.7 (at the moment running 0.14.6 and agents are v2.3.0).

P.S.: I really hope that soon we well be able to test/use (even beta) the reporting module.

Cheers,
-Tiho

@BMTTeam commented on GitHub (Sep 1, 2022): I just want to jump on this ride (yeah, I think it's related) as well - since TRMM is managing the updates (it's been confirmed on Discord that if the update was executed outside the TRMM patching process, the date of the installation is not going to be documented, no matter it can be obtained from Windows. I hope that for NX based the dpkg.log file will be used as a base point at least) some of the updates are without dates when they were installed. No matter if it installed (well approved via server/workstation policy) via TRMM. We had a case with several Windows machines (virtual and physical) that TRMM was indicating pending patches, even if you check on the system manually that there are not pending installation patches. I need to install the latest version 0.14.7 (at the moment running 0.14.6 and agents are v2.3.0). **P.S.:** I really hope that soon we well be able to test/use (even beta) the reporting module. Cheers, -Tiho

kerem commented

2026-03-02 02:19:05 +03:00

Author

Owner

@af7567 commented on GitHub (Sep 3, 2022):

I have done a bit more playing around, still not sure what "*ONLINE_AGENTS" does, but I think it's just something to do with the fields fetched from the database and wouldn't change the number of online agents returned.

Anyway, I think the reason only 1 or 2 agents get checked for updates when lots more are online isn't because the list being returned is too small but because check_agent_update_schedule_task() is exiting after finding any agent which had patches installed the same day (that is why my tests after midnight before seemed to have fixed something)

Should this line be a continue and not a return? :

github.com/amidaware/tacticalrmm@b14ea1fe3e/api/tacticalrmm/winupdate/tasks.py (L75)

edit:
The return could be intentional, assuming all agents will be patched at the same time and are all online at the same time.
If not all agents are online though for the first patch install, then they would only get updates installed if they are lucky enough to be at the start of the list (which changes order all the time) when the next patch run comes around.

@af7567 commented on GitHub (Sep 3, 2022): I have done a bit more playing around, still not sure what "*ONLINE_AGENTS" does, but I think it's just something to do with the fields fetched from the database and wouldn't change the number of online agents returned. Anyway, I think the reason only 1 or 2 agents get checked for updates when lots more are online isn't because the list being returned is too small but because check_agent_update_schedule_task() is exiting after finding any agent which had patches installed the same day (that is why my tests after midnight before seemed to have fixed something) Should this line be a continue and not a return? : https://github.com/amidaware/tacticalrmm/blob/b14ea1fe3ec4a1c78174bdf22dd13cb74be6c863/api/tacticalrmm/winupdate/tasks.py#L75 edit: The return could be intentional, assuming all agents will be patched at the same time and are all online at the same time. If not all agents are online though for the first patch install, then they would only get updates installed if they are lucky enough to be at the start of the list (which changes order all the time) when the next patch run comes around.

kerem referenced this issue

2026-03-14 04:04:09 +03:00

[GH-ISSUE #791] When trying to delete an automation task html content is shown in alert #2444