Peter Gernburd's MSCRM Corner

The other day, our client brought an interesting issue to our attention.  On the address form, both the ‘Save’ and ‘Save and Close’ buttons were missing on the header of the form; the address record could not be saved and linked to a contact record.

Our first inkling was a caching issue, but we were later informed all users with the exception of the a few – those with the System Administrator role – were experiencing this problem.

This notion led us to the belief that the issue was security related, yet we were quiet confident that no specific privilege related to the address entity.  Our initial thoughts were the ‘Append’ and ‘Append To’ on the Contact entity (afterall, we do associate the address record to a contact).  That did not work.

The remaining privileges for the Contact entity were in order. 

What was going on?

As it turns out, CRM also expects the Write privilege on the Account (Company) entity in order to save an address record for a contact. 

There is some truth that the address record form is shared between contact and account records, but I would not have expected to expose privileges on one entity, in order to allow a particular action for another.

We leave this question open to the community for a better explanation, workaround, or fix.

We have a number of clients who are using the latest and – in my opinion – greatest version of Windows – Windows 7.  Also, with the price of memory dropping to new lows, users are opting for a 64-bit version of Windows 7 (to address the 4GB RAM limitations of a 32-bit memory address).

Issue
On these 64-bit Windows 7 machines, users began reporting a generic CRM error message while starting Mail Merge functionality in CRM.  The concern was, not every user was experiencing this issue, and all users were on the same rollup level and OS/application level (at first, it was not clear to us that differences in memory address was an issue).

We enlisted the help of Microsoft Support, and with the gold standard service that several senior support engineers provide (Dan) were able to determine that the cause of the issue is not caused by a bug within CRM, but rather an issue with Windows 7 x64.

Specifically, when CRM calls to open an Internet Explorer window, it incorrectly reads a registry value, causing a 64-bit IE window to open instead.  Since the CRM client code is written as a 32-bit app, a 32-bit operation cannot be made in a 64-bit IE window causing the Mail Merge to fail.

Solution
The solution below (provided by Microsoft Support) applies only to 64-bit versions of Windows 7.  The solution does not apply for 32-bit versions of Windows 7 (there should be no issues).  If you are finding Mail Merge issues in a 32-bit Windows 7 environment, consider reviewing the latest Rollup for more details.

You will need the following:

• Be a local admin to the machine
• Download a Powershell script from here: http://uploading.com/files/7m2d93d3/IE64BitFix.zip/
• Take a full backup of your registry before starting

1 a) Extract IE64bitFix.ps1 from the IE64BitFix.zip file.
b) Change ownership of the script to be a local admin user for the machine.
c) Login as the local admin for that machine.
2. Launch Regedit (right click and Choose ‘Run As Administrator’)
3. Navigate to HKLM:\SOFTWARE\Wow6432Node\Classes\CLSID\{D5E8041D-920F-45e9-B8FB-B1DEB82C6E5E}
4. Right-click on the key and choose Permissions.
5. If the TrustedInstaller user appears in the list, remove it.  Make sure the Administrator user has Full Control on the key and its subkeys.
6. If you run into an error removing the TrustedInstaller, click on Advanced and then on the owner tab, change the owner.
7. Close the Registry Editor.
8. Launch Powershell doing the following:
a. Start > All Programs > Accessories > Windows Powershell.
b. Right click on Windows Powershell ISE
c. Choose ‘Run As Administrator’
d. Copy the attached Powershell script  to the machine.
e. Choose File > Open in the Powershell UI and select the powershell script you copied to the machine.
f. Press F5 or the Green Go button to execute the script
9. Start Outlook and verify the fix.

Some users have reported a need to apply less security restrictions by running the Set-ExecutionPolicy cmdlet prior to executing the script.  To do this in Powershell:

1. Apply no restrictions, so that all Windows Powershell scripts can be run

Set-ExecutionPolicy Unrestricted

2. Apply the Powershell script as detailed in step 8

3. Return to allowing only signed scripts (or Restricted, or RemoteSigned)

Set-ExecutionPolicy AllSigned

Update  – Exporting to Excel from a SharePoint iFrame
As a double bonus on this issue, clients have reported that using these steps, they are now able to open Excel documents within Excel, from a SharePoint iFrame in the CRM.  Prior to the fix, Excel document would open within the confinements of the iFrame window in a CRM record.

A client of ours recently ordered a new machine for one of their users.  The user was an administrator to their Windows 7 machine.  When the user launched the CRM for Outlook installer, they were met with the following error message:

Installation cannot proceed: Setup cannot continue because a pending restart is required.  Restart the computer and then try running Setup again.

Multiple reboots later, we were still running into the same issue.  The solution, was to make a slight modification to the registry.

1. Open HKEY_CURRENT_USER\Software\Microsoft
2. Create a new key named: MSCRMClient
3. In the MSCRMClient keyword, create a a DWORD named IgnoreChecks, and set the value to 1.

Released Feb 11, Updated Rollup 9 is available for Microsoft CRM 4.0

Download location: http://www.microsoft.com/downloads/details.aspx?FamilyID=5869f2b3-d1a0-4f71-8be3-fde6e8053a2e&displayLang=en

Knowledgebase article: http://support.microsoft.com/default.aspx?kbid=977650

A few points to consider:
* Before install Update Rollup 9, Update Rollup 7 is a pre-requisite for the Microsoft CRM for Outlook client and Microsoft Dynamics CRM Data Migration Manager.
* Microsoft CRM for Outlook may be restarted after applying Update Rollup 9
* After installing Update Rollup 9, the client should clear their Temporary IE files.

We recently had an interesting case brought to our attention.  Inbound e-mails were being tracked into the CRM, and a corresponding email activity was properly created and linked in the CRM.  The Track-in-CRM button was active when the user opened the email.  However, the user was concerned that she could not see e-mail messages being tracked in CRM through the default Outlook window (the double-head icon was missing).  In other words, no e-mails ‘appeared’ to be tracked in CRM from the main window.

Turns out, the Icon column was missing from the user’s Inbox window.

Hopefully this simple solution will help others who have a similar issue:

1) From the Outlook main window, click on Inbox
2) Right-click on the columns area and select Field Chooser

3) Drag the Icon field from the Field Chooser to the columns area window

Before (Missing Icon column):

After:

Suppose you’ve selected a list of CRM contacts for a Mail Merge (MM).  However, the list of recipients in the Mail Merge do not equal the number of contacts that you had selected for that MM.  The recipient list, although correct, is incomplete.  What happened?

To understand this problem, we need to understand how Microsoft CRM uses several out-of-the-box fields to select which contacts should and which contacts should not be selected to receive MM material.

There are two levels of control that Microsoft CRM uses to decide if a contact should be selected.

The first field, donotsendmm (commonly labeled as ‘Send Marketing Materials’) is the overriding option.  This option controls whether a contact could be selected in a MM (value = Yes), or not (value = No) altogether.  If donotsendmm is set to ‘Yes’, CRM then looks at a subset of other fields that outline which type of MM activity the contact can be included in.  The list of MM types include Letter, Email, Fax, Envelope, and Label.  This granular level of detail is necessary if, for example, a contact may wish to subscribe to MM e-mails, but not MM faxes.  These settings are controlled by individual fields.

The table below summarizes what field and option set is needed for a contact record to be included in a MM. 

Note: The table above assumes the field donotsendmm has been set to ‘Yes’

After installing Rollup 7, some users have reported a new ActiveX control notification when attempting to open CRM through the web browser.

Internet explorer has blocked this site from using an ActiveX control in an unsafe manner.

This issue has been a documented by Microsoft in KB976539.  The problem may arise if the CRM for Outlook was installed but not configured, or the user attempts to access an organization that CRM for Outlook was not configured for.

In our scenario, CRM for Outlook was properly configured to our default organization, yet all users continued to receive this ActiveX warning.  Second, many of our clients use the CRM for Outlook within a multi-tenant environment.  We needed a clearer solution.

Below is a workaround that we’ve found to ‘correct’ this problem:

1. Open Internet Explorer
2. From the Tools menu, select Internet Options
3. Switch to the Security tab
4. Click the site zone where you’ve placed the URL to your CRM (we place the CRM URL in the local intranet zone), and click Custom Level
5. Under the ActiveX controls and plug-ins, enable this option:

Initialize and script ActiveX controls not marked as safe for scripting

Save the new settings, and restart Internet Explorer.

The above recommendation was documented in MSDN’s article: Improve the Outlook Experience with CRM, part four

If you have an alternative solution, please feel free to share it with us. 

* This information is provided in the CRM 4.0 implementation guide.

Extending our earlier article on using the Auto Update feature to update CRM for Outlook clients, this article dives into the process for removing a patch that either had been mistakenly deployed, or no longer needed in the database.

Note, that this method does not actually remove a patch that has already been installed.  Rather, the steps below removes the autoupdate patch link from the database.

The process is quiet simple.

1) Retrieve a copy of the PatchId for the update you want to removed.

See the initial article: Auto Update feature to find out how to retrieve the PatchId

2) Create an XML file as follows (e.g., Rollup6-remove.xml).  Replace the PatchId with the update to be remove.

<ClientPatches>
<Delete>
    <PatchId>{7E83D1E5-7B7A-45D1-8930-4FEFB4123B57}</PatchId>
</Delete>
</ClientPatches>

3) Issue the following command below to remove the update:

“C:\Program Files\Microsoft Dynamics CRM Server\Tools\Microsoft.Crm.Tools.ClientPatchConfigurator.exe” “c:\crmpatches\Rollup6\Rollup6-remove.xml”

Note: Change the path to the ClientPatchConfigurator utility and the path to the xml file as required.

An interesting issue came to our support department today, with special thanks to Dr. B.T. for reporting it. 

The user added several money attributes to the contact entity.  All contact records appeared to have taken on the new money fields properly, with the exception of a few records.  For these records, when a user added a value to the money field, the following error appeared:

“ A currency is required if a value exists in a money field. Select a currency and try again. "

What happened?  One of the new features in CRM 4.0 is multicurrency.  Click here to learn more about it.  In short, anytime you place a money field on the form, a corresponding Currency value should also exist.

To correct the problem, we added the Currency field (schema: transactioncurrencyid) on the contact form, and selected the appropriate currency value for that record.

Problem solved!

By default, Microsoft CRM uses Smart Matching to match and regard inbound emails to existing CRM records, so that similarities in emails threads are linked to the same object record. For a review of how Smart Matching works, please visit: http://community.dynamics.com/blogs/cscrmblog/archive/2008/11/11/microsoft-dynamics-crm-email-correlation-and-smart-matching.aspx

Microsoft CRM can also be configured to use Tracking Tokens to help predict which inbound emails should link together. A tracking token is an alphanumeric string generated by Microsoft Dynamics CRM and appended to the end of an e-mail subject line. It matches e-mail activities with e-mail messages.

In the past, we have had reported issues where smart matching technology has work inconsistently, often times leading to incorrect tracking of records. Some clients have asked on the possibilities of switching from Smart Matching to Tracking Tokens. This article covers such steps.

Prerequisite:

The CRM environment is at least at the Rollup 3 level.

Part A:

Review and complete all steps in Microsoft Knowledgebase article 969946: http://support.microsoft.com/kb/969946/

Note: While running the Microsoft.crm.se.emailtrackingtokenextractortool.exe I received an error regarding the execution in the .NET Framework. Specifically, the error message was: Execution of user code in the .NET Framework is disabled. Enable "clr enabled" configuration option”.

I executed the following commands in SQL server:

exec sp_configure ‘clr_enable’,’1′
RECONFIGURE

The Microsoft.crm.se.emailtrackingtokenextractortool ran properly.

I then disabled this functionality after the tool completed.

exec sp_configure ‘clr_enable’,’0′
RECONFIGURE

Part B:

Review and complete all steps in Microsoft Knowledgebase article 958084:

http://support.microsoft.com/kb/958084

There is a hotfix, as well as a registry key setting that are applied to the CRM application server, and all client machines running CRM for Outlook.

Part C:

Enable Tracking Tokens in CRM by following these steps:

Open CRM | Settings | Administration | System Settings | Email (tab)

Click Use Tracking Tokens

If necessary, specify additional properties for tracking tokens, such as the subject prefix, number of digits for incremental message counter.

That’s all.  From here on, new CRM-tracked emails will have a tracking token appended to the end of the email subject