Windows 365 Adds Bulk Deprovisioning and PowerShell Security Hardening — What IT Admins Need to Know

Managing Cloud PC lifecycles at scale has always been a balancing act between operational efficiency and security. You want to deprovision departed users’ Cloud PCs quickly to free licenses and reduce attack surface, but doing it one device at a time is tedious. You want strong PowerShell security defaults on newly provisioned Cloud PCs, but if your organization’s GPO settings conflict with Microsoft’s defaults, provisioning itself can break.

This week’s Windows 365 update, announced for the week of July 27, 2026, tackles both challenges head-on with two new features:

1. Bulk deprovision for Cloud PCs in grace period (Public Preview)
2. PowerShell execution policy hardening for Cloud PC provisioning

Let’s break down what each feature does, why it matters, and how to prepare your environment — including the critical PowerShell policy conflict that could cause provisioning failures.

1. Bulk Deprovision for Cloud PCs in Grace Period (Public Preview)

The Problem It Solves

When a user’s Windows 365 license is removed or they’re taken out of a provisioning group, their Cloud PC enters a 7-day grace period. During this window, the Cloud PC still exists and — importantly — still counts against your active Cloud PC license usage. Admins could end the grace period early to deprovision the Cloud PC immediately, but only one at a time.

For small environments, that’s a minor annoyance. For organizations managing hundreds or thousands of Cloud PCs — especially during seasonal workforce changes, layoffs, or organizational restructuring — the one-at-a-time approach becomes a significant operational bottleneck. An admin spending hours clicking through individual Cloud PCs to end grace periods is time that could be spent on almost anything else.

What’s New

The new bulk deprovision capability (currently in Public Preview) allows administrators to:

• Select multiple Cloud PCs that are already in grace period
• End their grace periods in bulk, deprovisioning them simultaneously
• Available for Windows 365 Enterprise and Windows 365 Frontline Dedicated

This is a straightforward but impactful operational improvement. Instead of waiting seven days for grace periods to expire naturally or ending them device by device, admins can now clean up Cloud PCs in batches.

Why It Matters

License reclamation speed. Since grace-period Cloud PCs consume licenses, bulk deprovisioning lets you free up those licenses immediately for reassignment. In environments with license constraints or during mass offboarding events, this can mean the difference between having licenses available for new hires and hitting capacity walls.

Security hygiene. The faster a departed user’s Cloud PC is deprovisioned, the smaller the window for unauthorized access. While sign-in access is typically removed when a license is unassigned, the Cloud PC’s continued existence — with its data, configuration, and any cached credentials — represents unnecessary risk during the grace period.

Operational scale. Bulk operations are essential for large environments. This feature brings Cloud PC deprovisioning in line with other bulk device management capabilities already available in Intune.

Caveats and Considerations

• Irreversible. Once a grace period is ended and the Cloud PC is deprovisioned, the VM and its local state are deleted. If you need to preserve data — for legal hold, investigation, or rollback — create restore points before bulk deprovisioning. Microsoft supports bulk creation of restore points for up to 5,000 Cloud PCs stored in Azure storage.
• Preview status. As a Public Preview feature, expect potential UI changes, tenant/SKU limitations, and minor behavior differences before GA.
• Grace period prerequisite. Bulk deprovision only applies to Cloud PCs already in grace period. It doesn’t bypass the normal license/group removal process that triggers grace period.

What IT Admins Should Do

1. Update offboarding runbooks. When a user is offboarded and their Cloud PC license is removed, tag their Cloud PC for bulk deprovision rather than handling it individually.
2. Create restore points first. For any Cloud PCs that might need data preservation, use bulk restore point creation before deprovisioning.
3. Monitor license usage. Regularly review the number of Cloud PCs in grace period and total active vs. available license counts — grace-period PCs consume licenses.
4. Implement approval workflows. Bulk destructive actions should require change tickets and approvals. Limit bulk deprovision permissions to dedicated roles.
5. Pilot first. Test with a small subset before applying to large populations.

2. PowerShell Execution Policy Hardening During Cloud PC Provisioning

The Problem It Solves

PowerShell is one of the most powerful tools in Windows administration — and one of the most common vectors for malware and post-exploitation activity. Historically, Cloud PC provisioning didn’t enforce a specific PowerShell execution policy, which meant newly provisioned Cloud PCs could inherit whatever policy was in the image, in the tenant configuration, or set by scripts running during provisioning. This inconsistency created security gaps and unpredictable behavior.

What’s New

Windows 365 now explicitly sets the PowerShell execution policy to RemoteSigned at the LocalMachine scope during Cloud PC provisioning. This applies to all Cloud PC products.

What RemoteSigned at LocalMachine means in practice:

• Locally created scripts can run without being digitally signed — including Custom Script Extension (CSE) scripts used during provisioning
• Downloaded scripts — anything fetched from the internet or remote locations — must be digitally signed by a trusted publisher to execute
• This provides a security baseline that blocks drive-by script downloads and unsigned remote automation while allowing legitimate local scripting

The Critical Caveat: AllSigned Conflicts

Here’s where IT admins need to pay close attention.

If your organization enforces the AllSigned PowerShell execution policy through Intune device configuration or Group Policy (GPO), Cloud PC provisioning can fail entirely.

The reason is scope precedence. Windows 365 sets RemoteSigned at LocalMachine, but a MachinePolicy or UserPolicy from GPO/Intune with AllSigned has higher precedence. When the provisioning process encounters this conflict — particularly if CSE-based scripts need to run and aren’t signed — the scripts fail, and provisioning can stall or fail completely.

This is not a theoretical risk. Organizations that enforce AllSigned as a security hardening measure (which is itself a valid and recommended practice for production environments) need to ensure their provisioning scripts are properly signed, or adjust policy application timing.

Why It Matters

Security improvement. RemoteSigned at LocalMachine is a meaningful security baseline. It prevents the most common PowerShell abuse pattern — downloading and running unsigned scripts from the internet — while not blocking legitimate local automation. This aligns with Microsoft’s broader security guidance for PowerShell in enterprise environments.

Standardization. Every newly provisioned Cloud PC now starts with the same predictable PowerShell execution policy, regardless of what’s in the image or how the tenant is configured. This makes provisioning behavior more consistent and troubleshooting easier.

Potential for provisioning failures. This is the flip side. If your organization’s security policies conflict with the new default, you could see provisioning failures that didn’t occur before — particularly if you rely on unsigned downloaded scripts during provisioning.

How to Check Your Current State

Before this change impacts your provisioning, check your effective execution policy:

# Check all execution policy scopes
Get-ExecutionPolicy -List

# Check the effective policy
Get-ExecutionPolicy

If you see AllSigned at MachinePolicy or UserPolicy scope, you’re at risk of provisioning failures.

What IT Admins Should Do

1. Inventory your provisioning scripts. Identify every PowerShell script that runs during or immediately after Cloud PC provisioning — Intune Win32 apps, CSE scripts, configuration scripts. Classify each as locally created vs. downloaded, and signed vs. unsigned.

2. Sign your remote scripts. If you have scripts downloaded from remote locations during provisioning, obtain a code-signing certificate from your PKI or a trusted CA and sign them. This is good practice regardless of this change.

3. Review your Intune/GPO PowerShell policies. If you enforce AllSigned at MachinePolicy or UserPolicy scope:

   • Consider delaying the policy application until after provisioning completes (e.g., target it at a “provisioned” device group rather than all devices)
   • Ensure all provisioning scripts are properly signed and the certificate is trusted by Cloud PCs
   • Test policy layering in a pilot group before broad rollout

4. Create a Cloud PC security baseline. Document the expected execution policy for Cloud PCs, including organizational overrides and their rationale. Make this part of your standard Cloud PC configuration documentation.

5. Monitor provisioning success rates. After this change rolls out, watch for any increase in provisioning failures. Check the Windows 365 known issues page for updates, and use Intune’s provisioning status reports to identify affected devices.

6. Train your team. Make sure admins and automation engineers know to check the effective execution policy when troubleshooting script failures on Cloud PCs. A quick Get-ExecutionPolicy -List should be part of every provisioning troubleshooting checklist.

The Combined Impact: Lifecycle Management Meets Security Hardening

These two updates address different sides of the same coin: managing Cloud PCs efficiently throughout their lifecycle while maintaining strong security defaults.

Consider a common scenario:

An organization offboards 50 contractors at the end of a project.

Before this update:

• Each contractor’s Cloud PC enters a 7-day grace period, consuming licenses the entire time
• An admin must end each grace period individually — 50 clicks through the Intune admin center
• Meanwhile, newly provisioned Cloud PCs for replacement contractors may inherit inconsistent PowerShell execution policies, depending on the image and tenant configuration

After this update:

• The admin selects all 50 grace-period Cloud PCs and deprovisions them in bulk, freeing licenses immediately
• Replacement contractors’ Cloud PCs are provisioned with RemoteSigned as the baseline PowerShell execution policy — consistent, secure, and predictable
• If the organization enforces AllSigned via GPO, the admin has already signed their provisioning scripts and staggered policy application to avoid conflicts

This is the kind of end-to-end lifecycle and security management that Microsoft has been building toward across Windows 365, Intune, and the broader Microsoft ecosystem. Bulk operations reduce administrative overhead. Security defaults reduce attack surface. Together, they make Cloud PC management more efficient and more secure.

Preparation Checklist

What’s Next

The bulk deprovision feature is in Public Preview and will likely reach general availability within a few months, based on Microsoft’s typical preview-to-GA cadence. Expect additional bulk lifecycle management capabilities to follow — bulk restore point creation is already available, and bulk deprovision is a natural companion.

For PowerShell execution policy hardening, this is a provisioning-time default that’s now in effect. Microsoft may expand security defaults further in future updates, so organizations with strict PowerShell policies should review and align their signing and deployment practices now rather than waiting for the next conflict to cause a provisioning failure.

Both features underscore Microsoft’s approach to Windows 365: building enterprise-grade management capabilities that work at scale, with security defaults that protect by design. For IT admins, the message is clear — bulk operations are here to stay, and security hardening is only going to get stricter. Prepare accordingly.

For more information, see the Windows 365 What’s New documentation, Deprovision or end grace period for Cloud PCs, Automated provisioning steps, and Windows 365 known issues.

Follow @kkaminski on X for daily Windows 365 updates and analysis.