The BigFix team is pleased to announce the release of a new version of BigFix Insights and Patch Policy that includes the following product enhancements:
Improvements to the BigFix Insights ETL
Resolution of vulnerabilities and fixing of bugs for BigFix Insights
Usability improvement in the creation of the Patch Policy and its schedules
Summary
BigFix Insights ETL Improvements: Added clean up step for Custom Analysis Property: Insights could not identify when Custom Analysis Properties were deleted from the parent Custom Analysis. This caused reporting of inaccurate information in Insights that did not match with the actual data in BigFix. The Insights ETL was enhanced to identify custom Analysis Properties that user deleted, and correspondingly mark those custom property as "deleted" in the Insights database.
BigFix Insights Bug Fixing: Fix the defect where a non-sysAdmin user couldn’t add a new datasource
Disable single schedule for editingt: In Patch Policies with multiple schedules, editing a single schedule no longer requires disabling the entire policy. Individual schedules can now be disabled for modification without impacting other schedules.
Assign Timezone to the Patch Policy Schedule: Patch Policy Schedule creation now supports specifying a timezone other than UTC. This enhancement simplifies schedule creation by eliminating the need for manual timezone conversions, especially for environments with computers distributed across multiple regions.
I've disabled a specific schedule by pressing the "Active" button on "Schedule Status" - The button turned Gray and the "Edit Schedule" was still disabled.
After reopening the window, the Schedule status was still on "Active" status.
@ADL It looks like you can only specify a specific timezone and not a regional time zone. For example it does not allow you to specify "Israel Timezone" - and the server will make the summer/winter timezone changes.
@atlauren@orbiton the new functionality allows for scheduling in timezones other than UTC, removing the need for manual conversions. Operators can now set policies based on their own local time instead of calculating the UTC equivalent.
Note that if you need to run a policy at a fixed local time, you can still use the 'Client Time' option.
@orbiton we are looking ito this.
There is a refresh page issue, meaning that if you disable the Schedule, then refresh the page, and reopen the schedule, the "Active" switch now show the correct value.
Editing the Schedule when the entire Policy is still active is still not working, and we are looking into this.
In Israel for example the local time can be UTC+2 or UTC+3 it is being change between summer / winter - If it will be possible to take that into account that will be great because as of right now, I still need to Disable the Policy and make changes each winter /summer while using the new option