Skip to main content
Roll out the runtime packages, images, and policy you prepared on one device. Verify them in an employee session before expanding to the team. Before deployment, finish environment preparation and define and protect the policy. The steps below distribute it, verify the result, and maintain it over time.

​
Choose your device manager

Use your device manager to distribute the policy to a pilot group first.
1

Build a configuration package

On a packaging Mac, place managed.json in /Library/Application Support/microsandbox/. Drag the folder into Composer to create a package source.Set the owner to root, group to wheel, directory permissions to 0755, and file permissions to 0644. Select Build as PKG and sign according to your organization’s policy.
2

Upload the package

In Jamf Pro, open Settings > Computer management > Packages > New. Upload the PKG and make it available on your distribution point.
3

Create a deployment policy

Open Computers > Policies > New. In General, select Recurring Check-in and a daily execution frequency. Under Packages, add the PKG with the Install action.
4

Deploy to a pilot group

In Scope, select your pilot computers and save the policy. After check-in, review its logs and verify the effective settings as an employee before expanding the scope.
1

Prepare the file deployment

Use Intune’s macOS shell-script workflow. Your organization’s deployment script must write the JSON to the macOS policy path, apply the required permissions, and safely replace an existing policy. It should succeed when the correct file is already present.
2

Add the deployment in Intune

Open Devices > By platform > macOS > Manage devices > Scripts > Add. Give the policy a name in Basics, then upload your script under Script settings.
3

Configure execution

The Intune management agent must be installed. Microsoft’s script prerequisites require direct Internet access; proxy connections are unsupported for this delivery path.
4

Assign and verify

Under Assignments, include a pilot device group. Select Review + add > Add, then review Device status. Verify the effective settings in an employee session before extending the assignment.
1

Package the policy

Use your application-packaging tool to create a per-machine MSI that installs managed.json beneath the system ProgramData folder with the Windows permissions. This is your organization’s configuration package, separate from the microsandbox runtime.Wrap the MSI as an .intunewin file with Microsoft’s Win32 Content Prep Tool.
2

Create a Win32 app

Open Apps > All Apps > Create. Choose Windows app (Win32) and upload the .intunewin file. On Program, enter the MSI’s silent installation and uninstallation commands, choose System install behavior, and set Allow available uninstall to No.
3

Configure detection

In Detection rules, choose Manually configure detection rules, add an MSI rule, and enter your package’s product code and version check. See Intune’s Win32 app guide.MSI detection confirms package installation. It does not prove that the JSON content or permissions still match your policy.
4

Assign and verify

Assign the app as Required to a pilot device group, then create it. Review installation status and verify the effective settings as an employee before widening the assignment.

​
Verify the configuration

The check below uses the sample policy, which enforces two vCPUs and 1 GiB of memory. Adjust the expected values for your own policy.
  1. Sign in as an employee and open a fresh terminal. Confirm msb context selects a local backend.
  2. Create a sandbox with values that conflict with the sample policy:
  3. Confirm config.resources.cpus is 2 and config.resources.memory_mib is 1024. Repeat with your employees’ SDKs.
  4. Remove the test sandbox with msb rm --force managed-check.
Before expanding the pilot, check each supported OS and SDK:

​
Apply configuration updates

  • Publish: replace the complete file atomically, preserving permissions. Update the device-manager package or action and its detection rules together.
  • Roll back: redeploy the previous policy through the same tool. Removing a device from a deployment’s scope does not remove its file.
There are no file watchers. Applying a policy update depends on what is already running: Restarting a VM alone does not reload managed.json. Keep previous runtime binaries available until applications replace their backend handles and running VMs stop using them. Changing data paths does not migrate existing data. A missing policy file means no managed overrides; an invalid or unreadable file causes an error when loaded.