Copilot Admin Center Says Service Principal Not Found: Safe Diagnosis

Official documentation checked October 14, 2026.

A “Service Principal Not Found” message while administering Copilot needs investigation of the actual directory object named by the failing operation. The banner alone is not enough to identify a universal missing “Copilot” application, and it does not justify creating one with an ID copied from an unrelated example.

This guide focuses on an administrator’s portal or configuration failure. If the user-facing sign-in screen also gives an AADSTS code, preserve that code and the corresponding sign-in details as additional evidence.

Identify which object the admin operation needs

A service principal is an application’s local representation in a tenant. It differs from the application’s registration and has its own object ID. Microsoft’s application-object documentation explains why these identifiers must not be swapped.

1. Record the exact admin-center page, action, message and time. Capture any request or correlation ID shown.
2. Confirm the active directory and administrator role. If you manage multiple tenants, record the tenant ID rather than relying on similar organization names.
3. Determine the application ID or service-principal object ID from the error, associated logs or the service’s official deployment documentation. If none is available, ask support to identify the failing lookup.
4. Have the appropriate administrator inspect Entra ID > Enterprise apps > All applications. Include Microsoft applications in the application-type filter and use the known ID to narrow the results.

Microsoft’s enterprise-app viewing guide notes that application-type filters distinguish Microsoft and non-Microsoft apps. An empty name search is therefore not reliable evidence of deletion.

Keep screenshots and diagnostic exports within an approved support channel. Do not publish authentication tokens, secrets or confidential tenant information.

Separate an existing, deleted or unprovisioned principal

If the verified object exists: compare the tenant and identifier used by the failing request. Review relevant recent configuration changes and the administrator’s access. Do not delete a working principal and recreate it merely because the portal reported a lookup error.

If deletion is suspected: inspect directory audit evidence and the deleted-object inventory. For administrators already using Microsoft Entra PowerShell, Microsoft documents this read-only listing:

Connect-Entra -Scopes 'Application.Read.All'
Get-EntraDeletedServicePrincipal -All

Use an approved administrative session and the required permissions. Match the returned application ID and object ID against the affected service—not just its display name. These commands list objects; they do not restore anything. See Microsoft’s deleted-data recovery guide.

If the exact object is recoverable: the responsible administrator can follow the documented restoration procedure after confirming ownership, authorization and impact. Verify the service principal separately from its application registration; Microsoft’s restore API guidance requires explicit restoration of the associated principal.

If it was never provisioned or is not recoverable: follow the verified service’s onboarding or recovery instructions, or obtain Microsoft support guidance. Do not substitute a guessed AppId. There is no generally valid promise that every Copilot-related banner can be repaired by one principal-creation command.

Verify recovery and investigate recurrence

After an approved change, repeat the original administrative action and a limited user test. Confirm the intended app’s identity, permissions, assignments and relevant policy behavior. A successful create or restore response alone does not prove the Copilot feature now works.

Do not reflexively regrant all permissions. Microsoft’s permission-restoration guidance warns that regranting admin consent can remove existing permissions outside the developer’s default requested set. Review what actually changed before choosing that repair.

If the object disappears again, use audit evidence to identify the deleting identity or automation. Correct the specific lifecycle rule with its owner; an exclusion should reference a verified object, not a guessed name or GUID. If the object remains present but the error continues, provide support with both facts, the operation time and correlation details instead of repeatedly recreating it or waiting for an assumed fixed cache interval.