OPATH: Filterable properties that can be used in Recipient Filters

by Bharat Suneja

Exchange 2007 uses OPATH filters to filter recipients for things like Email Address Policies and Query-based Distribution Groups. Earlier I’d written about my adventures and annoyances with Exchange’s OPATH filters and the recently added support for memberOf attribute in OPATH filters.

Exchange 2007 and later use OPATH filters for filtering recipients in Address Books/GAL, Email Address Policies and Query-based Distribution Groups. OPATH supports a subset of attributes that LDAP filters support in Exchange 2003/2000.

One of the issues was my inability to get a list of filterable properties that can be used in OPATH filters – unlike LDAP filters (I hate to call them legacy filters :), you cannot use *all* the attributes of recipients in an OPATH filter. Commands referenced in the documentation to get this did not work for me the last last time I checked.

Last week, Evan Dodds, a Product Manager on the product team informed me that the list of filterable properties should be up on his blog soon, and here it is, as promised – Filterable Properties in Exchange 2007 RTM. He warns “The rest of this blog post will be long. And boring”. Not if you’ve been waiting for this info Evan… it’s an interesting reference!

Updated list of filterable properties in Exchange 2007 SP1

There are differences in the filterable properties used by the -Filter parameter used in recipient commands such as Get-Mailbox, and the properties used in OPATH filters for the -RecipientFilter parameter (for Address Lists, EmailAddressPolicies, Dynamic Distribution Groups). Both lists have been updated for SP1.

  • Filterable properties for the -Filter parameter: RTM SP1
  • Filterable properties for the -RecipientFilter parameter: RTM SP1

As you’ll find out from the post – and this is one of the issues I’ve had with OPATH – a lot of ldap attributes are referenced in OPATH using a name that’s different from their LDAP Display Name (ldapDisplayName). Here’s a list of some of the common ones:

LDAP Display Name OPATH property
sn
(Last name or surname, as it’s known in many cultures)
LastName
physicalDeliveryOfficeName Office
st
(State)
StateOrProvince
mailNickname Alias
cn CommonName
targetAddress
(used for mail-enabled Contacts/Users)
RawExternalEmailAddress
msExchHideFromAddressLists HiddenFromAddressListsEnabled
memberOf MemberOfGroup
msExchRequireAuthToSendTo RequireAllSendersAreAuthenticated
mail
(the email attribute seen on General tab of a recipient in ADUC)
WindowsEmailAddress

 
Yes, many of the OPATH property names do make a lot more sense, and while these will make things easier to figure out for newbies – as Evan notes in his post, it does add some complexity for folks used to LDAP syntax, filters, and attribute names.

I’m beginning to equate the OPATH property names to what “users” see in their Address Books in Outlook – simplified property names. At times you struggle with the cross-references between those simplified property names, and the actual attribute names that they map to when you fire up a tool like ADSIEdit or edit a Display Template.

If you’ve been using OPATH for any length of time, I am certain you must have felt some of that discomfort. Evan’s post and the list of filterable properties may help alleviate some of that.

{ 4 comments… read them below or add one }

Anonymous June 3, 2007 at 6:00 am

Thanks for the post, and the link to Evan Dodd’s reference material. Unfortunately, Evan disabled comments on his post after accepting a few. My comment/question is:

Why is there a limited set of properties which oPath can filter on?

In Microsoft’s desire to “simplify”, they have broken or reduced functionality by limiting what can be used.

I’m certain I’m in the minority on this issue, but ldap search filters are a fact of life for anyone worth their salt in Active Directory support, and I can’t really see how oPath makes my life better.

Reply

Bharat Suneja June 3, 2007 at 8:16 am

I am yet to come across a really good explanation why (there a limited set of properties which oPath can filter on), though part of it may be related to optimization of ldap queries for address lists, recipient policies and dynamic distribution groups.

What attributes would you like to see included in the list of filterable properties??

>I’m certain I’m in the minority on this issue.
No, you’re not.

I would love to see a way to continue using (now) ‘legacy’ LDAP filters as an alternative, or get the ability to enter LDAP filters and have the shell convert it to OPATH as required.

Reply

Anonymous October 2, 2007 at 5:20 am

Hi,

Been browsing this website a while now, alot of usefull knowledge to be picked up, thank you :-)

Your site doesn’t seem to have a forum so I thought I could ask my question here, sorry in advance if this is frowned upon.

My question involves Exchange 2003 en query based distribution lists.

Since a week i’ve made query distribution lists for each department in my company.

At the user accounts the field deparment is filled in and the query distribution lists filter this field aswell.

Now every user who has “example” filled in at their department field will automatiscally join the query distribution group “example”

It seems the filtering options are AND and not OR based.

I actually have 3 distribution lists which I need 1 user to be a member off. This is not possible without adding a OR filter.

Any help is much appreciated.

Kevin

Reply

V. Edward Martin June 20, 2008 at 11:16 am

I was and am very satisfied with the power and functionality of the LDAP query engine. Creating Address Lists, Query-Based DL, etc was and is straight forward in Exchange 2003. With Exchange 2007, Microsoft complicated and clouded the procedure to such an extend that I am seriously considering keeping an Exchange 2003 mailbox server on-line after the migration just to manage and create Address Lists, Query-Base DL, etc. Trying to accomplish the goal with Exch2007 is just too complicated and time consuming. Whomever at Microsoft thought the Exchange Command Shell would be more useful needs to have an MRI!

Reply

Leave a Comment

Previous post:

Next post: