Command line

What this is

Since 1.0.0b10 the Engine installs two names for one command line, m365g and m365-governance. Everything the earlier name did still works, and the manual that documents it command by command is the documentation. The same release brought four things:

• Commands grouped by service. m365g spo site list is found by its service, then the thing, then what to do with it. Each grouped command is an earlier command by another name, and the earlier name keeps working.
• A sign-in that can be kept. m365g login signs in to one tenant and keeps the session, so the SharePoint and Microsoft Graph reads that follow do not ask again.
• Reads that answer in the terminal. A read prints a view of what it read, and keeps the evidence only where --evidence-out says.
• Composed inspections. m365g governance inspect external-access, m365g governance inspect ownership, m365g governance inspect app-exposure and m365g governance inspect ca-coverage each answer one question from collections that were already made, and reach no tenant. m365g governance inspect-diff compares two inspections of the same question.

Find what can be collected

Three commands say what the Engine can read, and none of them reaches a tenant.

m365g collector list shows every collector with the command that runs it and whether it has read a directory. This is what it printed from the Engine's source at the commit these pages were read from. No tenant is involved: the list is the Engine's own registry.

agents
  m365g spo agent list               read a directory

entra
  m365g entra app list               read a directory
  m365g entra ca list                read a directory
  m365g entra group list             read a directory
  m365g entra guest list             read a directory
  m365g entra serviceprincipal list  read a directory
  m365g entra tenant governance get  read a directory

exchange
  m365g exo forwarding get           read a directory

licensing
  m365g entra license list           read a directory for some of what it covers

sharepoint
  m365g spo activity get             read a directory
  m365g spo brandcenter get          read a directory
  m365g spo classification get       read a directory
  m365g spo customization get        read a directory
  m365g spo hub list                 read a directory
  m365g spo modernity get            read a directory
  m365g spo owner list               read a directory
  m365g spo permission list          read a directory
  m365g spo sharing get              read a directory
  m365g spo site list                read a directory
  m365g spo site guests              read a directory
  m365g spo site admins              read a directory
  m365g spo sharing list             read a directory
  m365g spo spfx list                read a directory for some of what it covers
  m365g spo tenant sharing get       read a directory

24 collectors: 22 read a directory, 2 read one for part of what they cover, 0 did not. `m365g collector describe NAME` says what each reads and what its proof did not cover.

Its closing line counts collectors by whether a read of a directory is on record, and that is all it counts.

m365g collector describe NAME adds what the collector reads, the permissions recorded for it, the rules it feeds and what its proof did not cover.

hubs  (m365g spo hub list)
  the sites registered as hubs, and how each is set.

  Service      sharepoint (powershell)
  Reads        Get-PnPHubSite
  Permissions  not-established
  Needs        --tenant-url
  Feeds rules  none
  Read by      the hub list an operator enumerates, and a report
  State        full: read a directory
  Proof        acquisition proven, evidence proven, assessment not-applicable, bundle not-attempted, consumer not-attempted

  What its proof did not cover:
    - a tenant with no hub has not been read: the zero the tenant document exists to carry is proved by a fixture only
    - neither hub has a parent hub and both restrict association, so the branches for a parent and for an unrestricted hub have not run against a directory
    - one listed hub was referenced by no enumerated site; whether it has no associated site or the delegated enumeration did not show one is not established
    - one directory, one moment: nothing here establishes how another tenant answers

The lines under What its proof did not cover come from the Engine's record of the read, and they are the part to read before relying on the collector. Permissions not-established is a statement too: no minimum permission has been recorded for this read, and the Engine does not supply one.

m365g collector test NAME is a contract test. It runs the collector's packaged fixtures against its contract and renders the view of each, and reaches no tenant. It prints two lines that are kept apart: CONTRACT, which is what the test established, and TENANT, which is the proof registry's record and which the test says it did not establish.

CONTRACT TEST  hubs  (m365g spo hub list)
  Fixtures only. No tenant is reached and none was read for this.

  ✓ tenant-hubs-two-registered  [synthetic]  valid against its contract; view renders
  ✓ site-hub-association-restricted  [synthetic]  valid against its contract; view renders

CONTRACT       2 of 2 fixtures hold
TENANT         full: read a directory
               (from the proof registry; this test did not establish it)

A collector no tenant had answered would pass the same test, and its TENANT line would say none. In this release every collector has a read on record, whole or in part, and the collector catalogue says which.

Every fixture is marked [synthetic]: it was written for the test and is not a read of anything. A green CONTRACT line is the stand-in holding. It is not a tenant answering.

The collector catalogue lists all of them with what each reads, needs and feeds, built from the same catalogue these commands print.

These commands report states apart and never add them. A collector is contract-tested when its behaviour is proved against a stand-in service, and tenant-verified when the Engine's proof registry holds a record of a real read, with what that read did not cover. That is the same distinction the labels on these pages make.

The earlier commands, under their grouped names

The regrouping gave a second name to commands earlier releases already had. Each row below is one of them, and both names work: the grouped name, and the earlier one, typed after m365g or after m365-governance. The command reference links each to its page in the manual.

What the labels mean

Every command on these pages carries one label. Being published and being proved are different things, and the label says both: every command here is in the published release, and the rest of the label says how far a real tenant has answered it.

• Published The release carries the command, and the Engine's reference records no validation state for it, so these pages claim none. A command that reads no tenant, such as status or collector list, is in this state.
• Published, tenant-verified The release carries the command, and the Engine records a read of a real tenant for it.
• Published, contract-tested only The release carries the command. It is proved against a stand-in for the service and has never read a tenant: tenant verification is pending.

Two more complete the set.

• Published, part contract-tested only A scenario reaches no tenant itself and stands on the collections it reads. This label says some of them are tenant-verified and at least one is contract-tested only. A scenario whose every collection is contract-tested only carries that label itself.

• Planned, not implemented The Engine has prepared the permissions for the read and has not built it. It cannot be run.

A command is called published because the Engine's reference these pages are built from is the published release's, at the revision this site mirrors, and tenant-verified only when that reference records a tenant read. Where a state cannot be established, the weaker label is used.

The pages

• Command reference: every command, what it reads, the permissions recorded for it, the rules it feeds and its label.
• Collector catalogue: every collector, with what it reads, the permissions recorded for it, what it needs, the rules it feeds, who reads it and what its proof did not cover.
• Minimum permissions: the scope each read asks for, that each asks only for its own, and what has not been decided.
• Authentication and sessions: how it is installed, login, status, connection and logout, where the sign-in is kept, the one sign-in that serves the SharePoint and Microsoft Graph reads, and the scope each Graph read asks for.
• Evidence and provenance: why a view is not the evidence, how to read a column, a value and a state in brackets, and how to narrow and order a view with --where and --sort.
• Enumeration: sites, hubs, sharing settings, administrators, the guests each site has met, guest accounts, application registrations, service principals, Microsoft 365 groups and the teams among them, with the output each command prints.
• External access: the first composed inspection: what is in force for a site, which guest accounts each site has met, and what the inspection does not establish.
• Ownership: the administrators each site names, compared with a number the operator chooses, with the owners of its Microsoft 365 group counted as a range where that group is what administers the site.
• Conditional Access policies: whom each policy names and leaves out, and whether it is enforced. The static scope of a definition, and not who a policy applies to.
• Application governance: which application registrations hold a credential that has ended or is about to, which of them can sign in to the directory at all, and what is deliberately never collected.
• Errors, partial coverage and limitations: a refused site, an unread site, a duplicate, and an empty directory.

About the examples

Every example uses the fictional organisation contoso.sharepoint.com and site names invented for these pages. The output was produced by the Engine's own code, offline, from evidence documents written for the purpose. No tenant was read to make them, and nothing in them describes a real organisation. Where a line of real output would carry an identifier, the example leaves the line out and says so.