 Jasper says we encountered a strange issue whereby a SharePoint site was deleted by a user called AAD to SharePoint sync. We discovered this through the audit log in the Compliance Center. Anyone else ever had this issue knows what the user is? Yeah. I would love to take this. This one's interesting because there was an anomaly that occurred probably a few years ago now. It is a user or system account that's related to group expiration, and when the group expires, then this account goes ahead and does that cleanup. There's been some anomalies that were really related to when a SharePoint site didn't have a group associated, or the sync process of the team was deleted but the site was not cleaned up. I haven't seen it for a long time, so I think it's really interesting. I would go ahead and take a look at your expiration policies, review them, and hopefully that helps. But that is the Azure AAD, so AAD to SharePoint sync is the name of the service account that does all that cleanup. Sounds like it really affects kind of like orphaned objects, right? Yeah. Something isn't cleaned up, right, or something's left behind, and it's got no parent, and it doesn't know what to attach itself to. This took care of it, yeah. Well, and think about, if you set your expiration, you're getting reminders 30 days, 15 days, and one day, and so maybe right on that 15th day, you renew or you do some sort of activity that wasn't the same sync process of when the communication was going to come out or the expiration was going to occur. It was just a miss and that's really all it is. I think what I would just recommend here is to be reviewing to make sure that your expiration policies are the way you want them. But then to go in and take a look at your teams, go in the teams, admin center, review, maybe go in the audit logs, make sure everything's getting cleaned up appropriately. Can I add here that I think this is one of the strong justifications for some of the third party tools that are out there that do a really good job at making sure orphaned objects, orphan sites as you're going and moving and deleting and cleaning up that you're not missing any of these pieces. Again, depending on your price point, there's all different tools that are out there, but I think this is a pretty uniform capability and value add for those tools. Let me ask a question to this then. Is there and I don't know, I'm not a SharePoint person. Everybody knows what? Listen to this and not a SharePoint person. He's a Yammer guy, everybody. That's his life, lives for it. That ain't happening. Anyways, so does SharePoint, when you do this, if you were going to delete an object if something happened like that, does it ever recycle bin? Can you bring that site back? So you can bring back the site and everything that links to that site. I mean, is that all? But now here's the caveat. If it's a group site, right? That means when you create a modern SharePoint site, it associates itself to an M365 group. And now let's say you delete the M365 group. Essentially, the site will then be deleted. But if you restore then that site, which I'm not even sure if that's even possible, but let's just say we can, there'd be no group associated to it. So therefore, as the retention or the exploration policy is trying to delete something, it can't delete something without having an M365 group object assigned to it. Okay, would that follow also with teams? So because teams, he creates this SharePoint site, right? So if you got rid of the team, that site still is out there somewhere? It should be cleaned up, right? It should be cleaned up. It sometimes just, when you think of an M365 group, it will, wherever you're creating it from, by the way. So let's just pretend we're gonna create it in teams. So we're creating the group. We all think of it as creating a Microsoft team, but it is spinning up an exchange shared mailbox. It is spinning up a SharePoint site. It's spinning up a plan or plan depending on if you're using, well, I think under the circumstances of a team, it's creating a plan for you. So it's creating all these services, deleting them first over here shouldn't really affect the team itself. However, I think that's where some of these anomalies may happen if we have the expiration that's actually directed on the team. And then all the other things have obviously a natural path like we delete this service along with this service and then next this service. So all of that just needs to be really clean when it happens. And if there is some nuances, then of course that's where you get some of those orphan things. Yeah. Do you know, Michelle, if I was just thinking of the teamifying existing, so before moving over into Office 365, they're over to it now, Microsoft 365, moving over, you had SharePoint sites that could later on be teamified. So had the other components. And so in that scenario, just logically, I'm just thinking, well, that could cause some other wrinkles so that if you then delete the team that you connected it to, that does that react any different? Should it clean up the same way with those sites, even though it existed before the team existed? Could that be another way? I believe when you teamify it, you're then adding the M365 group construct. However, it's always do your due diligence going back into the SharePoint permissions to see if an actual SharePoint permission model still exists. And when I say that, what I mean by that is your owners, your members, and your viewers, those out of the box kind of classic SharePoint permissions that before you teamified it were created. Yeah, cool.