DriftMaester 1.3.0

With Maester 2.2, we now finally have Sharepoint support and tests! And of course much more, but that’s what stood out most to me. (legacy active directory just makes me feel dirty).

So, DriftMaester also needs to handle these new permissions and has the new pnp module dependency! Time to update 🙂

DriftMaester auto updates, but it doesn’t have permissions to increase its own permissions. So, for whoever wants to leverage the new tests, run this quick oneliner in Azure Shell!

iex ((Invoke-WebRequest -UseBasicParsing 'https://raw.githubusercontent.com/jflieben/DriftMaester/main/Update-DriftMaesterPermissions.ps1').Content)

You can also run the full GUI again as it is a fully idempotent install (overwrite without delete):

iex ((Invoke-WebRequest -UseBasicParsing 'https://raw.githubusercontent.com/jflieben/DriftMaester/main/Install-DriftMaester.ps1').Content)

The full changelog of 1.2.0 to 1.3.0 is:

  • SharePoint Online support: the installer grants the managed identity the SharePoint Sites.FullControl.All application role, and the invoke runbook connects PnP.PowerShell to the tenant admin endpoint with that managed identity so the Maester SharePoint Online tests run unattended.
  • Reports now lead with the number of passed tests instead of the score percentage as this is more valueable when new tests are added
  • Fixed the ORCA tests failing with “Cannot find type [PolicyInfo]”. Maester is now imported at script scope in the invoke runbook, because its manifest loads the ORCA class definitions through ScriptsToProcess, which only defines them in the scope that called Import-Module.
  • The installer now reuses the Azure sign-in for Microsoft Graph by passing an Az-issued Graph token to Connect-MgGraph, so the admin signs in once instead of twice.
  • Centralized permissions and added a permissions reconciliation script (Update-DriftMaesterPermissions.ps1) that automatically adds new permissions and can be executed lightweight in Azure Shell

M365AutoRevocate

Offboarding has always been an interesting case, and one I rarely see customers do 100% right. The will is there, often focused on keeping access to data or reclaiming licenses.

But execution is a whole different world. Automation for onboarding often exists, offboarding rarely, and if it exists, it is usually still triggered manually, and more often than not only for managed accounts (admins, guests, service accounts etc are totally forgotten), and then what is actually done upon offboarding?

Microsoft Graph has an option to subscribe to changes, specifically for user objects. This means we can listen to deactivation, idle (x days inactive) or deletion events and act accordingly. E.g. unshare onedrive, notify a manager of flows and powerapps or teams the user still owns, reclaim licenses, disable upon inactve, etc etc.

So I co-wrote a little PowerShell solution, of course perfectly based on best practises around MI auth, least privileges and assume breach.

It lets you configure WHAT (loads of things, expandable) to do WHEN (inactive, delete, deactivate), and runs at almost no cost in your own azure subscription, as usual, open source and a oneliner to install: https://github.com/jflieben/M365AutoRevocate

DriftMaester 1.2.0

A nicer installer!

And more changes:

  • Installer hardening: storage security baseline, lifecycle retention policy, root-elevation cleanup by object id, access report output, and optional RunNow workflow.
  • Invoke runbook reliability: token refresh before post-processing, report-delivery modes, severity gating, failure notifications, retention cleanup, summary blobs for trend reads, and optional Teams webhook notifications.
  • Update runbook reliability: target runtime resolution now stays scoped to driftmaester runtime and adds Maester dependency compatibility auto-bump behavior.
  • Added Remove-DriftMaester uninstaller script for full or scoped cleanup.

DriftMaester EXO clash with az.storage fixed

Using PSPublishModule to load the Exo module has finally solved this error:

Get-EXOMailbox: Could not load file or assembly 'Microsoft.OData.Core, Version=7.22.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. The located assembly's manifest definition does not match the assembly reference. (0x80131040)

Get the PS runbooks / installer here: https://github.com/jflieben/DriftMaester

Or if you already run it, it’ll automatically update tomorrow 🙂

THOROUGH reporting of a fileshare before migration to Sharepoint and Teams

I’ve been doing a migration project these past months to Sharepoint / Teams.

And boy does the tooling provided suck, I mean…Sharegate / AvePoint are supposed to be a market leaders right? Well, I can tell you it looks more like a cashcow to me, one that’s as good as ready for slaughter.

We wanted to know what cleanup needs to be done by individual teams, we wanted to show reports to them with actionable details, give them a good overview of WHERE in their folder structure to act, and we wanted to see how they were doing over time.

Lots of users also have macro’s….what happens to those? Do they survive a migration, or break? This tool actually tells you by DETECTING the macro’s, then READING them to see if they have external references
(e.g. other files or databases) and flagging them in the report.

It also tells you where inheritance was broken, so you may need to account for that in where to migrate a folder.

And last but not least, it detects duplicate files…helping you save $$$$$

So, here’s a super fast (multi threading) PowerShell solution you can use to generate the type of reporting shown below! Use this, your users / staff will thank you 🙂

https://github.com/jflieben/assortedFunctionsV2/blob/main/FileServerToSPO/PreMigrationReport.ps1