Retention: Resolve Email Archive and Deletion Issues When Using Retention Policies

By Ashwin Venugopal -

 





Common Causes:

There are several reasons why MRM might not process a mailbox as expected. For example- 
  • Retention hold is applied to the mailbox . In other words, the mailbox's RetentionHoldEnabled fieldis set to True. For instance, the PST Import service is used to transfer the mailbox. 

  • The ElcProcessingDisabled attribute of the mailbox is configured to True. This configuration stops the MFA from processing the mailbox completely.

  • The mailbox has been applied retention tag, but that tag is presently disabled. As a result, messages in the mailbox will not be achieved or removed at any time.

  • The mailbox awaiting processing is sizeable and holds numerous items. This may result in MFA archiving or removing content at a reduced speed. 

  • The retention policy assigned to the mailbox consists solely of personal tags. If the user fails to apply these tags manually, MRM may not manage the mailbox. 

Troubleshooting

Check the RetentionHoldEnabled Property of the Mailbox

Use the Get-Mailbox cmdlet to retrieve the RetentionHold Enabled  property of the mailbox. If the property is set to True, set it to False. 

Check the ElcProcessingDisabled property of the Mailbox

Use the Get-Mailbox cmdlet to retrieve the ElcProcessingDisabled property of the mailbox. If the property is set to True, set it to False. 

Review the Retention Policies and Tags that are applied to the Mailbox

Use the Get-RetentionPolicyTag, Get-RetentionPolicy, and Get-Mailbox cmdlets to check retention policies and tags that are assigned to the affected mailbox. 

Be mindful of retention tags that are turned off or configured to never archive or delete. The time period linked to a tag plays a crucial role in defining its priority. As a result, look for tags with the longest duration, like never move to archive or never delete, since these tags prioritize over others that are assigned. 

Check for Default Archive and Default Retention on the Mailbox

Check whether a Default Archive or Default Retention policy tag is applied to the mailbox. If it is, make sure that-

  • No personal archive or retention labels have been assigned to folders that are set to never move to archive or never delete. 

  • No archive or retention tags, whether disabled or default, have been applied to the entire mailbox. 

  • The Default Archive tag, along with any other applied policy tags, can be found in the list of retention policy tags within the PR_ROAMING_XMLSTREAM property. If a tag is absent, remove the IPM.Configuration.MRM message that contains the PR_ROAMING_XMLSTREAM property and execute the Start_ManagedFolderAssistant cmdlet with the -FullCrawl switch for the mailbox that is affected. This process recreates the hidden IPM.Configuration.MRM message and refreshes the PR_ROAMING_XMLSTREAM with the updated policy tag.

Check for Personal Tags applied to folders or individual items

If you are dealing with a Default Archive policy that applies to the entire mailbox, you won't see any archive policy properties like:

  1. PR_ARCHIVE_TAG
  2. PR_ARCHIVE_PERIOD
  3. PR_ARCHIVE-DATE
  4. PR_POLICY_TAG
  5. PR_RETENTION_DATE

These properties are visible only if a personal archive tag, default folder retention tag, or personal retention tag is applied. 

Check the MRM diagnostic logs

To collect the MRM diagnostic log, run the following PowerShell command:

Export-MailboxDiagnosticLogs <mailboxID> -ComponentName MRM

Examine the log to find out if any errors took place during the MFA processing of mailbox. Look at the date of the most recent error to assess its significance to the ongoing issue. 

If you are able to find any logs and encounter an error message stating "no logs were found," it indicates the MRM successfully processed the mailbox without encountering any errors. 

Best Practices

It is advisable to activate the archive mailbox for an account right after placing it on Litigation Hold. This is particularly important when the user has significant email activity. Enabling this feature can help avoid the Recoverable Items folder from reaching its capacity and will allow users to keep deleting items from their primary mailbox. Furthermore, it is recommended to turn on auto-expanding archiving, depending on the user's Microsoft 365 license. 

Note- Be aware that the Recoverable Items folder in the primary mailbox should not hit the maximum quota, as this may also hinder MRM from transferring items into the archive. 

Conclusion

Email Archive and Deletion issues that might occur while using Retention Policies are resolved. 






Comments

Post a Comment

Popular posts from this blog

Deployment (Part 3)

By Ashwin Venugopal -
Image
  To read part 1, please click  here To read part 2, please click  here Microsoft Monitoring Agent (MMA) MMA is used across multiple Microsoft solutions and has undergone a few name changes as its features and functionality have evolved. If it is being considered to be used, then following areas should be covered during a Microsoft Sentinel deployment project: Consider the timelines and the strategy for a migration to AMA (Azure Monitor Agent) before the MMA end-of-life.  Consider the central deployment and management methodology for MMA. Determine which endpoints are in scope for deployment as these affect the log ingestion volume significantly.  Azure Monitor Agent (AMA) Organizations with MMA as the main Microsoft Sentinel agent should start planning the migration to AMA as soon as possible to avoid a rushed migration. One of the main advantages of AMA is the ability to control the log collection policy centrally and apply different policies against different...
Read more

Deployment (Part 1)

By Ashwin Venugopal -
Image
  To read part 2, please click  here To read part 3, please click  here Azure Resources Microsoft Sentinel needs following resources to be created: Subscription (if a dedicated subscription(s) will be used) Resource group(s) Log Analytics workspace(s) Automation rules/playbook Alert rules Workbooks Microsoft Sentinel offers hundreds of alert rules, workbooks, and automation playbook templates along with hunting scripts. The templates can be used to activate/deploy schedule alerts, create customized dashboards, create automation playbooks and perform threat-hunting activities. Generally, once deployed, the resources created have to be adjusted to match the existing environment, configure local credentials, etc. Methods of deployment: Manual- Administrator can manually configures the Microsoft Sentinel resources with the help of Azure portal. Any manual process has the inherent risks of human operator error, lack of compliance with potential change control procedures, and u...
Read more

Design Planning (Part 3)

By Ashwin Venugopal -
Image
  To read part 1, please click  here To read part 2, please click  here Complex Organizational Structures SIEM can be an expensive security control, hence, it is common multiple businesses to contribute to the overall expense. Various organizational units may require a level of access to specific dashboards or sets of data. Microsoft Sentinel offers the ability to assign table-level permissions and limit the level of access to the minimum required to perform requisite job functions.  Role-based Access Control (RBAC) Requirements Microsoft Sentinel offers an extensive list of Azure built-in roles that can be used to provide granular access according to the job requirements and permitted level of access. Some of them are various Microsoft Sentinel dedicated roles: Microsoft Sentinel Contributor- Can perform all engineering-related configuration, such as creating alert rules, configuring data connectors, and additional similar tasks.  Microsoft Sentinel Reader- Can...
Read more