During Workplace Ninja US, I did an in-person session on this topic, and now I am releasing for all. I’ve built Azure Virtual Desktop environments in a few different ways over the years — quick POCs, “just one host pool” builds, and full-blown enterprise deployments. The problem is the same every time: it starts simple and then you end up stitching together monitoring, scaling plans, RBAC, dashboards, and cost alerts… usually across multiple Terraform folders.
So I pulled everything into one modular Terraform repo that can deploy four AVD patterns (pooled/personal + desktop/RemoteApp), with optional enterprise-grade monitoring, dashboards, cost management, and scaling.
It also follows Microsoft Cloud Adoption Framework (CAF) naming patterns for the main AVD + network resources (host pool, app group, workspace, vnet/subnet/nsg, etc.).
Why this repo is “enterprise ready”
A few highlights that make this more than a basic host pool deployment:
Scaling plans for pooled deployments (desktop + RemoteApp) and environment-specific schedules
Monitoring & observability using Log Analytics + diagnostics
Custom dashboards for operational visibility
Cost management with budgets + alerts
CAF-friendly naming so your portal stays clean and consistent
Supported deployment types (quick view)
The configuration automatically adjusts host pool/app group settings depending on deployment_type (pooled vs personal, desktop vs RemoteApp).
The deployment guide uses a Service Principal stored in a local .env file (ignored by git), and a set-auth.ps1 script that loads the values into ARM_* environment variables for Terraform.
High level flow: .env → set-auth.ps1 → ARM_* env vars → Terraform
Create your .env from .env.example, then run:
.\set-auth.ps1
Scaling plans note: your Service Principal needs the Desktop Virtualization Power On Off Contributor role at subscription scope for scaling to work properly.
Terraform init / plan / apply
terraform init terraform plan -var-file=dev-pooled-desktop.tfvars terraform apply -var-file=dev-pooled-desktop.tfvars
Monitoring, dashboards, cost alerts (optional but worth it)
If you use one of the monitoring/scaling-enabled tfvars options, the repo can deploy:
Log Analytics + diagnostics
Dashboards for ops visibility
Budgets/alerts for cost tracking
A quick note on dependency ordering (why it matters)
The repo is intentional about resource ordering — especially for scaling plans — to avoid portal oddities and ensure the host pool association is reliable. The dependency flow is documented and includes a separate scaling plan host pool association resource.
Resoure Group (RG)
Application Groups (AG)
Wrap up
If you want a repeatable way to deploy AVD that supports pooled + personal and desktop + RemoteApp, while also giving you the option to turn on monitoring, dashboards, budgets/alerts, and scaling, this repo is designed for exactly that.
If you’ve been running Azure Virtual Desktop for a while, you already know the pain: keeping session hosts consistent is easy until you start chasing app versions, Windows Updates, Teams changes, and the “one missing dependency” that breaks someone’s day.
Microsoft calls this a golden image approach: bake your base OS + apps + config once, then roll it out to session hosts consistently. (Microsoft Learn)
In this post, I’m sharing a Terraform-based approach that builds a custom AVD image using Azure VM Image Builder (AIB) and publishes it to Azure Compute Gallery (ACG) so you can consume it in your AVD host pool automation. (Microsoft Learn)
Terraform provisions the Image Builder “plumbing” (identity, storage, template, etc.)
Azure VM Image Builder spins up a temporary build VM
The build VM runs updates + optimizations + app installs (your choice)
The final image gets published into Azure Compute Gallery
You use that gallery image version when creating/re-imaging AVD session hosts (GitHub)
This repo uses a Windows 11 multi-session AVD + Microsoft 365 marketplace image as the starting point (so M365 and Teams are already there), then layers your customizations on top. (GitHub)
Why I like this approach
A few things in this repo are intentionally “enterprise friendly”:
No public script URLs / no long-lived SAS tokens: scripts are stored in a private blob container and downloaded using the Image Builder user-assigned managed identity. (GitHub)
SHA256 integrity checks: if someone tampers with your script artifacts, the build fails. (GitHub)
Deterministic image versioning: default version format is YYYY.MM.DD, with an option to override. (GitHub)
Optional optimization steps like Virtual Desktop Optimization Tool (VDOT) and FSLogix config (handy in AVD land). (GitHub)
Architecture
Pre-requisites
Azure subscription + permissions to create IAM assignments, storage, and image resources.
Terraform installed (repo expects Terraform + AzureRM provider versions aligned with the README). (GitHub)
Azure VM Image Builder basics: it supports starting from Marketplace/custom images and publishing to Azure Compute Gallery. (Microsoft Learn)
Start from the example and edit what you need (region, naming, feature toggles, etc.). (GitHub)
3. Authenticate
Use your preferred method (interactive az login locally, or service principal in CI/CD). The repo also calls out using .env locally and keeping secrets out of Git. (GitHub). The PowerShell script set-auth.ps1 calls these environment variables.
4. Terraform init / plan / apply
terraform init -upgrade
terraform plan -out image.tfplan
terraform apply image.tfplan
Important note: Terraform provisions the Image Builder template, but doesn’t wait for the build to finish. (GitHub)
5. Trigger + monitor the image build
You can monitor runs in the portal, or with Azure CLI:
az image builder show-runs shows run outputs for the template. (Microsoft Learn)
6. Validate the image in Azure Compute Gallery
Once the build completes, you’ll see a new image version in Azure Compute Gallery. ACG is designed to manage/share images and versions cleanly across environments. (Microsoft Learn)
Customizing applications (the fun part)
This repo supports multiple install strategies with fallback (so you’re not stuck when winget is blocked in some environments):
Build time: expect ~45–75 minutes depending on Windows Updates and app installs. (GitHub)
Template updates: Image Builder doesn’t really do “in-place template updates” the way you’d hope—plan on the “replace template” pattern when you change major parts. (Microsoft Learn)
Networking: if you go private networking / locked-down egress, make sure your update/app endpoints are reachable (or use offline packages). (GitHub)
AVD consumption: this pipeline publishes the image version—your AVD session host deployment should point to that exact gallery version. (GitHub)
Where this fits in your AVD build
If you already deploy host pools/workspaces/scaling plans via Terraform, think of this repo as the image factory that feeds your host pool automation. (Build image → publish to gallery → deploy session hosts from that version.) (GitHub)
Wrap up
That’s it — repeatable AVD image builds, versioned in Azure Compute Gallery, with a setup that avoids public script endpoints and keeps things predictable. (GitHub)
I hope you find this helpful information for building and maintaining an AVD golden image using Terraform + Azure VM Image Builder. If I have missed any steps or details, I will be happy to update the post.
This is part one of a two-part series on Windows 365 Cloud Apps. In this post, we’ll walk through what Cloud Apps are and how to create the provisioning policy with PowerShell. In part two, we’ll publish the apps themselves. I’ll also include the PowerShell script that uses Azure/Graph REST APIs.
What is Windows 365 Cloud Apps?
Windows 365 Cloud Apps let you give users access to specific apps streamed from a Cloud PC—without handing out a full desktop to everyone. Under the hood, Cloud Apps run on Windows 365 Frontline Cloud PCs in Shared mode. That licensing model is designed for shift or part-time staff: many users can be assigned, but only one active session per license at a time.
Think of it as “just-the-apps” VDI: Outlook, Word, your line-of-business app—delivered from the cloud—with the management simplicity of Windows 365 and Intune.
Why customers care: You streamline app delivery, lower overhead, and modernize VDI without building and babysitting a big remote desktop estate.
Cloud Apps vs AVD Published Apps vs “Traditional” VDI Published Apps
Topic
Windows 365 Cloud Apps
Azure Virtual Desktop Published Apps
Traditional VDI Published Apps
What users see
Individual apps streamed from a Cloud PC; no full desktop
Individual apps from session hosts in Azure Virtual Desktop
Individual apps from on-prem or hosted RDS/Horizon/Citrix farms
Infra you manage
Cloud PC lifecycle via Intune; Microsoft operates the fabric
You design & operate host pools, scaling, FSLogix, images
You run the farm: brokers, gateways, hypervisors, storage
Licensing / sessions
Frontline: many users per license, 1 active session per license
Per-user/per-device or CALs + Azure consumption; multiple sessions per host
Per-user/device + on-prem infra costs
Admin plane
Intune + Windows 365
Azure Portal + ARM + Host pool automation
Vendor consoles + on-prem change management
App packaging
Start-menu discovered apps from the image (MSIX/Appx discovery expanding)
Image: Set $ImageType (e.g., "gallery") and $ImageId for your chosen image.
Region: $RegionName (e.g., australiaeast or "automatic").
Assignment:
$GroupId: Entra group whose members should see the Cloud Apps.
$ServicePlanId: the Frontline size (e.g., FL 2vCPU/8GB/128GB in the example).
$AllotmentCount: how many concurrent sessions you want available for this policy.
$AllotmentDisplayName: a friendly label that shows up with the assignment.
Verification/Polling: The script dumps the policy with assignments and can optionally poll for provisioned Cloud PCs tied to the policy.
Get-or-Create a Cloud Apps provisioning policy (userExperienceType = cloudApp, provisioningType = sharedByEntraGroup, Azure AD Join in a specified region).
Assigns the policy to an Entra group with service plan, capacity (allotment), and a friendly label
App discovery: Ensure the app has a Start menu shortcut on the image. That’s how Cloud Apps gets its list.
Security baselines: If your tenant enforces restrictions on PowerShell in the image at discovery time, discovery can fail.
MSIX/Appx: Discovery is expanding—classic installers show up first; some Appx/MSIX apps (e.g., newer Teams) may not appear yet.
Concurrency math: Active sessions for the policy are capped by assigned Frontline license count on that policy.
Schema drift: These are beta endpoints. If you hit a property/enum change, the script’s warnings will surface the response body—update the field names accordingly.
What’s next (Part 2)
We’ll move to All Cloud Apps to publish the discovered apps, tweak display name/description/command line/icon index, confirm they appear in Windows App, and cover unpublish/reset workflows—with your screenshots.
I hope you find this helpful information for creating a Cloud App using PowerShell. If I have missed any steps or details, I will be happy to update the post.
Today I’m diving into a feature that’s currently in preview but promises to be super useful for Windows 365 Cloud PC admins: Cloud PC Maintenance Windows.
If you’ve ever needed to resize multiple Cloud PCs but worried about disrupting users during work hours, this new feature is about to make your life much easier. Let’s break it down!
What Are Cloud PC Maintenance Windows?
Simply put, maintenance windows allow you to schedule when certain actions (currently just resize operations) will take place on your Cloud PCs. Instead of changes occurring immediately after you initiate them, you can schedule them to run during specified time periods.
Think of it as telling your Cloud PCs, “Hey, only accept these maintenance actions during these specific hours.” It’s perfect for organizations that need to plan around busy periods and minimize disruption.
Why You Should Care About This Feature
There are several compelling reasons to start using maintenance windows:
After-hours maintenance: Schedule resize operations to happen overnight or on weekends
Predictable changes: Users receive notifications before maintenance begins
Bulk operations: Apply resize actions to entire departments or teams at once
Organizational compliance: Meet any requirements about when system changes can occur
Setting Up Your First Maintenance Window
The setup process is straightforward and consists of two main parts: creating the window itself and then applying it to a device action.
Part 1: Creating a Maintenance Window
Sign into the Microsoft Intune admin center
Navigate to Tenant administration > Cloud PC maintenance windows (preview)
Click Create
On the Basics page:
Enter a descriptive Name (e.g., “Weekend Resize Window”)
Add a Description to help other admins understand the purpose
On the Configuration page:
Set your Weekday schedule (if applicable)
Set your Weekend schedule (if applicable)
Remember: Each window must be at least two hours long
Select when users will receive notifications (15 minutes to 24 hours in advance)
On the Assignments page:
Add the groups whose Cloud PCs will use this maintenance window
Review your settings and click Create
Part 2: Using Your Maintenance Window
Once your window is created, it won’t do anything by itself until you create a bulk device action that uses it:
In the Intune admin center, go to Devices > Windows Devices > Bulk device actions
For the configuration:
OS: Windows
Device type: Cloud PCs
Device action: Resize
Select your source and target sizes
Important: Check the box for Use Cloud PC maintenance windows
Add the devices/groups and create the action
When the maintenance window becomes active, the resize operation will run, and users will receive notifications based on the lead time you specified.
Powershell way to implement Cloud PC maintence
Step 1 – Install the MS Graph Beta Powershell Module
#Install Microsoft Graph Beta Module
PS C:WINDOWSsystem32> Install-Module Microsoft.Graph.Beta
Step 2 – Connect to scopes and specify which API you wish to authenticate to. If you are only doing read-only operations, I suggest you connect to “CloudPC.Read.All” in our case, we are creating the policy, so we need to change the scope to “CloudPC.ReadWrite.All”
#Read-only
PS C:WINDOWSsystem32> Connect-MgGraph -Scopes "CloudPC.Read.All" -NoWelcome
Welcome To Microsoft Graph!
OR
#Read-Write
PS C:WINDOWSsystem32> Connect-MgGraph -Scopes "CloudPC.ReadWrite.All" -NoWelcome
Welcome To Microsoft Graph!
Permissions for MS Graph API
Step 3 – Check the User account by running the following beta command.
displayname – Name of the policy “CloudPC-Window-askaresh”
Description – Enter details to remember for the future
notification – 60 min (tweak based on your company policies)
Schedule – Weekday (Ensure don’t enter business hours)
# Ensure the Microsoft.Graph.Beta module is installed
if (-not (Get-Module -ListAvailable -Name Microsoft.Graph.Beta)) {
Write-Host "Installing Microsoft.Graph.Beta module..." -ForegroundColor Cyan
Install-Module Microsoft.Graph.Beta -Force -AllowClobber
}
Import-Module Microsoft.Graph.Beta
# Connect to Microsoft Graph with the required permissions for maintenance operations
Write-Host "Connecting to Microsoft Graph..." -ForegroundColor Cyan
Connect-MgGraph -Scopes "CloudPC.ReadWrite.All" -NoWelcome
# Define the endpoint for Cloud PC maintenance windows
$uri = "beta/deviceManagement/virtualEndpoint/maintenanceWindows"
# Construct the JSON payload for the maintenance window
$maintenancePayload = @{
displayName = "CloudPC-Window-askaresh"
description = "A window for test"
notificationLeadTimeInMinutes = 60
schedules = @(
@{
scheduleType = "weekday"
startTime = "01:00:00.0000000"
endTime = "04:00:00.0000000"
},
@{
scheduleType = "weekend"
startTime = "01:00:00.0000000"
endTime = "04:00:00.0000000"
}
)
} | ConvertTo-Json -Depth 5
# Call the Microsoft Graph API to create the maintenance window
try {
Write-Host "Creating Cloud PC maintenance window..." -ForegroundColor Cyan
$result = Invoke-MgGraphRequest -Method POST -Uri $uri -Body $maintenancePayload
Write-Host "Maintenance window created successfully." -ForegroundColor Green
$result | Format-List
}
catch {
Write-Error "Error creating maintenance window: $_"
}
# Optionally disconnect from Microsoft Graph when done
Disconnect-MgGraph
The User Experience
From the user perspective, they’ll receive a notification in their Cloud PC session when a maintenance window is approaching. The notification will indicate that maintenance is scheduled and when it will occur. They can’t override or postpone the maintenance, but at least they’ll be prepared.
Current Limitations
It’s worth noting that this feature is still in preview, and has some limitations:
Currently only supports resize operations (likely to expand in the future)
The maintenance window itself doesn’t guarantee the success of operations
Doesn’t handle Windows updates, Intune payloads, or OS updates
Each window must be at least two hours long
When NOT to Use Maintenance Windows
If you have an urgent situation requiring immediate resizing of Cloud PCs, simply don’t check the “Use Cloud PC maintenance windows” box when creating your bulk action. This way, the resize will happen immediately rather than waiting for the next scheduled window.
Conclusion
Having played with this feature for a bit, I’m impressed with how it streamlines the management of Cloud PCs. Before this, scheduling maintenance was much more manual and potentially disruptive. While I wish it supported more actions beyond just resizing, this is a solid foundation that I expect Microsoft will build upon.
This feature is particularly valuable for organizations with users across different time zones or with strict requirements about when system changes can occur. It’s also a huge time-saver for admins who manage large fleets of Cloud PCs. I hope you find this helpful information for creating a Cloud PC maintenance window using PowerShell. If I have missed any steps or details, I will be happy to update the post.
Example – With Windows 365 Frontline Shared licensing, you don’t assign a license to each individual user. Instead, you provision a pool of shared virtual desktops and grant access to a designated group of users. Each shared license represents a virtual desktop that can be dynamically used by any authorized user when available. For example, rather than needing a strict 1:1 (or even 1:3) mapping between users and desktops, you can support many more employees than the number of desktops you provision—much like a traditional non-persistent VDI setup. Once a user logs off, their desktop resets and becomes available for another user, allowing you to meet peak concurrency needs without assigning a dedicated device to every single employee.
Connect to MS Graph API
Step 1 – Install the MS Graph Beta Powershell Module
#Install Microsoft Graph Beta Module
PS C:WINDOWSsystem32> Install-Module Microsoft.Graph.Beta
Step 2 – Connect to scopes and specify which API you wish to authenticate to. If you are only doing read-only operations, I suggest you connect to “CloudPC.Read.All” in our case, we are creating the policy, so we need to change the scope to “CloudPC.ReadWrite.All”
#Read-only
PS C:WINDOWSsystem32> Connect-MgGraph -Scopes "CloudPC.Read.All" -NoWelcome
Welcome To Microsoft Graph!
OR
#Read-Write
PS C:WINDOWSsystem32> Connect-MgGraph -Scopes "CloudPC.ReadWrite.All" -NoWelcome
Welcome To Microsoft Graph!
Permissions for MS Graph API
Step 3 – Check the User account by running the following beta command.
If you are doing on-premise network integration (Azure Network Connection) , then the following additional property and value is required. In my lab, I am leveraging the Microsoft Managed Network, so this is not required.
Additionally, if you have enrolled into autopatch the following is the parameter. You will have to put the name from the Intune Portal.
"autopatch": null,
I hope you will find this helpful information for creating a shared frontline worker provisioning policy using PowerShell. Please let me know if I have missed any steps or details, and I will be happy to update the post.
In the latest update of Windows Intune, a new method has been introduced to disable Windows Copilot through the settings catalog policy. Previously, the technique revolved around CSP and registry, but now users can conveniently manage this setting directly within the settings catalog. There are plenty of blog posts showing how to do it via CSP and registry, and we are not going into that here.
What is Windows Copilot?
For those unfamiliar, Windows Copilot (formerly Bing Chat) is a built-in AI-powered intelligent assistant that helps you get answers and inspirations from across the web, supports creativity and collaboration, and enables you to focus on the task at hand.
How to Disable Windows Copilot via Settings Catalog Policy
The process to disable Windows Copilot through the settings catalog policy is simple and straightforward. Here’s a step-by-step guide:
# Define parameters for the new device management configuration policy $params = @{ name = "DisableCopilot" description = "Disable AI copilot" platforms = "windows10" technologies = "mdm" roleScopeTagIds = @( "0" ) settings = @( @{ "@odata.type" = "#microsoft.graph.deviceManagementConfigurationSetting" settingInstance = @{ "@odata.type" = "#microsoft.graph.deviceManagementConfigurationChoiceSettingInstance" settingDefinitionId = "user_vendor_msft_policy_config_windowsai_turnoffwindowscopilot" choiceSettingValue = @{ "@odata.type" = "#microsoft.graph.deviceManagementConfigurationChoiceSettingValue" value = "user_vendor_msft_policy_config_windowsai_turnoffwindowscopilot_1" children = @() } } } ) }
# Create a new device management configuration policy with the specified parameters New-MgBetaDeviceManagementConfigurationPolicy -BodyParameter $params
Check out my other blog post that outlines how to use MS Graph and Powershell to execute the above code.
I hope you’ll find this insightful for easily disabling the Copilot within the Windows 11 physical and Windows 365 Cloud PC fleet of device. Please let me know if I’ve missed any steps or details, and I’ll be happy to update the post.
In the Dec 4th, 2023 for Windows 365 Enterprise, the reports for Cloud PC actions were announced. In today’s post, I will showcase how to access and make sense of the new report available within Microsoft Intune.
What does the report offer?
The Cloud PC Actions Report, currently in public preview, is a powerful report within the Windows 365 ecosystem. It provides detailed information on various actions taken by administrators on the Cloud PCs. Imagine you have multiple teams and admins within your organisation. This report can help you track the actions along with the Status and Date initiated, which can come in handy for troubleshooting and audit purposes.
Accessing the report – Cloud PC Actions
To view the report in Microsoft Intune portal, you can follow these steps:
Go to Devices > Monitor > Others > Cloud PC Actions (preview).
What Actions are displayed?
The following actions are included in the report:
Action
Description
Create Snapshot
This action allows administrators to capture the current state of a Cloud PC. It’s useful for backup purposes or before making significant changes, ensuring that there’s a point to revert back to if needed.
Move Region
This feature enables the relocation of a Cloud PC to a different geographic region. It’s particularly beneficial for organizations with a global presence, ensuring that Cloud PCs are hosted closer to where the users are located, potentially improving performance and compliance with regional data laws.
Place Under Review
This action is used to flag a Cloud PC for further examination. It could be due to performance issues, security concerns, or compliance checks. Placing a PC under review may restrict certain functionalities until the review is completed.
Power On/Off (W365 Frontline only)
Specific to Windows 365 Frontline, this action allows administrators to remotely power on or off a Cloud PC. This is crucial for managing devices in a frontline environment, where PCs might need to be controlled outside of regular working hours.
Reprovision
Reprovisioning a Cloud PC involves resetting it to its initial state. This action is useful when a PC needs to be reassigned to a different user or if it’s experiencing significant issues that can’t be resolved through regular troubleshooting.
Resize
This action refers to changing the size/specifications of a Cloud PC, such as adjusting its CPU, RAM, or storage. It’s essential for adapting to changing workload requirements or optimizing resource allocation.
Restart
Administrators can remotely restart a Cloud PC. This is a basic but critical action for applying updates, implementing configuration changes, or resolving minor issues.
Restore
This action allows the restoration of a Cloud PC to a previous state using a saved snapshot. It’s a vital feature for recovery scenarios, such as after a failed update or when dealing with software issues.
Troubleshoot
This is a general action that encompasses various diagnostic and repair tasks to resolve issues with a Cloud PC. It might include running automated diagnostics, checking logs, or applying fixes.
How This Report Benefits You
Enhanced Troubleshooting: Quickly identify failed actions and understand potential reasons for failure.
Efficient Management: Monitor ongoing actions and ensure smooth operation of Cloud PCs.
Actionable Insights: Make informed decisions based on the status and details of actions taken.
If you have a failed action you can select and click on retry and it will try to perform the action on your behalf.
Bonus – PowerShell Access to Cloud PC Actions Report
To get the csv download of the report via MS Graph follow these steps:
Connect to MS Graph API
Step 1 – Install the MS Graph Powershell Module
#Install Microsoft Graph Beta Module
PS C:WINDOWSsystem32> Install-Module Microsoft.Graph.Beta
Step 2 – Connect to scopes and specify which API you wish to authenticate to. If you are only doing read-only operations, I suggest you connect to “CloudPC.Read.All” in our case, we are creating the policy, so we need to change the scope to “CloudPC.ReadWrite.All”
#Read-only
PS C:WINDOWSsystem32> Connect-MgGraph -Scopes "CloudPC.Read.All" -NoWelcome
Welcome To Microsoft Graph!
OR
#Read-Write
PS C:WINDOWSsystem32> Connect-MgGraph -Scopes "CloudPC.ReadWrite.All" -NoWelcome
Welcome To Microsoft Graph!
Step 3 – Check the User account by running the following beta command.
The Cloud PC Actions Report is a significant addition to Windows 365, offering a level of transparency and control that administrators have long sought. I hope you will find this helpful information for tracking the Cloud PC actions via this report. Please let me know if I have missed any steps or details, and I will be happy to update the post.
In today’s digital age, managing cloud resources efficiently is paramount, not just for operational efficacy but also for cost management. Enter Azure Virtual Desktop (AVD) Scaling Plans – Microsoft’s answer to dynamic and intelligent scaling of your virtual desktop infrastructure. No longer do organizations need to overprovision resources or let them sit idle; with AVD Scaling Plans, you get a responsive environment tailored to your usage patterns. In this blog post, we’ll create the scaling plans using Terraform.
In the previous blog post, we delved into the distinctions between the Personal Desktop (1:1 mapping), Pooled Desktop (1:Many mapping) and Remote App configurations, providing a comprehensive guide on their creation via Terraform. The series continues as we further explore how to create the AVD Scaling Plan for Pooled Host Pool.
Permissions within the Azure Subscription for using Terraform
Terraform – Authenticating via Service Principal & Client Secret
Before running any Terraform code, we will execute the following PowerShell (Run as administrator)and store the credentials as environment variables. If we do this via the environment variable, we don’t have to keep the below information within the providers.tf file. In a future blog post, there are better ways to store the below details, and I hope to showcase them:
Azure Subcription ID – Azure Portal Subcription copy the ID
Client ID – From the above step you will have the details
Client Secret – From the above step you will have the details
Tenant ID – While creating the Enterprise Apps in ADD you will have the details
Terraform Folder Structure
The following is the folder structure for the terrraform code:
Azure Virtual Desktop Scaling Plan – Create a directory in which the below Terraform code will be published (providers.tf, main.tf, variables.tf and output.tf)
Create a file named main.tf and insert the following code. Let me explain what all we are attempting to accomplish here:
Leverage a existing Resource Group
Leverage a existing Host Pool
Create a custom role AVD AutoScale and assign to the Resource Group
This is a prerequisite for ensuring the scaling plan can increase and decrease the resources in your resource group.
Assign the role – AVD AutoScale to the service principal (AVD)
Create a a scaling plan with a production grade schedule
Associate the scaling plan with the host pool
# Generate a random UUID for role assignment
resource "random_uuid" "example" {}
# Fetch details of the existing Azure Resource Group
data "azurerm_resource_group" "example" {
name = var.resource_group_name
}
# Fetch details of the existing Azure Virtual Desktop Host Pool
data "azurerm_virtual_desktop_host_pool" "existing" {
name = var.existing_host_pool_name
resource_group_name = var.resource_group_name
}
# Define the Azure Role Definition for AVD AutoScale
resource "azurerm_role_definition" "example" {
name = "AVD-AutoScale"
scope = data.azurerm_resource_group.example.id
description = "AVD AutoScale Role"
# Define the permissions for this role
permissions {
actions = [
# List of required permissions.
"Microsoft.Insights/eventtypes/values/read",
"Microsoft.Compute/virtualMachines/deallocate/action",
"Microsoft.Compute/virtualMachines/restart/action",
"Microsoft.Compute/virtualMachines/powerOff/action",
"Microsoft.Compute/virtualMachines/start/action",
"Microsoft.Compute/virtualMachines/read",
"Microsoft.DesktopVirtualization/hostpools/read",
"Microsoft.DesktopVirtualization/hostpools/write",
"Microsoft.DesktopVirtualization/hostpools/sessionhosts/read",
"Microsoft.DesktopVirtualization/hostpools/sessionhosts/write",
"Microsoft.DesktopVirtualization/hostpools/sessionhosts/usersessions/delete",
"Microsoft.DesktopVirtualization/hostpools/sessionhosts/usersessions/read",
"Microsoft.DesktopVirtualization/hostpools/sessionhosts/usersessions/sendMessage/action",
"Microsoft.DesktopVirtualization/hostpools/sessionhosts/usersessions/read"
]
not_actions = []
}
assignable_scopes = [
data.azurerm_resource_group.example.id,
]
}
# Fetch the Azure AD Service Principal for Windows Virtual Desktop
data "azuread_service_principal" "example" {
display_name = "Azure Virtual Desktop"
}
# Assign the role to the service principal
resource "azurerm_role_assignment" "example" {
name = random_uuid.example.result
scope = data.azurerm_resource_group.example.id
role_definition_id = azurerm_role_definition.example.role_definition_resource_id
principal_id = data.azuread_service_principal.example.id
skip_service_principal_aad_check = true
}
# Define the Azure Virtual Desktop Scaling Plan
resource "azurerm_virtual_desktop_scaling_plan" "example" {
name = var.scaling_plan_name
location = var.location
resource_group_name = var.resource_group_name
friendly_name = var.friendly_name
description = var.scaling_plan_description
time_zone = var.timezone
tags = var.tags
dynamic "schedule" {
for_each = var.schedules
content {
name = schedule.value.name
days_of_week = schedule.value.days_of_week
ramp_up_start_time = schedule.value.ramp_up_start_time
ramp_up_load_balancing_algorithm = schedule.value.ramp_up_load_balancing_algorithm
ramp_up_minimum_hosts_percent = schedule.value.ramp_up_minimum_hosts_percent
ramp_up_capacity_threshold_percent= schedule.value.ramp_up_capacity_threshold_pct
peak_start_time = schedule.value.peak_start_time
peak_load_balancing_algorithm = schedule.value.peak_load_balancing_algorithm
ramp_down_start_time = schedule.value.ramp_down_start_time
ramp_down_load_balancing_algorithm= schedule.value.ramp_down_load_balancing_algorithm
ramp_down_minimum_hosts_percent = schedule.value.ramp_down_minimum_hosts_percent
ramp_down_force_logoff_users = schedule.value.ramp_down_force_logoff_users
ramp_down_wait_time_minutes = schedule.value.ramp_down_wait_time_minutes
ramp_down_notification_message = schedule.value.ramp_down_notification_message
ramp_down_capacity_threshold_percent = schedule.value.ramp_down_capacity_threshold_pct
ramp_down_stop_hosts_when = schedule.value.ramp_down_stop_hosts_when
off_peak_start_time = schedule.value.off_peak_start_time
off_peak_load_balancing_algorithm = schedule.value.off_peak_load_balancing_algorithm
}
}
# Associate the scaling plan with the host pool
host_pool {
hostpool_id = data.azurerm_virtual_desktop_host_pool.existing.id
scaling_plan_enabled = true
}
}
Configure AVD – ScalingPlans – variables.tf
Create a file named variables.tf and insert the following code. The place where we define existing or new variables:
# Define the resource group of the Azure Virtual Desktop Scaling Plan
variable "resource_group_name" {
description = "The name of the resource group."
type = string
default = "AE-DEV-AVD-01-PO-D-RG"
}
# Define the attributes of the Azure Virtual Desktop Scaling Plan
variable "scaling_plan_name" {
description = "The name of the Scaling plan to be created."
type = string
default = "AVD-RA-HP-01-SP-01"
}
# Define the description of the scaling plan
variable "scaling_plan_description" {
description = "The description of the Scaling plan to be created."
type = string
default = "AVD Host Pool Scaling plan"
}
# Define the timezone of the Azure Virtual Desktop Scaling Plan
variable "timezone" {
description = "Scaling plan autoscaling triggers and Start/Stop actions will execute in the time zone selected."
type = string
default = "AUS Eastern Standard Time"
}
# Define the freindlyname of the Azure Virtual Desktop Scaling Plan
variable "friendly_name" {
description = "The friendly name of the Scaling plan to be created."
type = string
default = "AVD-RA-HP-SP-01"
}
# Define the host pool type(Pooled or Dedicated) of the Azure Virtual Desktop Scaling Plan
variable "host_pool_type" {
description = "The host pool type of the Scaling plan to be created."
type = string
default = "Pooled"
}
# Define the details of the scaling plan schedule
variable "schedules" {
description = "The schedules of the Scaling plan to be created."
type = list(object({
name = string
days_of_week = list(string)
ramp_up_start_time = string
ramp_up_load_balancing_algorithm = string
ramp_up_minimum_hosts_percent = number
ramp_up_capacity_threshold_pct = number
peak_start_time = string
peak_load_balancing_algorithm = string
ramp_down_start_time = string
ramp_down_load_balancing_algorithm = string
ramp_down_minimum_hosts_percent = number
ramp_down_capacity_threshold_pct = number
ramp_down_wait_time_minutes = number
ramp_down_stop_hosts_when = string
ramp_down_notification_message = string
off_peak_start_time = string
off_peak_load_balancing_algorithm = string
ramp_down_force_logoff_users = bool
}))
default = [
{
name = "weekdays_schedule"
days_of_week = ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"]
ramp_up_start_time = "08:00"
ramp_up_load_balancing_algorithm = "BreadthFirst"
ramp_up_minimum_hosts_percent = 20
ramp_up_capacity_threshold_pct = 60
peak_start_time = "09:00"
peak_load_balancing_algorithm = "DepthFirst"
ramp_down_start_time = "18:00"
ramp_down_load_balancing_algorithm = "DepthFirst"
ramp_down_minimum_hosts_percent = 10
ramp_down_capacity_threshold_pct = 90
ramp_down_wait_time_minutes = 30
ramp_down_stop_hosts_when = "ZeroActiveSessions"
ramp_down_notification_message = "You will be logged off in 30 min. Make sure to save your work."
off_peak_start_time = "20:00"
off_peak_load_balancing_algorithm = "DepthFirst"
ramp_down_force_logoff_users = false
}
]
}
# Define the location of the Azure Virtual Desktop Scaling Plan
variable "location" {
description = "The location where the resources will be deployed."
type = string
default = "australiaeast"
}
# Define the tags of the Azure Virtual Desktop Scaling Plan
variable "tags" {
description = "The tags to be assigned to the Scaling plan."
type = map(string)
default = {
"Billing" = "IT"
"Department" = "IT"
"Location" = "AUS-East"
}
}
# Define the name of the Azure Virtual Desktop Host Pool
variable "existing_host_pool_name" {
description = "The name of the existing Azure Virtual Desktop Host Pool."
type = string
default = "AE-DEV-AVD-01-PO-D-HP"
}
Configure AVD – ScalingPlans – output.tf
Create a file named output.tf and insert the following code. This will showcase in the console what is getting deployed in form of a output.
# Output the ID of the Azure Virtual Desktop Scaling Plan
output "scaling_plan_id" {
description = "The ID of the Virtual Desktop Scaling Plan."
value = azurerm_virtual_desktop_scaling_plan.example.id
}
Intialize Terraform – AVD – ScalingPlans
Run terraform init to initialize the Terraform deployment. This command downloads the Azure provider required to manage your Azure resources. (Its pulling the AzureRM and AzureAD)
terraform init -upgrade
Create Terraform Execution Plan – AVD – ScalingPlans
Run terraform plan to create an execution plan.
terraform plan -out scaleplan.tfplan
Apply Terraform Execution Plan – AVD – ScalingPlans
Run terraform apply to apply the execution plan to your cloud infrastructure.
terraform apply "scaleplan.tfplan"
Validate the Output in Azure Portal
Go to the Azure portal, Select Azure Virtual Desktop and Select Scaling Plans and validate all the details such as Host Pool Assignment and Schedule:
Clean-up the above resources (Optional)
If you want to delete all the above resources then you can use the following commands to destroy. Run terraform plan and specify the destroy flag.
terraform plan -destroy -out scaleplan.destory.tfplan
terraform apply "scaleplan.destory.tfplan"
Quick Start Links
The intention here is to get you quickly started with Terraform on Azure Virtual Desktop Solution:
Description
Links
Create an autoscale scaling plan for Azure Virtual Desktop
I hope you will find this helpful information for getting started with Terraform to deploy the Azure Virtual Desktop – Scaling Plans. Please let me know if I have missed any steps or details, and I will be happy to update the post.
Note – The best method of assigning the DNS Servers is through the DHCP server. If you are setting the IP using DHCP, always make sure you add/remove additional DNS Client Servers from there. In my situation, there was no DHCP server, hence the detailed blog post.
Prerequsites
We are going to implement this configuration via Microsoft Intune using the Scripts:
The necessary Microsoft Intune permissions to create, the PowerShell Scripts.
A device group available within Microsoft Entra with all the devices you want to target this change.
PowerShell Script for DNSClient (Additional DNS Servers)
Save the below script and place on the desktop and we shall be uploading it to Microsft Intune portal – “AddDNSClient.ps1″
Please enter the proper DNS Server Address within the script based on your environment and requirement. In the example below the existing two DNS servers are 8.8.8.8 and 8.8.8.4. We are adding additional two DNS Servers 9.9.9.9 and 9.9.9.4.
Select Devices > Scripts > Add > Windows 10 and later.
In Basics, enter the following properties, and select Next:
Name: AddDNSClientServers
Description: Additional DNS Server 3 & 4
In Script settings, enter the following properties, and select Next:
Script location: Browse to the PowerShell script. saved previously and upload it (AddDNSClient.ps1)
Run this script using the logged on credentials: Select No.
Enforce script signature check: Select No
Run script in 64-bit PowerShell host: Select Yes to run the script in a 64-bit PowerShell host on a 64-bit client architecture.
Select Assignments > Select groups to include. Add the AAD group “Win11-P-DG”
Wait for approx. 15-20 minutes and the policy will apply to the managed devices. (Machine Win11-Intune-15)
Managed Device
You can validate that the settings have been applied to the client by going to the path – C:\ProgramData\Microsoft\IntuneManagementExtension\Logs and opening the file IntuneManagementExtension.txt. I copied the policy ID – cf09649b-78b7-4d98-8bcc-b122c29e5527 from the Intune portal hyperlink and searched within the log file. We can see the policy has been applied successfully.
I hope you will find this helpful information for applying additional DNS servers via Intune – Scripts and PowerShell. Please let me know if I have missed any steps or details, and I will be happy to update the post.
Let’s say you have the entire Windows member server fleet of Windows Server 2016/2019/2022, Windows 11 Pro/Enterprise etc., using DNS Server 1 and Server 2 within their TCP-IP properties and now you decide to add DNS Server address 3 and Server 4 to the member servers to increase resiliency.
In the blog post, I will demonstrate how you can add the additional DNS Server using Group Policy Object and PowerShell with your enterprise.
What doesn’t work?
It would be best if you didn’t waste time – The GPO Computer Configuration –> Administrative Templates –> Network –> DNS Client –> DNS Servers doesn’t work. The “Supported On” version doesn’t include Windows Server 2016\Windows 10 in the compatibility. Even if you apply this GPO, it will apply to the server within the registry, but there will be no visible change under the TCP-IP properties.
Prerequsites
We are going to implement this configuration via group policy object within the enterprise:
The necessary active directory permissions to create, apply and link the GPOs
Access to the Sysvol folder to store the script
WMI Filters to target the script\GPO to specific subnets (More details below)
PowerShell Script for DNSClient (Additional DNS Servers)
Save the below script and place it within the location – \\DOMAINNAME\SYSVOL\DOMAINNAME\scripts\SetDNSAddress.ps1″
Please enter the proper DNS Server Address within the script based on your environment and requirements.
On a member server with administrative privileges, press Win + R to open the Run box. Type gpmc.msc and press Enter to open the Group Policy Management Console.
In the GPMC, expand the forest and domain trees on the left pane to locate the domain you want to create the GPO in.
Right-click on “Group Policy Objects” under the domain and select “New” to create a new GPO.
In the “New GPO” dialog box, provide a name for the GPO (e.g., “Additional DNS Servers”) and click “OK”.
Right-click on the newly created GPO and select “Edit” to open the Group Policy Management Editor.
Navigate to Computer Configuration > Preferences > Control Panel Settings > Scheduled Tasks
Right Click on Scheduled Tasks > Configure the task as Immediate Task.
Give it a name – SetDNSClient
Set the user account as SYSTEM. It will automatically convert into NT Authority\system.
Set the check “run with highest privileges”
In the Actions tab, create a new “Start a program” action.
Set the Program as: PowerShell.exe
Set the Add Arguments point to this line, and modify including your network share and file: ExecutionPolicy Bypass -command “& \\DOMAINNAME\SYSVOL\DOMAINNAME\scripts\SetDNSAddress.ps1”
Set the following in common Tab. – “Apply once and do not reapply”
Bonus Tip – WMI Filters
You want to target the GPO to a specific set of member servers who’s IP range starts with a particular IP address. Then you can create a WMI filter such as the below to target particular computers that meet the below range. In the below example, the GPO will apply to the machine starting with IP Address 10.XX OR 10.XX.
Select * FROM Win32_IP4RouteTable
WHERE (Mask='255.255.255.255'
AND (Destination Like '192.168.%' OR Destination Like '192.169.%'))
Intune (Configuration Profiles – Doesn’t Work)
As of writing the blog post the Intune built-in setting\CSP is showing similar behaviour like the DNS Server GPO it doesn’t work.
CSP
Under both situations (CSP & ADMX templates), the report says the policy is applied successfully. However, there is no visible impact on the operating system’s TCP-IP properties. I am optimistic that using the Scripts method and PowerShell can achieve the same results in Intune. Please let me know in the comments sections if you got it working or/else if you would like to see a blog post on using Intune Scripts to set the DNS Client on member servers.
Reference Links
Following are the references and important links worth going through for more details:
I hope you will find this helpful information for applying additional DNS servers via the GPO and PoweShell. I want to thank my friend Eqbal Hussian for his assistance and additional rounds of testing\validations. Please let me know if I have missed any steps or details, and I will be happy to update the post.
Recent Comments