PowerShell: Clean mailbox delegates No ratings yet.

An updated version of this script (that also handles the hidden forwarding rule) is available here:http://blogs.msdn.com/b/emeamsgdev/archive/2014/05/16/powershell-clean-mailbox-delegates-update.aspx

Granting delegate access to a mailbox stores the permission on the mailbox to which the permission is granted.  But what happens when a user is deleted?  The simple answer is nothing – deleting a user (or other AD object) does not delete references to that object in other places.  What this means is that you can end up with invalid references on other objects.  This is not normally an issue (even if it can get untidy in environments that have been around for a while).  We had a case recently where after a migration, the invalid delegates on certain mailboxes were causing an issue though.

Attached is a PowerShell script that uses EWS to retrieve all the delegates on a particular mailbox, and once done it will clear them and add only the valid ones back.  Syntax is as follows:


Reset-Delegates -Mailbox <string>
                   [-ReportOnly <bool>]
                   [-Username <string> -Password <string> [-Domain <string>]]
                   [-Impersonate <bool>]
                   [-EwsUrl <string>]
                   [-PowerShellUrl <string>]
                   [-IgnoreSSLCertificate <bool>]
                   [-EWSManagedApiPath <string>]
                   [-LogVerbose <bool>]
                   [-PermissionsLogFolder <string>]

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

 -ReportOnly : By default this it true, which means no changes will be applied to the mailbox
 -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 : Set to $true to use impersonation.
 -EwsUrl : Forces a particular EWS URl (otherwise autodiscover is used, which is recommended)
 -PowerShellUrl : Forces a particular remote Powershell URL (otherwise you need to have imported the remote session into the current PowerShell session)
 -IgnoreSSLCertificate : If $true, then any SSL errors will be ignored
 -EWSManagedApiDLLFilePath : Filename and path to the DLL for EWS Managed API (if not specified, default path for v1.2 is used)
 -LogVerbose: Show detailed output
 -PermissionsLogFolder: Path to the folder in which reports of mailbox permissions will be created



Please rate this

Leave a Reply

Your email address will not be published. Required fields are marked *