locked
CRM For Outlook Stopped Working After ADFS RRS feed

  • Question

  • Hey, I'm hoping there is a simple answer to this.

    About a month ago I finished setting up ADFS and IFD for our office deployment and ever since then our outlook clients have been breaking until there are none left.

    The outlook clients now just don't work, the setups wont connect to any internal or external URL's

    I'm completely stumped and I don't know how to diagnose this.

    Any help would be heavily appreciated.

    Thanks

    Ryan Bartlett

    Friday, November 9, 2012 12:42 PM

Answers

  • If you configure IFD correctly you would set up an internal relying party trust in ADFS and an external one.

    The internal one is used when users try to reach yourcrmserver.domain.co.uk; the external is used if they try to reach yourorgname.domain.co.uk (for any organisation name, or for some other end points such as the discovery service).

    When the user tries to browse to CRM it checks for a valid session token, If none is found it redirects their browser to talk to ADFS. ADFS checks which URL was used and matches it to a relying party trust identifier (ie a URL). If it is the internal one, it will ask the client for the current AD signin token, and when this is returned and validated will issue a token for the CRCM session and redirect the browser back to the CRM URL. This all happens transparently for the user without providing any credentials. (if they watch closely they will see this redirect to ADFS and back).

    If the URL used matches an external one, ADFS does not expect the user's current credentials to be useful (eg home computer, internet cafe) so it does not try to get these from the OS but simply prompts using the forms based authentication.

    None of these processes require port 80. Using only https on port 443 for CRM works just fine and is the least confusing for users.

    Don't forget you will need all the CRM endpoints and organisations to be valid names according to the certificate used for encryption, otherwise they won't work. A wildcard certificate is by far the easiest way to achieve this.


    Hope this helps. Adam Vero, Microsoft Certified Trainer | Microsoft Community Contributor 2011

    Saturday, November 10, 2012 11:24 PM

All replies

  • Hi,

    I would start by recofiguring an Outlook Client. I would first remove the CRM Organization from the Outlook client completely and then I would try to reconfigure.

    If any errors come up while trying to reconfigure, I would recommend using Fiddler to watch the traffic that is taking place and troubleshoot.

    Greetings,

    Pavlos


    Please mark this reply as an answer and vote it as helpful if it helps you find a resolution to your problem.
    View my latest gallery contribution here.
    Visit my blog here.

    Friday, November 9, 2012 12:53 PM
  • Reconfiguring is the problem, none of the url's work, the furthest I get is with the external CRM link, it says it cant find any organisations?

    Ryan Bartlett

    Friday, November 9, 2012 1:24 PM
  • Hi Ryan,

    did you first remove the organization from the client?

    In the configuration window try to enter the external URL of the organization ("https://myorg.domain.com"). Does the popup for the credentials show up? What happens after you enter the credentials?

    Can you access the web client on the same machine using the external URL?

    Greetings,

    Pavlos


    Please mark this reply as an answer and vote it as helpful if it helps you find a resolution to your problem.
    View my latest gallery contribution here.
    Visit my blog here.

    Friday, November 9, 2012 1:32 PM
  • Yes I removed it,

    I have and it pops up and credentials work but it errors on my external URL

    Yes I can

    Image for reference

    Thanks

    Ryan Bartlett

    Friday, November 9, 2012 1:53 PM
  • Hi,

    did you try entering the URL from the error ("https://..../OrganizationService.svc?wsdl") in a browser window? Does it get resolved correctly in the browser?

    Next step would be to try using Fiddler to capture the generated traffic after clicking the "OK" button in the configuration wizard.

    Greetings,

    Pavlos


    Please mark this reply as an answer and vote it as helpful if it helps you find a resolution to your problem.
    View my latest gallery contribution here.
    Visit my blog here.


    Friday, November 9, 2012 1:57 PM
  • yes I did

    I get this

    If I do it on the internal name like it was set up before I set up ADFS and IFD (http://svr-core-sql/XRMServices/2011/Discovery.svc?wsdl)


    Friday, November 9, 2012 2:14 PM
  • Hi,

    in the above screenshot I see the service contract for the Discovery Service and not the Organization Service. Did you also try it for the organization service using "https://myorg.domain.com/XRMServices/2011/Organization.svc" and "https://myorg.domain.com/XRMServices/2011/Organization.svc?wsdl" as provided in the error message?

    Greetings,

    Pavlos


    Please mark this reply as an answer and vote it as helpful if it helps you find a resolution to your problem.
    View my latest gallery contribution here.
    Visit my blog here.

    Friday, November 9, 2012 2:18 PM
  • Friday, November 9, 2012 2:26 PM
  • Hi,

    just for clarification: the host name in the URL in the error message is the same as in the URL you provided in the configuration wizard, right?

    Did you also check out this? Check for the 3 causes mentioned in this article.

    Greetings,

    Pavlos


    Please mark this reply as an answer and vote it as helpful if it helps you find a resolution to your problem.
    View my latest gallery contribution here.
    Visit my blog here.

    Friday, November 9, 2012 2:34 PM
  • Hey,

    Yes its the same URL on all of this.

    Thanks

    Ryan Bartlett

    Friday, November 9, 2012 2:37 PM
  • Ahah

    I think I am guilty of two of those causes

    2 and 3

    2: I have no URL listed in IIS and the URL in deployment manager is a fake one configured on hosts files

    3: It has two bindings 80 a 443 as we still wanted to use it internally and externally through IFD 

    Friday, November 9, 2012 3:00 PM
  • Ahah

    I think I am guilty of two of those causes

    2 and 3

    2: I have no URL listed in IIS and the URL in deployment manager is a fake one configured on hosts files

    3: It has two bindings 80 a 443 as we still wanted to use it internally and externally through IFD 

    Great! Hope that this will resolve your issue. Good luck!

    Please mark this reply as an answer and vote it as helpful if it helps you find a resolution to your problem.
    View my latest gallery contribution here.
    Visit my blog here.

    Friday, November 9, 2012 3:02 PM
  • Thanks for all your help,

    One thing quick, is there any way I can keep internal/external functionality? (The 443 and 80 binding)

    As I can picture some of my co-workers being annoyed at the extra hassle of signing in.

    Thanks

    Ryan Bartlett 

    Friday, November 9, 2012 3:08 PM
  • Hi,

    unfortunately I don't know the details for the internal configuration for IFD, but I think that you can accomplish this even when you only have the HTTPS binding. I'm sure you will be able to find some info on this by doing a little Google Research.

    Greetings,

    Pavlos


    Please mark this reply as an answer and vote it as helpful if it helps you find a resolution to your problem.
    View my latest gallery contribution here.
    Visit my blog here.

    Friday, November 9, 2012 3:29 PM
  • If you configure IFD correctly you would set up an internal relying party trust in ADFS and an external one.

    The internal one is used when users try to reach yourcrmserver.domain.co.uk; the external is used if they try to reach yourorgname.domain.co.uk (for any organisation name, or for some other end points such as the discovery service).

    When the user tries to browse to CRM it checks for a valid session token, If none is found it redirects their browser to talk to ADFS. ADFS checks which URL was used and matches it to a relying party trust identifier (ie a URL). If it is the internal one, it will ask the client for the current AD signin token, and when this is returned and validated will issue a token for the CRCM session and redirect the browser back to the CRM URL. This all happens transparently for the user without providing any credentials. (if they watch closely they will see this redirect to ADFS and back).

    If the URL used matches an external one, ADFS does not expect the user's current credentials to be useful (eg home computer, internet cafe) so it does not try to get these from the OS but simply prompts using the forms based authentication.

    None of these processes require port 80. Using only https on port 443 for CRM works just fine and is the least confusing for users.

    Don't forget you will need all the CRM endpoints and organisations to be valid names according to the certificate used for encryption, otherwise they won't work. A wildcard certificate is by far the easiest way to achieve this.


    Hope this helps. Adam Vero, Microsoft Certified Trainer | Microsoft Community Contributor 2011

    Saturday, November 10, 2012 11:24 PM
  • Thank you for replying.

    The only problem is when I configure an internal relying trust it throws out an error.

    Monday, November 12, 2012 9:32 AM
  • Its Ok it I have fixed it.

    Thank you guys this help really meant a lot

    Thanks Again

    Ryan. 

    Monday, November 12, 2012 9:58 AM
  • You're welcome! Glad you managed to get it sorted.

    Hope this helps. Adam Vero, Microsoft Certified Trainer | Microsoft Community Contributor 2011

    Monday, November 12, 2012 10:00 AM