SharePoint 2019 - SharePoint Workflow Manager - App principal does not exist

Question

SharePoint 2019 - SharePoint Workflow Manager - App principal does not exist

durica 0

I am using SharePoint Workflow Manager (16.0.19127.20336) on SharePoint 2019 (16.0.10417.20075). I noticed that any workflows are failing to run.

Error after starting WF 2013:

Details about the last request: HTTP Forbidden at _api/web/lists(guid'xxxxxxxxx')

I have imported the workflow certificate to manage trust in the central admin sharepoint. I can create and edit workflows 2013 in SharePoint Designer. The test workflow 2013 only includes writing to the workflow history.

Can you please help me solve this problem?

3 answers

Your answer

Answer 1

The error you are encountering, specifically the "HTTP Forbidden" message when trying to run workflows in SharePoint 2019 with Workflow Manager, typically indicates a permissions issue related to the App Principal. Here are some steps you can take to resolve the issue:

Check App Principal Permissions: Ensure that the App Principal has the necessary permissions to access the resources required by the workflow. You may need to register the App Principal correctly using PowerShell commands to ensure it has the right permissions.
Register the SPAppPrincipal: If the App Principal does not exist, you can register it using PowerShell commands. This involves using the Set-SPAppPrincipalPermission cmdlet to grant the necessary permissions to the App Principal on the SharePoint site. Make sure to include the -EnableAppOnlyPolicy parameter if the App Principal had App-Only permissions on the SharePoint site.
Republish Workflows: If the workflows were created before the App Principal was registered or updated, try republishing the workflows from SharePoint Designer. This can help ensure that they are correctly associated with the updated App Principal.
Run Timer Jobs: Consider running the Refresh Trusted Security Token Services Metadata feed timer job to refresh the security token services, which may help resolve any issues related to authentication.
Check Workflow Manager Configuration: Ensure that the Workflow Manager is properly configured and connected to your SharePoint farm. Any misconfiguration can lead to workflows failing to start.

If these steps do not resolve the issue, you may need to check the ULS logs for more detailed error messages that can provide further insight into the problem.

References:

Answer 2

Hi durica,

Welcome to Microsoft Q&A Forum! Have a good day and I hope you're doing well!

Thank you so much for reaching out. The error you’re seeing: 3002002; reason=App principal does not exist. Based on my research, this indicates that the App Principal does not exist or has been removed. Importing the certificate into Manage Trust was the right step to establish trust, but there’s another piece: the App Principal must be registered using Register-SPWorkflowService so Workflow Manager can obtain a token to call SharePoint’s REST API.

Steps commonly used to resolve this:

I. Open SharePoint 2019 Management Shell as Administrator and run:

Register-SPWorkflowService `
    -SPSite "https://your-webapp-url" `
    -WorkflowHostUri "https://workflow-hostname:12290" `   # or :12291 if using HTTP
    -AllowOAuthHttp `
    -Force

Note: Using -Force is what re-creates the missing App Principal so Workflow Manager can obtain an OAuth token again.

II. Then:

Perform an IISReset on the SharePoint and Workflow Manager servers.
Restart these two services on the Workflow Manager server:

Service Bus Message Broker
WorkflowServiceBackend

References:

In my testing environment, I don’t have a live SP2019 farm to verify this right now, so I recommend giving these steps a try and letting me know how it goes. I’ll continue reviewing additional documentation and related cases to gather more insights so we can troubleshoot together if needed.

I hope the information I’ve shared will clarify things for you, provide some insights, and help at least partially. If I’ve misunderstood anything or if something is unclear, feel free to let me know.

If the answer is helpful, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment".

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

durica 0 Reputation points

2026-01-07T06:57:41.4466667+00:00

Hi,

I created another post where I added another error ( https://learn.microsoft.com/en-us/answers/questions/5695788/sharepoint-2019-sharepoint-workflow-manager-app-pr ) – it kept telling me that I was violating the rules for adding posts, so I accidentally created two posts.

Your answer "Register-SPWorkflowService" does not help me, because I already have it registered and I apply it in the same way with the "Force" parameter, without which I would not be able to create Workflow 2013 or even run it. It is a page with https only. I restarted the services, IIS, and the server, but it didn't help.
Matthew-P 8,940 Reputation points Microsoft External Staff Moderator

2026-01-08T03:44:10.3666667+00:00

Hi durica,

Thanks for your response!

If your SharePoint 2013 workflows are still failing with a 403 Forbidden error despite having registered Workflow Manager with Register-SPWorkflowService -Force, the issue likely stems from either missing or insufficient permissions for the Workflow App Principal or a breakdown in OAuth token validation. You should confirm that the app principal exists and has FullControl permissions on the site using Set-SPAppPrincipalPermission with -EnableAppOnlyPolicy, and ensure that all certificates (Workflow Manager, SharePoint, and token issuer) are valid and trusted on both ends. Also verify that SharePoint and Workflow Manager servers can reach each other over the correct URLs and ports, and that IIS authentication settings on the Workflow Manager site are properly configured. These deeper checks often resolve persistent 403 errors that survive standard setup.

Check https://learn.microsoft.com/en-us/powershell/module/sharepoint-server/set-spappprincipalpermission is officially supported for SharePoint Server 2013, 2016, and 2019, and it allows you to explicitly grant permissions to an app principal on a site, including using the -EnableAppOnlyPolicy switch to allow elevated app-only access, critical for workflows that need to act independently of user context.

Microsoft’s guidance on Create a workflow with elevated permissions by using the SharePoint Workflow platform explains how workflows use app-only tokens and why proper app principal permissions are essential. These documents support the recommendation to manually verify and assign permissions when workflows fail with 403 errors despite successful registration.

I hope the information I’ve shared will clarify the situation, provide additional insights, and help at least partially. If there’s any update, please don’t hesitate to let us know.

Answer 3

durica 0

In the ULS log, I have:

The app principal i:0i.t|ms.sp.ext|f9251d09-7050-feb9-f3ed-b4fbae204c8b@4429e03e-d5b4-4354-b22b-805be7bd2896 does not exists.

After starting WF 2013, I also get the following error: User's image

RequestorId: 9c54832f-b9d8-7ddc-0000-000000000000. Details: An unhandled exception occurred during the execution of the workflow instance. Exception details: System.ApplicationException: HTTP 403 {"X-SharePointHealthScore":["0"],"x-ms-diagnostics":["3002002; reason=App principal does not exist"],"SPRequestGuid":["9c54832f-b9d8-7ddc-be24-bf82303cd0da"],"request-id":["9c54832f-b9d8-7ddc-be24-bf82303cd0da"],"X-FRAME-OPTIONS":["SAMEORIGIN"],"Content-Security-Policy":["frame-ancestors 'self' teams.microsoft.com *.teams.microsoft.com *.skype.com *.teams.microsoft.us local.teams.office.com *.powerapps.com *.yammer.com *.officeapps.live.com *.office.com *.stream.azure-test.net *.microsoftstream.com *.dynamics.com *.microsoft.com onedrive.live.com *.onedrive.live.com;"],"MicrosoftSharePointTeamServices":["16.0.0.10417"],"X-Content-Type-Options":["nosniff"],"X-MS-InvokeApp":["1; RequireReadOnly"],"Cache-Control":["max-age=0, private"],"Date":["Wed, 07 Jan 2026 14:55:06 GMT"],"Server":["Microsoft-IIS/10.0"],"X-AspNet-Version":["4.0.30319"],"X-Powered-By":["ASP.NET"]} at Microsoft.Activities.Hosting.Runtime.Subroutine.SubroutineChild.Execute(CodeActivityContext context) at System.Activities.CodeActivity.InternalExecute(ActivityInstance instance, ActivityExecutor executor, BookmarkManager bookmarkManager) at System.Activities.Runtime.ActivityExecutor.ExecuteActivityWorkItem.ExecuteBody(ActivityExecutor executor, BookmarkManager bookmarkManager, Location resultLocation)

When I am using the command:

$clientID = "**PII REMOVED**"
$site = Get-SPSite https://domain.com
$realm = Get-SPAuthenticationRealm -ServiceContext $site
$appIdentifier = $clientID + "@" + $realm
$appPrincipal = Get-SPAppPrincipal -NameIdentifier $appIdentifier -Site $site.RootWeb
Set-SPAppPrincipalPermission -EnableAppOnlyPolicy

I get the error:

Get-SPAppPrincipal : The app principal could not be found.

Workflow 2013 only writes to the workflow history list and then WF cancel: User's image

I don't have any applications available at the URL "https://www.domain.com/_layouts/15/appprincipals?Scope=Web".

When I go to "https://domain.com/_layouts/15/appinv.aspx" enter the application ID "PII Removed" in the input field, and then click "Search," nothing is returned.

User's image

It still doesn't work for me. Can you tell me where I might be going wrong?

Matthew-P 8,940 Reputation points Microsoft External Staff Moderator

2026-01-11T10:36:00.1933333+00:00
Hi durica,

Thanks again for sticking with this.

After seeing many SP2019 farms with the same behaviour (app principal appears briefly then vanishes, even with -Force), one approach that has helped quite a few people is to completely remove the Workflow Service Application Proxy and all its trust data, then re-pair from scratch. It basically gives the farm a clean slate for the trust relationship.

Step 1: Remove the old proxy and trust data Remove the Workflow Service Application Proxy (and related trust data):

In Central Administration > Manage Service Applications, delete the Workflow Service Application Proxy. When prompted, check “Delete data associated with the Service Application Connections” and confirm. This action removes the proxy itself and the associated Workflow token issuer and certificate trust entries on the SharePoint side.

Or with PowerShell

Get-SPServiceApplicationProxy | ? {$_.TypeName -match "Workflow"} and pipe to Remove-SPServiceApplicationProxy -RemoveData.)

Reference: joshroark.com

Note: Microsoft is providing this information as a convenience to you. These sites are not controlled by Microsoft, and Microsoft cannot make any representations regarding the quality, safety, or suitability of any software or information found there. Please ensure that you fully understand the risks before using any suggestions from the above link.

Step 2: Re-register (this time adding -ScopeName)

$siteURL = "https://<your site collection URL>" $wfHost = "https://<WorkflowServer>:12290" Register-SPWorkflowService -SPSite $siteURL -WorkflowHostUri $wfHost -ScopeName "SharePoint" -Force

Use the appropriate site URL (in the web app that needs workflows) and the correct Workflow Manager URI. Include -ScopeName "SharePoint" (or the scope name your farm uses) to ensure the principal is tied to the proper realm. The -Force flag is required to create a new trust scop

Step 3: After re-registration, verify that SharePoint now has the Workflow app principal

In the site, go to Site Settings > Site App Permissions and look for an entry for the Workflow app (a client ID with “@” followed by your farm realm). Its presence confirms the principal was created and given rights.

Run the “Refresh Trusted Security Token Service Metadata Feed” timer job to expedite SharePoint recognizing the new trust config (via Central Admin or PowerShell).

In Central Admin, check the Workflow Service Application Proxy (recreated automatically) and confirm its status shows “Workflow is Connected”. This indicates SharePoint trusts the Workflow service.

Then IISRestart on SharePoint servers and ensure the Workflow Manager services are running. Then run a 2013-style workflow. It should no longer immediately fail. Monitor ULS logs for any new errors.

Hope this helps. Thanks and looking forward to your update.
durica 0 Reputation points

2026-01-12T09:00:31.18+00:00

Hi,

I tried using the Get-SBNamespace command so that I could then use the correct ScopeName parameter in the Register-SPWorkflowService command, but I encountered something interesting:

I followed your instructions and used "WorkflowDefaultNamespace" in ScopeName. It was necessary to publish WF2013 additionally, because it would not start when launched. After publishing WF2013, it terminated correctly.

Thank you.
Matthew-P 8,940 Reputation points Microsoft External Staff Moderator

2026-01-12T11:10:10.26+00:00

Hi durica,

I’m pleased to hear that using the correct ScopeName from Get-SBNamespace resolved the issue and that your 2013 workflows are now completing successfully.

If my answer contributed to the resolution, please consider marking it as the "Accepted Answer" so others facing similar issues can find it more easily.

Thank you so much for your understanding and for helping the community!

Have a wonderful day!

Share via

SharePoint 2019 - SharePoint Workflow Manager - App principal does not exist

3 answers

Your answer