intune-remediation-scripts: a community library of Intune detection and remediation packages

One folder per package, each holding a detection script

The repository describes itself as a collection, a community project, holding detection and remediation scripts for Microsoft Intune endpoint management. Its stated purpose is a growing library of detection and remediation scripts for Intune Endpoint Analytics, and each script package includes a detection script and, where applicable, a remediation script that you can deploy directly to your environment.

The organizing idea is that the repository is a catalog you browse rather than a tool you run. The README says plainly to browse the folders to explore the available scripts, and the project context section calls it a deployable script library for Intune administrators who want ready-to-use detection and remediation packages, and describes it as both a community script catalog and a practical deployment reference.

The mechanism is Intune's proactive remediations, where a detection script runs on the endpoint and reports whether an issue exists, and a remediation script runs only if detection says action is needed. The separation is the point the README makes: each package is designed to separate detection from remediation so administrators can validate behavior before rollout. A detection script that always returns true would cause the remediation to run on every check interval, so the two scripts have to agree with each other, and reading both is the only way to know that they do.

The repository is not a single monolithic script with a menu, which is the more common shape for this kind of community collection. It is many small, independently deployable units, and the top-level entry list shows just how many: folders such as Activate-Numlock, AutomaticTimezone, BlackLotus-Mitigation, BlockAADWorkplaceJoin, Check-DiskHealth, Clear-TeamsCache, Disable-SMBv1, Enforce-BitLocker, Enforce-CredentialGuard, Enforce-DOH, Enforce-SMB-Signing, Enforce-WindowsFirewall, Fix-FileAssociations, Fix-OfficeActivation, Fix-SearchIndex and Fix-WMI-Repository, among many more.

The folder names are the catalog, and they are readable

Because the folders are named after the task rather than after a script file, the top-level listing does the documentation work. Reading the names tells you the scope of the collection, and it is a broad one.

There is security hardening in the collection, with Enforce-WindowsFirewall, Enforce-SMB-Signing, Enforce-CredentialGuard, Enforce-BitLocker, Enforce-DOH, Disable-LegacyTLS and Disable-SMBv1, plus a dedicated BlackLotus-Mitigation folder. There is a Detect group as well, including Detect-AdminUsers, Detect-Autologon, Detect-BlueScreenHistory, Detect-CertificateExpiry, Detect-DriverIssues, Detect-SCCM, Detect-SuspiciousScheduledTasks, Detect-VPNSplitTunnel and Detect-Browser-Passwords, which is a check for stored browser credentials rather than a credential-stealing script and belongs to the compliance and hygiene side of the collection.

The middle of the list is the housekeeping work that consumes support time. There is a family of cache and folder cleaners: Clear-BrowserCache, Clear-BrowserExtensions, Clear-DnsCache, Clear-DownloadFolder, Clear-DownloadFolder-SingleUser, Clear-FontCache, Clear-OutlookCache, Clear-TeamsCache, Clear-TempFiles-Advanced and Clear-WindowsUpdateCache. There is maintenance: Defrag-SSD-Trim, Disk-Repair, Enable-DeliveryOptimizationVerboseLogging, Fix-SearchIndex and Fix-WMI-Repository, and a group of configuration toggles such as Disable-Coinstaller, Disable-Fastboot, Disable-StartMenuWebSearch, Enable-DarkMode, Enable-DNSOperationalLogs, Enable-DotNet-35, Enable-RDP, Enable-SignatureValidation and Activate-Numlock.

A few entries are more specific to a working environment: Create-LocalAdmin, Get-Always_Elevated, BlockAADWorkplaceJoin, Copy-FilesToBlobStorage, Collect-EventLogErrors, AutomaticTimezone, Add-Winget-App, and a Device Auto-Syncer folder with a space in its name rather than the hyphen convention the rest use. That inconsistency is a small signal that contributions come from many people.

Deploying a package is a five-step walk through the Intune portal

The quickstart section is a portal walkthrough rather than a command line, and that reflects what the scripts actually are: artifacts you upload into the Intune service rather than something you run from a terminal.

The steps are: open the Intune Portal and go to Devices and then Scripts and remediations. Click the create button, which the README marks with a plus. Enter a Name, a Description, a Publisher and a Version, then continue. Upload the detection script and, optionally, the remediation script. Finally configure scope tags and assignments, and review and create.

Two of those fields deserve attention. The Name, Description, Publisher and Version you type are the metadata the deployment carries, and since the packages are community contributions, that metadata is how a colleague later knows who wrote the logic they are looking at in the portal. The Version field is the only version tracking the deployment has, because the repository has no GitHub releases attached and the packages themselves live in folders rather than tagged artifacts.

Scope tags are the second thing to get right. They are what determines which devices the package runs on, and the README's wording is that each package is designed to be reviewed, tested, and then deployed through Intune proactive remediations. A detection script that is harmless on a test machine can be disruptive on a production fleet, so the scope is where the review process has to be enforced in practice.

A template folder is the entry point for new contributions

The contributing section is short and gives two paths, one for people with an idea and one for people with code.

If you want a script that does not exist yet, the README asks you to open an issue describing it. If you already have a script, the instruction is to use the template in the `0 - Template` folder and submit a pull request. The template folder sits at the front of the top-level listing, numbered zero, which is the convention for making it the first thing a visitor sees.

The contrast between the two paths is a reasonable design. An issue is cheap and lets the community vote on whether a check is wanted at all, and a pull request with a script already written is the expensive case that needs review.

The README is also unusually open about the review bar. It says to open a pull request and not feel it needs to be perfect, that incomplete work is totally fine, and that the maintainers would love to help get it ready for merging. That is a reasonable posture for a community catalog where a partial script that half the fleet needs is still worth having.

One thing the README does not describe is the review criteria, how a script gets tested before merge, or what a package's internal file layout looks like beyond the fact that it holds a detection script and possibly a remediation script. The template folder is the reference for that, and the repository does not document it in the text available here.

A bulk import tool previews packages without touching devices

At the end of the README there is a short section on bulk import, and it points at an optional tool with its own README under `tools/`.

The tool is for previewing and importing selected packages without assigning them to devices. That distinction is the useful part. Bulk-creating dozens of script packages in Intune by hand through the portal is tedious, and each one still needs a decision about scope tags and assignments. A tool that creates the packages in an unassigned state means an administrator can review the whole set in the portal first, and assign deliberately afterwards, rather than working through the portal with a half-designed assignment list.

The word optional matters. It is not required to use the collection, and the main workflow is still one package at a time through the portal. The tool is a convenience for a specific bulk scenario, and the README gives no detail beyond its existence and the `tools/README.md` pointer, so its behavior on conflicts, its prerequisites, and the format of its import file are all things you would learn from that file rather than from the top-level documentation.

The homepage of the repository points to a blog article on endpoint analytics remediation script community repositories, which suggests the maintainer writes about the practice of running such a collection, not just the code.

No guarantee, test first, and note the branding

The disclaimer is short and worth quoting in full. This is a community repository and there is no guarantee for the scripts provided here. The README asks you to review and test thoroughly before deploying to production environments.

That is the correct instruction and it is also the main thing to understand about the project. A detection and remediation package is code that will run with administrative rights on every machine in its scope, on a schedule set by the Intune assignment, and a bug in a detection script is not a warning, it is a trigger. The repository is a starting point for a policy set that your environment owns, and the review step is where the risk is managed.

The project is MIT licensed, with the terms in the LICENSE file, and the repository is not archived with the last push on 2026-10-14. There are no GitHub releases attached, so versions live in the folder structure and in the Version field you type during deployment, which is a meaningful difference from a package you consume by pinned version.

One more observation about the README as a document. It is wrapped in personal branding blocks, with a link to the maintainer's website, LinkedIn, X and YouTube, plus a footer linking to the maintainer's articles and to an index of his other repositories. The links are the standard profile-readme pattern, and the README itself states the type as a collection and the status as a community project. For a catalog of scripts that will run in your environment, it is worth knowing that the project is presented as one person's community contribution rather than a vendor-supported product, since that changes who you would go to when a script misbehaves.

Editorial conclusion

Adopt this repository if you administer Intune, want ready-made detection and remediation logic for common endpoint issues, and are willing to read and test each script before it touches a production fleet. Do not adopt it as an unattended policy set, because the repository itself states there is no guarantee for the scripts and that they must be reviewed and tested before deployment. Verify first that a given package's detection and remediation behave the way your environment expects, since the deployment model gives the detection script the authority to decide whether remediation runs at all.

Frequently asked questions

Official sources

1. Issues
2. JayRHa/intune-remediation-scripts on GitHub
3. License: MIT
4. Project website
5. README