mirror of
https://github.com/amidaware/tacticalrmm.git
synced 2026-04-26 06:55:52 +03:00
[GH-ISSUE #49] Feature Request: Patch Management Policy #1962
Labels
No labels
In Process
bug
bug
dev-triage
documentation
duplicate
enhancement
fixed
good first issue
help wanted
integration
invalid
pull-request
question
requires agent update
security
ui tweak
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/tacticalrmm#1962
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @bradhawkins85 on GitHub (Aug 17, 2020).
Original GitHub issue: https://github.com/amidaware/tacticalrmm/issues/49
Originally assigned to: @sadnub on GitHub.
Would it be possible to add patch management settings to the policy manager?
@sadnub commented on GitHub (Aug 20, 2020):
@wh1te909 Would this need to be another tab in the policy manager? Similar to how checks/tasks are setup? It might be tricky to know when to override the agent windows update settings since they are added on agent creation.
@bradhawkins85 commented on GitHub (Aug 21, 2020):
Yes, I was thinking it would be another tab in policy manager the same ad checks/tasks.
It's not the end of the world if it can't be done but just thought i'd ask :)
@wh1te909 commented on GitHub (Aug 21, 2020):
So actually patch management policy for individual agent's is not working yet, it was working at some point but when I redesigned the windows agent a while ago I never re-implemented it. To actually install windows updates now, you have to right click on a windows update in the agent's south pane under the Patches tab, and click "Approve" on each update that you want to install. Then right click Agent > Patch Management > Install Patches now to actually begin the install. So basically we can design it however we want @sadnub and make changes to the setting applied on agent creation, since atm it doesn't actually do anything.
@sadnub commented on GitHub (Sep 9, 2020):
@bradhawkins85 Patching policies have been added to Automation manager. I just submitted a PR to allow bulk updating the agent patch policies to inherit from an automation policy if one exists. You can update the Agent auto approval settings to inherit and it will pull the patch policy.
@bradhawkins85 commented on GitHub (Sep 10, 2020):
Thank you @sadnub
What happens with the, Installation Schedule, Reboot After Installation and Failed Patches settings. Are these automatically inherited by an agent or ignored when a patch policy is applied?
It would be good if they could inherit from the policy but also be set manually like the approvals.
@sadnub commented on GitHub (Sep 10, 2020):
@bradhawkins85 Currently, if a policy is inherited, it will use the policies settings on the agent. I could allow for overriding the other settings on the agent as well. I will work on that. Thanks!
@bradhawkins85 commented on GitHub (Sep 10, 2020):
May or may not have just had an issue with the patch schedule. otherwise the issue is with my setup.
I applied the policy to a server to install at 2am and reboot if needed, the updates installed at 7pm instead and rebooted the server.
The client server has the correct time as does the RMM server. I have also got the correct timezone set in Default agent timezone.
Could this be a timezone thing with a component installed on the RMM server? I notice when I manually run a task the Last Run Time shows as UTC but the Last Response time shows as local time (UTC +10).
@wh1te909 commented on GitHub (Sep 11, 2020):
@bradhawkins85 please try now we just fixed timezone issues and im still testing but so far so good, i just had 10 workstations update at the correct local time which were not working before. Still need to work on showing the correct timezone on the frontend everywhere that there is a date, because now it's a mix of UTC and agent local time.