I was recently trying to deploy the Exclaimer Cloud for Outlook add-in via Microsoft 365 Admin Centre > Settings > Integrated Apps, but it was silently failing every time regardless of whether I targeted a single user, a group, or the entire organisation. There was no real useful information provided on the failure, it just sat and spun at the end and then said Failed.
With some help from my invisible robot friend, I took a deep API-level investigation to try and resolve it, and the fix is not documented anywhere.
Symptoms
- Integrated Apps deployment wizard completes through Users > Deployment > Permissions steps without error
- Clicking Finish deployment results in “Deployment failed” with no error message or error code
- The failure is consistent across all deployment scopes — single user, group, entire organisation
- Exclaimer does not appear in the Deployed apps tab after any attempt
- Exclaimer does not appear in the Available apps tab either
- The server-side Exclaimer pipeline (transport rules, Entra sync, email signatures) is working correctly
- All five Exclaimer enterprise apps in Entra ID show as Activated
In short: everything looks healthy, but the Outlook add-in deployment fails silently every time.
What Was Actually Happening
The Integrated Apps deployment pipeline for Outlook add-ins works by creating a PrivateCatalogApp service principal in the tenant’s Entra ID directory. This service principal carries the add-in metadata in its addIns collection, including the AppSource asset ID, capabilities, scopes, and version information.
On affected tenants, the pipeline silently fails to create this service principal, and returns no error code to the UI or to any visible log. Without this object, the deployment has nothing to register against, and the entire operation fails.
You can confirm this is your issue by inspecting the Integrated Apps metadata API response. In your browser, with DevTools > Network tab open, navigate to Settings > Integrated Apps and begin the Exclaimer deployment wizard. At the Permissions step, look for a fetch request to:
https://admin.cloud.microsoft/fd/addins/api/apps/WA200004512?type=appId&workloads=AzureActiveDirectory,WXPO,MetaOS,SharePointClick on that request and inspect the Response. On an affected tenant, you will see nearly every deployment field is null:
{
"appDetail": {
"appId": null,
"manifestVersion": null,
"manifestId": null,
"deploymentStatus": "None",
"deploymentType": "None",
"currentVersion": null,
"servicePrincipalId": null,
"isDeployed": false,
...
}
}On a tenant with a successful deployment, the same API returns:
{
"appDetail": {
"deploymentStatus": "OK",
"deploymentType": "FullRollout",
"currentVersion": "1.29.200",
"servicePrincipalId": "UUID-of-service-principal",
"isDeployed": true,
...
}
}The servicePrincipalId being null on the failing tenant confirms the service principal was never created.
How to fix this?
I manually createed the app registration and service principal in the affected tenant via the Microsoft Graph API. Once these objects had been created, the Integrated Apps deployment pipeline was then able to complete successfully.
You need to be a Global Administrator or Application Administrator in the affected tenant and have access to Microsoft Graph Explorer
Step 1 — Grant Graph Explorer permissions
In Graph Explorer, click Modify permissions and consent to:
Application.ReadWrite.AllDirectory.ReadWrite.All
Step 2 — Create the app registration
Method: POST
URL: https://graph.microsoft.com/v1.0/applications
Body:
{
"displayName": "Exclaimer Cloud for Outlook",
"signInAudience": "AzureADMyOrg",
"tags": ["PrivateCatalogApp"],
"addIns": [
{
"id": "efc30400-2ac5-48b7-8c9b-c0fd5f266be2",
"type": "PrivateCatalogStoreAddIn",
"properties": [
{"key": "AssetId", "value": "WA200004512"},
{"key": "ContentMarket", "value": "en-AU"},
{"key": "AddInState", "value": "Ok"},
{"key": "DefaultStateForUser", "value": "Mandatory"},
{"key": "AppId", "value": "214c49cc-b1f4-4105-bdd9-468bedc2056a"},
{"key": "Capabilities", "value": "ReadWrite Item;Send Data"},
{"key": "Scopes", "value": "User.Read;openid;profile"},
{"key": "Version", "value": "1.29.200"},
{"key": "DefaultDisplayName", "value": "Exclaimer Cloud for Outlook"},
{"key": "DefaultDescription", "value": "Outlook Add-In: Create and centrally manage professional email signatures for all users on M365"},
{"key": "DefaultIconUrl", "value": "https://store-images.s-microsoft.com/image/apps.40276.3263b52d-52ed-4337-afef-c4233f6fe5c1.16c69f7f-3929-48d8-a5e0-ce39dcfedb8e.00756d18-a42b-4a0d-a0e7-76888673cc2a.png"},
{"key": "ProviderName", "value": "Exclaimer Limited"},
{"key": "AutorunLaunchEvents", "value": "OnNewMessageCompose;OnMessageRecipientsChanged;OnMessageFromChanged"},
{"key": "InstallTimeAll", "value": "2026-06-01T00:00:00.0000000Z"},
{"key": "Supportedclients", "value": "Win32_Outlook;15.20.3863.0,Mac_Outlook;15.20.3863.0,IOS_Outlook;15.1.990.0,And_Outlook;16.0.8414.0,WAC_Outlook;15.20.3863.0"}
]
}
]
}A successful response returns 201 Created with a new appId GUID. Copy that value — you need it for the next step.
Step 3 — Create the service principal
Method: POST
URL: https://graph.microsoft.com/v1.0/servicePrincipals
Body (substituting the appId returned from Step 2):
{
"appId": "<appId from Step 2>",
"tags": ["PrivateCatalogApp"]
}A successful response returns 201 Created with the service principal object. Confirm appOwnerOrganizationId matches your tenant ID and the addIns array is populated.
Step 4 — Deploy via Integrated Apps
Go immediately to Microsoft 365 Admin Centre > Settings > Integrated Apps > Get apps, search for Exclaimer Cloud for Outlook, and run through the deployment wizard. It should now complete successfully with Status: OK.
Why Does This Happen?
The root cause is unclear as the Integrated Apps pipeline should be creating this service principal itself as part of the deployment process. On affected tenants, something prevents that creation, the pipeline fails silently, and Microsoft surfaces no error.
It is not caused by:
- Missing or incorrect admin consent
- Licence issues or missing Exchange Online mailboxes
- The five Exclaimer backend enterprise apps being in a bad state
- Conditional Access policies (in most cases)
- Deploying to a specific scope (single user, group, entire org)
It appears to be a tenant-level provisioning issue in the Integrated Apps pipeline, possibly related to tenant age, configuration history, or an undocumented prerequisite state that some tenants don’t satisfy.
Notes
- The
ContentMarketvalue ofen-AUreflects an Australian English locale. Adjust if deploying in a different region. - The
Versionvalue in theaddInsproperties is metadata only — set it to the current Exclaimer release version if known, or use1.29.200as of the time of writing. - The
InstallTimeAlltimestamp is informational — set it to the current date/time in ISO 8601 format. - The app registration
idandappIdwill be unique to each tenant — this is expected and correct behaviour. - After successful deployment, the add-in may show an “Updates pending” notification if the version metadata in the
addInsproperties doesn’t match the current AppSource release. This can be resolved by removing and redeploying with the current version number.
Automatica provides managed IT services and consulting for creative and professional services businesses in Melbourne. If you’re dealing with a stubborn Microsoft 365 deployment issue, get in touch.