shell-intune-samples: Intune shell script samples for Linux and macOS devices

Samples maintained by the people who write the documentation

This repository is for Intune Shell Script Samples, and it is maintained by the Microsoft Intune Customer Experience Engineering Team. The stated purpose is narrow and honest: the samples provided here are for education and showing the art of the possible, and you are encouraged to download, test and enhance them for your own use.

That last part is the interesting one for an engineer. These are not frozen artefacts that Microsoft supports, they are worked examples, and the invitation to enhance them is a statement that the sample is a starting point rather than a contract.

The context is Intune, Microsoft's device management service, and the three documentation links at the top of the README are the three places where this material plugs in. There is a page on using shell scripts on macOS devices in Intune, a page on using shell scripts on Linux devices in Intune, and a page on using custom compliance settings in Linux. The repository is the example half of that documentation, and reading it next to those pages is the intended way to use it.

The repository is MIT licensed, the primary language is Shell, and the last push was on 2026-10-15. The most recent tagged release is v1.25.04.0, named for the WSL Intune Plugin and dated 2025-07-17, which tells you that samples here are versioned and evolve, but on the schedule of a documentation repository rather than a software project.

Two trees, seven folders, and the features they mirror

The repository is split into scripts for Linux and macOS, and the tree is printed in the README in full.

   |-Linux
   |---Config
   |---Custom Compliance
   |---Misc
   |
   |-macOS
   |---Apps
   |---Config
   |---Custom Attributes
   |---Custom Profiles

Seven directories, and their names are the documentation of what the samples cover. On the Linux side there is Config, Custom Compliance and Misc. On the macOS side there is Apps, Config, Custom Attributes and Custom Profiles.

Read against the three Microsoft Learn links, the shape makes sense. Configuration scripts are the common case on both platforms, since a custom setting or a configuration profile is what most administrators write first. Linux has a dedicated folder for custom compliance settings, which matches the third documentation link exactly, and a Misc folder for the scripts that do not fit a category. macOS has no compliance folder, but it has Apps, which is where the line of business application scripts would sit, and Custom Attributes and Custom Profiles, which are macOS specific concepts that have no Linux equivalent in this tree.

The top level of the repository adds the supporting material that a sample repository needs and a code repository does not: a docs/ directory, an img/ directory for the images used in the documentation, a _config.yml for the GitHub Pages site, and a scripts/ directory that is separate from the platform trees, which suggests it holds tooling for the repository itself rather than samples for devices.

The disclaimer is the most important line in the README

Under a heading marked Disclaimer, the repository says: understand the impact of each sample script prior to running it, and samples should be run in a non-production or test environment.

That is worth taking seriously rather than reading as boilerplate, because of what a shell script in Intune is. A shell script deployed through Intune can reach every device in the targeted group, and it runs with whatever permissions the script asks for. A script that writes a configuration file, sets a default, or installs something will do that to every matching device, and a script with a mistake in it will do it repeatedly until somebody notices.

The framing of the whole repository follows from that. The samples are for education and for showing what is possible, which is a way of saying that they are demonstrations, and the disclaimer is the practical counterpart, telling you to try them where a mistake costs nothing.

This is also why the directory names matter more than they would in a normal code repository. A reader who picks up a file from Custom Compliance is making a decision about what their devices will be checked against, and the file tells them the shape of the check rather than the specifics of their fleet.

The CLA bot is the real gate on a pull request

The contributing section is short and its centre of gravity is legal rather than technical.

The project welcomes contributions and suggestions, and most contributions require you to agree to a Contributor License Agreement declaring that you have the right to, and actually do, grant the rights to use your contribution. Details are at the Microsoft CLA site, and when you submit a pull request, a CLA bot automatically determines whether you need to provide a CLA and decorates the pull request appropriately, with a status check and a comment, and you only need to do this once across all the repositories using that CLA.

That last sentence is a genuinely useful detail for anyone who contributes across Microsoft's open source repositories, since the alternative reading, signing a separate agreement per repository, is a lot of ceremony for a small script fix.

The project has also adopted the Microsoft Open Source Code of Conduct, with the code of conduct FAQ linked and a contact address given for questions. The rest of the governance is in the repository itself, with a CODEOWNERS file that routes review for particular paths, a SECURITY.md for vulnerability reports, a SUPPORT.md for where questions should go, and a CONTRIBUTING.md alongside an AGENTS.md for the agent tooling that works on the repository.

The structure of those files is a good sign about how the repository is run. A sample collection with no defined path for a security report or a support question is a sample collection that gets abandoned quietly, and a CODEOWNERS file is a commitment that somebody is responsible for each part of it.

Editorial conclusion

shell-intune-samples fits an Intune administrator who wants to see what a working configuration script looks like on Linux or macOS, and who can read a script closely enough to adapt it. It does not fit a team that wants a maintained tool, since the repository is explicitly a set of examples rather than a product, and it does not fit anyone who needs support commitments from Microsoft for what runs on their devices. Verify three things before you deploy anything you take from here: that the sample does what you think it does on the version of the operating system your fleet runs, since these are samples rather than supported configurations, that you test it in a non-production environment first, which the repository asks for explicitly, and that you know which Intune feature each script is exercising, because the tree mixes configuration, custom compliance, custom attributes and custom profiles and the wrong one produces a device that silently stays out of compliance.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. microsoft/shell-intune-samples on GitHub
4. README
5. Releases