Peter Gernburd's MSCRM and SharePoint Lounge

I often find myself navigating within SharePoint directly on the server.  Having blessed with installing the farm and playing around with the admin powers of configuration directly on the server, I often find myself running into a few common problems:

Issue: You are unable to open a document folder using the windows explorer feature.

Error: Your client does not support opening this list with Windows Explorer

Solution: Start the WebClient windows service.  To do this, make sure to install the “ Desktop Experience ” feature in Windows Server 2008.  From the Server Manager, click Features.  Install Desktop Experience.  After installation, you should start the WebClient windows service.

—-

Issue: With a new MS Office content type defined that hangs off the new button, you run into problems creating a new document.

Error: Word experienced an error trying to open the file.  There is a problem saving the file.  Usually this is because the disk or floppy disk is too small for the file or is full, RAM memory is low, or there is a permission problem with the drive the file is being saved to.

Solution: Disable Protected view in Office 2010
a) Open the office product
b) Click File –> Options
c) Select ‘Trust Center’
d) Select Protected View
e) Disable all the protected view options

In order to launch MS Office documents from SharePoint, or via the standard CRM 2011 list component, we need to define content types in SharePoint.

Here is a screenshot illustrating my goals from the CRM 2011 UI.  The new buttons, when clicked, will launch the appropriate MS Office application

Assumptions

1) A SharePoint site has been created.
2) At least 1 document library exists.  In our example, the CRM contact entity has it’s own document library named Contact.

Document Templates

For each type of document, open the corresponding application (Microsoft Word, Excel, PowerPoint).  Save a blank document to either your local drive, or you can upload it to site assets.  In this case, I created Word2010Template.docx, Excel2010Template.xlsx and PowerPoint2010Template.pptx

Adding Content Types

From the SharePoint site, navigate to Site Actions –> Site Settings
Under Galleries, click ‘Site Content Types’.
Click ‘Create’

Specify a name for the content type.  Under Select parent content type from, select ‘Document Content Types’.  Under Parent Content Type, select ‘Document’.  For the first new content type, we’ll create a new group to hold our custom types.  I named it ‘Office Documents’.  Click OK.

Next, we add the PowerPoint content type.  Perform the above steps but this time, group the type to an existing newly created group: ‘Office Documents’

Adding Content Types to Document Library

On the Contact document library, under Library Tools, click Library Settings

Click ‘Advanced settings’ under General Settings

Under Content Types, check Yes under ‘Allow management of content types’.  Click OK.

You’ll be redirected to the document library.  Now you should see a section labeled ‘Content Types’.  Click on ‘Add from existing content types’.

Under Select site content types from dropdown, select the custom group: ‘Office Documents’.

Move the content types from the left to the right frame.  Click OK./

With these new content types added, you can directly launch the MS Office application using the New button. 

I recently had the opportunity to work on an issue that would present itself as possible bad data, or an invalid attribute in a column view when browsing entity records.  In my case, it was browsing the e-mail template records.  However, I suspect this issue could turn its head on other entity record types as well.

When browsing to the e-mail templates, I was presented with this friendly error:

An error has occurred.

Try this action again.  If the problem continues, check the Microsoft Dynamics CRM Community for solutions or contact your organization’s Microsoft Dynamics CRM Administrator.  Finally, you can contact Microsoft Support.

Turning on the server platform trace revealed the following:

System.NullReferenceException: Microsoft Dynamics CRM has experienced an error. Reference number for administrators or support: #67EE19C8: System.NullReferenceException: Object reference not set to an instance of an object.

   at Microsoft.Crm.Sdk.Query.ConditionExpression..ctor(String attributeName, ConditionOperator conditionOperator, Array values)

   at Microsoft.Crm.ApplicationQuery.RetrieveEmailTemplateByObjectCommand.DecorateQuery()

I noticed that on the e-mail templates entity view, there were 2 default views.  Several CRM 4.0 users might recall this not-to-uncommon issue. 

However, I could not set one specific view to be the true default. 

To correct the problem, I manually modified customizations.xml.  As always, take a backup before making any direct modifications.

1) Create a new solution and add the email templates entity (EmailTemplatesSolution)
2) Export EmailTemplatesSolution and open customizations.xml
3) Find the XML section that refers to the savedqueryview that you do not want set as default (remember, we only want one default view).  Set it’s<isdefault> parameter to 0, as shown below.

4) Re-add the update customizations.xml file into the solution, re-import, and publish. 

You should hopefully be able to browse your entity records. 

When you try to configure the Outlook Client, you receive the following error

“There is a problem communicating with the Microsoft Dynamics CRM server. The server might be unavailable. If the problem persists, contact your system administrator”

Also, in your configuration logs, you receive the following error:
“Exception : The specified directory service attribute or value does not exist.
at System.DirectoryServices.DirectoryEntry.Bind(Boolean throwIfFail)
at System.DirectoryServices.DirectoryEntry.Bind()
at System.DirectoryServices.DirectoryEntry.get_SchemaEntry()
at System.DirectoryServices.AccountManagement.ADStoreCtx.IsContainer(DirectoryEntry de)”

The issue has to do with Update Rollup 5 and the new CRM Outlook client (R5).  This is a known issue at the moment.  Microsoft is working to address this in a future hotfix.  To work around this problem, you have 2 options:

Solution #1 – Give read privileges to Authenticated Users Group in AD for the user who is having the problem.  This is found on the security tab on the user’s profile.  You may need to enable advanced view in active directory to see the security tab.

Solution #2 – Install the old CRM Outlook RTM.
This solution ultimately helped our client resolve the problem.  You will need to have a copy of the existing CRM Outlook RTM client.  The new R5 client which was recently added to the Microsoft Downloads page will not work.

a) Uninstall any previous versions of CRM Outlook
b) Disable Windows Updates, so that Rollup 5 does not get pushed to the user’s workstation.
c) Install CRM Outlook RTM bits
d) Step through the configuration wizard.  You should be able to successfully
e) Install Rollup 5 client manually

For now, this is a workaround until the CRM team releases a hotfix.

My colleague and I were working this morning installing Update Rollup 14 on a client’s Production environment.  Shortly after patching and rebooting the application server, we were greeted with a not-to-friendly error message when launching CRM:

HTTP Error 500.0 – Internal Server Error
Calling LoadLibraryEx on ISAPI filter “C:\Program Files\Microsoft Dynamics CRM Server\Server\bin\DefaultAddonFilter.dll” failed.

The CRM application server was hosted on a 64-bit server with 8GB memory, running Windows Server 2008 R2, IIS7.

The cause of this problem was related to missing Microsoft Visual C++ 2008 SP1 runtime components.  After installing these component, CRM worked like a charm.

Below are links to the runtime libraries in case others run into this issue:

x64: http://www.microsoft.com/downloads/en/details.aspx?familyid=ba9257ca-337f-4b40-8c14-157cfdffee4e&displaylang=en
x86: http://www.microsoft.com/downloads/en/details.aspx?familyid=a5c84275-3b97-4ab7-a40d-3802b2af5fc2&displaylang=en

A number of our client’s have reported synchronization issues on their handheld devices after tracking CRM appointment.  Specifically, when CRM-tracked appointments are synchronized to the handheld device (in our findings, iPhones and Android phones are affected), users may see the following generated email:

—

Synchronization with your iPhone failed for 1 items.

Microsoft Exchange was unable to send the following items to your mobile device. These items have not been deleted. You should be able to access them using either Outlook or Outlook Web Access.

Item Folder:
Calendar

Item Type:
IPM.Appointment

Item Created:
DD/MM/YYYY HH:MM:SS
—-

At the time of this writing, we are aware that the problem affects mobile users who have Rollup 12, 13, or 14 installed.  A source suggests that a possible fix is slated for Rollup 15.  Another solution appears to be a downgrade to Rollup 11.

EDIT: The issue has been resolved in Rollup 15: http://support.microsoft.com/?kbid=2449283
EDIT #2: The issue continues to persist for users with Rollup 15.  We have re-opened our ticket with Microsoft Support.

Microsoft KB article outlining this issue: http://support.microsoft.com/kb/2447256

Our client recently rolled out Kaspersky Antivirius Workstation 6 to all client machines. 

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

Below is an issue recently brought to our attention by one of our clients.

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

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.