Question: Connection Problem / On Premises IFD Setup

May 15, 2013 at 11:25 AM
Hi,
I've been using your tool for a while now. It's made managing option sets much simpler. We recently change our CRM 2011 On Premises to use IFD with claim-based authentication and now when I try and use your tool I get the following message:

"Can not discover CRM services on https://crm2011.negroup.co.uk:5556
ID3242: The security token could not be authenticated or authorized."

The URL is the URL I use to login to CRM and the same URL that has been used for the CRM Router, so I presume its what should work for your tool too.

Any ideas what I’m doing wrong? I’m very new to IFD and claim-based authentication so I apologise if it’s a noddy mistake on my part.

Thanks in advance,

Phil
Coordinator
May 15, 2013 at 12:26 PM
Hi Phil,

Greetings from CrmXpress. Good to hear from you.

Can you tell me if "crm2011" in your url is an organization name? If yes, remove that and try connecting CRM again.

Let me know if that works or not. I will look into this and get back to you very soon.

Thanks and regards,
Rikin
May 16, 2013 at 8:32 PM
Hi Rikin,

Thanks for your quick reply. "crm2011" is not organisation name it's the URL used for the Internal IFD and the URL used in the deployment manager. If I use the Internal server name as before I get the following message "The provided uri did not return any Service Endpoints!".

Internally to access the web interface of our CRM deployment we use the URL: https://crm2011.negroup.co.uk:5556/<OrganisationName> externally it's https://<OrganisationName>.negroup.co.uk:5556 where <OrganisationName> is the CRM Organisation name, for example our test organisation "JoeBloggsInc".

Hope this helps? I've got to say I find the claim-based authentication and IFD setup very disjointed, hopefully I've set everything up correctly.

I used this article as a guide for setting up IFD - http://www.interactivewebs.com/blog/index.php/server-tips/microsoft-crm-2011-how-to-configure-ifd-hosted-setup/

Thanks in advance,

Phil
Oct 27, 2015 at 9:50 PM
Did this ever get a resolution? It seems the non-standard SSL port that causes the problem.