# AdminDroid PowerShell Scripts: Microsoft 365 reporting and auditing without a GUI > A collection of over 100 self-contained PowerShell scripts for Microsoft 365 IT administrators. Each script targets a specific audit, report or management task and can be scheduled to run periodically. **admindroid-community/powershell-scripts** — Office 365 Reporting PowerShell Scripts - Repository: https://github.com/admindroid-community/powershell-scripts - Stars: 2,032 · Forks: 489 - Language: PowerShell - License: not declared - Published: 2026-10-09 · Updated: 2026-10-09 · Language: en - Canonical page: https://hysenlabs.com/projects/admindroid-community-powershell-scripts ## A script per task, with no shared runtime between them Over 100 scripts address a single goal: giving Microsoft 365 IT administrators a way to generate reports, run audits and perform bulk management operations from the command line. Each is described as self-contained. Self-contained is the design choice that shapes the entire collection. No shared module needs importing, no base class to extend and no configuration file to edit before the first run. Each script carries its own comments, parameters and usage examples. A script for auditing failed sign-in attempts in Entra and a script for exporting distribution groups are therefore independent pieces of code: copying one to a new machine does not require copying any other. Authentication is where that independence costs something. Connection steps are duplicated across scripts rather than centralised. Dedicated scripts for connecting to Exchange Online and for connecting to all Office 365 services exist in the repository, but both are utilities rather than a shared framework the audit scripts depend on. ## What the directory listing shows about scope Repository entries map the scope directly. Audit tasks cover file access in SharePoint Online, email deletion in Office 365, DLP rule matches in M365, group membership changes, admin activities, Teams channel creations, Teams membership changes, PIM role activations and deactivations, shared mailbox activities, Teams meetings, external sharing activity and compromised user activities from a specific session. Management tasks go further: automate user offboarding, automate compromised account remediation, convert distribution lists to M365 groups, convert external users into internal users in Entra, convert user mailboxes to shared mailboxes in bulk, copy membership and ownership between distribution lists, enable MFA for admin users, disable self-service purchase in M365, change bulk meeting ownership, auto-archive inactive Teams, delete older emails in Outlook and configure HTML email signatures in Outlook. Reporting covers MFA status via MS Graph, archive mailbox size, Azure AD devices, CA policies, Entra sign-in logs, Entra users, mailboxes in Exchange Online and distribution groups. Scope is wide, but every entry in the listing is a separate directory rather than a single file, which implies each task ships with its own supporting files. ## Parameters, switch parameters and scheduling are the documented usage model Usage is documented in three points in the README. Scripts are self-contained and include comments and usage examples. Most have built-in parameters and switch parameters for granular control over the Microsoft 365 environment. For detailed use cases, the README directs users to a linked blog post within each script. That last point matters in practice. Blog links inside each script are where documented edge cases and examples live, and the repository itself does not replicate that content. An administrator who needs to understand the exact parameters for a specific audit task should read the embedded link before running the script against a production tenant. Scheduling support is listed as a feature for most scripts, not all. According to the README, most scripts support scheduling capability to generate reports periodically. What most means in practice is determined by each script's own parameters, and CSV is the export format for all reports, which integrates with tools that already handle spreadsheet data. ## Connecting to M365 services is a prerequisite the collection handles separately Running any script against a Microsoft 365 tenant requires an authenticated session before the first command does anything useful. A dedicated directory for this step exists in the repository: Connect to All Office 365 Services PowerShell Script and Connect to Exchange Online PowerShell script are both present as top-level entries, alongside a script for connecting Microsoft Graph PowerShell and another for connecting MS Graph with a certificate and automating Azure app registration. Certificate-based connection is the more durable path for scheduled tasks. Interactive sign-in prompts cannot run unattended, so scripts intended for scheduling depend on service principal authentication. One top-level entry named Connect MS Graph with Certificate-Automate Azure app registration suggests the collection does address that pattern, but no steps are documented in the README itself. For an administrator setting up their first scheduled report, the connection scripts are the starting point, not the reporting scripts. No sequence or dependency map across them appears in the README. ## No license file in the repository metadata Repository metadata lists the license as unknown. No license name appears in the README, and no LICENSE file shows up in the repository's top-level entries. That gap is a practical issue for any organisation with a policy on open source licensing. Without a license, the default position under copyright law is that all rights are reserved by the copyright holder, which means copying or modifying the scripts requires permission beyond what GitHub's terms of service provide. Neither the README nor the directory listing addresses this, and no GitHub releases exist where a license is sometimes declared. Administrators who want to use the scripts in a regulated environment or distribute modified versions should check the repository's full file listing and the AdminDroid website for a license statement before assuming free use. ## AdminDroid's commercial tool lives in the same README, and the boundary is thin A section of the README describes AdminDroid's free Microsoft 365 administration tool, offering 120 essential reports, 60 key management actions and dashboards at no cost. Commercial features extend that to 3,000 pre-built reports, 100 dashboards, 450 management actions and 85 alert policy templates. A download link and a demo link both point to admindroid.com. Scripts in the repository are separate from that tool. An administrator who runs a script from this repository is running standalone PowerShell code against their tenant, not using the AdminDroid application. No disclaimer blurs that line explicitly, but placing the commercial section after the script documentation means a first-time reader encounters the upsell before reading much about the scripts themselves. For an administrator whose requirement falls within what the free AdminDroid tool covers, that tool may be a better fit than maintaining and scheduling individual scripts. For an administrator with a specific audit need that the tool's fixed report list does not match, a script from this repository is more adaptable. ## Where individual scripts fall short of a full automation pipeline Each script is self-contained, which is a useful property for testing a single task and a limiting one for building a workflow. Scripts do not share session state, so an automation that connects to Exchange Online, exports a mailbox report and then audits sign-in logs would establish separate authenticated sessions in sequence. No guidance on composing scripts, passing output from one to another or handling failures midway through a pipeline appears anywhere in the repository. Error handling is not described in the README. Claims about error reduction in the feature list refer to removing manual steps, not to exception handling in code. An administrator who needs a script to retry a failed connection, log failures to a central location or send an alert on a non-zero exit code will need to add that logic. Compared with a purpose-built compliance tool or a Microsoft-native solution such as Microsoft Sentinel or the Compliance portal, these scripts offer more control and less infrastructure. Microsoft's own reporting API, available through the Graph PowerShell SDK, provides the same data but requires writing your own PowerShell code. AdminDroid's collection sits in between: pre-written scripts that target specific tasks, but with no alerting, dashboarding or centralised logging on top. ## Last push on 2026-09-16 and no versioned releases A push landed on 2026-09-16, which is under six months before today. It is not archived. No GitHub releases exist, which means no version number is available to reference in a change log or a bug report, and no tagged snapshot to pin if a script changes in a way that breaks an existing scheduled task. Without releases, there is no formal upgrade path for an organisation that copied scripts at a particular point in time. If a script changes to handle a Microsoft API deprecation, a tenant that pinned the old copy will not receive that update automatically. Administrators who depend on scheduled scripts for compliance reporting should check the repository for changes whenever Microsoft announces API or service changes that affect the relevant workloads. ## Conclusion Use these scripts if you manage a Microsoft 365 tenant and need audit logs, compliance reports or bulk management tasks without paying for a third-party tool. They are not a fit if you need a centralized dashboard, alerting or a visual interface, since the repository contains only scripts and no orchestration layer. Before committing a script to a production task, read the linked blog post inside it for documented edge cases, and verify that its permission requirements match your tenant's conditional access policies. ## FAQ ### What are the AdminDroid PowerShell scripts? A collection of over 100 self-contained PowerShell scripts for managing, reporting and auditing Microsoft 365 tenants. Each script targets a specific task, includes its own comments and usage examples, and exports results as CSV files. ### How do I use the AdminDroid PowerShell scripts? Each script is self-contained and runs independently. According to the README, most scripts have built-in parameters and switch parameters, and each includes a link to a blog post with detailed use cases. A connection script for Exchange Online or all Office 365 services is the usual starting point. ### Do the AdminDroid PowerShell scripts support scheduling? According to the README, most scripts support scheduling capability to generate reports periodically. The README does not specify which scripts lack scheduling support. ### What license do the AdminDroid PowerShell scripts use? Repository metadata lists the license as unknown. No license name appears in the README and no LICENSE file appears in the repository listing. Check the repository directly or contact AdminDroid before redistributing modified scripts. ### What is the difference between the scripts and the AdminDroid tool? Scripts in the repository are standalone PowerShell files that run against a Microsoft 365 tenant from the command line. AdminDroid's tool is a separate GUI application with pre-built reports and dashboards, available as a download from admindroid.com. ## Sources - [admindroid-community/powershell-scripts on GitHub](https://github.com/admindroid-community/powershell-scripts) - [Issues](https://github.com/admindroid-community/powershell-scripts/issues) - [README](https://github.com/admindroid-community/powershell-scripts/blob/master/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/admindroid-community-powershell-scripts