How to document a Microsoft 365 tenant: what to capture and where to find it
Published
Most tenants are documented in the head of whoever set them up. That works until that person leaves, an auditor asks how sign-in is controlled, or an incident needs someone to say what normal looked like last month. A written, dated document of the tenant answers all three, and it takes less time to write than one bad handover costs.
Why write it down at all?
Three moments need it:
- A handover. A new administrator or a new service provider needs to know what exists and why before they change anything.
- An audit. The question is always "how is it configured?", and the answer has to carry a date.
- An incident. To find what an attacker changed, you need a record of what the settings were before.
The admin centers show the present only. A document is the record of a point in time, which is the part they do not keep.
What are the ten areas, and where does each live?
Capture them in this order. It runs from the outside of the tenant inward, so a reader meets the domains and the people before the policies that govern them. Each area names where it lives in the admin centers and one cmdlet that exports it.
1. Tenant overview
The organization name, tenant ID, data location, every verified domain with its purpose, and the workloads in use. In the Microsoft 365 admin center: Settings, Domains, and Settings, Org settings, Organization profile. Export with Get-MgDomain.
2. Identity and directory
Counts rather than names: users enabled and disabled, members and guests, groups by kind, app registrations with their owners and credential end dates, and whether accounts sync from on-premises or sign in through federation. In the Entra admin center: Users, Groups, and Applications, App registrations. Export with Get-MgApplication for the applications, the part most often missed.
3. Sign-in and access
The authentication methods policy, authentication strengths, security defaults, every Conditional Access policy and the named locations those policies refer to. In the Entra admin center: Protection, Conditional Access, Policies and Named locations. Export with Get-MgIdentityConditionalAccessPolicy, then Get-MgIdentityConditionalAccessNamedLocation, because a policy holds only the location's ID.
4. Mail flow
Accepted and remote domains, inbound and outbound connectors, transport rules, DKIM, and the SPF, DMARC and MX records as published in DNS. Draw how mail enters and leaves, including any third-party gateway. In the Exchange admin center: Mail flow, Rules and Connectors. Export with Get-TransportRule from the ExchangeOnlineManagement module.
5. Mail protection
Anti-spam, anti-malware, anti-phishing, Safe Links and Safe Attachments, preset security policies, quarantine policies and the tenant allow and block lists. In the Microsoft Defender portal: Email & collaboration, Policies & rules, Threat policies. Export with Get-AntiPhishPolicy, and note which policy applies to whom.
6. Information protection
Sensitivity labels and their policies, data loss prevention policies, and retention policies and labels. In the Microsoft Purview portal: Solutions, Information protection, Sensitivity labels. Export with Get-Label after Connect-IPPSSession.
7. Devices
Enrollment methods, compliance policies, configuration profiles, update rings, app protection policies, and device counts by platform and compliance state. In the Intune admin center: Devices, Compliance. Export with Get-MgDeviceManagementDeviceCompliancePolicy.
8. Collaboration
The organization's external sharing level, default link type, OneDrive sharing, Teams external access and guest access, and the meeting policies. In the SharePoint admin center: Policies, Sharing. Export with Get-SPOTenant; for Teams, Get-CsTenantFederationConfiguration covers external access.
9. Licensing
Each subscription with seats bought, assigned and unassigned, and which service plans are switched on or off. In the Microsoft 365 admin center: Billing, Licenses. Export with Get-MgSubscribedSku.
10. Administrators
Who holds each directory role, who is eligible through Privileged Identity Management, service principals that hold roles, and any partner relationships (GDAP). In the Entra admin center: Roles & admins. Export with Get-MgRoleManagementDirectoryRoleAssignment -ExpandProperty Principal. Add one line on whether the unified audit log is on (Get-AdminAuditLogConfig), since the administrators are the people it records.
How do you keep it dated and versioned?
A tenant document without a date is a guess. Give every version four things:
- A cover line with the tenant, the date, and the account that collected it.
- The raw exports next to the written document, as JSON in a dated folder or a Git repository, so the next version can be compared with this one.
- A change log at the end that lists what was added, removed or changed since the previous version.
- Notes on intent. The settings say what is configured. Only a person can say why a connector exists or which policy is the agreed exception, and that is the part a successor needs most.
Keep the document where the people who need it can read it and nobody else can. It is a map of your defenses. A document records how the tenant stood; it cannot put a setting back. For that you need a configuration backup taken alongside it.
What changes most often?
Domains and the tenant itself barely move. These do:
- Conditional Access exclusions. A user is excluded for a trip and never put back.
- Group membership and licensing. People join, move and leave every week.
- Mail flow rules and connectors. Added to get one message through, then left.
- App registrations. New integrations, new secrets, owners who have left.
- Role assignments. Temporary rights that became permanent.
Rewrite the document monthly if you can, quarterly at the least, and always after a migration, a merger, a change of service provider or an incident. The change log between two versions is often the most useful page: it shows what moved when nobody was watching.
Would you rather have it written for you?
If you would rather not collect and write this by hand, GlacierPoint Atlas writes these ten sections from one read-only run, in plain sentences, tables and diagrams, dated, as a PDF and a Word file. Information protection and collaboration arrive in its second release.
Checked against
- Microsoft.Graph.Identity.DirectoryManagement 2.x (
Get-MgDomain,Get-MgSubscribedSku) and Microsoft.Graph.Identity.Governance 2.x (Get-MgRoleManagementDirectoryRoleAssignment) - Microsoft.Graph.Identity.SignIns 2.x (
Get-MgIdentityConditionalAccessPolicy,Get-MgIdentityConditionalAccessNamedLocation) - Microsoft.Graph.DeviceManagement 2.x (
Get-MgDeviceManagementDeviceCompliancePolicy) and Microsoft.Graph.Applications 2.x (Get-MgApplication) - ExchangeOnlineManagement 3.x (
Get-TransportRule,Get-AntiPhishPolicy,Get-AdminAuditLogConfig,Connect-IPPSSession,Get-Label), Microsoft.Online.SharePoint.PowerShell (Get-SPOTenant) and MicrosoftTeams (Get-CsTenantFederationConfiguration) - Admin center paths: Microsoft 365 admin center (Domains, Organization profile, Licenses), Entra admin center (Users, Groups, App registrations, Conditional Access, Roles & admins), Defender portal (Email & collaboration, Policies & rules, Threat policies), Intune (Devices, Compliance), Exchange (Mail flow), Purview (Sensitivity labels), SharePoint (Policies, Sharing)