Graph API assignLicense returns 409 Directory_ConcurrencyViolation with DirectoryValueExistsException for all users in tenant

Hello 江口 太一

Thank you for reaching out to Microsoft Q&A.

It sounds like what you’re seeing—409 Directory_ConcurrencyViolation with a DirectoryValueExistsException—isn’t just a plain concurrency/timing issue but a duplicate-attribute conflict buried in Graph’s license-provisioning engine. Here’s the rundown and some steps to get you unblocked:

1. What attribute is colliding—and how to find the culprit • Check your audit logs for the failed internal “Update user” entries. If you query the directory audit logs via Graph (GET /auditLogs/directoryAudits?$filter=activityDisplayName eq 'Update user' and contains(status/error/message,'DirectoryValueExistsException')), each entry will show the attribute or property name under “modifiedProperties.” • In practice this often turns out to be a proxyAddresses or mailNickname collision. You can confirm via Exchange Online PowerShell:

      
      Connect-ExchangeOnline  
      
      Get-Recipient -Filter "EmailAddresses -eq '******@contoso.com'" | fl Name,RecipientType,EmailAddresses
      
   

   This pinpoints any other object holding the same address.
2. Why you’re seeing 6–7 “Update user” attempts per single POST Graph’s back end runs an internal retry loop for each stuck service plan (PendingInput/PendingProvisioning) on the user’s existing E5 license. Each loop does an “Update user” + “Change user license,” so a single assignLicense call really spawns ~6 internal tries—and each one fails on the same duplicate-value check.
3. Why the M365 admin center works but your API call doesn’t The portal UI route first cleans up or finalizes any pending service plans before stamping on the new license, and it also de-duplicates attributes ahead of time. The raw Graph API path just says “go,” triggering those internal retries and surfacing the duplicate-value exception.
4. How to fix the DirectoryValueExistsException at scale a) Clear out the pending plans and duplicate attribute, then do a single combined add/remove call: • Use PowerShell or the portal to remove the E5 license from the user. • Wait until /users/{id}/licenseDetails shows no more PendingInput/PendingProvisioning states. • Reassign E5 + Copilot in one go:

       POST /users/{id}/assignLicense  
      
      
       {  
      
      
         "addLicenses": [{ "skuId":"639dec6b-bb19-468b-871c-c5c441c4b0cb" }],  
      
      
         "removeLicenses": [{ "skuId":"<your E5 skuId>" }]  
      
      
       }  
   

   b) Drill into your tenant for duplicate attributes: • Run a tenant-wide proxyAddresses scan via PowerShell or Graph and resolve any duplicates you find. c) Consider group-based licensing for Copilot so you avoid per-user write locks and the internal retry loop altogether.
5. Reference docs:

• Assign/Remove user licenses (Microsoft Entra ID)

‐ https://docs.microsoft.com/azure/active-directory/fundamentals/license-users-groups

• Group-based licensing troubleshooting

‐ https://docs.microsoft.com/azure/active-directory/active-directory-licensing-group-advanced#limitations-and-known-issues

• Identify & resolve license assignment problems

‐ https://docs.microsoft.com/entra/fundamentals/licensing-groups-resolve-problems

• HTTP 409 – Directory_ConcurrencyViolation during license assignment

‐ https://support.microsoft.com/kb/2604070040004864

If the answer is helpful, kindly upvote it. If you have extra questions about this answer, please click "Comment".

江口 太一

Following up to check if the resolution provided was helpful. Let us know if you need any further assistance.

@Shubham Sharma
Thank you. I’ve reviewed the details.

Since some of the URLs in the reference links aren’t opening, I’m planning to try Plan C as a workaround while also reaching out to Microsoft Support for assistance. In any case, I’ll let you know the results.

Internal Progress:
I confirmed via PowerShell that an Azure administrator was able to perform delegated authentication.
It was found that licenses were successfully assigned with the permissions "User.ReadWrite.All" and "Organization.Read.All."
Therefore, we believe the following factors could be potential causes:
・Authentication method (Managed Identity <Application> vs. Delegated <Azure administrator>)
・Permissions (LicenseAssignment.ReadWrite.All vs. User.ReadWrite.All, Organization.Read.All)

江口 太一

Thank you for your reply.

Below are the links:-

https://learn.microsoft.com/en-us/entra/fundamentals/licensing

https://learn.microsoft.com/en-us/entra/identity/users/licensing-group-advanced#limitations-and-known-issues

https://learn.microsoft.com/en-us/entra/fundamentals/licensing-groups-resolve-problems

Thank you.

江口 太一

Let us know if you need any further assistance from our end.