I’ve a customer who is expecting – due to a business merge – a huge increase in the volume of E-mails on daily basis from 300 to 20,000. Currently the setup is one e-mail router per each organization to handle both inbound and outbound emails, no forward mail boxes. Due to that change, they are considering scalability options.
So my customer is after scalability (ability to serve more users and/or bigger volume of transactions) not availability (which is minimizing down time and making sure service “available” as needed by operations requirements).
E-mail router Availability:
Looking at the available resources and the Implementation guide I found references to Availability solution not Scalability as follows.
Which is basically as follows:-
Step 1: Establish the cluster
Step 2: Install the E-mail Router to the active primary node in the cluster
Step 3: Install the E-mail Router to the passive node in the cluster
Step 4: Create the generic resource service for the cluster
Step 5: Verify and monitor the cluster
What we mean here is having more than one E-mail router, installed in more than one machine, serving the same organization, and all of them are active.
Multiple routers hosting the same inbound or outbound email profiles is not officially documented in the product implementation guide or any of the white papers issued by the product team, that makes it – based on the rule of thumb “not documented not supported”- not supported.
Actually having multiple routers works fine, but the problem is the potential for duplicate inbound email activities being created or outbound emails being sent (due to not having locking mechanism to control this).
Given that fact and considering the configurations of Email router, and the below rules
- Only one instance of the email router can be installed on a single machine.
- Each forward mailbox can only be processed by one email router.
Scalability options I found are:-
Important guidance here is, we should balance the out bound spread across routers based on the amount of emails being sent from those mailboxes not just by number of mailboxes. We discovered that 90% of email volume comes from 10% of the users, not to forget auto generated emails Ex: confirming receipt of email and OOB.
- We can separate incoming and outgoing processing across email routers (i.e. [machine 1 / email router 1] processes the incoming emails forward mailbox, and [machine 2 / email router 2] processes outbound mail).
- We can split out the outgoing emails across multiple email routers as long as each email router has a unique set of email address in its configuration, i.e. [machine x / email router x] processes outbound for email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, and [machine y / email router y] processes outbound for email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org.
- Good community article in that option :-http://quantusdynamics.blogspot.co.uk/2012/02/dynamics-crm-installing-email-router-on.html
- That option imposes HUGE maintainability issue, you have to maintain the list the email addresses.
- If we have multiple forward mailboxes we can use an email router (on its own machine) for each forward mailbox.
- Regardless of how many routers we are splitting across as described in the above scenarios, within one organization we are still querying on single tables – so adding appropriate indexing will also help performance.
- Coding and customization. Building on Option 2 above,
- Write code to populate the appropriate users in each XML file.
- Add a field to a user form that specifies which email router to use. This should probably be a lookup field pointing to a custom entity that holds a list of email routers, perhaps holding server name and IP. Make the field business required to ensure it is populated.
- Then there are a few options for the customs code:
- Custom workflow assembly or plugin to be triggered when the router value changes against a CRM user record. Connects to the specified previous email router server and updates the XML file to remove the user, connects to the new router to add the user to the XML file.
- Write a windows service that runs on each email router to update the distribution of users by connecting to the crm services and returning a list of all users that should be on that server and updating the XML.
- Write CRM Powershell or a batch command file that does the same as the above which is run by the scheduling process on each router server on a fixed schedule.
Performance of email router:
Having that all said, how good is the performance of e-mail router?
I would say it’s pretty solid, and I didn’t hear about availability problems with email routers so far. Check the article Large-scale CRM email processing at Microsoft
I’d like to call out:- One e-Mail router, 83 Deployment, 24 hours, 9400 received emails, 2400 tracked in CRM 2011.
So, before deploying scalability solutions make sure you actually need it.
· This information is provided for the purpose of illustration only and is not intended to be used in a production environment. THIS INFORMATION ARE PROVIDED “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE IMPLIED WARRANTIES OF MERCHANTABILITY AND/OR FITNESS FOR A PARTICULAR PURPOSE.