PSA: The Set-CalendarProcessing cmdlet no longer validates recipient input

I was yesterday’s years old when I found out that the Set-CalendarProcessing cmdlet no longer validates input for some of its parameters, such as the –ResourceDelegates one. Since this has the unfortunate side effect of potentially overwriting your existing configuration, I though I’d spread some awareness.

In the example below, we have a room mailbox, WC, for which a resource delegate has been configured. We want to update the list of resource delegates, but we make a slight typo and enter the value for a non-existent recipient. Instead of telling us that no such recipient exists in the directory, Exchange Online instead “resolves” the value to $null, effectively nullifying the current resource delegate list.

Get-CalendarProcessing wc | select -ExpandProperty resourceDelegates

Get-Recipient 453435

Set-CalendarProcessing wc -ResourceDelegates 453435

Get-CalendarProcessing wc | select -ExpandProperty resourceDelegates

The expected behavior would be to throw in an error about the invalid recipient value and halt the cmdlet execution. This is indeed the behavior we’ve seen in the past. Instead, this validation seems to no longer be performed, the cmdlet proceeds to execute and as the provided list of values effectively evaluates to an empty array, results in clearing the list of delegates.

The bad news is that the -ResourceDelegates parameter is not the only one affected by this issue. Some other parameters leveraged by the Set-CalendarProcessing cmdlet are also affected, such as the -BookInPolicy or the -RequestInPolicy ones. I haven’t bothered checking all of them, but it does look like any multi-valued parameter that does not support the hash-table notation is affected. I’ll leave it to Microsoft to determine the full scope on this.

On the positive side of things, one can argue that this behavior helps in scenarios where a single incorrect value would result in failing the execution of the cmdlet when invoked with a collection of values. For example, if we pass a collection of “userA, non-existent-recipient, userB”, the cmdlet will proceed with adding userA and userB as delegates, while ignoring the invalid entry. If the passed collection evaluates to an empty array however, the list of resource delegates will still be cleared, which is not what you’d want to happen.

Whether this is the expected behavior now I cannot tell, but it certainly does not match the experience we’re used to with the rest of Exchange Online’s cmdlets. I will let you know how things turn out.

/// UPDATE Dec 2025: The Exchange team has updated the cmdlet to throw an ManagementObjectNotFoundException for any “invalid” entry provided, thus eliminating the issue with “overwriting” existing values, and bringing the behavior in line with other cmdlets. Case closed.