Skip to main content

Notifications

Announcements

No record found.

News and Announcements icon
Dynamics 365 Community / Forums / Microsoft Dynamics CRM (Archived) / Weird new problem with...
Microsoft Dynamics CRM (Archived)

Weird new problem with audit history in CRM 2016 - Cannot view some secure fields even with full permissions - Possible bug?

(0) ShareShare
ReportReport
Posted on by Daniel at VNS

We've had auditing working fine for years.  I'm the admin, have full access to the DB, all Field Security roles, and handled our recent upgrade from 2011 to 2013, to 2015, and 2016 (SP1 v8.1.0000.0359).  Most things work fine.  Auditing *kind of* works fine.  I say that because I've encountered a weird problem.

There is a field in an entity that is secure (Account - Service Cost).  When I review audit history, I see a little icon and no data.  Even though I'm admin, and hold all 3 field security perms for the field on the entity.  I also noticed that there were some other secure fields that I still *could* see in the audit history (Auto Insurance Expiration).  See below.

Initially I thought this may be due to data encryption, since I'm running our 2016 deployment without SSL and our 2015 deployment that we migrated from *does* have SSL.  That made sense as the possible reason - until I realized that there *are* fields visible to me on the 2016 server, that *are* secured, as shown below with the Auto Insurance Expiration field.  Makes no sense.

Would be interested in any feedback.  I'm thinking it's a bug.  I'm reticent to apply SSL to our 2016 deployment to test my theory for a number of reasons.

However, I did  just apply data encryption to the deployment and these fields STILL do not appear visible to me, the domain admin.  Anyone know if this is a known bug?

Any input appreciated.

11_2D00_6_2D00_2016-8_2D00_04_2D00_21-PM.gif

*This post is locked for comments

  • Verified answer
    Daniel at VNS Profile Picture
    Daniel at VNS on at
    RE: Weird new problem with audit history in CRM 2016 - Cannot view some secure fields even with full permissions - Possible bug?

    SOLUTION, in case anyone needs it:

    To turn audit history back on where it was disabled:

    DELETE FROM auditbase

    WHERE Action='102'

    from:

    social.microsoft.com/.../ms-dynamics-crm-audit-history-shows-icons-instead-of-values

    and:

    msdn.microsoft.com/.../gg328086.aspx

    To enable it on specific entities:

    DELETE FROM auditbase

    WHERE Action='102' And ObjectTypeCode= 'ObjectTypeCode';

    where objecttypecode = the entity from the metadataschema/entitytable

    for OOB entiies, you get type code here: msdn.microsoft.com/.../gg328086.aspx

    for custom entities you go from entitytypetable.  for example, to find any named like hot sheets:

    Select objecttypecode, * from Entity where name like '%hot%'

    then replace each type code below with the right one you want.  here's an example of 3 of them:

    DELETE FROM auditbase

    WHERE Action='102' And ObjectTypeCode= '10009' or ObjectTypecode = '1' or ObjectTypecode = '4';

  • Daniel at VNS Profile Picture
    Daniel at VNS on at
    RE: Weird new problem with audit history in CRM 2016 - Cannot view some secure fields even with full permissions - Possible bug?

    So I've gotten closer to an answer on my own question but could still use an assist from anyone who knows how.  This article sheds light on the probable cause:

    [View:https://social.microsoft.com/Forums/en-US/01b4318b-ec73-4eb2-9245-479f643cc58a/ms-dynamics-crm-audit-history-shows-icons-instead-of-values?forum=crm:750:50]

    Specifically:

    We have also found a (unsupported) way of fixing this issue: due to the fact that the "new value" is either the current value or the old value of a subsequent entry, the information about the new value is not lost at all. The system just checks if the audit has been turned off at some point and displays the icon after that. To avoid this you can delete the information about the deactivation and reactivation of the auditing. You will find this entries in the AuditBase table. "Action" is 104. Delete the two newest entries for deactivation and reactivation and the system will display the values again. We are aware that this might not be correct in the point of view that audit information can only be valid if the audit was enabled the whole time, but in our case we deactivated the audit by accident during the update rollup and activated it immediately again.

    I did not *intentionally* disable auditing - i disabled and enabled the button while trying to test something else, not knowing it would cause much prior audit history to become inaccessible.

    This article states that the (unsupported) solution is to just hop into the org's dbo.AuditBase table and delete the 2 latest rows with 104 action (Audit Change at Org Level.....even though my change was made on a single entity).

    The problem is that I'm no DBA and don't even know how to go about finding these rows.  And once I do, is it as simple as deleting 2 rows?  

    Can anyone provide input on how to do this without damaging the DB?

    TIA.

  • Daniel at VNS Profile Picture
    Daniel at VNS on at
    RE: Weird new problem with audit history in CRM 2016 - Cannot view some secure fields even with full permissions - Possible bug?

    Update - i did try to simply disable the SSL check so that I could enter the key, to see if that solved this problem, per this article:

    crmbusiness.wordpress.com/.../crm-20152013-all-you-need-to-know-about-database-encryption

    Supported by this MS article:

    technet.microsoft.com/.../dn531199.aspx

    And immediately after doing so, I was reminded of why i didn't want to touch this.  CRM App Pool suddenly keeps stopping and won't stay running - as if the service PW is wrong.  But i did not *touch* the service PW.  I simply disabled the SSL check, and did an iisreset.

    This also happened on our 2015 deployment, which has a 3-server distributed CRM model (front, back, deployment), and the only way i could get the app pool to STAY running was to do a 'repair' installation and then I even had to move front end and deployment services to the same server to get SSL working.   I'm sure that can't be the best solution but I'm not finding clear documentation on why this would happen with a multi-server deployment.

    This did NOT happen on our 2013 deployment, which had front/back/deployment on the same server.

    Our 2016 deployment is running on 3 servers.  If anyone knows why doing this (ie: simply doing iisreset) breaks the CRM app pool (PERMANENTLY it appears), I'd love to know.  I run the app pool with a dedicated account, per best practices and no matter what, as long as I have CRM deployed in a distributed model, it seems like ANY time I do iisreset, be it for this procedure, or to install an SSL cert, it breaks the app pool and requires me to re-run the installer to 'repair' an installation of CRM that simply is not broken.

    Thank you.

Under review

Thank you for your reply! To ensure a great experience for everyone, your content is awaiting approval by our Community Managers. Please check back later.

Helpful resources

Quick Links

December Spotlight Star - Muhammad Affan

Congratulations to a top community star!

Top 10 leaders for November!

Congratulations to our November super stars!

Tips for Writing Effective Suggested Answers

Best practices for providing successful forum answers ✍️

Leaderboard

#1
André Arnaud de Calavon Profile Picture

André Arnaud de Cal... 291,253 Super User 2024 Season 2

#2
Martin Dráb Profile Picture

Martin Dráb 230,188 Most Valuable Professional

#3
nmaenpaa Profile Picture

nmaenpaa 101,156

Leaderboard

Featured topics

Product updates

Dynamics 365 release plans