I was working with one of the team the other day and we were hitting some issues with the Azure (Az) PowerShell modules.
We had recently just made some tweaks to our internal security policies so weren’t completely sure if they were the issue, but needed a quick way to rule them out (without stripping back the policies applied to the device).
Now normally I’d head across to our lab and fire up a VM, or look to enable or disable Hyper-V in Windows, but I then I remembered an option that quite often gets overlooked, Windows Sandbox.
Windows Sandbox is a lightweight VM running from the core OS files, but is isolated from your main device. It’s also non-persistent, so anything done within the VM is lost when you close it.
Not ideal if you want to setup an environment to repeatedly test things in that requires much installing, fire up a Hyper-V VM for that! But it is ideal when you want a quick, fresh, environment to test something and then be done with it.
It worked a treat in this case and we identified it was a conflict between the Azure Automation ISE Addon and the Az module.
If you’ve not got this enabled already, it’s really simple!
You can either go into the GUI via Programs and Features and enable Windows Sandbox in the Turn Windows Features on or off section, or simply run 1 line of PowerShell.
Enable-WindowsOptionalFeature -FeatureName “Containers-DisposableClientVM” -Online -NoRestart
You will need to reboot and you will also need to make sure you have all your CPU virtualisation options enabled, but as long as you do, after a reboot you’ll be able to launch it from the Start Menu and off you go!
There’s a lot more you can do with Sandbox and if you do find yourself regularly installing the same bits over and over, check out the advanced configuration options here:
Share on:
