Effect of system setting (share reassigned records with original owner) on POA table?

(0) Share

Report

Posted on by fb88

Hello,

If I disabled the setting shown in the image below to "No" after it was "Yes", will the records that were created in PrincipalObjectAccess due to it being turned on get deleted or updated? If so, when? If not, how do I force this to happen?

*This post is locked for comments

I have the same question (0)

All responses (9)

Answers (2)

Verified answer

a33ik 84,331 Most Valuable Professional on at

Like (1)

Report

Hello,

I believe it would not remove created records. To make it to work that way you will have to do that manually or write code that will do that.

Was this reply helpful? Yes No
Verified answer

ashlega 34,477 on at

Like (1)

Report

Hi, this won't change anything for the existing shares. As far as I know, you'll have to unshare manually for each of the records

Was this reply helpful? Yes No
fb88 on at

Like (0)

Report

I tested a RevokeAccessRequest request on one of the records and it changed the AccessRightsMask value to 0, but did not affect the InheritedAccessRightsMask value. Which I assume means this record will continue to persist and will never be cleaned up, I read that if AccessRightsMask and InheritedAccessRightsMask are 0, they will be purged after 90 days by the deletion service, not sure if that is true. It is not clear how I determine what is influencing the InheritedAccessRightsMask value so that it can also be set to 0.

Basically we have a security model where sharing most records is never required and I'm trying to determine the best ways to change relationships and settings to stop more records being auto-shared in these tables and then also clean up the records that have already been created. The environment has about 4 million records in the POA table.

Was this reply helpful? Yes No
ashlega 34,477 on at

Like (0)

Report

Well.. if you have access to the server, and it sounds like you do.. just go to the database and delete all those sharing entries from the POA table where a record is shared with a user(not a team) who is not an owner.. Take a backup first..

Was this reply helpful? Yes No
ashlega 34,477 on at

Like (0)

Report

Even Microsoft is offering it as a workaround (for 2011 version, but anyway), so it's probably not going to break anything:

support.microsoft.com/.../how-to-control-principalobjectaccess-table-growth-in-microsoft-dynamics-crm-2011

Was this reply helpful? Yes No
fb88 on at

Like (0)

Report

Alex, the article you referred to at this link is a script that deletes records from the POA table when the corresponding object is not present in the base table. That scenario is different than mine, my records still exist in the base tables, I just don't want them shared as the overhead of more records in the POA table is known to impact performance. I'm going through a project where I am trying to clean up as much as I can in CRM and this area was one that I identified as not being optimal.

I'm not opposed to deleting records via SQL but I don't consider the Microsoft script as evidence that doing this is okay since they are addressing a different scenario. For all I know, deleting records where the base object exists under specific relationship configurations could cause new errors. If there is a more authoritative source on the impact/strategies for removing records in this table, I'd be interested in finding that source, it may not exist outside of Microsoft support I suspect.

Was this reply helpful? Yes No
ashlega 34,477 on at

Like (0)

Report

I understand it's a different scenario, I'm simply giving it as an example of how you can manipulate POA on the SQL side (and, also, to prove that those manipulations are not, necessarily, that dangerous)

Other than that, totally agree. That's why "take a backup first":)

Was this reply helpful? Yes No
fb88 on at

Like (0)

Report

Alex, I appreciate your input! It is annoying to me that a table affecting performance can grow to millions of records with no real mechanic for the administrator to manage them in scenarios such as mine, where previous settings/configurations created records that are no longer needed.

Was this reply helpful? Yes No
Suggested answer

Community Member on at

Like (0)

Report

Few comments for your considerations:

1. Never do anything via SQL to delete the POA table unless you are confident. You have to treat this as online environment therefore you don't have the privilege to do this.

2. Divide and conquer. There is no quick way to unshare the records in a quick way. You can do a simple fetchxml by using some tools to identify those records and maybe create a simple program to unshare by using batchrequest. (Or manually if the # of records are minimal)

3. POA table growing too fast is a known fact for almost every CRM implementations, you can perform a SQL indexing for POA table to boost the performance radically and think of housekeeping strategy next.

Was this reply helpful? Yes No