The Settings Matrix: Every Setting, Every Level, One Screen

Every Atlas AVD setting can be set once for the whole deployment, once per tenant, and once per host pool. The Settings Matrix shows all three levels side by side for every setting, with the value that is actually in effect and the level it came from. This is how it works, how to use it, and why we have not seen another MSP tool do the same.

By David,

Ask an MSP engineer why a particular host pool deallocates idle session hosts after 15 minutes when every other pool waits 30, and watch what happens. They open the pool's settings page. Then the tenant's settings page. Then a global defaults page, if the tool has one. Then a script someone wrote two years ago. Somewhere in that tour the answer is sitting in plain sight, but nothing on any of those pages says this is the value that wins, and this is where it came from.

Atlas AVD answers that question on one screen. The Settings Matrix lists every setting Atlas manages, shows what it holds at the Global, Tenant and Host Pool level side by side, and prints the Effective value Atlas actually applies, labelled with the level that supplied it. It is the one place to change a setting and the one place to find out why a setting is what it is.

The short version: a value flows down from Global to Tenant to Host Pool. The most specific level that holds a value wins. The matrix shows all three levels and the winner for every setting at once, so you set things as high up as they hold true, override only where a tenant or pool really differs, and never guess which value is in effect.

Three levels, one table

Most Atlas AVD settings can be set at three levels:

  • Global is the baseline for the whole deployment. Set it once and every tenant inherits it. Only a platform administrator can edit this column.
  • Tenant is one customer's directory. A tenant inherits the global value unless it holds a value of its own.
  • Host Pool is one pool inside that tenant. A pool inherits from its tenant unless it holds its own value.

Below all three sits the built-in application default, which applies when nothing is set anywhere.

Open Settings → Configuration Matrix (the page is titled Settings Matrix, so you will see both names) and every setting appears as one row with five columns: Setting, Global, Tenant, Host Pool and Effective. Each cell tells you the state of that level:

  • Inherited. This level holds no value of its own and uses the one above it.
  • Override (Set). This level holds its own value, which replaces the one above it for everything below.
  • Default. Nothing is set anywhere, so the built-in default applies.

The Effective column is the value Atlas applies to the tenant and host pool you are looking at, with a label saying which level it came from. That label is the whole point. You never have to work out the precedence in your head, because the table has already done it.

What lives in the matrix

The matrix is not a page for a handful of toggles. It is the registry of Atlas's own operating policy, grouped into categories you can filter on:

  • Compute & VM Lifecycle and autoscale. The house autoscale default, load balancer choice, Start VM on Connect, how many VMs Atlas starts and stops in parallel, always-on hosts.
  • Provisioning and VM extensions. Provisioning concurrency, and which Azure VM extensions every new or reimaged host gets: Antimalware, Azure Monitor Agent, Defender for Endpoint onboarding, the Atlas agent.
  • Security & Compliance. Session timeouts, idle lock, re-authentication for sensitive pages, BitLocker policy, Defender settings, audit retention.
  • Software Distribution and browser policy. The organization-wide WinGet baseline, force-installed browser extensions, managed bookmarks and console session policies.
  • FSLogix, imaging, notifications, cost controls, feature modules and more.

Windows policy follows the same chain. The Group Policy categories in the matrix cover the ADMX policies and Windows security settings Atlas applies to session hosts, and each one inherits Global → Tenant → Host Pool policy by policy, exactly like the rest of the table. A security baseline you define once at Global reaches every pool in every tenant, and the one pool that needs an exception overrides just the policy it needs.

Two deliberate limits keep the matrix trustworthy. Secrets such as SMTP passwords and AI provider keys never appear in it, readable or writable. And a setting whose native page performs side effects beyond the database write, such as license-tier clamping, shows its resolved state here with a Read-only here badge and a link to the page that owns it, rather than duplicating that logic. A row marked N/A has no host pool level, Set at creation means the pool copied the value when it was built, and Per pool links to where that setting is managed.

Changing a setting

Editing happens in place. Find the row, click the value in the column you want to change, and choose a new value. To remove an override and go back to inheriting, choose Inherit (Clear). Before anything is written, a confirmation shows the current effective value and the new one, so you see the consequence of the change, not just the change. Confirm, and it applies immediately to the level you edited and everything that inherits from it. There is no staged draft to lose on a refresh.

Every setting also has its own page, reached from the matrix, with what the setting does, why it matters, its allowed values, and the same editors. It is the right link to paste into a ticket or a runbook.

A habit the matrix encourages: set a value as high up as it holds true, and override lower down only where a tenant or pool really differs. Fewer overrides make an estate easier to reason about, and the Overrides tab shows you exactly how many you are carrying.

Compare every host pool at once

The tenant and host pool selectors sit in the column headers, right above the values they control. The tenant selector lets you browse any tenant you manage without switching the tenant you are working in, which matters when you are on a call about one customer while another is open in the console.

The host pool selector has an All host pools option. Pick it and each row stops showing one pool's value and starts showing agreement across the whole tenant: Same across N pools, or Mixed, N of M pools override, with a per-pool breakdown. The Mixed tab filters the table down to just the rows where pools disagree. That is the list of inconsistencies an auditor would find eventually, available before they do.

From the same view, Apply to host pools sets a value on the pools you select, or resets them to inherit, in one confirmed action. Pools with active sessions pick the change up immediately.

"Why is this value?"

Click any effective value and a panel opens, named for the setting: Why is … this value? It lists every level in the chain, from the built-in default through Global and Tenant to the selected host pool, states what each one holds or that it holds nothing, and marks the level that applies.

This is the question from the first paragraph, answered in one click. A pool behaves unexpectedly, you open the panel, and the trace shows a tenant override from eighteen months ago that nobody remembers setting. The Settings History button in the page header opens the audit log for that tenant, so the next question, who set it and when, is answered on the next screen.

Finding what you need

The matrix lists hundreds of settings, so it is built to be narrowed:

  • Search filters by name.
  • Category narrows to one area, such as Security & Compliance or Software Distribution.
  • The state tabs show All, Overrides, Inherited, Mixed and Not configured, each with its count.
  • Only differences hides every row where all levels agree, so the places that differ stand out.

The page address keeps your tenant, host pool, search, category and the setting you have open, so a link copied from the address bar opens on exactly the same view for a colleague. The rows you are looking at can be exported to CSV or Excel for a change-control record or a customer review.

Some rows can be seen but not changed, and the note on the row says why: the feature belongs to a plan or add-on your subscription does not include, it depends on another setting that is not turned on yet, or it is fixed by your deployment's environment. The matrix shows you the whole picture even where you cannot act on all of it.

Why this is different

Policy inheritance on its own is not new. Plenty of tools let a setting cascade from an organization to a site to a device. What we have not found in another MSP tool is the matrix itself: every setting, every level, the effective value and its source, on one screen, with the disagreements across pools surfaced as a filter and the full trace one click away.

Three design choices make it work:

  1. The matrix uses the same resolver the product runs on. The effective value in the table is computed by the exact code that decides what Atlas does at runtime, on the server, not re-derived in the browser. The page can never disagree with production about what a setting means.
  2. It is a view over the real settings, not a copy. The matrix introduces no new storage and no new precedence rules. Every row describes a setting the product already reads, and every write goes to the same audit trails the native pages use. Nothing you do here is invisible to Settings History or the audit log.
  3. It is built to compare, not just to edit. Side-by-side columns, the Effective label, the all-pools view and the Only differences switch exist because an MSP's real question is rarely "what is this set to?" It is "where is this different, and why?"

For a single tenant with two host pools, a settings page per object is fine. For an MSP managing a dozen customers with fifty pools between them, the question "is anything configured differently than I think it is?" is otherwise unanswerable without a script and a spreadsheet. The Settings Matrix makes it a filter.

See it with your own tenants

The quickest way to feel the difference is to open the matrix on an estate you already run and switch to All host pools:

The best configuration is the one you can explain. With every level and the effective value on one screen, you always can.