CRM 2016 Can't set regarding - SecLib::AccessCheckEx failed

Recently when a user was trying to use set regarding for a tracked email they were receiving the following error.

'You do not have enough privileges to acces the Micrsoft Dynamics CRM object or perform the requested opeartion.'

When running the CRM trace we found this error 'SecLib::AccessCheckEx failed. Returned hr = -2147187962, ObjectID: b043cc71-a644-e611-80d7-005056a076e4, OwnerId: 9d589563-f988-dd11-8b66-0013211ccf00,  OwnerIdType: 8 and CallingUser: e2619700-963c-e111-9119-005056932219. ObjectTypeCode: 4200, objectBusinessUnitId: c7ec9cc6-9e67-db11-97e6-0013211cbfff, AccessRights: WriteAccess'

It turns out CRM 2016 sets the owner automatically based off who sent the email rather than who created the tracked record.  We had a disabled user in MSCRM in a different business unit that when ever another user tried to track an email from them it would set the disabled user as the owner!  Reassigning the email fixed the issue and I found a few more that were problematic using advanced find.

CRM 2016 Can't track an email - missing prvReadConvertRule privilege

Recently we found an intermittant new issue with tracking email messages for some users.  When tracing with outlook we found the error 'missing prvReadConvertRule privilege'.  This didn't seem to directly translate to any role found configurable in CRM.

Using a bit of SQL I managed to find the roles that had that privilege set and then started to compare with the role I was hoping to use and found out that I needed to set organisational read for Record Creation and Update Rule under the Service Management tab.

If you are interested here is the query I used to find the roles with the correct privileges set.

SELECT r.Name FROM Role r WHERE EXISTS(SELECT 1 FROM RolePrivileges rp JOIN Privilege p ON p.PrivilegeId = rp.PrivilegeId WHERE r.RoleId = rp.RoleId AND p.Name = 'prvReadConvertRule')

3 Bugs in CRM 2016

In our CRM 2016 upgrade we have uncovered 3 bugs.

1) Unable to go offline, error relating to generating BCP file.

In our database which is an older install of CRM we have a timestamp around the 8 000 000 000 mark.

When creating the BCP header file it tries to convert that timestamp to a 32 bit integer which creates an overflow exception.  It seems older versions of CRM ignored this error and continued anyway.

Microsoft has now released a hotfix for this which now handles 64bit timestamps.

2) IFrames stripping out parameters relating to reporting services parameters when set via JS or form designer with Pass record type code etc ticked.

The only way around this bug so far that we have found is to upload the report into CRM and using JS set a relative URL!

3) Cannot find X method when deactivating a record

It seems when you deactivate a record it can try to call methods from a previously viewed form in the onload, the work around was to include the library from the other form in a form you are likely to be using in sequence, for example contracts and contract lines.

CRM 2016 Update Profile Picture

Information on this seems to be fairly limited at the moment, but this is cool feature.

1. Double click your image at the top right of the CRM 2016 screen.

 2. Select Choose File

 3. Pick your picture and click open

4. Click OK

Your profile picture should now be updated!

Unable to add user to CRM 2016

Recently I encountered an issue where I couldn't add a user as CRM determined that the user ID already existed in the organisation, however I could see no evidence of this.

After a quick search I found this article

https://blogs.msdn.microsoft.com/ukdynsupport/2009/07/16/authentication-when-you-are-adding-a-new-user-to-crm-or-a-user-to-a-new-organization-in-crm/

So the key was the user record was in the MSCRM_CONFIG database still, as we had done a restore and org import on an earlier backup.

To identify this was actually the cause I had to find the SID for the user, without access to the AD tools, I found an article on using powershell, the following commands got me the SID

PS> $objUser = New-Object System.Security.Principal.NTAccount("{domain name}")
PS> $strSID = $objUser.Translate([System.Security.Principal.SecurityIdentifier])
PS> $strSID.Value
S-1-5-21-1004336348-1715567821-725345543-40705

With the returned SID I could identify the record

 SELECT * FROM SystemUserAuthentication WHERE AuthInfo LIKE '%S-1-5-21-1004336348-1715567821-725345543-40705'

I decided to update the record SID to one that will never exist rather than delete, as there could be a spider web of relationships that get really stuffed up.

 

UPDATE SystemUserAuthentication

SET AuthInfo = 'W:S-1-5-21-1004336348-1715567822-725345543-40705'

WHERE Id = 'CF775160-6BE6-E511-80CF-005056BD0631'

After this update I was able to create the user record.

Unable to distribute Campaign Activities, Error retrieving next number (currentbulkoperationnumber) ..

In a CRM system we were having trouble distributing campaign activities, we would always get the following error 'Error retrieving next number (currentbulkoperationnumber) for organization {e14513f2-5cdb-4194-9ca1-52d04cd0b077): return value is empty'.  No matter what entity was in the marketing list the distribute would fail after choosing the owner.  What was equally perplexing new organisatios wouldn't have this issue.

We started getting this error in CRM 2011, my hope was upgrading to CRM 2016 would resolve this error, unfortunately not.

After doing a SQL trace on the SQL server we managed to find 1 SQL query which looked suspect.

exec sp_executesql N'declare @currentval int

update OrganizationBase set @currentval = CurrentBulkOperationNumber, CurrentBulkOperationNumber = CurrentBulkOperationNumber + 1 where OrganizationId = @orgid

select @currentval',N'@orgid uniqueidentifier',@orgid='E14513F2-5CDB-4194-9CA1-52D04CD0B077'

The CurrentBulkOperationNumber field in our OrganizationBase table was currently set to NULL, updating this to 1000 resolved the issue.

 UPDATE OrganizationBase SET CurrentBulkOperationNumber = 1000

This does make me wonder what other data issues are lurking in our database, that we just haven't noticed yet.