Tag Archives: MEM

Windows 365 Cloud PC for Developers – Developer Configuration Image + PowerShell Provisioning

2 Sep

At Microsoft Build 2026, Microsoft announced a new developer-focused experience for Windows 365 a Windows 11 Developer Configuration gallery image designed to give developers a Cloud PC that is much closer to ready to code from the first sign-in.

Instead of provisioning a clean Windows Cloud PC and then spending considerable time installing VS Code, Git, Python, Node.js, WSL, command-line tooling and all the other pieces normally required for a developer workstation, Microsoft now provides a preconfigured Windows 365 gallery image with many of these components already installed.

The Developer Configuration image is currently Public Preview and is available for Windows 365 Enterprise and Windows 365 Flex Dedicated mode. Microsoft explicitly states that the image isn’t intended for production workloads while it remains in preview.

Naturally, instead of only creating the provisioning policy through the Intune portal, I wanted to see what the experience looked like through Microsoft Graph and PowerShell.

In this post I’ll cover:

  • What the Windows 365 Developer Configuration image actually is
  • A few important things to understand
  • Developer Image VS Custom Image
  • Creating the Windows 365 provisioning policy with PowerShell
  • Provisioning the Developer Cloud PC
  • Looking inside the Cloud PC to see what Microsoft preinstalled

What is the Windows 365 Developer Configuration image?

The idea is fairly simple.

A traditional Windows 365 gallery image gives you either:

  • Windows Enterprise
  • Windows Enterprise + Microsoft 365 Apps

The new developer image adds another starting point:

Windows Enterprise + Microsoft 365 Apps + a preconfigured developer environment.

Microsoft announced the image at Build 2026 as part of its broader Windows 365 investment for developer workloads. The goal is to reduce the repetitive workstation preparation that normally occurs when onboarding a developer, rebuilding their machine, or moving them onto a new project.

The important distinction here is that this isn’t a custom image that I built and uploaded. It is a Microsoft-maintained Windows 365 gallery image. That means the provisioning experience is exactly the same basic Windows 365 model we already know, but the starting operating system contains a substantially larger developer toolchain.

My mental model: Think of it as Microsoft’s Windows 365 equivalent of a developer workstation baseline – Windows, Microsoft 365 Apps, WSL and the commonly used development tooling already baked into the gallery image.

A few important things to understand

There are several caveats worth highlighting before anyone starts replacing their developer workstation strategy with this image.

1. The Developer Configuration image is still Public Preview

Microsoft explicitly states that the Developer Configuration gallery image isn’t currently intended for production workloads.

So for now I would treat this as something to evaluate, validate and design around rather than immediately rolling it out to every production developer.

2. Microsoft doesn’t manage all those third-party applications for you

Although Microsoft supplies the developer tools in the image, the customer remains responsible for managing and maintaining third-party applications, including vulnerability management, security updates and compliance.

A preinstalled application does not automatically mean a fully managed application.

3. Preinstalled third-party applications aren’t currently packaged Intune apps

Microsoft specifically notes that the third-party tools baked into the image aren’t currently manageable through Intune as packaged applications.

If your organisation requires full Intune application lifecycle management, Microsoft recommends removing the preinstalled versions and redeploying those applications through Intune.

That is something I would definitely evaluate before enterprise adoption.

4. Gallery images move forward

Microsoft refreshes supported Windows 365 gallery images monthly.

That is great from a security and freshness point of view, but it also means:

Test the image, don’t assume it is immutable.

If a development team depends on very specific Python, Node, SDK or extension versions, proper version management is still required.

Developer image vs custom image

I don’t think the new Developer Configuration image means custom Windows 365 images suddenly disappear.

RequirementDeveloper gallery imageCustom image
Standard developer toolsExcellentYou maintain them
Fast starting pointExcellentDepends on image pipeline
Microsoft-maintained Windows baselineYesNo
Internal applicationsAdd via Intune / Device PrepBake into image if required
Very specific tool versionsAdditional management requiredFull control
Highly specialised development stackLimitedExcellent
Image engineering overheadLowHigher
Developer onboarding consistencyStrongStrong if well managed

For many organisations, I suspect the sweet spot will be:

Microsoft Developer Gallery Image + Intune + Autopilot Device Preparation

rather than building an enormous custom developer image from scratch.

Creating the provisioning policy with PowerShell

Now we have everything we need:

  • Developer gallery image
  • Region
  • Cloud PC SKU
  • Entra ID assignment group
  • Windows language/locale
  • Device naming convention

I created the provisioning policy using Microsoft Graph.

My policy is called:

W365-Developer-SKU-Image

and my device naming template is:

CPC-DEV-%RAND:5%

The important image configuration is:

Image Type : gallery
Image ID :
microsoftwindowsdesktop_windows-ent-cpc_win11-25h2-ent-cpc-devready

I’ll provide the complete PowerShell script below so you can modify the variables for your own environment.

PowerShell Script

Link GitHub – avdwin365mem/CloudPC-Prov-DevImage.ps1 at main · askaresh/avdwin365mem

cloudpc-prov-devimage.ps1
#############################################################################################
# Windows 365 Dedicated Cloud PC Provisioning Policy via PowerShell
# Entra Join + Single Sign-On + Automatic (Recommended) Region + Dev Box Gallery Image
# Comment or Un-comment the components that do not apply to your environment
#
# Only requires the Microsoft.Graph.Authentication module - all work is done with raw
# Graph calls so the heavier SDK sub-modules are never loaded.
#############################################################################################
$ErrorActionPreference = "Stop"
#---------------------------------------------------------------------------------------------
# STEP 0 - Module + Authentication
#---------------------------------------------------------------------------------------------
# Install once if needed:
# Install-Module Microsoft.Graph.Authentication -Scope CurrentUser -Force
Import-Module Microsoft.Graph.Authentication
# Set your tenant explicitly - avoids home-tenant guessing and some consent failures
$TenantId = "dXXXX146-4eXX-4XX4-8XXX-fe79XXXXX5"
Connect-MgGraph -TenantId $TenantId -Scopes "CloudPC.ReadWrite.All","Group.Read.All"
# If Connect-MgGraph throws AADSTS650051, see the troubleshooting block at the bottom.
# Hard stop if we are not actually connected - prevents the rest of the script running blind
$ctx = Get-MgContext
if (-not $ctx) { throw "Not connected to Microsoft Graph. Resolve the sign-in error before continuing." }
Write-Host "Connected as $($ctx.Account) to tenant $($ctx.TenantId)" -ForegroundColor Cyan
# Confirm you hold the Cloud PC RBAC permissions before you start
Invoke-MgGraphRequest -Method GET -OutputType PSObject `
-Uri "https://graph.microsoft.com/beta/deviceManagement/virtualEndpoint/getEffectivePermissions"
#---------------------------------------------------------------------------------------------
# STEP 1 - Discovery (optional, but confirms your inputs are valid in THIS tenant)
#---------------------------------------------------------------------------------------------
# 1a. What Cloud PC SKUs have you actually purchased?
(Invoke-MgGraphRequest -Method GET -OutputType PSObject `
-Uri "https://graph.microsoft.com/beta/deviceManagement/virtualEndpoint/retrievePurchasedServicePlans?`$select=id,displayName,type,vCpuCount,ramInGB,storageInGB,userProfileInGB,category,supportedSolution,provisioningType").value |
Format-Table displayName, vCpuCount, ramInGB, storageInGB -AutoSize
# 1b. Which regions are available? Grab exact regionName / regionGroup strings here.
(Invoke-MgGraphRequest -Method GET -OutputType PSObject `
-Uri "https://graph.microsoft.com/beta/deviceManagement/virtualEndpoint/supportedRegions?`$filter=supportedSolution%20eq%20%27windows365%27&`$select=id,displayName,regionStatus,regionGroup,geographicLocationType").value |
Format-Table id, displayName, regionGroup, regionStatus -AutoSize
# 1c. Gallery images - confirm the imageId below exists and is 'supported' in this tenant.
(Invoke-MgGraphRequest -Method GET -OutputType PSObject `
-Uri "https://graph.microsoft.com/beta/deviceManagement/virtualEndpoint/galleryImages").value |
Where-Object { $_.status -eq "supported" } |
Format-Table id, displayName, status -AutoSize
# 1d. Custom (uploaded) images - use these instead if imageType = "custom"
# (Invoke-MgGraphRequest -Method GET -OutputType PSObject `
# -Uri "https://graph.microsoft.com/beta/deviceManagement/virtualEndpoint/deviceImages").value |
# Format-Table id, displayName, status, osBuildNumber -AutoSize
# 1e. Only needed for Hybrid Entra Join. Skip entirely for Entra Join (this script).
# (Invoke-MgGraphRequest -Method GET -OutputType PSObject `
# -Uri "https://graph.microsoft.com/beta/deviceManagement/virtualEndpoint/onPremisesConnections?`$select=id,displayName,healthCheckStatus,adDomainName").value |
# Format-Table id, displayName, healthCheckStatus -AutoSize
#---------------------------------------------------------------------------------------------
# STEP 2 - Build the Provisioning Policy body
#---------------------------------------------------------------------------------------------
$params = @{
displayName = "W365-Developer-SKU-Image"
description = "A Cloud PC for the Developers"
# dedicated = 1:1 Cloud PC per user.
# Alternatives: sharedByUser | sharedByEntraGroup (Frontline)
provisioningType = "dedicated"
# cloudPc = full desktop. Alternative: privateCloudPc
userExperienceType = "cloudPc"
# windows365 = licence-based W365. Alternative: devBox
managedBy = "windows365"
#-----------------------------------------------------------------------------------------
# Image - verify this ID appeared in the Step 1c output before running.
# Swap imageType to "custom" and use a deviceImages ID for your own uploaded image.
#-----------------------------------------------------------------------------------------
imageId = "microsoftwindowsdesktop_windows-ent-cpc_win11-25h2-ent-cpc-devready"
imageDisplayName = "Windows 11 Enterprise Developer Configuration + Microsoft 365 Apps (preview) 25H2"
imageType = "gallery"
#-----------------------------------------------------------------------------------------
# Microsoft Managed Desktop / Windows 365 Enterprise management
#-----------------------------------------------------------------------------------------
microsoftManagedDesktop = @{
type = "notManaged"
profile = $null
}
#-----------------------------------------------------------------------------------------
# Single Sign-On - requires the Entra Kerberos / SSO prerequisites to be in place
#-----------------------------------------------------------------------------------------
enableSingleSignOn = $true
#-----------------------------------------------------------------------------------------
# Entra Join with AUTOMATIC region selection inside the Australia/New Zealand geography.
# To pin a region instead: regionGroup = "australia"; regionName = "australiaeast"
# and drop geographicLocationType.
#-----------------------------------------------------------------------------------------
domainJoinConfigurations = @(
@{
type = "azureADJoin"
geographicLocationType = "australiaNewZealand"
regionGroup = "automatic"
regionName = "automatic"
}
)
# Hybrid Entra Join variant - comment out the block above and use this instead:
# domainJoinConfigurations = @(
# @{
# type = "hybridAzureADJoin"
# onPremisesConnectionId = "<connection-id-from-step-1e>"
# }
# )
windowsSettings = @{
language = "en-US"
}
#-----------------------------------------------------------------------------------------
# Naming template. %RAND:x% where x is 5-11. Total name must stay <= 15 chars.
# "CPC-DEV-" (8) + 5 random = 13 chars. Safe.
#-----------------------------------------------------------------------------------------
cloudPcNamingTemplate = "CPC-DEV-%RAND:5%"
# Scope tags. "0" is the built-in Default scope - omit this line entirely to inherit it.
scopeIds = @("0")
# Windows Autopatch - $null means no Autopatch group assigned
autopatch = @{
autopatchGroupId = $null
}
# User settings persistence - only meaningful for shared/non-dedicated types.
# NOTE: the top-level userSettingsPersistenceEnabled is flagged deprecated by Graph
# (sunset advertised via response Link headers). Use the nested configuration object.
# userSettingsPersistenceEnabled = $false
userSettingsPersistenceConfiguration = @{
userSettingsPersistenceEnabled = $false
userSettingsPersistenceStorageSizeCategory = "sixteenGB"
}
# Autopilot device preparation - not used here
autopilotConfiguration = $null
}
#---------------------------------------------------------------------------------------------
# STEP 3 - Create the policy
#---------------------------------------------------------------------------------------------
$policy = Invoke-MgGraphRequest -Method POST -OutputType PSObject `
-Uri "https://graph.microsoft.com/beta/deviceManagement/virtualEndpoint/provisioningPolicies" `
-Body ($params | ConvertTo-Json -Depth 10) -ContentType "application/json"
if (-not $policy.id) { throw "Policy creation returned no ID - stopping before assignment." }
Write-Host "Created provisioning policy: $($policy.displayName) [$($policy.id)]" -ForegroundColor Green
#---------------------------------------------------------------------------------------------
# STEP 4 - Assign the policy to an Entra security group
#---------------------------------------------------------------------------------------------
# Option A - resolve by display name
$groupName = "W365-CPC-Grp"
$filterEnc = [uri]::EscapeDataString("displayName eq '$groupName'")
$group = (Invoke-MgGraphRequest -Method GET -OutputType PSObject `
-Uri "https://graph.microsoft.com/v1.0/groups?`$filter=$filterEnc&`$select=id,displayName,securityEnabled,groupTypes").value |
Select-Object -First 1
# Option B - hard-code the object ID instead:
# $group = Invoke-MgGraphRequest -Method GET -OutputType PSObject `
# -Uri "https://graph.microsoft.com/v1.0/groups/01eecc64-c3bb-4c47-85ce-bafb18feef12?`$select=id,displayName,securityEnabled,groupTypes"
if (-not $group) { throw "Group '$groupName' not found in tenant $($ctx.TenantId)." }
if (-not $group.securityEnabled) { throw "Group '$($group.displayName)' is not security-enabled - assignment will fail." }
Write-Host "Assignment target: $($group.displayName) [$($group.id)]" -ForegroundColor Cyan
$assign = @{
assignments = @(
@{
id = ""
target = @{
"@odata.type" = "#microsoft.graph.cloudPcManagementGroupAssignmentTarget"
groupId = $group.id
}
}
)
}
Invoke-MgGraphRequest -Method POST `
-Uri "https://graph.microsoft.com/beta/deviceManagement/virtualEndpoint/provisioningPolicies/$($policy.id)/assign" `
-Body ($assign | ConvertTo-Json -Depth 10) -ContentType "application/json"
Write-Host "Assigned policy to $($group.displayName)" -ForegroundColor Green
#---------------------------------------------------------------------------------------------
# STEP 5 - Verify
#---------------------------------------------------------------------------------------------
Invoke-MgGraphRequest -Method GET -OutputType PSObject `
-Uri "https://graph.microsoft.com/beta/deviceManagement/virtualEndpoint/provisioningPolicies/$($policy.id)?`$expand=assignments&`$select=id,displayName,description,imageId,imageDisplayName,imageType,enableSingleSignOn,cloudPcNamingTemplate,provisioningType,managedBy,scopeIds,autopilotConfiguration,domainJoinConfigurations,microsoftManagedDesktop,autopatch,windowsSettings,lastModifiedDateTime,createdBy,createdDateTime,lastModifiedBy,assignments,userExperienceType,userSettingsPersistenceEnabled,userSettingsPersistenceConfiguration" |
ConvertTo-Json -Depth 10
# Disconnect-MgGraph

One important point for anyone using the Graph examples in this post: Microsoft Graph has both v1.0 and beta capabilities around Windows 365 provisioning policies. Some newer provisioning-policy properties, including autopilotConfiguration, are documented through the beta resource. Microsoft explicitly notes that beta APIs can change and shouldn’t be treated as production-stable APIs.

Provisioning policy created

Here is the output from my script after creating the policy:

Created provisioning policy:
W365-Developer-SKU-Image
Assignment target:
W365-CPC-Grp
Assigned policy to:
W365-CPC-Grp

And Graph confirms the image:

"imageType": "gallery",
"imageId": "microsoftwindowsdesktop_windows-ent-cpc_win11-25h2-ent-cpc-devready",
"imageDisplayName": "Windows 11 Enterprise Developer Configuration + Microsoft 365 Apps (preview) 25H2"

along with:

"cloudPcNamingTemplate": "CPC-DEV-%RAND:5%",
"provisioningType": "dedicated",
"managedBy": "windows365"

For validation I also read the provisioning policy back from Graph with the assignments expanded.

This is something I normally include in automation rather than simply assuming a successful HTTP POST means the complete configuration ended up exactly as expected.

Confirming the developer image in Intune

Back in Microsoft Intune:

Devices → Windows 365 → Provisioning policies

I can now see my two test provisioning policies using:

Windows 11 Enterprise Developer Configuration +
Microsoft 365 Apps (preview) 25H2

and Windows 365 reports the image as:

Supported

At this point we’ve created a completely standard Windows 365 provisioning policy — but with Microsoft’s new developer-ready image as the operating-system baseline.

So what’s actually installed inside the Developer Cloud PC?

This was the part I really wanted to inspect. According to Microsoft’s current Developer Configuration image documentation, the image contains significantly more than just VS Code and Git.

The Windows environment currently includes tooling such as:

AreaIncluded tooling
EditorVisual Studio Code
Source controlGit, GitHub tooling
LanguagesPython, Node.js
Node ecosystemnpm, nvm
PowerShellPowerShell 7
LinuxWSL + Ubuntu
AzureAzure CLI
.NET.NET Runtime and .NET SDK
Python toolingUV
TerminalIntelligent Terminal
Unix toolingCoreutils
PromptOh My Posh
Windows developmentWinApp CLI
UtilitiesPowerToys
AI developmentGitHub Copilot CLI

Microsoft also preinstalls several VS Code extensions, including PowerShell, Python, WSL, GitHub pull-request tooling and Edge developer tooling.

Microsoft updated the developer image again in August 2026 to add Intelligent Terminal and Coreutils, which is worth calling out because it demonstrates that this isn’t a one-time static developer image — the gallery image itself continues evolving.

Windows + Linux in the same developer workstation

One of the important parts of this image is WSL.

Microsoft doesn’t simply enable Windows Subsystem for Linux; the image includes:

WSL
+
Ubuntu
+
developer tooling inside the WSL environment

Microsoft also includes a Bash script used to configure the user environment inside Ubuntu.

That gives the developer a much more useful starting position:

Windows 11
├── Visual Studio Code
├── PowerShell 7
├── Git
├── Python
├── Node.js
├── Azure CLI
├── .NET
└── WSL
└── Ubuntu
├── Git
├── Python
├── Node
└── Developer tooling

For developers working across Windows, Linux, Azure and GitHub, this makes much more sense than treating the Cloud PC simply as another Windows desktop.

Final thoughts

I’ve been working with Windows 365 for quite some time, and this is one of the more interesting changes to the provisioning story for developer personas.

Previously, organisations basically had two choices:

Standard Microsoft image
+
install everything afterwards

or:

Build + patch + test +
maintain your own custom image

The Developer Configuration image introduces a useful middle ground.

Microsoft maintains the generic developer foundation, while organisations can layer their corporate requirements through Intune and Windows Autopilot Device Preparation.

There are still things I want to see evolve particularly application lifecycle management for the preinstalled developer tools and the preview status means I wouldn’t treat this as a finished production solution yet.

Thanks,
Aresh Sarkari

Microsoft Intune – Add additional DNS Client Servers across the managed devices

24 Aug

I recently wrote a blog post about adding DNS Client via GPO, highlighting which methods work and which don’t. If you’re interested, you can read more about it on – GPO – PowerShell – Intune – Add additional DNS Client Servers across the enterprise | AskAresh. As promised, here are the steps for performing the same task in Microsoft Intune for all of your managed devices.

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.
    $dnsclient=Get-DnsClient  | Get-DnsClientServerAddress | where{$_.ServerAddresses -contains "8.8.8.8" -or $_.ServerAddresses -contains "8.8.8.4"}
    foreach($nic in $dnsclient){
    Set-DnsClientServerAddress -InterfaceIndex $nic.InterfaceIndex -ServerAddresses ("8.8.8.8","8.8.8.4","9.9.9.9","9.9.9.4")
    }

    Create a script policy and assign it – Intune

    1. Sign in to the Microsoft Intune admin center.
    2. Select Devices > Scripts > Add > Windows 10 and later.Screenshot that shows creating a new script for a Windows 10 device.
    3. In Basics, enter the following properties, and select Next:
      • Name: AddDNSClientServers
      • Description: Additional DNS Server 3 & 4
    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.
    5. 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.

    Thanks,
    Aresh Sarkari

    PowerShell – Frontline Workers – Create Windows 365 Cloud PC Provisioning Policy

    23 May

    I have a blog post about creating a Windows 365 Cloud PC Provisioning Policy using PowerShell. In this post blog, I will demonstrate how to create the provisioning policy using PowerShell and MS Graph API with beta modules for Windows 365 Cloud PC – Frontline Workers.

    Windows 365 Frontline Worker

    Introduction

    I will not attempt to explain Frontline, but the best explanation is here: What is Windows 365 Frontline? | Microsoft Learn.

    Example – Each Windows 365 Frontline license can be shared with up to three employees. This means that if you have 30 employees, you only need to purchase 10 licenses to provision the CloudPC for all 30 employees with access over the day. However, note you are buying the frontline license based on the active sessions. You must purchase the license accordingly if you have more than 10 active workers in a shift.

    What happens when license are exhausted?

    In my demo tenant, I have two licenses for Frontline workers. When I try to log in to the third one (Note I have already logged into 2 active sessions and running them.) Get the following message.

    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!
    Permissions for MS Graph API

    Step 3 –  Check the User account by running the following beta command.

    #Beta APIs
    PS C:WINDOWSsystem32> Get-MgBetaUser -UserId admin@wdomain.com

    Create Provisioning Policy (Frontline Worker)

    We are creating a provisioning policy that involves the following: avdwin365mem/win365frontlineCreateProvPolicy at main · askaresh/avdwin365mem · GitHub

    • Azure AD Joined Cloud PC desktops
    • The region for deployment – Australia East
    • Image Name – Windows 11 Enterprise + Microsoft 365 Apps 22H2 (from the Gallery)
    • Language & Region – English (United States)
    • Network – Microsoft Managed
    • Cloud PC Naming format – FLW-%USERNAME:5%-%RAND:5% (FLW – Frontline Worker)
    $params = @{
    	displayName = "Demo-FrontLine"
    	description = "Front Line Workers Prov Policy"
    	provisioningType = "shared"
    	managedBy = "windows365"
    	imageId = "MicrosoftWindowsDesktop_windows-ent-cpc_win11-22h2-ent-cpc-m365"
    	imageDisplayName = "Windows 11 Enterprise + Microsoft 365 Apps 22H2"
    	imageType = "gallery"
    	microsoftManagedDesktop = @{
    		type = "starterManaged"
    		profile = $null
    	}
    	enableSingleSignOn = $true
    	domainJoinConfigurations = @(
    		@{
    			type = "azureADJoin"
    			regionGroup = "australia"
    			regionName = "automatic"
    		}
    	)
    	windowsSettings = @{
    		language = "en-US"
    	}
    	cloudPcNamingTemplate = "FLW-%USERNAME:5%-%RAND:5%"
    }
    
    New-MgBetaDeviceManagementVirtualEndpointProvisioningPolicy -BodyParameter $params

    Note – Post provisioning, you need to add the assignment of a AAD group consisting of all the frontline users. In the future I can demonstrate the API call for assignments. You can also use Andrew Taylors post around using Graph to create the Windows 365 Group – Creating Windows 365 Groups and assigning licenses using Graph and PowerShell

    Powershell Output

    Policy will show up in the MEM Portal

    Optional Properties

    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.

    OnPremisesConnectionId = "4e47d0f6-6f77-44f0-8893-c0fe1701ffff"

    I hope you will find this helpful information for creating a 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.

    Thanks,
    Aresh Sarkari

    Windows 365 Cloud PC – Alert Monitoring – Get your alerts in a Microsoft Teams Channel using Azure Logic Apps

    23 Mar

    If you’re managing Windows 365 Cloud PCs, keeping track of alerts can be a daunting task. Fortunately, Azure Logic Apps can help automate this process by sending alerts directly to your Microsoft Teams channel. In this blog post, we’ll explore how to set up this integration, so you can stay on top of your Windows 365 environment without constantly checking the portal or notifications within the Intune portal.

    Note – Within the Microsoft Intune admin center portal you can already send notifications via email.

    Set up your Microsoft Teams channel

    To start, you’ll need to create a Microsoft Teams channel where you want to receive alerts. If you don’t have one already, create a new channel and name it something like “Windows365Alerts.”

    Next, within the newly created channel, add the Connector – Incoming Webhook

    Click on Configure of the Incoming Webhook connectors by entering the Name – Win365Alerts and custom image. Why not use the Windows 365 Cloud PC Logo and click on create.

    Please copy the link and save it for all future reference purposes. We will be using this URL within the Azure Logic Apps.

    https://blahblahblahblah.webhook.office.com/webhookb2/9cd8bac0-XXXX-4e30-XXXX-00700XXXX0@XXXX-d8f4-4c55-XXXX-0eec698XXXXXX/IncomingWebhook/3aXXXXXXXXbed497fbc4d9857XXXXX/57cadd96-b493-4bf6-a665-b0e9XXXXXXX
    

    Azure Active Directory Enterprise App (MS Graph API)

    Let’s pre-create the application ID and client secret we will use to connect and leverage the Microsoft Graph APIs via Powershell

    • Connect to Azure Portal and go to Azure Active Directory
    • Click on App Registrations and select – New Registration
    • Give the App a Name – GraphAPI-App
    • You will get two important information created for later use within Powershell
      • Application ID
      • Tenant ID
    • Now let’s grant this App GraphAPI-App Permission. Click on Add a permission and select MS Graph and search for Cloud PC– CloudPC.ReadAll and select read permissions and Add Permissions
    • Select Grant admin consent for domain
    • We are using client secret so now lets enable that. Click on Certificates & Secrets – Client Secrets and select New client secret\
    • Give it a name (Deviceconfig_secret) and expiry date (12 months)
    • Copy the Secret Value

    Azure Key Vault – (Store the Secret)

    This is an optional step, and I highly recommend this step for all production environments as the secret is stored within the Azure Key Vault, and within the Azure Logic Apps, you will call this secret.

    After creating the value, go to Secret and click on Generate/Import, and under manual, enter a name and paste the secret key we created in the above step.

    Additionally, I will dedicate a service account(svc_kv_api) specifically for this secret retrieval for the Azure Logic Apps. Let’s add the service account with the necessary permissions under the Access Policies and give it Get and List permissions.

    Create an Azure Logic App

    Next, you’ll need to create an Azure Logic App. In the Azure portal, search for “Logic Apps” and click “Create.” Give your Logic App a name and select your desired subscription, resource group, and location. Then click “Review + Create” and “Create” to create your Logic App.

    Configure your Logic App

    Once your Logic App is created, click “Logic App Designer” and select blank logic app template and add the other operations shown below:

    Step 1 – Recurrence (A schedule that will be triggered)

    Depending upon your SLA agreements, put a trigger. In this example, I have selected every 3 min.

    Step 2 – Fetch the Secret from the Azure Key Vault

    In the earlier step, we created the Azure Key vault and stored the secret there. In this step, we will make the Azure Logic Apps Fetch the Secret

    • Tenant ID – Copy from the above steps
    • KeyVault Name – Copy from the above steps
    • Click on Sign and use the dedicated service account to fetch this Secret

    Step 3 – HTTP Get the Alerts for Windows 365 Using MS Graph API

    We shall create the HTTP request using the Windows 365 Alert API – List and authenticate the call using the secret. Enter all the information shown in the screenshot.

    https://graph.microsoft.com/beta/deviceManagement/monitoring/alertRecords

    Step 4 – We shall Parse the JSON output from the above API GET request

    Create the Parse JSON operation, and we will enter the below sample JSON output. Note I have run the GET and got the output from the API. Paste the below code into the schema example. It will auto-generate the below output for your use without values inside.

    {
        "properties": {
            "@@odata.context": {
                "type": "string"
            },
            "value": {
                "items": {
                    "properties": {
                        "alertImpact": {
                            "properties": {
                                "aggregationType": {
                                    "type": "string"
                                },
                                "value": {
                                    "type": "integer"
                                }
                            },
                            "type": "object"
                        },
                        "alertRuleId": {
                            "type": "string"
                        },
                        "alertRuleTemplate": {
                            "type": "string"
                        },
                        "detectedDateTime": {
                            "type": "string"
                        },
                        "displayName": {
                            "type": "string"
                        },
                        "id": {
                            "type": "string"
                        },
                        "lastUpdatedDateTime": {
                            "type": "string"
                        },
                        "resolvedDateTime": {
                            "type": "string"
                        },
                        "severity": {
                            "type": "string"
                        },
                        "status": {
                            "type": "string"
                        }
                    },
                    "required": [
                        "id",
                        "displayName",
                        "status",
                        "severity",
                        "alertRuleId",
                        "alertRuleTemplate",
                        "detectedDateTime",
                        "resolvedDateTime",
                        "lastUpdatedDateTime",
                        "alertImpact"
                    ],
                    "type": "object"
                },
                "type": "array"
            }
        },
        "type": "object"
    }

    Step 5 – Post the Alert to Microsoft Teams using the HTTP operation

    Create the HTTP Operation, select POST, enter the webhook URL from the above step on MS Teams, and paste it within the URL. With the Headers add Content-Type: application/json and paste the below body code.

    {
      "text": "**Alert name:** @{items('For_each')?['displayName']} \n\n **Status:** @{items('For_each')?['status']} \n\n **Severity:** @{items('For_each')?['severity']} \n\n **Detect Date:** @{items('For_each')?['detectedDateTime']} \n\n **Resolved Date:** @{items('For_each')?['resolvedDateTime']} \n\n **Alert Rule Template:** @{items('For_each')?['alertRuleTemplate']} \n\n **Alert Impact:** @{items('For_each')?['alertImpact']}",
      "title": "Windows 365 Cloud PC Alerts  with status and Severity "
    }

    Step 6 – Run the workflow

    The above will now start running the Azure Logic Apps every 3 mins and keep sending the alerts to Microsoft teams

    I need help filtering the alerts based on specific Status and Severity. If you manage to get to that, please message me, and I will happily include those bits in the blog post.

    I hope you will find this helpful information for enabling Windows 365 Alerts within the MS Teams using the Azure Logic Apps. Please let me know if I have missed any steps or details, and I will be happy to update the post.

    Thanks,
    Aresh Sarkari

    Alternate Azure Network Connection for Windows 365 Cloud PC

    15 Mar

    Alternate ANCs (Azure Network Connections) are secondary or backup connections to the Microsoft Azure network used to provide redundancy and high availability for Windows 365 Cloud PC provisioning of new desktops. Alternate ANCs can be used when a primary connection fails or experiences connectivity issues, ensuring access to Windows 365 Cloud Provisioning continues for the desktops uninterrupted using the backup ANC.

    Introduction

    Alternate ANCs can be used when a primary region availability fails, ensuring access to Windows 365 Cloud Provisioning continues for the new desktops uninterrupted using the backup ANC. As long as the first ANC in the list is Healthy, it will always be used for provisioning Cloud PCs using this policy. If the first ANC is not healthy, the policy will use the next ANC in the list that is healthy.

    My Scenario

    I have an Azure VNET in the region (Australia East) and a dedicated subnet for the Windows 365 Cloud PC desktops in my environment. Now imagine a scenario if the Azure region Australia East had issues. It will directly impact the provisioning of the new Cloud PC desktops.

    How will we increase HA/DR capability during Cloud PC Provisioning Issues

    Create a backup VNET in different region (Asia Pacific East Asia – HK)

    Go to you Azure Portal and create a new VNET in a different region of you choice (Azure Portal — Virtual Networks – Create Network)

    Create a dedicated subnet for Windows 365 Cloud PC

    Go into the newly created VNET – W365-Bckup-VNET01 and select Subnet and click + Subnet and create a dedicated subnet for the Windows 365 Cloud PC.

    Add the additional Azure Network Connection in Intune Portal

    I have a previous blog post on creating the the PowerShell – Create Azure Network Connection (ANC) for Windows 365 Cloud PC you can either use that or create one in the Microsoft Intune admin center. We are creating an Azure Network Connection that includes the following:

    • Display Name of the network – Win365-Bckup-ANC01
    • Azure Subscription Name – Azure subcription 1
    • Type – There are two types we are selecting Azure AD join – azureADJoin
    • Resource Group ID – The resource group within Azure – W365-AVD-RG01
    • Virtual Network ID – The VNET within Azure – W365-Bckup-VNET01
    • Subnet ID – The subnet for W365 within VNET – Win365-ASE-Bac-Sub01

    Cloud Provisioning Policy

    Go into your Cloud PC Provisioning Policy and select Edit. Under the Azure Network Connection you will be able to see the newly added ANC – Win365-Bckup-ANC01 make sure you choose that. It will automatically assign the priority as 2 and will come into effect during network outages in the region.

    In the above scenario, at all times, it will use the ANC-W365-Sub01 (Priority 1) network for provisioning all Cloud PC. If there is a contention or issues with the primary ANC, then the backup Win365-Bckup-ANC01 (Priority 2) network will kick in and continue provisioning the new desktops in that region/network.

    Note

    At the time of writting this blogpost, when i tried to create the backup VNET in Australia SouthEast and Australia Cental it said unsupported region when adding the Azure Network Connection. This was the reason i selected the Asiapacifc East (Honkong) region as the second best choice. I am sure at somepoint in time it will be fixed and I would be able to create a backup ANC within the country.

    I hope you will find this helpful information for creating an Alternate Azure Network Connection for increasing the HA and DR on the cloud pc provisioning of new desktops. Please let me know if I have missed any steps or details, and I will be happy to update the post.

    Thanks,
    Aresh Sarkari

    PowerShell Enable Remote Help in Microsoft Intune

    7 Mar

    Remote Help in Microsoft Intune works by enabling IT administrators to remotely control a user’s mobile device, allowing them to view the device’s screen and interact with it in real-time. This enables administrators to quickly diagnose and fix issues on the device, without needing to be physically present with the user.

    To use Remote Help in Microsoft Intune, IT administrators first need to enable the feature in the Intune console. Once enabled, administrators can initiate a remote session with a user’s device by sending an invitation link to the user via email or text message. The user then clicks on the link to join the remote session, allowing the administrator to remotely control the device.

    In the blog post I will showcase how to enable this feature via PowerShell instead of the Microsoft Intune admin center portal.

    Pre-requsites

    • An active Microsoft Intune subscription.
    • An Azure AD (Active Directory) subscription with administrative access.
    • The Azure AD application registration credentials, including client ID and secret.
    • Permissions to access and manage Microsoft Intune and Microsoft Graph API resources.
    • PowerShell and AzureAD PowerShell module installed on the local machine to run PowerShell scripts.
    • A valid Azure AD authentication token to authenticate and authorize Microsoft Graph API requests.

    Create the Client Secret for MS Graph

    Let’s pre-create the application ID and client secret we will use to connect and leverage the Microsoft Graph APIs via Powershell

    • Connect to Azure Portal and go to Azure Active Directory
    • Click on App Registrations and select – New Registration
    • Give the App a Name – MSGraph-DeviceMgmt-Secret
    • You will get two important information created for later use within Powershell
      • Application ID
      • Tenant ID
    • Now let’s grant this App MSGraph Permission. Click on Add a permission and select MS Graph and search for Device – DeviceManagementConfiguration and select read-write permissions and Add Permissions
    • Select Grant admin consent for domain

    Note that RemoteSettings, aka Remote Help, falls under Device Management Configurations. We will use that for the permissions (read-write)

    • We are using client secret so now lets enable that. Click on Certificates & Secrets – Client Secrets and select New client secret\
    • Give it a name (Deviceconfig_secret) and expiry date (12 months)
    • Copy the Secret Value

    Variable Region

    Delcare all the variable within this section. Lets take a look at what we are declaring within the script:

    • GraphEndpoint and resource URL if you notice we are using the remoteAssistanceSettings
    $graphEndpoint = "https://graph.microsoft.com"
    $resourceUrl = "$graphEndpoint/beta/deviceManagement/remoteAssistanceSettings"
    • From the above section we have the values for Client ID, Secret and tenant id which we will paste in here.
    $clientId = "XXXXXXXX-6f08-XXXXX-a6ff-XXXXXXXXXXXXX"
    $clientSecret = "Q-D8Q~XXXXXXXXXXXXXXXXXXXXXXXXXXX"
    $tenantId = "XXXXXXXXXX-d8f4-4c55-XXXXX-XXXXXXXXXXX"
    $authority = "https://login.microsoftonline.com/$tenantId/oauth2/v2.0/token"
    $scope = "https://graph.microsoft.com/.default"

    Execution block

    Execution code block within this section. Lets take a look at what we are we executing within the script:

    • The body payload to enable disable the Remote Help Assistance settings
      • RemoteAssistanceState – Enabled/Disabled
      • AllowSession to Unenrolled Devices – $true or $false
      • Block chat – $true or $false
    $payload = @{
        "@odata.type" = "#microsoft.graph.remoteAssistanceSettings"
        "remoteAssistanceState" = "disabled"
        "allowSessionsToUnenrolledDevices" = $false
        "blockChat" = $false
    } | ConvertTo-Json

    Final Script

    Here I will paste the entire script block for seamless execution in a single run. Following is the link to my GitHub for this script – https://github.com/askaresh/avdwin365mem/blob/main/enableremotehelpmem

    # Define the Graph API endpoint and resource URL
    $graphEndpoint = "https://graph.microsoft.com"
    $resourceUrl = "$graphEndpoint/beta/deviceManagement/remoteAssistanceSettings"
    
    # Define the authentication parameters
    $clientId = "XXXXXXXX-6f08-XXXXX-a6ff-XXXXXXXXXXXXX"
    $clientSecret = "Q-D8Q~XXXXXXXXXXXXXXXXXXXXXXXXXXX"
    $tenantId = "XXXXXXXXXX-d8f4-4c55-XXXXX-XXXXXXXXXXX"
    $authority = "https://login.microsoftonline.com/$tenantId/oauth2/v2.0/token"
    $scope = "https://graph.microsoft.com/.default"
    
    # Authenticate to the Graph API and obtain an access token
    $tokenResponse = Invoke-RestMethod -Method Post -Uri $authority `
        -Body @{
            client_id = $clientId
            client_secret = $clientSecret
            scope = $scope
            grant_type = "client_credentials"
        } `
        -Headers @{
            "Content-Type" = "application/x-www-form-urlencoded"
        }
    
    $accessToken = $tokenResponse.access_token
    
    
    # Define the payload for the PATCH request
    $payload = @{
        "@odata.type" = "#microsoft.graph.remoteAssistanceSettings"
        "remoteAssistanceState" = "enabled"
        "allowSessionsToUnenrolledDevices" = $false
        "blockChat" = $false
    } | ConvertTo-Json
    
    
    # Send a PATCH request to the remoteAssistanceSettings resource with the updated payload
    $headers = @{
        "Authorization" = "Bearer $accessToken"
        "Content-Type" = "application/json"
        "Content-length" = $payload.Length
    }
    
    Invoke-RestMethod -Method Patch -Uri $resourceUrl -Headers $headers -Body $payload

    Validations

    After running the powershell script now check the portat it will be enabled

    Overall, Remote Help in Microsoft Intune is a powerful tool for IT administrators, enabling them to quickly diagnose and fix issues on mobile devices, improving productivity and reducing downtime. If you’re using Microsoft Intune, be sure to take advantage of this powerful feature to improve your device management capabilities.

    Useful LinksCredits
    Update remoteAssistanceSettings – https://learn.microsoft.com/en-us/graph/api/intune-remoteassistance-remoteassistancesettings-update?view=graph-rest-betaMicrosof
    Enabling Remote Help and Supporting Users with Intune – Microsoft Community HubMicrosoft

    I hope you will find this helpful information for enabling Remote Help using PowerShell. Please let me know if I have missed any steps or details, and I will be happy to update the post.

    Thanks,
    Aresh Sarkari

    Disable Search Highlights on Windows 365 Cloud PC and Azure Virtual Desktop using Microsoft Intune

    24 Feb

    Search Highlight is a feature in Windows 11 (Enterprise\Multi-session) that highlights search results in the Start menu and taskbar search box. While this feature can be helpful for some users, others may find it distracting or unnecessary. Fortunately, it is possible to disable the Search Highlight feature in Windows 11 using Microsoft Intune. Plenty of information is available on disabling the Windows 11 Search Highlight using Group policy, Registry and UI. However, we will leverage Custom OMA-URI settings from Microsoft Intune in this blog post.

    Search – CSP Details

    The Search – Policy configuration service provider enables the enterprise to configure policies on Windows 11. Following are the details on the one we are using for disabling the search highlights:

    How to disable Search Highlights in Microsoft Endpoint Manager

    To disable the Search Highlight feature in Windows 11 (Enterprise/Multi-session) using Microsoft Intune, follow these steps:

    • Login to the MEM Portal – https://endpoint.microsoft.com/
    • Select Devices > Configuration Profiles > Create Profile.
    • For Platform, select Windows 10 and later.
    • For Profile type, select Templates > Custom and select Create.
    • Enter a Name – DisableSearchHighlight and description and choose Next
    • Under the OMA-URI Settings, clicks on Add
    • Enter the Name, Description, and OMA-URI fetched in the references from the MS CSP link below. The value is an integer based on the documentation, and as we disable the setting, the value is 0.
    • Remember the MS documentation called out this setting only applies to Devices. In the case of Assignments, we will target Windows 365 Device Group and Azure Virtual Desktop Session Host Pools.
    • Click on Review and Save

    Validate the Policy is applying

    After 10-15 mins of waiting, go into the newly configured configuration profiles policy, and you will start seeing it getting applied to the targeted devices (MEM Portal > Devices > Configuration Profiles > DisableSearchHighlights)

    Cloud PC – Within Windows 11

    Login to the Windows 365 Cloud PC, and now when you click on Search, the advertisements and search highlights are gone.

    Useful LinksCredits
    Search – CSP Policy – https://learn.microsoft.com/en-us/windows/client-management/mdm/policy-csp-searchMicrosoft
    5 Unique Ways to Disable Search Highlights on Windows 11Prajwal Desai
    Disable Enable Search Highlights in Windows 11Jitesh Kumar

    I hope you will find this helpful information towards disabling the annoying Search Highlights on Windows 365, AVD environment and physical endpoints using Microsoft Endpoint Manager. Please let me know if I have missed any steps or details, and I will be happy to update the post.

    Thanks,
    Aresh Sarkari

    Microsoft Defender for Endpoint – Web Content Filtering for Windows 365 Cloud PC and Azure Virtual Desktop

    22 Feb

    In today’s world, online security has become more important than ever, especially for businesses. As more and more companies shift their workloads to the cloud, the need for effective security measures has increased. One of the most critical aspects of security is web content filtering. Microsoft Defender for Endpoint is an excellent solution for protecting your Windows 365 Cloud PC and Azure Virtual Desktop environments. If you haven’t see my previous blog post on – Microsoft Defender for Endpoint (MDE) – Getting started for Windows 365 Cloud PC and Azure Virtual Desktop check that first.

    Usecase

    Web content filtering is a critical aspect of online security that can be used in many different scenarios. Here are some common use cases for web content filtering:

    1. Business Security: Blocking access to malicious websites and other dangerous content, web content filtering helps prevent cyber attacks and data breaches.
    2. Compliance: Many organizations are required to comply with industry-specific regulations and standards, such as HIPAA or PCI-DSS. Web content filtering can help ensure that employees are not accessing websites or content that violates these regulations.
    3. Employee Productivity: Web content filtering can also be used to enhance employee productivity by blocking access to non-work-related websites, such as social media or gaming sites.
    4. Education: Educational institutions can use web content filtering to prevent students from accessing websites that are not educational or age-appropriate.
    5. Guest Wi-Fi: Businesses that offer guest Wi-Fi can use web content filtering to protect their network and guests from online threats.

    Overall, web content filtering is a versatile tool that can be used in a variety of settings to enhance online security, productivity, and compliance.

    Pre-requisites

    To use Microsoft Defender for Endpoint web content filtering on Windows 365 Cloud PC and Azure Virtual Desktop, there are a few prerequisites that you need to meet:

    • Portal Access to Microsoft 365 Defender Portal
    • Windows Defender SmartScreen Enabled on all Browsers (Edge, Chrome etc.)
    • Network Protection must be enable on the endpoint devices
    • Microsoft Defender for Endpoint (MDE) Plan 1 or 2
    • MDE for Business
    • Windows 10/11 or Multi-session Operating System

    Enable Web Content Filtering

    To enable Web Content Filtering in Microsoft Defender for Endpoint (MDE), you need to follow these steps:

    • Log in to the Microsoft Defender Security Center: Go to https://security.microsoft.com/ and log in with your Microsoft 365 account.
    • Navigate to Settings and select Endpoints
    • Click on Advance Features and enable Web Content Filtering

    Create Device Group for Windows 365 & AVD in Microsoft 365 Defender Portal

    To assign the policy to particular devices such as Windows 365 Cloud and Azure Virtual Desktop Session, we will create the Device Groups:

    • Log in to the Microsoft Defender Security Center: Go to https://security.microsoft.com/ and log in with your Microsoft 365 account.
    • Navigate to Settings and select Endpoints
    • Under Permissions, click on Device Groups
    • Select Add device group and give it a name – Win365Devices
    • The Cloud PC start with CPC, I will be using that along with OS type – Windows 11
    • For the Azure Virtual Desktop – My Session host start with AVD-, I will use that as the device group along with OS Type – Windows 11

    Enable Network Protection under Microsoft Endpoint Portal (Intune)

    Under the Enpoint Secruity – Antivirus policy we will enable the configuration:

    • Login to the MEM Portal – https://endpoint.microsoft.com/
    • Select Endpoint security > Antivirus > Create Policy.
    • For Platform, select Windows 10, Windows 11, and Windows Servers.
    • For Profile type, select Microsoft Defender Antivirus, and then select Create.
    • Enter a Name – W365-AVD-AV-P01 and description and choose Next
    • Under the Configuration Settings
    • Enable Network Protection – Enable (Block Mode)

    In my previous blog post on getting started, I enabled Network Protect and other configurations. Here I am trying to give you a quick config guidance.

    Enable Smart Screen under Microsoft Edge Browser via Intune

    I want to use the security baseline around Microsoft Edge for enabling global configuration across all the endpoints:

    • Login to the MEM Portal – https://endpoint.microsoft.com/
    • Select Endpoint security > Security Baseline > Microsoft Endge Baseline.
    • Click on Create a profile and give it a name – MSEdge-Sbaseline-01
    • Enable the SmartScreen config
    • I am applying this security baseline to All Devices

    Note you can enable them via configuration profiles too. In this scenario, I prefer using the security baselines.

    Enable Smart Screen for Google Chrome Browser via Intune

    To enable Smart Screen on Google Chrome, follow these steps:

    • Login to the MEM Portal – https://endpoint.microsoft.com/
    • Select Devices > Configuration profiles > Create profile
    • Under Platform – Windows 10 & Later
    • Profile Type – Templates and Select Administrative Templates
    • Give the policy a name – GoogleChrome-SmartScreen-CP01
    • Under Computer – Select Configure the list of force-installed apps and extensions
    • Click on Enable and enter the below URL for extension
    • Further assign the policy to the target devices
    • Click on Review and Save
    bkbeeeffjjeopflfhgeknacdieedcoml;https://clients2.google.com/service/update2/crx

    Create policy for Web Content Filtering

    To create a web content filtering policy in Microsoft Defender for Endpoint, follow these steps:

    • Log in to the Microsoft Defender Security Center: Go to https://security.microsoft.com/ and log in with your Microsoft 365 account.
    • Navigate to Settings and select Endpoints
    • Under Rules > Web Content Filtering > Add Item
      • Policy Name – Stop Social Media
      • Block Categories > Leisure > Social Networking & Instant Messaging & Professional Networking
      • Scope – Select the Windows 365 Device Group & AVD Device Group (Session Host VMs), as its a targeted policy
    • Wait for approx. 40 mins for the policy to implement for your endpoints

    Validate the URLs within Windows 365 Cloud PC

    Before going ahead and checking the URLs within the browser verify the following on the virtual desktop or endpoints:

    SmartScreen

    Open the browser and type edge://policy and make sure the Smart Screen is enabled

    Network Protection

    Open the Powershell and check if network protection is enable (Value 1) block mode

    Microsoft Edge

    Open Microsoft Edge and open https:\\www.facebook.com or https:\\www.snapchat.com

    Google Chrome

    Check reports in Defender Portal

    Under the Microsoft Defender Portal go to Reports > Web Protection > Web content filtering categories details

    Useful LinksCredits
    Web content filtering – https://learn.microsoft.com/en-us/microsoft-365/security/defender-endpoint/web-content-filtering?view=o365-worldwideMicrosoft
    How to configure Microsoft Defender SmartScreen via Microsoft Intune? – Endpoint CaveRene Laas
    Enabling web filtering with Microsoft Defender for Endpoint – CIAOPSRobert Crane

    I hope you will find this helpful information towards web content filtering journey to secure your Windows 365 and AVD environments using Microsoft Defender for Endpoint. Please let me know if I have missed any steps or details, and I will be happy to update the post.

    Thanks,
    Aresh Sarkari

    Microsoft Defender for Endpoint (MDE) – Getting started for Windows 365 Cloud PC and Azure Virtual Desktop

    16 Feb

    If you are using Windows 365 Cloud PC and Azure Virtual Desktop, the Microsoft Defender for Endpoint (MDE) is a security solution designed for protecting endpoints, such as Windows 11/Windows 11 Mutli-Session computers, servers, Azure Virtual Desktops and more from various types of cyber threats. The main reason it’s evident to use MDE is that it seamlessly integrates with the solution with minimal to less effort compared to other solutions. This blog post will discuss how to get started with Microsoft Defender for Endpoint in the Windows 365 Cloud and Azure Virtual Desktop.

    Prerequisites

    • Rights to use and deploy Windows 365 Cloud PC and Azure Virtual Desktop and the ncessary licenses
    • Microsoft Defender for Endpoint Plan 1 or Plan 2 depending upon the requirements and $$$.
    • Make sure the license is available and listed Microsoft admin center

    Enable MDE in Microsoft 365 Security Portal/Intune

    To enable Microsoft Defender for Endpoint (MDE) in the Microsoft Defender Security Center, you need to follow these steps:

    1. Log in to the Microsoft Defender Security Center: Go to https://security.microsoft.com/ and log in with your Microsoft 365 account.
    2. Navigate to Settings and select Endpoints
    3. Click on On for Microsoft Intune Connection & Device Discovery
    4. Scroll to the bottom and select Save Preferences

    We will manage the endpoints via Intune, so all the rest of the actions and fun will be within the https://endpoint.microsoft.com/ and Endpoint Security. After a brief period of 10-15 mins, you can see the connection status being Available and synchronized.

    Create the Endpoint detection and response policy (onboarding)

    Our environment is managed via Modern Management, and we don’t have the overhead of legacy setup. We will use the Intune Endpoint detection response (EDR) policy to onboard the devices. This is the simplest method as it doesn’t involve installing the agent manually or via GPOs.

    Sign in to the Microsoft Endpoint Manager admin center.

    • Login to the MEM Portal – https://endpoint.microsoft.com/
    • Select Endpoint security > Endpoint detection and response > Create Policy.
    • For Platform, select Windows 10, Windows 11, and Windows Servers.
    • For Profile type, select Endpoint detection and response, and then select Create.
    • Enter a Name – W365-AVD-EDR-P01 and description and choose Next
    • Under the Configuration Settings
      • MDE client configuration package type – Auto from connector (We are a 100% modern managed environment we can leverage this simple option)
      • Sample Sharing – Not configured
      • Telemetry Reporting Frequency – Expedite (We want reporting to be lightning-fast)
    • Next, the most critical part is the target assignments. I am explicitly creating this policy to target Windows 365 Cloud PC and Azure Virtual Desktop
    • Review and Create the policy and it will go ahead and enable MDE on the fleet.
    • After sometime all your devices will show whether they are onboarded or not.

    Many ways to carry out the onboarding. This is just one way and the most straightforward. Read more options here – https://learn.microsoft.com/en-us/microsoft-365/security/defender-endpoint/onboarding-endpoint-manager?view=o365-worldwide

    On the onboarded device, go and run the following command to verify the status

    Get-MpComputerStatus

    Device Compliance Policy (Update)

    I already have my existing Windows 10/11 compliance policy after enabling MDE, and I will go ahead and update the compliance policy to accommodate the changes further. This will allow reporting within the tenant on what device compliance level the endpoints are on and whether corporate governance is maintained.

    Create Antivirus Policy in Intune

    The next step is creating the Antivirus (AV) Policy with the options that your organization demands. I am starting with a few, but remember most choices will require nailing out with internal security/endpoint/governance teams.

    Below configurations are not an exhaustive list – Consult with the endpoint/security teams to meet the organization’s requirements.

    Sign in to the Microsoft Endpoint Manager admin center.

    • For Platform, select Windows 10, Windows 11, and Windows Servers.
    • For Profile type, select Microsoft Defender Antivirus, and then select Create.
    • Enter a Name – W365-AVD-AV-P01 and description and choose Next
    • Under the Configuration Settings
    Configuration SettingsStatus (Value)
    Allow Archive Scanning (Scanning through zip and cab files)Allowed
    Allow Behaviour Monitoring Allowed
    Allow Cloud Protection (Joining Microsoft MAPS Community)Allowed
    Allow Email Scanning (Very useful if you are using Microsoft 365)Allowed
    Allow Full Scan Removable Drive Scanning (Scanning of Pen Drives)Allowed
    Allow Intrusion Prevention SystemAllowed
    Allow scanning of all downloaded files and attachmentsAllowed
    Allow Realtime MonitoringAllowed
    Cloud Block LevelHigh
    Allow Users UI Access (Defender Client)Allowed
    Enable Network ProtectionEnabled (Audit mode)
    Avg CPU Load Factor Enabled (30%)
    Schedule Quick Scan TimeEnable (120)
    Signature Update IntervalEnable (8 hours)
    • Next, the most critical part is the target assignments. I am explicitly creating this policy to target Windows 365 Cloud PC and Azure Virtual Desktop
    • Review and Create the policy and it will go ahead and enable AV across the fleet.
    • After sometime all your devices will show whether they are onboarded or not.

    Create Attack surface reduction (ASR) Policy in Intune

    The attack surface reduction set of capabilities provide the first line of defense in the stack. By ensuring configuration settings are properly set and exploit mitigation techniques are applied, these set of capabilities resist attacks and exploitation. This set of capabilities also includes network protection and web protection, which regulate access to malicious IP addresses, domains, and URLs. In my case I am starting with few, but remember most of the options will require nailing out with internal security/endpoint/governeance teams.

    Below configurations are not an exhaustive list – Consult with the endpoint/security teams to meet the organization’s requirements. Here I would like to take the approach of Audit mode first, followed by adding exclusions to refine the block rules (production).

    Sign in to the Microsoft Endpoint Manager admin center.

    • For Platform, select Windows 10, Windows 11, and Windows Servers.
    • For Profile type, select Attack Surface Reduction Rules, and then select Create.
    • Enter a Name – W365-AVD-ASR-P01 and description and choose Next
    • Under the Configuration Settings
    Configuration SettingsStatus (Value)
    Block Adobe Reader from creating child processesAudit
    Block execution of potentially obfuscated scriptsAudit
    Block Win32 API calls from office macrosAudit
    Block credential stealing from the Windows local security authority subsystemAudit
    Block JavaScript or VBScript from launching downloaded executable contentAudit
    Block process creatons originating from PSExec and WMI commandsAudit
    Block untrusted and unsigned processes that run from USBAudit
    Block abuse of exploited vulnerable signed drivers (Devices)Audit
    • Next, the most critical part is the target assignments. I am explicitly creating this policy to target Windows 365 Cloud PC and Azure Virtual Desktop
    • Review and Create the policy and it will go ahead and enable ASR across the fleet.
    • After sometime all your devices will show whether they are onboarded or not.
    Useful LinksCredits
    Microsoft Defender for Endpoint series – Tips and tricks/ common mistakes – Part10 (jeffreyappel.nl) – The most mind blowing and detailed blog post series on MDE. I think I only scratch the surface here however, Jeffrey takes an indept approach.Jeffrey Appel
    Configure Microsoft Defender for Endpoint in IntuneMicrosoft
    Defend Cloud PCs against threats with Microsoft Defender for Endpoint | Windows in the Cloud – YouTubeChristiaan Brinkhoff | LinkedIn and Paul Huijbregts | LinkedIn

    Next step, I plan to write a few blog posts on specific topics like URLs, Networks etc, blocking (TikTok, Facebook etc,) concerning MDE. I hope you will find this helpful information towards your journey to secure your Windows 365 and AVD environments using Microsoft Defender for Endpoint. Please let me know if I have missed any steps or details, and I will be happy to update the post.

    Thanks,
    Aresh Sarkari

    Remove built-in (default) Windows applications from the Windows 365 Cloud PC endpoints

    8 Feb

    Numerous scripts and vendor optimizers (VMware, Citrix and Microsoft) remove the default pre-installed Windows applications that come within the operating system, aka bloatware. You can get rid of all unnecessary applications using the Microsoft Store app (new) within Microsoft Intune.

    I attended the Microsoft 365 Modern Management Meetup, and our very own Steven Hosking demonstrated the uninstall of default applications via Intune. I got inspired and thought about blogging and socializing this trick with everyone.

    For my Windows 365 Cloud PC endpoint, I use the Azure image Gallery – Windows 11 22H2 + Cloud PC Optimized image, and for this example, we will uninstall Xbox pre-installed application.

    Fetch the Application ID (MS Store)

    In specific scenarios, when you try to search the application with the repository, it will not show, and the alternate method is to search via the ID.

    Application Removal Steps (Intune Portal)

    Here we will look at all the detailed steps involved in removing the applications from the operating system and Windows endpoints:

    • Under Application Information, click on Select App and in my case, I will enter the Application ID I copied in the previous step.
    • Make sure all the application details that it has fetched (auto-populated) look good, and select Next
    • The critical step on the Assignments as we are going to Uninstall it from the environment, we will select Un-install and specify the device group, in this case, Windows 365 Cloud (AAD – Dynamic Device Group)

    It is adviced you also leverage Filtering for targeting specifc device types within the environment.

    • Last step review and Create the Uninstall of the default Application

    Rinse & Repeat for other applications

    Using the above method, you can add other applications of your choice. Note the effort is one-time, so put it in and reap the benefits for all future versions of Windows.

    Advantages of using Intune for Default App Removal

    Lets take a look at the advantages of using this method:

    • There is no need of using 3rd party scripts posted by unknown sources.
    • You will still have to use the vendor optimizers for other things but you can setup these once within the Intune Portal and it will works for the current and future version of Windows.
    • The Intune method is not very socialized on removing bloatware from the default operating system.

    I hope you will find this helpful information for removal of default applications from the Intune Portal. Please let me know if I have missed any steps or details, and I will be happy to update the post.

    Thanks,
    Aresh Sarkari