Sunday, March 27, 2011

Dealing with Invalid Delegates with Exchange Web Services and Powershell

Invalid delegates have always been a tricky issue in Exchange an Invalid delegate happens when a mailbox that has a delegate setup and the delegate user account is deleted or disabled(has the Exchange attributes removed). When your using the EWS delegate operations and a mailbox has an invalid delegate you get a message back to tell you the delegate doesn't map to an active directory user however it doesn't tell you who that user was and what type of delegate access that user had. You also can't use the EWS delegate operations to remove a user in this state so you end up with a kind of stalemate solution that requires a manual delete with Outlook. Before going any further its worth covering briefly what happens when you add a delegate to mailbox within Oultook there are three areas of the delegator's mailbox that gets modified.
  • Local freebusy object in the mailbox
  • Permissions on folders that are given access to
  • Rules collection if forward meeting requests option selected
The last things that gets changed is the publicDelegates active directory property.

What happens to the LocalFreeBusy object is of the most interest and has been documented in the protocol document basically it comes down to the following 7 Mapi properties on the LocalFreeBusy object.



These last three properties contain specific setting for each delegate user including the X500DN of the delegated users within PidTagScheduleInfoDelegateEntryIds (Its stored as Addessbook entryid).

If your observant you would have only counted 5 properties which is all that are documented in the protocol document. If you look at the object with a Mapi editor however you would discover two more undocumented properties that also hold information about delegates.

x6870 and x6871

To get the localfreebusy object in a mailbox using EWS there are a few methods you can use the first is to search the NON_IPM_Subtree for and find the FreeBusy Data folder and then search that folder for an item with a subject of localfreebusy. The other option is to use is the PR_FREEBUSY_ENTRYIDS extended property on the Non_IPM_Subtree which contains an array of FreeBusy EntryID's which the 2nd element is the LocalFreeBusy Object which you can convert into a EWSid using a convertid operation and then bind directly to that item.

So if your using EWS and you get "The delegate does not map to a user in the Active Directory" and you want to find out which user this refers to you can compare whats returned in PidTagScheduleInfoDelegateNamesW with the valid delegates you back with normal operation you should be able to work out the invalid delegate.


Anonymous said...

Hi Glen,

Great post, this is just what im looking to do.

I am getting results from Get-MessageOps.MailboxDelegates

however the "compare" cmdlets you have mentioned do not seem to be available. e.g.

Get-MessageOps.MailboxDelegatesRaw : Object reference not set to an instance of an object.

Anonymous said...

Hi Glenn, The module doesn't seem to work with the EWS mAPI 1.2.

Glen Scales said...

You need to change the path in the installed script for 1.1 to 1.2 and the rest should work okay. Or manually copy the Managed api dll's to the module directory


Unknown said...

Hey Glen,

i know its 5 years ago :-) i tried to install and import the modules here but get an error after firing the import-module string, stating that the
"file or assembly "Microsoft.Exchange.WebSerbices, Version=, Culture=neutral,PublicKeyToken=31nf3856ad364e35" or a dependency hasn't found. the system could not find the file."
i installed the current 2.2 API, changed the path and the "install-module" part went a ok.
i'm on a 2013 exchange in hybrid configuration - any ideas where the problem lies? should i try to find a 1.0 version of the API?

thanks in advance!