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 Name ---- MailUser TeamMailbox SharedMailbox AuxAuditLogMailbox SchedulingMailbox SupervisoryReviewPolicyMailbox GuestMailUser RoomMailbox DiscoveryMailbox MailboxPlan ArbitrationMailbox UserMailbox User AuditLogMailbox PublicFolderMailbox
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... vasil@michev.info {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 🙂
Another Excellent article Vasil. Now i am able to find all the hidden supervision mailboxes.
Thanks,
Robert