M365Documentation turns a tenant into a Word file you can hand to an auditor

The report is a by-product of reading the tenant

The module is described as automatic Microsoft 365 documentation to simplify the life of admins and consultants, and the systems it can document are listed: Microsoft Intune, Microsoft Entra ID, Microsoft Cloud Print, Microsoft Information protection and Windows 365, with the note that this list will expand in the near future. The audience is the consultant who is asked what is configured in a tenant, and the administrator who has to prove it. The mechanism is a collection run rather than a template, so the document is a rendering of the live configuration, and that has a consequence worth holding on to. The output describes what is, and it is not a compliance verdict. The project describes itself as the successor to the IntuneDocumentation module, with many more options, and says that through the new architecture much other features will follow in the near future, which is a fair signal that the current feature set is the first generation rather than the finished one.

The JSON output is the part that keeps paying off

Five output formats are supported, and the README singles one out for a reason. Output to JSON lets you back up your configuration and create documentation later, and lets you compare your configuration over time, for example with JSON Diff or the JSONViewerTool JSON Compare service. The other formats are for humans, CSV, Markdown or MD, and HTML, and for Word documents through the PSWriteOffice module. The distinction is the useful idea in the whole project. A consultant who visits a client site twice can diff the two JSON exports and say exactly which policies, assignments or device categories changed in between, and a document is then generated from the current state. The README frames it as a way to avoid writing the same documentation twice, and the JSON path is what makes that true rather than merely convenient.

Authentication is delegated to MSAL.PS, with certificates or secrets

Flexible Authentication with MSAL.PS is listed as a feature, with support for certificate and secret based authentication. That choice is the right one for a tool that has to run inside a customer's tenant, because MSAL.PS is the standard Microsoft Authentication Library PowerShell module, so the sign-in flow, the consent behaviour and the token handling are the ones an administrator already knows from the Graph modules. The choice between a certificate and a client secret is the same choice every unattended Graph script makes, and the module does not force the choice on you. The advanced usage document in the repository covers creating your own app registration, which is the part that matters when the tool has to run on a schedule or from a service account rather than from an interactive session.

Installation is three module installs and a version floor

The required modules are available in the PowerShell Gallery, which makes the install short:

Install-Module MSAL.PS
Install-Module PSWriteOffice -MinimumVersion 1.0.2
Install-Module M365Documentation

PowerShell 7 is required, and there is a second requirement that is easy to miss. Word export requires PSWriteOffice 1.0.2 or later, and older PSWriteOffice releases, including 0.2.0, are no longer supported. After updating PSWriteOffice you have to start a new PowerShell session so the new assemblies are loaded, and the README notes that Word export has been tested with PSWriteOffice 1.0.2 and 3.0.8. That combination of a version floor and a session restart is the sort of detail that costs an afternoon when it is unknown, so it is worth reading before you plan a rollout.

The workflow is connect, select, collect, write

The basic usage section covers the interactive path, and it is four steps with one of them being a picker. You connect to the tenant with Connect-M365Doc, then you choose what to document:

# Connect to your tenant
Connect-M365Doc

# Collect information 
$Selection = Get-M365DocValidSection | Out-GridView -OutputMode Multiple
$Sections = $Selection | Select-Object -ExpandProperty SectionName
$Components = $Selection | Select-Object -ExpandProperty Component -Unique
$doc = Get-M365Doc -Components $Components -IncludeSections $Sections

# Output the documentation to a Word file
$doc | Write-M365DocWord -FullDocumentationPath "c:\temp\$($doc.CreationDate.ToString("yyyyMMddHHmm"))-WPNinjas-Doc.docx"

The Out-GridView call is what makes the selection interactive, and the output splits it into a set of components and a set of section names, which are the two arguments the collector takes. The final line names the file with a timestamp taken from the document's own creation date, so repeated runs do not overwrite each other. The advanced usage guide is where the same pieces are assembled without a window, which is what you need if you want this to run on a schedule rather than at a desk.

The section catalogue is what makes the module concrete

The README lists the sections you can choose from, grouped by component, and that list is the real specification of what the module can read. Under AzureAD there are entries such as AADConditionalAccess, AADDomain, AADOrganization, AADPolicy and AADDirectoryRole. Under CloudPrint, CPConnector and CPPrinter. Under InformationProtection, MIPLabel. Under Intune, a long list of Mdm prefixed entries covering configuration profiles, compliance policies, enrollment configuration, roles, shell and PowerShell scripts, security baselines, Apple configuration, Windows Update and device categories, alongside MobileApp, MobileAppConfiguration and MobileAppManagement. Under Windows365, W365Image, W365OnPremConnection, W365ProvisionProfile and W365UserSetting. The command Get-M365DocValidSection is the authoritative list, and the README gives a worked example of using it with the Intune component. The catalogue also tells you where the gaps are, since a section that is not listed is a section the module will not produce.

What each documented entity actually covers

The supported components section goes one level deeper than the section names, and it is where the differences between a document and a screenshot appear. For Intune the documented entities include configuration policies, compliance policies, device enrollment restrictions, terms and conditions, applications but only assigned ones, application protection policies, AutoPilot configuration, enrollment page configuration, the Apple push certificate, Apple VPP, device categories, the Exchange connector, application configuration, PowerShell scripts, ADMX backed configuration profiles, security baselines and custom roles. For Azure AD the list includes conditional access policies, domains, feature rollout policy, authentication policies, role assignments and PIM roles, mobile device management policies, subscriptions and SKU, organizational settings and administrative units, and notably a step that translates referenced IDs to real object names for users, groups, roles and applications, which is the difference between a report an auditor can read and a dump of GUIDs. Cloud Print covers printers, connectors and printer shares, Information Protection covers labels, and Windows 365 covers device images, provisioning profiles, user settings and on-premises connections.

A translated module, a custom licence, and a repository that is not the module

Three details about the repository itself are worth noting before anyone depends on it. First, the module is translated: the repository carries an AddTranslation.md file and a M365Doc.Translation directory, and the README thanks a contributor for continuous feedback and 10000 translations, so the module is presumably localised for a large set of locales rather than English only. Second, the licence is one GitHub could not classify, and the README points to the LICENSE file, so read that before redistributing. Third, the repository is not the module itself. The top level holds a PSModule directory, images, a logo, the AdvancedUsage and AddTranslation documents and a ReleaseNotes file, which is the layout of a documentation and packaging repository rather than the source of a large application. The releases are not tagged in GitHub either, so the version history lives in ReleaseNotes.md, and the last push was on 2026-10-09, which is recent enough that the module is being worked on rather than archived.

Editorial conclusion

Adopt M365Documentation if you are a Microsoft 365 administrator or consultant who has to produce evidence of a tenant configuration, especially if you want to keep the JSON and diff it over time rather than write the same report again each quarter. Do not adopt it as a monitoring or compliance product, since it is a module you run and it reports what exists rather than what should exist, and the README says further features are still to follow. Before you use it, confirm your sign-in can read the sections you intend to document, check the PowerShell and PSWriteOffice version requirements, and read the LICENSE file, since the repository licence is one GitHub could not classify.

Frequently asked questions

Official sources

1. Issues
2. README
3. ThomasKur/M365Documentation on GitHub