Forum Discussion
Different Retention Policies for Active/Inactive Mailboxes
Hey Nikki - thanks for your reply.
The issue I was running into was patience...everything mentioned above is working fine now. After the AD DS "Department" attribute is set then synced to Entra ID, it is properly being detected by the various Adaptive Scopes.
After deleting a user, the "Inactive" retention policy kicks in after a few days. I've tested with 2 different user's now and for both it worked as expected.
Licensing is so difficult to figure out, esp. when working in a black box environment like GCC High, where specific documentation is rarely found. Who knows what license is req. for what functionality; it varies wildly. I've learned to skim the support doc briefly for those purple boxes FIRST, and look for gotchya's with regard to GCC High. I don't know how many times I've been excited to try something in Azure or Office365, only to be let down by a purple box "Not implemented/possible in GCC High".
Don't even get me started with differences in Copilot rollout in GCC/Commercial vs. GCC High. There is absolutely no way to determine what's possible in GCCH/Copilot, without just paying for a license. We did that, and discovered, Agents aren't even possible yet, not to mention all the other neat features that are being marketed. My guess is 2027 at the earliest.
It is important to note that the active user mailbox must be subject to a Purview retention policy with a retention action before the user account is deleted for the mailbox to become inactive. If your offboarding process relies on removing the user license rather than deleting the user account, the mailbox becomes disabled rather than becoming inactive. Therefore, it stays in scope of the active mailboxes IsInactiveMailbox = false. I have written some blog posts about the risks of retaining ex-employee data forever Microsoft 365 Offboarding: Secure OneDrive & Mailbox Data and Ex-Employee OneDrive Retention: Why Data Is Kept Forever