Because a roles permissions may allow them to read the package, but not modify/deploy it, etc. This allows not BL Administrators to use the remediation packages without having to have administrative control over the original package, which may be in use by numerous roles/end users. This also allows you to delete your remediation packages when you are finished, without bothering the original one which may still be in user, etc.
Is it good htat, creating new BL pakcage each time when Complaince job runs & delete them after task completion.
if the job is scheduled for regular execution, so is it good way.
only for restrincting the end users to modify/delete the original BLPackage this functionality is added to BSA.
or any other intetion is there...?
The other reason I see is that the Compliance remediation gives u more control and a remediation blpackage is associated with every individual rule.
At the time of remediation only the rules which fail will be remediated and as such it creates blpackage for all failed rules for each server, this blpackage is created by reading all individual blpackages associated with that rule.
Its not causing any major problem.
But if multiple targets servers found non-compliant, it creates new BLPackages for them.
If we do compliance after a particulae time peroid, it fill the depot with new BLPackages.
using Retention policy & cleanup script we can clear it.
But it doesnt look a better way.
Your Explaination seems very effective & made me understood properly the auto-remediation process.
I also think that, if we give the Read & deploy (not Delete & modify ) authorizations to end users, then why ther eis need to create new BLPackages at runtime.
But you answer clears the things.
if multiple rules get failed, it creates an new BLPackge which is an combined BLPackage of associated BLPackages with failed rules.