We have many people wondering about this Automatic E-mail Tagging option that is available in the CRM Diagnostics and what it does. I will address that here in detail.
What is the E-mail Tagging Process?
The e-mail tagging process is a process that polls the CRM Server for messages that are currently tracked in Outlook. If there are CRM Server side modifications, it will retrieve these changes from the CRM server to Outlook for modified e-mails only.
When you turn on Automatic E-mail Tagging through the CRM Client Diagnostics tool, this updates the TagDisabled registry key to a 0 in the following path: HKEY_CURRENT_USER\Software\Microsoft\MSCRMClient\{Orgid}
When the e-mail tagger process starts, the client computer sends a request to the Dynamics CRM Server to get a list of the top 51 recently tracked e-mail messages on which the current user is a party. As part of the E-Mail Tagging process, it will fetch the e-mails using the following criteria.
-Records for which the CRM user is a party
-Records that have a modified on date on or after the TagStartDateOffline or TagStartDateOnline specified in the Outlook client registry
-Records where the messageid is not-null
The CRM server will then compile the list, and send it back to the CRM for Outlook client in the form of XML, consisting of the following values:
-TimeStamp
-MessageId
-ActivityID
If the CRM for Outlook client machine receives 51 records back in the response from the CRM Server, it increases the request to the last 101 e-mail messages. It does this until it can confirm that it is processing all of the messages where this user is a party that occurred after the timestamp in the query.
The e-mail tagging process utilizes an SDF database called EmailCache.sdf. This file can be found in the following location:
%AppData%\Microsoft\MSCRM\Client
There are two tables that exist in the EmailCache.sdf database that are used by the tagging process:
-EmailIdMappingTable
-RecentEmailsTable
Let's look at the RecentEmailsTable:
This table contains a list of all of the recent e-mails that have been received by the CRM for Outlook client within Microsoft Office Outlook. This includes the inbox and all subfolders within the mailbox. This table is used as an index of the user’s mailbox so that the CRM Add-in does not have to consistently scan the user’s mailbox looking for items to tag.
As the user receives new e-mail messages in their inbox, this table is updated with the messageId of the new message, as well as the EntryId so it can locate the message if it later needs to be tagged.
When an object is moved within Outlook, or is deleted, it also inhibits the ability of the CRM Add-in to find the record in the user’s mailbox. Each of these events is also tracked and the RecentEmailsTable is updated accordingly.
Now, let's look at the EmailIdMappingTable:
This table contains the mappings between the e-mail messages in the user’s mailbox and the ActivityID for the tracked e-mail message that exists in the Dynamics CRM database.
Let's go more in-depth with Tagging:
As the CRM for Outlook client machine is returned results from the CRM server of items that need to be tagged, it looks up the item in the EmailIdMappingTable to see if it has already been tagged.
If the message is already linked (it already exists within the EmailIdMappingTable), the CRM Add-in verifies that the information on the record is correct, such as the RegardingId. If an update is needed, meaning an update from the CRM Server, the CRM Add-in updates the item within Outlook, and then updates the corresponding row in the EmailIdMappingTable. Once this is complete, it goes to the next record.
If the message does not exist within the EmailIdMappingTable, the CRM Add-in looks up the MessageId and EntryId in the RecentEmailsTable. It uses this information to find the object within Outlook, and updates the records custom properties. Once the item has been updated, it inserts a row corresponding to the update into the EmailIdMappingTable. When it tries to find the object in Outlook, you may notice read requests to the Exchange server if Outlook is not configured for Cached Exchange mode. If it is configured for Cached Exchange mode, it will find this using the OST file.
The custom properties mentioned above include crmAsyncSend, crmEntryId, crmmessageid, crmxml, and crmsecondpagexml. These can be found in the email by clicking on the Developer tab in the e-mail. Once here, select Design this Form, click the All Fields tab, and select User-defined fields in this item.
If the email is sent outside of the Exchange domain, the User-Defined properties will be removed for the email that is received by the recipient.
Some of the registry keys that will affect tagging are below:
TagLastUpdateTime- This is updated with the System Time of the last tagging poll
TagStartDateOnline- This is updated based on the TagLastUpdateTime minus the TagGracePeriod time, which is 24 hours by default.
TagStartDateOffline- This is updated based on the TagLastUpdateTime minus the TagGracePeriod time, which is 24 hours by default.
TagGracePeriod- The default is 86400 seconds. It can be set to a lesser value allowing the Outlook client E-mail tagger to process records that are not as old. For example the value of 3600 should allow for e-mail about 1 hour old.
TagMaxAggressiveCycles- http://support.microsoft.com/kb/2585157
TagPollingPeriod- http://support.microsoft.com/kb/2585157- defaults to 5 minutes.
Two of the most common scenarios where tagging is useful are the following:
1. When the user record (Settings| Administration| Users) is set to use the Email Router. When using the Email Router for incoming and outgoing emails, the CRM for Outlook client cannot tell whether or not the emails should be tracked, as they are routed through the Email Router for tracking instead. Since the tagging process's main goal is to retrieve changes to emails from the CRM Server and bring them to the CRM for Outlook client, tagging will see that these emails have been added to or changed in CRM and that they should be tracked when requesting records from the CRM Server and it will then pull down these change to the CRM for Outlook client to show these emails as tracked.
2. The second scenario is where the System Settings (Settings| Administration | System Settings) "Track e-mails sent between CRM users as two activities" is not marked. If two CRM users are included on an email, each user has the option to track this into CRM. Now, if User1 tracks this to a specific record (Record A), the Set Regarding record will then be updated on the CRM Server for that email. However, if User2 tracks this email from their CRM for Outlook client and sets the regarding to a different record in CRM (Record B), this will update the Set Regarding for the same email record on the CRM Server. If tagging is enabled on User1's CRM for Outlook client, this set regarding change will roll down to User1's email in their CRM for Outlook client and they will now see this Set Regarding to Record B.