Lately, it seems that I’m increasingly asked to participate in pre-sales activities where someone from the customer’s IT department is blocking the purchase of CRM until he (or she) gets a better understanding of CRM’s impact on Exchange. Given the mission-critical nature of email these days, that’s understandable.
I’ve found that, for the most part, these discussions are all very similar. The customer has a lack of information, old information, or misinformation about how CRM interacts with Exchange. What follows are the major points I cover when in these pre-sales situations.
Outlook Sync vs. Outbound Email vs. Inbound Email
One misconception I run into a lot is that the Microsoft CRM-Exchange E-Mail Router handles all CRM email (both inbound and outbound) and also performs the synchronization of Contacts, Appointments, and Tasks between CRM and Exchange. Actually, the router only does a very small part of this: it processes inbound emails.
Outbound emails sent from the CRM Outlook Client (both flavors) are sent via Outlook if they are sent using the Outlook email form with the Track in CRM button selected. In earlier versions of CRM, these emails were diverted to the CRM server where they were sent out via SMTP. With CRM 3.0, though, these emails are sent like any other email, so like any other email, you’ll find the ones you’ve sent in your Sent Items folder.
Outbound emails sent by the CRM server are sent via SMTP. This includes all emails sent using the CRM web forms, workflow, and the CRM web services. CRM can use any SMTP server to send emails. This is configurable during the CRM install. In my deployments, I often use a local SMTP server (installed on the CRM box) or point CRM to an Exchange server which doubles as an SMTP server. It should also be noted here that since these emails exit via SMTP and never hit Exchange, you will not find these emails in your Sent Items folder.
Contacts, Appointments, and Tasks are synchronized via the Outlook Sync which is a component of the CRM Outlook Client (both flavors). This is a client-side synchronization process that takes place between CRM and Outlook, so while the data ends up in Exchange, the actual interaction is with Outlook.
CRM 3.0 Exchange E-Mail Router Architecture
Now that we know what the router does (processes inbound emails) and what it doesn’t do, let’s take a quick look at how it accomplishes its task:
The router, which is the only CRM component installed on Exchange, is associated with a mailbox created to process inbound CRM emails. Each CRM user has a rule on his/her inbox that forwards all received email to the CRM mailbox. The router, then processes each message that has been forwarded to the CRM mailbox. If it determines that the message belongs in CRM, it’ll insert the email into CRM; otherwise, it’ll toss it.
The router has to be installed on the back-end server that houses the CRM mailbox. It communicates with the local Exchange server only, so if the mailbox isn’t there, it’s not going to work.
Prior versions of CRM used an entirely different architecture, relying on SMTP Event Sinks that processed email when the it first comes in from the Internet. So, if you’ve heard anything about having to install the router on bridgeheads or front-end servers or gateways, forget about it. That’s the old architecture. It proved to be clunky and had an assortment of issues that I won’t go into. Just take my word that the 3.0 architecture is the right way to do it.
Risk Adverse? Deploy a Dedicated Exchange Server for CRM
If you’re risk adverse, you can always put the CRM mailbox and router on a dedicated Exchange Server. Since it’s a back-end server and it doesn’t house any user mailboxes, there’s little risk to it going down. You’ll lose inbound email while it’s down, but it should pick up where it left off once it’s up again.
Still Too Concerned? Don’t Deploy the Router; Users Can Still Promote Email
Even given the option of deploying to a dedicated Exchange Server, one of my customers was still too adverse to the whole thing to even go that route. They were looking to do a CRM deployment that included users across the globe. Their Exchange deployment was also global, utilizing back-end servers located near the users. The customer was concerned about the stress CRM would place on their Exchange environment given that mail received by someone in China would have to travel form the U.S. to China for initial delivery and then back again because the mail would now be forwarded to the CRM mailbox. I gave them some options to consider, and they picked to simply not deploy the router.
If you choose not to deploy the router, you won’t get automatic inbound email processing; however, your users can still promote received email by opening the item in Outlook and clicking the Track in CRM button. Note that this option is only available if you have one of the CRM Outlook Client flavors installed.
Exchange Router and Global CRM Deployments
On the topic of global CRM deployments, the choices I gave the customer in addition to not using the router were as follows:
- Use a single router, placed near your CRM server, and let Exchange handle the traffic of emails forwarded to the CRM mailbox.
- Use multiple routers, placed near your Exchange servers, and let the routers communicate with the CRM server from across the globe (I think the prior option is the better way to go, but I haven’t tested either option to be able to say definitively that this one shouldn’t be considered).
- Use a single router, placed near your CRM server, and only deploy the rules to those users near the CRM server (the ones in North America for this customer).
Support for Exchange Clusters
With 3.0, we do support installing the router on Active/Passive Exchange clusters. We don’t support Active/Active clusters. You can find more information on this topic here: http://www.microsoft.com/dynamics/crm/using/deploy/clusteringexchangeservers.mspx.
Support for Multiple CRM Deployments
The CRM 3.0 router does support multiple CRM deployments. You can use a single router processing multiple CRM mailboxes (one for each deployment). You can find more information on this topic on page 17-4 of the CRM 3.0 Implementation Guide (Rev. 3.0.5).
Well, that’s the stuff I go over with Exchange Administrators during pre-sales engagements. In every case so far, I’ve gotten their thumbs up. Hopefully this post will help you out if you’re getting some of the same questions during your pre-sales efforts or, better yet, if you’re an Exchange Administrator who’s stumbled onto this post while researching CRM.