Table of Contents
Microsoft Layoffs Remind Microsoft 365 Tenants About the Need to Preserve Ex-Employee Data
This week’s news that Microsoft is trimming 3% of its global workforce brought shock to those affected by the elimination of their position. My LinkedIn feed has been flooded by updates from people who discovered that they’re in a position that they never anticipated, some of whom have been with Microsoft for many years. I’ve been involved in many downsizing actions at Digital Equipment Corporation, Compaq, and HP, and it’s never easy for managers and employees alike. I wish all those affected the best of luck in finding new positions.
The hope of Microsoft management is probably that the layoffs will result in a leaner, more agile organization, the only goodness for the Microsoft 365 community that comes from the episode is that it’s a great reminder for tenant administrators to review the process used to secure ex-employee information following a termination.
Changes in Microsoft 365 Make It More Complex to Preserve Ex-Employee Data
Ten years ago, the task was relatively simple because fewer types of information needed to be secured. Today, new applications and more integration between applications means that the task is more complex.
The basics remain:
- Terminating access to resources by revoking access tokens, disabling accounts, and changing account passwords.
- Physically securing devices (workstations and mobile devices) or remote wipes to remove corporate content.
- Preserving application information such as mailboxes and OneDrive for Business accounts.
Deleting a user account via the Microsoft 365 admin center (Figure 1) takes care of the basics. To do a more comprehensive job, it’s best to script all the steps with PowerShell.

I recommend using inactive mailboxes to retain mailbox content rather than making a regular user mailbox into a shared mailbox, but advantages exist for both approaches. Happily, not much has recently changed with mailbox retention. The situation is completely different with OneDrive for Business in terms of the app reliance on OneDrive and how Microsoft deals with unlicensed OneDrive accounts.
The Key Role Played by OneDrive for Business
OneDrive for Business has become the de facto storage destination for many Microsoft apps, storing files as diverse as Loop components, Teams meeting recordings, and whiteboards. Microsoft’s enthusiasm knows no boundaries when it comes to storing files in OneDrive for Business. Even PowerShell module installations end up in OneDrive for Business if you’re not careful.
Message center notification MC1053121 (last updated 23 April 2025) describes how users who don’t use the Known Folder Move (KFM) feature to redirect common folders like Documents from local disks to OneDrive will be more aggressively “encouraged” to back up files in OneDrive for Business. This change is rolling out to general availability and should be active worldwide by mid-June 2025. If you don’t like users seeing this kind of prompting, consider the new Restrict KFM from Office policy for the Office apps (see MC1053121 for details).
Because OneDrive for Business accounts owned by ex-employees are so important from a retention perspective, it’s important to ensure an alternative site administrator (usually the ex-employee’s manager) is assigned to these accounts so that any useful information in the account is retained. Moving shared objects like Loop components or files shared in Teams chats from the account will break sharing. Eventually, the organization can remove the OneDrive account. If the account remains online, Microsoft will archive the now-unlicensed OneDrive account. Deleting or archiving the account will also break sharing!
The challenges of dealing with OneDrive accounts owned by ex-employees is one of the reasons why it is important to coach users to store corporate information in SharePoint Online instead of keeping files in OneDrive for Business. Unfortunately, that advice is often observed more in theory than practice.
The New Challenge Posed by Flows and Agents
Power Platform flows are often tied to a user account. If the account goes away or is disabled, the flow will stop working. That shouldn’t be a problem if the process performed by the flow is personal to the now-departed employee. On the other hand, if the flow does something that others depend on, that process is now broken and needs to be fixed.
The same applies to agents. It all depends on what an agent does and who uses it. Personal agents will stop running when an account is no longer available to authenticate and that shouldn’t be a problem. But we’re at the early stages of understanding the development, deployment, and management of agents within Microsoft 365 tenants, and care must be taken to ensure that any agents created and maintained by ex-employees remain functional when needed or are disabled and removed if not. This doesn’t happen automatically when an administrator disables or deletes a user account.
Other Issues Requiring Attention
Apart from personal data, there are other issues that might need attention to preserve ex-employee data, including the ownership of:
- Microsoft 365 groups, security groups, and distribution lists.
- Loop workspaces and the associated SharePoint Embedded container.
- Entra ID apps.
- Recurring meetings.
- Phone numbers for use with the Teams Phone system.
The point is that the Microsoft 365 ecosystem continues to evolve. This means that processes and procedures used to manage access to Microsoft 365 resources must evolve in step. This week’s Microsoft layoffs are a regrettable reminder of that fact.
Keep up with the changing world of the Microsoft 365 ecosystem by subscribing to the Office 365 for IT Pros eBook. Monthly updates mean that our subscribers learn about new developments as they happen.
I have developed a PowerShell script that restores user accounts and grants the appropriate access to Mailbox and OneDrive, enables email forwarding, and allows you to specify when the account should be deleted. Once the process is complete, the script logs all related information to a dedicated SharePoint list for restored users. Finally, I have scheduled an Azure Runbook that periodically checks this SharePoint list and deletes user accounts based on the specified deletion date.