May 19 2020 02:24 AM
We get the odd alert through for rare office operations that doesn't seem to have any information on the user or mailbox the operation was performed on.
I suspect this may be because the user or mailbox in question has been deactivated but I cannot be sure. We have other logs showing the usernames properly.
Here is a sample of an Add-MailboxPermission command that demonstrates this (data has been scrubbed):
[
{
"Name": "Identity",
"Value": "mailbox the permissions will allow access to"
},
{
"Name": "User",
"Value": "<Organisation Exchange Id>\\$001ABC-D12EF3GH4I56" - this normally shows a username
},
{
"Name": "AccessRights",
"Value": "FullAccess"
},
{
"Name": "InheritanceType",
"Value": "All"
}
]
Does anyone know what this $001ABC-D12EF3GH4I56 parameter is called and how I could map it to an actual user? I cannot seem to find a matching string in Exchange properties.
Jun 10 2020 06:40 AM - edited Jun 10 2020 06:46 AM
I've managed to figure this out. A fresh set of eyes will do you good for any problem.
It's the samaccountname it seems which you can find via Exchange powershell.
Get-Mailbox -Identity username@domain.com | fl
Running this command to search by SamAccountName will output the user. This didn't work for me initially because I was using double quotes but you need to use single quotes to stop the dollar sign from being expanded into a variable https://stackoverflow.com/questions/17452401/escaping-dollar-signs-in-powershell-path-is-not-working
get-mailbox -resultsize unlimited | where-object {$_.SamAccountName -eq '$1ABCD0-EFGH23456'}
I'm thinking now there could be a way to leverage some of the steps in this blog article to automatically link this attribute to a username via Exchange 365.
What you will see as well if you expand the Office Activity logs is that there will often be a similar event logged just before or just after which will have the actual username in it anyway.