Dynamics PTS Team Blog

A blog managed by Dynamics Partner Technical Services team for Global English

Using Web Application Proxy to Publish Dynamics CRM 2013 to the internet

Using Web Application Proxy to Publish Dynamics CRM 2013 to the internet

  • Comments 7
  • Likes

Sivakumar Venkataraman - Click for blog homepageWith the release of Windows Server 2012 R2 there is a new server role called Web Application Proxy (WAP).  The WAP server role functions as the ADFS Proxy as well.  In customer scenarios where a DMZ/perimeter network is used the common issue is how to get Dynamics CRM published to the internet.

One option you have is to put the CRM Front End server in the DMZ, but the main problem with this is the CRM server is required to be domain joined, which is usually a no-no for a DMZ.  So in the past some options included ISA or UAG but those products are being phased out.  So now we have the WAP server role.  This can be used to publish the CRM URLs needed for internet facing access. 

The rest of this post will walk through the WAP configuration and publishing the CRM URLs. This post assumes you have already setup ADFS internally and you already have Dynamics CRM installed and configured for IFD and now you just need to publish your CRM URLs to the internet.

Import ADFS Certificate

On the WAP server we need to import the certificate you are using on the ADFS server into the Personal Certificate store of the WAP server.  We will need this certificate later during the configuration and publishing the CRM URLs. Export the certificate from the ADFS server and import it into the WAP server.  Your certificate should be listed in the Personal store.

image 

Add the WAP role to the non domain joined server in the DMZ/perimeter network

In Server Manager - Click Manage and Choose Add Roles and Features.

image

Except the defaults and when you get to the Server Roles section select Remote Access.

image

Then select Web Application Proxy and finish the wizard.

image

Configure WAP role

Once the WAP role is installed you will have a Remote Access Management program on your start screen.  Launch it to start the configuration.

image

For the Federation service name enter in the URL you setup when configuring your ADFS server. (For example sts.domain.com or adfs.domain.com).  Then enter in a local admin account that you have on the ADFS server.

image

Select the certificate that you installed on the WAP server.  This will be the certificate you used on the ADFS server as well.  Then finish the wizard to complete the configuration.

image

Errors

If you have issues with the WAP configuration not connecting or finding the ADFS server.  Make sure your hosts file on the WAP server is updated to include the IP address of the ADFS server to resolve the ADFS URL.  Also verify you are using the correct ADFS URL that you created during the ADFS configuration.

image

Publish CRM URLs

Now we will publish the CRM URLs in the Remote Access Management Console.  Select the Web Application Proxy under configuration and then click Publish.

image

Select Pass-through.  We do not want the WAP to do any pre-authentication.  We just need the URL to pass through to CRM and then CRM will redirect to ADFS to get the claims needed to successfully login.

image

Enter in a friendly name for the URL.  Then Enter in the external org URL.  Select the certificate which will be the same certificate you uploaded earlier.  Enter in the same org  URL for the Backend server URL.  Then confirm the settings and click Publish.

image

Do the same for the Auth URL.

image

Do the same for the DEV/Discovery URL.

image

Do the same for the ADFS URL.

image

Once the three CRM URLs and one ADFS URL are published your Published Web Applications should look like this:

image

Disable URL Translation

Now there is one additional step we need to do to make this work.  We need to Disable URL translation.  The reason we have to do this is the WAP will re-scope the cookies as part of the URL translation and CRM leverages a domain cookie that can be shared across sub-domains.  If URL translation is not disabled access to CRM will be prevented.  Disabling URL translation will allow the WAP role to pass the cookie along that CRM is expecting.

The first thing we need to do is get the ID of each of the CRM published URLs we added above.  We do not need to disable URL translation on the adfs url. 

To do this launch PowerShell in Administrator mode and run

Get-WebApplicationProxyApplication Name* | Format-List

Replace Name* with the name or part of the name of one of your URL’s.  Like Dynamics* would find all URL’s that have Dynamics at the beginning.  Using Format-List will list out the results much nicer and make it easier to copy the ID out.

image

Command to Disable URL Translation

Once you have the ID for each of the URLs run this command replacing GUID with the ID you copied from above.

Set-WebApplicationProxyApplication –ID GUID –DisableTranslateUrlInResponseHeaders

image

External DNS

Final step is to make sure your external DNS records for each of these URLs points to the WAP server now.

  • External Org URL
  • Auth URL
  • Dev URL
  • ADFS URL

THANKS:  I also want to give credit to Jason on his post here that initially help me out:

http://blogs.msdn.com/b/javaller/archive/2014/01/13/publishing-crm-internet-facing-deployment-using-web-application-proxy-and.aspx

Comments
  • Hi Corey, excelent blog! I have a question: In final step, when you mention external DNS records... What URLs do you refer?

  • Thanks Richard. I was referring to the 4 urls that you created in the Remote Access Management Console on the WAP server. They would be the External Org URL, Auth URL, Dev URL and ADFS URL. I update the article as well to add them.

  • Corey - Awesome Blog! Thanks for sharing with folks in the Field.

  • Hi Corey. Does this work with CRM 2011?
    Many thanks,
    James.

  • James CRM 2011 isn't supported with Windows Server 2012 R2 or the ADFS version that comes with R2. The compatibility KB here http://support.microsoft.com/kb/3005163 mentions the supportability. So publishing CRM 2011 through WAP wouldn't be supported either. There may be no technical issues doing this but it wouldn't be supported if you need break/fix support. I personally haven't tried this with CRM 2011.

  • Hi Corey, Any plans to update CRM 2013 / Apps / Clients to handle the 307 redirect from the WAP server that currently breaks the Pre-Auth option? I know I and others would be more comfortable with this option over setting WAP to Pass Through

  • Hi, Corey. Is it possible to use different External and Backend URL addresses?

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment