[GH-ISSUE #551] Patches Perpetually Show "No Patches"

kerem commented

2026-03-14 03:26:46 +03:00

Owner

Originally created by @bleglord on GitHub (Jun 2, 2021).
Original GitHub issue: https://github.com/amidaware/tacticalrmm/issues/551

Server Info:

OS: Ubuntu 20.04
Browser: chrome
RMM Version: v0.6.13

Installation Method:

Standard
Docker

Agent Info (please complete the following information):

Agent version (as shown in the 'Summary' tab of the agent from web UI): v1.5.7
Agent OS: Win 10 v1809 (Hyper-V VM)

Describe the bug
Regardless of either automated patch scheduling, or attempting to scan/install patches manually, the patch level/history never updates and patches do not install or download.
Within the OS, Windows reports updates as managed by the organization as expected.

To Reproduce
Steps to reproduce the behavior:

Go to rmm.company.com
Click on Workstation
Scroll down to Patches
See error: Reporting No Patches
Right Click > Patch Management > Run Patch Status Scan results in no action

Expected behavior
Patches downloading/updating when manually or automatically triggered.

Originally created by @bleglord on GitHub (Jun 2, 2021). Original GitHub issue: https://github.com/amidaware/tacticalrmm/issues/551 **Server Info:** - OS: Ubuntu 20.04 - Browser: chrome - RMM Version: v0.6.13 **Installation Method:** - [X] Standard - [ ] Docker **Agent Info (please complete the following information):** - Agent version (as shown in the 'Summary' tab of the agent from web UI): v1.5.7 - Agent OS: Win 10 v1809 (Hyper-V VM) **Describe the bug** Regardless of either automated patch scheduling, or attempting to scan/install patches manually, the patch level/history never updates and patches do not install or download. Within the OS, Windows reports updates as managed by the organization as expected. **To Reproduce** Steps to reproduce the behavior: 1. Go to rmm.company.com 2. Click on Workstation 3. Scroll down to Patches 4. See error: Reporting No Patches 5. Right Click > Patch Management > Run Patch Status Scan results in no action **Expected behavior** Patches downloading/updating when manually or automatically triggered.

kerem closed this issue

2026-03-14 03:26:52 +03:00

kerem commented

2026-03-14 03:26:58 +03:00

Author

Owner

@silversword411 commented on GitHub (Jun 2, 2021):

...was about to write this one up too :)

Either I used the wrong value {{ summary.patches_last_installed }} or the value isn't being updated when patches run

@silversword411 commented on GitHub (Jun 2, 2021): ...was about to write this one up too :) Either I used the wrong value {{ summary.patches_last_installed }} or the value isn't being updated when patches run ![2021-06-02_110318 - trmm patches](https://user-images.githubusercontent.com/13395348/120504555-3d899380-c392-11eb-9c54-70e869e28a3d.png)

kerem commented

2026-03-14 03:27:03 +03:00

Author

Owner

@wh1te909 commented on GitHub (Jun 2, 2021):

@bleglord follow the instructions here to run the tacticalrpc service in debug mode (stop the service first) https://wh1te909.github.io/tacticalrmm/troubleshooting/#agents-not-checking-in-or-showing-up-general-agent-issues

then from the ui, right click agent > run patch scan now
you should see what's happening in real time in the cmd window on the agent. paste any errors here

@silversword411 is your issue just that it's showing "Never" or do you also see the "No patches" where the list of windows updates should show up

@wh1te909 commented on GitHub (Jun 2, 2021): @bleglord follow the instructions here to run the `tacticalrpc` service in debug mode (stop the service first) https://wh1te909.github.io/tacticalrmm/troubleshooting/#agents-not-checking-in-or-showing-up-general-agent-issues then from the ui, right click agent > run patch scan now you should see what's happening in real time in the cmd window on the agent. paste any errors here @silversword411 is your issue just that it's showing "Never" or do you also see the "No patches" where the list of windows updates should show up

kerem commented

2026-03-14 03:27:08 +03:00

Author

Owner

@silversword411 commented on GitHub (Jun 2, 2021):

@wh1te909 Issue is all agents I've checked show Never, and there is an automation policy that should be:

Doesn't green check mean installed (and probably installed by TRMM?)

@silversword411 commented on GitHub (Jun 2, 2021): @wh1te909 Issue is all agents I've checked show Never, and there is an automation policy that should be: ![2021-06-02_120018 - brave_Tactical_RMM_-_Brave](https://user-images.githubusercontent.com/13395348/120513386-3b2b3780-c39a-11eb-9803-51286a9f7e09.png) ![2021-06-02_120052 - brave_Tactical_RMM_-_Brave](https://user-images.githubusercontent.com/13395348/120513401-3fefeb80-c39a-11eb-9e00-b06097729364.png) Doesn't green check mean installed (and probably installed by TRMM?)

kerem commented

2026-03-14 03:27:13 +03:00

Author

Owner

@wh1te909 commented on GitHub (Jun 2, 2021):

@silversword411 no, green check means it's already installed not necessarily by tactical
the ones installed by tactical will have a datetime in the "Installed On" column
also the grey circle means no policy has been applied so maybe try deleting/recreating and re-apply the automation policy
try right clicking on one of the rows in the patch table and see how it changes color to blue and pending
then try installing patches and see how it updates

@wh1te909 commented on GitHub (Jun 2, 2021): @silversword411 no, green check means it's already installed not necessarily by tactical the ones installed by tactical will have a datetime in the "Installed On" column also the grey circle means no policy has been applied so maybe try deleting/recreating and re-apply the automation policy try right clicking on one of the rows in the patch table and see how it changes color to blue and pending then try installing patches and see how it updates

kerem commented

2026-03-14 03:27:19 +03:00

Author

Owner

@bleglord commented on GitHub (Jun 2, 2021):

...was about to write this one up too :)

Either I used the wrong value {{ summary.patches_last_installed }} or the value isn't being updated when patches run

The issue I'm seeing is actually different, here is a picture of what I'm seeing:

I'll run through the debug mode process and see what happens.

@bleglord commented on GitHub (Jun 2, 2021): > ...was about to write this one up too :) > > Either I used the wrong value {{ summary.patches_last_installed }} or the value isn't being updated when patches run > > ![2021-06-02_110318 - trmm patches](https://user-images.githubusercontent.com/13395348/120504555-3d899380-c392-11eb-9c54-70e869e28a3d.png) The issue I'm seeing is actually different, here is a picture of what I'm seeing: ![image](https://user-images.githubusercontent.com/85239122/120522151-585c0800-c392-11eb-866a-aadfdec0d12a.png) I'll run through the debug mode process and see what happens.

kerem commented

2026-03-14 03:27:24 +03:00

Author

Owner

@bleglord commented on GitHub (Jun 2, 2021):

@bleglord follow the instructions here to run the tacticalrpc service in debug mode (stop the service first) https://wh1te909.github.io/tacticalrmm/troubleshooting/#agents-not-checking-in-or-showing-up-general-agent-issues

then from the ui, right click agent > run patch scan now
you should see what's happening in real time in the cmd window on the agent. paste any errors here

@silversword411 is your issue just that it's showing "Never" or do you also see the "No patches" where the list of windows updates should show up

This makes me think it is not a tacticalrmm error at all and I'm pretty sure it's related to the test environment I'm using.
The DNS records for mesh/rmm/api.company.com are technically no longer publicly available (They were set up temporarily to get tacticalrmm installed in the sandbox environment for testing, then nuked while the sandbox environment uses hosts file hackery to function with it).
It seems all other tacticalrmm components have no issue with this setup, but is it possible that the non-existent public facing DNS records are interfering with the update request since they hit externally?

Output:

POST  /api/v3/winupdates/  HTTP/1.1
HOST   : api.*******.***
HEADERS:
        Accept: application/json
        Authorization: Token *************************************
        Content-Type: application/json
        User-Agent: go-resty/2.6.0 (https://github.com/go-resty/resty)
BODY   :
{
   "agent_id": "*************************************",
   "wua_updates": null
}
------------------------------------------------------------------------------
~~~ RESPONSE ~~~
STATUS       : 500 Internal Server Error
PROTO        : HTTP/1.1
RECEIVED AT  : 2021-06-02T11:06:58.4545782-06:00
TIME DURATION: 41.6201ms
HEADERS      :
        Content-Length: 145
        Content-Type: text/html
        Date: Wed, 02 Jun 2021 17:07:00 GMT
        Referrer-Policy: same-origin
        Server: nginx
        Vary: Origin
        X-Content-Type-Options: nosniff
        X-Frame-Options: DENY
BODY         :
<!doctype html>
<html lang="en">
<head>
  <title>Server Error (500)</title>
</head>
<body>
  <h1>Server Error (500)</h1><p></p>
</body>
</html>
==============================================================================
time="2021-06-02T11:07:16-06:00" level=debug msg="Checking for windows updates"
2021/06/02 11:07:21.802336 DEBUG RESTY
==============================================================================
~~~ REQUEST ~~~
POST  /api/v3/winupdates/  HTTP/1.1
HOST   : api.*******.***
HEADERS:
        Accept: application/json
        Authorization: Token *************************************
        Content-Type: application/json
        User-Agent: go-resty/2.6.0 (https://github.com/go-resty/resty)
BODY   :
{
   "agent_id": "*************************************",
   "wua_updates": null
}
------------------------------------------------------------------------------
~~~ RESPONSE ~~~
STATUS       : 500 Internal Server Error
PROTO        : HTTP/1.1
RECEIVED AT  : 2021-06-02T11:07:21.8023363-06:00
TIME DURATION: 59.0951ms
HEADERS      :
        Content-Length: 145
        Content-Type: text/html
        Date: Wed, 02 Jun 2021 17:07:23 GMT
        Referrer-Policy: same-origin
        Server: nginx
        Vary: Origin
        X-Content-Type-Options: nosniff
        X-Frame-Options: DENY
BODY         :
<!doctype html>
<html lang="en">
<head>
  <title>Server Error (500)</title>
</head>
<body>
  <h1>Server Error (500)</h1><p></p>
</body>
</html>

@bleglord commented on GitHub (Jun 2, 2021): > @bleglord follow the instructions here to run the `tacticalrpc` service in debug mode (stop the service first) https://wh1te909.github.io/tacticalrmm/troubleshooting/#agents-not-checking-in-or-showing-up-general-agent-issues > > then from the ui, right click agent > run patch scan now > you should see what's happening in real time in the cmd window on the agent. paste any errors here > > @silversword411 is your issue just that it's showing "Never" or do you also see the "No patches" where the list of windows updates should show up This makes me think it is not a tacticalrmm error at all and I'm pretty sure it's related to the test environment I'm using. The DNS records for mesh/rmm/api.company.com are technically no longer publicly available (They were set up temporarily to get tacticalrmm installed in the sandbox environment for testing, then nuked while the sandbox environment uses hosts file hackery to function with it). It seems all other tacticalrmm components have no issue with this setup, but is it possible that the non-existent public facing DNS records are interfering with the update request since they hit externally? Output: ~~~ REQUEST ~~~ POST /api/v3/winupdates/ HTTP/1.1 HOST : api.*******.*** HEADERS: Accept: application/json Authorization: Token ************************************* Content-Type: application/json User-Agent: go-resty/2.6.0 (https://github.com/go-resty/resty) BODY : { "agent_id": "*************************************", "wua_updates": null } ------------------------------------------------------------------------------ ~~~ RESPONSE ~~~ STATUS : 500 Internal Server Error PROTO : HTTP/1.1 RECEIVED AT : 2021-06-02T11:06:58.4545782-06:00 TIME DURATION: 41.6201ms HEADERS : Content-Length: 145 Content-Type: text/html Date: Wed, 02 Jun 2021 17:07:00 GMT Referrer-Policy: same-origin Server: nginx Vary: Origin X-Content-Type-Options: nosniff X-Frame-Options: DENY BODY : <!doctype html> <html lang="en"> <head> <title>Server Error (500)</title> </head> <body> <h1>Server Error (500)</h1><p></p> </body> </html> ============================================================================== time="2021-06-02T11:07:16-06:00" level=debug msg="Checking for windows updates" 2021/06/02 11:07:21.802336 DEBUG RESTY ============================================================================== ~~~ REQUEST ~~~ POST /api/v3/winupdates/ HTTP/1.1 HOST : api.*******.*** HEADERS: Accept: application/json Authorization: Token ************************************* Content-Type: application/json User-Agent: go-resty/2.6.0 (https://github.com/go-resty/resty) BODY : { "agent_id": "*************************************", "wua_updates": null } ------------------------------------------------------------------------------ ~~~ RESPONSE ~~~ STATUS : 500 Internal Server Error PROTO : HTTP/1.1 RECEIVED AT : 2021-06-02T11:07:21.8023363-06:00 TIME DURATION: 59.0951ms HEADERS : Content-Length: 145 Content-Type: text/html Date: Wed, 02 Jun 2021 17:07:23 GMT Referrer-Policy: same-origin Server: nginx Vary: Origin X-Content-Type-Options: nosniff X-Frame-Options: DENY BODY : <!doctype html> <html lang="en"> <head> <title>Server Error (500)</title> </head> <body> <h1>Server Error (500)</h1><p></p> </body> </html>

kerem commented

2026-03-14 03:27:29 +03:00

Author

Owner

@silversword411 commented on GitHub (Jun 2, 2021):

@wh1te909 Here's one with all the checks-checked showing bug :)

@silversword411 commented on GitHub (Jun 2, 2021): @wh1te909 Here's one with all the checks-checked showing bug :) ![2021-06-02_133511 - patch date updates2](https://user-images.githubusercontent.com/13395348/120527330-38cfda00-c3a8-11eb-86a3-35eff4fe3097.png)

kerem commented

2026-03-14 03:27:34 +03:00

Author

Owner

@silversword411 commented on GitHub (Jun 3, 2021):

I've deleted, and recreated the automation policy, and applied to all new client batch. Took a while to update, but finally see the blue check/pending. Will check for updated dates tomorrow.

@silversword411 commented on GitHub (Jun 3, 2021): I've deleted, and recreated the automation policy, and applied to all new client batch. Took a while to update, but finally see the blue check/pending. Will check for updated dates tomorrow. ![2021-06-03_120705 - TRMM automation patching](https://user-images.githubusercontent.com/13395348/120676784-624e3b80-c464-11eb-9937-2e0eb81cf460.png)

kerem commented

2026-03-14 03:27:39 +03:00

Author

Owner

@wh1te909 commented on GitHub (Jun 4, 2021):

@bleglord no, if ure getting a 500 error that means u are hitting trmm endpoint but the reason it's giving u 500 is cuz of "wua_updates": null in the post body that should not be null (trmm is expecting a list of updates) so the issue is with the windows computers, probably windows update is corrupted on them. the trmm agent just uses the windows update api to call updates. try running in debug again and see if there are any other errors, not the http stuff
edit: also remember someone had this problem and the windows update service was not running or something

@wh1te909 commented on GitHub (Jun 4, 2021): @bleglord no, if ure getting a 500 error that means u are hitting trmm endpoint but the reason it's giving u 500 is cuz of `"wua_updates": null` in the post body that should not be null (trmm is expecting a list of updates) so the issue is with the windows computers, probably windows update is corrupted on them. the trmm agent just uses the windows update api to call updates. try running in debug again and see if there are any other errors, not the http stuff edit: also remember someone had this problem and the windows update service was not running or something

kerem commented

2026-03-14 03:27:44 +03:00

Author

Owner

@bleglord commented on GitHub (Jun 4, 2021):

@bleglord no, if ure getting a 500 error that means u are hitting trmm endpoint but the reason it's giving u 500 is cuz of "wua_updates": null in the post body that should not be null (trmm is expecting a list of updates) so the issue is with the windows computers, probably windows update is corrupted on them. the trmm agent just uses the windows update api to call updates. try running in debug again and see if there are any other errors, not the http stuff
edit: also remember someone had this problem and the windows update service was not running or something

Figured it out.
Old broken WSUS configuration was being applied in the environment even though the WSUS server itself was no longer there.
Issue doesn't exist in fresh environment that never touched the broken WSUS setup

@bleglord commented on GitHub (Jun 4, 2021): > @bleglord no, if ure getting a 500 error that means u are hitting trmm endpoint but the reason it's giving u 500 is cuz of `"wua_updates": null` in the post body that should not be null (trmm is expecting a list of updates) so the issue is with the windows computers, probably windows update is corrupted on them. the trmm agent just uses the windows update api to call updates. try running in debug again and see if there are any other errors, not the http stuff > edit: also remember someone had this problem and the windows update service was not running or something Figured it out. Old broken WSUS configuration was being applied in the environment even though the WSUS server itself was no longer there. Issue doesn't exist in fresh environment that never touched the broken WSUS setup

kerem commented

2026-03-14 03:27:49 +03:00

Author

Owner

@silversword411 commented on GitHub (Jun 4, 2021):

Looks like the 2 marked patches by automation policy did install. The date did update at the top.

The two patches that installed dropped to close to the bottom of the list though when they were previously at the top, so I get that "patches" list has no rhyme or reason for where they are/sort order.

@silversword411 commented on GitHub (Jun 4, 2021): Looks like the 2 marked patches by automation policy did install. The date did update at the top. The two patches that installed dropped to close to the bottom of the list though when they were previously at the top, so I get that "patches" list has no rhyme or reason for where they are/sort order. ![2021-06-04_165449 - patch testing2](https://user-images.githubusercontent.com/13395348/120861740-c8ff5200-c555-11eb-9b2e-9f3a023a2d06.png)

kerem referenced this issue

2026-03-14 07:43:25 +03:00

[PR #2294] [MERGED] Fixed duplicate hostnames in subject and include Client/Site in resolved email body #3869

Rows
Columns

[GH-ISSUE #551] Patches Perpetually Show "No Patches" #2294