RDS-Templates: ARM templates for Remote Desktop Services on Azure

What the repository holds

The repository contains the latest version of RDS deployment templates and DSC resources.

That is a short description for a large collection, and the directory listing shows how large. The top level is a set of directories, each of which is a self-contained deployment or a supporting artefact:

The classic RDS deployments are `rds-deployment/`, `rds-deployment-existing-ad/`, `rds-deployment-ha-broker/`, `rds-deployment-ha-gateway/` and `rds-deployment-uber/`. Alongside them are the maintenance templates `rds-update-certificate/` and `rds-update-rdsh-collection/`, and the Windows Virtual Desktop material in `ARM-wvd-templates/`, `wvd-templates/` and `wvd-sh/`.

Then there is the operational layer: `DSC/` for the Desired State Configuration resources, `Scripts/` and `CustomImageTemplateScripts/` for scripts, `EnableBackupScript/` for backup enablement, `Custom-Image-Templates/` for image building, `AzureFirewallPolicyForAVD/` for the firewall policy used with AVD, `AVD-TestShortpath/` for testing, `VDOT-ConfigurationFiles/` for the virtual desktop optimisation tool configuration, `msix-app-attach/` for MSIX application attachment, `PortalDeploymentArtifacts/` for the artefacts used when deploying through the portal, and a `test/` directory.

That naming is worth reading as a map of the operational lifecycle of a remote desktop estate. There are templates to create it, templates to update the certificates on it, templates to update the Remote Desktop Session Host collection, templates to build the images it runs on, configuration for the optimisation tool that tunes those images, a firewall policy, and a mechanism for attaching applications to sessions.

The fact that the templates come with DSC resources is the other structural point. ARM templates describe what should exist, and DSC describes what should be true of a machine, so the two cover the declarative and the imperative half of the same problem. Having both in one repository means a deployment can create the topology and then converge the configuration of the machines in it.

The project is MIT licensed, the primary language is recorded as PowerShell, the default branch is master, and the last push was on 2026-10-08. There are no GitHub releases, which is normal for a repository of templates where the content is versioned by the branch and the deployment scripts rather than by a tag.

The deployment topologies

The five `rds-deployment-*` directories are the core of the collection, and the naming tells you what varies between them.

`rds-deployment/` is the base case, a standard deployment. `rds-deployment-existing-ad/` is the variant for an environment that already has Active Directory, which is the common case for an organisation that has an existing identity estate it does not want the deployment to own.

`rds-deployment-ha-broker/` adds high availability to the broker role, and `rds-deployment-ha-gateway/` adds it to the gateway role. In a Remote Desktop Services architecture the broker is the component that tracks session hosts and brokers connections, and the gateway is the one that faces external clients and brokers their connections inward. Both are single points of failure in the base topology, which is why they have their own variants rather than being a flag.

`rds-deployment-uber/` is the largest and most complete one. The name suggests the deployment with everything switched on, and given the other two are the broker and the gateway variants, it is presumably the combination.

The Windows Virtual Desktop directories cover the successor technology. `ARM-wvd-templates/` and `wvd-templates/` hold the templates themselves, and `wvd-sh/` is presumably the session host material, mirroring the naming convention used by the other directories where a separate directory holds one role.

This structure is the reason to prefer templates over the portal. A portal deployment is a set of clicks that produce a set of resources whose relationships you then have to discover. A template deployment produces the same resources with the relationships written down, in a form that can be reviewed, versioned and re-applied. For an estate with several session hosts and a domain-joined setup, that difference is the difference between a deployment you can reproduce and one you can only describe.

And the reviewability point has a specific security benefit here, because the templates contain the configuration of machines that hold credentials and grant remote access. A deployment whose network topology, its firewall rules and its certificate handling can be read in a diff is a deployment someone can audit.

The `AzureFirewallPolicyForAVD/` directory is worth noting in that light. A firewall policy for AVD is a set of rules about what can reach what, and keeping it in the repository next to the templates means the rules travel with the deployment rather than being applied separately and drifting.

Images, optimisation and the pieces around the estate

Several directories deal with the machines rather than the topology, and they are the ones that make the difference between a deployment that works and one that performs.

`Custom-Image-Templates/` and `CustomImageTemplateScripts/` are the image-building side. Deploying session hosts from a golden image rather than from a plain image is what makes a session host usable, since the base image has none of the configuration, the profile redirection and the optimisations that a session host needs. The presence of both a templates directory and a scripts directory suggests the images are described declaratively and then built by scripts.

`VDOT-ConfigurationFiles/` is the virtual desktop optimisation tool configuration, and that is the other half of the same concern. The optimisation tool is what strips unnecessary components from a Windows image and applies the settings that make a session host behave like a session host. It is a well-known source of both good outcomes and subtle breakage, because the same configuration that improves performance can remove something a particular application needs. Keeping the configuration files in version control, next to the image templates, is what makes that reviewable.

`msix-app-attach/` is for attaching MSIX packages to sessions rather than installing them into the image. That matters for the update model: an attached application can be updated for a user without rebuilding the image, which is the difference between a hotfix and a full redeployment of the estate.

`EnableBackupScript/` is the backup enablement, which for a remote desktop estate is about protecting the session host state rather than the virtual machines.

`AVD-TestShortpath/` is a testing directory, and its name suggests it covers the short path that a Windows Virtual Desktop deployment can take, which is the accelerated path that avoids some of the traditional session host networking. Having a test artefact for it in the repository suggests it is something that gets verified rather than assumed.

`PortalDeploymentArtifacts/` is the piece that connects the repository to the other way of deploying. Some of these deployments can be launched from the Azure portal rather than from a template, and this directory holds the artefacts that make that possible, so the same deployment is available to people who are not running ARM.

The `DSC/` directory is the one that underpins the convergence side. A DSC resource describes a state and applies it, and a set of them can bring a session host to the configuration the deployment expects, and can re-converge it when something drifts.

Support, branches and the contribution route

The support section is the first thing in the README and it is unusually direct about what you get.

Microsoft Support is not handling issues for any published tools in this repository. These tools are published as is with no implied support. However, the maintainers would like you to open issues using GitHub issues to collaborate and improve these tools.

So the tools are available with no support commitment, and the community route is the GitHub issue tracker. The instruction is to open an issue and add the corresponding label, with the 5-RDS-on-Windows-Server label given as the example, to associate it with the appropriate tool.

The labels are the routing mechanism. A repository holding a dozen deployment topologies and a set of scripts needs a way to file an issue against the right one of them, and a label per tool is the simplest way to do that without a separate tracker per template.

The branch policy is spelled out in the same detail, and it reflects the fact that these templates are consumed by two different audiences. master is the main branch with the latest stable code, which must be a working version and must pass the CI tests, and direct check-ins are discouraged in favour of personal forks and develop branches merged through pull requests. The release-<yymm> branch is a branch for merges into and from the Azure azure-quickstart-templates repository, and for any pending pull request into that repository the branch is frozen until the PR is merged.

That second branch is the important one for anyone consuming the templates. The azure-quickstart-templates repository is the main catalogue of Azure deployment templates, and the RDS templates are mirrored into it. The freeze is there so that the mirror cannot drift while a pull request is in flight, which is the sort of coordination problem that is easy to overlook until two copies of a template disagree.

The build status badge points at Travis CI, which is the older CI service, and the badge is on the master branch. The badge still points at Travis CI on the master branch.

The contributing guidance is short. The relevant request is to avoid direct check-ins into master, to work in a fork and a develop branch, and to merge via a pull request, which is the standard flow but stated clearly enough that a first-time contributor knows the shape of it.

Where the documentation actually is

The README is not where you will learn how to deploy one of these, and the Quick links section makes that clear.

There is `aka.ms/rdautomation`, which resolves to the Azure template gallery filtered on RDS, so the fastest way to see what exists is the gallery itself rather than the repository. There is the Azure azure-quickstart-templates repository, the main catalogue that these templates are mirrored into. And there is the RDS-Templates repository itself.

The Blogs section then lists the written material, and it is where the actual deployment guidance lives. There is a TechNet piece on deploying a basic desktop hosting environment using Azure IaaS, an Azure Resource Manager and JSON templates blog series by Freek Berson, an RDS Team blog post on the ARM template for RDS deployment, a Tip of the Day entry from Josh Bender, and a piece by Toby Phipps on creating a mostly seamless logon experience for a Remote Desktop Services environment.

Two of those are worth singling out for what they cover. The TechNet guide on a basic desktop hosting environment is the getting-started material, and the Phipps piece on logon experience addresses the thing that decides whether a remote desktop environment feels usable to the people in it, which is not a template concern but a design concern.

The reading order these blogs suggest is worth stating. The 2015 pieces from Freek Berson and the RDS team are the announcement material and they date the templates' origin. The TechNet guide on the desktop hosting environment is the one to follow for a first deployment. The Tip of the Day entry is the short form. And the logon experience piece is the one to read before you tell anyone the estate is ready.

That last point is the honest caveat about the whole collection. The templates cover the deployment, and the deployment is the part that can be automated. Whether the result is a good working environment for the people who will use it depends on decisions about profile redirection, single sign-on and client experience, and those decisions are made in the articles and not in the templates.

The repository therefore works best as a starting point rather than as a finished answer, which is also why the two collections of writing, the gallery and the blogs, are linked side by side in the Quick links section.

Editorial conclusion

Adopt RDS-Templates if you are deploying Remote Desktop Services on Azure and want the deployment expressed as ARM templates rather than through the portal, since the repository covers the standard topologies. Do not expect the artefacts to be supported, because the README states that Microsoft Support is not handling issues for the published tools and that they are published as is with no implied support, and check first which topology you need, since the deployment directories are separate and each covers a different shape of the estate.

Frequently asked questions

Official sources

1. Azure/RDS-Templates on GitHub
2. Issues
3. License: MIT
4. README