Cloud PC Provisioning Now Sets PowerShell to RemoteSigned

Windows 365 now sets the machine-scope execution policy to RemoteSigned during provisioning. Good for security — but if you enforce AllSigned via Intune or GPO, provisioning can fail, and here's why.

What's new — a short, independent summary. Read Microsoft's original: Microsoft Learn →

This one’s filed under “security improvement that will generate a support ticket.” Windows 365 now sets the PowerShell execution policy to RemoteSigned at LocalMachine scope during Cloud PC provisioning. Mostly you’ll never notice. If you enforce AllSigned, you very much will.

What it does

During provisioning, the machine-scope execution policy is set to RemoteSigned: downloaded scripts must be digitally signed to run, while locally created scripts and Custom Script Extension (CSE) scripts run without a signature. It’s a reasonable hardening default — it stops an unsigned script that wandered in from the internet from executing, without breaking the local provisioning machinery.

Where it bites

Here’s the trap. If your organisation enforces AllSigned through Intune or Group Policy, that’s stricter than RemoteSigned — it demands every script be signed, including the locally-created and CSE scripts that provisioning relies on. Those scripts aren’t signed, so under an AllSigned regime, provisioning and other CSE-based operations can fail. The symptom is a Cloud PC that won’t come up cleanly, and the cause is a policy you set months ago for entirely good reasons somewhere else.

What to check

If you enforce AllSigned anywhere that could apply to Cloud PCs, that’s your prime suspect for provisioning failures after this change. The fix is reconciling your signing policy with what provisioning needs — either scoping AllSigned away from the provisioning path or accepting RemoteSigned for those machines.

Source: Microsoft Learn. Summarised independently — check the source for the latest detail.