Windows Sandbox for IT admins: test apps and suspicious files in a throwaway Windows

Every IT team has the same two jobs on repeat: "will this installer work?" and "is this file safe to open?". Windows Sandbox answers both without a test VM. It starts a fresh copy of Windows in seconds, and when you close it, everything inside is gone.

To build a config file without writing XML by hand, use the free Windows Sandbox config builder.

What it is

Microsoft describes it as "a lightweight desktop environment to safely run applications in isolation." In practice that means:

• Pristine: "Every time Windows Sandbox runs, it's as clean as a brand-new installation of Windows."
• Disposable: "Nothing persists on the device. Everything is discarded when the user closes the application."
• Isolated: it uses the Microsoft hypervisor to run a separate kernel, so it's kept apart from your real Windows.
• Built in: there's no VHD to download. It uses the copy of Windows already on the device.

Requirements

Turn it on

Open Turn Windows features on or off, tick Windows Sandbox and restart. Or, from an elevated PowerShell prompt:

Enable-WindowsOptionalFeature -FeatureName "Containers-DisposableClientVM" -All -Online

If the option is greyed out, the device doesn't meet the requirements. Inside a Hyper-V VM you need nested virtualisation first. Run this on the Hyper-V host while the VM is off:

1
2Set-VMProcessor -VMName "contoso-test01" -ExposeVirtualizationExtensions $true
Update-VMVersion -VMName "contoso-test01"

Config files: the bit most people miss

Started from the Start menu, Sandbox runs with its defaults, and those defaults are generous: networking, the GPU, clipboard and microphone are all on. A .wsb file is a small XML file that changes that. Double-click it and Sandbox starts with your settings.

Two things to know about mapped folders. The host folder must already exist, or the sandbox won't start. And Microsoft is clear that a writable folder is a way out: "Changes made during a Sandbox session to a mapped folder with write permissions persist after the sandbox is disposed." Map folders read-only unless you need the output back.

Three configs worth keeping

Open a file you don't trust

This is based on Microsoft's own sample. There's no network and no GPU, the downloads folder is mapped read-only, and Explorer opens it when the sandbox starts. Clipboard is off and Protected Client is on, for extra isolation.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17<Configuration>
  <vGPU>Disable</vGPU>
  <Networking>Disable</Networking>
  <ClipboardRedirection>Disable</ClipboardRedirection>
  <AudioInput>Disable</AudioInput>
  <ProtectedClient>Enable</ProtectedClient>
  <MappedFolders>
    <MappedFolder>
      <HostFolder>C:\Users\Public\Downloads</HostFolder>
      <SandboxFolder>C:\temp</SandboxFolder>
      <ReadOnly>true</ReadOnly>
    </MappedFolder>
  </MappedFolders>
  <LogonCommand>
    <Command>explorer.exe C:\temp</Command>
  </LogonCommand>
</Configuration>

Sandbox isolates the file from your PC. It doesn't tell you what the file did. For that, you still need your security tools, or a proper malware analysis service.

Test an Intune app before you deploy it

Map your packaging folder read-only, and a second, writable folder for the install log, then run the silent install at sign-in. If the install command works here on a clean Windows, it's far more likely to work through Intune.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18<Configuration>
  <MemoryInMB>4096</MemoryInMB>
  <MappedFolders>
    <MappedFolder>
      <HostFolder>C:\Packaging\ContosoAgent</HostFolder>
      <SandboxFolder>C:\Package</SandboxFolder>
      <ReadOnly>true</ReadOnly>
    </MappedFolder>
    <MappedFolder>
      <HostFolder>C:\Packaging\Logs</HostFolder>
      <SandboxFolder>C:\Logs</SandboxFolder>
      <ReadOnly>false</ReadOnly>
    </MappedFolder>
  </MappedFolders>
  <LogonCommand>
    <Command>msiexec /i C:\Package\ContosoAgent.msi /qn /norestart /l*v C:\Logs\ContosoAgent-install.log</Command>
  </LogonCommand>
</Configuration>

One difference to remember: Intune installs Win32 apps as SYSTEM, but the logon command runs as the sandbox user, WDAGUtilityAccount. On Windows 11 24H2 you can close that gap with wsb exec -r System, covered next. The Win32 app command builder gives you the install, uninstall and detection rule to test.

A clean browser for one task

Keep networking on, and turn everything else off: clipboard, microphone, webcam and printers. It's useful for opening a link from a support ticket, or checking a site as a brand-new user with no cookies or saved sign-ins.

The wsb command line (Windows 11 24H2)

From Windows 11 version 24H2, Sandbox has a command line, wsb, so you can script it instead of clicking:

Put together, you can test an installer as SYSTEM, the same way Intune runs it, and check the exit code:

1
2
3
4
5
6wsb start                                   # returns the new sandbox's ID
$id = "12345678-1234-1234-1234-1234567890AB"  # paste the ID here
wsb share --id $id -f C:\Packaging\ContosoAgent -s C:\Package
wsb connect --id $id
wsb exec --id $id -c "msiexec /i C:\Package\ContosoAgent.msi /qn /norestart" -r System
wsb stop --id $id

Two things from Microsoft's documentation to plan around. exec returns the exit code but not the command's output, so write a log to a shared folder if you need detail. And exec needs an active user session in the sandbox, which is why wsb connect comes first. Add --raw to any command to get its output as JSON.

Control it across your devices

If Sandbox is enabled on a device, its defaults apply unless you set policy. The WindowsSandbox policy CSP lets you lock those settings down from Intune with a custom OMA-URI profile. Every policy defaults to allowed (1), and setting it to 0 blocks it:

The OMA-URIs start with ./Device/Vendor/MSFT/Policy/Config/WindowsSandbox/. The same settings are in Group Policy under Computer Configuration > Administrative Templates > Windows Components > Windows Sandbox. For the six older policies, Microsoft notes Windows Sandbox must be restarted before a change takes effect.

A sensible baseline for most users is networking allowed, but clipboard, printer, microphone and webcam blocked, and mapped folders read-only. Keep the full set for the people who test apps.

Checklist

• Check your devices are Pro, Enterprise or Education. Home can't run Sandbox.
• Turn it on for your IT team and app packagers, with PowerShell or a remediation script.
• Keep a locked-down .wsb file for files you don't trust: no network, no GPU, no clipboard, read-only folders.
• Test new Win32 apps in a sandbox before they go anywhere near Intune, ideally as SYSTEM with wsb exec.
• Set the WindowsSandbox policies, so the defaults aren't the only thing standing between a test and your network.