Application Management and Patching

Windows Sandbox: PowerShell and Application Workspace for Powerful Application Testing

Topics: Application Management and Patching

By Donny van der Linde, Field CTO BeNeLux at Recast Software and Harm Veenstra, Consultant at NEXXT

A few months ago, my former colleague Harm Veenstra, a consultant at NEXXT, wrote a detailed blog about setting up a development Windows Sandbox using PowerShell and Winget. It’s perfect for creating isolated testing or development environments. Since Harm clearly explained what Windows Sandbox is and how to set it up, I won’t cover that again here. It’s no surprise that Harm writes about PowerShell-related topics; he truly lives and breathes it. Earlier this year, he even became a Microsoft MVP in PowerShell, which, if you ask me, is well-deserved. NEXXT, a Dutch partner of Application Workspace, specializes in Cloud, Architecture, Security, Workspace, Collaboration, and Managed Services, serving organizations across various sectors in the Netherlands.

While reading his blog, I thought, “What a fantastic blog!” and immediately saw some use cases for Application Workspace. First, it would be more convenient and comprehensive to have these applications run directly within a Windows Sandbox. Take the example applications Harm uses in his blog, Visual Studio Code and Notepad++, which are installed via WinGet. We can easily accomplish this with Application Workspace by pulling them from our Recast Setup Store, ensuring the latest version is always available. Additionally, you might want to configure certain settings immediately, like enabling plugins within Notepad++. This is one of the strengths of Application Workspace: we not only install the applications but also easily configure settings as needed. All of this can be managed from a simple GUI without requiring extensive scripting knowledge. 

Windows Sandbox: PowerShell and Application Workspace for Powerful Application Testing

Now, we’ve achieved the first goal: ensuring certain applications are installed by default when the Sandbox starts. This is something Recast can easily handle with an Application Workspace deployment. Next, let’s tackle a second scenario. 

Another key feature of Application Workspace is its DTAP pipeline (Development, Testing, Acceptance, Production). This is a multi-phase method for testing and deploying software, helping manage and roll out applications in a controlled and structured way. The main device where the Sandbox is activated can continue to operate in the normal Production phase. This device can be a laptop or even a Windows 365 (Cloud PC)—essentially a virtual PC in the cloud. The Sandbox VM can then be used for the Test phase, allowing functional application managers or pilot users to safely test new versions or changes in an isolated environment. 

Script Modifications and Improvements

That all sounds great, but what exactly has changed compared to the first script Harm wrote? Here are the new additions to the new updated PowerShell script: 

  1. Copy Agent.json and Agentregistration.cer into $mappedfolder and download the bootstrapper. These files ensure Application Workspace can properly install the Universal Agent and initiate a deployment as needed. They will be used from the main device that also has the Application Workspace Universal Agent installed. 
  2. Update Agent.json to reference the default Sandbox deployment or the one specified with the $deployment variable. 
  3. Create the RecastComputerName.ps1 script, which runs when the Recast Sandbox starts and after every reboot. This ensures the Sandbox always uses the same name—necessary for linking a deployment within Application Workspace. You can choose the name when initiating the script. 
  4. Create the Recast.ps1 script, which installs the Application Workspace Universal Agent in the Windows Sandbox. This script uses the previously gathered files. Once the Agent is installed and activated, deployment begins. A default set of applications, including Notepad++ and Visual Studio Code, will be installed and ready as soon as the Sandbox script finishes. 
  5. In the RecastComputerName.ps1 script, rename RecastComputerName to the value specified in $RecastComputerName, then save. 

You can grab this script from my GitHub or from Harm’s GitHub 

Output Preview

Note: The Wdagutilityaccount is the default account used by Windows Sandbox. Normally, it’s challenging to link specific applications to this account, but with Application Workspace, this isn’t an issue. You can log in with an Entra ID account, making applications available for a specific user or group, allowing them to be tested. 

At the beginning of this blog, I outlined two scenarios where Application Workspace can add value when used with Windows Sandbox. 

Scenario 1 

Use Application Workspace to install applications like Visual Studio Code and Notepad++ from the Recast Setup Store when the Sandbox starts, ensuring you always have the latest version. Configure settings, such as plugins, without scripting knowledge, via a simple GUI. For the applications mentioned, we want the following settings configured: 

Notepad++ 

  • Set large icons 
  • Install two plugins: ComparePlus and AutoSave 

Visual Studio Code 

  • Install two extensions: GitHub Codespaces and PowerShell 

Scenario 2

Application Workspace offers a DTAP street for structured testing and software deployment. The Sandbox VM can be used for the Test phase, allowing Application Managers or Pilot Users to safely test new versions and settings in an isolated environment. For example, we’ll use the VTBL Calculator application. We’ll install version 4.7.1 (the latest) in the Sandbox (Test phase), while the main device (Production phase) remains on version 4.5.1. 

Final Thoughts 

Using Windows Sandbox in combination with Application Workspace provides a powerful, lightweight, disposable virtual environment that can be quickly set up and torn down. It’s ideal for testing applications and settings in isolation from the main system. Meanwhile, the main device (where Windows Sandbox is activated) can continue to operate in the Production phase. This ensures safe and controlled testing of new versions or changes. When the Sandbox is closed, all applications, settings, and the current state of the system are removed. Another advantage is that each time you start the Sandbox, you have an evergreen environment ready to use. 

Back to Top