The Zen of Hosting: Part 6 - Microsoft Dynamics CRM
So in the first five parts we have looked at the standard stuff, now let’s dive into a real product and we’ll tackle the one I am most familiar with: Microsoft Dynamics CRM 4.0. Thankfully, MSCRM 4.0 is the first version of the product to really support a hosted model. Somehow, MSCRM 3.0 could do hosted, but based on the architecture, you would have ended up hacking a lot to get it to work. I never did hosted MSCRM myself in version 3.0, so that thinking is just based on my understanding of the architecture of MSCRM 3.0.
So how is MSCRM 4.0 different from 3.0—and how does that allow it to be easily hosted? Well, firstly, you can now have a single deployment with multiple databases, one for each organization. This means that each organization’s data, settings, and customizations are completely separate! This is great if every machine is on the domain, but in hosting, you need a way to provide a login over the web or via a special client. This is because, in a hosted model, despite the fact that you have a domain, your end users may be on a separate domain. Thankfully, MSCRM 4.0 provides both!
This is configured using the IFD tool, which actually enables MSCRM to look at the source IP address. If it’s a local network IP, it uses standard NTLM authentication. However, if it sees an external IP address, it presents form-based authentication, which the user can use to log in. This means that not only does the web interface work over the Internet, but the Outlook client works too.
If you’re a regular MSCRM user, you likely love the dynamic export to Excel—and for those who don’t know what it is, let me explain briefly. In MSCRM, you can export almost any data to Excel, and it can be updated dynamically live from within MSCRM. This works by creating a dataset in the Excel spreadsheet and putting the SQL for your query in the dataset. The problem with this scenario is that Excel uses direct connections to SQL to do this, so does this mean you need to expose your SQL server? Not at all—if you’re running the Outlook client, a button is added to Excel that actually reverses the SQL and uses the normal MSCRM web services to get the data! So you can still just expose MSCRM to the net, keeping security high and lowering administrative overhead. Note: This is only available if you’re using IFD deployments.
If you’re planning to do hosted MSCRM, you may find the hosted deployment guide interesting, as it explains how to set up MSCRM 4.0—however, it’s not the most logical guide, as it’s broken into three sections. The first section explains how to configure your environment for hosted MSCRM, but this is exactly the same information as included in the HMC guide for configuration of the environment, which brings us to the second section: how to use HMC with MSCRM. So not only do they repeat what’s in the HMC guide, but they then tell you to go through that guide. It’s pointless—and a massive waste of space. The only advantage is that if you’d never heard of HMC, this might point you in the right direction. The last section, in contrast, has some interesting and useful information on the additional steps for MSCRM to get it to run in IFD mode, like how to edit the install configuration file to set up IFD from the install (though the easier and less error-prone route is to use the IFD tool) and any extra configuration needed for hosting, such as changing the security of the website in IIS to anonymous.
Something that’s vital for a happy hosting environment for MSCRM is making sure the async service is running all the time. This is vital not only because it manages workflow (and what good is MSCRM without workflow), imports, and background processes, but also in a hosted scenario—it handles logins done via form-based authentication.
Really, MSCRM is pretty easy to host and set up, and while the demo HMC web console doesn’t provide automatic provisioning tools, a lot of third-party ones do have options for MSCRM. Something I’ve learned is that when you deploy MSCRM 4.0, even if it’s not a hosted deployment, it’s worthwhile to make every MSCRM deployment IFD. My reasoning for this is twofold:
- Authentication is handled in a superior way, as you have normal NTLM and form-based options. This can give you a way to solve those complex Kerberos-based issues caused by problems in AD without needing to mess around with AD.
- At some point in the near future, someone in your business will want to work from home or while on a business trip. You can save them from messing around with VPNs and just point them to the same URL they normally use—provided you’ve set up your DNS and firewall correctly—so you’ll save some headaches for you and your users.
If this has interested you, make sure you go to TechEd Africa—there’s an IFD Tips and Tricks session for Microsoft CRM!