Microsoft 365 will not assign a licence to a user who has no usage location. The fix is to set the user's Usage location to a valid two-letter ISO 3166-1 alpha-2 country code, such as US or FR, and then assign the licence again. You can set it in the Microsoft 365 admin center, or with Microsoft Graph PowerShell using Update-MgUser -UsageLocation, and then run Set-MgUserLicense.
Who this is for and what you will have at the end
This guide is for Microsoft 365 administrators who see a licence assignment fail because of a missing or invalid usage location. This often happens with accounts synchronized from on-premises Active Directory, users created by a script or bulk import, and users added to a licensed group.
At the end you will have:
- An understanding of why Microsoft 365 requires a usage location.
- A PowerShell method to find every user without one and set it in bulk.
- Steps to assign the licence afterwards and to reprocess group-based licensing errors.
- A way to stop the problem recurring for new users.
Why a usage location is required
Some Microsoft services are not available in all locations. Before a licence can be assigned to a user, an administrator must specify the user's location setting, and Microsoft documents that you can only assign licences to accounts whose UsageLocation property is a valid ISO 3166-1 alpha-2 country code.
Specifying a location is a required part of creating a new user in the Microsoft 365 admin center, which is why the error is rare for users created there. It is common in these cases:
- Synchronized accounts. Accounts synchronized from on-premises Active Directory Domain Services do not have a location specified by default.
- Scripts and imports. A script that creates the user and licenses them in one go does not set the property unless you tell it to.
- Group-based licensing with unsupported countries. The location is set, but to a country or region where the service is not available.
Usage location is separate from the user's address fields. It controls licensing, so setting a city or office address does not fix the error.
Prerequisites
- To assign licences you must be at least a License Administrator or User Administrator. For group-based licensing, a Groups Administrator can also assign licences to groups.
- For PowerShell, the Microsoft Graph PowerShell SDK. Assigning and removing licences needs the
User.ReadWrite.Allpermission scope, or one of the other permissions listed in Microsoft's assignLicense reference. Reading the available licences needsOrganization.Read.All.
Connect with the scopes you need:
Connect-MgGraph -Scopes User.ReadWrite.All, Organization.Read.AllStep 1: Find users without a usage location
To see which member accounts have no usage location, run:
Get-MgUser -All -Select Id,DisplayName,Mail,UserPrincipalName,UsageLocation,UserType | where { $_.UsageLocation -eq $null -and $_.UserType -eq 'Member' }Always include -All. Without it, Get-MgUser returns only the first 100 accounts, and you could miss affected users.
To find unlicensed accounts in general, Microsoft's documentation gives this filter:
Get-MgUser -Filter 'assignedLicenses/$count eq 0' -ConsistencyLevel eventual -CountVariable unlicensedUserCount -AllFor unlicensed synchronized users only:
Get-MgUser -Filter 'assignedLicenses/$count eq 0 and OnPremisesSyncEnabled eq true' -ConsistencyLevel eventual -CountVariable unlicensedUserCount -All -Select UserPrincipalNameStep 2: Set the usage location
Pick the correct country for each user. It should be where the user is, not where the tenant is registered, because service availability depends on it.
For one user
$userUPN = "[email protected]"
$userLoc = "US"
Update-MgUser -UserId $userUPN -UsageLocation $userLocFor many users
Set the location for a list of users from a CSV with UserPrincipalName and UsageLocation columns:
Import-Csv .\locations.csv | ForEach-Object {
Update-MgUser -UserId $_.UserPrincipalName -UsageLocation $_.UsageLocation
}Test the script on two or three accounts before running it on everyone.
Other ways to set it
Microsoft's PowerShell licensing guide lists three places to configure a location for synchronized accounts: the Microsoft 365 admin center, PowerShell, and the Azure portal, where the path it documents is Users > the user account > Profile > Contact info > Country or region. Portal labels change over time, so if the menu differs in your tenant, use PowerShell, which does not depend on the interface.
Step 3: Assign the licence
Find the licence you want to assign. Get-MgSubscribedSku shows the available plans and counts. The number of available licences in each plan is ActiveUnits minus WarningUnits minus ConsumedUnits:
Get-MgSubscribedSku | Select-Object SkuPartNumber, SkuId, ConsumedUnitsThen assign it. This example assigns Microsoft 365 E5 (SPE_E5):
$e5Sku = Get-MgSubscribedSku -All | Where SkuPartNumber -eq 'SPE_E5'
Set-MgUserLicense -UserId "[email protected]" -AddLicenses @{SkuId = $e5Sku.SkuId} -RemoveLicenses @()Replace SPE_E5 with the SkuPartNumber of your own plan.
To copy another user's licences instead:
$mgUser = Get-MgUser -UserId "[email protected]" -Property AssignedLicenses
Set-MgUserLicense -UserId "[email protected]" -AddLicenses $mgUser.AssignedLicenses -RemoveLicenses @()Verify the result:
Get-MgUserLicenseDetail -UserId "[email protected]"Assigning in the Microsoft 365 admin center
On the Users > Active users page, select the user, choose Licenses and Apps in the right pane, expand Licenses, select the licences and choose Save changes. On the Billing > Licenses page, you can instead select a product, choose Assign licenses and add up to 20 users or groups at a time.
PowerShell and the Microsoft Graph API are the alternatives when you need to assign licences in bulk.
Step 4: Fix group-based licensing errors
Group-based licensing does not fail immediately like a direct assignment. It records the failure on the user and shows it later in the admin center.
To find the affected users:
- In the Microsoft 365 admin center, go to Billing > Licenses.
- Select the product.
- Open the Errors & issues tab to see users with assignment problems.
- Select a user to see the type of error.
Microsoft lists the usage location problem as "Usage location isn't allowed": the user's usage location is either missing or set to an unsupported location. The documented fixes are:
- Set the correct usage location on the user.
- Remove users in unsupported locations from the licensed group.
- Make sure the location is populated when the user is created.
If a user has no usage location, group-based licensing uses the tenant location. That means a missing location by itself may not block a group assignment, but an unsupported location will.
After you fix the underlying problem, select the affected user or group and choose Reprocess. When you reprocess from the admin center, the feature handles up to 20 users at a time. Our guide to group-based licensing in Microsoft 365 covers how licences flow from groups.
Other errors that appear in the same tab are listed in Microsoft's table of problems, including not enough licences, conflicting service plans and duplicate proxy addresses. Fix the one the user actually has, since a usage location change will not clear a different error.
Troubleshooting
| Symptom | Likely cause | Fix |
|---|---|---|
| Direct assignment fails for a synchronized user | No location by default on synchronized accounts | Set UsageLocation with Update-MgUser, then assign again |
| Script creates and licenses a user, and licensing fails | The property was not set at creation | Set UsageLocation in the create step, or set it before assigning |
| Group-licensed user shows an error | Usage location unsupported | Correct the location or remove the user from the group, then Reprocess |
Get-MgUser misses users | Only 100 returned without -All | Add -All |
| Not enough licences | Plan has no free units | Buy more, remove unused assignments or free licences from other users |
| Some users fixed, others still error | Reprocess handles 20 users at a time | Repeat the reprocess for the next set |
| Location is set but assignment still fails | A different error such as a conflicting service plan | Open the user's error detail and fix that cause |
If you run assignments from an unattended script, authenticate with app permissions rather than a signed-in admin, and give the app only the permissions it needs. Microsoft's assignLicense reference lists LicenseAssignment.ReadWrite.All as the least privileged permission for the API.
Checklist to prevent the error
- Make location a required field in whatever process creates users, whether that is the admin center, a script or an HR-driven import.
- For synchronized users, run the check from Step 1 on a schedule, so new accounts without a location are found before users ask for a licence.
- Keep one tested script that sets the location and then assigns the licence, in that order.
- For group-based licensing, review the Errors & issues tab after you add large numbers of users to a licensed group.
- Use the tenant location only as a fallback, not as a substitute for setting the correct country for users who work elsewhere.
References
- Assign Microsoft 365 licenses to user accounts with PowerShell (Microsoft Learn)
- Assign or unassign licenses for users in the Microsoft 365 admin center (Microsoft Learn)
- Assign or unassign licenses to a group in the Microsoft 365 admin center (Microsoft Learn)
- user: assignLicense (Microsoft Graph v1.0)
Comments
Questions and tips are welcome. Comments are checked by the EpiFive team before they appear; please do not share passwords, phone numbers or other private details.