Dynamics CRM 2013 – Access Denied “SecLib::AccessCheckEx failed” – Error & Resolution #MSDynCRM


It’s been a long time since I had blogged anything out here. Partly due to working on various projects simultaneously.

This post is about one CRM issue faced by one of our CRM users. He was trying to qualify a lead and it was not happening. Following error message was thrown:

Screen Shot 2014-08-06 at 12.40.12 PM

Following is the log file, which explained in detail about this issue:


<s:Envelope xmlns:s=”http://schemas.xmlsoap.org/soap/envelope/”><s:Body><s:Fault><faultcode>s:Client</faultcode><faultstring xmlns:xml=”http://www.w3.org/XML/1998/namespace&#8221; xml:lang=”en-US”>SecLib::AccessCheckEx failed. Returned hr = -2147187962, ObjectID: 919e14d1-6489-4852-abd0-a63a6ecaac5d, OwnerId: 3c8fcb46-39f6-4618-80eb-9c12f9f9a021,  OwnerIdType: 8 and CallingUser: 610b8b50-46e6-e311-80bb-00155d071101. ObjectTypeCode: 4703, objectBusinessUnitId: 3271f8a6-83d8-e311-80ba-00155d071101, AccessRights: ReadAccess </faultstring><detail><OrganizationServiceFault xmlns=”http://schemas.microsoft.com/xrm/2011/Contracts”><ErrorCode>-2147187962</ErrorCode><ErrorDetails /><Message>SecLib::AccessCheckEx failed. Returned hr = -2147187962, ObjectID: 919e14d1-6489-4852-abd0-a63a6ecaac5d, OwnerId: 3c8fcb46-39f6-4618-80eb-9c12f9f9a021,  OwnerIdType: 8 and CallingUser: 610b8b50-46e6-e311-80bb-00155d071101. ObjectTypeCode: 4703, objectBusinessUnitId: 3271f8a6-83d8-e311-80ba-00155d071101, AccessRights: ReadAccess </Message><Timestamp>2014-08-06T08:42:07.844046Z</Timestamp><InnerFault><ErrorCode>-2147187962</ErrorCode><ErrorDetails /><Message>SecLib::AccessCheckEx failed. Returned hr = -2147187962, ObjectID: 919e14d1-6489-4852-abd0-a63a6ecaac5d, OwnerId: 3c8fcb46-39f6-4618-80eb-9c12f9f9a021,  OwnerIdType: 8 and CallingUser: 610b8b50-46e6-e311-80bb-00155d071101. ObjectTypeCode: 4703, objectBusinessUnitId: 3271f8a6-83d8-e311-80ba-00155d071101, AccessRights: ReadAccess </Message><Timestamp>2014-08-06T08:42:07.844046Z</Timestamp><InnerFault xmlns:i=”http://www.w3.org/2001/XMLSchema-instance&#8221; i:nil=”true” /><TraceText xmlns:i=”http://www.w3.org/2001/XMLSchema-instance&#8221; i:nil=”true” /></InnerFault><TraceText xmlns:i=”http://www.w3.org/2001/XMLSchema-instance&#8221; i:nil=”true” /></OrganizationServiceFault></detail></s:Fault></s:Body></s:Envelope>


Upon checking those terms on CRM forums and blogs, following post, by Simon Harvey of Rule30, helped me on how to approach this issue: Fixing a SecLib::AccessCheckEx failed error in CRM.

My user’s issue was that he was not having access to read “Process” at the organization level. I had previously set it up to “User” level. After changing the access level as follows, he was able to qualify leads without any issues.

Screen Shot 2014-08-06 at 1.28.24 PM

 

Most important thing here is that when you query your ObjectTypeCode and corresponding Object Name for code 4703, it will return the name as WorkFlow. Note that on Security Role setup, it’s nothing but Process.

Happy troubleshooting.

VAIDY

#MSDYNGP Extender View Involving Extender Window/Form – Strange “Add Link” Issue & Reason.


Firstly, I am not sure whether I should categorise this as an issue. Let me explain this with an example.

For illustrative purpose, my requirement is to assign an additional information to customers. In addition to Country Code, I would like to assign from which continent a customer is from.

First step; to create an Extender Form named Continent Maintenance in which I will maintain list of continents. I do not need anything information other than an ID (Continent ID) and a name (Name); as shown below:

Snip20140114_1

Note that there are no fields apart from ID and Description.

Second step; I am going to create an Extender Window for Customer Maintenance (Cards -> Sales -> Customer -> Additional -> Continent) to assign a continent to a customer. Extender Window definition is as follows:

Snip20140114_2

Third step; is to check whether things are properly done and confirm. Let me open Customer Maintenance and see if I can access this new Extender information:

Snip20140114_3

Perfect. Let’s now get into the actual issue.

I would like to create a view to retrieve customer continent information. To achieve this, I would like to link Assign Continent (Extender Window) with Continent Maintenance (Extender Form) to get the continent name. Ideally, my view should retrieve following:

Customer ID, Continent ID, Continent Name

Now, when I try to create an Extender View linking my Extender Window and Form, I end up facing below issue:

Snip20140114_4

Snip20140114_6

Did you see that? I do not have my Extender Form fields shown here. I have two fields; Continent ID and Name. Where are they? Why are they not shown here? Shouldn’t it be available for me to link with my Extender Window’s Continent ID?

REASON: If your Extender Form DOES NOT have any other field than an ID and a Description (in my case, Continent ID and Name), ADD LINK To Field will not list out the ID and Description fields.

Is that the actual reason? Let’s confirm by adding another field to Extender Form as follows:

Snip20140114_7

After adding above field, Additional Info., look at my Extender View Add Link now:

Snip20140114_8

Did you see that? They are available now. AFTER adding a field in addition to default ID and Description fields.

And I am not sure how many have ever noticed this. I am noticing it for the first time now. I haven’t created any form with only ID and Description till now. I had to spend 4 hours to identify this reason, honestly. Had no idea whatsoever.

Those who are going to deal with Extender views with form(s) having ONLY ID and Description fields, save your 4 hours. :-)

VAIDY

SQL Server Uninstall: Removal Architecture Mismatch Error


When I was trying to uninstall SQL Server 2008 from my machine, I received the following error message:

Snip20140106_5

 

At a glance, this error may seem to be something critical, but it is not. It’s something quite silly to be honest. When you install SQL Server 2008 on a 64 bit machine, it installs SQL Server for both x86 and x64 compatibility, leaving two separate items under Control Panel -> Programs and Features, as shown below:

Snip20140106_4

 

If you try to uninstall by clicking on first one (above 64-bit one), then you will get this rule mismatch error. You must select the second one (64-bit one) to successfully uninstall.

When I selected the appropriate one, my uninstall validations passed without hassles.

Snip20140106_3

 

Happy troubleshooting…

VAIDY

GP Web Client: Rendering Issue – Some Facts


Almost a month back, I had posted my GP web client test drive results on how the client is rendered on Mac based browsers and possible issue with Silverlight plugin. I am probably wrong.

Everything works other than pictures; that’s what I had found. Upon drilling down further, what I realised is that it sounds obvious that it doesn’t work on Mac based browsers. Reason: Native Pictures.

Definition of Native Picture says following:

Snip20131230_12

Consider, for instance, the following snapshot of GP login window on a web client rendered on Mac Safari:

Snip20131230_10

It’s not shown. Initially I thought it was something to do with Silverlight rendering. But not exactly. It’s because, this picture is a Native Picture. And by definition, it’s specific to Windows OS. Look at this picture definition below:

Snip20131230_9

Apparently, by nature, it’s NOT supposed to show up on any OS other than Windows.

It’s not just this picture. Lookup Button icons, Note icons are all Native Picture types. And due to that, they are not going to render on any other OS. And if I am not mistaken, this will remain as it is at least till next major version of GP.

Those who implement GP web client MUST be aware of this.

VAIDY

GP 2013 Web Client – Cross Domain Error


This probably would be a common error faced by many of us across the GP world, while trying to access GP 2013 Web Client.

Upon launching GP web client on my browser, it asked me to enter my domain credentials and once I did that, I was greeted with following error:

Snip20131209_5

 

Complete error message is as follows:

Severity: Critical
Summary: An error occurred while initializing communication with the server.
Details: [CrossDomainError]
Arguments: https://<machine name>.<domain name>:48652/RuntimeService/5652
Debugging resource strings are unavailable. Often the key and arguments provide sufficient information to diagnose the problem. See http://go.microsoft.com/fwlink/?linkid=106663&Version=5.1.20913.00&File=System.ServiceModel.dll&Key=CrossDomainError

Reason is quite trivial; I had entered the url on my browser as follows:

https://<machine name>/GP

Instead, I should have entered the url on my browser as follows:

https://<machine name>.<domain name>/GP

For instance, if my GP web client server name is GPDEV and my domain name is GPDOMAIN.COM, then I should enter my url as follows:

https://gpdev.gpdomain.com/GP

There could be several other reasons for this CrossDomainError issue, but above solution fixed mine.

VAIDY

GP2013 – Purchase Invoice Inquiry Zoom Bug (Change)


I received a strange support request today from one of my users that PO number is not shown fully on Purchase Invoice Inquiry Zoom window. Just tried to inquire some purchase invoices myself and I got what she mentioned:

Snip20130807_12

 

If you see above highlighted PO number, it’s not shown fully. This will be the case only if you use GP’s standard PO number sequence or used entire PO length of 17 characters.

When I checked it on Modifier, I found a nice little icon sitting right next to PO number field, but overlapping it by some millimeters.

Snip20130807_11

This icon denotes whether the PO line item is Drop-Ship or not.

And boy, isn’t that icon looks cute? But unintentionally, it is overlapping on PO number field. Not sure how folks at GP dev team skipped this.

Solution to this issue? Modifier. Use modifier to resize the field, till we get this fixed by GP dev team.

VAIDY

syExcelReports Table & SQL Server Native Client 10.0 – Thanks Aaron Berquist


While upgrading our GP from GP2010 SP3 to GP2013 SP1, DYNAMICS database upgrade stopped unexpectedly with GP crashing without any information for me to debug.

But it stopped exactly at table syExcelReports and crashed. Without spending anymore time, I just went and checked my ODBC DSN setup, as explained by Aaron Berquist on his blog High Dynamics Range. Expectedly, the ODBC DSN driver was not pointing to SQL Server Native Client 10.0.

For some reason, GP fails to process upgrade further if your DSN driver is NOT native client 10.0 or above.

Those who upgrade your GP to latest version, please check DSN before you start database upgrade using GP Utilities.

VAIDY