Beringer Associates Technology Blog
I have been working on a client’s development system for a few months. This was an MSCRM 2011 instance which we upgraded to MSCRM 2016 on new servers. We’ve been updating our code, workflows, and plugins, as well as enabled Claims-Based Authentication and IFD. IFD will be used in the end for all users connecting to CRM. All went swimmingly on the development system. We then installed the MSCRM Production servers and setup Claims-Based Authentication and IFD on those as well. Again, all went well.
After we confirmed we could connect externally using a test MSCRM organization, we brought over a backup of our development instance of MSCRM and deployed it in the Production environment for testing. This is where things went wrong. For some reason when accessing this instance, I would get to the ADFS login screen, supply credentials and then receive the dreaded “404 – File or directory not found. The resource you are looking for might have been removed, had its name changed, or is temporarily unavailable.” Another non-descriptive error message to deal with. This was happening after ADFS redirected us to the MSCRM URL.
So, we did a little troubleshooting. I personally tried logging into MSCRM from various PCs, Laptops, Servers, etc. All with the same results. I reset Claims-Based authentication and IFD and double checked my ADFS Relying Party Trusts. Nothing appeared out of the ordinary. I then asked a few other co-workers to try as well. Some received the error, but to my amazement, some were able to login.
With this knowledge in hand, we were able to find a resolution.
It came down to the user accounts being used to log into MSCRM. For this client, we were given a couple different AD accounts which we used when mapping users during the upgrade process. I was using one account when testing (Error message) but the users which were able to login were using another user account (success).
I proceeded to look at the failed user record in MSCRM (after logging in with the successful user account), and nothing seemed out of place.
I reset the user record in MSCRM. I did this by opening the user record and changing the domain\username to another AD user. I saved the record and then changed it back to the original domain\username. I then logged out and logged back in with the failed users credentials and was able to log in. Simple fix not but sure why this error was thrown.
Hope this helps someone else. Happy trouble shooting.
Beringer Technology Group, a Microsoft Gold Certified Partner, is always here to provide expert knowledge in topics like these. Please contact us with any questions you may have.