LazyAdmin: a folder of PowerShell scripts organised by Microsoft product

A scripts folder, not a tool with an install step

LazyAdmin is described in one line as scripts for you to use, and the repository description says the same: SysAdmin scripts for you to use.

The project description adds that the repository contains a number of scripts the author has written or enhanced to make day to day life easier for system administrators, and that they are provided for free to the community under the MIT Licence. The topic tags line up with the content: devops, devops-tools, powershell, powershell-script, sysadmin and sysadmin-scripts.

There is no package to install and no module to import. The documented way to use a script is to copy it onto your workstation and open the PowerShell window in that location. The README points to a separate article on the author's blog about running PowerShell scripts for the details, and mentions that you should make sure Set-ExecutionPolicy is set to RemoteSigned or Bypass before you launch PowerShell.

That is the whole onboarding. It also tells you what kind of project this is. There is no CLI, no configuration file, no release artefact, no test suite visible in the tree, and no versioned API. It is a well-curated folder of scripts that have been run in anger by one administrator, published so that others can take the parts they need.

Whether that is a good thing depends entirely on your question. If you are looking for a tool to install, this is not it. If you are looking for the answer to a problem you have already hit, there is a reasonable chance someone has already solved it here.

The primary language is recorded as JavaScript, which is likely the language of the tooling around the scripts rather than the scripts themselves.

The directory names are the map of what it covers

Because the repository has no code listing beyond its folders, the top level directory listing is the most informative artefact available, and it reads as a map of a Microsoft-centric administration estate.

There is a directory for ActiveDirectory, and a separate one for AzureAD, which is a distinction that matters and which a script collection can easily get wrong. There is an Exchange folder, a Graph folder and a separate MsGraph folder, so the older Graph APIs and the Microsoft Graph are treated as distinct areas. Office365, Teams, SharePoint and Intune Policies each have their own place.

Then the categories turn away from Microsoft. There is a Home Assistant folder, a SmartMirror folder, a UniFi VPN Client folder, and a Phishing Mail Warning folder. Those four suggest the collection extends past a single vendor's stack, which is consistent with the origin story: a working administrator's scripts, not a productised suite.

The Windows platform has two directories, Windows 10 and Windows 11, which is a hint about how the scripts are versioned by target rather than by function. There is a PowerShellBasics folder, and there is a RemoveOldFiles folder.

Two more entries stand out for what they reveal about the author's working practice. There is a PowerShell Profile.ps1 at the root of the repository, which means the dotfiles are published alongside the scripts, so you can see the profile configuration the author actually runs with. And there is an Azure Runbook folder, which is the one place where the collection starts to look like an operations artifact rather than a personal helper.

For a reader deciding whether to look further, that listing is the answer: if your estate looks like this, keep reading; if your estate is Linux-first or cloud-native, this is not your repository.

A profile file and a .ignore file suggest a working environment, not a product

Two small files in the tree tell you more about how the project is maintained than the README does.

The first is the PowerShell Profile.ps1 at the repository root. A PowerShell profile is the file that runs when you start a shell, holding the aliases, functions, modules and prompt settings a person has accumulated. Publishing it means the author's own environment is part of the repository, which is useful context when you read a script and find it depending on a helper function that you do not have. It also tells you the scripts are meant to be read in the context of a configured workstation, not dropped onto a clean server.

The second is the .ignore file alongside the standard .gitignore, and there is a .vs/ directory, which is the Visual Studio workspace folder. Together they suggest a working setup with editor state and ignore rules maintained alongside the code.

The consequence for an adopter is specific. If a script in this repository calls a function that the author's profile defines, copying the script alone will not work, and the failure will look like a missing command rather than a missing file. The repository does not document a dependency manifest for the scripts, so the way to find out is to read the script and check what it imports.

This is the pattern of an experienced administrator's script drawer, and it is worth being clear-eyed about it. A script drawer is a source of working code. It is not a supported library, and the cost of using it is that you now own the script.

The contribution model is a fork and a pull request to one person

The contribution instructions are short and set the tone for the whole project.

The README says to create a fork of the project into your own repository, make all your necessary changes, and create a pull request with a description of what was added or removed and details explaining the changes in lines of code. If approved, the author will merge it.

Three things follow from that description. The author reviews and merges, so the project has a single maintainer and a single approval path. The pull request is expected to describe what changed and why, in terms of lines of code, which is a review standard closer to a code contribution than to a bug report. And there is no issue tracker guidance, no roadmap and no discussion of feature requests, so the repository reads as an accumulation of solved problems rather than a project with a plan.

For a would-be contributor, the practical implication is that your change will be judged on whether it fits the collection. A script that belongs in the ActiveDirectory folder will be more welcome than a general-purpose framework, because a framework changes the character of the repository from a script drawer into something that needs its own maintenance.

The last push to the repository was on 2026-09-10, and there are no GitHub releases. For a collection of scripts, that combination is less alarming than it would be for a library, since scripts do not have breaking version changes. It does mean there is no way to say which revision of a script you are running except by the commit you pulled.

MIT with the no warranty clause spelled out in full

The licensing section in the README reproduces the MIT licence text, and the notable part is the second paragraph.

The first sentence is the standard disclaimer that the software, the scripts in this case, are provided as is, without warranty of any kind, express or implied, including but not limited to the implied warranties of merchantability, fitness for a particular purpose and non-infringement. Then comes the limitation of liability, and the author adds a phrase you do not often see: the software is provided for free to the community under an MIT License.

The reason to read that closely is that these scripts do privileged things. A script in the ActiveDirectory or AzureAD folder may modify directory objects. A script in the StaffOffboarding folder may revoke access. An Intune Policies script may change what devices are allowed to do. The MIT licence means you are responsible for what a script does to your estate, and in a domain environment the blast radius of a bad script is the estate.

The repository description also mentions the licence file location, and the top level carries a LICENSE file, so the terms are in the place you would look for them.

The practical reading is not that the licence is unusual, it is that it is unusually explicit for a script collection. It is a strong signal that these scripts are offered as starting points rather than as products, and that the review step when you copy one belongs to you.

Where LazyAdmin is the wrong tool

The first wrong-tool case is a team that needs automation with a contract. There are no releases, no version numbers to pin, no changelog and no support commitment. If you are building a pipeline that runs unattended, a script pulled from a repository with a single maintainer and a no warranty disclaimer is not a dependency you want, and the absence of releases means you cannot even pin to a known good revision by tag.

The second case is a non-Windows estate. The whole collection is PowerShell against Microsoft administration surfaces, so a Linux or macOS team gets nothing from it, and even a mixed estate will find that the platform-specific directories, Windows 10 and Windows 11, mean the scripts are not portable across client versions either.

The third case is a team that wants a managed device posture rather than a set of admin chores. The Intune Policies folder is about the administrator writing policy, and the UniFi VPN Client folder is about a site to site client. If your requirement is an Intune configuration as a managed baseline that Compliance reports on, a hand written script in a repository is the wrong artefact, and the licensed product route is the right one.

The fourth case is anyone who wants a single tool rather than a drawer of scripts. If you are hoping to install one thing and get a maintained set of commands, that is a different category of software and this is not in it.

On the positive side, the risk profile is better than most of the alternatives in this category, and it is worth being specific about why. You can read every line before you run it. There is no install step, so there is no supply chain to trust. And copying a script into your own repository is exactly how you are meant to use it, which means the usual objection to running someone else's administration code, that you cannot see what it will do, does not apply here.

Editorial conclusion

LazyAdmin suits a Windows administrator who recognises a problem they have solved before and wants a working starting point for a script, since each file is a plain PowerShell script you can read, copy and edit rather than a dependency you have to adopt. It does not suit a team that wants a supported automation product with versioned releases, because the repository has no GitHub releases and the scripts carry the no warranty disclaimer of the MIT licence. Before copying anything, read the script to see which modules it assumes, check the execution policy requirement on the target machines, and note that the last push was on 2026-09-10, so confirm the file you are about to run matches the platform you are running it on.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. ruudmens/LazyAdmin on GitHub