It seems to be almost on a monthly basis that new issues are popping up in the Exchange Online REST API.
In mid-May, we saw Get-MailboxStatistics CmdLet failing (or actually the underlying REST API was failing).
We now see another issue surfacing with the Set-Place CmdLet which is used to configure properties on Exchange Online Room resources. Affected properties are, e.g.:
- Building
- Floor
- Capacity
- AudioDeviceName
- VideoDeviceName
- DisplayDeviceName
An example of an affected PowerShell CmdLet is the following:
Set-Place -Identity room-cph-1.4 -AudioDeviceName "MyAudioDevice"This results in the following bogus error message:
Write-ErrorMessage : ||Encountered an internal server error.
At C:\Users\Skrubbeltrang\AppData\Local\Temp\tmpEXO_maj54now.kcx\tmpEXO_maj54now.kcx.psm1:1189
+ char:13 Write-ErrorMessage $ErrorObject
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [Set-Place], TaskException
+ FullyQualifiedErrorId : [Server=AS4SPRMB0051,RequestId=ae7aec85-28bb-0e1b-fe69-a1bf1a513551,
TimeStamp=Fri, 27 Jun 2025 15:38:50 GMT],Write-ErrorMessage Using the Exchange Admin Center console renders the same issue:
This points in the direction of yet another issue with the underlying EXO REST API – which remains in beta half a decade after the release of the General Availability (GA) version of the EXO V2 module which is built on top of that API (just sayin’ 😬).
To resolve this issue, we recommend reporting the issue via the Microsoft Admin Center.
To avoid numerous ping-pongs with Microsoft first-line support, we recommend the following approach:
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:
Set-Place -Identity room-cph-1.4 -AudioDeviceName "TestDevice" -VerboseAs this currently fails, you will receive the “internal server error” message, including verbose info:
VERBOSE: Returning precomputed version info: 3.8.0
VERBOSE: POST https://outlook.office365.com/adminapi/beta/8a35f394-855d-4d13-9f6f-86d8eb24dc6b/
InvokeCommand with -1-byte payload
VERBOSE: Query 1 failed.
VERBOSE: Getting message from error object
Write-ErrorMessage : ||Encountered an internal server error.
At C:\Users\Skrubbeltrang\AppData\Local\Temp\tmpEXO_maj54now.kcx\tmpEXO_maj54now.kcx.psm1:1189
+ char:13 Write-ErrorMessage $ErrorObject
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [Set-Place], TaskException
+ FullyQualifiedErrorId : [Server=AS4SPRMB0051,RequestId=ae7aec85-28bb-0e1b-fe69-a1bf1a513551,
TimeStamp=Fri, 27 Jun 2025 15:38:50 GMT],Write-ErrorMessage 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-08:
We reported the incident to Microsoft support and it was logged as service incident that would be fixed within a weeks time.
This incident has indeed been solved according to testing in multiple tenants. We weren’t able to locate any public information on this incident, so we can put a ✅ next to another silent bug fix in the Exchange Online REST API.
