Work IQ Tenant Enablement Issues

[peyton-smith-kh]

Our team is having issues granting WorkIQ consent to our tenant. The quick start approach ends in an access denied error. We are also unable to view WorkIQ as an Enterprise Application in the catalog, and it has not been automatically added to our tenant even after we attempt to use WorkIQ through the CLI. Additionally for reference we have CoPilot licenses rolled out across the org. Any guidance would be appreciated. I am not a global admin but I have the other Entra roles listed in the requirements.

[juhisaha-p1]

I think this is tied to Issue #64 cc @darrelmiller

[peyton-smith-kh]

@juhisaha-p1 hitting the same error as described by you in issue #64.

[darrelmiller]

Thank you for reporting this. This is happening because we have updated the WorkIQ CLI client app registration to include some more permissions by default that will allow you to call the Work IQ Tools MCP Servers for doing additional capabilities. However, we missed the fact that the service principal for the resource AppId for the remote WorkIQ MCP Servers needs to be provision.

It is possible to work around this problem by using a modified consent URL that does not include the permissions for the Work IQ Tools MCP Servers. The URL would look like this:

https://login.microsoftonline.com/{your-tenant-id}/adminconsent?client_id=ba081686-5d24-4bc6-a0d6-d034ecffed87&scope=Sites.Read.All%20Mail.Read%20People.Read.All%20OnlineMeetingTranscript.Read.All%20Chat.Read%20ChannelMessage.Read.All%20ExternalItem.Read.All

That consent URL should limit the requested permissions to just the ones that are against the Microsoft Graph resource AppId which always has a service principal in every tenant.

As a short term fix we will create a PowerShell script that provisions the service principal to enable consenting to all the permissions.

[peyton-smith-kh]

@darrelmiller thank you for your response on this issue. Once the script is ready I will attempt to run that and confirm we were able to grant access in our tenant.

[darrelmiller]

@peyton-smith-kh Can you try the consent url and see if that unblocks you for using the CLI and local WorkIQ MCP Server?

[peyton-smith-kh]

@darrelmiller Unfortunately I am still seeing a localhost error at the moment with the new URL provided. I am prompted to login but then met with the local host error and the below message in the URL.

I'm happy to jump on a teams call as well if needed.

http://localhost:8080/callback?error=access_denied&error_description=AADSTS650052%3a+The+app+is+trying+to+access+a+service+%27ea9ffc3e-8a23-4a7d-836d-234d7c7565c1%27(Work+IQ+Tools)+that+your+organization+%277e220d30-0b59-47e5-8a81-a4a9d9afbdc4%27+lacks+a+service+principal+for.+Contact+your+IT+Admin+to+review+the+configuration+of+your+service+subscriptions+or+consent+to+the+application+in+order+to+create+the+required+service+principal.+Trace+ID%3a+7183a773-3878-4f1b-8289-051286fa4f00+Correlation+ID%3a+38db272a-f1f2-4b6e-8e34-61aa80ee2467+Timestamp%3a+2026-03-19+12%3a58%3a10Z&error_uri=https%3a%2f%2flogin.microsoftonline.com%2ferror%3fcode%3d650052&admin_consent=True

[juhisaha-p1]

@darrelmiller echoing @peyton-smith-kh - I am seeing the same issue when using this new URL.

[juhisaha-p1]

Tagging @sebastienlevert as well as this is impacting several folks and there are multiple issues filed around the same problem. Thank you and @darrelmiller !

[abrinkman]

Getting same error as reported here too. Seems like somehow WorkIQ is not automatically added to the tenant. Other methods for providing consent also fail because of - probably - the same reason.

[darrelmiller]

Sorry for the delay on this. I did prepare a PowerShell script to provision the service principals but that just brought more questions. I am working with the WorkIQ MCP Tools Server folks to get this sorted out.

[darrelmiller]

@peyton-smith-kh Yes, you will get a redirect to nothing at the end of the consent dialog. That is expected with this consent "hack". But the client service principal should be consented with the permissions to run the CLI. We are still working to resolve the issue with the remote MCP Servers.