Azure Virtual Desktop, from inventory to operations, as code you can read.

Open-source repos that inventory what an AVD environment is, assess what it should be, deploy a hardened landing zone, run it with agents a person approves, and remember what every deployment taught. Bicep and PowerShell, run from Azure Cloud Shell.

Personal project. Research and learning only. Not for production. No warranty.

Built on my own time for research and learning. Not affiliated with, endorsed by or supported by my employer or Microsoft.
Don't run any of it in production or against tenants that matter. Test in a dedicated lab subscription and tenant first.
Provided "as is", without warranty of any kind, under each repo's license. You use it at your own risk and own the Azure charges it incurs.
Contributions and forks are welcome and encouraged. See Contribute.

How the pieces fit

The foundation is three repos, each answering one question: avd-current-state is what it is, avd-assess is what it should be, and avd-landing-zone is how we build it. avd-current-state and avd-landing-zone work as a pair on their own. On top, avd-swarm and the second brain are how we automate it and make it smart and self-improving, and never something the foundation needs. The repos pass versioned, redacted contracts to each other instead of sharing code. Read the convention, or see the architecture for the layers and the contracts between them.

Foundation: what it is

avd-current-state

Read-only PowerShell that answers what is in an AVD environment today, and whether a subscription is ready for a deployment and the deployment landed correctly.

Built

C11 facts

Foundation: what it should be

avd-assess

The assessment method: how to collect, assess, set targets and benchmarks, and score an AVD environment. Methodology only, no tools: a research index that links out to published sources and adds what real runs observed.

Being specified

Foundation: how we build it

avd-landing-zone

An Azure Virtual Desktop landing zone for cloud-native organizations: Entra ID-joined, Intune-managed, private by default, deployed end to end from one Bicep template.

Built

C14 target statelessons

On top: how we automate it

avd-swarm

Agents that manage Azure and Entra ID without the portals. They read freely and change nothing until a person approves the exact plan.

Design and spike

C9 proposalsC10 outcomes

On top: how it gets smart and self-improving

avd-second-brain

One memory across the AVD lifecycle: what each estate looked like, what broke, what the organization learned, and why each rule is what it is.

Built, growing

C6 knowledgeC13 docs findingsC15 fact register

What they share

Read first, change with approvalCollectors and agents read freely. Every change to an estate goes through a plan a person approves, with a kill switch.
Tenant data stays with the tenantPublic repos hold generalized knowledge only. Estate data lives in the owner's private repo, and guards in CI catch leaks.
Every number traces to evidenceRules carry a history and a reason, sizing comes from measured observations, and answers cite a commit.
Azure-native and openBicep, PowerShell and GitHub Actions, all runnable from Azure Cloud Shell.

Contribute

Contributions and forks are welcome and encouraged. Fork a repo and make it your own, or send back what you learn: an issue for a bug, a question or an idea, or a pull request with a fix, a test, a doc or a lesson from a real lab run. Small pull requests are easiest to review.

Before you open one, run the checks the repo's README lists and keep tenant data, IDs and secrets out of the repo, issues and pull requests. A change to a contract between repos comes with the matching pull request in the repo on the other side.

avd-landing-zone avd-current-state avd-assess avd-swarm avd-second-brain