PowerShell: Clean Mailbox Delegates (update)


I wrote a script a while ago that can remove invalid delegates from a mailbox using a mixture of EWS and Exchange PowerShell.  The limitation of the original script is that is didn’t do anything about the hidden rules that forward messages to delegates, which means that the unexpected NDR issue (as described here) would remain.

I’ve revisited this script recently, and have been able to add support for this hidden message.  More accurately, the clean process deletes this hidden message (which contains all the forward rules), and when the valid delegates are written back to the mailbox, this message is recreated (correctly, without the invalid rules).

The script requires EWS only (it no longer requires an Exchange PowerShell session).  For this, you will need to install the EWS Managed API (any version should work, though the latest is always recommended).

 

Syntax

Reset-Delegates -Mailbox <string>
                   [-PurgeInvalidFreeBusy]
                   [-Username <string> -Password <string> [-Domain <string>]]

                   [-Impersonate]
                   [-EwsUrl <string>]
                   [-IgnoreSSLCertificate <bool>]
                   [-EWSManagedApiPath <string>]
                   [-LogVerbose]
                   [-PermissionsLogFolder <string>]
                   [-WhatIf]

Required:
 -Mailbox Mailbox SMTP email address (OR filename for source list of mailboxes; text file, one mailbox per line)

Optional:
 –PurgeInvalidFreeBusy If specified, any invalid FreeBusy messages (those not defined in PidTagFreeBusyEntryIds) will be deleted
 -Username
Username for the account being used to connect to EWS (if not specified, current user is assumed)
 -Password Password for the specified user (required if username specified)
 -Domain If specified, used for authentication (not required even if username specified)
 -Impersonate Use EWS impersonation to access mailboxes
 -EwsUrl Specify the EWS URL (otherwise autodiscover is used, which is recommended)
 -IgnoreSSLCertificate Ignore any SSL errors
 -EWSManagedApiDLLFilePath Filename and path to the DLL for EWS Managed API (if not specified, the scripts will look for any version)
 -PermissionsLogFolder Path to the folder in which reports of mailbox permissions will be created
 -WhatIf If specified, no changes will be written – the permissions will be logged

 

Examples

.\Reset-Delegates.ps1 user1.ex2k10@hybrid.local -impersonate -whatif

.\Reset-Delegates.ps1 “test@test.onmicrosoft.com” -Username “test@test.onmicrosoft.com” -Password “password”

Reset-Delegates.ps1

Comments (2)

  1. Adam Listek says:

    Awesome script! It's allowed me to remove ghost delegates finally. When I try to remove the delegate forwarding rule, I get: "Object cannot be deleted." I have full permission to the mailbox. Any thoughts?

    -Adam

  2. Eric Pedersen says:

    Howdy,

    Just an FYI, it seems there are issues adding the delegates back to the mailbox, when custom permissions are set on folders.  I initially ran "Reset-Delegates.ps1 user1@domain.com -purgeinvalidfreebusy -impersonate -whatif" and all appeared to be OK.

    But I got this error when running "Reset-Delegates.ps1 user1@domain.com -purgeinvalidfreebusy -impersonate":

    Exception calling "AddDelegates" with "3" argument(s): "This operation can't be performed because one or more folder permission levels were

    set to Custom."

    At C:scriptsReset-Delegates.ps1:355 char:26

    +     $service.AddDelegates <<<< ( $Mailbox, $null, $global:ValidDelegates ) | Write-Verbose

       + CategoryInfo          : NotSpecified: (:) [], MethodInvocationException

       + FullyQualifiedErrorId : DotNetMethodException

    I've added the delegate back to the mailbox manually.

    Cheers,

    Eric