Setting up a dev environment with VS Code & Windows Sandbox

by Jesper Nielsen • 18 minutes to read

If you’re writing PowerShell scripts for Microsoft Intune, you know that testing is everything. One wrong script deployed to thousands of devices can ruin your day - or your week. That’s why I’ve built my development workflow around Visual Studio Code and Windows Sandbox. This combination gives me a secure, isolated environment where I can break things without consequences, test scripts on a clean system, and validate that everything works before it hits production.

Development Environment with VS Code and Windows Sandbox

If you work with Microsoft Intune, you’ve likely encountered situations where script testing is critical:

Scenario 1: Deploying a Configuration Script. You’ve written a PowerShell script that modifies registry settings to configure a specific application for your organization. Before deploying it to thousands of devices through Intune, you need to verify it works correctly. Running it directly on your work machine could potentially misconfigure your own system or, worse, require a complete reinstall if something goes wrong.

Scenario 2: Testing Remediation Scripts. Microsoft Intune Remediations script allows you to detect and fix issues. You’re developing a detection script that checks for a specific condition and a remediation script that fixes it. Testing these scripts requires a clean environment where you can verify both the detection logic and the remediation action work as intended.

Scenario 3: Working with Sensitive Operations. Your script connects to Microsoft Graph API to modify user properties or device configurations in Entra ID. You want to test the authentication flow and API calls without risking your production environment or accidentally making changes with your primary admin account. Additionally, if you work as a consultant or in customer environments, using an isolated system like Windows Sandbox prevents credentials, tokens, and sensitive code from being stored on your device. This is crucial for maintaining security boundaries between different clients and ensuring no sensitive data persists after your session ends.

Scenario 4: Validating First-Run Experience. Many Intune scripts run during device enrollment or first user login. To accurately test these scenarios, you need an environment that simulates a fresh Windows installation - something your daily driver machine cannot provide.

These scenarios highlight a common challenge: you need a safe, repeatable environment to test scripts before they reach production. This is where the combination of Visual Studio Code and Windows Sandbox becomes invaluable.

In this post, I will walk you through my workflow for developing PowerShell scripts, including:

  • Installing and configuring Visual Studio Code with essential extensions.
  • How to enable and configure Windows Sandbox for script testing.
  • Setting up a workspace folder on the Desktop in Windows Sandbox for easy access.
  • Leveraging PSScriptAnalyzer for code validation and best practices.
  • Why avoiding PowerShell ISE is crucial for accurate testing and validation.

Let’s dive in and set up a development environment that will make your PowerShell scripting safer and more efficient.

Setting Up Visual Studio Code

Visual Studio Code is a lightweight but powerful source code editor that runs on your desktop. With the PowerShell extension, it becomes an excellent environment for developing and maintaining PowerShell scripts.

There are several ways to install Visual Studio Code:

Installing Visual Studio Code

To get started, install Visual Studio Code on your computer.

Installing via Official Installer

  1. Download the Installer - Visit the official website  and download the installer for Windows.
  2. Run the Installer - Execute the downloaded file and follow the installation wizard.
  3. Install PowerShell Extension - Open Visual Studio Code, go to the Extensions view (Ctrl+Shift+X), and search for the PowerShell extension by Microsoft. Install it to enable advanced scripting features.
  4. Configure Settings - Customize the Visual Studio Code settings for optimal PowerShell development. For example, set up linting, formatting, and debugging configurations specific to PowerShell.

Installing from Microsoft Store

Visual Studio Code is also available from the Microsoft Store, which offers some advantages:

  • Automatic Updates - The Store version updates automatically in the background
  • Simplified Installation - No need to download and run an installer
  • User Account Control - No administrator privileges required for installation

To install from the Microsoft Store:

  1. Open the Microsoft Store app on your Windows device
  2. Search for “Visual Studio Code”
  3. Click Install to download and install the application

Alternatively, you can open this link directly: Visual Studio Code on Microsoft Store .

Installing Visual Studio Code using Winget

Instead of manually downloading installers, you can use winget (Windows Package Manager) to quickly install Visual Studio Code and other development tools on your host system.

The following example demonstrates installing Visual Studio Code along with common companion tools for PowerShell development. Git enables version control integration, and PowerShell 7 provides the latest cross-platform PowerShell features:

Basic Installation Commands
:: Install Visual Studio Code
winget install --id Microsoft.VisualStudioCode --exact --silent --source winget

:: Install Git
winget install --id Git.Git --exact --silent --source winget

:: Install PowerShell 7 (optional, for cross-platform PowerShell)
winget install --id Microsoft.PowerShell --exact --silent --source winget

:: Add --accept-source-agreements and --accept-package-agreements to suppress prompts

Winget Commands to Install Dev Tools

Using Winget Configuration Files

For a more automated approach, you can create a winget configuration file (.winget) that installs all your preferred development tools in one go:

# Save as dev-environment.winget
properties:
  configurationVersion: 0.2.0
  resources:
    - resource: Microsoft.WinGet.DSC/WinGetPackage
      id: vscode
      directives:
        description: Install Visual Studio Code
        allowPrerelease: false
      settings:
        id: Microsoft.VisualStudioCode
        source: winget
    - resource: Microsoft.WinGet.DSC/WinGetPackage
      id: git
      directives:
        description: Install Git
        allowPrerelease: false
      settings:
        id: Git.Git
        source: winget
    - resource: Microsoft.WinGet.DSC/WinGetPackage
      id: pwsh
      directives:
        description: Install PowerShell 7
        allowPrerelease: false
      settings:
        id: Microsoft.PowerShell
        source: winget

Winget Configuration File for Dev Environment

Run the configuration file with:

# Apply the winget configuration
winget configure .\dev-environment.winget --accept-configuration-agreements

Applying Winget Configuration File

My Visual Studio Code Extensions

These are the preferred Visual Studio Code extensions I use in my development setup:

ExtensionPublisherDescription
GitHub Copilot ChatGitHubThe chat companion to Copilot. Great for explaining code, generating documentation, and troubleshooting.
GitHub CopilotGitHubAI-powered code completion. Honestly, it’s awesome - speeds up script writing significantly.
Insert GUIDHenrik SjökvistSimple but useful - generates GUIDs on demand. Handy when working with registry keys or Intune policies.
Learn MarkdownMicrosoftHelps with Markdown authoring, especially useful for documentation and README files.
PowerShellMicrosoftEssential for PowerShell development. Provides IntelliSense, debugging, and PSScriptAnalyzer integration.
XML ToolsJosh JohnsonXML formatting and validation. Essential when working with Windows Sandbox .wsb files and other XML configurations.
My Preferred Visual Studio Code Extensions

Setting Up Windows Sandbox

Windows Sandbox is one of those hidden gems in Windows that I wish more IT professionals knew about. It’s a lightweight, isolated desktop environment that lets you safely run applications and test scripts without any risk to your host system. Think of it as a throwaway virtual machine that launches in seconds, uses minimal resources, and completely resets itself every time you close it.

What makes Windows Sandbox particularly appealing is that it’s built right into Windows Pro, Enterprise, and Education editions - no additional software to install or VMs to maintain. It leverages the same hypervisor technology as Hyper-V to provide true kernel-level isolation, meaning anything running inside the sandbox is completely separated from your host machine. And when you’re done? Just close the window and everything disappears. No cleanup, no leftover files, no security concerns.

Here’s what I find most valuable about Windows Sandbox:

  • Zero maintenance: Unlike traditional VMs, there’s nothing to update or manage. It always starts fresh from the current Windows installation.
  • Instant availability: Launches in just a few seconds - perfect for quick testing scenarios.
  • Complete isolation: Uses hardware-based virtualization to ensure nothing escapes to the host system.
  • Resource efficient: Smart memory management and virtual GPU support keep it lightweight while still being functional.
  • Always clean: Every session starts as a pristine Windows installation, which is exactly what you need for reproducible testing.

Beyond PowerShell development, Windows Sandbox shines in many scenarios:

  • Software testing: Debug applications in a clean environment to identify compatibility issues without polluting your main system.
  • Secure browsing: Access unfamiliar or potentially risky websites without putting your host at risk of malware.
  • Opening untrusted files: Safely open suspicious email attachments or downloaded files before trusting them on your main machine.
  • Trying new software: Test drive applications, preview versions, or browser extensions without the install/uninstall dance on your host.

Activating Windows Sandbox

Getting started is surprisingly simple - it takes less than a minute to enable and requires just a single restart.

Prerequisites

Before you begin, there are a few requirements to check. Make sure your system meets these prerequisites:

  • Windows 10 Pro/Enterprise/Education or Windows 11 Pro/Enterprise/Education
  • AMD64 or ARM64 architecture
  • Virtualization capabilities enabled in BIOS/UEFI
  • At least 4 GB of RAM (8 GB recommended)
  • At least 1 GB of free disk space (SSD recommended)

Using the GUI (Windows Features)

You can enable Windows Sandbox through the Windows Features dialog:

  1. Press Win + R, type optionalfeatures.exe, and press Enter
  2. Scroll down and check Windows Sandbox
  3. Click OK and restart your computer when prompted

Using PowerShell

Alternatively, you can enable Windows Sandbox using PowerShell (run as Administrator):

# Enable Windows Sandbox feature
Enable-WindowsOptionalFeature -FeatureName "Containers-DisposableClientVM" -All -Online

# Restart is required after enabling
Restart-Computer

Using Command Prompt (DISM)

You can also use DISM from an elevated command prompt:

dism.exe /online /Enable-Feature /FeatureName:"Containers-DisposableClientVM" /All

Configuring Windows Sandbox

To use Windows Sandbox effectively, you need to configure it to load your script repository automatically as a mapped folder. This configuration is done using a Windows Sandbox configuration file (*.wsb).

Creating a Configuration File

A Windows Sandbox configuration file allows you to customize various aspects of the sandbox environment. Here’s how to create one:

  • Open a text editor (I prefer Visual Studio Code, but Notepad works too) and create a new file.
  • Save the file with a .wsb extension (e.g., MyDevSandbox.wsb).
  • Add the necessary XML configuration to map your script folder from the host to the sandbox.

Example Configuration File

Below is an example of a Windows Sandbox configuration file that maps a folder from your host system to the sandbox:

<Configuration>
  <MappedFolders>
    <MappedFolder>
      <HostFolder>C:\Path\To\Your\Scripts</HostFolder>
      <SandboxFolder>C:\Scripts</SandboxFolder>
      <ReadOnly>false</ReadOnly>
    </MappedFolder>
  </MappedFolders>
</Configuration>

Basic Windows Sandbox Configuration File

Using Relative Paths in Configuration

Here’s an example using a relative path that mounts the folder where the .wsb file resides:

<Configuration>
  <MappedFolders>
    <MappedFolder>
      <HostFolder>.\</HostFolder>
      <SandboxFolder>C:\Users\WDAGUtilityAccount\Desktop\Workspace</SandboxFolder>
      <ReadOnly>false</ReadOnly>
    </MappedFolder>
  </MappedFolders>
  <Networking>Enable</Networking>
</Configuration>

Windows Sandbox Configuration File with Relative Path

Simply place this .wsb file in your project folder and double-click it to launch Windows Sandbox with that folder automatically mounted to the Desktop.

Explanation of the Configuration

  • HostFolder: Specifies the folder on the host machine to share into the sandbox. The folder must already exist on the host, or the container fails to start. In this example, the host folder <current folder> is mapped to the sandbox folder C:\Users\WDAGUtilityAccount\Desktop\Workspace.
  • SandboxFolder: Specifies the destination in the sandbox to map the folder to. If the folder doesn’t exist, it gets created. If no sandbox folder is specified, the folder is mapped to the container user’s desktop, C:\Users\WDAGUtilityAccount\Desktop\<source folder>.
  • ReadOnly: If true, enforces read-only access to the shared folder from within the container. Supported values: true/false. Defaults to false.

Advanced Configuration Example

If you want to include multiple mapped folders, network access settings and specifies the amount of memory that the sandbox can use in megabytes, you can extend the configuration file:

<Configuration>
  <MappedFolders>
    <MappedFolder>
      <HostFolder>C:\Path\To\Your\Scripts</HostFolder>
      <SandboxFolder>C:\Scripts</SandboxFolder>
      <ReadOnly>false</ReadOnly>
    </MappedFolder>
    <MappedFolder>
      <HostFolder>C:\Path\To\Another\Folder</HostFolder>
      <SandboxFolder>C:\AnotherFolder</SandboxFolder>
      <ReadOnly>true</ReadOnly>
    </MappedFolder>
  </MappedFolders>
  <Networking>Enable</Networking>
  <MemoryInMB>4096</MemoryInMB>
</Configuration>

Advanced Windows Sandbox Configuration File

Explanation of Advanced Configuration Elements:

  • Configuration: The root element that wraps all sandbox configuration settings.
  • MappedFolders: Container for one or more <MappedFolder> entries. You can map multiple host folders to different locations in the sandbox.
  • MappedFolder: Defines a single folder mapping between host and sandbox.
    • HostFolder: The full path to the folder on your host machine. This folder must exist before launching the sandbox.
    • SandboxFolder: The path where the folder will appear inside the sandbox. If omitted, it maps to the desktop.
    • ReadOnly: When set to true, prevents the sandbox from modifying files in the mapped folder. Use false when you need to save changes back to the host.
  • Networking: Controls network access. Enable allows network access, Disable blocks all network traffic for maximum isolation.
  • MemoryInMB: Allocates a specific amount of RAM to the sandbox in megabytes. 4096 equals 4 GB. Increase this for memory-intensive scripts or testing.

Practical Use Cases

Windows Sandbox is not only a tool for isolation and security but also an excellent environment for developing and testing PowerShell scripts. Here’s how I use Windows Sandbox to enhance my scripting workflow:

Script Development: When creating and refining PowerShell scripts, I always use Windows Sandbox to test new code. This approach ensures that any mistakes or potentially harmful commands do not affect my primary system. The isolated environment allows me to experiment freely, leading to more robust and reliable scripts.

Reproducibility in Testing: Each time I launch Windows Sandbox, it creates a fresh instance of Windows. This feature is particularly valuable for testing scripts in a consistent environment. I can ensure that my scripts work as intended without any leftover artifacts from previous runs, leading to more predictable and reliable results.

Maintaining Azure, Entra ID, and Microsoft Intune: Windows Sandbox is my go-to environment for managing Azure resources, maintaining Entra ID configurations, and administering Microsoft Intune. By running my scripts and utilities within the sandbox, I can safely perform administrative tasks and push updates, confident that my primary system remains unaffected by any potential errors or security threats.

Combining Visual Studio Code and Windows Sandbox

Now that you have Visual Studio Code set up on your host and Windows Sandbox configured, let’s look at how these tools work together for an optimal development workflow.

The synergistic use of Visual Studio Code and Windows Sandbox offers several benefits for PowerShell script development:

  • Enhanced Security: By developing and testing scripts within Windows Sandbox, you mitigate the risk of accidental damage or malicious code affecting your primary system.
  • Consistent Environment: Each instance of Windows Sandbox provides a clean slate, ensuring that your development environment remains consistent and uncontaminated.
  • Seamless Integration: Visual Studio Code’s powerful features, including IntelliSense, debugging, and Git integration, enhance productivity and code quality.

My Preferred Workflow: Edit Outside, Test Inside

Key Insight: You don’t need to install Visual Studio Code or Git inside Windows Sandbox. By mapping your workspace folder to the sandbox, you can edit files in Visual Studio Code on your host system while using Windows Sandbox purely for validation and testing. This approach offers significant advantages:

  • Faster startup. No waiting for applications to install when the sandbox launches
  • Clean testing environment. The sandbox remains a pristine environment for script validation
  • Real-time editing. Changes made in Visual Studio Code on your host are immediately available in the sandbox
  • Separation of concerns. Development tools stay on the host; the sandbox is solely for execution testing

This workflow mirrors how scripts will actually run in production environments like Microsoft Intune, where only PowerShell is available - no IDE, no extensions, just the raw script execution.

Best Practices for PowerShell Script Development

It is crucial to adopt certain best practices when developing PowerShell scripts for Microsoft Intune.

Use PSScriptAnalyzer for Real-Time Validation

When you install the PowerShell extension in Visual Studio Code, PSScriptAnalyzer is automatically included. This static analysis tool checks your code against PowerShell best practices as you type, highlighting issues with squiggly underlines and displaying them in the Problems panel (Ctrl+Shift+M).

As you code, PSScriptAnalyzer will catch common issues like using cmdlet aliases instead of full names, detecting unused variables, warning about plain text passwords, ensuring state-changing functions support -WhatIf, and flagging security risks like Invoke-Expression. Many issues include quick fixes you can apply with a single click.

For a complete list of rules, see the PSScriptAnalyzer documentation .

Avoid Using PowerShell ISE

This is critical for testing and validation scenarios. It is advisable to never use PowerShell ISE for developing or testing scripts intended for Microsoft Intune deployment. Here’s why:

Why PowerShell ISE is Problematic for Testing

Deprecated and Unsupported: PowerShell ISE is no longer being actively developed. Microsoft has shifted focus to Visual Studio Code as the recommended editor for PowerShell development. ISE does not support PowerShell 7+ and lacks modern features.

Different Execution Environment: PowerShell ISE runs scripts in a way that differs from how they execute in production environments like Microsoft Intune. Scripts may work perfectly in ISE but fail when deployed through Intune because:

  • PowerShell ISE maintains a persistent runspace where variables and modules persist between executions
  • PowerShell ISE loads additional assemblies and modules by default
  • PowerShell ISE handles execution policy differently

Interestingly, the reverse is also common: scripts that fail in PowerShell ISE may work perfectly in production. PowerShell ISE’s unique environment can cause false negatives where valid scripts appear broken due to PowerShell ISE-specific quirks, module loading issues, or assembly conflicts that don’t exist in a clean PowerShell session.

The Right Approach for Testing

Instead of PowerShell ISE, use this workflow:

  1. Develop in Visual Studio Code with the PowerShell extension for real-time validation
  2. Test in Windows Sandbox using a fresh PowerShell console (not ISE)
  3. Run scripts using powershell.exe or pwsh.exe directly to simulate Intune execution
  4. Use PSScriptAnalyzer to catch potential issues before deployment
# Test script execution as Microsoft Intune would run it
powershell.exe -ExecutionPolicy Bypass -File ".\MyScript.ps1"

PowerShell script to test execution

Version Control with Git

Consider using Git to track changes to your scripts. Visual Studio Code has excellent built-in Git support, and extensions like GitLens enhance this further. Version control helps you track changes, collaborate with others, and roll back if something goes wrong. Store your scripts in a repository on GitHub or Azure DevOps to ensure they’re backed up and accessible from anywhere.

Click to collapse

Limitations of Windows Sandbox for PowerShell Development

While Windows Sandbox offers numerous advantages, it also has certain limitations:

  • Persistence: Any changes made within the sandbox are lost once the sandbox is closed. This limitation necessitates saving your work frequently and ensuring that critical files are stored on the host system via mapped folders.
  • Limited Resources: Windows Sandbox operates with limited system resources compared to a full virtual machine. This restriction can impact the performance of resource-intensive scripts or applications.
  • Component Availability: Not all PowerShell components or functionality may be available within the sandbox. For example, certain modules or dependencies that require installation on the host may not function correctly within the isolated environment.
  • No Domain Join: Windows Sandbox cannot be joined to a domain, which may limit testing scenarios that require Active Directory authentication.

Handling Limitations

Despite these limitations, you can optimize your workflow by:

  • Embrace Module Installation - Having to install PowerShell modules (or other tools) every time you launch Windows Sandbox is a benefit, not a burden. Building module installation into your scripts forces you to handle dependencies explicitly, ensures your code works on a clean system just like production environments, and validates that your deployment logic is correct.
  • Always Use Mapped Folders - Never save files directly in the sandbox. Keep all scripts and project files on your host system and access them through mapped folders. This way, your work automatically persists when the sandbox closes.
  • Resource Management - Monitor and manage system resources to ensure optimal performance within the sandbox. Use the <MemoryInMB> configuration option to allocate more RAM if needed.

Putting It All Together

Setting up a developer environment using Visual Studio Code and Windows Sandbox is a powerful approach for developing Windows PowerShell scripts for Microsoft Intune. The isolation, security, and reproducibility of Windows Sandbox, combined with the robust development features of Visual Studio Code and PSScriptAnalyzer, create an optimal environment for script development and testing.

Key takeaways:

  • Use Windows Sandbox for safe, isolated script testing
  • Configure a workspace folder on the Desktop for easy access
  • Install Visual Studio Code with the PowerShell extension for modern development features
  • Leverage PSScriptAnalyzer for real-time code validation
  • Avoid PowerShell ISE - it creates inconsistent testing conditions
  • Consider Git for version control - Visual Studio Code has excellent built-in support

By following the best practices and being mindful of the limitations, you can enhance your productivity and ensure the reliability of your PowerShell scripts. Embrace the benefits of this setup and take your PowerShell script development to new heights.

Happy scripting!

–Jesper