Archive for October, 2014

In Dynamics CRM every now and then users may encounter errors like the one below. These are typically random errors with Microsoft scripts that usually do not affect any functionality.

We’re prompted with the option to ‘Send Error Report’ to Microsoft so they can fix the bug if enough reports of the same issue come through, or we can click ‘Don’t Send’ and it will just close the dialog box and ignore the error. This dialog can be useful for customizers, but it is unnecessary to show to general users.

Each user can define their preferences for displaying these error messages in their Personal Options under the Privacy tab. By default it is set to ask us every time whether to send an error report or not. We can also select to automatically send the errors, or to never send the errors. Usually this is changed for everyone to automatically send or never send so that the dialog boxes do not show up.

What some people don’t know, is that we can define these preferences at a global level, so that each user doesn’t need to go into their personal options to make this change, and new users won’t need to see those popups by default.

To change this setting globally, go into System Settings, Administration, and click on Privacy Preferences.

On the Error Reporting tab, we can tick the box to specify the error preferences for all users, and then select whether to automatically send, never send, or prompt every time.

Once this change has been made, users will no longer see the Privacy tab in their personal options, and they will not be able to change this setting. Any new users that get created, as well as all existing users, will have these preferences automatically.

One thing to note is that as this is not a part of System Settings, you cannot deploy these preferences in a solution, so you’ll need to configure this in each CRM system.

If you’re seeing an error similar to the one above, you’ve probably done a database backup and restore from a CRM 2013 instance into a new CRM 2013 or 2015 instance. This error will pop up when you try and modify a user’s email address, or open personal options from outlook, as well as when performing some other tasks around CRM that include sensitive data.

The Data Encryption error states: “There are encrypted fields in the organization database, but the data encryption feature isn’t activated. Contact your Microsoft Dynamics CRM system administrator to activate data encryption. To activate, go to System Settings > Data Management > Data Encryption…”

The reason this error occurs is because when we restore/import a database, data encryption is disabled by default, even if it was enabled in the system we took a backup from. This is because the encryption settings are stored in the config database, so the .bak file does not contain these settings.

According to the error, to enable encryption we need to go into Data Encryption under Data Management. However, we can only enable Data Encryption if CRM is using the https protocol, and usually the reason we’ve done a backup/restore is because we’re setting up a Dev or UAT copy of Prod, which may not need to be https.

This error states that “The HTTPS protocol is required for this type of request. Enable the HTTPS protocol and try again.” However, enabling https may not be ideal, and we still need to be able use the system.

Fortunately, there is a SQL script we can run on the config database which will allow us to use data encryption without using the https protocol:

UPDATE [MSCRM_CONFIG].[dbo].[DeploymentProperties]
SET [BitColumn]=1
WHERE ColumnName=’DisableSSLCheckForEncryption’

You shouldn’t do this on a production instance, but for Dev or UAT instances this is necessary.

Once that’s updated you need to do an IISRESET on the CRM server for the changes to take effect.

If we try opening that Data Encryption window again, we should see that encryption is disabled, and we can create a new key and activate it.

You should be able to get the encryption key from the original CRM system you backed up from. If not, then you can simply create a new encryption key.

When you activate, you might be faced with another error which states “Please select an account that is a member of the PrivUserGroup security group and try again”.

This is because although we might be a system admin in CRM, we cannot update the encryption key unless we are a member of the PrivUserGroup in Active Directory. We can either log into CRM as the user who installed CRM, or we can get our user added to that security group.

Once that’s done we should now be able to activate the encryption key.

You should now be able to edit user email addresses, and perform any other operations that require data encryption without any errors.

NOTE: This encryption error only happens when we restore from a CRM 2013 or 2015 backup. If we create a new org through Deployment Manager, or if we upgrade a CRM 2011 database, encryption will still be enabled by default. We can see when creating a new org the wizard informs us that encryption will be enabled.

If you’ve recently upgraded to CRM 2013 SP1 and you’ve applied the product update for cases, you might be experiencing an issue where outlook users are unable to track certain emails in CRM. They receive an error: You do not have permissions to access these records. Contact your Microsoft Dynamics CRM administrator. Item Name = <email subject>.

After a bit of digging, we found that the missing privilege was Read access to the Case Creation Rule entity, which is a new entity added with the latest product updates. Because we already had existing security roles, these did not include any access to this new entity.

If we give User level Read access to the Case Creation Rule entity through our security roles, this error will no longer appear.

This error only seems to occur when the email being tracked is from an unresolved sender, which doesn’t match any existing CRM records.