Design Principles & Recommendations

Design Overview

We have provided some guidance as to the timing and configuration we believe would be a good baseline for many environments, however, be sure to review these settings and make sure they will work for you. We believe that the configuration parameters should be separate from the tests are run against your environment. Our reason for this is that it provides maximum portability between multiple environments and protects code updates from overwriting your configuration.

Our Guiding Principles:

• Identify the types of tests you want to automate (from easier to harder):

  • Automate built-in commands and parse the output
  • Create simple commands to run against multiple systems
    • (i.e. check systems are online with Ping)
  • Create custom commands that read data
  • Create custom commands that create and track data

• Identify where the tests should run:

  • Run on a single server, reaching out to remote systems
  • Initiate on a single server, and spawn local jobs on remote systems
  • Identify timing for the tests to run:
    • Hourly, multiple-times a day, daily, weekly, etc.
  • Identify the Desired output level

• Do you want to be notified if this fails a single time?

• Do you want to be notified only if this fails for multiple runs?

• Do you want to be notified when the failure no longer occurs?

• Identify the alerting methods

• Everything should write to the event log.

  • Alerts can be configured in Event Log management systems, in conjunction with alerts from the script. For critical issues, multiple alerting methods can be configured to provide redundancy to make sure no alerts are missed.
  • Custom Event IDs and Providers are used for all alerts in this project.
    • Email Alerts
    • Slack Alerts
    • Toast Alerts
    • MS Teams Alerts