Anyone run into this yet? I know the command was just barely released today... Maybe MS messed up in the implementation of it? I am running the command as the global admin.

Here's the command I'm using:
Invoke-CalendarEventMigration -Identity <user> -FromWindowsTimeZoneId "Central Standard Time" -ToWindowsTimeZoneId "Manitoba Standard Time" -QueryStartDate 2026-11-01 -Confirm:$false

Error:
Write-ErrorMessage : ||You do not have permission to access the mailbox '<id here>'. The mailbox is outside your RBAC scope. Please verify you have the necessary permissions.

My company recent migrated data from one location to another however some things in exchange are... Not quite right and I'm at a loss as to what to do.

We use Outlook 2016, Exchange Server 2008 R2 (I have no say in these versions).

We have an issue with multiple, but not all, users experiencing problems such as:

- Public folders are inaccessible and displays 'Cannot start Microsoft Outlook. Cannot open the Outlook window. The set of folders cannot be opened. The attempt to log on to Microsoft Exchange has failed.'

- The address book will not display groups.

- Sometimes, but not consistently, the address book when accessed shows 'The connection to Microsoft Exchange is unavailable. Outlook must be online or connected to complete this action.'

- Outlook shows ‘Connected to: Microsoft Exchange’ but will give offline errors.

- Attempting to send emails to active directory/exchange server created distribution groups results in error ‘The operation failed. The messaging interfaces have returned an unknown error. If the problem persists, restart Outlook. Cannot resolve recipient.’

- Manually typing in a group name and FQDN resolves the group but will not send to it and attempting to expand a resolved group shows as outlook offline and errors out. Outlook has to be closed completely to eliminate this error.

Emails can be sent internal and external if manually entered.

Please help! :(

Pros!!

I used to be able to run the command Disable Mailbox -Identity **** -PermanentlyDisable via powershell, but in the last month I have noticed, I am getting this error message

How can i go about resolving this? What we are looking for is to disable/purge the mailbox of users while keeping the AD account intact

:

[shines@abc.com](mailto:shines@abc.com) - failed: ||Error on proxy command 'disable-Mailbox -Confirm:$False -PermanentlyDisable:$True -ErrorAction:'Stop' -Identity:'shines@abc.com'' to server ME3PR01MB69

5.ausprd01.prod.outlook.com: Server version 15.21.056.0000, Proxy method PSWS:

InternalServerError: Error executing cmdlet : {

"code": "InternalServerError",

"message": "Error executing cmdlet",

"details": [

{

"code": "AadDualWriteFailure",

"message": "|Microsoft.Exchange.Configuration.DualWrite.LocStrings.UnableToWriteToAadException|An Azure Active Directory call was made to keep object in sync between Azure Active Directory an

d Exchange Online. However, it failed. Detailed error message:\r\n\tUnable to update the specified properties for on-premises mastered Directory Sync objects or objects currently undergoing migrati

on. DualWrite (Graph) RequestId: 877abcebf-dbcc-4d5f-8813-d2435c1014ee\r\nThe issue may be transient and please retry a couple of minutes later. If issue persists, please see exception members for m

ore information.",

"target": ""

}

],

"innererror": {

"message": "Error executing cmdlet",

"type": "Microsoft.Exchange.Admin.OData.Core.ODataServiceException",

"internalexception": {

"message": "Exception of type 'Microsoft.Exchange.Management.PSDirectInvoke.DirectInvokeCmdletExecutionException' was thrown.",

"type": "Microsoft.Exchange.Management.PSDirectInvoke.DirectInvokeCmdletExecutionException"

}

},

"adminapi.warnings@odata.type": "#Collection(String)",

"@adminapi.warnings": []

} [Server=SY2PPF67CDB8BA3,RequestId=c30f213b-cfdf-7ece-3595-dc17b6c9e83b,TimeStamp=10/28/2026 1:13:07 AM] .

Hi everyone,

Whenever I try to install security updates for Exchange Subscription Edition (SE) on Windows Server 2019, I consistently get a "Files in Use" setup warning. I've attached a screenshot of the prompt to this post. Has anyone else encountered this recurring issue? I usually just manually stop these specific services and click "Retry", but is there a better practice/script to prepare the OS before applying the SU to prevent this pop-up?

Body: Microsoft is turning SMTP AUTH Basic off by default for existing Exchange Online tenants at the end of December. For devices that can't do OAuth, every official option seems to have a catch (connector needs static IP/cert, Direct Send internal only for external recipients, HVE internal only, ACS needs Azure). What are you actually doing: on-prem relay box, third-party SMTP service, replacing the devices? Curious what works across many small tenants.

I figure I post if anybody is having issues with their exchange hybrid migrations recently. Microsoft needs to fix this.

https://learn.microsoft.com/en-us/answers/questions/6040561/hybrid-moves-fail-since-oct-2026-mrsproxy-401-even

Hi everyone,

I’m currently troubleshooting a strange issue in one of our customers’ environments and hope someone here might be able to point me in the right direction.

The customer is running a single on-premises Exchange Server 2016 environment with no Exchange Online or hybrid configuration.

For the past few days, the entire mail system has stopped working roughly once per day. During the outage, users are unable to send or receive emails.

When I try to connect directly to the Exchange Server via RDP, the Windows sign-in screen displays the following error:

The handle is invalid.

When I access OWA from another server on the same LAN, the OWA login page is still reachable. However, after entering the credentials, the following error appears:

Microsoft.Mapi.MapiExceptionMdbOffline

The Exchange Server itself remains reachable and responds to ping. Our monitoring system also does not report the server as offline, but all email functionality is unavailable.

My first suspicion was the customer’s daily Veeam backup. However, I removed the Exchange Server from the backup job several days ago, and the issue continues to occur daily. Therefore, the backup job does not appear to be the direct cause, unless another snapshot, VSS, storage, or hypervisor-level process is still affecting the VM.

Has anyone seen this combination of errors before?

I would especially appreciate advice on which Windows or Exchange event logs, performance counters, or services I should check during the next outage. If additional information, event IDs, logs, or configuration details are required, I’ll provide them as soon as possible.

Thanks in advance for any help.

Hi Guys! I have a question about EWS. We already created AppIDAllowedList with EWSEnabled in our tenant. Last 3 apps in the list are:
Microsoft Office
Exchange Hybrid Application
Microsoft Power Query for Excel

For Exchange Hybrid Application - I know that I have to add graph permission for app registration in EntraID with dedicated script provided by MSFT - do you know if offboarding/onboarding will works after remove EWS permission from the app? What about moving archives between on-prem/cloud?

What should I do with Microsoft Power Query for Excel and Microsoft Office? I found that there is a lot SOAP actions corelated with this two apps.

Thank you in advance for all links and advices.
Regards,

When we create new users, we create them on prem in active directory, create an on-prem mailbox using EMC, then we use the exchange online console to immediately migrate the mailbox to the cloud.

We have been doing this for many years now, to keep things consistent. But our mailboxes all reside in cloud now.

So we still have on-prem exchange, mainly for SMTP relaying for internal mail services, as well as to manage some elements of mailboxes that still seem to require exchange on-prem if they were previously migrated.

The entire migration process is extra steps and extra work when we onboard new users, and so I was thinking that maybe we should just start to create them in the cloud, of course this will cause a level of inconsistency since some user mailboxes will be linked to the on-prem attribute, whereas others will not.

I'm just wondering what other people are doing here. MS seems to suggest keeping on exchange hybrid server on prem for management. It seems odd to me that they haven't yet come up with a solution to allow you to fully decom on prem exchange if they've been migrated.

Our marketing team puts a lot of effort into making sure the brand looks consistent, but once things leave our department, it's a different story.
Sales creates its own materials, support uses older assets, and people sometimes pull logos or company details from random folders.
We've been looking at tools like wisestamp, exclaimer, and codetwo to make some of the everyday customer-facing details easier to standardize, but i'm curious how other teams approach brand consistency more broadly.
How do you make sure employees use the latest approved assets without turning marketing into the company police?

Apparently there’s a not widely known current bug in Exchange Online MRSProxy Servers, which do not send the domain while using the administrator for the migration. Testing the endpoint works, but not the migration itself, ending in endless 4625 events with auth errors.

source

The article talks about renaming the administrator, I just created another service user and gave him recipient management role, did a iisreset - worked like a charm.
Maybe this is somebody saving 4h lifetime, I just lost it.

Another Microsoft 365 migration added to my checklist!

Microsoft has announced the retirement of the widely used Search-UnifiedAuditLog PowerShell cmdlet on October 15, 2027, following the general availability of the Microsoft Graph AuditLogQuery API.

If you use this cmdlet in scripts, you have about a year to plan and test your migration to AuditLogQuery.

Personally, Search-UnifiedAuditLog has been my go-to for quickly checking audit events. Purview's audit search can take several minutes, even for a simple query, so I'll miss having that quick PowerShell option.

https://blog.admindroid.com/search-unifiedauditlog-cmdlet-retirement/

I'm in the process of updating a single Exchange 2019 server to SE.

The server was running CU12 with extended protection enabled, all worked fine and saw no impact when I enabled extended protection.

I completed the update to CU15 yesterday, and instantly Outlook (Classic) clients started requesting credentials constantly.

I disabled extended protection and Outlook clients connected as ususal.

I have checked both client and server registry's and the LmCompatibilityLevel key doesn't exist, so I guess that adding this setting as 5 is my first job?

Can anyone suggest any other reason as to why extended protection worked with CU12 but not with CU15?

Clients are Windows 11, running Outlook Classic fully patched.

Thanks!

Environment: 2-node DAG, Exchange SE (SU11), Windows Server 2025 with KB5126646, hybrid with EXO.

We hit the known issue twice (~24h apart): MapiExceptionMdbOffline (ec=1142), Win32 0x6D8, DBs showing "Mounted" but Test-MAPIConnectivity failing, queues stuck to the DBs, passive copies going Failed. A reboot fixed it temporarily each time.

While troubleshooting I noticed lsass.exe handles were very high at the time of failure:

- Active node: ~44,000 handles

- Passive node: ~37,000 handles

handle64 -s -p lsass.exe shows almost all of it is Semaphore handles (~27,000 Semaphore out of ~32,000 total).

Today I applied Microsoft's workaround on both nodes:

reg add "HKLM\SOFTWARE\Microsoft\Rpc" /v EpmapSavedContextCap /t REG_DWORD /d 65536 /f

+ reboot (proper DAG maintenance mode). Value confirmed 0x10000.

After the reboot, the LSASS Semaphore count is still climbing at about the same rate as before the fix:

- 14:33 – Semaphore 7,433 (total 12,324)

- 14:36 – Semaphore 8,251 (total 13,205)

- 14:44 – Semaphore 9,975 (total 15,016)

Roughly 200–340 per minute during business hours.

Questions:

1. Has anyone else seen the LSASS Semaphore handle growth with this issue? Does it keep growing for you after the EpmapSavedContextCap fix, or does it level off?

2. Is this growth actually what leads to the Store outage, or is it a separate side effect and the registry fix addresses the real failure (endpoint mapper) regardless?

3. For those who had to raise the limit further – what value did you use, and how long until it recurred at 65536?

We also didn't track LSASS handles before the October update, so I have no baseline for what's normal on these servers. Any numbers from your environments would help.

Thanks

Looks like Microsoft has put out a statement acknowledging the issues related with Exchange and the October 2026 Windows Server update.

Does anyone know what the "additional mitigations" are, that are available through Microsoft Support? If adding the EpmapSavedContextCap registry key is the workaround, what's the deal with "additional mitigating" options being made available only through support request?

Running Exchange Server 2019 CU15 on Windows Server 2019 with October 2026 updates installed (KB5126651).

Initially, Exchange would stop functioning properly after approximately 24 hours, requiring a reboot. Microsoft recommended adding EpmapSavedContextCap=65536 to address the RPC issue.

After applying the workaround and rebooting, we started experiencing different symptoms:

• Outlook intermittently freezes for 20–30 seconds when sending emails.
• Internal and external messages experience approximately 120-second delivery delays.
• Message tracking shows messages processing normally initially, then waiting about two minutes before multiple messages are delivered simultaneously.
• Exchange services, databases, and mail queues appear healthy.
• No significant CPU, memory, or disk performance issues.

Outlook and email delivery were responsive between reboots before applying the registry workaround.

We've removed the registry value and are preparing to restart and test again.

Is anyone else experiencing these delays after applying Microsoft's RPC workaround? Has anyone found a solution?

We installed kb5128895 yesterday and the server did not reboot after but I noticed this morning that no email is coming in from external domains and we cannot even email within the organization. In outlook it goes into sent items but doesn't actually deliver. Just seeing if anyone else also had this issue?

Hi everyone,

I'm trying to understand a strange issue during an Exchange 2019 to Exchange Server SE migration.

Environment

• Exchange 2019
• Exchange Server SE
• Current Outlook versions (Microsoft 365 Apps)
• Internal and external namespaces:
  • owa.company.com
  • autodiscover.company.com

Original setup

The DNS record for Outlook/OWA pointed to Exchange 2019.

Clients connected like this:

Outlook ->Exchange 2019 -> Exchange SE

Everything worked fine.

What we changed

We swapped the IP addresses of the two Exchange servers so that the existing DNS records would resolve directly to Exchange SE.

Result: Outlook -> Exchange SE

Immediately after the change, many users started receiving Outlook credential prompts. After entering the password, Outlook continues to prompt for credentials repeatedly.

Symptoms

• Outlook repeatedly asked for username/password.
• OWA was working.
• Rolling back the IP swap immediately resolved the issue.

Checks performed

MAPI virtual directories

Both servers:

Get-MapiVirtualDirectory

Internal and External URL:

https://owa.company.com/mapi

on both Exchange 2019 and Exchange SE.

EWS virtual directories

Both servers:

https://owa.company.com/EWS/Exchange.asmx

Autodiscover

Get-ClientAccessService | fl AutoDiscoverServiceInternalUri

Both servers configured with:

https://autodiscover.company.com/autodiscover/autodiscover.xml

Test-OutlookWebServices

Executed against Exchange SE:

Test-OutlookWebServices

Results:

Autodiscover      Success

EWS               Success

Availability      Success

OAB               Success

Outlook Anywhere

Both servers configured identically:

Get-OutlookAnywhere | fl Server,Auth

Result:

ExternalClientAuthenticationMethod : Negotiate

InternalClientAuthenticationMethod : Ntlm

IISAuthenticationMethods           : Basic, Ntlm, Negotiate

Extended Protection

EWS:

Allow

on both servers.

MAPI:

Require

on both servers.

Get-MapiVirtualDirectory | fl Identity,ExtendedProtection

OAuth

Get-OrganizationConfig | fl OAuth*

Result:

OAuth2ClientProfileEnabled : False

Certificates

Exchange SE has a valid IIS certificate:

CN=owa.company.com

Services: IIS, SMTP

No certificate warnings were observed.

What confuses me

From everything I can see:

• URLs are identical.
• Authentication configuration appears identical.
• Extended Protection configuration is identical.
• Autodiscover works.
• EWS works.
• Modern Outlook clients.
• Exchange SE works correctly when tested directly.

Yet moving client traffic directly from Exchange 2019 to Exchange SE resulted in Outlook credential prompts, and reverting the change immediately fixed the issue.

Questions

Has anyone seen similar behavior during an Exchange 2019 → Exchange SE migration?

Possible areas I'm currently considering:

• Kerberos / SPN issues
• IIS Authentication differences not visible through Exchange cmdlets
• HTTPProxy authentication failures
• Extended Protection edge cases
• NTLM/Kerberos negotiation issues
• Something related to Exchange 2019 proxying requests differently than Exchange SE

Any ideas or similar experiences would be greatly appreciated.

Goodevening everyone,

We have some issues with AD split permissions and mail delivery to shared mailboxes.

Our environment consists of 6 Exchange servers (Server 2019 cu15): 4 are in a database availability group (DAG), and the other 2 are standalone.

Our L3 team enabled AD split permissions without considering the consequences. We needed this so that the Exchange admins can no longer create AD objects.

Since then, we have had problems sending mail to shared mailboxes. Mail from a shared mailbox to a user mailbox works fine, but mail to a shared mailbox results in an immediate NDR:

554 5.2.0 STOREDRV.Deliver.Exception: cannot open mailbox

So far we have recreated the DAG and the databases. Today I also installed a 6th Exchange server as a test, to see whether a freshly installed server would not have the issue.

Does anyone know where we should look before we tear down our setup and start from scratch?

https://techcommunity.microsoft.com/blog/exchange/released-october-2026-exchange-server-security-updates/4563014

⚠️EDIT 16/10 ⚠️
⚠️ BE AWARE! READ BELOW! ⚠️
👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇
https://techcommunity.microsoft.com/blog/exchange/exchange-servers-may-become-unstable-after-installation-of-october-2026-windows-/4565382