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.
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.
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.
Are you looking to keep a vigilant eye on your Windows 365 environment? Good news! You can now send Windows 365 audit events to Azure Log Analytics, Splunk, or any other SIEM system that supports it.
Understanding the Scope of Windows 365 Audit Logs
When it comes to monitoring your Cloud PC environment, Windows 365 audit logs are an indispensable resource. These logs provide a comprehensive chronicle of significant activities that result in modifications within your Cloud PC setup (https://intune.microsoft.com/). Here’s what gets captured:
Creation Events: Every time a Cloud PC is provisioned, it’s meticulously logged.
Update Events: Any alterations or configurations changes made to an existing Cloud PC are recorded.
Deletion Events: If a Cloud PC is decommissioned, this action is also captured in the logs.
Assignment Events: The process of assigning Cloud PCs to users doesn’t go unnoticed; it’s all in the logs.
Remote Actions: Activities such as remote sign-outs or restarts are tracked for administrative oversight.
These audit events encompass most actions executed via the Microsoft Graph API, ensuring that administrators have visibility into the operations that affect their Cloud PC infrastructure. It’s important to note that audit logging is an always-on feature for Windows 365 customers. This means that from the moment you start using Cloud PCs, every eligible action is automatically logged without any additional configuration.
Windows 365 and Azure Log Analytics
Windows 365 has made it easier than ever to integrate with Azure Log Analytics. With a few simple PowerShell commands, you can create a diagnostic setting to send your logs directly to your Azure Log Analytics workspace.
Sign in to the Microsoft Intune admin center, select Reports > Diagnostic settings (under Azure monitor)> Add Diagnostic settings.
Under Logs, select Windows365AuditLogs.
Under Destination details, select the Azure Log Analytics and choose the Subscription & Workspace.
Select Save.
Query the Azure Log Analytics
Once your logs are safely stored in Azure Log Analytics, retrieving them is a breeze. You can use Kusto Query Language (KQL) to extract and analyze the data. Here’s a basic example of how you might query the logs:
Leverage Graph API to retrieve Windows 365 audit events
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.
Integrating Windows 365 with Azure Log Analytics is a smart move for any organization looking to bolster its security and compliance posture. With the added flexibility of forwarding to multiple endpoints, you’re well-equipped to handle whatever audit challenges come your way.
I hope you will find this helpful information for enabling and quering Windows 365 Audit Logs in Azure Logs Analytics or using Graph API with PowerShell. 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.
Suppose you’ve ever had to search for a particular or a list of GPO settings across a large number of Group Policy Objects (GPOs) within your domain. In that case, you know how tedious it can be to find specific settings across hundreds or thousands of GPOs. PowerShell comes to the rescue with a powerful script that can search for GPO settings across all your existing GPOs and generate an organized CSV output. In this blog post, we’ll walk you through the process and ensure you have all the prerequisites to get started.
Usecase
You have approx. 50 to 60 GPO settings from the Center of Internet Security (CIS) benchmark policies document (CIS Microsoft Windows Desktop Benchmarks/CIS Microsoft Windows Server Benchmarks), which you may want to search against your domain, whether they are already preconfigured\existing available within a GPO or not present in the environment. Instead of searching manually one by one, you may want to use the below PowerShell to get results like a champion.
Prerequisites
Before using the PowerShell script, ensure you have the following prerequisites in place:
Windows PowerShell version 5.0 and above
Active Directory Module for Windows PowerShell
Permissions: Ensure you have sufficient permissions to access and analyze GPO settings. Typically, you need to be a member of the Domain Administrators group or have equivalent privileges.
Execute the script from a member server that is part of the domain and has the necessary permissions.
Prepare the input file (inputgpo.txt) and enter the GPO setting one per line and save the file. In my situation, it’s present in C:\Temp
Relax minimum password length limits
Allow Administrator account lockout
Generate security audits
Impersonate a client after authentication
Lock pages in memory
Replace a process level token
Accounts: Block Microsoft accounts
Interactive logon: Machine inactivity limit
Microsoft network server: Server SPN target name validation level
Network access: Remotely accessible registry paths
Network security: Configure encryption types allowed for Kerberos
Audit Security State Change
Do not allow password expiration time longer than required by policy
Password Settings: Password Complexity
Password Settings: Password Length
Password Settings: Password Age (Days)
#Domain
$DomainName = "askaresh.com"
# Initialize matchlist
$matchlist = @()
# Collect all GPOs
$GPOs = Get-GPO -All -Domain $DomainName
# Read search strings from text file
# A list of GPOs settings you want to search
$SearchStrings = Get-Content -Path "C:\Temp\inputgpo.txt"
# Hunt through each GPO XML for each search string
foreach ($searchString in $SearchStrings) {
$found = $false
foreach ($gpo in $GPOs) {
$GPOReport = Get-GPOReport -Guid $gpo.Id -ReportType Xml
if ($GPOReport -match $searchString) {
$match = New-Object PSObject -Property @{
"SearchString" = $searchString
"GPOName" = $gpo.DisplayName
}
$matchlist += $match
$found = $true
}
}
if (-not $found) {
$match = New-Object PSObject -Property @{
"SearchString" = $searchString
"GPOName" = "No results found"
}
$matchlist += $match
}
}
# Output results to CSV, Search results
# This step will take time depending how many 100's or 1000's policies present in the enviornment
$matchlist | Export-Csv -Path "C:\Temp\gposearch.csv" -NoTypeInformation
Output (Results)
The ouput will look like the following within CSV:
I hope you will find this helpful information for searching GPO settings across 100’s and 1000’s of GPOs within your domain. Please let me know if I have missed any steps or details, and I will be happy to update the post.
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.
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.
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.
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.
Microsoft Security Response Center (MSRC) publishes a monthly consolidated report for all the Critical, Important, Moderate and Low security vulnerabilities affecting Microsoft products. The information posted there helps organizations manage security risks and keep their systems protected.
Looking at the overall release notes for all the affected products (30+ products) and filtering the OS you are interested in can become overwhelming. E.g. You are only interested in products Operating Systems – Windows 11 22h2 or Windows Server 2016/2019/2022. Not saying other information is not essential, but imagine you are only responsible for the Operating Sytems. In such situations, you can use the below script to get a monthly report of CVE (Critical & Important) for a particular OS over to you in an email.
Prerequsites
You will need the MSRCSecurity PowerShell module. Run the command to install the module; further, you can import the module within the script.
Following are the Operating System (OS) products you can fetch the information against. If you want details for any other operating systems, copy that value and, in my script, paste it under the variable $ClientOS_Type. In my demonstration, we used “Windows 11 Version 22H2 for x64-based Systems”
$ID = Get-MsrcCvrfDocument -ID $Month
$ID.ProductTree.FullProductName
ProductID Value
--------- -----
10049 Windows Server 2008 R2 for x64-based Systems Service Pack 1 (Server Core installation)
10051 Windows Server 2008 R2 for x64-based Systems Service Pack 1
10287 Windows Server 2008 for 32-bit Systems Service Pack 2 (Server Core installation)
10378 Windows Server 2012
10379 Windows Server 2012 (Server Core installation)
10407 Microsoft Outlook 2013 RT Service Pack 1
10483 Windows Server 2012 R2
10543 Windows Server 2012 R2 (Server Core installation)
10601 Microsoft Office 2013 Service Pack 1 (32-bit editions)
10602 Microsoft Office 2013 Service Pack 1 (64-bit editions)
10603 Microsoft Office 2013 RT Service Pack 1
10611 Microsoft Office Web Apps Server 2013 Service Pack 1
10612 Microsoft SharePoint Foundation 2013 Service Pack 1
10654 Microsoft Excel 2013 Service Pack 1 (32-bit editions)
10655 Microsoft Excel 2013 Service Pack 1 (64-bit editions)
10656 Microsoft Excel 2013 RT Service Pack 1
10729 Windows 10 for 32-bit Systems
10735 Windows 10 for x64-based Systems
10739 Microsoft Excel 2016 (32-bit edition)
10740 Microsoft Excel 2016 (64-bit edition)
10753 Microsoft Office 2016 (32-bit edition)
10754 Microsoft Office 2016 (64-bit edition)
10765 Microsoft Outlook 2016 (32-bit edition)
10766 Microsoft Outlook 2016 (64-bit edition)
10810 Microsoft Outlook 2013 Service Pack 1 (32-bit editions)
10811 Microsoft Outlook 2013 Service Pack 1 (64-bit editions)
10816 Windows Server 2016
10852 Windows 10 Version 1607 for 32-bit Systems
10853 Windows 10 Version 1607 for x64-based Systems
10855 Windows Server 2016 (Server Core installation)
10950 Microsoft SharePoint Enterprise Server 2016
11099 Microsoft SharePoint Enterprise Server 2013 Service Pack 1
11568 Windows 10 Version 1809 for 32-bit Systems
11569 Windows 10 Version 1809 for x64-based Systems
11570 Windows 10 Version 1809 for ARM64-based Systems
11571 Windows Server 2019
11572 Windows Server 2019 (Server Core installation)
11573 Microsoft Office 2019 for 32-bit editions
11574 Microsoft Office 2019 for 64-bit editions
11575 Microsoft Office 2019 for Mac
11585 Microsoft SharePoint Server 2019
11600 Microsoft Visual Studio 2017 version 15.9 (includes 15.0 - 15.8)
11605 Microsoft Office Online Server
11655 Microsoft Edge (Chromium-based)
11664 Microsoft Dynamics 365 (on-premises) version 9.0
11726 OneDrive for Android
11762 Microsoft 365 Apps for Enterprise for 32-bit Systems
11763 Microsoft 365 Apps for Enterprise for 64-bit Systems
11800 Windows 10 Version 20H2 for x64-based Systems
11801 Windows 10 Version 20H2 for 32-bit Systems
11802 Windows 10 Version 20H2 for ARM64-based Systems
11902 Microsoft Malware Protection Engine
11921 Microsoft Dynamics 365 (on-premises) version 9.1
11923 Windows Server 2022
11924 Windows Server 2022 (Server Core installation)
11926 Windows 11 version 21H2 for x64-based Systems
11927 Windows 11 version 21H2 for ARM64-based Systems
11929 Windows 10 Version 21H2 for 32-bit Systems
11930 Windows 10 Version 21H2 for ARM64-based Systems
11931 Windows 10 Version 21H2 for x64-based Systems
11935 Microsoft Visual Studio 2019 version 16.11 (includes 16.0 - 16.10)
11951 Microsoft Office LTSC for Mac 2021
11952 Microsoft Office LTSC 2021 for 64-bit editions
11953 Microsoft Office LTSC 2021 for 32-bit editions
11961 Microsoft SharePoint Server Subscription Edition
11969 Microsoft Visual Studio 2022 version 17.0
11987 Azure HDInsights
12051 Microsoft Visual Studio 2022 version 17.2
12085 Windows 11 Version 22H2 for ARM64-based Systems
12086 Windows 11 Version 22H2 for x64-based Systems
12097 Windows 10 Version 22H2 for x64-based Systems
12098 Windows 10 Version 22H2 for ARM64-based Systems
12099 Windows 10 Version 22H2 for 32-bit Systems
12129 Microsoft Visual Studio 2022 version 17.4
12137 CBL Mariner 1.0 x64
12138 CBL Mariner 1.0 ARM
12139 CBL Mariner 2.0 x64
12140 CBL Mariner 2.0 ARM
12142 Microsoft Edge (Chromium-based) Extended Stable
12155 Microsoft Office for Android
12156 Microsoft Office for Universal
12167 Microsoft Visual Studio 2022 version 17.5
12169 OneDrive for MacOS Installer
12170 OneDrive for iOS
12171 Azure Service Fabric 9.1 for Windows
12172 Azure Service Fabric 9.1 for Ubuntu
12173 Snipping Tool
12174 Snip & Sketch for Windows 10
9312 Windows Server 2008 for 32-bit Systems Service Pack 2
9318 Windows Server 2008 for x64-based Systems Service Pack 2
9344 Windows Server 2008 for x64-based Systems Service Pack 2 (Server Core installation)
Variable Region
Delcare all the variable within this section. Lets take a look at what we are declaring within the script:
The MSRC website releases the montly report in the following yyyy-MM format
#Month Format for MSRC
$Month = Get-Date -Format 'yyyy-MMM'
The operating system we want to focus on and leave the rest. If you are interested in any other OS, change the value from the above prerequisites, and it will give you Critical/Import vulnerabilities for that OS or product.
# Enter the Operating System you specifically want to focus on
$ClientOS_Type = "Windows 11 Version 22H2 for x64-based Systems"
Enter the details for sending the email (subject line, to and from etc.) for the report
#Email Details
$Recipients = "askaresh@askaresh.com", "someone@askaresh.com"
$Sender = "cve-report@askaresh.com"
$SMTP_Server = "smtp.askaresh.com"
$Subject = 'CVE List for Windows 11 22H2 on '+$Month
HTML report formatting (CSS, Title of the report, Logo and Header) information
I hope you will find this helpful information to gather Microsoft Security vulnerability reports for a specific operating system using PowerShell. Please let me know if I have missed any steps or details, and I will be happy to update the post.
Recent Comments