Playing with System mailboxes in Exchange Online

Being the curious type, I often probe different parts of the service and sometimes stumble into some interesting discovery. More often than not, it’s just some random stuff I notice while doing a quick test in order to make sure I give a proper answer to someone asking a question on the different communities. For this particular case, it all started with me trying to explain which objects types you can use to delegate permissions in Exchange Online.

For those of you that don’t know it yet, the Get-SecurityPrincipal cmdlet is one of the hidden gems in Exchange – rarely used, but very useful in answering that specific question. It’s fairly straightforward to use and has some convenient parameters, but the most interesting portion of is the output. Here’s an example:

Get-SecurityPrincipal | select Name,Type,RecipientTypeDetails

Name                                                          Type  RecipientTypeDetails
----                                                          ----  --------------------
DiscoverySearchMailbox{D919BA05-46A6-415f-80AD-7E09334BB852}  User  DiscoveryMailbox
vasil                                                         User  UserMailbox
Public Mailbox #1                                             User  PublicFolderMailbox
WC                                                            User  UserMailbox

OK, I’m cheating a bit here and trimmed some of the output to hold the suspense. But as you can see from the above, using the Get-SecurityPrincipal cmdlet will give you a nice list of all the objects you can use for delegation, so maybe give it a try?

Anyway, if you look at the full output of the cmdlet, you will notice some interesting entries. First of all, the WellknownSecurityPrincipal objects will be returned in the default, unfiltered output, and yes, they can be used to assign permissions as I’ve described here. For this particular article however, they are not important, so lets just ignore them. And lets do the same for all “boring” objects as well – filter them out. Here’s the full list of “User” object recipient types returned by the cmdlet:

Get-SecurityPrincipal -Types User | Group RecipientTypeDetails | select Name | sort


Striping the familiar ones, we are left with AuxAuditLogMailbox, ArbitrationMailbox, and AuditLogMailbox. So what’s so interesting about those you ask? The simple fact that they are considered “system” mailboxes, and we are not allowed to look at them in the service. For example, if you try to use the good old Get-Recipient cmdlet against any of those, you will get a nice error message like this one:

Get-Recipient -RecipientTypeDetails AuxAuditLogMailbox,ArbitrationMailbox,AuditLogMailbox
Cannot bind parameter 'RecipientTypeDetails' to the target. Exception setting "RecipientTypeDetails": "The following specified values aren't supported by this cmdlet: 'AuxAuditLogMailbox', 'ArbitrationMailbox', 'AuditLogMailbox'.

Well, seems out the devs simply forgot to apply the same rules against the Get-SecurityPrincipal cmdlet, so we can (ab)use it to get a list of those interesting objects:

Get-SecurityPrincipal -Filter {RecipientTypeDetails -eq "AuxAuditLogMailbox,ArbitrationMailbox,AuditLogMailbox"} | select Name,Type,RecipientTypeDetails

Name                                                         Type RecipientTypeDetails
----                                                         ---- --------------------
SystemMailbox{bb558c35-97f1-4cb9-8ff7-d53741dc928c}          User ArbitrationMailbox
SPO_Arbitration_f5c4804b-2cad-4f9a-9882-c6c68fc5859a         User ArbitrationMailbox
FederatedEmail.4c1f4d8b-8179-4148-93bf-00a95fa1e042          User ArbitrationMailbox
SystemMailbox{e0dc1c29-89c3-4034-b678-e6c29d823ed9}          User ArbitrationMailbox
Migration.8f3e7716-2011-43e4-96b1-aba62d229136               User ArbitrationMailbox
SystemMailbox{D0E409A0-AF9B-4720-92FE-AAC869B0D201}          User ArbitrationMailbox
SystemMailbox{2CE34405-31BE-455D-89D7-A7C7DA7A0DAA}          User ArbitrationMailbox
AggregateGroupMailbox.A.201708152125                         User ArbitrationMailbox
Loki_Hashtags_394866fc-eedb-4f01-8536-3ff84b16be2a           User ArbitrationMailbox
Weve-7afd44ee-758f-483c-993d-4f779f219ebe                    User ArbitrationMailbox
OrgExtensionProperties0_ED5B1323-0DC1-43D3-96C7-0049903548CF User ArbitrationMailbox
AuxAuditMailbox157c8858-e89c-4a2d-8d3d-3fdf9ff066fc          User AuxAuditLogMailbox
AuxAuditMailbox68a1604b-663c-47ae-983d-8d1aa2740074          User AuxAuditLogMailbox
SystemMailbox{8cc370d3-822a-4ab8-a926-bb94bd0641a9}          User AuditLogMailbox

The list above is again trimmed, but you can still see a rich variety of objects. Based on their recipient type or Name, you can make some assumptions on their purpose, and for some of those you can find some information available online, although Microsoft has not published a full list afaik.

Here’s the best part – although those objects are “hidden” from the *-Mailbox cmdlets, some other cmdlets will still happily accept output. So, if you were bored enough, you could do something like this:

Get-MailboxPermission "SystemMailbox{8cc370d3-822a-4ab8-a926-bb94bd0641a9}" -User vasil

Identity             User                 AccessRights
--------             ----                 ------------
SystemMailbox{8cc...    {FullAccess}

And even this:

Yes, those are automapped to my mailbox and added to Outlook. No, there’s not much you can do with it. But it opens the possibility to play around with it in MFCMAPI and such, if you are interested.

Some other cmdlets will also work just fine with those “hidden” mailboxes, so for example you can get the mailbox- or folder-level stats, toy with permissions, etc. None of this is supported though, in any way or form, so if you manage to mess things up, you are on your own. Have fun 🙂

This entry was posted in Exchange Online, Office 365. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *