I have these Azure Automation Runbooks that do a bunch of stuff with Exchange Online groups. One of those tasks is to add members to a group, following by enabling auditing. Like this:
|
1 2 3 4 5 6 7 8 |
try { Add-DistributionGroupMember -Identity "$dstGroupName" -Member "$member" -Confirm:$false -BypassSecurityGroupManagerCheck -ErrorAction Stop } catch { # Do stuff } # Also enable auditing due to the bug; see https://office365itpros.com/2022/08/25/mailbox-audit-events-more-problems/ Set-Mailbox -Identity "$member" -AuditEnabled $true -ErrorAction SilentlyContinue | Out-Null |
I don’t particularly care about the second cmdlet as I run it in other Runbooks too. It’s just one of those things I want to run but don’t really care about it succeeding. Hence the absence of a try/ catch and also me setting -ErrorAction to SilentlyContinue.
Now, as is often the case I set all this up and promptly forgot about it. But last week, when troubleshooting something, I noticed that I was consistently getting warnings like these:
|
1 |
WARNING: The command completed successfully but no settings of 'FirstName LastName' have been modified. |
Weird. It sounded like it was adding members to the group even though they were already members? A quick Google too gave the impression this was when someone was being re-added to a group. I didn’t have the cycles to investigate it further so left it for today (the weekend).
Today I checked the AAD audit logs and noticed that no I wasn’t re-adding the user to the group, they weren’t there to begin with. Moreover, if I run the Add-DistributionGroupMember cmdlet to re-add I get a different error:
|
1 |
Add-DistributionGroupMember: Ex93E602|Microsoft.Exchange.Management.Tasks.MemberAlreadyExistsException|The recipient "email@address.com" is already a member of the group "GroupName". |
Hmm. Digging around my script I then found the Set-Mailbox cmdlet. Re-ran it, and sure enough I get the warning error message. So that’s the cmdlet which was generating it. I had assumed (stupid me!) that since I set -ErrorAction SilentlyContinue that would take care of any warning messages too, but of course I should have known better! Errors and Warnings are different. And turns out I should add a -WarningAction SilentlyContinue to silently ignore the warnings.
Once I did that the warnings went away!
Learnt something new today.