Exchange Online Migration Cmdlets Lose Mailbox Properties: PowerShell Script Changes and December 15 Deadline

It isn't a security emergency, and nothing is "down." But a script can keep running without errors while handing back blank fields, and nobody notices until a report, a provisioning job or a migration runbook gives the wrong answer.

What Microsoft is changing, and when​

According to the Microsoft Learn page "Changes to Get-Mailbox and New-Mailbox specifically with the Migration parameter," the change happens in two phases:

Microsoft says it is "simplifying legacy management scenarios" as part of its ongoing Exchange Online management and directory modernization work. Message Center notice MC1511071 is tagged as a major change with action required by November 15, 2026.

Summary: Today the affected properties stop being returned (read side). On December 15, attempts to set them through New-Mailbox -Migration will be blocked (write side). If your code only reads the properties, phase one is the one that affects you. If it sets them while creating migration mailboxes, both phases do.

The November 10 vs. November 15 discrepancy​

Neowin spotted a date conflict. MC1511071 gives November 15 in its summary, its phase list and its action deadline. But its example of the impact says a script using Get-Mailbox -Migration will stop receiving the affected properties "beginning November 10, 2026."

Neowin said it couldn't tell whether that was a typo or an earlier rollout, and nothing we found settles it either. The Microsoft Learn page gives only November 15, and so does the notice's own timeline. If your migration-mailbox reports looked odd in the past few days, keep the November 10 date in mind while you troubleshoot. Don't treat it as confirmed.

What -Migration actually means​

The change sounds broader than it is. Microsoft's Get-Mailbox reference describes the -Migration switch as one that specifies whether to return only migration mailboxes in the results, and you don't need to specify a value with this switch. The same reference lists the switch for Exchange Server 2016, Exchange Server 2019, Exchange Server SE, Exchange Online. This change, however, is announced for Exchange Online only.

In practice:

• Not affected: an everyday Get-Mailbox -Identity [email][email protected][/email] or a tenant-wide Get-Mailbox -ResultSize Unlimited report. Neither Microsoft Learn nor MC1511071 says these lose properties.
• Affected: scripts, tools and third-party products that query or create migration mailboxes with -Migration and depend on the listed properties.
• Unclear: Set-Mailbox -Migration. MC1511071 tells admins to review workflows that use Get-Mailbox -Migration, New-Mailbox -Migration or Set-Mailbox -Migration. The Learn page names only the Get and New cmdlets as changing. Include Set-based workflows in your review anyway. Checking is cheap; a production surprise isn't.

The property list is long​

Microsoft Learn sorts the affected properties into a lot of categories. A selection, so you can see how much ground it covers:

• Custom attributes: CustomAttribute1 through CustomAttribute13 (the Learn page's range) and ExtensionCustomAttribute1 through ExtensionCustomAttribute5
• Delivery and moderation: ForwardingSmtpAddress, ForwardingAddress, DeliverToMailboxAndForward, ModerationEnabled, GrantSendOnBehalfTo, AcceptMessagesOnlyFrom
• Archive: ArchiveGuid, ArchiveStatus, AutoExpandingArchiveEnabled
• Restore, backup and soft delete: IsInactiveMailbox, SingleItemRecoveryEnabled, RetentionPolicy, RetainDeletedItemsFor
• Quota: MaxReceiveSize, RecipientLimits, RulesQuota
• Antispam and throttling: the SCL threshold settings, AntispamBypassEnabled, ThrottlingPolicy
• Identity and account: ExternalDirectoryObjectId, SamAccountName, IsDirSynced, UsageLocation
• Resources and public folders: IsShared, ResourceType, DefaultPublicFolderMailbox
• Policies and audit: RoleAssignmentPolicy, SharingPolicy, AuditEnabled, AuditLogAgeLimit
• Mailbox move: MailboxMoveStatus, MailboxMoveBatchName, MailboxMoveFlags
• Shared domain, hierarchy and directory: SharedEmailDomainState, ProtocolSettings, OrganizationalUnit, WindowsEmailAddress, MailTip

Some of these will catch people out. ExternalDirectoryObjectId is a common join key for matching Exchange objects to Entra ID records. MailboxMoveStatus is the sort of field a migration dashboard filters on. Custom attributes often carry data your organization defined itself, such as cost centers or department codes. These examples are only part of the list, so check the full table on Microsoft Learn against what your code actually uses.

How scripts fail​

MC1511071 warns that the change may hit automation that depends on the properties being present, or that "expects a fixed set of properties in the response." Typical problems:

1. Silent nulls. In PowerShell, reading a property that isn't on the object usually gives you $null, not an error. That's the default behavior unless strict mode is on. A report keeps running and fills a column with blanks.
2. Filters that quietly flip. A check like Where-Object { $_.IsShared -eq $true } returns nothing once the property is gone. A negative check like -ne $true suddenly matches everything.
3. Schema-strict exports. CSV pipelines, database loaders or API consumers that expect fixed column names may reject the output or shift columns.
4. Write-side failures from December 15. Provisioning that passes any affected property to New-Mailbox -Migration will be blocked from configuring it.

Exchange admins have seen this before. Easy365Manager noted years ago that the old Get-Mailbox cmdlet will retrieve all of the mailbox properties. The new Get-EXOMailbox, by default, will only retrieve a minimum set of properties. Scripts built on the assumption that "everything comes back" have broken before, and they'll break again.

What to do: a review checklist​

These steps follow Microsoft's recommendations in MC1511071. The PowerShell examples are general administrative practice, not Microsoft-published procedures.

1. Find every use of the migration switch. Search your script repositories, scheduled tasks, runbooks and automation accounts. For example:
   Get-ChildItem -Path C:\Scripts -Recurse -Include *.ps1,*.psm1 | Select-String -Pattern '-Migration'
   Search for New-Mailbox and Set-Mailbox calls too, not just Get-Mailbox.
2. Check third-party tools. MC1511071 names third-party solutions as possibly affected. Ask migration and provisioning vendors whether their products call these cmdlets with -Migration.
3. Compare property references against the Learn list. Look in Select-Object, Where-Object, calculated properties, hashtable splats and export column lists.
4. See what is coming back now. Run Get-Mailbox -Migration | Get-Member -MemberType Property in your tenant and compare the result with what your scripts expect. Rollouts can reach tenants at different times, so a property that's still there today may not be next week.
5. Fix and test. Remove each dependency, then test against real migration-mailbox output before the December 15 phase.
6. Escalate if you can't remove a dependency. Microsoft says to contact Microsoft Support with the property name, cmdlet, usage scenario and expected impact. Collect those four details before you open the ticket.

Don't simply swap in a different cmdlet and assume the problem is gone. Microsoft's Get-Mailbox reference does recommend Get-EXOMailbox for Exchange Online in general. Before you switch, confirm that the replacement supports your migration-mailbox use case. Don't treat it as a drop-in replacement for Get-Mailbox -Migration.

If your workflows don't use any of the affected properties, Microsoft says no action is required.

Analysis: reasonable housekeeping, poorly communicated​

Microsoft's case holds up. Many of these properties, such as ServerLegacyDN, ObjectCategory, OrganizationalUnit and the SCL thresholds, are leftovers from Exchange's on-premises Active Directory days, and they make little sense on a migration-mailbox object in a cloud service. Removing them reduces the surface Microsoft has to maintain and pushes admins toward cleaner, purpose-built queries.

The way it was announced deserves criticism, though. Admins got roughly a month's notice. The main notice contradicts itself on the start date. It also names a cmdlet (Set-Mailbox -Migration) that the authoritative documentation doesn't cover. The notice even says the rollout will begin and finish within mid-November, so there's little time to watch other tenants hit problems first. Admins who manage multiple tenants, or depend on vendor tooling they can't edit, have the hardest job here.

The bigger takeaway applies beyond this change: if your automation assumes a fixed set of properties from a cloud service, it can break whenever Microsoft trims that set. Scripts that validate expected fields, and log loudly when one is missing, catch problems like this early. A blank column in a quarterly report doesn't.

Bottom line: The change started today for migration-mailbox scenarios in Exchange Online, and configuration through New-Mailbox -Migration will be blocked from December 15. Search your scripts for -Migration, check the property list, and test before the second phase. If you can't drop a dependency, raise it with Microsoft Support before December 15.