Topic: ‘IFD’

We have a client that uses the On Premise Microsoft CRM 4.0 in both internal and IFD mode.  The client also used SQL Reporting Services (SRS) to display a dashboard and the link to it is contained in the Site Map.  The SRS was also exposed through the IFD.  The issue was the Site Map link would either provide a link to internal or external URL, and since the authentication is different between internal and IFD mode, if a user wasn’t already using that mode they would be prompted to login or not have access at all.  While a real easy fix could have been providing two different links, try explaining to the average user which link they should for which mode they are using.

The solution we came up with was to have the site map pointing to a custom .NET web page that would do the appropriate redirecting.  The web page gets the Request.Url.Host and compares it against the IFD host string.  If it is a match you redirect to the IFD URL and if not you redirect to the internal URL.  This way we only had one Site Map entry and the solution is seamless to the end user.

An Internet-Facing Deployment allows users that are not on the internal network of your organization to access Microsoft Dynamics CRM through the web.  This functionality is great for those that are in and out of the office or on and off the local network.  Like most of us, having CRM accessible through the web is great, but what about the Outlook Client?  We all live in Outlook, so below is a scenario and a few helpful hints about configuring users’ Outlook Clients for an Internet-Facing Deployment.

Scenario

• The customer has an IFD set up for its CRM 4.0 users.
• Users outside the domain have configured their outlook client using “Service Provider.”
• Currently, when these users are outside of the local network, they do not have an issue accessing CRM. (They can get to CRM through both the Web and Outlook)
• When users are in the office and connected to the local network, they CANNOT connect to CRM through OUTLOOK. 
• When users are in the office and connected to the local network, they CAN access CRM through the web successfully.

Process

It is important to have the users configure their Outlook clients while at the office on the local network.  The only time that we can configure the Client for both internal and external URLs is while the client workstation is in the office on the local network.

•  When the users are on the local network, have them configure the Outlook Client using “My Company.”
• During the configuration, users will come to the option to enter an internal and external URL.
  • There will be a check mark between the text boxes.  Remove the check mark and enter the internal URL used to access CRM.  For example:  http://crm
  • Then enter the URL that they are using to access CRM through IFD while outside the office in the external URL text box at the bottom.  For example: http://crm.infinity.com

  Â
  

• Continue to step through the configuration until it completes.
• Restart Outlook.
• Disconnect from the local network, and confirm that the outlook client can still be accessed with full functionality.

Assessment

What we have successfully accomplished is the ability for users to work in the Outlook Client, both on and off the local network.  When the users are connected internally, the Outlook Client will connect to CRM using the internal URL by default. Once they leave the internal network, the Outlook Client will attempt to connect using the internal URL, but when it sees that it cannot, it will then use the URL used to connect through IFD.

If we were to configure the Outlook client as ‘Service Provider,’ we do not give users the ability to use the Outlook Client on the local network.  This occurs because they have not defined an internal URL for CRM.

As always, if information such as this does not resolve your issue, documentation from Microsoft should be referenced.  This post should not replace documentation from Microsoft; however it can serve as a guide to solving your problems and as a helpful reminder.

A SQL guru in our office put together this document on how to setup an IFD with Exchange Server installed:

1. Install the IIS resource kit.

2. Navigate to the CRM4IFDtool.exe

3. Set the tool to these settings.

4. Set Authentication to IFD+OnPremise

5. Add the local subnets that will not be using external addressing.

6. Set the external to https and app root to external name:plus crm port

7. Set the internal app root name: plus port. Find the site ID that you want to add the certificate to. IISweb.vbs /query “name of site using http name.” Look at the first column (“default web site <w3svc/1>. The 1 tells you the ID number for this site. Enter it in the command below “/S:#”

8. Then create a self-signed certificate.

9. Open All Programs, IIS resources, self-signed. Type selfssl.exe /N:CN=”certname” /K:1024 /S:1 /P:443

10. This will add the certificate to the server’s web site.

11. This does not put the certificate in the trusted store for the machine.

12. Open cmd line and type mmc.

13. Select File, then select Add/Remove Snap-in.

14. Select ADD and Certificates.

15. Then select ADD, Computer Acct, Next, Finish, Close, and OK.

16. Expand certificates to trusted store, certificates.

17. Now open IIS Manager.

18. Right click on the CRM site and select Properties. Select Directory Security, Server Certificate. You will go into a wizard mode (you are going to export the certificate to add to trusted certificates).

Select Export the current certificate and NEXT. You can select any path as long as you can get to it from the machine. Set a short password and mark key as exportable. Next, click Finish.

19. Import the certificate to the trusted store. Right-click the certificate folder. Select All Tasks, and then select Import.

Select Next and Browse. Change file type to .pfx. Select File and OPEN.

Click on NEXT and type in short password created from export, NEXT. Mark key as exportable. The Trusted Root Certificate store s/b selected, NEXT and Finish.

21. Close MMC you do not have to save the console, and close IIS.

22. If the above example is exact and you are using port:555 for application then you will need to have network admin allow the port through the firewall to this server

23. Add a public dns name to their external zone (ex: crm.XXXXX.com)

24. Test the application. Have a user open https://crm.XXXXX.com:5555