Testing this is difficult because it seems you can’t schedule something for that same day; in other words, you can’t schedule something to kick off in 30 minutes. Even with a schedule of Daily, Next Run shows the next day. Anyway, I set my calendar to watch what happens when the next run came around for a single targeted endpoint with a few relevant patches. Nothing. Next Run showed the next day.
Anything I can look at to verify things are working? I was looking for an Action to kick off at some point before the Next Run, but nothing. What should I look for?
###UTC time zone setting can help
When creating schedule, by default it use “Client Time” as time zone settings, by design, the default time to create the Multiple Action Group is UTC +14. One thing regarding +14 time zone is that this is the earliest time zone on earth, meaning that areas in this zone are the first to see a new day, so it will ensure the client time apply to all computers on earth for that day. https://www.ibm.com/support/knowledgecenter/en/SSTK87_9.5.0/com.ibm.bigfix.webui.doc/WebUI/Users_Guide/t_setting_patch_policy_schedule.html
So in this case, it’s hard to set schedule in the same day.
To verify schedule behavior, I am thinking maybe you can try UTC as time zone settings. Say like currently I am in +1 time zone and now it’s 3:50 pm, then you try to create policy schedule, you can set schedule time as 3 PM UTC time, so the schedule will be run after 10 mins.
###What happened for that schedule?
We are thinking to add one UI to display events for certain schedules, this feature is planned in roadmap. But for now, enable verbose log for WebUI is needed to see what happened for certain behaviors in detail.
Patch Policies App Logs
– C:\Program Files (x86)\BigFix Enterprise\BES WebUI\WebUI\logs\autopatch.log
– Default is not Verbose. To enable verbose logging:
Edit the computer setting of WebUI Service and add a new setting: "_WebUIAppEnv_DEBUG“
The value is “bf*“ (bf* will enable all verbose log for WebUI Apps)
Restart WebUI Service
Sometime schedule will be executed but no Multiple Action Group will be created in Bigfix Console, one reason can be no relevant patches, after verbose mode enabled and you can see log like below: message: 'There is no patches included in this preview, will not create MAG!!!' }
To verify if there is any patch relevant to some devices, you can check Applicable Patches in “policy detail view” -> “patches” tab.
Hope the information helps and feel free to let us know in case you have further questions.
Thanks for the feed back… I have had the patching job running for three days now with zero activity so I think it is safe to say it isn’t working. The patches are relevant for the endpoint. I’ll probably discontinue my trials at this time as this feature isn’t ready.
And though I can appreciate wanting to get new features out the door to see how or if the masses embrace them, it may be best to test them a bit more internally before sending them to customers.
@AlexaVonTess If you’re seeing no activity after three days I think that’s a bug. We’re happy to work through L3 and maybe schedule a call to see if there’s something simple that was miconfigured or whether there’s something else that’s going on.
@AlexaVonTess
After you enable WebUI verbose log by following the steps in my previous post, you can zip all files under folder C:\Program Files (x86)\BigFix Enterprise\BES WebUI\WebUI\logs\ and upload here, we can start from checking the logs.
@AlexaVonTess
Thanks for the log info.
It seems you enable the verbose log starting from 2017-11-14T10:59:27.796Z.
After that, I can see DB initialization completed and Engine will wake up again in 328.52211666666665 minutes …, so things looks good to me.
But before you enable verbose mode, I can see some suspicious point, 2017-11-13T16:31:32.078Z bf:autopatch:engine:error Error detected: 2017-11-13T16:31:32.078Z bf:autopatch:engine:error Error: bad status [403] {"format":"Access is denied","arguments":[]} at DuplexWrapper.onEnd (C:\Program Files (x86)\BigFix Enterprise\BES WebUI\WebUI\sites\WebUI AutoPatch_12488_3_1506651709\autopatch-app\node_modules\bfquery\lib\await.js:45:23) at emitNone (events.js:72:20) at DuplexWrapper.emit (events.js:166:7) at C:\Program Files (x86)\BigFix Enterprise\BES WebUI\WebUI\sites\WebUI Auto Patch_12488_3_1506651709\autopatchapp\node_modules\readable-stream\lib\_stream_readable.js:934:16 at nextTickCallbackWith0Args (node.js:489:9) at process._tickDomainCallback (node.js:459:13)
So the log above telling, bfquery failed with error bad status [403] {“format”:“Access is denied”.
Based on my knowledge, this can be caused by certain operator doesn’t have permission to use Bigfix RESTful API to access Bigfix Server.
Btw, do you login WebUI as master operator or non-master operator? If you login as non-master operator, can you check with your master operator to see if you be granted for related resource access?
I logged in as MO to create the actual schedule (as I think you have to). The computer was then added by a non-MO if I recall, who was not allowed REST-API; I’ve since allowed it and will check tomorrow morning to see if patching takes place.
It doesn’t seem to be working. Here is the latest autopatch.log. If you’re not seeing anything obvious, I won’t be able to spend any more time on this; I don’t think it was ready for release. I certainly appreciate the willingness to help, however!
@AlexaVonTess I was able to see the action deployed on behalf of an Non-MO user with full permission. However, when I unassigned one of the RHEL sites from the Non-MO user, I got the same 403 error as in the log for my RHEL policy. You may want to check the applicable patches under Patches tab for your policy. The Non-MO user may have some site unassigned therefore not able to apply some of the patches. Additionally, there might be other permission related cause such as one of the targeted computer is unassigned from the Non-MO user.