Hi, I recently started owning the Internet Facing Deployment (IFD) feature set within the CRM team and so in this blog I would share some of my thoughts and insights. I have also noted that there are no IFD related blogs on CRM so far, so this should be a good start. J
IFD allows the customers to configure their CRM system to be reachable from outside the intranet (i.e. internet or outside of the firewall). The main difference when using IFD vs. typical on-premise deployment is how users are authenticated. When using the on-premise version, IIS handles most of the authentication via integrated windows authentication. There are however custom CRM authentication handler modules registered during setup to assist in the process. In IFD, the web site is opened for anonymous access and the authentication relies on the presence of the CRM ticket cookie. This cookie is obtained by starting off from a sign-in page.
Any page request that does not contain the CRM ticket cookie also gets redirected to it. This page deletes any expired CRM ticket cookies and if the user has provided correct credentials at the sign-in page, a new CRM ticket cookie would be written and used in later requests.
To install an IFD enabled CRM system, the install xml needs to have the following node in the crminstall.xml, under the path <CRMSetup><Server>. You will see that there isn’t too much information listed below, so the difference between an on-premise deployment with or without IFD should not be much. I will explain the difference later.
- The <ifdsettings> node is the root node containing all the details that the CRM server needs to enable IFD.
- The “enabled” attribute indicates if the IFD is to be enabled or not.
- The <internalnetworkaddress> is used to separate out internal vs. external request IP address. The internal requests will continue to go though the usual on-premise authentication, whereas external requests will go though the IFD. This is also known as SPLA authentication. SPLA stands for Service Provider Licensing Agreement. The value is specified in the IPAddress-IPAddressMask format and multiple values can be specified by separating them with a semicolon.
- The <sdkrootdomain> and the <webapplicationrootdomain> nodes are used to define the sdk and web application root domains. These should ideally be fully qualified domain names and can be same if sdk and application servers are located on the same box.
The installation of an IFD enabled CRM server is pretty simple but CRM setup does not provide any UI support for it so the IFD needs to be enabled via an xml install. Also once CRM is installed there is no easy out of box way (tools) to enable it. There is however a support tool that customers can download and use.
Ok. Now lets talk about difference between an on-premise and IFD enabled on-premise deployment. On the IFD enabled deployment you would see the following.
1) A new regkey ‘IfdInternalNetworkAddress’ with string value in format IPAddress-IPAddressMask. This contains the value of the node <internalnetworkaddress>
2) Three new DeploymentProperties in the config database (MSCRM_CONFIG).
select * from DeploymentProperties where ColumnName like ‘Ifd%’
Each entry has the string (NVarCharColumn) value set to the values from the config xml. The Id field in the deployment property is the deployment id.
select id from Deployment
3) Updated <crm.authentication> node in the web.config file
<authentication strategy=”OnPremise ” />
<authentication strategy=”ServiceProviderLicenseAgreement” />
4) Anonymous access being enabled on the CRM website and all web pages under it.
5) The url used to access IFD is different from on-premise. It is in the form https://myOrganizaitonName.myDomain.
You should also checkout the latest version of SDK (version 4.0.6). It has some great examples of adding web pages in an IFD enabled CRM server and more.