What Is Happening
When New-Mailbox is called in Exchange Online, the cmdlet first creates the Entra ID user account and then writes Exchange-specific attributes back to Exchange Online via a synchronisation mechanism Microsoft calls DualWrite (Graph). As of this morning, the DualWrite call is returning a type mismatch error:
Cannot convert a primitive value to the expected type 'Edm.Int64'.
See the inner exception for more details.
DualWrite (Graph) RequestId: 38456b43-078c-4cb0-8a57-32e41e5a97d0
The issue may be transient and please retry a couple of minutes later.
This error means that Microsoft’s backend is sending a value of the wrong numeric type to its own Graph/OData endpoint during the sync step. This is a server-side defect in Microsoft’s infrastructure – it is not caused by the parameters you supply to the cmdlet, the version of the Exchange Online PowerShell module you are using, or anything specific to your tenant configuration.
How This Affects EasyEntra
EasyEntra uses New-Mailbox when creating new cloud-only or hybrid users with Exchange Online mailboxes. Any workflow that provisions a new mailbox will fail with the above error until Microsoft resolves the underlying infrastructure issue. The following EasyEntra operations are blocked:
- Create user with Exchange Online mailbox (cloud-only users)
- Create hybrid user with cloud mailbox step
- Any template-based provisioning that includes mailbox creation
Operations that do not create new mailboxes – such as editing existing users, managing permissions, group membership, licence assignment, or decommissioning – are not affected.
Recommended Actions
Verify the Issue with the Raw Cmdlet.
Before contacting Microsoft Support, verify that the failure is reproducible in your tenant using the raw Exchange Online PowerShell cmdlet, independent of EasyEntra. This establishes that the problem is at the Exchange Online service level and not specific to EasyEntra, and provides Microsoft with a clean reproduction case.
Step 1 – Update the Exchange Online PowerShell module
Ensure you are on the latest version of the module before testing. Running an outdated module wastes time in back-and-forth with Microsoft support.
Install-Module ExchangeOnlineManagement -Force -AllowClobber
Get-InstalledModule ExchangeOnlineManagement
Confirm the version shown is 3.6.0 or later (the current release at time of writing is 3.9.x).
Step 2 – Connect and capture verbose output
Connect with the -Verbose flag. Save the full output – Microsoft support will ask for it to confirm module version, token acquisition, and session configuration, skipping the usual early-stage triage:
Connect-ExchangeOnline -Verbose -ShowBanner:$falseCopy and retain the entire verbose block from the terminal. It will look similar to:
PS C:\> Connect-ExchangeOnline -Verbose -ShowBanner:$false
VERBOSE: Returning precomputed version info: 3.9.2
VERBOSE: ModuleVersion: 3.9.2
VERBOSE: [ThreadID: #] Trying to get a new token from AAD
VERBOSE: [ThreadID: #] Trying to acquire token based on UI flow
VERBOSE: [ThreadID: #] Acquired new token when no params are passed
VERBOSE: [ThreadID: #] Successfully got a token from AAD
VERBOSE: AutoGen EXOModule created at C:\Users\Skrubbeltrang\AppData\Local\Temp\tmpEXO_50yf3xpj.saa
VERBOSE: Running Configure-AppSettings
VERBOSE: Setting PrintWarningsReceivedFromServer to False
VERBOSE: PageSizes is set to: 1000
VERBOSE: Logs location is reset to C:\Users\Skrubbeltrang\AppData\Local\Temp\EXOCmdletTelemetry
VERBOSE: Max directory size reset to 2000000000
VERBOSE: Max log size reset to 100000000
VERBOSE: Log level reset to Default
VERBOSE: Logger reset to null.
VERBOSE: TrackPerformance is set to: False
VERBOSE: ShowProgress is set to: False
VERBOSE: UseMultithreading is set to: TrueStep 3 – Reproduce the failure
Run the following command in your tenant, substituting a valid UPN from your verified domain:
PS C:\> New-Mailbox -Name "Test User" -FirstName "Test" -LastName "User" -DisplayName "Test User" -MicrosoftOnlineServicesID "testuser@azure.skrubbeltrang.com"You should see the error:
New-Mailbox: ||An Azure Active Directory call was made to keep object in sync between Azure Active Directory and Exchange Online.
However, it failed. Detailed error message: Cannot convert a primitive value to the expected type 'Edm.Int64'.
See the inner exception for more details. DualWrite (Graph) RequestId: 38456b43-078c-4cb0-8a57-32e41e5a97d0
The issue may be transient and please retry a couple of minutes later. If issue persists, please see exception members for more information.Include the entire output in your support ticket – it uniquely identifies the failed server-side operation and allows Microsoft engineers to trace the exact request in their backend logs.
Check Microsoft Service Health
Before opening a support ticket, check whether Microsoft has already posted a service incident for this issue. This is the fastest way to get status updates and avoids creating a duplicate ticket.
1. Sign in to the Microsoft 365 admin center, Health -> Service Health: https://admin.cloud.microsoft/#/servicehealth (requires Global Admin, Exchange Admin, or Service Support Admin role).
2. On the Service health page, locate Exchange Online in the list. If an active incident is shown, click it to view the incident ID, current status, and estimated resolution time.
3. Check the Issue history tab (top of the page) if no active incident is visible – it may have been posted and already marked as monitoring.
If you find an active incident, note the incident ID (format: EXnnnnnnn) and include it in your support ticket. If no incident is listed, proceed to file a new support request.
Report the Issue to Microsoft Support
If no service incident is listed in your Service Health dashboard, open a support request directly from the admin center so the issue is logged against your tenant:
1. Go to the admin center at https://admin.cloud.microsoft, then select Support → New service request.
2. In the title, enter: New-Mailbox fails with DualWrite Edm.Int64 type mismatch error
3. In the description, include all of the following:
- The full verbose output from Connect-ExchangeOnline (Step 2 above)
- The exact error text including the DualWrite RequestId GUID
- The Exchange Online PowerShell module version (Get-InstalledModule ExchangeOnlineManagement)
The time the failure was first observed (morning of 20 March 2026 CET) - Confirmation that the issue reproduces with a minimal New-Mailbox command as shown above
- A note that the issue affects all New-Mailbox calls regardless of parameters
4. Set the severity to match your business impact. If mailbox provisioning is blocking new employee onboarding, classify as Severity B (significant business impact).
Providing the verbose connection output and the DualWrite RequestId up front avoids the standard first-response questions about module version and reproduction steps, significantly shortening the time to escalation.
What to Expect
The error message from Microsoft states the issue may be transient. In practice, DualWrite type errors of this nature are caused by a deployment to Microsoft’s backend Graph/OData infrastructure that introduced a type mismatch – they do not resolve on their own without a rollback or a targeted fix from Microsoft. Retrying the cmdlet after a few minutes is unlikely to help.
Once Microsoft identifies and fixes the backend issue, New-Mailbox will resume working without any changes required on your side. EasyEntra will recover automatically on the next attempt.
Monitor the Service Health dashboard for updates. Incidents of this type are typically resolved within a few hours to one business day once Microsoft’s Exchange engineering team has triaged the root cause.
Update 22-03-2026:
Microsoft have now identified and fixed the issue according to EX1256744:
