Hello everyone,
We are using a Bigfix 10.0, patch license, on Windows platform.
We have a policy to trigger a patch every Friday night. The patch scheduler does not have the “force restart” option checked, because we don’t have control about the restart time.
Therefore we need to execute a restart on every Monday morning (6am) if it is needed like the fixlet “Restart Needed - Triggered by a BES Action”.
How can we do that restart every Monday?
Thanks in advance!
Regards,
Guido.
On the Execution Tab, you can select the “Day” you want it to run and also the restrict the time it could start and end.
Make sure to check “Reapply” unlimited times
The “Relevance” statement will make sure it will become not relevant when the Computer will finish restarting
https://help.hcltechsw.com/bigfix/10.0/remediate/Platform/Console/Dialogs/execution_tab.html
Hello orbiton,
First of all, thank you for your help. I appreciate it.
The action executed yesterday at 6:06 am, the check “Reapply” unlimited times was checked. Please find the action exported (.bes file):
Auto-Win2019 - lunes 6_06am -Restart Needed - Triggered by a BES Action.bes (4.3 KB)
However it runs only one time, it didn’t excuted for a second time. The server “simeto” is in “pending restart” status again, please find below the log action for simeto. The fix installation on simeto has finished at 6:17 am, and the action window finish at 7 am.
Perhaps I didn’t understand your sentence about “Relevance”. It is not clear for me where (or how) I should implement it. Could you please give me more detail about it?
Thanks in advance,
Guido.
@guido Just to make sure. Look into the Client Log file and make sure that after the action had been applied on the computer. The machine was actually restarted - from the screenshoot it looks like the computer was flagged as pending restart but did not finished the restart itself and because of that it will not reapply itself.
Agree with orbiton, check that the machine actually did restart by checking the ‘boot time of operating system’ relevance or ‘System Boot Time’ property.
If the machine actually did reboot as scheduled, but still appears to have ‘Pending Restart’ after rebooting, you may be encountering an issue where we don’t detect the ‘pending restart’ has completed because of badly-implemented software that writes to the PendingFileRenameOperations registry key. This causes a false detection of ‘Restart Required’ by BESClient, and when we think a restart is still required it does not clear any of the actions’ Pending Restarts.
You can configure the BESClient to either ignore some of the PendingFileRenameOperations values, or all of them, see Baseline Fixlets having "true" in there relevance become not relevant after restart
Thanks @orbiton and @JasonWalker so much for your time . I was reading your links and checking and checking our logs and registry keys
You are right about the time of reboot. It wasn’t at 6:06 am as log action said. It was at 6:15:51 am based on system boot time. The end of the patching based on the event viewer was at 6:17:19 am.
Please find log lines of the Bigfix client in simeto at the end of this message. #7561 is the restart action.
Regarding the “pending restart” issue, simeto has “PendingFileRenameOperations” with value to some files. However other machines, for instance my pc has values too for “PendingFileRenameOperations” and it is not in “pending restart” status. My pc doesn’t have _BESClient_ActionManager_PendingRestartExclusions property set.
The difference is simeto has the BESPendingRestart key, please find it in the screenshot below:
My scenario is to run a policy deploy every Friday night (without ‘force restart’ because I don’t know the end of the time of the deploy and some backups are running on weekends). Monday morning at a fixed time we need a restart if it is necessary.
I would appreciate it if someone could give us some light about what is happening.
Regards,
Guido.
— simeto bigfix client logs - #7561 is the restart action —
At 06:06:00 -0300 -
ActionLogMessage: (action:7561) Action signature verified for Execution
ActionLogMessage: (action:7561) starting action
At 06:06:00 -0300 - actionsite (http://cefeo.wad.bcu.gub.uy:52311/cgi-bin/bfgather.exe/actionsite)
Command succeeded (evaluated true) continue if {not locked of action lock state} (action:7561)
Command succeeded action requires restart (action:7561)
At 06:06:00 -0300 -
ActionLogMessage: (action:7561) ending action
At 06:06:08 -0300 -
Report posted successfully
At 06:11:02 -0300 -
Report aborted with restart command pending
At 06:11:05 -0300 -
Report posted successfully
BigFix Restart (Force count:1) from ActionID 7561
At 06:11:30 -0300 -
ActiveDirectory: Purging User information - Domain: WAD User: ******************
At 06:12:36 -0300 -
BigFix Restart (Force count:2) from ActionID 7561
At 06:13:52 -0300 - Enterprise Security (http://sync.bigfix.com/cgi-bin/bfgather/bessecurity)
Relevant - Disable hardening changes for Windows DCOM Server Security Feature Bypass (CVE-2021-26414) - KB5004442 (fixlet:500444201)
Fixed - Enable hardening changes for Windows DCOM Server Security Feature Bypass (CVE-2021-26414) - KB5004442 (fixlet:500444203)
Fixed - Disable the MSDT URL Protocol for Microsoft Support Diagnostic Tool Vulnerability (CVE-2022-30190) (fixlet:2022301901)
Fixed - 5028407: Manage the vulnerability associated with CVE-2023-32019 for Windows Server 2019 - Windows Server 2019 - KB5028407 (fixlet:502840714)
Fixed - Manage Office and Windows HTML Remote Code Execution Vulnerability (CVE-2023-36884) (fixlet:3688401)
At 06:13:58 -0300 - Updates for Windows Applications (http://sync.bigfix.com/cgi-bin/bfgather/updateswindowsapps)
Fixed - Adobe Flash Player - Disable Flash Player Update (fixlet:1070005)
At 06:14:00 -0300 - Enterprise Security (http://sync.bigfix.com/cgi-bin/bfgather/bessecurity)
Fixed - 4577586: Update for Removal of Adobe Flash Player for Windows Server 2019 for x64-based systems - Windows Server 2019 - Adobe Flash Player - KB4577586 (x64) (fixlet:457758615)
At 06:14:07 -0300 -
BigFix Restart (Force count:3) from ActionID 7561
At 06:15:32 -0300 -
Report posted successfully
At 06:15:41 -0300 -
Client shutdown (Service manager shutdown request)
********************************************
Current Date: October 2, 2023
Client version 10.0.8.37 built for WINVER 6.0 i386 running on WINVER 10.0.17763 x86_64
Current Balance Settings: Use CPU: True Entitlement: 0 WorkIdle: 10 SleepIdle: 480
IP Address 0: ********
IP Address 1: **********************************
Host name: SIMETO
we had similar case were we wanted to have server rebooted 1wk and initially we also focused on the pending-restart option and we did not get success everytime we added additional logic to check if machines uptime > 4days and if thats the case reboot the device.
Relevance we use: (pending restart Or uptime of operating system / day > 4)
Action in our case runs every saturday between 8:00pm - 9:00pm
Hope this helps
Hi Denis,
Have I had a chance to test that relevance expression in the “debug” dialog or other environment? I think my relevance expression is returning true.
Please find below my relevance expresion for the restart action.
Revieviews the expression “uptime of operating system / day > 4”, actually I couldn’t restart a server if it is not necessary.
Thanks,
Guiudo.
Hi Guiudo,
You should be okay using
“pending restart or uptime of operating system / day > 4”
the extra relevance you added is actually covered as part of pending restart
Hi Denis,
I appreciate your response. Thank you.
Please find below an screenshot with the “pending restart” relevance updated.
Currently my question is regarding to the windows time, if can I change the ‘4 days’ windows time to 15 minutes? The restarting windows time is 2 hours, Monday 5am to 7am, In that time I would like to have more than one restart if the patching process requires restarts. Do you see any negative impact with that?
Additionally if that is ok I would like to know which is the exact expression, I think this one has errores: “uptime of operating system / minute > 15”
Thanks in advance!.
Regards,
Guido.
relevance#3 before to the change: pending restart
relevance#3 after to the change: pending restart OR uptime of operating system / day > 4
