After seeing Damien van Robaeys doing some awesome stuff with Windows Sandbox, I noticed I didn’t write anything about Windows Sandbox…. Even while I was using it for a while now. So, I decided to do a blog about it.

Windows Sandbox provides a lightweight desktop environment to safely run applications in a nice protected and isolated environment. You can run sandbox on Windows 10 pro/enterprise or education. Software installed inside the Windows Sandbox environment remains “sandboxed” and runs separately and isolated from the host machine.

The sandbox instance is a dynamically generated image that uses the files from the host filesystem itself. Most OS files are immutable and can be freely shared with Windows Sandbox.

More on this (Reparse points) later.

Sandbox doesn’t have persistent storage, so running Windows Sandbox is temporary. When it’s closed, all the software and files and the config is deleted. You get a brand-new sandbox instance every time you open it. But I guess that one is obvious when looking at this warning when closing Sandbox

When taking a good look at Windows Sandbox you could say it looks much like Application Guard for Office apps. WDAG also launches an Office instance in an isolated environment. And like I told in this blog about Credential Guard: “Virtualization is just like segmentation”

Now we know, Sandbox is almost the same as Windows Defender Application Guard, let’s look at what 3 components it uses to deliver us this fantastic product

*CMservice.DLL

*VMcompute.exe

*VMWP.exe

You could see it for yourself by opening the task manager and take a look at all the running processes.

And by opening “services.msc” You could take a guess where CMService stands for. If that service isn’t running, Sandbox will not work!

Okay, now we are pretty sure it’s “just” a Virtual Machine, there should be a virtual hard disk somewhere with it. And yes there is, open explorer and browse to:

C:\ProgramData\Microsoft\Windows\Containers\Sandboxes

You will notice when you are not running Sandbox only one folder exists and when starting sandbox it will create a second one

Let’s try to open/mount the huge 4 MB VHDX to take a look at what’s inside.

Did you notice the nice grey crosses and the attributes?

These grey crosses are telling us these folders are Reparse Points. A reparse point is best explained as a symbolic link/windows shortcut. It will make sure these folders are linked to the host itself. I guess that’s why the image isn’t that big.

Please note software and applications installed on the host aren’t directly available in the sandbox. If you need specific applications available inside the Windows Sandbox environment, they must be explicitly installed within the environment. More on this on what I am missing in Windows Sandbox and how to improve Sandbox…

# 2. Installation of Sandbox

It’s very nice to know some background information but we still need to test it. Let’s start the installation of Sandbox.

You can open Powershell and run this command to Install Sandbox

Get-WindowsOptionalFeature -online -FeatureName Containers-DisposableClientVM

Or if you prefer the GUI option:

Of course, when you want to run sandbox inside a VM (just like me) you need to make sure hyper-v nesting is enabled

Set-VMProcessor -VMName \<VMName> -ExposeVirtualizationExtensions $true # 3.How to configure Sandbox? Now we know it’s very easy to install Sandbox we need to know some background information to understand how to configure sandbox. When launching sandbox without any modifications, it will spin up a default image. However, many times you want to redirect some folders or make sure a startup script is launched when launching sandbox. When you want to make use of some additional folders and installation media, you can use config files that allow you to customize the sandbox during startup. The sandbox configuration files are formatted as XML and use the .wsb file extension. Of course, you can specify multiple different settings to configure the Windows Sandbox. I guess this picture explains it all! So you can configure all options you want in a WSB config file and just double-click on it to start Windows Sandbox with all your defined settings. Let’s look at this XML file example and how to configure it <Configuration> <VGpu>Default</VGpu> <Networking>Default</Networking> <MappedFolders> <MappedFolder> <HostFolder>C:\Users\rudyooms\desktop\sandbox</HostFolder> <ReadOnly>true</ReadOnly> </MappedFolder> </MappedFolders> <LogonCommand> <Command>explorer.exe C:\users\WDAGUtilityAccount\Desktop\desktop</Command> </LogonCommand> </Configuration>  I will point out the 2 most important options you can configure: Shared Folders – This will share a folder from the host with the guest and you can specify if it has read or write permissions. Startup Script – This script/command will be launched when a sandbox instance spins up Let’s explain what happens when we launch sandbox with the XML configuration, I showed you above: My desktop folder sandbox from my host machine (C:\Users\rudyooms\Desktop\sandbox) will be read-only redirected/mapped to the wdagutilityaccount desktop folder (C:\Users\WDAGUtilityAccount\Desktop\Desktop) of the sandbox guest instance. When specifying the command “explorer.exe C:\users\WDAGUtilityAccount\Desktop\Desktop” it will open explorer in the desktop folder. # 4.Adding/Changing installation files to the Sandbox Baseline As you know by now, when you launch sandbox, a new clean instance will be started. If we don’t want to use the “shared folder” option, how are we going to add some files to the baseline? There is always another way to get more sand in the sandbox! It will only take 5 little steps 1. We need to stop the CMservice I showed you earlier before we could change anything, so let’s do so. 2. Open/mount the baselayer.vhdx inside the C:\ProgramData\Microsoft\Windows\Containers\BaseImages\guid\ folder 3.Add files to a specific existing folder like I show below 4. While at it we are also changing the default PowerShell execution policy, otherwise you will need to change it every time sandbox launches. To do so Open regedit , Click on HKLM and click on file and load hive and select the “ntuser.dat” from .\Files\Users\WDAGUtilityAccount\ntuser.dat 5. Give it a name and browse to the name you gave it (in the example, I am using “user”) Software\Microsoft 6. Create some new keys as I show below inside the software\microsoft key. 7. After you have created the keys, let’s add the strings necessary to configure the default PowerShell Execution Policy. To do this you will need to create 2 new strings: “Executionpolicy” and “Path” 8. Make sure you unload the registry “hive” and unmount the baselayer.vhdx 9. Start the “Cmservice” service again and open a sandbox instance and you will notice the files you added are persistent available in the container, now let’s check the default PowerShell Execution Policy! # 5.Improving the use of Sandbox As told at the beginning of this blog, I love the possibility of testing an Intunewin file in Windows Sandbox. There could only be one person who created this beautiful tool: Damien! Download and install it now! RunInSandbox: Run PS1, VBS, EXE, MSI, intunewin, extract ZIP, share folder directly in Windows Sandbox from a right-click | Syst & Deploy (systanddeploy.com) The only thing you will need to do after the installation is right-clicking on the file and click on test the intunewin in sandbox and put in the install command. UPDATE 22-08-2021 After talking to Damien, We noticed there was some confusion about the install command. I am using PowerShell a lot! When you need to launch a Script from within a PowerShell session you will need to enter it like this: “.\ ” So I did it without even thinking… But of course, you could also just enter the normal install command: msiexec /i “msifile.msi”/q It will launch a sandbox instance and it will try to install the package. If it’s not working and you need to start troubleshooting why… just open Powershell as admin and browse to the “run_in_sandbox” desktop folder. You will notice the Intunewin_install script. When running this script, it will extract the intunewin file to the c:\windows\temp\intunewin folder and from there you could continue to troubleshoot the installation even further! I love this tool. # 6. What you thought wasn’t working with Sandbox? In my opinion not that much, except for one very important Windows Feature! And that one important could be Dot.Net Framework 3.5. Or run PowerShell to detect which Dot.Net framework versions are installed. Get-ChildItem ‘HKLM:\SOFTWARE\Microsoft\NET Framework Setup\NDP’ -recurse | Get-ItemProperty -name Version,Release -EA 0 | Where {$_.PSChildName -match ‘^(?!S)\p{L}’} |

Select PSChildName, Version, Release

You could ask why I want/need to have dot.net framework 3.5 inside my sandbox? There could be only one reason, you would think of PSADT!

So why not installing Dot.Net manually? You will need to make sure you have enabled the trusted installer when you are installing additional features. You could try it for your own (even when I can tell you it’s not going to work)

Set-Service -Name "Trustedinstaller" -Status running -StartupType automatic
md c:\install
$download_url = "https://download.microsoft.com/download/2/0/E/20E90413-712F-438C-988E-FDAA79A8AC3D/dotnetfx35.exe"$local_download_url = "c:\install\dot35.exe"

$wc = New-Object net.webclient$wc.Downloadfile($download_url,$local_download_url)
c:\install\dot35.exe /q /norestart


Or use the DISM tool, but both will fail:

And here is why…. C:\windows may not point to a valid Windows folder…

But luckily!!, it’s a good thing when you don’t move or rename the deploy-application.exe, you don’t need to have dot.net 3.5 installed!

If you choose to rename or move it, it will prompt you for the dot.net requirement. To resume, you could still test win32 applications which are deployed with PSADT. But of course, when you are testing win32 applications with a dot.net 3.5 requirement like for example Snelstart, they will give you some dot.net framework errors!

# Conclusion

When you are deploying Win32 Apps daily you will know by now what can go wrong but if things go south you will need to know why. Sandbox is the way to go to test the deployment and installation of your win32 packages even when dot.net 3.5 is missing

I guess I am going to tell you it once again: Damien his solution is a great addon when using sandbox!