Exchange Online is finally fixing this. Message center item MC1227623 announces a new PowerShell cmdlet, Invoke-ChangeMeetingOrganizer, rolling out worldwide between late June and July 2026 (GCC High and DoD follow through August). It transfers an existing meeting or series to a new organizer, who then gets full control: recurrence, attendees, description, everything. A user-facing version in Outlook and Teams is promised for later; the admin cmdlet arrives first, enabled by default, no configuration required.

This post covers how the transfer behaves, the gotchas that are easy to miss, a wrapper script that makes it safe to run, and the one thing that will stop you cold if you try it too early.

How the transfer behaves

The one-liner is simple enough:

Invoke-ChangeMeetingOrganizer -Identity frank@contoso.com -EventId AAMkAGRlMGI0 -NewOrganizer adele@contoso.com

Identity is the mailbox of the current organizer, EventId identifies the meeting, NewOrganizer is the receiving mailbox. The cmdlet supports -WhatIf and -Confirm, which you should absolutely use given what it touches.

The interesting behaviour is in what happens around that call:

• The transfer splits the series on a date. With -TransferSeriesStartDate you pick the effective date. Instances before that date stay untouched in the old organizer's calendar; everything from that date moves to the new organizer. Meeting history is preserved instead of orphaned. Note that this date cannot be in the past: the cmdlet rejects a start date earlier than today, so when in doubt, use tomorrow.
• Attendees inside your tenant notice almost nothing. Their existing calendar items are silently updated with the new organizer. No re-RSVP, and their personal tweaks to the item, such as reminder, category, show-as and private flag, survive.
• Attendees outside your tenant get the noisy version. They receive a cancellation truncating the old series, followed by a fresh invitation to the new one, plus extra messages for any series exceptions. They must re-accept. If your recurring meeting has external guests, plan the transfer and warn them.

The two gotchas in the design

The previous organizer is dropped from the meeting. After the transfer, the old organizer is no longer an attendee on the transferred portion. For offboarding that is exactly right. For a role change where the person still needs to attend, the new organizer has to re-invite them manually. Easy to miss, awkward to discover live.

Identifying the right meeting has sharp edges. The cmdlet takes either -EventId or -Subject. -Subject is the convenient path: match exactly one meeting and it transfers; match several and the cmdlet refuses to guess, returning the list of candidates so you can rerun with the precise -EventId. That is genuinely helpful, but two things bite. Subjects are rarely unique across a mailbox's history, so the ambiguous case is often the norm, not the edge. And the docs are explicit that -EventId "must identify the recurring series, not an individual instance" — hand it an instance id and it fails. The subject match is also scoped tightly: it only looks at meetings on the default calendar where -Identity is the actual organizer, so a meeting that mailbox merely attends returns No calendar events were found, not a hit. So a safe transfer is less a one-liner and more: try by subject, read what comes back, and confirm before committing.

Which is exactly what the script below wraps.

A wrapper that makes the transfer safe

You could call Invoke-ChangeMeetingOrganizer -Subject ... directly. This wrapper adds the guardrails you want around something irreversible: it verifies both mailboxes before touching anything, lets you drive the transfer by subject or by an exact EventId, keeps -WhatIf working end to end, and fails loudly instead of printing a cheerful success over an error. It needs a single module, ExchangeOnlineManagement — the cmdlet finds the meeting itself, so there is no second module to install and no second source of truth to drift.

#Requires -Modules ExchangeOnlineManagement

<#
.SYNOPSIS
    Transfers meeting ownership in Exchange Online, safely.
.DESCRIPTION
    Wraps Invoke-ChangeMeetingOrganizer. Identify the meeting by -Subject (the
    cmdlet transfers it when exactly one matches, or returns the candidates so
    you can pick) or directly by -EventId. Validates both mailboxes first and
    supports -WhatIf end to end.
.EXAMPLE
    .\Transfer-MeetingOrganizer.ps1 -CurrentOrganizer frank@contoso.com `
        -NewOrganizer adele@contoso.com -Subject "Weekly stand-up" -WhatIf
.EXAMPLE
    .\Transfer-MeetingOrganizer.ps1 -CurrentOrganizer frank@contoso.com `
        -NewOrganizer adele@contoso.com -EventId AAMkAGRlMGI0
#>
[CmdletBinding(SupportsShouldProcess, DefaultParameterSetName = 'BySubject')]
param(
    [Parameter(Mandatory)] [string] $CurrentOrganizer,
    [Parameter(Mandatory)] [string] $NewOrganizer,
    [Parameter(Mandatory, ParameterSetName = 'BySubject')] [string] $Subject,
    [Parameter(Mandatory, ParameterSetName = 'ByEventId')] [string] $EventId,
    [datetime] $TransferFrom = (Get-Date).Date.AddDays(1)
)

$ErrorActionPreference = "Stop"

# 1. Both mailboxes must exist before we touch anything
foreach ($upn in $CurrentOrganizer, $NewOrganizer) {
    $null = Get-EXOMailbox -Identity $upn
    Write-Host "  [ok] mailbox found: $upn"
}

# 2. Let the cmdlet identify the meeting: by EventId directly, or by Subject
#    (it transfers a single match, or returns the candidates to choose from).
$params = @{
    Identity                = $CurrentOrganizer
    NewOrganizer            = $NewOrganizer
    TransferSeriesStartDate = $TransferFrom
    Confirm                 = $false
    ErrorAction             = 'Stop'   # so "action is disabled" actually stops us
}
if ($PSCmdlet.ParameterSetName -eq 'ByEventId') {
    $params.EventId = $EventId
    $label = "EventId $EventId"
} else {
    $params.Subject = $Subject
    $label = "subject '$Subject'"
}

# 3. Transfer, honouring -WhatIf all the way down
$doel = "$label organised by $CurrentOrganizer -> $NewOrganizer, effective $($TransferFrom.ToShortDateString())"
if ($PSCmdlet.ShouldProcess($doel, "Transfer meeting organizer")) {

    $result = Invoke-ChangeMeetingOrganizer @params

    # A single-match transfer returns nothing. An ambiguous -Subject returns the
    # candidate meetings instead of acting, so surface them and stop.
    if ($result) {
        Write-Warning "Subject '$Subject' matched more than one meeting. Nothing was transferred."
        Write-Host   "Pick the right EventId below and rerun with -EventId:`n"
        $result | Format-List *
        return
    }

    Write-Host "`nTransferred: $doel"
    Write-Host "Remember:"
    Write-Host "  - $CurrentOrganizer is NO LONGER an attendee; re-invite manually if needed."
    Write-Host "  - External attendees receive a cancellation plus a new invite and must re-accept."
}

A few deliberate choices in there. The mailbox check up front fails fast on typos, before anything irreversible. Identifying the meeting is left to the cmdlet itself — -Subject for convenience, -EventId when you already know it — which is what drops the second module. Parameter sets make -Subject and -EventId mutually exclusive, so you cannot accidentally pass both. When a subject is ambiguous the cmdlet returns the candidates rather than acting; the script surfaces that list and stops, so you rerun with the exact -EventId instead of transferring the wrong series. Finally, -ErrorAction Stop on the transfer means a failure actually stops the script, rather than printing a cheerful "Transferred" over the top of an error, which is exactly the trap the next section is about.

The one that will stop you cold

Here is the thing the announcement does not tell you clearly enough: the cmdlet can be present in your module and still refuse to run. Run it before the feature has landed in your tenant and you get:

Invoke-ChangeMeetingOrganizer: ||Transfer meeting action is disabled.

That is not your session, your permissions, or your script. It is the MC1227623 rollout still in flight. The cmdlet ships with the Exchange Online module ahead of the server-side capability, so the command exists, accepts your parameters, resolves the meeting, and then the service declines at the last step.

Two things worth knowing here. First, there is no organisation-level switch to flip while you wait. Checking for one comes back empty:

Get-OrganizationConfig | Format-List *MeetingOrganizer*, *ChangeMeeting*
# (no matching properties)

No property means no toggle: this is purely gated by the rollout, not by a setting you forgot. Second, this is precisely why the script uses -ErrorAction Stop. Without it, Invoke-ChangeMeetingOrganizer writes "action is disabled" as a non-terminating error and the script sails on to print "Transferred" underneath, telling you the transfer succeeded when it did nothing. Fail loudly, or you will trust a lie.

So if you are reading this during the rollout window and hit "action is disabled": the plumbing is correct, the service simply is not ready. Try again in a few days with the exact same call.

One more trap from that same window, and this one wastes an afternoon if you let it: the disabled state does not always surface as the clean message above. The exact same call comes back sometimes as Transfer meeting action is disabled, and sometimes, with nothing changed, as a generic:

A server side error has occurred because of which the operation could not be completed. Please try again after some time. If the problem still persists, please reach out to MS support.

That message all but tells you to open a support ticket. Don't, yet. It is intermittent: during the rollout the service is simply unreliable about how it reports a feature that is not switched on, and repeating the identical call often returns the real reason instead. Do not expect -Verbose to save you here, either. It shows the HTTP round-trip, which is reassuring, but the same call under -Verbose still returns the bare "server side error" as often as not, because the wording is the server's choice, not yours. During the rollout window, read a "server side error" on an otherwise valid call as one more spelling of "not ready", not as a bug to escalate.

Make it part of offboarding, not firefighting

The real value of this cmdlet is not the one-off rescue, it is closing a structural gap. Offboarding processes are usually solid on licences, group memberships and mailbox conversion, and silent on the recurring meetings a person owns. Those only surface weeks later, when someone tries to move the stand-up and cannot.

So add one line to the offboarding checklist: transfer or cancel the recurring meetings this person organises. Transferring a series you can already name is the script above. Finding them all in the first place is a different job — the transfer cmdlet only acts on a meeting you can identify — so discover the mailbox's meetings first with Get-CalendarDiagnosticObjects, which stays inside the same Exchange module. Run it during offboarding, transfer what should live on, cancel the rest, and the three-year-old zombie series never gets the chance to exist.

Sources: MC1227623, Invoke-ChangeMeetingOrganizer on Microsoft Learn, Roadmap 554937.

Why this is a real risk

A shared mailbox is supposed to be a mailbox without an owner: people access it through their own account with delegated permissions. The underlying Entra account is a technical by-product and should be blocked for sign-in. In practice, this goes wrong in two ways:

• Converted mailboxes. An employee leaves, the mailbox is converted to shared "so we can still get to it". The account stays enabled, the password stays valid, and sometimes even the license lingers. You now have a sign-in-capable account that nobody is watching anymore, often without MFA registration from an active owner.
• Manually created mailboxes where the "block sign-in" step was skipped. The password is system-generated and unknown, sure, but unknown is not the same as unusable: whoever has the rights to reset passwords has an inconspicuous way in.

For those who think in framework terms: this directly touches the management of inactive accounts and least privilege. An auditor who asks about this does not want to see a policy, but a list. We are going to make that list now.

The measurement

The nasty part is that you cannot see this in a single console. Exchange knows the mailbox, Entra knows the account and the licenses. So: pull the shared mailboxes from Exchange Online, per mailbox do the crosswalk to Entra via the ExternalDirectoryObjectId, and check AccountEnabled and the licenses there.

# Required: ExchangeOnlineManagement and Microsoft.Graph.Users
Connect-ExchangeOnline
Connect-MgGraph -Scopes "User.Read.All","Directory.Read.All"

# 1) All shared mailboxes from Exchange
$shared = Get-EXOMailbox -RecipientTypeDetails SharedMailbox -ResultSize Unlimited |
    Select-Object DisplayName, PrimarySmtpAddress, ExternalDirectoryObjectId

# 2) Crosswalk to Entra: is the account enabled, and are there licenses attached?
$report = foreach ($m in $shared) {
    try {
        $u = Get-MgUser -UserId $m.ExternalDirectoryObjectId `
             -Property Id, DisplayName, AccountEnabled, UserType, AssignedLicenses

        [pscustomobject]@{
            Mailbox        = $m.DisplayName
            Address        = $m.PrimarySmtpAddress
            AccountEnabled = $u.AccountEnabled
            Licenses       = @($u.AssignedLicenses).Count
            Verdict        = if ($u.AccountEnabled)              { "SIGN-IN ENABLED" }
                             elseif (@($u.AssignedLicenses).Count) { "LICENSED" }
                             else                                  { "OK" }
        }
    }
    catch {
        [pscustomobject]@{
            Mailbox = $m.DisplayName; Address = $m.PrimarySmtpAddress
            AccountEnabled = $null; Licenses = $null
            Verdict = "Not found in Graph"
        }
    }
}

# 3) Worst cases on top, and record the results
$report | Sort-Object Verdict | Format-Table -AutoSize
$report | Export-Csv .\shared-mailbox-measurement.csv -NoTypeInformation -Encoding UTF8

Reading the result

The Verdict column tells you where the work is:

Blocking is a single line:

Update-MgUser -UserId <objectId> -AccountEnabled:$false

And to those who think "we catch this with Conditional Access": maybe. But a blocked account is a guarantee, a CA policy is a configuration that can change. For accounts that should never sign in, the block is the only correct layer, with CA as the safety net on top of it, not the other way around.

From measurement to assurance

Running this script once gives you a cleanup action. The real gain is in repetition: every mailbox converted after today reintroduces the risk. So schedule the measurement periodically, or better: make blocking the account a fixed step in your offboarding and conversion process, and use the measurement as a check on that. Policy says what should happen; the export shows what has happened.

Questions about this script, or want to know how something like this fits into a broader baseline assessment? Let me know.

I work daily in Microsoft 365 environments where compliance is not a paper exercise but a requirement: BIO2, NIS2, and the Dutch Cybersecurity Act. What stands out most in that work is the gap between thinking everything is configured correctly and being able to prove that it is. Almost every organization has policies. Far fewer organizations can demonstrate, on any random Tuesday afternoon, that their tenant actually complies with those policies.

That gap is what this blog is about.

What you'll find here

The topics will be familiar if you've already looked around this site:

• Microsoft 365 governance: ownership, lifecycle management, external sharing, and why a decision log is often more valuable than a thick policy document.
• Compliance frameworks in practice: what BIO2 and NIS2 actually mean for a Microsoft 365 tenant, translated into configuration instead of intention.
• Automation with PowerShell: measuring configuration instead of assuming it, using tools such as Microsoft365DSC, Microsoft Graph, and the familiar PowerShell modules.
• Azure: where it intersects with the modern workplace, from Conditional Access to logging.

You won't find rewrites of product announcements or "10 tips" listicles. Instead, you'll find real-world scenarios I've encountered, worked out into something you can reproduce yourself.

Publishing cadence

I'm aiming for a weekly schedule, with the usual caveat that client work comes first. If you don't want to miss a post, there's an RSS feed, and I announce the larger articles on LinkedIn.

Have a question or a topic you'd like to see covered? Get in touch.

There is one small piece of friction, though. Maester lets you override the severity and the title of every test through a maester-config.json file. Maintaining that JSON by hand is tedious, error-prone, and worst of all it silently drifts out of sync with your actual tests the moment someone adds a new one.

This post shows a tiny PowerShell script that removes that friction entirely: it reads your test files, figures out which tests exist, looks up the severity for each of them, and writes a fresh maester-config.json for you. Run it as part of your build and the config can never fall behind again.

The problem in one picture

Maester's per-test overrides live in a file that looks roughly like this:

{
  "TestSettings": [
    {
      "Id": "MFA-001",
      "Severity": "Critical",
      "Title": "MFA-001 - Require MFA for privileged roles"
    },
    {
      "Id": "SPO-004",
      "Severity": "Medium",
      "Title": "SPO-004 - Restrict external sharing"
    }
  ]
}

Every object binds a test Id to a Severity (Critical, High, Medium, Low, Info) and a display Title. Maester uses those values when it renders the report and when it decides how loud a failure should be.

Now imagine a repository with dozens of custom tests spread across many files. Keeping this list correct by hand means:

• Remembering to add an entry every time you write a test.
• Removing entries for tests you deleted.
• Keeping the title in the JSON identical to the title in the test.
• Never fat-fingering a severity.

That is exactly the kind of bookkeeping a computer should do.

The idea

The trick is to treat your test files as the single source of truth and generate the config from them. That only works if your tests follow a small, predictable naming convention. A convention like this is easy to adopt and pays off immediately:

Describe 'Evaluating multi-factor authentication' {

    It 'MFA-001: Require MFA for privileged roles' -Tag "Entra ID", "Access control" {
        # ... your assertions ...
    }
}

The important part is the It line. Each test starts with a short, structured code (MFA-001), a colon, and a human-readable description. That single line gives us everything we need:

• The part before the colon (MFA-001) becomes the Id.
• The part after the colon becomes the description.

The script then builds the title as Id - description, so MFA-001: Require MFA for privileged roles becomes the title MFA-001 - Require MFA for privileged roles. Repeating the code in the title is deliberate: it means the Id is visible at a glance in the Maester report, not just in the raw config. If you would rather show only the description, drop the "$id - " prefix in the script — it is a one-line change.

The only thing still missing is the severity, and that lives in a separate lookup so that non-engineers can own it. More on that below.

A place to keep severities

Rather than hard-coding severities in the script, keep them in a simple mapping file. A two-column CSV is more than enough and can be edited by anyone, including people who do not touch PowerShell:

Id;Severity
MFA-001;Critical
SPO-004;Medium
EXO-002;High
LOG-001;Info

Tip: In practice this mapping file is a great place to also record why a control has a given severity, or to link it to whatever framework you report against (CIS, ISO 27001, NIS2, your own internal baseline). The script below only cares about the Id and Severity columns, so you can add as many extra columns as you like without changing a single line of code.

The script

Here is the whole thing. It is deliberately small, a little over fifty lines of PowerShell with no external modules.

# Stop on any error
$ErrorActionPreference = "Stop"

# Folder layout assumed here:
#   .\generate-maester-config.ps1   <- this script
#   .\severity-mapping.csv          <- Id;Severity lookup
#   ..\tests\Custom\*.Tests.ps1     <- your custom Pester tests

$scriptRoot = $PSScriptRoot
$repoRoot   = Split-Path -Parent $scriptRoot

# 1. Load the severity lookup into a hashtable for fast access
$csvPath = Join-Path -Path $scriptRoot -ChildPath "severity-mapping.csv"

$severityLookup = @{}
Import-Csv -Path $csvPath -Delimiter ";" | ForEach-Object {
    $severityLookup[$_.Id] = $_.Severity
}

# 2. Prepare the result set and the regex that recognises a test
$testSettings = [System.Collections.Generic.List[object]]::new()

# Matches:  It 'CODE-123: Some description' ...
$pattern = "^\s*It\s+'([A-Z]+-\d+):\s*(.*?)'"

# 3. Find every custom test file
$testsPath = Join-Path -Path $repoRoot -ChildPath "tests\Custom"
$files = Get-ChildItem -Path $testsPath -Recurse -Filter *.Tests.ps1

foreach ($file in $files) {
    foreach ($line in (Get-Content $file.FullName)) {
        if ($line -match $pattern) {
            $id    = $matches[1]
            $desc  = $matches[2]
            $title = "$id - $desc"

            # Look up the severity, fall back gracefully if it's missing
            $severity = $severityLookup[$id]
            if (-not $severity) {
                $severity = "Unknown"
                Write-Warning "No severity found for $id"
            }

            $testSettings.Add([PSCustomObject]@{
                Id       = $id
                Severity = $severity
                Title    = $title
            })

            Write-Host "  [+] $title ($severity)"
        }
    }
}

if ($testSettings.Count -eq 0) {
    Write-Warning "No tests found. Does your It-pattern look like  It 'CODE-123: Description' ?"
    return
}

# 4. Build the JSON and write it next to your tests
$json = @{ TestSettings = $testSettings } | ConvertTo-Json -Depth 3
$outputPath = Join-Path -Path $testsPath -ChildPath "maester-config.json"
$json | Out-File -FilePath $outputPath -Encoding UTF8

Write-Host "`nDone. $($testSettings.Count) test(s) written to maester-config.json"

How it works, step by step

1. Load the severities into a hashtable. Reading the CSV once into a @{} hashtable means every lookup afterwards is an instant key access instead of a repeated scan of the file. For a handful of tests it hardly matters; for hundreds it keeps things snappy.

2. Define the recognition pattern. The regex ^\s*It\s+'([A-Z]+-\d+):\s*(.*?)' is the heart of the script. It says: a line that starts with It, followed by a quoted string that begins with an uppercase code, a dash, some digits, a colon, and then the description. The two capture groups hand us the Id and the description directly. If your codes use a different shape (say numbers only, or a longer prefix), this one line is all you need to adjust.

3. Walk every test file. Get-ChildItem -Recurse -Filter *.Tests.ps1 collects your Pester test files (and only those, thanks to the .Tests.ps1 filter), and the script reads them line by line. Every line that matches the pattern becomes one entry in the result set. Because it works purely on text, it does not need to run your tests, so generating the config is fast and has no side effects on your tenant.

4. Fail loudly, then continue. If a test has no matching severity in the CSV, the script does not crash. It assigns Unknown and emits a Write-Warning. That way a forgotten mapping shows up as a visible nudge in your build log rather than a broken pipeline. You get the config and the reminder to fix the mapping.

5. Emit the JSON. Finally, ConvertTo-Json turns the collected objects into exactly the structure Maester expects, and it lands right next to your tests as maester-config.json.

A note on the collection. The results go into a System.Collections.Generic.List[object] rather than a plain $array += .... It is a small thing, but += rebuilds the entire array on every iteration, which is exactly the kind of quiet inefficiency you do not want in a script whose whole point is letting the machine do the tedious work. The list just grows.

Wiring it into your workflow

Because the script is idempotent and side-effect free, it fits anywhere:

• Locally, run it after adding a test so your config is always current before you commit.
• In CI, run it as a build step and either commit the result or fail the build if the generated file differs from the checked-in one. That turns "the config drifted" into a red pipeline instead of a silent bug.
• As a pre-commit hook, so nobody can forget.

A useful CI check is to regenerate and compare:

.\generate-maester-config.ps1
git diff --exit-code tests\Custom\maester-config.json

If that git diff returns a non-zero exit code, someone added or changed a test without regenerating the config, and CI will tell them.

Why bother?

A generated config buys you three things that a hand-written one never will:

1. It cannot drift. The config is derived from the tests, so it is correct by construction.
2. Severities become a shared, reviewable artefact. A CSV that non-engineers can edit means your security or compliance people can tune severities without opening a .ps1 file, and every change is visible in a pull request.
3. Onboarding is trivial. New tests just need to follow the naming convention. The plumbing takes care of itself.

The whole thing is a little over fifty lines of vanilla PowerShell, has no dependencies beyond what ships with the box, and works with any Maester setup that runs custom Pester tests. If you have been maintaining maester-config.json by hand, this is a small afternoon's work that you will be glad you did.

Have a different naming convention or a richer severity model? The regex and the lookup are the only two things you need to touch. Everything else stays the same.