All Collections
Integrations
Microsoft Dynamics
Support and maintenance
Technical installation details for Microsoft Dynamics
Technical installation details for Microsoft Dynamics

Learn what installation configurations are supported for the Dotdigital for Microsoft Dynamics connector.

Gareth Burroughes avatar
Written by Gareth Burroughes
Updated over a week ago

There are a number of options presented by the installation process for the Dotdigital for Microsoft Dynamics connector. In this article we outline those options and give guidance on recommended practice to help the installation run smoothly.


Use Microsoft Dynamics CRM Online

Microsoft CRM Online is fully supported. The Dotdigital for Dynamics connector is provided as a managed solution, which gives you full control of the connector.


Use a partner-hosted Dynamics CRM

Partner-hosted Dynamics CRM solutions can be accessed from the internet and only standard customisation changes are required. The connector requires a new user account that has access to the Dynamics CRM Web Services (CRM Service and Metadata Service).

On each server that is installed with the partner-hosted Dynamics CRM Server 2011/2013, you must enable anonymous authentication for the 2007 SPLA CrmDiscoveryService.

For other requirements, read the Microsoft Dynamics CRM Planning Guide.


Use an on-premise version of Dynamics CRM

If you host your own Dynamics CRM, you can use one of the following three methods to connect it to the Dotdigital for Dynamics connector:

Internet-facing deployment (best practice)

The main difference between internet-facing deployment (IFD) and a non-IFD-enabled on-premise deployment is the way in which users are authenticated. In a non-IFD-enabled on-premise deployment, Internet Information Services (IIS) handle most of the authentication through integrated Windows authentication.

In IFD-enabled deployment, the Dynamics CRM is open for anonymous access outside of your local network because authentication is claims-based, using the Active Directory Federation Services (ADFS) component from Microsoft. IFD is the recommended method from Microsoft for configuring secure external access to your Dynamics CRM.

To make your Dynamics CRM IFD-enabled:

  1. Download ADFS and install it on a separate web server from your Dynamics CRM.

  2. Configure IFD in the CRM Deployment Manager

If you block or filter inbound traffic based on IP address, then please add the following IP addresses to your firewall rules:

For Europe (region 1)

For North America (region 2)

  • 23.101.50.109

  • 23.102.11.18

  • 23.102.18.218

  • 40.85.101.127

  • 40.127.207.8

  • 13.68.20.229

  • 13.68.22.210

  • 13.68.30.243

  • 40.79.40.67

  • 40.84.63.147

Important

In CRM the address of the Organization Service web service must be updated in the Deployment Manager’s web address properties so that it uses an address that is reachable from the internet – not an internal server name.

This means that for non-IFD systems the exact URL used by both internal users and external users such as Dotdigital must be identical, including the port and protocol used, unless you have an appliance or reverse proxy that can conduct a complete content rewrite, replacing all references to your internal URL with that of the external URL.

If the full URL being used to access the CRM instance externally is not an exact match to the URL that is used internally by users this approach will fail.

We are unable to provide any advice about setting up a reverse proxy configuration within your environment.

Use a reverse proxy

Your organisation may not have a public-facing IFD environment and may already use a reverse proxy solution to publish internal web sites to the Internet. Using a reverse proxy implementation instead of port forwarding is generally more secure, as the reverse proxy sends requests on behalf of Dotdigital for Dynamics and processes responses on behalf of your CRM server – the two solutions have no direct communication but the reverse proxy must be able to pass on the NTLM credentials to the CRM servers. All communication should be undertaken over HTTPS.

In this approach all communication is undertaken with an internet-exposed static IP address and accompanying Fully Qualified Domain Name (FQDN) which can be resolved using public DNS systems. In this scenario, it is strongly recommended that all network traffic is encrypted and that HTTPS is used, which requires a valid SSL certification to be installed on your environment.

Direct web service connection via an internet connection to a public IP address (port forwarding)

This approach involves your Dynamics CRM Server being directly accessible from the Internet and will use standard Windows authentication to access the CRM system. This option is not usually recommended without secure firewalls being in place and SSL connectivity.

In this approach, all communication is undertaken with an internet-exposed static IP address and accompanying Fully Qualified Domain Name (FQDN) which can be resolved using public DNS systems. In this scenario, it is strongly recommended that all network traffic is encrypted and that HTTPS is used, which requires a valid SSL certification to be installed on your environment.

If you block or filter inbound traffic based on IP address, add the following IP addresses to your firewall rules:

For Europe (region 1)

For North America (region 2)

  • 23.101.50.109

  • 23.102.11.18

  • 23.102.18.218

  • 40.85.101.127

  • 40.127.207.8

  • 13.68.20.229

  • 13.68.22.210

  • 13.68.30.243

  • 40.79.40.67

  • 40.84.63.147

To use the connector, the internal CRM website must be internet accessible through standard web publishing techniques, including opening the firewall to a public IP for the CRM server and permitting direct Windows authentication.

This approach is less complex to configure than IFD and both users and our service would be able to access CRM externally through standard Windows authentication. As stated above, you should configure your firewall to restrict access to only our IP addresses for better security, but traffic will not be encrypted if you don't use SSL, which is against best practice and would be at your own risk.

Did this answer your question?