Shortly after the rollout, when any users attempts to open Outlook, the following error was thrown, and the CRM Outlook toolbar (and corresponding CRM functionality) were disabled:

The client was running Update Rollup 6 for the CRM for Outlook, and Kaspersky Workstation v6.0.4.1424.

To resolve the issue, we performed the following the following 2 steps:

1) Add the CRM for Outlook application to the Trusted Zone in Kaspersky.

2) White List the CRM URL in Kaspersky under Anti-Banner –> Settings –> WhiteList area

On an entity record list view (e.g., Contact records), when selecting a set of records, and clicking on the print button from the toolbar, an error message appears.  The issue happens under conditions where users run Internet Explorer 8, and use the CRM for Outlook client.  Affected user machines were patched to one of the later Rollup levels (at the time of writing – Rollup 10).  What was peculiar was the problem did not appear at the web client level, but only in the Outlook client.

Below is a screenshot of the error:

A platform trace revealed some additional not-too-helpful info:

‘System.Web.HttpUnhandledException’ was thrown.

Error Message: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

Error Details: Exception of type ‘System.Web.HttpUnhandledException’ was thrown.

Source File: Not available

Line Number: Not available

Request URL: http://crmserver/OrganizationName/_grid/print/print.aspx

Stack Trace Info: [FormatException: Input string was not in a correct format.]

   at System.Number.StringToNumber(String str, NumberStyles options, NumberBuffer& number, NumberFormatInfo info, Boolean parseDecimal)

   at System.Number.ParseInt32(String s, NumberStyles style, NumberFormatInfo info)

   at Microsoft.Crm.Application.Pages.Grids.PrintPage.ConfigurePage()

   at Microsoft.Crm.Application.Controls.AppUIPage.OnPreRender(EventArgs e)

   at System.Web.UI.Control.PreRenderRecursiveInternal()

   at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)

[HttpUnhandledException: Exception of type 'System.Web.HttpUnhandledException' was thrown.]

   at System.Web.UI.Page.HandleError(Exception e)

   at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)

   at System.Web.UI.Page.ProcessRequest(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)

   at System.Web.UI.Page.ProcessRequest()

   at System.Web.UI.Page.ProcessRequest(HttpContext context)

   at ASP.organization__grid_print_print_aspx.ProcessRequest(HttpContext context)

   at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()

   at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

We opened a ticket with Microsoft Support.  The explanation of the problem dealt with an IE 8 bug on handling multiple processes, or when information is moved between zones. 

The resolution:

1) Open Registry Editor on each affected client machine:
2) Navigate to: HKEY_CURRENT_USER –> Software –> Microsoft –> Internet Explorer –> Main
3) In the Main folder, create a new DWORD named: TabProcGrowth
4) Set the value of the TabProcGrowth to 0
5) Restart your machine
6) Upon restart, flush your IE temporary cache

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.

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.

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. 

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!

“ One or more e-mails in Microsoft Dynamics CRM are waiting to be sent.  To allow Microsoft Microsoft Dynamics CRM for Outlook to send these e-mails, go to Options from the CRM drop-down menu and review your e-mail integration settings. “

The message tells us that email activities are waiting to be sent, however, the owner of the email activity has not configured his/her CRM Options to allow Outlook to send e-mail activities.  What to do?  Check this option in the E-mail tab of CRM Options:

However …

What if you wanted to see what email activities are waiting to be sent out?  Perhaps you have generated some test workflow emails that have backlogged overtime.  Or, you’re just not sure what kind of email activities are going to be sent out, and to whom (you’ve never enabled the above option, right?)

When CRM email activities are created, they are placed into a queued state (also called a Pending Send state in the CRM).  To review what emails are in your queue, issue the following advanced find criteria

(remember to modify the owner to your user record)

From here, you can decide which email activities should be sent out, and which ones should be removed, before its too late.

Using advanced find functionality, you can generate a list of email and appointment activities that have unresolved recipient addresses in the activity party (in either the FROM, TO, CC).  You can specify any activity type, but Appointments and Emails are ones we deal with often.

Look For: Activities

Activity Type ‘Equals’ Email; Appointment

Related Activity Parties (Activity)

Party ‘Does Not Contain Data’

The latest update from MBS Support.

Symptoms:

====================================

When the display name contains a combination of parentheses, spaces and ‘@’, the CRM outlook client throws an error ‘Invalid Email Address’ when you attempt to perform a manual promotion to CRM.

Workaround:

====================================

Change the display name of the user such that it doesn’t contain a combination of space, parentheses and ‘@’

This issue is known to occur when Update Rollup 4 is installed.

A typical scenario might be that a WF rule fires and sends an e-mail activity to a recipient, based on some change in a record.  Recently, these e-mail activities appear to show placeholders (e.g., {Full Name(Contact)} {Account Type(Contact)} ) instead of the dynamic value in both the subject and description fields.

This issue has only recently appeared for these clients.  Both clients were at Rollup 3.  The clients had recently upgraded to IE8.

Upon a closer look at the available research, it appears others have reported this finding.  For some users, when a WF rule is published using IE8, the dynamic values are sent as placeholders in an e-mail activity.  Some users report the issue being fixed by Rollup 2, and Rollup 3.  Other users have not had this success.

It appears that republishing the WF using IE7 fixed the issue.  If anyone has insight or workaround on this, please share the findings with our community.