of the
tl;dr
To avoid overwriting some of the system entities flags for the customers, manually remove those flags from the managed solution files. WARNING! Super-duper unsupported.
Some juicy details
If you are a Dynamics CRM ISV or an infrastructure group within a large enterprise then, most likely, you distribute one or more managed solutions to your customers (external or internal). (If you are not ISV or infrastructure developer, what are you doing with managed solutions?)
Some of these solutions may include system entities such as accounts, contacts, etc. If they do then at some point in the past you received a call/email from a disgruntled customer:
You #@$&^%! solution switched audit for the accounts off!
If you have foreseen this and enabled audit on system entities in your solution then at some point in the past you received a call/email from an even more disgruntled customer:
You #@$&^%! solution switched audit for the accounts on and, since we were not aware, it blew up our data storage allowance!
What can I say? I know! (╯°□°）╯︵ ┻━┻
Breathe [in|out]
All you want to do is to leave those pesky flags out of your solution, right? And you are prepared to sell your developer’s soul (what’s left of it) and go unsupported, right? Keep reading then.
- Export your managed solution file as you normally would
- Extract customizations.xml file
- Open it in your favorite editor, find and delete the elements <IsAuditEnabled> for audit and <IsDuplicateCheckSupported> for duplicate detection
- Save, copy back into the solution zip file
- Test, test, and then test again
- Send it to your customers and keep the fingers crossed
Until Dynamics CRM delivers an ability for a developer to choose what flags and features to package within their solution, removing the elements seems to be the only way to ensure that your solution does not trample the existing settings.
Feel free to experiment with the other flags, but usually they are more or less innocuous.
Well, I wonder if this only works in more recent versions (CRM 2013/2015), because it does not work well in CRM 2011, evidenced by recent experience with an ISV solution that did not have the Audit attribute.
During import, the Audit was still stopped on all related entities, although it was still checked on the entities. To resolve I reset on the entity form.
Haven’t tested on CRM 2011, perhaps you’re right. I’d say, if aiming 2011, set Audit to on for the system entities and document it for the customers. Worst case scenario – they’d need to switch it off and delete the audit created. This is better than losing audit.