# Microsoft 365 Licence Assignment Error: Usage Location Required Fix

> Fix the Microsoft 365 licence error caused by a missing or invalid usage location. Set the country with the admin center or Graph PowerShell, then assign or reprocess the licence.

Source: https://www.epifive.com/blog/microsoft-365-license-usage-location-error · Published 2026-10-25 · EpiFive

## Key takeaways

- A direct licence assignment fails when the user has no usage location, so set the two-letter country code first and then assign the licence.
- Update-MgUser with the UsageLocation parameter sets the location, and Set-MgUserLicense assigns the licence.
- Accounts synchronized from on-premises Active Directory have no usage location by default.
- With group-based licensing, users without a location inherit the tenant location, and unsupported locations show up as errors that you fix and then reprocess.
- Include the usage location in your user creation process so new accounts can be licensed immediately.

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.All` permission scope, or one of the other permissions listed in Microsoft's assignLicense reference. Reading the available licences needs `Organization.Read.All`.

Connect with the scopes you need:

```powershell
Connect-MgGraph -Scopes User.ReadWrite.All, Organization.Read.All
```

## Step 1: Find users without a usage location

To see which member accounts have no usage location, run:

```powershell
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:

```powershell
Get-MgUser -Filter 'assignedLicenses/$count eq 0' -ConsistencyLevel eventual -CountVariable unlicensedUserCount -All
```

For unlicensed synchronized users only:

```powershell
Get-MgUser -Filter 'assignedLicenses/$count eq 0 and OnPremisesSyncEnabled eq true' -ConsistencyLevel eventual -CountVariable unlicensedUserCount -All -Select UserPrincipalName
```

## Step 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

```powershell
$userUPN = "belindan@contoso.com"
$userLoc = "US"

Update-MgUser -UserId $userUPN -UsageLocation $userLoc
```

### For many users

Set the location for a list of users from a CSV with `UserPrincipalName` and `UsageLocation` columns:

```powershell
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`:

```powershell
Get-MgSubscribedSku | Select-Object SkuPartNumber, SkuId, ConsumedUnits
```

Then assign it. This example assigns Microsoft 365 E5 (`SPE_E5`):

```powershell
$e5Sku = Get-MgSubscribedSku -All | Where SkuPartNumber -eq 'SPE_E5'
Set-MgUserLicense -UserId "belindan@contoso.com" -AddLicenses @{SkuId = $e5Sku.SkuId} -RemoveLicenses @()
```

Replace `SPE_E5` with the `SkuPartNumber` of your own plan.

To copy another user's licences instead:

```powershell
$mgUser = Get-MgUser -UserId "belindan@contoso.com" -Property AssignedLicenses
Set-MgUserLicense -UserId "jamesp@contoso.com" -AddLicenses $mgUser.AssignedLicenses -RemoveLicenses @()
```

Verify the result:

```powershell
Get-MgUserLicenseDetail -UserId "belindan@contoso.com"
```

### 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:

1. In the Microsoft 365 admin center, go to **Billing** > **Licenses**.
2. Select the product.
3. Open the **Errors & issues** tab to see users with assignment problems.
4. 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](https://www.epifive.com/blog/group-based-licensing-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)](https://learn.microsoft.com/en-us/microsoft-365/enterprise/assign-licenses-to-user-accounts-with-microsoft-365-powershell)
- [Assign or unassign licenses for users in the Microsoft 365 admin center (Microsoft Learn)](https://learn.microsoft.com/en-us/microsoft-365/admin/manage/assign-licenses-to-users)
- [Assign or unassign licenses to a group in the Microsoft 365 admin center (Microsoft Learn)](https://learn.microsoft.com/en-us/microsoft-365/admin/manage/manage-group-licenses)
- [user: assignLicense (Microsoft Graph v1.0)](https://learn.microsoft.com/en-us/graph/api/user-assignlicense?view=graph-rest-1.0)

## Frequently asked questions

### Why does Microsoft 365 need a usage location before I assign a licence?

Some Microsoft services are not available in all countries or regions, so a user's location must be set before a licence can be assigned. The usage location is a two-letter ISO 3166-1 alpha-2 country code, such as US or FR.

### How do I set the usage location with PowerShell?

Connect with Connect-MgGraph using the User.ReadWrite.All scope, then run Update-MgUser with the user's UPN and the UsageLocation parameter, for example Update-MgUser -UserId belindan@contoso.com -UsageLocation US. After that, assign the licence with Set-MgUserLicense.

### What happens to users in a licensed group that have no usage location?

With group-based licensing, users without a specific location inherit the location of the tenant. If a user's location is set to an unsupported country or region, the assignment fails and shows on the Errors and issues tab until you correct it and select Reprocess.

### Do synchronized on-premises users have a usage location?

Not by default. Accounts synchronized from on-premises Active Directory do not have a location specified, so you set it in the Microsoft 365 admin center, with PowerShell or in the Azure portal before assigning licences directly.