CRM 2011 Configure Internet-Facing Deployment wizard error RRS feed

  • Question

  • I'm running into an issue when running the Internet-Facing Deployment Configuration Wizard, specifically, when it runs its checks, the Root Domains part returns the following warning "The Discovery Web Service could not be accessed.  The domain is unavailable or does not exist".

    My environments looks like this:

    • CRM and ADFS installed on seperate servers, both are running Windows 2008 R2 SP1
    • I have a wildcard SSL that is bound on both servers
    • both servers have a NAT translated external IP with TCPIP port 443 open inbound on them
    • DNS for the wildcard SSL domain have been updated with dev.domain.com, crm.domain.com, & auth.domain.com pointing to the NAT IP for the CRM Server, and sts1.domain.com pointing to the NAT IP for the ADFS server.

    Since the above was just a warning, I continued with the deployment.  From a desktop computer, I was able to access the external site for logging in (https://crm.domain.com), was redirected to the ADFS login page, logged in, but then continue to get re-pompted for my credentials in a pop-up window.  I can either try to log in mulptiple time until it fails or just click on cancel - both result in bringing me to the https://auth.domain.com page with "HTTP Error 401 - Unauthorized: Access is denied".

    One thing I did notice earlier in the deployment was that from the adfs server I am unable to get to https://sts1.domain.com/FederationMetadata/2007-06/federationmetadata.xml (it returns "Internet Explorer cannot display the webpage").  However, from any other server in the domain, I can successfully get to that XML dump.  I tried this fix (Access CNAME url from same server), but that did not resolve the issue.

    I'm wondering if the above issue on the ADFS server is what is causing my over all issue since the dev and auth sites are on the CRM Server, and the Configruation wizard is running on the CRM Server, thus causing the waring in the configuration wizard.  Perhaps this is all what is causing the external access of CRM to fail.

    Anyhow, any thoughts or ideas?  I've been scrubbing through the web for the last couple of days, and have gone over every step of the IFD configuration process several times now, all with no resolution.



    Friday, September 7, 2012 2:42 PM

All replies

  • Hi,

    Did you find a solution to this, my setup is identical to yours and I am experiencing the same problem.


    Tuesday, September 11, 2012 11:24 PM
  • Yep, I did get this working.  I opened a case with Microsoft and found that the primary issue was around DNS (mixing internal and external).  We fixed the following issues:

    I had to create a DNS forward zone inside the domain the servers are in, with the same A records that you published with your internet hosting DNS provider except you use the internal IP addresses of the servers (so a forward zone of domain.com).  I added auth.domain.com, dev.domain.com, sts1.domain.com, <org>.domain.com (crm.domain.com for me), and now internalcrm.domain.com all with their internal IPs.  Anything within the domain (workstations, servers, etc) would use the internal IP to get access to the needed resource, while anyone from outside the domain (i.e. the internet) would use the public IPs published with your internet hosting DNS.  Previously I never was able to get the internal url setup properly (page 29 of the Microsoft Dynamics CRM 2011 and Claims-based Authentication document) as I had no way to create the DNS entry using an internal IP address.  This allowed me to also create the internalcrm.domain.com A record finally so the system could properly deal with the internal access of CRM via a url.  Initially, one of my problems was that I had the internal URL set to the same as the Organization name which was also the public access url to CRM (crm.domain.com).  That URL cannot be the same as any Organization (just as your dev, auth, and sts1 cannot be the same as any Organization).

    Next we added an SPN onto the CRMAppPool service account that was the internal url (http/internalcrm.domain.com).

    Finally, we used Fiddler and found that IIS authentication was just looking for host SPN instead of SPN on the AppPool account.  So we went into IIS and changed “UseAppPoolCredentials” from False to True.  Ran an IISRESET on both CRM and ADFS servers, and everything was working as it should.

    Hope that helps you with your deployment.

    Wednesday, September 12, 2012 12:42 PM
  • Another interested reader!

    My own environment looks like this:

    • CRM and ADFS installed on the same server, running Windows 2008 R2 SP1
    • I have a wildcard SSL: Default site --> port 443 and MSCRM site --> port 444.
    • Open inbound on them
    • DNS for the wildcard SSL domain have been updated with dev.domain.com, crm.domain.com, auth.domain.com, and sts1.domain.com

    This is a test server that we have been trying to"test" for months...reinstalled ADFS 2.0 so many times; could do it sleeping.

    From the outside I hit https://auth.domain.com and get redirected to https://sts1.domain.com/adfs/ls/?wa=wsignin...with a blank screen (with CRM identifier favicon)

    Is DNS an issue here or not so much? From the inside, I hit https://sts1.domain.com:444, get the Sign In page. Looks nice and clean, but upon entering a u/p, I get prompted again and again to re-enter the u/p or "There was a problem accessing the site. Try to browse to the site again."

    Event logs cite: Microsoft.IdentityServer.Web.InvalidScopeException: MSIS7007: The requested relying party trust 'https://sts1.domain.com:444/' is unspecified or unsupported.

    Is a Microsoft ticket needed or is there a simple setting I am overlooking?

    Thank you!

    Friday, September 14, 2012 1:59 AM
  • Well, I see a few things...

    1) from the outside, you have to specify the :444 in any url hitting CRM.  The ADFS site is running on 443, so you can't use plain https://... to get to CRM.

    2) form the outside, you need to hit https://crm.domain.com:444, not https://auth.domain.com.  From the CRM site, the system will take care of re-directing you to the appropriate sites and processes.

    3) when you set the Binding type in Deployment Manager (select Actions > Properties, and click on the Web Address tab) do you specify the urls as internalcrm.domain.com:444?

    4) when you run all of the different wizards, are you remembering to specify all urls on the CRM site (crm, auth, and dev) with :444?  Remember, the only site running on 443 is sts1.

    5) also, you need to setup an internal DNS entry for your domain that mimics the one you set in your public DNS records, but specify crm, auth, dev, sts1, and internalcrm all with the internal IP of the CRM/ADFS server.

    If those don't help, then yeah, I would open a ticket with Microsoft.  They will setup a shadow session with you to walk through your deployment and help you fix anything they find that isn't working as it should.

    Friday, September 14, 2012 12:08 PM
  • jbuxton - yes, all of those areas are addressed.

    Today... I can hit https://internalcrm.domain.com:444 and it redirects to https://sts1.domain.com/adfs/ls?.................

    And just hangs forever. Thoughts?

    Thank you so kindly for your response.

    Thursday, October 18, 2012 11:07 PM
  • Hi,

    a couple of things you can do:

    -Make sure that "sts1.domain.com" is resolvable from your client machine by pinging it or by using nslookup

    -Use Fiddler in order to see the requests that are sent during the whole process. Check to see if the responses contain errors

    -Go to your ADFS Server, open up the Event Viewer and take a look at the events under "Application and Services\ADFS 2.0\Admin". Check for any errors and post them here if you find any.

    -Another common source for errors is the security configuration for the certificate. You need to make sure that the "Network Service" Account has enough privileges to be able to read your certificate.



    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, October 19, 2012 6:35 AM
  • I also had this problem, and found one more configuration that was getting in the way.  Whenever I ran the Deployment Manager wizard to enable IFD, it would always give me "Warning: The external domain 'https://auth.litware.com' could not be accessed. The domain is unavailable or does not exist."

    PARTIAL SOLUTION: I had "auth" and "dev" HOST (A) records in my DNS forward zone pointing to the internal address of the CRM server.  However, I also had a "*" HOST (A) record pointing to a different (SharePoint) server in this domain.  When I removed that DNS record, the Deployment Manager wizard FINALLY completed with no errors!

    However, the address https://auth.litware.com/FederationMetadata/2007-06/FederationMetadata.xml still just gives me a 404.  I did disableloopbackcheck, ipconfig/flushdns, klist purge and iisreset, but still just 404.  I can get to the federation metadata using https://crm.litware.com/FederationMetadata/2007-06/FederationMetadata.xml, but I really want to follow the instructions and use "auth" because if that's not working, then it's a symptom that something else is wrong somewhere that's going to show up in other subtle problems.

    Hope the first answer helps.  Anyone have advice on the second?

    Mark Arend

    MCS Sr Consultant

    Thursday, January 10, 2013 10:08 PM
  • Mark, you may be better off starting your own thread and referring back to this one - lots of forum regulars may filter for new threads or ones with no replies so yours may get buried.

    Can you clarify your environment:

    are ADFS and CRM on different servers? Have you installed ADFS on the CRM server at any time, even if you later un-installed?

    What ports are they running on? Is the windows firewall on each open for this port?

    Are you using any host headers on CRM at all?

    Are all three DNS entries for crm (your orgname), auth and dev all pointing to the same IP?

    On what machine does a browser give you a 404 when pointing to the auth. URL? But not the crm. one? (I have seen oddities when accessing this from the local host versus from any other machine)

    Have you tried reinstalling the URL rewrite module? (as per http://blogs.msdn.com/b/emeadcrmsupport/archive/2011/05/13/we-receive-http-errors-while-accessing-the-crm-federationmetadata-url.aspx )

    Hope this helps.
    Adam Vero, Microsoft Certified Trainer | Microsoft Community Contributor 2011
    Blog: Getting IT Right

    Friday, January 11, 2013 2:32 PM