Microsoft Online - User & Service Troubleshooting

Overview

This page is to be used for troubleshooting errors related to provisioning or managing the Microsoft Online service. You can use the navigation menu on the right to locate your error.

Invalid Values

Invalid Value - with no description of the value

If you have ADFS enabled, you may see the error “One or more properties contains invalid values”

This will be because the user is being provisioned and not following the ADFS route for setup, or has an invalid source anchor. Please try the below or reach out to Atria’s support for assistance

1. Reprovision the Customer Service of Azure AD
2. Resync the customer tenant with O365
3. Try Reprovision the user

Invalid Values - With the specified property

This means Atria doesn’t match what exists in AzureAD. In this case, it’s erroring on “BusinessPhones”. This is the attribute in AAD for “Phone number”.

But in Atria it shows under this attribute.

So - Find what it is erroring on (Phone number in this example) then Reprovision the user, and it should now be functional.

Could not find suitable match for “License Type”

For example, the below user is failing the sync due to

590 <customer> Syncing Licenses for user@domain.com Could not find a suitable match for Microsoft Teams Commercial Cloud (User Initiated) 2 Error NULL 2020-05-07 10:00:11.840

We can see the error it doesn’t have a suitable match. This means the customer doesn’t have this license provisioned to them.

So go to the tenant in Atria, you see their licenses which also finds this “Team’s license'

Go into “Advanced Settings” and confirm that the user plan is there. We can see it hasn’t been provisioned for this customer, so select the plan and hit “Provision”. The license should be resolved after the next sync.

Not Enough Information was Specified to Generate a Username

This error occurs when a user is missing either

• Firstname
• LastName
• Display Name

Log into Microsoft 365 Admin Center and navigate to the user. You’ll likely be able to identify that the user in question is missing a firstName and lastName value.

At a minimum, we require either a First name, which would generate a DefaultLastName, but if the Display Name is present this gets used.

Set the required Attributes, then the user will be imported as needed.

This could be because there is no subscription in your partner center for this.

This means that the license is purchased by another reseller or on a credit card.

This can be disregarded, as this is due to the licenses being managed externally to your partner center.

Company Name	Cannot reduce subscription for Office 365 E1	This could be because there is no subscription in your partner center for this.

A unique UPN must be specified

If a user is unable to sync, search their UPN within Atria to find the duplicated user who already exists. This could be from a user not properly being deleted, or somehow being duplicated.

One example of this is when a customer moved from one to the other, the users became “Duplicated”.

This could also mean that a customer has a MSOL domain against them, which is also owned by another customer. This is a “Customer Domain Claim Issue”. For example, for Customer1 - Their domain is also used by Customer2. Causing the user sync to fail as the domain isn’t unique within the UPN.

Failed to get user licenses with error: Resource "GUID does not exist or one of its queried reference-property objects are not present"

This typically means that the user was deleted from O365 but not from Atria. Confirm that the user doesn’t exist in O365, then investigate if this is related to a case and not properly completed.

Failed to Update User Licenses - License Assignment failed because Service Plans

License Assignment Failed because **Service Plans GUID**, **GUID** are mutually exclusive.

Microsoft’s products require specific settings to co-exist. This means that if you add a two licenses that contain the same “Application” Such as adding Dynamics 365 and Microsoft 365 Business Premium, It will error on allocation as both SKUs contain Power Apps.

Unfortunately, this requires some juggling and research to resolve. The Atria team is working on a fix and in some scenarios you will not see this issue, but you will need to confirm the following.

If you would like assistance with this issue, please log a ticket with Atria Support as this is quite an odd one!

1. Identify the Service Plans and their relations to Product Features1. Microsoft have provided this list which provides the list of Service Plans and their respective items with Friendly Names

Product names and service plan identifiers for licensing - Azure AD - Microsoft Entra | Microsoft Learn

2. Identify the items in the Product Feature per product in Atria, and select a master “User Plan” to own the service plan item (Such as Power Apps being on the Microsoft 365 Business Premium license)
3. Disable the Service Plan identified in the other license (In our example, this would be PowerApps)

Object Reference is not set to an Instance of an Object.

This issue typically occurs when a user is being provisioned while they don’t exist in Office365, while AD connect is Enabled.

Force a directory sync of your On-Premise AD with the Microsoft 365 Tenant and then try reprovisioning.

User License is Inherited from a Group Membership

This is an error that is caused when a user isn’t licensed directly but is inherited through group-based licensing.

Atria currently does not support Group Based Licensing, so this needs to be removed and transferred to per user.

If you go to Azure AD, search “Licenses” then into the license that the user has, under “Licensed groups” on the left you will see what group is inheriting the license.

Then if you click into the group, you should see the user

Remove this user from the group to resolve the issue, then you will be able to provision the MSOL service from the user.

Sequence Contains No Matching Element

This error means customer domain claim is wrong for primary domain, Atria has a concept of “Domain Ownership” and who is the primary user of this domain. Typically, you won’t run into this issue, but if it does – We need to make the Customer the primary owner of the domain.

This is due to Microsoft only allowing a domain to exist in one Microsoft Tenant, so we also have the condition to check for the domain ownership.

• If you are not confident with SQL, please get in touch with our Friendly support team
• Identify the customers domains which the affected customer is having the problem

Select * from CustomerDomain where customerid = 2

• If IsOwner is 0, run the below to find the correct customer

SELECT * FROM CustomerDomain WHERE CustomerDomain = 'dyncorp.com'

If this is not owned by any other customer, perform the below

update CustomerDomain

set IsOwner = 1

where CustomerDomain = 'dyncorp.com'

Failed to retrieve objects from Exchange

This error occurs when Atria cannot connect to the Customers Exchange Online environment. This could be a few things

• Conditional Access Policies are blocking the authentication attempt
  • Log into the Customers Microsoft 365 Tenant, and check the Sign In Logs to see if this is being blocked due to policy
• The Atria user that is used for authentication has had a new MFA method or had the account tokens revoked
• Remote PowerShell is disabled for Exchange Online
• Connectivity issues or potential Microsoft Outage

If you are unsure or need further assistance on how to troubleshoot this error, please reach out to our friendly support team.

Password does not meet the history or complexity requirements

The MSOL Sync process may fail if the passwords it generates do not meet the requirements of your AD Password Policy. The following errors will appear when synchronising users from Azure AD to Atria.

The resolution is to create a New MSOL Sync Policy. The sync policy is maintained via an internal API, the following article will show you how to use the API to edit the Sync Policy. How to resolve password generation problems in the MSOL Sync Policy

Sync fails for an Active Directory User and Azure Active Directory user even when their UPN’s Match

When syncing a user that exists both in Active Directory and Azure, the sync process fails to find the user in Azure, even though the Login Name (UPN) matches in both directories. In addition, users in Azure may not be found by the Sync process when they appear valid.

Users in Azure have an attribute called userType, this typically has two settings, “Member” and “Guest”. Guest accounts are used as proxy users by Teams and SharePoint to grant external users access to resources. For example, if you share a file with an external user, a Guest account is created in your companies Office 365 Azure AD tenant.

When you create a new user account, the default userType is “Member”, the SyncPolicy for the Azure AD Synchronization process has a filter which restricts the list of users to Members.

The userType attribute was introduced into AzureAD in 2014, for older tenants with users that were created prior to this they may have an empty userType value. The default filter in the sync policy is set to only retrieve users of type Member and will not return these users.

To resolve, you need to set the UserType to “Member” for the users that are not appearing, this cannot be done via the Azure AD User Interface, but can be done using Powershell:

set-MsolUser -UserPrincipalName username@contoso.onmicrosoft.com -UserType Member

Could not find the service with name ‘MSOL’ or ID ‘0’ for user ID UserID

This occurs if the Microsoft Online Service has not been provisioned to the customer. To resolve, locate the customer and provision the Microsoft Online Service ensuring the correct plans are enabled. Re-run the sync and Atria will assign the correct Microsoft Online plans to the users.

Failed to find Customer Customer or Customer not found

This is due to the Partner Center Connection being set incorrectly. Please confirm which Microsoft Partner type you are, and update the Partner Center Connection as needed.

Failed to load Azure AD data: AADSTS65001:

The user or administrator has not consented to use the application with ID Guid named 'ApplicationName'. Send an interactive authorization request for this user and resource.

As of October, DAP is no longer present on tenants. This means that GDAP needs to be enabled against these tenants. For more information regarding GDAP, please see here - Microsoft Online - How does GDAP apply to Atria?

Once GDAP is used, please make sure you are using the two new Graph based Scripts within the portal for Authentication. These are located on the provisioning server

Once these two script(s) have been run and the Partner Center within the portal updated with the output, reprovision the Azure AD service for the affected customer. This will correctly grant the consent to the application for the customer.

warning

If you are still seeing this issue, please make sure the Grant was completed with the Service Account with REQUIRES MFA to be enforced. If MFA was not enforced and you did not receive either a prompt or an SMS (Or other MFA method), the grant will not be created with the correct requirements.