I cannot get the Outlook app for Dynamics 365 on Prem to connect

(2) Share

Report

Posted on by SteveHFX

Hello

I have been trying to get the Outlook App for 365 working with our on prem deployment without much success.

I believe that I have everything setup correctly as per all the other posts and troubleshooting steps I have found.

We are running Dynamics 365 9.2 On Prem. It is configured for IFD and logging on successfully through ADFS from various web browsers.

ADFS is Server 2019

All users, regardless of security roles or Windows OS versions (10 and 11) are suffering the same problem.

Exchange is Online 365, Office is Office 365. The Outlook app is the new version Dynamics pushes out, there is no manual installer or settings like in the previous versions of the App.

Now, this is an on prem deployment only, there is no physical access to the Dynamics or the ADFS servers from the outside, but I am only trying to get this to work internally anyway. I thought I should mention it incase there is some requirement where it needs to talk to something on the internet. As mentioned though, it is successfully configured as IFD with proper SSL certs and works fine logging in from browsers internally.

I have tried this many times and each time I make a change to ADFS or the CRM server to attempt to fix this, I get a different error from Outlook, so I know my changes are taking effect. The current error I am getting is continual forms based login prompts with never successfully authenticating. If I cancel the login prompts (there are often a number of prompts on top of each other) the error page in Outlook shows the standard:

We're sorry

Something went wrong during sign-in. Please try again. If the problem persists, contact your system administrator.

with:

Error: Failed to authenticate user

Trace: Error: Failed to authenticate user at new t (IFD_URL/.../shim.js at[....]

I can see an error in the event logs on the CRM server that comes from my workstation's IP at the time I attempt to log in. It is an ASP.NET warning message Event Code 3005:

Event message: An unhandled exception has occurred.

Application information:
Application domain: /LM/W3SVC/1/ROOT-1-133009045811111073
Trust level: Full
Application Virtual Path: /
Application Path: C:\Program Files\Dynamics 365\CRMWeb\

Exception information:
Exception type: XmlException
Exception message: The empty namespace requires a null or empty prefix. Line 3, position 28.

Request information:
Request URL: IFD-URL:443/default.aspx
Request path: /default.aspx
User host address: 10.0.0.214
User: [This is a blank line, there is no user info contained in it]
Is authenticated: False
Authentication Type: [This too is blank]
Thread account name: domain\service account

The same issue occurs if I use the Outlook webmail client.

If I had to guess, I would say the ADFS server is not passing the proper credentials (or any) to the CRM server from Outlook, but I can't figure out what setting I missed. Any guidance would be appreciated.

I tried the Grant-AdfsApplicationPermission command

I set Set-ADFSProperties–ExtendedProtectionTokenCheck "None" to allow Windows 11 Edge browsers to connect (there is no "Enable Protected Mode" option in W11 IE settings, so this gets around that)

I have set the properties on the webserver folders and files: XRMServices->2011, Nga, AppWebServices

OAuth claims settings is enabled

The SPNs are correct

I have tried several iterations of the redirect URL as detailed in other posts, but none seem to make a difference. It is currently set to IFD-URL/.../code_auth.aspx. And I can verify this page exists, I can view it in a browser when I add additional parameters that Outlook adds.

Thanks in advance for any help.

I have the same question (0)

All responses (6)

Answers (1)

SteveHFX 4 on at

Like (0)

Report

RE: I cannot get the Outlook app for Dynamics 365 on Prem to connect

Hello again.

Thank you so much Alan. That was the piece I was missing. I didn't understand how the internal vs IFD URLs were working. After re-working the URLs and setting up a wildcard cert, I was able to successfully connect the Outlook app to Dynamics.

Thank you again for all your help.

Steve.

Was this reply helpful? Yes No
Verified answer

Alan Ericson on at

Like (0)

Report

RE: I cannot get the Outlook app for Dynamics 365 on Prem to connect

Hi Steve,

Yes, you'll need to differentiate those addresses. A single subject certificate doesn't work well with the IFD setup for Dynamics as you do need separate identifiers in the relying party trusts on the AD FS side. But, you could change internal to something else and use the IFD URL with a new relying party trust in AD FS with the UPN claim rule. Only caveat there is that the deployment web service address needs to match the subject on the certificate for PowerShell to connect to Dynamics. You'd need to update the deployment web service address temporarily whenever you need to run PowerShell against CRM. That address is the one in the properties of the deployment on the web addresses tab.

Here is the feedback site for Dynamics: experience.dynamics.com/.../

Would be good to vote up any existing ideas on a configuration to be able to set the Dynamics 365 App for Outlook to the internal claims URL or create a new one.

Thanks

Alan

Was this reply helpful? Yes No
SteveHFX 4 on at

Like (0)

Report

RE: I cannot get the Outlook app for Dynamics 365 on Prem to connect

Hello again.

My deployment is a simple single server deployment for testing. How I have the IFD setup is simply myorg.mydomain.com. My CRM org name is myorg. So in the Web Application Server field in the Dynamics Settings, it is listed as myorg.mydomain.com. In the IFD deployment wizard, the base IFD address is mydomain.com, which generates a full url of myorg.mydomain.com. This makes it the same as the internal one. So, could this be confusing the system? Would the solution be as simple as just renaming the internal web application domain to something else (even though I won't have an SSL cert available for it)?

Thanks

Steve.

Was this reply helpful? Yes No
Alan Ericson on at

Like (0)

Report

RE: I cannot get the Outlook app for Dynamics 365 on Prem to connect

Hi Steve,

That would be the issue -- IFD versus Internal URL.

The app deploys to the IFD URL for Dynamics. So, the command that has the following redirect URI format is incorrect https://[myorg.mydomain.com]/[myorg]crmmailapp/code_auth.aspx

Needs to be the IFD URL where the Org is not appended after the slash -- 'https://[myorg.mydomain.com]/crmmailapp/code_auth.aspx'.

You'll need to remove the AD FS client for Dynamics 365 app for Outlook and add using the external address.

In the deployment manager, select Dynamics 365 in the upper left hand corner > select properties in the actions > select web address tab.

- The web application domain address is the one used for internal

- This is not the redirect URI the app will use

In the Deployment manager, select to run the IFD wizard > select next to get to the domains screen. The entry for Web Application Server Domain is the base for your IFD address -- for example... mydomain.com. The IFD format will be uniqueorgname.mydomain.com.

This is the address the app will be deployed to. Make sure you have the correct entries in the IFD wizard, there is a related relying party trust in AD FS for the external addresses, and the correct DNS entries are in place to browse Dynamics through the IFD URL.

Once the IFD is setup and working -- re-deploy the app and check the results.

Was this reply helpful? Yes No
SteveHFX 4 on at

Like (0)

Report

RE: I cannot get the Outlook app for Dynamics 365 on Prem to connect

Hello Alan Ericson

Thank you for the detailed response. You have helped me move forward with this a bit... I saw errors in the ADFS Admin event viewer that looked like what you were mentioning, so I ran the grant-adfsapplicationpermission command. I wasn't 100% positive on the serverroleidentifier option, but it looked like it was looking for the CRM webserver URL, so I put that in. The error in ADFS went away after that.

I also removed the authentication providers from the root CRM site, and that did seem to clear up the constant login windows.

However, it looks like I am stuck back at the redirect URI issue. It doesn't seem to make any difference what value I set this to in ADFS, Outlook always comes back with the same error saying it received the wrong redirect. my IFD address is https://[myorg.mydomain.com]/myorg/. So in the Outlook App settings, my redirect command looks like this: https://[myorg.mydomain.com]/[myorg]crmmailapp/code_auth.aspx.

I have seen other users report that there is a bug in the MS code and that there should actually be an extra / in that to look like: https://[myorg.mydomain.com]/[myorg]/crmmailapp/code_auth.aspx

Either way, it doesn't matter what I register in ADFS, the Outlook App always responds with the same error:

The received 'redirect_uri' parameter is not a valid registered redirect URI for the client identifier: '###'. Received redirect_uri: 'https://[myorg.mydomain.com]/crmmailapp/code_auth.aspx'.

Its always missing the CRM org part of the URI. I have re-pushed out the app several times to my Outlook with no change. So I have no idea where the Outlook app is getting this URI from.

I can see the same error message that Outlook gives me on the ADFS server: MSIS9224: Received invalid OAuth authorization request. The received 'redirect_uri' parameter is not a valid registered redirect URI for the client identifier: '###'. Received redirect_uri: 'https://[myorg.mydomain.com]/crmmailapp/code_auth.aspx'.

Thanks

Steve.

Was this reply helpful? Yes No
Alan Ericson on at

Like (0)

Report

RE: I cannot get the Outlook app for Dynamics 365 on Prem to connect

Make sure that the settings in the section "Configure Windows Server for Dynamics 365 Customer Engagement (on-premises) applications that use OAuth" are applied

Post-installation and configuration guidelines for Dynamics 365 Customer Engagement (on-premises) | Microsoft Docs

Need to remove the Windows Authentication providers of NTLM and Negotiate in IIS at the CRM site level.

One thing to keep in mind is that the OAuthClaimsSettings will revert to false if you re-run the claims wizard in the deployment manager. Even if you set it to true once -- good idea to confirm the settings using PowerShell on the deployment web server for Dynamics CRM:

add-pssnapin microsoft.crm.powershell

get-crmsetting -SettingType OAuthClaimsSettings

Make sure that is set to true.

Also, the app for Outlook is hard-coded to the IFD URL -- you don't have to open Dynamics to the internet, but the IFD setup needs to be completed and working with the IFD relying party trust on the AD FS side and the separate DNS records for the IFD format of OrgName.WebApplicationDomainName. The internal URL for Dynamics will have the orgname appended after -- internalwebaddress/orgname. So, the add-adfsclient command you retrieve from the settings menu in Dynamics 365 on premises will vary according to the URL you are logged in with. Make sure to log into Dynamics using the IFD url, and then copy the add-adfsclient command from the setup section of the Dynamics 365 app for Outlook settings menu. You can tell if it is the correct AD FS client by checking if the orgname is appended after the redirect uri or with the DNS address in the beginning.

get-adfsclient | select name, redirecturi

With AD FS 2019 -- You'll need to also run the grant-adfsapplicationpermission command. In order to find the correct serverroleidentifier and clientroleidentifier for the command -- you could try the login, let it fail, and then check the event viewer on the AD FS server -- application and services logs > AD FS > Admin. There will be a correlating error for the missing application permission, and it will have the parameters in the text of the error for the client and the server role identifiers.

If you are seeing Windows type of prompts and not the AD FS login page -- note the address they are coming from. If the Windows prompts is from AD FS, then add the AD FS URL in the local intranet zone on the client (even if you are using Edge browser). Start > type inetcpl.cpl > enter > select security > zones > local intranet > sites > advanced > enter in the STS URL > OK

If the Windows prompt is coming from Dynamics -- double check the authentication providers have been removed from the site level and from the xrmservices/2011/organization.svc file.

With what you are describing, it sounds like AD FS is providing a token, you go to CRM with the token, and then CRM just sends the client back to AD FS to get a token. In that case, there should be additional information by enabling tracing on the CRM server and checking the w3wp trace log when the issue is reproduced.

Monitor and troubleshoot Dynamics 365 Customer Engagement (on-premises) | Microsoft Docs

How to enable tracing in Dynamics CRM - Dynamics CRM | Microsoft Docs

Was this reply helpful? Yes No