TJ Martin's blog

Suppose you have a custom security role similar to the one below.

Suppose as well that we have the following scenario.

System admin creates two records – RecordA and RecordB

User named Bob (with the above custom role) creates two records – RecordC and RecordD

Scenario #1
RecordA and RecordC are merged, with recordA as the master record
Scenario #2
RecordB and RecordD are merged, with recordD as the master record

In both instances/scenarios, Bob can view both records as well as modify it as if it were his own. Regardless of what the system admin changes the owner of the records to, Bob still has access to the records. There’s no sharing enabled on any of these records that would bypass security roles. Yet this is clearly what we’re seeing – it seems that when records are merged, it maintains the privileges that the user previously had to the new record.

This behavior can also be replicated in CRM 2011.

Digging around SQL, one could see in the PrincipalObjectAccess table that the permissions are being inherited for the merged records for the user (InheritedAccessRightsMask). This is a flaw in design, as it clearly bypasses security roles and breaks business logic.

The Microsoft engineer that I’ve been working with on this issue has been kind enough to open up a Product Enhancement suggestion: https://connect.microsoft.com/dynamicssuggestions/feedback/details/731596/sharing-rights-incorrect-after-merging-two-records-security-issue

You can vote for this suggestion so we can see some kind of an implemented fix.

A client recently moved their deployment from IFD to strictly On-premise. Everything seemed all fine and dandy until they noticed that their URLs for their templates were still pointing to the old server.

The fix is simple, right? Simply go into Settings –> Business –> Templates, and correct the erroneous URL. Then Save. But alas, users continued to receive e-mails with the incorrect URL pointing to the activity.

Back in CRM v4.0, in order to resolve this issue, we had to do the following:

1. Log-in as a CRM Customizer or System Admin.

2. Go to Settings –> Customizations –> Export Customizations.

3. Select the Templates entity and export it.

4. Open the customizations.xml file in Notepad or another .xml file editor program.

5. Perform a search for “http://SampleCRMDev/SampleCo/” and replace the “http://SampleCRMDev/SampleCo/” with the correct CRM server information. You would typically see entries with the asyncoperation/edit.aspx or import/edit.aspx extension.

However, this seems to work quite differently with CRM 2011. I created a solution with the E-mail Templates entity, published and exported the file. I noticed immediately that there were no entries for these in the customizations.xml file. So instead, I exported the default solution, opened the customizations.xml file, and did a search for the old URL.

I replaced these entries to point to the new URL and also changed the URLs for the existing E-mail templates, reimported the default solution, and asked the client to give it a try again. Worked like a charm.

If you’re a CRM user with an Internet Facing Deployment, you’re likely aware of the following issue when exporting records to Excel using the dynamic worksheet method.

This seems to be a known issue with IFD users; the issue doesn’t affect On-premise deployments.

Thankfully, there’s a workaround – two, actually.

The easiest workaround:
After exporting the Dynamic Worksheets/Dynamics Pivot Tables, refresh the data.
a. Export the Dynamic Worksheets/Dynamics Pivot Tables from Microsoft Dynamics CRM 2011.

b. Open up the Dynamic Worksheets/Dynamics Pivot Tables with Excel.
c. Within Excel, click on Data tab.
d. Click on Refresh from CRM button.

Your data should now appear after refreshing:

Longer workaround:
1. Export the Dynamic Worksheets/Dynamics Pivot Tables from Microsoft Dynamics CRM 2011.
2. Open up the Dynamic Worksheets/Dynamics Pivot Tables with Excel.
3. After the ADFS sign in page or the “Script is disabled” error shows in the worksheet, click on Data tab.
4. Click on Connections.

5. Within Workbook Connections, click on Properties.

6. Within Connection Properties, click on Definition tab.
7. Click on Edit Query button.

8. Within the Edit Web Query, window you will need to do one of the following:
- Using IFD Claims authentication, the Edit Web Query will redirect to ADFS login, enter in the user’s credentials and click on Sign In.
- Using Claims authentication, continue to step 9.

9. After getting the Microsoft Dynamics CRM error, click on OK.

10. Within Edit Web Query, click on Cancel.
11. Within Connection Properties, click on Cancel.
12. Within Workbook Connections, click on Close.
13. Within Excel > Data tab, click on Refresh All.
If done correctly, your data should now appear.

We ran into an issue today with trying to update existing records for a custom entity using the Import Data tool:

‘The records were not updated because the record type was not found in Microsoft Dynamics CRM.’

We had a custom entity named Territory – but there was also an out-of-the-box entity named Territory. Perhaps this was the reason we were unable to update these records. We went into the Customizations and changed the out-of-the-box Territory to say ‘Territoryxx.’ We changed the Plural Name as well to ‘Territoriesxx.’

After saving and publishing, we attempted to import the data once again, but this time we were met another error.

‘The records were not updated because the following Microsoft Dynamics CRM fields were not found: Area Code’

We took another look at the list of fields for our custom entity, and found that we had two fields with the same display name of Area Code. One was a picklist and the other was a text field. We didn’t really need the picklist and decided to scrap it – then we saved and published, and attempted the import process once again.

This time it worked!

As we can see here, the import process successfully worked. Yes, it was only for a single record.

Remember, when you want to update existing records, to make sure that the following options are selected when using ‘Export to Excel.’

Also, ensure that when you’re done updating the Excel spreadsheet, that it’s saved as an XML Spreadsheet 2003 format.

A newly deployed CRM 2011 environment with a major issue: incoming tracking is not working for all users. An e-mail would only be tracked if a user manually clicked on ‘Track in CRM,’ regardless of the source address, and affects all inbound e-mails.

Let’s look at the machine configurations we looked at:

- CRM for Outlook 2011 with Rollup 4 installed

- Windows 7 / Outlook 2010 32-bit

Other things we’ve taken a look at:

- Only one e-mail address exists on the contact/account records; user e-mails only exist on user records with only the emailaddress1 having a value

- All users have sufficient permissions – even system admins have the tracking issue

- No plugins or onLoad JavaScripts – users are able to manually send CRM E-mail activities

We’ve also attempted to set Personal Options to below:

The options for the browser:

We’ve also specified Smart Matching and Tracking Tokens in the System Settings:

What we noticed was interesting. If an e-mail is manually promoted/tracked to the CRM, clicking on ‘View in CRM’ gives us the ‘FROM’ address but there’s no corresponding ‘TO’ value.

After running a server-side platform trace, we saw that there were no error messages, but we decided to look into it closer:

>OrganizationSdkService starts processing request for user:CheckIncomingEmail

As user:da5fd2aa-60ce-e011-b310-6431504fbf78

Request Xml:

<CheckIncomingEmailRequest xmlns=”http://schemas.microsoft.com/crm/2011/Contracts” xmlns:i=”http://www.w3.org/2001/XMLSchema-instance“><Parameters xmlns=”http://schemas.microsoft.com/xrm/2011/Contracts” xmlns:a=”http://schemas.datacontract.org/2004/07/System.Collections.Generic”><KeyValuePairOfstringanyType><a:key>MessageId</a:key><a:value i:type=”b:string” xmlns:b=”http://www.w3.org/2001/XMLSchema”>&lt;92EFEDCEEBA84946B4EE9652BA5A392C25FD16AC@SINEX14MBXC420.southpacific.corp.microsoft.com&gt;</a:value></KeyValuePairOfstringanyType><KeyValuePairOfstringanyType><a:key>From</a:key><a:value i:type=”b:string” xmlns:b=”“TJ’>http://www.w3.org/2001/XMLSchema”>”TJ Martin” Totmartin@salentica.com</a:value></KeyValuePairOfstringanyType><KeyValuePairOfstringanyType><a:key>To</a:key><a:value i:type=”b:string” xmlns:b=”“Test’>http://www.w3.org/2001/XMLSchema”>”Test User” /O=FIRST ORGANIZATION/OU=First Administrative Group/cn=Recipients/cn=TUser;</a:value></KeyValuePairOfstringanyType><KeyValuePairOfstringanyType><a:key>Cc</a:key><a:value i:type=”b:string” xmlns:b=”http://www.w3.org/2001/XMLSchema”/></KeyValuePairOfstringanyType><KeyValuePairOfstringanyType><a:key>Bcc</a:key><a:value i:type=”b:string” xmlns:b=”http://www.w3.org/2001/XMLSchema”/></KeyValuePairOfstringanyType><KeyValuePairOfstringanyType><a:key>Subject</a:key><a:value i:type=”b:string” xmlns:b=”http://www.w3.org/2001/XMLSchema“>RE: tracing e-mail after tracking CRM:00020004</a:value></KeyValuePairOfstringanyType></Parameters><RequestId i:nil=”true” xmlns=”http://schemas.microsoft.com/xrm/2011/Contracts”/><RequestName xmlns=”http://schemas.microsoft.com/xrm/2011/Contracts”>CheckIncomingEmail</RequestName></CheckIncomingEmailRequest>

>Email delivery found no matching user or queue recipient and the e-mail will be rejected (subject: RE: tracing e-mail after tracking CRM:00020004).

Running the client-side tracing, we found that the TO e-mail address field is specified in a non-SMTP format:

<CheckIncomingEmailRequest xmlns=”http://schemas.microsoft.com/crm/2011/Contracts” xmlns:i=”http://www.w3.org/2001/XMLSchema-instance“>

<Parameters xmlns=”http://schemas.microsoft.com/xrm/2011/Contracts” xmlns:a=”http://schemas.datacontract.org/2004/07/System.Collections.Generic“>

<KeyValuePairOfstringanyType>

<a:key>MessageId</a:key>

<a:value i:type=”b:string” xmlns:b=”http://www.w3.org/2001/XMLSchema”>&lt;92EFEDCEEBA84946B4EE9652BA5A392C25FD16AC@SINEX14MBXC420.southpacific.corp.microsoft.com&gt;</a:value>

</KeyValuePairOfstringanyType>

<KeyValuePairOfstringanyType>

<a:key>From</a:key>

<a:value i:type=”b:string” xmlns:b=”“TJ Martin’>http://www.w3.org/2001/XMLSchema“>”TJ Martin” tmartin@salentica.com</a:value>

</KeyValuePairOfstringanyType>

<KeyValuePairOfstringanyType>

<a:key>To</a:key>

<a:value i:type=”b:string” xmlns:b=”“Test User’>http://www.w3.org/2001/XMLSchema“>”Test User” /O=FIRST ORGANIZATION/OU=First Administrative Group/cn=Recipients/cn=TUser;</a:value>

</KeyValuePairOfstringanyType>

<KeyValuePairOfstringanyType>

<a:key>Cc</a:key>

<a:value i:type=”b:string” xmlns:b=”http://www.w3.org/2001/XMLSchema”/>

</KeyValuePairOfstringanyType>

<KeyValuePairOfstringanyType>

<a:key>Bcc</a:key>

<a:value i:type=”b:string” xmlns:b=”http://www.w3.org/2001/XMLSchema”/>

</KeyValuePairOfstringanyType>

<KeyValuePairOfstringanyType>

<a:key>Subject</a:key>

<a:value i:type=”b:string” xmlns:b=”http://www.w3.org/2001/XMLSchema“>

RE: tracing e-mail after tracking CRM:00020004

</a:value>

</KeyValuePairOfstringanyType>

</Parameters>

<RequestId i:nil=”true” xmlns=”http://schemas.microsoft.com/xrm/2011/Contracts”/>

<RequestName xmlns=”http://schemas.microsoft.com/xrm/2011/Contracts”>CheckIncomingEmail</RequestName>

</CheckIncomingEmailRequest>

When we manually track an e-mail in the CRM, this is what we see:

<CheckIncomingEmailRequest xmlns=”http://schemas.microsoft.com/crm/2011/Contracts” xmlns:i=”http://www.w3.org/2001/XMLSchema-instance“>

<Parameters xmlns=”http://schemas.microsoft.com/xrm/2011/Contracts” xmlns:a=”http://schemas.datacontract.org/2004/07/System.Collections.Generic“>

<KeyValuePairOfstringanyType>

<a:key>MessageId</a:key>

<a:value i:type=”b:string” xmlns:b=”http://www.w3.org/2001/XMLSchema”>&lt;BFFEF0EA51BE13488F7238A04BEB9AAA0522DD06@alenCRM5.fisat.com&gt;</a:value>

</KeyValuePairOfstringanyType>

<KeyValuePairOfstringanyType>

<a:key>From</a:key>

<a:value i:type=”b:string” xmlns:b=”http://www.w3.org/2001/XMLSchema“>”test user”test@fisat.com</a:value>

</KeyValuePairOfstringanyType>

<KeyValuePairOfstringanyType>

<a:key>To</a:key>

<a:value i:type=”b:string” xmlns:b=”http://www.w3.org/2001/XMLSchema”>”Administrator”Administrator@fisat.com;</a:value>

</KeyValuePairOfstringanyType>

<KeyValuePairOfstringanyType>

<a:key>Cc</a:key>

<a:value :type=”b:string”xmlns:b=”http://www.w3.org/2001/XMLSchema“/>

</KeyValuePairOfstringanyType>

<KeyValuePairOfstringanyType>

<a:key>Bcc</a:key>

<a:value i:type=”b:string” mlns:b=”http://www.w3.org/2001/XMLSchema”/>

</KeyValuePairOfstringanyType>

<KeyValuePairOfstringanyType>

<a:key>Subject</a:key>

<a:value i:type=”b:string” xmlns:b=”http://www.w3.org/2001/XMLSchema“>trace with smart matching</a:value>

</KeyValuePairOfstringanyType>

</Parameters>0

<RequestId i:nil=”true” xmlns=”http://schemas.microsoft.com/xrm/2011/Contracts”/>

<RequestName xmlns=”http://schemas.microsoft.com/xrm/2011/Contracts”>CheckIncomingEmail</RequestName>

</CheckIncomingEmailRequest>

We decided to look into the user’s Outlook SMTP box. The SMTP field has to be populated in order for tracking to work.

Here’s what our users were seeing on their SMTP fields:

The client was running on Exchange 2010, Rollup 5.

The client mentioned that it seemed to be an issue with their OAB. When a user runs Outlook in cached mode, the SMTP info doesn’t populate and no inbound tracking occurs. Taking Outlook out of cached mode, the SMTP data populates and inbound tracking e-mails works like a charm.

The issue was resolved by deleting the existing OAB on Exchange, creating a new one from scratch, and then had it downloaded to the client. This then populated the SMTP fields correctly and tracking should work at this point.

I hope this helps someone out there – this was quite a head scratcher, certainly!

If you remember from this previous posting: http://blogs.salentica.com/tmartin/2011/07/04/crm-4-0-0×80040216-an-unexpected-error-occurred/

We found that this was due to the AddressNumber=1 field in the database having NULL values, and resolved it correspondingly.

Now, however, another client faced a similar issue but albeit different one altogether. In the Contact record, address2 fields are being used but certain records aren’t able to be updated when attempting to modify these fields. CRM throws a generic, non-descript error.

Upon running a platform trace to reproduce the issue, we again see the following from the logs:

Stack Trace Info: [InvalidCastException: Specified cast is not valid.]

at Microsoft.Crm.BusinessEntities.AddressTrigger.Update(GUID)

Diving into SQL, we looked at a few affected records in the CustomerAddressBase table and compared it with a test record that works and can be updated just fine.

From the looks of it, AddressNumber=2 field simply didn’t exist in the database for the affected records.

Now, as with the previous posting, the supported way of resolving this issue is to recreate the records or merge them into a new one. However, if there are too many records to do this for (READ: hundreds), you may want to look into an unsupported method. By unsupported, we mean that Microsoft will NOT support it and neither will we.

But for the curious, we ran the below script to insert an empty AddressNumber=2 field into the affected records.

————————–
–Add CustomerAddress
– AddressNumber =2 if missing
– 2 Separate Steps
————————-

———-
– Step 1
———-
declare @ThisUserId uniqueidentifier
select @ThisUserId = SystemUserId from SystemUser where DomainName=”

declare @RunDate datetime
select @RunDate = GETUTCDATE()

insert into CustomerAddressBase
([CustomerAddressId]
,[ParentId]
,[CreatedOn]
,[CreatedBy]
,[ModifiedOn]
,[ModifiedBy]
,[AddressNumber]
,[ObjectTypeCode]
,[Name]
,[ImportSequenceNumber]
)
select NEWID(),
ParentId,
@RunDate,
@ThisUserId,
@RunDate,
@ThisUserId,
2,
2,
‘Billing’,
999
from CustomerAddress
where ParentId not in (select ParentId from CustomerAddress where AddressNumber = 2)
and ObjectTypeCode = 2
group by ParentId

——
–Step 2 – ONLY After Step 1 completed successfully
——

insert into CustomerAddressExtensionBase
(CustomerAddressId,
ssi_primarymailingaddress
)
select CustomerAddressID,
0
from CustomerAddressBase
where CustomerAddressId not in (select customeraddressid from CustomerAddressExtensionBase)

The result should look like the below, and you should be back to updating the records correctly.

More installation issues with the Outlook add-in; this time, our client is installing on a Windows XP SP3, and we end up running into the below error:

Looking at the Add/Remove Programs, we see the following.

We tried uninstalling and reinstall .NET Framework 3.5 SP1 but to no such avail. We decided to have a look at the setup log files that the CRM dumps out during a failed installation, and we noticed this:

14:53:29| Info| Installation of Microsoft .NET Framework failed. Exit code: 5100. Result: A pre-release version of Windows Workflow Foundation or .NET 3.0 has been detected. Please uninstall it before continuing.

However, looking further into the log, we saw that it was trying to look for .NET Framework 4.0.

14:53:12| Info| Launching external process:
14:53:12| Info| CmdLine: <”C:\DOCUME~1\ADVISO~1\LOCALS~1\Temp\MSCRM_{ABE67266-4498-4AFA-9E79-A4C802A66A86}\dotNetFx40_Full_x86_x64.exe” /q /norestart /ChainingPackage NETFX4Beta2_DynamicsCRM>
14:53:12| Info| WorkingDir: <C:\DOCUME~1\ADVISO~1\LOCALS~1\Temp\MSCRM_{ABE67266-4498-4AFA-9E79-A4C802A66A86}>

Once we downloaded and installed .NET 4.0, it was smooth sailing from there.

Ever run into this particular issue?

‘The installation has failed. The installation of the Windows Live ID Sign-in Assistant failed. Click the link below to view to log the file.’

To resolve the issue, simply download the Windows Live Sign-in Assistant to the Desktop (anywhere really), and install it by running the following command prompt:

msiexec /i wllogin_32.msi /l*v C:\setupLogs.log NOMU=1

After this is completed, you should be able to install, deploy Rollups, and configure CRM for Outlook.

A client was unable to update a few contacts – it was producing an error over and over. Attempting to reproduce the issue for the affected records, we came across this particular error:

When trying to set an address as a ‘Primary Mailing Address’ In the More Address section of a CRM contact, the above error takes place. It wasn’t an issue for most of any other contact.

A trace revealed the following information:

Error: Exception has been thrown by the target of an invocation.

Error Message: Exception has been thrown by the target of an invocation.

Source File: Not available

Line Number: Not available

Request URL: http://crm

Stack Trace Info: [InvalidCastException: Specified cast is not valid.]

at Microsoft.Crm.BusinessEntities.AddressTrigger.Update(GUID)

Further, the event log was showing errors related to this. It seemed to be attempting to call a step in one of our plugins that clearly was non-existent.

We decided to investigate in SQL, and found that there were contacts with a missing AddressNumber=1 field in the CustomerAddress table. In our case, AddressNumber fields were stamped for our records; however, they were stamped as AddressNumber=2. If you compare a broken record with one that works, you’ll see something similar with the one described below:

It was time to resolve the issue. We ran a few queries to do this.

The first query returns a count of how many records have the missing AddressNumber=1 field:

select COUNT(*)
from ContactBase c left outer join
CustomerAddressBase a on c.ContactId=a.ParentId and a.AddressNumber=1
where a.CustomerAddressId is null

The second query returns a column listing of all those records (you can add more columns if you wish):

select contactid, fullname, c.createdon, c.createdbyname
from Contact c left outer join
CustomerAddressBase a on c.ContactId=a.ParentId and a.AddressNumber=1
where a.CustomerAddressId is null

There are two ways to resolve this issue – one of which is unsupported by Microsoft. Create a backup of your MSCRM databases before attempting this.

Supported method:

Recreate the record, including the addresses, and merging the broken one with the new one.

Unsupported method:

begin tran

update CustomerAddress

set AddressNumber=1

where AddressNumber = 2 and ObjectTypeCode=2 and ParentId not in (

select ParentId from CustomerAddress where AddressNumber =1 and ObjectTypeCode = 2)

commit tran

I just want to reiterate that this method is completely UNSUPPORTED. However, this is an easier method if you have a number of records you’d rather not recreate/merge as it can be extremely time consuming.

Both methods will end up stamping the AddressNumber field correctly, and as a result, will be able to be updated with no issue from then on.

Recently, we weren’t able to publish several workflows (though the others work fine).

It all started with not being able to delete an attribute. We were seeing this error, even though the attribute we were trying to delete wasn’t being touched in a workflow:

- This attribute cannot be deleted because it is used in one or more workflows. Cancel any system jobs for workflows that use this attribute, then delete or modify any workflows that use the attribute, and then try to delete the attribute.

We unpublished the workflow, and then we were able to delete the attribute. However, when we try to publish these workflows again, we receive two different error messages:

- A generic “An error has occurred”

- The selected workflow has errors and cannot be published. Please open the workflow, remove the errors and try again.

At first, we thought that perhaps that the AsyncOperationBase table was getting out of control. That didn’t seem to be the case as it was within reasonable means. Nevertheless, we cleared it out. Same errors. We double checked our workflows and found no errors on any step of the workflows.

This time, we ran a trace and saw something that caught our attention: Crm Exception: Message: Unable to find metadata information for attribute (attribute).

We know that recreating the affected workflows would resolve the issue; however, these workflows are extremely massive in both scope and size. Recreating these would be too time consuming – plus, we couldn’t afford to recreate workflows each and every time we decide to delete attributes. We thought about going into the database and removing the references to the attribute, but then we all know that this wouldn’t be supported my Microsoft…

Then out of sheer luck, we were able to resolve the issue. We were verifying that the records that were going to be created for the step of the workflow was valid.

We simply went into the workflows, clicked on each step that was creating a new record, hit Set Properties, and clicked Save & Close. And just like that, we were able to publish our workflows again! Crazy. I suppose that saving the workflow step somehow refreshes the metadata and fixes the reference in the database?