Introduction
In the automation world, organizations are increasingly relying on Microsoft 365 for their email infrastructure. In this era of automation, it is very crucial to automate email management. Recently, I encountered an issue while developing a PowerShell script for email backup for the given users' OneDrive. The script involves deleting attachments from the mailbox, restoring them, and adding links to the mailbox with a folder URL to redirect to the actual attachment storage location. This script turned from simple automation to a deep dive into Microsoft Graph api concurrency handling.
In this blog, we will explore the reasons behind the concurrency issue and why PowerShell cmdlets fail, while the Graph REST API succeeds.
Script goal
Ask the user to select user type, comma-separated or all users.
Then ask the user for the date range between emails received.
Ask the user for the folder name from Outlook.
After these questions the script runs and does below tasks.
Check all emails for any attachments, such as images, PDFs, zips, and more.
If there is, it uploads those attachments to the user’s OneDrive in a timestamp-titled folder, also storing the mail URL in that folder to access the mail from OneDrive easily.
Then, it updates each email with its attachment links, which are stored in OneDrive, and also adds a folder link to redirect.
Then delete those attachments from the mail.
That’s it, this was the challenge that I was achieving. Script runs fine, but sometimes it gives me errors like shown in the image below.
![Powershell]()
I found a lot, then I got some fixes, and now I'm going to share them with you.
Using the PowerShell cmdlet Remove-MgUserMessageAttachment generates ETag and concurrency conflicts.
Let’s understand ETag and concurrency.
The send or update operation could not be performed because the change key passed in the request does not match the current change key for the item., Cannot save changes made to an item to store. SaveStatus:
The above error statement says about the key.
ETag (Entity Tag): It is one type of versioning mechanism that REST API uses to handle concurrent modifications, as shown below, for example.
When you fetch a message, it comes with an ETag, similar to a version number.
When you modify that message, the ETag changes.
Any further operation must use the current ETag, which frequently changes.
When you try to get the old ETag, you get this error with Status 412.
Below is the command that was causing the issue.