CRM 2011: when auditing is turned off, why do existing Audit records lose "New Value"? RRS feed

  • Question

  • Not sure if this is by design (if so, would love to know why!) or if this is a bug.  Let's say I have auditing turned on for Accounts.  I change the phone number in the Main Phone field from 555-1111 to 555-5555, and an audit record is created showing the Old Value (555-1111) and New Value (555-5555).  Great.  Now I turn off auditing. The system goes back to the audit record that had previously been created, and modifies it so that it shows the Old Value (555-1111), and inserts an icon into the New Value field indicating auditing was turned off.  The tool tip for that icon states "Auditing was stopped and restarted.  The new values for the fields that changed during this period cannot be identified or recorded."

    First of all (minor picky issue) auditing hasn't been turned back on yet, despite what the tool tip says (says the same thing whether or not auditing is turned back on).  But the real problem is why the existing audit record's New Value would be removed... why would that happen?!?  We're talking about a historical update.  It really did change, and the system knew what it changed from/to, so why would the system remove that new value from the audit record?  Logically I would expect that any changes made while auditing is off would not be logged, and that once auditing is turned back on, Old/New values would correspond to whatever was/is in the system at the time that any new audit record is created, so there may be a disconnect between an older audit record and a new one (old record's New Value not matching the new record's Old Value, because changes were made while auditing was off). And it's quite apparent when auditing is turned off, because an audit record is created stating "Auditing Disabled". 

    Any ideas if there's a logical reason why it would do this, or if this is really a bug that Microsoft needs to fix?  We have a client with a business need to periodically turn off auditing while integration updates run between CRM and another system (otherwise hundreds of thousands of unnecessary audit records would be created).  But if they're going to lose audit data every time they disable auditing, the auditing is worthless.

    Thursday, June 16, 2011 9:54 PM

All replies

  • Very late reply and you might not even care anymore, but we've just hit the same thing and wondered.

    I can't say this authoritatively, but the explanation of the audit data's structure in this thread suggests that new values aren't actually recorded in audit data, only old ones. So if you're looking at audit record 1 that says "Field X changed value from A to B", that "B" is coming either from audit record 2 (which records B changing to something else) or from the current value of field X if there are no other audit records (and auditing hasn't been turned off since audit record 1).

    If you turn auditing off after audit record 1 is generated, you remember that X used to be A (because that's what audit record 1 stores), but you lose entirely the fact that it changed to B. Obviously, X can undergo any number of changes until it's turned back on, so CRM warns you that the audit data is unreliable.

    It would seem that auditing is designed to either be permanently on or lose data :P

    Wednesday, July 3, 2013 11:50 AM
  • The previous post correctly explains this behaviour. I think the main explanation for this design is for performance reasons when recording the auditing data.

    I'm struggling to see a good reason for temporarily turning off auditing. If the reason is that there are unwanted audit records due to records being updated with all fields set to the same value (which does generate audit records), then I'd suggest redesigning the process to only update records where one or more fields has changed

    Microsoft CRM MVP - http://mscrmuk.blogspot.com/ http://www.excitation.co.uk

    Wednesday, July 3, 2013 7:09 PM
  • David, thanks for the update.

    I think what you propose is perfectly reasonable, but right now, that's the nature of the process we have. I'd suggest it's also pretty reasonable that the retention of audit data not be dependent on auditing remaining enabled, and that the actual behaviour of CRM is quite surprising - though understandable from the point of view of performance.

    • Edited by Anton Burger Wednesday, September 4, 2013 3:21 PM
    Wednesday, September 4, 2013 3:21 PM
  • We wouldn't ever temporarily turn auditing off on purpose... it's happening when we import managed solutions.  We have vendors with managed solutions that contain system entities such as Contacts.  When importing their solution, it momentarily turns auditing off on those entities.  The only evidence of this is audit records indicating "Entity Audit Stopped", and of course the loss of all the most  recent "new value" on all audit records.  The interesting (?) parts of this are:

    1. When importing the managed solution, the recommended option to keep all existing customizations is selected.  I would think this would include the audit settings on the entity, but apparently not (sort of... see #2).

    2. As soon as the managed solution is imported, in addition to creating an "Entity Audit Stopped" audit record on relevant entities and wiping out new values, it apparently turns auditing back on, yet there's no record of this (in customizations, the entity still (or once again) indicates auditing is enabled; but on records for that entity, there is no "Entity Audit Enabled" record.   

    So, now it's on to working with the vendors, to dig into their managed solutions and see if there's a way to prevent this!

    Saturday, July 19, 2014 4:07 PM
  • As far as I can see this is not only happening for managed solutions on CRM 2013? We are struck by this and it is very annoying since our users have a hard time interpreting the audit history. 

    It even seems to make the "Entity audit stopped" record twice, every time we import an entity in a solution - even if that solution comes with audit turned on. 

    I've seen it happen on CRM 2013 SP1 UR1 - we applied UR2 on Sunday so it might fix it even though given there are no mention of this in the knowledge base article I doubt it. 

    -- Please vote as helpful / mark as answer where appropriate ;)

    Thursday, March 5, 2015 10:11 AM
  • I opened a case with MS on this awhile back and they conformed its "By Design"
    Thursday, March 5, 2015 10:03 PM
  • Only problem is that the design is flawed... :o

    Vendors that release managed solutions will have the Audit Entity option switched off. Which means every time they include a core entity that has auditing switched on in the customer environment, will always introduce this issue. There needs to be a way to stop the changing of the audit entity option. Maybe they need to switch is on by default, and the customer switches it off if it wasn't on in the first place...

    Ian Carter.

    Here are my links: Twitter Blog LinkedIn

    Friday, January 6, 2017 4:46 PM
  • Just noticed this issue in our system.  I cannot believe MS see this as by design. Importing a vendors solution should NOT turn off auditing in your environment. Additionally, even if auditing needed to be temporarily turned off for a solution import, it most certainly should NOT remove past audit information. This is very important data. 

    At this point I see no need to even have auditing turned on. If every time I import our solution I loose all that important data what the heck is the point to even having auditing. Unbelievable Microsoft.

    Pat B

    Thursday, February 23, 2017 9:55 PM
  • There is a fix to run a sql statement to remove a few records from auditbase. It brings all audits back, but if data changed while auditing was off the history may look odd. If online you can log an MS ticket and they can run the sql for you (they did this for us).

    Ian Carter <p>Click <a href="http://www.m4systems.com">here</a> to go to M4 Systems Ltd.</p> <p>Here are my links: <a href="http://twitter.com/iandavidcarter">Twitter</a> <a href="http://iandavidcarter.blogspot.com"> Blog</a> <a href="http://uk.linkedin.com/pub/ian-carter/26/72/834">LinkedIn</a></p>

    Saturday, February 25, 2017 7:22 PM
  • I am also catching this one in a clients environment. Has anyone heard anything different from Microsoft? or is this still by design? 
    Thursday, August 17, 2017 9:22 PM
  • Hi Everyone,

    Just looked into this issue with a client and we realized that our DEV environment had auditing disabled for Account while in QA it is enabled. So each time we did an import of the solution (which included entity metadata) it would turn off auditing in QA. 

    To prevent this, make sure the entity settings are the same in both environments, or you can import subcomponents without including the entity metadata. 

    Thursday, August 17, 2017 9:44 PM