ZEN MASTER June 2021 RELEASE NOTES

the following updates will be included in the zen master june 16, 2021 release improvements this release of zen master delivers a major rework of the event notification system in zen master with this release you can configure every alert that zen master can generate including the rules that govern when an event is classified as a warning or an error based on user defined escalation and de escalation thresholds, where applicable management of the new event notification system is under the configuration >events menu every zen master account will start with default event profile (1) the user cannot modify the default profile but can make a new event profile using the clone button (2) after naming and saving the new event profile you will see it in the event profiles list (1) now you can edit the event rules in the new event profile using the edit rules button (2) to see details for an event rule or edit it, click on the down arrow to drop down the details for the rule rules are grouped by resource type – adaptive channel, broadcaster, source, etc and then by an error group – usage, configuration, etc and then by an error code some rules have single reason for a warning/error, such as cpu usage values exceeding a threshold, while other rules have multiple reasons for the warning/error, such as an adaptive channel going offline depending on the type of rule there are relevant settings for thresholds and the generation of user notifications the thresholds define whether the event is a warning event or an error event if a zen master resource has any related error events, it will be in error state if there are no error events on the resource, then if it has any related warning events, it will be in warning state when an event escalates to an error, a user notification can be generated if enabled in the event rule when an event is no longer an error, an “ok” notification letting the user know that the error conditions has been de escalated can be generated, based on setting in the event rule normally, the “ok” notification occurs when the zen master resource no longer has any errors and thus is in “ok” state however, if the "ignore object state for notification generation" checkbox is checked, then the “ok” notification occurs when each error event has been de escalated currently, all users who have access to a zen master resource, based on roles and access tags, will see the same notifications as defined in the event rules allowing different users to get different notifications is being considered for a future release different types of event rules with different escalation approaches are implemented based on the zen master resource type and error group the most common type of event rule escalates based on the number of times an event happens within a window of time if the event type configuration is set to warning, as shown in the example below, it will be a warning event upon the first occurrence of the event and will escalate to an error event based on occurrences and time window if the event does not occur again in the time window, then it will de escalate back to “ok” state the event type configuration can also be set to error, which means it will be an error event upon the first occurrence of the event when event type is set to error there is no de escalation process as always, user notifications happen on error events another type of event rule is available for simple events where thresholds are relevant this rule is used for situations like broadcaster license expiration which progress towards a final error state and there is no need for de escalation in the example below, there is a threshold for a warning event at 14 days prior to the license expiration and an threshold for an error event at 7 days prior to the license expiration as always, user notifications happen on error events another type of event rule is slightly more complicated events where both thresholds are relevant, and de escalation can occur for this type of event, it is a warning event when the value crosses one threshold and an error event when the value crosses a higher threshold but if the value falls back below either threshold, for the specified time window, then it will de escalate back to the appropriate state as always, user notifications happen on error events the last type of event rule does not allow any user configuration for error escalation because it is a critical issue however, the user can configure notifications just like all other event rule types whenever you modify an event rule, be sure to click the save button you can also see the save status of the rule next too its title it will either say “not save” or “modified”, after you save it after having modified an event rule, you can always set it back to default values with the reset button once you have defined the event rules to your liking, they are applied individually to each resource – channels, broadcasters, sources, etc – in zen master when creating or editing the resource you will see a pull down menu titled “events configuration profile” where you can select the appropriate event profile note that once this release is deployed, any customizations of the old notifications system will no longer apply and will need to be re implemented using the new system the following additional improvements were implemented in this release • added dtls status to zixi and rist targets • added support for hls sources • added ability to manually switch active failover source • visualize traceroutes on a map • removed zixi license management and monitoring from zen master; please use zixi customer portal • added ability to sort channels by source and target columns • added active broadcaster columns to targets and channels • changed srt default latency to 1000ms to match broadcaster default • updated free for all (ffa) authorization mode ui to require at least one input/output setting • added api endpoint to list child targets • added dns prefix validation to clusters create and update api endpoint • cmaf (dash + fmp4 hls) is now disabled by default bug fixes the following issues were resolved • fixed incorrect source information shown on multi broadcaster clusters • fixed issue with editing zixi pull target name requiring restart • fixed issue with being able to import duplicate mediaconnect flows • fixed error when deleting a user that has custom grids • fixed invalid parameters error when cloning a zixi target • fixed maps occasionally not auto refreshing • fixed some scte errors not being logged correctly • events message search inconsistent when message includes dashes • fixed missing tooltips on events log page • fixed dashboard issues list being inconsistent with main menu error/warning counters