I want to add ExchangeOnlineManagement feature in Azure source IdentityNow.
I am using certification based authentication through thumbprint. Test connection is working fine but during full account aggregation i am getting error.
I am using same IQService server, Same certificate, Same service account in sandbox so everything is working in Sandbox, not getting any error.
but In prod I am getting error in full account aggregation.
when i ran the command, I got my domain name but default value was false.
I am getting below error: Please check online documentation for assigning a correct directory roles to Azure ad application for EXO app only Authentication.
When using certificate-based (app-only) authentication with Connect-ExchangeOnline, you must ensure two main things are in place for your Production Azure AD app, especially if it differs from what you used in the Sandbox:
Your Production Azure AD application has the required permissions and roles
Exchange Online recognizes the domain (i.e., it is an Accepted Domain, and if needed, set as default or properly referenced).
Below are the common causes and how to fix them:
1. Verify that the correct permissions and roles are assigned
For certificate-based (app-only) Exchange Online authentication, your Azure AD application must have either:
The Exchange Administrator role in Azure AD or
The appropriate app permissions granted (e.g., Exchange.ManageAsApp) with admin consent.
Steps to check/assign roles to your Production application
In the Azure portal, navigate to Azure Active Directory → Enterprise Applications → All Applications and select your Production app (the one with the App ID that’s failing).
Go to Permissions or API permissions for that app.
Ensure you have the Exchange.ManageAsApp (or a similar Exchange permission) under Application permissions.
Click Grant admin consent to confirm that the permission is fully granted across the tenant.
Go to Azure AD → Roles and administrators → look for Exchange Administrator (or Global Administrator) and confirm that your service principal (Production app) is assigned the necessary role.
Note: In many cases, simply adding the Application permission isn’t enough—you must also grant admin consent at the tenant level, and/or ensure that the application is assigned the Exchange Administrator role if your org’s policies require it.
2. Confirm the domain is recognized in Production (Accepted Domain)
When you see messages about the domain not being found or references to “default value = false,” it often indicates a domain mismatch or that the domain is not “Default” within Exchange Online. Some points to verify:
Run:
Get-AcceptedDomain
to ensure your Production domain is indeed listed.
Check the Default column to see which domain is set as default in Production. If your Organization parameter in Connect-ExchangeOnline points to a domain that is not recognized or not set to default, you can:
Or remove -Organization <domain> from your Connect-ExchangeOnline command if you don’t actually need to specify it.
Make sure that the Production tenant’s domain references match exactly (e.g., mycompany.onmicrosoft.com vs. mycompany.com). A small typo or a mismatch in your Production domain vs. the Sandbox domain can cause errors.
3. Confirm the same certificate and thumbprint usage
You mentioned you’re using the same IQService server and same certificate (thumbprint). A couple of reminders:
Ensure that the certificate is imported into the Local Machine → Personal store (where the private key is accessible) on the server where IQService runs.
Double-check that you are using the correct thumbprint (no hidden spaces or character differences) for the Production environment’s app registration.
4. Validate the connection from the Production environment
It’s always good to test the Connect-ExchangeOnline call directly on the IQService host (or wherever the PowerShell is running) using the Production app details. For instance:
If you still see “Domain not found” or “Please check the documentation for assigning the correct directory roles…”, that’s a clear indicator that the Production app has not been assigned the right role/permission or that the domain reference is incorrect.
5. Summary of Key Troubleshooting Steps
Assign the Exchange Administrator role (or required permissions) to your Production Azure AD app. Grant admin consent for Exchange.ManageAsApp.
Verify the Accepted Domain configuration in Production. Make sure the domain in -Organization matches one in Get-AcceptedDomain and is recognized.
Confirm the certificate is installed correctly, and you’re using the correct thumbprint for Production.
Test the Connect-ExchangeOnline command manually (outside of SailPoint) from the same server to isolate issues with domain or role misconfiguration.
By ensuring these points, your Production environment should match the Sandbox configuration and allow you to run full account aggregations successfully without the “Domain not found” or “Directory roles” error.
And one more thing, my prod app have Exchange.ManageAsApp with admin consent but prod app do not have “Exchange Administrator” or Global Administrator role.
Note: If you still see “Command not found,” it almost certainly means you are either not fully connected to the Exchange Online session or do not have a role that exposes that cmdlet.
2. Check your role/permissions in Azure AD
Even if you are connected to Exchange Online, the cmdlet might not show up if your account or service principal doesn’t have the required Exchange admin privileges. The Set-AcceptedDomain cmdlet requires at least one of these roles:
Global Administrator
Exchange Administrator (sometimes known as “Exchange Service Administrator”)
If your account does not have one of these roles, you will see a “Command not recognized” error or an access error.
To check:
In the Azure portal, go to Azure Active Directory → Roles and administrators.
Look for Global Administrator or Exchange Administrator and confirm the user you’re authenticating with is assigned.
3. Use the Exchange Admin Center (EAC) as a workaround
If you have the admin privileges but are having trouble with PowerShell, you can also change the default accepted domain via the Exchange Admin Center in Microsoft 365:
