From the Learn Something New Department

Dynamics CRM 4, IFD, and Mobile Express - For Dummies

{NOTE: A LOT of the below content is a rehashing of already available documents, guides, and kb articles. I'm re-writing it, in an informal style, because various bits and pieces weren't perfectly clear to me in the proper documentation, or weren't emphasized enough for me to 'get it', etc... }

In the course of my job I am sometimes called upon to install, fix, and otherwise manage Microsoft Dynamics CRM. At least in part due to the business climate over the last several months (presumably), I have had very little to do concerning CRM since last Fall.

So, my CRM knowledge has grown a bit rusty, and when I was tasked with some CRM work late last week things were challenging. I decided to document here tidbits from my recent work both to aid my own recollection, and provide the info for anybody else that may encounter similar troubles. Hopefully this may help.

The task was to implement Mobile Express on an existing Dynamics CRM v4 server, so that remote users could view CRM data on BlackBerry mobile devices.

* CRM 4 Mobile Express DOWNLOAD

* CRM 4 Update Rollup 5 DOWNLOAD

Installing Mobile Express is a pretty easy process, but things may not go smoothly, so I'm here with some tips.

IMPORTANT: The Mobile Express installation includes CRM Update Rollup 5. On two different servers this caused problems for me, and the problems were avoided easily by simply installing Update Rollup 5 separately, first, and then installing Mobile Express afterward.

* The installation of Update Rollup 5 required a reboot on my two servers.
* The installation of Mobile Express also required a reboot on my two servers.

On one of my servers, after installing Update Rollup 5 the CRM site no longer worked, only displaying an error that the GUID {servername}$ could not be found in the Global Catalog. Any error involving AD and the Global Catalog is very, very frightening to me. To remedy this problem I simply uninstalled UR5. Later I reinstalled UR5, and all was fine.

Somehow I overlooked an important requirement while reviewing the documentation for Mobile Express. Mobile Express REQUIRES your CRM server to be configured for Internet Facing Deployment (IFD). Without IFD, some devices may work, but others won't. In my experiences, my T-Mobile Dash, running Windows Mobile 6, worked. An iPhone worked (something I can't explain at all!). A pair of AT&T PocketPC phones, running Windows Mobile 6.1 Pro did not work, and most importantly, a BlackBerry Storm and a BlackBerry Pearl did not work.

Mobile Express requires IFD in order to work properly.

IFD is a system designed to let users view a CRM system that exists behind a firewall from outside of the firewall, without the use of a VPN. You should use SSL security with this arrangement, but that is not required.

DIGRESSION: It IS strongly encouraged, though, and I personally consider it unwise to ignore this advice. If you implement an IFD system for you CRM server, and you don't put SSL into the mix, than all of the traffic going back and forth between you server and your remote users will be transmitted across the public internet in clear text. Anybody can point a network sniffer at your IP address, collect all of the data going back and forth, and view the entire session. If usernames and passwords are transmitted in clear text, you've just given away the store. If, on the other hand, you use SSL, the entire session is encrypted, and it becomes impractical and unlikely that anybody will decrypt the transmission. Every bit of documentation you find will recommend you use SSL, and I agree as strongly as I can. As for how to implement SSL on your server, you'll need to find that information elsewhere, sorry.


Now, back to IFD...

IFD works its magic by identifying where a user is located when that user attempts to log in to the CRM website. If the user is on the same local network as the CRM webserver, the CRM server prompts the user to authenticate (to login) using NTLM Authentication (Windows Authentication). NTLM Authentication will display a login dialog box on your screen, with OK and Cancel buttons:

ASIDE: NTLM is a Microsoft protocol, and it's very unlikely that non-Microsoft clients (Linux, Mac, Opera, Safari, Mozilla, BlackBerry, etc...) will work with NTLM. NTLM does not work across the internet.

If the user is on a different network, as a remote user will be if coming in from the internet, than IFD will prompt the user to login using Forms-Based Authentication (FBA). You'll know you are encountering FBA because the login is NOT a dialog box, but instead looks like a webpage with username and password fields, and a SIGN IN button:


Without IFD, a CRM system would need a user to login using NTLM, and as NTLM won't work across the internet, the authentication would fail and remote users would be shut out. With IFD, the remote user is able to login via FBA.

So, how does IFD work, and how does the unfortunate administrator set it up?

If you haven't yet installed your CRM server, you can configure your IFD in an .xml file, and have the CRM installation process refer to the .xml file during the installation. Most likely, though, is the scenario where the CRM system is already in use, and you want to add IFD functionality. For this, Microsoft has made the IFD Configuration Tool.

Get the IFD Config Tool here: DOWNLOAD

[MS KB explaining how to use the tool: http://support.microsoft.com/kb/948779]

The tool, CRM4IFDTool.exe, must be run from the Tools folder, within the CRM Program Files directory. (On my server, the path was C:\Program Files\Microsoft Dynamics CRM\Tools.) The tool is fairly minimal. The interface is one dialog box, that's it:



There is a drop-down box that lets you select whether the server is running On-Premise, or IFD & On-Premise. This effectively turns IFD on or off.
There is an area for you to enter IP addresses and subnet masks. THIS IS IMPORTANT. IFD needs to know whether or not a user is local, and it does this by looking at the IP address of the incoming user request. You must enter a local IP address and subnet mask here. The specific address isn't important. It only matters that you enter an IP address and subnet that is on the local network. If your environment has multiple subnets, you should add an IP Address/Subnet Mask for each of your subnets.

Below the list of IP addresses are a few textboxes describing the AD and IFD domains. You need to specify whether your remote users will be using HTTP:// or HTTPS://, and in the IfdAppRootDomain box, you should enter the public domain of your site. Notice the large box at the bottom-left of the CRM4IFDTool. It lists the Organization Name for your CRM system. (You may have multiple Organizations.) IFD will add either HTTP:// or HTTPS://, and the Organization name to whatever you enter in the IfdAppRootDomain box, and redirect remote users to that URL.

So in the example screenshot of the tool above, as configured a remote user would be sent to https://AdventureWorksCycle.yourdomain.com. THIS IS WHERE DNS COMES IN. The URL that IFD redirects remote users to must be resolvable from outside. You need to make sure the URL is publically resolvable, and publically accessible. In other words, public DNS servers need to know about the URL and know what public IP address it should map to, and you need to make sure that URL will get through your firewall and get to your CRM webserver, whether via HTTP or HTTPS, depending on whether or not you've implemented SSL. You ALSO need to make sure your networks internal DNS is configured to resolve the address, and get the users to the CRM server. The right-most Ifd textbox, Ifd SDK Root Domain, will most likely be identical to the IfdAppRootDomain value. It is only different if you've got your CRM server's Operations split among different servers.

Below the Ifd textboxes are the AD textboxes. The values entered here correspond to how the users on the internal network will get to the server. You'll probably just enter HTTP://, and the CRM-servername and port # here.

Next, you can use the 'Check DNS' command in the Tools menu to verify the values you've entered resolve before you save your changes. To effect the changes, click on the File menu, and choose 'Apply changes'.

When you apply changes, the following occurs:
* A value is changed in the CRM website web.config file.
* Anonymous Access is enabled for the CRM website
* A registry key is added to the registry of the CRM server, containing the internal network IP Address/subnet mask, for use by IFD
* The Ifd values in the CRM4IFDTool textboxes are added to the MSCRM_CONFIG database

When I used the tool this morning, NONE OF THE ABOVE OCCURRED. I applied my changes repeatedly, and the tool consistently did NOT make the necessary changes. If that happens to you, you can manually make the changes:
1) First, the easiest: Edit the web.config file, found on the CRM webserver, probably at C:\Program Files\Microsoft Dynamics CRM\CRMWeb. Within the file, find the line "authentication strategy=..." and change it to "authentication strategy="ServiceProviderLicenseAgreement".
2) On the CRM webserver, use the IIS Manager and open up the properties of the CRM website. Enable Anonymous Access to the website. Leave Integrated Authentication enabled as well.
3) Within the registry of the CRM server, run regedit and navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSCRM. Add a new string value, named IfdInternalNetworkAddress. The value of this key should be a local IP address, then a dash, then the subnet mask. Make sure there are NO SPACES before, after, or in the middle of the value. Example: 192.168.1.200-255.255.255.0 .
4) To add the necessary values to the SQL database, start up SQL Management Studio and connect to the SQL Server running your CRM databases.
a) In SQL Mgmt Studio, expand 'Databases'.
b) Find the MSCRM_CONFIG database and expand it.
c) Expand 'Tables'.
d) Find the table called 'dbo.DeploymentProperties'.
e) Right-click the DeploymentProperties table and select 'Open Table'. (NOTE: Changes made in the table are immediate. BE CAREFUL.)
f) Look in this table for three records with a ColumnName beginning with 'Ifd'. IF THEY ARE MISSING, you need to add them, using the SQL Query Editor:
g) Click on the 'New Query' button. When the query editor opens, verify the tab at the top-left of the editor is labelled with the name of the DeploymentProperties table.
h) In the query editor, enter

INSERT INTO DeploymentProperties (Id,ColumnName,NVarCharColumn) VALUES ('whatever value is in your other records','IfdRootDomainScheme','HTTPS')

INSERT INTO DeploymentProperties (Id,ColumnName,NVarCharColumn) VALUES ('whatever value is in your other records','IfdSdkRootDomain','your Ifd Root domain')

INSERT INTO DeploymentProperties (Id,ColumnName,NVarCharColumn) VALUES ('whatever value is in your other records','IfdWebApplicationRootDomain','your Ifd Web App Root Domain')



Press the 'Execute Query' button, and the three records should be added to the DeploymentProperties table.

Once all of the above is accomplished, your CRM system should be accessible from outside of your firewall. When a remote user wants to view CRM, he/she should go to https://{organizationname}.yourdomain.com. Your CRM server will receive the request, and send them a Forms-based Authentication page to prompt for login credentials. The user enters the creds and signs in, and is then able to work with the CRM system.

Assuming the above is all installed/configured and working, Mobile Express is a piece of cake. The install is pretty much nothing but clicking Next, and then Finish. After Mobile Express is installed, it can be configured by going into CRM, then Settings, then Customization. You'll find a link for Mobile Express Customization, and clicking that will take you to a page that allows you to configure Mobile Express. Mobile Express can be accessed by going to whatever your CRM URL is, with a "/m" added to the end. Using the URL in our previous example, you'd go to https://{organizationname}.yourdomain.com/m.

If Mobile Express doesn't seem to work, pay attention to the login prompt, and verify you are getting a Forms-based authentication page when logging in from a remote network. If you are seeing an NTLM login prompt, than IFD isn't working properly, and Mobile Express won't work right either.