Where’s My SharePoint Site? Ask the `AAD to SharePoint Sync` User

Today one of my clients had a problem. One of her SharePoint sites was missing. She found it in Deleted sites in the SharePoint Admin Center. Restoring the site from the Deleted sites is an easy fix, of course: she had already done that on her own. But none of the Site Owners or Site Members could access the site. This was why she had pinged me.

But why had the site been deleted? As a Global Admin in a very small organization, she felt should have known why this had happened.

Analysis

We thought about what the causes might be, and these were data points about the site which made it a little different than most of their sites.

• She thought she may have set up a policy when she created it – but we couldn’t find one.
• There were guest users who had sharing links for 30 days which had just expired – but that shouldn’t have caused any change in the state of the site.

We turned to the Audit Log in the Compliance Portal Microsoft Purview Compliance Portal to see whodunnit. Many people don’t think of using the Audit Log for things like this, but it’s a great way to pin something on the perpetrator figure out what happened. Unfortunately, usually the people who have access to the Microsoft Purview Compliance Portal are tough to find in a large organization. Here, it was easy.

We set the start date to the date when the last modification had been made in the site, as seen in the Active sites listing, and we set the activity to search for Deleted site in the Site administration activities. (The audit log gives us a lot of granular settings.)

About 10 minutes later – these requests run in the background – we had an answer, of sorts. Like many things, the output is a little unintelligible in Excel (you get a CSV file), so I popped the JSON payload into Visual Studio code and formatted it.

So, what gives? We see that the user who deleted the site is AAD to SharePoint Sync. (Oops – another example of Microsoft’s penchant for renaming things leaving unintelligible messages! No more AAD; Azure Active Directory [AAD] is now Entra ID. Is that EI?) There’s no “user” with that name, of course. The name implies some automated process deleted the site. AAD/EI “owns” Microsoft 365 Groups, so it had to be something with the underlying Group.

Solution

When my client realized what date and time the site was deleted, she said “Hmmm…” She had deleted the Microsoft Team associated with the site in question last week. Bingo! I explained how the Team is connected to a Microsoft 365 Group which is connected to the SharePoint site (plus any other apps or services provisioned for the Group – like Planner). She had known this at one point, but in the heat of cleaning up the place…

But what about the permissions issue on the restored site? Well, while we were figuring all this out, one of her team members (a Member of the Microsoft 365 Group) was able to get into the site. As with many things in the Microsoft 365 platform, sometimes you have to wait a little while. In this case, the background percolation to reinstate the underlying Microsoft 365 Group’s permissions took a while.

Finally, back to normal – and we knew what had happened!

Learnings

The big thing I learned here was about the mysterious AAD to SharePoint Sync “user”. If you see that user doing something, know that it’s probably due to a change made to a Microsoft 365 Group rippling out into the other Microsoft 365 apps and services. Of course, but the time I need this bit of knowledge again, that not user will probably be named something else. EI to SharePoint Sync, maybe?