SP2019 + Workflow Manager (HTTP Unauthorized)

Question

SP2019 + Workflow Manager (HTTP Unauthorized)

Radim Trncak 0

We are running SharePoint Server 2019 with Workflow Manager 1.0 (CU4). Recently, all SharePoint 2013-style workflows stopped working.

The error we are getting is: "Activity in progress Retrying last request. Next attempt scheduled after 20/10/2025 12:44. Details of last request: HTTP Unauthorized to https://intranet.xxxxx.xx/_api/web/lists(guid'26f3c2f1-541c-4f99-ae36-a28795c4a068') Correlation Id: 9fba991d-6850-f265-beb5-0039bbd07407 Instance Id: 0d6ced29-bc94-4d46-91d0-4fae6d763156 "

· Register-SPWorkflowService runs successfully, and the Workflow Manager farm appears healthy.

· The Workflow Manager metadata endpoint (https://server:12290/metadata/json/1) returns 404 or ScopeNotFoundError.

· SharePoint now points instead to its internal endpoint (https://intranet.../_layouts/15/metadata/json/1) which responds, but workflows still fail to start.

· ULS logs show repeated 401 UNAUTHORIZED and Non-OAuth request. IsAuthenticated=False entries, sometimes also “Context has no SMTP/UPN claims”.

· Claims providers are enabled (AD, User Profile, etc.), but UPN/SMTP claims are not being passed through, even for accounts created with the proper suffix.

So far, we’ve:

· Verified Workflow Manager certificates, farm health, and IIS modules.

· Re-registered the Workflow Service multiple times with -Force.

· Checked claims providers and tried to ensure UPN claims are available.

· Installed missing IIS features (WebSockets, WCF activation).

Despite all of this, workflows do not start, and the environment looks connected but not functional.

3 answers

Your answer

Answer 1

VPHAN 10,565 Independent Advisor

Hi Radim Trncak,

Even if Register-SPWorkflowService runs successfully, the OAuth trust or certificate connection mayavexpired or become invaliry the following steps:

Open SharePoint Management Shell and run:
```
   Get-SPTrustedSecurityTokenIssuer
```

=> “Workflow” appears in the list and that it’s not expired.

If it looks missing or old, re-register it with this command:


   Register-SPWorkflowService -SPSite https://intranet.xxxxx.xx -WorkflowHostUri https://workflowserver:12290 -Force

you restart these services on the Workflow Manager server:
- Workflow Backend
- Service Bus Gateway

And check the certificate used for Workflow communication is still valid in both IIS and Local Machine Certificates. If it’s expired, renew and rebind it.

Finally, Claims to Windows Token Service (C2WTS) is running, as missing claims can also cause “Unauthorized” errors.

If this helps solve your issue, click “Accept Answer” so others can find it easily too 😊

Best regards,

VP

Radim Trncak 0 Reputation points

2025-10-20T13:31:37.2833333+00:00

Hi VP,

thank you for your detailed steps. I went through them, and everything checks out:

·         Register-SPWorkflowService was re-run with -Force and completed without error.

·         Workflow certificates are valid and correctly bound in IIS and the local machine store.

·         Workflow Manager and Service Bus services were restarted successfully.

·         Get-SPTrustedSecurityTokenIssuer shows Workflow is present and Online.

The only problem I hit is: Claims to Windows Token Service (C2WTS).

·         The service is currently Disabled, and when I try to enable/start it, I get: Error 2: The system cannot find the file specified.

So it looks like the service is either corrupted or not properly installed.

Could you please advise:

1.      How to reinstall or repair C2WTS on a SharePoint 2019 server?

2.      Is C2WTS mandatory for SharePoint 2013 workflows (OAuth) to function, or can workflows run without it?

Thanks a lot for your help!

Radim

Answer 2

Hi Radim Trncak,

C2WTS (Claims to Windows Token Service) is required in typical SharePoint 2013-style workflow deployments that use Workflow Manager and OAuth because it translates SharePoint claims into Windows tokens that the Workflow Manager and downstream services expect, so workflows commonly fail with 401/Non-OAuth errors when C2WTS is missing or broken.

Start by checking the service registration: open RegEdit and verify HKLM\SYSTEM\CurrentControlSet\Services\C2WTS exists and note the ImagePath value to confirm the executable location. If the ImagePath points to a missing file, copy the service executable and dependent DLLs from a healthy SharePoint 2019 application server, or preferably repair the SharePoint installation to restore missing binaries.

To repair: run the SharePoint setup from the installation media on the affected server and choose Repair, then run the SharePoint Products Configuration Wizard (psconfig) to re-register services. After the binaries are present, ensure the dedicated C2WTS service account has the required rights: Act as part of the operating system, Impersonate a client after authentication, and Trusted for delegation as needed, and make the account a member of the local Administrators group only for the repair/installation phase if recommended by your security team. If the service entry was removed, recreate it using the ImagePath discovered earlier and set the service StartType to Automatic or Manual as appropriate, then attempt to start the service and confirm no “Error 2” appears.

If the service still fails to start, capture the System and Application event logs around the start attempt for the specific error text and confirm required runtime components (.NET, VC++ redistributables) are present. Once C2WTS runs and your OAuth trust is intact, re-test a workflow start; you should see the Non-OAuth/IsAuthenticated=False messages disappear.

If this resolves your issue, please click Accept Answer so others with the same problem can find this solution easily 🙂.

VP

Radim Trncak 0 Reputation points

2025-10-20T14:34:49.1666667+00:00

Hi VP,

thank you for guidance.

I now have the C2WTS (Claims to Windows Token Service) up and running – I reinstalled it, set the correct user account, it is visible in registry and restarted the server, but unfortunately workflows are still not functioning.

I checked the Workflow Manager certificates and they are all valid to 01/2026:

· Workflow Manager Front-End Certificate

· Service Bus Gateway Certificate

· Workflow Manager Backend Certificate

Would it be helpful if I provided screenshots of the certificate bindings and service configuration for further troubleshooting?

Radim
Radim Trncak 0 Reputation points

2025-10-20T14:49:13.09+00:00

I recently also adjusted the user logon name suffix (changed it from one UPN suffix to another) about a week ago. However, the issue persists even when reverting back to the original settings.

From the ULS logs, I’m consistently seeing the following message:

Context has no SMTP/UPN claims. IdentityContext: '{"upn":"******@XXXXXXX.org","userId":"0#.w|XXXXXXX\XXXXXX"}'

It looks like SharePoint is not issuing the SMTP/UPN claims for this account, which might be causing the workflows to fail.

Answer 3

Solution: Before installing the latest SharePoint cumulative update, the workflows were working perfectly fine with only the HTTPS binding configured in IIS for Workflow Manager.

After the CU installation, the workflows stopped functioning. The issue turned out to be that Workflow Manager was missing an HTTP binding (port 12291) on the Workflow Management Site in IIS.

To fix it, I opened IIS Manager on the Workflow Manager server, selected the site, and added an HTTP binding alongside the existing HTTPS (port 12290) one.

Share via

SP2019 + Workflow Manager (HTTP Unauthorized)

3 answers

Your answer