Table of Contents
It’s All About the Substrate
I must be slowing down. At least, that’s the thought which ran through my mind as I tried to make sense of Microsoft’s post about SharePoint Online proxy addresses and Exchange Online mailboxes. Specifically, I couldn’t understand this sentence “To ingest SharePoint Online content into a mailbox, we establish SharePoint Online routing information to the mailbox.” This sounds awfully like the way site mailboxes worked, but thankfully those abominations are long gone. And then I realized that the text wasn’t as clear or precise as it could have been, despite discussing an interesting aspect of the Microsoft 365 ecosystem. Here’s what I think Microsoft meant to say.
The Microsoft Substrate and Digital Twins
As anyone who’s listened to Microsoft Fellow Jeffrey Snover talk about the Microsoft 365 substrate knows, the substrate plays a key role in making Microsoft 365 shared services work. The substrate is what captures compliance records for Teams, Planner, and Yammer. It handles the ingestion of audit records generated by multiple workloads. And the substrate creates “digital twins” of SharePoint Online and OneDrive for Business documents and lists. A digital twin is not necessarily a full copy of an item; it’s enough to allow shared processes to operate against the data. If access is required to the complete data, a link redirects to the owning workload.
The substrate does this work because assembling digital twins gathered from across Microsoft 365 workloads into one place makes it much easier for shared services like compliance processing or search to operate. Instead of a service needing to communicate with multiple repositories, it needs to deal with one. And the physical representation of that repository is a special form of Exchange Online mailboxes.
SharePoint Online Proxy Addresses
Which brings me back to the subject of the blog point: the SPO (SharePoint Online) proxy addresses stamped on user mailboxes. If you examine a mailbox, you see the proxy addresses assigned to the mailbox. For example, four proxy addresses exist for this mailbox:
DisplayName : Steve Gippy (Operations)
EmailAddresses : {SPO:SPO_20876de2-3b1c-44ce-8773-34499caaa16c@SPO_a662313f-14fc-43a2-9a7a-d2e27f4f3478,
SIP:steve.gippy@office365itpros.com,
SMTP:Steve.Gippy@office365itpros.com,
smtp:Steve.Gippy@office365itpros.onmicrosoft.com}
One is the primary SMTP address used for email routing (the one with capitalized SMTP), another is a secondary SMTP address belonging to the service domain for the tenant. Then there’s the SIP address used by Teams for calls and meetings. And finally, there’s SPO, the SharePoint Online proxy address, which means nothing to anyone because this address is created and maintained by background Microsoft 365 processes. The address includes a unique identifier for the user and the tenant identifier.
As the post says, administrators should leave the SPO addresses alone as “several internal cloud processes rely on them” not to mention that “Admins should never modify the SharePoint Online proxy address as it is an internal Microsoft service concept.” In other words, keep your greasy hands away from SPO proxy addresses. If you don’t, things break, and you won’t be able to fix them. In fact, you probably won’t know what broke and where it broke.
Without the SharePoint Online proxy address in place, the link between Exchange Online and SharePoint Online is broken, and the substrate can’t ingest digital twins from SharePoint Online into Exchange Online. In other words, the SharePoint Online proxy address stamped on user mailboxes is a connection back to SharePoint Online (and OneDrive for Business).
Hard and Soft Deletes
Now the opening of the post makes sense. It discusses why administrators see mailbox objects they believe are permanently removed (hard deleted) persist in a recoverable (soft deleted) state. After all, if you run the Remove-Mailbox cmdlet and use the PermanentlyDelete switch to tell Exchange Online to erase all trace of a mailbox, you’d like to think that the service would do your bidding.
But because Exchange Online is the foundation for the Microsoft 365 substrate, it has more to do than simply blow away a mailbox. In particular, because the search results generated by Microsoft search depend on mailbox content, some adjustment is necessary to reflect a mailbox deletion. That’s why Exchange Online signals SharePoint Online so that background processing can adjust the search results shown to users. While this processing proceeds, it’s possible to see erroneous results featuring a deleted user, but eventually processing completes and search is 100% accurate again.
Exchange Online keeps the mailbox in a soft-deleted state until the deleted mailbox retention period expires (183 days). By then, background processes have adjusted indexes and SharePoint Online is content. Exchange Online can then tidy up by hard-deleting the mailbox, unless of course it’s under the control of a retention hold (litigation hold or otherwise), in which case the mailbox is inactive and kept until all retention holds expire.
Life is More Complicated in the Cloud
All of this proves that cloud objects lead a more complicated existence than on-premises objects. The Microsoft 365 substrate connects objects together in a way that simply doesn’t exist on-premises, so when you remove an object, it might just have an effect elsewhere that must be dealt with. Which is why some mailboxes that you might want to hard delete have to stay soft-deleted until background processes can adjust connections.
Insight like this doesn’t come easily. You’ve got to know the technology and understand how to look behind the scenes. Benefit from the knowledge and experience of the Office 365 for IT Pros team by subscribing to the best eBook covering Office 365 and the wider Microsoft 365 ecosystem.