Overview
This article explains how Druva handles the preservation of Microsoft 365 (Azure AD) user accounts when they are disabled or deleted in Azure AD. Unlike Google Workspace provisioning, Druva for Microsoft 365 automatically marks disabled users as "preserved" without a configurable setting to alter this behavior.
This document assumes you have already configured User Provisioning using Azure Active Directory in Druva, as outlined in the following article: https://help.druva.com/en/articles/8367980-user-provisioning-using-azure-directory-ad
How Druva Handles Disabled/Deleted Azure AD Users: Automatic Preservation
When a user account is disabled in your Azure Active Directory, Druva automatically detects this change during its regular synchronization with Azure AD. Instead of immediately deactivating or deleting the user's backup data in Druva, the user is marked as "preserved."
Key Characteristics of Preserved Azure AD Users in Druva:
Automatic Action: This preservation process is the default and non-configurable behavior for Microsoft 365 (Azure AD) integrated tenants in Druva. There is no setting within the Druva console to modify this auto-preservation behavior, unlike the 'Edit Auto-preserve settings' available for Google Workspace.
Data Retention: Data backed up for a preserved user is retained according to your Druva retention policies. This ensures that data associated with former employees or inactive accounts is not immediately purged, allowing for potential future recovery if needed.
License Consumption: Preserved users may continue to consume a Druva license, depending on your Druva licensing model. It's important to review your Druva licensing to understand the implications of preserved users on your license count.
No Option to Modify: Currently, Druva does not offer an option to change this automatic preservation behavior for Microsoft 365 (Azure AD) users. When a user is disabled in Azure AD, they will be automatically marked as preserved in Druva.
Why is it the Default Behavior for Azure AD?
Unlike Google Workspace, Azure AD's user lifecycle management and deletion processes do not inherently provide a direct mechanism for applications like Druva to easily distinguish between a temporary suspension and a permanent deletion with configurable recovery options at the application level. To ensure data safety and potential recovery, Druva's default behavior is to preserve the data of disabled Azure AD users.
Managing Preserved Users:
While the auto-preservation is automatic and not configurable, you can still manage preserved users within the Druva console. This typically involves actions such as:
Reviewing Preserved Users: Identifying users marked as "preserved" in the Druva user list.
Manual Deletion (with caution): If you are certain that the data of a preserved user is no longer needed and should be permanently deleted (keeping in mind your retention policies), you may have the option to manually delete the user from Druva. This action is irreversible and will result in the deletion of their backed-up data after the retention period. Exercise extreme caution when performing manual deletions.
Deactivating Users in Druva: While the user is automatically preserved upon being disabled in Azure AD, you might have a separate status within Druva to further manage these preserved users. Refer to Druva's user management documentation for details.
In Summary:
For Microsoft 365 (Azure AD) user accounts managed by Druva, the preservation of data for disabled users is an automatic and non-configurable process. When a user is disabled in Azure AD, Druva will mark them as "preserved" to ensure data retention according to your policies. There is no equivalent to the 'Edit Auto-preserve settings' found in the Google Workspace provisioning settings.
Key Differences Highlighted for the User:
No Configurable Setting: Explicitly state that unlike Google, there's no setting to change the auto-preserve behavior for Azure AD.
Default Behavior: Emphasize that automatic preservation is the default and only way Druva handles disabled Azure AD users.
Reasoning (Implied): Briefly touch upon the differences in Azure AD's user management compared to Google Workspace as a potential reason for this default behavior.