This article will describe how to enable Sandbox through Intune and use it for intunewin packaging.
- Azure AD Joined Intune MDM managed devices
- Enabling Sandbox with Intune
- Use Sandbox to make your intunewin packaging much easier
Windows Sandbox provides a lightweight desktop environment to safely run applications in isolation. Software installed inside the Windows Sandbox environment remains “sandboxed” and runs separately from the host machine.
A sandbox is temporary. When it’s closed, all the software and files and the state are deleted. You get a brand-new instance of the sandbox every time you open the application. 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.
Windows Sandbox has the following properties:
- Part of Windows: Everything required for this feature is included in Windows 10 Pro and Enterprise. There’s no need to download a VHD.
- 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.
- Secure: Uses hardware-based virtualization for kernel isolation. It relies on the Microsoft hypervisor to run a separate kernel that isolates Windows Sandbox from the host.
- Efficient: Uses the integrated kernel scheduler, smart memory management, and virtual GPU.
Intunewin: if you wanna deploy Windows Classic Apps (Win32) apps with Intune (.exe), they have to be converted to the .intunewin extension. This can be done with the Microsoft Win32 Content Prep Tool. The tool also detects some of the attributes required by Intune to determine the application installation state.
After you use this tool on the app installer folder, you will be able to create a Win32 app in the Intune console. The Microsoft Win32 Content Prep Tool zips all files and subfolders when it creates the .intunewin file. Be sure to keep the Microsoft Win32 Content Prep Tool separate from the installer files and folders, so that you don’t include the tool or other unnecessary files and folders in your .intunewin file.
You can download the Microsoft Win32 Content Prep Tool from GitHub as a zip file. The zipped file contains a folder named Microsoft-Win32-Content-Prep-Tool-master. The folder contains the prep tool, the license, a readme, and the release notes.
I’m not gonna go in detail a lot of the process, you can always consult the Microsoft docs, but the flow looks like this: Good to know is you can wrap more than exe’s in the .intunewin extension. And how I see it, personally, I wrap everything, just everything. It unlocks more options when deploying applications and has a lot of advantages. And wrapping into .intunewin only takes a few minutes. So why wouldn’t we do it? So, what do I wrap? Everything! (.exe, .msi, powershell scripts, .bat scripts if necessary, …)
1. Enable Sandbox on Windows 10 with Intune
Simple as it is, this can be done with a PowerShell script. I’m not gonna waste a lot of time on this topic as it has been blogged before by Peter Van Der Woude. It comes down to these simple steps:
- Deploy Peter his PowerShell script through Intune
- If you want to speed up the process (testing wise) restart the Microsoft Intune Management Extension service (normally this runs 1/hour and this service makes sure your PowerShell scripts get processed, so if you wanna speed up the process just restart the service).
You can find his guide here: ‘Simply enabling Windows Sandbox‘
2. Use Sandbox to make your intunewin packaging life easier
So, now I hear everyone thinking, how can this Sandbox environment make your life easier for packaging? Well, up until now if I wanted to wrap .exe’s into .intunewin on projects for clients, I always used a Hyper-V Windows 10 VM. Because we have to test out some things.
- Silent install command (if there is one)
- Sometimes you need to create an InstallShield Response File (.iss)
- I want to know the location of the installation (for further use when deploying with Intune – detection rules)
And a VM works just fine but I always had to revert it back to the previous state of the VM. Or uninstall the application (and not knowing what mess some uninstallers leave behind sometimes). With Sandbox you just don’t have all that hassle. So now, if the time arises that I have to convert some MSI’s or EXE’s into .intunewin for deploying with Intune. I just open Sandbox.
And once in Sandbox, I just do what I have to do (I won’t dive deep into my process of packaging & deploying with Intune – this will follow in another blog post). And once I’m done and I have all the information I need I just close the Sandbox and I don’t have to clean anything up, or uninstall programs or revert VM’s to the original state. Makes life easier. And hey, we are al lazy f**** ain’t we. If something can make your life easier. We just do it!
So if you need to convert some installers into intunewin, just try it out. You’ll see it’ll make your life easier.
More articles on Intune:
- Get device hashes from HP for Autopilot pre-production testing
- Run as admin gives black screen in Quick Assist/TeamViewer – Intune fix
- Intune – change Primary User of a device
- Ransomware protection (Controlled Folder Access) setup with Intune
- Windows Hello for Business multi-factor unlock with Intune