Former Calendar Delegate still receives meeting notifications

Calendar delegation allows a user to manage someone else’s calendar on their behalf. For example, an assistant could be granted delegator rights to their manager’s calendar. Through delegation, the assistant has the right to add, edit, or delete items from their manager’s calendar. A delegate can also be granted the ability to view items marked as private. Aside from calendar permissions, the delegate can receive meeting invites on behalf of the delegator and respond to those invites (accept, decline, tentative, propose new time).

When an assistant no longer needs to access their manager’s calendar, they can be removed as a delegate. Either the manager can do this via the Outlook client or an Exchange administrator by using PowerShell. When their delegation rights have been removed, all access to the calendar is revoked. In addition, meeting invites are no longer sent to the delegate to accept or decline.

It is possible that even when the delegate permissions have been revoked, the assistant could still unexpectantly receive items sent to their manager. In this article, we look at a couple of possible areas that could be forwarding these items to the former delegate.

Let’s get started!

Verify the user is no longer a delegate

The first item to confirm is whether the delegate rights have been properly removed. To do this, connect to Exchange PowerShell and run the following command.

 C:\> Get-MailboxFolderPermission -Identity river.song@xyz.com:\Calendar

FolderName            User                  AccessRights
----------            ----                  ------------
Calendar              Default               {AvailabilityOnly}
Calendar              Rory Williams         {Editor}

In the example above, we are checking the calendar permissions for the user River Song. We use the Get-MailboxFolderPermission command for this purpose. The Identity parameter is a combination of the delegator’s email address and the folder in question. In this case, the calendar folder. You can also use this command against any other folder in the mailbox. In our example, we want to see if River Song’s former assistant, Amy Pond, still has any rights to River’s calendar.

The example output returns two entries. The first is for a user named Rory Williams. We see Rory Williams has editor rights to River’s calendar. We also see a user named Default. Default is the default permission users receive if they have not been granted explicit permissions. In the example above, Rory Williams would receive editor rights to River’s calendar, whereas all other users will only see River’s free/busy information (availability only). Amy Pond is not identified in this output, so she should only receive free/busy information. In this example, Amy is not a delegate.

If the output had returned Amy Pond as a user, we could remove those rights using the Remove-MailboxFolderPermission. For example, to remove all of Amy’s permissions from River’s calendar folder, we would issue the following command.

 C:\> Remove-MailboxFolderPermission -Identity river.song@xyz.com:\Calendar 
-User amy.pond@xyz.com

Check for hidden inbox rules

If a delegate was granted the right to see private calendar items, a hidden inbox rule is created in the delegator’s mailbox. When a delegate is removed from the calendar, it should automatically remove the hidden inbox rule. However, it is possible that when the delegation was removed, the hidden inbox rule was not.

Hidden inbox rules are not visible to the user in Outlook. Only an Exchange Administrator can search for hidden inbox rules. You can check for a hidden inbox rule with the Get-InboxRule command and by leveraging the IncludeHidden parameter. The Mailbox parameter identifies the delegator, not the delegate. An example of this command is below.

 C:\> Get-InboxRule -Mailbox river.song@xyz.com -IncludeHidden

Note: It is typical for hidden inbox rules to exist in a mailbox. For example, all mailboxes have hidden inbox rules to manage out-of-office (OOF) replies and handle junk emails.

Below is an example output of a mailbox with a hidden delegate inbox rule. This output also lists three hidden rules found in all mailboxes. The hidden delegate rule has been highlighted.

 C:\> Get-InboxRule -Mailbox river.song@xyz.com -IncludeHidden
 
Name                                       Enabled  RuleIdentity
----                                       -------  ------------
Junk E-mail Rules                          True     1074015670206105291
Microsoft.Exchange.OOF.InternalSenders     False    1597534569874256321
Microsoft.Exchange.OOF.AllExternalSenders  False    1578951235789512587
 Delegate Rule 1538451201245271021         True     1538451201245271021 

To find out more about what that rule is doing, we can expand our previous command with the addition of the Identity parameter. Note that the identity is not the rule’s name but the value from the RuleIdentity column (e.g., 1538451201245271021). We then pipe that command into a formatted list. The example output below has been abbreviated.

 C:\> Get-InboxRule -Mailbox river.song@xyz.com -IncludeHidden -Identity 1538451201245271021 | Format-List

Description     : If the message:
                        has "Private" sensitivity
                  Take the following actions:
                        redirect the message to 'Pond, Amy'
Enabled         : True
Identity        : Song, River\1538451201245271021
Name            : Delegate Rule 1538451201245271021
Priority        : 0
RuleIdentity    : 1538451201245271021
WithSensitivity : Private
RedirectTo      : {"Pond, Amy" [EX:/o=ExchangeLabs/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=Pond, Amy]}

From the example above, we can see that messages received by River Song (with a sensitivity label of private) will be redirected to Amy Pond. This delegate rule should have been automatically cleaned up after the delegation was removed. We can remove this rule by piping our last command into a remove statement rather than a formatted list.

  C:\> Get-InboxRule -Mailbox river.song@xyz.com -IncludeHidden -Identity 1538451201245271021 | Remove-InboxRule

Confirm
Are you sure you want to perform this action?
Removing inbox rule Identity:"Song, River\1538451201245271021" from mailbox "Song, River".
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  (default is "Y"): Y

We can then confirm the removal of the rule by reissuing our initial command.

 C:\> Get-InboxRule -Mailbox river.song@xyz.com -IncludeHidden
 
Name                                       Enabled  RuleIdentity
----                                       -------  ------------
Junk E-mail Rules                          True     1074015670206105291
Microsoft.Exchange.OOF.InternalSenders     False    1597534569874256321
Microsoft.Exchange.OOF.AllExternalSenders  False    1578951235789512587

With the forwarding delegate rule removed, this should resolve your issue. If not, there are a few other possibilities to check.

Other things to check

One possibility is that mailbox forwarding has been configured between the manager and the former delegate. You can check for mailbox forwarding with the following command.

  C:\> Get-Mailbox -Identity river.song@xyz.com | Format-List Name,ForwardingSmtpAddress,ForwardingAddress

Name                  : River Song
ForwardingSmtpAddress :
ForwardingAddress     :

If mailbox forwarding is present, values will be returned in either the ForwardingSmtpAddress and ForwardingAddress fields. These can be cleared using the Set-Mailbox command. If these fields are blank, like in the example above, mailbox forwarding is not in place. The following example would clear the forwarding for River Song if present.

 C:\> Set-Mailbox -Identity river.song@xyz.com -ForwardingSmtpAddress $null -ForwardingAddress $null -DeliverToMailboxAndForward $false

Another possibility is forwarding is in place with a standard inbox rule. For this, check all inbox rules to see if any include a forward or redirect action.

Have you run into the issue where a hidden delegate rule was still present after the delegate was removed? Have you seen another cause for this issue? Drop a comment below or join the conversation on Twitter @SuperTekBoy.