jason.brownhill
My feedback
3 results found
-
2 votes
An error occurred while saving the comment jason.brownhill
supported this idea
·
-
10 votes
An error occurred while saving the comment jason.brownhill
commented
Any update on this at all? It's kind of desperately needed!
jason.brownhill
supported this idea
·
An error occurred while saving the comment jason.brownhill
commented
For me this is critically important as both of my clients use retention policies to secure content. Beyond this content retained by other policies such as labelling is likely to have the same effect - the sites cannot be easily archived and result in a manual process ultimately to go through the failed archives and re-archive the groups - doubling up on the retained archives as it is not possible currently to determine failed archives in the Azure blob storage, to those that were successful.
Coupled to this we have seen evidence where retention policies are applied inconsistently across two policies, resulting in the GROUP being deleted by the user decision to archive a Group connected site, but the SharePoint site remaining. This has happened I believe due to some kind of policy precedence - though I have no evidence to back this up - the result is I have over 400 sites that are now 'Ghosted' and I'm having to work with Microsoft to resolve this issue - which is rather problematic. So this is the scenario:
Policy A has a retention policy to protect SharePoint workloads
Policy B has a retention policy to protect SharePoint AND Groups workloadsWhat I believe is that due to one policy not retaining Groups, the SG:Apricot application has been able to delete the Group from working through the Policy A, but then blocked on the SharePoint workload protection for Policy A and Policy B. Again, I have no proof that this is happening other than the fact that I have had over 400 groups/sites that are exhibiting issues that their Group connection has been removed and is ghosted in the tenant. In fact, I am able reproduce this issue quite easily, but able to recover the group to correctly archive the group/site using SG:A.
How would I perceive this working in the future? Some kind of interaction with PowerAutomate with a notification to manually (or automatically) execute the exclusion of a site from all retention policies. I dont know if its possible to do this in conjunction with PowerAutomate, or just simply build the notification/approval process into the SG:A chat bot so that it 'Talks' to an SG:A Administrator Teams channel or something? The application should be able to detect that a retention policy is holding onto the Group, Teams AND SharePoint workloads before archiving, otherwise this application and it's ability for end user decisions to archive a Teams/Groups is pretty much redundant to us. To that point and due to the 400~ sites that are currently sitting in a ghosted state without the Groups available, we have turned off the user decisioning to archive sites. This is critically difficult for one of my clients where we are going through a storage remediation exercise and have less than 5Tb of space to play with that cannot be extended. So time is of the essence for us and we are having to manually manage this data and archive it where identified.
Many Thanks,
Jason. -
3 votesjason.brownhill
shared this idea
·
This is critically important to me also as currently we're migrating classic sites to modern sites and the source content has labels applied to retain data from the moment they were labelled - ie: since the point they were copied to the preservation hold library - which in our instance is not required. Currently have spent many hours with Microsoft over the past month to try and fix this with no sight of a resolution. The labels are auto applied and no way of editing them - the destination site isn't even within the label policy or ever was, so its not like I can remove the site from the policy to release the label from the content. very very painful.