If you’re running the Get-MailboxStatistics cmdlet and encounter the following error:
PS C:\WINDOWS\system32> Get-MailboxStatistics lene.hau | ft DisplayName,ItemCount
Write-ErrorMessage : ASSERT: Attempting to convert large prop tag to 32-bit
form
At C:\Users\adm.lhau\AppData\Local\Temp\tmpEXO_klbvevxg.btq\tmpEXO_klbvevxg.btq
.psm1:1189 char:13
+ Write-ErrorMessage $ErrorObject
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [Get-MailboxStatistics],
Exception
+ FullyQualifiedErrorId : [Server=YQXPR01MB6219,
RequestId=c34ad88c-77c3-0aed-60b0-a9f8f105bc9c,
TimeStamp=Wed, 23 Jul 2025 14:43:49 GMT],Write-ErrorMessage …then you’re likely facing yet another glitch introduced by the Exchange Online (EXO) REST backend.
As we’ve documented in many previous posts, the EXO REST API continues to break with alarming frequency on a monthly basis. These issues frequently roll out without warning, without proper changelogs, and without any public acknowledgment from Microsoft. This latest failure appears to be another example of poor change control within the EXO REST team.
The Get-MailboxStatistics cmdlet is a basic and essential part of any Exchange administrator’s toolkit. When this functionality breaks, it disrupts operational insight and automation routines, especially in hybrid or large-scale environments.
It also utilized in third-party applications, like Easy365Manager and EasyEntra, and any errors in the EXO REST API will cascade into scripts and third-party applications using the API.
We strongly encourage you to report this error directly to Microsoft to raise visibility and pressure for resolution. You can do so via the Microsoft 365 Admin Center Health Portal.
It’s notoriously difficult to get this quickly through first-line support. We recommend that you provide the following output in your ticket to remove any questions up-front regarding EXO PowerShell version, credentials, and error message:
1. Upgrade EXO PowerShell to the latest version:
Install-Module ExchangeOnlineManagement -Force 2. Perform a verbose authentication with EXO using a specific UPN:
Connect-ExchangeOnline -UserPrincipalName adm-user@example.com -Verbose This will return detailed output confirming module version, authentication steps, and connection setup.
3. Show the connection output:
Get-ConnectionInformation 4. Verify your management roles:
Get-ManagementRoleAssignment -RoleAssignee
adm-user@example.com | ft Name,Role,RoleAssigneeName -AutoSize 5. Run the failing command with verbose output to capture the error context:
This will return detailed output confirming module version, authentication steps, and connection setup.
Get-MailboxStatistics user -Verbose In the failing case, you will receive the error message listed in the beginning of this article.
Include the full output from the above commands in your support ticket to ensure efficient escalation to senior support team members.
Summary
Microsoft has not yet officially acknowledged the issue, and no public advisory has been released. Based on past experience, it’s possible that Microsoft will apply a silent backend fix without prior notice.
We will update this article as more information becomes available.
Update 2025-07-24
Multiple clients are now reporting the issue has been solved by Microsoft. We were unable to find any official information regarding this issue. It seems another EXO REST API change gone bad ended with a silent fix.
