Someone at your organization is connecting a Microsoft 365 mailbox to Kolleno and it is failing. This page is the troubleshooting companion to the setup guide: what each error means, which checks to run, and the fix for each result.

Nearly every failure is one of five things. Kolleno's application is registered in Exchange under the wrong object ID, the management scope does not match the mailbox's primary address, the role assignments were never created, the mailbox is not one Microsoft Graph can reach, or the change is correct and has not propagated yet. The checks below tell you which.

If you have not run the setup yet, start with For IT admins: giving Kolleno access to one shared mailbox (Microsoft 365). Everything here assumes those steps have been attempted at least once.

The one check that decides everything

In an Exchange Online PowerShell session, run this against the mailbox you are connecting:

Connect-ExchangeOnline -UserPrincipalName you@yourcompany.com
Test-ServicePrincipalAuthorization -Identity 7bdba930-27b8-4bad-a068-157e92f6759c -Resource ar@yourcompany.com | Format-List

7bdba930-27b8-4bad-a068-157e92f6759c is Kolleno's application ID for shared mailbox connections. It is the same for every customer. Replace only the mailbox address.

There are three possible results and they point at different problems.

Result	What it means
Two rows, both `InScope : True`	Exchange is configured correctly. If Kolleno still fails, go to Everything checks out and it still fails.
Rows showing `InScope : False`	The role assignment exists, but its scope does not cover this mailbox. Go to When the check says False.
No output at all	Nothing matched. Either there are no role assignments for Kolleno, or the values you passed do not exist. Go to When the check prints nothing.

An empty result is not a pass. PowerShell prints nothing when a command matches nothing, which looks identical to success. Two things commonly cause it: the assignments genuinely do not exist, or you pasted commands that use variables such as $app into a different window from the one where those variables were set, so every command ran against an empty value.

What the message in Kolleno tells you

Kolleno checks a mailbox by reading its inbox folder through Microsoft Graph, and turns Microsoft's response into one of these messages.

Message in Kolleno	What Microsoft returned, and what to do
This mailbox hasn't been authorized yet	403. Kolleno's application exists in your tenant, but this mailbox is not in its Exchange scope, or the change has not propagated. Start with the check above.
Mailbox not found	404. Graph cannot see a mailbox at that address. Go to "Mailbox not found".
Could not verify the mailbox right now	Kolleno could not get a token for your tenant, or Microsoft returned something unexpected. Go to "Could not verify the mailbox right now".
This consent link is invalid or has expired	Nothing reached Microsoft. Go to Problems with the admin consent link.
Admin consent was not granted	Microsoft did not confirm the consent. Go to Problems with the admin consent link.

The full diagnostic

Run all eight checks, every time, even if you are confident which one is at fault, and keep the output. If the connection still fails at the end of this page, that transcript is what we need in order to help: the result of a single check, or a description of it, is not enough to tell the cases above apart.

Record the session to a file so you can send it as it is. In your Exchange Online window:

Start-Transcript -Path "$HOME\Desktop\kolleno-diagnostic.txt"

Then edit the two values at the top of the block below and paste the whole thing into that same window. When it has finished:

Stop-Transcript

That leaves kolleno-diagnostic.txt on your desktop, holding both the commands and their output. Nothing in it is a secret: there are no tokens, passwords or message contents, only configuration. Copying and pasting the window contents works just as well, as long as it is the complete text rather than a screenshot.

$app = '7bdba930-27b8-4bad-a068-157e92f6759c'
$mbx = 'ar@yourcompany.com'

'=== 1. Which tenant am I connected to ==='
Get-ConnectionInformation | Select-Object UserPrincipalName, TenantId

'=== 2. Is Kolleno registered in Exchange (setup step 3) ==='
Get-ServicePrincipal | Where-Object { $_.AppId -eq $app } |
    Format-List DisplayName, AppId, ObjectId, ServiceId

'=== 3. The mailbox, and its primary address ==='
Get-Mailbox $mbx | Format-List Name, PrimarySmtpAddress, EmailAddresses, RecipientTypeDetails

'=== 4. Role assignments for Kolleno (setup step 5) ==='
$assignments = foreach ($role in 'Application Mail.ReadWrite', 'Application Mail.Send') {
    Get-ManagementRoleAssignment -Role $role | Where-Object { $_.Name -notlike '*Delegating*' }
}
$assignments | Format-List Name, Role, RoleAssignee, RoleAssigneeType, CustomResourceScope

'=== 5. What each scope actually matches (setup step 4) ==='
foreach ($name in ($assignments.CustomResourceScope | Where-Object { $_ } | Select-Object -Unique)) {
    $scope = Get-ManagementScope $name
    $scope | Format-List Name, RecipientFilter, ScopeRestrictionType
    Get-Recipient -RecipientPreviewFilter $scope.RecipientFilter |
        Select-Object PrimarySmtpAddress, RecipientTypeDetails
}

'=== 6. The verdict (setup step 6) ==='
Test-ServicePrincipalAuthorization -Identity $app -Resource $mbx | Format-List

'=== 7. Is an application access policy blocking it ==='
Get-ApplicationAccessPolicy | Format-List AppId, PolicyScopeGroupId, AccessRight, Description

'=== 8. Are all your domains in this tenant ==='
Get-AcceptedDomain | Select-Object DomainName, DomainType

Send us all eight results, including the empty ones. A check that printed nothing is a finding in its own right, and it is often the one that identifies the problem, so please do not trim the quiet parts out before sending.

Healthy output looks like this: 2 prints one entry with an ObjectId, 3 shows your mailbox with the address you typed into Kolleno as its PrimarySmtpAddress, 4 shows two assignments, 5 lists your mailbox among the recipients the scope matches, 6 shows two rows of InScope : True, and 7 lists no policy for Kolleno's application ID.

When the check says False

Work through these in order. The first is by far the most common.

1. Exchange is registered under the wrong object ID

Setup step 3 needs the object ID of the enterprise application in your tenant. The value is easy to confuse with the application ID, and with the object ID of an app registration. Compare what Exchange holds with what Entra shows:

Get-ServicePrincipal | Where-Object { $_.AppId -eq "7bdba930-27b8-4bad-a068-157e92f6759c" } |
    Format-List DisplayName, AppId, ObjectId

The ObjectId must match Microsoft Entra admin center, Enterprise applications, Kolleno RBAC, Object ID on the overview. Make sure you are under Enterprise applications and not App registrations.

If they differ, the role assignments are pointing at an object that does not correspond to Kolleno, which is why the scope never binds. Remove and redo. List the assignments, remove yours by name, leaving any row ending in -Delegating alone:

Get-ManagementRoleAssignment -Role "Application Mail.ReadWrite" | Select Name, RoleAssignee, CustomResourceScope
Get-ManagementRoleAssignment -Role "Application Mail.Send" | Select Name, RoleAssignee, CustomResourceScope
Remove-ManagementRoleAssignment "<NAME_FROM_THE_LIST_ABOVE>"
Remove-ServicePrincipal 7bdba930-27b8-4bad-a068-157e92f6759c

Then run setup steps 3 and 5 again with the correct object ID.

2. The scope does not match the mailbox address

Check 5 in the diagnostic shows which recipients your scope actually matches. If your mailbox is not in that list, the scope is the problem. Two traps account for most cases.

The filter names an alias, not the primary address. PrimarySmtpAddress -eq matches only the primary address. Compare the filter against PrimarySmtpAddress and EmailAddresses from check 3. A mailbox whose primary address is on one domain and whose alias is on another, for example .net against .com, fails here even though both addresses reach the same inbox.
The address in the filter does not exist. A typo, or a mailbox in another tenant, and check 5 returns no recipients at all.

Correct the filter in place rather than creating a second scope:

Set-ManagementScope "Kolleno mailboxes" -RecipientRestrictionFilter "PrimarySmtpAddress -eq 'ar@yourcompany.com'"

Connecting several mailboxes, across entities or domains, is easier with a mail-enabled security group holding all of them:

Set-ManagementScope "Kolleno mailboxes" -RecipientRestrictionFilter "MemberOfGroup -eq '$((Get-DistributionGroup 'Kolleno mailboxes').DistinguishedName)'"

Adding a mailbox to that group later needs no further Exchange work, though the membership change takes the same propagation time as everything else here.

3. The role assignments are missing or point at another scope

Check 4 should show two assignments, one for Application Mail.ReadWrite and one for Application Mail.Send, with RoleAssignee equal to the object ID from step 1 of the setup guide and CustomResourceScope equal to your scope name. Rows whose names end in -Delegating are normal and belong to Organization Management: leave them.

If check 4 is empty, the assignments were never created. Run setup step 5. If only one of the two is present, Kolleno can either read or send but not both, and the connection fails.

4. An application access policy is blocking Kolleno

Application access policies are the older mechanism for limiting an application to certain mailboxes, and a tenant that uses them for other vendors may have caught Kolleno in one. Check 7 lists them. If Kolleno's application ID appears with RestrictAccess, confirm the effect on your mailbox:

Test-ApplicationAccessPolicy -Identity ar@yourcompany.com -AppId 7bdba930-27b8-4bad-a068-157e92f6759c

If the result is denied, either add the mailbox to the group the policy scopes, or remove the policy for this application and rely on the RBAC scope instead.

5. Your session is holding a stale token

If you created the service principal or changed role assignments in the same window you are testing from, Exchange may still be using the token it issued before those changes. Reconnect and re-run the check:

Disconnect-ExchangeOnline -Confirm:$false
Connect-ExchangeOnline -UserPrincipalName you@yourcompany.com

When the check prints nothing

Nothing matched the query. In order of likelihood:

Variables are empty. If you are running the commands with $app and $mbx, they only exist in the window where you set them. Paste the whole diagnostic block into one window, top to bottom.
There are no role assignments yet. Check 4 is also empty. Setup step 5 has not been completed, or it was run and errored. Run it again and read the error.
The wrong ID was passed. Test-ServicePrincipalAuthorization -Identity takes the application ID, 7bdba930-27b8-4bad-a068-157e92f6759c, not the object ID you used in the setup steps.
The mailbox address does not exist in this tenant. Check 3 returns an error rather than a mailbox. Confirm with check 1 that you are connected to the tenant that owns the mailbox.

"Mailbox not found"

Microsoft returned 404, meaning Graph could not see a mailbox at that address at all. Start here:

Get-Recipient ar@yourcompany.com | Format-List Name, PrimarySmtpAddress, RecipientType, RecipientTypeDetails

An alias was entered in Kolleno. Enter the PrimarySmtpAddress, which is also what the scope should filter on.
It is a distribution list or a Microsoft 365 group, not a mailbox. RecipientTypeDetails shows MailUniversalDistributionGroup or GroupMailbox. Kolleno needs a shared or user mailbox. A distribution list that forwards into a mailbox will not work: connect the mailbox behind it.
The mailbox is still on-premises. In a hybrid setup, a mailbox that has not been migrated to Exchange Online is not reachable over Graph, and appears as MailUser in Exchange Online. It has to be migrated before it can be connected.
The mailbox is too new, or was recently deleted and restored. Provisioning is not instant. Wait, then retry.
A user mailbox with no licence. Shared mailboxes need no licence, user mailboxes do, and an unlicensed one eventually stops responding over Graph.

"Could not verify the mailbox right now"

This one is not about the mailbox. Kolleno either could not get a token for your tenant, or Microsoft answered with something other than success, not authorized or not found, for example throttling or a service incident.

Retry after a few minutes. If it persists, check that Kolleno RBAC is still listed under Enterprise applications in Entra. If it was deleted, or the authorization was revoked in Kolleno, the tenant has to be authorized again with a fresh consent link before any mailbox can be connected.

It is also worth looking at Microsoft's own record of the attempt: Entra admin center, Sign-in logs, Service principal sign-ins, filtered on application ID 7bdba930-27b8-4bad-a068-157e92f6759c. If your tenant applies Conditional Access to workload identities, a policy blocking the application shows up there and nowhere else.

Problems with the admin consent link

"This consent link is invalid or has expired"

Each link is single use and valid for 24 hours. Ask your Kolleno contact to generate a new one. Note that opening the same link a second time produces this message even when the first attempt succeeded, so check in Kolleno whether the tenant is already authorized before assuming it failed.

"AADSTS650051: The service principal name is already present for the tenant"

Kolleno's application already exists in your tenant, usually because it was created by hand with New-MgServicePrincipal or New-ServicePrincipal, or consented to earlier. Open the link again first, as this often succeeds on the second attempt.

If it keeps failing, remove the existing object and let the consent create it. Remove the role assignments first, then Exchange's record, then the enterprise application in Entra admin center under Enterprise applications, Kolleno RBAC, Delete:

Remove-ManagementRoleAssignment "<NAME_FROM_CHECK_4>"
Remove-ManagementScope "Kolleno mailboxes"
Remove-ServicePrincipal 7bdba930-27b8-4bad-a068-157e92f6759c

Then open the consent link again and run the setup from step 1. The object ID changes when the object is recreated, so the earlier value is no longer valid anywhere.

"Admin consent was not granted"

The consent screen was closed or declined, or your tenant routes consent through an approval workflow and the request is waiting for review. The account opening the link needs to be able to grant tenant-wide admin consent, which in most tenants means Global Administrator. Consent here records your tenant with Kolleno. It grants no mailbox access on its own: that comes only from the Exchange scope you create.

Several Kolleno entities

Consent is recorded per Kolleno entity. If your organization runs several entities, for example one per legal entity, each one needs its own consent link opened, even when they all share one Microsoft tenant. One Exchange scope can still cover every mailbox: use the mail-enabled security group approach above rather than repeating the setup per entity.

More than one Microsoft tenant

Check 8 lists the domains in the tenant you are connected to. If the domain of one of your entities does not appear, that mailbox lives in a different tenant, and the whole setup has to be run there by an administrator of that tenant.

Errors while running the setup commands

These three come up during setup rather than at connection time, and are covered in more detail in the setup guide.

Connect-MgGraph fails with "Method not found ... WithLogging". The Exchange module is loaded in that window. Use a separate window for Graph, or take the object ID from the Entra portal instead.
"You must first enable organization customization". Run Enable-OrganizationCustomization once, then repeat the step.
An error about a delegating role assignment without a scope restriction. Your session predates the service principal. Disconnect, reconnect, and run the assignment again.

Everything checks out and it still fails

If check 6 says InScope : True for both rows and Kolleno still cannot connect, it is almost always propagation. Exchange applies these changes on a delay that is usually minutes but can reach a couple of hours, and it applies in both directions, so a correction to a wrong scope also takes time to take effect.

Wait, retry the connection in Kolleno, and re-run check 6 afterwards to confirm it still reports True. If the result has changed, something else in the tenant is modifying the assignments.

What to send us

If it is still failing after the checks above, send your Kolleno contact the following. We cannot diagnose this from a description of what you saw, so please include the transcript itself.

The complete output of all eight checks, as the kolleno-diagnostic.txt transcript or pasted as text, including every check that printed nothing and any red error text
The mailbox address exactly as it was typed into Kolleno
Your tenant ID, from check 1
The name of the Kolleno entity the connection was attempted from
The date and time, with time zone, of the most recent attempt

The timestamp matters: we record the exact response Microsoft gave for each attempt, and it lets us match your attempt to that record rather than guessing. Together with the transcript, that is normally enough for us to say which side the problem is on without a call.

Please do not grant Mail.ReadWrite or Mail.Send tenant-wide in Entra as a workaround. The effective permission is the union of the Entra grant and the RBAC scope, so it would cancel out the restriction and give Kolleno access to every mailbox in your tenant. If the checks on this page pass and the connection still fails, tell us instead.

Troubleshooting a Microsoft 365 mailbox connection (for IT admins)