MS Dynamics CRM 2013/15 Plug-in Regsitration Tool Fails to create a connection to an IFD – Error “404”
Recently I came up against an issue where the CRM 2013/2015 Plug-in registration tool from the CRM SDK couldn’t connect to an IFD CRM instance – throwing a “404” exception even though I knew I was using the correct connection details and credentials. I need to turn off some plug-in steps whilst data was updated.
Previously I had been able to connect to the test instance which was also internet facing and the application was available both internally and externally.
Well, one thing you can check (which thankfully worked for me) was to check the “ActiveMexEndpoint’ for the Federation Provider in the MSCRM_Config database.
STEP 1 – Log into SQL Server Management studio on the SQL server used by the CRM instance in question.
STEP 2 – Navigate to the MSCRM_CONFIG database and then “dbo.FederationProvider”
STEP 3 – Run one of the stored jobs to “Select Top 1000” records, the script executed should read;
/****** Script for SelectTopNRows command from SSMS ******/
SELECT TOP 1000 [ActiveEndpoint]
STEP 4 – Check the value stored for ActiveMexEndpoint, there should be more than one line returned, the value should look like this – https://sts.<yourdomain>/adfs/services/trust/mex if it doesn’t, then that’s your problem. You can execute a script like the following to update them;
UPDATE [MSCRM_CONFIG].[dbo].[FederationProvider] SET ActiveMexEndpoint = ‘https://sts.<yourdomain>/adfs/services/trust/mex’
WHERE ActiveMexEndpoint = ‘https://sts.<yourdomain>://adfs/ls/mex’
STEP 5 – Once the update has run perform an IIS Reset (cmd > iisreset) on the CRM Server and the ADFS Server and try to reconnect. It is also worth checking that access to the CRM instance externally is functioning as expected.
You should now be able to establish a connection from the CRM Plug-in Registration Tool and register/deactivate your plug-in steps.
NOTE: The production instance had been created from a database backup of test initially as the data was imported from external sources and cleansed – therefore the plug-ins hadn’t been manually registered in the past. Otherwise this issue would have been encountered earlier in the deployment.