Maintenance Windows and Devices in Different Timezones

Last Modified

Mon Oct 19 13:52 GMT 2020

Description

  • This article covers the functionality of creating a maintenance window for a device that is in a different timezone than the N-able N-central server as well as how the downtime functionality works for those devices.
  • There are two different behaviors based on what type of Maintenance Window is used:
    • Downtime Window
    • All Other Maintenance Windows

Environment

  • Any N-able N-central

Solution

  • Downtime Window:
    • This Maintenance Window does not impact the device at all.
    • Instead this type of downtime only tells N-able N-central to ignore any alerts during this period, but the device itself is unaware of the window.
    • As a result, the Downtime Window is strictly in N-able N-central time and not device time so some timezone conversion needs to be performed.
      • If the window is set for 2am it will happen at 2am N-able N-central time which would be adjusted by the difference in timezone.
      • So a device in a timezone two hours ahead would affect the alerts for the device starting at 4am.
    • The device is removed from downtime Only after the downtime window is completed.
  • Maintenance Window:
    • The Maintenance Window is created at N-able N-central time, but is presented to the agent as a cron string.
    • What this means is that no translation is performed during the process so that 2am in the maintenance window will be 2am on the device regardless of timezone to make the window as consistent as possible across devices if you are supporting nationally or globally.
    • Once the maintenance window is recorded by the agent in its configuration it keeps that time static even if the device time changes due to daylight savings and so on.
    • When the device goes into maintenance and the downtime option is selected to prevent alerts from triggering during planned maintenance N-able N-central puts the device in downtime during the device time not N-able N-central time, but the logs, such as Agent Status, will show based on N-able N-central time when recorded in the UI. While this requires the user to know the device is in a different timezone when looking at the services, etc, it creates the most consistent time-based records for the services when they are reported as a state change to N-able N-central .
    • The logic for the process:
      1. All applicable maintenance windows defined in rules and device level is sent to the appliance as a cron string (static time).
      2. If "place device in downtime during reboot " option is enabled in the maintenance window then agent sends a message to N-able N-central when it is going to reboot.
      3. On receiving the message the server looks at all the applied maintenance windows for that device and checks if any are supposed to be active and whether the option - 'place device in downtime during reboot' has been enabled'.
      4. N-able N-central then uses the device's timezone to determine that the cron is active based on the appliance.reported_timezoneid table in the database.
      5. If everything checks out then the device is placed into downtime with a maximum allowed duration that is set on that particular maintenance window.
      6. This max downtime is the time the device can remain in downtime if the agent does not come back up after reboot.
      7. Once agent comes back the device is placed out of downtime immediately. This transition happens either after agent checkin or XMPP communication is restored.
  • In summary, the Downtime Window is N-able N-central server based time and the Maintenance Window is device time based.