App Registrations Setup
The solution uses two Entra ID app registrations: an installer account to create the Azure resources, and a runtime account to read Microsoft 365 data. Create and configure both before running the installer (Deployment Guidance) or a manual install. For the permissions these need, see Prerequisites -> Permissions.
Two registrations is the whole list. SharePoint web tracking needs an administrator to sign in interactively during install, but it does not need a third app registration — the installer uses Microsoft's built-in SharePoint Online Management Shell application. Only tenants that block that app need to register their own; see Optional: use your own Entra ID app registration.
For both accounts follow this process:
Create an app registration with Entra ID. Find the Entra ID section:
Add new app registration through portal.azure.com – the Entra ID blade.
New registration name: Microsoft 365 Advanced Analytics - Runtime or Microsoft 365 Advanced Analytics - Installer (you need to repeat this process for each registration).
Leave the "redirect URIs" for now, but we will need to add them later for the runtime application. Click "Register" to create the application registration.
You should now be sent to the new application you've just created. Next, we need to add a client secret.
Create a new client secret for the app registration with the following information:
- Description: whatever you want. Blank is fine.
- Expires: the maximum amount you can (or a date you'll have to change the secret & update configuration).
Click "add" and the secret will be generated. Copy & store the key that is shown.
Remember to save the secret value – we will need this later. Do NOT copy the Key ID.
Go to application overview. Copy & store application registration ID and the directory ID:
The application should be now created. You need the client ID, secret value, and directory ID for both installer & runtime applications.
Important: both accounts need to be in the same Entra ID directory.
The runtime service principal must have permissions granted to the activity and Graph API. This is not something granted by default, so needs to be added after registration.
The list of permissions can be found in the prerequisites docs.
In the runtime app registration, add the permissions in the following screenshot. Click "API permissions" and then "Add a permission".
There are two sources we need to read data from: Office 365 Management API and Microsoft Graph.
The permissions for the Office runtime application should look like this if you need all the permissions used (see your solution specific documentation):
When permissions are added initially, they are not granted until an Entra ID administrator can consent to them.
Important: grant admin consent to the application to complete configuration.
This may take some time internally within your organisation to get approved.
All Entra ID permissions should now be configured for the runtime application.
Once the permissions above have been set, you can validate them in the installer application easily. Open the installer/control-panel, and just fill out these fields:
Then on the Install tab, click "Test Configuration"
When testing configuration, no changes are made in any way to anything. The installer just simulates similar reads the importer web-jobs will do and reports their success.
For the web application to correctly authenticate users, its URL must be registered as a reply URL (redirect URI) on the runtime app registration, and ID tokens must be enabled.
This is documented on its own page — including the exact URL format (the HTTPS root with a trailing slash), the token settings to enable, handling multiple environments, and how to troubleshoot the common AADSTS50011 redirect-URI-mismatch error:
Note: this step requires the URL of the Azure App Service you have (or will have) created. You may need to come back to it once the app service exists — but don't skip it, as it's required for the website to work.
Follow the same process above to create a runtime service principal. For this account, no permissions are added, we just need an application registration & secret.
For the installer we need to grant it permissions to an existing resource group in the Azure subscription. From the portal, create a new resource group:
Once created we can add the installer permissions to it.
In the resource group, add the installer account to list of role assignments:
Next find the role owner.
Next pick who we want to add as "owner" to this group.
Select members and search for the installer account. Selecting it will add it to the select list.
Confirm we have the right permissions:
Click "review + assign" to verify one last time.
When you click this a 2nd time, Azure will add the role:
The installer account has been added to the resource group.
Next, we need to do the same for the subscription, but with reader permissions. Go to the subscription that hosts the resource group:
In access control, add a new role:
This time add reader role:
Great! The installer should now be able to create all the resources needed.
Finally, register the web app's URL as a reply URL on the runtime app registration so users can sign in to the website — see Runtime app reply URLs (we recommend doing this once the app service exists, as you'll need its URL).