views:

306

answers:

1

I'm working for the first time on a MS Dyanmics CRM 4.0 project. Our company has a high number of remote employees and even more remote consultants. As such it will be necessary to make the CRM solution available over the internet. As near as I can tell, I have three options:

  • Have everyone use a VPN to access an intranet site (typical onsite deployment). However, we have found that VPNs are far from trouble free and cause many support issues. We avoid them like the plague.
  • Use IFD to expose the CRM on the internet. I don't know much about this except that the URL will be different than the onsite URL, which could cause some headaches (see below).
  • Expose the CRM site by opening the site to the internet, using SSL to encrypt traffic. We currently do this with our MS sharepoint sites. I'm not sure how secure this would be (one of the reasons for this question).

I'd like to avoid using both the onsite intranet deployment and the IFD together for a couple of reasons. One of the requests for the solution is use email to notify users that they've been assigned a task, and include the URL to the task within the email. For this reason. If both deployments are used, then I'll need to include two URLs and the user would need to know which to use. Which leads to the second reason, the main users of the solution split time between being in the office and being remote. Thus they would need to access the solution two different ways, and know when to use which. Bad.

So, what are the advantages/disadvantages of any of these methods? Any other options? Is there any issue using IFD from within the intranet? Security issues?

Thanks!

UPDATE: Be sure to read the comments of the accepted answer, as they further explore the ramifications of the various options.

+1  A: 

Hi Greg,

  1. That is the best, you have all the security, and a low maintenance deployment. Also if you are developing custom code (ASPx pages) you will have only one deployment type to support. If your users are already using a VPN Client, this should be the best solution.

  2. This is the Microsoft way to do it. Except for the URL duplication. This solution is used in companies where clients do not want to have a VPN client, or where VPN clients can't pass thru firewalls. Also this solution is almost required if your outlook clients are using "Connect to exchange thru the web". Because in this case all the clients can open Outlook without VPN, CRM should be exposed without VPN, and the IFD deployment is handled natively by the Outlook client. Note that this is SSL enabled (required). EDIT : It's not required, but a best practice, even if the implementation guide says "You must define a URL for the Microsoft Dynamics CRM IFD by using the following format: https://".

  3. This this the worst of all the worlds, you have to maintain the deployment manually, and you will have all the headache of using a deployment as we were using it in CRM 3.0 (NTLM, Kerberos etc). I do not recommend this.

You can use an IFD deployment thru the intranet, but there is some buggy behavior. The external DSN should be configured on the internal DNS server, so that internal client can access the internal server. And because IFD is SSL enabled, you are encrypting internal traffic...

Hope this help!

Mercure Integration
IFD does NOT require SSL
Focus
#1 is definitely not best in our case. When we've used VPN in other situations, we ended up using 3 different VPNs and even then there was a high failure rate due to firewalls mostly. The external environments are out of our control (client sites mostly).
Greg McGuffey
On #3, I don't understand what you mean by "you have to maintain the deployment manually". Could you say more about this? Also what sort of buggy behavior is there when using IFD thru intranet. Thanks!
Greg McGuffey
Related to Focus' comment, is SSL required if using outlook to access CRM, but not if only web access?
Greg McGuffey
No. SSL is not a requirement at all, although it is a best practice. We have clients that use IFD and outlook integration without SSL. Also, I'm not sure what kind of buggy behavior he's referring to. Usually issues that we run into regarding DNS are network issues and not IFD issues.
Focus
That's it, the buggy behavior that I'm talking about is mainly make an Internet Facing Deployment working in an intranet. Modifying the DNS entries is one of the thing that should be considered, re-entering credentials each time a user want to log in could be another.
Mercure Integration
Any further comments related to option #3? This is the most appealing solution, as we are doing it already with Sharepoint, so I'd like to better understand why Mercure Integeration indicates this is the worst option. Thanks!
Greg McGuffey
The problem with option 3 is that it's using directly windows credentials. The Outlook client is not working with Windows Authentication when used from the internet. The automatic fall back mechanism is using IFD when the client can't authenticate himself against a domain controller. Also, back in CRM 3.0 all reports could not be executed when the report server was an another server (the authentication mechanism must be Kerberos which is not working for out-of-domain computers). But I think that was solved in 4.0.
Mercure Integration
Thanks! At this point we aren't using the Outlook client at all, but it's nice to know that option #3 could provide problems down the road.
Greg McGuffey