Community store specification

Added in

Easy Tune retrieves community curated tuning packs from the EasyTune_Overrides GitHub repository. This article describes the formatting required for contributions to this repository.

If using Easy Tune Enterprise and or later you will also be able to use a custom community store to manage your company tuning packs using this format in your own GitHub hosted repository.


Repository root

The repository root should contain 3 main components:

  • Index.json

  • A folder for each tuning pack

  • (optional)


This file allows Easy Tune to parse the tuning packs in your store. It is an ordered array of objects with the following properties:

  • TuningPackName – The name of the tuning pack. It must match the tuning pack folder name.

  • TuningPackDescription – Currently unused.

        "TuningPackName":  "Company Inc. pre-prod SQL overrides",
        "TuningPackDescription":  ""
        "TuningPackName":  "Company Inc. pre-prod RHEL 7 overrides",
        "TuningPackDescription":  ""
] (optional for custom community stores)

This file is optional, however, is best practice for GitHub repositories in general. Written in Markdown you can use this file to quickly tell people about your project and provide rules on how they can contribute. GitHub themselves have documentation going into further detail here.

Tuning pack folders

Tuning pack folders themselves contain 3 main components:

  • details.csv

  • metadata.json (optional)

  • (optional)


This file defines your tuning pack and the overrides applied at each level in a comma-separated values format. The contents and creation of tuning packs are documented in more detail here.

Note that the file must be named ‘details.csv’. Names for the tuning pack are defined as part of the index file and folder structure.

metadata.json (optional for custom community stores)

This file defines the additional details shown in the SCOM console when selecting a tuning pack:

It contains the following properties:

  • Author – The name of the tuning pack author with their job title in parentheses.

  • ConfigurationOptions – An array of properties describing the different tuning levels.

    • ConfigurationName – Must match the tuning level name in the CSV.

    • DisplayName – Not currently used.

    • Level – A unique signed Int32 value for each level in the tuning pack.

    • Summary – A brief description of the tuning level.

  • Description – A brief description of what the tuning pack covers.

  • Tags – Not currently used.

  • URL – A URL pointing to online documentation. Typically the GitHub page for the pack.

    "Author": "Jo Bloggs (Company Inc. technical writer)",
    "ConfigurationOptions": [{
            "ConfigurationName": "Basic",
            "DisplayName": null,
            "Level": 0,
            "Summary": "The core monitoring elements for server health and uptime, minimal performance collection."
        }, {
            "ConfigurationName": "Balanced",
            "DisplayName": null,
            "Level": 1,
            "Summary": "A balance of monitoring and performance collection for servers."
        }, {
            "ConfigurationName": "Full",
            "DisplayName": null,
            "Level": 2,
            "Summary": "The most robust monitoring scenario, including additional performance collection."
    "Description": "Overrides for monitoring servers in the Company Inc. pre-production environment.",
    "Tags": null,
    "URL": ""
} (optional for custom community stores)

This file is optional, however, can be used as a quick and easy landing page for your tuning pack. We recommend that it provides a synopsis for the pack, the intention behind each of the tuning levels, and the name(s) of any management pack tuned by your tuning pack.

# IIS 7 Tuning
This tuning pack covers IIS 7, which was shipped with Server 2008.  Microsoft authors both management packs covered in the Tuning Pack.

## Tuning Levels
The following tuning levels are included in this pack, 

### Discovery Only
Included with every Tuning Pack, discovery only is an excellent way to learn the scope and content of your environment without any alerts or data collection.

### Essentials
Matching the name, the essentials level is designed to give you bare-bones monitoring for your environment.  To over-simplify things, this tuning level attempts to reduce alerts to only those actionable items at the risk of missing some proactive notifications.
Example items included in the Essentials:
- Windows service stopped
- Service failed to start / load configuration

### Balanced
The balanced level is designed to provide additional monitoring and performance collection over the essential level, while still reducing unnecessary noise from the default and full tuning options.  With the variance between deployments, the balanced level is a great candidate to start with when tuning your custom level.

### Full
Using the full level creates a comprehensive monitoring environment, with the downside of additional alerts and data collection.  Full monitoring includes alerts for more unique and specific conditions as well as some increased monitoring and performance collection intervals.

### Management Packs Tuned